Kdaj se splača avtomatizacija in kdaj je potreben nov sistem

Kdaj se vprašanje sploh pojavi#

Podjetja se pogosto znajdejo pred vprašanjem, ali obstoječi proces le pospešiti z avtomatizacijo ali zgraditi nov informacijski sistem. Vprašanje se navadno pojavi, ko ročno delo postane preobsežno, ko podatki živijo v več ločenih orodjih ali ko se napake pri prenosu informacij ponavljajo. Odločitev vpliva na obseg dela, trajanje projekta in na to, kako se bo organizacija v prihodnje prilagajala spremembam. Napačna izbira pomeni izgubljen čas in podvojeno delo, zato je smiselno vprašanje razčleniti, preden se izbere pot naprej.

Pri Epixu se s tem vprašanjem srečujemo pri projektih digitalizacije in modernizacije obstoječih sistemov ter pri avtomatizaciji poslovnih procesov, delovnih tokov, poročanja in obvestil. Vsak primer je drugačen, saj je odvisno od tega, koliko obstoječi sistem sploh omogoča nadgradnjo, koliko podatkov je treba povezati in kako kritičen je proces za vsakodnevno poslovanje. Zato pred vsako odločitvijo pregledamo obstoječo izvorno kodo, arhitekturo, infrastrukturo in podatke, če sistem že obstaja.

Članek pojasnjuje, kdaj avtomatizacija zadostuje, kdaj je potreben nov sistem in kako se odločitev prenese v konkreten projektni načrt. Ne gre za splošna priporočila, temveč za vprašanja, ki si jih mora naročnik zastaviti, preden se lotimo tehnične izvedbe.

Kaj pomeni avtomatizacija poslovnih procesov#

Avtomatizacija poslovnih procesov pomeni, da se ponavljajoča se opravila prenesejo iz ročnega izvajanja na sistem, ki jih izvede samodejno po vnaprej določenih pravilih. Sem spadajo urejanje delovnih tokov, samodejno pošiljanje obvestil, generiranje poročil in prenos podatkov med sistemi prek API-integracij. Cilj ni zamenjati celoten informacijski sistem, temveč odstraniti korake, ki jih danes izvajajo zaposleni ročno, čeprav bi jih lahko izvajal sistem sam.

Avtomatizacija se navadno nadgrajuje nad obstoječimi sistemi, ne glede na to, ali gre za CRM, ERP ali interno razvito aplikacijo. Pri tem je pomembno, da so podatki, ki jih avtomatizacija uporablja, dostopni prek API-ja ali druge oblike sistemske integracije. Če podatki obstajajo, a so razpršeni po več orodjih, je pogosto smiselno najprej vzpostaviti povezavo med njimi in šele nato graditi avtomatizirane korake nad to povezavo.

Pri Epixu avtomatizacijo obravnavamo kot projektni sklop, ki ga je mogoče prevzeti samostojno ali kot del širšega projekta digitalizacije. To pomeni, da naročniku ni treba zamenjati celotnega sistema, če je težava omejena na posamezen proces, kot je poročanje, obveščanje ali prenos podatkov med oddelki.

Kdaj avtomatizacija prinaša rezultat#

Avtomatizacija se splača takrat, ko je proces jasno definiran, ponavljajoč in ne zahteva stalnega ročnega odločanja. Če zaposleni vsak dan izvajajo enak niz korakov, na primer prenos podatkov iz enega sistema v drugega, pripravo poročila ali pošiljanje obvestil ob določenem dogodku, je to primeren kandidat za avtomatizacijo. Proces mora biti pred avtomatizacijo dovolj stabilen, da ga je mogoče zapisati kot pravilo, sicer bo avtomatizacija zahtevala pogosto spreminjanje.

Drugi pogoj je, da obstoječi sistem ali sistemi omogočajo dostop do podatkov prek API-ja ali druge oblike integracije. Če podatki niso dostopni sistemsko, temveč samo prek uporabniškega vmesnika, je avtomatizacija otežena ali nezanesljiva. V takih primerih pri Epixu najprej preverimo, ali je mogoče vzpostaviti sistemsko integracijo, preden predlagamo avtomatizacijo kot rešitev.

Avtomatizacija je smiselna tudi takrat, ko gre za povezovanje več že delujočih sistemov, na primer med CRM, ERP in internimi orodji za poročanje. V takem primeru avtomatizacija ne nadomesti nobenega od obstoječih sistemov, temveč zapolni vrzel med njimi in odpravi ročno prepisovanje ali podvajanje podatkov.

Znaki, da obstoječi sistem ne zadostuje več#

Nasprotno pa se pogosto izkaže, da avtomatizacija ne reši osnovne težave, ker ta ne izvira iz procesa, temveč iz sistema samega. Če je obstoječa aplikacija zgrajena na arhitekturi, ki ne podpira dodatnih integracij, če je podatkovna struktura neurejena ali če sistem ne zdrži obsega podatkov, ki jih podjetje danes obdeluje, avtomatizacija le prekrije težavo, ne odpravi pa je.

Znak, da je potreben nov sistem, je tudi takrat, ko se zahteve poslovanja spremenijo do te mere, da jih obstoječa rešitev ne more podpreti brez obsežnega poseganja v osnovno zgradbo. Sem spadajo primeri, ko podjetje širi delovanje na več lokacij, ko potrebuje podporo za več uporabniških vlog ali ko obstoječi sistem ne omogoča modularne nadgradnje brez tveganja za stabilnost celote.

V takih primerih pri Epixu predlagamo modernizacijo obstoječega sistema ali izgradnjo novega, odvisno od tega, kaj pokaže pregled izvorne kode, arhitekture in podatkov. Modernizacija je pogosto smiselna, kadar je osnovna zasnova sistema še vedno uporabna, nov sistem pa takrat, ko bi bilo nadaljnje nadgrajevanje dražje in bolj tvegano od nove izgradnje.

Kako prepoznati mejo med avtomatizacijo in novim sistemom#

Meja med avtomatizacijo in novim sistemom ni vedno očitna, zato je pred odločitvijo smiselno odgovoriti na nekaj konkretnih vprašanj o obstoječem stanju. Vprašanja se nanašajo na to, kje nastaja težava, kako pogosto se pojavlja in ali jo je mogoče odpraviti brez poseganja v osnovno arhitekturo sistema. Odgovori pokažejo, ali gre za omejitev procesa ali za omejitev sistema.

Pri Epixu pri tej presoji upoštevamo naslednje točke, ki jih preverimo skupaj z naročnikom pred pripravo projektnega predloga.

Če večina odgovorov kaže, da je težava omejena na posamezen proces in da sistem podatke že hrani na dostopen način, je avtomatizacija verjetno zadostna rešitev. Če pa odgovori kažejo, da je omejitev v sami zasnovi sistema, na primer v podatkovni strukturi ali v arhitekturi, ki ne prenese dodatnih povezav, je smiselneje načrtovati nov sistem ali obsežnejšo modernizacijo.

• ali je proces, ki povzroča težavo, jasno opredeljen in ponavljajoč
• ali obstoječi sistem omogoča dostop do podatkov prek API-ja ali druge integracije
• ali je težava omejena na en proces ali se pojavlja na več mestih hkrati
• ali obstoječa arhitektura zdrži dodatne integracije brez tveganja za stabilnost
• ali je podatkovna struktura urejena in dosledna
• ali gre za enkratno omejitev ali za ponavljajoč se vzorec, ki nakazuje širšo omejitev sistema

Pregled obstoječega sistema pred odločitvijo#

Preden pri Epixu predlagamo eno ali drugo pot, izvedemo pregled obstoječega sistema, če ta že obstaja. Pregled zajema izvorno kodo, arhitekturo, infrastrukturo in podatke, na katerih sistem trenutno deluje. Namen pregleda ni oceniti kakovost dela prejšnjega izvajalca, temveč ugotoviti, kaj je mogoče ohraniti, kaj je treba prilagoditi in kaj predstavlja tveganje za nadaljnji razvoj.

Pregled je pomemben tudi zato, ker naročnik pogosto nima popolnega vpogleda v to, kako je sistem tehnično zgrajen, še posebej če ga je razvijal zunanji izvajalec, ki ni več vključen v projekt. V takih primerih prevzamemo obstoječ ali nedokončan sistem po opravljenem pregledu in šele nato pripravimo predlog za nadaljevanje, ki je lahko avtomatizacija, modernizacija ali izgradnja novega sistema. Pregled običajno vključuje naslednje korake.

Na podlagi pregleda pripravimo priporočilo, ki je vedno vezano na konkretno stanje sistema, ne na splošno oceno. Priporočilo lahko vključuje avtomatizacijo posameznih procesov, postopno modernizacijo delov sistema ali izgradnjo novega sistema, če je to dolgoročno bolj vzdržno.

• pregled izvorne kode in dokumentacije, če obstaja
• oceno arhitekture in njene sposobnosti za nadaljnjo nadgradnjo
• pregled infrastrukture, na kateri sistem trenutno teče
• analizo podatkov, njihove strukture in kakovosti
• preverjanje obstoječih integracij in dostopov
• oceno tveganj pri nadaljnjem razvoju brez posega v osnovno zgradbo

Kako pri Epixu pristopimo k odločitvi in izvedbi#

Pri Epixu projekt lahko prevzamemo v celoti ali kot posamezen projektni sklop, kar pomeni, da avtomatizacija ali modernizacija ni nujno del večjega projekta. Pri večjih projektih določimo projektnega vodjo, odgovornosti ekip, roke in način komunikacije ter poročanja, kar naročniku omogoča vpogled v napredek skozi celoten proces izvedbe, ne le ob zaključku.

Razvoj poteka v ločenih okoljih za razvoj, testiranje in produkcijo, pri čemer se v testnem okolju ne uporabljajo pravi osebni podatki. Vsaka sprememba gre skozi pregled in testiranje, preden se objavi v produkcijsko okolje. Ta pristop velja tako za projekte avtomatizacije kot za izgradnjo novih sistemov, saj zmanjšuje tveganje, da bi sprememba vplivala na delujoče procese pri naročniku.

Izvorna koda in podatki so v vseh primerih last naročnika. Dokumentacija, dostopi in gesla so del primopredaje, kar pomeni, da naročnik po zaključku projekta ni odvisen od enega izvajalca za nadaljnje odločitve o sistemu. To je pomembno tako pri avtomatizaciji kot pri izgradnji novega sistema, saj omogoča, da naročnik kasneje izbere drugačen pristop, če se razmere spremenijo.

Prevzem, SLA in nadaljnji razvoj po uvedbi#

Po uvedbi rešitve, ne glede na to, ali gre za avtomatizacijo ali nov sistem, lahko pri Epixu prevzamemo nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj. To je pomembno predvsem takrat, ko avtomatizirani proces ali nov sistem postane del vsakodnevnega poslovanja in izpad ali napaka neposredno vpliva na delo zaposlenih ali strank.

Podpora po uvedbi je razdeljena na razrede glede na resnost napake, kar naročniku omogoča jasno pričakovanje glede odzivnega časa.

Razdelitev na razrede je enaka za avtomatizirane procese in za nove sisteme, saj gre v obeh primerih za del produkcijskega okolja, ki zahteva jasno določen način odzivanja. Naročniku to omogoča, da vnaprej ve, kaj lahko pričakuje ob različnih vrstah napak, ne glede na to, kateri del rešitve je prizadet.

• razred 1, izpad: sistem ali ključni del ne deluje, odzivni čas je dogovorjen v pogodbi o podpori
• razred 2, motnja: sistem deluje, posamezna funkcija ne, odzivni čas je dogovorjen v pogodbi o podpori
• razred 3, napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• razred 4, zahteva: sprememba ali nadgradnja, obseg ocenimo in termin uskladimo skupaj z naročnikom

Tveganja pri napačni odločitvi#

Če se podjetje odloči za avtomatizacijo tam, kjer bi bil potreben nov sistem, se težava običajno ne odpravi, temveč le premakne na kasnejši čas. Avtomatizacija, zgrajena nad nestabilno arhitekturo, postane dodaten sloj, ki ga je treba vzdrževati, ne da bi rešila osnovno omejitev sistema. To pomeni, da bo podjetje prej ali slej znova stalo pred isto odločitvijo, tokrat z dodatnim slojem, ki ga je treba upoštevati pri nadaljnjem razvoju.

Nasprotno pa gradnja novega sistema tam, kjer bi zadostovala avtomatizacija posameznega procesa, pomeni nepotrebno poseganje v del sistema, ki že deluje. To podaljša čas, potreben za uvedbo spremembe, in poveča obseg dela, ki bi ga bilo mogoče omejiti na en projektni sklop. Zato je pregled obstoječega stanja pred odločitvijo ključen korak, ne glede na to, na katero stran na koncu obrne izbira.

Pri Epixu zato pred vsakim predlogom preverimo, ali je omejitev v procesu ali v sistemu, in šele na podlagi tega predlagamo projektni obseg, ki ustreza dejanski težavi.