Predložak opsega SAP projekta: što definirati i isključiti

Predložak opsega SAP projekta definira što će program isporučiti, što namjerno neće isporučiti, tko je vlasnik svakog dijela i kako se opseg može mijenjati. Devet odjeljaka niže to pokriva. Dva koja su najvažnija su ona koja timovi preskaču: izričita isključenja i opseg migracije podataka. Popunite predložak prije početka konfiguracije i neka ga potpišu sponzor i vlasnici procesa.

Ponekad timovi popune predložak opsega i krenu dalje. Taj dio djeluje lako. Tjednima kasnije, tijekom dizajna ili izgradnje, netko označi proces koji se „pretpostavljao da je u opsegu”. Razgovor postaje neugodan. Nitko to nije zapisao. Nitko ga nije namjeravao izostaviti. Vidio sam to prečesto. Nekoliko neprovjerenih pretpostavki na početku tiho odgurne projekt tjednima s kursa.

Zadatak dokumenta o opsegu nije bilježiti što su ljudi rekli u prostoriji. Njegov je zadatak iznuditi jasnoću prije nego što konfiguracija zaključa pretpostavke koje je skupo poništiti.

Ovo je devet odjeljaka, uz ono na što svaki mora odgovoriti.

1. Ciljevi

Zašto se ovaj posao radi i što će poslovanje vidjeti kada bude gotov? Svaki cilj vežite uz mjerljiv ishod: skratiti mjesečno zatvaranje za tri dana, ukloniti ručna usklađivanja kroz tri subjekta, jedan pogled na zalihe u svim pogonima. Nejasni ciljevi daju nejasne kriterije uspjeha, a neslaganje izlazi na vidjelo u korisničkom testiranju prihvaćanja (UAT).

2. Definicija opsega

Moduli, pravni subjekti, pogoni, zemlje, jezici, integracije i model isporuke. Budite konkretni. „Financije” nisu opseg. „Financijsko računovodstvo i kontroling (FI/CO) koji pokrivaju obveze prema dobavljačima, potraživanja od kupaca, glavnu knjigu i računovodstvo troškovnih mjesta za pravni subjekt u UAE-u na S/4HANA Cloud Private Edition” jest opseg.

3. Isključenja

Tu većina predložaka opsega zakaže. Ako nešto nije zapisano kao isključeno, netko će pretpostaviti da je uključeno. Isključenja koja treba zapisati poimence:

1. Zemlje ili subjekti odgođeni za kasniju fazu.
2. Naslijeđene integracije koje za sada ostaju kakve jesu.
3. Povijesni podaci prije definiranog datuma prekida.
4. Izvještaji premješteni na popis proširenja nakon puštanja u rad.
5. Regulatorni zahtjevi odgođeni do pravne potvrde.

Svakom isključenju dodijelite fazu u koju se premješta, ako je ima. Potpisano isključenje pretvara dvotjednu raspravu u kratak razgovor.

4. Opseg migracije podataka

Dosljedna slijepa pjega. Pisanim putem odgovorite na tri pitanja:

1. Što se prenosi? Samo otvorene stavke ili i povijest? Svi kupci i dobavljači ili samo aktivni? Materijali za svaki pogon ili samo za subjekte koji idu u rad?
2. Koja su pravila prekida? Datum stanja za otvorene nabavne, prodajne i radne naloge i što se događa sa stavkama u tijeku pri prijelazu (cutover).
3. Što se umjesto toga arhivira? Zakonska pravila zadržavanja povijesti i koliko dugo naslijeđeni sustav ostaje čitljiv.

Pretpostavke ovdje ostavljene nedokumentiranima postaju sporovi tijekom izgradnje. Moj članak o tome zašto migracija SAP podataka ne uspijeva detaljno obrađuje planiranje.

5. Nefunkcionalni opseg

Oni ispadnu iz planiranja i izlaze kao zapreke kasno u testiranju. Uvrstite ih u opseg:

1. Raspoloživost i prozor održavanja. Uz RISE, pozovite se na uvjete raspoloživosti u svom ugovoru.
2. Performanse pri vršnom opterećenju, poput mjesečnog zatvaranja.
3. Evidentiranje audita: koje transakcije i koliko dugo se zapisnici čuvaju.
4. Sigurnost i kontrola pristupa po ulogama.
5. Latencija izvještavanja: u stvarnom vremenu, gotovo u stvarnom vremenu ili dnevno.

To nisu funkcionalnosti. To su ograničenja koja sustav mora zadovoljiti. Ako nisu u opsegu, nitko ih ne projektira.

6. Uloge i odgovornosti

Svakom radnom toku trebaju voditelj konzultant i poslovni sugovornik s ovlastima odlučivanja, oboje imenovani. Praznina koju najčešće vidim je vlasništvo nad UAT-om: tko može potpisati da je proces testiran i prihvaćen? Odlučite to prije početka izgradnje, a ne dva tjedna prije puštanja u rad.

7. Kontrola promjena

Ne „promjene zahtijevaju formalno odobrenje”. Konkretan proces: što pokreće zahtjev za promjenu, tko procjenjuje utjecaj na vrijeme i proračun, tko odobrava i što se bilježi. Bez njega „možemo li ovo dodati?” postaje „mislili smo da je to uključeno”, a zatim produljenje od tri tjedna koje nitko nije planirao.

8. Pravila proširenja

Kako će se odobravati prilagođeni razvoj. SAP sada klasificira proširenja od razine A, samo objavljeni API-ji, do razine D, izmjene jezgre (SAP News, kolovoz 2025.). Na Public Edition uz GROW sustav dopušta samo objavljena sučelja. Na Private Edition uz RISE i on-premise jezgra se još može mijenjati pa opseg treba navesti ciljnu razinu i tko odobrava iznimke. Moj vodič za Clean Core objašnjava razine.

9. Pretpostavke i ograničenja

Popišite pretpostavke iza opsega kako bi ih netko morao provjeriti. Zatim ograničenja: regulatorni rokovi koji fiksiraju datum puštanja u rad, gornje granice proračuna, ljudi koji rade samo s dijelom radnog vremena i datumi gašenja naslijeđenih sustava.

Prilagodba je oblik klizanja opsega kojem najdulje treba da se pokaže. Jedan odobren prilagođeni izvještaj postaje pet. Jedna iznimka u tijeku rada postaje presedan za svaki sljedeći zahtjev.

Klasificirajte svaki zahtjev prije nego što išta odobrite:

Kategorija	Test	Što učiniti
Ključna	Proces ne može pravno ili operativno funkcionirati bez nje	Odobrite, uz najjeftinije proširenje koje je sigurno pri nadogradnji
Važna, ali ne kritična	Poboljšava učinkovitost, ali nije zapreka za puštanje u rad	Odobrite samo uz jasan slučaj troška i koristi
Nepotrebna	Preferencija ili kopija načina na koji je radio naslijeđeni sustav	Osporite, zatim odbijte ili odgodite

Većina nepotrebnih prilagodbi postoji jer netko nije želio promijeniti način na koji radi, a ne zato što SAP nije mogao podržati proces. A trošak izgradnje tek je početak. Svaki prilagođeni objekt dodaje testiranje, obuku, dokumentaciju i posao oko nadogradnji dokle god postoji.

Odredite zamrzavanje promjena (change freeze). Odaberite datum, obično četiri do šest tjedana prije puštanja u rad, nakon kojeg se za izdanje ne prihvaćaju novi zahtjevi. Sve kasnije ide u backlog nakon puštanja u rad. Zamrzavanje treba potpis upravljačkog odbora iza sebe. Datum koji objavi samo voditelj projekta bit će nadglasan prvi put kad voditelj odjela pritisne.

1. 01Podnesen zahtjevŠto se računa kao promjena definira se unaprijed
2. 02KlasificiranKljučna, važna ili nepotrebna
3. 03Procijenjen utjecajVrijeme i proračun, od imenovanog procjenitelja
4. 04OdlukaImenovani odobravatelj odobrava, odbija ili odgađa
5. 05Opseg dobiva novu verzijuNovi broj verzije i popis što se promijenilo

Nakon zamrzavanja promjena novi zahtjevi idu u backlog nakon puštanja u rad

Analitika je mjesto gdje se razgovori o opsegu zaoštre. Svi žele izvještaje, a nitko ne kaže koliko.

Dogovorite fiksni popis izvještaja tijekom dizajna. Pitajte ljude što im treba, a ne što bi mogli željeti. Označite svaki izvještaj kao standardni SAP izlaz ili prilagođeni razvoj i neka se popis potpiše zajedno s ostatkom opsega. Standardni izvještaji koštaju djelić prilagođenih. Istodobno utvrdite izvore podataka svakog izvještaja; izvještaj koji vuče podatke iz tri sustava integracijski je zahtjev. Ako su nadzorne ploče i planiranje u opsegu, moj vodič za SAP Analytics Cloud pokriva što prvo treba riješiti.

Pogreška	Što uzrokuje	Kako je izbjeći
Ciljevi nisu mjerljivi	UAT sporovi oko toga što znači „radi”	Na početku postavite mjerljive ishode
Isključenja nisu zapisana	Posao se upija bez odobrenja	Poimence navedite što je izvan opsega
Opseg migracije podataka nejasan	Pogrešni volumeni, pomaknut cutover, prerada	Definirajte što se prenosi, prekide i arhiviranje
Nedostaju nefunkcionalni zahtjevi	Problemi s auditom i performansama pri puštanju u rad	Raspoloživost, performanse, evidentiranje i sigurnost uvrstite u opseg
Nema imenovanih vlasnika UAT-a	Testiranje se razvlači, nitko ne može potpisati	Imenujte pojedince s ovlastima
Nema kontrole promjena	Neformalni dodaci, sabijeno testiranje	Proces promjena upišite u opseg
Nema potpisa	Opseg se kasnije osporava bez odgovornosti	Potpisuju sponzor i vlasnici procesa
Analitika ostavljena za kasnije	Zahtjevi za izvještaje dva tjedna prije puštanja u rad	Dogovorite popis izvještaja tijekom dizajna
Model isporuke ili pravila proširenja otvoreni	Rasprava se prelijeva u fazu izgradnje	Odlučite oboje prije potpisivanja opsega

Pregledajte opseg na svakoj kontrolnoj točki faze SAP Activate i nakon svake odobrene promjene, uz broj verzije i popis što se promijenilo. Opseg pripada u povelju projekta referencom, tako da oba dokumenta pričaju istu priču.

Što treba uključivati predložak opsega SAP projekta?

Devet odjeljaka: ciljeve s mjerljivim ishodima, definiciju opsega (moduli, subjekti, zemlje, integracije, model isporuke), izričita isključenja, opseg migracije podataka, nefunkcionalne zahtjeve, imenovane uloge, kontrolu promjena, pravila proširenja te pretpostavke s ograničenjima. Isključenja su odjeljak koji najčešće nedostaje.

Kako spriječiti klizanje opsega u SAP projektima?

Isključenja pišite izričito, svaku promjenu provedite kroz formalni zahtjev s procjenom utjecaja i imenovanim odobravateljem, klasificirajte prilagodbe prije odobravanja i odredite potpisano zamrzavanje promjena četiri do šest tjedana prije puštanja u rad. Cilj nije odbiti svaku promjenu. Cilj je da promjena bude vidljiva, procijenjena i odobrena.

Što je opseg migracije podataka u SAP projektu?

Definicija koji podaci prelaze u SAP i po kojim pravilima: koji objekti (kupci, dobavljači, materijali, otvoreni nalozi, povijest), datumi prekida i što se umjesto migracije arhivira. Određuje napor i vremenski plan te odlučuje koliko dugo naslijeđeni sustavi moraju ostati dostupni.

Što je nefunkcionalni opseg u SAP projektima?

Ograničenja koja sustav mora zadovoljiti, za razliku od procesa koje podržava: raspoloživost, performanse pri vršnom opterećenju, evidentiranje audita, sigurnost i kontrola pristupa te latencija izvještavanja. Često se izostave iz opsega, a zatim otkriju u testiranju. U reguliranim industrijama evidentiranje audita pravna je obveza.

Kako treba postupati s prilagodbama u opsegu?

Klasificirajte svaki zahtjev kao ključan, važan ili nepotreban. Za svaki odobreni zabilježite zahtjev, zašto standardni SAP ne zadovoljava, napor, utjecaj na testiranje, trošak održavanja i pristup proširenju. Na Private Edition i on-premise navedite ciljnu razinu Clean Core i tko odobrava iznimke.

Kada treba pregledavati opseg SAP projekta?

Na svakoj kontrolnoj točki faze SAP Activate, nakon svakog odobrenog zahtjeva za promjenu i kad god se promijene proračun, resursi ili vremenski plan. Čuvajte svaku verziju s datumom, brojem verzije i sažetkom što se promijenilo. Ta povijest štiti tim kada se opseg kasnije osporava.