Nejčastějším důvodem nespokojenosti zákazníků s implementací při zpětném hodnocení jsou nedodržení termínů ze strany dodavatele a množství změn, které často zákazník za změny ani nepovažuje, ale smlouva ani popis neobsahují rozporovaný popis a tím pádem je problém na světě.

Definice změnového řízení

Změnové řízení by mělo nastoupit skutečně v okamžiku, kdy se jedná o změnu. Změnou se pak rozumí

• Skutečná změna, původní požadavky popisují požadavek jinak a v rámci popisu lze nalézt jednoznačný rozpor
• Skutečná novinka, tedy požadavek není obsažen v žádném předchozím dokumentu, především pak v poptávce, zadávací dokumentaci, zápisech z jednání, smlouvě

Změnové řízení je pak proces, jehož cílem je dohodnout změnu původního rozsahu implementace tak, aby změnový požadavek, který změnové řízení vyvolal, se stal součástí implementace. Důsledek změnového řízení pak může být zápis, protokol, specifikující nový rozsah a případně upravující novou cenu či podmínky dodání. Změnou může být i omezení rozsahu implementace.

Jak se vyhnout změnovému řízení

Dobře připravený projekt minimalizuje změnová řízení, dokonce bych řekl, že dobře připravený projekt žádná změnová řízení nemá, pokud nejsou vyvolána externí složkou, například požadavek na externí napojení třetího subjektu nebo něco podobného. Jak se tedy připravit?

Analýza požadavků

Na začátku je důkladná analýza požadavků, ta by měla probíhat dvoukolově, nejprve interní, kdy sami nebo za pomoci externího poradce si stanovíte cíle celé implementace. Následně by pak měl stejnou analýzu požadavků provést potencionální dodavatel řešení.Prvotní analýza slouží pro zadávací dokumentaci, druhá již pak jako podklad pro návrh řešení. V rámci zadávací dokumentace by veškeré konkrétní výčty měli obsahovat kouzelná slůvka

• A podobně
• A tak dále
• Mimo jiné

Aby se předešlo konkretizaci v této fází, neboť tato pak může být brána jako konečná specifikace a není horšího změnového řízení, než přidání položky do seznamu z původních požadavků.

Návrh řešení

Následuje návrh řešení, zde je velmi důležité, jak moc do detailu budeme zacházet a jak si stanovíme pravidla změny detailu. Pokud dodavatel deklaruje předem a písemně, že například přidání pole do tabulky není problém, můžeme v analýze mít seznam polí pro každou konkrétní tabulku, pokud ale tato deklarace chybí, doporučuji se detailní analýze vyhnout a specifikovat obecně s tím, že seznam polí bude dodán do nějakého termínu. Konkrétní výčet pak dodavatel může lehko obhajovat jako schválený seznam a ten pak brát jako podklad pro změnové řízení.

Záruka za analýzu

Nejčastějším prohřeškem dodavatelů je neochota přijmout odpovědnost za analýzu a návrh řešení. Prakticky se jedná o ochranný dokument dodavatele, který si tak fixuje, co je a co není v ceně, přičemž samozřejmě v okamžiku podpisu smlouvy, kdy je velký tlak na celkovou cenu, je obsah minimalizován, v horším případě skrytě minimalizován. Požadavek záruky za analýzu by měl znít v tom smyslu, že není chybou, že zákazník dodavateli neřekl o nějakém požadavku, ale je chybou, že se na to dodavatel nezeptal. Není chybou, že odběratel nepochopil popis návrhu řešení, když skutečnost, ač je v souladu s návrhem absolutně nevyhovuje reálných požadavkům zákazníka. Je potřeba si uvědomit, že v případě návrhu, pokud nespolupracujete s někým, kdo nabízený produkt, rétoriku se kterou je popisovaný nezná, schvalujete návrh řešení, kterému nemůžete plně rozumět. Víra že uvedené procesy cca odpovídají tomu, co potřebujete se naplní až v okamžiku spuštění do ostrého provozu, neboť ani testování často neodhalí možné problémy.

Rada na závěr

Požadujte záruku za analýzu, máte na ni nárok. Poraďte se při čtení návrhů, smluv s externistou, nezapomeňte, že dodavatelé tyto dokumenty řeší denně, kdežto vy minimálně. Pozor na právo spojené s implementacemi, je specifické a liší se od klasických smluv o dílo například stavební. I v tomto ohledu je vhodné oslovit specialistu na právo ICT.