Kako izbjeći klizanje opsega u implementaciji SAP-a

Klizanje opsega u implementaciji SAP-a izbjegavate tako da svaku promjenu učinite vidljivom i skupom za odobrenje. Zapišite što nije u opsegu jednako pažljivo kao i što jest. Svaki zahtjev provedite kroz kontrolu promjena uz procjenu utjecaja na vrijeme, trošak i kvalitetu. Tražite kompromis za svaki dodatak. Odredite datum zamrzavanja opsega uz potporu rukovodstva i istu disciplinu unesite u ugovor sa SI-jem. Ovaj je vodič za direktore programa, sponzore i PMO-ove na S/4HANA programima. Tablicu troška promjene i ugovorne klauzule u nastavku iskoristite u sljedećem paketu za upravljački odbor.

Većina SAP projekata premašuje proračun i rokove, a klizanje opsega najčešći je razlog. Radio sam s desecima poduzeća čiji su SAP projekti izmakli kontroli, a tri se signala pojavljuju prije nego što prekoračenje stigne u izvještaj upravljačkom odboru. Male promjene se gomilaju bez procjene utjecaja. Kontrola promjena radi na osobnim odnosima umjesto na dokumentiranoj ovlasti. A sponzor uz kavu odobrava stvari za koje projektni tim čuje tjedan dana kasnije.

Jedan farmaceutski klijent krenuo je s jasnim rokom od 18 mjeseci. Tri godine kasnije još je implementirao, a troškovi su se udvostručili. CIO jedne proizvodne tvrtke rekao mi je da je njegov tim odbacio cijele module koje je mjesecima konfigurirao jer su se zahtjevi stalno mijenjali. Opseg je narastao toliko da nitko nije prepoznavao izvorni plan.

To nisu rubni slučajevi. To je najčešći način na koji SAP programi propadaju.

Počinje nedužno. Poslovni voditelj traži „samo jednu malu promjenu“. Pa još jednu. Fraza „kad smo već tu, samo...“ izbacila je iz kolosijeka više SAP implementacija od bilo kojeg tehničkog izazova.

Radio sam s maloprodajnim klijentom kod kojeg smo krenuli čisto: osnovne financije i osnovno upravljanje materijalima. Šest mjeseci kasnije CMO je želio analitiku kupaca. Zatim je COO trebao napredne funkcije skladišta. Izvorni devetomjesečni rok bio je ugrožen. Odbio sam oba zahtjeva. Ta je disciplina posao.

Nije svaka promjena klizanje opsega. Ponekad otkrijete kritične praznine u dizajnu koje nitko nije predvidio. Ponekad se propisi promijene usred projekta. To je opravdano i slijedi proces s prilagodbom roka i proračuna. Klizanje opsega jednostavno se pojavi, obično nakon razgovora na hodniku.

Jedan proizvodni klijent krenuo je s 10 prilagođenih izvještaja i završio s 47, a svaki je dodavao vrijeme dizajna, izgradnje i testiranja. Samo je tijek izvještavanja prekoračio proračun za 200 %.

200 %

prekoračenje proračuna tijeka izvještavanja nakon što je klizanje opsega povećalo broj prilagođenih izvještaja s 10 na 47

Izvor: Program proizvodnog klijenta

Znakovi upozorenja

Ovo su znakovi koje pratim i odgovor na svaki:

Znak upozorenja	Temeljni uzrok	Odgovor
„Samo još jedna stvar“ postaje svakodnevni jezik	Nejasne granice opsega	Ponovno postavite polaznu osnovu s poslovnim voditeljima; provedite formalnu kontrolu promjena
Poslovni voditelji neformalno dodaju značajke	Nerazumijevanje utjecaja na ostale dijelove sustava	Svaki zahtjev provedite kroz procjenu utjecaja; pokažite trošak
Rok se produljuje bez formalnog preplaniranja	Tiho širenje opsega	Održavajte kontrolne točke opsega; preplanirajte uz odobrenje odbora za promjene
Dokumentacija više ne odgovara onome što je izgrađeno	Neformalno rukovanje opsegom, nema verzioniranja	Ažurirajte specifikacije i planove uz svaku odobrenu promjenu
Potrošnja proračuna brža od napretka	Skriveni napor iz nedokumentiranih promjena	Pratite napor prema radnim paketima; istražite odstupanja
Tim radi noću i vikendom da nadoknadi	Opseg premašuje kapacitet	Eskalirajte odboru za promjene; iznudite odluku o opsegu
Prebacivanje krivnje između poslovanja, IT-a i partnera	Opseg je već izmakao kontroli	Zamrznite opseg, provedite analizu uzroka, ponovno postavite polaznu osnovu

Sve je povezano

SAP povezuje sve. Financije utječu na opskrbni lanac. Ljudski resursi dotiču platni obračun. Prodaja je povezana sa zalihama. Jedna promjena može pokvariti deset stvari.

Jedan je klijent dodao jedno polje u proces narudžbenice. Izgledalo je trivijalno. Pokvarilo je tri sučelja i zahtijevalo prepravljanje izvještaja po odjelima. Drugi je klijent zatražio „sitnu promjenu“ postupka određivanja cijena, što je zahtijevalo ponovnu konfiguraciju cijele strukture cijena: tri tjedna rada i 40.000 USD naknada za savjetovanje, za sitnu promjenu.

Pritisak jednom u desetljeću

Većina tvrtki implementira SAP jednom u 10 do 15 godina. Svaki odjel zna da sljedeću priliku neće dobiti desetljeće. Nitko ne želi čuti „faza 2“, što u većini organizacija znači nikad. Zato se sve gura u tekući projekt, a popis opsega postaje popis želja.

Što mijenja clean core

Clean core stavlja tehničku kočnicu na prilagodbe. Na S/4HANA Cloud Public Edition mijenjanje jezgre nije moguće: ekstenzije idu preko objavljenih API-ja, on-stack ili side-by-side na SAP BTP-u. Na Private Edition i on-premise izmjena je i dalje moguća, ali je SAP-ove smjernice smatraju krajnjim rješenjem jer svaka dodaje posao oko nadogradnje.

Korisna nuspojava je disciplina opsega. Zahtjev „samo dodaj ovaj korak odobrenja u standardni proces od narudžbe do naplate“ prestaje biti usputni razgovor o konfiguraciji i postaje ekstenzija s vlastitim troškom dizajna, izgradnje i testiranja. Postavite forum za pregled ekstenzija ispod upravljačkog odbora, s jednim arhitektom koji može odobriti ili odbiti, i mnogi od tih zahtjeva stat će prije nego što uđu u polaznu osnovu. On-premise programi bez tog foruma vraćaju se starim obrascima. Moj vodič za clean core objašnjava kako ga postaviti.

1. Definirajte opseg s izričitim isključenjima. Dokumentirajte što nije u opsegu jednako pažljivo kao što jest i ishodite potpis na oboje. Dvosmislenost je mjesto gdje počinju svađe.
2. Provodite formalnu kontrolu promjena s posljedicama. Svaka promjena treba procjenu utjecaja na trošak, vrijeme i kvalitetu, vidljivu onome tko odobrava.
3. Komunicirajte granice opsega na svakom sastanku upravljačkog odbora. Prikažite stanje opsega jednostavnim crveno-žuto-zelenim prikazom. Veliki dio klizanja je nesporazum.
4. Napišite plan upravljanja opsegom. Odredite kako se promjene procjenjuju, odobravaju, eskaliraju i prate, da ih svaki tijek rada rješava na isti način. Moj predložak opsega SAP projekta daje početnu strukturu.
5. Prioritizirajte prema MoSCoW. Must have (obvezno), Should have (poželjno), Could have (moguće), Won't have this time (ovaj put ne). Čvrsto se borite da popis Must have ostane kratak.
6. Verzionirajte svaku odluku. Svaka odobrena promjena ažurira polaznu osnovu. Svaka odbijena promjena bilježi se s razlogom.
7. Zahtijevajte kompromise. Ako uđe novi zahtjev, nešto drugo izlazi. Obvezni zahtjevi brzo postanu neobvezni kad nešto koštaju.

Tri tehnike koje sam koristio čine da se ovo drži.

Disciplina potpisa. Neka poslovni voditelji potpisuju odobrene zahtjeve. Na jednom je programu poslovni voditelj tvrdio da nikad nije odobrio određeni tijek procesa. Izvukli smo dokument s njegovim potpisom i rasprava je završila. Potpis nije birokracija. On sprječava da se ista rasprava ponovno pokrene šest mjeseci kasnije.

Pokažite posljedice koje se šire. Klijentu sam izradio demonstraciju koja pokazuje kako bi promjena jednog polja na prodajnom nalogu utjecala na 14 područja, od izvještavanja preko sučelja do sigurnosnih uloga. Ponašanje se promijenilo. Edukacija košta sate. Nerazumijevanje posljedica koje se šire košta mjesece.

Pokažite trošak promjene. Promjena tijekom dizajna može koštati 5.000 USD. Ista promjena tijekom testiranja može koštati 50.000 USD. Stavite ljudima pred oči jednostavan grafikon toga i usputni zahtjevi se uspore.

Ovo su okvirni rasponi troška promjene za S/4HANA programe na američkom tržištu. Variraju prema složenosti i partneru. Koristite ih kao sidra, a ne kao ponude.

Faza	Tipičan trošak male promjene	Tipičan trošak srednje promjene
Explore (dizajn)	2 tis. do 10 tis. USD	10 tis. do 30 tis. USD
Rani Realize	5 tis. do 20 tis. USD	20 tis. do 80 tis. USD
Sredina Realize (izgradnja)	15 tis. do 50 tis. USD	50 tis. do 200 tis. USD
Kasni Realize (testiranje)	30 tis. do 100 tis. USD	100 tis. do 400 tis. USD
Deploy i cutover	80 tis. do 300 tis. USD	300 tis. do 1 mil.+ USD
Hypercare (nakon puštanja u rad)	150 tis. do 500 tis. USD	500 tis. do 2 mil.+ USD

Obrazac odgovara onome što istraživanja nalaze desetljećima. NASA-ina studija eskalacije troška pogrešaka utvrdila je da je pogreška u zahtjevima uhvaćena u integraciji i testiranju koštala 21 do 78 puta više za popravak nego ona uhvaćena tijekom zahtjeva, a daleko više nakon što je sustav bio u radu. Upravljanje opsegom postoji da promjene zadrži na jeftinoj strani te krivulje.

Ugovorne klauzule koje su važne

Nejasni ugovori stvaraju skupe probleme. Vidio sam klijenta koji je potpisao ugovor u kojem je pisalo samo „implementirati S/4HANA“. Partner je kasnije tvrdio da su određeni procesi dodaci koji zahtijevaju dodatne naknade, i klijent je na kraju platio dvostruko. Ove klauzule to sprječavaju:

Klauzula	Svrha
Opseg s izričitim isključenjima	Ograničava što pokriva fiksna cijena i uklanja dvosmislenost oko dodataka
Unaprijed dogovorene stope za uobičajene promjene	Zaključava cijene izvještaja, sučelja i promjena konfiguracije prije nego što stigne pritisak
Kontinuitet konzultanata	Sprječava da novi konzultanti ponovno otvaraju riješene odluke i šire opseg
Ovlast odobravanja na objema stranama	Sprječava da mlađi konzultanti obećavaju značajke koje nitko nije odobrio
Naplata prema prekretnicama	Veže plaćanje uz potpisane isporuke, a ne uz proteklo vrijeme
Kriteriji prihvaćanja po isporuci	Definira „gotovo“ prije nego što se itko počne prepirati
Klauzula o clean core ekstenzijama	Zahtijeva da ekstenzije koriste objavljene API-je ili SAP BTP; štedi prepravljanje pri prvoj većoj nadogradnji

Moje bilješke o pregovaranju o ERP ugovoru pokrivaju kako postići dogovor o tim klauzulama.

Odbor za kontrolu promjena

Odbor za promjene radi kad ima prave ljude. Svoj sastavljam od tri uloge: poslovni donositelj odluka kojemu je stalo do funkcije, voditelj projekta kojemu je stalo do roka i financijski voditelj kojemu je stalo do proračuna. Ta ravnoteža sprječava da jedan prioritet dominira.

1. 01Zahtjev podnesenPisano, ne uz kavu
2. 02Procjena utjecajaVrijeme, trošak i kvaliteta, prije nego što itko odobri
3. 03Kompromis imenovanNešto drugo izlazi da bi se napravilo mjesta
4. 04Odbor za promjene odlučujePoslovanje, projekt i financije za stolom
5. 05Polazna osnova ažuriranaOdbijene promjene zabilježene s razlogom

Opseg se mijenja samo kroz odbor

Odbor treba stvarnu ovlast. Na jednom programu nijedna promjena opsega nije prošla bez njegova odobrenja. Nijedna. Dogovori na hodniku prestali su. Kad je voditelj prodaje pokušao ubaciti nove zahtjeve, tim je imao dokumentiranu matricu odobravanja na koju je mogao uputiti.

Većina odluka treba ostati na razini odbora. Samo stvarni sporovi idu sponzoru, što sponzora drži uključenim, a da ga se ne zatrpa. Svaka dva tjedna održite pregled opsega s voditeljima tijekova rada i izvještavajte o podnesenim, odobrenim i odbijenim zahtjevima. Kad ljudi u statusnom izvještaju vide „15 % rasta opsega ovaj mjesec“, ponašanje se mijenja.

Neke su promjene nužne. Jedan farmaceutski klijent bio je pogođen novim propisima FDA usred implementacije. Morali su ući. To nije klizanje opsega. To je stvarnost.

Kad stigne opravdana promjena, postavite dva pitanja. Koje je najmanje rješenje koje će funkcionirati? I onome tko traži: što ste spremni ukloniti da napravite mjesta? Hitnost brzo opada kad zahtjev nešto košta.

Opcije su produljiti rok, dodati proračun, izrezati druge zahtjeve, dodati ljude ili kombinaciju. Što god odaberete, dokumentirajte i istodobno ažurirajte sve dokumente polazne osnove. Zastarjeli dokumenti stvaraju sljedeći krug problema s opsegom.

AI sada pomaže s papirologijom. Asistenti poput Microsoft Copilota sažimaju duge niti zahtjeva za promjenu u sažetak spreman za odluku odbora, a SAP Cloud ALM drži zahtjeve, promjene i testove povezanima pa je utjecaj promjene lakše pratiti. AI može pokazati da promjena dotiče 14 područja. Ne može reći COO-u da njezin zahtjev znači da se zahtjev CFO-a neće ostvariti. Taj je razgovor i dalje Vaš.

Proizvodna tvrtka s kojom sam radio završila je svoj SAP projekt na vrijeme, što je rjeđe nego što bi trebalo biti. Rano je odredila datum zamrzavanja opsega, a svaka promjena nakon njega trebala je osobno odobrenje CEO-a. Projekt je završio uz preostali proračun i nitko nije radio vikendom pri puštanju u rad.

Drugi je klijent koristio sustav žetona: svaki je odjel dobio tri žetona za promjene za cijeli projekt. Želite promjenu? Potrošite žeton. Ljudi su dobro razmislili što je važno, a „obvezni zahtjevi“ su preispitani kad su počeli koštati ograničenu valutu.

Nijedan pristup nije složen. Oba traže disciplinu i potporu vodstva. Test svakog procesa upravljanja opsegom je dan kad COO uđe u projektnu sobu s „samo jednom malom promjenom“. Izgradite ga za taj dan.

Što je klizanje opsega u SAP projektu?

Postupan, nekontroliran rast zahtjeva bez odgovarajućih promjena roka, proračuna ili resursa. U SAP-u obično počinje malim dodacima: dodatni izvještaji, dodatna polja, „samo jedna brza promjena tijeka rada“. Svaki izgleda bezazleno. Zajedno dodaju mjesece.

Opravdane promjene opsega slijede proces i dolaze s prilagodbom roka i proračuna. Klizanje opsega stiže neformalno i zaobilazi kontrolu promjena.

Koji su najčešći uzroci klizanja opsega na SAP projektima?

Tri se pojavljuju dosljedno: nejasni početni zahtjevi, pa se za sve može tvrditi da je u opsegu; nema formalne kontrole promjena, pa promjene prolaze na svakoj razini; i mentalitet jednom u desetljeću, u kojem svaki odjel pokušava ovim projektom riješiti godine problema.

SAP-ova povezanost pojačava sva tri. Jedna promjena može pokvariti deset povezanih procesa, a ako poslovni voditelji ne vide te veze, utjecaj se pojavi u testiranju, kad košta višestruko više.

Kako clean core mijenja rizik klizanja opsega?

Dodaje tehničku kočnicu. Na S/4HANA Cloud Public Edition jezgra se ne može mijenjati, pa svaka praznina postaje ekstenzija s vlastitim troškom dizajna, izgradnje i testiranja. Na Private Edition i on-premise izmjena je moguća, ali dodaje posao oko nadogradnje, pa je SAP-ove smjernice ne preporučuju.

Forum za pregled ekstenzija, s jednim arhitektom koji ima ovlast odlučivanja, zaustavlja mnoge zahtjeve prije nego što uđu u polaznu osnovu. Bez tog foruma on-premise programi klize natrag u stare navike.

Koja je razlika između klizanja opsega i gold-platinga?

Klizanje opsega dolazi iz poslovanja: zahtjevi izvan dogovorenog. Gold-plating dolazi iz tima za isporuku: složenost koju nitko nije tražio.

U SAP terminima, gold-plating je konzultant koji gradi razrađenu logiku tijeka rada gdje bi dovoljno bilo jednostavno usmjeravanje. Klizanje opsega je COO koji traži napredne funkcije skladišta šest mjeseci nakon početka projekta definiranog za osnovni MM. Oba napuhuju trošak i vrijeme, i oba traže istu disciplinu.

Kako strukturirati proces kontrole promjena koji stvarno radi?

Tri elementa. Svaki zahtjev nosi procjenu utjecaja na rok, proračun i resurse. Odbor za odobravanje uključuje nekoga kome je stalo do svakog od ta tri, a ne samo poslovne voditelje, koji će odobriti sve. I svaki dodatak traži kompromis: nešto drugo izlazi.

Samo to posljednje pravilo filtrira zahtjeve koji nisu uistinu kritični.

Može li se klizanje opsega potpuno izbjeći?

Ne. Na svakom programu duljem od nekoliko mjeseci poslovni se uvjeti mijenjaju, propisi se mijenjaju i dizajn otkriva praznine.

Cilj je kontrola, a ne eliminacija. Kontrolirana promjena slijedi dokumentirani proces, procjenjuje se njezin utjecaj i ažurira polaznu osnovu. Nekontrolirana promjena zaobilazi proces i pojavljuje se u testiranju ili nakon puštanja u rad kao trošak koji nitko nije planirao.

Koji je najbolji način rukovanja zamrzavanjem opsega na dugom SAP programu?

Dajte mu posljedicu i vidljivu potporu rukovodstva. Najučinkovitija verzija koju sam koristio: datum zamrzavanja nalazi se u povelji projekta od prvog dana, proces promjena definira što „zamrzavanje“ znači u praksi, a sponzor ga javno potvrđuje na upravljačkom odboru prije nego što datum stigne.

Kad CEO mora osobno odobriti svaku promjenu nakon zamrzavanja, popis ostaje vrlo kratak.