SIAM Quickstart Kit
Multi-vendor bez chaosu

Kalendarz pęka od statusów, ale nikt nie pamięta, co ustalono tydzień temu. Spotkania nie mają jasnego celu, nie kończą się decyzjami, a follow-up istnieje tylko w głowach uczestników. Governance istnieje na papierze, ale realnie nie generuje wartości — ludzie wychodzą ze spotkań z poczuciem zmarnowanego czasu.

Każde spotkanie zaczyna się od jednego celu i kończy decyzjami z ownerami. Wdroź Action Tracker — prostą tabelę: owner / działanie / termin / miara sukcesu / status. Zamiast kolejnego calla użyj asynch update — szablon 6 zdań wysłany na kanale zespołu. Reguła: jeśli temat da się zamknąć asynchronicznie — nie potrzebuje spotkania.

RACI powstał na początku projektu, żyje w PowerPoincie, ale nikt go nie otwiera. Kiedy wybucha pożar, ludzie wciąż pytają „kto to powinien wziąć?". W efekcie każdy czeka na drugiego, a czas ucieka. Problem pogłębia się, gdy vendorzy mają inną interpretację ról niż zespół wewnętrzny.

Nie wystarczy mieć RACI — trzeba go ćwiczyć. Przygotuj 3 scenariusze walkthrough: MI, breach SLA i vendor dispute. Raz w miesiącu 15-minutowy table-top — przejście scenariusza krok po kroku z zespołem. Nie chodzi o testowanie wiedzy, lecz o budowanie nawyku: „ja wiem, kto robi co, i nie muszę pytać".

Na vendor review wszystko jest zielone — SLA compliance 99%, czas reakcji w normie. Ale biznes dzwoni z frustracją, bo ticket krąży 5 dni między zespołami. Lokalne KPI nie oddają prawdy o doświadczeniu użytkownika końcowego. Vendor optymalizuje swój fragment, nie patrząc na cały łańcuch.

Zdefiniuj minimum 3 KPI E2E — np. czas od zgłoszenia do rozwiązania, % ticketów zamkniętych w pierwszym kontakcie, user satisfaction. Powiąż vendor scorecard z wpływem na te wskaźniki. Jeśli vendor jest zielony, ale E2E jest czerwony — to problem do rozwiązania wspólnie, nie wymówka.

Na service review pojawiają się wnioski i pomysły — ale po miesiącu te same tematy wracają. Akcje istnieją w notatkach, ale nie mają ownerów, terminów ani miary sukcesu. Nikt nie weryfikuje, czy działanie przyniosło efekt. W efekcie spotkania generują „listę życzeń", nie realne zmiany.

Wdroź szablon CAPA dla każdego działania: co robimy → kto jest ownerem → do kiedy → jaka jest miara sukcesu → jakie evidence potrzebujemy na zamknięcie. Zasada: bez ownera i terminu — nie ma akcji. Zamykanie akcji wymaga evidence (link, screenshot, raport before/after).

Podczas Major Incidentu trzy osoby mają trzy różne wersje statusu — jedna z maila, druga ze Slacka, trzecia z war roomu. Biznes dostaje sprzeczne informacje. Nikt nie wie, który status jest aktualny. Po incydencie nie da się odtworzyć co się działo, bo nie ma jednego rekordu do odwołań.

Wybierz 1 kanał i 1 format statusu — i traktuj go jako jedyne źródło prawdy. Format: Status | Impact | Co zrobiono | Co dalej | ETA | Next update. Reguła dla wszystkich: „jeśli nie ma w SST — nie istnieje". To dotyczy też vendorów — ich update'y muszą trafiać do tego samego miejsca.

Eskalacje zdarzają się „gdy komuś puszczą nerwy", nie gdy spełnione są kryteria. Jedne problemy eskalowane są za wcześnie (bo ktoś się zdenerwował), inne za późno (bo nikt nie chciał „robić problemu"). Brak jasnych progów i formatów powoduje, że eskalacja to emocja, nie narzędzie zarządzania.

Zdefiniuj 3 poziomy eskalacji (OPS → MGT → CONTRACT) z jasnymi kryteriami: impact (ilu użytkowników), time (ile czasu od zgłoszenia), SLA risk (ile do breach). Każda eskalacja musi zawierać: fakty, impact, opcje, rekomendację i prośbę o konkretną decyzję. Emocje → format → decyzja.

Biznes dostaje update'y pełne logów, nazw serwerów i skrótów technicznych. Nie wie, kiedy problem zostanie rozwiązany, kogo dotyczy ani jaki ma wpływ na użytkowników. Brak ETA i next update powoduje, że biznes sam zaczyna eskalować „bo nie wiemy co się dzieje".

Standard komunikacji w 6 zdaniach: status / impact na użytkowników / co robimy / ETA / co dalej / kiedy następna aktualizacja. Wyznacz Comms Lead w każdym MI — jedna osoba, która komunikuje do biznesu, żeby reszta mogła się skupić na rozwiązaniu. Reguła: update co 30–60 min, nawet jeśli brak postępu.

Tickety bez kategorii, bez CI, bez service — trafiają do złych zespołów. Reassignment rate rośnie, czas rozwiązania się wydłuża, a raporty są bezwartościowe, bo dane wejściowe są brudne. „Garbage in, garbage out" — nie da się mierzyć tego, co nie jest poprawnie opisane.

Zdefiniuj „minimum data set" — 5 pól obowiązkowych przy tworzeniu ticketa (np. kategoria, CI, priorytet, opis wpływu, kontakt). Wdroź quality gate: ticket bez wymaganych danych nie przechodzi dalej. Mierz KPI: % kompletności danych. Cotygodniowo top 5 problemów z jakością danych na service review.

Te same problemy wracają miesiąc po miesiącu. Po RCA są rekomendacje, ale nikt ich nie priorytetyzuje i nie wdraża. Brak struktury do zarządzania usprawnieniami sprawia, że organizacja jest reaktywna — gasi pożary zamiast usuwać ich przyczyny.

Stwórz CSI backlog — listę top 10 inicjatyw usprawnień. Wybieraj 1–2 na miesiąc, przypisz ownera, termin i miarę sukcesu. Mierz efekt metodą Pareto before/after. Raportuj postęp na monthly review. Ciągłe doskonalenie nie działa bez rytmu i rozliczania — to nie jest „miło mieć", to serce dojrzałej operacji.

Każdy vendor raportuje inaczej, w innym formacie, z inną częstotliwością. Nie wiadomo, czego od niego oczekiwać w kwestii czasu odpowiedzi na eskalację, dowodów SLA compliance, ani co dokładnie jest w zakresie umowy. Prowadzi to do nieporozumień, frustracji i pozornego „spełniania SLA".

Zdefiniuj standard w SOW/UC: format raportowania (co, kiedy, jak), SLA evidence (co vendor musi udowodnić), escalation path (kto, do kogo, w jakim czasie). Wdroż OLA dla zespołów wewnętrznych + vendor scorecard z wagami i monthly review oparty na danych, nie na wrażeniach.