Je důležité si uvědomit, že existuje velký rozdíl při nasazení hotového krabicového softwaru oproti podnikovému řešení, které je tvořeno na míru podle požadavků zadavatele. Krabicový software je testován velkým počtem uživatelů, kteří vytváří dlouhodobou zpětnou vazbu. Díky této zpětné vazbě výrobce postupně produkt vylepšuje. Takový produkt je otestován časem. Oproti tomu podnikový software bývá krokem do neznáma. I když se obvykle řeší podobné problémy, nakonec nikdy neexistují stejná řešení.
Různorodé požadavky zadavatele přinášejí různorodé problémy. Je to podobné, jako když se podle přání investora navrhuje a staví dům. První důležitý krok je stanovení účelu stavby. Přijde na řadu architekt, který musí správně pochopit potřeby zadavatele a přetransformovat je na konkrétní požadavky na stavitele. Dále je nutné vhodně zvolit stavební materiál, dobře položit základy, postavit správně obvodové zdi, zajistit kvalitní střechu. Každá jednotlivá činnost je důležitá, každé opomenutí v kvalitě provedení jednotlivých částí komplikuje celkovou stavbu. Nejenže jednotlivá klopýtnutí ohrožují obvykle napjatý rozpočet, ale v případě kumulace problémů může dojít k tomu, že výsledek vůbec neodpovídá tomu, co jsme původně chtěli.
Při vývoji softwaru dochází k podobným rizikům. Nejdůležitější částí projektu je stanovení požadavků na software, a to především schopnost odlišit důležité požadavky od těch méně významných, nebo dokonce zcela nepodstatných. Zdá se, že stejně jako v ekonomii zde platí Paretovo pravidlo 80/20 – v tomto případě dvacet procent požadavků, které definuje zadavatel, je tak důležitých, že pokryjí osmdesát procent skutečných potřeb. Jde především o nalezení těchto kritických požadavků a přiřazení odpovídajících priorit. V případě existence problémů, ať už časových nebo rozpočtových, se zaměřit především na prioritní požadavky a nerozptylovat energii na něco, co ve skutečnosti není důležité. Jinak hrozí zvýšení nákladů kvůli realizaci nepotřebných funkcionalit, nebo snížení kvality v důležitých částech systému. V nejhorším případě oboje zároveň.
Obtížnou částí vývoje softwaru je převedení problému z reálného světa do domény informačních technologií. Častou chybou je snaha o otrockou migraci stávajících postupů a procesů do nového informačního systému. Tento postup obvykle vede k zbytečnému zesložitění a byrokratizaci procesu. Co dobře funguje v reálném světě, nemusí dobře fungovat (a obvykle také nefunguje) ve světě IT. V reálném světě neexistují zásadní omezení, a pokud proces definovaný směrnicí nefunguje, je možné ho modifikovat ad hoc rozhodnutím konkrétního pracovníka. Ve světě IT ale tato ad hoc řešení nemusí být vůbec k dispozici. Například poznámku, která se obvykle píše na formuláři pod čarou, teď v novém systému nelze do žádné kolonky zapsat, dokument omylem poslaný kolegovi, který je nyní na dovolené, již nelze získat zpět pro důležitou korekturu a podobně. Je tedy nutné projít veškeré procesy a rozhodnout se, které ponechat, které od základu změnit a které do informačního systému vůbec nepřevádět. V případě nesprávné migrace procesů může dojít k tomu, že míra byrokratizace systému překročí únosnou mez a vysněný systém nakonec přinese více nových problémů, než kolik původně řešil.
Další kapitolou je nalezení vhodné platformy a technologie. Tady dodavatel samozřejmě protlačuje svoje řešení, které může, ale nemusí být v souladu se skutečnými potřebami zákazníka. Výběr technologie je důležitý pro budoucí rozšíření a kompatibilitu s aplikacemi třetích stran. S tímto také souvisí požadavek na určitou nezávislost na dodavateli softwaru. Neexistence alespoň hypotetické možnosti odejít v budoucnu ke konkurenci zvyšuje samozřejmě provozní náklady a zdražuje případné budoucí požadavky na rozšíření.
Důležitou částí je testování výsledné aplikace. Nejde jen o běžné vyzkoušení základní požadované funkcionality, ale o širší zodpovězení otázek typu „co se stane, když“. Například co se stane při větší zátěži (se systémem pracuje větší množství uživatelů než obvykle), při neoprávněném přístupu, při nestandardním úkonu uživatele a podobně. Při nedostatečném otestování aplikace hrozí akceptace nekvalitního řešení. Následně skryté kritické chyby mohou později dokonce poškodit provozní data, a problém nakonec může eskalovat mimo firemní prostředí.
Výše zmíněná rizika mohou neplánovitě navýšit celkové náklady na softwarový systém. Kromě nákladů, které jsou vidět – základní vývoj a implementace softwaru –, existují také náklady, které běžně vidět v tomto kontextu nejsou. Jsou to náklady související s:

• neefektivitou pracovních postupů uživatelů systému,
• administrací systému,
• řešením havarijních situací systému,
• budoucím rozšířením – novými požadavky na software,
• integrací s jinými systémy.

Je vidět, že vývoj, implementace a provoz podnikových systémů je komplexní proces, který přináší určitá rizika, ať už projektová, technická nebo obchodní. Zkušený dodavatel může těmto rizikům předcházet, nicméně ne vždy se zájmy dodavatele kryjí se zájmy zadavatele. Navíc může být obtížné kvalitního a zkušeného dodavatele vůbec najít.
Východiskem v této situaci může být existence nezávislého pohledu třetí strany. Podobně jako může být ohrožena stavba bez kvalitního stavebního dozoru, implementace složitých softwarových řešení může být velmi riziková bez nezávislého softwarového dozoru. Softwarový dozor stojí na straně zadavatele a jeho úkolem je především:

• analýza a detekce důležitých prioritních požadavků,
• korekce nerealistických přání a vizí,
• rozeznání, analýza, plánování a monitorování rizik,
• kontrola technické realizace,
• kontrola testování,
• kontrola produkčního prostředí.

Softwarový dozor by měl provádět odborník s kvalitním vzděláním a dlouholetou praktickou zkušeností v oboru implementace podnikových řešení. Ať už zadavatel využije služby softwarového dozoru, či nikoliv, je nutné věnovat dostatečný čas především přípravné analytické fázi, kdy se dávají dohromady klíčové požadavky a technologie. I na drobné chyby v této fázi se mohou postupně nabalovat jiné problémy a v konečném důsledku degradovat výsledný produkt, kdy vynaložené náklady neodpovídají očekávaným výsledkům.

Roman Bouchner