Access-tietokantasovelluksen rooli tietokannan hallintajärjestelmässä

Tietokannan sisällön konstruoinnissa ja ohjelmoinnissa saavutettiin tyydyttäväk-si koettu taso syyskuussa 2001, jonka jälkeen tietokanta piti saada toimimaan verkkoympäristössä keskusvarastolla toteutettavan pilotin aikana. Ideointia ja luonnostelua tehtiin niin kauan, että valmiina olevat luonnokset ja demoversiot täyttivät konstruoinnille asetetut perusvaatimukset ja kaikkiin ongelmakohtiin oli visioitu jonkinlainen toteuttamiskelpoinen ratkaisu. Pilotin katsottiin tarkoittavan myös varsinaisen implementoinnin ensimmäistä vaihetta, sillä välittömästi kon-struktioon liittyvien teknisten kysymysten ratkaisemisen ja järjestelmän käyt-töönoton jälkeen keskusvarastolla kaikki muut varastot haluttiin liittää samaan järjestelmään keskusvarastopilotista saatuihin kokemuksiin tukeutuen. Konstruk-tion eri tavoin tapahtuva testaaminen oli jo aloitettu keskusvarastolla yhtä aikaa tietokannan sisällön suunnittelun kanssa eli kesäkuussa 2000 ja se jatkui käytän-nössä toukokuuhun 2002, jolloin järjestelmä oli otettu käyttöön kaikissa varas-toissa. Ensimmäinen todellinen asiakaspalautedata syötettiin tietokantaan tes-tausvaiheessa manuaalisesti keskusvaraston reklamaatioiden selvittelijöiden toi-mesta kevään ja kesän 2001 aikana. Testaaminen oikealla datalla oli tärkeää, koska näin pystyttiin demonstroimaan tietokannan toimintoja, käyttöä ja hyödyn-tämistä konkreettisesti. Oikealla asiakaspalautedatalla suoritetun demonstroinnin lähtökohtainen tarkoitus oli esitellä tietokannan rakennetta ja toimintaa teknises-tä näkökulmasta, mutta tutkijalle hieman yllätteknises-täen logistiikkajohdon kiinnostus kohdistui heti teknisiä asioita enemmän testiaineiston analysointiin, koska tieto-kanta mahdollisti aineiston tarkastelun uusista näkökulmista.

Tietokannan sisällön ohjelmoinnin jälkeen syyskuussa 2001 tietokanta piti saada toimimaan verkkoympäristössä. Relaatiotietokannan ohjelmointityö oli osoitta-nut tutkijalle, että Access oli hyvä työkalu tiedon hallintaan pienen mittakaavan toiminnassa yhdellä tietokoneella käytettäessä, mutta monien käyttäjien ja suuri-en datamassojsuuri-en verkkoympäristöön ssuuri-en ei pitänyt olla yhtä hyvin soveltuva³¹². Päätöksenteon kannalta olikin tärkeää määritellä, millaisia roolivaihtoehtoja

312 Tietohallinnon konsultoivilta it -asiantuntijoilta saadun tiedon perusteella voitiin tehdä johto-päätös, että ”paikalliseen käyttöön” tarkoitetut Access-tietokannat kuormittaisivat liikaa yrityk-sen tietoverkkoa aiheuttaen jopa verkon ”kaatumista”, vaikka tietokanta olisi periaatteessa mah-dollista saada toimimaan sellaisenaan verkkoympäristössä.

cess-sovellukselle oli mahdollista määritellä osana tietokannan hallintajärjestel-mää ja toisaalta, mikä vaihtoehdoista oli tietototeknisestä näkökulmasta järkevin-tä toteuttaa. Rajoituksia tietoteknisiin mahdollisuuksiin aiheutti heti lähtötilan-teessa se, että käytettävissä ei ollut Access-sovelluksen uusin ohjelmaversio, vaan kehitysprojektissa piti tyytyä vuoden 1997 ohjelmaversioon³¹³. Tutkija määritteli Access-sovellukselle neljä erilaista roolivaihtoehtoa, joista ensimmäi-sessä Access-ohjelman rooli osana tietokannan hallintajärjestelmää oli suuri, kahdessa seuraavassa Access-ohjelman rooli jäi pienemmäksi ja viimeisessä sille ei enää jäänyt lopullisessa konstruktiossa roolia lainkaan.

Ensimmäisessä vaihtoehdossa Access-sovellus sisältäisi sekä tietovaraston että asiakaspalautteen laadinnassa ja käsittelyssä tarvittavat tietojen syöttölomakkeet.

Lisäksi ohjelmalla generoitaisiin kaikki kyselyt ja raportit datan hyödyntämisek-si. IBM-toiminnanohjausjärjestelmästä tarvittavat tiedot linkitettäisiin Access-sovelluksen päätauluun, joka samalla toimisi informaation päätietovarastona (KUVIO 24).

Windows -ympäristö

IBM-linkitykset

Access -sovellus

Access -raportointi

palautteen

käsittely-lomake Access -taulut

tietovarasto

KUVIO 24: Access-ohjelman rooli osana it -konstruktiota; vaihtoehto 1

Toisessa vaihtoehdossa Access-sovellus sisältäisi reklamaatioiden laadinnassa ja käsittelyssä tarvittavat tietojen syöttölomakkeet. Lisäksi ohjelmalla generoitaisiin kaikki kyselyt ja raportit datan hyödyntämiseksi. IBM-toiminnanohjaus-järjestelmästä tarvittavat tiedot linkitettäisiin erilliseen tietovarastoon, josta ne linkitettäisiin edelleen Access-ohjelman päätauluun (KUVIO 25).

313 Toimisto-ohjelmistojen päivityksistä vastasi keskitetysti tietohallinto-osasto ja tiedossa ei ollut uutta päivitysinvestointia, jonka yhteydessä samaan toimisto-ohjelmistotuoteperheeseen kuulunut Access olisi myös päivitetty.

Windows -ympäristö

IBM-linkitykset

Access -sovellus

Access -raportointi

palautteen

käsittely-lomake tietovarasto

Access -taulut

KUVIO 25: Access-ohjelman rooli osana it -konstruktiota; vaihtoehto 2

Kolmannessa vaihtoehdossa Access-sovellus olisi ainoastaan ns. käyttäjäliitty-mä, jolla generoitaisiin erilaisia kyselyjä ja raportteja erillisestä verkkoon ohjel-moidusta tietovarastosta haetun datan avulla. Tietovarastoon tiedot linkitettäisiin tarvittavilta osin IBM-toiminnanohjausjärjestelmästä ja tietojen käsittely tapah-tuisi räätälöidysti ohjelmoidulla graafisella käyttäjäliittymällä, joka olisi myös linkitetty tietovarastoon (KUVIO 26).

Windows -ympäristö

IBM-linkitykset

Access -sovellus

Access -raportointi

tietovarasto graafinen

käyttäjäliittymä:

käsittelylomake

Access -taulut

KUVIO 26: Access-ohjelman rooli osana it -konstruktiota; vaihtoehto 3

Neljännessä vaihtoehdossa Access-sovellusta hyödynnettäisiin vain tietojen vä-listen yhteyksien määrittelyssä ja toiminnan hahmottelussa eli se olisi vain kon-struktion suunnittelutyökalu. Windows-lähiverkkoon ohjelmoitaisiin tietovaras-to, jonka käyttämiseksi verkkoon ohjelmoidaan graafisia käyttäjäliittymiä räätä-löidysti käyttötarkoituksen mukaan. Graafiset käyttäjäliittymät ohjelmoitaisiin erikseen asiakaspalautteen käsittelijöille ja asiakaspalautteen hyödyntäjille. IBM-toiminnanohjausjärjestelmästä linkitettäisiin tarvittavat tiedot suoraan tietovaras-toon. Vaihtoehdon toteuttaminen tarkoittaisi siis Access-sovelluksen hylkäämistä ja korvaamista kokonaan räätälöidyllä sovelluskehitystyöllä (KUVIO 27).

Windows -ympäristö

IBM-linkitykset

tietovarasto graafinen

käyttäjäliittymä:

käsittelylomake

graafinen käyttäjäliittymä:

raportointi graafinen

käyttäjäliittymä:

taulujen ylläpito

KUVIO 27: Access-ohjelman rooli osana it -konstruktiota; vaihtoehto 4

Projektin alussa määritellyn konstruktion edullisuus -perusvaatimuksen nojalla Access-ohjelmalle haluttiin antaa mahdollisimman suuri rooli asiakasinformaa-tiojärjestelmässä, mikä olisi tarkoittanut edellä esitetyistä rakenteellisista vaihto-ehdoista ensimmäisen vaihtoehdon toteuttamista³¹⁴. Ensimmäinen vaihtoehto arvioitiin myös riittäväksi käytettävyys -perusvaatimuksen toteutumiseksi. Tieto-teknisestä näkökulmasta myös yksinkertaisuus -perusvaatimus tuki tätä näkemys-tä, mutta toimivuus -perusvaatimuksen toteutumisesta ei tällöin kuitenkaan ollut mitään varmuutta. Toimivuuden varmistamiseksi Access-ohjelman roolista osana konstruktiota päätettiin kuitenkin tinkiä tarpeen vaatiessa, mikä tarkoitti siirty-mistä edellä esitetystä ensimmäisestä vaihtoehdosta seuraavaan ja tarvittaessa aina neljänteen vaihtoehtoon asti. Vastoin it -asiantuntijoilta jo aiemmin saatuja arvioita ensimmäisen vaihtoehdon epärealistisuudesta Access-sovellusta päätet-tiin kuitenkin testata yrityksen tietoverkossa ensimmäisen roolin määrityksen kuvaamalla tavalla³¹⁵.

Syyskuussa 2001 tutkijan suorittama testaus Talotekniikkatukku Oy:n logistiik-kaosastolla osoitti, että tietokanta oli toimiva ja yhteiskäyttö oli mahdollista Windows-lähiverkossa pienillä data- ja käyttäjämäärillä. Data- ja käyttäjämäärän kasvaessa verkon toiminta alkoi kuitenkin hidastua kääntäen samassa suhteessa.

Keskusvarastolla tietokannan varsinainen käyttö onnistui pienillä data- ja käyttä-jämäärillä kohtuullisen hyvin, mutta tietokannan avaamisessa ja tietokantaan kirjattujen uusien tietojen tallentamisessa esiintyi suuria vaikeuksia. Tietokannan käyttö saattoi jopa jumittaa tietokoneen täydellisesti, erityisesti jos joku muu saman toimipisteen työntekijä yritti tehdä jotain muuta työtä samassa

314 Mitä enemmän tietokannan hallintajärjestelmässä pystyttäisiin tukeutumaan valmiin Access-sovelluksen käyttöön, sitä vähemmän projekti edellyttäisi räätälöityä sovelluskehitystä, joka olisi ostettava ulkopuolisena palveluna lisäkustannuksia aiheuttaen.

315 Ajatuksena oli, että kun asiaan saadaan testaamisen kautta täysi varmuus, voidaan myöhem-min välttää turhaa spekulointia vaihtoehdon toimivuudesta. Menettelyyn vaikutti paljon myös se seikka, että testaus ei vaatinut erityisosaamista ja tutkijan oli helppo suorittaa testaus logistiikka-osastolta käsin.

kossa kuormittaen verkkoa samanaikaisesti lisää. Tutkijan oman arvion mukaan pullonkaulana ei kuitenkaan ollut relaatiotietokannan käyttöön tarvittu tietoko-neiden kapasiteetti vaan tietoverkon tiedonsiirtokapasiteetti. Sitä tarvittiin ns.

palvelintietokoneella sijainneen tietokannan avaamisen ohella tietojen verkon kautta tapahtuvaan tallentamiseen. Tutkija totesi yhdessä keskusvaraston rekla-maatioiden selvittelijöiden kanssa tiedonsiirtokapasiteetin olevan keskusvarastol-la merkittävästi Vantaan päätoimipisteen kapasiteettia alhaisempi³¹⁶. Tietojen tallennettavuudesta muodostui uusi vaatimus tietokantakonstruktion toimivuus -perusvaatimuksen täyttämiseksi. Tietokannan avaaminen, tietojen selaaminen, uusien tietojen kirjaaminen ja tallentaminen oli yksinkertaisesti saatava toimi-maan kunnolla³¹⁷.

Koska muiden Access-roolivaihtoehtojen tekninen määrittely edellytti sellaista tietoteknistä erityisosaamista, jota tutkijalla itsellä ei ollut, oli asiassa tukeudut-tava tietohallinnon puoleen. Tietohallinnon IBM-asiantuntijat eivät kuitenkaan osanneet hekään auttaa asiassa, koska heidän osaamisensa keskittyi ymmärrettä-västi IBM-toiminnanohjausjärjestelmään eikä Windows NT-käyttöjärjestelmään.

Myöskään Windows-lähiverkon ylläpidosta vastannut taho ei osannut auttaa asi-assa, koska heillä ei ollut riittävästi Access-osaamista. Asiassa oli pakko turvau-tua ulkopuoliseen it- asiantuntijan apuun. Valinnan käytettävästä it -konsultista teki tietohallinto, mutta vastuu projektin eteenpäin viemisestä yhdessä it -konsultin kanssa säilyi tutkijalla. Tutkijan yhteistyö ensimmäisen it -konsultointiyrityksen kanssa alkoi it -konsultin tekemän ns. määritystarjouksen käsittelyllä³¹⁸. Tietotekninen määritys päätettiin tehdä valitun konsultointiyrityk-sen toimesta.

316 Keskusvaraston henkilöstö oli tiedostanut ”verkon hitauden” jo pitkään sitä pidettiin jopa ongelmana. ”Hidas verkko” ja ”kaatuvat koneet” hidastivat työntekoa ja koettelivat ajoittain työntekijöiden kärsivällisyyttä. Verkon toiminta oli tietohallinnon vastuulla, mutta lokakuussa 2001 keskusvaraston henkilöstö ei vielä saanut tietohallinnolta myönteistä vastausta verkkokapa-siteetin nostamiseksi. Verkon hitaus passivoi tutkijan arvion mukaan keskusvaraston henkilöstöä Windows-verkon käytössä. Tutkijalle oli jo tässä vaiheessa täysin selvää, että konstruktion toi-mivuuden varmistaminen osoittautuisi keskusvarastolla erittäin haasteelliseksi tehtäväksi ilman verkkokapasiteetin lisäystä.

317 Vrt. Davenport & Short (1990): Informaatioteknologia vaikuttaa merkittävästi liiketoiminnan arkkitehtuurin uudelleen suunnittelussa. Samalla tavoin kuin se voi olla prosessien uudistamisen keskeinen mahdollistaja, se voi olla myös vaikeuttaa prosessien uudistamista ja olla siten uudis-tamisen estäjä.

318 Määritystarjous esittelee palvelutarjoajan yhteistyökumppanina yleisesti, palvelutarjoajan osaamisalueet ja referenssejä suoritetuista projekteista. Määritystarjouksessa esitetään hinta esi-selvitystyön tekemiselle. Esiesi-selvitystyön tuloksena valmistuu määrämuotoinen määritysdoku-mentti, jossa esitetään kaikki tekniset ominaisuudet ja -vaatimukset rakennettavan konstruktion toteuttamiseksi. Määritysdokumentin pohjalta palvelutarjoaja tekee uuden tarjouksen teknisestä toteutuksesta, johon määritellään erikseen tarjous toteutukseen liittyvästä projektinhallinnasta.

4.2.3.3 Järjestelmäarkkitehtuurin rakentaminen ulkopuoliseen