W skrócie

Kontrola zmian w zakresie systemu ERP zapewnia zleceniodawcy całościowy obraz wartości, kosztów, testów oraz skutków wdrożenia przed zatwierdzeniem wniosku. Gdy zespół programowy potwierdzi wniosek jako zmianę, zleceniodawca ma cztery możliwości: zaakceptować, odroczyć, zamienić lub odrzucić. Dyrektor programu ERP przygotowuje rekomendację w jednym dokumencie. Sponsor ustala limity delegowanych uprawnień oraz decyduje o środkach finansowych, terminach i zrewidowanej linii bazowej wykraczającej poza te limity.

W jaki sposób drobne wnioski o zmiany w systemie ERP powodują rozszerzanie zakresu projektu

Po zatwierdzeniu projektu zaczynają napływać prośby. Wydają się nieistotne: nowe pole na ekranie, zmiana progu zatwierdzania, inny układ raportu. Każda z nich trafia do komitetu sterującego jako konieczność, opisywana jako wymagająca kilku dni pracy konsultanta i wiążąca się z niewielkim ryzykiem.

Program może wymknąć się spod kontroli nawet bez podjęcia jednej poważnej decyzji. Sponsorzy mają dobre powody, by wyrazić zgodę, ponieważ wnioskodawcy znają specyfikę ich działalności. Odmowa może wydawać się przeszkodą, gdy ostrzegają oni, że ucierpi na tym wydajność lub zamknięcie księgowe na koniec miesiąca. To uzasadniona reakcja. Trudność polega na tym, co sponsor jest w stanie dostrzec w momencie podejmowania decyzji.

Skutki zmian zakresu systemu ERP dla dalszych etapów operacyjnych i testowych

Zleceniodawca dostrzega na stronie funkcję oprogramowania. Za tym programem kryje się cały łańcuch konsekwencji. Weźmy pod uwagę hipotetyczne zgłoszenie. Dwudniowa zmiana konfiguracji logiki alokacji zapasów może spowodować dziesięć dni prac nad tworzeniem niestandardowych skryptów. Może unieważnić trzydzieści ukończonych scenariuszy testów integracyjnych typu end-to-end. Może również wymagać renegocjacji interfejsów z podmiotami zewnętrznymi i odciągnąć kluczowych użytkowników biznesowych od krytycznych prób przed wdrożeniem.

Liczby te odnoszą się do jednej hipotetycznej prośby, a nie do wskaźnika dotyczącego jakiejkolwiek innej zmiany. Gdy zakres, koszty, zależności testowe i harmonogram wdrożenia są przedstawione w oddzielnych raportach, żadna pojedyncza strona nie pokazuje pełnego obrazu sytuacji. Wówczas punkt odniesienia ulega zmianie, mimo że nikt nie podjął decyzji o jego zmianie.

Wyzwania transgraniczne związane z zarządzaniem wnioskami o zmiany w systemie ERP

Siedziba główna w Paryżu, Zurychu, Monachium lub Wiedniu budzi uzasadnione obawy. Konieczne są standardy grupowe, spójny wgląd w sytuację oraz przestrzeganie budżetu uzgodnionego z integratorem systemów. Należy również wyjaśnić zarządowi wszelkie odchylenia od planu.

Zakład stosuje inny zestaw procedur. Zakład pierwszego rzędu w Polsce, Czechach, na Węgrzech lub w Rumunii może zaopatrywać niemieckie linie montażowe w branży motoryzacyjnej lub klientów z sektora lotniczego. Klienci ci ustalają sekwencyjne terminy dostaw, audyty identyfikowalności oraz standardy pakowania. W globalnym szablonie może brakować logiki kodów kreskowych lub manifestów recyklingu pojemników, których wymaga klient. Zakład potrzebuje wówczas szybkiej odpowiedzi, ponieważ termin przejścia na nowy system jest powiązany z terminami dostaw dla klientów i harmonogramami produkcji. Błąd może oznaczać konieczność oczekiwania na następny możliwy termin, a nie tylko kilka dni roboczych.

Oba stanowiska są uzasadnione. Do tarć dochodzi, gdy proces między nimi przebiega zbyt wolno. Zespoły zakładowe szukają wówczas rozwiązań alternatywnych, takich jak nieformalne zwrócenie się do lokalnego konsultanta. Są to sygnały, a nie akt nieposłuszeństwa.

W przypadku wniosku transgranicznego konieczne są trzy potwierdzenia z trzech różnych miejsc. Podmioty te działają w ramach różnych jednostek organizacyjnych i systemów prawnych, a żaden z nich nie może samodzielnie potwierdzić całego wniosku. Sekcja „Uprawnienia” pokazuje, kto co potwierdza.

Integrator reaguje na otrzymywane wnioski, a decyzja dotycząca zakresu należy do klienta. Wymaga to wyznaczenia osoby odpowiedzialnej po stronie klienta, posiadającej wyraźne uprawnienia do wprowadzania zmian. W przeciwnym razie grupa może ponieść podwójne koszty: najpierw za nieprzewidziane w budżecie dostosowania, a następnie za błędy integracyjne po uruchomieniu systemu. To, czy lokalna potrzeba uzasadnia odstępstwo od globalnego szablonu, jest odrębną decyzją, podejmowaną przed tą decyzją.

Kluczowe wskaźniki rozszerzania się zakresu projektu ERP

Sponsorzy i komisje audytowe nie muszą przeglądać dzienników konfiguracji, aby zauważyć, że zakres projektu ulega rozmyciu. Praktyczne oznaki wskazują, że program stracił kontrolę nad zmianami.

• Niesynchronizowane linie bazowe: Integrator, biuro programowe i zakład dysponują różnymi harmonogramami ramowymi.
• Pozycje zaległe bez dokumentacji: Kierownicy poszczególnych obszarów prac prowadzą nieformalne wykazy usprawnień projektowych, które nie trafiają do komitetu sterującego.
• Powtarzane testy regresji: Testowanie zostaje wznowione, ponieważ po zamrożeniu oprogramowania wprowadzono nowe ulepszenia.
• Erozja spowodowana czynnikami nieprzewidzianymi: Zmiany w zamówieniach od dostawców pochłaniają środki rezerwowe, podczas gdy kluczowe etapy pozostają niezrealizowane.

Już jeden sygnał może wynikać ze zwykłej przyczyny. Dwa takie sygnały razem stanowią podstawę do przeanalizowania, w jaki sposób zmiany są wprowadzane do programu.

Ramy decyzyjne dla sponsorów dotyczące wniosków o zmiany w systemie ERP

Zarządzanie wnioskami o zmiany w systemie ERP opiera się na ustalonej sytuacji wyjściowej. Ramy te zakładają, że w ramach programu dana pozycja została już uznana za zmianę, a nie za niezakończone, uzgodnione zadanie. Jeśli klient i partner wdrażający nadal nie są zgodni co do tego, o co chodzi, należy najpierw ustalić tę granicę. Sponsor lub dyrektor programu – w ramach przekazanych mu uprawnień – ma wówczas cztery możliwości. Każda z nich wymaga innych dowodów.

Opcja 1: Zatwierdzenie i sfinansowanie rozszerzeń zakresu systemu ERP

Sponsor zatwierdza dodanie tego elementu i finansuje je ze środków rezerwowych. Jeśli wymagają tego zależności, sponsor przedłuża również na piśmie okres testowania oraz termin wdrożenia. Wymagane dowody: pisemne zestawienie kosztów, liczba godzin pracy kluczowych użytkowników wewnętrznych, testy, których to dotyczy, oraz data, od której zmiany będą obowiązywać. Kompromis jest oczywisty. Środki rezerwowe wydane teraz nie będą mogły pokryć kolejnego wniosku.

Opcja 2: Przeniesienie wniosków dotyczących systemu ERP do aktualizacji wprowadzanych po uruchomieniu systemu

Sponsor akceptuje tę wartość i przenosi wniosek do wydania po uruchomieniu systemu. W poniższym przykładzie nazywa się to fazą 1.1 lub dniem drugim. Przejście na nowy system odbywa się zgodnie z ustaloną linią bazową. Wymagane dowody: nazwane tymczasowe obejście oraz potwierdzenie, że firma może funkcjonować bez tej zmiany w dniu uruchomienia. Kompromisem jest okres, w którym wnioskodawca radzi sobie z luką.

Opcja 3: Zmiana zakresu wdrożenia systemu ERP w celu zapewnienia dotrzymania terminów uruchomienia

Sponsor zgadza się na tę zmianę pod jednym warunkiem: z pierwotnej wersji zostanie usunięty istniejący element o równoważnym znaczeniu, który nie ma charakteru krytycznego. Pozwala to zachować możliwości testowe i dotrzymać terminu premiery. Wymagane dowody: potwierdzenie, że usunięty element rzeczywiście nie ma charakteru krytycznego, oraz zgoda jego właściciela na jego odłożenie. Kompromis polega na tym, że jedno zgłoszenie musi poczekać, aby inne mogło zostać zrealizowane.

Opcja 4: Odrzucanie wniosków o wprowadzenie zmian w systemie ERP, które nie mają charakteru niezbędnego

Sponsor odrzuca wniosek, ponieważ jego wartość nie uzasadnia kosztów, zakłóceń w testach ani ryzyka operacyjnego. Odmowa jest oceną dotyczącą terminu i konsekwencji, a nie wartości samego pomysłu. Wymagane uzasadnienie: należy odnotować powód odmowy, aby wnioskodawca mógł powrócić do tematu po uruchomieniu projektu z bardziej przekonującymi argumentami. Kompromis ten wiąże się z pewną luką i może spowodować utratę zaufania do programu.

Organ zatwierdzający w ramach kontroli zmian w systemie ERP

Dyrektor programu ERP dysponuje przekazanymi uprawnieniami w zakresie kontroli zmian. Osoba ta ocenia wykonalność techniczną, zależności między poszczególnymi obszarami pracy oraz dostępność zasobów, a następnie przedstawia zalecenia. Dyrektor musi również posiadać uprawnienia do wstrzymywania nieformalnych rozszerzeń zakresu projektu oraz do przedstawiania sponsorowi jasnych decyzji biznesowych.

Powyżej przyznanych limitów to sponsor podejmuje decyzje dotyczące alokacji środków finansowych i harmonogramu. Obejmują one kapitał, harmonogram oraz datę uruchomienia. Może to być dyrektor finansowy grupy, dyrektor operacyjny grupy lub inna osoba z kierownictwa odpowiedzialna za ten obszar.

Wyznaczniki eskalacji do sponsora w przypadku zmian budżetu i harmonogramu systemu ERP

Kontrola zmian budżetowych w systemie ERP działa skutecznie, gdy zleceniodawca ustala limity uprawnień na wczesnym etapie. Należy to zrobić przed złożeniem pierwszego wniosku, a nie w trakcie sporu dotyczącego późniejszego wniosku. Zleceniodawca ustala limit dla każdego wniosku oraz łączny limit na nieprzewidziane wydatki. Wniosek podzielony w celu nieprzekroczenia limitu liczy się jako jeden wniosek. Takie sytuacje powodują, że wniosek trafia bezpośrednio do zleceniodawcy.

• Wniosek ten powoduje przesunięcie terminu uruchomienia lub innego ustalonego etapu realizacji.
• Wniosek ten, wraz z dotychczas zatwierdzonymi wnioskami, powoduje przekroczenie limitu rezerwy na nieprzewidziane wydatki ustalonego przez wnioskodawcę.
• Zgłoszenie dotyczy zmiany kryterium etapu kontrolnego lub zatwierdzonego projektu.
• Integrator i dyrektor programu nie są zgodni co do skutków.

Wszelkie kwoty poniżej progów pozostają w gestii dyrektora programu, który je rejestruje i w każdym cyklu sterowania przedstawia stan rezerwy awaryjnej.

Role związane z zatwierdzaniem transgranicznym w zakładach i centrali grupy

Kierownik zakładu lub dyrektor zarządzający potwierdza, że wniosek jest niezbędny z operacyjnego punktu widzenia. Specjaliści posiadający odpowiednie kwalifikacje w kraju, w którym znajduje się zakład, potwierdzają zgodność z wymogami prawnymi. Centrala potwierdza zgodność z standardami grupy i przyznaje środki finansowe.

Jasno określone ramy są korzystne dla obu stron. Zakład otrzymuje decyzję lub opatrzony datą wniosek o przedstawienie dowodów podczas pierwszego posiedzenia komitetu sterującego, na którym rozpatrywany jest dany wniosek. W przypadku wniosków zgłoszonych na żądanie klienta lub wymaganych przepisami prawa zleceniodawca może ustalić procedurę pozacyklową i określić jej częstotliwość. Centrala ma wgląd w każdą decyzję w ramach jednego rejestru.

Pola obowiązkowe w rekordzie decyzji o zmianie systemu ERP

Rejestr decyzji o zmianach zapewnia zleceniodawcy jedną stronę na każdy wniosek. Stanowi on narzędzie robocze służące do kontroli zmian w zakresie systemu ERP. CE Interim proponuje go jako praktyczną pomoc, a nie jako uznaną normę. Zawiera sześć pól.

• Opis zgłoszenia zmiany: czego domaga się zgłaszający i dlaczego właśnie teraz.
• Wartość biznesowa i uzasadnienie operacyjne: proces, który chroni.
• Koszt dostawcy i wpływ na zasoby wewnętrzne: opłata zewnętrzna, godziny pracy pracowników oraz saldo rezerwy na nieprzewidziane wydatki przed i po.
• Analiza zależności testów i wpływu harmonogramu: testy oraz terminy, na które ma to wpływ.
• Zmieniony lub zamieniony zakres: co ewentualnie opuszcza obszar zwolnienia.
• Zatwierdzona decyzja i zaktualizowany punkt odniesienia: osoba zatwierdzająca, wybrana opcja oraz zaktualizowany plan.

Kierownik programu dokumentuje wyniki przed podjęciem decyzji przez sponsora. Następnie dyrektor aktualizuje powiązany plan i informuje o tym zainteresowane placówki oraz integratora. Zatwierdzenie uruchomienia, umowa oraz kryteria akceptacji to odrębne decyzje, dla których wymagane są własne dowody. Decyzje te pozostają w gestii sponsora lub zarządu, jeśli stanowisko jest nieobsadzone. Wszelkie zmiany terminu ustalonego przez zarząd również podlegają zatwierdzeniu przez zarząd.

Lista kontrolna dotycząca weryfikacji sponsora przed zatwierdzeniem zmian zakresu systemu ERP

Wiarygodność dokumentu zależy wyłącznie od zawartych w nim danych liczbowych. Doświadczony sponsor podchodzi z nieufnością do wniosku zawierającego jedynie jedną wycenę, ponieważ każda ze stron wycenia wyłącznie swoją część projektu.

Po pierwsze, ustal, czego brakuje w poszczególnych szacunkach: ponownych testów, godzin pracy kluczowych użytkowników, osób odpowiedzialnych za interfejsy oraz czasu na próbę przełączenia. Następnie należy zebrać dane liczbowe dostawcy usług integracyjnych, zakładu oraz centralnego działu finansowego w jednym zestawieniu, tak aby żadna ze stron nie oceniała własnego wkładu. Dopiero wtedy należy zadać kluczowe pytanie: czy firma będzie w stanie funkcjonować w dniu uruchomienia bez tej zmiany?

Ręczny etap w procesie o niewielkim znaczeniu może pozostać niedoskonały. Podobnie jak raport, który czeka na pierwsze wydanie. Nie powinno tak być jednak w przypadku luk w fakturowaniu, kontroli zapasów, wysyłkach do klientów czy zgodności z przepisami. Pozostaje jeszcze kwestia rezerwy na nieprzewidziane wydatki. Każde zatwierdzenie wiąże się z wydatkami, które mogą uniemożliwić pokrycie kolejnego wniosku, dlatego sponsor powinien znać stan środków, zanim wyrazi zgodę.

Przykłady z praktyki: Ocena zmian zakresu systemu ERP w oparciu o fakty

Ten scenariusz ma charakter hipotetyczny. Nie dotyczy on klienta CE Interim, a podane liczby mają charakter poglądowy, a nie porównawczy. Austriacki dostawca części samochodowych wdraża szablon systemu ERP swojej grupy w zakładzie w Polsce. W ciągu jednego cyklu sterowania napływa kilka zgłoszeń, z których każde jest określane jako niewielkie.

Przed spotkaniem dyrektor programu ERP rejestruje każde zgłoszenie w protokole decyzji o zmianie. Integrator przedstawia pisemną ocenę wpływu na koszty, testy i terminy. Zakład i centralny dział finansowy podają liczbę godzin pracy swoich pracowników. Rejestr ten zapewnia zleceniodawcy uporządkowany sposób przeglądu, wyważenia i podjęcia decyzji w sprawie każdej proponowanej zmiany w systemie ERP. Zapobiega to wprowadzaniu jakichkolwiek modyfikacji zakresu bez wyraźnej widoczności kosztów, testów i kamieni milowych realizacji.

Przykład akceptacji: Zautomatyzowana rezerwacja zwrotu przy linii produkcyjnej

Zakład chce, aby operatorzy zaprzestali ręcznego wprowadzania danych dotyczących zwrotów złomu, a prośba ta jest zgodna z wytycznymi.

• Prośba: Automatyczna rezerwacja zwrotów przy linii produkcyjnej.
• Korzyść: Eliminuje konieczność ręcznego wprowadzania danych dotyczących zwrotów złomu; pozwala zaoszczędzić 1,5 godziny pracy administracyjnej na zmianę.
• Koszt: 18 500 euro – opłata dla zewnętrznego dostawcy; 45 godzin pracy wewnętrznych użytkowników kluczowych poświęconych na konfigurację.
• Testy i harmonogram: Wymagane są 4 dni testów regresyjnych w ramach ścieżki roboczej „Assembly”; brak opóźnień na ścieżce krytycznej.
• Zakres zmian: Nie jest wymagany; sytuacja awaryjna została opanowana.
• Decyzja i stan wyjściowy: Zatwierdzono (Zaakceptuj teraz): Zaktualizowano budżet wyjściowy; testy zakończono w sprincie 4.

Kierownik zakładu potwierdza tę potrzebę. Skutki są ograniczone: testy są realizowane w ramach ścieżki roboczej dysponującej wolnymi mocami produkcyjnymi, a ścieżka krytyczna pozostaje niezmieniona. Nie ma podstaw do eskalacji, więc dyrektor programu zatwierdza zmianę w ramach przyznanych uprawnień. Decyzja ta jest odnotowywana w dokumentacji przeznaczonej dla zleceniodawcy. Dyrektor aktualizuje plan bazowy i zgłasza pozostały rezerwowy czas w ramach tego samego cyklu sterowania.

Przykład wykorzystania Scope Exchange: Niestandardowy pulpit menedżerski z wskaźnikami KPI

Kierownictwo grupy chce, aby statyczne raporty w arkuszach kalkulacyjnych zastąpił pulpit analityczny, a ta potrzeba jest uzasadniona.

• Zlecenie: Indywidualny pulpit menedżerski z wskaźnikami KPI.
• Korzyść: Zastępuje statyczne raporty w arkuszach kalkulacyjnych przygotowywane dla zespołu kierowniczego grupy.
• Koszt: 34 000 euro na prace związane z rozwojem dostawcy; 30 godzin przeglądu centralnej sprawozdawczości finansowej.
• Testy i harmonogram: Wysoki stopień złożoności; angażuje głównych architektów ds. raportowania podczas testów akceptacyjnych użytkownika.
• Zmieniony zakres: Przesunąć sporządzanie niekrytycznych raportów podsumowujących dotyczące ośrodków kosztów na drugi dzień.
• Decyzja i stan wyjściowy: Zakres uzgodniony: Zatwierdzono do pierwszego wydania; sporządzenie raportów podsumowujących odroczono do fazy 1.1.

Centrala ma w tej kwestii rzeczywistą potrzebę: niezawodny wgląd w działanie zakładu. Koszt wykracza poza opłatę dla dostawcy, ponieważ testy akceptacyjne wymagają udziału tych samych architektów odpowiedzialnych za raportowanie. Odroczenie zatwierdzonych raportów podsumowujących powoduje zmianę zatwierdzonego projektu, co wywołuje eskalację. Sponsor rejestruje pisemną zgodę właściciela raportu na odroczenie, a następnie dokonuje zamiany zamiast dodawania. Pulpit nawigacyjny zostaje dołączony do pierwotnej wersji.

Przykład odroczenia: identyfikowalność palet dla konkretnego klienta

Jeden z regionalnych dystrybutorów ma niestandardowe wymagania logistyczne, a relacje handlowe mają tu duże znaczenie.

• Wniosek: Identyfikowalność palet dla poszczególnych klientów.
• Wartość: Realizacja niestandardowego zlecenia logistycznego dla jednego dystrybutora regionalnego.
• Koszt: opłata na rzecz dostawcy w wysokości 26 000 euro; rozbudowana, dostosowana do indywidualnych potrzeb logika w module zarządzania magazynem.
• Testy i harmonogram: Opóźnia zatwierdzenie integracji systemu zarządzania magazynem o 12 dni roboczych.
• Zakres wyłączony: Żadnego nie zidentyfikowano w ramach zgłoszonego obszaru prac.
• Decyzja i stan początkowy: Przekazano do fazy 1.1: Wdrożono 60 dni po uruchomieniu; początkowo stosowano ręczny dziennik pakowania.

Opóźnienie powoduje przesunięcie ustalonego terminu realizacji, co uruchamia procedurę eskalacji, a zespół odpowiedzialny za realizację zadania nie ma możliwości rezygnacji. Kierownik zakładu potwierdza, że dystrybutor potrzebuje działającego procesu od pierwszego dnia. Rozwiązaniem jest rejestr prowadzony ręcznie. Sponsor odkłada rozpatrzenie wniosku, wyznacza kierownika magazynu jako osobę odpowiedzialną za prowadzenie rejestru i wyznacza termin przeglądu.

Przykład odrzucenia: automatyczne fakturowanie przez dostawców na zasadzie samofakturowania

Dział finansowy oczekuje szybszego dopasowywania faktur w całej sieci dostawców, a korzyści z tego wynikające wydają się realne.

• Prośba: Zautomatyzowane fakturowanie oparte na samodzielnym wystawianiu faktur przez dostawców.
• Wartość: Przyspiesza proces dopasowywania faktur w ramach zobowiązań wobec dostawców w całej europejskiej sieci dostawczej.
• Koszt: prace rozwojowe zlecone dostawcy o wartości 52 000 euro; znaczna rekonfiguracja interfejsu EDI.
• Testy i harmonogram: Zmienia podstawowe zasady księgowania operacji finansowych; zagraża terminowi przejścia na nowy system finansowy.
• Zmieniony zakres: Brak; zespół składający wniosek nie wyraża zgody na zmianę zakresu.
• Decyzja i punkt odniesienia: Odrzucono: wysokie ryzyko związane z harmonogramem; w momencie uruchomienia systemu zachowano standardowe dopasowywanie zamówień zakupu.

Decyzja opiera się na ryzyku związanym z harmonogramem, a nie na merytorycznych przesłankach. Wniosek zmienia podstawowe zasady księgowania finansowego, co powoduje modyfikację zatwierdzonego projektu i wymaga eskalacji. Zespół składający wniosek nie zmieni zakresu projektu. Zleceniodawca utrzymuje standardowe dopasowanie terminów uruchomienia i odnotowuje powód. Samodzielne wystawianie faktur wiąże się również z zasadami fakturowania, które różnią się w zależności od kraju. Specjaliści posiadający uprawnienia w Polsce potwierdzają, na co pozwalają przepisy, zanim pomysł zostanie ponownie rozpatrzony.

Najważniejsze wnioski z przykładów zmian zakresu systemu ERP

Ten sam zapis generował różne odpowiedzi na podobnie sformułowane wnioski, a żadna z nich nie polegała na całkowitym wstrzymaniu prac. Są to wzorce występujące w tym scenariuszu, a nie sztywne zasady. Przyjęty wniosek miał ograniczony wpływ, a ścieżka krytyczna pozostała nienaruszona. Wymiana zadziałała, ponieważ ograniczeniem była zdolność testowa, a element niekrytyczny miał chętnego właściciela. Odroczenie zadziałało, ponieważ firma mogła funkcjonować dzięki określonym rozwiązaniom zastępczym. Odmowa wynikała z wysokiego ryzyka związanego z harmonogramem, przy braku możliwości rezygnacji z jakiejkolwiek części zakresu.

Zakład otrzymał uzasadnioną odpowiedź na każdy wniosek, w tym również na te, które nie zostały rozpatrzone pozytywnie. Przyjęty wniosek wykorzystał rezerwę na nieprzewidziane wydatki, więc kolejny wniosek będzie mógł skorzystać z mniejszej rezerwy. Grupa utrzymuje poziom odniesienia, który jest w stanie uzasadnić.

Wypełnianie luk w zarządzaniu w zakresie kontroli zmian w systemie ERP

Kompetentny organ wewnętrzny może sprawować kontrolę nad zmianami zakresu systemu ERP, dysponując przydzielonymi limitami oraz możliwością eskalacji do sponsora. Sponsor – lub zarząd, jeśli stanowisko to jest nieobsadzone – może zweryfikować zgodność z warunkami określonymi w dokumentacji programu.

• Żaden z kierowników po stronie klienta nie odpowiada jednocześnie za budżet, plan testów i plan wdrożenia, więc o każdej z tych kwestii decydują odrębne gremia.
• Dyrektor programu nie może wstrzymać nieformalnych rozszerzeń zakresu, ponieważ nikt nie przyznał mu tego uprawnienia na piśmie.
• Stanowisko sponsora jest nieobsadzone lub sponsor sam kieruje działalnością, przez co wnioski czekają dłużej niż trwa jeden cykl posiedzeń komitetu sterującego.
• Dane dotyczące wpływu przedstawione przez integratora, zakład i dział finansowy nadal się różnią, a nikt nie ma uprawnień, by je uzgodnić.

Jeżeli spełnione są co najmniej dwa z tych warunków, program nie rozpatruje już wniosków dotyczących jednego rekordu. W takiej sytuacji grupa naraża się na ryzyko podwójnej płatności lub domyślnej zmiany terminu wyznaczonego przez Zarząd. W ocenie CE Interim program ten wiąże się wówczas z ryzykiem krytycznym dla przedsiębiorstwa i wymaga lidera po stronie klienta, dysponującego uprawnieniami wykonawczymi. Sam termin nie stanowi wystarczającego powodu do powołania tymczasowego dyrektora wykonawczego.

Rola tymczasowego dyrektora ds. transformacji w zarządzaniu systemem ERP

An Tymczasowy dyrektor ds. transformacji i programów może posiadać uprawnienia do wprowadzania zmian po stronie klienta. Osoba pełniąca tę rolę podejmuje decyzje w ramach pisemnego upoważnienia. Odpowiada przed podmiotem, który jej to upoważnienie przyznał: sponsorem lub zarządem, jeśli stanowisko to jest nieobsadzone. Nie jest to ani kierownik projektu z ramienia integratora, ani doradca, który jedynie przedstawia zalecenia.

Mandat określa limity delegowania uprawnień, ustalane po zebraniu danych w jednym dokumencie. Wyznacza on tymczasowego dyrektora wykonawczego jako jedynego odpowiedzialnego właściciela planu po stronie klienta. Określa on ścieżkę eskalacji i uzgadnia przekazanie sprawy wyznaczonemu właścicielowi. Dyrektor wykonawczy przedkłada decydentowi potwierdzenie zapotrzebowania ze strony zakładu, lokalne potwierdzenie zgodności z przepisami oraz zgodę centrali na uwolnienie środków kapitałowych.

Partnerzy tymczasowi CE sprawdzają jakość dokumentacji zmian i wspierają proces eskalacji. Zapewniają osobie, która przekazała uprawnienia, wgląd w postępy prac z ustaloną częstotliwością oraz nadzorują przekazanie zadań.

Określenie zakresu tymczasowego mandatu w zakresie nadzoru wykonawczego

Jeżeli stanowisko dyrektora jest nieobsadzone lub brakuje pisemnego upoważnienia, funkcję tę pełni na czas trwania kadencji dyrektor tymczasowy. To samo dotyczy sytuacji, gdy stanowisko to znajduje się w ramach działu integracji lub działu IT.

W przypadku gdy dyrektor jest kompetentny, ale luka występuje na poziomie sponsora, uprawnienia te przysługują osobie stojącej nad dyrektorem. Jeśli stanowisko sponsora jest nieobsadzone, Rada Nadzorcza wyznacza osobę uprawnioną do podejmowania zastrzeżonych decyzji przed rozpoczęciem obowiązywania uprawnień. Decyzje te dotyczą kapitału przekraczającego ustalone limity, harmonogramu oraz daty uruchomienia projektu. A Interim CFO lub Interim COO może utrzymywać je w granicach określonych przez Zarząd.

Kolejność ma znaczenie. Najpierw kierownictwo konsoliduje dane dotyczące wpływu integratora, zakładu i działu finansowego w jednym rejestrze. Kierownictwo uwzględnia w nim również nieformalne zaległości, uzyskując uprawnienia do wstrzymania wprowadzania nowych nieformalnych pozycji. Następnie sponsor lub zarząd – w przypadku braku sponsora – ustala na tej podstawie limity delegowania zadań. Dopiero wtedy kierownictwo uruchamia cykl sterowania, zgodnie z terminem przekazania ustalonym na początku.

Mianowanie to nie zmienia treści umowy wdrożeniowej, nie znosi kryteriów akceptacji ani nie upoważnia do uruchomienia projektu. Uprawnienia te pozostają w gestii zleceniodawcy lub Rady, w przypadku gdy stanowisko jest nieobsadzone. Wszelkie zmiany terminu ustalonego przez Radę również podlegają zatwierdzeniu przez Radę.

Opublikowano wytyczne dotyczące zarządzania zakresem systemu ERP

Dwa opublikowane źródła potwierdzają zasadę ograniczania zakresu. W wytycznych firmy Microsoft dotyczących platformy Dynamics 365 opisano tablice projektowe, które przejrzeć i zatwierdzić projekty rozwiązań. Stwierdza się w nim, że zespoły powinny przestrzegać kryteriów etapowo-kontrolnych i nie pomijać ich "z powodu presji lub optymizmu".

Dostawca usług ERP, firma Atreus, informuje o przekroczenie budżetu przy wdrażaniu systemu ERP w dziale obsługi posprzedażowej że sytuacja się ustabilizowała. Przeprowadzono ponowne planowanie zakresu, budżetu i etapów wdrożenia oraz określono role i zakresy odpowiedzialności dla działów biznesowych, IT i partnerów. Żadne ze źródeł nie opisuje tego przypadku ani nie wskazuje konkretnej zmiany jako przyczyny. Raport Atreus jest raportem dostawcy, a nie niezależnym audytem.

Najczęściej zadawane pytania dotyczące kontroli zmian w zakresie systemu ERP

Czy należy wstrzymać wprowadzanie zmian w zakresie systemu ERP tuż przed uruchomieniem?

Nie jest to jednak reguła ogólna. Zamrożenie zmian może uniemożliwić funkcjonowanie przedsiębiorstwa. Zmiana, która spełnia wymóg prawny lub zabezpiecza kluczowy proces, ma silne uzasadnienie do zaakceptowania. Specjaliści z kraju, w którym znajduje się zakład, powinni potwierdzić, że wymóg ten rzeczywiście istnieje. Ulepszenia, które nie są niezbędne, mogą poczekać do kolejnej wersji.

Kto zatwierdza zmiany w ramach kontroli zmian w systemie ERP?

Dyrektor programu ERP zatwierdza wnioski w ramach przyznanych uprawnień i rejestruje je. Wniosek spełniający określone kryteria trafia do sponsora wykonawczego, który podejmuje decyzję w sprawie nakładów finansowych, harmonogramu oraz terminu uruchomienia. Sponsor rozstrzyga również wszelkie spory między integratorem a dyrektorem programu dotyczące skutków projektu.

Czy tymczasowy dyrektor wykonawczy zastępuje dyrektora programu ERP?

Nie z mocy prawa. Stanowisko to zachowuje kompetentny dyrektor posiadający pisemne upoważnienie. W przypadku gdy pełni je tymczasowy członek zarządu, mandat określa strukturę podległości służbowej oraz granice delegowanych uprawnień. Określa on również od początku termin przekazania obowiązków. Decyzje dotyczące umowy, zatwierdzenia i uruchomienia projektu pozostają w gestii sponsora lub, w przypadku wakatu na tym stanowisku, zarządu.

Co dzieje się z uzgodnioną datą uruchomienia po zatwierdzeniu zmiany systemu ERP?

Sponsor na piśmie aktualizuje podstawowe założenia programu: harmonogram ogólny, terminy etapów kontrolnych, plany testów integracyjnych oraz budżet. Następnie dyrektor programu informuje o tym wszystkie zainteresowane placówki i dostawców. Jeśli zarząd zatwierdził pierwotny termin, sponsor najpierw przedkłada nowy termin zarządowi.

Powiązana wiedza i kolejny krok

Kontrola zmian w zakresie systemu ERP chroni stan bazowy, gdy każdy wniosek wiąże się z określonymi kosztami, testami i wpływem na termin, co jest rozpatrywane w ramach jednej decyzji. Wniosek zatwierdzony bez uwzględnienia tych skutków może doprowadzić do uruchomienia systemu przed uzgodnieniem nowej daty przez Radę. Sponsor lub Rada, w przypadku gdy stanowisko jest nieobsadzone, najpierw weryfikuje powyższe warunki w oparciu o dokumentację programu. Kolejnym krokiem jest określenie granic delegowania uprawnień oraz ocena, czy rozbieżność występuje na poziomie programu, czy sponsora.

Warto przeczytać:

• Zamknięcie amerykańskiego zakładu z Niemiec: tymczasowy kierownik zakładu, który zrealizował to zadanie w ciągu sześciu miesięcy
• Jeden dostawca obsługuje kilka zakładów w Europie Środkowo-Wschodniej. W jaki sposób należy rozdzielić ograniczone zasoby materiałów?
• Dlaczego wyznaczenie docelowego poziomu kosztów produkcji nie oznacza przeprojektowania modelu operacyjnego

CE Interim zapewnia transgraniczne wsparcie kadry kierowniczej w zakresie kluczowych transformacji biznesowych. Po sporządzeniu briefu zlecenia do działania gotowy do rozpoczęcia pracy jest już sprawdzony menedżer, dopasowany do wymagań zlecenia i związany umową o zachowaniu poufności.

Jeśli spełnione są co najmniej dwa z powyższych warunków, należy skonsultować się z Tymczasowy partner CE na temat mandatu.