6 kroków od świadomości do sukcesu wdrożeniowego – Krok 4: Przygotowanie środowisk i biznesu do Startu Produkcyjnego

Z artykułu dowiesz się:

1. Jakie są najczęstsze błędy między analizą wdrożeniową a startem produkcyjnym?
2. Jak prawidłowo zdefiniować procesy przed startem produkcyjnym?
3. Dlaczego stabilność zespołu wdrożeniowego jest kluczowa?
4. Czy każda „stacja” we wdrożeniu wygląda tak samo?
5. Jakie są główne przyczyny niepowodzeń wdrożeniowych?
6. Jak unikać przeciążeń systemu ERP i optymalizować procesy?
7. Jak testy międzyobszarowe wpływają na sukces wdrożenia?
8. Kim jest Solution Architect i dlaczego jego rola jest kluczowa?
9. Jak zapewnić techniczną jakość wdrożenia?
10. Jak uniknąć błędów przed startem produkcyjnym?

Jesteśmy w fazie drugiej - przygotowanie systemu w oparciu o zatwierdzony dokument analityczny.

W większości przypadków taki dokument można opisać dwoma słowami: obszerny oraz indywidualny. Analitycy biznesowi podczas spotkań starają się zarejestrować każde słowo klienta, a klient opowiada o swoim obszarze bez podziału na czas przeszły i przyszły. Jeśli przemnożymy liczbę obszarów przez objętość napisanego tekstu, to w wielu przypadkach przebijemy objętością Biblię Gutenberga. Dla jednych to sukces, dla innych - tomy wiedzy niemożliwe do przyswojenia.

Gdybyśmy przeprowadzili ankietę wśród osób, które przeczytały "Nad Niemnem" Elizy Orzeszkowej, większość znałaby losy głównych bohaterów, ale tylko nieliczni zwróciliby uwagę na opisy przyrody. Orzeszkowa od dziecka fascynowała się botaniką – do "Nad Niemnem" zgromadziła aż 460 różnych okazów roślin. Każdy z nas postrzega świat inaczej, niezależnie od tego, czy jesteśmy dostawcą usługi, czy jej odbiorcą. Dokument powinien być napisany w sposób czytelny i zrozumiały dla konsultanta, Project Managera, architekta oraz programisty.

Definicja projektowa – proces, element, czynność

Obserwujmy i rejestrujmy świat klienta z perspektywy procesów, elementów i czynności. Iloczyn liczby procesów, ich elementów oraz czynności w ramach tych procesów determinuje harmonogram wdrożeniowy. Im większa wyliczona wartość, tym większy jest projekt. Jeśli potraktujemy proces jak linię metra, możemy posługiwać się analogią do różnych miast:

• 3 procesy – Praga,
• 11 procesów – Londyn,
• 16 procesów – Paryż,
• 27 procesów – Nowy Jork.

Przykładowy proces biznesowy w systemie informatycznym to złożenie zamówienia u dostawcy w Chinach, a końcowym etapem procesu jest ewidencja wszystkich opłat i zobowiązań względem dostawcy zagranicznego, urzędu celnego i skarbowego. Elementami tego procesu są: przesłanie zamówienia z systemu do dostawcy, ewidencja punktów przemieszczenia produktów po lądzie, wodzie, portach, aż po fizyczne przyjęcie towaru do odpowiedniej lokalizacji magazynowej.

Każdy element procesu wymaga ewidencji czynności. Przykładowo, w procesie przyjęcia produktu czynności obejmują:

• ustalenie terminu przyjazdu ładunku,
• przyjazd i rozładowanie towaru na rampie,
• oznakowanie oraz rozmieszczenie towaru w poszczególnych lokalizacjach magazynowych.

Proces ten można porównać do linii metra w Londynie, np. Victoria Line, która ma 16 stacji, a niemal na każdej stacji istnieje możliwość przesiadki na inną linię.

Transport for London – zespoły wdrożeniowe

Każdy projekt ma swojego sponsora, który finansuje wdrożenie nowego systemu poprzez przelew na konto dostawcy. Odpowiedzialność za rzetelną realizację projektu po stronie dostawcy spoczywa na barkach kierownika projektu. Tak dużymi przedsięwzięciami nie mogą zarządzać dwie osoby, dlatego powoływane są zespoły wdrożeniowe. W poprzedniej części przedstawiłem elementarne cechy takich zespołów oraz podstawowe zasady, które powinny je obowiązywać w fazie analizy.

Porównując do metra w Londynie, sponsorem byłby Burmistrz Londynu, a zespołem wdrożeniowym – agencja wykonawcza Transport for London. Na czele zespołu stoi osoba powołana przez zarząd, którą projektowo nazywam Project Managerem (PM). Do jego zadań należy nadzorowanie zespołu oraz wdrożenie planu opisanego w dokumencie analizy. Każdy PM musi trzymać się harmonogramu, aby start poszczególnych węzłów komunikacyjnych przebiegł bez opóźnień, ponieważ podstawową cechą efektywnej komunikacji jest punktualność.

Stacja

Każdy zespół buduje się na podstawie kompetencji obszarowych. Członkami zespołu są konsultanci odpowiedzialni za obszary finansów, produkcji, projektów, zasobów oraz serwisu. Ściśle współpracują oni z programistami i administratorami systemu. Każdy z nich odpowiada za swój obszar w systemie, budując swoją "stację metra". W zależności od kompetencji ostateczny wygląd i funkcjonalność danej stacji często odbiegają od założeń opisanych w projekcie (analiza). Niestety jest to jeden z głównych problemów, które wpływają na planowe uruchomienie przedsięwzięcia jakim jest start metra.

Jakie czynniki determinują porażkę?

Nieodpowiednio dobrany zespół może prowadzić do problemów, które wpływają na planowe uruchomienie projektu. Jednym z najczęstszych błędów jest brak lidera z doświadczeniem, który świadomie zarządza podległymi sobie osobami. Kolejnym problemem jest nadmierna rotacja zespołu, zarówno po stronie dostawcy, jak i klienta. Stabilność kadrowa jest kluczowa dla powodzenia wdrożenia.

Zawsze sprawdź, czy przy każdej budowanej stacji znajduje się lider z doświadczeniem, który w sposób świadomy zarządza zespołem.

Wiele firm wykorzystuje swoich najlepszych, najbardziej doświadczonych pracowników podczas prezentacji oraz rozmów analitycznych. Wymagajmy od dostawcy niezmienności zespołu podczas całego procesu wdrożeniowego. Nie dopuśćmy do rozmycia odpowiedzialności poszczególnych osób w procesie tworzenia. Jeśli ktoś rozmawia, analizuje, ustala i projektuje rozwiązanie, to niech również uczestniczy w dalszym procesie tworzenia oraz czynnie bierze udział w przecięciu wstęgi z napisem „start produkcyjny”. Zbyt duża rotacja ekip budujących stację metra powoduje zwiększenie kosztów oraz wydłużenie czasu realizacji.

Drugim istotnym elementem jest spójność budowanych elementów. Każda stacja metra powinna wyglądać i funkcjonować podobnie. Brak jednolitych standardów może powodować opóźnienia w transporcie i zwiększenie kosztów utrzymania. Projektujmy rozwiązania w sposób spójny, unikając zbędnych elementów, które mogą negatywnie wpłynąć na wydajność całego systemu.

Pasażer kupując bilet na przejazd, nie powinien tracić czasu na czytanie legendy dotyczącej zasad występujących na danej stacji. Niewiele osób jest zainteresowanych malowidłami ściennymi oraz zmieniającą się paletą barw i świateł. Wchodzimy do metra by w łatwy sposób dostać się na odpowiedni poziom, który umożliwi nam w najkrótszym czasie realizację naszego celu podróży. Często ponosi nas ambicja, by „nasza” stacja wyróżniała się na tle innych. Brak spójności obiektów w późniejszym etapie powoduje opóźnienia w transporcie oraz zwiększenie kosztów funkcjonowania zbytecznych elementów. Twórzmy tak swoje rozwiązania, by zawsze były spójne z innymi obszarami w systemie. Nie twórzmy elementów i czynności nadmiarowych, bo mogą wpływać negatywnie na wydajność całego systemu. Każdy dodatkowy kod programistyczny może generować wysokie koszty podczas aktualizacji systemu i wprowadzania modyfikacji. Projektujmy i wykonujmy elementy tak, aby dane efektywnie przemieszczały się w całym procesie oraz aby nie zaburzały innych czynności w systemie.

Wagon

W kontekście przewozu osób istotne jest optymalne wykorzystanie jednostek transportowych. Twórzmy rozwiązania tak, aby składy pasażerskie umożliwiały łatwe zarządzanie liczbą wagonów.

Nieoptymalnie zaprojektowane procesy mogą prowadzić do przeciążeń systemu. Zbyt duża liczba wagonów w składzie powoduje spowolnienie transportu, co przekłada się na wydłużenie czasu przejazdu na całej trasie. W konsekwencji pasażerowie doświadczają opóźnień, a organizacja transportu ponosi straty budżetowe. W systemach informatycznych analogiczne błędy mogą powodować zatory w procesach wsadowych. Nadmierne obciążenie jednego obszaru wpływa negatywnie na cały system. Ważne jest, aby projektować procesy tak, aby dane przemieszczały się płynnie, nie zakłócając działania innych funkcjonalności. Nieoptymalny kod daje początek kuli śnieżnej, czyli wydłużenie przejazdu w obrębie nie tylko tej linii, ale wydłużenie czasu przejazdu pasażera poruszającego się kilkoma liniami metra. Niezadowolony pasażer to dla Transport for London straty nie tylko wizerunkowe, ale przede wszystkim budżetowe wynikające z odpływu pasażerów oraz zwiększenie energii na transport nieefektywny.

Projektujmy, by podróż produktu w systemie była jak najkrótsza, a dodatkowo stanowiła źródło niezbędnych danych kontrolingowych do optymalizacji cen i kosztów. W systemach fundamentalne znaczenie ma efektywne działanie obszaru zadań wsadowych. Dobierajmy liczbę wagonów tak, aby proces był przewidywalny w zakresie ustalania początku i końca przejazdu. Zbyt duża porcja pobranych danych może spowodować w systemie wydłużenie czasu księgowania zestawień handlu detalicznego, co bezpośrednio spowoduje opóźnienia lub puste przebiegi obszaru rozliczeń sprzedaży, a w konsekwencji uniemożliwi księgowanie zwrotów i korekt.

Linie

Co może oznaczać linia metra w kontekście projektu wdrożenia?

Linia metra symbolizuje cały proces biznesowy, natomiast poszczególne stacje to jego elementy składowe. Zatrzymania, ruszanie pociągu oraz wsiadanie i wysiadanie pasażerów to analogia do poszczególnych czynności wykonywanych w ramach procesu. Podczas budowy nowego systemu często dochodzi do błędów wynikających z błędnej interpretacji procesów. Zespoły wdrożeniowe mylnie postrzegają swój zakres pracy jako niezależny, co skutkuje brakiem integracji pomiędzy poszczególnymi obszarami. Konieczne jest podejście holistyczne, uwzględniające powiązania między procesami i ich wpływ na całą organizację.

Przekładając na system, to procesem może być złożenie zamówienia u dostawcy, a skończywszy na ewidencji księgowej faktury oraz rozliczenie zobowiązania wobec dostawcy. Elementem procesu jest przyjęcie fizyczne towaru dokumentem PZ, dokonanie zapłaty za zakupiony towar itp. Czynnościami jest przyjęcie na terminalu dostawy w magazynie, zabranie z rampy oraz przetransportowanie wózkiem widłowym palety przywiezionego towaru do odpowiedniej lokalizacji magazynowej.

Jak proces jest postrzegany przez zespół implementujący rozwiązania podczas budowy nowego systemu? Czy w tym obszarze występują błędy?

Odpowiedź na to pytanie związana jest z omawianym powyżej opisem stacji, czyli obszarem kompetencyjnym. Każdy z zespołu odpowiada za swój element procesu, buduje rozwiązania, a tym samym tworzy arterię komunikacyjną, czyli szyny oraz stacje. Podstawowym błędem podczas wewnętrznych spotkań jest używanie sformułowań: „Zaprezentuj nam swój proces”, „Mój proces zaczyna się….., a kończy na …..”. Otóż to nie jest proces tylko element procesu. Błędne sformułowania o skończoności tego, co robimy powoduje, że nie zastanawiamy się nad wpływem naszych rozwiązań na pracę innych osób w zespole. Ktoś, kto projektuje rozwiązania w obszarze zakupowym, magazynowym, nie zastanawia się nad tym, że praca może mieć wpływ na rozbieżności pomiędzy obszarem magazynowym, a finansowym. Podobnie jak osoba projektująca w obszarze finansowym fakturę VAT marża, gdzie skupia się na aspekcie wyglądu layoutu faktury VAT. Precyzyjnie ustala wszystkie elementy w dokumencie, które są określone przepisami Ministerstwa Finansów. Po zakończonej pracy jest z siebie zadowolona i ogłasza, że ona swój proces już zakończyła.

Tylko czy na pewno przy takim podejściu do definicji procesu biznes klienta jest bezpieczny?

Jeśli przełożymy to na linię metra, to możemy mówić o odcinku od stacji „London City Airport” do stacji „Star Lane”, czyli o zakresie 4 przystanków. Projektant z poczuciem zakończenia pracy, bo jego proces się zakończył, nie widzi, że kolejna stacja to stacja przesiadkowa „West Ham”, gdzie krzyżuje się kilka linii. W ujęciu procesowym mogą to być procesy odpowiadające za ustalanie wyceny magazynu, przeliczanie i zamknięcie magazynu. Te 3 procesy wpływają znacząco na efekt końcowy oraz poprawność danych na tak misternie projektowanej i wykonanej fakturze. Przestrzegam przed błędami wynikającymi z niewłaściwego podejścia do definiowania procesu. W naszym przypadku zderzenie 3 wartości: wyceny magazynu średnioważonej, przeliczenia i korekty transakcji magazynowej oraz procesu zamknięcia magazynu może skutkować fluktuującymi wartościami wyliczonego podatku VAT. Kluczem do sukcesu jest prawidłowa definicja procesu, elementu procesu oraz czynności.

Komunikacja

Efektywna komunikacja jest kluczowa zarówno na poziomie procesowym, jak i zespołowym. Jeśli definicja procesu jest zbyt ogólna, zespoły wdrożeniowe nie są w stanie przewidzieć skutków problemów pojawiających się w ich obszarach. Błędnie zaprojektowane rozwiązania mogą prowadzić do zatorów lub nawet „wykolejenia” całego systemu.

Jeśli dane nie są prawidłowo przetwarzane na jednym etapie, mogą wpłynąć na wszystkie kolejne etapy wdrożenia. Koszty naprawy błędów są wysokie, dlatego kluczowe jest przeprowadzanie dokładnych testów międzyobszarowych jeszcze przed uruchomieniem systemu.

Jeśli zbyt powierzchownie zdefiniujemy proces, wówczas nie jesteśmy w stanie ostrzec członków zespołu o skutkach problemów pojawiających się w naszym obszarze. Zła definicja procesu to również błędna interpretacja otrzymanej informacji od innych członków zespołu. Jeśli nie będę świadomy wpływu swojej pracy na pracę innych, może to produkcyjnie wstrzymać cały proces. Metro między moimi stacjami będzie jeździć szybko i sprawnie, ponieważ zaprojektowałem „nowoczesne i unikatowe” szyny.  O ile słowo „nowoczesne” na pierwszy rzut oka nie stanowi zagrożenia, to słowo „unikatowe” powoduje olbrzymie zagrożenie. Jeśli będziemy kierować się tylko swoim elementem procesu, a nie całym procesem, to możemy spowodować zatrzymanie procesu lub doprowadzić do wykolejenia całego składu. W tym drugim, bardziej drastycznym przypadku, będziemy musieli użyć kosztownych narzędzi naprawczych. W systemach mamy do czynienia z milionami przemieszczających się danych w ciągu minuty. Wykolejenie składu pociągu na pewnym odcinku trasy poprzez błędne zaprojektowanie zbyt wąskiego lub zbyt szerokiego rozstawu szyn spowoduje wstrzymanie całej linii, kilku linii lub w skrajnych przypadkach całego metra. Pamiętajmy, że jeśli w systemie pojawią się błędy, to mamy do czynienia z dwoma elementami: udrożnieniem procesów oraz naprawą danych. Koszt w przypadku naprawy danych jest znaczący, mając na uwadze zatrudnienie specjalisty lub zespołu znającego topologię wdrożonego systemu.

Jeśli chcemy uniknąć przytoczonych błędów, zachęcam do organizowania testów międzyobszarowych podczas oddawania funkcjonalności. Jeśli implementujemy w systemie nowe rozwiązanie, to zweryfikujmy w całym procesie niezmienność jego wpływu na dane oraz funkcjonowanie pozostałych obszarów tego samego procesu. Testy międzyobszarowe to element gwarantujący sukces wdrożenia. Nie wyobrażam sobie braku tej pozycji w harmonogramie wdrożenia. Testy wszystkich procesów, a więc wszystkich linii naszego metra powinny być wykonane zarówno przez firmę wdrażającą, jak również przez odbierającego usługę. Przejedźmy się każdą linią metra, wyjdźmy na każdej stacji, wykonajmy wszystkie czynności, a następnie wsiądźmy do pociągu w kierunku kolejnej stacji. Jeśli nasz środek lokomocji zawiezie nas do końcowej stacji, to możemy mówić o poprawnym działaniu całego procesu. Spójrzmy później na dane kontrolingowe, czyli dokonajmy analizy czasu przejazdu naszego pociągu od punktu stacji „A” do stacji końcowej „Z”. Dokonajmy analizy szczegółowej poszczególnych elementów, czynności w obrębie każdej linii metra. Jeśli wyniki nie są optymalne, dokonajmy korekt, a następnie znów udajmy się w kolejną podróż od stacji do stacji. Jeśli w tym miejscu będziemy zadowoleni z warunków podróży i będziemy osiągać określone w projekcie metra cele, wówczas możemy śmiało mówić o dacie startu produkcyjnego.

Czy każda firma wdrożeniowa i każdy odbiorca usługi wykonuje testy międzyobszarowe?

Niestety nie. Powiem więcej, ten punkt nawet nie jest zapisywany w ofercie oraz harmonogramie, ponieważ podnosi w sposób znaczący czasochłonność zaangażowania obu stron, co przekłada się na koszt wdrożenia. Firmy z reguły przenoszą ten punkt na moment startu produkcyjnego, testując proces w stanie podniesionej adrenaliny.

Metro

Czy najważniejszą osobą podczas budowy metra jest Project Manager?

Nie. Jego zadaniem jest zarządzanie harmonogramem i organizacja pracy. Project Manager neutralizuje wszystkie problemy wpływające na harmonogram projektu. Jeśli na danej linii brakuje materiałów lub osób, to jego zadaniem jest wypełnienie zasygnalizowanych braków. Project Manager ściśle współpracuje z projektantem, czyli architektem budowy całego metra. Architekt ma wszechstronną wiedzę merytoryczną, a do jego zadań należy opracowywanie projektów obiektów nowych i projektów przebudowy, modernizacji i adaptacji. Musi też sprawować kontrolę nad realizacją projektów. Bez jego akceptacji nie powinno dojść do przejścia do kolejnej fazy budowy. On jest osobą merytoryczną i sprawuje rolę translatora obrazu oraz stanu budowy do PM-a.

W procesie wdrożenia systemu IT taką rolę pełni Solution Architect, który jest jego najważniejszą postacią. Solution Architect posiada wiedzę na temat całego systemu – od finansów, przez logistykę, po produkcję i usługi. Jego zadaniem jest zapewnienie spójności wdrożenia i nadzór nad zgodnością rozwiązania z założeniami projektu. W fazie wdrożenia musi on czuwać nad jakością implementacji i eliminować potencjalne problemy zanim wpłyną one na cały proces. Zawsze warto upewnić się, że w zespole wdrożeniowym jest Solution Architect, który będzie miał pełną dostępność i odpowiednie kompetencje.

Podczas prezentacji prototypu Solution Architect kreśli wizję budowy określonej liczby linii metra, optymalnej do panujących warunków liczby stacji oraz węzłów przesiadkowych. Prezentuje sposób poruszania się pasażerów od bramki wejściowej do metra, poprzez przemieszczanie się po stacjach, wspomnianych węzłach przesiadkowych, kończąc na bramkach wyjściowych. W fazie drugiej, czyli fazie wykonania i implementacji, odpowiada za urzeczywistnienie tego przedstawionego projektu. To on indywidualnie 24 godziny przez 7 dni w tygodniu czuwa nad spójnością procesów. Bez niego nie powinno nastąpić żadne odstępstwo od planu. Jednym z jego zadań jest merytoryczny komentarz do Project Managera na podstawie informacji pozyskanych od osób pracujących w projekcie oraz stanu faktycznego. Do niego należy odseparowywanie nieistotnych informacji od kluczowych dla harmonogramu wdrożenia. Mówiąc kolokwialnie, jest ochraniarzem, zabezpiecza merytorycznie kierownika projektu przed popełnieniem błędnych decyzji w kontekście projektu. Zawsze zwróćcie uwagę, czy podczas przedstawiania zespołu wdrożeniowego zostaje wymieniony Solution Architect.

Drugim ważnym elementem, który uchroni przed turbulencjami w projekcie, jest zweryfikowanie dostępności Solution Architekta oraz jego kompetencji. Firmy często mylą tę rolę z liderami obszarowymi, co prowadzi do braku kompleksowego spojrzenia na cały system. Zbyt mała wiedza w tym zakresie powoduje, że patrzymy na poszczególne elementy, a nie na całe procesy. Budujemy stacje, odcinki linii metra, a nie całe linie metra. Solution Architekci w firmach są dobrze wynagradzani, dlatego często firmy wykorzystują takie osoby do uczestniczenia w kilku projektach jednocześnie. Niektóre firmy nawet przekraczają te granice i dostarczają dodatkowych emocji w czynnościach sprzedażowych, dodając rolę Pre-Sales. Obowiązki komunikacji z kierownikami budowy poszczególnych odcinków i linii metra przejmuje wówczas kierownik projektu. Mamy więc problem, bo Project Manager nie jest osobą merytoryczną. Jeśli zespół nie ma kontrolera merytorycznego, wówczas przekazuje informacje niespójne z rzeczywistością, co prowadzi do zwiększenia kosztów i zmian w harmonogramie. Możemy zastanowić się, czy osoba budująca jednocześnie metro w Londynie, Paryżu, Pradze oraz dodatkowo pracująca nad sprzedażą nowego metra w Krakowie, jest dla nas gwarantem jakości.

Rozkład jazdy

Przed uruchomieniem metra konieczne jest ustalenie optymalnego planu jazdy. W projektach IT tym zadaniem zajmuje się Technical Architect, który współpracuje z Solution Architektem, programistami i kierownikami projektu. Technical Architect odpowiada za techniczną implementację systemu i optymalizację kodu. Jego błędy mogą prowadzić do wydłużenia testów, zwiększenia kosztów oraz przesunięcia startu produkcyjnego. Dlatego istotne jest, aby w fazie wdrożeniowej zapewnić jego pełną dostępność i nadzór nad wdrożeniem.

Zadbajmy, aby w fazie implementacji systemu i przygotowania organizacji do startu produkcyjnego mieć pełną kontrolę nad jakością wdrożenia i stabilnością zespołu projektowego. Dzięki temu unikniemy problemów i zagwarantujemy sukces całego przedsięwzięcia.

Niestety podobne błędy są popełniane w projektach w stosunku do Technical Architekta, jak wcześniej pisałem w przypadku Solution Architekta. Dobrze wynagradzani Technical Architekci również są delegowani w tym samym czasie do różnych projektów, przez co kontrola techniczna poszczególnych odcinków budowy jest niedopełniona. Nieoptymalny lub błędny kod programistyczny powoduje zwiększenie nakładów na testy i ponowne poprawki. Niestety znów muszę napisać, że zaistniały fakt powoduje podniesienie wartości budżetu na uruchomienie przedsięwzięcia, czy nawet przesunięcie startu produkcyjnego. Zadbajmy, by w fazie drugiej implementacji zmian, przygotowania systemu i organizacji startu produkcyjnego mieć 100% dostęp do Solution Architekta oraz Technical Architekta z kompetencjami związanymi z piastowanymi stanowiskami.

O tym, jak możemy uniknąć błędów podczas startu produkcyjnego systemu, opowiem w piątej części cyklu „6 kroków od świadomości do sukcesu wdrożeniowego. Krok 5 – Start Produkcyjny”.

--

Poniżej udostępniamy ten artykuł w formie dźwiękowej - czyta AI głosem Dariusza i za jego zgodą.

‍