Nejlepší postupy před změnou systému

Při přechodu na nový systém se zřídka stává, že by zpoždění způsobila samotná nová aplikace. Častěji se problémy objeví, když se během přechodu zjistí, že objednávkové údaje se na různých místech liší, výjimka ve skladu existuje pouze v hlavě zkušeného kolegy, nebo tabulka Excel podporuje rozhodnutí, které nikdo nedokumentoval. Nejlepší praxe před přechodem na nový systém proto nejsou pouze IT kontrolní body. Jsou to podmínky pro kontrolu provozu.

U rostoucí společnosti může výměna nebo integrace systému ovlivnit prodej, nákup, výrobu, sklad, fakturaci a manažerské reporty. Pokud přechod začíná pouze jako technologický projekt, staré chyby mohou zůstat - jen na novém rozhraní. Lepší přístup je, když společnost nejprve zkoumá, jak skutečně pracuje, a teprve poté rozhodne, co je třeba převést, přeměnit nebo opustit.

Před přechodem na nový systém zmapujte skutečný proces

Popisovaný proces a skutečný provoz často nejsou totožné. Podle diagramu procesu se například objednávka z e-shopu automaticky přenáší do ERP, ale v praxi zaměstnanec každé ráno kontroluje, opravuje a ručně doplňuje chybějící údaje. To nemusí být nutně chyba dotyčného kolegy. Spíše to naznačuje, že systém nebo proces neřeší výjimky správně.

Před přechodem je dobré sledovat několik skutečných případů od začátku do konce. Příchozí objednávku, vrácené zboží, urgentní nákup, výrobní odchylku nebo reklamaci. Kdo zahajuje proces? Na základě jakých informací rozhoduje? Ve kterém systému zaznamenává data? Kde případ čeká a kdo zasahuje, pokud se něco neděje obvyklým způsobem?

Tato práce není administrativní formalita. Zde se ukáže, které funkce musí v novém systému skutečně fungovat od prvního dne a které staré kroky již neslouží obchodnímu účelu. V mnoha případech největšího výsledku nedosáhne vývoj, ale odstranění zbytečného schválení, paralelního zadávání dat nebo ručního sladění.

Výjimky mohou být důležitější než průměrné případy

Normální proces je obvykle snadné představit. Potíže začínají, když dorazí částečná dodávka, zákazník požádá o jinou dodací adresu, zásoba produktu se dostane do záporných hodnot nebo je třeba změnit objednávku po vystavení faktury. Tyto případy nejsou často každodenní, ale přesto způsobují značný čas, sladění a riziko.

Cílem není automatizovat každou výjimku. U vzácného rozhodnutí, které vyžaduje vysokou odbornost, může být lepší, když systém jasně signalizuje problém a nasměruje jej na určenou osobu. Důležité je, aby řešení výjimky nebylo skrytou, na osobě závislou oklikou.

Před přesunem dat je třeba vyjasnit vlastníka dat

Jedním z nejčastějších nedorozumění při přechodech je, že je třeba přenést všechna stávající data. To není jisté. Přesun desetiletého, neúplného nebo duplicitního kmenového datového souboru není zachování, ale pokračování staré nejistoty.

Nejprve je třeba určit, která data jsou potřebná pro denní provoz, právní nebo smluvní povinnosti a obchodní analýzu. Poté je třeba identifikovat vlastníka dat. Kdo je zodpovědný za název, jednotku a stav kmenových dat? Kdo může rozhodnout o změně údajů o partnerovi? Který systém je primárním zdrojem, pokud se stejné údaje o zákazníkovi objevují v CRM, ERP a fakturačním systému?

Pokud na to není jasná odpověď, integrace pouze rychleji rozšíří rozdíly. Technické spojení může přenášet data, ale nemůže rozhodnout, která data jsou správná.

Netestujte pouze záznamy, ale i obchodní pravidla

Import dat nelze považovat za úspěšný, i když se načetla každá řádka. Je třeba také zkoumat, zda lze s daty provádět důležité obchodní operace. Vytvoří se objednávka správně? Je možné rezervovat zásoby? Je na dokladu správně uvedeno DPH, platební podmínky, cena nebo sleva? Ukazuje report to, co vedení dosud používalo, a pokud ne, vědí přesně proč?

Je užitečné, když kontrola není pouze úkolem IT a dodavatele. Finance, sklad, prodej a výroba mohou zaznamenat chyby, které technicky nemusí být viditelné, ale během provozu okamžitě způsobí problémy.

Nejlepší praxe před přechodem na nový systém: jasné odpovědnosti

Během přechodu se mnoho úkolů dostane k „někomu“. Někdo musí schválit kmenová data, zkontrolovat import, informovat uživatele nebo rozhodnout o otevřené otázce. „Někdo“ však není odpovědnost.

Již na začátku projektu je třeba stanovit, kdo činí obchodní rozhodnutí, kdo je zodpovědný za proces, kdo připravuje data, kdo provádí technické změny a kdo může povolit ostrý start. Zvláště důležité je vymezit rozhodovací hranice. Vývojář nemůže sám rozhodnout, zda je fakturační výjimka obchodně přijatelná, zatímco obchodní vedoucí nemusí poskytovat technickou odpověď na úrovni databáze.

Vyjasnění odpovědností také zviditelňuje zatížení klíčových osob. Mnoho projektů se zpomaluje, protože stejní dva odborníci provádějí denní operace a zároveň se od nich očekává, že provedou všechny testy a schválení. V takových případech musí plán přechodu počítat s náhradou, cílenými časovými okny nebo přechodnou kapacitou.

Ostrý start by neměl být prvním úplným testem

Testovací prostředí samo o sobě není zárukou. Skutečnou bezpečnost poskytuje, pokud společnost vyzkouší scénáře, které jsou kritické z hlediska denního provozu. U skladu to může být příjem, uskladnění, kompletace, inventura a expedice. Ve výrobě vydání materiálu, zpracování pracovních listů, zaznamenávání odpadu a příjem hotových výrobků. V obchodu řetězec objednávek, plateb, fakturace, vrácení a informování zákazníků.

Test by měl být proveden pokud možno s realistickými množstvími a rolemi. Nestačí jediná vzorová objednávka, pokud v normálním provozu přicházejí data z více kanálů, dochází k pohybům zásob a na stejném souboru pracuje více lidí. Je také důležité, aby testeři nekontrolovali pouze to, co by měl nový systém umět, ale také to, co dříve vedlo k chybám.

Pro rozhodnutí před ostrým startem je vhodné předem stanovit podmínky přijetí. Které procesy musí fungovat bez chyb? Jaká odchylka je ještě zvládnutelná po spuštění a co zastaví přechod? Tím se vyhnete nejistému rozhodnutí „jdeme do ostrého provozu“ na základě dojmů.

Je třeba plán obnovy, ale ne vždy stejný

Plán obnovy není pesimismus, ale disciplína kontinuity podnikání. Pokud se v novém systému objeví kritická chyba, každý by měl vědět, kdo rozhoduje o obnově, jaká data lze zachránit, do kdy je možné se vrátit k starému systému a jak se budou řešit transakce vzniklé během přechodu.

Úplná obnova není vždy reálná nebo nutná. U postupně zaváděného nového reportovacího řešení může být po určitou dobu udržován starý report paralelně. U centrální výměny ERP to může být mnohem složitější, protože paralelní účetnictví a řízení zásob mezi dvěma systémy může vytvořit nové rozdíly. Zde je třeba předem zvážit, jak krátkou dobu lze starý provoz udržet a jaké riziko představuje dvojí zpracování dat.

Plán by měl také řešit dopady na zákazníky, dodavatele a zaměstnance. Pokud z důvodu výpadku dojde ke zpoždění potvrzení, expedice nebo fakturace, měla by být jasná komunikační a manuální procedura. Dobře připravený přechod není dobrý tím, že nikdy nedochází k problémům, ale tím, že organizace neimprovizuje, když k problémům dojde.

První dny po spuštění jsou také součástí projektu

Přechod nekončí stisknutím tlačítka pro ostrý start. Z chyb, které se objeví v prvních dnech, rychle vyjde najevo, kde byl rozdíl mezi předpokládaným a skutečným provozem. K tomu je třeba určená podpora, krátká rozhodovací cesta a společný seznam řešení chyb.

Je vhodné rozlišovat chyby, které zastaví provoz, problémy, které lze řešit oklikou, a požadavky na vývoj. Pokud každá připomínka dostane stejnou naléhavost, tým ztratí zaměření. Pokud se však kritické problémy rychle zviditelní, vedení může lépe rozhodovat o prioritách.

Dobré otázky položené před přechodem na nový systém jsou často cennější než dlouhý seznam funkcí. Kterou práci děláme jen ze zvyku? Kde se stejná data vytvářejí dvakrát? Kdo jediný může opravit proces? Pokud na tyto otázky vzniknou upřímné odpovědi, nový systém nejen nahradí starý, ale poskytne předvídatelnější provoz pro růst.