Planiranje rokova SAP implementacije: 5 pogrešaka koje treba izbjeći

Vremenski plan SAP implementacije plan je po fazama, od faze Discover do hypercarea. Kod projekta u javnom oblaku, pregled stotina projekata koji je napravio jedan SAP-ov stručnjak za proizvod tipično puštanje u rad smješta nakon pet do sedam mjeseci. Programi velikih poduzeća u privatnom oblaku ili on-premise traju znatno dulje od godine dana. Hoće li Vaš plan izdržati, manje ovisi o metodologiji, a više o pet pogrešaka u planiranju: datumima zaključanima prije nego što je opseg jasan, kasnoj migraciji podataka, preskočenim kontrolnim točkama kvalitete, prerano održanoj obuci i puštanju u rad u sezoni vrhunca. Ovaj je vodič namijenjen direktorima programa i sponzorima koji izrađuju plan ili ga spašavaju. Tablicu faza upotrijebite kao kostur, a zatim ga provjerite prema ovih pet pogrešaka. Svaki dodatni mjesec kašnjenja može značiti 100.000 USD ili više troškova savjetovanja.

Upoznao sam voditelja projekta iz jedne proizvodne tvrtke čiji je SAP projekt kasnio šest mjeseci. Nakon što su se strogo vratili na faze SAP Activatea, preostali su posao završili za četiri mjeseca. Njegove riječi: „Jasne faze s konkretnim isporukama napravile su svu razliku. Uvijek smo točno znali što nam je sljedeće raditi."

Rokovi koji se održe imaju tri zajednička obilježja. Realne rezerve. Pretpostavke provjerene prije zaključavanja. Kontrolne točke kvalitete tretirane kao stroge zaustavne točke.

Pet pogrešaka čini većinu prekoračenja. Svaka je predvidljiva i za svaku postoji protumjera.

Pogreška 1: određivanje rokova prije nego što je opseg jasan

Jednom sam radio s tvrtkom koja je upravi obećala devetomjesečnu implementaciju bez ikakve rezerve. Kad je migracija podataka trajala dulje nego što se očekivalo, rok su probili za tri mjeseca, a rukovoditelji su izgubili povjerenje u tim. Kad su me kao savjetnika pitali za mišljenje, otvoreno sam im rekao da je rok preagresivan. Voditelj projekta bio je prisiljen prihvatiti ga.

Rješenje: zaključajte rok nakon faze Explore, a ne na početku projekta, i to unaprijed recite upravi. Ugradite 15-20 % rezerve povrh procjene isporučitelja.

Pogreška 2: migracija podataka kao radni tok koji počinje kasno

Većina timova kasno imenuje voditelja migracije podataka i za taj posao izdvaja premalo resursa. Početne procjene stanja podataka gotovo uvijek podcjenjuju problem. Slijede tri mjeseca čišćenja podataka pod pritiskom živog sustava.

Rješenje: profiliranje podataka započnite u fazi Discover, a ne u fazi Realize. U fazi Realize provedite punu probnu migraciju prije početka integracijskog testiranja. Ako probna migracija padne, imate vremena za popravak. Ako to otkrijete tek pri cutoveru, nemate. Moj tekst o tome zašto SAP migracija podataka propada detaljno opisuje ciklus probnih migracija.

Pogreška 3: preskakanje kontrolnih točaka kvalitete pod pritiskom rasporeda

Kontrolnu točku između faza Realize i Deploy timovi najčešće preskaču, jer pritisak da se „samo pusti u rad" ondje doseže vrhunac. Preskakanje kontrolnih točaka radi „držanja rasporeda" kasnije uzrokuje veća kašnjenja.

Rješenje: upišite mjerljive izlazne kriterije u projektnu povelju i prepustite upravljačkom odboru da ih provodi. Probno mjesečno zatvaranje financijskih knjiga ovdje je korisna kontrolna točka. Ako ga financijski tim ne može provesti bez grešaka, sustav nije spreman. Više o oblikovanju kontrolnih točaka u mom vodiču kroz SAP kontrolne točke kvalitete.

Pogreška 4: obuka korisnika dva mjeseca prije puštanja u rad

Radio sam s maloprodajnom tvrtkom koja je sve korisnike obučila dva mjeseca prije puštanja u rad. Do dana pokretanja svi su zaboravili kako se sustav koristi. Morali smo na svako radno mjesto postaviti kratke podsjetnike za rad i udvostručiti podršku na licu mjesta. Većina novca utrošenog na obuku bila je bačena.

Rješenje: obuku smjestite u razdoblje od dva do tri tjedna prije puštanja u rad. Za trenere angažirajte napredne korisnike (power usere), jer ljudi uče od kolega kojima vjeruju. Sesije za osvježavanje znanja planirajte tijekom hypercarea. Cjelovit pristup opisujem u svom članku o strategijama obuke za SAP.

Pogreška 5: puštanje u rad usred vrhunca poslovnog ciklusa

Hershey je svoj sustav sastavljen od SAP R/3, Siebela i Manugistics pustio u rad u srpnju 1999., tri mjeseca kasnije nego što je planirano i to točno u sezoni narudžbi za Halloween. Njegov je glavni direktor analitičarima rekao da će zbog problema Hershey ostati bez mogućnosti isporuke narudžbi za Halloween vrijednih 100 milijuna USD. Pouka je očita i još se uvijek zanemaruje.

Rješenje: za svaku zahvaćenu poslovnu jedinicu ucrtajte vrhunce poslovnih ciklusa, uključujući mjesečna i tromjesečna zatvaranja. Sustav pustite u rad u razdoblju manjeg opsega poslovanja, čak i ako to znači pomak od šest tjedana. Pomak se može nadoknaditi. Neuspješan go-live u sezoni vrhunca ne može.

SAP Activate zamijenio je staru metodologiju ASAP. Njegovih šest faza kostur je svakog plana za S/4HANA, bilo u oblaku bilo on-premise. Trajanja u nastavku polazne su točke za planiranje programa u velikom poduzeću, a ne obećanja.

1. 1Discover2 do 4 tjedna. Izlaz: potpisani opseg i kriteriji uspjeha
2. 2Prepare3 do 6 tjedana. Izlaz: povelja odobrena, resursi potvrđeni pisanim putem
3. 3Explore4 do 8 tjedana. Izlaz: odluke o odstupanjima imaju vlasnike, rok zaključan
4. 4Realize8 do 16 tjedana. Izlaz: probna migracija prošla, integracijski testovi zatvoreni
5. 5Deploy2 do 4 tjedna. Izlaz: UAT potpisan, probno zatvaranje, odluka go/no-go
6. 6Run4 do 8 tjedana hypercarea. Izlaz: greške ispod praga, podrška potpisana

Faza	Tipično trajanje	Što se događa	Izlazna kontrolna točka prije prelaska dalje
Discover	2-4 tjedna	Poslovni slučaj, opseg, odabir modela isporuke (javni oblak, privatni oblak ili on-premise)	Potpisani opseg i mjerljivi kriteriji uspjeha
Prepare	3-6 tjedana	Uključivanje tima, upravljanje projektom, sistemsko okruženje, osnovni plan, registar rizika	Povelja odobrena, imenovani donositelji odluka po modulu, pisane obveze o resursima
Explore	4-8 tjedana	Radionice Fit-to-Standard, popis odstupanja (gap log), popis RICEFW (izvještaji, sučelja, konverzije, proširenja, obrasci, tijekovi rada)	Odluke o odstupanjima zabilježene s vlasnicima; rok zaključan
Realize	8-16 tjedana	Konfiguracija, razvoj, testiranje jedinica i integracijsko testiranje, probne migracije	Probna migracija prošla; integracijski testovi zatvoreni
Deploy	2-4 tjedna	Korisničko prihvatno testiranje (UAT), proba cutovera, obuka krajnjih korisnika, završno učitavanje	UAT potpisan, probno zatvaranje prošlo, odluka go/no-go
Run	4-8 tjedana hypercarea	Podrška na licu mjesta, dnevno razvrstavanje problema, predaja u podršku	Otvorene greške ispod dogovorenog praga; prijenos u podršku potpisan

Gdje vrijeme stvarno odlazi

Fazu Discover timovi požure. Rok odrede prije nego što razumiju opseg i preskoče mjerljive kriterije uspjeha. Trebaju Vam ciljevi poput „skratiti mjesečno zatvaranje za tri dana".

U fazi Prepare počinju tehnička kašnjenja. Na RISE with SAP infrastrukturu osigurava SAP. On-premise je grade klijent i partner, a kašnjenje se ovdje prelijeva na sve ostalo. Obveze o resursima ishodite pisanim putem. Usmena raspoloživost ishlapi.

U fazi Explore važno je voditi evidenciju. Šest mjeseci kasnije nitko se ne sjeća zašto se povrati obrađuju na određeni način, osim ako su odluka i njezin vlasnik zapisani. Timovi također podcjenjuju broj odstupanja.

Realize je najdulja faza i ondje završava većina prekoračenja, obično zato što je Explore proizveo preoptimističan popis odstupanja. Vaša prva probna migracija će propasti. Treba Vam da propadne u testiranju, a ne u produkciji. Dugotrajni tjedni od 60 sati vode do pogrešaka i odlazaka ljudi.

Faza Deploy traži plan cutovera s točnim koracima, vremenima i vlasnicima. „Migriraj podatke" nije korak.

U fazi Run stvari pođu po zlu kad kritični problemi čekaju iza beznačajnih. Prioritete odredite prema poslovnom učinku, a ne prema redoslijedu dolaska, i zapišite svaki popravak. Vaš tim za podršku isti će problem vidjeti ponovno.

Radio sam sa zdravstvenim pružateljem usluga koji je kasnio tri mjeseca i suočavao se s prekoračenjem proračuna od 2 milijuna USD. Ponovno smo se postavili pomoću radionica Fit-to-Standard iz metodologije SAP Activate. Tim je pronašao 28 procesa u financijama i opskrbnom lancu koje je moguće voditi bez ikakve prilagodbe. Riječi njihova voditelja projekta: „Mjesecima smo osmišljavali stvari koje je SAP već imao izgrađene." U roku od šest tjedana vratili su se u raspored i sustav pustili u rad na vrijeme.

Radio sam s maloprodajnom tvrtkom koja je otkrila da standardni SAP procesi pokrivaju 70 % njezinih potreba. Planirala je opsežne prilagodbe sve dok nije vidjela sustav na djelu.

Clean Core to dodatno zaoštrava. Na izdanju S/4HANA Cloud Public Edition standardni su procesi jedina opcija, a proširenja se nalaze na SAP BTP-u ili objavljenim API-jima. U privatnom oblaku i on-premise još uvijek možete mijenjati sustav, ali SAP-ove smjernice za Clean Core vuku u istom smjeru. Kad za svako odstupanje treba odluka o proširenju na BTP-u s pripadajućim troškom, razgovor o prilagodbama postaje iskreniji.

Model isporuke mijenja vremenski plan više od bilo kojeg drugog izbora.

1. Javni oblak (GROW with SAP, S/4HANA Cloud Public Edition, koji se sada prodaje kao SAP Cloud ERP). SAP-ov stručnjak za proizvod koji je pregledao stotine projekata tipično puštanje u rad procjenjuje na pet do sedam mjeseci. SAP-ova ponuda GROW Fast, pokrenuta početkom 2026., cilja na dva do četiri mjeseca uz fiksni opseg. Veliki projekti u javnom oblaku traju 12 mjeseci ili dulje.
2. Privatni oblak (RISE with SAP, sada SAP Cloud ERP Private) i on-premise. Opseg velikog poduzeća tipično traje 12-24 mjeseca. SAP na RISE-u vodi infrastrukturu, što uklanja dio posla u fazi Prepare. Ne uklanja napor oko podataka, testiranja i promjena.

Industrija dodaje vlastito usporavanje. Ovo su tipični rasponi za cjelovit S/4HANA program velikog poduzeća:

Industrija	Raspon planiranja	Što ga produljuje
Proizvodnja	14-20 mjeseci	Kvaliteta sastavnica (BOM) i tehnoloških postupaka, podešavanje MRP-a, zahtjevi QM-a
Maloprodaja i potrošna roba	12-18 mjeseci	Integracija POS-a, količina matičnih podataka, prozori sezone vrhunca
Farmacija	16-22 mjeseca	GxP validacija, sljedivost serija, serijalizacija
Komunalne usluge	15-20 mjeseci	Upravljanje uređajima, strukture tarifa za obračun, integracija GIS-a i SCADA-e
Javni sektor	18-24 mjeseca	Fondovsko računovodstvo, propisi o javnoj nabavi, administracija odobrenja, zahtjevi o lokaciji pohrane podataka
Automobilska industrija	16-22 mjeseca	Just-in-time opskrbni lanac, kontrola inženjerskih promjena
Zrakoplovstvo i obrana	20-26 mjeseci	Izvještavanje prema državi, programsko računovodstvo, zaštićeni opskrbni lanci
Nafta i plin	18-24 mjeseca	Računovodstvo zajedničkih ulaganja (joint venture), poslovanje intenzivno u imovini
Financijske usluge	14-20 mjeseci	Oblikovanje uloga za podjelu dužnosti (segregation of duties), regulatorna validacija

Što AI alati mijenjaju, a što ne

SAP Joule for Consultants postao je opće dostupan 2025. Odgovara na pitanja o konfiguraciji iz SAP-ove vlastite baze znanja, uključujući SAP Notes, i objašnjava ABAP kod. SAP Build Code, opće dostupan od ožujka 2024., uz Joule generira Java i JavaScript kod za proširenja na SAP BTP-u.

Oba alata pomažu pojedinim konzultantima i programerima. Nijedan ne mijenja koliko traju radionice, odluke, čišćenje podataka ili prihvaćanje od strane korisnika. Planirajte s njima, ali ne skidajte tjedne s plana dok Vaš tim sam ne izmjeri učinak.

Ovo su rizici koje stavljam na tjedni dnevni red programa. Svaki od njih pomiče rokove ako ga se ostavi za mjesečni upravljački odbor.

1. Kasne promjene opsega. Zaključajte opseg na kraju faze Explore. Nakon toga svaku promjenu odobrava odbor za kontrolu promjena, uz priložen učinak na rok i proračun.
2. Kvaliteta podataka. Većina tvrtki preskače procjenu podataka tijekom planiranja. Započnite je sada. Loši podaci najdosljedniji su uzrok neuspjelih probnih migracija.
3. Uska grla u resursima. Od voditelja odjela zatražite pisane obveze za imenovane osobe i datume. Za svaku kritičnu ulogu obučite zamjenu.
4. Zastoji u odlučivanju. Neslaganja oko opsega eskalirajte u roku od 48 sati. Ne dopustite da odluke čekaju mjesečne preglede.
5. Kasno upravljanje promjenama. S krajnjim korisnicima počnite razgovarati u fazi Prepare, a ne dva tjedna prije puštanja u rad.

Matrica procjene rizika pretvara ovaj popis u nešto što upravljački odbor može ocijeniti.

Što se tiče alata: SAP Cloud ALM SAP-ova je primarna platforma za upravljanje implementacijom. Redovno održavanje za SAP Solution Manager 7.2 završava krajem 2027., a prošireno održavanje odabranih funkcija traje do 2030. za kupce koji ugovore prošireno održavanje za Business Suite. SAP Best Practices Explorer ukinut je 2023.; procesni sadržaj sada se nalazi u alatu SAP Signavio Process Navigator.

Koliko traje SAP implementacija u 2026.?

Ovisi o modelu isporuke, opsegu i industriji. Pregled stotina projekata koji je napravio SAP-ov stručnjak za proizvod S/4HANA Cloud Public Edition smješta na pet do sedam mjeseci, a SAP-ovu ponudu GROW Fast s fiksnim opsegom na dva do četiri. Programi velikih poduzeća na RISE with SAP u privatnom oblaku ili on-premise obično traju 12 do 24 mjeseca. Programi u javnom sektoru i zrakoplovstvu redovito traju dulje od 20 mjeseci.

Kako RISE with SAP utječe na vremenski plan?

RISE prebacuje odgovornost za infrastrukturu na SAP, što uklanja dio posla u fazi Prepare. Ne skraćuje migraciju podataka, testiranje, obuku ni donošenje odluka, a upravo tamo odlazi većina vremena. Disciplina Clean Core može skratiti fazu Realize ako zaustavi prilagođeni razvoj prije nego što počne.

Kako izraditi plan ključnih točaka za SAP implementaciju?

Počnite sa šest faza SAP Activatea i za svaku kontrolnu točku napišite mjerljive izlazne kriterije. U svakoj fazi odredite aktivnosti kritičnog puta i ovisnosti. Kontrolne točke tretirajte kao stroge zaustavne točke, pratite plan tjedno i upravljajte njime u SAP Cloud ALM-u.

Koji čimbenici utječu na trajanje SAP implementacije?

Najvažniji su opseg (moduli, društva, integracije), količina prilagodbi, kvaliteta podataka, broj korisnika i zemljopisna raširenost, brzina odlučivanja i regulatorna validacija. Povrh svega toga stoji model isporuke. Javni oblak najbrži je jer su opseg i procesi ograničeni. On-premise s mnogo prilagodbi najsporiji je.

Kako ubrzati SAP implementaciju?

Strogo provedite Fit-to-Standard, jer svaka prilagodba koju izbjegnete štedi tjedne. Čišćenje podataka započnite u fazi Discover. Poslovne resurse angažirajte s punim radnim vremenom umjesto da ih posuđujete na pola radnog vremena. Dogovorite putove odobrenja prije početka konfiguracije i plan cutovera pripremite tijekom faze Realize, a ne nakon nje.

Treba li odabrati big bang ili postupno uvođenje SAP-a?

Big bang sve pušta u rad odjednom. Ukupno je brži i rizičniji te odgovara manjem opsegu ili organizacijama s jakim upravljanjem promjenama. Postupno uvođenje ide po modulu, lokaciji ili poslovnoj jedinici. Rizik je manji, a trajanje dulje, pa odgovara velikim grupacijama s više društava. Mnogi programi srednje veličine biraju hibrid: osnovne financije odjednom, operativu postupno.

Koji su najčešći uzroci kašnjenja SAP projekata?

Nekontrolirani zahtjevi za promjenama, iznenađenja oko kvalitete podataka, kasno upravljanje promjenama, neuspjesi integracije s trećim stranama, gubitak ključnih ljudi usred projekta i spore odluke upravljačkog odbora. Većinu timova iznenadi kvaliteta podataka. Svi pretpostavljaju da su stari podaci čisti. Gotovo nikad nisu.

Što se događa nakon puštanja SAP-a u rad?

Počinje hypercare: četiri do osam tjedana podrške na licu mjesta, dnevnog razvrstavanja problema i praćenja performansi. Nakon toga sustav prelazi u tim za aplikacijsku podršku ili interni centar izvrsnosti. Prvo izdanje poboljšanja planirajte tri do šest mjeseci nakon go-livea.