10 pogrešaka u modernizaciji ERP-a koje treba izbjegavati

Pogreške u modernizaciji ERP-a koje najviše bole strateške su, a ne tehničke: tretiranje go-livea kao ciljne crte, kopiranje starih procesa u novi sustav, prekasno započinjanje rada na podacima i promjeni, ugrađivanje svega u ERP i potpisivanje licenci bez petogodišnjeg modela. Rijetko se vide u stvarnom vremenu. Izlaze na vidjelo nakon go-livea, kad se obećana učinkovitost ne pojavi, a zaobilaznice se vrate.

Ovo je za CIO-e, financijske direktore i direktore programa koji planiraju ili spašavaju S/4HANA ili drugu modernizaciju ERP-a. Svaka pogreška u nastavku dolazi s time kako izgleda u praksi i s popravkom, a slijede jednostranični kontrolni popis ranih upozorenja i što znače promjene u SAP-u 2026.

Gledao sam kako dobro financirani projekti s iskusnim timovima i punom klupom savjetnika ipak zaostaju. Uzrok rijetko leži u sustavu. Radi se o prazninama u vlasništvu, planiranju integracija i komunikaciji među timovima koji donose odluke koje međusobno ovise.

1. Tretiranje go-livea kao ciljne crte

Kad sustav proradi, mnogi timovi pretpostavljaju da je najteži dio gotov. Tada počinje pravi pritisak: svakodnevne operacije, promjenjivi zahtjevi i stvarno ponašanje korisnika guraju protiv dizajna.

Vidio sam projekte u kojima se upravljački odbor raspušta odmah nakon go-livea. Šest mjeseci poslije prihvaćanje stagnira i nitko ne posjeduje backlog.

Popravak: financirajte razdoblje upravljanja od 6 do 12 mjeseci nakon go-livea. Produljite mandat upravljačkog odbora. Pratite prihvaćanje procesa, a ne samo dostupnost. Postavite kontrolne točke kvalitete nakon go-livea s imenovanim vlasnicima.

2. Migriranje starih procesa bez preispitivanja

Vidio sam cijele lance odobravanja izgrađene točno onakvima kakvi su bili, čak i kad polovica uključenih ljudi nije imala nikakve veze s trenutnim procesom. Nitko nije pitao trebaju li koraci još. Rezultat je bio moderan ERP koji vrti stare tijekove rada: skuplja verzija onoga što su već imali.

S/4HANA verzija toga: prilagođeni batch poslovi premješteni iz ECC-a nepromijenjeni, izgrađeni na strukturama tablica koje više ne postoje. Migracija je tehnički čista. Poslovna logika je pokvarena.

Popravak: redizajnirajte procese prije izgradnje. Provedite timove za operacije, financije i isporuku zajedno kroz svaki tijek rada i dovedite u pitanje svaki korak.

Naslijeđeno područje	Što često pođe krivo	Što učiniti umjesto toga
Prilagođeni kod iz ECC-a	Neiskorišteni prilagođeni kod premješten u S/4HANA	Pokrenite analizu korištenja i SAP-ove provjere prilagođenog koda; ukinite neiskorišteni kod
Stari tijekovi rada	Tijekovi odobravanja ponovno izgrađeni kad je automatizacija sada moguća	Vratite se na njih s poslovnim vlasnicima; koristite standardne Fiori aplikacije ili SAP Build Process Automation
Nestandardni matični podaci	Fleksibilne naslijeđene postavke ne prolaze S/4HANA validaciju	Očistite i uskladite prije migracije, uz SAP MDG gdje odgovara
Izvješća na naslijeđenim tablicama	Izravan pristup tablicama ne odgovara S/4HANA modelu podataka	Ponovno izgradite na CDS viewovima
Skrivene ručne zaobilaznice	Pomoćni procesi pojavljuju se nakon go-livea	Koristite process mining prije migracije i digitalizirajte praznine

3. Prekasno započinjanje migracije podataka

Premještanje loših podataka u novi ERP kao selidba je bez bacanja ičega. Nered ide s vama i teže ga je počistiti kad je u strukturiranom sustavu.

Jednom sam vidio go-live koji je propao jer nitko nije primijetio da ključni skup podataka ima unose iz pet različitih poslovnih jedinica, svaka s vlastitom logikom kodiranja. Tehnička migracija bila je ispravna. Podaci nisu bili upotrebljivi. Izvješća su se pokvarila, korisnici su izgubili povjerenje, a čišćenje na živom sustavu trajalo je mjesecima.

Popravak: učinite podatke radnim tokom s poslovnom odgovornošću. Dodijelite vlasnike procesa, ne samo tehničke konzultante. Odlučite što prenijeti, arhivirati ili ponovno izgraditi prije početka migracije. Provedite barem dva puna probna učitavanja, s mapom ovisnosti za slijed učitavanja i definiranim povratkom za svako učitavanje. Moj tekst o tome zašto migracija SAP podataka ne uspijeva ide dublje.

4. Tretiranje upravljanja promjenom kao sporednog zadatka

Uobičajena verzija: upravljanje promjenom je „već riješeno“, što znači nekoliko slajdova, demo i jedna obuka prije go-livea.

Ljudi se ne opiru jer ne vole promjene. Opiru se kad nitko ne objasni zašto se stvari mijenjaju ili kako im to pomaže. Prate sustav taman toliko da prođu kontrolni popis, a zatim se vrate proračunskim tablicama.

Uobičajeni okidač je pritisak rasporeda: obuka se sažima da se nadoknadi vrijeme, korisnici su preplavljeni na go-liveu, a dodatni hypercare košta više od obuke koja je skresana.

Popravak: upravljanju promjenom dajte vlastiti proračun, vremenski plan i višeg vlasnika od početka. Rano mapirajte uloge, pronađite lokalne zagovornike i pratite KPI-jeve prihvaćanja uz tehničke prekretnice. Moj vodič za plan upravljanja promjenom iznosi strukturu.

5. Planiranje oko planova razvoja dobavljača

Vidio sam timove koji su integracijsku strategiju temeljili na budućem izdanju dobavljača, da bi ga on odgodio za 12 mjeseci. U međuvremenu su zapeli gradeći privremene zaobilaznice, a zaobilaznice su postale trajne.

Dobavljači grade planove razvoja (roadmap) za široke skupine kupaca. Vaše poslovanje rijetko je središte tog dizajna.

Popravak: tretirajte plan razvoja kao jedan ulaz. Dizajnirajte oko onoga što je danas općenito dostupno, nove funkcije testirajte u sandboxu prije nego što ih uračunate u plan, a koristi iz plana razvoja brojite kao dodatnu vrijednost, ne kao proračun.

6. Nema plana ukidanja naslijeđenih sustava

Jednom sam vidio tvrtku koja je plaćala šesteroznamenkasti iznos godišnje da održava star sustav za šest korisnika kojima su izvješća trebala dvaput godišnje. Nitko nije izradio plan ukidanja.

Popravak: unesite ukidanje u povelju projekta od prvog dana, uz uključene pravnu službu, usklađenost i upravljanje podacima, ne samo IT. Dogovorite rokove čuvanja i pristup arhiviranju prije go-livea, mapirajte i odspojite svako sučelje prema starom sustavu i dajte jednom timu zadatak da ga ugasi.

7. Podcjenjivanje složenosti integracije

Kad integracija zakaže, poslovanje to primijeti prije IT-a, jer tijekovi rada staju usred procesa u produkciji, a ne u testnom sustavu.

Uobičajeni obrazac: IT i poslovanje svaki pretpostavljaju da je drugi definirao zahtjeve za integraciju. Nijedan nije. Dok se praznine pokažu u testiranju, nema vremena za redizajn.

Popravak: počnite dizajn integracije u blueprintu. Definirajte svaki scenarij, middleware, mapiranje i količine poruka te s poslovanjem razjasnite stvarno vrijeme naspram batcha po sučelju. Imenujte vlasnika sučelja sa SLA-om prije go-livea. Za nove SAP programe middleware je SAP Integration Suite; SAP PI/PO izlazi iz standardnog održavanja krajem 2027.

8. Pretpostavka da ERP može sve

Radio sam na projektima gdje su timovi gurali složene uslužne tijekove rada (IT tikete, zahtjeve za imovinu, usmjeravanje eskalacija) u ERP jer nisu željeli uključivati vanjske sustave kao ServiceNow. Rezultat su bila prilagođena polja posvuda, ručne zaobilaznice i korisnici zaglavljeni u procesu koji nikad nije pristajao.

ERP je dobar u strukturiranim, transakcijskim, financijski usidrenim procesima. Namjenske platforme bolje rade IT zahtjeve za uslugu, orkestraciju tijekova rada i upravljanje znanjem.

Popravak: namjerno odlučite što ne graditi u ERP-u. Koristite side-by-side proširenja na SAP BTP-u za iznimke, a ServiceNow ili slično za orkestraciju izvan transakcijske jezgre. Moj članak o modernizaciji ERP-a uz SAP i ServiceNow obuhvaća tu podjelu.

9. Podcjenjivanje dugoročnog troška licenciranja

Znam jedan tim koji je u drugoj godini udvostručio potrošnju na licence jer mu je trebala jedna funkcija iza licence više razine. Poslovni slučaj modelirao je samo trošak do go-livea.

ERP licence naplaćuju korisnike, module, transakcije i korištenje API-ja, a trošak raste s poslovanjem, bilo da ste to planirali ili ne. Na SAP-u model Digital Access znači da dokumenti koje stvaraju sustavi trećih strana mogu nositi trošak licence kojeg nije bilo u izvornom komercijalnom modelu. Pod RISE-om i SAP GROW broj Full User Equivalenta (FUE) raste s prihvaćanjem.

Popravak: izradite model licenci za tri do pet godina prije potpisa. Mapirajte uloge na vrste licenci, modelirajte rast FUE-a na realnoj krivulji prihvaćanja, razumite neizravni pristup (indirect access) prije povezivanja vanjskih sustava i revidirajte neaktivne korisnike nakon go-livea.

10. Tretiranje ERP-a kao IT projekta

Najčešći i najštetniji obrazac. Planiranje počinje u IT-u, vodi ga IT i rješava IT probleme.

Vidio sam timove koji na papiru pogode svaku prekretnicu, a poslovanje i dalje pita zašto se ništa ne osjeća bolje. To obično znači da je ERP izgrađen za jučerašnje procese, bez voditelja operacija, financija ili prodaje u dizajnu.

Popravak: stavite komercijalne voditelje, voditelje financija i operacija u upravljački odbor od početka. U povelju upišite stratešku usklađenost, a ne samo tehnički opseg. Ciljeve programa provjerite u odnosu na ishode na razini uprave prije početka dizajna.

Koristite ga na svakom upravljačkom odboru. Ako je znak upozorenja prisutan, imenovani vlasnik izvještava o njemu dok ne nestane.

1. PoveljaVlasništvo i trošakNema voditelja operacija ni financija, nema petogodišnjeg modela licenci, nema datuma ukidanja
2. BlueprintDizajn procesa i integracijaDanašnji proces kopiran, sučelja još nedizajnirana
3. Prvo probno učitavanjePodaciJoš nema izvješća o kvaliteti podataka
4. Go-liveŠto slijediNema financiranog upravljanja za 12 mjeseci poslije

Pogreška	Rani znak upozorenja	Vlasnik
1. Go-live kao ciljna crta	Nema financiranog plana upravljanja za 12 mjeseci nakon go-livea	Sponzor
2. Kopirani stari procesi	Radionice dizajna kreću od zaslona „kako to radimo danas“	Vlasnici procesa
3. Kasni rad na podacima	Nema izvješća o kvaliteti podataka prije prvog probnog učitavanja	Voditelj migracije podataka
4. Promjena kao sporedni zadatak	Plan promjene je kalendar obuka	Voditelj promjene
5. Ovisnost o planu razvoja	Odluka o dizajnu čeka funkciju koja nije objavljena	Solution arhitekt
6. Nema ukidanja	U povelji nema datuma ukidanja ni za jedan naslijeđeni sustav	PMO
7. Podcijenjena integracija	Sučelja nisu dizajnirana do kraja blueprinta	Voditelj integracije
8. ERP za sve	Prilagođeni objekti za netransakcijske tijekove rada	Enterprise arhitekt
9. Licenciranje	Nema petogodišnjeg modela licenci u poslovnom slučaju	CFO
10. Program samo za IT	Upravljački odbor nema voditelja operacija ni financija	Sponzor

Isporuka. Za nove SAP programe zadano je RISE with SAP na SAP Cloud ERP Private ili SAP GROW na public editionu (SAP Cloud ERP) za srednje velike tvrtke. Nova on-premise uvođenja rijetka su. ECC kupci suočavaju se s krajem standardnog održavanja 31. prosinca 2027., što skraćuje vrijeme za ispravljanje pogrešaka 2, 3 i 7.

Clean core. SAP sada ocjenjuje proširenja na četiri razine clean corea, od A (samo objavljeni API-ji, side by side na BTP-u ili unutar sustava uz ABAP Cloud) do D (nije clean). Public edition dopušta samo razinu A, što forsira razgovor iza pogreške 2. Private edition i dalje dopušta klasična proširenja, pa disciplina mora doći iz upravljanja. Klasični prilagođeni kod čini svaki upgrade projektom. Moj tekst o strategiji clean corea ide dalje.

AI u alatima za isporuku. Joule se sada nalazi u SAP Cloud ALM-u i SAP Activate Roadmap Vieweru, a SAP Build Code koristi Joule za razvoj proširenja. Pitajte partnere kako se AI alati odražavaju u njihovu cjeniku. Ako se ne odražavaju, ili je cijena visoka ili ušteda ide u njihovu maržu.

Alati za životni ciklus. SAP Cloud ALM alat je za upravljanje životnim ciklusom cloud programa. Solution Manager 7.2 izlazi iz standardnog održavanja krajem 2027., pa okruženja koja koriste oba trebaju plan prelaska.

Deset pogrešaka nije se promijenilo. Promijenio se trošak pogrešnog postupanja. Na RISE programu odluka o clean coreu, model isporuke i model FUE-a postavljaju se u prvim tjednima mobilizacije. Prozor za utjecaj na njih kratak je.

Zašto napori modernizacije ERP-a zaostaju nakon go-livea?

Većina timova planira do go-livea i staje. Nitko ne posjeduje poboljšanja, povratne informacije, ispravke procesa ni backlog. Raspuštanje upravljačkog odbora na go-liveu najpouzdaniji je znak nevolje. Financirajte 6 do 12 mjeseci upravljanja nakon go-livea od prvog dana.

Koji je rizik kopiranja starih procesa u novi ERP?

Novi sustav nasljeđuje stare neučinkovitosti uz viši trošak. Posebno u S/4HANA migracijama, prilagođeni kod i batch poslovi izgrađeni za ECC tablice često ne rade, pa migracija može biti tehnički čista dok je poslovna logika pokvarena.

Kako loša kvaliteta podataka šteti modernizaciji ERP-a?

Dupli dobavljači, nedosljedni matični podaci, naslijeđene šifre i nepotpuni zapisi prenose se u novi sustav osim ako ih netko prije ne očisti. Izvješća se kvare, korisnici prestaju vjerovati brojkama, a čišćenje na živom sustavu traje mjesecima.

Zašto se upravljanje promjenom u ERP projektima tako često podcjenjuje?

Zato što nije vidljivo na projektnom planu kao konfiguracija. Rukovoditelji pretpostavljaju da je dovoljno nekoliko obuka. Upravljanje promjenom priprema ljude na ono što će se doista promijeniti u njihovu svakodnevnom radu, prije go-livea. Alati za digitalno prihvaćanje kao što je WalkMe, sada u vlasništvu SAP-a, pomažu s uputama unutar aplikacije, ali ne zamjenjuju objašnjenje zašto.

Zašto naslijeđeni sustavi rade godinama nakon go-livea ERP-a?

Zato što nitko nije planirao njihovo gašenje. Svi su usredotočeni na to da novi ERP proradi, a stari sustavi ostaju zbog usklađenosti, uvida ili udobnosti. Ukidanje mora biti u opsegu od prvog dana, uz uključenu pravnu službu i usklađenost.

Kako RISE with SAP i clean core mijenjaju ove pogreške?

Na public editionu pravila clean corea onemogućuju duboke prilagodbe, što forsira razgovor o procesima iza pogreške 2. Na private editionu klasična proširenja i dalje su dopuštena, pa clean core ovisi o upravljanju. Integracija se seli na SAP Integration Suite kako završava održavanje PI/PO-a. Licenciranje postaje pitanje rasta FUE-a. Ukidanje postaje hitnije jer paralelno održavanje naslijeđenih sustava dodaje trošak povrh višegodišnje pretplate.