Projekt jede podle plánu… na papíře bez ERP testování
Projekt se nyní rozjel jako vlak v nastavených kolejích. Realizační tým si sedl a začal nastavovat (a do značné míry i programovat, což zákazník ne zcela pochopil) to, co bylo napsáno v analýze. Tak, jak je to správné, si sestavil seznam GAPů a realizoval je dle svého nejlepšího vědomí a svědomí, netuše, že analýza má málo společného s tím, co zákazník chce nebo potřebuje. Steering committee se pravidelné scházel a zákazník viděl pěkné grafy, jak se postupné GAPy řeší a projektový vlak jede dle cestovního pořádku ke světlým zítřkům. Nikde nebyly problémy ani překážky, vše bylo světlé, jak už to v této fázi projektu bývá.
Prototyp a první mráčky
Po nějaké době byl prezentován prototyp, poté pokročilý prototyp, kde konzultant ke spokojenosti všech diváků (což bylo vedení projektu a management, který samozřejmě tyto operace v detailu neznal a neprováděl) naklikal připravený doklad a zpracoval jej způsobem, který dle analýzy pokládal za správný. Koláčové grafy ukazovaly stále větší dílky, sloupcové grafy stále vyšší sloupce a a Ganttův graf další a další Gapy. Samozřejmě, občas došlo k zaškobrtnutí a nějaký úkol se trochu zpozdil nebo z nějakého testu vylezla nutnost opravy, ale to vše bylo pod kontrolou.
IT v roli viníka
Snad jediný problém na prozářené obloze byla část projektu (komunikace s jedním z partnerů) svěřená internímu IT. IT velmi správně usoudilo, že je projektem ohroženo, což management potvrdil tím, že je k projektu přizval pouze s úkolem zajištění infrastruktury. To bylo poněkud nešťastné, neboť v reálu IT mělo velmi detailní znalost stávajícího systému a snad mohli zabránit dalšímu vývoji. I když spíše ne, neboť aktivita IT se soustřeďovala na chození po firmě a vykládání, jak je stávající systém vlastně dobrý (což byl nesmysl) a jak dodavatel prakticky neví, jaké probíhají na pozadí procesy (což byla pravda). Nakonec, když přijali fakt, že projekt se nezastaví, v obavách o svou budoucnost se přihlásili k tomu, že pomohou s tvorbou integrací s firemními partnery. Jenže tento úkol byl očividně nad jejich síly a od samého začátku poskytovali dodavateli oblast, na kterou ukázat, když nastane problém. Nicméně to dávalo dodavateli na steering comitte náboje kdykoliv se někomu na straně dodavatele něco nezdálo.
ERP testování jako kritický moment
První mráčky na obloze se začaly ukazovat s nasazením prvních verzí k testování. Samozřejmě, součástí nastavení projektu bylo, že testování si provádí zákazník. Kdybych měl vypíchnout jeden bod, který obvykle způsobí kolaps projektu, je to tento. V realitě je ERP testování náročná, komplexní a dosti drahá práce. Je nutno skutečně detailně projít analýzu, chápat firemní procesy, vytvořit testovací cases… Teoreticky. V praxi snad nepamatuji jediný projekt, kde bych viděl, že by se tak stalo.
V rámci soutěžení na ceně je u nás naprosto běžná praxe, kdy se testovací práce a odpovědnost za testovací práce plně přenesou na zákazníka. Logika je jednoduchá – nabídka tím může být bratru o 20 procent nižší, což je pro management většinou rozhodující. Z pohledu zákazníka to vypadá naprosto logicky – stejně to musíme vyzkoušet, ušetříme hromadu peněz – otestují to naši lidé ve volném čase, protože jej samozřejmě mají hromady, v kancelářích sedí celé hodiny bez práce… A dodavateli to dává naprosto neprůstřelný argument kdykoliv něco nefunguje: „Je to vaše chyba, protože jste to neotestovali“. Samozřejmě, jedná se o alibismus, ale to alibi s nadšením dodavateli poskytuje zákazník.
Situace se stává lepší, když existuje dedikovaný implementační tým uvnitř firmy, ale i tak osobně preferuji u projektů této velikosti, bez velkého dedikovaného týmu, jako formu testu zduplikování provozu za dané období (optimálně měsíc, ale to si může málokdo dovolit).
V našem případě si těmito úvahami nikdo hlavu nelámal. Dodavatel nasadil systém na testovací infrastrukturu, provedl nějaké provizorní nastavení a import pár vzorků dat a vyzval zákazníka k testu. A jak ERP testování dopadlo?
V Quartexu víme, že ERP testování je jedním z nejcitlivějších míst každé implementace. Je to okamžik, kdy se ukáže, jestli systém opravdu podporuje procesy, nebo jen papírové předpoklady. Proto testování nikdy nenecháváme jen na zákazníkovi – spolupracujeme na scénářích, zajišťujeme dohled a pomáháme firmám zvládnout tuto kritickou fázi.
Firmy si nás mohou najmout nejen jako dodavatele, ale i jako konzultanty na jejich straně. V takovém případě chráníme zájmy zákazníka a řídíme testování tak, aby nebylo alibistickou pastí, ale cestou k reálnému výsledku.
30 let s ERP – 6. díl
Petr Kunetka
CEO Quartex Praha
27.8.2025
Projekt jede podle plánu… na papíře bez ERP testování
Projekt se nyní rozjel jako vlak v nastavených kolejích. Realizační tým si sedl a začal nastavovat (a do značné míry i programovat, což zákazník ne zcela pochopil) to, co bylo napsáno v analýze. Tak, jak je to správné, si sestavil seznam GAPů a realizoval je dle svého nejlepšího vědomí a svědomí, netuše, že analýza má málo společného s tím, co zákazník chce nebo potřebuje. Steering committee se pravidelné scházel a zákazník viděl pěkné grafy, jak se postupné GAPy řeší a projektový vlak jede dle cestovního pořádku ke světlým zítřkům. Nikde nebyly problémy ani překážky, vše bylo světlé, jak už to v této fázi projektu bývá.
Prototyp a první mráčky
Po nějaké době byl prezentován prototyp, poté pokročilý prototyp, kde konzultant ke spokojenosti všech diváků (což bylo vedení projektu a management, který samozřejmě tyto operace v detailu neznal a neprováděl) naklikal připravený doklad a zpracoval jej způsobem, který dle analýzy pokládal za správný. Koláčové grafy ukazovaly stále větší dílky, sloupcové grafy stále vyšší sloupce a a Ganttův graf další a další Gapy. Samozřejmě, občas došlo k zaškobrtnutí a nějaký úkol se trochu zpozdil nebo z nějakého testu vylezla nutnost opravy, ale to vše bylo pod kontrolou.
IT v roli viníka
Snad jediný problém na prozářené obloze byla část projektu (komunikace s jedním z partnerů) svěřená internímu IT. IT velmi správně usoudilo, že je projektem ohroženo, což management potvrdil tím, že je k projektu přizval pouze s úkolem zajištění infrastruktury. To bylo poněkud nešťastné, neboť v reálu IT mělo velmi detailní znalost stávajícího systému a snad mohli zabránit dalšímu vývoji. I když spíše ne, neboť aktivita IT se soustřeďovala na chození po firmě a vykládání, jak je stávající systém vlastně dobrý (což byl nesmysl) a jak dodavatel prakticky neví, jaké probíhají na pozadí procesy (což byla pravda). Nakonec, když přijali fakt, že projekt se nezastaví, v obavách o svou budoucnost se přihlásili k tomu, že pomohou s tvorbou integrací s firemními partnery. Jenže tento úkol byl očividně nad jejich síly a od samého začátku poskytovali dodavateli oblast, na kterou ukázat, když nastane problém. Nicméně to dávalo dodavateli na steering comitte náboje kdykoliv se někomu na straně dodavatele něco nezdálo.
ERP testování jako kritický moment
První mráčky na obloze se začaly ukazovat s nasazením prvních verzí k testování. Samozřejmě, součástí nastavení projektu bylo, že testování si provádí zákazník. Kdybych měl vypíchnout jeden bod, který obvykle způsobí kolaps projektu, je to tento. V realitě je ERP testování náročná, komplexní a dosti drahá práce. Je nutno skutečně detailně projít analýzu, chápat firemní procesy, vytvořit testovací cases… Teoreticky. V praxi snad nepamatuji jediný projekt, kde bych viděl, že by se tak stalo.
V rámci soutěžení na ceně je u nás naprosto běžná praxe, kdy se testovací práce a odpovědnost za testovací práce plně přenesou na zákazníka. Logika je jednoduchá – nabídka tím může být bratru o 20 procent nižší, což je pro management většinou rozhodující. Z pohledu zákazníka to vypadá naprosto logicky – stejně to musíme vyzkoušet, ušetříme hromadu peněz – otestují to naši lidé ve volném čase, protože jej samozřejmě mají hromady, v kancelářích sedí celé hodiny bez práce… A dodavateli to dává naprosto neprůstřelný argument kdykoliv něco nefunguje: „Je to vaše chyba, protože jste to neotestovali“. Samozřejmě, jedná se o alibismus, ale to alibi s nadšením dodavateli poskytuje zákazník.
Situace se stává lepší, když existuje dedikovaný implementační tým uvnitř firmy, ale i tak osobně preferuji u projektů této velikosti, bez velkého dedikovaného týmu, jako formu testu zduplikování provozu za dané období (optimálně měsíc, ale to si může málokdo dovolit).
V našem případě si těmito úvahami nikdo hlavu nelámal. Dodavatel nasadil systém na testovací infrastrukturu, provedl nějaké provizorní nastavení a import pár vzorků dat a vyzval zákazníka k testu. A jak ERP testování dopadlo?
Pokračování: 7. díl
Quartex Praha: ERP testování bez alibi
V Quartexu víme, že ERP testování je jedním z nejcitlivějších míst každé implementace. Je to okamžik, kdy se ukáže, jestli systém opravdu podporuje procesy, nebo jen papírové předpoklady. Proto testování nikdy nenecháváme jen na zákazníkovi – spolupracujeme na scénářích, zajišťujeme dohled a pomáháme firmám zvládnout tuto kritickou fázi.
Firmy si nás mohou najmout nejen jako dodavatele, ale i jako konzultanty na jejich straně. V takovém případě chráníme zájmy zákazníka a řídíme testování tak, aby nebylo alibistickou pastí, ale cestou k reálnému výsledku.
👉 Přemýšlíte o novém ERP projektu? www.quartex.cz/BC
👉 Máte již vybraného dodavatele a potřebujete pomoci na vaší straně ? www.quartex.cz/outsorcing
Tagy:
Nejnovější příspěvky
Kategorie
Štítky