Oporavak SAP projekta: spašavanje programa koji je skrenuo s kursa

Oporavak SAP projekta znači zaustaviti migraciju ili implementaciju koja je skrenula s kursa, utvrditi što je o njoj stvarno istina i iznova planirati na temelju te istine. Prvi tjedan odlučuje hoće li uspjeti: procijenite status programa, pregledajte dizajn i procijenite ono što je stvarno uvedeno u sustav.

Kratki odgovor: ako se te tri provjere slažu međusobno i s planom, programu treba poticaj, a ne spašavanje. Ako se ne slažu, nikakav dodatni trud na trenutačnom planu to neće popraviti i treba Vam formalni oporavak s novom polaznom vrijednošću.

Ovaj se članak bavi tom dijagnozom i onim što slijedi. Krak je mog vodiča za migraciju s ECC-a na S/4HANA, koji pokriva putove, trajanje i rokove. Ovdje je pitanje uže: Vaš je program u problemima, pa što sada?

Većini programa koji kasne ne treba spašavanje. Treba im brže donošenje odluka, oslobođen ključni korisnik ili dobavljač kojeg se drži za datum. To je poticaj.

Spašavanje je nešto drugo. Znakovi dolaze iz istih triju provjera koje provodim u prvom tjednu, a signal je jednostavan: status, dizajn i ono što je uvedeno ne slažu se međusobno ni s planom.

Neki obrasci koje bih tretirao kao signale za spašavanje:

1. Status je zelen, sustav nije. Izvještaji kažu da je većina izrade gotova, ali testni sustav ne može provesti osnovni order-to-cash.
2. Dizajn je potpisan, izrada ga ignorira. Konfiguracija je rađena prema bilješkama s radionica, a ne prema odobrenom dizajnu.
3. Plan ima datum go-livea, ali nitko ne zna objasniti put do njega. Testiranje, učitavanja podataka i probe cutovera nemaju realan termin.
4. Opseg samo raste. WRICEF popis (izvještaji, sučelja, konverzije, proširenja, obrasci i workflowi) i dalje raste dugo nakon faze Explore.

Svaki od ovih može se popraviti poticajem. Dva ili više istodobno obično ne mogu.

Prvi tjedan služi tome da se utvrdi što je istina. Ne za popravljanje, ne za okrivljavanje i ne za pisanje novog plana. Procjenjujem tri stvari, ovim redoslijedom: status, dizajn i ono što je stvarno uvedeno.

Ovo svaka provjera pokriva i ovo Vam govori neslaganje:

Provjera	Što promatram	Na koje pitanje odgovara	Ako se ne slaže s ostalima
Status programa	Plan, izvještaji o statusu, RAID log, otvoreni zahtjevi za promjenu, potrošnja u odnosu na proračun	Što program vjeruje o sebi?	Izvještavanje je optimistično ili odvojeno od isporuke
Dizajn	Dizajn poslovnih procesa, rezultati Fit-to-Standarda, WRICEF popis, otvorene dizajnerske odluke	Što je poslovanju obećano?	Izrada je odlutala od dogovorenog ili dizajn nikada nije dovršen
Ono što je uvedeno	Razvojni i testni sustavi, konfiguracija, transporti, prilagođeni kod, dosadašnja učitavanja podataka	Što danas stvarno postoji?	Napredak je prijavljen za posao koji nije u sustavu

Treću provjeru većina pregleda preskače. Ona znači sjesti pred sustav i provoditi procese, a ne čitati dokumente o sustavu.

Izvještaji o statusu i dizajnerski dokumenti tvrdnje su. Sustav je dokaz.

Tko bi trebao provoditi provjere

Ljudi koji su pisali izvještaje o statusu ne bi trebali biti ljudi koji ih provjeravaju. To nije optužba. Isti je razlog zbog kojeg revizori ne revidiraju vlastiti rad.

Za prvi tjedan postavio bih nekoga neovisnog o partneru za implementaciju, s punim pristupom sustavima i pravom da razgovara sa svima na programu. Ako to nije moguće, barem neka Vam partner pokaže uvedeni sustav uživo, a ne na slajdovima.

Godine 2018. radio sam na oporavku jednog zrakoplovnog programa. Moduli su bili uvedeni, ali ništa nije bilo konfigurirano na temelju poslovnih zahtjeva.

To je upravo situacija koju tri provjere iz prvog tjedna trebaju razotkriti. Uvedeni moduli nisu isto što i funkcionalan dizajn, a razliku pokazuje samo pogled unutar sustava.

Zrakoplovne tvrtke usko povezuju održavanje, nabavu i financije, pa se jaz u jednom području širi. Kako se SAP uklapa u tu industriju, pokrivam na svojoj stranici o SAP-u za zrakoplovstvo.

U 21 SAP programu koje sam vodio ili spašavao, najveća pogreška koju vidim jest to što se na početku implementacije ne planira kako treba. Spašavanje je često upravo to propušteno planiranje, obavljeno kasno i pod pritiskom.

Dva druga uzroka ponavljaju se iznova:

1. Dobavljač kontrolira opseg. Kada sistemski integrator piše opseg, on opisuje ono što integrator planira isporučiti. Praznine stižu kasnije kao zahtjevi za promjenu, koje cijeni isti dobavljač.
2. Prilagođeni kod probija rokove. Prema mom iskustvu prilagođeni kod je faza migracije koja najčešće probija rokove, a ujedno i skriveni trošak koji se najčešće zaboravi.

Proračunska strana ovoga, uključujući to zašto troškovi skaču upravo u fazi Explore, obrađena je u mom članku o tome zašto SAP projekti premašuju proračun. Ovdje to neću ponavljati.

Slaba kontrola druga je česta nit. Ako program nikada nije imao tjedni ritam praćenja, eskalacije i kontrole promjena, spašavanje ga mora uspostaviti. Moj vodič za planiranje i kontrolu SAP projekata postavlja taj ritam s vlasnicima.

Kada znate što je istina, oporavak ima jasan slijed. Preskakanje koraka obično znači da spašavanje radite dvaput.

Slijed oporavka SAP programa

1. 01

   Dijagnoza

   Status, dizajn i ono što je uvedeno, provjereni jedno prema drugome.

2. 02

   Vraćanje opsega

   Opseg u vlasništvu klijenta, zamrznut, sa svakom promjenom procijenjenom.

3. 03

   Nova polazna vrijednost

   Jedan novi plan izgrađen na dokazima, s rezervom na Vašoj strani.

4. 04

   Kontrolne točke faza

   Kontrolna točka kvalitete na kraju svake preostale faze.

5. 05

   Proba i cutover

   Pune probe prije nego što se potvrdi datum go-livea.

1. Vratite vlasništvo nad opsegom

Prije nego što itko iznova planira, odlučite tko je vlasnik opsega. Ako je odgovor i dalje dobavljač, novi plan propast će na isti način kao i stari.

Napišite opseg na strani klijenta, usporedite ga s onim što je uvedeno i zamrznite ga. Od tada je svaka promjena procijenjena odluka s vlasnikom.

2. Novu polaznu vrijednost postavite jednom, na temelju dokaza

Oporavak dobiva jednu novu polaznu vrijednost, a ne niz malih pomaka. Izgradite je iz onoga što sustav pokazuje, a ne iz onoga čemu se stari plan nadao.

Najprije iznova procijenite prilagođeni kod, jer odande prekoračenja najčešće dolaze. Zatim podatke, budući da migracija podataka odnosi 30 do 40 posto napora i obično kasni u programu s problemima.

Držite 10 do 20 posto rezerve na svojoj strani, koja se oslobađa samo za imenovane rizike. Moj srodni članak o troškovima migracije na S/4HANA objašnjava što određuje brojke.

3. Stavite kontrolnu točku kvalitete na kraj svake faze

Programi u problemima obično su iz faze u fazu prelazili prema datumima, a ne prema dokazima. Ispravite to.

U SAP Activateu faza Explore provodi Fit-to-Standard radionice, a odobreni delta zahtjevi ulaze u product backlog za fazu Realize. Ako je program izašao iz faze Explore bez dovršenog dizajna, vratite se i dovršite ga. SAP Cloud ALM podržava kontrolne točke kvalitete kao provjere s kontrolnim popisima, prikazane u pregledu projekta, pa kontrolna točka ne mora živjeti u proračunskoj tablici.

4. Provedite probe prije nego što se obvežete na datum

Na brownfield konverziji planiram tri probne konverzije prije cutovera. Programi u problemima često skraćuju probe kako bi uštedjeli vrijeme, čime se rizik premješta na go-live vikend.

Zastoj pri cutoveru koji sam vidio kreće se od jednog vikenda do tjedan dana. Spašeni program trebao bi svoju brojku znati iz probe, a ne iz procjene.

5. Provjerite rok prema kojem zaista radite

Za SAP ERP 6.0 na enhancement packageima 6 do 8 redovno održavanje završava 31. prosinca 2027., uz neobavezno produljeno održavanje do kraja 2030. uz premiju od dva postotna boda (SAP News). Oporavak koji migraciju s ECC-a gura iza 2027. trebao bi otvoreno predvidjeti produljeno održavanje u proračunu.

Ne dopustite da datum iz 2027. iznudi go-live koji probe ne podupiru. Kasni go-live stoji naknada za održavanje. Neuspjeli stoji daleko više.

Spašavanje često otvara pitanje treba li zadržati trenutačnog sistemskog integratora. Ponekad je zamjena partnera ispravna. Često je veći problem način na koji je program postavljen, a novi ga partner nasljeđuje.

Ovo su pitanja koja bih postavio prije odluke:

1. Možete li nam pokazati uvedeni sustav, uživo, u odnosu na potpisani dizajn? Ne demo okruženje i ne slajdove.
2. Koji su WRICEF objekti izrađeni, testirani i transportirani, a koji su samo prijavljeni kao gotovi?
3. Koji je Vaš dizajn na visokoj razini za dovršetak i koje reference možemo nazvati gdje ste oporavili program sličan našem? Reference i dizajn na visokoj razini dvije su stvari koje tražim od svakog partnera prije potpisivanja.
4. Što Vam od nas treba, a ne dobivate? Odluke koje nedostaju i ključni korisnici na pola radnog vremena često su pola priče.
5. Za korisnike RISE with SAP: koji su problemi na SAP-u, a ne na partneru, i tko ih eskalira?

Znak upozorenja isti je onaj zbog kojeg pri odabiru odustajem od partnera: generički odgovori. Ako bi plan oporavka vrijedio za bilo koju tvrtku, nije napisan za Vašu. Moj vodič o tome kako odabrati partnera za migraciju na S/4HANA pokriva stranu odabira.

Ako program nikada nije imao pravu procjenu izvornog sustava, provedite je sada. SAP Readiness Check analizira Vaš postojeći sustav, a SAP ga preporučuje pokrenuti u produkciji radi točne slike stvarnog korištenja. Moj članak o SAP Readiness Checku i procjeni migracije objašnjava što propušta, počevši od prilagođenih objekata.

Rezervirajte pola dana sa svojim direktorom programa i SAP voditeljem i zamolite ih da Vam pokažu tri stvari jednu uz drugu: najnoviji izvještaj o statusu, potpisani dizajn i testni sustav koji provodi jedan cjelovit poslovni proces. Ako te tri stvari pričaju istu priču, potaknite program. Ako ne pričaju, pokrenite formalni oporavak prije sljedećeg sastanka upravnog odbora.

Ako želite neovisno mišljenje o programu koji je skrenuo s kursa, pomažem organizacijama upravo u ovakvoj dijagnozi. Možete dogovoriti razgovor sa mnom.

Što je oporavak SAP projekta?

Oporavak SAP projekta jest posao vraćanja SAP implementacije ili migracije koja je skrenula s kursa pod kontrolu. Počinje dijagnozom statusa programa, dizajna i onoga što je stvarno uvedeno, zatim vraća vlasništvo nad opsegom, postavlja jednu novu polaznu vrijednost i dodaje kontrolne točke kvalitete preostalim fazama.

Kako znati treba li mom SAP projektu spašavanje?

Usporedite tri stvari: što kažu izvještaji o statusu, što kaže potpisani dizajn i što je stvarno uvedeno u sustav. Ako se slažu međusobno i s planom, programu treba poticaj. Ako se ne slažu, više truda na trenutačnom planu to neće popraviti i treba Vam formalni oporavak.

Što bi se trebalo dogoditi u prvom tjednu oporavka SAP implementacije?

Samo dijagnoza. Procijenite status programa, pregledajte dizajn i procijenite ono što je stvarno uvedeno, idealno pod vodstvom nekoga neovisnog o partneru za implementaciju. Ne pišite novi plan dok te tri provjere nisu gotove.

Trebamo li zamijeniti partnera za SAP implementaciju tijekom oporavka?

Ne automatski. Zatražite od partnera da pokaže uvedeni sustav u odnosu na potpisani dizajn i da Vam da dizajn na visokoj razini za dovršetak, s referencama iz sličnih oporavaka.

Ako su odgovori generički, to je snažan signal za promjenu. Ako je pravi problem vlasništvo nad opsegom ili odluke koje nedostaju na Vašoj strani, novi partner će ga naslijediti.

Zašto migracije na SAP S/4HANA skrenu s kursa?

Najčešći temeljni uzrok koji vidim jest to što se na početku implementacije ne planira kako treba. Drugi je prepuštanje kontrole nad opsegom dobavljaču, a prilagođeni kod je faza koja najčešće probija rokove. Migracija podataka, s 30 do 40 posto napora, obično također kasni.

Hoće li oporavak pogurati našu migraciju s ECC-a iza roka 2027.?

Moguće. Redovno održavanje za SAP ERP 6.0 na enhancement packageima 6 do 8 završava 31. prosinca 2027., a neobavezno produljeno održavanje traje do kraja 2030. uz premiju od dva boda. U proračunu predvidite produljeno održavanje umjesto da iznuđujete go-live koji Vaše probe ne podupiru.