Autonomię wyznacza to, czego pętla nie może dotknąć

Weźmy starannie zautomatyzowany proces zakupowy. Może samodzielnie składać zamówienia do określonej kwoty; wszystko powyżej czeka na człowieka. Limit jest rozsądny, opisany i przetestowany. Jest też liczbą w tabeli ustawień, w tej samej bazie, do której proces zapisuje, dostępną przez te same poświadczenia, których używa do wszystkiego innego.

Nie musi się wydarzyć nic złego, żeby to był problem. Pewnego dnia migracja konfiguracji wyzeruje tabelę. Albo dobra intencja sprawi, że limit stanie się regulowany, żeby proces poradził sobie w sezonie. Albo proces zacznie składać wiele zamówień tuż pod limitem — każde dozwolone, a razem daleko poza tym, co ktokolwiek zamierzał. W każdej z tych wersji granica była prawdziwa do chwili, w której przestała — bo mieszkała wewnątrz tego, co miała ograniczać.

Dlaczego tak się dzieje

Granice ustawiają zwykle ludzie budujący automatyzację, w chwili, gdy próbują sprawić, żeby w ogóle działała — i lądują tam, gdzie było wygodnie: we własnej konfiguracji procesu, egzekwowane jego własnym kodem, na koncie technicznym z szerokimi uprawnieniami, żeby pierwsze wdrożenie się nie wywróciło. Tak buduje się prototyp i to jest w porządku. Tak nie definiuje się tego, co wolno systemowi autonomicznemu, bo wtedy definicja jest częścią systemu, a nie ograniczeniem nałożonym na niego.

Kiedy każdy krok zatwierdza człowiek, prawie nie ma to znaczenia — granicą jest człowiek. W działalności autonomicznej granica jest najważniejszym elementem projektu. To ona odróżnia pętlę, która może się mylić, od pętli, której pomyłki mają znaną maksymalną wielkość.

Jak zawodzą granice

Leżą tam, gdzie pętla może pisać. Limity zapisane we własnej konfiguracji pętli, sprawdzane jej własnym kodem, pod jej własnymi poświadczeniami. Limit, który system może zmienić, jest wartością domyślną, a nie limitem.

Dotyczą pojedynczego działania, nie sumy. „Żadne zamówienie powyżej tej kwoty” nic nie mówi o stu zamówieniach tuż poniżej. Liczy się łączna ekspozycja: na godzinę, na dzień, na kontrahenta, na wszystko, co pętla ma w toku.

Opisują możliwości, nie skutki. „Może korzystać z interfejsu płatności” to uprawnienie do narzędzia. „Może zapłacić najwyżej tyle, na te rachunki, tak często” to granica skutku. Pierwsze jest prawie zawsze szersze, niż ktokolwiek chciał, bo narzędzia buduje się do robienia wielu rzeczy.

Rosną po cichu. Za każdym razem, gdy limit blokuje pętlę, ktoś prosi o jego podniesienie — i zwykle prośba jest rozsądna. Nikt nie śledzi, jak bardzo rama urosła przez rok, więc porusza się tylko w jedną stronę.

Na krawędzi nic nie jest zdefiniowane. Co pętla ma zrobić, gdy dojdzie do limitu: zatrzymać się, poczekać, spróbować czegoś mniejszego, kogoś powiadomić? Jeśli tego nie określono, system adaptacyjny znajdzie ścieżkę, która nadal działa — czyli dokładnie odwrotność tego, czemu granica służy.

Najpierw rama, potem pętla

Kolejność ma znaczenie. Zanim ustalisz, co pętla ma robić, zapisz, czego nigdy nie może móc zrobić i jaki może być najgorszy skutek każdego dozwolonego działania. Potem zbuduj pętlę wewnątrz tego, zamiast rysować granicę na końcu wokół wszystkiego, czego pętla akurat potrzebowała.

Egzekwuj z zewnątrz. Osobny komponent stoi między pętlą a wszystkim, co kosztuje pieniądze, przemieszcza towar albo kontaktuje się z ludźmi — z własnymi poświadczeniami i własną konfiguracją. Pętla nie ma żadnego poświadczenia, które pozwoliłoby go obejść. To ta sama zasada, na której opiera się wyłącznik, którego system nie dosięgnie: zatrzymanie to po prostu najwęższa możliwa granica.

Ograniczaj skutki, nie narzędzia. Kwoty, kontrahenci, częstotliwość, strefy fizyczne, łączna ekspozycja. Jeśli najgorszego przypadku danego działania nie da się wyrazić liczbą albo listą, to działanie nie jest jeszcze ograniczone.

Niech dojście do granicy będzie zwyczajne. Osiągnięcie limitu to normalne, zapisywane zdarzenie ze zdefiniowaną reakcją, a nie błąd. Warto patrzeć, jak często pętla napiera na swoje granice, z tego samego powodu, dla którego patrzy się na częstość napraw: rosnąca liczba znaczy, że działalność i jej rama rozjeżdżają się.

Poszerzanie ramy to decyzja. Podniesienie limitu robi wskazana z nazwiska osoba, poza pętlą, a powód trafia do rejestru decyzji. Dzięki temu powolny wzrost ramy staje się czymś, co widać i o co można się spierać.

Nic z tego nie czyni pętli mniej zdolną wewnątrz jej ramy. Sprawia natomiast, że właściciel potrafi tę ramę opisać — a to warunek, żeby w ogóle mógł odpowiadać za to, co dzieje się w środku.

Test na dziś

Wybierz jeden zautomatyzowany proces, który może wydać pieniądze, zmienić cenę, wysłać wiadomość do klienta albo przemieścić coś fizycznego. Spisz wszystkie poświadczenia, jakie ma. Przy każdym zapisz najgorszą rzecz, jaką da się nim zrobić w ciągu godziny — niezależnie od tego, do czego proces ma go używać.

Potem przy każdej pozycji zapytaj, czy cokolwiek poza samym procesem by to zatrzymało. Tam, gdzie odpowiedź brzmi „proces by tego nie zrobił”, znalazłeś lukę między granicą, w którą wierzysz, a tą, która istnieje.

Ludzka rama prawna to jeden z sześciu komponentów programu Demertis i ten, w którym muszą się zmieścić wszystkie pozostałe.