Posłuchaj odcinka:
Spotify: kliknij tutaj.
YouTube: kliknij tutaj.
Przeczytaj artykuł: kliknij tutaj.
Transkrypcja odcinka 7: „Dobre intencje, złe decyzje – o źródłach błędów w projektach ERP”.
Kolejnym takim mitem, z którym warto się zmierzyć, to jest podejście, w którym mamy nadzieję, czy klient ma nadzieję, organizacja wdrażająca ma nadzieję, że jeżeli uzgodni z dostawcą budżet całościowy przedsięwzięcia, to od strony finansowej ma wszystko pod
kontrolą.
Witam. Dzisiejsza część będzie miała troszeczkę inny charakter niż pozostałe. Nie będzie odnosić się do jakichś konkretnych tematów, zagadnień, natomiast będzie poruszać trzy grupy krótkich spostrzeżeń, sugestii, propozycji.
Pierwsza z nich będzie mówiła o tym, że wokół projektów informatycznych, wokół projektów wdrożeń systemów finansowo-księgowych w szczególności, ale nie tylko, krąży kilka mitów, z którymi warto byłoby się może nie rozprawić, ale co najmniej spojrzeć na nie i pomyśleć, czy one są prawdziwe.
Drugą częścią będzie kilka punktów, kilka sugestii, kilka takich pomysłów, o których warto pamiętać, a rzadko do nich wracamy. Rzadko bierzemy je pod uwagę w procesie zarówno wymyślania samej koncepcji procesów wdrożeniowych, jak również w trakcie procesów doborowych dostawcy czy rozwiązania, jak i w ciągu całego cyklu prac projektowych.
Ostatnia część koncentrować się będzie na kilku aspektach, które. jak praktyka pokazuje, nie mają sensu zbyt wielkiego. Natomiast często gdzieś spotykamy się z nimi w trakcie zarówno rozmów, jak i przygotowań, jak i procesów negocjacyjnych czy potem w trakcie realizacji projektów. Nie jest to rozsądne, ale często jest to oczekiwanie, które jest artykułowane przez firmy czy organizacje, które są zaangażowane w projekty.
Ta konkretna część dotyczy mitów. Będzie ich sześć. Kilka z nich omówię w sposób bardziej rozwinięty. Dwa ostatnie będą dość krótkie.
Jesteśmy wyjątkowi, więc nasz system ERP też taki musi być
Wracając do mitów. Jednym z najczęściej spotykanych mitów, z którymi osobiście miałem przyjemność się spotkać już od dwudziestu paru lat to jest takie podejście, że my jako firma, czy my jako organizacja, jesteśmy unikalni i dlatego musimy mieć wszystko specjalnie dla nas uszyte, przygotowane pod nas.
W kontrze do tego można powiedzieć, że systemy, które są oferowane, te takie najbardziej popularne są wykorzystywane w kilkunastu tysiącach organizacji, dziesięć tysięcy organizacji plus. I są budowane w oparciu o doświadczenia z tych wdrożeń. Więc można byłoby przyjąć, można byłoby mieć nadzieję, że co najmniej w istotnym stopniu wszelkie procesy, które są realizowane w typowych organizacjach, czy to przemysłowych, czy handlowych, czy jakichkolwiek innych, mają swoje odzwierciedlenie w tych systemach. Oczywiście są pewne obszary, czy to sprzedaż może być takim obszarem, czy jakieś bardzo specyficzne procesy związane z certyfikacjami, czy chociażby kwestia związana z wymogami prawnymi wynikającymi ze specyfiki rynku.
I tu oczywiście jest ta pewna unikalność, ale też bez przesady. VAT w Europie jest podobnie naliczany, więc można mieć nadzieję, że te same narzędzia będą w jakiś sposób mogły być wykorzystane zarówno we Francji, w Mołdawii i w Polsce. Natomiast spora część systemu może dość podobnie funkcjonować w większości organizacji.
Kolejnym elementem, który daje nam taki sygnał do przemyśleń w tym kierunku, jest fakt, że coraz większa część dostawców oferuje swoje rozwiązania w wersji chmurowej, które z natury rzeczy są wspólne dla wszystkich użytkowników. Wszelkie modyfikacje, wszelkie doróbki, wszelkie specyfiki są niejako dodatkiem do centralnego rozwiązania, które funkcjonuje i w założeniu swoim jest wspólne dla wszystkich klientów. Więc jeśli świat informatyczny, świat systemów finansowo-księgowych, świat systemów wspierających tak zwany back office idzie w kierunku chmurowym, oznacza to, że prawdopodobnie daje się sporą część tych potrzeb uwspólnić. Oczywiście, wymaga to zmian po stronie organizacji. Wymaga to jakichś dostosowań. Wymaga to zmiany dzisiejszych procedur czy dzisiejszego sposobu funkcjonowania. Natomiast czy to jest złe, czy dobre? Wydaje się, że co najmniej warto to rozważyć i wziąć to pod uwagę.
Osobiście też doświadczyłem kilku wdrożeń, w których podstawowym założeniem nie tylko wstępnie deklarowanym, ale dotrzymanym do samego końca, było wdrożenie systemu z paczki. Czyli po prostu bez jakichkolwiek modyfikacji. Pomijam tutaj w ogóle lata dziewięćdziesiąte, kiedy systemy standardowe, takie nowoczesne, wchodziły do Polski. Gdzie spora część z nich w ogóle nie dopuszczała modyfikacji i tam wszelkie wdrożenia były wdrożeniami standardowymi. I jeżeli system w paczce nie miał danej funkcjonalności, to po prostu trzeba było w jakiś inny sposób sobie tą funkcjonalność zapewnić.
Natomiast mówię tutaj o systemach już tych bardziej rozbudowanych, dających możliwości modyfikacyjne. I doświadczyłem kilku wdrożeń, gdzie klienci na koniec projektu w skomplikowanych organizacjach wielozakładowych, produkcyjnych, sprzedażowych, byli w stanie, zakończyć projekt albo z zerową ilością modyfikacji, albo z minimalną typu jedna, dwie modyfikacje, jakieś bardzo szczegółowe.
W ogóle doświadczałem też wdrożenia, w którym system stanowił wytyczną dla organizacji, jak budować swoje procesy wewnętrzne. Czyli nie dostosowywaliśmy systemu do procesów, tylko na bazie systemu były tworzone wewnętrzne procesy. Dało się wdrożyć naprawdę skomplikowany system minimalnym zespołem w bardzo krótkim czasie i system ten był stabilny. Nie było modyfikacji, nie było niczego, co mogłoby zakłócać jego działanie w takim wymiarze stabilizacji technicznej.
Raz uzgodniony budżet wdrożenia ERP nie ulega zmianie
Kolejnym takim mitem, z którym warto się zmierzyć, to jest podejście, w którym, mamy nadzieję, czy klient ma nadzieję, organizacja wdrażająca ma nadzieję, że jeżeli uzgodni z dostawcą budżet całościowy przedsięwzięcia, to od strony finansowej ma wszystko pod kontrolą. I to jest absolutnie nieprawda. Dlatego, że mamy do czynienia z procesami wdrożeniowymi, które po pierwsze trwają co najmniej kilka, a często kilkanaście, żeby nie powiedzieć kilkadziesiąt miesięcy. Nie jesteśmy w stanie oszacować wszelkich zmian, wszelkich potrzeb, wszelkich modyfikacji, które zostaną wymuszone z zewnątrz na tak długi okres czasu. Tak samo nieskończenie długo musiałaby trwać analiza wstępna, sprecyzowanie zakresu, precyzowanie potrzeb, precyzowanie oczekiwań. Musielibyśmy uwzględnić wszelkie zmiany wynikające z tego, że część załogi odchodzi, część uczestników zespołu projektowego się zmienia po stronie klienta. Jest to nie do opanowania.
Więc jeżeli w wyniku warunków stawianych przez klienta mamy dojść do uzgodnionego harmonogramu sztywnego, jeszcze nie daj Boże bardzo srodze okorowanego i stałego budżetu, to po stronie dostawcy rodzi się naturalny odruch, w którym będą zakładane do tego budżetu i do tego harmonogramu gigantyczne rezerwy. Taki musi być odruch obronny, jeżeli nie zostaną spełnione te warunki, o których mówiłem na początku, czyli precyzyjny zakres, precyzyjne oczekiwania, stałość przepisów, stałość rynku, stałość zespołu projektowego. Co jest po prostu fikcją.
Całkiem niedawno miało miejsce postępowanie, w którym oferenci jedną trzecią budżetu, a był to budżet sto kilkadziesiąt milionów złotych, jedna trzecia budżetu w ofertach była przeznaczona z założenia na kary i rezerwy wynikające z niejasności, zakresu nierealności harmonogramu, no i wymogu stałej ceny. Czyli wartość wdrożenia była sto dwadzieścia milionów, a oferta była na sto osiemdziesiąt, ponieważ z założenia wszyscy oferenci przyjmowali, że około sześćdziesięciu milionów muszą przeznaczyć na kary i rezerwy.
Nie wiem, czy to jest rozsądne. Wydaje się być mało rozsądne. Jeśli ktoś taką taktykę chce stosować, proszę bardzo. Ja uważam, że lepiej jest przyjąć ramowy budżet, bardziej precyzyjnie monitorować postęp prac, zarządzać oczekiwaniami i starać się zrealizować cel postawiony na początku i uzyskać korzyści, o których myśleliśmy uruchamiając projekt. A nie kupować złudny spokój poprzez stwierdzenie, że budżet wdrożenia wynosi X, a harmonogram ma się skończyć pierwszego stycznia. To jest złudne i bardzo często się nie sprawdza. Osiemdziesiąt procent projektów informatycznych kończy się poza budżetem i poza terminem wstępnie założonym, więc też statystyka wskazuje, że takie podejście jest po prostu jakby to powiedzieć mało realistyczne.
Firma wdrażająca jest właścicielem projektu wdrożeniowego ERP
Kolejnym mitem czy takim błędnym spojrzeniem, które chciałbym tutaj pokazać i zwrócić na niego uwagę, to jest podejście, zresztą mówiłem o tym w trakcie spotkań, kiedy opowiadałem o przygotowaniu się do projektów i określaniu celu projektu. Taki błąd w podejściu to jest logika, w której klient patrzy na przedsięwzięcie tak, jakby właścicielem przedsięwzięcia była firma wdrażająca.
To nie dostawca robi projekt. To jest projekt firmy lub organizacji, która go wdraża. Dostawca jest niejako siłą pomagającą w zrealizowaniu tego zadania. Bez zaangażowania się zespołu, decydentów, kluczowych użytkowników, którzy wiedzą, rozumieją, po co ten projekt robią i co chcą na koniec uzyskać przeprowadzenie go w sposób efektywny dający korzyści pierwotnie założone, jest niemożliwe.
Nie ma znaczenia, jak bardzo świetny, doświadczony i zaangażowany byłby zespół wdrażający z zewnątrz. To jest tak, jakby murarz postawił bardzo, bardzo fajnie i sprawnie mur. Natomiast nie we właściwym miejscu, niewłaściwej wysokości i jeszcze niewłaściwej grubości i z niewłaściwych być może cegieł, bo nie dostał dobrych danych, dobrych założeń, dobrego projektu. Mamy świetny mur w niewłaściwym miejscu. Nie jest to przepis na sukces.
Ostatnia wersja systemu ERP jest najlepsza
Kolejny taki punkt, który już trochę jest bardziej techniczny, ale często bardzo istotny, to jest podejście takie, w którym firmy wdrażające oprogramowanie oczekują czy żądają, żeby wdrożona u nich wersja była ostatnią wersją. I argumenty są takie – ostatnia to najlepsza. Jeżeli wdrożymy ostatnią wersję, to później będziemy musieli aktualizować oprogramowanie. No być może tak.
Natomiast z drugiej strony mamy też minusy takiego rozwiązania. Rozwiązania, które funkcjonują na rynku półtora roku, rok czy co najmniej pół roku mają za sobą już choroby wieku dziecięcego. Wszelkie podstawowe niedociągnięcia, błędy, braki zostały już wykryte przez innych klientów na innych wdrożeniach i zostały przez producenta naprawione, usunięte albo przynajmniej zidentyfikowane i mamy ich świadomość.
Także wdrożenie oprogramowania w wersji, nazwijmy to przedostatniej, daje nam gwarancję tego, że poza naszymi wyzwaniami:
- które pojawią się przy testowaniu,
- które pojawią się w pracy operacyjnej,
- wynikającymi z naszych modyfikacji,
- wynikającymi z naszego uczenia się oprogramowania,
- wynikającymi z naszych błędów, gdzieś w obsłudze czy nawet w pomyłkach parametryzacyjnych,
to przynajmniej pozbywamy się problemu błędów w standardzie. A musimy tutaj pamiętać, że usuwanie błędów w standardzie to jest dość dużo bardziej skomplikowane zagadnienie niż usunięcie błędów w jakichś modyfikacjach, które sami robimy. Nasze modyfikacje funkcjonują tu i teraz, w naszym rozwiązaniu. Mamy nad nimi pełną kontrolę, nie muszą być sprawdzane w innych instalacjach.
A w przypadku przygotowywania patcha, to jak producent taką poprawkę przygotuje, to musi ją wytestować pod kątem poprawnego funkcjonowania w kilkunastu tysiącach instalacji. Musi być to włożone w pełen cykl rozwoju produktu, bardzo dobrze przetestowane, zmienione. Także te procesy są dużo bardziej złożone, dużo bardziej skomplikowane i dużo więcej czasu zabierają. I wbrew pozorom przy wdrażaniu nowych wersji oprogramowania często stanowią one wyzwania, ponieważ też zespół wdrażający nie ma doświadczenia z tego typu błędami, bo stare błędy znamy, a nowe sami musimy poznać. Niezależnie od tego, czy mamy dziesięć, pięć czy trzydzieści lat doświadczenia, to jest nowy błąd i pierwszy raz go na oczy widzimy i musimy próbować go jakoś ominąć, zidentyfikować, opisać.
Także warto jest rozważyć oparcie się, szczególnie przy bardziej skomplikowanych wdrożeniach na o wersję co najmniej jedną w tył. W sumie daje nam to pół roku do dziewięciu miesięcy różnicy, jeśli chodzi o wdrażanie kolejnej wersji. Co w zamian za:
- stabilność,
- spokój przy uruchomieniu i wdrożeniu
jest ceną, którą wydaje mi się warto ponieść.
Jedynym wyjątkiem, w którym namawiałbym do użycia najnowszej wersji, to jest sytuacja, w której najnowsza wersja ma istotne wartości funkcjonalne w krytycznych dla nas obszarach. Jeżeli ta najnowsza wersja obsługuje właśnie ten rodzaj biznesu, ten rodzaj sprzedaży, ten rodzaj funkcjonowania gospodarki magazynowej, która jest u nas specyficzna, a w poprzedniej wersji tego nie było i trzeba byłoby robić do tego olbrzymią modyfikację, to tutaj warto jest zaryzykować. Warto jest poczekać na tą najnowszą wersję, użyć tej najnowszej wersji, tylko po prostu ze świadomością jej niedojrzałości wydłużyć procesy testowe, wydłużyć procesy stabilizacji po uruchomieniu i wziąć pod uwagę, że być może część błędów standardowych trzeba będzie naprawiać, że tak powiem, na potrzeby własne lokalnie.
Poznałem już system ERP, więc wdrożymy go samodzielnie
Kolejny punkt to jest podejście, w którym na koniec procesu doborowego, czy to niejako z założenia, bo taki był cichy plan pierwotny, czy w wyniku obserwacji klient dochodzi do tego, że on już tyle wie o systemie, on już tyle wie o tych wszystkich narzędziach, że on sobie ten system wdroży samemu. I to jest bardzo trudna decyzja i bardzo rzadko ona ma sens.
Zdarzają się organizacje, które mają wyspecjalizowane działy, de facto wewnętrzne firmy wdrożeniowe, które niewiele znaczy trochę różnią się od firm rynkowych, które realizują tego typu wdrożenia. Natomiast tam przynajmniej jest pewna powtarzalność, jest pewna ilość wdrożeń, doświadczenie. To są firmy specjalizujące się w tym i są gdzieś tak pomiędzy. Pomiędzy klientem, który samodzielnie chciałby coś zrobić a firmami, które funkcjonują normalnie na rynku i zajmują się tym jako swoją podstawową działalnością.
I moje doświadczenia z wdrożeń wewnętrznych robionych przy okazji niejako są takie, że one są niezwykle długie, niezwykle kosztowne. Trudno jest potem w sposób racjonalny ocenić, czy to, co uzyskaliśmy na koniec, to jest najlepsze, co się dało. Wynika to chociażby z tego, że w większości przypadków tego, jeśli klient postanawia samemu coś wdrożyć, to nie ma takiej bazy porównawczej. Nie ma skąd wziąć doświadczeń z innych wdrożeń, bo robi je to pierwszy raz samemu.
Nawet jeżeli weźmie jedną czy dwie osoby z rynku, co już niejako zaczyna się mieszać, bo skoro bierzemy ludzi z rynku, to weźmy całą organizację, która ma za sobą doświadczenia, ma struktury, ma metodyki, ma ewentualne możliwości zastąpienia jednej osoby drugą. Ma możliwości zwiększenia zespołu w razie potrzeby, ma dużo większą elastyczność. No to może zróbmy to razem z jakąś organizacją, która może nas całościowo wesprzeć.
Podsumowując, wdrożenia jednostkowe, wdrożenia samodzielne przez firmy lub organizacje, z którymi miałem do czynienia – jeżeli te organizacje nie miały dedykowanych działów, które by się zajmowały tego typu przedsięwzięciami już kilkukrotnie, to zawsze się przeciągały, zawsze pochłaniały więcej środków niż to początkowo planowano i to znacząco więcej tych środków. I na koniec często wychodziły wdrożenia, które daleko odbiegały od standardu, od typowego modelu, który się stosuje w tego typu przedsięwzięciach. I często te rozwiązania, które były wynikiem takiego wdrożenia, były bardzo dziwne, bardzo nietypowe.
Im więcej kar w umowie, tym lepiej
I ostatni punkt, który poniekąd wiąże się z punktem związanym z budżetem całościowym. I trochę już mówiłem o tym, jakie są skutki czasami takiego podejścia. To jest podejście, w którym klient zakłada, że im więcej kar narzuci na dostawcę, tym lepiej.
Dlaczego to nie jest najrozsądniejsze rozwiązanie? Kilka jest powodów. Pierwszy z nich jest taki, że racjonalnie myśląca organizacja skalkuluje te kary i włoży je sobie w budżet. Jeżeli stawiamy mało realistyczny termin i obkładamy go karami, to rozsądny wykonawca wie o tym. Przewidzi to i uwzględni w budżecie.
Punkt drugi – takie podejście, szczególnie jeśli w domniemaniu za wszelkie opóźnienia, za wszelkie uchybienia odpowiada dostawca powoduje, że dostawca od pierwszego dnia projektu usztywnia się. Nie chce dodatkowych spotkań. Jeśli uzgodniliśmy dwa dodatkowe spotkania, to nie będzie dodatkowych spotkań. Jeśli czas akceptacji dokumentu to jest pięć dni, to nie będzie żadnych szansy na przedłużenie tego, ponieważ rygor kar, które gdzieś wiszą nad dostawcą, będzie powodował, że nie ma na to przestrzeni. A często w projekcie jest tak, że warto byłoby spędzić jeszcze tydzień i ten model, czy planistyczny, czy kosztowy, czy sprzedażowy przemyśleć i go jeszcze doprecyzować. Natomiast jak, jeżeli jest to obostrzenie takie, to musimy to zatrzymać. Warto jest dotrzymywać harmonogramu. Warto jest się trzymać ram czasowych, ale czasami warto mieć też trochę swobody. To jest druga, druga kwestia.
Trzecia kwestia jest taka, że jeżeli ten mechanizm kar jest źle skonstruowany, to on potem ma fatalne skutki praktyczne w życiu projektowym. Dlaczego? Dlatego, że użytkownicy czy członkowie zespołu projektowego po stronie firmy wdrażającej nie czują większego problemu z opóźnieniami po swojej stronie, ponieważ mają świadomość, że i tak spadnie to na drugą stronę, czyli dostawcę. Dodatkowe prace, które wynikają ze zmian, z opóźnień, z niedociągnięć nie będą musiały być finansowane przez organizację, więc jest dużo większa swoboda w takim niefrasobliwym podejściu do projektu.
Czwarty, ostatni punkt. Wydaje mi się, że najgorsze w gruncie rzeczy to jest to, że jeśli takie są ostre obostrzenia, jeżeli te kary są dotkliwe, jeżeli te terminy są zagrożone, to macie Państwo duże prawdopodobieństwo, że organizacja, która zdecyduje się wziąć ten projekt u was, jest z jakiegoś powodu zdesperowana, żeby tak karkołomne zadanie brać na siebie. Dobre firmy, stabilne firmy, które nie są w jakiejś sytuacji zagrożenia, bardzo często zrezygnują z takiego projektu, nie będą chciały go realizować. I zostaniecie Państwo z firmą, która z jakiegoś powodu jest zdesperowana, żeby ten projekt z wami wziąć. I wcale nie musi być najlepsza.
Miałem do czynienia z takimi sytuacjami, kiedy w bardzo słabo finansowo stojącej firmie ludzie czuli się zagrożeni i zespół realizacyjny podejmował się wykonania projektu po to, żeby stać się niejako niezbędnym elementem w firmie wdrożeniowej. Żeby nikt nie pomyślał o tym, żeby objąć ich zwolnieniami, bo przecież mają projekt jeszcze przez półtora roku i nikt poza nimi tego projektu nie będzie w stanie zrobić. Firma krwawiła, ponosiła straty, ale w imię nieponiesienia jeszcze większych strat wynikających z rozstania się z klientem, z jakichś sankcji sądowych – krwawiła, cierpiała i doprowadzała ten projekt do końca. Raz szczęśliwego, raz mniej szczęśliwego. A czasami w ogóle te, projekty były przerywane. Natomiast to jest tak jak wybieranie najtańszej oferty z rynku, nawet czasami poniżej progu opłacalności. Ten, kto to oferuje, robi to z jakiegoś powodu. Także proszę to rozważyć.
Podsumowanie
Jeśli chodzi o mity to wszystko. Jeśli macie jakiekolwiek pytania, wątpliwości i chcielibyście, żeby coś rozszerzyć, to kontakt do mnie jest w opisie odcinka. Dziękuję bardzo. Do usłyszenia.
W następnym odcinku…
W następnym odcinku porozmawiamy o tym, o czym nie warto zapominać, planując i realizując wdrożenie systemu ERP. Zastanowimy się, jak podejść do projektu, który ma służyć organizacji przez kolejne 10 lat. Opowiemy, dlaczego każda decyzja powinna być powiązana z realizacją konkretnych celów biznesowych, a nie tylko z bieżącymi potrzebami technicznymi. Poruszymy też temat zaangażowania zespołu wewnętrznego, który – w różnych etapach – odpowiada nawet za 80%, 60% czy 20% powodzenia całego wdrożenia.
Nowe odcinki publikujemy w pierwszy wtorek miesiąca. Tydzień później na naszej stronie pojawia się artykuł z podsumowaniem treści oraz kluczowymi punktami poruszonymi w podcaście — link do naszego bloga znajdziecie w opisie tego odcinka.— Znajdziecie tam także adres e-mail, pod którym możecie się z nami skontaktować. Jeśli macie jakieś pytania lub sugestie, dajcie nam znać!
Do usłyszenia w kolejnym odcinku.
________________________________________________________________________________________________
Nie zapomnij też odsłuchać poprzedniego odcinka, jeśli jeszcze tego nie zrobiłeś.
Odcinek 6, „Czas start! Realizacja wdrożenia systemu ERP”:
Spotify: kliknij tutaj.
YouTube: kliknij tutaj.
Artykuł: kliknij tutaj.
Transkrypt: kliknij tutaj.
>