Planiranje raspodjele resursa za SAP projekte

Planiranje raspodjele resursa za SAP projekt znači odlučiti koje uloge Vam trebaju, u kojoj SAP Activate fazi i na koliko sati tjedno, a zatim svaki tjedan provjeravati odgovara li stvarnost još uvijek planu. Popunjavajte po ulozi, a ne po općenitom broju zaposlenih. Oblikujte plan prema krivulji faza: funkcionalni stručnjaci u fazi Explore, tehnički u fazi Realize, podaci, Basis i promjene u fazi Deploy. Dostupnost potvrdite pisanim putem s linijskim menadžerima. Ovaj je vodič namijenjen direktorima programa, PMO-ovima i CIO-ima koji izrađuju ili spašavaju plan resursa za S/4HANA. Tablice FTE-a i raspone dnevnih cijena u nastavku koristite kao polazne orijentire.

Vidio sam desetke implementacija kako se bore s istim problemima resursa. Plan pretpostavlja stabilnost koja nestaje čim izvedba počne.

Jednom sam vidio tim koji je izgubio cijeli tjedan jer nitko nije primijetio da voditelj sigurnosti ima uzastopne odsutnosti i obuke. Nije bilo označeno ni praćeno, a odgodilo je ključni pregled pristupa sustavu za devet dana.

Većina SAP planova oslanja se na uredne procjene, dostupnost u punom radnom vremenu i predvidljive tokove rada. Takva verzija svijeta rijetko preživi prvi mjesec faze Realize.

Planiram oko tri stvari: što posao stvarno zahtijeva, što će dostupni ljudi stvarno isporučiti i što se mijenja kad se stvarnost razlikuje od plana. Plan koji drži pokriva šest dimenzija:

1. Broj ljudi po ulozi po Activate fazi. Ne ravnomjerna raspodjela. Explore nimalo ne sliči fazi Realize.
2. Sati tjedno koje potvrdi linijski menadžer. Pisanim putem, a ne pretpostavljeno.
3. Istodobne obveze po osobi. Netko tko je naveden sa 100 %, a pokriva i produkcijsku podršku, isporučit će mnogo manje.
4. Zamjena za svaku ulogu na kritičnom putu. Međusobna obuka nije opcionalna na programu od 18 mjeseci.
5. Ovisnosti među radnim tokovima. Svaka s imenovanim vlasnikom, rokom i putem eskalacije, vidljiva onog dana kad zakasni.
6. Ritam ažuriranja. Tjedno u aktivnim fazama. Plan na kick-offu tek je prva verzija.

Planovi pođu po zlu kad planer koristi općenite IT uloge. SAP traži specifičnu funkcionalnu i tehničku specijalizaciju. Standardni skup za S/4HANA program:

Vodstvo programa. Voditelj programa, voditelj PMO-a i arhitekt rješenja. Arhitekt odgovara za koherentnost dizajna među modulima.

Funkcionalni konzultanti. Po jedan voditelj za svaki modul u opsegu: financijsko računovodstvo (FI), kontroling (CO), upravljanje materijalima (MM), prodaja i distribucija (SD), planiranje proizvodnje (PP), Extended Warehouse Management (EWM), uz upravljanje ljudskim potencijalima (HCM), održavanje postrojenja (PM) i projektni sustav (PS) gdje su u opsegu. Ako još koristite klasični Warehouse Management (WM), planirajte prelazak: prava korištenja WM-a iz paketa kompatibilnosti na S/4HANA on-premise istekla su krajem 2025.

Tehnički konzultanti. ABAP programeri za izvješća, sučelja, konverzije, proširenja, obrasce i tokove rada (RICEFW) te za clean core proširenja na objavljenim API-jima ili SAP BTP-u. Stručnjaci za integraciju za SAP Integration Suite (Cloud Integration, ranije CPI), SAP Process Orchestration gdje se još koristi te bilo koji middleware treće strane.

Platforma. Basis konzultanti za HANA-u, zakrpe kernela, transporte, kopije sustava i podešavanje performansi. Sigurnosni konzultanti za dizajn uloga, analizu podjele dužnosti i SAP GRC Access Control gdje je u opsegu.

Podaci. Stručnjaci za migraciju koji koriste aplikaciju „Migrate Your Data" iz SAP S/4HANA Migration Cockpita (starija transakcija LTMC je zastarjela), Migration Object Modeler za prilagođene objekte i SAP Data Services za složene transformacije. Moj vodič o razlozima zašto migracija SAP podataka propada objašnjava zašto ovaj tim treba početi ranije nego što većina planova dopušta.

Promjene. Voditelj promjena, voditelj obuke i vlasnik spremnosti poslovanja. Obično nedovoljno popunjeno, jer potreba postaje vidljiva tek u fazi Deploy.

Strana klijenta. Poslovni analitičari (po jedan za svaki veći modul), vlasnici procesa (po jedan za svako procesno područje) i testeri iz operative za UAT.

Tretiranje ovih uloga kao zamjenjivih mjesta najčešća je pogreška u planiranju. Stariji FI konzultant ne može voditi SD radionicu dizajna. Mlađi ABAP programer ne može projektirati integraciju. Za odgovornosti po ulozi pogledajte moj popis ključnih uloga u SAP implementacijskom timu.

Potražnja za resursima nije ravnomjerna. Activate faze stvaraju predvidljive krivulje koje ravnomjerna raspodjela promašuje.

Prepare (obično tjedni 1 do 4). Lagano. Voditelj programa, arhitekt i po jedan voditelj za svaki modul zbog određivanja opsega. Poslovni korisnici potvrđuju opseg. Basis i sigurnost započinju postavljanje okruženja.

Explore (obično mjeseci 2 do 5). Opterećeni su funkcionalni konzultanti i poslovni korisnici, a radionice dizajna određuju raspored. ABAP i integracija lagani su dok se ne donesu odluke o dizajnu. Basis priprema sandbox i sustave za kontrolu kvalitete.

Realize (obično mjeseci 5 do 12). Opterećeni su tehnički ljudi: konfiguracija, izrada, jedinično i integracijsko testiranje. Opterećenje ABAP-a doseže vrhunac. Poslovni korisnici ulaze u testne cikluse. Tim za podatke gradi objekte za migraciju i provodi probne migracije.

Deploy (obično mjeseci 12 do 14). Opterećeni su migracija podataka, Basis, sigurnost, promjene i obuka. UAT troši kapacitet poslovanja. Probe cutovera traže timove na istoj lokaciji. Počinje planiranje hypercarea.

Run (od 14. mjeseca; hypercare obično 30 do 90 dana). Mala jezgra tima i snažna pokrivenost podrške. Basis i upravljanje aplikacijama jačaju, dok konzultanti odlaze.

Ako ih tretirate kao jednako zahtjevne prozore, previše ćete popuniti Prepare, premalo Realize i ostati kratki s migracijom podataka u fazi Deploy. Krivulja faza najvažniji je oblik u planu.

1. PrepareOko 11 FTETjedni 1 do 4. Voditelji određuju opseg, Basis postavlja okruženje
2. ExploreOko 36 FTEMjeseci 2 do 5. Funkcionalni stručnjaci i poslovni korisnici
3. RealizeOko 56 FTE, vrhunacMjeseci 5 do 12. Izrada, a opterećenje ABAP-a doseže vrhunac
4. DeployOko 42 FTEMjeseci 12 do 14. Podaci, Basis, sigurnost, promjene
5. RunOko 12 FTEOd 14. mjeseca. Hypercare obično 30 do 90 dana

Stalne hitne situacije. Kad tim stalno gasi požare, plan je prestao predviđati stvarnost. Jedna odsutnost ne bi smjela moći izbaciti radnu cjelinu iz kolosijeka.

Poslovni korisnici nestaju kad su Vam potrebni. Radionice dizajna i UAT zastajkuju jer poslovni korisnici nisu dostupni. To je jedan od najčešćih izvora kašnjenja. Uzrok je gotovo uvijek isti: vrijeme je pretpostavljeno, a ne formalno dogovoreno. Operativni pritisak pobjeđuje svaki put kad obveza nije formalizirana.

Tehnički ljudi rastegnuti pretanko. Rad Geralda Weinberga o upravljanju softverom procjenjivao je da netko tko je podijeljen na tri projekta isporučuje oko 60 % svojih ukupnih kapaciteta, a ostatak se gubi na prebacivanje. Sažetak istraživanja o prebacivanju između zadataka Američkog psihološkog udruženja navodi gubitak istog reda veličine: kratki mentalni zastoji zbog prelaska s jednog zadatka na drugi mogu stajati čak 40 % produktivnog vremena. Plan izgleda učinkovito. Rezultat ne.

Kritični put mijenja se svaki tjedan. Stalno preslagivanje, radne cjeline koje kasno počinju i tjedne promjene prioriteta obično se svode na nejasan opseg ili loše poredane ovisnosti. Prvo popravite opseg, a tek onda plan resursa.

1. Lažna dostupnost. Netko naveden sa 100 % vodi i mjesečno zatvaranje te produkcijsku podršku. Pitajte koliko sati tjedno, na čemu još radi i je li njegov linijski menadžer to potvrdio pisanim putem.
2. Zajedničke uloge bez granica. Jedna osoba istodobno radi dizajn rješenja, testiranje i upravljanje promjenama. Podijelite odgovornosti po zadacima, a ne po nazivu pozicije, i nikada ne činite jednu osobu ključnom na dva mjesta u isto vrijeme.
3. Nedostaje vrijeme poslovnih korisnika. Radionice kasne, a odobrenja UAT-a traju tjednima dulje. Zatražite vrijeme pisanim putem, uz potpis voditelja odjela, pratite prisutnost i rano eskalirajte obrasce.
4. Nema pričuve. Jedna odsutnost zaustavlja radnu cjelinu. Pričuvu ugradite na razini zadataka, a ne samo faza, i međusobno obučite barem jednu osobu za svaku ključnu ulogu.
5. Plan koji se nikad ne ažurira. Izrađen na kick-offu i nikad revidiran. Pregledavajte ga tjedno u aktivnoj isporuci, povežite ga s točkama odobrenja faza i ažurirajte kad se stvarnost promijeni.

Počnite s potvrđenom dostupnošću. Obratite se linijskim menadžerima prije početka projekta. Potvrdite sate tjedno i druge obveze te ih dokumentirajte. Kad se dostupnost usred projekta promijeni, ta osnovica Vaša je podloga za eskalaciju.

Oblikujte ga po fazama. Opterećenje ABAP programera u fazi Explore razlikuje se od faze Realize. Poslovni korisnici imaju vrhunac u fazi Explore zbog dizajna, a u fazi Deploy zbog UAT-a. Ravnomjerna raspodjela na papiru izgleda uravnoteženo, a na terenu zakaže.

Izričito mapirajte ovisnosti. Migracija podataka napaja integracijsko testiranje, koje napaja UAT, koji pokreće cutover. Svakoj ovisnosti dajte vlasnika, datum i zastavicu, tako da je kašnjenje vidljivo istog dana.

Vrijeme poslovnih korisnika štitite na razini upravljačkog odbora. Njihov redovni posao se nastavlja. Bez izričitog odobrenja njihova rukovodstva za sate tjedno, napustit će projekt kad stigne operativni pritisak. Sponzor, a ne voditelj projekta, trebao bi od voditelja odjela tražiti to vrijeme.

Plan ažurirajte tjedno. Plan koji dva tjedna nitko nije dotaknuo vjerojatno je pogrešan. Pratite stvarnu u odnosu na planiranu iskorištenost. Netko tko je dva tjedna zaredom na 120 % znak je da je ili preopterećen ili da je plan pogrešan.

Ovo su okvirni rasponi broja ljudi i cijena koje možete koristiti kao polazne orijentire. Pomiču ih industrija, opseg, geografija i partner. Tablice koristite kao provjeru razumnosti, a ne kao ponudu.

Brownfield za srednje tržište (5 do 15 milijuna USD, oko 12 mjeseci)

Tipičan opseg: jedan pravni subjekt ili manja grupa, tri ili četiri modula (obično FI, CO, MM, SD), standardni procesi i ograničen razvoj prilagodbi.

Radna cjelina	Prepare	Explore	Realize	Deploy	Run
Voditelj programa	1	1	1	1	0,5
Arhitekt rješenja	1	1	1	0,5	0
Funkcionalni konzultanti (FI/CO, MM, SD plus jedan)	1	4	4	2	1
ABAP i tehnika	0	1	3	1	0,5
Integracija	0	0,5	2	1	0,5
Basis	0,5	0,5	1	2	1
Sigurnost i autorizacije	0	0,5	1	1,5	0,5
Migracija podataka	0	1	2	3	0
Voditelj testiranja	0	0,5	1	1	0
Promjene i obuka	0,5	1	1	2	0,5
Poslovni analitičari na strani klijenta	1	4	3	2	1
Ukupni vršni FTE	5	14	20	17	5

Brownfield za velike korporacije (30 do 80 milijuna USD, 15 do 18 mjeseci)

Tipičan opseg: više subjekata, šest do devet modula, složena integracija, znatan razvoj prilagodbi i više uvođenja po državama.

Radna cjelina	Prepare	Explore	Realize	Deploy	Run
Voditelj programa i PMO	2	2	3	3	1
Arhitekti rješenja (glavni plus modulni)	2	3	3	1,5	0,5
Funkcionalni konzultanti (svi moduli u opsegu)	2	10	12	5	2
ABAP i tehnika	0	3	8	3	1
Integracija i middleware	0,5	2	5	2	1
Fiori i UI5	0	1	3	1	0,5
Basis	1	1	2	4	2
Sigurnost i GRC	0,5	1,5	2	3	1
Migracija podataka	0	2	5	6	0,5
Testiranje	0,5	1	3	4	0
Promjene i obuka	1	2	3	5	1
Poslovni analitičari na strani klijenta	2	8	7	5	2
Ukupni vršni FTE	11	36	56	42	12

Dnevne cijene po ulozi i regiji (2024. do 2025.)

Ovo su cijene koje partner naplaćuje po stručnjaku, a ne plaće. Mješovita cijena na razini programa obično je 30 do 50 % ispod onshore cijene za seniora, jer većina programa miješa onshore arhitekte s offshore isporukom.

Uloga	Onshore SAD/UK/DE	GCC (UAE/KSA)	Nearshore (LatAm/istočna Europa)	Offshore (Indija)
Arhitekt rješenja (senior)	2.000 do 3.500 USD	1.500 do 2.500 USD	900 do 1.500 USD	500 do 1.000 USD
Funkcionalni konzultant (senior)	1.500 do 2.800 USD	1.200 do 2.000 USD	700 do 1.400 USD	300 do 700 USD
Funkcionalni konzultant (srednja razina)	1.000 do 1.800 USD	800 do 1.400 USD	500 do 900 USD	200 do 500 USD
ABAP i tehnika (senior)	1.400 do 2.500 USD	1.000 do 1.800 USD	600 do 1.200 USD	300 do 700 USD
Stručnjak za integraciju	1.500 do 2.800 USD	1.100 do 1.900 USD	700 do 1.300 USD	350 do 800 USD
Basis	1.400 do 2.200 USD	1.000 do 1.800 USD	600 do 1.100 USD	300 do 700 USD
Sigurnost i GRC	1.500 do 2.500 USD	1.100 do 1.900 USD	700 do 1.300 USD	350 do 800 USD
Migracija podataka	1.300 do 2.200 USD	1.000 do 1.700 USD	600 do 1.100 USD	300 do 700 USD
Voditelj promjena i obuke	1.200 do 2.000 USD	900 do 1.500 USD	500 do 1.000 USD	250 do 600 USD
Junior konzultant (bilo koja uloga)	800 do 1.400 USD	500 do 900 USD	400 do 700 USD	150 do 350 USD

Omjer onshorea, nearshorea i offshorea

Većina SAP programa miješa regije. To je odluka o trošku naspram brzine, a ne binarni izbor.

Programi u privatnom sektoru SAD-a obično su 30 do 60 % onshore, mjereno u FTE-ima. Onshore je koncentriran u arhitekturi, promjenama, poslovnoj analizi i starijim funkcionalnim ulogama, gdje je blizina poslovanju važna. Offshore je koncentriran u ABAP-u, izradi integracija i izvođenju migracije podataka, gdje je posao lakše specificirati. Programi američke savezne vlade često su potpuno onshore uz ograničenja za osobe s američkim statusom (US-person), ovisno o opsegu posla.

GCC programi obično su 60 do 70 % onshore, jer lokalna pravila zapošljavanja i zahtjevi za arapskim jezikom taj udio podižu. Offshore posao naginje južnoazijskim centrima zbog preklapanja vremenskih zona. Europski programi variraju: u proizvodnji je često oko 50 % onshore, dok javni sektor i regulirane industrije idu više zbog zahtjeva za lokacijom podataka.

Česta je pogreška optimizirati omjer samo prema trošku. Tim koji je 80 % offshore uz 20 % onshore arhitekata na proračunskoj tablici izgleda jeftino. Skriveni su troškovi dnevni ciklus primopredaje i sporije radionice dizajna bez poslovnog konteksta. Najjeftiniji tim rijetko isporuči najjeftiniji program. Kad uspoređujete partnere, moj vodič za SAP implementacijske partnere po razinama obrađuje kako se cijene i sastav tima među njima razlikuju.

Plan izrađen jednom i nikad ponovno preispitan nije plan. Svaku pretpostavku u njemu tretirajte kao hipotezu koju treba provjeriti u prvom tjednu izvedbe, i svakog tjedna nakon toga.

Što je planiranje raspodjele resursa u SAP projektima i zašto je važno?

To je odlučivanje koji ljudi projektu trebaju, kada i za koliki dio njihova vremena, a zatim praćenje odgovara li to stvarnosti.

SAP projekti ovise o konkretnim pojedincima: FI/CO voditelju koji razumije Vaš kontni plan, stručnjaku za migraciju koji poznaje Vaše naslijeđene podatke, voditelju promjena s vezama u poslovanju. Kad nisu dostupni u pravom trenutku, posao staje ili se radi pogrešno. Mnoga kašnjenja koja izgledaju tehnička zapravo su problemi resursa.

Kako loša raspodjela resursa uzrokuje kašnjenja SAP projekata?

Kroz ovisnosti. Voditelj konfiguracije povuče se na drugi projekt u fazi Realize. Njegov posao staje, što odgađa integracijsko testiranje, zatim UAT, zatim spremnost za cutover. Odsutnost od dva tjedna u osmom tjednu do go-livea može narasti u kašnjenje od šest tjedana.

Male praznine rano postaju velika kašnjenja kasno. Dok je utjecaj vidljiv, oporavak košta višestruko više od ranog ispravka.

Kako obvezati poslovne korisnike na SAP projekt kad imaju svoj redovni posao?

Zatražite pisanu obvezu njihova linijskog menadžera prije početka projekta: sate tjedno, u kojim fazama su najpotrebniji i kakvo je odobrenje potrebno ako se dostupnost promijeni.

Njihovu prisutnost pratite kao i svaki drugi resurs. Kad opadne, eskalirajte na razini upravljačkog odbora. Voditelji odjela mogu provesti obvezu; projektni tim ne može.

Kako postupiti kad ključna osoba napusti projekt usred izvedbe?

Najprije izbjegavajte pojedinačne točke otkaza: barem jedna druga osoba trebala bi dovoljno dobro razumjeti svaku ključnu radnu cjelinu da je može održati u pokretu.

Kad netko ode, odmah zabilježite što zna: nedokumentirane odluke i obrazloženja konfiguracije. To je često teže nego pronaći zamjenu. Za nadomjestak su minimum dokument o primopredaji, snimljene sesije i tjedan dana preklapanja.

Kada treba eskalirati problem s resursima?

Ranije nego što je ugodno. Eskalirajte kad imenovani vlasnik ovisnosti nije dostupan dulje od tjedan dana, kad poslovni korisnik stalno propušta sesije, kad je tehnički resurs dva tjedna iznad 120 % iskorištenosti ili kad je radna cjelina blokirana odgođenom odlukom o resursima.

Cijena prerane eskalacije neugodan je razgovor. Cijena prekasne eskalacije su tjedni kašnjenja.

Kako postupati sa zajedničkim resursima na više projekata?

Pretpostavite da će zajednički ljudi dati prednost nečem drugom kad stigne pritisak. Dogovorite konkretne sate tjedno s njihovim primarnim menadžerom, ugradite pričuvu u posao koji ovisi o njima i držite ih izvan svog kritičnog puta osim ako nemate rezervno rješenje.

Za zajedničke poslovne korisnike zahtjev mora doći od sponzora. Voditelj projekta koji traži vrijeme od voditelja odjela svaki će put izgubiti od operativnih prioriteta.