Cutover

Právě řeším na BPM portálu klasické dilema, stokrát předtím už prožité na projektech spojených se změnou IS - provést přechod na nový systém jednou velkou ranou nebo držet po nějakou dobu systémy paralelně, aby se vychytaly mouchy? Geniální plán přechodu však bohužel neexistuje, i když protřelý systémový integrátor vám s ním bude mávat před nosem. Existuje jen špatné, velmi špatné a tragické řešení. Špatné řešení vás bude stát po určitou dobu víc práce. Vždycky. Velmi špatné řešení je, že v době, kdy zažíváte ono údobí zvýšené zátěže, neobjevíte už aspoň nějaký reálný přínos nového IS. A tragedie spočívá v tom, když mouchy proštípají zákazníka. Cutover plodí hmyz vždy trojího typu. První mušky vylézají z neodladěné funkcionality nového IS. Ty měly být odstraněny při funkčních testech. Jenže ty zdaleka nezachytí všechny legrace reálných situací. Druhé se líhnou z nepovedené či neprovedené integrace. Nemyslím jen tu systémovou, myslím hlavně procesní. Že byznys case je možno protáhnout celou sekvencí tak, jak prolézá všemi podporujícími systémy, nejen tím měněným. Tyto mouchy měly pobít integrační testy. Už jste viděli někdy takové, které opravdu prochází celý proces? Ve všech jeho větvích? Třetí čeledi hmyzu jsou nejzáludnější a líhnou se v myslích obsluhy. Ta zatížena letitými návyky hyperkriticky porovnává ubohost a nepohodlnost nového IS se starým dobrým systémem odstavovaným. Uživatelé jsou sice již od počátku analýz vtahováni do hry, aby autorský komplex fungoval co repelent, ale pokud je pak delší dobu (měřeno ve dnech, ne týdnech!) necháte pracovat paralelně na obou systémech, bažina návyku vyplodí pochybnosti další a ani luxusní uživatelské školení a podpora už je nepobijí. Ono totiž přemýšlet o tom, že budu něco dělat jinak - a pak skutečně muset něco začít dělat jinak - je rozdíl jako mezi sociální demokracií a demokracií. Takže až zvládnu cutover, napíšu, jakou roli má v tomto kritickém bodu přechodu byznys analytik.