Znaki, da je informacijski sistem zrel za modernizacijo

Kdaj je informacijski sistem zrel za modernizacijo?#

Informacijski sistem je zrel za modernizacijo takrat, ko ovira delo bolj, kot ga podpira – ko se preprosta opravila rešujejo z obvodi, ročnimi vnosi in ljudmi, ki vedo, 'kako se stvar naredi', ker tega ne zna povedati noben zaslon. Modernizacija zastarelega sistema (ang. legacy system modernisation) ni vprašanje starosti programske opreme, temveč vprašanje, ali sistem še sledi obsegu, številu uporabnikov in zahtevam po povezljivosti, ki jih ima podjetje danes. Kadar vodstvo vsak mesec znova sliši, da je neko poročilo 'spet treba sestaviti ročno', je to jasen signal, da je čas za spremembo.

Znaki so redko tehnične narave same po sebi. Pogosteje gre za organizacijsko trenje: oddelki si podatke pošiljajo po e-pošti namesto prek skupnega sistema, poročila nastajajo v preglednicah, ki jih nihče ne preveri proti izvornim podatkom, in vsaka nova zahteva – nov oddelek, nova lokacija, nov predpis – zahteva mesece prilagajanja namesto dni. Ko se to ponavlja na več področjih hkrati, modernizacija ni več vprašanje 'če', temveč 'kako in v kakšnem vrstnem redu'.

Za odločevalca je ključno vprašanje, kateri del sistema najbolj omejuje rast podjetja: ali je to zastarela arhitektura, pomanjkanje povezav z drugimi sistemi ali preprosto dejstvo, da nihče več ne pozna izvorne kode sistema. Odgovor določa, ali gre za prenovo, nadgradnjo ali popoln prevzem obstoječega sistema s strani novega izvajalca.

Prvi znaki, da sistem zaostaja za poslovanjem#

Najbolj očiten znak je podvajanje dela: isti podatek se vnese v enega od obstoječih sistemov, nato pa še ročno prepiše v preglednico, drug sistem ali poročilo za vodstvo. Kadar zaposleni preverjajo pravilnost podatkov med dvema viroma namesto da bi zaupali enemu, sistem ne opravlja svoje osnovne naloge – zanesljivega vira resnice za podjetje.

Drugi znak je odvisnost od posameznikov. Če le ena oseba v podjetju zna sistem administrirati, popraviti napako ali razložiti, zakaj se neko poročilo izračuna tako, kot se, je podjetje izpostavljeno tveganju, ki nima zveze s programsko opremo, temveč s kadrovsko odvisnostjo. Odhod te osebe lahko ustavi del poslovanja, dokler se znanje znova ne sestavi od začetka.

• Ročno prepisovanje podatkov med sistemi, ki bi morali biti povezani
• Poročila, ki jih je treba vsak mesec znova sestaviti v preglednicah
• Nezmožnost dodajanja novega uporabnika, oddelka ali lokacije brez posega razvijalca
• Odvisnost od ene osebe, ki edina pozna delovanje sistema
• Pogoste zaustavitve ali počasno delovanje ob večji obremenitvi
• Nezmožnost sledenja, kdo je podatek spremenil in kdaj

Zakaj nepovezani sistemi najbolj dražijo vsakodnevno delo#

Podjetja z več kot milijon evrov prihodkov običajno uporabljajo več sistemov hkrati: enega za poslovanje in finance, drugega za odnose s strankami, tretjega za proizvodnjo ali zaloge, poleg tega pa še dokumentni sistem in orodja za poročanje. Podjetja pogosto uporabljajo enega od uveljavljenih sistemov, kot so Pantheon, Business Central ali SAP, ob njih pa še ločen CRM in sistem za upravljanje dokumentov. Kadar ti sistemi niso povezani prek API-jev, nastane vmesni prostor, ki ga zapolnijo ljudje – z izvozi, uvozi in ročnim usklajevanjem.

Prav ta vmesni prostor je eden najzanesljivejših znakov, da je sistem zrel za modernizacijo. Vsaka ročna povezava je priložnost za napako, vsaka napaka pa se v poslovnih poročilih pojavi z zamikom, ko jo je težje najti. Pri proizvodnih in trgovskih podjetjih to pomeni netočne zaloge, podvojena naročila ali zamujena plačila – ne zato ker bi bil posamezni sistem slab, temveč ker med njimi ni povezave.

Vprašanje, ki si ga mora zastaviti vodstvo, ni, kateri sistem zamenjati, temveč koliko podatkov trenutno potuje med sistemi ročno in kaj bi se zgodilo, če bi ta pot postala avtomatizirana. Odgovor pogosto pokaže, da modernizacija ne pomeni zamenjave vsega, temveč povezovanje obstoječega prek API-jev in ciljno avtomatizacijo najbolj ponavljajočih se opravil.

Kako zastarel sistem ogroža varnost podatkov?#

Zastarel sistem najpogosteje ogrozi varnost podatkov tam, kjer ni več jasno, kdo ima dostop do česa, kdo je podatek nazadnje spremenil in ali so varnostne posodobitve sploh še na voljo. Starejši sistemi so bili pogosto grajeni v času, ko zahteve po sledljivosti, ločevanju okolij in nadzoru dostopov niso bile tako stroge, kot so danes v reguliranih panogah in javnem sektorju.

Za podjetja, ki hranijo osebne, finančne ali zdravstvene podatke, to pomeni neposredno izpostavljenost zahtevam, kot jih postavljata GDPR ali NIS2 – ne glede na to, ali je sistem star pet ali petnajst let. Vprašanje ni le, ali je sistem še 'deloval do zdaj', temveč ali izpolnjuje trenutne zahteve glede revizijske sledi, ločevanja pravic in zaščite podatkov.

• Ali sistem še prejema varnostne posodobitve proizvajalca
• Kdo ima administratorski dostop in ali je ta dostop dokumentiran
• Ali obstaja ločeno testno okolje ali se spremembe preizkušajo neposredno v produkciji
• Ali se v testnem okolju uporabljajo pravi osebni podatki
• Ali sistem beleži, kdo je podatek spremenil in kdaj
• Kako hitro se sistem povrne po izpadu ali napaki

Kaj zastarel sistem pomeni za zaposlene, ki z njim delajo vsak dan#

Zaposleni so pogosto prvi, ki opazijo, da sistem ne sledi več obsegu dela – še preden to opazi vodstvo. Počasno odzivanje, nerazumljivi vmesniki in opravila, ki zahtevajo več korakov, kot bi jih morala, se kopičijo v izgubljeni čas, ki ga nihče uradno ne meri, a se pozna v obremenjenosti ljudi in v številu obvodov, ki jih vpeljejo sami.

Modernizacija informacijskega sistema zato ni le tehnično vprašanje, temveč vpliva neposredno na to, kako zaposleni preživijo delovni dan. Kadar ljudje razvijejo lastne preglednice, beležke in neuradne postopke, da nadomestijo pomanjkljivosti sistema, to pomeni, da je znanje o dejanskem delovanju procesov razpršeno med posameznike in ne zapisano v sistemu, kar oteži usposabljanje novih sodelavcev.

Pri načrtovanju modernizacije je zato smiselno vključiti ljudi, ki sistem uporabljajo vsak dan, ne le vodje oddelkov. Njihovi obvodi pogosto razkrijejo, katere funkcionalnosti novi sistem nujno potrebuje, da ne bi ponovil istih omejitev v novi obliki.

Je bolje zastarel sistem zamenjati ali ga nadgraditi?#

Odgovor ni enoznačen: pogosto se izkaže, da je smiselneje obstoječi sistem prevzeti in nadgraditi po delih, kot ga v celoti zamenjati naenkrat, saj popolna zamenjava hkrati pomeni tudi popolno prekinitev znanja, ki je v starem sistemu nabrano.

Odločitev je odvisna od stanja izvorne kode, arhitekture in podatkov obstoječega sistema. Kadar je mogoče priti do izvorne kode in dokumentacije, se pogosto izkaže, da je del sistema še vedno uporaben in da je modernizacija smiselna po projektnih sklopih – najprej tisti del, ki najbolj ovira poslovanje, nato ostalo. Kadar izvorna koda ni dostopna ali dokumentacije ni, je pregled toliko obsežnejši, preden se lahko določi obseg dela.

Pri odločitvi med zamenjavo in nadgradnjo je treba upoštevati tudi, kako kritičen je sistem za vsakodnevno poslovanje. Sistem, ki ga uporablja en oddelek, dopušča počasnejši prehod kot sistem, ki je del vsakodnevnega poslovanja celotnega podjetja – v tem primeru je prehod brez prekinitve delovanja pogosto pomembnejši od hitrosti same zamenjave.

Kako izbrati izvajalca za modernizacijo informacijskega sistema#

Izbira izvajalca za modernizacijo zastarelega sistema je odločitev, ki presega ceno ponudbe, saj gre za dostop do podatkov, arhitekture in pogosto kritičnih poslovnih procesov podjetja. Izvajalec mora znati najprej analizirati obstoječe stanje, šele nato predlagati rešitev – obratni vrstni red je znak, da ponudba ni utemeljena na dejanskem stanju sistema.

Posebej pri večjih projektih, ki zadevajo več oddelkov, je pomembno, da izvajalec vnaprej določi projektnega vodjo ter jasno razmeji odgovornosti med ekipami, roke in način poročanja vodstvu. To ni formalnost, temveč zaščita naročnika pred situacijo, ko nihče ne ve, kdo je za kaj odgovoren, ko se projekt zaplete.

Enako pomembno je vprašanje lastništva: izvorna koda in podatki morajo ostati last naročnika, dokumentacija, dostopi in gesla pa del formalne primopredaje ob zaključku projekta ali posameznega sklopa. Brez tega je podjetje po koncu sodelovanja z izvajalcem lahko v enakem položaju kot pred modernizacijo – odvisno od zunanjega partnerja za vsako spremembo.

• Ali izvajalec pred ponudbo pregleda izvorno kodo, arhitekturo in podatke obstoječega sistema
• Ali lahko prevzame projekt v celoti ali po posameznih sklopih
• Kako določi projektnega vodjo, odgovornosti ekip in način poročanja
• Ali ločuje razvojno, testno in produkcijsko okolje
• Kako poteka testiranje pred objavo sprememb v produkcijo
• Kaj je del primopredaje – izvorna koda, dostopi, gesla, dokumentacija
• Kakšno podporo ponuja po uvedbi in kako razvršča prednostne napake

Kaj določa obseg in potek projekta modernizacije#

Obsega in trajanja projekta modernizacije ni mogoče oceniti brez analize konkretnega sistema, saj je odvisen od več dejavnikov hkrati – od tega, koliko obstoječih sistemov je treba povezati, do tega, kakšne so zahteve glede varnosti in skladnosti. Cena se zato določi šele po pregledu zahtev, pred tem pa je smiselna krajša analiza, ki obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno.

Količina in stanje podatkov, ki jih je treba prenesti v nov ali nadgrajen sistem, pogosto najbolj vpliva na trajanje projekta, saj podatki iz starih sistemov redko ustrezajo strukturi, ki jo zahteva nova rešitev. Pregled in čiščenje podatkov pred selitvijo zato pogosto traja dlje kot sam razvoj nove funkcionalnosti.

Za javni sektor in regulirane panoge se obsegu doda še zahteva po skladnosti s predpisi, kot sta GDPR ali ZJN-3 pri javnem naročanju, kar vpliva na dokumentacijo, revizijsko sled in postopek izbire izvajalca. Vse to je treba določiti pred začetkom del, ne med samim projektom, saj naknadno dodajanje zahtev podaljša vsak naslednji sklop.

• Obseg funkcionalnosti in število uporabniških vlog
• Koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• Ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• Količina in stanje podatkov, ki jih je treba prenesti
• Zahteve glede varnosti, revizijske sledi in skladnosti
• Ali je potreben mobilni del in za katere platforme
• Raven podpore po uvedbi in dogovorjeni odzivni časi

Kako modernizacija poteka, ne da bi ustavila tekoče poslovanje?#

Prehod na modernizirani sistem poteka brez prekinitve poslovanja takrat, ko se spremembe najprej preizkusijo v ločenem testnem okolju in šele nato postopoma uvedejo v produkcijo, namesto da bi se stari sistem ugasnil in novi vklopil v enem koraku.

Razvojno, testno in produkcijsko okolje morajo biti ločena, v testnem okolju pa se ne uporabljajo pravi osebni podatki, kar ščiti podatke zaposlenih in strank med samim testiranjem. Spremembe gredo skozi pregled in testiranje – ročno in avtomatizirano, po potrebi tudi s strani neodvisne ekipe za zagotavljanje kakovosti, ločene od razvojne ekipe – šele nato se objavijo v produkcijskem okolju.

Pri sistemih, ki so kritični za vsakodnevno poslovanje, se prehod pogosto razdeli na sklope: najprej se modernizira del, ki najmanj vpliva na druge procese, šele nato osrednji del sistema. Tak pristop podaljša celoten projekt, a zmanjša tveganje, da bi modernizacija sama povzročila izpad, ki bi bil dražji od težav, zaradi katerih je bila sprožena.

Kaj sledi po uvedbi posodobljenega sistema#

Po uvedbi moderniziranega sistema se odgovornost ne konča z zagonom – sledi obdobje, v katerem je treba spremljati delovanje, odpravljati napake in zagotoviti, da sistem ostane varnostno posodobljen. Podjetja, ki to spregledajo, se pogosto čez nekaj let znajdejo v enakem položaju kot pred modernizacijo, le z novejšo programsko opremo.

Podpora po uvedbi se običajno razvrsti po prednosti: izpad celotnega sistema ali ključnega dela zahteva takojšnjo obravnavo, motnja posamezne funkcije ima nižjo prednost, manjše napake pa se uvrstijo v naslednjo redno objavo, zahteve za nove funkcionalnosti pa se ocenijo in uskladijo ločeno. Taka razvrstitev naročniku omogoča, da ve, kaj lahko pričakuje v posameznem primeru, ne da bi za vsako napako na novo pogajal odzivni čas.

Dogovor o podpori je smiselno skleniti še pred zaključkom projekta modernizacije, ne šele, ko se pojavi prva napaka v produkciji. Tako ima naročnik jasno sliko, kdo prevzame nadzor delovanja, tehnične in varnostne posodobitve ter nadaljnji razvoj sistema, in se izogne obdobju brez podpore tik po zagonu.