Zakończenie pracy przez jeden dział nie oznacza jeszcze, że kolejny ma przydzielone zadanie. Między statusem „sprzedaż zakończona” a rozpoczęciem wdrożenia musi być jasne, co uruchamia następny krok i kto za niego odpowiada.

Przykład modelowy: firma sprzedaje usługę wymagającą wdrożenia. Handlowiec podpisuje umowę, zapisuje uzgodniony zakres i dane kontaktowe w CRM oraz zamyka sprzedaż. Wszystkie warunki rozpoczęcia wdrożenia są spełnione. Kilka dni później klient pyta o początek współpracy, ale zespół wdrożeniowy nie ma tej sprawy na liście zadań. Z perspektywy zarządu sprzedaż jest zakończona, a realizacja nie ma wyznaczonego wykonawcy pierwszego kroku.

Nie musi to oznaczać błędu handlowca ani przeciążenia wdrożeń. Możliwe, że firma nie określiła, kiedy ma powstać następne zadanie, do kogo powinno trafić i jak rozpoznać jego przejęcie. Zanim zacznie poprawiać komunikację między działami, warto sprawdzić, czy następna praca w ogóle została komuś powierzona.

Informacja, zadanie i odpowiedzialność to trzy różne rzeczy

Warto rozróżnić trzy momenty:

• Informacja dotarła. Zespół wdrożeniowy wie o podpisanej umowie, ale nie wynika z tego jeszcze, jakie zadanie ma wykonać
• Zadanie powstało. Określono konkretną czynność i udostępniono ją właściwej osobie lub kolejce zespołu
• Odpowiedzialność została przejęta. Wiadomo, kto ma wykonać następne działanie, na przykład dlatego, że zadanie przypisano mu imiennie albo przyjął je ze wspólnej kolejki

Zadanie może być poprawnie skierowane do kolejki, choć nikt jeszcze go nie podjął. Z drugiej strony, jeżeli firma przypisuje zadania bezpośrednio wskazanym osobom, taki przydział może już ustanawiać odpowiedzialność. Nie należy dodawać obowiązkowego potwierdzenia tylko po to, by system miał kolejny status. Rozróżnienie osób uprawnionych do przejęcia pracy i jej faktycznego właściciela jest znane również z modeli zarządzania zadaniami.

Przy niewielkiej liczbie spraw wystarczającym rozwiązaniem może być e-mail, jeśli wskazuje konkretny obowiązek i odbiorcę, a firma potrafi ustalić, kto odpowiada za reakcję. Samo wysłanie informacji nie jest jednak dowodem, że następna praca została przyjęta.

Kiedy kolejny etap może się rozpocząć?

W opisanym przykładzie zakładamy, że dane są kompletne. W innych sprawach samo podpisanie umowy może nie wystarczyć: do rozpoczęcia wdrożenia potrzebne bywają zatwierdzony zakres, osoba kontaktowa lub dodatkowe dane startowe.

Dlatego trzeba oddzielić zdarzenie uruchamiające sprawdzenie od warunków pozwalających przekazać pracę. Jeśli brakuje wymaganego zakresu, poprawną decyzją może być wstrzymanie uruchomienia wdrożenia i wskazanie osoby, która uzupełni brak. Nie każda sprawa, która nie ruszyła dalej, została zgubiona.

Status w CRM może skutecznie uruchamiać następne zadanie, jeżeli firma ustaliła jego znaczenie i wymagane warunki. Problemem nie jest więc sam status, lecz brak jasnej reguły albo jej niewłaściwe działanie. Jak pokazała pierwsza część tej serii, status w systemie mówi tylko tyle, ile firma wcześniej ustaliła, że ma znaczyć.

Sześć ustaleń dla jednego przekazania

Właściciel procesu może opisać krytyczne przejście za pomocą Karty przekazania kroku: prostego narzędzia roboczego proponowanego przez Codino. Nie jest to formalny standard. Karta pomaga uzgodnić, co dokładnie musi wydarzyć się między zakończeniem jednego etapu a ustanowieniem odpowiedzialności za następny.

Termin w ostatnim polu jest przykładowy, nie stanowi uniwersalnej normy. Firma dobiera go do znaczenia danego przekazania. Osobno powinna wskazać właściciela reguły, odpowiedzialnego za jej aktualność.

Sześć ustaleń nie oznacza sześciu nowych statusów w CRM. Jeśli zadanie trafia bezpośrednio do konkretnej osoby i zgodnie z zasadami firmy oznacza to przejęcie odpowiedzialności, wystarczy wiarygodny zapis przydziału. Przy wspólnej kolejce potrzebny jest sposób ustalenia, kto faktycznie podjął pracę. Przejęcie zadania nie oznacza jeszcze wykonania wdrożenia.

Jak sprawdzić, gdzie zatrzymała się sprawa?

Karta opisuje uzgodniony sposób działania. Gdy konkretna sprawa nie rusza dalej, potrzebna jest jeszcze diagnoza tego, co rzeczywiście się wydarzyło.

Warunki nie zostały spełnione. Jeśli brakuje wymaganych danych lub decyzji, zadanie nie powinno zostać uruchomione przedwcześnie. Trzeba wskazać brak i osobę odpowiedzialną za jego usunięcie.

Warunki są spełnione, ale zadanie nie powstało. Najpierw należy ustalić, czy istnieje reguła tworząca następny obowiązek. Jeśli nie, właściciel procesu musi ją zdefiniować. Jeśli istnieje, ale nie zadziałała, trzeba sprawdzić wykonanie reguły w systemie. To nie musi być problem współpracy między działami.

Zadanie powstało, ale trafiło do niewłaściwego odbiorcy. Brakuje poprawnego przypisania, odpowiedniej kolejki lub zasady wyboru wykonawcy. Tutaj należy poprawić regułę kierowania pracy.

Zadanie trafiło do właściwej kolejki, ale nikt go nie przejął. Trzeba sprawdzić, kto miał zareagować i w jakim terminie. Jeśli przyczyną jest przeciążenie zespołu, sama reguła przekazania może być poprawna, a problem dotyczy dostępności zasobów.

Jeżeli zadanie ma już właściwego właściciela, lecz jego wykonanie nadal stoi, nie należy automatycznie nazywać tego błędem przekazania. Przyczyn trzeba wtedy szukać w dalszej realizacji, na przykład w przerwach między czynnościami, o których była poprzednia część.

Co konkretnie powinien otrzymać zarząd?

Na początek wystarczy sprawdzić jedno istotne przejście na kilku rzeczywistych sprawach. Wynikiem powinny być wypełniona karta oraz krótka informacja: który warunek lub obowiązek nie został spełniony, na czym opiera się ten wniosek i kto odpowiada za następny krok.

Przykładowy wynik dla modelowej sprawy z początku artykułu:

Umowa podpisana: tak. Zakres i dane startowe: kompletne. Zadanie dla wdrożeń w uzgodnionej kolejce: nie znaleziono.

Wniosek: w uzgodnionej kolejce nie znaleziono wymaganego zadania. Nie wiadomo jeszcze, czy zadanie nie powstało, czy zostało utworzone, ale trafiło w inne miejsce.

Dalsza decyzja: właściciel procesu sprawdza, czy określono regułę utworzenia zadania i właściwego odbiorcę. Jeśli tak, zespół IT ustala, czy zadanie utworzono oraz dokąd zostało skierowane. Jeśli reguły nie ma, trzeba ją najpierw uzgodnić.

To przykład hipotetyczny. Pokazuje, dlaczego brak zadania w oczekiwanym miejscu jest obserwacją, a brak reguły, błędne skierowanie pracy lub niewykonanie reguły, różnymi możliwymi przyczynami. Jedna sprawa może pomóc je rozpoznać, ale nie mówi jeszcze, jak często problem występuje w firmie.

Warto także przetestować przypadek, w którym warunki rozpoczęcia kolejnego etapu nie są spełnione, oraz sprawę, w której zadanie poprawnie trafiło do kolejki, lecz nie zostało przejęte. Dzięki temu wiadomo, czy proces potrafi zarówno uruchomić pracę, jak i świadomie ją wstrzymać oraz zareagować na brak właściciela.

Dopiero po takiej kontroli ma sens decyzja, czy wystarczy procedura i e-mail, funkcja istniejącego CRM albo prosta automatyzacja. Dokumentacja Salesforce pokazuje, że system CRM może uruchamiać działania po określonym zdarzeniu i spełnieniu warunków. Technologia nie rozstrzyga jednak za firmę, kiedy kolejny obowiązek ma powstać.

Jeżeli jeden dział zakończył pracę, zarząd powinien móc ustalić nie tylko, kogo powiadomiono, ale jaka następna czynność została komu powierzona. Bez tego problem może pozostawać niewidoczny aż do momentu, gdy o rozpoczęcie realizacji upomni się klient.