Blogi avalehele
Kaks programmeerijat töötavad arvuti taga

Kuidas vähendada legacy-süsteemi uuendamise riski

Paljudes ettevõtetes on legacy-süsteem, mida hea meelega ei puututa. Sellest sõltuvad olulised äriprotsessid, selle loogikat tunnevad põhjalikult vaid mõned inimesed ning iga suurema muudatusega tekib küsimus: mis võib katki minna?

Sageli on legacy-süsteemi uuendamist kaalutud juba mitu korda, kuid otsus lükkub edasi. Projekti tegelikku mahtu on raske hinnata, süsteemiga on seotud palju sõltuvusi ning keegi ei taha võtta riski, et igapäevatöö saab häiritud. Lisaks tehnilistele küsimustele on veel üks oluline risk: mis saab siis, kui uus süsteem küll valmib, kuid inimesed jätkavad tööd vanaviisi?

Legacy-süsteemi uuendamine ei ole seetõttu ainult tehniline projekt. Riski aitab vähendada see, kui enne arenduse alustamist saadakse aru nii olemasolevast süsteemist kui ka sellest, kuidas inimesed seda päriselt kasutavad.

1. Ära alusta arendusest, vaid olemasoleva olukorra mõistmisest

Legacy-süsteemi puhul on üks suuremaid riske teadmatus. Dokumentatsioon võib olla puudulik või aegunud, süsteemile on aastate jooksul lisatud uusi integratsioone ja erandeid ning osa selle loonud inimestest ei pruugi enam ettevõttes töötada.

Kui tervikpilt puudub, on keeruline hinnata nii töömahtu, eelarvet kui ka seda, milline muudatus võib mõjutada mõnda teist süsteemi osa. Seetõttu tasub enne suuremate otsuste tegemist kaardistada vähemalt kolm asja:

  • kuidas süsteem tehniliselt töötab;
  • millised teised süsteemid ja protsessid sellest sõltuvad;
  • kuidas inimesed seda igapäevatöös tegelikult kasutavad.

Mida parem on lähteolukorra mõistmine, seda vähem tuleb projekti käigus teha otsuseid oletuste põhjal.

2. Vaata nii koodi kui ka inimeste tööd

Olemasolevast süsteemist tervikpildi saamiseks on vaja kahte vaadet. Esimene on tehniline.

AI-toega koodianalüüs aitab suurest koodibaasist kiiremini aru saada ning kaardistada näiteks süsteemi ülesehitust, äriloogikat, integratsioone ja sõltuvusi. Samuti aitab see leida kohti, mis vajavad spetsialisti põhjalikumat tähelepanu. AI ei otsusta, kuidas süsteem tuleks ümber ehitada, küll aga võib see aidata tehnilisel meeskonnal kiiremini jõuda õigete küsimusteni.

Näiteks aitab analüüs vaadata:

  • millised süsteemi osad sõltuvad üksteisest;
  • millised integratsioonid on ärikriitilised;
  • kus võib üks muudatus mõjutada teisi funktsioone;
  • millised kohad vajavad enne muudatuste tegemist põhjalikumat analüüsi.

Teine vaade tuleb inimestelt. Kood näitab, mida süsteem teeb, kuid mitte alati seda, kuidas ja miks inimesed seda kasutavad.

Näiteks ei pruugi koodist selguda, miks ekspordib töötaja igal hommikul andmed Excelisse, miks kontrollib klienditeenindaja sama infot kahest süsteemist või millist funktsiooni kasutatakse ainult kord aastas, kuid just siis on see kriitilise tähtsusega. Sellised teadmised on sageli inimeste peas, mitte dokumentatsioonis.

Seetõttu tasub rääkida töötajatega, kes süsteemi iga päev kasutavad, ja vaadata, kuidas töö tegelikult käib. Alles tehnilise ja kasutaja vaate ühendamisel saab hakata otsustama, mida tasub säilitada, mida muuta ja mida ei ole uude süsteemi vaja kaasa võtta.

3. Ära ehita uut süsteemi vana koopia järgi

Üks levinud risk on see, et uuendamise käigus tehakse vana süsteem lihtsalt uuema tehnoloogia peale ümber. See võib tunduda turvalise valikuna, kuid nii võivad uude lahendusse kaasa tulla ka aastatega tekkinud ebavajalikud sammud, erandid ja piirangud.

Samal ajal võib juhtuda vastupidine: uus süsteem tehakse juhtkonna või projektitiimi ettekujutuse järgi, kuid kasutajate tegelikud tööprotsessid jäävad tähelepanuta. Mõlemal juhul võib tulemus olla tehniliselt korrektne lahendus, mille kõrval elavad edasi samad Exceli tabelid, käsitsi kontrollid ja vanad töövõtted.

Enne uue lahenduse kavandamist tasub seetõttu koos kasutajatega läbi mõelda, millised tööprotsessid toimivad juba hästi, millised probleemid tulenevad süsteemist ja millised hoopis töökorraldusest. Samuti on oluline eristada päriselt vajalikke erandeid neist, mis on aastatega lihtsalt harjumuseks saanud.

Uue süsteemi eesmärk ei peaks olema vana võimalikult täpselt kopeerida, vaid toetada paremini seda tööd, mida ettevõttel päriselt vaja on.

4. Too äri ja IT otsuste tegemiseks ühe laua taha

Legacy-süsteemi uuendamisel näevad eri osapooled sageli erinevaid probleeme. IT näeb tehnilist võlga, integratsioone, turvariske ja hooldatavust, äripool aga aeglaseid protsesse, käsitööd ja funktsioone, millest töötajad puudust tunnevad.

Mõlemad vaated on olulised ning risk kasvab siis, kui tehnilised ja ärilised otsused tehakse teineteisest eraldi.

Projekti alguses tasub äri- ja IT-poolega kokku leppida, milliseid probleeme uuendusega lahendatakse, millised protsessid on kõige kriitilisemad ning mille järgi hiljem hinnatakse, kas uus lahendus päriselt töötab. Sama oluline on kokku leppida, kes teeb projekti jooksul olulised otsused siis, kui tehniline ja äriline vaade omavahel põrkuvad.

Mida selgemad on need kokkulepped alguses, seda vähem tekib arenduse käigus olukordi, kus tehniliselt mõistlik lahendus ei vasta ärivajadusele või vastupidi.

5. Mõõda mitte ainult seda, kas süsteem valmis

Uue süsteemi käivitamine ei tähenda veel, et uuendus õnnestus. Mõni kuu pärast kasutuselevõttu tasub hinnata, kas uus süsteem on päriselt vähendanud Exceli tabelite kasutamist, dubleerivat andmesisestust ja käsitsi kontrollimist ning kas inimesed kasutavad uut töövoogu nii, nagu kavandatud.

Need näitajad annavad projekti tegelikust tulemusest sageli rohkem infot kui see, kas arendus valmis algselt planeeritud kuupäevaks. Legacy-süsteemi uuendamise eesmärk ei ole lihtsalt uus tehnoloogia, vaid süsteem, mis toetab ettevõtte tööd paremini kui vana.

Esimene samm ei pea olema suur arendusprojekt

Legacy-süsteemi uuendamise otsustamiseks ei pea kohe teadma kogu projekti mahtu ega lõplikku eelarvet. Esimene eesmärk võib olla hoopis teadmatuse vähendamine.

Trinidad Wisemanis alustame legacy-süsteemi uuendamise protsessi tasuta kolmetunnise töötoaga, kuhu kaasame juhtkonna ja võtmekasutajad. Koos vaatame üle olemasoleva olukorra, peamised riskid ja küsimused, millele oleks enne suuremate otsuste tegemist vaja vastata.

Seejärel saab edasi liikuda viiepäevase kiirpildiga, mille käigus kasutame AI-d süsteemi koodi ja tehnilise ülesehituse analüüsimiseks ning räägime inimestega, kes süsteemi iga päev kasutavad ja tunnevad selle ärilist konteksti.

Viie päeva lõpuks on olemas esimene tervikpilt:

  • mida süsteem praegu teeb;
  • millised on olulisemad tehnilised ja ärilised riskid;
  • millised küsimused vajavad veel uurimist;
  • millest oleks mõistlik uuendamist alustada.

Kiirpildi tulemused ja selle käigus kogutud teadmine jäävad sulle sõltumata sellest, kas otsustad meiega edasi liikuda või mitte.

Loe lähemalt legacy süsteemi uuendamisest.

Selgus enne suurt investeeringut

Kui kaalud legacy-süsteemi uuendamist, kuid pole veel selge, millest alustada, võta meiega ühendust. Vaatame koos üle sinu tänase olukorra, peamised riskid ja võimalikud järgmised sammud.

Mikk Maiste

Mikk Maiste

Erilahendusega tarkvaraarenduse konsultant

Kirjuta meile