Tento text je určen představenstvům a osobám, které svým podpisem stvrzují nákup systému: tajemníkovi a pokladníkovi na úřadě, řediteli komunální společnosti, finančnímu řediteli, majiteli firmy. Také vedoucímu IT, který připravuje zadávací řízení nebo poptávku a chce vědět, na co by si vedení mělo dát pozor, než dokumenty schválí.
Proč tento problém vzniká
Většina problémů s dodavateli má původ na straně zadavatele, a to dlouho před podpisem smlouvy. Nikoli ze zlé vůle: příprava zakázky je práce, na kterou v organizaci málokdy zbývá čas a potřebné kompetence, a dodavatelé jí rádi vypomohou. Přinesou hotové popisy, prezentace a cenové nabídky. Výsledkem je, že zadavatel kupuje to, co dodavatel umí prodat, a ne to, co skutečně potřebuje. Problémem je také to, že nákupní rozhodnutí velmi často zůstávají v rukou věcně příslušných útvarů, zatímco IT plní pouze roli strážce bezpečnosti. Chybějící standardy a dlouhodobá IT strategie vedou k tomu, že organizace realizuje nákupy, které ne vždy odpovídají rámci, jehož úkolem je zmírňovat rizika.
Stejné chyby vídám na úřadech i ve firmách. Liší se způsob zadávání zakázky, nikoli samotný mechanismus.
Dvanáct chyb
- Požadavky sepsané podle nabídky nebo prezentace jediného dodavatele. Omezuje to konkurenci a upevňuje závislost ještě předtím, než vyberete zhotovitele. Podrobněji jsem to popsal v textu o závislosti na dodavateli v zadávací dokumentaci (SWZ).
- Chybějící věcný vlastník. Projekt má formálně svého vedoucího, ale nikdo s mandátem vedení nerozhoduje o tom, jak mají procesy fungovat.
- Chybějící akceptační kritéria a testovací scénáře před podpisem. Přejímka se pak stává sporem o interpretaci, a ne ověřením, zda výstup projektu splňuje kritéria úspěchu implementace.
- Neznalost toho, co už existuje. Kupujete nový systém, aniž byste věděli, které stávající smlouvy, licence a funkce se s ním překrývají.
- Opomenuté integrace. S čím má nový systém vyměňovat data, kterým směrem, které systémy mají nadřazenou roli, jaká data a v jakých formátech, a zda o tom dodavatel ví a zaručuje, že dodá potřebné mechanismy a převezme odpovědnost za jejich nepřetržitý provoz.
- Migrace dat popsaná jednou větou. Bez stanovení, která data, za jaké období, kdo je očistí a kdo ověří výsledek.
- Požadavky ve formě seznamu funkcí místo popisu procesů. Na otázku ohledně funkce odpoví každý dodavatel „ano“. Na otázku, jak vyřeší Váš konkrétní případ, se odpovědi už liší.
- Porovnávání vstupní ceny místo celkových nákladů. Licence je jen začátek. Za údržbu, změny a integrace se platí léta. O tomto mechanismu píšu v textu o celkových nákladech na vlastnictví (TCO) a vaření žáby.
- Chybějící pravidla pro změnu rozsahu. Není jasné, kdo změnu nahlašuje, kdo ji oceňuje a kdo ji schvaluje.
- Smlouva bez podmínek pro ukončení spolupráce. Chybí ustanovení o exportu dat, dokumentaci a předání údržby jinému subjektu. Chybí nástroje pro zmírnění rizika.
- Servisní smlouva převzatá ze vzoru dodavatele. Úroveň služeb, reakční doby i cenu změn pak určuje jediná strana.
- Rozhodnutí odložené na poslední chvíli před termínem. Když se blíží zákonná lhůta nebo konec podpory starého systému, nezbývá už prostor na porovnání nabídek ani na vyjednávání.
Chyby jedna až tři jsou kořenové. Pokud je odstraníte, většina ostatních se stane viditelnou už ve fázi přípravy, a ne až při realizaci.
Pro radu, dozorčí radu nebo centrálu je nejdůležitější, zda má rozhodnutí o výběru dodavatele zdokumentované odůvodnění. Dvanáct bodů uvedených výše je zároveň seznamem otázek, které stojí za to položit dříve, než vedení schválí zadávací dokumentaci.
Příklad z praxe
Jeden z našich klientů dostal od dodavatele systému ERP informaci, že bez problému budeme moci vyměňovat data o obchodních partnerech se zaváděným systémem pro správu korespondence (EZD – systém pro správu dokumentů a spisů / e-Doręczenia – polský systém elektronického doručování). Systém pro správu korespondence obvykle uchovává data všech obchodních partnerů, nejen těch, u nichž dojde k hospodářským událostem, tedy stanou se zákazníky nebo dodavateli. Životní cyklus dat nového obchodního partnera totiž většinou začíná mnohem dříve, než k hospodářským událostem dojde.
Během implementace se ukázalo, že náklady na úpravu API rozhraní pro obousměrnou výměnu dat o obchodních partnerech na straně dodavatele ERP systému představují 80 % celkové hodnoty projektu zavedení oběhu nákladových dokladů v integraci s KSeF (polský Národní systém e-fakturace), OCR, VIES, GUS (polský statistický úřad) a nakonec s exportem dat do ekonomického systému. Tato jediná integrace, kterou na začátku dopodrobna neprojednali s dodavatelem, prakticky zdvojnásobila náklady projektu.
Kdy je potřeba nezávislý poradce
Pokud máte zkušený tým, který už připravil několik podobných zakázek, poslouží Vám tento seznam jako kontrola. Nezávislý pohled má smysl tehdy, když je zakázka v rámci organizace velká, když požadavky vznikaly v kontaktu s jediným dodavatelem, když bude třeba rozhodnutí obhájit před kontrolou, radou nebo centrálou, nebo když nikdo na straně zadavatele tyto systémy nezná zevnitř.
Mohu si dokumenty přečíst ještě před zveřejněním zadávacího řízení nebo odesláním poptávky, připravit požadavky a testovací scénáře nebo vyhodnotit již podané nabídky. Na úřadech vypadá výchozí bod trochu jinak, popisuji ho na stránce pro jednotky územní samosprávy (JST).