Po prezentacji systemu ERP na stole zostaje lista możliwości i kilka historii udanych wdrożeń. Kolejny krok jest mniej efektowny, lecz ważny: trzeba sprawdzić, które doświadczenia innych firm mają znaczenie dla własnego przedsiębiorstwa. Dobry przykład referencyjny może podpowiedzieć, o co zapytać dostawcę. Nie zastąpi jednak opisu własnego procesu ani ustalenia, jak będzie oceniany wynik projektu.

Co dokładnie oznacza przedstawiony rezultat?

Pierwsze pytanie powinno dotyczyć miary. „Szybsza obsługa zamówień” może oznaczać krótszą pracę przy wprowadzaniu danych, mniej czasu na kompletację albo krótszy okres od zakupu do nadania przesyłki. To różne zjawiska, które wymagają innych danych. Podobnie niższy koszt magazynowy nie jest tym samym co mniejsza wartość zapasów czy mniej miejsca zajętego przez towar. Bez rozdzielenia tych pojęć trudno ustalić, czy przedstawiony efekt odpowiada na problem firmy. Warto poprosić o definicję wskaźnika i sposób jego obliczania. Jeżeli danych nie można udostępnić, dostawca lub klient referencyjny może przynajmniej wyjaśnić zakres pomiaru.

Kampanię Streamsoft opisaną przez Wirtualne Media oparto na doświadczeniach Grupy RBB, Dynaxo, Sportano i Lilou. Materiał pokazuje różne obszary wykorzystania ERP: od planowania produkcji po obsługę sprzedaży w kilku kanałach. Pełny opis znajduje się tutaj: https://www.wirtualnemedia.pl/klienci-w-centrum-kampanii-telewizyjnej-streamsoft,7337404857493920a. Z perspektywy osoby przygotowującej projekt IT najcenniejsze jest rozpoznanie procesu, którego dotyczy historia, a następnie zadanie pytań o warunki uzyskania rezultatu.

Podczas analizy można zapisać:

• początek i koniec mierzonego procesu oraz jednostkę pomiaru;
• okres przed zmianą i okres po uruchomieniu rozwiązania;
• zakres danych, w tym uwzględnione oddziały, magazyny lub typy zleceń;
• zmiany organizacyjne, które towarzyszyły wdrożeniu;
• informację, kto zbierał dane i jak sprawdzano ich kompletność.

Taka notatka pomaga oddzielić zrozumiały wynik od atrakcyjnego, ale nieprecyzyjnego hasła. Nie trzeba od razu budować rozbudowanego zestawu mierników. Lepiej wybrać kilka, które firma potrafi obliczać konsekwentnie, niż stworzyć długą listę bez odpowiedzialnej osoby i źródła danych.

Podobna branża nie oznacza identycznego wdrożenia

Wyobraźmy sobie dwa zakłady wytwarzające elementy metalowe. Jeden realizuje wiele krótkich zleceń, drugi pracuje na dłuższych seriach. Oba mogą potrzebować planowania produkcji, ale inne znaczenie będą miały dla nich zmiany kolejności zadań, dostępność materiału i czas przygotowania stanowisk. To hipotetyczne porównanie pokazuje, dlaczego nazwa branży jest dopiero początkiem analizy referencji.

Trzeba zejść do sposobu pracy. Ile etapów obejmuje zlecenie? Gdzie powstają dane o materiałach? Jak przekazuje się informację o wykonaniu? Czy część operacji odbywa się w innych narzędziach? Im dokładniej firma opisze swój proces, tym łatwiej będzie sprawdzić, czy pokazane wdrożenie rozwiązywało podobną trudność, czy jedynie działało w podobnym otoczeniu.

Z opisu produktów Streamsoft wynika, że Prestiż obejmuje rozwiązania dla produkcji, handlu i usług, natomiast Verto jest przeznaczone między innymi dla nowoczesnego handlu i modelu omnichannel. To rozróżnienie pozwala rozpocząć rozmowę o zakresie. Ostateczna ocena musi jednak dotyczyć konkretnych modułów, integracji i ustalonej konfiguracji, a nie wyłącznie nazwy systemu.

W referencji warto szukać przedsiębiorstwa podobnego pod względem problemu, nie tylko wielkości. Firma o znacznie większym obrocie może mieć użyteczne doświadczenie w łączeniu kanałów sprzedaży, ale jej projekt nie musi stanowić właściwego wzorca organizacji całego wdrożenia u mniejszego klienta.

Sprawdzić drogę danych na rzeczywistym zadaniu

Prezentacja modułów powinna prowadzić do demonstracji wybranego procesu. Można poprosić o przejście od zamówienia przez rezerwację towaru do wydania i rozliczenia. W zakładzie produkcyjnym scenariusz może obejmować sprawdzenie materiałów, utworzenie zlecenia oraz rejestrację jego wykonania. Zakres trzeba uzgodnić z dostawcą i oprzeć na wymaganiach przedsiębiorstwa, bez zakładania, że każde rozwiązanie obsługuje wszystkie etapy w jednakowy sposób.

Najwięcej pytań warto zadać przy przekazywaniu informacji pomiędzy systemami. Które narzędzie jest źródłem danych? Kiedy pozostałe otrzymują aktualizację? Co dzieje się, jeśli komunikat nie zostanie dostarczony?

Samo potwierdzenie, że istnieje integracja, jest niewystarczające do oceny konkretnego zadania. Trzeba poznać jej zakres, częstotliwość wymiany danych, obsługę błędów i sposób ponowienia operacji. Warto także ustalić odpowiedzialność za utrzymanie połączenia oraz za zmiany po aktualizacji jednej z aplikacji. Dzięki temu oczekiwania wobec integracji można później przełożyć na sprawdzalny scenariusz odbioru.

Dane demonstracyjne bywają uporządkowane lepiej niż firmowe kartoteki. Dlatego przed projektem należy ocenić własne informacje o produktach, materiałach, kontrahentach i jednostkach miary. Jeśli firma używa różnych nazw dla tego samego elementu, najpierw musi ustalić zasady identyfikacji. Nowy system nie rozstrzygnie sam, które z dwóch sprzecznych oznaczeń odpowiada rzeczywistemu procesowi.

Ustalić punkt odniesienia przed uruchomieniem

Ocenę efektu warto zaplanować, zanim zespół zacznie korzystać z nowego rozwiązania. W przeciwnym razie po wdrożeniu może brakować danych o wcześniejszym sposobie pracy. Porównanie oparte jedynie na pamięci pracowników będzie trudne do odtworzenia. Nie trzeba mierzyć każdego ruchu; należy wybrać zadania ważne dla projektu i ustalić jednolite zasady zbierania informacji.

Dla jednego procesu można przygotować prostą kartę: nazwa wskaźnika, definicja, źródło danych, osoba odpowiedzialna i termin przeglądu. Jeżeli firma chce oceniać terminowość zleceń, musi ustalić, do którego terminu porównuje wykonanie i jak traktuje zmianę uzgodnienia z klientem. Jeśli interesuje ją czas obsługi, powinna zdecydować, czy uwzględnia oczekiwanie na informacje oraz przerwy niezwiązane z pracą systemu.

Pierwsze dni po uruchomieniu mogą być okresem nauki i poprawiania konfiguracji. Warto rozdzielić ocenę gotowości rozwiązania od oceny ustabilizowanej pracy. Daty i warunki obu przeglądów powinny zostać ustalone dla konkretnego projektu.

Porównując okresy, trzeba uwzględnić różnice w obciążeniu i strukturze zadań. Obsługa prostych zamówień i obsługa zamówień wymagających dodatkowych uzgodnień nie są tym samym. Jeżeli po wdrożeniu zmienił się udział tych grup, sama średnia może ukrywać ważną różnicę. Dobrze jest więc analizować podobne typy operacji i opisać ograniczenia dostępnych danych, zamiast dopasowywać interpretację do oczekiwanego wyniku.

Najbardziej użyteczny rezultat rozmowy o historii klienta to zestaw zadań, które firma chce sprawdzić podczas własnego projektu. Każde powinno mieć dane wejściowe, oczekiwany przebieg i warunek uznania wyniku za poprawny. Warto uwzględnić również wyjątki: zmianę zamówienia, brak materiału, zwrot lub błąd komunikacji. Ich wybór powinien wynikać z rzeczywistych sytuacji przedsiębiorstwa.

Przed odbiorem dobrze ustalić:

• kto wykonuje scenariusze i kto zatwierdza rezultat;
• które przypadki są konieczne do rozpoczęcia pracy;
• jak rejestrowane są uwagi i uzgadniane poprawki;
• jakie dane pozwolą później ocenić efekt biznesowy.

Historia referencyjna może wskazać kierunek, ale na końcu to własne zamówienie, własne dane i własny pracownik powinny znaleźć się w scenariuszu sprawdzenia. Gdy zespół potrafi pokazać, jak wykona konkretne zadanie i jak rozpozna nieprawidłowy rezultat, rozmowa o ERP staje się wystarczająco precyzyjna, by podejmować decyzje o dalszym zakresie projektu.

Publikacja przygotowana we współpracy