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 3 – Typowe problemy w modelu multi-provider
1. Wstęp: Wyzwania dostarczania usług przez wielu dostawców
Współczesne organizacje rzadko polegają na jednym dostawcy. Zarządzanie ekosystemem wielu partnerów (wewnętrznych i zewnętrznych) wiąże się jednak z gwałtownym wzrostem złożoności oraz trudnościami w koordynacji działań.
2. Zjawisko „Efektu Arbuza” (The Watermelon Effect)
To jeden z najbardziej charakterystycznych problemów adresowanych przez SIAM.
Definicja: Sytuacja, w której raporty poszczególnych dostawców są „zielone” (SLA są dotrzymane), ale ogólna usługa z perspektywy klienta końcowego jest „czerwona” (niezadowalająca).
Przyczyny:
Cele dostawców są skupione na technicznych komponentach, a nie na wartości biznesowej.
Brak uwzględnienia czasu „przekazywania” zadań między dostawcami w pomiarach SLA.
Wskaźniki nie są wyrównane z rzeczywistymi potrzebami biznesu.
3. Silosy dostawcze i „Kultura obwiniania się” (The Blame Culture)
W modelu bez integracji każdy dostawca działa w izolacji, co prowadzi do patologii współpracy.
Silosy operacyjne: Dostawcy skupiają się wyłącznie na własnych celach kontraktowych, nie dbając o to, jak ich działania wpływają na innych partnerów lub całość usługi.
Unikanie odpowiedzialności: Gdy dochodzi do awarii na styku usług, dostawcy tracą czas na udowadnianie, że „to nie ich wina”, zamiast wspólnie szukać rozwiązania (mentalność fix first, discuss later jest tu nieobecna).
Brak dzielenia się wiedzą: Dostawcy mogą postrzegać swoją wiedzę jako przewagę konkurencyjną i odmawiać jej udostępniania innym, co prowadzi do duplikacji pracy i błędów.
4. Brak jasności w rolach i odpowiedzialnościach
W środowisku wielu dostawców granice odpowiedzialności często się zacierają.
Rozproszona odpowiedzialność: Trudno ustalić, kto odpowiada za dany etap procesu end-to-end, co prowadzi do „porzucania” zadań.
Brak właściciela incydentów: Incydenty trwają dłużej, bo nikt nie czuje się odpowiedzialny za ich koordynację między dostawcami (brak ścieżek eskalacji).
Shadow IT: Użytkownicy biznesowi, zniechęceni chaosem w IT, zaczynają kupować usługi na własną rękę, pogłębiając problemy z integracją.
5. Fragmentacja procesów, danych i narzędzi
Techniczne i proceduralne niedopasowanie utrudnia sprawne działanie organizacji.
„Efekt krzesła obrotowego” (Swivel chair approach): Pracownicy muszą ręcznie przepisywać te same dane z systemu jednego dostawcy do systemu drugiego, co jest nieefektywne i generuje błędy.
Luki w procesach: Zadania „wpadają w szczeliny” między dostawcami (np. incydent przekazany do innego zespołu nie zostaje podjęty, bo nie ma jasnego standardu komunikacji między narzędziami).
Brak standardów danych: Każdy dostawca używa innej kategoryzacji (np. to, co dla jednego jest „Priorytetem 1”, dla innego jest „Severity 3”), co uniemożliwia rzetelne raportowanie end-to-end.
6. Bariery kontraktowe i brak elastyczności
Tradycyjne podejście do outsourcingu często utrudnia współpracę.
Sztywne kontrakty: Stare umowy często nie przewidują współpracy z innymi dostawcami, co ogranicza innowacyjność i zdolność do szybkiej wymiany partnerów typu „best of breed”.
Sprzeczność interesów: Interesy komercyjne zewnętrznych dostawców mogą być sprzeczne z celami strategicznymi klienta.
Podsumowanie
W modelu multi-provider bez SIAM suma działań poszczególnych dostawców rzadko daje wysoką jakość usługi końcowej. Największym wyzwaniem nie jest technologia, lecz brak wspólnego celu, rozmyta odpowiedzialność i bariery w przepływie informacji. Metodologia SIAM ma za zadanie usunąć te bariery poprzez wprowadzenie warstwy integratora