Od czego powinien zacząć się projekt CRM?
Dobry projekt CRM powinien zacząć się od problemu biznesowego, który firma chce rozwiązać, a nie od stwierdzenia „potrzebujemy CRM”. Rzeczywistym problemem może być słaba widoczność lejka sprzedażowego, brak konsekwencji w działaniach następczych, niespójne etapy sprzedaży, niejasna odpowiedzialność za klientów, niskie zaufanie do danych albo brak wspólnego obrazu aktywności związanych z klientem.
To rozróżnienie ma znaczenie.
Kiedy zarząd mówi „potrzebujemy CRM”, brzmi to jak opis wymagań. W rzeczywistości często jest to jedynie objaw. Określa kategorię rozważanego systemu, ale nie wskazuje problemu operacyjnego, która stoi za tą potrzebą.
Jedna firma może potrzebować lepszej kontroli nad nowymi zapytaniami. Inna może potrzebować sprawniejszego przekazywania klientów z działu sprzedaży do zespołu wykonawczego. Jeszcze inna może potrzebować wiarygodnego śledzenia aktywności, ponieważ zbyt duża część wiedzy o klientach znajduje się w prywatnych skrzynkach e-mail, arkuszach kalkulacyjnych i osobistych notatkach. I wszystkie te trzy firmy mogą mówić, że potrzebują CRM. To jednak nie oznacza, że potrzebują takiego samego projektu.
To w tym miejscu projekty CRM często zaczynają zbaczać z właściwego kursu. Zespół zaczyna rozmawiać o polach, dashboardach, automatyzacjach, integracjach i licencjach, zanim uzgodni, co dokładnie powinno poprawić się w sposobie działania firmy.
Mitem jest przekonanie, że niepowodzenie projektu CRM wynika głównie z problemów z oprogramowaniem. Znacznie częściej wynika ono z niewłaściwego zdefiniowania problemu.
CRM nie powinien być traktowany jako cyfrowa książka adresowa ani miejsce służące wyłącznie do „przechowywania kontaktów”. W organizacjach, w których sprzedaż odgrywa kluczową rolę, szczególnie w produkcji, dystrybucji i innych sektorach opartych na relacjach, CRM powinien działać jako wspólna warstwa operacyjna do pracy z klientami. Powinien pokazywać, kto odpowiada za relację, co już się wydarzyło, jakie działanie należy wykonać w następnej kolejności, na jakim etapie znajdują się szanse sprzedaży oraz gdzie narasta ryzyko biznesowe.
Przed wyborem lub konfiguracją systemu CRM kadra zarządzająca powinna przeanalizować obecny model działania sprzedaży:
- Czy problemem jest brak dyscypliny procesowej?
- Czy problemem są słabej jakości lub niekompletne dane klientów?
- Czy problemem jest niejasna odpowiedzialność?
- Czy problemem jest niespójne prowadzenie działań follow-up?
- Czy problemem jest niedopasowanie systemu, ponieważ obecne narzędzia nie wspierają już sposobu, w jaki firma obecnie sprzedaje?
Takie pytania zapobiegają sytuacji, w której projekt zbyt wcześnie zaczyna koncentrować się na funkcjach systemu.
Klasyczna analiza niepowodzeń projektów CRM opublikowana przez „Harvard Business Review” ostrzegała, że wielu menedżerów traktuje CRM jak oprogramowanie, które samo będzie zarządzać relacjami z klientami, zamiast postrzegać je jako strategię i procesy obsługi klienta wspierane przez technologię. W analizie wskazano również, że 55% projektów CRM nie przyniosło oczekiwanych rezultatów.
Płynący stąd wniosek nie prowadzi do unikania CRM. „Ale chodzi o to, aby zacząć we właściwym miejscu.
Bezpieczniejsze wdrożenie CRM zaczyna się od przekształcenia ogólnego oczekiwania w jasno opisany problem biznesowy. Na przykład:
„Nie możemy ufać naszej prognozie sprzedaży, ponieważ szanse sprzedaży są aktualizowane w niespójny sposób, odpowiedzialność za kontakt po wysłaniu oferty nie jest jasno określona, a kluczowe informacje o aktywności klientów są rozproszone pomiędzy skrzynkami e-mail i arkuszami kalkulacyjnymi”.
Takie stwierdzenie nadaje projektowi kierunek. Pokazuje firmie, co CRM powinien naprawić w pierwszej kolejności. Chroni również zakres projektu, budżet i poziom adopcji, ponieważ każdą kolejną decyzję można ocenić za pomocą tego samego pytania: czy pomaga ona rozwiązać rzeczywisty problem sprzedażowy?
Co liderzy naprawdę próbują naprawić za pomocą CRM?
Liderzy zazwyczaj pytają o CRM, ponieważ chcą mieć większą kontrolę nad wynikami sprzedaży. Praktyczną potrzebą rzadko jest samo przechowywanie kontaktów. Chodzi o wiarygodny obraz lejka sprzedażowego, jaśniejszą odpowiedzialność, konsekwentne działania następcze, lepsze prognozowanie oraz jedno miejsce, w którym można zobaczyć aktywność klientów bez przeszukiwania pięciu różnych źródeł.
Z tych powodów projekt CRM powinien być definiowany przez pryzmat kontroli nad procesem sprzedaży.
W Dynamics 365 CRM kontrola ta opiera się na kilku podstawowych zasadach: jasno zdefiniowanych etapach sprzedaży w przepływie procesu biznesowego, obowiązkowych danych w kluczowych momentach procesu, rejestrowaniu aktywności za pomocą Outlooka i Teams oraz standardowych widokach lejka sprzedażowego, z których menedżerowie sprzedaży korzystają podczas regularnych przeglądów.
W wielu firmach obraz sprzedaży jest „składany” ręcznie. Prognoza pochodzi z jednego arkusza kalkulacyjnego. Historia ofert znajduje się w kolejnym folderze. Ustalenia z klientami są ukryte w wiadomościach e-mail. Notatki ze spotkań znajdują się w Teams, notesach albo w pamięci poszczególnych osób. Menedżer sprzedaży może znać prognozowaną wartość sprzedaży, ale niekoniecznie wie, na ile można jej ufać.
CRM oparty na Dynamics 365 powinien przenieść te informacje do Dataverse, które będzie jednym źródłem prawdy. Dzięki temu dane dotyczące lejka sprzedażowego i aktywności nie będą już rozproszone pomiędzy arkuszami kalkulacyjnymi i skrzynkami e-mail.
W efekcie często pojawia się znany schemat: przeglądy lejka sprzedażowego stają się spotkaniami służącymi zbieraniu informacji o statusie, zamiast spotkaniami, podczas których podejmuje się decyzje. Liderzy pytają, co się zmieniło. Handlowcy opisują to, co pamiętają. Firma kończy spotkanie z większą liczbą informacji o wykonanych działaniach, ale nie zawsze z większą jasnością sytuacji.
Bain ustalił, że ponad 80% badanych firm deklarowało prowadzenie uporządkowanych działań sprzedażowych i marketingowych. Jednocześnie 70% z nich nie integrowało skutecznie swoich scenariuszy sprzedażowych z CRM lub technologiami wspierającymi przychody, a pełną wartość z tych rozwiązań uzyskiwało jedynie około 20% organizacji.
Dokładnie tę lukę wiele projektów CRM próbuje w rzeczywistości zamknąć: różnicę pomiędzy posiadaniem określonego podejścia do sprzedaży, a posiadaniem tego podejścia w systemie, w formie widocznej, użytecznej i objętej jasnymi zasadami zarządzania.
Dobry projekt Dynamics 365 CRM powinien ułatwiać realizację przyjętego modelu sprzedaży. Oznacza to zdefiniowane etapy, jasne kryteria zakończenia każdego etapu, zasady działań follow-up, rejestrowanie aktywności, przeglądy kondycji lejka oraz raportowanie odzwierciedlające rzeczywiste zachowania, a nie niekompletne rekordy.
Słabe dane wejściowe a ryzyko biznesowe
W każdym systemie CRM, a szczególnie w Dynamics 365, gdzie raportowanie i sztuczna inteligencja opierają się na wiarygodnych danych z Dataverse, słabe dane wejściowe w procesie sprzedaży szybko przekształcają się w ryzyko biznesowe.
Nie mówimy tutaj o kontrolowaniu każdego ruchu wykonywanego przez handlowca. Chodzi o usunięcie niepotrzebnych niejasności z pracy, która już teraz wpływa na przychody, marżę i doświadczenie klienta.
Rozmowa o CRM staje się znacznie bardziej użyteczna, gdy wychodzimy od pytania:
„Które decyzje podejmujemy obecnie wolniej lub gorzej, ponieważ nie jesteśmy w stanie wystarczająco szybko zobaczyć prawdziwego obrazu sytuacji?”.
Dla części firm pierwszym sukcesem będzie stworzenie jednego źródła prawdy o lejku sprzedażowym i aktywności klientów. Dla innych będzie nim większa wiarygodność prognoz, lepsze przekazywanie klientów pomiędzy zespołami albo możliwość rozpoznania szans sprzedaży wymagających interwencji, zanim pod koniec miesiąca pojawi się nieprzyjemna niespodzianka.
Kiedy cel jest już jasny, CRM przestaje być projektem polegającym na zakupie oprogramowania. Jest wówczas praktycznym sposobem na uzyskanie lepszej widoczności, jaśniejszej odpowiedzialności i trafniejszych decyzji sprzedażowych.
Jak zdefiniować rzeczywisty problem CRM przed rozpoczęciem projektowania?
Rzeczywisty problem, który ma rozwiązać CRM, powinien zostać opisany prostym językiem biznesowym, zanim ktokolwiek zacznie projektować ekrany, pola lub dashboardy. Dobre sformułowanie problemu CRM wskazuje rezultat, który obecnie jest zagrożony, dowody potwierdzające istnienie problemu, osoby, których problem dotyczy, oraz wpływ biznesowy, gdy pozostawimy go bez rozwiązania.
Na tym polega wartość etapu analizy i diagnozy w projekcie CRM. W projektach Dynamics 365 do tego służą warsztaty diagnostyczne oraz robocze plany działania w ramach podejścia Success by Design. Przekształcają one problemy opisane prostym językiem w określone procesy, modele danych i wymagania dotyczące rozwiązania.
Zespół zarządzający może początkowo stwierdzić, że firma potrzebuje lepszego raportowania.
Natomiast lepsze zdefiniowanie problemu brzmiałoby: „Nie możemy podejmować wiarygodnych decyzji dotyczących lejka sprzedażowego, ponieważ etapy sprzedaży są stosowane w niespójny sposób, aktywność klientów nie jest rejestrowana w jednym miejscu, a aktualizacje szans sprzedaży zależą od indywidualnych nawyków poszczególnych osób”.
Ta zmiana sformułowania ma znaczenie. Pierwsza wersja prowadzi do zamówienia dashboardu. Druga ujawnia problemy dotyczące procesów, danych, zachowań i odpowiedzialności. Nadaje projektowi CRM konkretne zadanie.
Test "Problem-First" dla projektu CRM
Przed rozpoczęciem projektowania rozwiązania należy zadać sześć pytań.
Ten test naprawdę działa, ponieważ oddziela to, o co proszą użytkownicy, od tego, czego rzeczywiście potrzebuje firma. Użytkownicy mogą oczekiwać mniejszej liczby kliknięć, większej automatyzacji, czytelniejszych ekranów albo konkretnego dashboardu. I takie oczekiwania mogą być uzasadnione. Nadal jednak powinny zostać ocenione pod kątem problemu, który firma próbuje rozwiązać.
Dobry warsztat diagnostyczny dotyczący CRM powinien zgromadzić kierownictwo sprzedaży, użytkowników, przedstawicieli operacji, IT oraz wszystkich zespołów korzystających z informacji o klientach. Celem nie jest zebranie wszystkich preferencji, ale uzgodnienie zasad operacyjnych, które CRM musi wspierać.
Zasady te obejmują określenie:
- które rekordy mają znaczenie,
- które pola są obowiązkowe,
- kiedy szansa sprzedaży przechodzi do kolejnego etapu,
- jakiego standardu działań następczych oczekuje firma,
- jakich raportów potrzebują liderzy,
- kto odpowiada za jakość danych po uruchomieniu systemu.
Takie podejście chroni również projekt Dynamics 365 CRM przed nadmierną rozbudową. Jeżeli celem pierwszego etapu jest widoczność lejka sprzedażowego, projekt nie musi od pierwszego dnia obejmować wszystkich możliwych automatyzacji, integracji i raportów. Potrzebuje odpowiedniej struktury, właściwych danych oraz właściwych nawyków, które pozwolą osiągnąć pierwszy rezultat.
Opisanie problemu prostym językiem biznesowym nadaje projektowi CRM bardziej precyzyjny zakres. Pomaga liderom uzgodnić, co będzie sukcesem, zanim rozpocznie się realizacja.
Dlaczego lepsze zdefiniowanie problemu chroni zakres i budżet projektu CRM?
Właściwe zdefiniowanie problemu chroni zakres projektu CRM, ponieważ pozwala ocenić każdą decyzję projektową za pomocą jednego pytania:
„Czy to pomaga rozwiązać uzgodniony problem biznesowy?”.
Bez takiej dyscypliny wdrożenie CRM może szybko wypełnić się dodatkowymi polami, niepotrzebnymi automatyzacjami, słabymi decyzjami dotyczącymi migracji danych oraz raportami, które wyglądają użytecznie, ale nie zmieniają sposobu działania użytkowników.
Ryzyko kosztowe nie ogranicza się do wydatków na licencje. Obejmuje również czas stracony na poprawki, opór użytkowników, niski poziom adopcji oraz utratę zaufania kierownictwa do systemu, zanim otrzyma on uczciwą szansę, aby zacząć działać.
Bezpieczniejszy projekt CRM definiuje na wczesnym etapie cztery rzeczy:
Co należy rozwiązać w pierwszej kolejności: podstawowy problem sprzedażowy, np. brak widoczności lejka lub brak konsekwencji w działaniach follow-up.
Co może poczekać: przydatne, ale niekrytyczne funkcje przeznaczone na kolejne etapy.
Czego nie należy konfigurować: oczekiwania, które zwiększają złożoność, ale nie poprawiają uzgodnionego rezultatu.
Co musi mieć właściciela po uruchomieniu systemu: jakość danych, nawyki użytkowników, rytm raportowania oraz wewnętrzna odpowiedzialność za system.
Jest to zgodne z etapowym podejściem Microsoft do Dynamics 365: należy zacząć od ograniczonego zakresowo, ale kompletnego procesu od początku do końca, który przyniesie wyraźną wartość. Następnie rozwiązanie można rozwijać w kolejnych etapach, gdy adopcja i jakość danych będą już stabilne.
W tym miejscu określanie zakresu CRM staje się narzędziem kontroli biznesowej. Pierwszy etap nie powinien próbować rozwiązać wszystkich problemów sprzedaży, marketingu i obsługi klienta jednocześnie. Powinien stworzyć użyteczną podstawę:
- wiarygodne rekordy,
- jasną odpowiedzialność,
- uzgodnione etapy sprzedaży,
- praktyczne raportowanie,
- szkolenia pomagające ludziom zmienić sposób pracy.
Przykładowo pierwsza wersja Dynamics 365 Sales może koncentrować się wyłącznie na zarządzaniu szansami sprzedaży i przeglądach lejka. Bardziej złożona automatyzacja ofertowania lub rozwiązania CPQ mogą zostać przeniesione do kolejnych etapów.
Dobrym przykładem jest migracja danych. Przeniesienie wszystkich historycznych rekordów może wydawać się bezpiecznym rozwiązaniem, ale słabej jakości dane ze starego systemu mogą już od pierwszego dnia osłabić zaufanie użytkowników.
Lepiej skupić się na tym, których danych o klientach, kontaktach, aktywnościach i szansach sprzedaży użytkownicy potrzebują, aby prawidłowo prowadzić działalność po uruchomieniu systemu.
Do adopcji również należy podejść realistycznie. Użytkownicy nie zaczną korzystać z CRM tylko dlatego, że system istnieje. Adopcja pojawia się wtedy, gdy użytkownicy rozumieją powód zmiany, menedżerowie wzmacniają właściwe zachowania, a system sprawia, że codzienna praca staje się bardziej przejrzysta, a nie bardziej uciążliwa.
Najczęściej zadawane pytania dotyczące projektów CRM (FAQ)
Od czego powinien zacząć się projekt CRM?
Projekt CRM powinien zacząć się od problemu biznesowego opisanego prostym językiem, na przykład słabej widoczności lejka sprzedażowego, niespójnych działań follow-up albo niewiarygodnych danych klientów. Wybór oprogramowania powinien nastąpić dopiero po zdefiniowaniu tego problemu.
Dlaczego projekty CRM kończą się niepowodzeniem?
Projekty CRM często kończą się niepowodzeniem, gdy technologia jest traktowana jak strategia. Słabo zaprojektowane procesy, niska jakość danych, niejasna odpowiedzialność oraz niski poziom adopcji użytkowników mogą podważyć wartość nawet dobrze zbudowanego systemu.
Jak uniknąć niekontrolowanego rozszerzania zakresu projektu CRM?
Uzgodnione sformułowanie problemu należy wykorzystywać jako filtr zakresu. Jeżeli dana funkcja nie wspiera rezultatu, który ma zostać osiągnięty w pierwszym etapie, należy ją zakwestionować, odłożyć na później albo usunąć z zakresu.
Kiedy warto rozważyć Dynamics 365 CRM?
Dynamics 365 CRM warto rozważyć, gdy CRM ma znaleźć się w centrum strategii chmurowej opartej na rozwiązaniach Microsoft: wspólnych danych w Dataverse, pracy połączonej z Outlookiem i Teams, analizach w Power BI oraz rozszerzaniu procesów za pomocą Power Platform w ramach uporządkowanego modelu zarządzania. Rozpoczynając dyskusję na temat CRM warto rozpocząć od pytania „Jaki problem sprzedażowy jesteśmy gotowi zdefiniować na tyle precyzyjnie, aby rzeczywiście go rozwiązać?”.
Organizacjom rozważającym Dynamics 365 CRM GO ERP może pomóc w przeprowadzeniu warsztatów diagnostycznych lub przeglądu zakresu projektu CRM. Celem jest doprecyzowanie rzeczywistego problemu, ocena gotowości danych i użytkowników oraz przygotowanie praktycznej mapy pierwszego etapu, zanim zostaną podjęte decyzje dotyczące budowy rozwiązania.
