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ę.
