Infosüsteemi juurutamine
Infosüsteemi juurutamine (ing k implementation, adaptation) tähendab uue süsteemi kasutuselevõttu.[1][2][3] See on üks osa tarkvaraarenduse elutsüklist.[1] Sujuva ülemineku ja tõhususe tagamiseks on juurutamine enamasti jagatud mitmeks toiminguks, näiteks programmeerimine, testimine, kasutajakoolitus.[1][2][3] 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.[1] Need tegurid määravad juurutamise edukuse.[4]
Juurutamise etapid
[muuda | muuda lähteteksti]Infosüsteemi juurutamisetappide läbiviimine mõjutab seda, kuidas kasutajad suhtuvad hiljem infosüsteemi ja kui edukalt see uus süsteem kasutusele võetakse.[5] Enamasti sõltub projekti õnnestumine varem püstitatud ootustest (nt ajaraamistik, eelarves püsimine).[6] Tihti puudub üksmeel projektiga seotud osaliste seas – näiteksprojektijuhid hindavad edukust finantsmõõdikute järgi, kasutajad peavad oluliseks süsteemi kasutusmugavust.[7] Projektides kiputakse juurutamise faasi alahindama ning ei keskenduta võrdselt kõigile etappidele.[4] Enamjaolt hõlmab juurutamine endas planeerimist, muutuste juhtimist, koolitamist, kasutajatuge, dokumentatsiooni, testimist ja programmeerimist. [1][2][3]
Planeerimine ja muutuste juhtimine
[muuda | muuda lähteteksti]Hea planeerimistöö (sh projekti selge määratlus) suurendab juurutamise edukust.[2] Võidakse alahinnata vajalikku aega ja kiirustamise tõttu võib infosüsteemi juurutamine ebaõnnestuda.[4] Planeerimise alla kuulub ka üleminekustrateegiate põhjalik analüüs, mille tulemusel jõutakse organisatsioonile sobivaima lahenduseni.[3] 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.[2]
Üks suurim ebaedu põhjustaja on inimeste ja organisatsioonide vastuseis muutustele, mistõttu on juurutamise õnnestumiseks vaja juhtide häid suhtlemis- ja koostööoskuseid.[1] Tulevastele süsteemi kasutajatele tuleb selgitada, milline kasu kaasneb muutustega, arvestades samas inimeste vajadustega.[3] 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.[1]
Koolitamine, kasutajatugi ja dokumentatsioon
[muuda | muuda lähteteksti]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.[2] 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.[8]
Paljudes Ameerika Ühendriikide ettevõtetes peetakse kasutajate väljaõpet tähtsaks, kuid infosüsteemide juurutamisel eiratakse sageli koolitamise vajadust, eriti alahinnatakse arvutioskuste arendamist.[2] 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.[5] Kasutajakoolitus peaks toimuma enne süsteemi rakendamist, kuid koolitusmaterjalid peaksid juba selleks ajaks olema kooskõlas süsteemi lõpliku vormi ja välimusega.[8]
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.[2] Sageli kuulub kasutajatugi siiski süsteemiarenduse hoolduse faasi [3] ja mõnikord ei eristata koolitamist kasutajatoest.[2]
Programmeerimine ja testimine
[muuda | muuda lähteteksti]Programmeerimine on protsess, mille tulemiks on töötav arvutikood vastavalt süsteemi disaini kirjeldustele.[2] Programmeerimine on enamasti intensiivsem asutusesiseselt arendatud süsteemide puhul, sest see etapp on üks aeganõudvamaid ja ressursikulukamaid.[8] Tänapäeval eelistatakse sisseostetud programme, et organisatsioon ei peaks tegelema ka programmeerimiskuludega.[1] Testimine aitab määratleda, kas koostatud süsteem vastab soovitud tulemustele ja organisatsiooni vajadustele.[1][8] See tegevus aitab tuvastada vigu kogu süsteemiarenduse tsükli vältel, kuid kaasneb oht, et kontrollimise käigus tekivad uued vead.[9] Võimalikult kvaliteetsete testide läbiviimiseks on vaja kaasata palju osapooli (sh kasutajad) ja toetav keskkond.[8] Ressursipuuduse tõttu kasutatakse testimisel piiratud koguses sisendeid, seevastu pannakse rõhku tõhususele ja õigete testitüüpide valikule.[9]
Mõned võimalikud testide tüübid:
- Ühik-/moodultestimine – automatiseeritud tehnika, kus testitakse iga tarkvaramoodulit eraldi, et leida üles võimalikud vead enne integreerimist terviklikku süsteemi.[2] 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.[9]
- Integratsiooni testimine – sõltumatu testija poolt läbiviidud katsetamiseprotsessi käigus kombineeritakse ja ühendatakse järk-järgult erinevaid mooduleid, et kontrollida nende koostööd.[2][9]
- Koodikontroll (ing k desk checking) – paberi ja pliiatsi meetod, kus programme mõistev spetsialist koostab käsitsi testjuhtumite ja käskude alusel erinevaid koodilahendusi.[2]
- Süsteemtestimine – integreeritakse programmid süsteemidesse ja testitakse mitte ainult mooduleid ja programme, vaid ka nende vahelisi liideseid.[2] Ü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.[9]
- Koodi ülevaatus – käsitsi tehtav test, kasutatakse vastava programmeerimiskeele enamlevinud vigade nimekirja, mida võrreldakse enda koodiga.[2]
- 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.[1][8][9]
Testimine ja programmeerimine toimuvad enamasti paralleelselt ning tihti võivad mõlemad etapid enne juurutamist tehtud olla, sest on kasutatud agiilset lähenemismeetodit.[2]
Juurutamisstrateegiate eelised ja puudused
[muuda | muuda lähteteksti]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.[3]
Enamasti eristatakse süsteemivahetuse puhul nelja strateegiat – paralleelne, otsene, moodulipõhine ja pilootstrateegia.[1][2][3] Mõnikord lisatakse liigitusse ka hübriidlahendus, kus kombineeritakse mitu süsteemivahetuse taktikat, et suurendada paindlikkust ja vähendada riske.[3]
Otsene süsteemivahetuse strateegia
[muuda | muuda lähteteksti]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.[1][2][3] 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.[3] 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.[1][2][3] Juurutamist raskendab ka see, et süsteem tuleb paigaldada korraga kõigile seadmetele.[2]
Paralleelstrateegia
[muuda | muuda lähteteksti]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.[1][2][3] Selle strateegia eelis on uue süsteemi täiustamise lihtsus, kuna tööprotsessid ei katke.[2][3] Teisalt on see kulukam, kuna ettevõttel tuleb hallata kahte süsteemi korraga.[1][2][3] 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.[2][3]
Katsetamise strateegia
[muuda | muuda lähteteksti]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.[1][2][3] Selle strateegia on uue süsteemiga seotud probleemidega tegelemine lihtsam, kuna takistuse likvideerimise ajal ei ole terve organisatsiooni tegevus häiritud.[2][3] Samas ei pruugi üks osakond olulisi (nt suure tehingumahuga) probleeme tähele panna.[3] Lisaks kaasneb selle lahenduse puhul lisakoormus arendajatele, kes peavad süsteemide vahelist andmejagamist korraldama.[2]
Etapiviisiline strateegia
[muuda | muuda lähteteksti]
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öö.[1][2][3] 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.[3] Seetõttu on suur koormus IT-osakonnal, kelle ülesanne on andmete migreerimist ja süsteemidevahelist sünkroonimist korraldada.[2]
Näide: Eesti Ehitisregister, mille uue versiooni juurutamist alustati järk-järgult 2021. aastal, kuna süsteemi tegevust ei saanud katkestada.[10][11]
Hübriidmeetod
[muuda | muuda lähteteksti]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.[3]
Vaata ka
[muuda | muuda lähteteksti]Viited
[muuda | muuda lähteteksti]- ↑ 1,00 1,01 1,02 1,03 1,04 1,05 1,06 1,07 1,08 1,09 1,10 1,11 1,12 1,13 1,14 1,15 1,16 Laudon, K. C.; Laudon, J. P. (2022). Management Information Systems: Managing the Digital Firm (inglise) (17. trükk). Harlow, Inglismaa: Pearson Education Limited. ISBN 978-1-292-40328-1.
- ↑ 2,00 2,01 2,02 2,03 2,04 2,05 2,06 2,07 2,08 2,09 2,10 2,11 2,12 2,13 2,14 2,15 2,16 2,17 2,18 2,19 2,20 2,21 2,22 2,23 2,24 2,25 2,26 2,27 2,28 Valacich, J. S.; George, J. F. (2021). Modern Systems Analysis and Design (inglise) (Üheksas trükk). Harlow, Inglismaa: Pearson Education Limited. Lk 462-493. ISBN 978-1-292-35162-9.
- ↑ 3,00 3,01 3,02 3,03 3,04 3,05 3,06 3,07 3,08 3,09 3,10 3,11 3,12 3,13 3,14 3,15 3,16 3,17 3,18 3,19 3,20 3,21 Xu, J. (2020). Essential Topics of Managing Information Systems (inglise). Singapur: World Scientific. Lk 74-93. ISBN 978-981-121-355-7.
- ↑ 4,0 4,1 4,2 Toom, L. (2019). "Juurutusprotsessiga seotud edu ja ebaedu tegurid vangiregistri näitel". Tartu Ülikool DSpace. Vaadatud 10. novembril 2024.
- ↑ 5,0 5,1 Leikums, T (2012). "Managing HUuman Factors in Implementing Electronic Document System in the Public Sector". Romanian Review of Social Sciences. 2: 21-30.
- ↑ Dinu, A.-M. (jaanuar 2016). "Project risk management - Reasons why projects fail". Quality-Access to Success Journal. 17: 208-213 – cit. via ResearchGate.
- ↑ Dwivedi, Y; Wastell, D.; Laumer, S.; Henriksen, H.; Myers, M.; Bunker, D.; Elbanna, A.; Ravishankar, M.N.; Srivastava, S. (veebruar 2014). "Research on information systems failures and successes: Status update and future directions". Information Systems Frontiers. 17: 143-157 – cit. via ReasearchGate.
- ↑ 8,0 8,1 8,2 8,3 8,4 8,5 Gelinas, U. J. Jr; Sutton, S. G.; Federowicz, J. (2008). Business Processes and Information Technology (inglise). Ohio: Thomson Learning/South-Western. Lk 239-231. ISBN 0-324-00878-3.
- ↑ 9,0 9,1 9,2 9,3 9,4 9,5 "1.4.3 Testimise tüübid". EUCIP. Vaadatud 11. november 2024.
- ↑ ERR, Hanneli Rudi | (1. november 2022). "Kevadel uuendatud ehitisregister pole siiani korralikult tööle hakanud". ERR. Vaadatud 26. detsembril 2024.
- ↑ "Uus ehitisregister jõudis kasutajate ette | Majandus- ja Kommunikatsiooniministeerium". mkm.ee. Vaadatud 26. detsembril 2024.