Změna v systému ERP se zdá být drobná. Kdo schvaluje její dopad na náklady a termín zavedení?

U napůl zvednuté závorové brány před polským závodem s osvětlenou nakládací rampou stojí malá bedna na ručním vozíku; s vínově červenou trasou, která ji spojuje s ústředím rakouské skupiny.

Stručně řečeno

Řízení změn v rámci ERP poskytuje zadavateli ucelený přehled o přínosu, nákladech, testování a dopadu na spuštění ještě před schválením žádosti. Jakmile program potvrdí žádost jako změnu, má zadavatel čtyři možnosti: přijmout, odložit, vyměnit nebo zamítnout. Ředitel programu ERP připraví doporučení v rámci jednoho záznamu. Sponzor stanoví limity delegovaných pravomocí a rozhoduje o finančních prostředcích, časovém harmonogramu a revidované základní linii nad těmito limity.

Jak i drobné požadavky na změny v ERP systému vedou k rozšiřování rozsahu projektu

Po schválení návrhu začnou přicházet požadavky. Na první pohled se zdají být drobné: nové pole na obrazovce, změněná prahová hodnota pro schválení, jiné rozvržení přehledu. Každý z nich se dostane k řídícímu výboru jako nezbytnost, přičemž je popsán jako úkol vyžadující několik konzultačních dnů a představující nízké riziko.

Program může ztratit kontrolu, aniž by došlo k jedinému zásadnímu rozhodnutí. Sponzoři mají pádné důvody k tomu, aby žádost schválili, protože žadatelé znají jejich provoz. Odmítnutí může působit jako překážka, když žadatelé varují, že tím utrpí výkonnost nebo závěrka na konci měsíce. Tento instinkt je oprávněný. Problémem je to, co sponzor vidí v okamžiku rozhodování.

Dopady změn rozsahu ERP na provoz a testování v navazujících fázích

Zadavatel vidí na stránce softwarovou funkci. Za tímto programem se skrývá řada důsledků. Vezměme si jeden hypotetický požadavek. Dvoudenní změna konfigurace logiky přidělování zásob může vyvolat desetidenní vývoj skriptů na míru. Může zneplatnit třicet dokončených scénářů komplexních integračních testů. Může také vyžadovat nové vyjednávání o rozhraních třetích stran a odlákat klíčové obchodní uživatele od důležitých nácviků přechodu na nový systém.

Tyto údaje popisují jeden hypotetický požadavek, nikoli poměr pro jakoukoli jinou změnu. Pokud jsou rozsah, náklady, závislosti na testování a termín uvedení do provozu uvedeny v samostatných zprávách, žádná jednotlivá stránka nezobrazuje celkový dopad. Výchozí stav se pak mění, aniž by se někdo rozhodl jej změnit.

Přeshraniční výzvy v oblasti řízení žádostí o změny v ERP systémech

Umístění ústředí v Paříži, Curychu, Mnichově nebo Vídni vyvolává oprávněné obavy. Je zapotřebí stanovit skupinové standardy, zajistit ucelený přehled a dodržovat rozpočet dohodnutý se systémovým integrátorem. Jakékoli odchylky je rovněž nutné vysvětlit představenstvu.

Závod používá odlišnou sadu. Závod první úrovně v Polsku, České republice, Maďarsku nebo Rumunsku může zásobovat německé montážní linky v automobilovém průmyslu nebo zákazníky z leteckého a kosmického průmyslu. Tito zákazníci stanovují časová okna pro dodávky, audity sledovatelnosti a standardy balení. Globální šablona může postrádat logiku čárových kódů nebo seznamy recyklace kontejnerů, které zákazník vyžaduje. Závod pak potřebuje rychlou odpověď, protože termín přechodu na nový systém je vázán na dodací termíny zákazníků a výrobní kalendáře. Jakékoli zpoždění může znamenat čekání na další volný termín, což může trvat i několik pracovních dnů.

Oba postoje jsou opodstatněné. K třenicím dochází, když je komunikace mezi nimi pomalá. Týmy v závodech pak hledají náhradní řešení, jako je například neformální žádost adresovaná místnímu konzultantovi. Jde o signály, nikoli o vzdor.

V případě přeshraniční žádosti jsou zapotřebí tři potvrzení ze tří různých míst. Tato místa spadají pod různé subjekty a právní systémy a žádný z nich nemůže potvrdit celou žádost sám. V části „Oprávnění“ je uvedeno, kdo co potvrzuje.

Integrátor reaguje na přijaté požadavky, přičemž rozhodnutí o rozsahu projektu je na straně zákazníka. To vyžaduje, aby na straně zákazníka byl vedoucí pracovník s jasně stanovenými pravomocemi k provádění změn. Bez něj může skupina zaplatit dvakrát: za neplánované přizpůsobení a poté za integrační chyby po spuštění systému. Zda místní potřeba ospravedlňuje výjimku z globální šablony, je samostatné rozhodnutí, které se přijímá ještě před tímto rozhodnutím.

Klíčové ukazatele postupného rozšiřování rozsahu projektu ERP

Sponzoři a auditní výbory nemusí číst konfigurační protokoly, aby zjistili, že dochází k odchylkám v rozsahu. Praktické známky naznačují, že program ztratil kontrolu nad změnami.

Nesynchronizované základní čáry: Integrátor, programová kancelář a závod mají různé hlavní harmonogramy.
Položky v nevyřízených záznamech bez dokumentace: Vedoucí pracovních skupin vedou neformální seznamy návrhových úprav, které se nedostanou až k řídícímu výboru.
Opakované testování regrese: Testování se obnoví, protože po zmrazení vývoje softwaru jsou zaváděna nová vylepšení.
Eroze způsobená nepředvídanými okolnostmi: Změnové příkazy dodavatelů čerpají rezervní prostředky, zatímco klíčové milníky zůstávají nesplněny.

Už jeden příznak může mít běžnou příčinu. Dva příznaky dohromady jsou důvodem k přezkoumání toho, jak se změny dostávají do programu.

Řízení žádostí o změny v systému ERP vychází z dohodnutého výchozího stavu. Tento rámec předpokládá, že program již danou položku potvrdil jako změnu, nikoli jako nedokončenou dohodnutou práci. Pokud se klient a implementační partner stále neshodnou na tom, o co se jedná, je třeba nejprve vyjasnit tuto hranici. Sponzor, případně ředitel programu v rámci svěřených pravomocí, má poté čtyři možnosti. Každá z nich vyžaduje jiné podklady.

Možnost 1: Schválit a financovat rozšíření rozsahu ERP

Sponzor schválí tento dodatek a financuje jej z rezervy na nepředvídané výdaje. Pokud to vyžadují závislosti, sponzor také písemně prodlouží lhůtu pro testování a termín přechodu. Požadované podklady: písemný odhad nákladů, počet hodin interních klíčových uživatelů, dotčené testy a datum, od kterého se změna projeví. Kompromis je zřejmý. Prostředky z rezervy vynaložené nyní již nebudou k dispozici pro další žádost.

Možnost 2: Odložit požadavky na ERP do verzí vydaných po spuštění

Sponzor přijme návrh a přesune žádost do vydání po uvedení do provozu. V níže uvedeném příkladu se tato fáze označuje jako Fáze 1.1 nebo Den 2. Přechod probíhá podle stanovené základní linie. Požadované podklady: konkrétní dočasné provizorní řešení a potvrzení, že podnik může v den spuštění fungovat i bez dané změny. Kompromisem je období, během kterého žadatel obchází danou mezeru.

Možnost 3: Úprava rozsahu ERP s cílem zajistit dodržení termínů spuštění

Zadavatel souhlasí se změnou pod jednou podmínkou: z původní verze musí být vyřazena stávající položka stejného rozsahu, která není kritická. Tím se zajistí kapacita pro testování a dodržení termínu uvedení do provozu. Požadované podklady: důkaz, že vyřazená položka skutečně není kritická, a souhlas jejího vlastníka s jejím odložením. Kompromisem je, že jeden požadavek musí počkat, aby mohl být realizován jiný.

Možnost 4: Zamítnout žádosti o změny v systému ERP, které nejsou nezbytné

Sponzor žádost zamítá, protože její hodnota neodůvodňuje náklady, narušení testování ani provozní riziko. Zamítnutí je posouzením načasování a důsledků, nikoli kvality samotného nápadu. Požadované podklady: zdůvodnění, aby žadatel mohl po spuštění projektu předložit přesvědčivější argumenty. Kompromis je proces, který s sebou nese mezeru a může vést ke ztrátě důvěry v program.

Schvalovací orgán v rámci řízení změn v systému ERP

Ředitel programu ERP disponuje delegovanou pravomocí v oblasti řízení změn. Tato osoba posuzuje technickou proveditelnost, vzájemné závislosti mezi jednotlivými pracovními toky a dostupnost zdrojů a následně předkládá doporučení. Ředitel rovněž potřebuje pravomoc pozastavit neformální rozšíření rozsahu projektu a předložit sponzorovi jasné obchodní možnosti.

Nad rámec delegovaných pravomocí má rozhodovací pravomoc ohledně finančních prostředků a času sponzor. Tato pravomoc se týká kapitálu, časového harmonogramu a data uvedení do provozu. Může jím být finanční ředitel skupiny, provozní ředitel skupiny nebo jiný člen vedení s odpovědností za daný projekt.

Kontrola změn rozpočtu v systému ERP funguje, pokud zadavatel včas stanoví limity pro delegování pravomocí. Tyto limity je třeba stanovit ještě před podáním první žádosti, nikoli až v průběhu sporu ohledně některé z pozdějších žádostí. Zadavatel stanoví limit pro každou žádost a celkový limit pro nepředvídané výdaje. Žádost rozdělená tak, aby nepřekročila stanovený limit, se počítá jako jedna žádost. Tyto spouštěcí mechanismy přesměrují žádost přímo k zadavateli.

Tato žádost posouvá datum spuštění do ostrého provozu nebo jiný stanovený milník.
Tato žádost, spolu s dosud schválenými žádostmi, čerpá z rezervních prostředků nad rámec limitu stanoveného navrhovatelem.
Žádost mění kritérium fáze-brány nebo schválený návrh.
Integrátor a programový ředitel se neshodují ohledně dopadu.

Všechny položky pod hranicí spouštěcích hodnot zůstávají v kompetenci programového ředitele, který je eviduje a v každém řídicím cyklu podává zprávu o zůstatku rezervy.

Role v rámci přeshraničního schvalovacího procesu pro závody a ústředí skupiny

Vedoucí závodu nebo generální ředitel potvrdí, že daná žádost je z provozního hlediska nezbytná. Odborníci s příslušnou kvalifikací v zemi, kde se závod nachází, ověří splnění všech zákonných požadavků. Centrála potvrdí soulad se standardy skupiny a uvolní finanční prostředky.

Jasně stanovené lhůty jsou ku prospěchu obou stran. Závod obdrží rozhodnutí nebo datovanou žádost o předložení důkazů na prvním zasedání řídícího výboru, který se touto žádostí zabývá. V případě žádostí na základě požadavku zákazníka nebo ze zákona může zadavatel stanovit postup mimo běžný cyklus a určit jeho interval. Centrála má přehled o každém rozhodnutí v rámci jednoho záznamu.

Povinná pole v záznamu o rozhodnutí o změně ERP systému

Záznam o rozhodnutí o změně poskytuje zadavateli jednu stránku pro každou žádost. Jedná se o pracovní nástroj pro řízení změn v rámci ERP. CE Interim jej navrhuje jako praktickou pomůcku, nikoli jako uznávanou normu. Obsahuje šest polí.

Popis požadavku na změnu: co žadatel požaduje a proč právě teď.
Obchodní hodnota a provozní opodstatnění: proces, který chrání.
Náklady dodavatele a dopad na interní zdroje: externí poplatek, interní pracovní hodiny a zůstatek rezervy před a po.
Testování závislostí a vlivu harmonogramu: testy a termíny, kterých se to týká.
Změna nebo výměna rozsahu: co případně zůstane v platnosti.
Schválené rozhodnutí a aktualizovaný výchozí stav: schvalovatel, zvolená varianta a revidovaný plán.

Ředitel programu zaznamená dopad ještě předtím, než sponzor přijme rozhodnutí. Poté ředitel aktualizuje související plán a informuje dotčené lokality a integrátora. Schválení spuštění, smlouva a kritéria přijetí jsou samostatná rozhodnutí s vlastními podklady. O těchto rozhodnutích rozhoduje sponzor, případně představenstvo, pokud je místo neobsazené. Jakákoli změna termínu, ke kterému se představenstvo zavázalo, se rovněž předkládá představenstvu.

Spolehlivost nabídky závisí na spolehlivosti údajů v ní uvedených. Zkušený zadavatel nedůvěřuje nabídce, která obsahuje pouze jeden odhad, protože každá strana stanovuje cenu pouze za svou vlastní část.

Nejprve si ujasněte, co každý odhad opomíjí: opakované testování, pracovní hodiny klíčových uživatelů, správce rozhraní a čas na nácvik přechodu. Za druhé, shromážděte údaje od integrátora, závodu a centrálního finančního oddělení do jednoho přehledu, aby žádná ze stran nehodnotila svůj vlastní dopad. Teprve poté si položte rozhodující otázku: může podnik v den spuštění fungovat bez této změny?

Ruční krok v nekritickém procesu může zůstat nedokonalý. Stejně tak i zpráva, která čeká na první vydání. Mezery ve fakturaci, řízení zásob, expedici zákazníkům nebo dodržování právních předpisů by však neměly. Zbývá ještě zvážit kompromis v podobě rezervy. Každé schválení stojí peníze, které pak nelze použít na pokrytí další žádosti, a proto by měl zadavatel znát celkovou bilanci, než dá souhlas.

Příklady z praxe: Vyhodnocení změn rozsahu ERP na základě faktů

Tento scénář je hypotetický. Nejedná se o klienta společnosti CE Interim a uvedené údaje slouží pouze pro ilustraci, nejedná se o referenční hodnoty. Rakouský dodavatel v automobilovém průmyslu zavádí šablonu skupinového ERP systému ve svém závodě v Polsku. Během jednoho řídicího cyklu dorazí několik požadavků, z nichž každý je označen jako malý.

Před schůzkou zaznamená ředitel programu ERP každou žádost do protokolu o rozhodnutí o změně. Integrátor předloží písemný odhad dopadu na náklady, testování a termíny. Provoz a centrální finanční oddělení poskytnou údaje o svých interních hodinách. Tento záznam poskytuje zadavateli strukturovaný způsob, jak posoudit, zvážit a rozhodnout o každé navrhované změně v systému ERP. Zabraňuje tomu, aby byly jakékoli úpravy rozsahu přijaty bez jasného přehledu o nákladech, testování a milnících dodání.

Příklad přijetí: Automatizované zaúčtování vráceného zboží přímo na výrobní lince

Závod požaduje, aby operátoři přestali ručně zadávat údaje o vráceném šrotu, a tento požadavek odpovídá základním požadavkům.

Žádost: Automatizované rezervace vrácení zboží přímo u výrobní linky.
Výhoda: Odstraňuje nutnost ručního zadávání vráceného odpadu; šetří 1,5 administrativní hodiny na směnu.
Náklady: poplatek externímu dodavateli ve výši 18 500 EUR; 45 hodin času interních klíčových uživatelů na konfiguraci.
Testování a harmonogram: Vyžaduje 4 dny regresního testování v rámci pracovní skupiny Assembly; žádné zpoždění na kritické cestě.
Rozsah přesahu: Není vyžadován; mimořádné náklady jsou pokryty.
Rozhodnutí a výchozí stav: Schváleno (Přijmout nyní): Aktualizován výchozí rozpočet; testování dokončeno ve sprintu 4.

Vedoucí závodu potvrzuje tuto potřebu. Dopad je pod kontrolou: testování je zařazeno do pracovního toku s volnou kapacitou a kritická cesta zůstává zachována. Nejedná se o žádný spouštěcí faktor pro eskalaci, a proto programový ředitel schválí změnu v rámci delegovaného limitu. Záznam o tomto rozhodnutí je předán zadavateli. Ředitel aktualizuje základní plán a ve stejném řídicím cyklu podá zprávu o zbývající rezervě.

Příklad výměny rozsahu: Přizpůsobený dashboard s klíčovými ukazateli výkonnosti pro vedoucí pracovníky

Vedení skupiny požaduje zavedení přehledového panelu namísto statických výkazů v tabulkách, a tato potřeba je oprávněná.

Požadavek: Vlastní řídicí panel s klíčovými ukazateli výkonnosti (KPI) pro vedení.
Význam: Nahrazuje statické výkazy v tabulkách pro výkonný tým skupiny.
Náklady: 34 000 € na vývoj u dodavatele; 30 hodin kontroly centrálního finančního výkaznictví.
Testování a harmonogram: Vysoká složitost; během uživatelského akceptačního testování odvádí pozornost klíčových architektů pro tvorbu reportů.
Změna rozsahu: Odložit vypracování nekritických souhrnných zpráv o nákladových střediscích na druhý den.
Rozhodnutí a výchozí stav: Rozsah projektu upraven: Schváleno k prvnímu vydání; souhrnné zprávy odloženy na fázi 1.1.

Centrála má v tomto ohledu skutečnou potřebu: spolehlivý přehled o provozu. Náklady přesahují pouhý poplatek dodavateli, protože pro akceptační testování jsou zapotřebí ti samí architekti zodpovědní za vypracování zpráv. Odložení schválených souhrnných zpráv mění schválený návrh, což vyvolává eskalaci. Zadavatel zaznamená písemný souhlas autora zprávy s odložením a následně provede výměnu namísto přidání. Dashboard se připojí k původní verzi.

Příklad odkladu: Sledovatelnost palet pro konkrétního zákazníka

Jeden regionální distributor má nestandardní logistické požadavky a obchodní vztah je v tomto případě důležitý.

Požadavek: Sledovatelnost palet pro konkrétního zákazníka.
Hodnota: Splnění nestandardního logistického požadavku pro jednoho regionálního distributora.
Cena: poplatek prodejci ve výši 26 000 €; rozsáhlá logika vytvořená na míru v modulu pro správu skladu.
Testování a harmonogram: Zpoždění schválení integrace systému správy skladu o 12 pracovních dnů.
Rozsah, který nebyl zahrnut: Žádný nebyl identifikován žádajícím pracovním týmem.
Rozhodnutí a výchozí stav: Odloženo na fázi 1.1: Nasazeno 60 dní po spuštění; zpočátku se používal ruční protokol balení.

Zpoždění posouvá stanovený milník, což spouští eskalaci, a pracovní skupina, která o to požádala, nemá žádný prostor pro ústupky. Ředitel závodu potvrzuje, že distributor potřebuje funkční proces již od prvního dne. Ten zajišťuje ručně vedený protokol. Sponzor žádost odkládá, jmenuje vedoucího skladu jako správce protokolu a stanoví termín přezkumu.

Příklad odmítnutí: Automatizované fakturace dodavatelů formou vlastní fakturace

Finanční oddělení požaduje rychlejší párování faktur v rámci celé dodavatelské sítě a přínos tohoto opatření je zřejmý.

Žádost: Automatizované vystavování faktur dodavateli formou vlastní fakturace.
Hodnota: Urychluje přiřazování faktur k závazkům v rámci celé evropské dodavatelské sítě.
Náklady: 52 000 € na vývoj na straně dodavatele; rozsáhlá rekonfigurace rozhraní EDI.
Testování a harmonogram: Mění základní pravidla pro zaúčtování finančních transakcí; ohrožuje termín přechodu na hlavní finanční systém.
Posunutý rozsah: Žádné; zadávající tým není ochoten změnit rozsah projektu.
Rozhodnutí a výchozí stav: Zamítnuto: Vysoké riziko spojené s harmonogramem; pro spuštění systému zůstává zachováno standardní přiřazování objednávek.

Rozhodnutí závisí na riziku spojeném s harmonogramem, nikoli na meritu věci. Žádost mění základní pravidla finančního zaúčtování, což vede ke změně schváleného návrhu a vyvolává eskalaci. Tým, který žádost podal, nebude měnit rozsah projektu. Zadavatel zachová standardní sladění pro uvedení do provozu a zaznamená důvod. Vlastní fakturace se rovněž dotýká pravidel fakturace, která se liší podle jednotlivých zemí. Odborníci s kvalifikací v Polsku ověří, co pravidla umožňují, než se návrh vrátí zpět.

Hlavní poznatky z příkladů změn rozsahu ERP

Stejný záznam vedl k odlišným odpovědím na žádosti, které se navzájem podobaly, a žádná z nich neznamenala plošné pozastavení. V tomto scénáři se jedná o vzorce, nikoli o pravidla. Schválená žádost měla omezený dopad a kritická cesta zůstala zachována. Výměna fungovala, protože omezujícím faktorem byla testovací kapacita a nekritická položka měla ochotného vlastníka. Odložení fungovalo, protože podnik mohl fungovat na základě konkrétního provizorního řešení. Zamítnutí následovalo po vysokém riziku pro harmonogram, přičemž nebylo možné ustoupit z rozsahu projektu.

Závod obdržel odůvodněnou odpověď na každou žádost, včetně těch, které nebyly schváleny. Schválená žádost čerpala z rezervy pro nepředvídané výdaje, takže další žádost bude čerpat z menší rezervy. Skupina si udržuje základní úroveň, kterou dokáže zdůvodnit.

Řešení mezer ve správě v rámci řízení změn rozsahu ERP

Kompetentní interní orgán může provádět kontrolu změn rozsahu ERP v rámci delegovaných limitů a s možností eskalace na zadavatele. Zadavatel, případně představenstvo v případě, že je tato funkce neobsazena, může tuto kontrolu porovnat s podmínkami uvedenými v záznamu o programu.

Žádný vedoucí pracovník na straně zákazníka nemá na starosti současně rozpočet, plán testování i plán převodu, a proto o každém z nich rozhodují samostatné pracovní skupiny.
Ředitel programu nemůže pozastavit neformální rozšíření rozsahu, protože mu nikdo tuto pravomoc písemně neudělil.
Pozice sponzora je neobsazená, nebo sponzor řídí podnik, a proto žádosti čekají déle, než trvá jeden řídící cyklus.
Údaje o dopadech poskytnuté integrátorem, provozovatelem závodu a finančním oddělením se stále liší a nikdo nemá pravomoc je sjednotit.

Pokud se vyskytnou dvě nebo více z těchto situací, program již nerozhoduje o žádostech na základě jediného záznamu. Skupině pak hrozí, že zaplatí dvakrát, nebo že se termín představenstva automaticky posune. Podle posouzení společnosti CE Interim představuje program v takovém případě riziko kritické pro podnik a vyžaduje vedoucího na straně zákazníka s výkonnými pravomocemi. Samotný termín není důvodem k jmenování dočasného vedoucího pracovníka.

Úloha prozatímního ředitele pro transformaci v rámci řízení ERP

. Prozatímní ředitel pro transformaci a programy může mít pravomoc k provádění změn na straně zákazníka. Tato role rozhoduje v rámci písemného pověření. Odpovídá tomu, kdo ji pověřil: sponzorovi nebo představenstvu, pokud je tato funkce neobsazena. Nejedná se ani o projektového manažera integrátora, ani o poradce, který pouze dává doporučení.

Mandát stanoví limity pro delegování pravomocí, které se určují, jakmile jsou údaje zaznamenány v jednom záznamu. Jako jediného odpovědného vlastníka plánu na straně zákazníka určuje prozatímního vedoucího pracovníka. Stanoví postup eskalace a sjednává předání záležitosti jmenovanému vlastníkovi. Vedoucí pracovník předloží rozhodovacímu orgánu potvrzení o potřebě ze strany závodu, potvrzení o souladu s místními právními předpisy a schválení uvolnění kapitálu ze strany ústředí.

Prozatímní partneři CE prověřují kvalitu záznamu o změně a podporují eskalaci. V dohodnutých intervalech poskytují osobě, která změnu schválila, přehled o postupu a dohlížejí na předání.

Vymezení prozatímního mandátu pro dohled nad výkonnou mocí

Je-li místo ředitele neobsazené nebo chybí písemné zmocnění, zastává tuto funkci po dobu trvání mandátu prozatímní výkonný ředitel. Totéž platí v případě, že je tato funkce součástí oddělení integrace nebo IT.

Pokud je k dispozici způsobilý ředitel, ale mezeru představuje pozice sponzora, mandát se vztahuje na úroveň nad ředitelem. Je-li pozice sponzora neobsazena, představenstvo před zahájením platnosti mandátu určí osobu, která má pravomoc přijímat vyhrazená rozhodnutí. Ta se týkají kapitálu nad stanovené limity, časového harmonogramu a data spuštění. A Interim CFO nebo Interim COO může je udržet v mezích stanovených představenstvem.

Pořadí je důležité. Nejprve vedoucí pracovník sjednotí údaje o dopadech od integrátora, závodu a finančního oddělení do jednoho záznamu. Do tohoto záznamu zahrne také neformální objem nevyřízených zakázek a má pravomoc pozastavit přidávání nových neformálních položek. Poté sponzor, nebo v případě neobsazeného místa představenstvo, na tomto základě stanoví limity pro delegování pravomocí. Teprve poté výkonný ředitel spustí řídicí cyklus s termínem předání dohodnutým na začátku.

Toto jmenování nemění smlouvu o realizaci, nezbavuje povinnosti dodržet kritéria přijetí ani neopravňuje ke spuštění projektu. Tyto pravomoci zůstávají v rukou zadavatele, případně v rukou představenstva, pokud je dané místo neobsazené. Jakákoli změna termínu, ke kterému se představenstvo zavázalo, musí být rovněž předložena představenstvu.

Zveřejněné pokyny k řízení rozsahu ERP

Princip řízení rozsahu podporují dva publikované zdroje. Pokyny společnosti Microsoft k řešení Dynamics 365 popisují návrhové tabule, které posoudit a schválit návrhy řešení. Uvádí se v něm, že týmy by měly dodržovat kritéria jednotlivých fází a neměly by je vynechávat "kvůli tlaku nebo optimismu".

Poskytovatel služeb ERP, společnost Atreus, uvádí, že překročení rozpočtu při zavádění ERP systému pro poprodejní služby že se situace stabilizovala. Došlo k přehodnocení rozsahu, rozpočtu a fází projektu a k vymezení rolí a odpovědností pro obchodní oddělení, IT a partnery. Žádný ze zdrojů tento záznam nepopisuje ani neoznačuje konkrétní změnu jako příčinu. Zpráva společnosti Atreus je zprávou poskytovatele, nikoli nezávislým auditem.

Často kladené otázky týkající se řízení změn v rozsahu ERP

Měly by být změny v rozsahu ERP projektu zmrazeny těsně před spuštěním?

Ne jako obecné pravidlo. Zmrazení může způsobit, že podnik nebude schopen fungovat. Změna, která splňuje zákonnou povinnost nebo chrání klíčový proces, má pádné důvody pro schválení. Odborníci v zemi, kde se závod nachází, by měli potvrdit, že se jedná o skutečný požadavek. Nepodstatná vylepšení mohou počkat na pozdější verzi.

Kdo schvaluje změny v rámci řízení změn v systému ERP?

Ředitel programu ERP schvaluje žádosti v rámci svěřených pravomocí a eviduje je. Žádost, která splňuje stanovené kritérium, se předává výkonnému sponzorovi, který rozhoduje o finančních prostředcích, časovém harmonogramu a datu spuštění. Sponzor rovněž řeší případné neshody mezi integrátorem a ředitelem programu ohledně dopadů.

Nahradí dočasný vedoucí pracovník ředitele programu ERP?

Ne automaticky. Tuto funkci zastává schopný ředitel s písemným zmocněním. Pokud ji zastává prozatímní vedoucí pracovník, mandát stanoví hierarchii podřízenosti a meze delegování pravomocí. Rovněž na začátku stanoví datum předání funkce. Rozhodnutí o smlouvě, přijetí a zahájení projektu zůstávají v kompetenci zadavatele, případně představenstva, pokud je tato funkce neobsazena.

Co se stane s dohodnutým termínem spuštění, když je schválena změna ERP systému?

Zadavatel písemně upraví výchozí parametry programu: hlavní harmonogram, termíny kontrolních milníků, plány integračních testů a rozpočet. Ředitel programu poté informuje všechna dotčená pracoviště a dodavatele. Pokud představenstvo schválilo původní termín, zadavatel nejprve předloží nový termín představenstvu.

Kontrola změn v rámci ERP chrání základní plán tím, že každá žádost přináší své náklady, testy a dopad na termín v rámci jednoho rozhodnutí. Žádost schválená bez zohlednění těchto dopadů může vést k uvedení do provozu dříve, než představenstvo odsouhlasí nový termín. Zadavatel, nebo v případě neobsazeného místa v představenstvu samotné představenstvo, nejprve ověří výše uvedené podmínky na základě záznamů o programu. Dalším krokem je vymezení mezí delegování pravomocí a posouzení, zda se daná nesrovnalost nachází na úrovni programu, nebo na úrovni zadavatele.

Další články na toto téma:

Společnost CE Interim zajišťuje přeshraniční vedení na úrovni vrcholového managementu při zásadních transformacích podniků. Jakmile je zadání hotové, je připraven nastoupit již prověřený manažer, který odpovídá požadavkům zakázky a je vázán smlouvou o mlčenlivosti.

Pokud platí dvě nebo více z výše uvedených podmínek, poraďte se s Prozatímní partner CE o mandátu.