Poszliście na produkcję. Gratulacje. Nikt nie chce z tego korzystać.

Nadszedł ten wielki dzień. Ostatnie 2–3 lata to była szalona jazda, a teraz ktoś w końcu zacznie używać tego rozwiązania. Prawdziwi użytkownicy zalogują się i zaczną tworzyć klientów, szanse sprzedaży i oferty.

Dyrektor IT wciska przycisk i… po tygodniu dalszy rozwój jest praktycznie niemożliwy z powodu liczby spływających zgłoszeń. System jest tak trudny w nawigacji, że użytkownicy nie potrafią z niego korzystać, mimo że przeszli szkolenia. Szkolenie nie zastąpi używalnego oprogramowania.

Czasy oczekiwania są tak długie, że czekając na asetyzację, użytkownicy mogą wyjść na godzinny lunch i wrócić tylko po to, żeby stwierdzić, że proces wciąż się nie skończył.

Po miesiącu handlowcy odkurzają więc swoje arkusze Excela i zaczynają ich używać jako CPQ, CRM-a i czegokolwiek jeszcze, na co pozwoli to potężne narzędzie i ich wyobraźnia.

Wspomnę tu tylko, że Excel nadal jest źródłem prawdy dla firm na całym świecie i choć jest bardzo potężny, nie jest CRM-em.

Ale wróćmy do perspektywy Dyrektora IT, który jest w tej chwili w dość niekomfortowej sytuacji. Właśnie uruchomił nowe rozwiązanie, a już jest proszony o przedstawienie planu naprawczego. Zdecydowanie nie jest to pozycja, w której chcielibyście się znaleźć.

Ten artykuł będzie początkiem serii, w której rozwinę trochę temat źródeł tego rodzaju sytuacji — bo to wielowarstwowy tort złych decyzji, przełożony lukrem słabych praktyk, z niewłaściwym partnerem wdrożeniowym jako wisienką na wierzchu.

Dziś chciałem rozwinąć trochę wątek tego, jakie opcje ma nasz Dyrektor IT.

Zarząd jest dość niezadowolony z tego, co się dzieje.

Obecny partner wdrożeniowy Dyrektora IT próbuje odbijać wszystkie problemy słowami: „To jest dokładnie zgodne z wymaganiami, a wy zaakceptowaliście wszystkie User Stories”. Pytanie, które chciałoby się zadać, brzmi: „A gdzie napisaliśmy, że system ma być nieużywalny?”.

Faza discovery, przekładanie wymagań na user stories oraz zrozumienie, dlaczego zaakceptowane user stories niekoniecznie oznaczają, że system będzie działał zgodnie z zamierzeniem — to materiał na osobny artykuł. Dlatego gorąco polecam śledzić nasz blog i kolejną część serii.

W praktyce Dyrektor IT ma kilka opcji. Kiedy zaufanie do istniejącego układu delivery się załamało, dwie są szczególnie częste:

1. Pierwsza to próba rozwiązania sprawy zasobami wewnętrznymi: dowieść, że partner wdrożeniowy nie ma racji, zidentyfikować złe praktyki i inne problemy w rozwiązaniu oraz ustalić, co właściwie poszło nie tak. Ale wtedy ktoś jeszcze będzie musiał to naprawić. Do tego dysponowanie zasobami wewnętrznymi wystarczającymi, by jednocześnie prowadzić dalszy rozwój, naprawiać błędy i przeprowadzać audyt, rzadko jest realną możliwością.
2. Druga droga to wynajęcie firmy, która przyjdzie, sprawdzi rozwiązanie i przygotuje opartą na dowodach ocenę pokazującą: co nie działa, dlaczego tak się dzieje, jak poważny jest wpływ i co należy zrobić, aby uratować rozwiązanie; jakie są luki, których dobrych praktyk przestrzegano, a których nie, gdzie jakość kodu jest poniżej akceptowalnego poziomu i tak dalej. I wreszcie — dostarczy jasną roadmapę naprawczą.

Jak wspomniałem powyżej, każde wdrożenie ma wiele warstw. My w Craftware wiemy, jak badać je warstwa po warstwie, żeby dotrzeć do źródeł problemów.

To pytanie, które może paść, kiedy powiem, ile trwa taka inspekcja tortu.

Ale możecie przyjąć to jako pewnik, bo to nie nasze pierwsze rodeo.

Jako przykład mogę podać nasz ostatni duży assessment, przeprowadzony dla dużej firmy telekomunikacyjnej. Było to rozwiązanie rozwijane przez poprzednie pięć lat, z ogromną ilością customizacji. Ale przy odpowiednim planie, wiedzy branżowej i garści bardzo doświadczonych ludzi jeden miesiąc to więcej niż wystarczająco.

W tym miejscu na moment wychodzę z perspektywy Dyrektora IT i opowiadam o naszym własnym zespole.

Chciałbym się tu na sekundę zatrzymać i powiedzieć trochę więcej o naszych ludziach.

Siła i wiedza każdej organizacji mierzy się kombinacją umiejętności, doświadczenia i wiedzy jej pracowników. Jednym z ekspertów, którzy byli kluczową częścią naszego ostatniego assessmentu, jest Grzegorz Popardowski albo, jak sam mówi:

„Nikt poza Polską nie potrafi wymówić Grzegorz, więc po prostu mówcie mi Greg”.

Kto to taki, zapytacie?

Ma ponad 10 lat doświadczenia w telekomunikacji i transformacjach Salesforce, w tym ponad 5 lat w roli lidera architektury. Przejął nierokujący program Communications Cloud CPQ dla globalnego operatora Tier 1, ustabilizował delivery, ochronił budżet i odbudował zaufanie klienta.

Grzegorz odegrał również kluczową rolę w transformacji Lead-to-Cash dla Telia Carrier oraz prowadził architekturę backendu dla My Carrier Portal, wystawiając ponad 180 API Salesforce i integrując walidację katalogu produktowego w czasie rzeczywistym oraz CPQ pomiędzy Salesforce i Heroku.

Specjalizuje się w programach wysokiego ryzyka, złożonych integracjach i dopasowaniu biznesu do IT w działających środowiskach telekomunikacyjnych.

Piszę o tym nie tylko po to, żeby się przechwalać: „Patrzcie, mamy doświadczonych ludzi”, ale żeby podkreślić jedną bardzo ważną rzecz: te assessmenty i udane projekty to nie tylko wiedza techniczna. Wymagają połączenia wiedzy branżowej, technicznej i biznesowej.

Właśnie dlatego możemy przeprowadzić tego rodzaju projekt w ciągu miesiąca.

Czy to znaczy, że mamy doświadczenie wyłącznie w telekomunikacji?

Wręcz przeciwnie. To tylko jedna z gałęzi, a nie całe drzewo.

Poza Gregiem w zespole byli: Technical Architect / Expert Developer, Expert Consultant i Delivery Manager. Ci panowie na razie pozostaną anonimowi. Więcej o nich opowiem w kolejnych odcinkach.

Rola Technical Architecta / Developera jest dość oczywista, ale też kluczowa. To osoba, która schodzi do najgłębszych warstw, a nie jest to łatwe zadanie.

Reverse engineering, niezbędny, by odtworzyć rzeczywiste zachowanie systemu, zależności, założenia, powiązania (coupling) i efekty uboczne, jest zadaniem bardzo złożonym i wymagającym dużego doświadczenia.

Expert Consultant również musiał wykonać reverse engineering — obejmujący wszystkie narzędzia deklaratywne i funkcje Salesforce, za pomocą których zaimplementowano część funkcjonalności.

I na koniec: kto da wam lepszy feedback na temat governance projektu niż doświadczony Delivery Manager z doświadczeniem w delivery governance?

Odpowiedź: nikt.

Dlatego bardzo dobry DM także był częścią tego projektu i wniósł wiele do raportu. To ten człowiek, dla którego wychwytywanie nawet najmniejszych szczegółów, które mogą opóźnić wdrożenie, zagrozić mu lub obniżyć jego jakość, jest chlebem powszednim.

Tak.

I jeśli o mnie chodzi, nie znam żadnego innego ani lepszego sposobu, żeby porządnie coś ocenić. Jeśli wy znacie — dajcie mi znać.

Oczywiście możemy przeczytać dokumentację, jeśli istnieje. Możemy przeczytać kod i oczywiście możemy przejść przez dema i inne nagrania.

Niemniej to nie zastąpi kontaktu z ludźmi.

Żeby proces był dla klienta jak najbardziej bezbolesny, dzielimy taki projekt na kilka etapów.

Ogólnie mamy kilka głównych etapów:

1. Przygotowanie i wprowadzenie. Zbieramy wszystkie potrzebne dostępy, dokumentację i każde inne źródło wiedzy, jakie możemy uzyskać. Analizujemy to, żeby przygotować się do następnego kroku.
2. 2–3 dni warsztatów on-site. W przypadku programów w kryzysie wolimy zaczynać na miejscu, u klienta. To po prostu najszybszy sposób, by odkryć sprzeczne założenia, ukryte wyjątki procesowe i ten rodzaj wiedzy, który rzadko trafia do dokumentacji. Warsztaty dają nam możliwość zebrania niezbędnej wiedzy, zadania wszystkich pytań i wywoływania dyskusji po drodze. Dają nam też to, czego potrzebujemy, żeby przejść do kolejnego etapu.
3. Assessment. Zamykamy się w naszych biurach na kolejne trzy tygodnie, żeby przygotować ocenę. W tym czasie analizujemy, szukamy i dokumentujemy każde ustalenie oraz przygotowujemy dokumentację, która to wszystko potwierdza — a następnie ją prezentujemy.
4. Podsumowanie i kolejne kroki. Ostatnim etapem jest spotkanie „Podsumowanie i kolejne kroki”, które również lubimy przeprowadzać on-site. Lubimy spotykać ludzi na żywo. Wiem, jesteśmy trochę dziwni. To najlepszy moment, żeby podsumować wszystko, co znaleźliśmy, i wywołać dyskusję o tym, co można zrobić dalej.
   I to będzie wszystko w dzisiejszym odcinku „Jak poznałem wasze nieudane wdrożenie”.

W następnym odcinku opiszę bardziej szczegółowo, co dokładnie robimy podczas assessmentu i jak przechodzimy do kolejnych kroków.

Wszystkim, którzy dotrwali do końca tego artykułu, życzę udanego dnia i smacznej kawy.