Kto po stronie firmy odpowiada za wdrożenie CRM z ERP

Większość rozmów o wdrożeniu CRM zintegrowanego z ERP zaczyna się od pytania „co ten system będzie umiał". To złe pytanie na start. O tym, czy projekt się uda, w największym stopniu decyduje coś, co dzieje się po stronie firmy, a nie po stronie wykonawcy: kto w organizacji za ten projekt realnie odpowiada.

Firmy produkcyjne, handlowe i dystrybucyjne, które raz przeżyły wdrożenie „które utknęło", zwykle nie utknęły na technologii. Utknęły na tym, że nie było jasne, kto po ich stronie podejmuje decyzje, kto jest dostępny, kiedy trzeba coś potwierdzić, i kto przejmie system po zakończeniu prac. Ten artykuł opisuje, jakie role trzeba obsadzić we własnej firmie, zanim projekt ruszy, czym się od siebie różnią i co się dzieje, gdy którejś zabraknie. Piszemy o tym z perspektywy zarządczej, bo integracja ERP z CRM to nie zadanie techniczne do przekazania do działu IT. To projekt, którym ktoś w firmie musi pokierować.

Dlaczego o powodzeniu integracji ERP z CRM decyduje klient, a nie wykonawca?

Wykonawca odpowiada za konfigurację, mapowanie danych między systemami, testy i szkolenia. To jest do zaplanowania i do dowiezienia. Znacznie trudniej zaplanować to, na czym projekty realnie się zatrzymują: na decyzjach, które może podjąć wyłącznie klient, i na dostępności ludzi, którzy te decyzje podejmują.

Integracja ERP z CRM w firmie produkcyjnej dotyka procesu sprzedaży, danych finansowych, obiegu zamówień i tego, kto do jakich informacji ma dostęp. Żadnej z tych rzeczy wykonawca nie rozstrzygnie za firmę. Może zaproponować rozwiązanie, ale zatwierdzić je musi ktoś, kto rozumie, jak firma sprzedaje i jak chce sprzedawać. Jeśli tej osoby nie ma przy stole albo jest, ale nie ma czasu, projekt czeka. A projekt, który czeka, kosztuje: rosną koszty, gaśnie zaangażowanie zespołu, a firma zaczyna traktować wdrożenie jako coś, co „się ciągnie".

Wyjaśnienie

Integrując ERP z CRM, budujemy warstwę zarządczą nad ERP. ERP pozostaje źródłem prawdy o fakturach, zamówieniach i produktach, a CRM staje się miejscem, z którego zarządza się sprzedażą i przychodem. Decyzje o tym, jak ta warstwa ma wyglądać, są decyzjami biznesowymi, nie technicznymi. Dlatego to biznes, a nie dział IT, musi mieć nad nimi kontrolę.

Dlatego przygotowanie do integracji zaczynamy nie od pytania o funkcje systemu, tylko od pytania, kto po stronie firmy będzie tym projektem kierował. To nie jest formalność. To warunek, żeby w ogóle sensownie ruszyć.

Kto musi być po stronie firmy? Trzy role, bez których projekt staje

W praktyce potrzebne są trzy role. Nie muszą to być trzy osobne osoby w każdej firmie, ale każda z tych funkcji musi mieć właściciela, który wie, że za nią odpowiada. Poniższa tabela pokazuje, za co odpowiada każda z nich i co się dzieje, gdy zostaje nieobsadzona.

Koordynator projektu

To główny punkt kontaktu po stronie firmy. Osoba, która zbiera informacje wewnątrz organizacji, pilnuje, żeby ludzie pojawili się na warsztatach, i szybko reaguje, gdy pojawia się pytanie lub przeszkoda. Koordynator nie musi podejmować strategicznych decyzji, ale musi mieć do nich szybki dostęp. Jego rolą jest to, żeby projekt się nie zatrzymywał na drobiazgach.

Decydent biznesowy

To osoba, która zatwierdza kierunek: jak ma wyglądać proces sprzedaży, jaka jest architektura rozwiązania, kto ma widzieć jakie dane. Decydent akceptuje projekt, zanim zacznie się konfiguracja, i rozstrzyga sytuacje sporne. To zwykle ktoś z zarządu albo dyrekcji, kto ma mandat, żeby powiedzieć „tak, robimy to w ten sposób".

Administratorzy systemu

To ludzie, którzy będą CRM utrzymywać po zakończeniu projektu. Muszą uczestniczyć w konfiguracji i testach od początku, bo tylko wtedy zrozumieją, dlaczego system działa tak, jak działa. Jeśli dostaną gotowe rozwiązanie dopiero na końcu, firma zostaje z systemem, którego nikt wewnątrz nie umie rozwijać. Razem z nimi w warsztatach i testach akceptacyjnych powinien uczestniczyć zespół pilotażowy, czyli przyszli użytkownicy, którzy sprawdzą system na własnych procesach, zanim trafi on do całej firmy.

Uwaga

Brak dostępności którejkolwiek z tych ról nie jest niedogodnością organizacyjną, którą da się „jakoś obejść". To bloker harmonogramu. Projekt, który czeka na niedostępnego decydenta albo na przeciążonego koordynatora, nie idzie wolniej. On stoi.

Czym różni się koordynator od decydenta i dlaczego to nie ta sama osoba?

To najczęstsze uproszczenie i najczęstsza pułapka. Firmy zakładają, że jedna osoba pogodzi i bieżącą współpracę, i strategiczne decyzje. Zwykle kończy się to tak, że ta jedna osoba jest zbyt zajęta, żeby robić którąkolwiek z tych rzeczy dobrze.

Koordynator działa na poziomie operacyjnym i codziennym: odpowiada na pytania, umawia ludzi, przekazuje materiały. Decydent działa na poziomie zarządczym i rzadszym: akceptuje kierunek na kluczowych kamieniach milowych. To dwa różne rytmy pracy. Gdy łączy się je w jednej osobie, która ma jeszcze swoją normalną pracę, projekt zaczyna czekać na moment, w którym ta osoba będzie miała czas. A takich momentów bywa mało.

Dobrą praktyką jest rozdzielenie: koordynator dostępny na bieżąco plus decydent, który wchodzi w projekt w wyznaczonych punktach, żeby zatwierdzić najważniejsze rzeczy. Koordynator może eskalować do decydenta, gdy trzeba podjąć decyzję wykraczającą poza jego mandat. Dzięki temu projekt nie zatrzymuje się za każdym razem, gdy pojawia się coś ważnego.

Dlaczego administratorzy muszą być w projekcie od początku, a nie po uruchomieniu?

Kuszące jest myślenie: niech wykonawca wszystko skonfiguruje, a my przejmiemy gotowe. To podejście mści się później. System, który firma dostaje „pod klucz", bez udziału własnych administratorów, staje się czarną skrzynką. Gdy trzeba coś zmienić, dodać pole, poprawić raport, okazuje się, że nikt wewnątrz nie wie, jak system jest zbudowany i dlaczego.

Administratorzy, którzy uczestniczą w konfiguracji i testach od początku, uczą się systemu w trakcie jego powstawania. Rozumieją, skąd biorą się dane, jak działają automatyzacje i gdzie są granice rozwiązania. Po zakończeniu projektu firma nie jest zależna od wykonawcy przy każdej drobnej zmianie. To jest różnica między firmą, która ma CRM, a firmą, która ma CRM i umie z nim pracować.

Co się dzieje, gdy brakuje właściciela projektu?

Ten wzorzec widać w projektach wielokrotnie i wygląda za każdym razem podobnie. Gdy w firmie nie ma jasno wyznaczonego właściciela projektu, dzieje się jedna z dwóch rzeczy.

Pierwsza: decydent jest, ale niedostępny. Kluczowe rozstrzygnięcia wymagają jego zgody, a on jest na urlopie, w podróży albo po prostu zawsze zajęty. Zespół nie może ruszyć dalej, bo czeka na akceptację, której nie ma jak uzyskać. Projekt stoi nie dlatego, że coś jest technicznie trudne, tylko dlatego, że nie ma kto powiedzieć „tak".

Druga: właściciel jest formalnie wyznaczony, ale nie jest zaangażowany i nie deleguje. Nie ma czasu, nie przekazuje zadań dalej, a przez to cały harmonogram opiera się na jednej przeciążonej osobie. Ryzyko dla projektu rośnie, bo wszystko przechodzi przez wąskie gardło, które nie nadąża.

W obu przypadkach problem nie leży w narzędziu ani w wykonawcy. Leży w tym, że rola właściciela nie została obsadzona kimś, kto ma czas i mandat, żeby ją pełnić. Dlatego traktujemy brak dostępności kluczowych osób nie jako niedogodność, tylko jako realne ryzyko, które trzeba rozpoznać i rozwiązać, zanim projekt się zacznie.

Ile czasu naprawdę zajmuje to pracownikom firmy?

To pytanie pada często i jest uzasadnione. Zarząd boi się, że wdrożenie zje czas ludzi, których i tak jest za mało. Odpowiedź uczciwa brzmi: wymaga zaangażowania, ale przewidywalnego, jeśli role są dobrze obsadzone.

Koordynator jest zaangażowany przez cały projekt, ale w rytmie bieżącej współpracy, nie w trybie pełnego etatu. Decydent wchodzi punktowo, na kluczowych kamieniach milowych: zatwierdzenie kierunku, akceptacja architektury, odbiór. Administratorzy i zespół pilotażowy, który przetestuje system, angażują się mocniej w fazie warsztatów, testów i szkoleń. Największy błąd to niedoszacowanie tego zaangażowania i założenie, że „jakoś się to zrobi obok". Projekt, który nie ma zarezerwowanego czasu ludzi firmy, opóźnia się właśnie dlatego, że ten czas trzeba w końcu znaleźć, tyle że pod presją.

Wskazówka

Zarezerwuj okna czasowe kluczowych osób, zanim projekt ruszy, a nie w trakcie. Gdy z góry wiadomo, kto i kiedy jest potrzebny, warsztaty i decyzje nie zamieniają się w negocjacje o czyjś kalendarz.

Czy to projekt działu IT, czy zarządu?

Odruch wielu firm to potraktowanie integracji ERP z CRM jako tematu technicznego i przekazanie go do IT. To zrozumiałe, bo w grze są systemy, dane i mapowania. Ale to podejście prowadzi na manowce.

Dział IT jest niezbędny do części technicznej: dostępów, bezpieczeństwa, kwestii związanych z ERP. Nie jest jednak właściwym miejscem, żeby rozstrzygać, jak firma ma sprzedawać, jak wygląda jej proces sprzedaży i ofertowania czy kto ma widzieć marżę na karcie klienta. To są decyzje zarządcze i sprzedażowe. Jeśli projektem kieruje wyłącznie IT, powstaje system technicznie poprawny, ale oderwany od tego, jak firma naprawdę działa. Handlowcy go nie używają, bo nie odpowiada ich pracy, a zarząd nie ufa danym, bo proces nie odzwierciedla rzeczywistości.

Dlatego właścicielem projektu powinien być ktoś po stronie biznesu, z realnym mandatem, wspierany przez IT tam, gdzie trzeba. Integracja ERP z CRM jest projektem zarządczym, który ma techniczne elementy, a nie projektem technicznym, który przy okazji dotyka zarządzania.

Gdzie te role ustala się formalnie?

Ról nie zostawia się domyślności. Ustala się je i zapisuje, zanim zaczną się prace i zanim firma zdecyduje o zakupie licencji. Miejscem, w którym to robimy, jest Analiza Przedwdrożeniowa (APW). To etap poprzedzający właściwe wdrożenie, w którym rozpoznajemy proces sprzedaży firmy, jej dane i systemy, a przy okazji wskazujemy, kto po stronie klienta ma pełnić rolę koordynatora, decydenta i administratora.

Ustalenie ról na tym etapie ma dwie zalety. Po pierwsze, firma wie, kogo musi oddelegować i na jak długo, zanim podejmie zobowiązania finansowe. Po drugie, ewentualny problem z obsadą ról wychodzi na jaw wcześnie, gdy jeszcze da się go rozwiązać, a nie w połowie projektu, gdy zatrzymuje harmonogram. To jest sens robienia Analizy Przedwdrożeniowej przed zakupem: zdejmuje ryzyko, zamiast pozwalać mu się ujawnić w najgorszym momencie.

Od czego naprawdę zależy powodzenie integracji ERP z CRM?

Sprowadźmy to do jednego zdania: los projektu rozstrzyga się w strukturze odpowiedzialności, a nie na liście funkcji systemu. Firma, która wie, kto podejmuje decyzje, kto jest dostępny na co dzień i kto przejmie system po zakończeniu prac, wdraża przewidywalnie. Firma, która tego nie ustaliła, prędzej czy później zatrzymuje się na czekaniu, aż ktoś znajdzie czas.

Dlatego trzy role, koordynator, decydent i administratorzy, nie są pozycją do wpisania w dokument, tylko warunkiem kontroli nad projektem. Każda musi mieć właściciela, który ma i czas, i mandat. Im wcześniej te role zostaną nazwane, tym taniej kosztuje ewentualny problem z obsadą: rozpoznany na etapie Analizy Przedwdrożeniowej jest do rozwiązania, ujawniony w połowie wdrożenia zatrzymuje harmonogram. Kontrola nad integracją ERP z CRM zaczyna się więc nie od wyboru narzędzia, lecz od decyzji, kto po stronie firmy za nią odpowiada.

Najczęściej zadawane pytania

Kim jesteśmy

BusinessWeb to certyfikowany Partner HubSpot o najwyższym statusie Elite. Nasze doświadczenie obejmuje ponad 200 wdrożeń HubSpot, a 96% klientów, którzy wdrożyli HubSpot z nami, pozostaje z systemem. Partnerem HubSpot jesteśmy od 2018 roku.