Nový softwarový systém je připravený. Vývoj je dokončen, testování proběhlo a termín spuštění se blíží. V tuto chvíli si mnoho majitelů firem oddechne úlevou — to nejtěžší je za nimi.
Není.
V praxi se některé z nejnákladnějších a nejškodlivějších problémů softwarových projektů nevyskytují během vývoje, ale při zavádění. Zaměstnanci, kteří se změně brání, obcházení systému pracujícího paralelně s novým řešením, data, která se nikdy nedostanou na správné místo, a nakonec nástroj, který stál nemalé peníze, ale je využíván jen z části. To nejsou výjimky. To je časté.
Přimět váš tým, aby nový software skutečně přijal — a nejen toleroval — vyžaduje cílené úsilí. Dobrou zprávou je, že toto úsilí není enormní a principy jsou přímočaré.
Proč zavádění softwaru selhává
Než se podíváme na to, co funguje, stojí za to pochopit, proč věci jdou špatně.
Nejčastější příčinou neúspěšného přijetí není technologie. Většina moderního softwaru na míru je spolehlivá a dobře navržena v okamžiku, kdy se dostane k vašemu týmu. Selhání jsou téměř vždy lidská:
Lidé nerozumí tomu, proč ke změně dochází. Když jsou zaměstnanci požádáni, aby začali používat nový systém, aniž by rozuměli důvodu, přirozenou reakcí je podezřívavost. Co bylo špatného na starém způsobu? Jde o to, nás sledovat? Bude naše práce těžší?
Lidé nebyli zapojeni do procesu. Týmy, které neměly žádný hlas při formování nového systému, mají často pocit, že byl postaven podle cizí představy o tom, jak by práce měla vypadat — ne jak skutečně funguje.
Školení bylo nedostatečné nebo špatně načasované. Jediné školení týden před spuštěním bez jakéhokoli navazujícího programu zanechává lidi nepřipravené. Tlak dělat skutečnou práci a zároveň se učit nový nástroj je spolehlivá cesta k frustraci.
Starý systém nebyl plně vyřazen z provozu. Pokud lidé mohou stále spoléhat na tabulky, e-mailové vlákna nebo předchozí software, mnozí to budou dělat. Paralelní systémy rozdělují pozornost, vytvářejí nekonzistenci dat a výrazně zpomalují přijetí.
Odpor byl vnímán jako obstrukce, nikoli jako zpětná vazba. Zaměstnanci, kteří se novému systému brání, často upozorňují na skutečné problémy — funkce, které neodpovídají skutečným pracovním postupům, terminologii, která neodpovídá způsobu myšlení týmu, nebo chybějící funkcionalitu. Odmítnutí této zpětné vazby situaci zhoršuje.
Začněte ještě před tím, než je software hotový
Nejúčinnější řízení změny nezačíná při spuštění. Začíná již během samotného projektu.
I když je systém budován na základě vaší vize jako majitele nebo manažera, lidé, kteří ho budou každý den používat, mají znalosti, které vy možná nemáte. Vědí, které okrajové případy jsou důležité, které procesy jsou složitější, než vypadají na papíře, a jaké informace skutečně potřebují mít po ruce.
Zapojení alespoň několika klíčových uživatelů do fáze návrhu — ukázání jim raných wireframů, provázení je zamýšleným pracovním postupem, ptaní se, co by udělali jinak — slouží dvěma účelům. Za prvé, vytváří lepší software. Za druhé, vytváří interní zastánce, kteří systém chápou, věří mu a mohou pomoci svým kolegům, až přijde čas.
Tito interní zastánci — někdy nazývaní ambasadoři změny — jsou jedním z nejcennějších zdrojů, které máte při zavádění.
Komunikujte proč, než komunikujete co
Když jste připraveni oznámit nadcházející změnu širšímu týmu, odolajte pokušení začít s funkcemi. Nikoho nezajímá, že nový systém má lepší přehled reportů. Záleží jim na tom, zda bude jejich práce těžší.
Komunikace, která funguje, je upřímná ohledně kontextu:
- Jaký problém nový software řeší?
- Jak bylo rozhodnutí o jeho vytvoření přijato?
- Co se změní pro každý tým?
- Co zůstane stejné?
- Co se stane se starým systémem?
- Kdy k tomu dojde a jak vypadá harmonogram?
Jasné odpovědi na tyto otázky, sdělené dříve, než je lidé začnou klást, výrazně snižují úzkost. Nejistota je palivem odporu. Informace jsou protijedem.
Navrhněte školení kolem skutečné práce, ne funkcí
Instinktem mnoha organizací je uspořádat ukázku softwaru — průchod každou obrazovkou a funkcí, vedený tím, kdo systém implementoval. To je zřídkakdy efektivní. Lidé si ze školení, které pasivně sledují, pamatují velmi málo — zejména když jsou úzkostní ze změny.
Školení, které funguje, vypadá jinak:
Je praktické. Lidé se učí software jeho používáním, nikoli sledováním, jak ho používá někdo jiný. Kdykoli je to možné, školení by mělo zahrnovat skutečné úkoly v testovacím prostředí.
Je přizpůsobené rolím. Vedoucí skladu a účetní nemusí rozumět stejným částem systému. Rozdělení školení podle rolí znamená, že každý se naučí to, co skutečně potřebuje.
Probíhá blízko data spuštění. Školení, které se koná dva měsíce před spuštěním, bude z velké části zapomenuto. Školení, které probíhá jeden nebo dva týdny před spuštěním s reálným systémem dostupným krátce poté, se mnohem lépe přemění ve znalosti.
Je podpořeno referenčními materiály. Ne obsáhlými manuály, ale krátkými průvodci pro konkrétní úkoly — „jak zpracovat reklamaci", „jak vygenerovat měsíční zprávu" — které si lidé mohou prohlédnout, když se v prvních týdnech zaseknou.
Zahrnuje jasnou cestu k podpoře. Lidé potřebují vědět, koho se zeptat, když si něco nemohou přijít na kloub. To může být váš interní ambasador, určený kontakt pro pomoc nebo přímá podpora od vašeho vývojového partnera.
Řiďte přechodné období
Prvních čtyři až šest týdnů po spuštění je nejkritičtějších. V této době se formují návyky, lidé narážejí na slabá místa a pokušení vrátit se ke starým způsobům je nejvyšší.
Několik postupů toto období usnadňuje:
Stanovte jasné datum, kdy starý systém skončí. Pokud jste se interně dohodli, že starý systém bude k určitému datu vyřazen, jasně to komunikujte a dodržte to. Indefinitní paralelní provoz je destruktivní.
Pořádejte pravidelné krátké kontrolní schůzky. Stručné týdenní nebo dvoutýdenní rozhovory s vedoucími týmů v prvním měsíci vám dávají včasné varování o problémech, dříve než se zakoření. Co funguje? Kde se to zasekává? Jaké otázky se opakují?
Rozlišujte mezi „potřebuji pomoc" a „toto je skutečně rozbité". Určité tření je při každém novém systému normální. Některé problematické body ukazují na skutečné mezery v softwaru. Váš vývojový partner by měl být v tomto období zapojen, aby mezi nimi rozlišoval a rychle řešil skutečné problémy.
Oslavujte první úspěchy. Když tým dokončí první uzávěrku měsíce pomocí nového systému, když první objednávka projde bez problémů, když sestava, která dříve trvala čtyři hodiny, trvá dvacet minut — uznejte to. Malá uznání posilují přesvědčení, že změna stála za to.
Jak skutečné přijetí softwaru vypadá
Po úspěšném zavedení se software stává neviditelným správným způsobem. Lidé nemyslí na nástroj — jen dělají svou práci. Staré obcházení systému bylo opuštěno. Data jsou na správném místě. Procesy, které systém měl podporovat, skutečně skrze něj probíhají.
To se nestane samo od sebe. Je to výsledek toho, že se k lidské stránce změny přistupuje se stejnou vážností jako k technické stránce.
Organizace, které to zvládají správně, sdílejí společné pochopení: software není řešení. Software je enabler. Řešením je tým, který ho dobře používá.
Plánujete zavádění softwaru, nebo jste stále ve fázi návrhu a přemýšlíte, jak svůj tým nastavit pro úspěch? Ozvěte se nám. Provázíme klienty celým obloukem softwarového projektu — nejen vývojem.