Dlaczego każdy projekt czyszczenia CRM regresuje w ciągu sześciu miesięcy

Widziałem ten wzorzec już w pięciu firmach. RevOps zdobywa budżet na projekt czyszczenia CRM. Wchodzą konsultanci albo kontraktor, przeprowadzają sześciotygodniowy sprint i dostarczają audyt, który domyka 3000 duplikatów, normalizuje 60% pól z wolnym tekstem i produkuje 40-stronicowy raport z rekomendacjami na cały kwartał. Zespół danych świętuje. Raportowanie poprawia się w mierzalny sposób. Prognozy stają się czystsze przez kilka przeglądów pipeline’u. Zespół przechodzi do następnego projektu.

Sześć miesięcy później duplikaty wracają, pola z wolnym tekstem zdryfowały, a deck używany do wyjaśnienia, dlaczego liczby pipeline’u się nie spinają, jest tym samym, którego używano sześć miesięcy wcześniej.

Dlaczego projekty regresują

Audyt naprawia istniejące dane. Nie naprawia systemu, który w pierwszej kolejności wyprodukował złe dane.

Importy nadal się odbywają z niedopasowanymi formatami. Formularze webowe zbierają wolny tekst w polach, które powinny być listami wyboru. AE pracujący nad dealem poza platformą podczas sprintu nigdy nie synchronizują rekordu z powrotem, a im starszy staje się deal, tym mniej prawdopodobne, że ktokolwiek go posprząta. Operacje marketingowe uruchamiają nową kampanię z własnymi konwencjami pól, bo nikt im nie powiedział, że konwencje zostały ponownie ustandaryzowane trzy miesiące temu. Każde z tych jest świeżym źródłem dryfu, a żadne z nich nie zostało ujęte w zakresie projektu.

Uczciwe ujęcie jest takie, że czyszczenie to utrzymanie, a nie projekt. Projekty mają datę końcową i praca przestaje się dziać. Utrzymanie to ciągłe obciążenie, którego ktoś jest właścicielem na zawsze, a udawanie, że jest inaczej, jest tym, co produkuje kolejny projekt czyszczenia.

Jak naprawdę wygląda „ciągłe”

Higiena utrzymuje się między czyszczeniami, gdy na miejscu są trzy elementy. Zwykle ich brakuje.

Warstwa reguł, która uruchamia się przy zapisie. Waliduje format, sprawdza względem listy wyboru, dopasowuje rozmyto względem istniejących kont i albo akceptuje rekord, albo kieruje wyjątek do kolejki. Bez niej nowy dryf napływa szybciej, niż stary dryf zostaje rozwiązany, a kolejka jest bezdenna od pierwszego dnia.

Kolejka wyjątków z przypisanym właścicielem, z imiennie wskazaną osobą i cyklicznym slotem. Nie „w ramach swojej roli” abstrakcyjnie — naprawdę w czyimś kalendarzu, w każdy wtorek o 10:00. Firmy, które utrzymują jakość swoich danych między czyszczeniami, wszystkie to mają. Te, które regresują, traktują kolejkę jako best-effort, co oznacza, że dostaje ona czas, który zostaje po wszystkim innym, co oznacza, że nie dostaje żadnego czasu.

Jakość danych raportowana jako metryka pierwszej klasy — wskaźnik duplikatów, kompletność pól, liczba przeterminowanych rekordów — na dashboardzie, który lider RevOps przegląda w normalnej kadencji. Jeśli te liczby stają się niewidoczne między projektami, zanim ktokolwiek znowu na nie spojrzy, już szacujesz zakres kolejnego czyszczenia.

Nasz playbook do czyszczenia danych CRM zbudowany jest wokół uczynienia tych trzech elementów zrównoważonymi bez tworzenia nowego etatu.

Wersja tej pracy, która nie regresuje, to ta, która zapobiega dryfowi w punkcie wejścia. Wersja oparta na czyszczeniu regresuje zawsze.