Planiranje i kontrola SAP projekata: držite projekte na tragu

Većina SAP programa ima plan. Mnogo ih je manje koji imaju kontrolu. Planiranje određuje opseg, vremenski okvir, proračun i rizike. Kontrola je tjedni posao: praćenje napretka u odnosu na plan, upravljanje ovisnostima, rana eskalacija i procjena svake promjene prije nego što se odobri. Ovaj je vodič namijenjen direktorima programa, PMO-ovima i sponzorima čiji SAP program klizi ili koji žele spriječiti da klizi. Opisuje kako kontrola izgleda, tri javna neuspjeha koja pokazuju što se događa bez nje te tjedni ritam kontrole s vlasnicima koji možete uvesti već ovaj tjedan.

Kad sam počinjao, radio sam na SAP programu koji je na papiru izgledao sjajno. Vremenski planovi, registri rizika, dnevnici promjena, sve što biste očekivali. Nitko ih se nije držao. Upravljački odbor rijetko se sastajao. Financije su čekale migraciju podataka. IT još nije bio počeo. Nitko nije pratio ovisnosti. Svi su pretpostavljali da netko drugi drži stvari na tragu.

Do šestog mjeseca polovica projekta kasnila je i trčali smo za vlastitim pogreškama. Najgore je bilo to što nitko nije vidio da dolazi.

Nije bio problem planiranja. Bio je problem kontrole. Nije bilo prave raspodjele resursa, pravog ublažavanja rizika ni puta eskalacije. Plan je jednom izrađen, a zatim napušten u korist sastanaka.

Planiranje obuhvaća opseg, vremenski okvir, proračun, resurse, registar rizika i obveze prema prekretnicama. Većina timova to izradi. Pitanje je koristi li to itko iz tjedna u tjedan.

Kontrola obuhvaća praćenje stvarnog napretka u odnosu na plan, rano uočavanje odstupanja, upravljanje ovisnostima, eskalaciju kad stvari zakasne i ponovno postavljanje osnovnog plana kad se opseg ili rokovi formalno promijene. Većina timova to radi slabo.

1. 01Praćenje napretkaStvarno u odnosu na plan, po radnom paketu
2. 02Uočavanje odstupanjaSvaki zadatak koji kasni tri dana
3. 03Provjera ovisnostiTko je blokiran ako ovo zakasni
4. 04EskalacijaPutem unaprijed dogovorenog puta
5. 05Procjena promjenaPrvo vrijeme, trošak i resursi
6. 06Novi osnovni planTek nakon formalne promjene

Svaki tjedan, s imenovanim vlasnicima

Evo što se raspada kad kontrole nema:

Što se raspada bez kontrole	Zašto se to događa
Rokovi tiho kližu	Nitko ne provjerava između pregleda prekretnica
Pretpostavke ostaju neprovjerene	Svaki tim očekuje da će ovisnost riješiti neki drugi
Opseg se neformalno širi	Promjene se odobravaju na sastancima bez procjene utjecaja
Rizici se ignoriraju dok ne nastupe	Registar rizika ažurira se kvartalno umjesto tjedno
Troškovi prelaze proračun	Utrošeni sati stoje u evidenciji vremena, ali nisu povezani s radnim paketima
Timovi prestaju komunicirati	Statusni sastanci postaju izvješća bez zadataka

Ovo su javni slučajevi, a ne klijentske priče. Njihovi su temeljni uzroci oni koje redovito vidim u savjetodavnom radu.

Lidl: oko sedam godina i procijenjenih 500 milijuna eura, a zatim zaustavljen projekt

Lidl je 2011. pokrenuo projekt eLWIS na SAP Retailu. Njegova praksa vrednovanja zaliha razlikovala se od SAP-ova standardnog modela, a Lidl je odlučio prilagoditi softver, a ne praksu. Do 2018. sustav je bio u produktivnom radu u Austriji, Sjevernoj Irskoj i SAD-u, ali je uprava zaključila da se izvorni ciljevi ne mogu postići uz razuman trošak. Lidl je zaustavio projekt i vratio se razvoju vlastitog internog sustava. Stručni mediji procijenili su utrošak na oko 500 milijuna eura, a član uprave zadužen za IT otišao je 2017. Heise je o odluci izvijestio u srpnju 2018. Pouka: godine prilagodbi radi zaštite naslijeđene prakse neuspjeh su kontrole, a ne softvera.

Hershey: narudžbe za Noć vještica vrijedne oko 100 milijuna dolara nisu isporučene

Hersheyjev novi sustav SAP, Siebel i Manugistics trebao je biti pušten u rad u travnju 1999., mirnom mjesecu za industriju slastica. Kasnio je tri mjeseca i pušten je u srpnju, baš kad su počele stizati narudžbe za Noć vještica. Narudžbe nisu mogle stići iz sustava do skladišta. Izvršni direktor rekao je analitičarima da će zbog problema Hershey izostati isporuka oko 100 milijuna dolara proizvoda za Noć vještica, a prodaja u trećem tromjesečju pala je 12,4 %. Prikaz časopisa CIO pravi neuspjeh pripisuje odabiru trenutka. Kontrola rasporeda koja bi štitila sezonski vrhunac iznudila bi drukčiji datum puštanja u rad.

Revlon: poremećen pogon i materijalna slabost u kontrolama

Revlon je u veljači 2018. uključio SAP u pogonu u Oxfordu u Sjevernoj Karolini, svojoj najvećoj proizvodnoj lokaciji. Poremećaji u radu pogodili su proizvodnju i isporuke velikim američkim trgovcima. U ožujku 2019. Revlon je objavio materijalnu slabost internih kontrola povezanu s uvođenjem, navodeći izostanak učinkovite kontinuirane procjene rizika i premalo obučenih ljudi u pogođenim operacijama. Ulagači su tužili tvrtku; TechTarget je pisao o tužbi, u kojoj se tvrdi da je ostalo neisporučeno oko 64 milijuna dolara pošiljki.

Nijedan od njih nije propao zato što je SAP bio pogrešan izbor. Propali su na temeljima planiranja i kontrole koji postoje desetljećima.

Strukturna raščlamba posla

Strukturna raščlamba posla (WBS) dijeli ukupni opseg na isporučevine s jasnim vlasnicima. Bez nje je posao nevidljiv dok ne zakasni. Za SAP program obuhvaća dizajn procesa, konfiguraciju, migraciju podataka, integraciju, testiranje, obuku i cutover, svaki razrađen do zadataka s vlasnikom i rokom.

Vrijednost nije u dokumentu. Ona prisiljava na razgovor o tome što treba napraviti, tko to radi i o čemu ovisi. Ovisnosti ubijaju projekte. Kašnjenje migracije podataka blokira integracijsko testiranje, koje blokira UAT, koji skraćuje prozor za cutover. WBS taj lanac čini vidljivim.

Upravljanje rasporedom

Rokovi propadaju iz predvidljivih razloga. Ljude se povuče na druge poslove. Procjene su bile pogrešne. Odluke traju dulje nego što je planirano. Pričuvu vremena ugradite od prvog dana, kao izričit međuprostor uz zadatke kojima će je najvjerojatnije trebati, a ne kao dodatak razmazan posvuda.

Raspored pratite tjedno. Kašnjenje od tjedan dana u četvrtom tjednu povod je za razgovor. Kašnjenje od četiri tjedna u šesnaestom tjednu kriza je. Isti problem, vrlo različit trošak ispravka.

Termin puštanja u rad tretirajte kao zasebnu odluku. Nikada ne puštajte sustav u rad usred poslovnog vrhunca. Hersheyjeva pouka vrijedi za svaku tvrtku.

Kontrola proračuna

Proračuni pucaju iz tri razloga: nekontroliranih promjena opsega, podcijenjene migracije podataka i troškova hypercarea većih od ranih procjena. Stvarnu potrošnju pratite u odnosu na plan od prvog tjedna. Dok odstupanje stigne do upravljačkog odbora, obično je prekasno za ispravak bez poremećaja.

Kontrola promjena glavna je zaštita proračuna. Svaka promjena opsega prije odobrenja dobiva procjenu utjecaja na vrijeme, trošak i resurse. Ako procjena dolazi nakon odobrenja, promjena je zaobišla proračun. Moj vodič za izbjegavanje nekontroliranog širenja opsega u SAP implementacijama dublje obrađuje odbor za promjene.

Upravljanje rizicima

Registar rizika koji se održava kvartalno puka je predstava. Rizici trebaju tjedni pregled, imenovane vlasnike i planove odgovora. Imenujte ove rizike na svakom SAP programu: kasno otkrivenu kvalitetu podataka, kašnjenja integracije, praznine u dostupnosti resursa, sabijanje prozora za cutover i slabo prihvaćanje među korisnicima.

Jedan klijent izgubio je tri mjeseca jer je njegov dobavljač za migraciju podataka propuštao rok za rokom. Stalno smo slušali „još samo dva tjedna" sve dok nije bilo prekasno za promjenu dobavljača bez probijanja proračuna. Rizik s vlasnikom i datumom okidača iznudio bi tu odluku mjesecima ranije. Moja matrica procjene rizika za SAP daje predložak za bodovanje rizika i dodjelu vlasnika.

Komunikacija i eskalacija

Rukovodstvu trebaju sažeci. Timovima za isporuku trebaju pojedinosti. Voditeljima projekata trebaju podaci o odstupanjima. Jedno izvješće za sve ne koristi nikome.

Puteve eskalacije dokumentirajte i uvježbajte prije krize. Na jednoj SAP implementaciji IT je pretpostavljao da konfiguraciju pregledavaju financije, a financije da je pregledava IT. Nitko to nije podigao dok do puštanja u rad nije ostalo tri mjeseca, a ključna odobrenja nisu bila dana; ispravak je bio trka u zadnji čas, dodatni trošak i odgođeno uvođenje. Druga je tvrtka to napravila kako treba: izvještavanje je bilo strukturirano i vezano uz zadatke, pa je, kad bi se pojavio problem, svatko znao tko je njegov vlasnik, kakav je utjecaj i kako će se riješiti.

Opseg je mjesto na kojem eskalacija opravdava svoje postojanje. Radio sam s jednom zrakoplovnom tvrtkom koja je započela jednostavnom nadogradnjom rezervacija. Nakon šest mjeseci dodala je izmjene programa lojalnosti, raspoređivanje posade i financijske module. Ništa od toga nije bilo hitno. Nitko nije rekao ne. Rok se udvostručio, a troškovi su porasli 70 %.

Priručnik za on-premise ne preživljava RISE with SAP nepromijenjen. Tri su stvari drukčije.

RISE mijenja prema kome eskalirate

U okviru RISE with SAP, SAP upravlja infrastrukturom i tehničkim operacijama te osigurava tim za uspjeh korisnika (customer success) koji prati prihvaćanje. Vaša struktura kontrole mora ih uključiti. Za probleme platforme (performanse sustava, regija hyperscalera, razine usluge SAP-a) voditelj programa treba dokumentiran put eskalacije prema SAP-u koji ne ide preko implementacijskog partnera. Zapišite ga prije nego što Vam zatreba.

Clean core daje kontroli opsega tehnički oslonac

Za svaki gap sada je potrebna odluka: konfigurirati ga, proširiti putem objavljenih API-ja (on-stack uz ABAP Cloud ili side-by-side na SAP BTP-u) ili ga odbiti. Na S/4HANA Cloud Public Edition izmjena jezgre nije opcija. Na private edition i on-premise moguća je, ali SAP-ove smjernice za clean core smatraju je posljednjim utočištem, jer svaka izmjena dodaje posao pri nadogradnji.

To pomaže kontroli opsega. Zahtjev da se „samo malo prilagodi standardni proces od narudžbe do naplate" prestaje biti usputan razgovor o konfiguraciji i postaje proširenje s naporom dizajna, izrade i testiranja. Ispod upravljačkog odbora uspostavite malen forum za pregled proširenja, s jednim arhitektom koji ima ovlast odobriti ili odbiti. Bez njega svaka rasprava o prilagodbi završava na upravljačkom odboru.

Umjetna inteligencija piše nacrte izvješća, odluke donose ljudi

Umjetna inteligencija danas pomaže oko papirologije kontrole. SAP Cloud ALM, SAP-ov alat za upravljanje životnim ciklusom aplikacija, drži projektne zadatke, zahtjeve i status testiranja te može generirati nacrte zahtjeva iz transkripata radionica. Microsoft Copilot izrađuje nacrte sažetaka odstupanja za materijale upravljačkog odbora iz nadzornih ploča i izvješća o statusu. Otkrivanje anomalija u Power BI-ju ili SAP Analytics Cloudu označava KPI-jeve koji odstupaju od uobičajenog obrasca. To je korisno za iskorištenost resursa, broj zahtjeva za promjenu i prijave podrške, a manje za metrike koje prirodno jako variraju.

Umjetna inteligencija ne djeluje umjesto Vas. Nadzorna ploča može šest tjedana prikazivati kašnjenje rasporeda crvenom bojom. Ako upravljački odbor ne učini ništa, kašnjenje se nastavlja.

Ovo je minimalni ritam za program u aktivnoj isporuci. Ako bilo koji redak nedostaje, dodajte ga prije svega ostalog.

Kontrola	Minimalna praksa	Vlasnik	Učestalost
Strukturna raščlamba posla	Svaki zadatak ima vlasnika, rok i svoje ovisnosti	Voditelj PMO-a	Ažurira se tjedno
Pregled rasporeda	Označite svaki zadatak koji kasni više od tri dana; provjerite kritični put	Voditelj programa	Tjedno
Praćenje proračuna	Stvarno u odnosu na plan po radnom paketu	Voditelj financija programa	Tjedno, izvještavanje mjesečno
Pregled rizika	Svaki aktivni rizik ima vlasnika, okidač i odgovor	Voditelji radnih tokova	Tjedno
Kontrola promjena	Procjena utjecaja na vrijeme, trošak i resurse prije odobrenja	Predsjedavatelj odbora za promjene	Tjedno ili kako zahtjevi stižu
Pregled proširenja (RISE i GROW)	Odluka konfigurirati, proširiti ili odbiti za svaki gap	Arhitekt rješenja	Svaka dva tjedna
Upravljački odbor	Odluke, a ne status; materijali poslani unaprijed	Izvršni sponzor	Svaka dva tjedna; tjedno u cutoveru i hypercareu

Većina planiranja i kontrole ne propada zato što je metoda bila pogrešna, nego zato što je disciplina napuštena do četvrtog mjeseca. Ritam držite dovoljno malim da ga tim još uvijek provodi u četrnaestom mjesecu. Za sam upravljački odbor pogledajte moj vodič za uspostavu učinkovitog SAP upravljačkog odbora.

Koja je razlika između planiranja projekta i kontrole projekta?

Planiranje izrađuje putokaz: opseg, vremenski okvir, proračun, resurse i rizike. Ono određuje smjer na početku.

Kontrola je kontinuirani posao praćenja napretka u odnosu na taj plan, uočavanja odstupanja, upravljanja ovisnostima i ponovnog postavljanja osnovnog plana kad nastupe formalne promjene. Odvija se svaki tjedan tijekom cijelog trajanja programa.

Većina SAP programa puno ulaže u planiranje, a premalo u kontrolu. Dok se odstupanje pojavi na upravljačkom odboru, već su se nakupili tjedni ili mjeseci troškova oporavka.

Zašto SAP projekti propadaju iako imaju projektni plan?

Zato što nitko ne radi prema planu. Ovisnosti se ne prate, pa kašnjenje jedne radne cjeline tiho blokira drugu. Registri rizika ažuriraju se kvartalno. Promjene opsega odobravaju se neformalno. Upravljački odbor sastaje se mjesečno i vidi sažetke prekretnica koji skrivaju što se stvarno događa na terenu.

Lidl, Hershey i Revlon svi su imali planove. Nedostajala im je aktivna kontrola: iskreno praćenje, rana eskalacija i stvarna reakcija kad su se pojavili znakovi upozorenja.

Kako upravljati širenjem opsega na dugom SAP programu?

Svaka promjena opsega prije odobrenja treba dobiti pisanu procjenu utjecaja: vrijeme, trošak i resursi. Bez nje odobravanje promjene znači odobravanje nepoznanice.

Najučinkovitije je pravilo da svaki dodatak mora istisnuti nešto drugo. To jedno ograničenje tjera poslovne voditelje da iskreno postavljaju prioritete.

Rukovodstvo ga mora podržati. Kad CFO ili COO javno podrži kontrolu promjena, neformalni zahtjevi brzo opadaju. Na RISE i GROW programima odluka o proširenju za svaki gap dodaje tehničku provjeru povrh toga.

Što je strukturna raščlamba posla i zašto je važna za SAP?

WBS dijeli ukupni opseg na isporučevine, svaku s vlasnikom i rokom. Na SAP programu to znači dizajn procesa, konfiguraciju, migraciju podataka, integraciju, testiranje, obuku i cutover, sve razrađeno do zadataka.

Njezina je praktična vrijednost mapiranje ovisnosti. Migracija podataka napaja integracijsko testiranje, koje napaja UAT, koji napaja cutover. Kad jedno kasni, posljedica na sljedeće korake odmah je vidljiva.

Kako RISE with SAP mijenja planiranje i kontrolu projekta?

SAP postaje sudionik isporuke. Upravlja infrastrukturom i tehničkim operacijama, a njegov tim za uspjeh korisnika vodi vlastiti ritam oko prihvaćanja i vrijednosti.

Slijede tri promjene. Potreban Vam je dokumentiran put eskalacije prema SAP-u za probleme platforme koji ne ide preko partnera. Potreban Vam je forum za pregled proširenja ispod upravljačkog odbora koji odlučuje kako se rješava svaki gap prema načelu clean core. I SAP-ov ritam za uspjeh korisnika trebali biste uklopiti u svoje upravljanje, a ne voditi ga paralelno.

Što bi upravljački odbor trebao raditi na SAP programu?

Donositi odluke. Njegov je posao riješiti ono što programski tim ne može: sukobe oko resursa, sporove oko opsega, promjene proračuna i sve što traži međufunkcijsku ovlast. Sastanak odbora koji završi bez odluka bio je statusno izvješće.

Mjesečni odbor na velikom programu ostavlja probleme da čekaju i do četiri tjedna. Svaka dva tjedna minimum je u aktivnoj isporuci, a tjedno u cutoveru i hypercareu. Izvješća o napretku šaljite unaprijed, a sastanak iskoristite za odluke koje iz njih proizlaze.