Jak zbudować fabrykę agentów w IT firmy: pętla etap po etapie

Fabryka agentów nie jest szybszą wersją starego cyklu pracy. To ten sam cykl zamknięty w pętlę, w której każdy etap zostawia zapis, a człowiek przesuwa się z wykonywania pracy do trzech punktów decyzji: zatwierdza opis, potwierdza weryfikację i zgadza się na wydanie. Wszystko pomiędzy przygotowują agenci.

Kto przeniesie stary proces jeden do jednego, tylko z agentem zamiast człowieka, dostanie więcej zmian, ale nie lepsze IT.

Pokazujemy tę pętlę na pracy, którą znamy najlepiej: zgłoszeniach i zmianach w IT średniej firmy. Ten sam kształt sprawdza się w księgowości i zakupach, o czym pisaliśmy w tekście fabryki agentów przyjdą do księgowości.

Stary cykl w jednym akapicie

Klasyczny cykl wytwarzania oprogramowania (SDLC) to sztafeta ludzi. Analityk zbiera wymagania, architekt projektuje, programista pisze, drugi przegląda, tester testuje, administrator wdraża. Wsparcie IT w średniej firmie wygląda tak samo, tylko krócej: pracownik pisze do informatyka, informatyk dzwoni do dostawcy, dostawca coś zmienia, ktoś sprawdza, czy działa. Między każdą parą jest przekazanie. Wiedza o tym, dlaczego coś ustawiono tak, a nie inaczej, żyje w głowach.

— Kto pamięta, czemu drukarka w magazynie ma stały adres? Pamiętał poprzedni informatyk. Odszedł dwa lata temu.

Ten model działał, bo najdroższy był czas specjalisty, a przekazania były ceną współpracy. W fabryce najtańsze staje się wykonanie, a najdroższa uwaga człowieka. To odwraca logikę całego cyklu.

Pętla w ośmiu etapach

1. Wejście — zgłoszenie, prośba, alert trafia do jednej kolejki.
2. Triage — agent sortuje i próbuje odtworzyć problem.
3. Opis — agent przygotowuje opis zmiany; człowiek zatwierdza.
4. Wykonanie — agent przygotowuje zmianę.
5. Recenzja — drugi agent sprawdza zmianę względem opisu.
6. Weryfikacja — agent przechodzi ścieżkę użytkownika i zapisuje dowód; człowiek potwierdza.
7. Wydanie — człowiek akceptuje i zmiana wchodzi.
8. Monitoring — agent obserwuje skutki i zakłada nowe zgłoszenia, które wracają na etap 1.

Nad pętlą pracuje koordynator. To agent, który odbiera wyzwalacz, decyduje, na którym etapie jest praca, i uruchamia właściwego agenta z właściwym modelem i kontekstem. Tańszy model do sortowania. Mocniejszy do opisu. Do recenzji ten, który najlepiej wypadł na Waszych zadaniach testowych.

1. Wejście: praca przychodzi w jednym miejscu

Mail do informatyka, wiadomość na czacie, telefon do biura, alert z kopii zapasowej. Wszystko trafia do jednej kolejki.

Dlaczego ważne: fabryka, do której praca wpada sześcioma drzwiami, nie wie, co ma na stole. Nie zmierzy ani przepustowości, ani kosztu.

Co się psuje bez tego: połowa pracy dzieje się poza pętlą, w prywatnych skrzynkach, bez śladu i bez metryk.

2. Triage: najtańsza oszczędność w całej pętli

Agent czyta zgłoszenie, sprawdza, czego dotyczy, i odkłada je do jednego z trzech koszy. Gotowe do wykonania: nowa osoba potrzebuje dostępu do wspólnego folderu działu, w którym już pracuje jej zespół. Niejasne, potrzebny opis: „VPN nie działa” od trzech osób naraz. Potrzebny człowiek: dostęp do folderu finansów dla osoby spoza działu, bo to decyzja właściciela danych, a nie IT.

Dlaczego ważne: sortowanie i wstępne rozpoznanie zjadają godziny najbardziej doświadczonej osoby. Tu dostaje zgłoszenia już posortowane, a drobne, jasne sprawy idą dalej bez niej.

Co się psuje bez tego: agent wykonawczy dostaje niejasne zadanie i sprawnie rozwiązuje nie ten problem.

3. Opis: tu decyduje się jakość pętli

Dla zadań niejasnych agent przygotowuje dwa krótkie dokumenty. Opis dla użytkownika: co pracownik zobaczy i zrobi po zmianie. Opis techniczny: którą grupę, regułę albo ustawienie zmieniamy, co jeszcze od tego zależy i jak to cofnąć. Człowiek czyta oba, poprawia i zatwierdza, zanim cokolwiek się zmieni.

Dlaczego ważne: to punkt o największej dźwigni. Poprawienie zdania w opisie kosztuje minutę. Odkręcenie zmiany reguły zapory, po której magazyn stracił drukarki, kosztuje poranek. Człowiek przestaje przeglądać gotową zmianę. Przegląda zamiar.

Co się psuje bez tego: recenzja zamienia się w archeologię. Ktoś próbuje zrozumieć z konfiguracji, co agent chciał zrobić, i odkrywa, że zrobił coś innego, niż chciała firma.

4. Wykonanie: najmniej ciekawy etap

Agent bierze zgłoszenie z triage albo zatwierdzony opis i przygotowuje zmianę: w konfiguracji zapisanej jako pliki, w środowisku testowym albo jako gotowy do uruchomienia skrypt.

Dlaczego ważne: mniej, niż się wydaje. Jeśli wejście, triage i opis działają, wykonanie jest najbardziej przewidywalną częścią pętli. Wszyscy chcą od niego zaczynać, bo tu widać efekt. To błąd.

Co się psuje, gdy zacznie się tylko od tego: szybki agent zmienia rzeczy na podstawie zgłoszeń, których nikt nie posortował ani nie opisał. Ludzie spędzają czas na cofaniu zamiast na zatwierdzaniu.

5. Recenzja: etap, który uczy się sam

Drugi agent przegląda każdą zmianę, zanim zobaczy ją człowiek. Ma przed sobą opis, więc ocenia zmianę względem zamiaru. Ma dostęp do środowiska testowego, więc może sprawdzić własną uwagę, zanim ją zostawi.

Do tego dochodzi pętla zewnętrzna. Kolejny agent zbiera uwagi, które ludzie zostawiają przy recenzjach, i co jakiś czas proponuje zmianę instrukcji recenzenta. Ta propozycja to zwykła zmiana do zatwierdzenia przez człowieka.

Dlaczego ważne: zwyczaje firmy („uprawnienia nadajemy grupom, nigdy osobom”, „nic nie zmieniamy w piątek po południu”) nie muszą być spisane z góry w dokumencie, którego nikt nie czyta. Narastają w instrukcji recenzenta z każdą uwagą.

Co się psuje bez tego: człowiek co tydzień powtarza te same pięć uwag.

6. Weryfikacja: człowiek potwierdza, zamiast śledzić

Agent loguje się jako użytkownik testowy i przechodzi ścieżkę od początku do końca: otwiera folder, drukuje stronę, łączy się z zewnątrz. Do zmiany dołącza zrzuty ekranu i porównuje wynik z opisem. Przy kopiach zapasowych to oznacza próbne odtworzenie, a nie zielony znaczek, o czym pisaliśmy przy kopii, której nikt nie odtworzył.

Dlaczego ważne: automatyczne testy sprawdzają to, co ktoś przewidział. Przejście ścieżki łapie to, czego nikt nie przewidział. Człowiek nie odtwarza zmiany sam. Ogląda dowód i mówi „tak” albo „nie”.

Co się psuje bez tego: ostatni krok przed wydaniem znowu zależy od tego, czy ktoś miał czas.

7. Wydanie: decyzja zostaje przy człowieku

Człowiek akceptuje zmianę i wypuszcza ją, najlepiej w uzgodnionym oknie prac.

Dlaczego ważne: to moment, w którym ryzyko przechodzi z IT na całą firmę. Ktoś musi się pod tym podpisać. Agent przygotowuje, sprawdza i podpowiada. Człowiek decyduje i odpowiada.

8. Monitoring: pętla się zamyka

Agent obserwuje skutki: logowania, kopie, dostępność usług. Wyłapuje nietypowe zachowania i sam zakłada zgłoszenie, które wraca na etap pierwszy. Przykład całej pętli aż do akceptacji: nocna kopia się nie wykonała, monitoring zakłada zgłoszenie, triage ustala przyczynę, wykonanie przygotowuje poprawkę, recenzja i weryfikacja ją sprawdzają, a rano człowiek dostaje gotową zmianę z dowodem.

Dlaczego ważne: bez tego etapu fabryka jest linią montażową. Z nim jest pętlą, w której środowisko samo zgłasza, co trzeba poprawić.

Druga pętla: fabryka, która ulepsza fabrykę

Nad pętlą pracy działa druga, mniej widoczna. Agent obserwator ocenia każdy przebieg: ile kosztował, ile razy człowiek musiał coś poprawić, czy zmiana nie wróciła potem jako nowe zgłoszenie. Na tej podstawie proponuje zmiany w samej fabryce: inny model na etapie triage, dokładniejszą instrukcję opisu, nową umiejętność recenzenta.

Żeby to było bezpieczne, definicja fabryki musi być zapisana jak kod: z historią wersji, z możliwością cofnięcia złej zmiany i sprawdzenia nowej wersji na stałym zestawie zadań testowych. Zmiana w fabryce idzie tą samą drogą co zmiana w środowisku: propozycja, recenzja, akceptacja człowieka. Fabryka, która sama zmienia swoje instrukcje, po trzech miesiącach robi rzeczy, których nikt nie rozumie.

Gdzie te pliki i ta historia mają leżeć, opisaliśmy w tekście czyja jest fabryka agentów. Krótko: u Was.

Stary cykl a fabryka

Wymiar	Stary cykl	Fabryka agentów
Kształt	sztafeta: przekazania między ludźmi	pętla: monitoring zasila nowe zgłoszenia
Gdzie patrzy człowiek	na gotową zmianę albo na skutki	na opis przed zmianą i na dowód po weryfikacji
Najdroższy zasób	czas specjalisty	uwaga człowieka w punktach decyzji
Wiedza o środowisku	w głowach i w nieaktualnej dokumentacji	w instrukcjach agentów i historii przebiegów, z wersjami
Sprawdzanie	„u mnie działa” i telefon od użytkownika	przejście ścieżki z dowodem i porównanie z opisem
Doskonalenie	przegląd raz na jakiś czas	ocena każdego przebiegu i propozycje zmian w fabryce
Praca w toku	prywatna, w czyjejś skrzynce	jawna, w kolejce fabryki
Odpowiedzialność za wydanie	człowiek	nadal człowiek

Ostatni wiersz jest najważniejszy. Wymagania, zatwierdzenie opisu i decyzja o wydaniu zostają przy ludziach. Zmienia się wszystko pomiędzy.

Gdzie automatyzacja szkodzi

Zadania, które tylko wyglądają na proste. „Zaktualizuj firmware przełącznika” brzmi jak praca dla agenta. Dopóki nowa wersja nie zmieni domyślnych ustawień sieci w magazynie. Zaczynajcie od zadań, w których błąd jest tani i od razu widać: dostęp do folderu w obrębie działu, reset hasła z potwierdzeniem tożsamości, oczywiste awarie usług.

Pomijanie opisu, bo agent i tak działa szybko. Szybkie działanie bez zatwierdzonego opisu to najdroższy sposób, żeby odkryć, że każdy rozumiał zadanie inaczej.

Agent z uprawnieniami administratora. Agent wykonawczy dostaje dokładnie te uprawnienia, których wymaga jego etap, na własnym koncie w katalogu, a nie konto administratora z hasłem w pliku. Inaczej nie da się odróżnić jego działań od działań ludzi, o czym pisaliśmy przy odejściu pracownika.

Samodoskonalenie bez hamulca. Zmiana w fabryce bez akceptacji człowieka to dryf, nie postęp.

Fabryka zamiast ludzi. Osoba od IT, której powiecie, że fabryka ma ją zastąpić, odejdzie, zanim fabryka zacznie działać, i zabierze wiedzę, której fabryka potrzebuje. Budowanie pętli to awans w odpowiedzialności, nie wyrok.

Po czym poznać, że fabryka działa

Metryka próżności	Metryka wyniku
liczba zamkniętych zgłoszeń	ile razy człowiek dotknął jednej sprawy od zgłoszenia do wydania (ma spadać)
liczba zużytych tokenów	koszt jednej zamkniętej sprawy i jego trend miesiąc do miesiąca
liczba uruchomionych agentów	odsetek spraw, które przeszły przez pętlę bez poprawek po akceptacji
czas pierwszej odpowiedzi	czas od zgłoszenia do działającej zmiany, częstotliwość zmian, odsetek zmian, które trzeba było cofnąć, czas przywrócenia działania

Ostatni wiersz to cztery klasyczne miary DORA, przełożone z wdrożeń oprogramowania na zmiany w środowisku. Pierwsza odpowiedź, którą mierzy wiele umów serwisowych, nie mówi, czy coś naprawiono, o czym pisaliśmy przy tym, co naprawdę obiecuje umowa na wsparcie IT. Ocena jakości przez drugi model może być uzupełnieniem. Jeśli rośnie liczba spraw, które wracają, żadna ocena modelu tego nie przykryje.

Kolejność budowy

Każdy krok daje działający system. Można zatrzymać się po dowolnym i nadal mieć coś, co pomaga.

1. Jedno wejście i triage. Wszystkie zgłoszenia w jednej kolejce, agent sortuje je do trzech koszy. Efekt: osoba od IT zaczyna dzień od posortowanej listy.
2. Opisy. Dla spraw niejasnych agent pisze opis dla użytkownika i opis techniczny, człowiek zatwierdza. Efekt: większe zmiany przestają utykać, bo wiadomo, co dokładnie ma się stać.
3. Recenzja z pętlą uczenia. Każda zmiana ma pierwszy przegląd, zanim zobaczy ją człowiek, a uwagi ludzi trafiają do instrukcji recenzenta.
4. Weryfikacja z dowodem. Agent przechodzi ścieżkę użytkownika i porównuje wynik z opisem. Efekt: człowiek potwierdza zamiast sprawdzać.
5. Połączenie i pomiar. Koordynator spina etapy, monitoring zasila wejście, obserwator ocenia przebiegi. Dopiero teraz działa druga pętla.

Pod spodem przez cały czas te same fundamenty: konta agentów w Waszym katalogu, konfiguracja zapisana jako pliki, historia przebiegów na Waszym koncie, objęta kopią. W tym kształcie projektujemy prowadzenie środowisk w SovereOS. Jesteśmy przed startem, więc to opis podejścia, a nie raport z wdrożeń.

Od czego zacząć w poniedziałek

Weźcie ostatnie dwadzieścia zgłoszeń do IT, z maili, czatu i notatek z telefonów, i ręcznie, w arkuszu, przypiszcie każde do jednego z trzech koszy. Jeśli więcej niż połowa trafia do kosza „niejasne”, pierwszym agentem w Waszej fabryce nie powinien być ten, który zmienia konfigurację. Powinien być ten, który pisze opisy.

Zostaje decyzja. Możecie dać osobie od IT agenta, który szybciej klika, i patrzeć, jak rośnie kolejka rzeczy do sprawdzenia i cofnięcia. Albo możecie zbudować pętlę, w której ta osoba przestaje robić i sprawdzać wszystko sama, a zaczyna zatwierdzać to, co naprawdę wymaga jej osądu.