Kategoria: Business Central

Marek Zasada: Programista nie jest tylko klepaczem kodu. Ci goście, którzy przyjechali rzeczywiście nas zrozumieli i wiedzą o co chodzi. Ważne jest po prostu umieć snuć pewną narrację tego wdrożenia.

Marek Mac: CTO firmy INLOGICA, prawie 10 lat doświadczenia. Marek Zasada, cześć.

Marek Zasada: Cześć.

Marek Mac: Marku, porozmawiamy sobie dzisiaj na temat sytuacji, w której pojawiają się programiści na etapie sprzedażowym. Ty jesteś odpowiedzialny w INLOGICA za zespół programistyczny i chciałem zapytać Ciebie, dlaczego handlowiec pojawia się z programistą u potencjalnego klienta?

Marek Zasada: Przede wszystkim chodzi o to, aby zacząć jak najszybciej budować świadomość o biznesie klienta, bo programista nie jest tylko klepaczem kodu. Nie jest tak, że dostaje dokumentację przygotowaną i musi tylko wykonać rolę odtwórczą. Jako programiści musimy rozumieć pewne procesy biznesowe, czasami nie mamy tego doświadczenia z wcześniejszej pracy. Tłumaczą nam to osoby z firmy lub konsultant, z którym jedziemy, specjalizujący się w danym obszarze, w finansach czy magazynie oraz procesy jak pracują firmy, które musimy zrozumieć. I to jest dla mnie wartość dodana do zawodu programisty, po kilku latach doświadczenia się okazuje, że wiemy dużo o procesach, w firmach, więc jest to dodatkowa gałąź do rozwoju osobistego.

Marek Mac: Czy na tym etapie warto, aby firmy pomyślały, gdy wiedzą, że przyjedziesz Ty, aby także zaprosiły po swojej stronie przedstawiciela-programistę, czy dyrektora IT?  Pamiętam, że nie zawsze tak było. Gdy odbywały się rozmowy na temat wyboru czy wdrożenia systemu, to przeważnie byli to topowi pracownicy danych modułów.

Marek Zasada: Tak. Często tak się dzieje.
Jak anonsujemy, że przyjeżdża ktoś techniczny, to rzeczywiście druga strona też zaprasza osobę techniczną. Wtedy jesteśmy w stanie porozmawiać o tym, co już istnieje w systemie.

Marek Mac: Na tym etapie można wyjaśnić, jak będzie wyglądała integracja. Czy na etapie sprzedażowym mogą zapalić się czerwone lampki?

Marek Zasada: Tak. Kwestia długu technologicznego, który już jest, z czegoś wynika decyzja o tym, że chcemy wdrażać nowy system ERP. Jednym z takich triggerów jest po prostu dług technologiczny. Trzeba uciekać do czegoś nowszego.

Marek Mac: Co się dzieje później po takim spotkaniu?

Marek Zasada: Dzieje się już na spotkaniu, i to jest ważne. Tak jak wspomniałem wcześniej, jest to tandem konsultanta i programisty, rozmawiamy o pewnych procesach, które dzieją się w firmie z osobami, które są na tym spotkaniu. Wiadomo, zależy od firmy, często to są osoby z księgowości, bo jednak ERP to głównie księgowość. Rozmawiamy o pierwszych rzeczach, trudach, które są w obecnym systemie, o ergonomii pracy, która do tej pory się nie sprawdzała, i o wymogach prawnych, które nie zostały jeszcze wdrożone albo są zrobione dookoła lub w innym systemie. Inną kwestią jest fakt, że firmy funkcjonują w określonym ekosystemie, w zbiorze kilku oprogramowań.
Na przykład faktury spływają z jednego systemu, integracja kurierska jest w drugim systemie itd. Jest to mocno rozproszone i w tym momencie już jesteśmy w stanie z kluczowymi użytkownikami rozpoznać, gdzie jest ważny punkt w firmie, środek ciężkości, na którym musimy się skupić.

Marek Mac: A często słyszysz, że przy poprzednim wdrożeniu nie mieliśmy takiego tandemu, to podejście było inne, teraz jest inaczej. Klienci widzą pewną różnicę a za tym idzie jakość.

Marek Zasada: Zdarza się, że spotykam się z komentarzem, że klienci poczuli się wysłuchani i zrozumiani. Spojrzenie tego tandemu i wysłuchanie doprowadziło do tego, że goście, którzy przyjechali rzeczywiście nas zrozumieli i rozumieją o co chodzi i już będą wiedzieli, jak tym zarządzić dalej.

Marek Mac: Lata wcześniej było przeświadczenie, iż pierwsze miesiące to w dużej mierze praca programistyczna, o której klient często nie widział a fakturę zawsze widział i musiał zapłacić. Czy uważasz, że na etapie, gdy się pojawiacie, klienci są świadomi jak praca i wdrożenie przebiega?

Marek Zasada: Tak. Zawsze staram się na spotkaniu o tym opowiedzieć, z mojego punktu widzenia jest to bardzo istotne, aby po stronie klienta byli partnerzy, którym jesteśmy w stanie transferować wiedzę. To kwestia pewnych możliwości i schematów, czy też przekonfigurowania systemów na poziomie podstawowym oraz pewnych ograniczeń technicznych, gdyż tak to działa i na to trzeba uważać. Dlaczego to jest ważne?
Jeśli nie przetransferujemy tej wiedzy, pewne problemy będą cały czas do nas wracać, a klient może mieć poczucie, że ciągle płaci, do tego worka dokłada, a problemy się powtarzają. Ktoś w końcu np. z zarządu przyjdzie i powie: „ale o co tutaj chodzi?” Wiadomo, nikt nie lubi niewygodnych pytań. To jest jedna rzecz. Druga rzecz, dla mnie jako programisty czy zespołu, z którym wchodzę w takie wdrożenie, jest utknięcie na dłuższy czas u jednego klienta w jednym projekcie. To powoduje, że wiedzy zdobytej z jednego wdrożenia, która trwa np. rok, dwa, nie jesteśmy w stanie przenieść do następnego klienta. Nie możemy zrobić kroku jako organizacja a relacja przy wdrożeniu ERP powinna być relacją symbiozy. Jedna i druga strona powinna z tego skorzystać.

Marek Mac: Czy uważasz, że przy tego typu projektach, zwłaszcza dużych wdrożeniach, lepiej skupić się na jednej koncepcji? Często spotkałem się z sytuacjami, że równolegle przy wdrożeniu systemu ERP firma rozwijała e-commerce i zewnętrzny system WMS. Mam na myśli tą całą komunikację. Wy macie takie podejście – pojawiasz się na samym początku z zespołem programistycznym, zakładam, że cały Twój zespół komunikuje się z klientem, to przy 3 różnych projektach może być to trudne?

Marek Zasada: To jest trudne, ale moja w tym głowa. Jak ustawić projekty i priorytety, zaplanować zespół lub jego rozwój, czy nawet zatrudnić następne osoby, po to, aby transfer wiedzy był płynny, aby próg wejścia dla następnej osoby, która przejmie projekty był akceptowalny, by wydarzyło się to w określonym czasie oraz zarządzić oczekiwaniami klienta. Czasami w naszej pracy grupują się 2-3 duże projekty w jednym czasie. Trzeba umieć tym zarządzić i powiedzieć, że zrobimy to, ale trzeba będzie poczekać miesiąc, dwa, gdyż taka jest teraz sytuacja i o dziwo najczęściej klienci przyjmują to dobrze. Ważne jest umieć snuć pewną narrację, opowieść tego wdrożenia, nawet jeśli rzeczywiście jest to chwilowy przestój, czy trafiliśmy w zły moment, to nic złego się nie dzieje, jeśli się rozmawia.

Marek Mac: Jesteśmy już w trakcie wdrożenia, mamy pierwsze miesiące za sobą. Na co Wy jako dział programistyczny zwracacie szczególną uwagę, a na co klient, na co powinien być przygotowany?

Marek Zasada: Pewne zdarzenia trwają w określonym czasie i na moment wdrożenia systemu sporo rzeczy trzeba odłożyć na później. Podchodzimy do tego tak: oznaczamy procesy i modyfikacje, które są krytyczne, aby wystartować teraz, a które kwestie można zrobić w kolejnym kroku. To bywa uciążliwe, rozumiem to, dla użytkownika końcowego, który będzie na tym pracował. Po zażegnaniu wszystkich krytycznych rzeczy jest czas na ergonomię. Ten czas potrafi być bardzo długi, nawet dwa lata. Zdaję sobie sprawę, że ktoś może pracować w sposób nieergonomiczny na początku przez pół roku, rok, zanim dostanie od nas rozwiązanie.
Tak jest po prostu, decyzje biznesowe muszą być podjęte, kolejność działań musi być zachowana. Gdybyśmy rzucili wszystko naraz, nie wiadomo by było na przykład, gdzie szukać problemu, jeśliby coś przestało działać.

Marek Mac: Po stronie klienta zawsze jest przygotowanie danych. Oni często przygotowują to na ostatnią chwilę i różnie z tymi danymi bywa. Czy trafiają do ciebie case’y typu: klient woli zapłacić więcej abyście wy przygotowali dane? Czy to jest według ciebie dobre podejście?

Marek Zasada: Tak, zdecydowanie trafiają się takie rzeczy i zdarzają się za często. Dlaczego? Dane mają swój kontekst, tło. Osoba, która na tym pracuje, zna to tło. Jeśli wchodzę tam ja, muszę i tak dopytać o pewne rzeczy, gdyż mogę wszystkiego nie rozumieć. Zdarzają się takie przypadki: „tutaj jest dostęp do bazy danych, zobaczcie sobie, jak się rozpoznacie, to dajcie znać i przygotujcie”. Często prowadzi to do zgrzytu, polegającego na tym, że klient myśli, że my wszystko o nim wiemy. Pojawia się odpowiedź: „ale daliśmy wam już wszystko, czego nie rozumiecie?”. Niestety to tak nie jest, gdyż to klient jest właścicielem swojego biznesu, on wie najlepiej, co robi. Skoro decyduje się na wdrożenie ERP, znaczy, że jest jego biznes jest dobry. Musi nam sprzedać tą opowieść, o tym jak pracuje, do czego te dane mu są potrzebne i w jakiej częstotliwości.

Marek Mac: Często spotykałem się z sytuacjami, gdzie firma decydując się na nowy system ERP w poprzednim rozwiązaniu nie do końca miała opisany ten system. Nie było instrukcji, co uważam, na tamte lata, powiedzmy 5-10 lat temu było normą. Nikt o to nie dbał, czy to w samym kodzie – SQL, czy w bazach danych, triggery lub customowe rzeczy na bazach – totalnie nie były opisane. Czy spotykasz takie sytuacje? Pytam, aby klienci byli uczuleni, że macie dodatkową robotę i to nie małą.

Marek Zasada: Wiąże się to z dodatkową pracą. Starałem się to wyłapywać już na samym początku, aby to uwzględnić w pierwotnych szacunkach w budżetowaniu, mimo, że to jest trudne do budżetowania. Na całe szczęście w technologiach, w których pracuje Microsoft kładzie nacisk na pewien best practice, aby ten kod był self-descriptive, samoopisujący się i rzeczywiście sporo firm się do tego stosuje, więc analiza tego kodu nie jest taka straszna. Zdarzają się sytuacje, w których firma nie spodziewała się aż takiego rozwoju, zwłaszcza jeśli jest zza granicy i kod jest napisany a przy nim komentarz w języku rosyjskim albo włoskim.
Ktoś nie dostosował się do tego, że kiedyś to może być międzynarodowe i wtedy robi się ciekawie.

Marek Mac: Czy trafia do Was klient, który korzystał z rozwiązania rodzinnego, czyli kolega kolegi napisał jakiś soft, który działa. Czy takie osoby pojawiają się na Waszych spotkaniach? Mam przeświadczenie, że to są trudne rozmowy, jeżeli jest jedna osoba od softu, bądź dwie, to przekazanie tej wiedzy może być kłopotliwe.

Marek Zasada: Zdarzają się takie sytuacje, aczkolwiek nie pamiętam, aby było to dużym problemem.
Raczej to jest współpraca. Wynika to ze świadomości, że już to oprogramowanie kilka lat jest i przydałoby się to zastąpić czymś sprawniejszym. Ta osoba chce się rozwijać i zobaczyć coś nowszego. Zdarza mi się, że osoby, które wdrożyły starszą wersję ERP, dzwonią do mnie i pytają, gdyż wiedzą, że mam kontakt z najnowszą wersją: „a jak to jest rozwiązane w najnowszej wersji?” Zaczynają myśleć i się zastanawiają: „czy to co mamy musimy rozwijać, czy iść w stronę migracji w nowsze wersje ERP, bo to rozwiąże w przyszłości wszystkie problemy”.

Marek Mac: Kiedy jesteśmy już po etapie wdrożenia, jaką macie rolę jako dział programistyczny? Wspomniałeś oczywiście o ergonomii, jak dalej wygląda kontakt z klientem? Czy to jest typowy serwis czy każdy klient ma swoją osobę do kontaktu, czy kontaktuje się z wami jako dział programistyczny?

Marek Zasada: Tak, mamy system ticketowy, klient składa do nas ticket i staje się jednym z wielu, ale nie rezygnujemy z relacji. To cały czas osoby, które były przy wdrożeniu. Jeśli są dostępne i mają wiedzę z tego wdrożenia, co jest bardzo ważne to kontaktują się z tymi osobami bezpośrednio. Staramy się tym zarządzić w taki sposób, aby obie strony były zadowolone.
Generalnie taki support trwa przez wiele lat. Stawiamy na długofalowe relacje. Ja też się dobrze czuję w takich relacjach. Taki klient jest przewidywalny. Dla nas ta współpraca jest po prostu modelowa. Też chcemy komfortowo spędzać czas w pracy.
Są kwestie związane ze zmianami prawnymi i trzeba system dostosować, więc zaufany dostawca jest dobrym partnerem do tego, aby rozwijać ten system pod nowe okoliczności.

Marek Mac: Teraz mamy takie czasy, że wszyscy stawiamy na umiejętności miękkie. Kiedyś tego nie było.
Ja pamiętam, jak przyjeżdżaliśmy, jako wdrożeniowcy to słyszeliśmy: „przyjechał pan informatyk”. Teraz naszą branżę traktujemy jako doradców biznesowych i to jest kapitalne.
Z perspektywy doświadczenia, co było największym wyzwaniem w twojej pracy?

Marek Zasada: Myślę, że bardzo długo zajęło mi złapanie, pewnego żargonu. Kiedy byłem początkującym programistą, zwłaszcza pierwsze pół roku, inne osoby mogły mówić do mnie po koreańsku – niej więcej tyle samo zrozumiałem.
Budowanie w sobie świadomości i relacji, które są w systemie. Rozpoznanie systemu od strony technicznej, jak działa oraz zrozumienie podstawowych procesów i praw, które się rządzą w systemie. To jest organiczna współpraca, najczęściej z konsultantem. Zadaniem programisty jest wyciągnąć wiedzę od konsultanta, aby opowiedział całą historię, jak klient działa biznesowo, może podać porównanie jak to robiliśmy u innego klienta i czym to się różni, aby zbudować w sobie poczucie całości procesu i punktu biznesowego, w którym się znajduje dana zmiana. To było najtrudniejsze i trwało najdłużej. I uczę tego wszystkich programistów, którzy przychodzą do nas do firmy. Ten okres może trwać spokojnie dwa lata. Jeśli przez ten czas jeszcze czegoś nie rozumie, to ok, jest na dobrej drodze. My jesteśmy od tego, aby mu pomóc.

Marek Mac: A o co najczęściej klienci pytają na pierwszych spotkaniach?

Marek Zasada: Pytania skierowane do mnie nie są bezpośrednio techniczne, programistyczne. Moja rola sprowadza się do projekcji możliwości, integracji i utrzymania systemu. Pytają w jaki sposób pracujemy i dostarczamy modyfikacje.
Jeśli ktoś nie miał wcześniej styczności, może nie wiedzieć, że najpierw pewne rzeczy robimy na środowisku testowym. Tam proszę użytkowników kluczowych, aby dokładnie to zbadali, aby uniknąć sytuacji eksperymentowania bezpośrednio na produkcji. To jest projekcja współpracy. Jeśli jest ktoś z działu IT, to faktycznie pojawiają się kwestie o doświadczenie, integrację. Czasami pytają o konkretne systemy i rozwiązania, z którymi firma planuje się zintegrować, i czy mamy kompetencje. To jest szukanie partnera, który ma umiejętności.
Jeśli na spotkaniu jest osoba techniczna, to kwestie techniczne się pojawiają, a jeśli nie, to jest projekcja jakby prowadzenia projektu.

Marek Mac: W kwestii systemu ticketowego, o którym wspomniałeś, czy klienci nie wolą po prostu zadzwonić? Dla nich jest wygodniej i szybciej. Czy dzisiaj, mimo iż mamy system ticketowy, który jest prowadzony po to, aby klient opisał dany problem, aby zostało to zapisane, a nie telefon 5-10 minut: „proszę to poprawcie, to zróbcie”. Jak to teraz wygląda?

Marek Zasada: Nie ma dla nas problemu, jeśli klient zadzwoni. System ticketowy nie jest tylko dla klienta, ale także dla nas. Jeśli to jest kwestia do rozwiązania przez 10-15 minut przez telefon, albo był telefon pierwszy z wielu, ja zakładam to zadanie dla klienta.
Wtedy klient ma informację, że ja to odnotowałem. Zostawiam notatkę w tickecie po takiej rozmowie, co zaplanowaliśmy, ustaliliśmy, albo że potrzebujemy spotkania. Zarządzamy ticketami dla klienta.

Marek Mac: Ok, Marku, bardzo Ci dziękuję. Mam nadzieję, że będziemy mieli jeszcze okazję w przyszłości porozmawiać.

Marek Zasada: Dziękuję.

Michał Paluszczak: Dla mnie to jest bardzo dobra wiadomość, że będziemy rozmawiać o finansach. Drugi najczęściej pojawiający się tekst po stronie klienta to: „u nas wszystko jest proste”. Tak się w ERP nie da. Jakby nigdy się nie dawało.

Marek Mac: Ponownie w studio Michał Paluszczak, CEO INLOGICA. Cześć.

Michał Paluszczak: Cześć, spodobało mi się, więc jestem jeszcze raz.

Marek Mac: Dokładnie, bardzo dobrze. Chcieliśmy dzisiaj poruszyć z Tobą temat: jak wygląda podejście do wdrożenia Dynamics?

Michał Paluszczak: Chcesz poruszyć trudny temat finansowo-precyzowy?

Marek Mac: Tak, jesteś osobą, z którą będę mógł porozmawiać o finansach. To będzie ciekawe, bo nie każda firma chce o tym rozmawiać. Chciałem zapytać Cię, co się dzieje kiedy przychodzi do Was klient?

Michał Paluszczak: Zanim odpowiem na to pytanie, powiem dla mnie to też jest bardzo dobra wiadomość, że będziemy rozmawiać o finansach. Najważniejsze jest, aby nie rozczarować się wzajemnie w relacji z klientem. My dość otwarcie komunikujemy kwestie finansowe, staramy się na rzędach wielkości na początek, bo to jest proste. Wracając do Twojego pytania, co się dzieje, kiedy przychodzi klient? Jedno z pierwszych pytań: „ile to będzie kosztować?” Kiedyś miałem takie powiedzenie, ale ono się zużyło, że między 100 tys. a 100 mln. w zależności od tego, co wymyślimy w tym projekcie. Potrafimy to oszacować, tylko kiedy przychodzi klient, to często nie jest w stanie nam odpowiedzieć na podstawowe pytania, abyśmy mogli to zdiagnozować.

Marek Mac: Tak, często klienci nie wiedzą sami, czego chcą.

Michał Paluszczak: Tak i jaki jest ich ekosystem. Drugi najczęściej pojawiający się tekst po stronie klienta: „u nas wszystko jest proste”. Ja wiem, że u klienta to jest proste. W jego głowie, biznesie, świecie to wszystko jest oczywiste i banalne. My to musimy zrozumieć. Tak naprawdę, kiedy przychodzi klient, to musimy przede wszystkim zdefiniować, w jakim miejscu on jest w tej chwili. Czy on sam rozumie do końca, jak działa jego biznes? Czy ma zmapowane procesy w tym biznesie? Czy jest nam w stanie dostarczyć taką pigułkę wiedzy, abyśmy mogli poszukać analogii w historycznych projektach, w tym, co robimy być może w tej chwili dla innego klienta albo robiliśmy w przeszłości. Pierwszy krok- zrozummy się, tak bym go nazwał. Musimy nawiązać jakiś poziom zrozumienia.

Marek Mac: Widzę to po rynku: firmy na początku chcą mieć zrobioną analizę. Jest to w zasadzie uzasadnione. Chcą wiedzieć, jak to będzie wyglądało. Jak Wy do tego podchodzicie? Czy Wy też robicie analizę, czy macie trochę inne podejście?

Michał Paluszczak: Do niedawna też robiliśmy analizę.

Marek Mac: Dlaczego nie robicie?

Michał Paluszczak: Dlaczego nie robimy analizy? To ma związek z tym, że analiza jest takim usypiającym słowem. Z niego nic nie wynika. Co my będziemy tam analizować? Nas nie interesuje analiza w rozumieniu „pogłębmy wiedzę o kliencie”. To jest oczywiście ważne, ale nas jako firmę wdrożeniową interesują procesy, którymi powinniśmy się zaopiekować i odzwierciedlić w systemie. I robimy to już wiele lat. Dopiero niedawno stwierdziliśmy, że słowo analiza jest słowem pułapką. Po analizie możesz dostać np. prostego Excela z cyferkami, które będą mówić, że na obszar X przeznaczymy tyle czasu w tym wdrożeniu, na obszar Y- tyle. Dopiero kiedy cofniesz się przed analizę i zobaczysz, jak można efektywnie pracować z klientem w formie warsztatów, mapowania procesów, robiąc to z nim, wtedy to ma wartość. Analiza jest dla mnie ostatnio słowem bardzo usypiającym, staram się klientów, ale też wewnętrznie zespół, wiele lat posługiwaliśmy się tą nomenklaturą, uwrażliwić na to, aby nie dać się w tą pułapkę wpędzić, która często występuje: „u nas to jest proste”. Trzeba dogłębnie odkryć i dopatrzyć się w tym projekcie, co naprawdę robi klient i co powinno być przez nas uwzględnione.

Marek Mac: A możemy to rozdzielić? Czyli robimy i analizę i takie warsztaty. Klient sobie wybiera, z czego chce skorzystać albo z tego i z tego. Ale jest mała gwiazdka.

Michał Paluszczak: Tak. Możemy potraktować to jako odrębne procesy. Natomiast ja bym chciał mówić i komunikować, i aby nasi klienci przychodząc do takiego projektu, do nas mówiąc: „mamy potrzebę wdrożyć nowy system ERP, uruchomić nowy system”, aby przychodzili do nas z nastawieniem, że to będzie współpraca. Analiza, moim zdaniem, ma takie ukryte przesłanie: ktoś przyjdzie, mnie wysłucha, a potem do mnie wróci i przedstawi mi gotowe rozwiązanie.
Tak się w ERP nie da. Nigdy się nie dawało. Teraz nie daje się szczególnie.
Zaraz powiem, dlaczego. Musimy cofnąć się i od początku włączyć klienta w ten proces. Nie da się szczególnie dlatego, że pracujemy w Scrum, w metodykach zwinnych, więc kontakt z klientem, który w czasie projektu będzie się już odbywał, jest dość intensywny. Jeżeli od początku klient przyjdzie z takim nastawieniem, że przyjdą ludzie, wysłuchają mnie i magicznie stworzą mi system, to się nie może skończyć dobrze.
Mieliśmy taki przykład przy ostatnim wdrożeniu, gdzie komentarze ze strony użytkowników klienta były takie: „ale to jeszcze nie gotowe, niby szkolenie, ale to jeszcze nie działa” i tak dalej. I odpychali ten moment, kiedy użytkownicy wejdą do systemu. Pojawili się bardzo krótko przed go live. Można by powiedzieć, że projekt zawisł na włosku, bo testy odbywały się praktycznie po uruchomieniu.
Kiedy mamy do czynienia z taką pracą warsztatową, mapowaniem procesów, współpracą od początku, już na etapie analizy, kiedy tą analizę zaczniemy ubierać w formę, usiądziemy razem przed Visio i zaczniemy wspólnie te procesy kreślić. Nie w takiej formule analitycznej-przyjeżdża konsultant, wysłuchuje klienta, potem wraca i on to próbuje drugi raz rozpisać. Bez sensu zupełnie.
Staramy się skrócić teraz tą drogę, tak aby dużo od początku realizować wspólnie z klientem. To jest takie przygotowanie klienta na to, co się będzie działo w projekcie. Umówmy się, że przy tej analityce początkowej, klient jest świadomy, to przy samym wdrożeniu są klienci, którzy są gotowi włączyć się w odpowiednim momencie. Bardzo wielu klientów przy takim podejściu przyjmowało postawę, przecież o tym rozmawialiśmy już podczas analizy. No dobrze, rozmawialiśmy, a teraz trzeba to skonkretyzować. Nie. Szczegóły na początku. Przestawmy tą dźwignię, nie przeskakujmy tego kroku.

Marek Mac: Dla Was to jest dobry moment, gdyż nie będzie zgrzytu. Często klienci nie są świadomi, że po analizie, musimy to doprecyzować i wychodzą rzeczy, o których nikt na początku nie pomyślał.

Michał Paluszczak: Tak, moim zdaniem dopiero kiedy zobaczysz, możesz stwierdzić, że coś czujesz. Staramy się bardzo mocno klientów zachęcić od początku, aby to nie była praca na ogólnikach, na dużych obszarach klockowych.
Usiądźmy, narysujmy i umówmy się wtedy między sobą, co będziemy w tym systemie robić i w tym momencie mój zespół może podać w miarę wiarygodne estymaty: czasowe, budżetowe i jak to będziemy realizować w praktyce.

Marek Mac: Jak klienci reagują na takie Wasze podejście?

Michał Paluszczak: O dziwo całkiem nieźle.

Marek Mac: Wydaje mi się, że podejście warsztatowe będzie droższe i dłuższe.

Michał Paluszczak: Troszkę.

Marek Mac: Co w przypadku, jeśli klient po warsztatach stwierdzi: „to system nie dla nas” albo Wy to stwierdzicie.

Michał Paluszczak: Nie ten klient na ten system.

Marek Mac: Tak.

Michał Paluszczak: Dla klienta najlepszą informacją jest to, że kiedy pójdzie do innego partnera, dostawcy tego systemu, będzie miał obiektywnie spisane i skatalogowane procesy.
To jest praca, której często klienci nie mają czasu wykonać wewnętrznie, nie przymuszani taką sytuacją, jak wdrożenie systemu ERP. Kiedy powiemy sobie: „no słuchajcie, to jednak nie jest dla was”, nie powinienem tak mówić, bo Microsoft to system dla wszystkich i wszyscy się na pewno wpiszą, ale gdyby klient stwierdził: „nie dla nas ten budżet”, „musimy znaleźć coś tańszego” albo „z innej półki”, to też jest ok. Etap tych warsztatów, pracy wstępnej, mocno intensywnej, we współpracy z klientem, na pewno spowoduje, że efektem,  będzie mapa procesów, spisane wrażliwe obszary, zaznaczone didaskalia na wykresach i to właśnie jest problematyczny obszar, którym trzeba się mocno zająć, ustandaryzować go lub zmienić.
Mogę przedstawić wam mail pod tytułem: u nas wszystko jest proste versus efekt. Mamy prosty biznes, proste zamówienia, tylko sprzedajemy, dystrybucja, żadnych fajerwerków i taki wykres, nie wygląda strasznie, ale kroków ma kilkanaście co najmniej. Więc od prostego – ja kupuję i sprzedaję do faktycznego, co ja robię, jest bardzo duża przestrzeń do zdefiniowania.

Marek Mac: Jesteś w stanie określić, ile takie warsztaty czasowo mogą trwać? I jak wyglądają finansowo?

Michał Paluszczak: Tak, możemy porozmawiać otwarcie o finansach, jeżeli mówimy o firmie, zatrudniającej 20-30 osób, wdrożenie niewielkie, mamy firmę – sprzedaż dystrybucyjna, wiemy, że musimy porozmawiać z ludźmi w dziale zakupów, sprzedaży i z magazynem. Weźmy to przez pryzmat ludzi. Chcemy zmapować te procesy, wyślijmy do każdego z tych obszarów pracownika na 2 dni, żeby spokojnie usiadł w każdym z tych departamentów, mógł sobie omówić, jak ci ludzie pracują, jakie są główne procesy, czyli co ja deklaratywnie robię, aby w miarę mógł wyłapać te wszystkie wyjątki tego prostego procesu, który zawsze w głowie klienta jest prosty, to mamy 2 dni w każdym dziale, każdego konsultanta, który jedzie i rozmawia – 6 dni w sumie. Ten pracownik musi wrócić, przemyśleć, przedyskutować to, co zebrał, w jakiś sposób to skatalogować.
Dzień ekstra dla każdego z nich, to mamy dni 9. Dajmy jeszcze każdemu z nich po dniu na dopieszczenie tej dokumentacji, on zaczął rysować z klientem, tworzyć jakieś grafy, procesy. Dajmy mu jeszcze dzień, taki ekstra, żeby spokojnie mógł jeszcze to dopieścić.
Dni 12. Spotkanie podsumowujące z prezentacją wyników – każde z nich, trwa pół dnia, z klientem w zestawieniu.
Ile nam wyszło? 13 i pół dnia x stawka, którą się posługujemy- koszt około 10 tys. Euro- za pracę wejściową.

Marek Mac: To nie jest dużo. Ja pamiętam sytuację, gdzie klienci do nas na portal się zgłaszali: o analizę; jak podejść, jak wybrać i tak dalej. Często staramy się zasugerować, aby spróbowali sami rozpisać te procesy. I mamy rekordzistę! Trwało to 8 miesięcy. Gdyby to policzyć: 8 miesięcy koszt i tak dalej…

Michał Paluszczak: To może tyle trwać. Jeżeli skala firmy jest taka, wchodzimy w korporacyjne wdrożenie i użytkowników będzie 100, 200, tak naprawdę możemy analizę robić wiele lat nawet. Ja powiedziałem o prostym scenariuszu, znowu możemy wziąć pracownika, zastanowić się, ile on tam będzie, koszt naszej pracy to koszt ludzi, których zatrudniamy do tej pracy. Tutaj nie ma żadnych kosztów ukrytych, to nie jest tak, że ja ekspercko to wyliczam. Muszę zastanowić się po ludzku, jaki czas nasi ludzie, to jest też ciekawy temat, gdyż klienci się zastanawiają, skąd te koszty, skąd się bierze stawka, te wolumeny. Musimy wziąć pracownika, wysłać do Was, do klienta, on tam spędzi dzień, 2, w takim wariancie, jak teraz opowiadałem, mamy 3 dni takiej pracy warsztatowej w departamencie. Wydaje się dużo nawet. Można zrobić to szybciej, ale dajmy sobie bufor, aby zmieścić się w czasie, bo okaże się, że pierwszy dzień poszedł bardzo opornie i musimy zrobić dogrywkę. Zawsze można ją zrobić. Ważne jest, że te wolumeny nie biorą się znikąd. To jest praca tych ludzi. Microsoft nie jest najtańszym we wdrożeniu systemu ERP. Jest systemem bardzo uniwersalnym, ale wymagającym bardzo wiele konfiguracji wstępnej, aby ruszyć z miejsca, aby mógł zadziałać.
Jeżeli firma klienta jest wielowymiarowa i potrzebuje zintegrowanego systemu, pracownicy z tych departamentów, którzy wrócą, muszą usiąść razem i porozmawiać o tym. To jest kolejny czas. Jaki wpływ ruchy magazynowe mają mieć na sprzedaż, czy są specyficzne wymagania co do trzymania wysokości stoków albo śledzenia magazynu w drodze. To wszystko ma znaczenie.
Te koszty wynikają bezpośrednio z pracy ludzi, z czasu, który spędzają z klientem. Można sobie go na dużych klockach bardzo łatwo wyobrazić. Tak jak mówię, w dużej firmie to mogą być tygodnie albo miesiące w procesie spędzone u klienta i wtedy taki scenariusz, w którym mówisz, że coś trwa pół roku, też jest możliwe.

Marek Mac: Takie warsztaty są dla każdego? Czy będą sytuacje: zróbmy standardową analizę?

Michał Paluszczak: Uważam, że warsztaty są dla każdego.
Jestem świeżo po zmianach, które wprowadzamy wewnętrznie, więc jestem entuzjastą tego podejścia. Uważam, że podejście pasywno-słuchające, nieaktywne, wychodzi mocno z obiegu. Nie da się w ten sposób realizować projektów. Mieliśmy bardzo wiele historii tego rodzaju, nie wciągnięcie klienta w odpowiednim momencie w pracę warsztatową, wspólną – bardzo mocno rezonowało później w projekcie, kiedy realizowaliśmy wdrożenie.
Klient nie był do tego przyzwyczajony, nie rozumiał naszych oczekiwań, był wyrywany ze swojej pracy. Tak to odbierał, że ciągle coś od niego chcemy. Więc od początku angażujemy go delikatnie i mówimy: słuchaj, my tak pracujemy, nie pracujemy w próżni. Znam takie historie od klientów, którzy przychodzą do nas i mówią: „przekazaliśmy wszystko firmie, która u nas to wdrażała albo wdraża, potrzebujemy pomocy, oni zniknęli, potem wrócili z czymś, to nie spełnia naszych oczekiwań”. To nie jest wina tej firmy, która to robiła.
Jeżeli klient się w to nie zaangażował, nie był na bieżąco, tak naprawdę może mieć pretensje do siebie. Takie sytuacje się zdarzają- jakaś grupa osób albo pracowników w organizacji klienta, chroni resztę przed tym, aby nie za mocno byli angażowani na etapie wdrożenia, bo mają swoją robotę. To błąd. To co będziemy testować dopiero po uruchomieniu, to zrozumienie systemu, jego ergonomii, wyglądu, gdzie to się, mówiąc bezpośrednio, klika w systemie, jak on jest skonstruowany wizualnie nawet.
Każda minuta, godzina spędzona klienta na etapie tych warsztatów już podczas wdrożenia, od samego początku jest istotna, to się nie dzieje w próżni, my rozmawiamy o tych procesach, czasami są dyskusje i są pytania: „jak to wygląda w tej chwili w systemie, na przykładzie?” Konsultant wyciąga komputer, odpala system i mówi: tak to możemy zamodelować, tak zrobiliśmy na naszej wersji demo lub prezentacji, czy dla Was to jest ok? I ta praca musi tak wyglądać. Jak o tym mówię nawet, to słyszę wewnętrzny głos, a jak mogłoby wyglądać inaczej?  Podejście do analizy przy wielu wdrożeniach, które robiliśmy, było przeprowadzone po macoszemu. Nie do końca uważam z perspektywy czasu, że robiliśmy to dobrze i dobrze kierunkowaliśmy energię klienta w tych wdrożeniach.

Marek Mac: Najgorsze według mnie, jak trafisz na klienta, który faktycznie nie przyłożył się do tradycyjnej analizy, a podczas wdrożenia przy procesie powie: „a jeszcze to!”. Być może nie wywróci to całego projektu, ale potrafi dołożyć tyle godzin, że pojawiają się problemy.

Michał Paluszczak: Oczywiście.
Przede wszystkim tak już powiedziałem podczas pierwszego naszego spotkania, musimy mieć świadomość, na co się z klientem umawiamy. Wszystkie słowa, sformułowania ryzykowne: mówiliśmy o tym, wspominaliśmy o tym… Świetnie, ale jaki jest po tym ślad? Wiadomo, że analiza, nawet w tym tradycyjnym ujęciu, powinna się kończyć podsumowaniem, dokumentem.
Stawiamy w tej chwili mocno na głębszą interakcję od samego początku. Wdrożenie we współpracy, a nie wdrożenie dla klienta. Myślę, że jednym zdaniem można byłoby to podsumować.

Marek Mac: Wspomniałeś wcześniej, że wdrożenie systemu Microsoft nie należy do najtańszych. Moje pytanie: ile to może kosztować?

Michał Paluszczak: Rozumiem, między 100 tys. a 100 mln., tak?

Marek Mac: Tak.

Michał Paluszczak: Najważniejsze, dlaczego tak jest. Produkty nie są najtańsze, gdyż są uniwersalne. System Microsoft Dynamics i w wersji Business Central i w wersji Finance & Operations jest systemem stworzonym przez producenta na cały świat. 
To tak, jakbyśmy rozsypali klocki Lego, możemy z nich coś ułożyć. Tak samo działa ten system. Możemy z niego ułożyć obraz dla bardzo małej firmy, ale mając do dyspozycji zasobnik tego systemu, możemy utworzyć system dla bardzo dużej organizacji, zaopiekować się procesami korporacyjnymi. Zaraz odpowiem na pytanie, ile to może kosztować. 2-3 przykłady mogę Ci podać. Najważniejsze jest zrozumienie, dlaczego tak jest. Nie jest jak w polskich systemach finansowo- księgowych – kiedy wszystko jest gotowe – pewne procesy są zamodelowane. Microsoft ‘u nie interesuje, że w Polsce JPK składa się w ten sposób po stronie finansów, albo wymogi formalne są takie a nie inne. On jest uniwersalny. Ma swoje lokalizacyjne paczki, które wymagają za każdym razem dostosowania do potrzeb klienta.
Rozmawialiśmy ostatnio o naszym wzorcowym wdrożeniu w 5 dni- to koszt kilkunastu tys. zł. Wdrożenie takiego systemu w małej organizacji może kosztować kilkanaście-kilkadziesiąt tys. zł. W organizacjach, które zatrudniają około 80-100 użytkowników, raczej mówimy już stanowczo o 6-ciu zerach – pewnie to będą miliony złotych. W dawnych czasach, kiedy OnPrem królował, mówiło się, że wartość zakupu licencji (jednorazowej) to mniej więcej równoważnik tego, ile będzie kosztowało wdrożenie. A najlepiej, gdyby to wdrożenie jeszcze przemnożyć razy 1,5.
Kiedyś licencja kosztowała 4 tys. Euro na usera. Jeżeli miałeś 80 userów, to znaczy, że zakup licencji kosztował cię 320 tys. Euro, to mniej więcej 1,5 mln musiałeś zaplanować na inwestycje w wykonanie tego projektu dla takich firm wdrożeniowych jak nasza. Teraz wydaje się, że ta bariera się zmieniła, trudno ją złapać, bo są subskrypcje, więc jest troszeczkę inaczej.
Ostatnio przy Business Central rozmawialiśmy z klientem, który ma dość prosty biznes, bez robienia tych warsztatów, liczyliśmy koszt licencji: około 50 userów, jeżeli przyjmę cenę licencji miesięcznej dla Business Central około 80 Euro x 50 userów, czyli 4 tys. miesięcznie x 1 rok około 50 tys. Euro w licencjach, to nie wiem, czy uda mi się zrobić to wdrożenie za 50 tys. Euro. To by było nadużycie, ale przemnażając to x 1,5 -myślę, że jesteśmy w równowartości w tym przypadku- mamy firmę, która zajmuje się rozliczaniem projektu, mamy faktury, sprzedaż, zakupy, spinamy to w module projektowym – stosunkowo powtarzalny i prosty deklaratywnie biznes. Zaraz przechodzimy do warsztatów, więc powiem Ci, może przy następnym spotkaniu czy z tego prostego procesu zbieram faktury kosztowe, fakturuję klienta i rozliczam projekt. Czy to będzie rzeczywiście takie proste, czy pokażę Ci jakiś wielki diagram przy następnym spotkaniu.

Marek Mac: Wspomniałeś o wdrożeniu w 5 dni, zrobiliśmy o tym odcinek i wiem, że macie już jeden case opisany.

Michał Paluszczak: Tak, jeden case już się skończył, w warsztacie samochodowym, jak możemy to gdzieś podlinkujmy i pokażmy jak to się odbyło.

Marek Mac: Tak. Opinie były skrajne i ciekawe po tym odcinku. Jedni się pukali w głowę. Mamy komentarze: „jak w 5 dni? To jest marketingowy chwyt”. Okazuje się, że nie jest.

Michał Paluszczak: Nieustannie zapraszam do skonfrontowania tej propozycji z oczekiwaniami, to musi wybrzmieć: poczyniliśmy założenia i te oferujemy w ramach wdrożenia.
Przewagą jest, że system Business Central, w naszej propozycji, możemy rozwinąć. Jeżeli będą elementy, które nie będą pasowały klientowi wzorcowemu, zawsze możemy je zmienić. Rzeczywiście to są dodatkowe koszty i nakład prac, ale pytanie o skalę.
Jeżeli ktoś będzie chciał wzorcowe wdrożenie, które jest dla firm usługowych do kilku użytkowników systemu, przepiąć na firmę produkcyjną, to oczywiście nie mamy o czym mówić. Ale jeżeli ktoś mi powie, że oprócz usługi prowadzi jeszcze drobną sprzedaż z magazynu, to nie zajmie dużo więcej niż 5 dni. Jeżeli będziemy mieli skonfigurować przyboczny magazyn, to też będzie w tych granicach.

Marek Mac: Dla mnie to jest intrygujące wejście do świata systemów ERP niewielkim kosztem, kiedy właściciel firmy ma bardzo dobry pomysł na biznes, aby go skalować.

Michał Paluszczak: Zgadza się. Wiemy jakie są stawki na rynku IT. Będąc małą firmą, 5-10 osobową, to jest cały Twój biznes, możesz finanse, księgowość, sprzedaż i zakupy prowadzić w genialnym, skalowalnym narzędziu na przyszłość- to jest proste.
To naprawdę może się zdarzyć w 5 dni. Odsyłamy, mam nadzieję, do case’a i wciąż zachęcam do tego, aby się z nami skontaktować i skonfrontować swój biznes, najlepiej usługowy, z naszą propozycją.

Marek Mac: Michale, bardzo Ci dziękuję za udział i mam nadzieję do zobaczenia. Porozmawiamy następnym razem o warsztatach.

Michał Paluszczak: Porozmawiamy o warsztatach. Dzięki.