Wdrożenie CRM w firmie – etapy, harmonogram i ryzyka

Wdrożenie CRM w firmie to projekt obejmujący analizę procesów sprzedaży i obsługi, konfigurację systemu, migrację danych, integracje z pocztą i systemem ERP, testy, szkolenia oraz start produkcyjny. W typowym projekcie trwa od 6 do 10 tygodni, a przy wielu działach i rozbudowanych integracjach od 3 do 6 miesięcy. O powodzeniu decydują trzy rzeczy: jakość danych przeniesionych do systemu, realnie zawężony zakres pierwszego etapu i adopcja po stronie zespołu, bo korzyści z wdrożenia CRM pojawiają się dopiero wtedy, gdy handlowcy pracują w systemie, a nie obok niego. Poniżej znajdziesz osiem etapów projektu z rezultatem każdego z nich, harmonogram w tabeli, podział ról między firmą a partnerem oraz macierz ryzyk z objawem i sposobem zapobiegania.

Czym jest wdrożenie CRM i co obejmuje

Wdrożenie systemu CRM to projekt, w którym firma opisuje swój proces sprzedaży i obsługi klienta, odwzorowuje go w systemie, przenosi do niego dane i uczy zespół pracy w nowym modelu. Zakres obejmuje siedem elementów, a instalacja oprogramowania jest z nich najkrótszym.

Każdy z tych elementów ma swojego właściciela i mierzalny rezultat, dlatego wdrożenie CRM Dynamics 365 czy dowolnej innej platformy prowadzi się jak projekt z harmonogramem i kryteriami odbioru, a nie jak zadanie dla działu IT.

Kiedy wdrożyć CRM, sygnały że arkusz przestał wystarczać

Moment na wdrożenie CRM przychodzi wtedy, gdy koszt chaosu w danych zaczyna przekraczać koszt systemu. Ten próg przekracza się po cichu, bo utracone szanse i godziny spędzone na szukaniu informacji nie mają osobnej pozycji w budżecie.

Trzy sygnały występujące jednocześnie oznaczają, że firma już płaci za brak systemu, tylko rozproszonymi kosztami. Jeśli sprzedajesz innym firmom, zestaw wymagań jest przy tym inny niż w sprzedaży konsumenckiej, co rozkładamy osobno w materiale o tym, jak wybrać CRM dla firmy B2B. Sam projekt, niezależnie od wybranej platformy, przebiega w ośmiu etapach.

Etapy wdrożenia CRM krok po kroku

Wdrożenie CRM przebiega w ośmiu etapach: analiza przedwdrożeniowa i mapowanie procesów, rejestr wymagań i wybór systemu, konfiguracja, migracja danych, integracje, testy akceptacyjne i pilotaż, go-live z hypercare oraz szkolenia i adopcja użytkowników. Kolejność jest stała, bo każdy etap korzysta z rezultatu poprzedniego.

Poniżej opisujemy cel każdego etapu, przebieg prac i rezultat, po którym poznasz, że etap faktycznie się zakończył. Jeśli szukasz przebiegu projektu tydzień po tygodniu na konkretnej platformie, opisaliśmy go osobno w materiale pokazującym przebieg wdrożenia platformy Microsoft w rozbiciu na tygodnie.

1. Analiza przedwdrożeniowa i mapowanie procesów

Celem analizy przedwdrożeniowej jest opisanie procesu, który system ma obsłużyć, i przełożenie go na listę wymagań. To jedyny etap, którego pominięcie przesądza o wyniku całego projektu, bo bez niego konfiguracja odtwarza domysły konsultanta zamiast realnej pracy zespołu.

Analiza procesów prowadzona jest trzema technikami naraz. Warsztaty z właścicielami procesów ustalają, jak sprzedaż i obsługa mają wyglądać docelowo, wywiady z użytkownikami pokazują, jak wyglądają dzisiaj, a przegląd obecnych arkuszy i raportów ujawnia, jakie dane firma faktycznie zbiera i czego nikt nie używa. Mapowanie prowadzi się na całej ścieżce od leada do faktury, czyli lead-to-cash, bo dopiero wtedy widać miejsca, w których informacja przestaje płynąć: między marketingiem a sprzedażą, między sprzedażą a realizacją oraz między realizacją a obsługą klienta. Rozbieżność między tym, co mówią właściciele procesów, a tym, co robią użytkownicy, jest najcenniejszym wynikiem tego etapu.

Rezultat etapu: model procesu docelowego w formie mapy oraz lista wymagań z przypisanymi właścicielami.

2. Rejestr wymagań i wybór systemu

Rejestr wymagań porządkuje wszystko, co system ma robić, i nadaje temu priorytety, zanim ktokolwiek zobaczy prezentację dostawcy. Bez rejestru wybór systemu CRM opiera się na wrażeniu z demo, a zakres projektu rozjeżdża się już w pierwszym miesiącu.

Rejestr rozdziela wymagania funkcjonalne, czyli co system ma umieć, od niefunkcjonalnych, czyli jak ma działać: czas odpowiedzi, dostępność, model uprawnień, zgodność z RODO, obsługa na urządzeniach mobilnych. Priorytety nadaje się metodą MoSCoW, która dzieli wymagania na cztery grupy: must have bez których start jest niemożliwy, should have ważne ale nieblokujące, could have do rozważenia przy zapasie czasu oraz won’t have świadomie wykluczone z tego etapu. Każde wymaganie z grupy must have dostaje kryterium akceptacji, czyli zdanie opisujące, co musi się wydarzyć, żeby uznać je za spełnione. Platformę ocenia się następnie w sześciu kryteriach: dopasowanie do opisanego procesu, integracje z systemami już używanymi w firmie, przewidywana adopcja, bezpieczeństwo i model uprawnień, koszt w trzech latach oraz dostępność partnera wdrożeniowego. Wybór między gotowym systemem a rozwiązaniem dedykowanym rozstrzyga zwykle stopień nietypowości procesu, a pełny rachunek kosztu posiadania rozkładamy w materiale o kryteriach decyzyjnych i TCO przy zmianie systemu CRM.

Rezultat etapu: zatwierdzony rejestr wymagań z priorytetami i kryteriami akceptacji oraz decyzja o platformie.

3. Konfiguracja systemu i wdrożenie etapowe

Konfiguracja przekłada rejestr wymagań na działające środowisko: obiekty i pola, etapy lejka sprzedaży, model uprawnień, automatyzacje oraz raporty. Pracuje się na środowisku testowym, oddzielonym od produkcyjnego, żeby zmiany można było cofać bez konsekwencji.

Najważniejsza decyzja tego etapu nie dotyczy ustawień, lecz zakresu pierwszego uruchomienia. Wdrożenie etapowe startuje od jednego procesu albo jednego działu, zwykle sprzedaży, i rozszerza zakres po ustabilizowaniu pierwszej fazy. Wdrożenie całościowe uruchamia wszystkie procesy naraz, co skraca projekt w teorii, ale mnoży liczbę jednoczesnych zmian, testów i szkoleń. Praktyka jest taka, że projekty całościowe wydłużają się przez kumulację błędów w testach, a etapowe kupują zespołowi czas na naukę kosztem dłuższego okresu pracy w dwóch systemach. Przy wielu integracjach i kilku działach model etapowy jest jedynym, który daje się dowieźć w zaplanowanym terminie. Konfigurację prowadzi się przy tym w granicach standardu platformy, bo każde odstępstwo od standardu jest kosztem powtarzanym przy każdej kolejnej aktualizacji systemu.

Rezultat etapu: skonfigurowane środowisko testowe odwzorowujące wymagania must have, gotowe do migracji danych.

4. Migracja danych do CRM

Migracja danych przenosi do systemu klientów, kontakty, historię transakcji i dokumenty z arkuszy oraz poprzedniego systemu, w stanie zweryfikowanym przez właścicieli tych danych. Jakość tego etapu decyduje o zaufaniu zespołu do CRM w pierwszym tygodniu pracy.

Etap składa się z sześciu kroków w stałej kolejności. Audyt danych pokazuje, co firma faktycznie posiada i w jakim stanie: ile rekordów ma puste pola wymagane, ile kontaktów nie ma przypisania do firmy, ile adresów jest nieaktualnych. Czyszczenie i deduplikacja usuwają powtórzenia i scalają rekordy dotyczące tego samego podmiotu, co przy danych z kilku arkuszy bywa najdłuższym elementem całego etapu. Mapowanie pól przypisuje każdą kolumnę źródłową do pola docelowego i ustala reguły przekształcenia, na przykład ujednolicenie formatu numerów NIP i telefonów. Migracja próbna przenosi niewielką, reprezentatywną partię i pozwala wychwycić błędy mapowania, zanim dotkną całości. Migracja właściwa uruchamiana jest w oknie bez pracy użytkowników. Weryfikacja końcowa polega na tym, że właściciele danych sprawdzają w systemie swoje własne rekordy i potwierdzają zgodność, bo nikt inny nie zauważy, że historia kontaktu z największym klientem urywa się dwa lata za wcześnie.

Zasada, która najbardziej skraca ten etap, brzmi: nie przenoś wszystkiego. Do systemu produkcyjnego trafiają dane aktywne, zwykle z ostatnich dwudziestu czterech miesięcy, oraz pełna historia klientów, z którymi firma nadal współpracuje. Resztę archiwizuje się poza CRM, z dostępem na żądanie. Przeniesienie kompletnej bazy sprzed dekady wydłuża migrację, obniża wydajność raportów i zasypuje handlowców rekordami, których nikt nigdy nie otworzy. Gdy migracja dotyczy istniejącego systemu z własnymi rozszerzeniami, osobnym zagadnieniem jest zachowanie tych modyfikacji, co opisujemy w materiale o przenoszeniu danych do chmury bez utraty wykonanych wcześniej customizacji.

Rezultat etapu: dane w CRM zweryfikowane i podpisane przez właścicieli, z raportem rozbieżności wobec źródła.

5. Integracje z pocztą, ERP i innymi systemami

Integracje łączą CRM z systemami, w których firma już pracuje, żeby handlowiec nie przepisywał danych między aplikacjami. W typowej firmie B2B jest ich pięć: poczta i kalendarz, komunikator zespołowy, system ERP, system księgowy oraz narzędzie marketing automation.

Integracja z pocztą i kalendarzem jest zwykle pierwsza i daje najszybszy efekt, bo korespondencja z klientem trafia na rekord konta bez kopiowania, a spotkania wiążą się z szansą sprzedaży. Połączenie z komunikatorem, na przykład Microsoft Teams, przenosi ustalenia z rozmów do systemu i powiadamia zespół o zmianach na transakcjach. Integracja CRM z ERP obejmuje kartotekę klientów, limity kredytowe, status zamówień, faktury oraz stany magazynowe, przy czym ERP pozostaje systemem źródłowym dla danych rozliczeniowych, a CRM odczytuje je i pokazuje handlowcowi w kontekście konta. System księgowy zasila CRM informacją o płatnościach, a marketing automation wymienia z nim leady i dane o aktywności kontaktów.

Technicznie realizuje się to na trzy sposoby: gotowym konektorem dostawcy, kiedy taki istnieje dla danej pary systemów, bezpośrednim połączeniem przez API, gdy wymagana jest własna logika, albo warstwą pośrednią typu iPaaS, gdy systemów jest więcej niż trzy i wymiana danych jest dwukierunkowa. Zakres i sposób integracji planuje się na etapie analizy, a nie po starcie produkcyjnym, bo integracja dołożona później wymaga zmian w modelu danych już wypełnionym rzeczywistymi rekordami.

Rezultat etapu: przetestowane przepływy danych w obu kierunkach, z udokumentowanym systemem źródłowym dla każdej wymienianej informacji.

6. Testy akceptacyjne i pilotaż

Testy akceptacyjne, w skrócie UAT, polegają na tym, że kluczowi użytkownicy przechodzą w systemie realne scenariusze od leada do zamówienia i potwierdzają, że działają zgodnie z kryteriami akceptacji z rejestru wymagań. Testuje biznes, nie dostawca.

Scenariusze pisze się na podstawie transakcji, które firma faktycznie prowadziła, razem z przypadkami trudnymi: klient z kilkoma oddziałami, oferta z rabatem wymagającym akceptacji, zamówienie częściowo zrealizowane, zgłoszenie serwisowe w trakcie negocjacji rozszerzenia. Każdy wykryty błąd trafia do jednej listy z priorytetem, a projekt rozróżnia błędy krytyczne blokujące pracę od usterek kosmetycznych, które można zamknąć po starcie. Pilotaż jest kolejnym krokiem i przenosi test z warunków laboratoryjnych do codziennej pracy: mała, reprezentatywna grupa, od trzech do pięciu osób z różnych ról, prowadzi przez dwa do trzech tygodni prawdziwe transakcje wyłącznie w nowym systemie. Pilotaż ma zamkniętą datę końcową i mierzalne kryteria ustalone przed startem, bo bez nich zamienia się w drugi system prowadzony równolegle w nieskończoność.

Rezultat etapu: zamknięta lista błędów krytycznych, potwierdzone kryteria akceptacji i decyzja go albo no-go dla startu produkcyjnego.

7. Go-live i hypercare

Go-live to moment, w którym system staje się jedynym miejscem pracy zespołu, a poprzedzają go cztery kryteria gotowości, które trzeba spełnić łącznie. Decyzję o starcie podejmuje właściciel projektu po stronie firmy, nie dostawca.

Kryteria gotowości są następujące. Po pierwsze, lista błędów krytycznych z testów akceptacyjnych jest zamknięta, a usterki niekrytyczne mają przypisany termin naprawy po starcie. Po drugie, dane są zmigrowane i sprawdzone przez właścicieli, z raportem rozbieżności zaakceptowanym przez biznes. Po trzecie, szkolenia dla wszystkich ról są zakończone, a nie zaplanowane. Po czwarte, gotowy jest plan wycofania opisujący, co zespół robi, jeśli po dwóch dniach okaże się, że system nie obsługuje procesu: kto podejmuje decyzję o powrocie, w jakim czasie i jak wracają dane wprowadzone w międzyczasie.

Sam start prowadzi się z poprzednim systemem przełączonym w tryb tylko do odczytu, zwykle na dwa do czterech tygodni. Powód jest praktyczny: zespół musi mieć dostęp do informacji, których nie objęła migracja, ale nie może mieć możliwości dalszego wprowadzania tam danych, bo wtedy firma prowadzi dwa równoległe źródła prawdy i żadne nie jest kompletne. Po starcie zaczyna się hypercare, czyli okres podwyższonego wsparcia, w którym konsultanci i administrator systemu są dostępni w trybie dyżuru, zgłoszenia od użytkowników obsługiwane są w ciągu godzin, a nie dni, i codziennie przeglądana jest lista problemów zgłaszanych z pracy produkcyjnej. Hypercare kończy się wtedy, gdy liczba zgłoszeń spada do poziomu obsługiwanego w normalnym trybie wsparcia, a nie po z góry ustalonej liczbie dni.

Rezultat etapu: system w codziennym użyciu jako jedyne źródło danych o kliencie, zgłoszenia obsługiwane na bieżąco, poprzedni system wyłączony.

8. Szkolenia i adopcja użytkowników

Szkolenia prowadzi się według ról i na realnych scenariuszach, bo handlowiec, menedżer, pracownik obsługi klienta i administrator używają tego samego systemu w zupełnie różny sposób. Szkolenie ogólne dla wszystkich naraz jest najczęstszą przyczyną niskiej adopcji CRM.

Handlowiec uczy się prowadzenia szansy sprzedaży, wystawiania oferty i pracy na urządzeniu mobilnym, na przykładach własnych klientów. Menedżer uczy się czytania pipeline, prognozy i raportów, oraz tego, jakich pytań nie musi już zadawać zespołowi. Obsługa klienta pracuje na kolejce zgłoszeń, priorytetach i terminach SLA. Administrator przechodzi przez model uprawnień, słowniki i obsługę zgłoszeń wewnętrznych. W każdym dziale warto wyznaczyć jednego lub dwóch championów CRM, czyli osoby, które przeszły rozszerzone szkolenie i stanowią pierwszą linię pomocy dla kolegów, bo pytanie zadane osobie z sąsiedniego biurka pada zawsze, a zgłoszenie do działu IT tylko czasem.

Adopcję mierzy się w trzech punktach kontrolnych. Po trzydziestu dniach sprawdza się odsetek aktywnych użytkowników logujących się co najmniej raz dziennie oraz udział transakcji prowadzonych wyłącznie w systemie. Po sześćdziesięciu dniach kompletność danych na rekordach, czyli odsetek szans z uzupełnionymi polami wymaganymi i aktualną datą kolejnego kontaktu. Po dziewięćdziesięciu dniach liczbę raportów generowanych samodzielnie przez menedżerów oraz liczbę procesów nadal prowadzonych poza systemem. Ostatni wskaźnik jest najważniejszy, bo każdy arkusz utrzymywany równolegle po trzech miesiącach oznacza konkretną funkcję, której system nie obsługuje albo obsługuje gorzej niż poprzednie narzędzie.

Rezultat etapu: mierzone wskaźniki adopcji w punktach 30, 60 i 90 dni oraz lista funkcji do korekty wynikająca z procesów prowadzonych poza systemem.

Harmonogram wdrożenia CRM, ile trwa każdy etap

Typowy projekt wdrożenia CRM w małej i średniej firmie trwa od 6 do 10 tygodni, a projekt obejmujący kilka działów i rozbudowane integracje od 3 do 6 miesięcy. Różnica nie wynika z wielkości zespołu, lecz z liczby systemów, które muszą wymieniać dane, i z liczby decyzji do podjęcia po stronie firmy.

Harmonogram wydłużają trzy rzeczy, a technologia nie jest żadną z nich. Pierwsza to stan danych: baza z duplikatami i brakami w polach wymaganych potrafi wydłużyć etap migracji dwukrotnie wobec pierwotnego założenia, bo czyszczenia nie da się zautomatyzować bez decyzji merytorycznych. Druga to tempo decyzji po stronie firmy, ponieważ każdy tydzień zwłoki w zatwierdzeniu modelu procesu lub rejestru wymagań przesuwa wszystkie kolejne etapy. Trzecia to integracje, zwłaszcza z systemami starszymi lub mocno zmodyfikowanymi, gdzie rozpoznanie sposobu wymiany danych bywa dłuższe niż samo jej uruchomienie.

Kto odpowiada za co, role po stronie firmy i partnera

Projekt wdrożenia CRM ma jednego właściciela po stronie firmy, który podejmuje decyzje zakresowe i rozstrzyga spory między działami w ciągu jednego dnia roboczego. Partner odpowiada za to, jak system ma działać, ale nie za to, jak firma ma pracować.

Rozmycie tej granicy jest powodem większości konfliktów w projektach. Partner nie rozstrzygnie, czy rabat zatwierdza dyrektor sprzedaży, czy zarząd, ani kto odpowiada za jakość danych o kliencie, bo to decyzje organizacyjne. Firma z kolei nie powinna projektować modelu uprawnień ani wybierać metody integracji, bo to kompetencja techniczna. Pytanie o to, jak wybrać partnera do wdrożenia CRM, sprowadza się w praktyce do sprawdzenia, czy dostawca potrafi tę granicę nazwać na pierwszym spotkaniu i czy ma realizacje w podobnym procesie, a nie tylko w podobnej branży.

Najczęstsze ryzyka wdrożenia CRM i jak im zapobiec

Wdrożenia CRM rzadko upadają przez technologię, częściej przez zakres, dane i ludzi. Każde z poniższych ryzyk ma objaw widoczny na długo przed porażką projektu oraz etap, na którym reakcja jest jeszcze tania.

Ryzyka z tej listy mają wspólną cechę: wszystkie są tańsze do usunięcia na etapie analizy niż po starcie produkcyjnym. Nieudane wdrożenie CRM prawie nigdy nie zaczyna się od awarii systemu, tylko od decyzji odłożonej na później, która wraca kilka etapów dalej z odsetkami.

Etapy, harmonogram i ryzyka opisują projekt od strony przebiegu. Trzy pytania wracają jednak niezależnie od tego, na którym etapie jest firma: ile to kosztuje, co zrobić, gdy system już działa, ale nie przynosi efektów, oraz czym różni się wdrożenie dla działu obsługi klienta.

Ile kosztuje wdrożenie CRM

Koszt wdrożenia CRM składa się z siedmiu pozycji: licencji rozliczanych za użytkownika, analizy przedwdrożeniowej, konfiguracji systemu, migracji danych, integracji, szkoleń oraz utrzymania i wsparcia po starcie. Proporcje między nimi zmieniają się wraz ze skalą projektu, bo w małym wdrożeniu dominują licencje i konfiguracja, a w projekcie z kilkoma integracjami największą pozycją stają się prace integracyjne i migracja danych. Rynkowe widełki są przy tym mało użyteczne jako punkt odniesienia, ponieważ ten sam system w dwóch firmach o podobnej wielkości potrafi kosztować kilkukrotnie różnie, zależnie od liczby systemów do połączenia i stanu danych źródłowych. Zamiast operować kwotą oderwaną od kontekstu, własny scenariusz policzysz w kalkulatorze wyceny wdrożenia CRM, a pełne zestawienie składników kosztu rozkładamy w osobnym materiale o tym, ile kosztuje CRM. Warunki licencyjne warto weryfikować bezpośrednio w oficjalnym cenniku dostawcy, bo modele rozliczeń zmieniają się kilka razy w roku.

Co zrobić, gdy wdrożenie CRM nie przynosi efektów

Objawy nieudanego wdrożenia są rozpoznawalne i pojawiają się zwykle między drugim a szóstym miesiącem po starcie: handlowcy wracają do arkuszy, dane w raportach nie zgadzają się z tym, co zespół mówi na odprawie, a pola wymagane wypełniane są byle czym, żeby przejść dalej. Przyczyna leży najczęściej w rozjeździe między procesem opisanym na etapie analizy a tym, jak firma faktycznie pracuje, albo w danych, którym zespół przestał ufać po pierwszym błędnym raporcie.

Naprawa przebiega w czterech krokach. Krok 1, audyt. Sprawdzasz, które procesy faktycznie idą przez system, a które omijają go w praktyce, i zestawiasz to z konfiguracją oraz jakością danych; audyt wdrożenia CRM kończy się listą rozbieżności z priorytetami, nie oceną ogólną. Krok 2, szybkie usprawnienia. Usuwasz pola wymagane bez odbiorcy, upraszczasz najczęściej używane widoki i naprawiasz raport, który jako pierwszy podważył zaufanie do danych; efekt musi być widoczny dla zespołu w ciągu dwóch tygodni, bo to on odbudowuje wiarygodność projektu. Krok 3, naprawa średnioterminowa. Korygujesz model procesu tam, gdzie system wymusza pracę niezgodną z rzeczywistością, domykasz brakujące integracje i czyścisz dane, które psują raportowanie. Krok 4, stabilizacja. Ustawiasz stały rytm przeglądu wskaźników adopcji i obsadzasz administratora po stronie firmy, żeby zmiany nie wymagały zlecenia za każdym razem. Szerzej o odbudowie zaufania zespołu do systemu piszemy w materiale o roli adopcji w ratowaniu wdrożenia CRM.

Wdrożenie CRM w obsłudze klienta, czym się różni

Wdrożenie CRM dla działu obsługi klienta dokłada do projektu pięć elementów, których nie ma w projekcie czysto sprzedażowym: kanały kontaktu, kolejki zgłoszeń, terminy SLA, bazę wiedzy oraz portal klienta. Zmienia to punkt ciężkości analizy, bo zamiast procesu od leada do zamówienia mapuje się ścieżkę zgłoszenia od wpłynięcia do zamknięcia, z regułami przydziału i eskalacji. Obsługa omnichannel wymaga przy tym decyzji, które kanały trafiają do wspólnej kolejki, a które pozostają poza systemem, oraz jak liczy się czas reakcji, gdy zgłoszenie przychodzi po godzinach pracy.

Uruchomienie sprzedaży i obsługi na jednej bazie klientów skraca drogę od podpisania umowy do pierwszego zgłoszenia, bo konto klienta, warunki kontraktu i historia negocjacji są widoczne dla zespołu serwisu bez pytania handlowca. Działa to również w drugą stronę: sprzedaż widzi otwarte eskalacje przed rozmową o rozszerzeniu współpracy i wie, kiedy taka rozmowa nie ma sensu. Dla firm, które chcą zbudować ten obszar świadomie, punktem wyjścia jest wdrożenie systemu do obsługi zgłoszeń z kolejkami i SLA pracującego na tej samej bazie klientów co sprzedaż.

Najczęściej zadawane pytania o wdrożenie CRM

Odpowiedzi na pytania, które najczęściej wracają w rozmowach z firmami planującymi lub prowadzącymi projekt wdrożenia CRM.