Osoba odpowiedzialna za operacje zgłasza potrzebę zmiany obiegu zwalniania zamówień do realizacji. Proponowanym rozwiązaniem jest dedykowane rozszerzenie, ale wniosek o zatwierdzenie zmiany nie pokazuje, czy obecny ERP może spełnić wymaganie przez konfigurację, czy należy zmienić sam proces ani kto będzie utrzymywał rozszerzenie po wdrożeniu.
Zatwierdź wymaganie biznesowe, zanim zatwierdzisz sposób jego realizacji. Modyfikacja nie jest z definicji ani marnotrawstwem, ani strategiczną inwestycją. Zgódź się na nią, gdy udokumentowana potrzeba operacyjna uzasadnia stałe obowiązki dotyczące odpowiedzialności, interfejsów, testów i wsparcia. W przeciwnym razie przyjmij proces standardowy, skonfiguruj dostępne funkcje lub oceń zewnętrzną aplikację.
To decyzja dotycząca pojedynczego wniosku o zmianę. Jeśli analiza wykaże jednak, że platforma nie obsługuje podstawowych wymagań biznesowych, skorzystaj z szerszych ram decyzyjnych dotyczących usprawnienia lub wymiany ERP, zanim uznasz kolejne rozszerzenia za właściwą odpowiedź.
Ustal, czego nie zapewnia proces standardowy
Zacznij wniosek od oczekiwanego rezultatu, a nie od projektu ekranu. „Odtworzyć stary ekran zatwierdzania” narzuca rozwiązanie. „Zablokować zwolnienie zamówienia do czasu, aż osoba odpowiedzialna za operacje zaakceptuje wymaganie dotyczące obsługi danego klienta” opisuje mechanizm kontroli biznesowej, który można zrealizować na różne sposoby.
Podczas webinaru o suwerenności cyfrowej w ERP prelegenci z SoftEngine odrzucają bezwarunkową krytykę modyfikacji, argumentując, że złożone procesy mogą wymagać indywidualnego dostosowania. Kwestionują też automatyczne odtwarzanie istniejących sposobów pracy: najpierw należy ustalić, czy dany proces nadal jest potrzebny, a następnie sprawdzić, czy można go obsłużyć standardowymi funkcjami.
Dla osoby zatwierdzającej zmianę oznacza to konieczność uzyskania demonstracji proponowanego wariantu standardowego. Poproś konsultanta funkcjonalnego i właściciela procesu o przeprowadzenie rzeczywistego scenariusza biznesowego, łącznie z wyjątkami. Przekonująca odpowiedź wskazuje konkretny brakujący mechanizm kontroli lub rezultat. „Użytkownicy wolą stary sposób” nie jest równoważnym dowodem, choć wykazany problem z użytecznością, który uniemożliwia niezawodne wykonanie zadania, zasługuje na uwzględnienie.
Zapisz, dlaczego wymaganie jest ważne: ze względu na zobowiązanie umowne, ograniczenie operacyjne, niezbędny mechanizm kontroli lub istotną handlowo możliwość świadczenia usługi. Nie każda uzasadniona zmiana musi wyróżniać firmę na rynku. Jeśli proces standardowy zapewnia oczekiwany rezultat, zatwierdź dostosowanie procesu i przygotowanie użytkowników zamiast odtwarzania znanego sposobu pracy. Jeśli go nie zapewnia, opisz brak na tyle precyzyjnie, aby ułatwić kolejną decyzję projektową.
Porównaj sposoby realizacji tego samego wymagania
Dla każdego wariantu zastosuj ten sam scenariusz odbioru. W przeciwnym razie demonstracja konfiguracji może być oceniana na podstawie całego obiegu pracy, podczas gdy prototyp dedykowanego rozwiązania zostanie zaakceptowany po pokazaniu wyłącznie jego najbardziej atrakcyjnej funkcji. Traktuj poniższe warianty jako możliwości do zbadania, a nie uniwersalny ranking.
| Wariant | Kiedy go rozważyć | Jakich dowodów wymagać |
|---|---|---|
| Przyjęcie procesu standardowego | Oczekiwany rezultat można osiągnąć przez zmianę sposobu pracy. | Demonstracja realistycznego obiegu pracy i akceptacja różnic przez właściciela procesu. |
| Konfiguracja dostępnych funkcji | Istniejące ustawienia, reguły lub funkcje obiegu pracy wydają się spełniać wymaganie. | Projekt konfiguracji, opis jej ograniczeń oraz właściwe warunki wsparcia produktu. |
| Integracja zewnętrznej aplikacji | Warto ocenić odrębną aplikację pod kątem wymaganej funkcjonalności. | Dostęp do interfejsów, odpowiedzialność za transakcje, obsługa wyjątków i warunki dalszego korzystania. |
| Zatwierdzenie prac programistycznych | Pozostaje istotna luka, a proponowane rozszerzenie ma akceptowalny plan utrzymania w całym cyklu życia. | Projekt o jasno określonym zakresie, wspierany mechanizm rozszerzeń, osoba odpowiedzialna za utrzymanie i testy regresji. |
Wymagaj jednoznacznej terminologii w propozycji. Wyjaśnienie Oracle na blogu ERP-ACE opisuje konfigurację jako wykorzystanie standardowych funkcji do sterowania zachowaniem aplikacji i określa ją jako „zawsze bezpieczną przy aktualizacjach”. Traktuj to jako charakterystykę przedstawioną przez Oracle, a nie gwarancję umowną dla Twojej instalacji ani dowód, że integracja podlega takiej samej ochronie. Zapytaj, jakiego produktu, wydania, modelu wdrożenia i mechanizmu rzeczywiście dotyczy proponowana zmiana.
W dyskusji o transformacji przedsiębiorstw pojawia się dalej idący argument architektoniczny: należy unikać gromadzenia długu technicznego w obszarach, które nie wyróżniają firmy, i ostrożnie wybierać miejsca budowania przewagi. Dyskusja o podejściu clean core wykorzystuje SAP jako przykład i wskazuje na podejście oparte na aplikacjach zamiast dopisywania dedykowanego kodu. Przy zatwierdzaniu zmiany wykorzystaj tę opinię do zakwestionowania zbędnych prac programistycznych, a nie do założenia, że wszystkie produkty ERP mają identyczne zasady tworzenia rozszerzeń.
Zewnętrzna aplikacja powinna podlegać tak samo wnikliwej ocenie jak rozszerzenie wewnętrzne. Zapytaj, dlaczego jej funkcjonalność uzasadnia dodatkowy interfejs, obowiązki operacyjne i zależność handlową. Z drugiej strony nie odrzucaj rozszerzenia o jasno ograniczonym zakresie tylko dlatego, że istnieje inna aplikacja. Porównuj kompletne projekty pod kątem tego samego rezultatu.
Wypełnij arkusz zatwierdzania zmiany
Poniższy arkusz jest redakcyjnym narzędziem wspierającym decyzję, a nie zweryfikowanym źródłowo standardem architektonicznym. Dołącz go do wniosku o zmianę i przypisz osobę odpowiedzialną do każdej nierozstrzygniętej kwestii. Zatwierdzenie powinno opisywać zarówno sposób realizacji, jak i przyjmowane stałe obowiązki.
| Pytanie przed zatwierdzeniem | Dowody do załączenia | Powód do wstrzymania decyzji |
|---|---|---|
| Jakiego rezultatu nie można osiągnąć w procesie standardowym? | Wymaganie biznesowe, scenariusz niespełniony przez standard i konsekwencje pozostawienia luki. | Uzasadnienie opisuje wyłącznie preferowany ekran lub historyczny nawyk. |
| Dlaczego wybrano ten sposób realizacji? | Porównanie zmiany procesu, konfiguracji, integracji i prac programistycznych. | Alternatywy odrzucono bez sprawdzenia, czy spełniają wymaganie. |
| Kto odpowiada za rozszerzenie? | Właściciel biznesowy, osoba odpowiedzialna za utrzymanie techniczne, dostęp do repozytorium i uzgodnione prawa do użytkowania oraz modyfikacji. | Odpowiedzialność sprowadza się do wiedzy, do kogo zadzwonić. |
| Jakich interfejsów i danych potrzebuje rozwiązanie? | Wykaz interfejsów, uprawnienia do dostępu, uprawnienia użytkowników i systemów, granice transakcji oraz obowiązujące opłaty. | Stwierdzenie „istnieje API” zastępuje sprawdzenie wymaganych operacji. |
| Jak będą testowane aktualizacje? | Scenariusze regresji, środowisko testowe, odpowiedzialność za wydania i procedura przywracania prawidłowego działania. | Testowanie kończy się na instalacji lub dostarczeniu komunikatu. |
| Jakie stałe prace wymagają finansowania? | Zadania utrzymaniowe, odpowiedzialność za wsparcie, nakład pracy na testy i odpowiednie cykliczne opłaty. | Wycena obejmuje wyłącznie wytworzenie rozwiązania. |
| Co się stanie, jeśli zmieni się dostawca lub plan rozwoju produktu? | Materiały przekazania, alternatywne możliwości wsparcia, postanowienia dotyczące zakończenia współpracy i sposób wycofania lub zastąpienia rozwiązania. | Plan zależy od niepotwierdzonej przyszłej funkcji lub niedostępnej wiedzy dostawcy. |
Oddziel odpowiedzialność biznesową od utrzymania technicznego. Właściciel procesu powinien zaakceptować działanie zmiany i decydować, czy nadal jest ona potrzebna. Osoba odpowiedzialna za stronę techniczną powinna odpowiadać za implementację, zależności i wsparcie. Dział zakupów lub prawnicy powinni potwierdzić odpowiednie prawa, zamiast wywodzić je z samego posiadania repozytorium kodu.
Jeśli odpowiedzialność przypisano partnerowi wdrożeniowemu, sprawdź, kto wykona pracę i jak będzie przebiegało przekazywanie zadań. Kwestia zdolności zespołu do realizacji należy do oceny partnera wdrożeniowego; wniosek o zmianę powinien odnotować uzgodnione obowiązki, zamiast powtarzać cały proces wyboru dostawcy.
Zatwierdzaj utrzymanie i kryteria odbioru, nie tylko wykonanie
Zanim zaakceptujesz oszacowanie kosztów cyklu życia rozszerzenia ERP, poproś o plan utrzymania opisany zadaniami i odpowiedzialnymi rolami. Uwzględnij analizę istotnych zmian produktu, aktualizację i wykonywanie testów, usuwanie błędów, wdrażanie oraz wsparcie operacyjne. Dodaj opłaty za hosting, interfejsy lub aplikacje tam, gdzie wymaga ich proponowany projekt. Poproś o założenia stojące za wyceną, zamiast stosować nieuzasadnioną procentową stawkę utrzymania.
Hipotetyczny scenariusz oceny: zewnętrzna aplikacja sprawdza warunek zwolnienia zamówienia do realizacji i przesyła zatwierdzenie do ERP. Poprawne przesłanie komunikatu nie wystarcza do odbioru. Poproś zespół o wykazanie, że właściwe zamówienie zmienia status, zatwierdzenie bez odpowiednich uprawnień zostaje odrzucone, a pracownicy operacyjni mogą ustalić, co się wydarzyło.
Następnie przetestuj błędy i przywracanie prawidłowego działania: zewnętrzna aplikacja zatwierdza operację, ale ERP odrzuca aktualizację; odpowiedź jest opóźniona; zatwierdzenie zostaje przesłane ponownie; albo firma anuluje zamówienie przed zakończeniem operacji. Wymagaj, aby projekt wskazywał, kto wykrywa każdy wyjątek, kto uzgadnia stan procesu biznesowego i kto zatwierdza działania naprawcze. Są to propozycje testów odbiorowych, a nie twierdzenia o zachowaniu konkretnego produktu.
W przypadku aktualizacji zapytaj, które testy trzeba powtórzyć i kto decyduje, że zmiana nadal nadaje się do użytkowania. „Zgodne z aktualizacjami” to słaba odpowiedź bez właściwej polityki produktu i planu testów danego obiegu pracy. Ogranicz zakres zatwierdzenia lub odrocz decyzję, jeśli zespół nie potrafi ustalić wspieranego mechanizmu, obowiązków związanych z aktualizacjami lub odpowiedzialności za usuwanie problemów.
Sprawdź zależności przed zatwierdzeniem zmiany
W dyskusji o transformacji, prowadzonej na przykładzie SAP, jeden z uczestników zachęca klientów do domagania się potrzebnych API, w tym dostępu umożliwiającego współpracę z innymi dostawcami. Wniosek przydatny przy ocenie pojedynczej zmiany jest konkretny: przed zatwierdzeniem integracji zweryfikuj dostęp do operacji i danych wymaganych przez projekt. Nie utożsamiaj ogólnej deklaracji dostępu do platformy z uprawnieniem do każdego potrzebnego interfejsu.
Przeprowadź analizę scenariuszy zakłóceń dla proponowanego rozszerzenia. Zapytaj, co się stanie, jeśli osoba odpowiedzialna za utrzymanie stanie się niedostępna, wymagany interfejs się zmieni, warunki handlowe przestaną być akceptowalne lub planowana funkcja zostanie wycofana z planu rozwoju. Wymagaj, aby zespół odróżnił to, co organizacja może samodzielnie eksploatować, modyfikować, zastąpić lub wycofać, od tego, co nadal zależy od innego podmiotu.
W przypadku dedykowanego rozszerzenia poproś o repozytorium możliwe do skontrolowania, instrukcje budowania i wdrażania, dokumentację zależności, materiały testowe oraz potwierdzenie odpowiednich praw. W przypadku zewnętrznej aplikacji sprawdź eksport danych, warunki korzystania z interfejsów, dokumentację konfiguracji i pomoc przy zakończeniu współpracy. To postanowienia, które należy negocjować i weryfikować, a nie prawa, które można przyjąć za pewnik.
Przed zatwierdzeniem kolejnej zmiany wypełnij arkusz z właścicielem procesu i osobą odpowiedzialną za utrzymanie techniczne, a następnie uzupełnij brakujące dowody, które mogłyby zmienić wybór sposobu realizacji. Zatwierdź wariant, którego wartość biznesowa uzasadnia jasno określone obowiązki, a nie po prostu ten, który miał najbardziej przekonującą demonstrację.
Jeśli potrzebujesz wsparcia funkcjonalnego lub technicznego przy ocenie tego wymagania, porozmawiaj ze specjalistami ERP Digiventi o rozważanej konfiguracji, integracji lub pracach programistycznych.
