Procjena rizika SAP projekta: praktična verzija

Procjena rizika SAP projekta popisuje što bi moglo izbaciti program iz kolosijeka i ocjenjuje svaki rizik prema vjerojatnosti i utjecaju. Svaki rizik dobiva jednog imenovanog vlasnika i odgovor dogovoren prije nego što se dogodi, a popis se pregledava svaki tjedan. Rizici koji potapaju SAP programe rijetko su iznenađenja: migracija podataka, integracija, dostupnost ljudi, klizanje opsega i usvajanje. Ovaj je vodič za voditelje programa i sponzore koji žele registar rizika koji mijenja odluke, a ne onaj koji stoji u mapi. Daje Vam bodovanu matricu, predložak registra, tri javna neuspjeha kao razrađene primjere i rizike koje RISE with SAP i Clean Core dodaju. Počnite tako da uz svaki rizik koji već imate upišete imenovanog vlasnika.

Većina procjena rizika SAP-a izgradi se prije prvog upravljačkog odbora, jednom pregleda i nikad više ne dotakne. To nije upravljanje rizicima. To je dokument.

Vidio sam rizike koji su ignorirani jer ih je bilo previše neugodno rano iznijeti. Ta šutnja gotovo uvijek kasnije košta više. Ono što počne kao malo integracijsko pitanje u upravljanju materijalima odjednom blokira financije. Izvještaj koji je u testiranju izgledao u redu puca nakon ažuriranja sustava. To sam vidio više puta.

Rizici nisu bili iznenađenja. Bili su dokumentirani. Nitko po njima nije djelovao.

Opseg. Projekt počinje sa standardnim modulima. Zatim netko doda „samo još jedan izvještaj”, pa nadzornu ploču, pa nekoliko proširenja. Opasnost su promjene opsega uvedene neformalno na radionicama, u e-porukama i razgovorima na hodniku za koje voditelj projekta sazna tek nakon što je konfiguracija gotova. Moj vodič o izbjegavanju klizanja opsega obrađuje kontrole.

Resursi. Arhitekta povuku na produkcijski problem. Ključni programer odlazi. Poslovni korisnici propuštaju cikluse testiranja jer njihov redovni posao ne staje. Dobijte dostupnost u pisanom obliku. Usmena obećanja ispare pod pritiskom broja zaposlenih.

Tehnički rizici. Mapiranja polja nikad nisu validirana prema ciljnoj strukturi. Sučelja koja prolaze jedinično testiranje, a pucaju pri stvarnom volumenu transakcija. Prilagođeni kod koji izgleda u redu do produkcijskog opterećenja. To je predvidljivo ako znate gdje gledati.

Vremenski plan. Kasni blueprint steže testiranje, a datum puštanja u rad ostaje fiksan. UAT, obuka i priprema podataka obavljaju se u žurbi. Isti obrazac pojavljuje se na gotovo svakom programu koji propusti kontrolnu točku faze (phase gate) i ne pomakne plan nizvodno.

Usvajanje. Ljudi odbacuju ono što ne razumiju. Slaba ili kasna obuka stvara zaobilazna rješenja, zaobilazna rješenja kvare podatke, a sustav se okrivljuje za neuspjeh upravljanja promjenama.

Ovi su slučajevi javni i dobro dokumentirani. Obrasci se ponavljaju na svakoj razini.

Lidl: oko 500 milijuna eura tijekom sedam godina

Lidl je 2011. započeo svoj projekt eLWIS na SAP for Retail, pustio ga u rad u nekim manjim zemljama i odustao od njega 2018. uz prijavljeni trošak od oko 500 milijuna eura. Jedan naširoko prijavljen uzrok: Lidl je zalihe vrednovao prema nabavnim cijenama, dok SAP-ov standardni maloprodajni model koristi maloprodajne cijene. Lidl je prilagođavao umjesto da promijeni praksu, a tvrtka je rekla da se izvorni ciljevi ne mogu postići uz razuman napor.

Pouka: nepodudarnost između Vašeg podatkovnog modela i SAP-ova standarda rizik je prvog tjedna, a ne otkriće pete godine.

HP: oko 400 milijuna dolara izgubljenog prihoda

HP je 2004. migrirao dio svog poslovanja s poslužiteljima na konsolidirani sustav narudžbi i opskrbnog lanca temeljen na SAP-u. Narudžbe su ispadale između naslijeđenog prednjeg sloja i SAP-a i tražile ručni rad, a zaostatak se udvostručio. HP-ov izvršni direktor rekao je da su problemi grupu za poslužitelje i pohranu koštali oko 400 milijuna dolara prihoda i 275 milijuna dolara operativne dobiti, ostavivši zaostatak od 120 milijuna dolara. HP-ov CIO kasnije je rekao da je tim planirao tri tjedna poremećaja, a trebao je imati pričuvu za četiri do šest.

Pouka: pričuvu dimenzionirajte za loš cutover, a ne za prosječan, i izgradite zalihe ili kanalne međuspremnike prije prelaska.

Nike: više od 100 milijuna dolara izgubljene prodaje

Nike je 2000. pustio u rad i2 softver za planiranje potražnje prije svog SAP ERP programa. Softver je bio jako prilagođen da radi s Nikeovim naslijeđenim sustavima, radio je sporo i rušio se pod količinom proizvoda. Naručio je previše jednih cipela, a premalo drugih. Nike je izgubio više od 100 milijuna dolara prodaje, a njegova dionica pala je oko 20 posto. Nike je kasnije premjestio kratkoročno i srednjoročno planiranje u SAP.

Pouka: nikad ne pretpostavljajte da integracija radi dok nije radila pri produkcijskom volumenu sa stvarnim podacima.

Procjena izgrađena na pretpostavkama gora je od nikakve jer stvara lažno povjerenje. Važno je šest ulaza:

1. Dokumentacija opsega: povelja, odobreni opseg i potpisani zahtjevi. Ako ne postoje, rizik opsega već je visok.
2. Obveze resursa: pisane obveze voditelja odjela, matrica vještina za kritične uloge i imenovana zamjena za svaku ključnu poziciju.
3. Proračun i vremenski plan: odobreni proračun s pričuvom i vremenski plan provjeren prema usporedivim programima. Šest mjeseci i minimalno financiranje za puni rollout rizik je koji treba istaknuti odmah.
4. Obveze dobavljača: ugovori s razinama usluge i kaznama. Na RISE-u, odgovornosti SAP-a i put eskalacije.
5. Tehnički krajolik: kompatibilnost naslijeđenih sustava, složenost migracije podataka, model isporuke i plan Clean Core za sav prilagođeni rad.
6. Zapisnici prošlih projekata: registri rizika, zapisnici problema i analize nakon završetka (post-mortem) iz ranijih SAP ili ERP programa. Većina rizika nije nova.

Ocijenite svaki rizik prema vjerojatnosti i utjecaju od 1 do 5 i pomnožite. Primjer niže tipično je polazište za S/4HANA program; Vaše će se ocjene razlikovati.

Rizik	Vjerojatnost (1-5)	Utjecaj (1-5)	Ocjena	Prioritet
Neuspjeh migracije podataka	4	5	20	Visok
Kašnjenja integracije	4	4	16	Visok
Ograničenja resursa	4	4	16	Visok
Prekoračenje proračuna	3	5	15	Srednji
Prilagođeni kod u jezgri koji blokira nadogradnje	3	5	15	Srednji
Klizanje opsega	4	3	12	Srednji
Praznine u pokrivenosti testiranja	3	4	12	Srednji
Performanse pod vršnim opterećenjem	3	4	12	Srednji
Praznine u usklađenosti	2	5	10	Srednji
Nema puta eskalacije prema SAP-u (RISE)	2	5	10	Srednji
Slabo usvajanje od strane korisnika	3	3	9	Srednji
Izloženost troškovima pretplate ili licenci	2	4	8	Srednji
KPI-jevi se ne prate	3	2	6	Nizak

Ocjene od 16 naviše trebaju imenovanog vlasnika i akciju odmah. Ocjene od 8 do 15 trebaju praćenje s definiranim okidačem eskalacije. Ispod 8 zadržite ga u registru bez trošenja prioritetnog vremena na njega. Ocjene su polazište, a ne presuda: praznina u usklađenosti ocijenjena s 10 u reguliranoj industriji može postati 25.

Sama ocjena ne mijenja ništa. Svaki rizik treba ova polja, popunjena.

Polje	Što napisati	Primjer
Rizik	Događaj, u jednoj rečenici	Matični podaci dobavljača nisu očišćeni prije probnog učitavanja 2
Vlasnik	Jedna imenovana osoba	Voditelj obveza prema dobavljačima
Ocjena	Vjerojatnost × utjecaj	4 × 5 = 20
Okidač	Mjerljiva točka u kojoj djelujete	Stopa duplikata iznad 5 posto u izvatku iz probnog učitavanja 1
Odgovor	Izbjeći, ublažiti, prenijeti ili prihvatiti, s akcijom	Ublažiti: dva analitičara obveza prema dobavljačima na čišćenju tri tjedna
Sljedeći pregled	Datum	Pregled rizika sljedećeg ponedjeljka
Status	Otvoreno, u akciji, zatvoreno	U akciji

Gdje možete, iskažite trošak u stvarnim iznosima. „Visok rizik” je nejasno. „Tjedan dana kašnjenja UAT-a košta oko šesteroznamenkasti iznos u vremenu tima i može pomaknuti puštanje u rad za tri tjedna” privlači pažnju.

Prilagođeni kod je zasebna kategorija rizika. Na S/4HANA Cloud Public Edition prilagođeni kod u jezgri nije moguć. Proširenja idu preko SAP BTP-a, objavljenih API-ja ili alata za ključne korisnike (key-user). Na privatnom cloudu i on-premise još uvijek možete mijenjati jezgru, a partneri koji su na to navikli hoće. Taj tehnički dug izlazi na vidjelo pri prvoj većoj nadogradnji. Pratite koliko identificiranih prilagodbi ima dogovoren pristup Clean Core, provjerite partnerovo iskustvo s BTP proširenjima i do kraja faze Explore uspostavite forum za pregled.

RISE mijenja tko je vlasnik raspoloživosti. SAP vodi infrastrukturu pa se rizik pomiče s „naš tim je vlasnik raspoloživosti” na „SAP je vlasnik, a nama treba brz put do njih kada nešto zakaže”. Zabilježite SAP-ove imenovane kontakte, put eskalacije i razine usluge te plan postupanja u incidentima dogovoren prije puštanja u rad. Bez toga problemi koji bi trebali ići SAP-u predugo stoje unutar projektnog tima.

AI pomaže s papirologijom, ne s prosudbom. Asistenti temeljeni na asistentu Joule u SAP Cloud ALM i alati poput Microsoft Copilot mogu sastaviti nacrte stavki registra i paketa za upravljački odbor iz statusnih izvještaja, evidencija grešaka i zapisnika sastanaka. To ubrzava održavanje registra na programima s čistim izvornim podacima. Pronalazi rizike koji su već vidljivi u podacima. Ne odlučuje koji rizici zaslužuju akciju, ne tjera vlasnike na djelovanje i ne eskalira rizike koje bi rukovodstvo radije ignoriralo.

1. Identificirajte rizike u svih pet kategorija. Provedite radionice s IT-jem, poslovanjem i dobavljačima; svaki vidi različite rizike. Na RISE-u uključite SAP-ove kontakte u barem jednu. Rizici koje timovi obično propuste: IT i poslovanje očekuju različite stvari, slabo definirane vanjske integracije, vlasnici UAT-a koji nisu dostupni i neformalne promjene opsega.
2. Ocijenite svaki rizik prema vjerojatnosti i utjecaju, sa stvarnim brojevima gdje je moguće.
3. Dodijelite jednog vlasnika po riziku. Osobu, a ne tim. Nema vlasnika, nema praćenja, nema rješenja.
4. Definirajte odgovor prije nego što rizik nastupi. Izbjeći, ublažiti, prenijeti ili prihvatiti. „Pratiti i reagirati” nije plan. To je odgođena odluka.
5. Pregledavajte tjedno. Provjerite otvorene rizike, dodajte nove, ponovno ocijenite gdje su se uvjeti promijenili i eskalirajte sve blizu okidača. Najvažnije rizike iznesite pred upravljački odbor s predloženom odlukom, a ne bojom.

1. 01IdentificirajteSvih pet kategorija
2. 02OcijeniteVjerojatnost × utjecaj, 1 do 5
3. 03Dodijelite vlasnikaJedna osoba, ne tim
4. 04Definirajte odgovorIzbjeći, ublažiti, prenijeti ili prihvatiti
5. 05Pregledajte tjednoPonovno ocijenite, eskalirajte blizu okidača

16 ili više: imenovani vlasnik i akcija ovaj tjedan

Što je procjena rizika u SAP projektu?

To je proces prepoznavanja što bi moglo poći po zlu, ocjenjivanja svakog rizika prema vjerojatnosti i utjecaju, dodjele vlasnika svakom i dogovaranja odgovora prije nego što se dogodi. SAP programi istodobno vode nekoliko modula, integracija, migraciju podataka, program promjena i fiksno puštanje u rad pa neformalno upravljanje rizicima ne drži. Kratak popis stvarnih rizika s vlasnicima bolji je od dugog dokumenta koji nitko ne čita.

Kako izraditi matricu rizika za SAP projekt?

Popišite rizike kroz opseg, resurse, tehničko područje, vremenski plan i usvajanje, uz Clean Core i SAP eskalaciju na RISE-u. Ocijenite svaki prema vjerojatnosti i utjecaju od 1 do 5 i pomnožite. Rizike od 16 naviše smatrajte visokima, od 8 do 15 srednjima, a ispod 8 niskima. Svakom srednjem i visokom riziku dajte vlasnika i mjerljiv okidač, poput „ako je dovršenost UAT-a ispod 80 posto do tjedna 16, datum puštanja u rad ide na pregled”. Ponovno ocjenjujte tjedno i na svakoj kontrolnoj točki faze.

Koji su najčešći rizici u SAP implementacijama?

Neuspjeh migracije podataka, jer su naslijeđeni podaci gotovo uvijek neurednije nego što je procijenjeno. Kašnjenja integracije, osobito s nedokumentiranim naslijeđenim sučeljima i dobavljačima trećih strana. Klizanje opsega koje sabija testiranje i obuku. Ograničenja resursa, poput ključnih ljudi koji se povlače ili korisnika nedostupnih tijekom UAT-a pri mjesečnom zatvaranju. Slabo usvajanje zbog obuke koja demonstrira ekrane umjesto da simulira posao. Na RISE-u dodajte prilagođeni kod u jezgri i nepostojanje puta eskalacije prema SAP-u.

Kada tijekom SAP projekta treba provesti procjenu rizika?

Prije početka projekta, kada su strukturni rizici poput nepodudarnosti podatkovnog modela ili nerealnih rokova najjeftiniji za ispravljanje. Prije svake kontrolne točke faze SAP Activate, jer svaka faza mijenja profil rizika. Kad god se promijene opseg, proračun ili resursi. I kada se rizik pretvori u problem, kako bi se provjerilo na što još utječe. U međuvremenu pregledavajte tjedno.

Tko u SAP programu treba biti vlasnik rizika?

Osoba koja može djelovati po njima. Voditelj podataka vlasnik je rizika migracije podataka, tehnički arhitekt rizika integracije, voditelj promjena rizika usvajanja, a arhitekt rješenja rizika Clean Core. Na RISE-u CIO ili direktor programa vlasnik je puta eskalacije prema SAP-u. Voditelj programa prati zdravlje registra, ali nije vlasnik svakog rizika.

Što se događa kada se procjena rizika ERP-a preskoči?

U velikom opsegu dobijete slučajeve poput Lidla, koji je 2018. odustao od svog SAP maloprodajnog projekta nakon oko 500 milijuna eura. Ili HP-a, čija je migracija SAP sustava narudžbi 2004. koštala njegovu grupu za poslužitelje oko 400 milijuna dolara prihoda. U manjem opsegu mehanizam je isti: nepodudarnosti podatkovnog modela otkrivene kasno, integracije koje pucaju pri produkcijskom volumenu i neuspjesi usvajanja zbog slabe obuke. Rizici su se mogli identificirati prije nego što su postali problemi.