Pilotaż się udał. Skalowanie to inny projekt

Pilotaż trwał cztery miesiące w zespole obsługi klienta. Kierowniczka zespołu sama się zgłosiła, dwie osoby, które używały narzędzia najczęściej, były tymi, które o nie prosiły, a inżynier danych spędził pierwsze sześć tygodni na ręcznym czyszczeniu historii zgłoszeń, żeby model miał z czego się uczyć. Konsultanci siedzieli dwa biurka dalej i naprawiali rzeczy tego samego popołudnia. Na koniec jest demo, krótki raport i wyraźne poczucie, że zadziałało.

Zarząd zadaje naturalne pytanie: kiedy dostanie to każdy zespół? Powstaje plan wdrożenia, który kopiuje pilotaż do jedenastu innych zespołów w dwa kwartały. Pół roku później trzy zespoły używają narzędzia codziennie, cztery spróbowały i przestały, a reszta czeka na poprawkę w danych, która nie ma właściciela.

Skalowanie potraktowano jako więcej tego samego. To nie było to samo. Pilotaż to test w warunkach dobranych tak, żeby się udał. Skalowanie to spotkanie z warunkami, których nikt nie dobierał.

Czego pilotaż nie sprawdził

Procesów innych zespołów. Proces zespołu pilotażowego został opisany, uproszczony i uzgodniony, zanim pojawiło się narzędzie. Następny zespół robi nominalnie tę samą pracę w innej kolejności, z innymi wyjątkami, i założenia narzędzia pękają w pierwszym tygodniu. Tekst o niezdefiniowanych procesach tłumaczy dlaczego; skalowanie mnoży to przez liczbę zespołów.

Danych takich, jakie są naprawdę. Dane do pilotażu były wybrane, wyczyszczone, a miejscami poprawione ręcznie. Dane produkcyjne przychodzą z każdego systemu, ze wszystkimi lukami i niespójnościami. Narzędzie jest to samo; jego wejście już nie, a jakość wyniku idzie za wejściem.

Wsparcia, gdy nikt nie siedzi dwa biurka dalej. W pilotażu problem naprawiał tego samego dnia ktoś, kto rozumiał narzędzie. W skali problem trafia do kolejki. Doświadczenie drugiego zespołu z narzędziem to głównie doświadczenie z tą kolejką, a żadne demo tego nie zmierzyło.

Szkolenia, które nie jest rozmową. Zespół pilotażowy nauczył się narzędzia, rozmawiając z ludźmi, którzy je zbudowali. Jedenasty zespół dostaje nagranie i dokument. To, co w pilotażu przeszło nieformalnie, w skali trzeba zaprojektować, spisać i nauczyć celowo, a nikt tego nie zabudżetował.

Kto płaci i kto jest właścicielem. Pilotaż był finansowany z budżetu na innowacje i należał do programu. W skali koszt utrzymania ląduje w dziale, który go nie wybierał, a decyzja o utrzymaniu u kierownika, którego nikt nie pytał. Oboje mają prawo powiedzieć nie.

Ludzi, którzy się nie zgłosili. Zespół pilotażowy chciał. Następnym zespołom powiedziano. Tekst o oporze wyjaśnia, dlaczego ich reakcja jest zwykle rozsądna; plan wdrożenia zbudowany na entuzjazmie zespołu pilotażowego weźmie ją za sabotaż.

Potraktujcie skalowanie jak nowy projekt

Zdiagnozujcie każdy zespół przyjmujący, krótko. Nie program, tylko szybkie spojrzenie: jak ten zespół robi tę pracę dziś, które systemy go zasilają, co musiałoby być prawdą, żeby narzędzie pasowało. Część zespołów będzie pasować od razu, część po zmianie procesu, część wcale. Wiedzieć które jest które przed wdrożeniem jest taniej niż odkrywać to w trakcie.

Zastąpcie pracę ręczną potokami przed drugim zespołem. Cokolwiek inżynier danych robił ręcznie na potrzeby pilotażu, musi działać automatycznie, codziennie, na danych, których nikt nie oglądał. Jeśli tego nie da się zbudować, wynik pilotażu się nie przenosi i lepiej wiedzieć to w pierwszym tygodniu.

Zbudujcie wsparcie i szkolenia jako produkty. Imienny właściciel, czas reakcji, wokół którego da się planować, ścieżka szkoleniowa działająca bez pierwotnych twórców. To nie są koszty uboczne wdrożenia; to jest jego większość.

Przenieście budżet i decyzję do linii. Dział, który będzie narzędzie utrzymywał, powinien sam zdecydować, czy je przyjmuje, z kosztem utrzymania we własnych liczbach. To wolniejsze niż centralny nakaz i daje adopcję, która przeżyje koniec programu.

Kolejkujcie zespoły i pozwólcie pierwszym zmieniać projekt. Dwa zespoły naraz, a druga fala poprawiona o to, co znalazła pierwsza. Plan, który stawia jedenaście zespołów na jednym wykresie Gantta, to plan odkrycia tego samego problemu jedenaście razy.

Co zmierzyć, zanim zdecydujecie o skalowaniu

Raport z pilotażu mówi, że zadziałało. Przed skalowaniem zapytajcie, wobec czego zadziałało: wobec punktu wyjścia zmierzonego przed startem, jak argumentuje tekst o punkcie wyjścia, czy wobec wrażenia powstałego w trakcie. Potem zadajcie trzy węższe pytania. Jak duża część wyniku zależała od pracy ręcznej, ochotników i ludzi dwa biurka dalej i co zostaje bez nich. Ile miesięcznie kosztowało utrzymanie, licząc czas ludzi, którzy to naprawiali. I który z zespołów przyjmujących ma proces na tyle bliski zespołowi pilotażowemu, żeby wynik miał prawo się powtórzyć.

Jeśli odpowiedzi nie są znane, decyzja o skalowaniu zapada na podstawie opowieści o pilotażu, a nie jego dowodów, i komitet sterujący powinien usłyszeć to wprost.

Uczciwa opcja

Czasem właściwą odpowiedzią jest nie skalować. Zespół pilotażowy zachowuje narzędzie, bo u niego działa; inne zespoły go nie dostają, bo u nich by nie działało; a budżet idzie na inny problem. Pilotaż, który tak się kończy, zrobił swoje. Porażką nie jest pilotaż, który zostaje mały; porażką jest wdrożenie utrzymywane przy życiu, bo zatrzymanie wyglądałoby jak przyznanie, że pilotaż był błędem, choć nie był.

Test na dziś

Weźcie raport z pilotażu i narysujcie dwie kolumny. Po lewej każdy warunek, który był prawdziwy w trakcie pilotażu: kto był w zespole, kto co czyścił, kto co naprawiał, skąd były pieniądze. Po prawej, czy każdy z nich będzie prawdziwy dla następnego zespołu.

Jeśli zmienia się więcej niż kilka warunków, skalowanie jest nowym projektem, a właściwym następnym krokiem jest diagnoza zespołów przyjmujących, nie plan wdrożenia. To moment, w którym praca VUCALE nad ramą problemu zaczyna się od nowa, zamiast toczyć się dalej, i w którym wynikiem tej pracy może być to, że pilotaż powinien zostać tam, gdzie jest.