Alakítsa mérhető üzleti eredménnyé az összetett IT-transzformációt

Mindkettő — és a szerződés még az aláírás előtt megmondja, melyik. A szokásos felállás az, hogy nevesített szenior kollégák az Önök programstruktúráján belül ülnek, nem mellette: transzformációs programvezető, aki a tervért, az irányításért és a felsővezetői riportálásért felel, mellette vezető üzleti és IT-architekt. Ahol a munka nem megvalósítás, hanem felmérés, ott tanácsadás, és jelentéssel meg cselekvési tervvel zárul. A nagyobb programoknál mi vezettük azokat az irányító testületeket, amelyeket magunk terveztünk, és mi vittük az ügyfél nevében a tárgyalást az ellenoldallal — ez már vitel, nem tanácsadás.

Két dokumentumhalmaz találkozásánál. A kiváló oldalról rendszertartományonként előkészített szétválasztási javaslat. Az Önök oldaláról három dolog, aminek léteznie kell, mielőtt bármilyen tervezés elindul: a célarchitektúra, az alkalmazás-landscape és a cél működési modell. Ezek magas szintű tervezési (HLD) workshopokon találkoznak, tartományonként — vállalatirányítás, munkairányítás és döntéstámogatás, mérésügy, üzemirányítás, dokumentumkezelés, infrastruktúra —, és egyetlen tranzíciós tervben és ütemtervben futnak össze. Ha nincs tranzakció, és a saját rendszerparkjuk alakul át, az ennek megfelelő első lépés a szervezet, a folyamatok, a szerződések és a mérőszámok jelen állapotának felmérése, majd hiányelemzés — még mielőtt bárki célképet rajzolna.

A dátum megszűnik határidő lenni, és azzá a korláttá válik, amely a szakmai preferencia fölött áll. Egy általunk vitt kiválásnál az irányelvet eleve két dolog együtteseként írták le — a zárási dátum, és működőképes üzem másnap reggel —, és ebből vezették le a szétválasztás mélységét rendszerosztályonként, nem egységesen: az ügyviteli rendszerek logikai, az üzemviteli rendszerek vegyes alapon váltak szét, mert mindennek a fizikai szétválasztása nem fért volna bele. Amikor az ellenoldal utóbb az üzemviteli rendszerek teljes fizikai szeparációját kérte a zárásra, a kérést nem utasítottuk el és nem is engedtük át automatikusan: három kimondott próbán ment keresztül — jobb-e teljes bekerülési költség szempontjából, veszélyezteti-e a dátumot, és műszakilag jövőbe mutat-e —, és csak az a változás mehetett tovább, amely mindháromon átment. A tervezés közben közös architekt munkacsoportban folyt, kéthetes fix ritmusban, hogy egy hatóköri kérdés két héten belül kapjon választ, ne egy változáskezelési sorban.

Három szenior szerepkör — és rendszerint mindhármat javasoljuk, nem választást kínálunk közülük. Transzformációs programvezető: programterv, irányítás, felsővezetői riportálás, valamint az Önök szakmai csapatainak és beszállítóinak koordinálása. Vezető üzleti architekt: a to-be folyamatkatalógus, a fit-gap elemzés, és a hatókörkontroll egyszerűsítési javaslatokkal együtt. Vezető IT-architekt: architektúra-útiterv, integrációtervezés és -validáció, valamint a napi szakmai kapcsolat az Önök IT-vezetésével. Feszített ütemezésnél mindhármat teljes munkaidőben javasoljuk, nem részmunkaidőben: egy szoros programban elsőként a részidős szenior szerepkörök törnek el.

A cutover maga az átállás — azok az órák és napok, amikor a rendszerek, az adatok és az üzleti folyamatok ténylegesen átkerülnek —, és azért kell hozzá külön terv, mert egyetlen alkalmazásstream sem látja a többi közötti összefüggéseket. Négy szakaszban fut. Tervezés: minden stream kidolgozza a saját migrációs eljárását és műszaki feltételeit, egy dedikált cutover csapat pedig összefésüli ezeket, kezeli a köztük lévő anomáliákat, vagy feladatként visszaadja az érintett streamnek. Próba: a migrációkat a streamekben teszteljük és finomítjuk, a cutover tervet pedig a tapasztaltakhoz igazítjuk. Éles átállás: egyetlen összevont menetrendből vezetve, rendszerenkénti dashboarddal, hogy minden állapota egyszerre látszódjon. És „baby sitting”: nagyjából három hét utána a hosszan elnyúló feladatokra, amelynek a végén formális átadás-átvétel történik az üzemeltetés felé — nem az éles indulásnál.

Nevesítve jelentjük, a következménnyel együtt, és a megkerülő megoldás azelőtt születik meg, hogy válsággá válna. Az előfeltételeket egyetlen összevont ütemterven követjük, dátumozott mérföldkövekkel, és minden területet minden érintett szervezetre lebontva jelentünk: nem érintett, terv szerint, vagy csúszik — megjegyzéssel arról, hogy miért, egyszerű szavakkal, például „ez a beszerzés még el sem indult”. Egy programban, ahol az éles környezet hardverbeszerzése nem indult el, ugyanaz a jelentés tartalmazta a dokumentált B tervet, hogy a függő munka enélkül is haladhasson, és azt is, hogy a másik akadályozott függőséget eszkaláltuk. A továbbgyűrűző következményt pedig leírtuk, nem sejtetni hagytuk: ha ezek a mérföldkövek csúsznak, a következő hullám velük együtt mozdul. Ez az a mondat, amitől egy irányító testület cselekszik.

A PMO a tervet követi. Ami a nagy programokból jellemzően hiányzik, az valami, ami a streamek közötti illesztéseket birtokolja, és egy testület, amelynek van felhatalmazása dönteni. Három dolog jön hozzá. Egy cutover csapat, amely egyik streamhez sem tartozik, és amelynek épp a köztük lévő tér a feladata. Egy architektúra fórum elnökkel, fix idősávval, döntési lappal és döntési nyilvántartással — és annak írásba foglalásával, hogy miről dönthet, és mi marad a projektvezetőé, nehogy a kettő a negyedik hónapban ütközzön. És egy felelősségi mátrix, amely cégek határain ível át — Önök, az Önök IT-szolgáltató cége, az ellenoldal —, szándékosan összeegyeztetve azzal a felelősségi rendszerrel, amely a szétválási szerződésben már szerepel, hogy a kettő ne mondhasson ellent egymásnak.

Az irányítás úgy épül, hogy átadható legyen, ne visszavonható. Egy architektúra fórumot olyan szabálykönyvként adunk át, amely az Önöké: ki elnököl, milyen gyakran ülésezik, hogyan néz ki egy napirendi pont, és sablonokkal a döntési laphoz, a döntési nyilvántartáshoz és az emlékeztetőhöz — beleértve azt a szabályt, hogy egy projekt nem zárható le addig, amíg az architektúra-nyilvántartás nem frissült. Ez az, ami megakadályozza, hogy a dokumentáció az elmenetelünk utáni hónapban elkezdjen romlani. Egy cutover a „baby sitting” időszak után formális átadás-átvétellel zárul az üzemeltetés felé, nem az éles indulásnál. Tanácsadási munkánál pedig az elemzési keret és a sablonok eleve újrafelhasználhatóra készülnek, és az Önök szervezetéhez igazítva kerülnek átadásra — nem a miénkhez.

Kétféle alak, és szándékosan másképp árazva. Egy körülhatárolt felmérés — IT-szervezet, irányítás, szerződések, folyamatok — fix áras, megadott hetekre. Egy transzformációs program szerepkörönként árazott, teljes munkaidős allokációval, egy minimális elkötelezettségi időszak felett kedvezőbb napidíjjal — mert ezek hónapokon átívelő szerepkör-betöltések, nem szállítandók, és ennek az ellenkezőjét állítani senkinek nem használ. A nagyságrendről: az ilyen programok hullámokban futnak, és amelyeket mi vittünk, nagyjából két évet öleltek fel az első tervezéstől az utolsó hullám éles indulásáig — az egyes cutoverek pedig körülbelül nyolc hónappal az átállás dátuma előtt kerültek tervezésre.

A riportokból, még mielőtt máshonnan megtudnák. Az irányító testületi anyagok területenként piros, sárga vagy zöld státuszt visznek, a miérttel egyszerű szavakkal és a továbbgyűrűző következménnyel kimondva — hogy egy itteni csúszás elmozdítja a következő hullámot. Ahol valami valóban akad, ugyanaz az anyag rögzíti, hogy eszkaláltuk, és mi a tartalék terv — nem viszi tovább csendben a következő ülésre. És az kerül a diára, amit senki nem szeretne diára tenni: egy programban előre leírtuk, hogy a legösszetettebb hullám túl összetett ahhoz, hogy végponttól végpontig elpróbálható legyen. Ezt a mondatot egy szállítónak kísértés kihagyni — és pontosan ez az, amire egy irányító testületnek elég korán szüksége van ahhoz, hogy számoljon vele.