Beszerzési szoftver bevezetése 8 lépésben: a felméréstől az élesítésig

A beszerzési szoftver bevezetése nem az első felhasználói fiók létrehozásával kezdődik, és nem is az éles rendszer bekapcsolásával ér véget. Akkor tekinthető sikeresnek, ha az igénylők tudják, hogyan indítsanak beszerzést, a vezetők átlátják a jóváhagyásokat, a beszerzés és a pénzügy pedig megbízható adatokból dolgozik. Ehhez a technológia mellett világos felelősségi körök és közösen elfogadott működési szabályok kellenek.

Az alábbi nyolclépéses terv a felméréstől a stabil üzemi működésig vezet. Minden lépésnél megmutatja, ki feleljen az eredményért, milyen kézzelfogható kimenet készüljön, és mit érdemes ellenőrizni a továbblépés előtt. A megközelítés új rendszer bevezetésénél és meglévő, széttagolt beszerzési megoldások kiváltásánál is alkalmazható.

1–2. Folyamatfelmérés és végrehajtható projektterv

1. Térképezzük fel a tényleges beszerzési működést

Ne csak a szabályzatot olvassuk el: kövessünk végig néhány valós beszerzést az igény felmerülésétől a teljesítés visszaigazolásáig. Hol születik az igény? Ki ellenőrzi a keretet? Mikor kérnek ajánlatot? Hol kerülnek elő e-mailek, táblázatok vagy telefonos jóváhagyások? A kerülőutak gyakran olyan működési szükségleteket jeleznek, amelyeket a hivatalos folyamat nem kezel.

Felelős: a beszerzési folyamatgazda, az igénylő területek, a pénzügy és az IT bevonásával. Kimenet: jelenlegi és célfolyamat, problémalista, valamint a rendszer által támogatandó esetek jegyzéke. Külön rögzítsük a sürgős beszerzés, a visszautasítás, a módosítás és a helyettesítés útját.

A célfolyamatnál minden lépéshez rendeljünk felelőst, bemeneti adatot és lezárási feltételt. Már ekkor gyűjtsünk kiinduló adatokat a későbbi értékeléshez, például a jóváhagyási átfutásról vagy a hiánypótlásra visszaküldött igényekről. Ne vállaljunk javulási célt olyan mutatóra, amelyet még nem tudunk következetesen mérni.

2. Határozzuk meg a projekt kereteit és döntési rendjét

Az első ütemnek ne kelljen minden beszerzési problémát megoldania. Jelöljük ki, mely szervezeti egységek, beszerzési kategóriák és folyamatlépések tartoznak bele. Egy jól körülhatárolt igénylés–jóváhagyás–megrendelés folyamat biztonságosabb indulást adhat, mint több, egymástól függő részfolyamat egyidejű átalakítása.

Felelős: a projektvezető; a kereteket az üzleti szponzor hagyja jóvá. Kimenet: ütemterv, erőforrásterv, felelősségi lista és elfogadási feltételek. Minden mérföldkőhöz tartozzon döntéshozó, ne csak határidő.

• Üzleti szponzor: biztosítja az erőforrásokat, és rendezi a prioritási vitákat.
• Folyamatgazda: dönt a beszerzési működés szabályairól.
• IT-felelős: koordinálja az integrációt, a hozzáféréseket és az üzemeltetési feladatokat.
• Kulcsfelhasználók: ellenőrzik, hogy a megoldás a napi munkában is használható-e.

Legyen változáskezelési rend is: az új igényeknél mindig vizsgáljuk meg a határidőre, költségre és tesztelésre gyakorolt hatást. Ami hasznos, de nem szükséges az induláshoz, kerüljön későbbi fejlesztési listára.

3. Konfiguráljuk a folyamatokat, jogosultságokat és kapcsolódásokat

A konfiguráció során a jóváhagyott célfolyamatból működő űrlapok, státuszok, feladatok és értesítések lesznek. Határozzuk meg a kötelező adatokat, a jóváhagyási értékhatárokat, a költséghely szerinti elágazásokat és a helyettesítési szabályokat. Kerüljük a felesleges mezőket: minden bekért adatnak legyen felhasználási célja.

Felelős: a bevezetési szakértő és az IT-felelős; az üzleti szabályokat a folyamatgazda fogadja el. Kimenet: bemutatható konfiguráció, jogosultsági mátrix és dokumentált integrációs terv.

A jogosultságokat szerepkörökhöz rendeljük, ne kizárólag személyekhez. Vizsgáljuk meg azt is, szükséges-e elválasztani az igénylői, jóváhagyói és adminisztrátori feladatokat. A bemutatón ne csak az ideális útvonalat járjuk végig: mi történik, ha a jóváhagyó távol van, vagy az igény összege menet közben megváltozik?

Az ERP-hez, pénzügyi rendszerhez vagy címtárhoz tervezett kapcsolódásoknál rögzítsük, melyik rendszer melyik adat elsődleges forrása. Tisztázzuk az adatátadás gyakoriságát, a hibajelzést és az újraküldés módját. Az integráció csak akkor kész, ha a sikertelen adatátadás kezelése is rendezett, nem csupán a sikeres kapcsolatfelépítés.

4. Készítsük elő és próbáljuk ki az adatmigrációt

Az adatmigráció nem egyszerű fájlbetöltés. Először döntsük el, mit érdemes átvinni: beszállítói törzsadatokat, költséghelyeket, felhasználókat, szerződésadatokat vagy nyitott beszerzéseket. A történeti állomány egy része kereshető archívumban is maradhat, ha ez megfelel az üzleti és megőrzési követelményeknek.

Felelős: az üzleti adatgazda, technikai támogatással. Kimenet: tisztított adatállomány, mezőmegfeleltetés és ellenőrzött próbamigráció. Az adatok tartalmi helyességét nem a technikai csapatnak kell egyedül megítélnie.

• Szűrjük ki a duplikált beszállítókat és az elavult rekordokat.
• Egységesítsük az azonosítókat, pénznemeket és szervezeti hivatkozásokat.
• Ellenőrizzük a kötelező mezőket és a rekordok közötti kapcsolatokat.
• Próbabetöltés után végezzünk darabszám-ellenőrzést és tételes mintavételt.

A végleges átállás előtt legyen adatbefagyasztási vagy változásátvezetési terv. Enélkül a próbamigráció és az éles betöltés között létrejött módosítások elveszhetnek, vagy eltérő állapot jelenhet meg a két rendszerben.

5–6. Teszteljünk üzleti esetekkel, majd indítsunk pilotot

5. Igazoljuk a működést felhasználói átvételi tesztekkel

A tesztelés azt bizonyítsa, hogy a beszerzés végrehajtható és ellenőrizhető, ne csak azt, hogy megnyílnak a képernyők. Készítsünk forgatókönyvet normál igénylésre, többszintű jóváhagyásra, visszautasításra, javításra és jogosulatlan hozzáférési kísérletre. Ellenőrizzük az értesítéseket, a kereshetőséget és a kapcsolódó rendszerekbe továbbított adatokat is.

Felelős: a kijelölt tesztkoordinátor és a kulcsfelhasználók. Kimenet: dokumentált teszteredmények, hibajegyzék és üzleti elfogadás. Minden hibához tartozzon súlyosság, felelős és javítás utáni visszaellenőrzés.

Az élesítést blokkoló hibák körét előre rögzítsük. A hibás jóváhagyási útvonal vagy az illetéktelen adathozzáférés például nem kezelhető egyszerű kényelmi hiányosságként.

6. Pilotban ellenőrizzük a napi használhatóságot

A pilot korlátozott, de valós működési próba. Válasszunk olyan csapatot és beszerzési kört, amelyben tipikus esetek és kivételek is előfordulnak. A tesztkörnyezethez képest itt már a napi munkaterhelés, a feladatátadás és a felhasználói szokások hatása is láthatóvá válik.

Felelős: a pilot terület vezetője és a folyamatgazda. Kimenet: értékelés, javítási lista és döntés a kiterjesztésről. Előre szabjuk meg, milyen eseteket kell kipróbálni, és hol gyűjtjük a visszajelzéseket.

Ne pusztán elégedettséget kérdezzünk. Vizsgáljuk meg, hol akadnak el az ügyek, mely mezőket értik félre, és visszatérnek-e a felhasználók az e-mailes ügyintézéshez. Ezekből konkrét konfigurációs vagy oktatási feladatok következhetnek.

7. Oktassunk szerepkörönként, valós feladatokon keresztül

Az igénylőnek, a jóváhagyónak és a beszerzőnek más tudásra van szüksége. Az oktatást ezért ne menüpontok, hanem elvégzendő feladatok köré szervezzük: igény indítása, hiánypótlás, döntés, helyettesítés vagy státuszkövetés. A résztvevők saját szerepkörükben gyakoroljanak.

Felelős: az oktatási koordinátor és a kulcsfelhasználók. Kimenet: szerepköralapú segédletek, gyakorlási lehetőség és ismert támogatási csatorna. Az oktatás lehetőleg a pilot tapasztalataival pontosított működést mutassa be, közel az érintett csapat éles indulásához.

A kommunikációban az is szerepeljen, mikortól melyik folyamat kötelező, és mi történik a korábban indított ügyekkel. A bizonytalan átmeneti szabályok könnyen párhuzamos nyilvántartásokhoz vezetnek. Ne csak azt mondjuk el, hogyan működik az új rendszer, hanem azt is, miért változik a munkavégzés.

8. Fokozatosan élesítsünk, és támogassuk a stabilizációt

Az élesítés történhet szervezeti egységenként vagy beszerzési kategóriánként. A sorrendet az üzleti kockázat és a felkészültség alapján határozzuk meg. Minden hullám előtt ellenőrizzük az adatokat, hozzáféréseket, integrációkat és a támogatási kapacitást.

Felelős: a projektvezető koordinál; az indulásról az üzleti és IT-felelősök közösen döntenek. Kimenet: jóváhagyott átállási forgatókönyv, helyreállítási terv és üzemeltetési átadás.

Az indulás utáni időszakban legyen sűrített hibakövetés és egyértelmű eszkaláció. Különítsük el a rendszerhibát, az adatproblémát és a használati kérdést. Kövessük a felméréskor kijelölt mutatókat, majd a tapasztalatok alapján tervezzük a következő fejlesztési ütemet.

Összegzés: a bevezetés üzleti változás, nem pusztán IT-feladat

A beszerzési szoftver bevezetése akkor marad kontrollálható, ha minden lépésnek van felelőse, ellenőrizhető eredménye és elfogadási feltétele. A felmérés, konfiguráció, adatmigráció, tesztelés, pilot, oktatás és fokozatos élesítés együtt teremti meg a fenntartható működés alapját.

Beszerzési folyamatainak digitalizálását tervezi? Egyeztessen az xFLOWer szakértőivel a jelenlegi működésről, a kapcsolódó rendszerekről és az első bevezetési ütem lehetséges határairól. A közös tervezés kiindulópontja legyen egy konkrét beszerzési folyamat és annak üzleti célja.

Ez a cikk a teljes útmutatónk része: Beszerzési szoftverek: teljes útmutató a választástól a hatékony működésig