Rozważmy sytuację, w której dział finansów odtwarza raporty poza ERP, a pracownicy operacyjni ponownie wprowadzają transakcje w różnych systemach. Zarząd chce sfinansować wymianę systemu. Przed jej zatwierdzeniem dyrektorzy finansowy, operacyjny i IT muszą ustalić, czy przyczyną problemów są brakujące funkcje oprogramowania, źle zaprojektowane procesy, zawodna integracja czy niejasna odpowiedzialność.
Rozwój firmy i trudności operacyjne uzasadniają analizę, a nie automatyczną wymianę systemu. Finansuj usprawnienia, gdy można wykazać, że obecna platforma obsłuży wymagane procesy. Rozwijaj wariant wymiany, gdy istotnych ograniczeń nie da się usunąć na akceptowalnych warunkach. Zleć dalszą ocenę, jeśli przyczyna problemów, opłacalność lub zdolność organizacji do realizacji zmian pozostają niepewne.
Decyzja inwestycyjna powinna prowadzić do popartego dowodami wyboru między tymi ścieżkami, a nie do propozycji wdrożenia, w której wymianę założono z góry.
Udokumentuj problemy w procesach, zanim określisz wymagania wobec nowego systemu
Francesco Perrotta wskazuje nieefektywne lub złożone procesy biznesowe oraz trudności z integracją istniejących aplikacji jako sygnały skłaniające do rozważenia zmian w ERP. Potraktuj je jako początek diagnozy. Stwierdzenie „ERP nie wspiera rozwoju” trzeba zamienić w możliwy do zweryfikowania opis tego, co nie działa, w jakich warunkach i z jakimi konsekwencjami biznesowymi.
Poproś dział finansów o prześledzenie niedawnego problemu z zamknięciem okresu, uzgodnieniem sald lub raportowaniem. Poproś dział operacyjny o pokazanie opóźnionego zamówienia, rozbieżności magazynowej lub wyjątku w procesie zakupowym. Zapisz oczekiwany rezultat, rzeczywisty wynik, ręczne interwencje i wpływ na dalsze etapy. Oddziel zaobserwowane konsekwencje od założeń: opóźnione fakturowanie nie oznacza automatycznie utraconych przychodów, a uwolniony czas pracowników nie oznacza automatycznie oszczędności pieniężnych.
Dla każdego krytycznego procesu zbierz historię transakcji, informacje o istotnej konfiguracji, historię zgłoszeń wsparcia i wyjaśnienie właściciela biznesowego. Następnie sklasyfikuj podejrzewane ograniczenie:
- Możliwości oprogramowania: wymaganej reguły biznesowej lub transakcji nie da się odwzorować.
- Projekt procesu: odpowiedzialność, akceptacje lub przekazywanie zadań są niejasne albo niepotrzebnie skomplikowane.
- Integracja: informacje nie docierają, docierają w niewłaściwej postaci lub nie można niezawodnie przywrócić prawidłowego przepływu po błędzie.
- Gotowość organizacyjna: użytkownicy, właściciele danych lub decydenci nie są w stanie utrzymać zakładanego sposobu pracy.
To hipotezy robocze, a nie ostateczne etykiety. Jeśli finanse twierdzą, że raportu nie da się przygotować, poproś o wskazanie potrzebnych informacji i demonstrację obecnego sposobu raportowania. Jeśli operacje obwiniają integrację, prześledź problem między aplikacjami. Kolejna decyzja o finansowaniu powinna dotyczyć wykazanego ograniczenia, a nie tylko działu, który je zgłasza.
Sprawdź, czy obecny ERP może dostosować się do zmian
Perrotta podkreśla, że wartość zewnętrznej oceny polega na obiektywnej analizie procesów biznesowych i głębszym zrozumieniu kontekstu firmy. Zapisz tę zasadę w zakresie zlecenia: wymagaj rekomendacji dopuszczającej pozostawienie obecnego systemu, zamiast zamawiać analizę, której jedynym dozwolonym wynikiem jest wymiana.
Wybierz proces krytyczny dla firmy i poproś zespół o pokazanie, jak obecna instalacja mogłaby go obsłużyć dzięki zmianom procesu, konfiguracji, dostępnemu modułowi lub integracji o jasno określonym zakresie. Wymagaj dowodów odnoszących się do zainstalowanej wersji i odpowiednich warunków handlowych. Odpowiedź „produkt to obsługuje” nie wystarczy, jeśli zależy od niezatwierdzonej aktualizacji, niedostępnego interfejsu lub nieprzetestowanego rozszerzenia.
Hipotetyczny scenariusz oceny: aplikacja magazynowa wysyła potwierdzenia wysyłek, ale finanse nadal ręcznie poprawiają faktury. Pomyślne przesłanie komunikatu nie dowodzi, że proces działa prawidłowo. Poproś zespół o zademonstrowanie księgowania zdarzenia gospodarczego, uzgodnienia danych, obsługi wyjątków i odpowiedzialności za przywrócenie prawidłowego działania. Jeśli po poprawieniu interfejsu ERP może obsłużyć cały proces, przemawia to za analizą ukierunkowanego usprawnienia. Jeśli obowiązkowej reguły biznesowej nadal nie da się odwzorować, uzasadnienie wymiany staje się mocniejsze.
Sprawdź nie tylko obecne dopasowanie, ale też przyszłą elastyczność. Podczas webinaru o suwerenności cyfrowej z udziałem przedstawicieli dostawcy ERP prelegenci proponują sprawdzenie zależności w scenariuszach zmian regulacyjnych, przejęć i zmian strategii dostawcy. Problemem nie jest według nich sama zależność, lecz zależność odbierająca firmie zdolność do działania. Na potrzeby tej decyzji inwestycyjnej zapytaj, co się stanie, jeśli potrzebna funkcja zniknie z planu rozwoju produktu, zmienią się warunki dostępu lub firma będzie musiała spełnić nowy obowiązek.
Zapisz odpowiedź od strony umownej, technicznej i operacyjnej zarówno dla obecnego systemu, jak i proponowanego następcy. Nie zakładaj elastyczności nowej platformy, jeśli od istniejącej wymagasz jej udowodnienia. Gdy proponowane rozwiązanie obejmuje rozszerzenie, które ma pozostać na stałe, skorzystaj z osobnego arkusza zatwierdzania modyfikacji ERP, aby przeanalizować tę zależność, zamiast rozszerzać decyzję inwestycyjną o szczegółowe zatwierdzanie zmian.
Porównaj usprawnienie i wymianę na równych zasadach
Buduj scenariusze dla tych samych wymaganych rezultatów biznesowych i tego samego horyzontu planowania. Uwzględnij pozostawienie obecnej instalacji z ukierunkowanymi usprawnieniami, jej wymianę oraz, jeśli niepewność pozostaje istotna, ocenę o ograniczonym zakresie przed podjęciem któregokolwiek zobowiązania. Jeżeli ponowne wdrożenie obecnego produktu jest realnym wariantem, wyceń je osobno, zamiast ukrywać znaczną przebudowę pod nazwą „optymalizacja”.
Przy ustalaniu kosztów bazowych obecnego systemu kategorie kosztów wskazane przez ERP Research obejmują licencje, hosting, wsparcie, personel wewnętrzny, utrzymanie modyfikacji i koszty obejść. Wykorzystaj te kategorie, aby nie porównywać programu wymiany wyłącznie z obecną fakturą za licencje. Dodaj proponowane prace usprawniające i wskaż, które istniejące koszty rzeczywiście znikną, pozostaną lub wzrosną.
Dla wymiany wymagaj wyraźnych szacunków prac związanych z przejściem na nowy system, a nie tylko jego późniejszej eksploatacji. Poradnik podejmowania decyzji o ERP autorstwa Digital Advisory wymienia jako dane do uzasadnienia biznesowego zastępstwa za pracowników, próby migracji, tymczasowe integracje, podróże integratora i rezerwę na zmiany oraz wsparcie stabilizacyjne wykraczające poza okres wzmożonego wsparcia ujęty w ofercie. Potraktuj je jako pozycje do wyceny w swoim programie, a nie jako uniwersalne opłaty lub wartości porównawcze.
Dla każdej deklarowanej korzyści wskaż mechanizm jej uzyskania i osobę odpowiedzialną. Jeśli wymiana ma skrócić zamknięcie okresu, określ, który etap uzgadniania lub akceptacji się zmieni, jakie dowody potwierdzają tę możliwość i co finanse muszą robić inaczej. Nie licz tego samego uwolnionego czasu pracy jednocześnie jako redukcji zatrudnienia i zwiększenia wydajności, chyba że plan operacyjny wyjaśnia jego podział.
Sformułuj rekomendację warunkowo. Usprawnienie jest wiarygodne, gdy usuwa istotne problemy przy akceptowalnych dalszych zobowiązaniach. Wymiana jest wiarygodna, gdy wykazane ograniczenia funkcjonalne lub zależności przeważają nad ryzykiem przejścia na nowy system. Dalsza ocena jest właściwa wtedy, gdy konkretna nierozstrzygnięta kwestia może zmienić wybór. Określ jej wynik, właściciela i termin decyzji, zamiast zlecać analizę bez wyraźnych granic.
Użyj arkusza decyzyjnego zamiast syntetycznej punktacji
Poniższy arkusz jest redakcyjną pomocą decyzyjną, a nie zwalidowanym modelem punktowym. Wypełnij go dla każdego realnego scenariusza. Zachowaj widoczne rozbieżności, zamiast uśredniać krytyczne ograniczenie biznesowe do pozornie akceptowalnego wyniku łącznego.
| Obszar decyzji | Dowody do zapisania | Pytanie przed zatwierdzeniem |
|---|---|---|
| Wpływ operacyjny | Niedziałające procesy, dokumentacja transakcji, obecny nakład pracy i konsekwencje biznesowe | Które problemy rozwiąże ten wariant, a które pozostaną? |
| Możliwości i zależności | Demonstracje procesów, weryfikacja zainstalowanej wersji, interfejsy, warunki wsparcia i założenia dotyczące rozwoju produktu | Czy firma może działać i dostosowywać się w ramach proponowanych ograniczeń? |
| Porównywalność ekonomiczna | Obecne koszty eksploatacji, koszty zmian, nakład pracy przy przejściu, dalsze wsparcie i założenia dotyczące korzyści | Czy porównaliśmy równoważny zakres bez zakładania, że korzyści oznaczają oszczędności pieniężne? |
| Zdolność organizacji do realizacji prac | Wskazani właściciele procesów, wymagane zaangażowanie, konkurujące obowiązki i decyzje o zastępstwach | Czy firma może zapewnić ludzi i decyzje wymagane przez ten wariant? |
| Ryzyko okresu przejściowego | Operacje objęte zmianą, rozwiązania tymczasowe, odpowiedzialność za przywrócenie działania i nierozstrzygnięte kwestie ciągłości | Jakie ryzyko biznesowe akceptuje kierownictwo, finansując tę ścieżkę? |
| Brakujące dowody | Otwarte pytania, osoby odpowiedzialne i ustalenia, które zmieniłyby rekomendację | Zatwierdzić teraz, zatwierdzić analizę o ograniczonym zakresie czy odroczyć decyzję? |
Dołącz do arkusza dokumenty źródłowe, zamiast wypełniać go zapewnieniami. „Użytkownicy będą uczestniczyć” powinno oznaczać przypisane obowiązki i uzgodniony czas na ich wykonanie. „Integracja jest wykonalna” powinno wskazywać interfejs, rezultat biznesowy i nierozstrzygnięte warunki. „Niższe koszty operacyjne” powinny wynikać z uzgodnienia z bazą kosztową i jasno określonego przyszłego modelu działania.
Przypisz odpowiedzialność biznesową przed zatwierdzeniem realizacji
Perrotta opisuje niedocenianie szkoleń jako problem powracający w jego doświadczeniu, wiążąc go z nieefektywnym wykorzystaniem systemu i ograniczeniem korzyści. Na etapie decyzji inwestycyjnej oznacza to potrzebę uwzględnienia w budżecie udziału pracowników biznesowych i nauki, a nie przeprowadzania przedwczesnego przeglądu gotowości do uruchomienia. Nawet technicznie realne rozwiązanie wymaga ludzi, którzy potrafią zdefiniować, przetestować i przyjąć docelowy sposób pracy.
Przypisz finansom odpowiedzialność za założenia ekonomiczne, operacjom za rezultaty procesów, a IT za dowody dotyczące architektury i zależności. Wyznacz właściciela biznesowego każdej istotnej korzyści i nierozstrzygniętej decyzji procesowej. Tam, gdzie odpowiedzialność przebiega między działami, sponsor z kadry zarządzającej powinien uzgodnić zasady przekazywania zadań przed przyznaniem finansowania na realizację.
Oddziel późniejsze decyzje. Po zatwierdzeniu ścieżki inwestycyjnej skorzystaj z weryfikacji partnera wdrożeniowego ERP, aby sprawdzić, kto ją zrealizuje. Zgoda na uruchomienie produkcyjne należy do późniejszego przeglądu gotowości ERP do uruchomienia. Żadna z tych ocen nie powinna zastępować decyzji, czy sama inwestycja jest uzasadniona.
Przed zatwierdzeniem realizacji zestaw obok siebie wiodące scenariusze usprawnienia i wymiany. Wymagaj od każdego właściciela wskazania nierozstrzygniętej kwestii, której wynik najprawdopodobniej mógłby odwrócić rekomendację, a następnie zleć jej sprawdzenie przed zaangażowaniem większego budżetu.
Jeśli potrzebujesz wsparcia funkcjonalnego lub technicznego w ocenie tych scenariuszy, omów swoje procesy, ograniczenia integracyjne i zdolność organizacji do realizacji prac ze specjalistami ERP Digiventi.
