Przegląd kwartalny wdrożenia Kyber: co sprawdzamy

Firma dystrybucyjna, dziesięć miesięcy po uruchomieniu. Serwer na zapleczu nie stanął ani razu. Agenci co rano przygotowują zamówienia do dostawców, człowiek je zatwierdza, magazyn pracuje. Od przekazania nikt od dostawcy nie był na miejscu, a miesięczna faktura za wsparcie przychodzi i jest płacona, zanim ktokolwiek ją przeczyta.

Potem odchodzi szefowa finansów. Jej następca zadaje proste pytanie: co dokładnie ten system robi dziś samodzielnie i kto o tym zdecydował? Kierownik operacyjny otwiera plik z zasadami w repozytorium. Opisuje on firmę sprzed dziesięciu miesięcy. Od tego czasu doszły dwie linie produktów, jeden magazyn został zamknięty, a limit zatwierdzania w pliku był pisany pod wolumen, którego firma już nie robi.

Nic nie jest zepsute. I to jest problem: na system, który się nie psuje, nikt nie patrzy, a odległość między tym, co mówią zasady, a tym, co robi firma, rośnie po cichu z każdym tygodniem.

Przyczyną nie jest niczyje zaniedbanie. Umowa wsparcia napisana wokół incydentów tworzy kontakt tylko wtedy, gdy coś zawiedzie. Dobrze działające wdrożenie nie generuje incydentów, więc nie generuje kontaktu, a obraz firmy po stronie dostawcy zastyga w dniu przekazania. Naprawa jest strukturalna: umowa musi zaplanować patrzenie, z agendą, której nikt nie pominie dlatego, że wszystko wygląda w porządku.

Co się rozjeżdża, gdy nikt nie planuje spojrzenia

Zasady zostają w tyle za firmą. Plik z politykami dla agentów powstał z ludźmi, którzy wtedy podejmowali te decyzje. Ludzie zmieniają role, limity się zmieniają, dochodzą procesy. Reguła, która nadal mówi „zamówienia powyżej tej kwoty czekają na człowieka”, trzyma kwotę z innego roku, a reguła dla procesu, którego już nie ma, dalej działa na danych, na które nikt nie patrzy.

Dostępy przeżywają ludzi. Ktoś dołączył, zmienił stanowisko, przejął proces i odszedł. Każdy krok załatwiono na bieżąco i nigdy nie uzgodniono całości. Po roku lista tożsamości, które mogą czytać dane klientów, zawiera dwóch podwykonawców, z których jeden skończył wiosną, oraz wspólne konto założone podczas incydentu „tylko na chwilę”.

Modele się aktualizują, a nikt nie czyta ponownie ewaluacji. Wersja modelu się zmienia, zwykle z dobrych powodów. Ewaluacje sprzed uruchomienia robiono na starej. Czy agent prognozujący zachowuje się na Twoich danych tak samo, nie wiadomo, dopóki ktoś nie zapyta, a nikt nie pyta, póki liczby wyglądają wiarygodnie.

Kopie są robione i nigdy nie odtwarzane. Zadanie uruchamia się co noc i raportuje sukces. Sukces oznacza, że zapisano plik. Czy ten plik odtwarza się w działający system, z bieżącą konfiguracją i bieżącymi zasadami, ostatnio udowodniono w dniu przekazania, o ile w ogóle.

Wyjście staje się teoretyczne. Umowa mówi, co jest przekazywane przy wyjściu, w jakich formatach i w jakim czasie. Jeśli tej procedury nigdy nie uruchomiono, nikt nie wie, czy eksport nadal działa po trzech ostatnich aktualizacjach, a klauzula, która miała trzymać dostawcę w uczciwości, jest akapitem, którego nikt nie sprawdził.

Klient przestaje się uczyć. Po przekazaniu zespół umiał obsłużyć rutynę. Dwanaście miesięcy później dwie osoby, które przy tym siedziały, zmieniły pracę, a runbook opisuje ekrany, które od tego czasu się zmieniły. Zespół może zadzwonić do wsparcia, więc dzwoni, a wiedza, którą umowa miała przekazać, znów mieszka u dostawcy.

Co przegląd powinien zawierać

Użyteczna wersja to stała agenda, co kwartał ta sama, wpisana do umowy tak, żeby jej pominięcie było naruszeniem, a nie decyzją kalendarzową. Każdy punkt kończy się krótkim pisemnym wynikiem: sprawdzone, zmienione albo odłożone z podanym powodem.

1. Zasady kontra rzeczywistość. Przejście przez plik polityk z ludźmi, którzy dziś odpowiadają za te decyzje, a nie z tymi, którzy odpowiadali przy uruchomieniu. Każda reguła jest potwierdzona, zmieniona albo wycofana. Różnica trafia do repozytorium z datą.
2. Tożsamości i dostępy. Każde konto, każda tożsamość agenta, każda reguła sieciowa KyberCell, zestawione z aktualną listą ludzi i procesów. Wszystko bez imiennego właściciela jest usuwane, a nie odkładane.
3. Wersje modeli i ich ewaluacje. Które wersje działają dziś, co się zmieniło od ostatniego przeglądu i czy ewaluacje uruchomiono ponownie na danych firmy. Wersja bez świeżej ewaluacji to ustalenie, a nie szczegół.
4. Odtworzenie, nie raport z kopii. Wybór jednej kopii z kwartału i odtworzenie jej w osobnym środowisku. Potwierdzenie, że konfiguracja, zasady i dane wracają tak, jak powinny, i zapisanie, ile to trwało.
5. Gotowość do wyjścia. Uruchomienie eksportu opisanego w klauzuli wyjścia, w formatach, które ona wymienia. Sprawdzenie, czy to, co wychodzi, dałoby się przekazać innemu zespołowi i zrozumieć. Klauzula przećwiczona to klauzula, która działa.
6. Co klient potrafi już sam. Lista operacji, które zespół wykonał w tym kwartale bez wsparcia, i tych, o które dzwonił. Druga lista to agenda szkoleń na następny kwartał i powinna się kurczyć.

Test, który możesz zrobić w tym tygodniu

Otwórz swoją umowę wsparcia i wyszukaj słowo „przegląd”, „kwartalny” albo cokolwiek, jak nazywa to Twój dostawca. Jeśli taki zapis jest, przeczytaj, do czego go zobowiązuje, i porównaj z sześcioma punktami powyżej. Jeśli zapisu nie ma, zapytaj dostawcę o datę, kiedy ktoś ostatnio odtworzył kopię z Twojego systemu w działającym środowisku.

Jeśli odpowiedzią jest data, masz przegląd w praktyce, choć nie na papierze, i następnym krokiem jest spisanie go. Jeśli odpowiedzią jest to, że kopie robią się co noc i raportują sukces, właśnie dowiedziałeś się, czego umowa nie obejmuje, i dowiedziałeś się tego w spokojny dzień, a nie w ten drugi.

Umowa wsparcia z KYBERTIS ma zawierać przegląd tego kształtu, zaplanowany i udokumentowany, z klauzulą wyjścia ćwiczoną w jego ramach, a nie odłożoną do szuflady. Skąd bierze się taka umowa i dlaczego nie ma przy niej cennika, to temat kolejnego wpisu.