Większość wniosków trafiających do działu IT jest powtarzalna: konto dla nowego pracownika, dostęp do udziału, skrzynka współdzielona, maszyna wirtualna o standardowych parametrach. Każdy z nich wymaga kilkunastu minut pracy i przeciętnie dwóch dni czekania w kolejce. Czas oczekiwania nie wynika z trudności zadania, lecz z tego, że człowiek musi je zauważyć, przeczytać i przeklikać.

Wzorzec

Automatyzacja obsługi wniosków składa się z czterech elementów, które istnieją w większości organizacji, tylko nie są ze sobą połączone:

  1. Formularz w systemie zgłoszeń ze strukturalnymi polami: nie „opisz, czego potrzebujesz”, lecz lista wyboru działu, pole z nazwą udziału, przełącznik odczyt/zapis.
  2. Akceptacja w tym samym systemie, przez przełożonego lub właściciela zasobu, według istniejących reguł.
  3. Wywołanie platformy automatyzacji po akceptacji: system zgłoszeń wysyła żądanie z zawartością formularza do API platformy uruchamiającej playbook lub skrypt.
  4. Zwrotny zapis wyniku do zgłoszenia: co zostało utworzone, z jakimi parametrami, albo jaki błąd wystąpił. Zgłoszenie zamyka się automatycznie lub wraca do kolejki dla człowieka.

Człowiek pojawia się w dwóch miejscach: przy akceptacji, jeśli reguły jej wymagają, i przy błędzie.

Zasady projektowe

Walidacja po stronie automatu, nie formularza. Formularz można zmienić, obejść albo wywołać API bezpośrednio. Playbook sprawdza każde pole: czy dział istnieje, czy nazwa spełnia konwencję, czy wnioskujący ma prawo prosić o ten zasób. Dane z zewnątrz są niezaufane niezależnie od źródła.

Idempotentność. Ponowne uruchomienie tego samego wniosku nie tworzy drugiego konta ani nie nadaje dostępu dwa razy. Jeśli zasób istnieje, automat to raportuje i kończy pracę bez błędu.

Konto serwisowe z minimalnymi uprawnieniami. Automat zakładający konta użytkowników nie potrzebuje uprawnień administratora domeny. Potrzebuje delegacji do jednej jednostki organizacyjnej. Każde uprawnienie ponad to jest ryzykiem bez korzyści.

Ślad. Każda akcja automatu jest zapisana z numerem zgłoszenia: w logu platformy, w opisie tworzonego obiektu, w komentarzu w zgłoszeniu. Pytanie „kto założył to konto i dlaczego” ma odpowiedź bez szukania.

Błąd jest widoczny. Nieudane wykonanie nie kończy się cichym zamknięciem zgłoszenia. Zgłoszenie wraca do kolejki z pełnym komunikatem błędu i oznaczeniem, że wymaga ręcznej interwencji.

Tryb próbny. Automat da się uruchomić z parametrem, który tylko raportuje, co zrobiłby. Pierwsze tygodnie działania nowego automatu odbywają się w tym trybie, z porównaniem wyniku z ręczną realizacją.

Od czego zacząć

Nie od najbardziej skomplikowanego wniosku, lecz od tego, który spełnia dwa warunki: ma największy wolumen i najmniejsze konsekwencje błędu. Zwykle jest to dostęp do udziału lub grupy dystrybucyjnej. Jeden typ wniosku doprowadzony do końca, z walidacją, śladem i obsługą błędów, jest szablonem dla wszystkich następnych.

Co mierzyć

Dwie liczby: czas od złożenia wniosku do jego realizacji oraz odsetek wniosków danego typu wykonanych bez udziału człowieka. Pierwsza pokazuje efekt dla użytkowników, druga pokazuje, gdzie automat jeszcze zawodzi i dlaczego.

Podsumowanie

Automatyzacja wniosków nie wymaga nowej platformy, tylko połączenia systemu zgłoszeń z narzędziem, które już wykonuje playbooki, przez API i według kilku zasad: dane z formularza są niezaufane, akcje są idempotentne, konto serwisowe ma minimalne uprawnienia, każda akcja ma ślad, a błąd wraca do człowieka. Dwa dni czekania zamieniają się w dwie minuty, a zespół IT zajmuje się wnioskami, które naprawdę wymagają decyzji.