Sedam konzultantskih okvira za isporuku SAP-a i AI-ja

Kad SAP ili AI program zapne, uzrok je obično strukturni, a sedam jednostavnih okvira ga pronalazi. Mapirajte trenutačno stanje. Dogovorite tko o čemu odlučuje pomoću RACI-ja. Povežite rad s poslovnim sposobnostima. Pronađite temeljne uzroke metodom pet zašto. Rangirajte zahtjeve pomoću MoSCoW-a. Rangirajte rizike prema tome što stvarno može zaustaviti program. Provedite pravi post-mortem nakon svake faze. Ovaj je vodič za voditelje programa, konzultante i sponzore na isporukama SAP-a i AI-ja. Počnite s tablicom u nastavku: pronađite svoj simptom i prvo upotrijebite odgovarajući okvir.

Srednje velika medijska tvrtka u Kataru uvodila je SAP u nekoliko regija. Financije i nabava išle su u rad u prvoj fazi. Željela je i AI modele za prognoziranje u svom izvještavanju.

Do šestog tjedna počela su se uvlačiti kašnjenja. Poslovni korisnici govorili su da su potpisali zahtjeve, ali da im i dalje nije jasno što dobivaju. Predloženi su AI slučajevi uporabe, a nitko nije mogao reći tko je vlasnik podataka ni kako će se izlaz koristiti. Ljudi su na sastanke dolazili kasno ili uopće ne.

Bila je to ona međufaza. Prerano da se nazove neuspjehom. Prekasno da se pretvaramo da će se samo riješiti.

Okvire smo primijenili korak po korak. Nije sve bilo odmah dobrodošlo. Neke su sesije bile tihe. Druge su skrenule s puta. No struktura je olakšala posao: tim je prestao kružiti, backlog je postao upravljiv, a AI slučajevi uporabe dobili su prave vlasnike. Projekt je pušten u rad osam tjedana kasnije od plana. Ne savršeno. Ali je stigao do cilja, a druga je faza počela na boljim temeljima, s manje nepoznanica.

Verzije svih sedam koristio sam kroz 23 godine isporuke SAP, Oracle i AI programa u Zaljevu, Europi i šire. Nijedan nije egzotičan. Svi funkcioniraju ako ih primjenjujete disciplinirano, a ne kao vježbe dokumentiranja.

Povežite simptom s okvirom:

Simptom koji vidite	Okvir	Što proizvodi	Tipičan trud
Korisnici su potpisali zahtjeve, ali su i dalje zbunjeni	1. Mapiranje trenutačnog stanja	Zajednička karta kako se posao danas stvarno odvija	3 do 5 dana radionica
Odluke se stalno odbijaju između sastanaka	2. RACI za kritične odluke	Imenovani vlasnici odluka za 20 do 30 ključnih poteza	Jedna radionica, zatim provedba
Sponzori su se odvojili od „IT projekta”	3. Mapiranje sposobnosti	Napredak prikazan kao poslovne sposobnosti	Ugrađeno u fit-to-standard
Isti tip greške stalno se vraća	4. Pet zašto	Temeljni uzrok koji možete promijeniti	Jedna moderirana sesija po problemu
Sve je označeno visokim prioritetom	5. MoSCoW	Rangiran opseg s realističnim popisom za Must have	Jedna zajednička sesija poslovanja i IT-a
Registar rizika izgleda dobro, ali tim je napet	6. Rangiranje rizika	Zasebni popisi rizika koji zaustavljaju program i onih koji samo smetaju	Tjedni pregled od 30 minuta
Iste se pogreške ponavljaju fazu za fazom	7. Post-mortem	Tri do pet promjena s vlasnicima	Pola dana nakon svake faze

Najčešća pogreška na početku programa je skok na rješenje prije dokumentiranja onoga što postoji. Procesna dokumentacija obično je zastarjela. Ljudi opisuju kako stvari trebaju funkcionirati, a ne kako funkcioniraju. Jaz između to dvoje je mjesto gdje žive problemi implementacije.

Korisna karta trenutačnog stanja traje tri do pet dana radionica s ljudima koji obavljaju posao, a ne s onima koji njima upravljaju. Obuhvaća korake procesa po redu, sustave korištene na svakom koraku, ručne intervencije i zaobilazna rješenja te tokove podataka među odjelima.

Tražite ručne korake koje nitko ne spominje jer su postali nevidljivi, zaobilazna rješenja koja traju toliko dugo da se već računaju kao standardni proces te probleme kvalitete podataka za koje svi znaju, a nitko ih nije popravio.

U Kataru je karta trenutačnog stanja nastala iz radionica s korisnicima, a ne iz dokumentacije. Tu se počela razbistravati zbrka oko potpisanih zahtjeva.

Napravljena kako treba, karta trenutačnog stanja traje dane. Tretirana kao vježba prikupljanja dokumenata, traje mjesece i proizvodi nešto čemu nitko ne vjeruje.

Prava odlučivanja strukturni su element koji najčešće nedostaje u SAP i AI projektima. Svatko ima mišljenje. Nitko ne zna tko donosi konačnu odluku. Odluke idu na sljedeći sastanak, koji ih prepušta upravljačkom odboru, koji ih vraća radnoj skupini.

RACI matrica (Responsible, Accountable, Consulted, Informed, odnosno izvršitelj, nositelj odgovornosti, konzultirani i informirani) svakoj odluci i isporuci daje vlasnika. Jedna je osoba nositelj odgovornosti (Accountable) i može biti i izvršitelj ili to delegirati. Konzultirani daju doprinos. Informirani čuju ishod.

Praktična verzija: navedite dvadeset do trideset najkritičnijih odluka u trenutačnoj fazi i provedite RACI radionicu uz prisutnost donositelja odluka. Gdje je neka dodjela osporena, nešto ste saznali: ili je upravljanje nejasno ili se vodi politička borba oko ovlasti. U oba slučaja to iznesite u drugom tjednu, a ne u četrnaestom.

RACI bez provedbe je dekoracija. Imena moraju odgovarati ljudima sa stvarnom ovlasti. Dodjela odgovornosti nazivu uloge umjesto imenovanoj osobi način je izbjegavanja razgovora o tome tko je vlasnik rizika.

SAP i AI programi stvaraju mnogo tehničke aktivnosti koju poslovanje ne vidi. Veza između onoga što se gradi i ishoda koji treba isporučiti postaje apstraktna. Sponzori se povlače, a „IT projekt” dobiva krivicu za kašnjenja koja su zapravo poslovne odluke.

Mapiranje sposobnosti povezuje funkciju sustava s poslovnom sposobnošću: što organizacija treba biti u stanju činiti. Umjesto praćenja je li tijek rada narudžbenice konfiguriran, pratite može li organizacija obraditi račune dobavljača unutar tri dana od primitka. Konfiguracija je mehanizam. Sposobnost je ishod.

U SAP Activate to se preslikava na fit-to-standard radionice u fazi Explore. Svaki proces u opsegu je sposobnost, a svaki jaz između SAP standarda i tražene sposobnosti je odluka: prihvatiti standard, konfigurirati varijantu ili proširiti. Zadržavanje razgovora na razini sposobnosti drži pažnju poslovanja kroz izgradnju i otkriva sposobnosti za koje su svi pretpostavljali da su u opsegu, a nitko ih nije potvrdio.

Kad se ista vrsta problema stalno pojavljuje kroz sprintove ili faze, krpanje svake pojave ne pomaže. Uzrok je uzvodno.

Pet zašto najjednostavniji je alat za temeljni uzrok. Pitajte zašto se problem dogodio, zatim zašto se dogodilo to, sve dok ne dođete do nečega što možete promijeniti. Pet krugova obično dođe do pravog uzroka. Dva kruga obično stanu na simptomu.

Primjer iz migracije podataka. Probno učitavanje ima pogreške u kvaliteti podataka: to je simptom. Zašto? Izvorni izvadak imao je pogrešna preslikavanja polja. Zašto? Specifikaciju preslikavanja nikad nije pregledao poslovni vlasnik podataka. Zašto? Vlasnik podataka imenovan je tek nakon završetka preslikavanja. Zašto? Plan nije učinio uključivanje vlasnika podataka ovisnošću za preslikavanje. To je temeljni uzrok, a rješenje je odluka o upravljanju, a ne ispravak podataka. Moj tekst o tome zašto migracija SAP podataka zakazuje pokazuje koliko se često pojavljuje upravo taj lanac.

1. 01Pogreške probnog učitavanjaSimptom
2. 02Pogrešna preslikavanja poljaZašto je učitavanje palo?
3. 03Specifikacija nikad pregledanaZašto su preslikavanja bila pogrešna?
4. 04Vlasnik imenovan prekasnoZašto specifikacija nije pregledana?
5. 05Plan propustio ovisnostZašto je vlasnik kasnio?

Temeljni uzrok je odluka o upravljanju, a ne ispravak podataka

Analiza temeljnog uzroka u prostoriji bez okrivljavanja daje iskrene odgovore. U prostoriji u kojoj se traže krivci daje obrambeni stav. Posao moderatora je držati razgovor na procesu, a ne na ljudima. Moj vodič za strukturirano razmišljanje i rješavanje problema pokriva kako raščlaniti neuredan problem prije nego što počnete pitati zašto.

Svaka rasprava o opsegu SAP-a i AI-ja ima zamku konsenzusa. Nitko ne želi praviti kompromise, pa sve postaje visoki prioritet. Kad je sve visoki prioritet, ništa nije, a tim za izgradnju pokušava napraviti sve.

MoSCoW (Must have, Should have, Could have, Won't have this time) prisiljava na izbor. Must have je minimum potreban za puštanje u rad. Should have je važan, ali ne blokira. Could have je poželjan ako vrijeme i proračun dopuštaju. Won't have je izričito odgođen.

Disciplina je u liniji Must have. Prvi prolaz MoSCoW vježbe obično u Must have stavi daleko previše. Smjernice DSDM-a iz Agile Business Consortiuma, odakle MoSCoW potječe, postavljaju gornju granicu od 60 % truda na Must have stavke i upozoravaju da veći udio ugrožava isporuku. Jaz između prvog prolaza i realističnog popisa uglavnom su neprovjerene pretpostavke.

MoSCoW provodite s poslovanjem i tehnologijom u istoj prostoriji. Provedeni odvojeno, IT-ov popis Must have i poslovni popis Must have ispadnu nespojivi, a nitko ih ne usklađuje dok konfiguracija ne počne.

Većina registara rizika dugački su popisi ocijenjeni vjerojatnošću i utjecajem, pregledavani mjesečno, s RAG statusima koji se rijetko mijenjaju. Bilježe rizik, ali ne pokreću akciju.

Odvojite rizike koji mogu zaustaviti program od rizika koji ga čine težim. Prva skupina treba vlasnike, planove odgovora i tjednu vidljivost. Druga treba praćenje.

U Kataru je registar rizika na papiru izgledao dobro, ali su svi bili na rubu. Brza matrica rizik-utjecaj, pregledavana tjedno umjesto mjesečno, iznijela je prave brige.

Registar koji izgleda dobro dok je tim napet gotovo uvijek nešto skriva. Registar nije istina; istina su razgovori oko njega. Tjedni pregled koji pita „što Vas je sinoć držalo budnim?” otkriva više od pitanja „kakav je status stavke 14?”. Moja matrica procjene rizika SAP projekta daje predložak za ocjenjivanje i vlasništvo.

Post-morteme nakon faze ili puštanja u rad sprječavaju da se iste pogreške ponove u sljedećoj fazi. Ujedno su prva stvar koja se reže kad je raspored pod pritiskom.

Koristan post-mortem postavlja četiri pitanja. Što smo planirali postići i što smo postigli? Što je prošlo dobro i treba se ponoviti? Što je prošlo loše i što je to uzrokovalo? Što bismo napravili drukčije? Treba završiti s tri do pet konkretnih akcija s vlasnicima, a ne dokumentom koji sažima što se dogodilo.

Uobičajen propust je vježba opravdavanja u kojoj timovi brane odluke umjesto da ih preispituju. Držite se usmjerenosti prema naprijed. Pitanje nije tko je uzrokovao kašnjenja u šestom tjednu. Pitanje je koja strukturna promjena sprječava njihov povratak u sljedećoj fazi.

U Kataru je post-mortem proveden odmah nakon puštanja u rad i bio je usmjeren na akciju, a ne na krivnju. To je velik dio razloga zašto je druga faza počela na boljim temeljima.

Okviri se nisu promijenili. Promijenilo se kako se primjenjuju, na tri načina.

Izrada nacrta postala je brža; slušanje nije. AI alati sada transkripte radionica i procesne dokumente pretvaraju u prvu kartu za nekoliko minuta, a SAP Cloud ALM može izraditi nacrte zahtjeva iz transkripata fit-to-standard radionica. Same radionice traju koliko su oduvijek trajale, jer je slušanje cilj. Vrijeme uštedjeno na nacrtu treba uložiti u propitivanje karte s ljudima.

RACI nacrti stižu gotovi, a težak dio ostaje. AI asistent opće namjene izradit će RACI iz povelje i popisa radnih paketa u minuti. Disciplina se pomiče na pregovaranje: svaka ćelija traži pravi razgovor o ovlasti i eskalaciji. Vrijeme uštedjeno na izradi nacrta treba uložiti u te teške razgovore.

MoSCoW postaje teži s AI-jem u prostoriji. AI rangiranje zahtjeva je uvjerljivo, uglađeno i često pogrešno u pogledu lokalne politike. Konzultanti koji ga prihvate bez propitivanja izrađuju lošije popise prioriteta od konzultanata koji kreću s praznim listom. AI nacrt tretirajte kao polazište, nikada kao odgovor.

Prosudba povrh ovih okvira sada vrijedi više, a ne manje. Ako te vještine gradite kao konzultant, karijerni putovi na SAPopediji pokazuju koje su važne u kojoj fazi SAP karijere.

Što su konzultantski okviri i zašto ih SAP projekti koriste?

To su strukturirani pristupi analizi, odlukama i rješavanju problema. Na SAP i AI programima daju voditeljima poslovanja, arhitektima, voditeljima projekata, integratorima i sponzorima zajedničku metodu.

Bez nje svaka skupina prelazi na vlastiti mentalni model: ishode procesa, arhitekturu ili vremenski plan i resurse. Okviri kao što su mapiranje trenutačnog stanja, RACI i MoSCoW čine neslaganje izričitim i rješivim. SAP Activate je sam okvir za faze, kontrolne točke i isporuke; ovih sedam funkcionira unutar njega i bavi se strukturnim i ljudskim pitanjima koja sama metodologija ne rješava.

Kako mapiranje trenutačnog stanja funkcionira u SAP implementaciji?

Dokumentira kako procesi stvarno funkcioniraju prije početka konfiguracije, za razliku od toga kako kaže postojeća dokumentacija da bi trebali. Gradite ga na radionicama s ljudima koji vode procese: koraci, sustavi, predaje, ručne intervencije i zaobilazna rješenja.

Hrani fit-to-standard radionice u fazi Explore SAP Activate, gdje trenutačno stanje postaje osnovica koja se uspoređuje sa SAP-ovim standardnim procesima. Dovršite ga prije početka tih radionica, inače Vaša analiza jaza počiva na pretpostavkama.

Što je MoSCoW prioritizacija i kada se koristi u SAP programima?

MoSCoW razvrstava zahtjeve u Must have, Should have, Could have i Won't have this time. Must have je minimum za puštanje u rad; Won't have su izričito isključeni kako se ne bi vratili.

Najkorisniji je u fazi Explore, kad nalazi fit-gap analize pokreću odluke o ekstenzijama, i u fazi Realize, kad se greške i poboljšanja natječu za vrijeme izgradnje. Uobičajen problem je previše Must have stavki u prvom prolazu. DSDM preporučuje najviše 60 % truda na Must have stavkama; moderator koji propituje svaku, uz poslovanje i IT u istoj sesiji, dovest će Vas tamo.

Kako provesti učinkovit pregled rizika na SAP projektu?

Kao razgovor, a ne statusno izvješće. Počnite otvorenim pitanjima kao što je „Što Vas ovaj tjedan najviše brine, a nije u registru?” prije nego što prođete registar.

Za svaki rizik visokog prioriteta pitajte što se promijenilo, koja je akcija poduzeta, poboljšava li se trend i odgovara li plan odgovora još uvijek. Rizici koji tjednima stoje na istoj ocjeni bez akcije često su podcijenjeni. Pregledavajte tjedno u aktivnim fazama, a upravljačkom odboru pokažite prvih pet sa statusom i sljedećom akcijom, a ne cijeli registar.

Što čini koristan post-mortem nakon SAP puštanja u rad?

Konkretne promjene na koje se može djelovati za sljedeću fazu. Sažetak onoga što se dogodilo je zapis, a ne post-mortem.

Obuhvatite što ste namjeravali postići, što ste postigli, što je funkcioniralo, a što nije. Probijte se ispod površinskih objašnjenja poput „nismo imali dovoljno resursa”: je li plan resursa bio pogrešan, opseg pogrešan ili put eskalacije pokvaren? Završite s tri do pet promjena, svaka s vlasnikom i datumom.

Kako konzultantski okviri pomažu kod AI implementacije u SAP okruženjima?

AI projekti zakažu iz istih strukturnih razloga kao SAP projekti, plus nekoliko vlastitih: podaci bez vlasnika, nedefinirane mjere uspjeha i nedogovoren proces za djelovanje na temelju izlaza.

Mapiranje trenutačnog stanja pokazuje tko je vlasnik podataka koje model treba i koliko su dobri. RACI odgovara tko validira izlaz, tko odlučuje djelovati na temelju njega i tko je odgovoran kad je pogrešan. MoSCoW odvaja bitne slučajeve uporabe od zanimljivih. Počnite s dva ili tri bitna slučaja uporabe s jasnim vlasnicima i mjerama uspjeha, a ne s petnaest odjednom.