Legjobb gyakorlatok rendszerátállás előtt

Egy rendszerátállás ritkán azért csúszik meg, mert az új alkalmazás önmagában rossz. Gyakrabban az okoz gondot, hogy az átállás közben derül ki: a rendelési adatok több helyen eltérnek, egy raktári kivétel csak egy tapasztalt kolléga fejében létezik, vagy egy Excel-tábla olyan döntést támogat, amelyet senki sem dokumentált. A legjobb gyakorlatok rendszerátállás előtt ezért nem kizárólag informatikai ellenőrzőpontok. Ezek a működés kontrolljának feltételei.

Egy növekvő vállalatnál a rendszer csere vagy integrációja érintheti az értékesítést, a beszerzést, a termelést, a raktárt, a számlázást és a vezetői riportokat is. Ha az átállás csak technológiai projektként indul, könnyen megmaradnak a régi hibák - csak egy új felületen. A jobb megközelítés az, ha a cég először azt vizsgálja meg, hogyan dolgozik valójában, és csak ezután dönti el, mit kell átvinni, átalakítani vagy elhagyni.

A rendszerátállás előtt a valós folyamatot mérjék fel

A leírt folyamat és a tényleges működés sokszor nem ugyanaz. A folyamatábra szerint például a webshop rendelése automatikusan átkerül az ERP-be, a gyakorlatban viszont egy munkatárs minden reggel ellenőrzi, javítja és kézzel pótolja a hiányzó adatokat. Ez nem feltétlenül hiba az érintett kolléga részéről. Inkább annak a jele, hogy a rendszer vagy a folyamat nem kezeli megfelelően a kivételeket.

Átállás előtt érdemes végigkövetni néhány valódi ügyet elejétől a végéig. Egy beérkező rendelést, egy visszárut, egy sürgős beszerzést, egy gyártási eltérést vagy egy reklamációt. Ki indítja el a folyamatot? Milyen információ alapján dönt? Melyik rendszerben rögzít adatot? Hol várakozik az ügy, és ki lép közbe, ha valami nem a megszokott módon történik?

Ez a munka nem adminisztratív formalitás. Innen derül ki, hogy egy új rendszerben mely funkcióknak kell valóban működniük az első naptól, és melyek azok a régi lépések, amelyek már nem szolgálnak üzleti célt. Sok esetben a legnagyobb eredményt nem egy fejlesztés, hanem egy felesleges jóváhagyás, párhuzamos adatbevitel vagy kézi egyeztetés megszüntetése adja.

A kivételek fontosabbak lehetnek, mint az átlagos esetek

A normál folyamatot általában könnyű bemutatni. A nehézség ott kezdődik, amikor részszállítás érkezik, a vevő másik szállítási címet kér, egy termék készlete negatívba fordul, vagy egy rendelést módosítani kell a számla kiállítása után. Ezek az esetek gyakran nem mindennaposak, mégis jelentős időt, egyeztetést és kockázatot okoznak.

Nem cél minden kivételt teljesen automatizálni. Egy ritka és nagy szakértelmet igénylő döntésnél jobb lehet, ha a rendszer egyértelműen jelzi a problémát, és kijelölt emberhez irányítja azt. A lényeg az, hogy a kivétel kezelése ne rejtett, személyfüggő kerülőút legyen.

Adatköltöztetés előtt tisztázni kell az adat gazdáját

Az átállások egyik leggyakoribb félreértése, hogy minden meglévő adatot át kell vinni. Nem biztos. Egy tízéves, hiányos vagy duplikált törzsadatállomány átköltöztetése nem megőrzés, hanem a régi bizonytalanság továbbvitele.

Először azt kell meghatározni, mely adatok szükségesek a napi működéshez, a jogszabályi vagy szerződéses kötelezettségekhez, illetve az üzleti elemzéshez. Ezután azonosítani kell az adat gazdáját. Ki felel egy cikktörzs megnevezéséért, mértékegységéért és státuszáért? Ki dönthet egy partner adatainak módosításáról? Melyik rendszer az elsődleges forrás, ha ugyanaz az ügyféladat a CRM-ben, az ERP-ben és a számlázó rendszerben is szerepel?

Ha erre nincs világos válasz, az integráció csak gyorsabban fogja terjeszteni az eltéréseket. A technikai kapcsolat képes adatot továbbítani, de nem tudja eldönteni, melyik adat helyes.

Ne csak rekordokat, üzleti szabályokat is teszteljenek

Egy adatimport akkor sem tekinthető sikeresnek, ha minden sor betöltődött. Vizsgálni kell azt is, hogy az adatokkal elvégezhetők-e a fontos üzleti műveletek. Létrejön-e helyesen a rendelés? Lefoglalható-e a készlet? Megfelelő áfa, fizetési feltétel, ár vagy kedvezmény kerül-e a bizonylatra? A riport ugyanazt mutatja-e, amit a vezetés eddig használt, és ha nem, tudják-e pontosan, miért?

Hasznos, ha az ellenőrzés nem csak az IT és a szállító feladata. A pénzügy, a raktár, az értékesítés és a termelés olyan hibákat is észrevesz, amelyek technikailag nem feltétlenül látszanak, működés közben viszont azonnal fennakadást okoznak.

A legjobb gyakorlatok rendszerátállás előtt: egyértelmű felelősségek

Az átállás során sok feladat „valakihez” kerül. Valakinek jóvá kell hagynia a törzsadatot, ellenőriznie kell az importot, tájékoztatnia kell a felhasználókat, vagy döntést kell hoznia egy nyitott kérdésben. A „valaki” azonban nem felelősségi kör.

Már a projekt elején rögzíteni kell, ki hoz üzleti döntést, ki felel a folyamatért, ki készíti elő az adatokat, ki végzi a technikai módosításokat, és ki adhat engedélyt az éles indulásra. Különösen fontos a döntési határok kijelölése. Egy fejlesztő nem dönthet önállóan arról, hogy egy számlázási kivétel üzletileg elfogadható-e, ugyanakkor egy üzleti vezetőnek sem kell adatbázis-szintű technikai választ adnia.

A felelősségek tisztázása a kulcsemberek terhelését is láthatóvá teszi. Sok projekt azért lassul le, mert ugyanaz a két szakértő ember végzi a napi operációt, miközben tőlük várják az összes tesztet és jóváhagyást is. Ilyenkor az átállási tervnek számolnia kell helyettesítéssel, célzott időablakokkal vagy átmeneti kapacitással.

Az éles indulás ne legyen az első teljes próba

A tesztkörnyezet önmagában nem garancia. Akkor ad valódi biztonságot, ha a cég olyan forgatókönyveket próbál ki benne, amelyek a napi működés szempontjából kritikusak. Egy raktár esetében ilyen lehet a beérkezés, betárolás, komissiózás, leltár és kiszállítás. Gyártásban az anyagkiadás, munkalap-kezelés, selejt rögzítése és késztermék bevétele. Kereskedelemben a rendelés, fizetés, számlázás, visszatérítés és ügyféltájékoztatás lánca.

A próbát lehetőleg valósághű mennyiségekkel és szerepkörökkel kell végezni. Nem elég egyetlen mintarendelés, ha a normál működésben több csatornáról érkeznek adatok, készletmozgások történnek, és több ember dolgozik ugyanazon az állományon. Az is fontos, hogy a tesztelők ne kizárólag azt ellenőrizzék, amit az új rendszernek tudnia kell, hanem azt is, ami korábban hibához vezetett.

Az élesítés előtti döntéshez érdemes előre meghatározni az elfogadási feltételeket. Mely folyamatoknak kell hibamentesen működniük? Milyen eltérés még kezelhető indulás után, és mi az, ami megállítja az átállást? Ezzel elkerülhető a bizonytalan, benyomások alapján hozott „menjünk élesbe” döntés.

Kell visszaállási terv, de nem minden esetben ugyanaz

A visszaállási terv nem pesszimizmus, hanem üzletmenet-folytonossági fegyelem. Ha az új rendszerben kritikus hiba jelentkezik, mindenkinek tudnia kell, ki dönt a visszaállásról, milyen adatok menthetők, milyen időpontig lehet a régi rendszerhez visszatérni, és hogyan kezelik az átmenet alatt keletkezett tranzakciókat.

A teljes visszaállás nem mindig reális vagy szükséges. Egy fokozatosan bevezetett új riportingmegoldásnál például tartható egy ideig a régi riport párhuzamosan. Egy központi ERP-csere esetében ez jóval összetettebb lehet, mert a két rendszer közötti párhuzamos könyvelés és készletkezelés újabb eltéréseket teremthet. Itt előre kell mérlegelni, milyen rövid ideig fenntartható a régi működés, és mekkora kockázatot jelent a kettős adatkezelés.

A tervnek az ügyfelekre, beszállítókra és dolgozókra gyakorolt hatással is foglalkoznia kell. Ha egy kiesés miatt késik a visszaigazolás, a kiszállítás vagy a számlázás, legyen világos kommunikációs és manuális eljárás. A jól előkészített átmenet nem attól jó, hogy soha nincs probléma, hanem attól, hogy a szervezet nem improvizál, amikor probléma történik.

Az indulás utáni első napok is a projekt részei

Az átállás nem az élesítés gombjának megnyomásakor ér véget. Az első napokban jelentkező hibákból gyorsan kiderül, hol volt eltérés a feltételezett és a tényleges működés között. Ehhez kijelölt támogatási rend, rövid döntési út és közös hibakezelési lista kell.

Érdemes megkülönböztetni a működést megállító hibákat, a kerülőúttal kezelhető problémákat és a fejlesztési igényeket. Ha minden észrevétel azonos sürgősséget kap, a csapat elveszíti a fókuszt. Ha viszont a kritikus problémák gyorsan láthatóvá válnak, a vezetés is megalapozottabban tud dönteni a prioritásokról.

A rendszerátállás előtt feltett jó kérdések sokszor értékesebbek, mint a hosszú funkciólista. Melyik munkát végezzük csak megszokásból? Hol keletkezik ugyanaz az adat kétszer? Ki tudja egyedül helyrehozni a folyamatot? Ha ezekre őszinte válasz születik, az új rendszer nem csupán lecseréli a régit, hanem kiszámíthatóbb működést ad a növekedéshez.