Infosüsteemi juurutamine

**Infosüsteemi juurutamine** (ing k *implementation*, *adaptation*) tähendab uue süsteemi kasutuselevõttu. See on üks osa tarkvaraarenduse elutsüklist. Sujuva ülemineku ja tõhususe tagamiseks on juurutamine enamasti jagatud mitmeks toiminguks, näiteks programmeerimine, testimine, kasutajakoolitus. Uue süsteemi ladus sidumine olemasolevate tööprotsessidega ja ettevõtte igapäevategevustega on oluline, et tagada mitte ainult funktsionaalsus ja tehniline töökindlus, vaid ka vastavus kasutajate vajadustele ning organisatsiooni strateegiliste eesmärkide saavutamine. Need tegurid määravad juurutamise edukuse. 

## Juurutamise etapid
Infosüsteemi juurutamisetappide läbiviimine mõjutab seda, kuidas kasutajad suhtuvad hiljem infosüsteemi ja kui edukalt see uus süsteem kasutusele võetakse. Enamasti sõltub projekti õnnestumine varem püstitatud ootustest (nt ajaraamistik, eelarves püsimine). Tihti puudub üksmeel projektiga seotud osaliste seas – näiteksprojektijuhid hindavad edukust finantsmõõdikute järgi, kasutajad peavad oluliseks süsteemi kasutusmugavust. Projektides kiputakse juurutamise faasi alahindama ning ei keskenduta võrdselt kõigile etappidele. Enamjaolt hõlmab juurutamine planeerimist, muutuste juhtimist, koolitamist, kasutajatuge, dokumentatsiooni, testimist ja programmeerimist. 

### Planeerimine ja muutuste juhtimine
Hea planeerimistöö (sh projekti selge määratlus) suurendab juurutamise edukust. Võidakse alahinnata vajalikku aega ja kiirustamise tõttu võib infosüsteemi juurutamine ebaõnnestuda. Planeerimise alla kuulub ka üleminekustrateegiate põhjalik analüüs, mille tulemusel jõutakse organisatsioonile sobivaima lahenduseni. Kasutaja vajaduste ja soovide määramine on planeerimisel oluline, sest töötajate ootused süsteemi toimimisele mõjutavad nende hilisemat süsteemiga rahulolu ja süsteemi kasutatavust. 

Üks suurim ebaedu põhjustaja on inimeste ja organisatsioonide vastuseis muutustele, mistõttu on juurutamise õnnestumiseks vaja juhtide häid suhtlemis- ja koostööoskuseid. Tulevastele süsteemi kasutajatele tuleb selgitada, milline kasu kaasneb muutustega, arvestades samas inimeste vajadustega. Samuti on olulised infosüsteemide spetsialistid, kes tähtsustavad kasutajatest erinevaid eesmärke, neil on teistsugused teadmised, mille tõttu võib nende kahe grupi vahel tekkida arusaamatusi. 

### Koolitamine, kasutajatugi ja dokumentatsioon
Juurutamise dokumenteerimine jagatakse enamasti kahte kategooriasse: süsteemihooldus ja kasutajajuhendid. Esimene neist keskendub süsteemi disainile ja funktsioonidele, teine aitab kasutajatel süsteemi mõista ja kasutada. Heas kasutusjuhendis on kirjas informatsioon erinevate protseduuride ja süsteemi toimimise kohta ning selle koostamisel on kaasatud nii süsteemi disainerid, arendajad kui ka kasutajad. 

Paljudes Ameerika Ühendriikide ettevõtetes peetakse kasutajate väljaõpet tähtsaks, kuid infosüsteemide juurutamisel eiratakse sageli koolitamise vajadust, eriti alahinnatakse arvutioskuste arendamist. Mõnikord ongi mõistlik loobuda kasutajate põhjalikust koolitamisest, näiteks kui tegemist on tuntud valmislahendustega (nt Microsoft Office) või väiksemate süsteemidega. Kasutajakoolitus peaks toimuma enne süsteemi rakendamist, kuid koolitusmaterjalid peaksid juba selleks ajaks olema kooskõlas süsteemi lõpliku vormi ja välimusega. 

Tavaliselt on klienditugi olnud saadaval paberil, veebipõhiste juhendite, kolmandate osapoolte või kaastöötajate näol, kuid seda on kasutajate poolt peetud sageli ebapiisavaks. Arvutite laialdase leviku ja klient-server arhitektuurile ülemineku tulemusena kasvas lisatoe saamise vajadus, kuna seadmete ja tarkvara ühilduvuse säilitamisel on vaja rohkem abi. Sageli kuulub kasutajatugi siiski süsteemiarenduse hoolduse faasi  ja mõnikord ei eristata koolitamist kasutajatoest. 

### Programmeerimine ja testimine
Programmeerimine on protsess, mille tulemiks on töötav arvutikood vastavalt süsteemi disaini kirjeldustele. Programmeerimine on enamasti intensiivsem asutusesiseselt arendatud süsteemide puhul, sest see etapp on üks aeganõudvamaid ja ressursikulukamaid. Tänapäeval eelistatakse sisseostetud programme, et organisatsioon ei peaks tegelema ka programmeerimiskuludega. Testimine aitab määratleda, kas koostatud süsteem vastab soovitud tulemustele ja organisatsiooni vajadustele. See tegevus aitab tuvastada vigu kogu süsteemiarenduse tsükli vältel, kuid kaasneb oht, et kontrollimise käigus tekivad uued vead. Võimalikult kvaliteetsete testide läbiviimiseks on vaja kaasata palju osapooli (sh kasutajad) ja toetav keskkond. Ressursipuuduse tõttu kasutatakse testimisel piiratud koguses sisendeid, seevastu pannakse rõhku tõhususele ja õigete testitüüpide valikule.  

Mõned võimalikud testide tüübid: 

* **[[Ühiktestimine|Ühik]]-/moodultestimine** – automatiseeritud tehnika, kus testitakse iga tarkvaramoodulit eraldi, et leida üles võimalikud vead enne integreerimist terviklikku süsteemi. Seda testi nimetatakse ka "valge kasti" meetodiks, sest läbiviija on enamasti mooduliloojast arendaja, kes on juba tuttav tarkavara seesmise struktuuri ja toimimispõhimõtetega. 
* **Integratsiooni testimine** – sõltumatu testija poolt läbi viidud katsetamiseprotsessi käigus kombineeritakse ja ühendatakse järk-järgult erinevaid mooduleid, et kontrollida nende koostööd. 
* **Koodikontroll** (ing k *desk checking*) – paberi ja pliiatsi meetod, kus programme mõistev spetsialist koostab käsitsi testjuhtumite ja käskude alusel erinevaid koodilahendusi.
* **Süsteemtestimine** – integreeritakse programmid süsteemidesse ja testitakse mitte ainult mooduleid ja programme, vaid ka nende vahelisi liideseid. Üritatakse leida vastus küsimusele "kuidas süsteem töötab tervikuna?" ja seda nimetatakse "musta kasti" meetodiks, sest testija ei ole koodiga kursis, vaid kasutab osa, mis on nähtav ainult kasutajatele.
* **Koodi ülevaatus** – käsitsi tehtav test, kasutatakse vastava programmeerimiskeele enamlevinud vigade nimekirja, mida võrreldakse enda koodiga.
* **Vastuvõtutest** või üleandmistest (*acceptance test*) – kogu süsteemi testimine kasutaja poolt, kes hindab, kas süsteem vastab kliendi ootustele ja varem kokku lepitud strandarditele, mille põhjal saab järeldada süsteemi paigaldamisvalmidust.
Testimine ja programmeerimine toimuvad enamasti paralleelselt ning tihti võivad mõlemad etapid enne juurutamist tehtud olla, sest on kasutatud agiilset lähenemismeetodit.

## Juurutamisstrateegiate eelised ja puudused
Infosüsteemi juurutamisstrateegia valik määrab suuresti selle, kui edukalt protsess kulgeb. Seetõttu tuleb organisatsioonis põhjalikult kaaluda erinevate lähenemiste tugevusi ja nõrkusi, et jõuda enda ettevõttele sobivaima lahenduseni. 

Enamasti eristatakse süsteemivahetuse puhul nelja strateegiat – paralleelne, otsene, moodulipõhine ja pilootstrateegia. Mõnikord lisatakse liigitusse ka hübriidlahendus, kus kombineeritakse mitu süsteemivahetuse taktikat, et suurendada paindlikkust ja vähendada riske.

### Otsene süsteemivahetuse strateegia
Selle taktika (ing k *direct cutover)*) puhul on vastu võetud otsus, et eelmise süsteemi kasutamine lõpetatakse kindlal ajal, millest alates on võimalik kasutada ainult uut infosüsteemi. See lähenemine sobib eelkõige väiksematele ja vähem hädavajalikele süsteemidele, sest nii on juurutamise õnnestumisel kulud väiksemad ja protsess kiirem ning sujuvam. Samas on sellel suurem tõrgete oht, sest kasutajad sõltuvad täielikult uuest süsteemist ja kõik vead mõjutavad tööprotsesse ning organisatsiooni tegevust. Varuvariandi puudumise tõttu võib olla raske ka vana süsteemi taastada, mistõttu tööülesannete täitmine viibib veelgi. Juurutamist raskendab ka see, et süsteem tuleb paigaldada korraga kõigile seadmetele.

### Paralleelstrateegia
Paralleelstrateegia puhul kasutatakse samaaegselt nii vana kui ka uut süsteemi, kuni ollakse kindlad, et uus süsteem toimib. Seda peetakse enamasti vähem riskantseks, sest juurutamise ebaõnnestumise puhul on olemas tagavara võimalus, ehk vana süsteem. Selle strateegia eelis on uue süsteemi täiustamise lihtsus, kuna tööprotsessid ei katke. Teisalt on see kulukam, kuna ettevõttel tuleb hallata kahte süsteemi korraga. Samuti on selle meetodi ajakulu suurem võrreldes otsese juurutamisega. Lisaks tekivad ka erinevad probleemid personaliga, sest töötajad peavad tegutsema mitmes süsteemis samaaegselt, mõjutades töötajate töökoormust, kasutajate soortitust ja suutlikkust täita oma tööülesandeid. 

### Katsetamise strateegia
Selle strateegia puhul on samuti kasutusel kaks infosüsteemi korraga, aga uut süsteemi rakendatakse ainult organisatsiooni ühes osas (nt raamatupidamisosakonnas Tartu kontoris). Tegemist on otsese ja paralleelse juurutamise kombineerimisega. Kui juurutamine on ühes kohas edukas, siis laiendatakse süsteemi kogu organisatsioonile. Selle strateegia on uue süsteemiga seotud probleemidega tegelemine lihtsam, kuna takistuse likvideerimise ajal ei ole terve organisatsiooni tegevus häiritud. Samas ei pruugi üks osakond olulisi (nt suure tehingumahuga) probleeme tähele panna. Lisaks kaasneb selle lahenduse puhul lisakoormus arendajatele, kes peavad süsteemide vahelist andmejagamist korraldama. 

### Etapiviisiline strateegia

Etapiviisiline lähenemine sarnaneb katsetamise strateegiaga, sest juurutamist alustatakse ühest osakonnast või rakendusest (nt raamatupidamine). Selle meetodi puhul antakse kasutamisõigused samm-sammult aina uutele kasutajatele. Seega töötavad üheaegselt nii vana kui uus süsteem, aga nende vahel toimub pidev koostöö. Tegemist on mõõduka riskitasemega strateegiaga, mis aitab ühes kohas tekkivad probleemid lahendada enne süsteemi teisele kasutajagrupile üleandmist. Teiselt poolt võib probleemiks saada see, et kõik ei tööta samasuguses versioonis. Seetõttu on suur koormus IT-osakonnal, kelle ülesanne on andmete migreerimist ja süsteemidevahelist sünkroonimist korraldada.

Näide: Eesti Ehitisregister, mille uue versiooni juurutamist alustati järk-järgult 2021. aastal, kuna süsteemi tegevust ei saanud katkestada. 

### Hübriidmeetod
Hübriidmeetod ühendab mitut juurutamisstrateegiat, et vähendada mõju olemasolevatele süsteemidele ja argiprotsessidele. Tegemist on madala riskitasemega lähenemisega, sest selle puhul on alles erinevad süsteemiversioonid teatud osakondades või rakendustes, pakkudes paindlikkust ja vähendades üleminekuga seotud riske.

## Vaata ka
*Projektijuhtimise elutsükkel
*Infotehnoloogia

## Viited