facebook LinkedIN LinkedIN - follow
IT SYSTEMS 1-2/2014 , ERP systémy

Quality assurance – maják v rozbouřeném moři



DeloittePodle odhadů renomované společnosti Gartner končí dvacet až třicet pět procent implementací ERP systémů nezdarem. Běžný zákazník, který implementuje nový rozsáhlý informační systém jen jednou za mnoho let, přirozeně nemůže mít dostatek zkušeností a adekvátních zdrojů na to, aby dokázal být dodavateli rovnocenným partnerem.


Večírek

V okamžiku, kdy se po trhu rozkřikne zpráva, že chce nějaká společnost implementovat nový informační systém, začne okamžitě okolo rozhodujících zástupců této společnosti kroužit hejno prodejců, potenciálních dodavatelů. Nastává období přátelských setkání, malování situace na růžovo, idealizování služeb a produktů, pozvánek na společné cestování za sportovními a kulturními akcemi do zahraničí, cestování na referenční návštěvy.

Smlouva s vybraným dodavatelem, implementačním partnerem, je podepsaná, bouchá šampaňské. Začíná se připravovat projekt a postupně formovat implementační tým. Uvolněná optimistická nálada, vydatně podporovaná sliby a optimismem dodavatele, je cíleně šířena i do zainteresovaných nižších pater společnosti. V hledáčku implementačního partnera se ocitá střední a nižší management a klíčoví specialisté zákazníka.

Projekt začíná úvodním projektovým setkáním implementačního týmu, zpravidla v atraktivních restauračních prostorách, kde vedení zákazníka či hlavní projektový sponzor zdůrazní význam projektu pro celou společnost, zástupce dodavatele věští úspěch projektu a za vydatné konzumace alkoholu dochází k úvodnímu seznamování implementačního týmu.

Vystřízlivění

Dodavatelé mívají nad zákazníkem značnou informační převahu. Mají velmi komunikačně zdatné account manažery, podobnými projekty si již několikrát prošli a přesně vědí, jak v různých situacích bude zákazník reagovat. Běžný zákazník bývá z pohledu implementace v nevýhodě. Většinou nedisponuje dostatečnou relevantní zkušeností z velkých implementací informačních systémů, a to zejména z důvodu relativně dlouhého životního cyklu balíkových informačních systémů (pro ilustraci, životnost ERP aplikace dosahuje dle společnosti Gartner typicky deset let). Dále bývají zaměstnanci zákazníka souběžně s implementačním projektem alokováni i na svou běžnou práci, či v horším případě jde implementace zcela nad rámec jejich každodenních pracovních povinností. Zákazník rovněž nedisponuje vlastní implementační metodiku, kterou by byl ochoten dodavatel použít, či nezná dodavatelovu implementační metodiku.

Zákazník si zpravidla uvědomí své handicapy až v okamžiku, kdy nastanou první nepříjemné problémy. Zpočátku se problémy snaží řešit jednotlivé pracovní týmy. Když se pracovní tým neshodne na řešení, tak se rozpor mezi zástupci zákazníka a dodavatele eskaluje o jednu projektovou úroveň výš, typicky na projektového manažera. V realitě nastávají i situace, kdy i na úrovni projektových manažerů se problém nepodaří vyřešit, a tak je eskalace posunuta o další patro výš, například na projektový řídicí výbor. S narůstajícími eskalačními patry se však postupně vytrácí porozumění podstatě problematiky a zvyšuje se riziko rozhodnutí spíše na základě pocitů než na základě faktů. Po několika konfliktních situacích a jejich neuspokojivém řešení si může zákazník začít uvědomovat, že mu projekt začíná přerůstat přes hlavu a že s tím bude potřeba něco udělat.

Náprava

Zákazník se zpravidla začne rychle poohlížet po jednotlivých zdrojích, kterými by doplnil a rozšířil svou část implementačního týmu. Výběr se děje v krátkém čase a ve spěchu, kdy významným kritériem pro výběr je okamžitá dostupnost daného poptávaného zdroje. Nová posila má po nástupu na projekt málo času na získání potřebných informací, zaškolení a zorientování se v projektové situaci. Navíc ne všechno bývá zdokumentováno, mnoho důležitých skutečností je ukryto jen v hlavách klíčových projektových členů. Získání těchto informací pak stojí cenný čas stávajících členů projektových týmů.

Dalším možností, jak se pokusit vrátit projekt zpět na správnou cestu, může být najmutí externí subjektu pro zajištění jakosti, tzv. quality assurance (dále také zkráceně QA).

Jak dodavatel reaguje na najmutí QA?

K najmutí QA se různí implementační partneři staví rozdílně. Na základě zkušenosti z praxe lze konstatovat, že většina implementačních partnerů zákazníka od najmutí QA odrazuje, zatímco zbytek implementačních partnerů v QA vidí možnost nestranného hodnocení vzniklých projektových situací. Implementační partneři se mohou obávat, že je QA bude svou činností brzdit v jejich práci a bude zbytečně poukazovat na věci, které implementační partner zanedbal z důvodu řešení záležitostí s vyšší prioritou. Z toho důvodu může dodavatel tíhnout k tomu, že bude zákazníkovi podsouvat, že přínos QA je diskutabilní, protože QA nemá vhled do implementačního detailu nebo vnese do projektu chaos svými zjištěními nezatíženými historickým vývojem a historickými kompromisy. Argument nedostatečného vhledu do implementačního detailu lze považovat za irelevantní, neboť hlavním úkolem QA je kontrola dodržování procesů a standardů jakosti, nikoli posuzování jakosti výsledného díla, to by mělo zajišťovat spíše quality control. Naopak pohled „zvenčí“ nezatížený historickým vývojem a historickými kompromisy napomáhá objektivnějšímu vnímání aktuálních problematických situací, a vytváří tak předpoklady pro jejich úspěšné řešení.

Dojde-li k najmutí QA, proti kterému se stavěl dodavatel, pak může v praxi docházet k bojkotu práce QA takovým způsobem, kdy dodavatel „omylem“ zapomíná opakovaně posílat důležité výstupy i na QA, nebo je odmítá předat úplně, či je dodává na poslední chvíli například před schůzkou, kde se dokument bude projednávat nebo před vypršením termínu pro připomínkování výstupu. Jinou formou obstrukce může být neochota či zdlouhavé přidělování přístupů do technických prostředků, které zajišťuje dodavatel.

K čemu je QA dobré?

Jak jsme zmínili v úvodu, podle Gartneru skončí dvacet až třicet pět procent implementací ERP systémů nezdarem. Podle analytiků také osmdesát procent implementací neskončí v požadovaném čase a ve stanoveném rozpočtu. Pod nezdarem nerozumí Gartner jen krajní situaci zastavení projektu, ale také situaci, kdy výsledky projektu zásadním způsobem nesplní původní zadání, například ve formě dodání menšího než požadovaného rozsahu projektu, nesplnění klíčových business požadavků apod. Analýzy Gartneru ukazují na skutečnost, že nezdar implementace je často způsoben spíše organizačními aspekty implementačního projektu než výběrem nevhodného balíkového informačního systému. Za organizační aspekty nezdaru implementace lze považovat nedostatečnou podporu projektu vrcholovým managementem společnosti, nedostatečný rozpočet projektu, nedostatečnou podporu řízení změn a školení či najmutí nedostatečně kvalifikovaného projektového manažera.

Právě v hlídání procesních a organizačních aspektů projektu tkví jádro činnosti QA. Lze na něj s trochou nadsázky nahlížet jako na „projektového policistu“, který má v popisu práce „pomáhat a chránit“. QA na jednu stranu hlídá, kontroluje a upozorňuje na nesrovnalosti a odchylky od metodik, definovaných procesů, standardů, stanovených milníků apod., na druhou stranu by ale mělo být schopno i povzbudit a rámcově poradit na základě zkušenosti z jiných obdobných projektů. Nemělo by však řešit věcnou implementační problematiku (například co a jak v konkrétní situaci implementovat), aby se nedostalo do konfliktu zájmů. QA by mělo konat tak, aby jeho zjištění byla transformovatelná do skutečných, v optimálním případě i měřitelných opatření, a nikoli konat tak, aby si svým konáním jen vytvářelo alibi typu „já jsem vám to přece říkal“ pro případ neúspěchu.

Jak vybrat správné QA?

Samotný výběr QA však nemusí projekt zachránit, pokud je proveden uspěchaně či nekompetentně. První věc, kterou je potřeba si uvědomit, je okamžik zapojení QA do projektu. Najímá-li si zákazník QA až během běžícího projektu, v okamžiku opakovaného výskytu obtížně řešitelných problémů, může už být pozdě. V tomto případě již QA nemůže ovlivnit tolik věcí, jako by bylo schopno ovlivnit, kdyby bylo najmuto již na začátku projektu.

QA lze zapojit do projektu již ve fázi jeho přípravy. QA může pozitivně přispět k optimálnímu výběru implementačního partnera, kde může uplatnit svou znalost trhu či zkušenosti s daným uchazečem na jiných projektech. Mimořádně významným přínosem může být podpora zákazníka během kontraktační fáze ve formě připomínkování implementační smlouvy či znalost obvyklých ustanovení implementačních smluv z obdobných projektů.

Před výběrem QA je nutné, aby si zákazník ujasnil základní požadavky na QA a vytvořil svoji představu o jeho fungování, rozsahu pravomocí, kterými bude na projektu disponovat, množství požadovaných zdrojů a jejich požadované kompetence a kapacity. Pokud dochází k najmutí QA během běžícího projektu, pak je i vhodné prověřit, že najmutí QA či jeho plánované činnosti nebrání implementační smlouva se stávajícím dodavatelem (například ve formě příliš přísného ujednání o mlčenlivosti, tzv. NDA) a v případě potřeby zajistit nápravu.

Další krokem je pak specifikace kritérií pro výběrové řízení QA a provedení vlastního výběru. Aby bylo QA opravdu přínosné, je vhodné se během výběru zamyslet minimálně nad kritérii, které budou zohledňovat prokazatelnou opakovanou zkušenost z obdobných implementačních projektů daného informačního systému v daném odvětví, a to jak samotné společnosti nabízející QA služby, tak i jejich pracovníků. Dále je důležité správně vyhodnotit navržený přístup ke QA, tj. kdo, co a jak bude dělat a komu a jak budou výsledky QA kontrol komunikovány. Do komunikace musí být zataženy všechny zúčastněné strany a jejich dotčené útvary (tj. jak business, tak i IT a management společnosti).

Peníze až na prvním místě?

Je na zvážení každého zákazníka, jestli si připlatit za QA, či nikoli. Každopádně složitá a komplikovaná realita ukazuje, jak snadné je ve shonu implementačních projektů zapomínat i na základní projektové návyky, které jsou však důležité pro zajištění řiditelnosti projektu a úspěšné nasazení nového informačního systému. Kontrola a zajištění dodržování definovaných projektových pravidel, procesů a standardů externí autoritou a přenesení zkušeností z obdobných implementačních projektů je cenným a nenahraditelným přínosem QA.

Zdeněk Slunečko Zdeněk Slunečko
Autor působí jako senior konzultant ve společnosti Deloitte. Pravidelně se účastní domácích a zahraničních projektů v oblasti informačních technologií, které svým rozsahem pokrývají celý životní cyklus podnikových informačních systémů. Pracuje na projektech zejména v odvětvích bankovnictví, technologie a telekomunikace.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.