Jak zaprojektować model operacyjny SIAM, który naprawdę działa

Wprowadzenie

Wiele modeli SIAM wygląda świetnie na slajdach. Są role, procesy, macierze RACI, warstwy governance i eleganckie diagramy. Problem zaczyna się wtedy, gdy przychodzi prawdziwy incydent.

Nagle okazuje się, że trzech dostawców ma trzy różne definicje priorytetu, każdy pracuje z innym narzędziem zgłoszeń, a odpowiedzialność za usługę end-to-end rozpływa się między zespołami. Model, który miał porządkować rzeczywistość, zostaje w folderze z dokumentacją.

Dlatego skuteczny SIAM nie zaczyna się od perfekcyjnego procesu. Zaczyna się od prostego pytania: czy ten model pomoże ludziom działać szybciej, spokojniej i bardziej odpowiedzialnie wtedy, gdy dojdzie do “pożaru” i eskalacji?

Dlaczego wiele modeli SIAM nie działa

Najczęstszy błąd polega na tym, że model operacyjny projektuje się z perspektywy dokumentu, a nie codziennej pracy operacyjnej. Organizacja chce od razu opisać wszystko: polityki, procesy, role, macierz eskalacji, narzędzia, raportowanie i governance.

Na papierze wygląda to dojrzale. W praktyce bywa zbyt ciężkie, żeby ktokolwiek chciał tego używać jak przyjdzie do tego okazja.

Drugi problem to oderwanie od realiów dostawców. Każdy z nich ma własne SLA, własną kulturę pracy, własne ograniczenia kontraktowe i własne narzędzia w tym obsługujące zgłoszenia. Jeśli SIAM nie uwzględnia tej rzeczywistości, staje się kolejną warstwą biurokracji zamiast warstwą integracji. Więcej o tym, gdzie kończą się możliwości samego ITIL-a, pisałem osobno.

Trzy elementy działającego modelu SIAM

1. Governance, które działa nie tylko na spotkaniach

Governance w SIAM to nie cykliczne statusy i prezentacje. To jasne zasady podejmowania decyzji.

 

• • Kto decyduje w sytuacji krytycznej?

• • Kiedy eskalujemy i do kogo?

• • Kto ma prawo zmienić priorytet?

• • Kto bierze odpowiedzialność za usługę end-to-end?

Jeżeli odpowiedzi na te pytania trzeba szukać dopiero podczas incydentu lub jako “lessons learnt” to governance nie działa poprawnie.

Dobry model governance jest prosty, zrozumiały i możliwy do zastosowania pod presją czasu. Nie może wymagać idealnych warunków, bo operacje rzadko działają w idealnych warunkach.

2. Integracja, czyli wspólny sposób pracy

Integracja w SIAM nie oznacza wyłącznie integracji systemów i narzędzi. To przede wszystkim wspólny sposób działania.

 

• • Wspólny proces obsługi incydentów, problemów, zmian.

• • Wspólne zasady przekazywania odpowiedzialności.

• • Wspólny kalendarz zmian.

• • Wspólny widok na jakość usługi.

Bez tego każdy dostawca działa poprawnie we własnym zakresie, ale cała usługa nadal może źle funkcjonować.

To jedna z największych pułapek środowisk multi-vendor: lokalnie wszystko jest „zielone”, a z perspektywy biznesu użytkownik nadal ma problem.

3. Współpraca między dostawcami

SIAM nie zadziała, jeśli dostawcy będą traktować się jak rywale. A będą, jeśli system motywuje ich wyłącznie do obrony własnego SLA. 

Dlatego model operacyjny musi wzmacniać współpracę: wspólne retrospektywy, wspólne cele i inicjatywy naprawcze, transparentne dane i jasne zasady odpowiedzialności. Jak budować taką współpracę na co dzień, opisuję w osobnym wpisie o sztuce zarządzania środowiskiem wielu dostawców.

Nie chodzi o to, żeby wszyscy byli dla siebie mili. Chodzi o to, żeby wszystkim opłacało się działać na rzecz jednej usługi.

Minimalny model SIAM w 90 dni

Nie trzeba od razu wdrażać pełnego, wielowarstwowego modelu. W wielu organizacjach lepiej zacząć od wersji minimum, która działa natychmiast.

1–30 dni: fundamenty

Wybierz kilka kluczowych usług. Ustal, które z nich są najbardziej problematyczne, gdzie pojawia się najwięcej eskalacji i gdzie odpowiedzialność najczęściej się rozmywa.

Na tym etapie warto zdefiniować:

 

• • właściciela usługi end-to-end – Service Ownera,

• • prostą macierz decyzyjną RACI,

• • podstawowe reguły eskalacji (kiedy, jak i do kogo)

• • jeden wspólny proces, najlepiej zacząć od major incident management.

31–60 dni: uruchomienie

Zacznij pracować według nowego modelu. Nie czekaj, aż będzie idealny. Wprowadź krótkie forum operacyjne, zbieraj dane, obserwuj tarcia i sprawdzaj, gdzie proces nie pasuje do rzeczywistości.

To etap, w którym organizacja uczy się nowego sposobu pracy.

61–90 dni: optymalizacja

Dopiero teraz warto poprawiać model. Na podstawie danych, a nie przypuszczeń czy założeń.

Możesz dodać kolejny proces, np. change lub problem management, przeprowadzić pierwszą retrospektywę w kilkoma dostawcami / interesariuszami i ustalić kilka wspólnych KPI na kolejny kwartał. Przy wyborze tych KPI warto od razu myśleć szerzej niż samo SLA, o czym piszę w tekście od dostarczania usług do tworzenia wartości.

Podsumowanie

Model SIAM nie musi być doskonały. Musi być praktyczny i użyteczny.

Jeśli ludzie rozumieją, jak z niego korzystać, dostawcy wiedzą, kto za co odpowiada, a biznes widzi jedną spójną usługę zamiast chaosu między kontraktami, model zaczyna spełniać swoją rolę.

Dobry SIAM nie jest dokumentem. Jest sposobem działania.