Jak przygotować firmę do wdrożenia CRM?

Dlaczego wdrożenia CRM utykają, zanim powstanie pierwszy ekran

Większość wdrożeń CRM, które się przeciągają, nie utknęła na programowaniu. Utknęła na pytaniach, na które firma nie miała odpowiedzi. Co ma się zmienić, kto decyduje, skąd wziąć dane. Co zrobić z klientami, którzy nie pasują do żadnego etapu. Każde z tych pytań wraca w trakcie, kiedy zmiana kosztuje najwięcej. Dlatego to, jak przygotować firmę do wdrożenia CRM, rozstrzyga się przed pierwszym ekranem.

Ten poradnik mówi o przygotowaniu, a nie o tym, jak wybrać narzędzie. Wybór omawiamy w porównaniu gotowego CRM-u z dedykowanym. Tu zakładamy, że decyzja o wdrożeniu zapadła albo jest blisko, i zajmujemy się tym, co leży po Twojej stronie: procesem, danymi, ludźmi oraz decyzjami.

Nie potrzebujesz specyfikacji ani dokumentacji technicznej. Potrzebujesz kilku decyzji i kilku list, które da się zrobić w jedno popołudnie, jeśli wiesz, o co pytać. Większość punktów poniżej to odpowiedzi na pytania, które padną na pierwszej rozmowie tak czy inaczej. Lepiej, żeby padły wcześniej, w firmie, bez nas.

Jeśli Wasza sprzedaż i obsługa żyją dziś w arkuszach, poradnik o tym, kiedy Excel przestaje wystarczać, pomoże ocenić, czy to już ten moment.

Jeden problem zamiast „lepszej sprzedaży”

Zapisz, co ma się poprawić. Jedno zdanie, które da się sprawdzić po wdrożeniu. „Lepsza sprzedaż” nie jest takim zdaniem, bo nie wiadomo, co system ma w niej zmienić. „Każde zapytanie ma opiekuna i termin kolejnego kontaktu” jest, bo po miesiącu można otworzyć listę i zobaczyć, czy tak jest.

Przykłady problemów, od których zaczynają firmy, z którymi pracujemy:

• Historia klienta jest w głowie jednego handlowca. Gdy jest na urlopie, nikt nie wie, co ustalono.
• Oferty wychodzą, a nikt nie wraca do klienta po tygodniu, bo przypomnienie nie istnieje.
• Sprawa przechodzi od handlowca do realizacji mailem, a realizacja dostaje połowę ustaleń.
• Właściciel nie wie, ile ofert jest otwartych i na jakim etapie, bez obdzwaniania zespołu.
• Klient dzwoni z pytaniem, a osoba, która odbiera, nie widzi, co było wcześniej.

Wybierz jeden. Jeśli masz pięć, uszereguj je i powiedz nam, który jest pierwszy. Pierwsza wersja systemu ma rozwiązać jeden problem od początku do końca. Pozostałe wchodzą w kolejnych etapach, gdy zespół już pracuje w systemie i wie, czego mu brakuje. Jak określić taki zakres, opisujemy w poradniku o pierwszej wersji aplikacji dla firmy.

Dopisz, jak poznasz, że problem zniknął. Najlepiej obserwacją, bo liczb nie obiecujemy: kierownik przestaje pytać o status na porannej odprawie, handlowiec na urlopie nie odbiera telefonów od kolegów. Takie zdanie wraca po uruchomieniu jako pierwsze pytanie o to, czy wdrożenie się udało.

O co zapytamy na pierwszej rozmowie

Nie prowadzimy jej z kartki, ale kilka pytań wraca zawsze. Jeśli pomyślisz o nich wcześniej, rozmowa kończy się zakresem, a nie listą rzeczy do sprawdzenia w firmie.

• Jak dziś wygląda droga jednej sprawy od pierwszego kontaktu do zamknięcia i gdzie się zatrzymuje.
• Kto bierze udział w tej drodze i które z tych osób będą codziennie pracować w systemie.
• Gdzie dziś są dane o klientach i które z nich są aktualne.
• Co dziś robicie ręcznie, a co chcielibyście, żeby system robił sam.
• Które narzędzia zostają i czy CRM ma z nimi rozmawiać.
• Co ma zobaczyć właściciel, otwierając system w poniedziałek rano.
• Co musiałoby się wydarzyć, żebyście uznali wdrożenie za nieudane.

Ostatnie pytanie bywa najbardziej użyteczne. Odpowiedź „handlowcy przestaną wpisywać dane po dwóch tygodniach” mówi więcej o tym, co zaprojektować, niż lista funkcji.

Kto decyduje, kto testuje, kto zna dane

W projekcie CRM najwięcej czasu kosztują sprzeczne oczekiwania. Właściciel chce raportu, handlowcy chcą mniej klikania, księgowa chce, żeby nic nie zmieniać. Każdy ma rację ze swojej strony, a zakres puchnie.

Wyznacz osobę, która podejmuje decyzje po stronie firmy. Zbiera uwagi od zespołu, usuwa sprzeczności, potwierdza zakres i rozstrzyga różnice między tym, jak pracują dwa działy. Ta osoba nie musi być właścicielem, ale musi mieć jego mandat. Jeśli każda decyzja wraca do właściciela, który ma na to kwadrans w tygodniu, projekt czeka na te kwadranse.

Poza decydentem potrzebujemy jeszcze kilku ról. Jedna osoba może pełnić dwie z nich, ale nie wszystkie.

Ustal też, kto sprawdzi system w codziennych zadaniach. Najlepiej dwie osoby z różnych działów, w tym ta, która najgłośniej narzeka na obecny sposób pracy. Jeśli ona uzna, że nowy system jej pomaga, reszta pójdzie za nią. Jeśli testuje wyłącznie kierownik, zespół dostaje narzędzie, które pasuje do pracy kierownika.

Powiedz tym osobom, czego od nich oczekujesz, zanim projekt ruszy. Udział we wdrożeniu dochodzi do ich zwykłej pracy, a nie ją zastępuje. Handlowiec, który ma odpowiedzieć na pytania o proces w tygodniu zamykania kwartału, odpowie byle jak albo wcale. Zaplanuj ich czas w kalendarzu tak samo, jak planujesz spotkania z klientami.

Opisz proces, również jego wyjątki

Przejdź przez jedną sprawę od zapytania do zakończenia obsługi. Weź prawdziwą, z zeszłego miesiąca, z usuniętymi danymi klienta. Przy każdym kroku zapisz trzy rzeczy: jakie informacje są potrzebne, kto jest odpowiedzialny i jaki warunek pozwala przejść dalej.

Jak spisać proces w godzinę

1. Zapisz, skąd przychodzi sprawa: formularz na stronie, telefon, mail, polecenie, targi.
2. Kto ją przyjmuje i co robi w pierwszej kolejności. Dzwoni, wycenia, umawia pomiar.
3. Jakie informacje musi zebrać, zanim przekaże sprawę dalej albo wyśle ofertę.
4. Kto przygotowuje ofertę i skąd bierze ceny. Z cennika, z kalkulacji, z głowy.
5. Co się dzieje po wysłaniu oferty. Kto wraca do klienta, po jakim czasie, ile razy.
6. Co oznacza „wygrane” i co wtedy dostaje realizacja albo produkcja.
7. Co oznacza „przegrane” i czy ktokolwiek zapisuje powód.
8. Kiedy sprawa wraca: klient odzywa się po roku, chce drugi projekt, reklamuje.

Z tej listy wynikają etapy w CRM-ie, pola na karcie sprawy i reguły przypomnień. Nie musisz tego rysować. Wystarczy opis i anonimowe przykłady dokumentów: oferta, zamówienie, mail z ustaleniami. My przełożymy je na funkcje i widoki, bo to jest nasza część pracy w dedykowanych systemach CRM.

Dokumenty, które pomagają

Prześlij anonimowe przykłady tego, co powstaje w trakcie sprawy. Ofertę, którą wysyłacie najczęściej, z zaznaczeniem, które pola zmieniają się przy każdym kliencie. Mail z ustaleniami, po którym sprawa idzie do realizacji. Arkusz, w którym handlowiec notuje kolejne kontakty. Protokół, zamówienie, potwierdzenie. Z tych dokumentów widać, jakie dane system ma przechowywać i w którym momencie powstają. Opis procesu mówi, co się dzieje. Dokumenty mówią, co z tego zostaje na papierze.

Wyjątki, które zawsze się pojawiają

Proces na papierze jest prosty. Prawdziwy ma wyjątki, a CRM zaprojektowany bez nich zmusza zespół do obejść od pierwszego tygodnia. Dopisz te, które znasz:

• Klient wraca po długiej przerwie i nikt nie pamięta, kto go obsługiwał.
• Klient zmienia opiekuna, bo poprzedni odszedł albo bo tak chce.
• Klient prosi o drugą wersję oferty, a pierwsza ma zostać w historii.
• Jedna firma ma kilka osób kontaktowych i każda pyta o co innego.
• Sprawa dotyczy dwóch działów naraz i nie wiadomo, czyj jest etap.
• Oferta została zaakceptowana ustnie, a formalne zamówienie przyjdzie za miesiąc.
• Handlowiec przyjmuje sprawę przez telefon w terenie i wprowadza ją do systemu po fakcie.

Każdy wyjątek to decyzja: obsługujemy go w systemie, czy zostawiamy poza nim. Obie odpowiedzi są dobre, jeśli są świadome. Zła jest trzecia: udawanie, że wyjątków nie ma.

Co zostaje poza CRM-em

CRM nie musi robić wszystkiego. Zapisz, które narzędzia zostają: poczta, kalendarz, program do faktur, aplikacja do obsługi zleceń, jeśli jest. Dla każdego ustal, czy CRM ma się z nim łączyć, czy tylko wiedzieć, że istnieje. Połączenie to osobny zakres, który trzeba sprawdzić przed wyceną, bo zależy od tego, co dany program udostępnia. Jak wygląda takie połączenie na przykładzie formularza ze strony, opisujemy w poradniku o integracji strony z CRM-em.

Granica między CRM-em a realizacją bywa najtrudniejsza. CRM porządkuje relacje i sprzedaż, obsługa zleceń porządkuje wykonanie uzgodnionych prac. Ustal moment przekazania sprawy i to, kto za nią odpowiada po tym momencie. Bez tego dwa zespoły będą zakładać, że sprawą zajmuje się ten drugi.

Dane: skąd pochodzą, co przenosimy, co zostaje w archiwum

Dane są najczęstszym powodem, dla którego start wdrożenia się przesuwa. Nie dlatego, że ich brakuje, tylko dlatego, że jest ich za dużo, w za wielu miejscach i nikt nie wie, które są aktualne.

Spis źródeł

Wypisz wszystko, gdzie dziś żyją informacje o klientach i sprawach. Arkusz handlowy, arkusz biura, skrzynki poszczególnych osób, program do faktur, notatki w telefonach, stary CRM, z którego nikt nie korzysta, ale coś w nim jest. Przy każdym źródle zapisz, kto za nie odpowiada i czy da się z niego wyeksportować dane w sensownym formacie.

Potem odpowiedz na pytanie, które źródło jest prawdą, gdy dwa się różnią. W arkuszu handlowca klient ma jeden telefon, w programie do faktur inny. Bez tej decyzji migracja albo stanie, albo przeniesie oba numery i nikt nie będzie wiedział, który jest dobry.

Co przenosimy, a co zostaje

Nie wszystko musi trafić do nowego systemu. Dobrym punktem wyjścia jest podział na trzy grupy:

• Przenosimy w całości: aktywni klienci, otwarte sprawy, ustalenia z ostatniego okresu, który zespół uzna za potrzebny.
• Przenosimy skrótowo: klienci z przeszłości jako kontakt z notatką, bez pełnej historii.
• Zostaje w archiwum: stare oferty, zamknięte sprawy sprzed lat, dane, których podstawa przetwarzania wygasła.

Przed importem ustalamy identyfikatory, czyli po czym rozpoznać, że dwa wpisy to ta sama firma. NIP jest najlepszy, jeśli go macie. Nazwa firmy jest najgorsza, bo „Kowalski Sp. z o.o.” i „KOWALSKI sp z o o” to dla komputera dwie różne firmy. Ustalamy też, co z brakami: pusty telefon, adres bez kodu, kontakt bez nazwiska.

Co sprawdzić w danych przed eksportem

• Czy jedna kolumna zawiera jeden rodzaj informacji. „Jan Kowalski, tel. 600…, dzwonić po 16” w polu „kontakt” trzeba rozbić ręcznie.
• Czy statusy znaczą to samo u każdej osoby. „W toku” u jednego handlowca to oferta wysłana, u drugiego to pierwszy telefon.
• Czy daty są datami, a nie tekstem „zeszły wtorek”. System nie ustawi przypomnienia od takiego wpisu.
• Czy firmy mają NIP albo inny identyfikator, po którym da się połączyć wpisy z różnych źródeł.
• Czy w danych są osoby, których nie wolno już przechowywać, na przykład kontakty sprzed lat bez żadnej relacji.
• Czy jest kolumna, której nikt nie rozumie. Zwykle jest, i zwykle można ją pominąć.

Próba migracji

Zanim przeniesiemy całość, robimy próbę na części danych. Osoba od danych sprawdza, czy klienci są na właściwych kartach, czy historia się zgadza i czy duplikaty zostały połączone. Z próby wynika lista poprawek w danych źródłowych, którą firma robi przed właściwą migracją. Próba kosztuje mniej niż czyszczenie bazy po starcie, gdy zespół już w niej pracuje.

Uprawnienia, RODO oraz zasady korzystania z usług zewnętrznych

Decyzje z tej sekcji zapadają przed budową, bo zmieniają strukturę systemu. Dodanie roli po wdrożeniu jest możliwe, ale przebudowa tego, kto co widzi, dotyka każdego ekranu.

Kto widzi całą bazę, a kto własne sprawy

Opisz role w firmie i to, co każda z nich ma widzieć. Handlowiec widzi swoich klientów, czy wszystkich. Kierownik widzi sprawy zespołu i raporty. Biuro widzi dane kontaktowe, ale nie wartości ofert. Kto może eksportować dane, bo eksport całej bazy przez odchodzącego pracownika to scenariusz, który zdarza się częściej, niż firmy przyznają. Kto zakłada i odbiera konta.

Zapisz też, co dzieje się z kontem osoby, która odchodzi. Jej sprawy muszą dostać nowego opiekuna tego samego dnia, a konto ma zostać zablokowane, nie usunięte, żeby historia została.

RODO przed migracją

Przeniesienie bazy klientów do nowego systemu jest przetwarzaniem danych osobowych. Przed migracją sprawdź z osobą od RODO trzy rzeczy. Na jakiej podstawie przechowujecie kontakty, które nigdy nie zostały klientami. Jak długo trzymacie dane po zakończeniu współpracy. Czy dostawca hostingu albo systemu, w którym CRM będzie działał, ma z Wami umowę powierzenia, jeśli jest zewnętrzny.

Tekst rozporządzenia jest na EUR-Lex, a wyjaśnienia organu nadzorczego publikuje Urząd Ochrony Danych Osobowych. Treść klauzul i decyzje o okresach przechowywania są po stronie firmy jako administratora. My wdrażamy je w systemie: okresy przechowywania, oznaczanie podstawy przetwarzania, obsługę prośby o usunięcie.

Usługi zewnętrzne, w tym AI

Jeśli CRM ma korzystać z usług zewnętrznych, na przykład z AI do podsumowań rozmów, ustalamy to przed budową. Zapisujemy, jakie dane do nich trafiają i co wymaga akceptacji człowieka. Zapisz, czy w firmie są dane, które nie mogą opuścić Waszych serwerów. Gdzie AI w aplikacji pomaga, a gdzie wymaga kontroli, opisujemy w poradniku o AI w aplikacji firmowej.

Jak przygotować firmę do wdrożenia CRM w różnych branżach

Lista z poprzednich sekcji jest wspólna. Każdy rodzaj firmy ma jednak inne miejsce, w którym proces się rwie, i inne dane, bez których CRM zostaje pustą tabelą.

Serwis i instalacje

Sprawa zaczyna się od zapytania, a kończy wizytą ekipy i protokołem. CRM obsługuje pierwszą część, a druga wymaga grafiku i zleceń. Przygotuj decyzję, gdzie kończy się sprzedaż, a zaczyna realizacja, i kto przekazuje sprawę. Do danych dołóż adresy obiektów, bo klient serwisowy to często jeden płatnik i dziesięć lokalizacji. Jak układa się proces od zapytania do realizacji, opisujemy w poradniku o CRM-ie dla firmy usługowej.

Produkcja B2B

Tu proces ma najwięcej etapów przed ofertą: zapytanie, analiza rysunku, wycena przez technologa, akceptacja marży, oferta. Przygotuj listę osób, które biorą w tym udział, i warunki przejścia między etapami. Do danych dołóż historię ofert z parametrami, bo kolejne zapytanie od tego samego klienta zaczyna się od pytania „co mu daliśmy ostatnio”. Przy realizacji Nomatec, firmy z inżynierii i obróbki CNC, zakres objął stronę WWW, branding oraz CRM wspierający obsługę zapytań i kontakt handlowy.

Handel i dystrybucja

Problemem jest zwykle liczba kontaktów i powtarzalność zamówień. Przygotuj decyzję, czy CRM ma widzieć zamówienia z systemu sprzedażowego, czy tylko relację i ustalenia handlowe. Jeśli planujecie panel dla odbiorców, oba narzędzia muszą dzielić jedną bazę firm. Zapisz, kto odpowiada za cenniki i rabaty, bo to pytanie wraca przy każdej integracji.

Usługi dla firm: księgowość, kancelarie, agencje

Klient jest stały, a sprawy cykliczne. Przygotuj listę typów spraw i to, które z nich wracają co miesiąc albo co rok. Do danych dołóż osoby kontaktowe po stronie klienta z rolami, bo z księgową rozmawia się inaczej niż z prezesem. Ustal, czy CRM ma pilnować terminów cyklicznych, czy to zostaje w innym narzędziu.

Budowlanka i wykończenia

Dwie grupy klientów i dwa procesy: inwestor prywatny z wyceną po oględzinach oraz generalny wykonawca z ofertą na przedmiar. Przygotuj oba procesy osobno. Do danych dołóż inwestycje jako osobny byt, bo jeden klient może mieć trzy budowy, a każda ma własne ustalenia i własny termin.

Firmy z oddziałami

Przygotuj decyzję o widoczności: centrala widzi wszystko, oddział swoje, a co z klientem, który kupuje w dwóch oddziałach. Do tego zastępstwa między oddziałami i reguła, kto przejmuje sprawę przy nieobecności. Dane z oddziałów trzeba połączyć przed migracją, bo każdy prowadził je po swojemu, a to samo pole może oznaczać co innego w Poznaniu i w Lesznie.

Przykład z biurka: od trzech arkuszy do jednego procesu

Firma produkcyjna z Wielkopolski, kilkanaście osób, sprzedaż do innych firm. Przyszła z jednym zdaniem: „Chcemy CRM, bo gubimy oferty”. Handlowcy prowadzili każdy własny arkusz, biuro trzecie, a prezes dostawał raz w tygodniu podsumowanie, w które nikt nie wierzył.

Krok pierwszy: problem. Po rozmowie „gubimy oferty” zmieniło się w „nikt nie wraca do klienta po wysłaniu oferty, bo nie ma przypomnienia i nie wiadomo, czyja to sprawa”. To już dało się sprawdzić po wdrożeniu.

Krok drugi: proces. Jeden z handlowców opisał ostatnią wygraną sprawę i ostatnią przegraną. Z opisu wyszło sześć etapów i trzy wyjątki, w tym najważniejszy: wycena przez technologa, która trwała różnie i blokowała resztę. CRM dostał etap „u technologa” z osobnym odpowiedzialnym, zamiast udawać, że handlowiec panuje nad tym czasem.

Krok trzeci: dane. Trzy arkusze miały różne kolumny i różne nazwy tych samych firm. Osoba z biura dostała zadanie: jeden arkusz, jedna firma w jednym wierszu, NIP przy każdej. Zajęło jej to dłużej, niż zakładała, i ten czas poszedł w harmonogram zamiast w zaskoczenie.

Krok czwarty: uprawnienia. Handlowcy widzą swoich klientów i sprawy zespołu w trybie odczytu. Prezes widzi wszystko. Biuro widzi kontakty i statusy bez wartości ofert. Eksport tylko dla prezesa.

Krok piąty: odbiór. Dwóch handlowców i osoba z biura przeszli scenariusze na swoich przykładach: nowy klient, oferta z drugą wersją, przekazanie do technologa, powrót klienta po przerwie. Jedna rzecz nie przeszła: przypomnienie przychodziło tylko w systemie, a handlowcy w terenie go nie otwierali. Dodaliśmy powiadomienie na telefon przed startem.

Start wyznaczono na poniedziałek. Od tego dnia nowe sprawy wchodziły do CRM-u, a arkusze zostały zamknięte do odczytu. Po kilku tygodniach wróciliśmy do zdania z kroku pierwszego i zapytaliśmy, czy jest prawdziwe. Z uwag zespołu wyszedł następny etap: szablony ofert, bo handlowcy nadal składali je ręcznie.

Scenariusze odbioru i pierwsze dni pracy

Odbiór CRM-u nie polega na obejrzeniu ekranów. Polega na tym, że użytkownik wykonuje swoje codzienne zadania bez pomocy wykonawcy. Listę takich zadań przygotuj przed budową, bo z niej wynika, co ma być gotowe w pierwszej wersji.

Uzgodnij, kto potwierdza wynik każdego testu i jak zgłaszacie uwagi. Najlepiej jedna lista, z podziałem na dwie grupy: błąd względem ustalonego zakresu i pomysł na rozwój. Ten podział pozwala ocenić, czy pierwsza wersja jest gotowa, bez mieszania tego, co obiecane, z tym, co przyszło do głowy w trakcie testów.

Dzień startu

Ustal datę, od której nowe sprawy trafiają wyłącznie do CRM-u, i osoby, do których zespół zgłasza problemy w pierwszych dniach. Zespół powinien wiedzieć, gdzie zostaje archiwum i że arkusze są tylko do odczytu. Równoległe prowadzenie kilku baz bez ustalonej zasady kończy się tym, że po miesiącu nikt nie wie, gdzie jest prawda.

Pokazanie systemu zespołowi

Przy przekazaniu pokazujemy obsługę ustalonych funkcji osobom, które będą w systemie pracować. Przydaje się, gdy prowadzą to razem z nami użytkownicy testujący, bo mówią językiem zespołu i znają obiekcje. Zdecyduj, czy zespół dostaje instrukcję na piśmie, krótkie nagrania, czy jedno spotkanie. Osoby, które dołączą do firmy za rok, będą potrzebowały tego samego, więc materiał z przekazania zostaje w firmie jako instrukcja.

Ustal też, co robi zespół z pytaniami w pierwszych dniach. Jeśli każdy pisze do nas osobno, odpowiadamy dziesięć razy na to samo. Jeśli pytania zbiera koordynator, odpowiedź trafia do wszystkich i do instrukcji.

Pierwsze tygodnie

Po starcie wróć do zdania o problemie z początku tego poradnika i sprawdź, czy jest prawdziwe. Zbierz uwagi osób, które pracują w systemie, w tej samej liście co przy odbiorze. Kolejne moduły planuj na podstawie tych uwag, a nie na podstawie listy pomysłów sprzed wdrożenia. Lista sprzed wdrożenia zwykle zawiera rzeczy, które po miesiącu pracy okazują się niepotrzebne.

Etapy współpracy i co przygotować na każdy z nich

Pracujemy etapami z oferty aplikacji dla firm. Każdy etap zużywa inną część przygotowań i kończy się inną decyzją po Twojej stronie.

Poznajemy sposób pracy

Rozmawiamy o zadaniach, użytkownikach oraz obecnych narzędziach. Ustalamy, gdzie gubią się informacje, co robicie ręcznie i jaki efekt ma dać system. Od Ciebie: zdanie o problemie, opis jednego procesu z wyjątkami, spis źródeł danych, lista ról. Nie potrzebujemy specyfikacji.

Projektujemy i ustalamy zakres

Pokazujemy układ ekranów i przebieg najważniejszych zadań. Ustalamy funkcje pierwszej wersji, role użytkowników, integracje, koszt oraz harmonogram. Od Ciebie: decyzje o uprawnieniach, o tym, co zostaje poza CRM-em, i lista scenariuszy odbioru. Decyzja zamykająca etap: zatwierdzenie zakresu i oferty. Co wpływa na wycenę, opisujemy w poradniku o koszcie aplikacji dla firmy.

Budujemy i sprawdzamy

Tworzymy system, łączymy go z uzgodnionymi narzędziami i testujemy na scenariuszach odbioru. Przygotowujemy przeniesienie danych, zaczynając od próby na części. Od Ciebie: oczyszczone dane źródłowe, dostępność osób testujących, uwagi w jednej liście. Decyzja zamykająca etap: zgoda na uruchomienie.

Wdrażamy i rozwijamy

Pomagamy zespołowi zacząć pracę i zbieramy uwagi z codziennego użycia. Ustalamy zasady opieki, utrzymania oraz kolejnych zmian. W ofercie określamy dokumentację, dostępy, licencje oraz prawa do kodu, sposób zgłaszania problemów i zakres utrzymania. Od Ciebie: data startu, osoby wspierające zespół, decyzja o następnym etapie na podstawie uwag.

O co zapytać wykonawcę

• Co dostaniemy przy przekazaniu: kod, dokumentację, dostępy do serwera, prawa do systemu.
• Gdzie będą dane i kto robi kopie zapasowe. Jak sprawdzimy, że da się je odtworzyć.
• Jak wygląda zgłaszanie problemów po starcie i jaki jest ustalony czas reakcji.
• Co się stanie, jeśli zakończymy współpracę. Czy system działa dalej i czy da się go rozwijać z kimś innym.
• Jak wyceniane są zmiany po wdrożeniu i co jest w ramach opieki.
• Jak będzie wyglądać próba migracji i kto po naszej stronie ma ją sprawdzić.
• Jakie usługi zewnętrzne będą użyte i jakie dane do nich trafią.

Najczęstsze błędy w przygotowaniu i czym się kończą

Każdy z tych błędów widzieliśmy więcej niż raz. Żaden nie wynika z braku staranności, raczej z tego, że wdrożenie CRM robi się w firmie raz na kilka lat i nie ma skąd wziąć doświadczenia.

• Lista funkcji zamiast problemu. Firma przynosi dwadzieścia punktów „co CRM ma mieć” zebranych z opisów gotowych systemów. Połowa nie dotyczy jej procesu, a brakuje tego, co dotyczy.
• Proces opisany przez kierownika, nie przez osobę, która go wykonuje. Kierownik opisuje, jak powinno być. Handlowiec wie, jak jest. CRM zbudowany na „jak powinno być” zmusza do obejść.
• Dane „posprzątamy po wdrożeniu”. Zespół zaczyna pracę w systemie pełnym duplikatów i przestaje mu ufać w pierwszym tygodniu.
• Uprawnienia ustalane przy pierwszym konflikcie. Ktoś zobaczył, czego nie powinien, i teraz trzeba przebudować widoki przy działającym systemie.
• Brak decydenta. Każda decyzja czeka na właściciela, a właściciel ma na nią kwadrans w tygodniu. Projekt zużywa kwadranse zamiast tygodni.
• Odbiór przez obejrzenie prezentacji. Użytkownicy pierwszy raz dotykają systemu w dniu startu, a wtedy każdy brak jest pilny.
• Brak daty zamknięcia starych arkuszy. Dwie bazy żyją równolegle, a po miesiącu nikt nie wie, która jest prawdziwa.
• Wszystko w pierwszej wersji. Zakres rośnie, start się przesuwa, a zespół traci wiarę, że system kiedykolwiek powstanie.

Wszystkie te błędy łączy jedno. Decyzja odłożona na później wraca wtedy, gdy zmiana dotyka już działającego systemu i pracujących w nim ludzi.

Lista kontrolna i słownik pojęć

Zaznacz, co masz, co masz do ustalenia, a czego świadomie nie będzie w pierwszej wersji. Z taką listą pierwsza rozmowa kończy się zakresem do wyceny, a nie listą pytań do przemyślenia.

1. Jedno zdanie o problemie, który ma rozwiązać pierwsza wersja, i obserwacja, po której poznasz, że zniknął.
2. Decydent z mandatem, koordynator uwag, dwie osoby testujące z różnych działów.
3. Opis jednego procesu od zapytania do zakończenia, z informacjami, osobami oraz warunkami przejścia.
4. Lista wyjątków i decyzja przy każdym: w systemie czy poza nim.
5. Lista narzędzi, które zostają, z informacją, czy CRM ma się z nimi łączyć.
6. Moment przekazania sprawy do realizacji i osoba odpowiedzialna po tym momencie.
7. Spis źródeł danych z osobą odpowiedzialną i możliwością eksportu.
8. Decyzja, które źródło jest prawdą przy rozbieżnościach, i identyfikator firmy, najlepiej NIP.
9. Podział danych: przenosimy w całości, skrótowo, zostaje w archiwum.
10. Role i uprawnienia: kto widzi całość, kto własne sprawy, kto eksportuje, kto zakłada konta.
11. Podstawy przetwarzania, okresy przechowywania, umowa powierzenia, jeśli system działa u zewnętrznego dostawcy.
12. Zasady korzystania z usług zewnętrznych, w tym AI, i dane, które nie mogą opuścić firmy.
13. Scenariusze odbioru z osobą sprawdzającą i definicją „zaliczony”.
14. Data startu, data zamknięcia starych arkuszy, osoby wspierające zespół w pierwszych dniach.
15. Materiały właściwe dla branży: adresy obiektów, historia ofert z parametrami, inwestycje, osoby kontaktowe z rolami.

Punkty od 1 do 6 przydają się przed pierwszą rozmową. Reszta może dojść na etapie projektowania zakresu. Jeśli wygodniej Ci wpisać to w formularz, brief aplikacji pyta o te same rzeczy i przyjmuje pliki.

Słownik pojęć z oferty

• Karta klienta. Jedno miejsce z danymi firmy, osobami kontaktowymi, notatkami, dokumentami oraz historią spraw.
• Sprawa, szansa sprzedażowa. Pojedyncza okazja do sprzedaży z etapem, opiekunem, wartością oraz terminem następnego kroku. Jeden klient może mieć wiele spraw.
• Etap, lejek. Kolejne kroki, przez które przechodzi sprawa, odwzorowane z Waszego procesu. Nie z szablonu gotowego systemu.
• Opiekun. Osoba odpowiedzialna za sprawę albo klienta. Każda sprawa ma jednego opiekuna, nawet gdy pracuje nad nią kilka osób.
• Rola, uprawnienia. Zestaw tego, co użytkownik widzi i może zmienić. Ustalane przed budową, bo wpływają na każdy ekran.
• Migracja. Przeniesienie danych z obecnych źródeł do nowego systemu, z łączeniem duplikatów i uzupełnianiem braków. Poprzedzona próbą na części danych.
• Identyfikator. Cecha, po której system rozpoznaje, że dwa wpisy to ta sama firma, na przykład NIP.
• Integracja. Połączenie CRM-u z innym narzędziem, na przykład formularzem na stronie albo programem do faktur. Osobny zakres, sprawdzany przed wyceną.
• Scenariusz odbioru. Zadanie, które użytkownik wykonuje samodzielnie podczas testów, z ustaloną definicją, kiedy jest zaliczone.
• Pierwsza wersja, MVP. Zakres, który obsługuje jeden proces od początku do końca. Kolejne moduły dochodzą po starcie, na podstawie uwag.
• Opieka, utrzymanie. Zasady zgłaszania problemów, czas reakcji, aktualizacje oraz kopie zapasowe po uruchomieniu. Ustalane w ofercie.
• Umowa powierzenia. Umowa z dostawcą, który przetwarza dane osobowe w imieniu firmy, na przykład z firmą hostingową. Wymagana przez RODO.

TL;DR

• Zapisz jeden problem, który ma rozwiązać pierwsza wersja, i obserwację, po której poznasz, że zniknął.
• Wyznacz decydenta z mandatem i dwie osoby testujące, w tym tę, która najgłośniej narzeka na obecny sposób pracy.
• Opisz jeden prawdziwy proces z wyjątkami. Opis i anonimowe dokumenty wystarczą, specyfikacja nie jest potrzebna.
• Spisz źródła danych, ustal, które jest prawdą, i podziel dane na przenoszone, skrócone oraz archiwalne.
• Ustal role i uprawnienia oraz sprawdź podstawy przetwarzania przed migracją, nie po niej.
• Przygotuj scenariusze odbioru, które użytkownicy przejdą sami, i jedną listę uwag z podziałem na błędy i pomysły.
• Wyznacz datę startu i datę zamknięcia starych arkuszy. Kolejne moduły planuj na podstawie uwag po starcie.

FAQ