Úvodní přednáška dne se zabývala designem a realizací výběru dodavatele IT systému. Formát panelové diskuze s hlavním řečníkem a čtyřmi spolubesedníky nebyl zcela uživatelsky přívětivý, jelikož se hlavní doporučení dosti vytrácela a místy se diskuse trochu točila v kruhu respektive. Na druhou stranu zaznělo několik skvělých myšlenek, které bych rád ve svém příspěvku zmínil.
Ale ještě než se pustím do analýzy, dovolím si stručně představit odborný článek profesorů J. Verville a A. Hallington[1] nazvaný ´A six-stage model of the buying process for ERP software.´ Autoři se v něm totiž na základě čtyř případových studií nákupčích ERP systému definují ´univerzální´ model pro nákup software ve formě šesti klíčových nákupních procesů (viz tabulka).
|
Plánování
|
Tvorba nákupního týmu, Nákupní strategie, Specifikace, Hodnotící kritéria, Analýza rizik, Analýza trhu, Klíčové indikátory výkonu. |
|
Vyhledávání informací
|
Získat informace o potřebách organizace i informace z dodavatelského trhu. |
|
Selekce
|
Analyzovat nabídky a vybrat finální kandidáty na základě multikriteriálního rozhodování. |
|
Hodnocení
|
Ohodnotit nabídky z hlediska funkčního, technického a dodavatelského. |
|
Výběr
|
Formulovat závěrečné doporučení a to předložit nezávislé komisi k finálnímu rozhodnutí. |
|
Vyjednávání
|
Komerční a právní vyjednávání. |
Každý z uvedených procesů je v článku detailněji popsán, ovšem já se zaměřím pouze na proces plánování, který pro blok pro dobrou praxi nákupu software nedůležitější.
Proces plánování je ze všech uvedených procesů časově nejnáročnější a začal v okamžiku, kdy se firma rozhodla ERP systém nakoupit. Hned na začátku bylo nutno vytvořit mezioborový akviziční tým, který mimo jiné zodpovídal za vytvoření nákupní strategie, harmonogramu poptávkového řízení a identifikaci možných problémů, které by při akvizici a implementaci mohly nastat. Bylo velmi podstatné, aby se do týmu zapojili pracovníci s rozmanitým know-how a byly zohledněny všechny perspektivy. Součástí plánování byl sběr informací z hlediska interních požadavků, hodnoticích kritérií a metody jejich evaluace. Dalším úkolem týmu bylo získat a analyzovat informace z dodavatelského trhu, které posloužily k vytvoření definitivní specifikace. Konečně bylo potřeba s klíčovými stakeholdery definovat klíčové indikátory úspěchu, tedy priority, celého projektu.
Po tomto krátkém teoretickém úvodu se mohu vrátit k diskusi a přehledně strukturovat doporučení expertů.
Řízení projektu
Hned na úvod přednášející představil agilní přístup řízení projektu, který se dnes většinou doporučuje pro řízení nákupu a vývoje IT systémů. Naopak z článku vyplývá, že manažeři při nákupu ERP volili tradiční, vodopádový přístup. Bylo by zajímavé prodiskutovat, proč se firmy rozhodly pro vodopádové projektové řízení. Jedním z důvodů může být i fakt, že článek byl publikován v roce 2002, kdy byl agilní přístup ještě v plenkách.
Specifikace
Následně přednášející vysvětlil rozdíl mezi přesnou a funkční specifikací zakázky. Několikrát zdůraznil, že pro úspěšný nákup softwaru přesná specifikace systému spíše na škodu, naopak obecné stanovení cílů, které musí software splňovat, je to pravé ořechové. Je totiž vysoce pravděpodobné, že přesné specifikace se v průběhu vývoje, několikrát změní a můžou být i chybně zadány. Naopak funkční specifikace, která určuje cíl, ale ne cestu je daleko flexibilnější. Na to však zástupci veřejného sektoru namítali, že takový postup ve veřejném zadávání není možný a diskuse se začala točit v bludném kruhu.
Je to škoda, protože mě nejvíc problematika zadávání specifikací velmi zaujala. Myšlenka, že specifikace požadavků hraje proti zadavateli, mi v případě nákupu IT softwaru dává opravdu smysl. Vždyť toto odvětví je komplexní a trpí velkou mírou nejistoty. Navíc, nákupčí nemusí být v problematice IT expertem. Dokáži si představit situaci, dodavatel vyvine software přesně podle specifikace a ukáže se, že finální produkt je zcela nefunkční! To vše mluví pro funkční specifikaci.
Při použití agilního způsobu řízení projektu, je tento model možné uhlídat. Jen je potřeba s dodavateli nastavit jasná pravidla, jak se bude postupovat a v jakých krocích bude systém postupně vyvíjen. Díky prototypům se nákupčí může snadno rozhodnout, zda je prototyp potřeba upravit, či nikoliv. Pomocí těchto inkrementálních dodávek se následně vyvine finální řešení. Přidanou hodnotou tohoto postupu je plně funkční systém, který přesně odpovídá požadavkům zadavatele. Ondřej současně nezapomněl podotknout, že takovýto způsob řízení projektu samozřejmě má svoje mínusy, kterými je časté nedodržení časového nebo finančního rámce.
Hotový nebo na míru?
V samotném závěru přednášky se diskutující zaměřili na otázku koupě již hotového řešení versus řešení na míru. Hotové řešení je na místě kupovat vždy, kdy nakupujeme běžný software, který pro firmu nemá přidanou hodnotu (např. mzdový systém). Naopak, firma by měla přistoupit k řešení na míru pouze v případech, kdy má software potenciál přispět ke konkurenční výhodě firmy. Software na zakázku totiž firma konkurenci znesnadní případné okopírování.
Jaké tedy plyne poučení z této přednášky?
Bohužel, vymezený čas byl příliš krátký na to, aby přednášející prodiskutovali všechny předpoklady pro efektivní nákup software. Přestože se i následující bloky věnovaly různým aspektům nákupu software, nejsem přesvědčen, že se podařilo pokrýt všechny aspekty. I proto jsem svůj příspěvek doplnil o vědecký článek, který poskytuje přeci jen více příkladů dobré praxe. Zadavatelé by se měli určitě zamyslet nad funkčními specifikacemi a agilním řízením projektů, které vycházejí z postupných dodávek a flexibilního řízení projektu. Na druhou stranu, veřejní zadavatelé si tento způsob nedokáží představit, takže je otázka, zda je na něj veřejný sektor připraven.
[1] Verville, J., & Halingten, A. (2003). A six-stage model of the buying process for ERP software. Industrial Marketing Management, 32(7), 585-594.
O autorech:
Gabriel König, Štěpán Černohouz, Patrik Nátr, Jakub Nademlejnský, 2020
Autoři článku jsou studenti pátého ročníku specializace Logistics and Supply Chain Management