Kako izraditi povelju projekta za implementaciju SAP-a

Povelja projekta za implementaciju SAP-a kratak je dokument koji formalno odobrava program. Pismeno utvrđuje što će program isporučiti, što neće, tko odlučuje, kako se mjeri uspjeh i do kada. Napišite je prije potpisivanja SOW-ova dobavljača, neka je posjeduje klijentov sponzor i neka bude dovoljno konkretna da riješi spor. Pregled po odjeljcima nalazi se u nastavku.

Timovi uskaču u SAP kickoff sastanke s pouzdanjem. Onda otkriju da su uloge bile nejasno definirane, granice opsega nikad dogovorene i da nitko ne zna reći kako izgleda uspjeh. Povelja bi to trebala spriječiti. Većina ne sprječava jer se piše da bi se zadovoljio zahtjev upravljanja, a ne da bi usidrila posao.

Vidio sam povelje projekta koje izgledaju uredno, ali se ne povezuju sa stvarnim planovima. Verzija koja funkcionira ona je oko koje se ljudi prepiru tijekom pisanja. Tako znate da je iskrena.

Tri se dokumenta miješaju na svakom velikom SAP programu. Rade različite poslove.

Dokument	Svrha	Izrađuje	Vrijeme
Prijedlog projekta	Opravdati zašto bi se projekt trebao dogoditi	Poslovni sponzor	Prije odobrenja
Povelja projekta	Odobriti projekt; utvrditi opseg, ciljeve, imenovane vlasnike i upravljanje	Sponzor s voditeljem programa	Pri pokretanju
Plan projekta	Definirati kako se posao obavlja: zadaci, resursi, ovisnosti	Voditelj programa	Nakon odobrenja povelje

Povelja je dokument upravljanja. Povlači crte. Ako Vaš S/4HANA program obuhvaća više modula, zemalja i dobavljača, povelja je mjesto gdje odlučujete što je uključeno prije nego što ljudi počnu stvarati vlastite pretpostavke.

Ciljevi vezani uz poslovni ishod

Ne „modernizacija sustava“. Svaki cilj treba broj. Test: možete li viziju objasniti članu uprave u 30 sekundi bez slajdova?

Radio sam na SAP programima gdje su svi slavili pri puštanju u rad, a dva mjeseca kasnije nitko nije mogao reći je li isporučena obećana vrijednost. Jedan proizvodni klijent potrošio je više od 4 milijuna USD i nije mogao dokazati nikakav povrat. Financijski direktor tražio je metrike. Nitko ih nije imao, a to je odgodilo njihov sljedeći krug financiranja.

Usporedite to s maloprodajnim klijentom kojeg sam podržavao. Njegova je povelja od prvog dana imala definirane KPI-jeve. Pokazali su pad troškova obrade narudžbi od 32 %, a faza 2 odobrena je odmah.

Opseg s izričitim isključenjima

Ovo je najviše previđen odjeljak. Timovi pišu detaljne popise onoga što je u opsegu, a izostavljaju isključenja, što je upravo mjesto gdje nastaju svađe.

Radio sam sa zdravstvenom tvrtkom koja je na ovaj način držala svoje SAP uvođenje usredotočenim. Voditelj marketinga htio je dodati analitiku za praćenje kampanja tijekom korisničkog prihvatnog testiranja (UAT). Povelja nije imala mjesta za to, a upravljački odbor to je odmah označio. Ta jedna odluka uštedjela je 850.000 USD i izbjegla kašnjenje od šest tjedana.

Imenovani ljudi, a ne odjeli

„Financijski tim: daje doprinos za izvještavanje“ nikoga ne čini odgovornim. „Voditelj financija, [ime]: definira zahtjeve za izvještavanje, potpisuje konfiguraciju FI/CO, odobrava spremnost migracije podataka“ čini.

Prekretnice kao obveze

Jedan je maloprodajni klijent odgodio puštanje u rad za četiri mjeseca. Početno kašnjenje bilo je od tri tjedna u prikupljanju zahtjeva koje nitko nije unio u raspored. Pretpostavili su da to mogu nadoknaditi kasnije. Umjesto toga potrošili su 1,8 milijuna USD prekoračenja.

Djeluje i obrnuto. U jednom proizvodnom angažmanu tim se držao objavljenog plana. Kad je tim za migraciju podataka označio kašnjenje, upravljački je odbor odmah odobrio kadrovsku potporu jer je povelja učinila prekretnicu vidljivom. Ta je odluka uštedjela i vrijeme i 600.000 USD.

Proračun, rizici i ovisnosti

Proračun na visokoj razini, tri ili četiri rizika koji mogu izbaciti program iz kolosijeka i drugi programi koji se natječu za iste ljude i novac. Jedan je maloprodajni klijent potrošio 3,2 milijuna USD na implementaciju koja nikad nije puštena u rad. Njegov redizajn financija i SAP projekt tekli su paralelno s istim resursima i proračunskim prozorom, a nijedna povelja nije spominjala drugu. Vodstvo je to uhvatilo prekasno.

Ovo je struktura od koje bih krenuo. Svaki odjeljak treba stati na jednu stranicu ili manje.

1. Svrha i pozadina: zašto sada, što ne funkcionira, što se događa ako ne učinite ništa.
2. Ciljevi i mjere uspjeha: svaki cilj s polaznom vrijednošću, ciljnom vrijednošću i datumom.
3. Opseg: moduli, procesi, pravni subjekti, zemlje, lokacije, integracije i podaci u opsegu.
4. Izvan opsega: napisano jednako pažljivo kao opseg, s fazom na koju je svaka isključena stavka odgođena.
5. Model uvođenja i pravila za ekstenzije: S/4HANA Cloud Public Edition, Private Edition u okviru RISE-a ili on-premise, i kako će se odobravati razvoj po mjeri.
6. Upravljanje: sponzor, upravljački odbor, tijelo za dizajn, kontrola promjena, put eskalacije, s imenovanim ljudima.
7. Uloge i odgovornosti: imenovani pojedinci za svako procesno područje, podatke, testiranje, promjene i cutover.
8. Prekretnice: kontrolne točke faza s datumima i kriterijima za prolaz. Moj vodič o Quality Gates ima primjere.
9. Proračun i rezerva: okvir, rezerva i tko je može osloboditi.
10. Rizici, pretpostavke i ovisnosti: uključujući paralelne programe i regulatorne rokove.
11. Zahtjevi usklađenosti: na primjer HIPAA u američkom zdravstvu, GxP u farmaciji, SOX za tvrtke uvrštene na američkim burzama.
12. Potpis: sponzor i poslovni voditelji, s brojem verzije i datumom.

1. 01Pitajte ljude koji poznaju posaoSponzori, poslovni voditelji i krajnji korisnici
2. 02Razvrstajte obvezno od poželjnogPuštanje u rad, faza 2 ili ne u ovom projektu
3. 03Krenite od predloškaZatim dodajte integraciju, podatke i usklađenost
4. 04Budite dovoljno konkretni da riješite sporoveMožete li dokazati da je svaki cilj ostvaren?
5. 05Ishodite pravi potpisPročitano, osporeno i prihvaćeno, odjeljak po odjeljak

Povelja na koju možete uputiti kad se opseg ospori u trećem mjesecu

1. Pitajte ljude koji poznaju posao

Prije nego što išta napišete, sjednite sa sponzorima, poslovnim voditeljima i krajnjim korisnicima. Pitajte što ne funkcionira i što se ranije pokušalo. Jednom sam radio s proizvodnim klijentom koji je bacio 1,8 milijuna USD na SAP implementaciju jer je pretpostavio da zna što treba proizvodnoj hali. Šest mjeseci kasnije otkrio je da se stvarni problemi tijeka rada ne rješavaju.

Na jednoj financijskoj transformaciji na kojoj sam radio IT je planirao uvesti SAP da riješi probleme učinkovitosti. Razgovori s financijama pokazali su da je stvarni problem loša kvaliteta podataka. Da nismo pitali, potrošili bismo milijune na rješavanje pogrešnog problema.

2. Razvrstajte obvezno od poželjnog prije pisanja opsega

Svaki ulaz razvrstajte kao potreban za puštanje u rad, fazu 2 ili ne u ovom projektu. Jedan moj klijent iz stručnih usluga prekoračio je proračun za 40 % jer su zahtjevi bili na tri različita mjesta i stalno su se „ponovno otkrivali“ mjesecima nakon početka projekta. Moj vodič o predlošku opsega pomaže u ovom koraku.

3. Krenite od predloška, zatim dodajte SAP specifičnosti

Generički predložak propušta ono što SAP programe čini skupima: točke integracije, vlasništvo nad migracijom i čišćenjem podataka, pretpostavke o modulima, zahtjeve usklađenosti i pravila za razvoj po mjeri. Čuo sam za jedan SAP projekt koji je krenuo s generičkom poveljom koja nikad nije spomenula čišćenje podataka. Šest mjeseci kasnije stari su podaci ispali u užasnom stanju, što je dodalo 750.000 USD i tri mjeseca.

4. Budite dovoljno konkretni da riješite sporove

Vodio sam implementaciju za maloprodajnog klijenta u Singapuru čija je povelja govorila „modernizirati upravljanje zalihama“. Pola tima mislilo je da to znači brže procesiranje. Druga se polovica usredotočila na prognoziranje. Rezultat je bilo potrošenih 1,8 milijuna USD i nikakav dogovor o tome kako izgleda uspjeh. Za svaki cilj pitajte: mogu li dokazati da je ovo završeno?

5. Ishodite pravi potpis

Povelja je gotova kad su je ljudi koji je potpisuju pročitali, osporili i prihvatili njezine obveze. Provedite sponzora i poslovne voditelje kroz nju odjeljak po odjeljak. Vidio sam maloprodajne klijente koji su potrošili tri puna dana na usklađivanje povelje. Uštedjelo im je mjesece svađa i promjena opsega kasnije.

Pogreška	Što uzrokuje	Što učiniti umjesto toga
Nejasni ciljevi („poboljšati učinkovitost“)	Timovi vuku u različitim smjerovima	Stavite broj na svaki cilj
Nema isključenja	Opseg tiho raste	Popis izvan opsega pišite jednako pažljivo kao opseg
Vlasnici imenovani samo po nazivu ili odjelu	Odluke se odgađaju	Imenujte pojedince
Nema mjera uspjeha	Puštanje u rad se slavi, vrijednost se nikad ne pokaže	Definirajte KPI-jeve prije kickoffa
Paralelni programi nisu mapirani	Sudari resursa i proračuna	Ovisnosti zabilježite u objema poveljama
Povelju je napisao implementacijski partner	Opseg odražava ono što partner želi isporučiti	Povelju posjeduje klijent; partner doprinosi detaljima

Što se tiče posljednje točke, čvrst sam. Vaš implementacijski partner ne bi trebao pisati Vašu povelju. Njegov poticaj je započeti projekt. Vaš je odrediti mu opseg.

Na RISE with SAP (Private Edition) dodajte dvije stvari u odjeljak o upravljanju. Prvo, forum za odobravanje po načelu clean core. SAP sada klasificira ekstenzije od razine A, samo objavljeni API-ji, do razine D, izmjene (SAP News, kolovoz 2025.). Private Edition i dalje dopušta izmjenu jezgre, pa je forum ono što sprječava nakupljanje tehničkog duga. Drugo, put eskalacije prema SAP-u. Pod RISE-om SAP vodi infrastrukturu i tehničke operacije. CIO mora znati koga nazvati u SAP-u kad nešto zakaže na razini platforme, a ne samo kod partnera.

Na GROW with SAP (Public Edition) povelja postaje manja. Ekstenzije su ograničene na objavljena sučelja, pa platforma umjesto Vas provodi clean core, a mogućnosti integracije su uže. Vizija, mjere uspjeha, imenovani vlasnici i isključenja važni su jednako.

AI alati mogu brže pretvoriti bilješke s intervjua u prvi nacrt. Ne mogu obaviti političku stranu povelje, a to je da sponzori pristanu na to što posjeduju.

Što je povelja projekta u implementaciji SAP-a?

Dokument koji formalno odobrava SAP program. Određuje opseg i isključenja, imenuje sponzora i odgovorne osobe, definira mjere uspjeha, postavlja prekretnice i upravljanje te navodi glavne rizike. Korisna povelja dovoljno je konkretna da riješi neslaganje oko opsega ili vlasništva.

Što treba uključiti u povelju SAP projekta?

Svrhu, ciljeve s mjerljivim ciljnim vrijednostima, opseg, izričita isključenja, model uvođenja i pravila za ekstenzije, upravljanje s imenovanim ljudima, uloge, prekretnice s kriterijima kontrolnih točaka, proračun i rezervu, rizike i ovisnosti, zahtjeve usklađenosti i potpis. Pregled iznad prikazuje svaki odjeljak.

Koja je razlika između povelje projekta i plana projekta?

Povelja odobrava i definira: opseg, sponzora, upravljanje i prekretnice na visokoj razini. Plan izvršava: zadatke, ovisnosti, resurse i slijed. Plan bez povelje luta jer opseg nikad nije dogovoren. Svaka obveza iz plana treba se moći pratiti do povelje.

Tko bi trebao napisati povelju SAP projekta?

Posjeduje je klijentov sponzor, a nacrt piše voditelj programa, uz detalje voditelja financija, IT-a i operacija. Preporučujem da ne dopustite implementacijskom partneru da je napiše. Njegov je poticaj započeti projekt, a ne štititi Vas od opsega koji Vam ne treba.

Kako RISE with SAP mijenja povelju projekta?

Dodajte forum za odobravanje po načelu clean core koji odlučuje koje su ekstenzije dopuštene i na kojoj razini. Dodajte put eskalacije prema SAP-u za probleme platforme, jer pod RISE-om SAP vodi infrastrukturu. Na GROW with SAP povelja je lakša jer Public Edition tehnički provodi clean core.

Može li se povelja projekta mijenjati tijekom implementacije?

Da, kroz kontrolu promjena. Tretirajte povelju kao polaznu osnovu. Kad se promijene opseg, sponzor, proračun ili velika prekretnica, ažurirajte je s brojem verzije, bilješkom što se promijenilo i zašto te novim potpisom. Ne dopustite da se tiho revidira kad god projekt luta.