Najlepšie postupy pred prechodom na nový systém

Prechod na nový systém zriedka zlyhá kvôli tomu, že nová aplikácia je sama o sebe zlá. Častejšie sa problémy objavia počas prechodu, keď sa zistí, že objednávkové údaje sa na viacerých miestach líšia, výnimka zo skladu existuje len v hlave skúseného kolegu, alebo Excelová tabuľka podporuje rozhodnutie, ktoré nikto nezaznamenal. najlepšie praktiky pred prechodom na nový systém preto nie sú výlučne IT kontrolné body. Sú to podmienky na kontrolu prevádzky.

V rastúcej spoločnosti môže výmena alebo integrácia systému ovplyvniť predaj, nákup, výrobu, sklad, fakturáciu a manažérske reporty. Ak sa prechod začne len ako technologický projekt, staré chyby môžu zostať - len na novom rozhraní. Lepší prístup je, keď spoločnosť najprv preskúma, ako skutočne pracuje, a až potom rozhodne, čo treba preniesť, transformovať alebo opustiť.

Pred prechodom na nový systém zmerajte skutočný proces

Popísaný proces a skutočná prevádzka často nie sú to isté. Podľa diagramu procesov sa napríklad objednávka z e-shopu automaticky prenesie do ERP, ale v praxi zamestnanec každé ráno kontroluje, opravuje a ručne dopĺňa chýbajúce údaje. To nemusí byť chyba dotknutého kolegu. Skôr to naznačuje, že systém alebo proces nevhodne spracováva výnimky.

Pred prechodom je vhodné sledovať niekoľko skutočných prípadov od začiatku do konca. Prichádzajúcu objednávku, vrátenie tovaru, urgentný nákup, výrobnú odchýlku alebo reklamáciu. Kto spúšťa proces? Na základe akých informácií rozhoduje? V ktorom systéme zaznamenáva údaje? Kde čaká prípad a kto zasahuje, keď sa niečo nedeje podľa očakávania?

Táto práca nie je administratívnou formalitou. Odtiaľto sa zistí, ktoré funkcie v novom systéme musia skutočne fungovať od prvého dňa a ktoré staré kroky už neslúžia obchodnému účelu. V mnohých prípadoch najväčší výsledok neprináša vývoj, ale odstránenie zbytočného schválenia, paralelného zadávania údajov alebo ručného zladenia.

Výnimky môžu byť dôležitejšie ako priemerné prípady

Normálny proces je zvyčajne ľahké predstaviť. Ťažkosti začínajú, keď príde čiastočná dodávka, zákazník žiada inú dodaciu adresu, zásoba produktu sa stane negatívnou alebo objednávku je potrebné upraviť po vystavení faktúry. Tieto prípady nie sú často každodenné, ale spôsobujú značný čas, koordináciu a riziko.

Cieľom nie je úplne automatizovať každú výnimku. Pri zriedkavom a odbornom rozhodnutí môže byť lepšie, ak systém jasne signalizuje problém a nasmeruje ho na určenú osobu. Dôležité je, aby spracovanie výnimky nebolo skrytou, osobne závislou obchádzkou.

Pred presunom údajov je potrebné objasniť vlastníka údajov

Jedným z najčastejších nedorozumení pri prechodoch je, že všetky existujúce údaje musia byť prenesené. Nie je to isté. Presun desaťročného, neúplného alebo duplicitného základného súboru údajov nie je uchovávanie, ale pokračovanie starých neistôt.

Najprv je potrebné určiť, ktoré údaje sú potrebné pre dennú prevádzku, zákonné alebo zmluvné povinnosti a obchodnú analýzu. Potom je potrebné identifikovať vlastníka údajov. Kto je zodpovedný za názov, mernú jednotku a stav kmeňového záznamu? Kto môže rozhodnúť o zmene údajov partnera? Ktorý systém je primárnym zdrojom, ak sa rovnaké údaje o zákazníkovi nachádzajú v CRM, ERP a fakturačnom systéme?

Ak na to nie je jasná odpoveď, integrácia len rýchlejšie rozšíri rozdiely. Technické spojenie dokáže prenášať údaje, ale nemôže rozhodnúť, ktoré údaje sú správne.

Netestujte len záznamy, ale aj obchodné pravidlá

Import údajov sa nepovažuje za úspešný, ak sa načítali všetky riadky. Je potrebné skúmať aj to, či sa s údajmi dajú vykonávať dôležité obchodné operácie. Vytvára sa objednávka správne? Je možné rezervovať zásoby? Sú na doklade správne DPH, platobné podmienky, cena alebo zľava? Zobrazuje report to isté, čo vedenie doteraz používalo, a ak nie, vedia presne, prečo?

Je užitočné, ak kontrola nie je len úlohou IT a dodávateľa. Financie, sklad, predaj a výroba si všimnú chyby, ktoré technicky nemusia byť viditeľné, ale počas prevádzky okamžite spôsobia problémy.

Najlepšie praktiky pred prechodom na nový systém: jasné zodpovednosti

Počas prechodu sa mnoho úloh dostane k „niekomu“. Niekto musí schváliť základné údaje, skontrolovať import, informovať používateľov alebo rozhodnúť o otvorenej otázke. „Niekto“ však nie je zodpovednosť.

Už na začiatku projektu je potrebné zaznamenať, kto robí obchodné rozhodnutia, kto je zodpovedný za proces, kto pripravuje údaje, kto vykonáva technické úpravy a kto môže povoliť ostrý štart. Obzvlášť dôležité je určiť hranice rozhodovania. Vývojár nemôže samostatne rozhodnúť, či je fakturačná výnimka obchodne prijateľná, zatiaľ čo obchodný manažér nemusí poskytovať technickú odpoveď na úrovni databázy.

Objasnenie zodpovedností tiež zviditeľňuje zaťaženie kľúčových osôb. Mnoho projektov sa spomaľuje, pretože rovnakí dvaja odborníci vykonávajú dennú prevádzku, zatiaľ čo sa od nich očakáva všetky testy a schválenia. V takýchto prípadoch musí plán prechodu počítať s náhradou, cieľovými časovými oknami alebo dočasnou kapacitou.

Ostrý štart by nemal byť prvou úplnou skúškou

Testovacie prostredie samo o sebe nie je zárukou. Skutočnú bezpečnosť poskytuje, ak spoločnosť vyskúša scenáre, ktoré sú kritické z hľadiska dennej prevádzky. V prípade skladu to môže byť príjem, uskladnenie, komisionovanie, inventúra a expedícia. Vo výrobe vydávanie materiálu, správa pracovných listov, zaznamenávanie odpadu a príjem hotových výrobkov. V obchode reťazec objednávky, platby, fakturácie, vrátenia a informovania zákazníkov.

Skúšku treba vykonať s realistickými množstvami a rolami. Nestačí jedna vzorová objednávka, ak v normálnej prevádzke prichádzajú údaje z viacerých kanálov, dochádza k pohybom zásob a viacerí ľudia pracujú na rovnakom súbore. Dôležité je aj to, aby testeri nekontrolovali len to, čo má nový systém vedieť, ale aj to, čo predtým viedlo k chybe.

Na rozhodnutie pred ostrým štartom je vhodné vopred určiť podmienky prijatia. Ktoré procesy musia fungovať bezchybne? Aká odchýlka je ešte zvládnuteľná po štarte a čo zastaví prechod? Tým sa vyhnete neistému rozhodnutiu „prejdime na ostrý štart“ založenému na dojmoch.

Je potrebný plán obnovy, ale nie vždy rovnaký

Plán obnovy nie je pesimizmus, ale disciplína kontinuity podnikania. Ak sa v novom systéme vyskytne kritická chyba, každý musí vedieť, kto rozhoduje o obnove, aké údaje sa dajú zachrániť, do akého času je možné vrátiť sa k starému systému a ako sa riešia transakcie vzniknuté počas prechodu.

Úplná obnova nie je vždy realistická alebo potrebná. Pri postupne zavádzanom novom riešení reportingu môže byť starý report nejaký čas paralelne udržiavaný. Pri výmene centrálneho ERP to môže byť oveľa zložitejšie, pretože paralelné účtovanie a správa zásob medzi dvoma systémami môže vytvárať nové rozdiely. Tu je potrebné vopred zvážiť, ako krátko je možné udržať starú prevádzku a aké riziko predstavuje dvojité spracovanie údajov.

Plán musí tiež riešiť vplyv na zákazníkov, dodávateľov a zamestnancov. Ak kvôli výpadku mešká potvrdenie, dodávka alebo fakturácia, musí byť jasná komunikačná a manuálna procedúra. Dobre pripravený prechod nie je dobrý preto, že nikdy nie sú problémy, ale preto, že organizácia neimprovizuje, keď sa problémy vyskytnú.

Prvé dni po štarte sú tiež súčasťou projektu

Prechod sa nekončí stlačením tlačidla ostrého štartu. Chyby, ktoré sa objavia v prvých dňoch, rýchlo odhalia, kde bol rozdiel medzi predpokladanou a skutočnou prevádzkou. Na to je potrebná určená podpora, krátka rozhodovacia cesta a spoločný zoznam riešenia chýb.

Je vhodné rozlíšiť chyby, ktoré zastavujú prevádzku, problémy, ktoré sa dajú riešiť obchádzkou, a požiadavky na vývoj. Ak každé zistenie dostane rovnakú naliehavosť, tím stratí zameranie. Ak sa však kritické problémy rýchlo zviditeľnia, vedenie môže lepšie rozhodovať o prioritách.

Dobré otázky položené pred prechodom na nový systém sú často cennejšie ako dlhý zoznam funkcií. Ktorú prácu robíme len zo zvyku? Kde sa rovnaké údaje vytvárajú dvakrát? Kto dokáže sám opraviť proces? Ak sa na tieto otázky úprimne odpovie, nový systém nielen nahradí starý, ale poskytne predvídateľnejšiu prevádzku na rast.