Röviden

Az ERP-program változáskezelési folyamata lehetővé teszi a szponzor számára, hogy a kérelem jóváhagyása előtt átfogó képet kapjon az értékről, a költségekről, a tesztelésről és a bevezetés hatásairól. Miután a program a kérelmet változtatásként megerősítette, a szponzornak négy lehetősége van: elfogadni, elhalasztani, kicserélni vagy elutasítani. Az ERP-programigazgató egy dokumentumban készíti el az ajánlást. A szponzor határozza meg a felhatalmazási határokat, és dönt a pénzügyi keretről, az időkeretről, valamint az azok feletti módosított alapvonalról.

Hogyan vezetnek a kisebb ERP-módosítási kérelmek a projekt terjedelmének fokozatos kiterjedéséhez

A terv jóváhagyását követően érkeznek a kérések. Első ránézésre apróságoknak tűnnek: egy új mező egy képernyőn, egy módosított jóváhagyási küszöbérték, egy másfajta jelentéselrendezés. Mindegyik szükségszerűségként kerül az irányító bizottság elé, néhány tanácsadói munkanapra becsült időigény és alacsony kockázat mellett.

Egy program irányítása anélkül is kicsúszhat a kezek közül, hogy egyetlen jelentős döntés is születne. A szponzoroknak jó okuk van igent mondani, mert a kérelmezők jól ismerik a saját működésüket. Az elutasítás akadályozónak tűnhet, ha arra figyelmeztetnek, hogy ez negatívan hat a teljesítményre vagy a hónapvégi zárásra. Ez az ösztön helyes. A nehézség abban rejlik, hogy a szponzor mit lát a döntés pillanatában.

Az ERP-rendszer hatókörének módosításai által kiváltott operatív és tesztelési hatások a rendszer alsóbb szintjein

A szponzor egy szoftveres funkciót lát az oldalon. A program azonban egy egész következményláncot von maga után. Vegyünk egy hipotetikus kérést. A készletelosztási logika kétnapos konfigurációs módosítása tíz napos egyedi szkriptfejlesztést vonhat maga után. Érvénytelenné tehet harminc befejezett, teljes körű integrációs tesztforgatókönyvet. Emellett szükségessé teheti a harmadik felek interfészeinek újratárgyalását, és elvonhatja a kulcsfontosságú üzleti felhasználókat a kritikus átállási próbáktól.

Ezek az adatok egy elképzelt igényt ábrázolnak, nem pedig bármely más változás arányát. Amikor a projekt terjedelme, a költségek, a tesztelési függőségek és a bevezetés időzítése külön-külön jelentésekben szerepelnek, egyetlen oldal sem mutatja be a teljes hatást. A kiindulási pont így anélkül változik, hogy bárki is úgy döntene, hogy megváltoztatja.

Határokon átnyúló kihívások az ERP-változáskérelmek irányításában

A párizsi, zürichi, müncheni vagy bécsi központtal kapcsolatos aggodalmak megalapozottak. Szükség van csoportszintű szabványokra, átfogó áttekinthetőségre, valamint a rendszerintegrátorral egyeztetett költségvetés betartására. Emellett az esetleges eltéréseket az igazgatóságnak is meg kell magyaráznia.

Az üzem más követelményrendszert alkalmaz. Egy első szintű üzem Lengyelországban, Csehországban, Magyarországon vagy Romániában ellátja a német autóipari szerelősorokat vagy a repülőgépipari ügyfeleket. Ezek az ügyfelek határozzák meg a szállítási időkeretek sorrendjét, a nyomonkövethetőségi ellenőrzéseket és a csomagolási szabványokat. Előfordulhat, hogy a globális sablonból hiányzik a vevő által megkövetelt vonalkód-kezelési logika vagy a konténer-újrahasznosítási jegyzék. A gyárnak ilyenkor gyors válaszra van szüksége, mivel az átállás időpontja a vevői szállítási időkeretekhez és a gyártási ütemtervekhez van kötve. Egy apró hiba akár a következő megfelelő időkeretet is jelentheti, nem csupán néhány munkanapot.

Mindkét álláspont megalapozott. Akkor keletkezik feszültség, amikor a kettő közötti folyamat lassú. Ilyenkor a gyári csapatok megoldásokat keresnek, például informálisan fordulnak egy helyi tanácsadóhoz. Ezek jelzések, nem pedig ellenszegülés.

Határon átnyúló kérelem esetén három helyről három megerősítésre van szükség. Ezek különböző szervezetekhez és jogrendszerekhez tartoznak, és egyik sem tudja egyedül megerősíteni a teljes kérelmet. A „Hatóságok” szakaszban látható, ki mit erősít meg.

Az integrátor reagál a beérkező kérésekre, a hatókör meghatározása pedig az ügyfél feladata. Ehhez szükség van egy olyan ügyféloldali vezetőre, aki kifejezett döntési jogkörrel rendelkezik a változtatások tekintetében. Ennek hiányában a csoport kétszer is fizethet: egyszer a költségvetésben nem szereplő testreszabásért, majd a rendszer élesítése utáni integrációs hibákért. Az, hogy egy helyi igény indokolja-e a globális sablon alóli eltérést, egy külön döntés, amelyet ennek megelőzően kell meghozni.

Az ERP-projektek terjedésének legfontosabb mutatói

A szponzoroknak és az ellenőrző bizottságoknak nem kell elolvasniuk a konfigurációs naplókat ahhoz, hogy észrevegyék: a projekt hatóköre eltér a tervezettől. A gyakorlati jelek arra utalnak, hogy a program elvesztette az irányítást a változások felett.

• Nem szinkronizált alapvonalak: Az integrátor, a programiroda és az üzem különböző főütemtervekkel rendelkezik.
• A dokumentálatlan hátralékos tételek: A munkacsoportok vezetői nem hivatalos listákat vezetnek azokról a tervezési finomításokról, amelyek nem kerülnek a irányító bizottság elé.
• Ismételt regressziós tesztelés: A tesztelés újraindul, mivel a szoftverbefagyasztás után új fejlesztések kerülnek bevezetésre.
• Vészhelyzeti erózió: A beszállítói módosítási megrendelések felemésztik a tartalékot, miközben a legfontosabb mérföldkövek még mindig nem teljesültek.

Egy jel önmagában még közönséges okra utalhat. Kettő együtt azonban indokolja annak felülvizsgálatát, hogy a változások hogyan kerülnek be a programba.

Az ERP-módosítási kérelmekre vonatkozó szponzori döntéshozatali keretrendszer

Az ERP-módosítási kérelmek irányítása egy rögzített kiindulási alapról indul. Ez a keretrendszer abból indul ki, hogy a program már megerősítette: az adott tétel módosításnak minősül, nem pedig befejezetlen, korábban jóváhagyott munkának. Ha az ügyfél és a megvalósító partner között még mindig vita van arról, hogy melyikről van szó, akkor először ezt a kérdést kell tisztázni. A szponzornak – vagy a programigazgatónak a ráruházott hatáskörön belül – ezután négy lehetősége van. Mindegyikhez eltérő bizonyítékokra van szükség.

1. lehetőség: Az ERP-rendszer hatókörének kiterjesztéseinek elfogadása és finanszírozása

A szponzor jóváhagyja a kiegészítést, és azt a tartalékalapból finanszírozza. Ha a függőségek megkövetelik, a szponzor írásban meghosszabbítja a tesztelési időszakot és az átállás dátumát is. Szükséges igazoló dokumentumok: írásos költségkimutatás, a belső kulcsfelhasználók munkaórái, az érintett tesztek és a hatálybalépés dátuma. A kompromisszum egyértelmű: a most felhasznált tartalékalap nem fedezheti a következő kérelmet.

2. lehetőség: Az ERP-kérelmek elhalasztása a bevezetés utáni kiadásokra

A szponzor elfogadja az értéket, és a kérést az élesítés utáni kiadásba helyezi át. Az alábbi példában ezt 1.1. fázisnak vagy második napnak nevezik. Az átállás a megállapított alapvonal szerint folytatódik. Szükséges bizonyítékok: egy megnevezett ideiglenes megoldás, valamint annak megerősítése, hogy az üzleti tevékenység az élesítés napján a módosítás nélkül is működőképes. Ennek az ára egy olyan időszak, amely alatt a kérelmezőnek megoldást kell találnia a hiányosságra.

3. lehetőség: Az ERP-projekt hatókörének módosítása az üzembe helyezés határidőinek biztosítása érdekében

A szponzor egy feltétellel fogadja el a módosítást: az eredeti kiadásból ki kell hagyni egy azzal egyenértékű, nem kritikus feladatot. Ez biztosítja a tesztelési kapacitást és a bevezetési határidőt. Szükséges igazolás: annak bizonyítása, hogy az eltávolított feladat valóban nem kritikus, valamint a felelős beleegyezése annak elhalasztásába. A kompromisszum lényege, hogy az egyik kérelem várakozik, hogy a másik továbbhaladhasson.

4. lehetőség: A nem alapvetően szükséges ERP-módosítási kérelmek elutasítása

A szponzor elutasítja a kérelmet, mert annak értéke nem indokolja a költségeket, a tesztelés megszakítását vagy az üzemeltetési kockázatot. Az elutasítás az időzítésre és a következményekre vonatkozó döntés, nem pedig az ötlet érdemeire vonatkozik. Szükséges bizonyíték: írásban rögzített indoklás, hogy a kérelmező a bevezetés után erősebb érvekkel térhessen vissza. A kompromisszum olyan folyamat, amely hiányosságot hordoz magában, és a program iránti bizalom elvesztéséhez vezethet.

Jóváhagyási jogosultság az ERP-rendszer változáskezelési folyamatában

Az ERP-program igazgatója felhatalmazás alapján rendelkezik változáskezelési jogosultsággal. Ő értékeli a műszaki megvalósíthatóságot, a különböző munkaterületek közötti függőségeket és az erőforrások rendelkezésre állását, majd javaslatot tesz. Az igazgatónak emellett jogosultsággal kell rendelkeznie ahhoz, hogy felfüggessze az informális feladatkör-bővítéseket, és egyértelmű üzleti döntési lehetőségeket terjesszen a szponzor elé.

A delegált határértékek felett a szponzor hozza meg azokat a döntéseket, amelyek pénzügyi és időbeli következményekkel járnak. Ezek kiterjednek a tőkére, az ütemtervre és az üzembe helyezés időpontjára. Ez lehet a csoport pénzügyi igazgatója, a csoport operatív igazgatója vagy egy másik vezető tisztségviselő.

Az ERP-költségvetés és ütemterv módosításaihoz kapcsolódó szponzori eskalációs feltételek

Az ERP-költségvetés-módosítások ellenőrzése akkor működik hatékonyan, ha a kezdeményező már korán meghatározza a felhatalmazási határértékeket. Ezeket az első kérelem benyújtása előtt kell megállapítani, nem pedig egy későbbi kérelem miatti vita során. A kezdeményező minden egyes kérelemre külön határértéket, valamint a váratlan kiadásokra vonatkozó összesített határértéket állapít meg. Az a kérelem, amelyet a határérték alatt maradás érdekében több részre osztanak, egyetlen kérelemnek számít. Ezek a feltételek azt eredményezik, hogy a kérelem közvetlenül a kezdeményezőhöz kerül.

• A kérelem módosítja az üzembe helyezés dátumát vagy egy másik, már rögzített mérföldkövet.
• Ez a kérelem – az eddig jóváhagyottakkal együtt – a szponzor által meghatározott határ feletti tartalékra támaszkodik.
• A kérelem egy szakasz-kapu kritériumot vagy egy jóváhagyott tervet módosít.
• Az integrátor és a programigazgató nem értenek egyet a hatásokkal kapcsolatban.

A küszöbérték alatt maradó összegeket a programigazgató kezeli, aki nyilvántartásba veszi azokat, és minden irányítási ciklusban jelentést készít a tartalékegyenlegről.

Gyárak és a csoportközpontok határokon átnyúló jóváhagyási szerepkörei

Az üzemvezető vagy az ügyvezető igazolja, hogy a kérelem üzemeltetési szempontból szükséges. Az üzem székhelye szerinti országban képesített szakértők igazolják az esetleges jogi követelmények teljesülését. A központi iroda megerősíti a vállalatcsoport szabványainak betartását, és jóváhagyja a források kiutalását.

A világos határok mindkét fél érdekeit szolgálják. Az üzem a kérelmet elsőként tárgyaló irányító bizottság ülésén kapja meg a döntést vagy a dátummal ellátott bizonyíték-kérést. Az ügyfél által előírt vagy jogszabályban előírt kérelmek esetében a kezdeményező meghatározhat egy cikluson kívüli eljárást, és dönthet annak gyakoriságáról. A központi iroda minden döntést egyetlen nyilvántartásban követ nyomon.

Az ERP-átállási döntési rekord kötelező mezői

A változás-döntési jegyzőkönyv minden kérelemhez egy oldalt biztosít a kezdeményező számára. Ez az ERP-rendszer hatókörének változáskezeléséhez szükséges munkaeszköz. A CE Interim ezt gyakorlati segédeszközként javasolja, nem pedig elismert szabványként. Hat mezőből áll.

• A módosítási kérelem leírása: mit kér a kérelmező, és miért éppen most.
• Üzleti érték és működési indoklás: az általa védett folyamat.
• Szállítói költségek és a belső erőforrásokra gyakorolt hatás: a külső díj, a belső munkaidő, valamint a tartalék egyenlege a változás előtt és után.
• A függőségek és az ütemterv hatásának vizsgálata: az érintett tesztek és időpontok.
• Kiváltott vagy kicserélt hatály: mi marad hatályban, ha egyáltalán marad valami.
• Jóváhagyott döntés és frissített kiindulási állapot: a jóváhagyó személye, a kiválasztott lehetőség és a módosított terv.

A programigazgató rögzíti a hatást, mielőtt a szponzor döntést hozna. Ezt követően az igazgató frissíti a kapcsolódó tervet, és tájékoztatja az érintett helyszíneket és az integrátort. A bevezetés jóváhagyása, a szerződés és az átvételi kritériumok külön döntések, amelyekhez saját bizonyítékok tartoznak. Ezek a szponzornál maradnak, vagy az igazgatóságnál, amennyiben az elnöki poszt betöltetlen. Az igazgatóság által jóváhagyott dátum bármilyen módosítását szintén az igazgatóságnak kell jóváhagynia.

Ellenőrzőlista a szponzorok hitelesítéséhez az ERP-projekt hatókörének módosításainak jóváhagyása előtt

Egy ajánlat csak annyira megbízható, amennyire a benne szereplő számadatok. Egy tapasztalt megbízó nem bízik meg egy olyan ajánlatban, amelyhez csak egy becslés csatolva van, mivel minden fél csak a saját részét árazza be.

Először is, határozzuk meg, mit hagy ki az egyes becslések: az újratesztelést, a kulcsfelhasználók munkaidejét, az interfész-felelősöket és az átállási próbára szánt időt. Másodszor, gyűjtsük össze egy táblázatba az integrátor, az üzem és a központi pénzügyi osztály adatait, hogy egyik fél se értékelje saját hatását. Csak ezután tegyük fel a döntő kérdést: működhet-e a vállalkozás a bevezetés napján e változás nélkül?

Egy nem kritikus folyamatban a kézi lépés maradhat tökéletlen. Ugyanez vonatkozik egy olyan jelentésre is, amely az első kiadásra vár. A számlázás, a készletnyilvántartás, az ügyfeleknek történő kiszállítás vagy a jogi előírások betartása terén azonban nem lehetnek hiányosságok. A fennmaradó kompromisszum a vészhelyzeti tartalék. Minden jóváhagyás olyan pénzt emészt fel, amely már nem fedezheti a következő kérelmet, ezért a szponzornak tisztában kell lennie az egyenleggel, mielőtt igent mondana.

Esettanulmányok: Az ERP-rendszer hatókörének változásainak tényeken alapuló értékelése

Ez a forgatókönyv hipotetikus. Nem egy CE Interim ügyfélről van szó, és az adatok csupán illusztrációs jellegűek, nem pedig referenciaértékek. Egy osztrák tulajdonú autóipari beszállító a csoportos ERP-sablonját vezeti be egy lengyelországi gyárában. Egy irányítási ciklus során több kérelem is beérkezik, amelyek mindegyikét „kis” kategóriájúként jelölnek meg.

Az értekezlet előtt az ERP-program igazgatója minden kérelmet rögzít a változtatási döntési jegyzőkönyvben. Az integrátor írásban ismerteti a költségekre, a tesztelésre és a határidőkre gyakorolt hatásokat. Az üzem és a központi pénzügyi osztály megadja a belső munkaórákat. A jegyzőkönyv strukturált keretet biztosít a szponzor számára az egyes javasolt ERP-változtatások áttekintéséhez, összehangolásához és jóváhagyásához. Ezzel megakadályozza, hogy bármilyen hatókör-módosítás a költségek, a tesztelés és a szállítási mérföldkövek kifejezett átláthatósága nélkül kerüljön beépítésre.

Alkalmazási példa: Automatizált, a vonal mellett történő visszafoglalás

Az üzem azt szeretné, ha az operátorok felhagynának a visszavitt hulladékok kézi rögzítésével, és ez a kérés megfelel az alapkövetelményeknek.

• Kérés: Automatizált, gyártósor melletti visszaküldés-foglalás.
• Előny: Megszünteti a selejt visszajuttatásának kézi rögzítését; műszakonként 1,5 adminisztratív órát takarít meg.
• Költség: 18 500 euró külső szolgáltatói díj; 45 óra belső kulcsfelhasználói konfigurációs munkaidő.
• Tesztelés és ütemterv: 4 napos regressziós tesztelésre van szükség az Assembly munkacsoportban; a kritikus út késedelme nulla.
• A hatály kiterjesztése: Nincs szükség rá; a váratlan események kezelése biztosítva.
• Döntés és kiindulási állapot: Jóváhagyva („Most elfogadom”): A kiindulási költségvetés frissítve; a tesztelés a 4. sprintben befejeződött.

Az üzemvezető megerősíti a szükségességet. A hatás kezelhető: a tesztelés egy olyan munkamenetbe illeszkedik, amelyben van szabad kapacitás, és a kritikus út változatlan marad. Mivel nem lép érvénybe semmilyen eskalációs feltétel, a programigazgató a ráruházott hatáskörön belül jóváhagyja a változtatást. A feljegyzésben rögzítik a döntést a megbízó számára. Az igazgató frissíti az alapvonalat, és ugyanazon irányítási cikluson belül jelentést készít a fennmaradó tartalékról.

A Scope Exchange példája: Egyedi vezetői KPI-műszerfal

A vállalatcsoport vezetői a statikus táblázatos jelentések helyett egy irányítópultot szeretnének, és ez az igény teljesen indokolt.

• Kérés: Egyedi vezetői KPI-műszerfal.
• Érték: Felváltja a csoport vezetői csapat számára készített statikus táblázatos jelentéseket.
• Költség: 34 000 euró a beszállítói rendszer fejlesztésére; 30 óra a központi pénzügyi jelentések áttekintésére.
• Tesztelés és ütemterv: Magas komplexitás; a felhasználói átvételi tesztelés ideje alatt lekötik a fő jelentéskészítő rendszermérnököket.
• Áthelyezett hatály: A nem kritikus költségközpontokra vonatkozó összefoglaló jelentések elkészítését halasszuk el a második napra.
• Döntés és kiindulási állapot: A hatály módosítása: A kezdeti kiadás jóváhagyva; az összefoglaló jelentések elkészítését az 1.1. fázisra halasztották.

A központi vezetésnek itt valódi igénye van: az üzem megbízható átláthatóságára. A költségek nem csupán a szállítói díjra korlátozódnak, mivel az átvételi teszteléshez ugyanazokra a jelentéskészítő szakemberekre van szükség. A jóváhagyott összefoglaló jelentések elhalasztása a jóváhagyott terv módosítását jelenti, ami eskalációt vált ki. A projektfelelős rögzíti a jelentés készítőjének írásbeli beleegyezését az elhalasztásba, majd a jelentéseket kicseréli, nem pedig kiegészíti. A műszerfal csatlakozik a kezdeti kiadáshoz.

Halasztási példa: Ügyfélspecifikus raklapnyomonkövethetőség

Egy regionális forgalmazónak nem szokványos logisztikai igényei vannak, és a kereskedelmi kapcsolat is fontos.

• Kérés: Ügyfélspecifikus raklap-nyomonkövethetőség.
• Érték: Egyetlen regionális forgalmazó nem szabványos logisztikai igényének teljesítése.
• Költség: 26 000 euró eladói díj; a raktárkezelési modulban kiterjedt, egyedi logika.
• Tesztelés és ütemterv: A raktárkezelési rendszer integrációjának jóváhagyását 12 munkanappal elhalasztja.
• Eltérő hatály: A kérelmező munkacsoport nem azonosított ilyet.
• Döntés és kiindulási állapot: Átirányítva az 1.1. fázisba: A bevezetés után 60 nappal üzembe helyezve; kezdetben kézi csomagolási napló használata.

A késedelem miatt egy már rögzített mérföldkő elhalasztásra kerül, ami eskalációt vált ki, és a kérelmet benyújtó munkacsoportnak nincs lehetősége a feladatra való lemondásra. Az üzemvezető megerősíti, hogy a forgalmazónak az első naptól kezdve működőképes folyamatra van szüksége. Ezt egy kézi napló biztosítja. A projektfelelős elhalasztja a kérelmet, a raktárvezetőt nevezi meg a napló felelősének, és meghatározza a felülvizsgálat időpontját.

Elutasítási példa: Automatizált beszállítói önszámlázás

A pénzügyi részleg gyorsabb számlaegyeztetést szeretne az egész beszállítói hálózatban, és ennek előnyei kézenfekvőek.

• Kérés: Automatizált beszállítói önszámlázás.
• Érték: Felgyorsítja a szállítói számlák egyeztetését az európai beszállítói hálózatban.
• Költségek: 52 000 eurós fejlesztés az eladó részéről; az EDI-interfész jelentős átalakítása.
• Tesztelés és ütemterv: Módosítja az alapvető pénzügyi könyvelési szabályokat; veszélyezteti a fő pénzügyi rendszer átállásának időkeretét.
• Elmozdult hatály: Nincs; a kérelmező csapat nem hajlandó módosítani a feladat körét.
• Döntés és kiindulási helyzet: Elutasítva: Magas ütemtervi kockázat; az élesítésig a szokásos megrendelések összehangolását tartjuk fenn.

A döntés az ütemtervi kockázaton múlik, nem pedig az érdemi szempontokon. A kérelem a pénzügyi könyvelés alapvető szabályait módosítja, ami egy már jóváhagyott terv megváltoztatását jelenti, és eskalációt vált ki. A kérelmező csapat nem módosítja a projekt hatókörét. A megbízó fenntartja a rendszerbevezetéshez tartozó szokásos összehangolást, és rögzíti az indokot. Az önszámlázás az országonként eltérő számlázási szabályokat is érinti. Lengyelországban képesített szakértők megerősítik, hogy a szabályok mit engedélyeznek, mielőtt az ötlet visszakerülne.

Az ERP-rendszer hatókörének módosítására vonatkozó példák legfontosabb tanulságai

Ugyanaz a bejegyzés különböző válaszokat eredményezett egymáshoz hasonló kérésekre, és egyik sem jelentett általános befagyasztást. Ezek ebben a forgatókönyvben megfigyelhető mintázatok, nem pedig szabályok. Az elfogadott kérelem hatása korlátozott volt, és a kritikus út megmaradt. A csere azért működött, mert a tesztkapacitás jelentette a korlátot, és egy nem kritikus elemnek volt hajlandó felelőse. Az elhalasztás azért működött, mert az üzletmenet egy megnevezett ideiglenes megoldás alapján is működhetett. Az elutasítás a magas ütemtervi kockázatot követte, és nem volt lehetőség a feladatra.

A létesítmény minden kérelemre indokolt választ kapott, beleértve azokat is, amelyek nem kerültek elfogadásra. Az elfogadott kérelem a tartalékból került fedezésre, így a következő kérelemre már kevesebb tartalék áll rendelkezésre. A csoport olyan alapszintet tart fenn, amelyet meg tud magyarázni.

Az ERP-rendszer hatókör-módosítások ellenőrzésében fennálló irányítási hiányosságok kezelése

Egy kompetens belső szerv képes kezelni az ERP-rendszer hatókörének módosításait, a ráruházott hatáskörök keretein belül, valamint a projekt kezdeményezőjéhez vezető útvonalat biztosítva. A projekt kezdeményezője – vagy amennyiben az pozíció betöltetlen, az igazgatóság – ellenőrizheti, hogy a módosítások megfelelnek-e a programnyilvántartásban szereplő feltételeknek.

• Egyetlen ügyféloldali vezető sem felel egyidejűleg a költségvetésért, a teszttervért és az átállási tervért, ezért ezeket külön fórumok határozzák meg.
• A programigazgató nem állíthatja le a nem hivatalos feladatkör-kiterjesztéseket, mivel senki sem ruházta rá írásban ezt a jogosultságot.
• A szponzor pozíciója betöltetlen, vagy a szponzor maga vezeti a vállalkozást, ezért a kérelmek egy irányító cikluson túlra halasztódnak.
• Az integrátor, az üzem és a pénzügyi részleg által közölt hatástanulmányi adatok továbbra is eltérnek egymástól, és senkinek nincs jogosultsága ezeket egyeztetni.

Ha ezek közül kettő vagy több is fennáll, a program már nem dönt egyetlen bejegyzés alapján a kérelmekről. Ebben az esetben fennáll annak a kockázata, hogy a csoport kétszer fizet, vagy a rendszer alapértelmezés szerint módosítja a testület ülésének időpontját. A CE Interim véleménye szerint a program ilyen esetben a vállalat számára kritikus kockázatot jelent, és olyan ügyféloldali vezetőre van szükség, aki végrehajtói hatáskörrel rendelkezik. A határidő önmagában nem indokolja egy ideiglenes vezető kinevezését.

Az ideiglenes átalakítási igazgató szerepe az ERP-irányításban

Egy Ideiglenes átalakítási és programigazgató rendelkezhet az ügyfél oldali változtatási jogosultsággal. A szerepkör egy írásbeli felhatalmazás keretein belül hoz döntéseket. Azon személynek tartozik felelősséggel, aki a felhatalmazást adta: a szponzornak, vagy – amennyiben az a pozíció betöltetlen – az igazgatóságnak. Nem az integrátor projektmenedzsere, és nem is olyan tanácsadó, aki csupán ajánlásokat fogalmaz meg.

A megbízás előírja a felhatalmazás korlátait, amelyeket az adatok egyetlen nyilvántartásba való felvétele után határoznak meg. Az ideiglenes vezetőt nevezi meg az ügyféloldali terv kizárólagos felelős tulajdonosaként. Meghatározza az eskalációs útvonalat, és rögzíti az ügy átadását egy kijelölt tulajdonosnak. A vezető együttesen terjeszti a döntéshozó elé az üzem igényigazolását, a helyi jogi megerősítést és a központi székhely tőke-jóváhagyását.

A CE ideiglenes partnerek ellenőrzik a változási jegyzőkönyv minőségét, és támogatják az ügyek magasabb szintre történő továbbítását. Megállapodott időközönként tájékoztatják a felhatalmazást adó személyt az előrehaladásról, és felügyelik az ügy átadását.

Az ügyvezetői felügyeletre vonatkozó ideiglenes megbízatás kereteinek meghatározása

Ha az igazgatói poszt betöltetlen, vagy nincs írásbeli felhatalmazás, akkor a megbízatás idejére az ideiglenes ügyvezető tölti be azt. Ugyanez vonatkozik arra az esetre is, ha az integrátor vagy az IT szervezeten belül található.

Amennyiben van alkalmas igazgató, de a hiány a szponzor szintjén áll fenn, a megbízás az igazgató felett érvényesül. Ha a szponzori pozíció betöltetlen, az igazgatóság a megbízás kezdete előtt kijelöli azt a személyt, aki a fenntartott döntési jogkörrel rendelkezik. Ezek a határok feletti tőkére, az ütemtervre és az üzembe helyezés időpontjára vonatkoznak. Egy Interim CFO vagy Interim COO az igazgatóság által meghatározott keretek között tarthatja őket.

A sorrend fontos. Először a vezető egyetlen nyilvántartásba összesíti az integrátor, az üzem és a pénzügyi részleg hatást mutató adatait. A vezető ezenkívül felveszi ebbe a nyilvántartásba az informális megrendelésállományt is, és felhatalmazást kap arra, hogy felfüggessze az új informális hozzáadások felvételét. Ezután a szponzor – vagy az igazgatóság, amennyiben az adott pozíció betöltetlen – ezen az alapon határozza meg a felhatalmazási korlátokat. Csak ezután indítja el a vezető a irányítási ciklust, a kezdetben megállapodott átadási határidővel.

A kinevezés nem módosítja a végrehajtási szerződést, nem mentesít az átvételi feltételek alól, és nem jogosít fel a projekt elindítására. Ezek a döntések továbbra is a szponzor hatáskörébe tartoznak, illetve – amennyiben a pozíció betöltetlen – az Igazgatóságéba. Az Igazgatóság által jóváhagyott határidők bármilyen módosítását szintén az Igazgatóságnak kell jóváhagynia.

Az ERP-rendszer hatókörének irányításáról szóló útmutatás közzététele

Két nyilvánosan hozzáférhető forrás alátámasztja a hatókör szabályozásának elvét. A Microsoft Dynamics 365 útmutatója olyan tervezőtáblákat ismertet, amelyek felülvizsgálni és jóváhagyni megoldástervek. A dokumentum szerint a csapatoknak be kell tartaniuk a szakasz-kapu kritériumokat, és nem szabad azokat "nyomás vagy túlzott optimizmus miatt" kihagyniuk.

Az Atreus ERP-szolgáltató a következőket közli: az értékesítés utáni szolgáltatások ERP-rendszerének bevezetése során felmerült költségtúllépés hogy stabilizálódott. Újratervezte a projekt hatókörét, költségvetését és fázisait, valamint meghatározta az üzleti részleg, az IT és a partnerek szerepeit és felelősségi köreit. Egyik forrás sem írja le ezt a tényt, és egyik sem jelöli meg egyetlen változást sem az okként. Az Atreus egy szolgáltatói jelentés, nem pedig független audit.

Gyakran feltett kérdések az ERP-rendszer hatókörének módosítás-ellenőrzéséről

Az ERP-projekt hatókörének módosításait a rendszer élesítésének közeledtével be kell-e fagyasztani?

Ez nem általános szabály. A befagyasztás a vállalkozás működésképtelenségéhez vezethet. Az olyan változtatás, amely jogi követelménynek felel meg vagy egy kritikus folyamatot véd, erős érveket szolgáltat az elfogadás mellett. Az üzem országában működő szakértőknek meg kell erősíteniük, hogy a követelmény valóban fennáll. A nem alapvetően szükséges fejlesztések várhatnak egy későbbi kiadásra.

Ki hagyja jóvá a módosításokat az ERP-rendszer hatókör-változás-ellenőrzési folyamatában?

Az ERP-program igazgatója a ráruházott hatáskörön belül jóváhagyja a kérelmeket, és nyilvántartásba veszi azokat. Az a kérelem, amely megfelel egy kiváltó feltételnek, az ügyvezető szponzorhoz kerül, aki dönt a beruházásról, az ütemtervről és az üzembe helyezés időpontjáról. A szponzor emellett rendezi az integrátor és a programigazgató között a hatásokkal kapcsolatban felmerülő esetleges nézeteltéréseket is.

Az ideiglenes vezető helyettesíti-e az ERP-program igazgatóját?

Alapértelmezés szerint nem. A szerepet egy írásbeli felhatalmazással rendelkező, alkalmas igazgató tölti be. Amennyiben ideiglenes vezető tölti be a tisztséget, a megbízás határozza meg a jelentési hierarchiát és a felhatalmazás határait. Ezenkívül a kezdetektől fogva rögzíti az átadás időpontját is. A szerződéskötési, elfogadási és bevezetési döntések a szponzornál maradnak, vagy – amennyiben a pozíció betöltetlen – az igazgatóságnál.

Mi történik a megállapodás szerinti bevezetési dátummal, ha az ERP-váltást jóváhagyják?

A szponzor írásban újra meghatározza a program alapvető paramétereit: a fő ütemtervet, a szakasz-kapu határidőket, az integrációs tesztterveket és a költségvetést. Ezt követően a programigazgató értesíti az összes érintett telephelyet és beszállítót. Amennyiben az igazgatótanács már jóváhagyta az eredeti határidőt, a szponzor először az új határidőt terjeszti az igazgatótanács elé.

Kapcsolódó ismeretek és a következő lépés

Az ERP-rendszer hatókör-módosításainak ellenőrzése védi az alapállapotot, mivel minden kérelem költség-, teszt- és időbeli hatásait egyetlen döntés keretében figyelembe veszik. Ezek nélkül jóváhagyott kérelem esetén a rendszer üzembe helyezése megtörténhet, mielőtt az igazgatóság új határidőt állapított volna meg. A szponzor – vagy az igazgatóság, ha a szponzor helye betöltetlen – először a fenti feltételeket ellenőrzi a programnyilvántartás alapján. A következő lépés a felhatalmazási határok meghatározása, valamint annak elbírálása, hogy a hiányosság program- vagy szponzorszinten jelentkezik-e.

További olvasnivaló:

• Egy amerikai gyár bezárása Németországból: az ideiglenes telephelyvezető, aki hat hónap alatt véghezvitte a feladatot
• Egy beszállító több közép-kelet-európai üzemet is ellát. Hogyan kell elosztani a korlátozott mennyiségű anyagot?
• Miért nem jelenti a gyártási költségcél a működési modell átalakítását?

A CE Interim határokon átnyúló vezetői támogatást nyújt kritikus üzleti átalakításokhoz. A megbízási leírás elkészülte után egy előzetesen átvilágított, a megbízás követelményeinek megfelelő és titoktartási megállapodást aláíró vezető áll készen a munkába állásra.

Ha a fenti feltételek közül kettő vagy több teljesül, forduljon egy CE ideiglenes partner a megbízásról.