Od implicitních znalostí k explicitním: Vrstvy projektu

Implementace softwaru je náš denní chléb. Jak společnost rostla, zjistili jsme, že potřebujeme některé zavedené postupy formalizovat. Hned vysvětlím proč. Pokud pracujete ve stabilním týmu, některé věci dobře fungují prostě proto, že máte v týmu zkušené lidi, kteří vědí, co mají dělat: mají tzv. implicitní znalosti, tedy znalosti, které nejsou nikde zaznamenané. Problém implicitních znalostí spočívá v tom, že není snadné je sdílet. Jistě, můžete si s kolegou sednout a vyzpovídat ho. Co ale budete dělat v situaci, kdy tým začne rychle růst a váš zkušený kolega nestíhá pokrýt poptávku po svém know-how? Takové výzvě čelí dříve či později každá rostoucí firma.

I my jsme se dostali do situace, kdy bylo nutné naše know-how stále častěji sdílet, ať už novým kolegům, nebo konzultantům partnerských společností. To byla ideální příležitost sepsat naše znalosti do srozumitelného rámce. Identifikovali jsme pět vrstev, které je nutné u každého projektu řídit. Myšlenka vrstev je inspirována klasickým projektovým nástrojem WBS (work breakdown structure). Jednotlivé vrstvy jsou jasně definované samostatné celky, které se ale navzájem prolínají, podporují a doplňují.

Rozdělení do vrstev usnadňuje komunikaci. Od začátku je srozumitelné, že projekt sestává z několika propojených bloků. Jasně definujeme vstupy a výstupy každé vrstvy. Víte tedy, co se od vás očekává a jaký výstup dostanete. Víte také, jaké materiály jsou pro každou vrstvu k dispozici. Jelikož vrstvy jsou kompaktní celky, je možné je v případě potřeby delegovat na různé lidi.

Úspěšný implementační projekt by měl mít následujících pět vrstev

Jaké vrstvy by měl mít implementační projekt? Podle nás následující: technická, datová, metodická, projektová a transformační. Tento výčet nelze brát dogmaticky. Jsou projekty, kde je vrstev více či méně. Pokud jde o jednoduchou implementaci, význam projektové vrstvy bude menší. Pokud v rámci implementace řešíte hodně customizací, přibude vám další vrstva. Důležité je právě porozumění, se kterými vrstvami pracujete. Řada lidí má totiž tendenci zaměřit svou pozornost pouze na technickou a datovou vrstvu. I když tyto jsou nezbytné pro úspěch implementace, teprve kombinace všech vrstev zaručí, že z investice do softwaru získáte největší hodnotu.

Technická vrstva

Software je samozřejmě potřeba nainstalovat a nakonfigurovat. Vy i dodavatel potřebujete rozumět technickému kontextu, do kterého software nasazujete a jakým způsobem bude integrován do zbytku infrastruktury. Nezapomeňte ale, že instalací to celé nekončí. Musíte si zodpovědět také na otázku, jak budete software provozovat, kdo se bude starat o pravidelné aktualizace, zda máte k dispozici funkční testovací prostředí a zda máte jasno, jak postupovat v případě chyb a incidentů. U SaaS aplikací si jasně definujte technické parametry řešení, za které vám dodavatel ručí. Jaká je dohodnutá dostupnost aplikace? Zálohuje dodavatel vaše data? Jaká je garantovaná rychlost aplikace?

Datová vrstva

O každém systému platí, že je pouze tak dobrý jako data uvnitř. Jednou z častých chyb při implementaci je nerealistické očekávání ohledně údržby dat v systému. Základní mantrou je, aby vstupovalo do systému pouze to, co dokážete automaticky či ručně aktualizovat tak, aby systém zůstal konzistentní a odpovídal realitě. Pokud v CRM evidujete zakázky, měli byste mít jasně popsaná související workflow. Které informace získáte automaticky? Na základě jakých spouštěčů? Která data musíte doplnit ručně? Jak zajistíte, aby se na to nezapomnělo?

Potřebujete také jasnou strategii na to, jak budete do systému zadávat úvodní data. Pokud například implementujete systém pro IT Asset Management, na začátku vás čeká soukromý audit IT majetku. Jak budete výstupy nahrávat do systému? Jak je následně budete aktualizovat? Jaká data v systému budou již defaultně zadaná od dodavatele v momentu, kdy ho nainstalujete?

Metodická vrstva

Když svoje dítko učíte sekat dříví, dáte si dobrý pozor na to, abyste ho naučili, jak správně a bezpečně používat sekeru. Nikdo by dítěti nedal do rukou ostrý nástroj, ať si s ním už nějak poradí. Řada firem se ale přesně takto chová u implementace softwarových nástrojů. Každý nástroj nasazujete v určitém kontextu a máte od něj konkrétní očekávání. Potřebujete se ujistit, že nástroj v daném kontextu může fungovat a dodavatel mu rozumí.

Například čekáte, že nový CRM systém pomůže marketingovému a obchodnímu oddělení lépe zachytávat poptávku a řídit obchodní proces, což by mělo pomoci obchodníkům realizovat více prodejů. Software může být k takovému úkolu dokonale vybavený, pokud ale nemáte příslušné know-how, nevíte, jak nastavit interní procesy a jaké jsou nejlepší praktiky, software sám o sobě vás nespasí.

V rámci metodické vrstvy se kritickým okem potřebujete podívat na zavedené procesy a položit si otázku, zda nejsou zastaralé. Možná vám nový software otevírá možnosti dělat věci jinak a efektivněji. Při implementacích Asset Managementu například řešíme věci jako jmenné konvence pro nové počítače, úpravy procesu odchodu zaměstnanců či řízení životního cyklu hardware. Jde o to, že žádný software není samospasitelný a bez optimalizovaných procesů může dokonce napáchat více škody než užitku.

Projektová vrstva

Touto vrstvou se myslí klasické projektové řízení, kdy pomocí běžných projektových nástrojů hlídáte, abyste projekt zvládli včas, v daném rozsahu a za danou cenu.

Transformační vrstva

Jestliže metodická vrstva má za úkol zajistit, že software budete používat správně a v souladu s nejlepšími praktikami, transformační vrstva hlídá, aby se tyto změny zhmotnily v reálných byznysových výsledcích. S určitou nadsázkou se dá říct, že transformační vrstva má motivační a marketingovou úlohu. Jde vám o to, aby se proces ujal, lidé ve firmě ho přijali za svůj, protože vnímají reálnou hodnotu. Šetří jim práci, vydělává peníze, zjednodušuje život…

Mezi vaše úkoly zde patří porozumět motivaci lidí ke změně, řídit očekávání a prezentovat vhodně hodnotu celého projektu tak, aby ho zaměstnanci pozitivně přijali. S novým softwarem je vždy spojena určitá míra frustrace. Pokud nezískáte podporu koncových uživatelů, šance na úspěch se rázem ztenčí.

Zároveň v rámci transformační vrstvy potřebujete stále hledět na cíle, kvůli kterým se software kupoval. Vrátila se vám investice do softwaru? Pokud ne, co tomu brání?

Závěr

Ke koupi nového softwaru můžete mít spoustu dobrých důvodů. Někdy si ale od softwaru slibujeme, že vyřeší všechny naše problémy. Abyste získali to, co jste si od softwaru na začátku slibovali, potřebujete zhodnotit nejen technické aspekty projektu, ale také širší kontext, ve kterém software nasazujete.

Jan Škrabánek Autor článku je konzultantem společnosti ALVAO.