Jak działa AutomaIT
AutomaIT łączy analizę procesu, architekturę systemów, development i operacje IT. Bezpieczeństwo danych, kontrola zmian i audytowalność są częścią rozwiązania od początku.
Poniższe wzorce pochodzą z narzędzi zbudowanych na potrzeby organizacji zatrudniających setki osób. Opisany jest sposób rozwiązania problemu, bez nazw, konfiguracji, architektury i skali konkretnego wdrożenia. Ten sam wzorzec działa w firmie kilkunastoosobowej, tylko w mniejszej skali.
Konto pracownika powstaje, zmienia zakres i wygasa na podstawie zdarzenia kadrowego, a nie zgłoszenia do działu IT. Źródłem prawdy jest system HR, katalog użytkowników i skrzynki są jego pochodną. Odejście z firmy odbiera dostęp tego samego dnia, bez pamiętania o tym przez człowieka.
Nadanie, okresowy przegląd i odebranie uprawnienia są osobnymi krokami, a każdy zostawia dowód. Dostęp bez wskazanego właściciela i bez daty ważności nie powstaje, więc lista uprawnień nie rośnie w nieskończoność.
Liczba potrzebnych licencji, kont i miejsc kontraktowych jest wyliczana z historii rok do roku, zanim stanie się pilnym zakupem. Negocjacja z dostawcą zaczyna się od danych, a nie od terminu odnowienia.
Proces prowadzony we współdzielonym arkuszu zostaje zamieniony na aplikację z modelem danych, rolami i historią zmian. Operacja przestaje zależeć od jednej osoby, która wie, jak ten plik działa.
Telemetria z przeglądarek i laptopów zwraca w większości szum, czyli pakiety systemowe, biblioteki i procesy działające w tle. Gemini uruchomiony przez Vertex AI pracuje tu jako klasyfikator na wejściu i oddziela oprogramowanie faktycznie używane przez ludzi od tego, co po prostu jest zainstalowane. Dopiero tak odsiany zbiór nadaje się na inwentarz oprogramowania i na prognozę zapotrzebowania opisaną obok. Nie ma tu okna czatu ani asystenta, model jest elementem potoku danych.
Asystent odpowiadający pracownikom na pytania o wewnętrzne procedury jest wart tyle, ile baza, z której korzysta. Baza pisana ręcznie starzeje się od pierwszego dnia, bo rozwiązania powstają w zgłoszeniach, a nie w dokumentacji. Wdrożony wzorzec zamyka tę lukę automatycznie. Asystent działa w Atlassian Rovo, a warstwę przetwarzania zamkniętych zgłoszeń na wpisy obsługuje Claude Opus.
Asystent odpowiada wyłącznie na podstawie wskazanych dokumentów firmowych, z zachowaniem uprawnień do nich.
Zamknięty ticket zawiera diagnozę i działające rozwiązanie, którego nie było w dokumentacji.
Treść zgłoszenia jest przetwarzana na wpis w bazie wiedzy i staje się dostępna dla kolejnych pytań.
Ten sam problem nie trafia drugi raz do kolejki, tylko zostaje obsłużony przy pierwszym kontakcie.
Model nie jest douczany. Zmienia się baza, z której korzysta, i to jest zaletą, a nie ograniczeniem. Każdy wpis da się obejrzeć, poprawić i cofnąć, a odpowiedź asystenta zawsze można przypisać do konkretnego zgłoszenia źródłowego. Rozwiązanie oparte na treningu modelu nie daje żadnej z tych trzech możliwości.
Uprawnienia są ograniczane do potrzebnego minimum, a role i operacje administracyjne mają wskazanego właściciela.
Ważne operacje pozostawiają ślad pozwalający ustalić zdarzenie, zakres danych i rezultat.
Wdrożenie obejmuje test, kopię, plan wycofania i ocenę wpływu na systemy zależne.
Integracja otrzymuje obsługę błędów, ponowienia, monitoring i jasno określoną odpowiedzialność.
Ustalane są potrzeby użytkowników, dane, ograniczenia i oczekiwany rezultat.
Architektura opisuje granice, zależności, dostęp i sytuacje awaryjne.
Rozwiązanie jest sprawdzane na uzgodnionych scenariuszach i danych testowych.
Kod, dostęp i dokumentacja ograniczają zależność klienta od jednego wykonawcy.
Nazwy, architektura, dane oraz materiały z poufnych projektów nie są publikowane. Przykładowe scenariusze na stronach usług pokazują metodę realizacji, ale nie są przedstawiane jako case study konkretnej organizacji.
