Wstęp

Wybór systemu ERP i partnera wdrożeniowego to moment, w którym decydujesz nie tylko o technologii, ale i o tym, z kim będziesz realizować jeden z kluczowych projektów w firmie. W tym odcinku rozmawiamy o tym, jak sprawdzić stabilność dostawcy, jak ocenić zespół wdrożeniowy i dlaczego warto skupić się na kilku funkcjach istotnych dla Twojego biznesu zamiast analizować setki standardowych opcji. Pokazujemy też, jak uniknąć pułapek przeciągających się decyzji i ukrytych kosztów.

Ta transkrypcja dotyczy 4 odcinka podcastu „Odkoduj wdrożenie ERP”.

Artykuł przeczytasz tutaj.

Posłuchać możesz na naszych kanałach Spotify i YouTube.

Dlaczego wybór partnera i systemu ERP jest tak ważny?

Bardzo ważna jest wbrew pozorom chemia między osobami, które mają współpracować ze sobą ponad rok, które mają ze sobą dyskutować, które mają ze sobą uzgadniać pewne kwestie, czasami się nie zgadzać, czasami wchodzić kolokwialnie mówiąc na kurs kolizyjny. I to w jaki sposób jesteśmy w stanie się z nimi dogadać, to w jaki sposób się komunikujemy, to w jaki sposób jesteśmy w stanie zarządzić tymi rozbieżnościami, będzie miało naprawdę gigantyczny wpływ na komfort współpracy w ramach projektu.

Wstęp

Witam w kolejnej części. Dzisiaj skupimy się na kwestii kolejnych kroków związanych z rozpoczęciem prac nad projektem wdrożeniowym. Dzisiejsza część dotyczyć będzie wyboru partnera i technologii do naszego przedsięwzięcia. Jesteśmy już po etapie definiowania potrzeb, określania celów, przygotowaliśmy organizację, przemyśleliśmy w jaki sposób chcemy to realizować,  i przychodzi czas na wybór partnera i technologii, w której chcemy realizować planowane przedsięwzięcia. Większość organizacji dzisiaj świetnie sobie radzi z tymi procesami – nie ma tutaj zbyt wielu tajemnic, natomiast mam kilka sugestii, które uważam że warto rozważyć, użyć i zastosować w praktyce.

Sprawdź plany rozwojowe i kondycję partnera

Dlaczego plany rozwojowe mają znaczenie

Wybór partnera jest nawet, myślę, często bardziej istotny niż wybór samej technologii. Natomiast jedna i druga rzecz jest bardzo istotna. Jeśli chodzi o to, czym się powinniśmy kierować w tym zakresie to poza takimi rzeczami oczywistymi warto też przyjrzeć się temu, na ile ten partner jest w stanie się włączyć, zgrać z nami w naszym podejściu jeśli chodzi o kwestie realizacji celów naszego przedsięwzięcia.

Ponieważ tak jak opowiadałem w poprzednim odcinku, jeśli patrzymy na przedsięwzięcie informatyczne jako na inwestycje, to takie kwestie jak brak opóźnień, wiedza i umiejętności, które pozwolą osiągnąć nasze cele są dużo bardziej istotne moim zdaniem niż kwestia czy dane wdrożenie / dane przedsięwzięcie będzie kosztowało odrobinę drożej czy odrobinę taniej. Najważniejsze są cele, czas ich uzyskania.

Najważniejsze jest, żebyśmy my uzyskali to, po co te przedsięwzięcie robimy i żeby one były realizowane najefektywniej jak się da to zrobić. Przy samym wyborze myślę, że takim elementem, który często jest pomijany lub odwrotnie mówiąc rzadko się spotykam z takim spojrzeniem to jest kwestia stabilności i planów rozwojowych.

Tutaj szczególnie chodzi mi o kwestie narzędzia czy też oprogramowania, które planujemy wykorzystać, ponieważ niektórzy dostawcy oferując dzisiaj swój produkt wcale nie gwarantują nam w perspektywie 8-10 lat stabilnego rozwoju i zadbania o to narzędzie, ten produkt i nie dają nam chętnie gwarancji, że będzie on rozwijany utrzymywany czy też dostosowany do wymogów prawnych czy to polskich czy unijnych, czy jakichkolwiek innych.

Więc zweryfikowanie jaka jest planowana polityka producenta w kontekście danego narzędzia, przynajmniej warto jest o to zapytać żeby podejmując decyzję mieć świadomość jak to wygląda. Na polskim rynku dzisiaj mamy produkty które były sprzedawane, wdrażane 20-30 lat temu i są nadal utrzymywane, natomiast nie ma zbyt daleko idących inwestycji w te produkty i ja nie mówię, że to jest argument, żeby takich produktów nie wybierać, ale warto jest przynajmniej mieć świadomość, że takie coś może nas spotkać i po prostu się do tego przygotować.

Unikaj weryfikacji oczywistości

Drugą kwestią która już jest bardziej bliska nam samym naszemu przedsięwzięciu to jest kwestia weryfikowania przydatności narzędzia do naszych potrzeb. I tutaj od dość długiego czasu moim postulatem jest zawsze, żeby skupiać się na wybranych 10, może 15% szczególnych specjalnych dla nas potrzeb, funkcjonalności, które w największym stopniu odpowiadają za to, żeby nasze cele biznesowe zostały zrealizowane. Ponieważ weryfikowanie, najpierw definiowanie, a potem weryfikowanie 1500 wymogów funkcjonalnych, które z założenia w większości są realizowane jeżeli dany produkt funkcjonuje na polskim rynku, na naszym rynku, no to to jest uważam, że niecelowe.

Jeśli mamy tabelę 1500 wymagań w których są tak podstawowe rzeczy, jak możliwość obsługi prawnie wymaganych dokumentów, jeżeli to są najbardziej podstawowe wymogi, z którymi możemy się spotkać czy to w obszarze magazynów księgowości, środków trwałych, zakupów czy sprzedaży. A wiemy, że dany produkt funkcjonuje na polskim rynku od kilkunastu kilkudziesięciu lat, no to możemy podejrzewać dość swobodnie, że tego typu wymagania będą realizowane, będą obsługiwane w co najmniej w poprawny sposób. Więc zamiast skupiać się na weryfikacji długich list i weryfikować poszczególne czynności w systemie, ja zawsze proponuję skupić się na tych wybranych 7, 10 czy 15% funkcji, które są krytyczne dla sukcesu naszego przedsięwzięcia. Poświęcić na to mniej czasu, za to głębiej w to wejść, przedyskutować z dostawcą, przedyskutować z producentem jak te funkcje są realizowane, obejrzeć je już w takim najmniej powerpointowym, a bardziej żywym systemie. Wyrobić sobie zdanie na ile te funkcje będą wspierać nasze procesy, na ile procesy będą sprawniej przebiegać dzięki takiemu narzędziu.

I to jest moim zdaniem dużo bardziej efektywne, dużo więcej daje. Łatwiej i poprawniej jesteśmy w stanie dokonać selekcji tego oprogramowania niż w przypadku informacji, że z naszej listy punktów jeden system realizuje 96,5% a drugi 93,5% wymagań funkcjonalnych. Są to tak marginalne różnice, że trudno czasami w oparciu o takie podejście podjąć racjonalną decyzję.

Często się z tym spotykamy, że wrażenie jest takie, że oba systemy robią prawie to samo. Natomiast jak się przyjrzeć szczegółom to okazuje się, że tak do końca nie musi być.

Poznaj zespół projektowy

Kolejny punkt, to jest coś, co ja bardzo często zachęcam partnerów po drugiej stronie, to jest zapoznanie się z zespołem wdrożeniowym.

Warto jest poświęcić czas na poznanie ludzi. Nie przeczytanie ich doświadczeń, nie przeczytanie ich CV, tylko poznanie tych 4-5 kluczowych osób, które:

• będą potencjalnie z Państwem współpracować,
• które będą brały udział w projekcie,
• które będą definiować procesy w systemie,
• które będą właśnie odpowiadać za to, czy Wasze cele biznesowe zostaną zrealizowane i w jaki sposób.

Bardzo ważna jest wbrew pozorom chemia między osobami, które:

• mają współpracować ze sobą ponad rok,
• mają ze sobą dyskutować,
• mają ze sobą uzgadniać pewne kwestie, czasami się nie zgadzać, czasami wchodzić kolokwialnie mówiąc na kurs kolizyjny i to w jaki sposób jesteśmy w stanie się z nimi dogadać to w jaki sposób się komunikujemy, to w jaki sposób jesteśmy w stanie zarządzić tymi rozbieżnościami.

Będzie miało naprawdę gigantyczny wpływ na komfort współpracy w ramach projektu. Więc poświęcenie kilku godzin lub dwóch dni na to, żeby poznać tych ludzi, żeby zrozumieć ich sposób myślenia i sposób komunikacji, to nie jest czas stracony w żadnym wypadku. Czasami też warto jest porozumieć się z dostawcą i na przykład przesunąć trochę start, dostosować go do momentu dostępności tego zespołu, na którym nam najbardziej zależy, bo z nim nam się najfajniej współpracuje.

To już jest takie bardziej zaawansowane podejście, natomiast co najmniej poznanie tych ludzi co najmniej, przedyskutowanie ich sposobu pracy, ich praktyk to jest coś co bardzo, bardzo sugeruję i to się dobrze sprawdza. Potem dużo prościej jest się współpracować jest się komunikować w trakcie samego przedsięwzięcia.

Czego unikać przy wyborze systemu ERP

Nie porównuj nieporównywalnych ofert

To czego natomiast nie sugeruję, czy sugeruję tego nie robić, to jest porównywanie w jednym procesie organizacji o zupełnie różnym charakterze funkcjonowania. Czyli jeżeli szukamy Partnera do projektu wdrożenia systemu wspierającego obszar X w naszej organizacji, to nie powinniśmy wrzucać do jednego worka partnerów czy firm, które mają kompletnie inne profile.

Jeśli po jednej stronie będziemy mieli małą specjalistyczną spółkę, która zajmuje się tylko i wyłącznie tym obszarem i wybranym narzędziem, a po drugiej stronie będziemy mieli bardzo dużą organizację, która kompleksowo zajmuje się wdrożeniami, kompleksowo jest w stanie nas wesprzeć, to zarówno jeden, jak i drugi partner może być dla nas świetny, natomiast porównywanie ich jest niezmiernie trudne.

Będziemy mieli zupełnie inną strukturę kosztową, zupełnie inne podejście, bardzo często zupełnie inną metodykę pracy, bardzo często będzie to też zupełnie inna struktura organizacyjna po stronie dostawców. Także jeżeli mamy w jednym koszyczku podejście, w którym zakładamy zebranie specjalistów z rynku, czy też z tak zwanych firm body leasingowych, mamy w tym koszyczku też średniej wielkości lub małą firmę specjalistyczną i dużego potentata, który robi kompleksowe wdrożenia, to będziemy mieli tak różne oferty, że będzie nam niezmiernie trudno sensownie się po tych ofertach poruszać.

Każda z tych opcji i body leasing i firmy specjalistyczne i duzi partnerzy to są dobre ścieżki natomiast myślę, że warto najpierw podjąć decyzję z kim chcemy współpracować i dopiero z tej puli wybierać tego partnera,:

• który najlepiej spełnia nasze oczekiwania,
• z którym nam się najlepiej współpracuje,
• którego rozwiązanie jest najbardziej stabilne i długoterminowo dla nas bezpieczne, a zespół delegowany do naszego przedsięwzięcia najbardziej nam odpowiada.

Dlaczego doradca nie jest dobrym wyborem?

Ponownie – tutaj mamy kwestię, którą już poruszałem. To nie jest dobre miejsce, żeby delegować odpowiedzialność za prowadzenie procesu doboru na doradców. Bardzo szanuję doradców, często występuję w roli doradcy, natomiast tak jak opowiadałem w odcinku poświęconym tylko i wyłącznie doradcy (tu posłuchasz, tu przeczytasz), niech ten doradca nas nauczy jak mamy to robić, niech ten doradca pokaże nam dobre metody niech ten doradca przygotuje nam narzędzia, które pomogą nam zweryfikować dostawców. Natomiast prowadźmy ten proces doborowy, proces weryfikacyjny samemu, ponieważ to my będziemy z tymi ludźmi pracować, my będziemy z tym narzędziem się mierzyć w trakcie projektu wdrożeniowego.

A doradca – jego cele nie są zbieżne z naszymi celami. Nie on chce poprawiać zdolności produkcyjne, jego celem nie jest poprawienie zdolności produkcyjnych, jego celem nie jest zmniejszenie stanów magazynowych czy przyspieszenie procesów raportowych, tylko jego celem jest zarobienie pieniędzy na wspieraniu nas w procesie. Więc tutaj nasze cele z celami doradcy bardzo rzadko są zbieżne, chociaż oczywiście zdrowy rozsądek nakazywałby założenie, że powinni nas wspierać w sposób odpowiedzialny.

Natomiast, tak jak mówię, nauczmy się od nich, ale róbmy to samemu.

Uważaj na ukryte koszty

Kolejną kwestią jest kwestia ukrytych kosztów, ukrytych zagrożeń. Jak wybieramy dane rozwiązanie, czy wybieramy danego partnera, to warto jest też popatrzeć na to w perspektywie kosztów, których na pierwszy rzut oka nie widać. Czyli jeżeli mamy narzędzie, które jest tanie, ale wymaga bardzo dużych dostosowań, bardzo dużych modyfikacji, to ja nie mówię, że to jest zły wybór. Natomiast musimy mieć świadomość tego, że potem utrzymanie, wdrażanie nowych wersji w takiej sytuacji będzie dużo droższe niż w sytuacji gdybyśmy wybrali nieco droższe rozwiązanie na starcie, natomiast funkcjonalność, której potrzebujemy byłaby bardziej standardowa, bardziej, jak my to określamy przyszła z pudełka, czyli nie wymagała dodatkowych modyfikacji i rozwojów, które potrzebujemy zrobić w trakcie projektu.

To samo tyczy się tego, że w różnych technologiach na przykład koszt pracy konsultantów na rynku jest inny w technologii A, która jest popularna, dość prosta. Masowo stosowane te usługi mogą być istotnie tańsze niż w technologii B, która jest co prawda super niszowo specjalistyczna, ale za to bardzo mało osób o wysokich kompetencjach jest dostępnych na rynku, w związku z tym po pierwsze jest ich trudno pozyskać, po drugie są dużo drożsi.

Jeśli pomyślimy też o innych ukrytych kosztach, to możemy mieć na przykład bardzo fajne rozwiązanie, które wymaga bardzo specjalistycznej technologii, ponieważ jest przygotowane w oparciu o dedykowane narzędzia. I samo utrzymanie, administrowanie tym oprogramowaniem będzie wymagało stworzenia dedykowanego zespołu po naszej stronie, który będzie musiał się nauczyć tej nowej technologii, której dzisiaj nie mamy. Albo nawet nie jakoś specjalnie nowej ale po prostu takiej, z której nie korzystamy. Możemy mieć systemy bazodanowe oparte o producenta A lub B. Dzisiaj korzystamy z producenta A i jeżeli wdrożenie wymusi na nas stworzenie kompetencji w produkcie dostawcy B, no to jest to dodatkowy koszt, który na pierwszy rzut oka nie jest zawarty w naszej ofercie, w naszym projekcie wdrożeniowym. Natomiast ten koszt nas spotka wcześniej czy później. I to jest też punkt, który gdzieś tam powinniśmy uwzględnić sobie w liczeniu przychodu z naszej inwestycji o czym opowiadałem w odcinku dotyczącym określania celu i definiowania planowanego podejścia wdrożeniowego (posłuchasz tutaj, przeczytasz tutaj).

Nie przeciągaj decyzji

Warto jest też pamiętać o rzeczy dość niby prostej, natomiast wiele osób o tym zapomina, że przedłużający się proces decyzyjny opóźnia start projektu. Czyli jeżeli planujemy uruchomić system 1 stycznia zakładamy że system będziemy wdrażać 1,5 roku, no to przedłużanie procesu doborowego, próba znalezienia idealnego partnera, który nie będzie miał żadnych wad, co prawdopodobnie nie występuje na rynku, no to ten proces przedłużający się i potem skracający nam czas na prace projektowe i powodujące napięcia i powodujące gigantyczną presję w trakcie już samego projektu – to nie jest rozsądne podejście.

Dlatego uważam że czasami lepiej jest trochę skrócić proces doboru, trochę lepiej skrócić procesy weryfikacyjne, ale dać sobie czas na przeprowadzenie projektu zgodnie z racjonalnym harmonogramem A nie najpierw przedłużać dobór, przedłużać negocjacje, przedłużać ustalenia, a potem i zmuszenie i swojego, i zespołu projektowego, i zespołu projektowego dostawcy do pracy pod gigantyczną presją, w sytuacjach gdzie jakość i czas na przemyślenie jest naprawdę bardzo, bardzo przydatny.

Myśl o przyszłości – utrzymanie i rozwój systemu ERP

Taką rzeczą może nie jakąś super krytyczną ale też warto czasami o tym jest pomyśleć to jest kwestia tego, w jaki sposób planujemy utrzymywać w przyszłości system. Bo jeżeli planujemy budowę zespołu wewnętrznego, budujemy wewnętrzne kompetencje specjalistów, którzy mają się zajmować wdrożonym systemem, to bardzo istotne jest, żeby oni w jak największym stopniu uczestniczyli w projekcie wdrożeniowym.

I to oni powinni też uczestniczyć w procesie doboru i weryfikować partnera, z którym będziemy współpracować, a co najmniej uczestniczyć w tych spotkaniach gdzie dojdzie do zapoznania się z zespołem projektowym delegowanym przez dostawcę. Po to, żeby te osoby się po prostu po ludzku poznały. Te osoby będą ze sobą współpracować, te osoby z naszego zespołu będą przejmować wiedzę, będą budować swoją wiedzę i doświadczenia w oparciu o współpracę z zespołem projektowym dostawcy. Więc zarówno zaangażowanie ich od samego początku jak i danie im możliwości poznania osób, które zostaną delegowane do projektu wdrożeniowego jest bardzo istotnym elementem i warto o tym pamiętać.

Jeżeli natomiast zakładamy że realizacja prac utrzymaniowych będzie realizowana przez dostawcę zewnętrznego, to też jest często spotykany model, to warto jest od samego początku budować założenia jak ta współpraca docelowo ma wyglądać. Dlatego, że w zależności od tego jak chcemy sobie poukładać te procesy, jak ta komunikacja ma się odbywać, jak chcemy dokumentować zarówno kwestie zgłaszanych błędów jak i potrzeb rozwojowych, to to jest coś, czego się nie da ustalić, dogadać kolokwialnie mówiąc wynegocjować w bardzo, bardzo krótkim czasie.

Także warto jest myśleć o tym już od poziomu analizy chociażby po to, żeby ta dokumentacja, która będzie powstawała w trakcie projektu była jak najbardziej przydatna, jak najbardziej zrozumiała, jak najbardziej odpowiadająca naszym potrzebom i ułatwiająca potem współpracę z firmą, która ma nam świadczyć usługi utrzymaniowe i rozwojowe naszego systemu.

Także w zależności od tego, jak chcemy ten system po projekcie utrzymywać, to warto jest się skupić albo na budowie zespołu wewnętrznego, albo jak najszybszym uzgodnieniu zasad wsparcia oferowanego przez firmę wdrażającą lub też przez inną firmę, która potencjalnie mogłaby przejąć utrzymanie już po samym wdrożeniu.

Przykład z praktyki

Na koniec taka historia z życia. Przydarzyło mi się to kilkanaście lat temu. Było to bardzo ciekawe doświadczenie, był to najlepszy proces doborowy w którym brałem udział. Była to sytuacja, w której klient rozważał trzech dostawców na początku, potem zawęził to tak naprawdę do dwóch i cały proces doborowy polegał na tym, że z poziomu bardzo wysokiego kierownictwa, bo to byli członkowie, członek zarządu, dyrektor co najmniej jeden, a chyba dwóch nawet, poświęcili tydzień czasu na spędzenie u jednego z dostawców w biurze w laboratorium, gdzie zapoznali się z ludźmi, zapoznali się z zespołem, który miałby to realizować, zapoznali się dość dogłębnie z oprogramowaniem, poznali propozycję umów, poznali sposób pracy, metodykę pracy, podejście, harmonogram.

Bardzo głęboko w to weszli. Drugi tydzień spędzili u drugiego dostawcy i po tych dwóch tygodniach spędzili 2-3 dni na podjęcie decyzji z kim chcą współpracować. To był naprawdę jeden z najkrótszych procesów doborowych. Świetnie nam się to sprawdziło. Bardzo fajnie potem było negocjować, uzgadniać doprecyzować założenia.

Oni świetnie rozumieli jaki produkt dostaną. Oni świetnie rozumieli jego ograniczenia. Oni świetnie rozumieli jego mocne strony. Także można by powiedzieć, że po długim przygotowaniu wewnętrznym spędzili czas bardzo krótki z dostawcami, podjęli decyzję i w oparciu o to uruchomili projekt wdrożeniowy, który notabene zakończył się sukcesem a po kilku latach współpracy z nimi na tyle głęboko  zrozumieli produkt, że byli dla nas bardzo równorzędnym partnerem, z którym de facto wspólnie wymyślaliśmy jak przyszłe rollouty, jak przyszłe projekty rozwojowe mają być realizowane. I często to oni mieli lepsze pomysły jak ich specyfikę oddać w produkcie standardowym, a my się czasami od nich też uczyliśmy jak do tego podejść i to było naprawdę efektywne.

Podsumowanie

Na dziś to tyle. Jeśli byście chcieli zadać mi jakieś pytania prosić o rozszerzenie któregoś z tematów lub jakiekolwiek uwagi to zachęcam do kontaktu. Namiary są w opisie odcinka. Dziękuję i do usłyszenia.

W następnym odcinku porozmawiamy o tym, czym jest dobra umowa. Taka która nie tylko zabezpiecza interesy obu stron, ale też tworzy solidny fundament do udanej współpracy. Zastanowimy się także, jak prowadzić negocjacje, by po ich zakończeniu obie strony mogły z pełną energią i zaufaniem przystąpić do realizacji wspólnego projektu.

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.