9 min read • Feb 22, 2023
Prihod rešitev ERP v oblaku je prinesel tudi določene spremembe v načinih vpeljave. V tem zapisu bomo poskusili ugotoviti, kateri dejavniki vplivajo na vpeljavo rešitve ERP in kako te spremembe občutijo vsi, ki se ukvarjajo z vpeljavo poslovnih rešitev.
Kaj je bilo značilno za poslovne aplikacije pred obdobjem oblaka?Microsoft je na področje poslovnih rešitev vstopil leta 2002 z nakupom rešitev Navision in Axapta. Navision, ki ga danes poznamo pod imenom Dynamics 365 Business Central, je bil že takrat namenjen predvsem malim podjetjem, medtem ko je bila rešitev Axapta, danes znana kot Dynamics 365 for Finance and Operations, namenjena predvsem večjim podjetjem. Kljub razlikam imata rešitvi kar nekaj skupnih značilnosti, ki jih pravzaprav najdemo pri večini tradicionalnih poslovnih rešitev:
Danes Microsoft na področju poslovnih aplikacij ponuja rešitvi Dynamics 365 Business Central in Dynamics 365 Finance and Supply Chain ter številne druge aplikacije Dynamics 365. Obe rešitvi sta bili zasnovani s poudarkom na oblaku, cilj razvoja pa je ponuditi celovite odgovore na izzive, s katerimi se srečujemo pri tradicionalnih poslovnih rešitvah. Ti odgovori pa pomembno vplivajo tudi na način vpeljave, na izvajalca in naročnika. In za kaj gre pri teh vplivih?
Začnimo pri področju, kjer so razlike najbolj očitne – infrastrukturi.S prihodom rešitev v oblaku nam ni več treba razmišljati o strojni in programski opremi, ki jo potrebujemo za nemoteno delovanje. Ni nam treba skrbeti za sistemske posodobitve ali posodobitve aplikacij. Ni nam treba skrbeti za načine uporabe, ki zahtevajo visoko razpoložljivost sistema, varnostne kopije in podobno. Veliko informacij si lahko zagotovimo s pomočjo telemetrije, ki nam kaže, v kakšnem stanju je naš sistem.
Infrastruktura v oblaku omogoča preprosto vzpostavitev dodatnih okolij za različne namene, npr. razvoj, preizkušanje, preizkušanje zmogljivosti itd., kar je velika prednost v primerjavi z lokalno namestitvijo (dodatna okolja v lokalni infrastrukturi so seveda povezana z dodatnimi stroški).
Dodatna okolja v infrastrukturi v oblaku so lahko povezana z dodatnimi stroški ali pa tudi ne. Na primer, pri rešitvi Dynamics 365 Business Central Microsoft v osnovni naročnini zagotavlja eno produkcijsko in tri preizkusna okolja. Če podjetje potrebuje dodatna okolja (dodatno produkcijsko ali četrto preizkusno okolje), bo to pomenilo dodatne stroške.Pomembno je poudariti, da je rešitve ERP Dynamics 365 mogoče namestiti tudi na lokalno infrastrukturo, kar seveda bistveno poveča njihovo kompleksnost. V tem primeru mora izvajalec pripraviti podroben načrt potrebne strojne, sistemske in aplikativne programske opreme, vzpostaviti pa je treba tudi mehanizme vzdrževanja in posodabljanja.
Ena od pomembnih ugotovitev ponudnikov tradicionalnih rešitev ERP je bila, da se nekatere stranke zelo težko odločijo, ali naj svojo rešitev nadgradijo na novejšo različico. Njihovi dvomi in strahovi so bili večinoma povezani z negotovostjo glede morebitnega velikega števila potrebnih prilagoditev. Bolj ko je rešitev prilagojena, več truda zahteva nadgradnja. Zato smo pogosto naleteli na dejstvo, da ni šlo več le za nadgradnjo, temveč tudi za ponovno vpeljavo. Ena glavnih značilnosti vseh storitev v oblaku je, da so stalno posodobljene z novimi zmogljivostmi - posodobitve so lahko na voljo praktično vsak mesec. Da pa bi lahko uporabniki razmeroma enostavno uvedli nove različice svoje rešitve, je bilo treba že v sami osnovi spremeniti način razvoja prilagoditev. V preteklosti je bilo mogoče spremeniti standardno osnovno kodo, ki jo je zagotovil ponudnik, pri rešitvah v oblaku pa to ni več možno. Zato je bil predstavljen nov model, pri katerem izvajalec nima več možnosti spreminjanja standardne kode, lahko pa na vnaprej določenih mestih v programski kodi (t. i. točkah razširitve) napiše svojo lastno kodo, ki jo imenujemo razširitev. Kadar proizvajalec zamenja svojo standardno kodo in ne naredi nobene prelomne spremembe (npr. odstrani določene podatkovne strukture, programske artefakte itd.), obstoječe razširitve z novo posodobitvijo delujejo enako kot pred posodobitvijo (za lažjo predstavo - pri zamenjavi prenosnega računalnika vse naprave USB delujejo enako kot prej, prelomna sprememba pa bi seveda pomenila spremembo standarda). Prilagajanje je zaradi tega postalo bolj kompleksno.Po drugi strani pa obstaja platforma za razvoj aplikacij brez pisanja kode pod imenom Power Platform, ki vključuje izdelke PowerBI, PowerApps, PowerAutomate, PowerPages in Power Virtual Agents. S temi storitvami je mogoče hitro razvijati rešitve na področjih, ki vključujejo samopostrežno poslovno inteligenco, aplikacije in avtomatizacijo.
Sodobna družina poslovnih aplikacij Dynamics 365 se posodablja praktično vsak mesec ali še pogosteje. Živimo v obdobju velikih sprememb - prihaja do razgradnje velikih monolitnih rešitev, kar se kaže v izločanju celotnih modulov, ki jih nadomeščajo nove rešitve v oblaku (nekateri nedavni primeri vključujejo Dynamics 365 Human Resources, Dynamics 365 Finance Insights, Dynamics 365 AI itd.). V takem okolju si je nemogoče predstavljati, da bi se za vpeljavo kompleksnih poslovnih rešitev posluževali togih metodologij. Kot odziv na hitro spreminjajoče se okolje je Microsoft predlagal metodološki pristop, imenovan CRP (Conference Room Pilot), ki je mešanica kaskadnega modela in agilnega pristopa. V tem primeru vpeljavo sestavljajo naslednji koraki:
Glavne prednosti takšnega pristopa so:
Pri tradicionalnih rešitvah smo bili pogosto vajeni, da smo imeli povsem proste roke pri upravljanju kode in nameščanju popravkov, pri rešitvah v oblaku pa je povsem drugače. Pri rešitvi Dynamics 365 Finance and Operations je mogoče življenjski cikel aplikacij upravljati le prek portala za sodelovanje LCS (Lifecycle services), kar v primeru rešitev v oblaku pomeni, da posodobitve v produkcijskem okolju izvaja Microsoft v okviru svojih rednih storitev. Tako naročnik kot izvajalec lahko do sistema dostopata le s pomočjo uporabniškega vmesnika. Medtem ko smo včasih lahko preprosto dostopali do podatkov, nameščali popravke in izvajali enostavne sprotne aktivnosti, je zdaj ta možnost popolnoma onemogočena. Zdaj obstaja postopek, ki natančno določa korake za namestitev novega paketa v produkcijsko okolje. Na primer, v tem postopku je predpogoj za uvedbo preizkus v okolju »peskovnika«.
V primeru Dynamics 365 Business Central Microsoft samodejno ponudi posodobitev za preizkusna in produkcijska okolja prek administratorskega središča Dynamics 365 Business Central. Do administrativnega vmesnika lahko dostopata tako naročnik kot podjetje, ki vpeljuje poslovno rešitev. Z nastavitvami posodobitev lahko načrtujeta posodobitve ob določenem času (obdobje, dan, mesec). Ker gre za rešitev SaaS (programska oprema kot storitev), teh posodobitev ni mogoče preskočiti in jih je treba namestiti. Če naročnik ali izvajalec v določenem časovnem obdobju posodobitve ne sproži ročno, jo Microsoft samodejno sproži na zadnji datum načrtovane posodobitve (približno 30 dni po izdaji glavne različice).
Bolj kot kdaj koli prej je zdaj preizkušanje z avtomatiziranimi preizkusi postalo izjemno pomembno, saj si ne moremo privoščiti izpada sistemov zaradi pomanjkljivih preizkusov.
S posodobitvami prihajajo tudi vedno nove možnosti in funkcionalnosti. Za rešitev Dynamics 365 for Finance and Supply Chain naročnik prejme 8 posodobitev na leto, sprejeti pa mora vsaj dve na leto, kar pomeni, da lahko v praksi preskoči 3 zaporedne posodobitve. Poleg tega so za prejšnje izdaje vedno na voljo kritični popravki (če trenutna izdaja nosi oznako 10.0.6, so kritični popravki na voljo za izdajo 10.0.5). Za rešitev Dynamics 365 Business Central so nujni popravki (manjše različice) redno objavljeni, prav tako pa sta naročnikom na voljo tudi dve glavni letni izdaji (večja različica). Sprotni popravki ali manjše posodobitve so predstavljeni enkrat na mesec in nosijo oznako različice v21.1. Za manjše posodobitve bo Microsoft samodejno sprožil posodobitev na datum zadnje načrtovane posodobitve (približno 20 dni po izdaji manjše posodobitve).Glavne različice so objavljene dvakrat letno, aprila in oktobra (z oznakama wave 1 in wave 2).
Tako naročniki vedno uporabljajo najnovejšo različico, ki vsebuje vse znane kritične popravke ter nove možnosti in funkcionalnosti.
Za podjetja za vpeljavo to seveda pomeni, da moramo posodobitve sprejeti večkrat letno in poskrbeti, da vse razširitve delujejo pravilno. Tudi v tem primeru pomembno vlogo igra avtomatizirano preizkušanje.Pri rešitvi v oblaku seveda ne smemo pozabiti, da govorimo o celoviti storitvi, kar pomeni, da je treba posodobiti tako sistemsko kot aplikativno programsko opremo.Obstaja razlika med namestitvijo v oblaku in namestitvijo na lokaciji - pri lokalni namestitvi ima stranka bolj proste roke (tj. mora poskrbeti zase), vendar brez rednih posodobitev ne gre.
Naročite se na naše e-novice in najnovejše vsebine boste prejeli na vaš e-naslov.
