Tydzień 2 - Struktury SIAM, role i odpowiedzialność
Nauczysz się:
* jak podzielić odpowiedzialność bez chaosu,
* jak ograniczyć konflikty między zespołami i vendorami,
* jak zbudować podstawę governance.
Nauczysz się:
* jak nie zaczynać SIAM “od tabelki i nazw ról”,
* jak budować wdrożenie z sensem,
* jak połączyć proces, kontrakt, dane i odpowiedzialność.
Tydzień 1 Lekcja 7 – Gdzie SIAM wspiera ITIL, a gdzie wymaga innego spojrzenia
1. Wstęp: SIAM jako ewolucja, a nie zastępstwo dla ITIL
SIAM nie jest nowym zestawem procesów, który ma zastąpić ramy takie jak ITIL®. Jest to metodologia zarządzania, która wykorzystuje i adaptuje znane procesy, aby działały one efektywnie w ekosystemie wielu dostawców.
SIAM buduje na fundamentach ITIL, rozszerzając je na cały ekosystem, tam gdzie są one istotne dla modelu integracji.
Kluczowym celem pozostaje dostarczanie wysokiej jakości usług i zadowolenie klienta, co jest zbieżne z celami ITIL.
2. Fundamenty: Gdzie SIAM czerpie bezpośrednio z ITIL
Wiele procesów stosowanych w SIAM to te same procesy, które znamy z tradycyjnego ITSM, takie jak zarządzanie zmianą czy zarządzanie incydentami.
Wspólne cele: Skupienie na tworzeniu wartości biznesowej i wynikach końcowych usług.
Standardy: Wykorzystanie znanych definicji (np. incydent, zmiana) ułatwia komunikację, o ile zostanie wprowadzony wspólny słownik danych (Common Data Dictionary).
3. Zmiana paradygmatu: Gdzie SIAM wymaga innego spojrzenia
Największa różnica między tradycyjnym podejściem a SIAM leży w skali i sposobie egzekucji procesów. Tradycyjne ramy zakładają zazwyczaj wykonanie procesu wewnątrz jednej organizacji.
Procesy międzyorganizacyjne: W SIAM procesy muszą być wykonywane przez podmioty w różnych warstwach (np. integrator i dostawca) oraz między dostawcami w tej samej warstwie (np. dostawca sieci i hostingu).
Brak mandatu na procesy wewnętrzne: W tradycyjnym outsourcingu klient często narzuca procesy. W SIAM organizacja klienta nie narzuca procesów, narzędzi ani praktyk roboczych wewnątrz organizacji dostawcy. Zamiast tego oczekuje się, że dostawca skutecznie zintegruje swoje procesy z nadrzędnym modelem SIAM i procesami end-to-end.
Agregacja i orkiestracja: Integrator nie zarządza technicznymi detalami pracy dostawcy, ale „skleja” (orkiestruje) ich wyniki w jedną usługę.
4. Adaptacja ról i odpowiedzialności (RACI)
W tradycyjnym ITIL rola process managera jest zazwyczaj przypisana do jednego zespołu. W SIAM ta sama czynność lub proces może obejmować wszystkie trzy warstwy:
Przykład Zarządzania Zmianą:
Klient: Inicjuje zmiany o dużym wpływie biznesowym i zatwierdza harmonogramy strategiczne.
Integrator: Prowadzi zintegrowany proces zarządzania zmianą (Integrated CAB), koordynując wpływ zmiany na różnych dostawców.
Dostawca: Zarządza własnym, wewnętrznym procesem zmiany i wdraża poprawki techniczne.
5. Inne spojrzenie na role procesowe (Owner i Manager)
SIAM wprowadza specyficzne rozróżnienie w hierarchii odpowiedzialności procesowej:
Integrator Process Owner: Jest odpowiedzialny za to, jak proces przepływa między wieloma dostawcami i jak się ze sobą łączą ich działania (integracja procesowa).
Service Provider Process Owner: Odpowiada za wykonanie procesu wewnątrz swojej firmy zgodnie z umową i wytycznymi integratora.
Skupienie na interfejsach: Zamiast kontrolować każdy krok, integrator skupia się na punktach styku (touchpoints) i przepływie informacji między organizacjami.
6. Wyzwania integracyjne (Tooling i Dane)
ITIL często skupia się na funkcjonalności narzędzi. SIAM kładzie nacisk na ich interoperacyjność.
Wymagane jest przejście od silosów narzędziowych do strategii, która pozwala na swobodny przepływ danych o incydentach czy problemach między systemami różnych dostawców bez konieczności ich ręcznego przepisywania (unikanie „efektu krzesła obrotowego”).
Podsumowanie
SIAM to ITIL „na sterydach” wielostronnej współpracy. Największą zmianą jest odejście od myślenia „mój proces w moim dziale” na rzecz „nasz proces w całym ekosystemie”, przy jednoczesnym poszanowaniu autonomii operacyjnej każdego z dostawców. Sukces w SIAM wymaga, aby procesy ITIL stały się elastycznym mostem łączącym niezależne organizacje.