Wdrożenie enterprise

Grupa transportowa rzadko jest jedną firmą. Bywa kilkoma spółkami, które rozliczają się między sobą, mają odrębne numeracje dokumentów i odrębne zobowiązania wobec kontrahentów, a jednocześnie wspólną flotę i wspólnych ludzi.

System musi to odwzorować bez zmuszania organizacji do udawania, że jest prostsza. Oddzielne podmioty, wspólne zasoby, przewóz wykonany autem jednej spółki na zleceniu drugiej — jeśli narzędzie tego nie obsługuje, różnicę uzupełnia arkusz, a wtedy wdrożenie jest tylko pozorne.

Przy kilkuset użytkownikach pytanie „kto to zmienił” przestaje być retoryczne. Potrzebna jest kontrola dostępu na poziomie ról i zakresów oraz historia zmian, którą da się przejrzeć bez angażowania dostawcy.

Dotyczy to szczególnie danych finansowych. Widoczność marży bywa w takich organizacjach kwestią polityczną i musi być sterowalna — inaczej wdrożenie zatrzyma się na etapie uzgodnień, a nie technologii.

Kartoteki kontrahentów, floty, kierowców i warunków handlowych przenosi się zawsze. Historię zleceń — rzadko w całości, bo koszt przeniesienia rośnie szybciej niż jej przydatność, a jakość starych danych zwykle okazuje się gorsza, niż wszyscy zakładali.

Rekomendujemy przenoszenie zamkniętego okresu i pozostawienie starego systemu w trybie odczytu na czas wynikający z przepisów. To niepopularna rekomendacja, bo brzmi jak niedokończona robota, ale ratuje projekty przed utknięciem na migracji danych sprzed sześciu lat, do których nikt nie zagląda.

Start całej organizacji w jednym dniu wygląda dobrze w harmonogramie i źle w praktyce. Preferujemy uruchomienie na jednym oddziale albo jednej spółce, przepracowanie pełnego cyklu miesięcznego łącznie z fakturowaniem, a dopiero potem rozszerzanie.

Pierwszy cykl jest ważniejszy niż pierwszy dzień. Większość niespodzianek — nietypowe rozliczenie, wyjątek u konkretnego klienta, dokument, o którym nikt nie wspomniał — wychodzi dopiero przy zamknięciu miesiąca.

Przy kilkuset użytkownikach nie ma jednego szkolenia dla wszystkich, bo spedytor, dyspozytor, księgowa i kierowca korzystają z zupełnie innych fragmentów systemu. Jedno wspólne spotkanie kończy się tym, że każdy słucha uważnie przez jedną czwartą czasu i wychodzi z poczuciem, że narzędzie jest skomplikowane.

Skuteczniejsze jest szkolenie ról i wskazanie w każdym zespole osoby, która zna system lepiej niż reszta. To ona odpowiada na dziewięćdziesiąt procent pytań w pierwszych tygodniach — szybciej niż jakiekolwiek zewnętrzne wsparcie i w języku, którym mówi jej dział.

Warto to zaplanować i policzyć w harmonogramie. Wdrożenia opóźniają się z powodu ludzi znacznie częściej niż z powodu oprogramowania, a czas tych kilku osób jest realnym kosztem projektu, tyle że rzadko wpisywanym do budżetu.

Po pierwsze brak decydenta po stronie biznesu. Projekt prowadzony wyłącznie przez dział IT rozstrzyga pytania procesowe technicznie, czyli źle, i wychodzi to po kilku miesiącach.

Po drugie równoległe prowadzenie dwóch systemów bez daty końcowej. Jeśli stary system pozostaje w użyciu „na wszelki wypadek”, część zespołu zostaje w nim na zawsze, a firma płaci za oba i ma dane w dwóch miejscach.

Po trzecie zamrożenie zakresu na pół roku. Wymagania spisane w styczniu i wdrażane w lipcu opisują firmę, której już nie ma — dlatego pracujemy etapami, a zakres kolejnego ustalamy po zakończeniu poprzedniego.

Przy tej skali rozmowa o czasie reakcji, oknach serwisowych i trybie zgłaszania awarii jest częścią umowy, a nie dobrą wolą. Ustalamy je przed startem i wprost, razem z tym, co dzieje się w sytuacji, której umowa nie przewiduje.

Osobno zapisujemy zasady eksportu danych. Firma tej wielkości nie powinna wchodzić w wieloletnią zależność bez jasnej odpowiedzi na pytanie, jak z niej wyjść.