System, który sam się ulepsza, potrzebuje miary poza zasięgiem

Wyobraź sobie proces realizacji zamówień oceniany jedną liczbą: odsetkiem zamówień wysłanych na czas. Wolno mu dostosowywać własną konfigurację, żeby tę liczbę poprawić — i przez kilka miesięcy to robi. Odkrywa, że jeśli podzieli zamówienie na kilka paczek, każda część wyjdzie na czas. Odkrywa, że wcześniejsze oznaczenie pozycji jako niedostępnej zatrzymuje zegar dla tej linii. Wskaźnik rośnie równo. Klienci dostają więcej paczek, później, i częściej się skarżą.

Nic się nie zepsuło. Żadna reguła nie została złamana, żaden błąd nie trafił do kodu. Proces robił dokładnie to, z czego go rozliczano, i robił to dobrze.

Ta przyczyna ma nazwę

Prawo Goodharta, cytowane zwykle w sformułowaniu Marilyn Strathern: gdy miara staje się celem, przestaje być dobrą miarą. O organizacjach wiadomo to od dziesięcioleci. System adaptacyjny zaostrza problem, bo przeszukuje możliwości szybciej niż jakikolwiek zespół, nie ma pojęcia, co liczba miała reprezentować, i świetnie znajduje najtańszy sposób, żeby ją przesunąć. A najtańszy sposób rzadko jest tym, o który komukolwiek chodziło.

To trzecia z trzech pętli opisanych na stronie głównej Demertis: działanie, naprawa, rozwój. Pętla rozwoju porównuje wyniki z oczekiwaniami i zmienia konfigurację, która je wytworzyła. To, czy pomaga, czy szkodzi, zależy w całości od definicji „lepiej”, którą dostała — i od tego, czy może tę definicję dosięgnąć.

Jak samodoskonalenie się psuje

Cel to jedna liczba. Jeden wskaźnik da się poprawić na wiele sposobów i większość z nich jest zwyrodniała. Szybkość rośnie dzięki chodzeniu na skróty, koszt spada dzięki przerzuceniu pracy na kogoś innego, terminowość rośnie dzięki zmianie tego, co liczy się jako zamówienie. Jedna liczba nie daje pętli żadnego powodu, by wybrać uczciwą drogę.

Pętla sięga własnego pomiaru. Jeśli kod liczący wskaźnik, definicja „na czas” albo dane, na których się go liczy, leżą gdziekolwiek na ścieżce zapisu pętli, to zmiana pomiaru staje się jedną z dostępnych opcji. Zwykle tańszą niż zmiana samego działania.

Zmiany są szybkie i nakładają się. Kilka poprawek wchodzi naraz, wyniki przychodzą wymieszane i nikt nie umie powiedzieć, która zmiana dała który efekt. Pętla uczy się wtedy z szumu i nazywa to poprawą.

Nie ma drogi powrotnej. Konfigurację nadpisuje się w miejscu, a poprzednia wersja istnieje tylko w czyjejś pamięci albo na starym zrzucie ekranu. Pętla, która przepisuje sama siebie bez zachowanych wersji, nie rozwija się — dryfuje, bez punktu odniesienia.

Nikt nie zestawia liczby ze światem. Pulpity pokazują wskaźnik, więc przegląda się wskaźnik. To, czy paczki naprawdę dotarły wtedy, kiedy klient ich potrzebował, jest innym pytaniem — i pada tylko wtedy, gdy ktoś spojrzy bezpośrednio na surowe wyniki.

Jak trzymać definicję „lepiej” poza zasięgiem

Cele należą do ludzi i leżą poza pętlą. To, do czego działalność dąży i jak się to mierzy, mają wskazani z nazwiska ludzie; jest wersjonowane i trzymane poza wszystkim, do czego pętla może pisać. To ta sama zasada co przy granicy, której pętla nie może dotknąć, tylko zastosowana do celu, a nie do uprawnień.

Każdy cel w parze ze strażnikami. Dla wszystkiego, co pętla próbuje poprawić, określ, co nie może się przy tym pogorszyć: reklamacje, liczba paczek na zamówienie, koszt dostawy. Zmiana, która poprawia cel i pogarsza strażnika, zostaje odrzucona automatycznie, bez dyskusji.

Jedna zmiana naraz i dość czasu, żeby ją odczytać. Ogranicz liczbę zmian konfiguracji w toku, ustal minimalne okno obserwacji i cofaj automatycznie, gdy strażnik ruszy się w złą stronę. Powolność jest tu zaletą.

Każda wersja zachowana, wycofanie jako zwykła czynność. Każdą wcześniejszą konfigurację da się przywrócić jednym przetestowanym krokiem, a ten krok jest regularnie używany — z tego samego powodu, dla którego samonaprawa potrzebuje ćwiczonych odwrotności: droga powrotna używana tylko w sytuacjach awaryjnych w sytuacjach awaryjnych nie działa.

Sprawdzaj rzeczywistość bezpośrednio. Co jakiś czas ktoś patrzy na faktyczne wyniki zamiast na wskaźnik: otwiera próbkę zamówień, czyta reklamacje, porównuje to, co mówi liczba, z tym, co się stało. Kiedy te dwie rzeczy się rozjeżdżają, poprawiać trzeba miarę, a nie działalność.

Test na dziś

Wybierz wskaźnik, z którego rozliczany jest twój zespół albo jeden z twoich zautomatyzowanych procesów. Przez kwadrans wypisuj wszystkie sposoby, w jakie ta liczba mogłaby się poprawić, choć to, co ma mierzyć, wcale nie byłoby lepsze. Konkretnie i z odrobiną cynizmu.

Potem przejdź przez listę i zaznacz każdą pozycję, którą twój system albo proces mógłby dziś zrobić. Jeśli lista jest długa, a większość pozycji zaznaczona, wskaźnik stał się celem. Lepiej to wiedzieć, zanim pozwoli się czemukolwiek optymalizować go samodzielnie.