ERP v oblaku za proizvodna podjetja: kaj urediti pred selitvijo

Kaj je ERP v oblaku in zakaj proizvodna podjetja prehajajo nanj?#

ERP v oblaku je poslovni informacijski sistem, ki teče na strežnikih zunaj podjetja in je dostopen prek spleta, namesto da bi ga podjetje gostilo na lastnih strežnikih v proizvodnem obratu. Za proizvodno podjetje to pomeni, da lahko vodja proizvodnje, nabave in financ dostopajo do istih podatkov o naročilih, zalogah in delovnih nalogih ne glede na to, ali so v pisarni, na proizvodni liniji ali na poti med lokacijami. Prehod na tak program v oblaku za proizvodna podjetja je zato pogosto posledica rasti, širitve na več lokacij ali potrebe po poenotenju razpršenih evidenc.

Razlogi za prehod so pri proizvodnih podjetjih praviloma praktični, ne modni. Lokalno nameščen ERP pogosto teži k staranju: strojna oprema potrebuje zamenjave, varnostne popravke je treba nameščati ročno, dostop od zunaj pa zahteva dodatne VPN povezave, ki jih je treba vzdrževati ločeno. Ko podjetje odpre novo proizvodno linijo, skladišče ali poslovalnico, se ista vprašanja ponovijo znova. Program v oblaku za proizvodna podjetja te korake poenostavi, ker infrastrukturo upravlja ponudnik oblačnih storitev, podjetje pa se osredotoči na nastavitve, ki odražajo njegove dejanske procese.

Za proizvodnjo je posebej pomembno, da so podatki o zalogah, delovnih nalogih in kapacitetah vidni v realnem času ne glede na izmeno ali lokacijo. Ko vodja proizvodnje vidi zastoj na eni liniji, lahko nabava takoj preveri, ali je vzrok v manjkajočem materialu, finance pa, ali zastoj vpliva na načrtovane dobave. Brez skupnega sistema te informacije krožijo po e-pošti, preglednicah in telefonskih klicih, kar podaljšuje odzivni čas in povečuje tveganje za napake pri usklajevanju med oddelki.

Odločitev o prehodu zato ni le tehnično vprašanje za IT oddelek, temveč zadeva odgovornost vodstva za neprekinjeno delovanje proizvodnje. Izpad ERP sistema med aktivno izmeno lahko ustavi naročanje materiala, izdajanje delovnih nalogov in izdajo dokumentov za odpremo. Zato je treba že pred izbiro izvajalca jasno določiti, kdo v podjetju odloča o obsegu projekta, kdo prevzema tveganje med selitvijo in kako se preverja, da nov sistem dejansko pokriva vse procese, ki jih je pokrival prejšnji.

Kdaj se proizvodnemu podjetju splača preseliti ERP v oblak?#

Preselitev se najbolj splača takrat, ko obstoječi sistem ne sledi več rasti podjetja – ko se širi na nove lokacije, ko se povečuje število uporabnikov ali ko vzdrževanje lastne strojne opreme postane dražje od najema oblačne infrastrukture. Pravi trenutek ni vezan na koledarsko leto, temveč na to, ali trenutni sistem še zanesljivo podpira ključne procese.

Znaki, da je čas za premislek, so običajno vidni že pred tem, ko sistem dejansko odpove. Poročanje za vodstvo traja dlje, ker je treba podatke ročno združevati iz več evidenc. Nove zaposlene je težko uvesti, ker uporabniški vmesnik ne sledi več načinu dela v proizvodnji. Posamezne poslovalnice ali obrati si med seboj izmenjujejo podatke prek izvozov v preglednice namesto prek skupnega sistema. Vsak od teh znakov posamično še ni razlog za selitev, skupaj pa kažejo, da obstoječi sistem ne sledi več obsegu poslovanja.

Trenutek za selitev pogosto sovpada s poslovnim dogodkom, ne z iztekom pogodbe s ponudnikom. Odpiranje nove proizvodne lokacije, prevzem drugega podjetja ali vstop na nov trg so priložnosti, ko je smiselno podatke in procese od začetka postaviti v oblak, namesto da bi novo enoto naknadno vključevali v star sistem. Enako velja, kadar podjetje pripravlja revizijo poslovanja ali vstopa v javne razpise, kjer naročniki pričakujejo sledljivost podatkov in jasno dokumentirane procese.

Selitev je smiselno časovno umestiti zunaj konice proizvodnje, da morebitne prilagoditve med testiranjem ne vplivajo na dobavne roke do kupcev. Priporočljivo je, da se najprej preseli en proizvodni obrat ali en sklop procesov, nato pa se na podlagi izkušenj širi na preostale lokacije. Tak postopen pristop zmanjša tveganje, da bi se napaka v nastavitvah razširila na celotno podjetje, hkrati pa vodstvu da priložnost, da preveri, ali sistem dejansko podpira njihove procese, preden se vanj preseli vsa proizvodnja.

Katere podatke in procese je treba pred selitvijo urediti#

Pred selitvijo je treba najprej popisati, kateri podatki v podjetju sploh obstajajo, kje so shranjeni in kdo jih vnaša in posodablja. ERP v oblaku je mogoče smiselno nastaviti šele, ko je jasno, kateri procesi so dokumentirani v obstoječem sistemu in kateri potekajo po ustnem dogovoru med zaposlenimi ali v ločenih preglednicah, ki jih uradni sistem ne vidi.

Posebna pozornost gre šifrantom izdelkov, kosovnicam, dobaviteljem in strankam, ker se napake v teh osnovnih podatkih med selitvijo samo prenesejo v nov sistem, ne pa odpravijo. Podvojeni zapisi, zastareli artikli ali različno poimenovanje istega izdelka na več lokacijah povzročijo, da poročila po selitvi niso nič bolj zanesljiva kot pred njo. Čiščenje matičnih podatkov zato ni administrativna formalnost, temveč pogoj, da nov sistem sploh lahko prikaže točno sliko zalog in naročil.

Pred podpisom pogodbe z izvajalcem je smiselno pripraviti pregled, ki zajema vsaj naslednje:

Ločeno od tega je treba urediti tudi testno okolje, v katerem se preverjajo nastavitve pred prehodom v redno uporabo. Testno okolje ne sme vsebovati pravih osebnih podatkov strank ali zaposlenih, temveč vzorčne zapise, ki omogočajo preverjanje delovanja brez tveganja za zasebnost. Šele ko so osnovni podatki urejeni in testno okolje pripravljeno, se lahko začne dejanska selitev delovnih nalogov, naročil in finančnih evidenc v produkcijski sistem.

• popis obstoječih virov podatkov (ERP, preglednice, papirne evidence)
• seznam procesov, ki niso dokumentirani, a jih zaposleni izvajajo rutinsko
• pregled kosovnic in šifrantov izdelkov po posameznih obratih
• seznam zunanjih sistemov, s katerimi se mora nov ERP povezati prek API-ja
• opredelitev uporabniških vlog in pravic dostopa po oddelkih
• določitev, kateri podatki morajo ostati dostopni tudi med selitvijo

Varnost podatkov in skladnost pri ERP v oblaku#

Varnost ERP sistema v oblaku je odvisna predvsem od tega, kako sta urejena nadzor dostopa in ločevanje razvojnega, testnega in produkcijskega okolja, ne od tega, ali sistem teče v oblaku ali na lastnem strežniku v proizvodnem obratu. Oblačna infrastruktura sama po sebi ni ne bolj ne manj varna od lokalne – odločilno je, kako so nastavljene pravice dostopa, kako se beležijo spremembe in kako hitro se namestijo varnostni popravki.

Za proizvodna podjetja je poleg splošne varnosti pomembno tudi, kdo ima dostop do občutljivih podatkov, kot so recepture, kalkulacije stroškov, pogodbe z dobavitelji in osebni podatki zaposlenih. Pravice dostopa je treba določiti po vlogah, ne po posameznikih, da ob menjavi zaposlenega ni treba na novo urejati celotnega sistema pravic. Prav tako je treba ločeno voditi sledljivost sprememb, da je ob morebitnem sporu ali reviziji mogoče ugotoviti, kdo je kateri podatek spremenil in kdaj.

Pri projektih, ki zahtevajo višjo raven zanesljivosti, se Epix in njegova specialistična partnerska mreža opirata na standarde, uveljavljene v panogi informacijske varnosti, in na certificirane strokovnjake znotraj delivery strukture. To pomeni, da se varnostna arhitektura, nadzor dostopa in postopki odziva na incidente načrtujejo po preverjenih praksah, ne po presoji posameznega razvijalca. Za proizvodno podjetje to pomeni manjše tveganje, da bi selitev v oblak odprla varnostno luknjo, ki je prej ni bilo.

Kako poteka selitev obstoječega ERP sistema v oblak?#

Selitev poteka v fazah, ki si sledijo od pregleda do primopredaje. Najprej se pregledajo obstoječa izvorna koda, arhitektura, infrastruktura in podatki obstoječega sistema, nato se določi, kateri deli se prenesejo v novo okolje, kateri se zgradijo na novo in kateri procesi se ob tem poenostavijo. Šele na podlagi tega pregleda je mogoče realno oceniti obseg selitve in zaporedje korakov, namesto da bi se obseg ocenjeval le na podlagi površnega opisa trenutnega stanja.

Pri proizvodnih podjetjih je pogosto, da obstoječi sistem ni bil nikoli v celoti dokončan ali da ga je v preteklosti nadgrajevalo več različnih izvajalcev. V takem primeru je mogoče prevzeti obstoječ ali nedokončan sistem, ga pregledati in nadaljevati razvoj, ne da bi bilo treba vse zgraditi znova. To je pomembno predvsem takrat, kadar podjetje v obstoječem sistemu že ima leta zgodovinskih podatkov o naročilih, zalogah in dobaviteljih, ki jih ne želi izgubiti.

Pri večjih selitvah se določi projektni vodja, ki je odgovoren za usklajevanje med izvajalcem in naročnikom, jasno se opredelijo odgovornosti posameznih ekip, roki posameznih faz ter način komunikacije in poročanja o napredku. Naročnik v vsakem trenutku ve, v kateri fazi je projekt, kateri podatki so že preseljeni in kateri procesi še čakajo na testiranje. Brez takega okvira se pri večmesečnih projektih hitro izgubi pregled nad tem, kaj je dejansko že narejeno.

Pred prehodom v redno uporabo se pripravijo testni scenariji, ki pokrivajo ključne procese: izdajo delovnega naloga, prejem materiala, obračun zalog in izdajo dokumentov za odpremo. Testiranje poteka ročno in avtomatizirano, po potrebi pa se vključi neodvisen QA, ločen od razvojne ekipe, da se napake odkrijejo, preden jih opazijo uporabniki v proizvodnji. Prevzemno testiranje se izvede po vnaprej dogovorjenih merilih, tako da je jasno, kdaj je sistem pripravljen za prehod v produkcijo.

Vpliv na zaposlene in spremembe delovnih procesov#

Prehod na ERP v oblaku najbolj občutijo zaposleni, ki sistem uporabljajo vsak dan: operaterji na proizvodni liniji, skladiščniki, nabavna služba in računovodstvo. Njihovo vključevanje že v fazo priprave neposredno vpliva na to, ali bo uvedba uspešna, saj se šele pri dejanskem delu pokaže, ali nov vmesnik ustreza načinu, kako ljudje dejansko beležijo delovne naloge, prevzeme materiala in izmet.

Sprememba sistema pomeni tudi spremembo navad, ki so se v proizvodnji pogosto utrdile skozi leta. Zaposleni, ki so vajeni papirnih delovnih nalogov ali preglednic, novega sistema ne bodo sprejeli samo zato, ker je tehnično boljši. Potrebno je usposabljanje, prilagojeno posameznim vlogam, in obdobje, v katerem imajo zaposleni na voljo podporo za vprašanja, ki se pojavijo šele pri dejanskem delu, ne med predstavitvijo sistema.

Pri uvajanju novega sistema je smiselno vnaprej nasloviti naslednje vidike, povezane z zaposlenimi:

Del primopredaje so tudi dokumentacija, dostopi in gesla, ki morajo ostati pri naročniku, ne le pri izvajalcu. To zaposlenim, ki prevzamejo vlogo internega skrbnika sistema, omogoča, da po koncu projekta samostojno urejajo uporabnike, pravice dostopa in osnovne nastavitve, ne da bi bili za vsako spremembo odvisni od zunanjega izvajalca. Jasna dokumentacija je še posebej pomembna v proizvodnji, kjer se zaposleni menjavajo med izmenami in oddelki pogosteje kot v pisarniškem delu podjetja.

• usposabljanje po vlogah (proizvodnja, skladišče, nabava, finance)
• določitev, kdo v podjetju je interni skrbnik sistema po uvedbi
• obdobje vzporednega dela v starem in novem sistemu za kritične procese
• jasna navodila za najpogostejše delovne naloge, prilagojena vsaki izmeni
• kanal za prijavo težav med zagonom, ločen od splošne podpore

Povezovanje ERP z drugimi sistemi v proizvodnji#

ERP v oblaku redko deluje sam zase – v proizvodnem podjetju se mora povezati s sistemi za upravljanje odnosov s strankami, z dokumentnimi sistemi, s poročanjem za vodstvo in pogosto tudi z opremo na proizvodni liniji, zato je treba te povezave določiti še pred izbiro rešitve, ne šele po njeni uvedbi.

Podjetja, ki selitev ERP v oblak šele načrtujejo, imajo pogosto za finance in osnovno poslovanje že vzpostavljen enega od uveljavljenih sistemov, kot so Pantheon, Business Central ali SAP. Nov ERP mora znati prevzeti podatke iz takega sistema ali z njim nekaj časa delovati vzporedno, dokler se ne preveri, da so vsi procesi pravilno preneseni. Povezave med sistemi potekajo prek API-jev, ki omogočajo, da podatki med sistemi tečejo samodejno, brez ročnega izvoza in uvoza datotek.

Pri proizvodnem podjetju je treba pred izbiro ERP sistema določiti vsaj, kako se bo povezal z:

Vsaka dodatna povezava poveča obseg projekta, zato jo je treba obravnavati kot ločen sklop z lastnim testiranjem, ne kot stransko nastavitev ob robu glavne uvedbe. Pri tem je pomembno tudi razmejiti, kateri sistem je po uvedbi glavni vir resnice za posamezen podatek, denimo za zalogo ali ceno artikla, da si dva sistema po nesreči ne nasprotujeta. Jasna razmejitev virov podatkov prepreči, da bi se po selitvi pojavljala razhajanja med poročili iz različnih oddelkov.

• sistemom za upravljanje odnosov s strankami (CRM)
• dokumentnim sistemom za pogodbe, dobavnice in certifikate kakovosti
• opremo na proizvodni liniji, kot so senzorji in merilniki zasedenosti
• orodji za poslovno poročanje, ki jih uporablja vodstvo
• sistemom za nadzor zalog in skladiščno poslovanje

Vzdrževanje, podpora in odzivni časi po uvedbi#

Po uvedbi ERP sistema v oblaku je treba določiti, kdo prevzame nadzor nad delovanjem, odpravo napak, varnostne posodobitve in nadaljnji razvoj sistema. Projekt z zagonom ni končan – sistem se v proizvodnji uporablja dnevno, v vseh izmenah, zato zahteva stalno vzdrževanje in jasno dogovorjen način obravnave napak, ne le enkratno podporo v prvih tednih po uvedbi.

Napake in zahteve po spremembah je smiselno razvrstiti po prednosti, da se najprej obravnava tisto, kar dejansko ustavi proizvodnjo, ne tisto, kar je bilo prijavljeno prvo po vrsti. Izpad celotnega sistema ali ključnega dela zahteva takojšnjo obravnavo z najvišjo prednostjo, medtem ko manjša napaka brez vpliva na poslovanje počaka na naslednjo redno objavo. Odzivni časi za posamezen razred se določijo v pogodbi o podpori, prilagojeni kritičnosti procesov v konkretnem podjetju.

Razvrstitev napak po prednosti običajno vključuje:

Vsaka sprememba, tudi manjša, gre pred objavo v produkcijsko okolje skozi pregled in testiranje v ločenem testnem okolju. Tak postopek prepreči, da bi se nepreverjena sprememba neposredno odrazila na delovnih nalogih ali zalogah v živem sistemu. Za proizvodno podjetje to pomeni, da nadgradnje sistema ne ogrožajo tekoče proizvodnje, hkrati pa se sistem lahko postopoma razvija skladno s spremembami v poslovanju, brez potrebe po ponovni večji selitvi čez nekaj let.

• izpad – sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• motnja – sistem deluje, posamezna funkcija pa ne
• napaka – manjša težava brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• zahteva – sprememba ali nadgradnja, za katero se oceni obseg in uskladi termin

Kako izbrati izvajalca za program v oblaku za proizvodna podjetja?#

Pri izbiri izvajalca za program v oblaku za proizvodna podjetja je ključno preveriti, ali zna pokriti celoten obseg projekta – od analize obstoječih procesov prek razvoja in integracij do podpore po uvedbi – ali le posamezen tehnični sklop, ki ga bo moralo podjetje pozneje samo povezati z ostalimi deli sistema.

Projekti selitve ERP v proizvodnem podjetju običajno zahtevajo širok nabor znanj: solution arhitekte, ki znajo zasnovati povezave med sistemi, razvijalce za prilagoditve, strokovnjake za podatke pri selitvi zgodovinskih evidenc in strokovnjake za varnost pri nastavitvi dostopov. Epix in njegova specialistična partnerska mreža za tovrstne projekte sestavljata ekipe po potrebah posameznega projekta, namesto da bi vsak projekt izvajala ista majhna skupina ljudi ne glede na njegov obseg.

Pri izbiri izvajalca je smiselno preveriti vsaj naslednje:

Pri tem je vredno preveriti tudi, ali pogodba jasno določa, da sta izvorna koda in podatki last naročnika, ter da so dokumentacija, dostopi in gesla del primopredaje ob koncu projekta. Brez tega podjetje po koncu sodelovanja z izvajalcem ostane odvisno od njega tudi za najosnovnejše spremembe v sistemu, kar dolgoročno omejuje njegovo samostojnost pri upravljanju lastnega ERP sistema v oblaku.

• ali izvajalec zna prevzeti tudi obstoječ ali nedokončan sistem, ne le graditi od začetka
• kako je urejeno ločevanje razvojnega, testnega in produkcijskega okolja
• kdo po uvedbi prevzame podporo in po kakšnih pravilih se razvrščajo napake
• ali izvorna koda in podatki ostanejo last naročnika
• kako izvajalec pristopi k pregledu in čiščenju obstoječih podatkov pred selitvijo
• ali je mogoče najprej preseliti en proizvodni obrat in nato širiti na preostale

Od česa je odvisna cena ERP projekta v oblaku?#

Cena ERP projekta v oblaku se določi šele po pregledu zahtev, obsega dela in tehnične zahtevnosti, ne po splošnem ceniku, saj se projekti med seboj razlikujejo po številu uporabniških vlog, številu sistemov, ki jih je treba povezati, in zahtevah glede varnosti ter razpoložljivosti. Zato pred oceno cene praviloma sledi krajša analiza, ki obseg razčleni na sklope, tako da je vsak sklop mogoče oceniti in izvesti ločeno.

Cena je odvisna predvsem od naslednjih dejavnikov:

Krajša predhodna analiza omogoča, da se obseg dela razdeli na sklope, ki jih je mogoče izvajati in presojati ločeno – na primer selitev finančnih podatkov, povezavo z dokumentnim sistemom in uvedbo mobilnega dostopa za vodje izmen kot samostojne faze. Tak pristop vodstvu omogoča, da sprejema odločitve postopno, glede na to, kateri sklopi so za poslovanje najbolj nujni, namesto da bi moralo vnaprej potrditi celoten projekt brez jasnega vpogleda v njegov obseg.

Za proizvodno podjetje je končna cena tako posledica odločitev, sprejetih v fazi analize, ne naključne ocene izvajalca. Jasno opredeljen obseg dela, dogovorjena raven podpore po uvedbi in vnaprej znan način obravnave sprememb omogočajo, da se stroški projekta ujemajo s pričakovanji vodstva, hkrati pa ostane dovolj prostora za prilagoditve, če se med izvedbo izkaže, da določen proces zahteva drugačno rešitev, kot je bilo prvotno predvideno.

• 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
• raven podpore po uvedbi in dogovorjeni odzivni časi