Dlaczego wdrożenia CRM i ERP kończą się niepowodzeniem — i co naprawdę jest tego przyczyną

Każda organizacja ma jakiś podział na tych, którzy sprzedają i tych, którzy realizują. W firmach usługowych to handlowcy i project managerowie. W produkcji – dział sprzedaży i produkcja. W SaaS – sales i customer success. Nazwy są różne, mechanizm identyczny.

Sprzedaż jest rozliczana z tego, co podpisze. Revenue, liczba kontraktów, wartość pipeline’u. To są cele mierzalne, twarde, rozliczalne co kwartał. W takiej logice każda dobita umowa jest sukcesem – niezależnie od tego, co obiecano i czy da się to dostarczyć.

Delivery jest rozliczane z tego, co dostarczy. Terminowość, budżet, jakość, satysfakcja klienta. I przejmuje projekt, który sprzedaż zostawiła – razem ze wszystkimi zobowiązaniami złożonymi w ferworze negocjacji, które niekoniecznie były konsultowane z kimkolwiek po stronie realizacji.

Obydwa działy działają racjonalnie względem swoich celów, a problem leży właśnie w tym, że te cele są rozbieżne. Gdy patrzysz na to przez pryzmat teorii zarządzania, nie ma w tym nic zaskakującego – od lat sześćdziesiątych wiemy, że ludzie optymalizują pod to, za co są rozliczani, i że asymetria celów między różnymi funkcjami w organizacji generuje dokładnie takie zachowania, jakie tu opisuję. Jensen i Meckling opisali ten mechanizm formalnie w 1976 roku jako problem principal-agent

principal-agent problem

– i choć pisali o właścicielach i menedżerach, mechanizm jest dokładnie ten sam.

Bardzo podobna dynamika działa między

sprzedażą a marketingiem

– i jest równie kosztowna, choć rzadziej kojarzona z niepowodzeniami wdrożeń. Marketing bez dostępu do danych z CRM nie wie, które segmenty faktycznie konwertują, jakie obiekcje pojawiają się najczęściej ani czego klienci szukają tuż przed decyzją zakupową. Sprzedaż rzadko artykułuje swoje potrzeby komunikacyjne, bo nikt tego nie wymaga i nie mierzy. Efekt jest przewidywalny: marketing wysyła generyczne komunikaty, handlowcy narzekają na słabą jakość leadów, a dwa działy, które powinny działać jak zazębiające się koła zębate, pracują obok siebie – każdy pod własne KPI, bez wspólnego języka i wspólnych danych.

W większości organizacji brakuje formalnego, zdefiniowanego momentu, w którym projekt przechodzi ze sprzedaży do delivery. Jest e-mail, jest spotkanie kick-off, jest (jeśli szczęście dopisze) jakiś dokument z wersją oferty. Brakuje ustrukturyzowanego procesu, który określa: to są dane, które muszą być kompletne, to są zobowiązania, które muszą być potwierdzone, i dopiero wtedy projekt może wystartować.

W efekcie delivery zaczyna od odkrywania tego, co sprzedaż zdążyła uzgodnić. Zakres bywa „żywy” jeszcze w trakcie podpisywania umowy. Obietnice złożone klientowi istnieją w głowie handlowca i w mailach, nie w systemie. I każdy projekt startuje z deficytem informacji, który trzeba odrobić.

To jest błąd procesu – a właściwie jego braku. Wynikający wprost z faktu, że nikt nie miał interesu w tym, żeby ten moment zdefiniować. Sprzedaż miała interes w podpisaniu. Delivery miało interes w realizacji. Interfejs między nimi należał do nikogo.

Wyobraź sobie, że chcesz wdrożyć CRM zintegrowany z ERP. Albo platformę projektową połączoną z systemem rozliczeń. Albo jakikolwiek system, który ma wspierać organizację od początku do końca procesu – od lead’a po fakturę.

Taki system potrzebuje jednego spójnego modelu danych. Klient to klient – jeden rekord, jeden identyfikator, jedna historia. Projekt to projekt – zakres, wartość, status, zasoby, terminy. Te pojęcia muszą znaczyć to samo w CRM, w ERP, w systemie rozliczeń i w narzędziu projektowym.

W organizacji, gdzie sprzedaż i delivery żyją w odrębnych światach, te pojęcia mają różne znaczenia. „Wartość kontraktu” dla handlowca to liczba z oferty, dla project managera to rzeczywisty budżet do zrealizowania. „Status projektu” closed-won oznacza dla sprzedaży zamkniętą sprawę, a dla delivery – dopiero punkt startowy.

W 1967 roku informatyk Melvin Conway sformułował obserwację, która dziś nosi jego imię:

Prawo Conwaya

mówi, że organizacje projektują systemy będące kopią swojej własnej struktury komunikacyjnej. Jeśli sprzedaż i delivery nie rozmawiają ze sobą i mają rozbieżne cele, system odwzoruje tę fragmentację. CRM będzie narzędziem sprzedaży. ERP będzie narzędziem delivery. Oba będą ze sobą technicznie połączone, ale semantycznie rozbieżne – co w praktyce oznacza, że dane trzeba przepisywać, słowniki mapować ręcznie, a raporty z jednego systemu nie zgadzają się z raportami z drugiego.

To samo dotyczy integracji CRM z narzędziami marketingowymi. Jeśli marketing i sprzedaż nie mają wspólnie zdefiniowanych pojęć – czym jest „kwalifikowany lead”, co oznacza „gotowość do zakupu”, kiedy kontakt staje się szansą – żadna integracja techniczna tego nie naprawi. Można połączyć systemy, ale dane nie zaczną znaczyć tego samego, gdy ludzie po obu stronach rozumieją je inaczej.

Przez lata analizy przedwdrożeniowe skupiały się na zbieraniu wymagań funkcjonalnych. „Czego potrzebuje sprzedaż?” – pytano sprzedaż. „Czego potrzebuje delivery?” – pytano delivery. I każdy odpowiadał przez pryzmat swoich celów i procesów. Wymagania były kompletne z perspektywy każdego działu z osobna, ale nikt nie zadał pytania: czy te wymagania są ze sobą kompatybilne?

Żeby zadać takie pytanie, trzeba patrzeć na proces jako całość. A to wymaga kogoś, kto rozumie zarówno CRM, jak i ERP – kogoś, kto potrafi usiąść z klientem i zmapować drogę od pierwszego kontaktu do zapłaconej faktury bez szufladkowania na „część sprzedażową” i „część operacyjną”.

Dla nas ten punkt zwrotny przyszedł wtedy, gdy połączyliśmy kompetencje CRM i ERP w jednej rozmowie z klientem – jako jeden proces, a nie dwa osobne projekty wdrożeniowe. Zaczęliśmy widzieć rzeczy, które wcześniej ginęły w szczelinach między silosami: niekompletne dane na handoffie, pola o identycznych nazwach w obu systemach mające różne definicje, raporty, które każdy dział uważa za „prawdziwe”, a które pokazują różne liczby o tym samym.

Z naszych doświadczeń wynika jedna prosta, choć niepopularna konkluzja:

nie da się zbudować systemu IT wspierającego całą organizację, jeśli na poziomie celów mamy rozbieżność między kluczowymi funkcjami.

Systemy można połączyć kablami, integracje można zakodować, API można napisać. Sprzecznych modeli świata skleić się nie da. Gdy sprzedaż jest rozliczana wyłącznie z liczby i wartości podpisanych kontraktów, a delivery z jakości i terminowości realizacji, mamy dwa działy, które strukturalnie muszą ze sobą rywalizować, zamiast współpracować.

Rozwiązanie leży po stronie organizacyjnej. Sprzedaż musi mieć w swoich celach coś, co łączy ją z jakością przekazywanego projektu – choćby margin at delivery, NPS klienta po 3 miesiącach od startu, albo formalny sign-off delivery przed zamknięciem szansy w CRM. Delivery musi rozumieć, że projekt był sprzedawany w określonym kontekście i z określonymi oczekiwaniami klienta.

Analogicznie: gdy marketing odpowiada też za jakość leadów mierzoną przez sprzedaż, a sprzedaż ma obowiązek zwrotnego feedbacku do marketingu – obydwa działy zaczynają pracować na wspólny wynik. Dopiero wtedy wspólny system (CRM, marketing automation, analityka) ma szansę działać tak, jak powinien.

Wspólne, kaskadowane cele obejmujące wiele działów są warunkiem technicznej wykonalności wdrożenia. Gdy wymagania funkcjonalne zbierane przez obie strony wynikają ze sprzecznych priorytetów, system staje się polem kompromisów, który nie służy w pełni nikomu.

Zanim zacznie się jakiekolwiek wdrożenie, warto zadać trzy pytania:

Jak wygląda u was proces lead-to-cash jako całość?

Nie po działach, ale end-to-end – od pierwszego kontaktu do zapłaconej faktury. Jeśli nikt nie potrafi tego narysować bez zatrzymywania się na granicy sprzedaż/delivery, to właśnie znalazłeś główne ryzyko projektu.

### Czym są rozliczani ludzie po obu stronach tej granicy?

Cele czysto ilościowe po stronie sprzedaży i czysto jakościowe po stronie delivery to sygnał, że przed wdrożeniem systemu warto porozmawiać o KPI. System nie naprawi tego, co jest zepsute na poziomie motywacji. To samo dotyczy relacji marketing–sprzedaż: jeśli marketing nie ma wglądu w dane CRM i nie jest rozliczany z jakości leadów, żadne narzędzie marketing automation tego nie zmieni.

### Kto jest właścicielem danych na przejściu?

Single source of truth to kwestia odpowiedzialności organizacyjnej, nie architektury technicznej. Kto odpowiada za to, że dane w momencie handoffu są kompletne, poprawne i gotowe do użycia przez kolejny dział?

Te pytania powinny poprzedzać analizę przedwdrożeniową. Jeśli odpowiedzi są niejasne, analiza zbierze wymagania będące symptomem problemu, a nie jego rozwiązaniem.

Większość wdrożeń ma swój moment krytyczny znacznie wcześniej, niż myślimy – zanim ktokolwiek zaloguje się do systemu po raz pierwszy. System IT jest lustrem, w którym wewnętrzna rozsynchronizacja organizacji staje się w końcu widoczna. I zazwyczaj boleśnie droga.

Jeśli chcesz sprawdzić, czy Twoja organizacja jest gotowa na wdrożenie – zanim zainwestujesz w licencje i miesiące pracy –

porozmawiajmy

. Często godzina szczerej rozmowy oszczędza rok kosztownych korekt.