Dlaczego wdrożenia się przeciągają. Sześć powodów widocznych już w analizie

Kiedy wdrożenie się przeciąga, w raporcie zwykle ląduje technologia: integracja okazała się trudniejsza, dane były w gorszym stanie, niż sądzono.

Prawie zawsze jest to opis objawu, a nie przyczyny. Prawdziwe powody widać dużo wcześniej, często już na trzecim spotkaniu analitycznym, i wszystkie sześć poniżej daje się rozpoznać, zanim ktoś napisze pierwszą linię konfiguracji.

Powód 1: zakres obejmuje wszystko naraz

Firma postanawia „skoro już wdrażamy, to zróbmy porządek w całości”: faktury, umowy, urlopy, reklamacje i jeszcze raportowanie.

Każdy z tych procesów ma innych właścicieli i inne wyjątki, więc analiza pięciu procesów nie trwa pięć razy dłużej niż jednego, tylko znacznie dłużej, bo dochodzą zależności między nimi. Efektem jest pół roku bez niczego działającego i rosnące zniecierpliwienie zarządu.

Powód 2: nie ma osoby decyzyjnej, są konsultacje ze wszystkimi

To jest najczęstszy pojedynczy powód opóźnień i najtrudniejszy do powiedzenia klientowi wprost.

Jeżeli na pytanie „czy akceptuje kierownik, czy dyrektor” odpowiedź brzmi „musimy to skonsultować”, każda taka odpowiedź kosztuje dwa tygodnie. Przy trzydziestu pytaniach projekt stoi pół roku, choć nikt nie zrobił nic złego.

Lekarstwo jest proste i niepopularne: jedna osoba z prawem do rozstrzygania, która może się pomylić. Decyzja błędna i szybko poprawiona jest tańsza od decyzji doskonałej podjętej po kwartale.

Powód 3: proces opisany tak, jak powinien wyglądać

Na warsztacie ludzie opisują wersję oficjalną, bo tak wypada przy przełożonym. System powstaje pod ten opis, a potem okazuje się, że w rzeczywistości połowa spraw idzie skrótem, którego nikt nie zgłosił.

Objaw rozpoznawczy: proces opisany bez ani jednego wyjątku. Nie ma takich procesów. Jeżeli ktoś twierdzi, że jego proces nie ma wyjątków, to znaczy, że wyjątki obsługuje ktoś inny i nie ma go na sali.

Powód 4: wyjątki odkrywane po starcie

Wynika wprost z poprzedniego. Nikt nie zadał pytania „co robicie, gdy się nie zgadza”, więc system obsługuje wyłącznie przypadek idealny.

Pierwsza faktura sporna, pierwsza korekta i pierwsza sprawa prowadzona równolegle przez dwie osoby wywracają konfigurację, a poprawki wchodzą już na działającym systemie, co jest kilka razy droższe niż przewidzenie ich wcześniej.

Jedno pytanie, które warto zadać na każdym warsztacie: kiedy ostatnio sprawa poszła inaczej, niż przed chwilą opisano, i dlaczego.

Powód 5: integracja z systemem, którego nikt nie zna

Sytuacja powtarzalna. Trzeba się spiąć z systemem, który wdrażał zewnętrzny partner osiem lat temu, dokumentacji nie ma, a osoba, która to prowadziła, dawno odeszła.

Integracja jest jedynym elementem wdrożenia, który zależy od strony trzeciej, więc należy ją sprawdzić najwcześniej, a nie najpóźniej. Ustalenie w pierwszym tygodniu, czy tamten system w ogóle ma API i kto ma do niego dostęp, potrafi uratować miesiąc.

Powód 6: zaplanowano wdrożenie oprogramowania, nie ludzi

W harmonogramie są konfiguracja, testy i uruchomienie. Nie ma pozycji „ludzie zaczynają z tego korzystać”, bo wydaje się, że to stanie się samo.

Nie stanie się. Przez pierwsze tygodnie nowy sposób jest wolniejszy od starego i to jest normalne, tylko trzeba to przewidzieć i przez to przeprowadzić. Bez tego projekt formalnie kończy się w terminie, a faktycznie ciągnie się miesiącami w postaci dwóch równoległych obiegów.

Co robić zamiast tego

Recepta jest krótka i sprowadza się do odwrócenia kolejności: najpierw coś działającego, potem reszta analizy.

1. Jeden proces na start. Najlepiej ten najbardziej uciążliwy, bo korzyść będzie widoczna, a zwolennicy projektu pojawią się sami.

2. Jedna osoba decyzyjna. Wskazana z imienia i nazwiska, z prawem do rozstrzygania i z czasem na to zarezerwowanym.

3. Krótki cykl. Co dwa tygodnie coś, co da się kliknąć, nawet jeżeli jest niekompletne.

4. Data wyłączenia starego sposobu. Zapisana w harmonogramie, nie w dobrych chęciach.

Sprawdzian jest prosty. Jeżeli po miesiącu od startu nikt w firmie nie widział działającego ekranu, projekt nie jest opóźniony technicznie. Jest źle ułożony, a opóźnienie dopiero nadejdzie.