Najlepsze praktyki przed migracją systemu

Przestawienie systemu rzadko opóźnia się z powodu samej aplikacji. Częściej problemem jest to, że podczas przestawienia okazuje się, że dane zamówienia różnią się w różnych miejscach, wyjątek magazynowy istnieje tylko w głowie doświadczonego kolegi, lub tabela Excel wspiera decyzję, której nikt nie udokumentował. najlepsze praktyki przed przestawieniem systemu to nie tylko punkty kontrolne IT. Są to warunki kontroli działania.

W rozwijającej się firmie wymiana lub integracja systemu może dotyczyć sprzedaży, zakupów, produkcji, magazynu, fakturowania i raportów zarządczych. Jeśli przestawienie zaczyna się tylko jako projekt technologiczny, stare błędy mogą pozostać - tylko na nowym interfejsie. Lepszym podejściem jest najpierw zbadanie, jak firma faktycznie działa, a dopiero potem zdecydowanie, co należy przenieść, przekształcić lub porzucić.

Przed przestawieniem systemu należy ocenić rzeczywisty proces

Opisany proces i rzeczywiste działanie często nie są takie same. Na przykład, zgodnie z diagramem procesu, zamówienie ze sklepu internetowego jest automatycznie przenoszone do ERP, ale w praktyce pracownik codziennie rano sprawdza, poprawia i ręcznie uzupełnia brakujące dane. To niekoniecznie jest błąd ze strony zaangażowanego kolegi. Raczej wskazuje to, że system lub proces nie radzi sobie odpowiednio z wyjątkami.

Przed przestawieniem warto prześledzić kilka rzeczywistych przypadków od początku do końca. Zamówienie przychodzące, zwrot, pilny zakup, odchylenie produkcyjne lub reklamację. Kto inicjuje proces? Na podstawie jakiej informacji podejmuje decyzję? W którym systemie rejestruje dane? Gdzie sprawa czeka i kto interweniuje, jeśli coś nie dzieje się zgodnie z oczekiwaniami?

Ta praca nie jest formalnością administracyjną. Dzięki niej wiadomo, które funkcje w nowym systemie muszą działać od pierwszego dnia, a które stare kroki nie służą już celom biznesowym. W wielu przypadkach największy sukces osiąga się nie dzięki rozwojowi, ale poprzez eliminację zbędnego zatwierdzania, równoległego wprowadzania danych lub ręcznego uzgadniania.

Wyjątki mogą być ważniejsze niż przeciętne przypadki

Normalny proces jest zazwyczaj łatwy do przedstawienia. Trudności zaczynają się, gdy przychodzi częściowa dostawa, klient prosi o inny adres dostawy, zapas produktu staje się ujemny lub zamówienie trzeba zmodyfikować po wystawieniu faktury. Te przypadki nie są codzienne, ale powodują znaczny czas, uzgadnianie i ryzyko.

Nie celem jest całkowita automatyzacja każdego wyjątku. W przypadku rzadkiej decyzji wymagającej dużej wiedzy lepiej, aby system wyraźnie sygnalizował problem i kierował go do wyznaczonej osoby. Ważne jest, aby obsługa wyjątku nie była ukrytym, zależnym od osoby obejściem.

Przed migracją danych należy wyjaśnić właściciela danych

Jednym z najczęstszych nieporozumień podczas przestawień jest to, że wszystkie istniejące dane muszą zostać przeniesione. Nie jest to pewne. Przeniesienie dziesięcioletniego, niekompletnego lub zduplikowanego zbioru danych głównych nie jest zachowaniem, ale kontynuacją starej niepewności.

Najpierw należy określić, które dane są niezbędne do codziennego działania, zobowiązań prawnych lub umownych oraz analizy biznesowej. Następnie należy zidentyfikować właściciela danych. Kto odpowiada za nazwę, jednostkę miary i status artykułu? Kto może decydować o zmianie danych partnera? Który system jest głównym źródłem, jeśli te same dane klienta znajdują się w CRM, ERP i systemie fakturowania?

Jeśli nie ma na to jasnej odpowiedzi, integracja tylko szybciej rozprzestrzeni różnice. Połączenie techniczne może przesyłać dane, ale nie może zdecydować, które dane są poprawne.

Nie tylko rekordy, ale także zasady biznesowe powinny być testowane

Import danych nie jest udany, jeśli wszystkie wiersze zostały załadowane. Należy również sprawdzić, czy dane pozwalają na wykonanie ważnych operacji biznesowych. Czy zamówienie jest prawidłowo tworzone? Czy zapas jest rezerwowany? Czy na dokumencie znajduje się odpowiedni VAT, warunki płatności, cena lub rabat? Czy raport pokazuje to samo, co wcześniej używało kierownictwo, a jeśli nie, czy dokładnie wiedzą dlaczego?

Przydatne jest, jeśli kontrola nie jest tylko zadaniem IT i dostawcy. Finanse, magazyn, sprzedaż i produkcja zauważają błędy, które technicznie mogą nie być widoczne, ale w działaniu natychmiast powodują zatory.

Najlepsze praktyki przed przestawieniem systemu: jasne odpowiedzialności

Podczas przestawienia wiele zadań trafia do „kogoś”. Ktoś musi zatwierdzić dane główne, sprawdzić import, poinformować użytkowników lub podjąć decyzję w otwartej kwestii. Jednak „ktoś” nie jest zakresem odpowiedzialności.

Już na początku projektu należy określić, kto podejmuje decyzje biznesowe, kto odpowiada za proces, kto przygotowuje dane, kto dokonuje zmian technicznych i kto może udzielić zgody na uruchomienie. Szczególnie ważne jest określenie granic decyzyjnych. Programista nie może samodzielnie decydować, czy wyjątek fakturowania jest akceptowalny biznesowo, ale kierownik biznesowy nie musi udzielać odpowiedzi technicznej na poziomie bazy danych.

Wyjaśnienie odpowiedzialności ujawnia również obciążenie kluczowych osób. Wiele projektów spowalnia, ponieważ ci sami dwaj eksperci wykonują codzienną operację, a jednocześnie oczekuje się od nich wszystkich testów i zatwierdzeń. W takich przypadkach plan przestawienia musi uwzględniać zastępstwa, określone okna czasowe lub tymczasową pojemność.

Uruchomienie nie powinno być pierwszym pełnym testem

Środowisko testowe samo w sobie nie jest gwarancją. Daje prawdziwe bezpieczeństwo, jeśli firma testuje w nim scenariusze krytyczne z punktu widzenia codziennego działania. W przypadku magazynu mogą to być przyjęcia, przechowywanie, komisjonowanie, inwentaryzacja i wysyłka. W produkcji wydawanie materiałów, zarządzanie zleceniami, rejestracja odpadów i przyjmowanie gotowych produktów. W handlu łańcuch zamówień, płatności, fakturowania, zwrotów i informacji dla klientów.

Test powinien być przeprowadzany z realistycznymi ilościami i rolami. Nie wystarczy jedno zamówienie próbne, jeśli w normalnym działaniu dane pochodzą z wielu kanałów, następują ruchy zapasów, a kilka osób pracuje nad tym samym zasobem. Ważne jest również, aby testerzy nie sprawdzali tylko tego, co nowy system powinien umieć, ale także tego, co wcześniej prowadziło do błędów.

Do decyzji o uruchomieniu warto wcześniej określić warunki akceptacji. Które procesy muszą działać bezbłędnie? Jakie odchylenie można obsłużyć po uruchomieniu, a co zatrzymuje przestawienie? Dzięki temu można uniknąć niepewnej decyzji „przejdźmy na żywo” opartej na wrażeniach.

Plan powrotu jest potrzebny, ale nie zawsze taki sam

Plan powrotu nie jest pesymizmem, ale dyscypliną ciągłości działania. Jeśli w nowym systemie pojawi się krytyczny błąd, każdy powinien wiedzieć, kto decyduje o powrocie, jakie dane można zapisać, do jakiego momentu można wrócić do starego systemu i jak obsługiwać transakcje powstałe podczas przejścia.

Całkowity powrót nie zawsze jest realny lub konieczny. W przypadku stopniowo wprowadzanej nowej rozwiązania raportowego można przez jakiś czas utrzymać stary raport równolegle. W przypadku wymiany centralnego ERP może to być znacznie bardziej skomplikowane, ponieważ równoległe księgowanie i zarządzanie zapasami między dwoma systemami może tworzyć nowe różnice. Tutaj należy wcześniej rozważyć, jak długo można utrzymać stare działanie i jakie ryzyko niesie podwójne zarządzanie danymi.

Plan powinien również uwzględniać wpływ na klientów, dostawców i pracowników. Jeśli z powodu przerwy opóźnia się potwierdzenie, wysyłka lub fakturowanie, powinna być jasna procedura komunikacyjna i ręczna. Dobrze przygotowane przejście nie jest dobre dlatego, że nigdy nie ma problemu, ale dlatego, że organizacja nie improwizuje, gdy problem się pojawia.

Pierwsze dni po uruchomieniu są również częścią projektu

Przestawienie nie kończy się naciśnięciem przycisku uruchomienia. Błędy pojawiające się w pierwszych dniach szybko ujawniają, gdzie były różnice między założonym a rzeczywistym działaniem. Wymaga to wyznaczonego wsparcia, krótkiej ścieżki decyzyjnej i wspólnej listy zarządzania błędami.

Warto rozróżniać błędy zatrzymujące działanie, problemy możliwe do obejścia i potrzeby rozwoju. Jeśli każda uwaga ma ten sam priorytet, zespół traci koncentrację. Jeśli jednak krytyczne problemy szybko stają się widoczne, kierownictwo może podejmować bardziej uzasadnione decyzje dotyczące priorytetów.

Dobre pytania zadane przed przestawieniem systemu są często cenniejsze niż długa lista funkcji. Jaką pracę wykonujemy tylko z przyzwyczajenia? Gdzie te same dane są tworzone dwa razy? Kto potrafi samodzielnie naprawić proces? Jeśli na te pytania padną szczere odpowiedzi, nowy system nie tylko zastąpi stary, ale zapewni bardziej przewidywalne działanie dla wzrostu.