Při implementaci pracuje většina dodavatelů podle metodologie, kterou při úvodní nabídce presentují s velkou pompou, metodologie má vznešené názvy, nejčastěji se používají slova „mezinárodní“, „ověřená“, „bezpečná“. Je tomu ale skutečně tak? Jsou implementační metodologie takové, jako jsou prezentovány?Chtěl bych zde ukázat pár triků, které dodavatelé používají.

Vezmu si jeden termín - Bezpečná - asi nejdůležitější pojem, zároveň však pojem plný rozporů. Především metodologie pocházejí od dodavatelů, a proto je kladen důraz na to, aby implementace byla bezpečná pro ně. Tedy bezpečná ano, ale otázka je jak a pro koho. Pokud chcete implementovat dle metodologie, je nutné, aby byla bezpečná i pro zákazníka.

Trik první – Harmonogram

Harmonogram je sestaven na základě postupných kroků a to v přímé linii za sebou. Každý krok se začíná až v okamžiku, kdy je hotov krok předchozí. Vypadá to logicky, ale problém spočívá ve složitosti informačního systému, kde se nejedná o jeden celek, ale o několik prvků spojených dohromady. A čekat na zahájení migrace dat zboží po školení personalistiky je prostě věc zcela zbytečná. V praxi dodavatel tak činit nebude, ale v okamžiku, kdy začnete požadovat plnění termínů, zjistíte, že něco ještě nebylo předané a dodavatel prostě řekne,

„To je v harmonogramu až po schválení předchozího bodu a ten ještě schválen není, pak začne teprve běžet lhůta x dní“
Jak z toho ven? Ideální se jeví žádný harmonogram nemít. Dodavatel musí projekt řídit, a pro jeho úspěch bohatě stačí garance odpovědi. Jinak řečeno

• Je dán termín startu a termín předání a za ten ručí dodavatel
• Je řečeno, že zákazník musí do x (3-5) dnů reagovat na požadavky dodavatele, každý den navíc pak může termín posunout.

Pokud dodavatel projekt skutečně řídí, tak je bezpečný z hlediska dodavatele i zákazníka. Dodavatel je kryt při neposkytování součinnosti a zákazník má garantovaný termín.

Trik druhý – Analýza

„Ale to jste neříkali“, věta, kterou pokud uslyšíte, tak začnete počítat vícenáklady. Vhledem k etapám projektu, které většinou vypadají cca takto

• Analýza požadavků
• Návrh řešení
• Vývoj
• Implementace
• Zkušební (testovací) provoz
• Ostrý provoz s dohledem
• Předání - samostatný provoz

Kde po návrhu řešení vznikne dokument a co v něm není napsáno, bude do budoucna považováno za vícepráce. Buď se spolehnete na to, že jste skutečně při analýze řekli vše a dokument návrhu je dokonalý (což je skutečně málokdy), nebo budete požadovat záruku na analýzu. Pokud je partner tak dobrý, jak o sobě mluví, měl by Vám ji dát.

Dávejte si pozor na přílišný detail, výčty prvků, to vše vypadá jako kvalitně provedená analýza, ale v konečném důsledku omezuje řešení v rámci ceny implementace.

Trik třetí – testovací scénáře

Předávání vývoje se děje pomocí testovacích scénářů. Považuji to za největší ztrátu času na projektu a to z několika důvodů.

• Scénáře připravuje dodavatel nebo si dodavatel vyhrazuje právo scénáře znát. Tedy jinak řečeno, má čas vše připravit tak, aby scénáře prošli.
• Scénáře jsou standardizované postupy, neřeší většinou celý proces, neřeší varianty.
• Přípravou scénářů tráví čas jak konzultanti, tak vývojáři dodavatele a to ne malou z projektu. To vše platí zákazník. Tedy velká cena za to, že TS neposkytne žádnou jistotu toho, ž systém je připraven na ostrý provoz.

Jak tedy předat vývoj? Nepředávat. Řešit až při testovacím provozu, nebo pokud přece jenom chcete ke scénářům přistoupit, připravte je sami a dodavateli je ukažte v okamžiku testu. Systém musí zvládnout situace, které v podniku nastanou a konzultanti musí být obecně připraveny tyto situace řešit.

Závěrem bych chtěl navrhnout ještě jedno řešení, v rámci implementace je vhodné mít někoho na své straně, kdo tyto ale i jiné implementační triky dodavatelů zná. Ale o tom detailněji až příště.