Posłuchaj odcinka:
Spotify: kliknij tutaj.
YouTube: kliknij tutaj.
Przeczytaj artykuł: kliknij tutaj.
Transkrypcja odcinka 8: „Błędne oczekiwania, które psują wdrożenia ERP”.
Dbanie o to, żeby oczekiwania były konkretne, zamknięte, a nie otwarte, jest bardzo zasadne i służy temu, żeby projekt skończył się w zaplanowanym czasie i w przewidywanym na początku zakresie.
Dzień dobry. Druga część podsumowania koncentrować się będzie wokół działań lub przeświadczeń, które nie są rozsądne i w praktyce się nie sprawdzają i raczej są źródłem problemów i nieefektywności na projekcie, a nie pomagają nam w jego realizacji w sposób płynny i dążący do sukcesu.
Nieracjonalne oczekiwania w projektach ERP
Pierwszym takim bardzo częstym problemem czy zagadnieniem jest kwestia nieracjonalnych oczekiwań. Absolutnie nieracjonalnych oczekiwań, które jak się na chłodno je przeanalizuje, są po prostu nie do realizacji.
Takim jednym z sztandarowych przykładów jest wpisanie oczekiwań do zapytania ofertowego punktu mówiącego, że system ma być niezależnie od wszystkiego gotowy w stu procentach na to, żeby obsługiwać wymagania prawne w momencie uruchomienia systemu.
Brzmi to bardzo dobrze. Wydaje się, że zabezpiecza firmy / organizacje, która wdraża system. Natomiast jak to w praktyce wygląda? Jeżeli budujemy sześć, dziewięć czy osiemnaście miesięcy system, robimy analizę, budujemy parametryzację, przygotowujemy rozszerzenia, potem je testujemy, poprawiamy, integrujemy i z jakiegoś niepojętego powodu na miesiąc przed uruchomieniem prawodawca zmienia wymogi prawne, wprowadza nowy podatek, wprowadza nową regulację wymagającą jakichś działań po stronie systemu, to nie ma możliwości, żeby z jednej strony dotrzymać terminu uruchomienia, a z drugiej strony zaaplikować to rozwiązanie w systemie.
I jest zrozumiałe, że organizacja jako taka powinna być w stanie ten wymóg prawny obsłużyć. Natomiast być może na początek przy pomocy procedur ręcznych, przy pomocy jakiegoś wsparcia poza systemowego. Jeśli mamy sytuację, w której mamy system gotowy i musimy do niego wprowadzić istotne dwie, trzy czy cztery zmiany, to po prostu nie da się tego zrealizować. Nie da się tego zrealizować w sposób bezpieczny, w sposób planowy, w sposób racjonalny.
Otwarty zakres wymagań, czyli co?
Inna rzecz, inny zapis, inny przykład – to jest też często, na szczęście coraz rzadziej, ale jednak nadal spotykany zapis mówiący, że poniżej jest lista raportów lub lista magazynowa, lub lista środków trwałych, które mają zostać uwzględnione w systemie. I na końcu jest mały dopisek i wszystkie inne pozostałe, które się gdzieś po drodze uda zidentyfikować.
Jest to zapis, który de facto otwiera zakres, czyli w każdym momencie każdy członek zespołu projektowego po stronie klienta może sobie coś przypomnieć i oczekiwać, że jego postulat zostanie zrealizowany. Też wygląda to bardzo dobrze. Zdejmuje to odpowiedzialność członków zespołu po stronie klienta, natomiast nie dążymy do tego, żeby było bardzo dużo swobody w podejściu do wdrożenia. Chcielibyśmy ten proces uporządkować i żeby czas analizy się zaczął i żeby ten czas analizy się skończył. Potem, żeby był czas budowy. Potem, żeby były testy, a potem uruchomienie. Oczywiście zdarzają się przypadki, kiedy z różnych powodów, po zakończeniu analizy pojawia się nowa potrzeba. Mówiłem o tym w części związanej z wdrożeniem. Natomiast jeśli taka potrzeba się pojawia, to jest to impuls do dyskusji o tym, jak sobie z tą potrzebą poradzić. Czyli obie strony, zarówno wykonawca, jak i firma, która będzie ten system wykorzystywała, muszą się wspólnie zastanowić nad tym, co z tą potrzebą zrobić i jeśli ona jest niezbędna do uwzględnienia, jeśli ona wymaga niezależnie od wszystkiego, żeby zostać uwzględniona, to wtedy należy sobie powiedzieć – trudno, nie ten termin wdrożenia. Musimy to zmienić albo musimy przez jakiś czas funkcjonować z rozwiązaniem tymczasowym, albo niestety skutki są takie i oddalenie się korzyści z wdrożenia są na tyle długie, że na razie musimy z takiego wymagania zrezygnować. Więc dla porządku, dla tego, żeby terminy i zakres prac był pod kontrolą, to dbanie o to, żeby oczekiwania były konkretne, zamknięte, a nie otwarte, jest bardzo zasadne i służy temu, żeby projekt skończył się w zaplanowanym czasie i w przewidywanym na początku zakresie. Jeśli ten zakres musi być zmieniony, to wspólnie należy podjąć decyzję, co z tego wynika i od strony budżetowej, i od strony harmonogramowej. Być może któryś z innych obszarów w systemie może zostać trochę przesunięty w czasie i dzięki temu da się zaoszczędzić możliwości czasowe i finansowe, żeby te nowe potrzeby obsłużyć. Natomiast nie powinno to być tak, że bezrefleksyjnie dajemy sobie szansę na nieskończone poszerzanie zakresu, wydłużanie zadań, zmienianie oczekiwań.
Priorytetyzacja potrzeb wdrożeniowych
Jeżeli już rozmawiamy o wymaganiach i potrzebach, to warto jest też pamiętać, że nie jest racjonalnym oczekiwanie i weryfikowanie czy bazowanie w ogóle w podejściu wdrożeniowym, już nawet nie mówię o wyborze systemu, ale już nawet w trakcie samego wdrożenia, badanie zgodności nieskończonej ilości wymagań pod kątem tego, czy one spełniają nasze potrzeby. Tak jak opowiadałem w odcinku związanym z wyborem systemu, jestem zwolennikiem koncentrowania się – i to się sprawdza w praktyce – na głównych, wybranych, niezbędnych potrzebach organizacji. I to nie może być tak, że tych głównych potrzeb jest tysiąc pięćset czy tysiąc sześćset. Tych głównych potrzeb powinno być dziesięć, piętnaście i całą resztę powinniśmy jako organizacja wdrażająca system być gotowi przyjąć trochę, być może w formie nieidealnych dla nas, ale jednak umożliwiającej funkcjonowanie, realizację codziennych procesów i dzięki temu pozwala to na szybsze zamknięcie projektu wdrożeniowego, szybsze dojście do końca, szybsze zapoznanie się z tym, jak system funkcjonuje, szybsze wystabilizowanie tego systemu, a potem tak jak mówiłem, system będziemy wykorzystywali przez co najmniej osiem, dziesięć lat, więc będzie czas na to, żeby te pozostałe dziesiątki czy setki wymagań doprecyzowywać, dostosowywać i ulepszać, żeby była ona jeszcze bardziej ergonomiczna dla nas niż to było na początku.
Nadmiernie krytyczne wymagania i ryzyka projektowe
Pochodną tego zagadnienia jest też podejście, w którym czy to na etapie wyboru systemu, czy potem na etapie analizy, czy potem na etapie już budowy systemu mamy sytuację, w której z tysiąca wymagań dziewięćset dziewięćdziesiąt pięć jest krytycznych. Nie da się z niczego zrezygnować. Wszystko jest najważniejsze, wszystko musi być na pierwszy dzień uruchomienia systemu. Wszystko musi być w docelowej formie. Ja rozumiem, że wynika to z tego, że organizacja, która wdraża sobie system, nie jest przyzwyczajona do tego, żeby… To nie jest jej główna funkcja. Przeważnie są to firmy zajmujące się produkcją czy handlem, czy są to organizacje typu ministerstwo czy firma energetyczna. I one nie funkcjonują wokół systemu wdrażania systemów informatycznych, tylko mają swój biznes, swoje procesy, swoje potrzeby. Więc podejście takie, w którym zbudowana jest po stronie zespołu wdrażającego świadomość, że budowa systemu to jest proces ciągły, nie jest powszechne i trzeba nad tym popracować. Natomiast trudno mi sobie wyobrazić sytuację, w której nie uda się przekonać jednak zespołu po stronie klienta, że nie może być tak, że dziewięćdziesiąt dziewięć procent jego oczekiwań jest krytycznych. Któreś z założenia muszą być bardziej krytyczne i o nie powinniśmy zadbać.
Jeśli mamy sytuację taką, że od początku widać, że system będzie wdrażany bez żadnych odstępstw, bez żadnego dania sobie swobody wyboru, bez dawania sobie swobody uruchomienia, to zwiększa to znacząco ryzyko projektowe, zwiększa wysiłek, który my zakładamy jako firma wdrożeniowa, że będzie musiało być włożone. Bo trudno sobie też wyobrazić, że osoba nieznająca systemu w ciągu pierwszych dwóch, trzech tygodni analizy będzie w stanie sobie wymyśleć, wyobrazić docelowe funkcjonowanie przy pomocy nowego narzędzia. Jeśli mamy świadomość tego, że nie możemy liczyć na żadne odstępstwa w trakcie prac wdrożeniowych, to to też znakomicie podnosi koszt całego przedsięwzięcia. Często w sposób nieracjonalny i nieuzasadniony tak naprawdę, ponieważ potem się okazuje, że system co prawda nie działa tak, jak kiedyś działaliśmy, ale spełnia nasze oczekiwania tylko w trochę inny sposób. Tylko musimy sobie dać szansę, żeby doczekać, żeby to użyć i żeby się przekonać, że rzeczywiście tak jest.
Doradca a projekt ERP
Ostatni punkt, który już też omawiałem, to jest podejście do wykorzystania, do współpracy, do zaangażowania w projekcie doradcy. Spotykamy takich klientów, którzy wychodzą z założenia, że nie wiemy, jak się robi projekty informatyczne – to weźmy doradcę. I tak jak mówiłem w odcinku poświęconym doradcy, samemu czasami występuję w funkcji doradcy. Sam czasami doradzam organizacjom, jak podejść do wdrożeń, jak podejść do budowania strategii informatyzacji. Natomiast zawsze wychodzę z założenia, że doradca powinien przekazać swoją wiedzę, pomóc zrozumieć, przedstawić argumenty za, argumenty przeciw, przekonać do być może zmian organizacyjnych, wyjaśnić silne i słabe strony tego czy innego podejścia, tego czy innego rozwiązania. Natomiast nie powinno się cedować na niego decyzji. Nie powinno się powierzać jemu wiodących roli / wiodących funkcji w projekcie.
Na przykład, jeżeli rekrutujemy szefa projektu ze strony doradcy, to on bardzo często nie ma ani autorytetu wewnątrz organizacji, ani tak dogłębnie tej organizacji nie zna. Nie do końca czuje, nie do końca identyfikuje się z celami, z założeniami przyjętymi dla tego projektu. Jeżeli ma być to osoba, która w pełni reprezentuje organizację, to świetnie by było, gdyby ona pochodziła z wewnątrz organizacji, żeby się z nią całkowicie identyfikowała.
Różnica między zatrudnieniem doradcy na kontrakt a zatrudnieniem takiej osoby do ośrodka organizacji nie jest wielka i jeśli wiemy, że przygotowujemy się do projektu, warto jest rozpocząć rekrutację, poszukać taką osobę na rynku, dać jej czas na zapoznanie się ze specyfiką procesów, ze specyfiką organizacji, z kulturą organizacji, z zespołem. Dać sobie czas na zweryfikowanie podejścia tej osoby do realizacji zadań, jej zaangażowania, jej pomysłów i potem już korzystając z niej na projekcie, mieć ją jako członka zespołu wewnętrznego.
Podsumowując, doradcy są bardzo przydatni, ale do pozyskiwania wiedzy i uważam, że angażowanie ich w sam proces, w sam projekt i powierzanie im zadań realizacyjnych, a nie daj Boże jeszcze decyzji, to nie jest dobre rozwiązanie, chociaż czasami oczywiście się sprawdza i czasami można było znaleźć dowód na to, że nie musi to być zły pomysł i czasami jest to lepsze niż realizowanie projektu przy pomocy osób, które zupełnie nie mają pojęcia, jak takie przedsięwzięcia się realizuje. Natomiast jest to raczej wyjątek niż reguła.
Podsumowanie
I to chyba wszystko, jeśli chodzi o tą część. Dziękuję. Jeśli bylibyście zainteresowani zadaniem pytań lub ewentualnie rozszerzeniem któregokolwiek z punktów dzisiejszej prezentacji, to bardzo proszę o kontakt. Wszystkie dane kontaktowe są w opisie odcinka. Dziękuję.
W następnym odcinku…
W kolejnym, ostatnim odcinku tej serii odkryjemy te elementy wdrożeń ERP, o których wszyscy wiedzą, ale o których wszyscy zapominają w kluczowych momentach.
Dlaczego osiemdziesiąt procent projektów informatycznych wykracza poza budżet i harmonogram? Dlaczego to, co wydaje się być dwudziestoma dniami pracy, kończy się trzema miesiącami dodatkowego wysiłku i dlaczego najsłabszy kierownik projektu z firmy wdrożeniowej wciąż może być cenniejszy niż Twój najbardziej doświadczony wewnętrzny ekspert Poznasz prawdę o tym, że budowa systemu to zaledwie wierzchołek góry lodowej. Dowiesz się, dlaczego Twój zespół może być obciążony w osiemdziesięciu procentach czasu pracy i jak tego uniknąć, a także dlaczego zmiany w projekcie to nie wyjątek, lecz reguła, którą można przewidzieć i wykorzystać na swoją korzyść.
To będzie odcinek o rzeczach oczywistych, które przestają być oczywiste, gdy zaczynasz je stosować w praktyce.
Jak zawsze tydzień po publikacji odcinka na naszym blogu pojawi się artykuł z podsumowaniem najważniejszych punktów. Link do niego znajdziecie w opisie odcinka. Tam też umieścimy adres email: podcast@dahliamatic.pl. Jeśli macie pytania lub chcecie podzielić się swoimi doświadczeniami, śmiało piszcie.
Do usłyszenia w ostatnim odcinku serii!
________________________________________________________________________________________________
Nie zapomnij też odsłuchać poprzedniego odcinka, jeśli jeszcze tego nie zrobiłeś.
Odcinek 7, „Dobre intencje, złe decyzje – o źródłach błędów w projektach ERP”:
Spotify: kliknij tutaj.
YouTube: kliknij tutaj.
Artykuł: kliknij tutaj.
Transkrypt: kliknij tutaj.
>