Jaki problem to rozwiązuje
Procesy i systemy rozjeżdżają się od pierwszego dnia. Podręcznik mówi, że każdy deal dostaje rozmowę kwalifikacyjną; CRM ochoczo przyjmuje deale bez niej. System wymaga pola, którego nikt nie używa, więc handlowcy wypełniają je śmieciem, by przejść walidację. Automatyzacja egzekwuje regułę przypisywania sprzed dwóch reorganizacji. Wkrótce są trzy rzeczywistości: proces udokumentowany, reguły systemu i to, co ludzie faktycznie robią, a każdy raport, audyt i nowa osoba potyka się o różnice między nimi.
Jak pracujemy
Stawiamy trzy rzeczywistości obok siebie. Z dokumentacji: co proces deklaruje. Z konfiguracji systemu: czego CRM wymaga, co automatyzuje i co dopuszcza. Z zachowania: co rekordy CRM pokazują, że ludzie faktycznie robią. Każdą trójstronną rozbieżność logujemy z jej kierunkiem: proces przed systemem, system przed procesem albo oba porzucone w praktyce.
Każda rozbieżność dostaje potem werdykt, bo nie są równe. Niektóre luki systemu to zdrowa elastyczność; niektóre wypełnione śmieciem pola wymagane sygnalizują regułę, która powinna umrzeć, a nie być egzekwowana mocniej. Ocena odróżnia, gdzie system powinien dogonić proces, gdzie proces trzeba przepisać, by pasował do rzeczywistości, a gdzie sama praktyka jest problemem.
Rezultatem jest rejestr zgodności z kierunkiem poprawki na rozbieżność i sekwencjonowany plan naprawy. To fundament, który czyni projekty automatyzacji bezpiecznymi, bo automatyzowanie na nieuznanym rozjeździe utwardza złe zachowanie na skalę.
Deliverables
- Trójstronne porównanie: proces udokumentowany, konfiguracja systemu, faktyczne zachowanie
- Rejestr rozbieżności z kierunkiem i ważnością na element
- Werdykt na rozbieżność: napraw system, napraw proces albo napraw praktykę
- Przegląd walidacji i automatyzacji oznaczający reguły generujące śmieciową zgodność
- Sekwencjonowany plan naprawy gotowy do oszacowania