IT Service Management na rynku produktowym. Czy ma to w ogóle jeszcze sens?

Pomysł na zarządzanie usługami informatycznymi miał na celu zaspokoić pewną bardzo ważną potrzebę tego dynamicznie rozwijającego się rynku. Mianowicie: miał usystematyzować istniejące, ale niezbyt dobrze funkcjonujące w przedsiębiorstwach procesy. Miał dać im swego rodzaju przepis na sukces – prosty wzór, zestaw dobrych praktyk, które wyeliminują zastoje, skrócą czas napraw, poprawią rentowność i jakość usług. Zaczynając prawie 15 lat temu swoją przygodę z usługami IT, bardzo szybko stałam się zagorzałą „wyznawczynią” porządku, który przyniósł ze sobą on: ITIL.

ITIL – Information Technology Infrastructure Library

ITIL to biblioteka zarządzania infrastrukturą informatyczną, zbiór dobrych praktyk zarządzania procesami i usługami informatycznymi. Swego czasu był niezwykle popularny, a kolejne jego wersje były słowem wytrychem. Jeżeli w swojej firmie ktoś miał wdrożoną tę konkretną metodologię, to była zupełnie inna rozmowa. Być może udało mu się zastosować proces zarządzania incydentami, problemami czy zmianą. Jego wdrożenia wymagały gromadzenia przeróżnych pozwoleń, nie można było niczego zaimplementować na wariackich papierach. Wszystko uporządkowane i pod kontrolą. Co więcej: ITIL był (i nadal jest) zbiorem zaleceń i dobrych praktyk, a nie wymogiem czy normą jak np. ISO (International Organization for Standardization – Międzynarodowa Organizacja Normalizacyjna).

Można było sobie wdrożyć z wachlarza ITILa dwa-trzy procesy, które akurat potrzebne były w danym środowisku, a resztę odrzucić czy zostawić na później. Niestety, po latach badania pokazały, że ITIL jest zbyt złożony dla średnich i małych firm – procesy są dla nich zbyt metodyczne i długotrwałe. Czyli coś, co sprawdza się w międzynarodowej korporacji, niekoniecznie będzie dobrym wyborem dla kilku- czy kilkunastoosobowej firmy. Z badań wynika także, że w firmach, które pracują zgodnie z regulacjami ITIL, produktywność nawet spadła, ponieważ procesy były często wdrażane nieprawidłowo. Może to wynikać z braku zrozumienia mechanizmów danego procesu albo ze specyfiki branży, w której po prostu nie da się zastosować ITIL. 

To wszystko było nowe, piękne, uporządkowane. I sprawdzało się bardzo dobrze w wielkim korporacyjnym świecie. Pełniąc rolę najpierw Incident Managera, a później Major Incident Managera, odkryłam, że ta korporacyjna rzeczywistość bardzo sprawnie funkcjonuje wokół jasno sprecyzowanych reguł, udokumentowanej wiedzy, uniwersalnych powtarzalnych schematów. Widziałam doskonale korzyści, wynikające z dobrze sporządzonej umowy SLA (Service Level Agreement, czyli umowa dotycząca ustalonego gwarantowanego poziomu jakości świadczonych usług informatycznych), która moim zdaniem chroni zarówno klienta, jak i dostawcę. Dotyczy zarówno utrzymania, konserwacji, jak i ustawicznego doskonalenia usług w niej zawartych. Są w niej również uwzględnione: katalog usług, mapa zależności, ustalenia stron umowy, parametry techniczne, progi dostępności usług, dopuszczalne odchylenia, raporty i ich częstotliwość, sposoby mierzenia wyników, kary w przypadku złamania lub niedotrzymania warunków umowy.

Poznałam wartość skutecznego zarządzania ryzykiem w projekcie i tego, jak potrafi on uratować skórę w sytuacjach podbramkowych. Zarządzanie zmianą było uporządkowane i bardzo dobrze udokumentowane. Z każdego kryzysu tworzyliśmy raporty, po każdej wdrożonej zmianie dyskutowaliśmy na temat tego, co poszło dobrze, co źle, czego można na przyszłość uniknąć, czego nowego i pożytecznego się nauczyliśmy.

Zarządzanie usługami informatycznymi i rola właściciela usługi czy też service managera kojarzy nam się zazwyczaj z takim scenariuszem: klient daje nam do utrzymania i ewentualnego usprawnienia jakąś usługę (serwery, aplikacje, bazy danych, sieci) – łatwizna. Gdzieś tam na horyzoncie majaczy jakaś umowa, dostępność, może jakiś plan konserwacji, wsparcie gwarancyjne. Mamy przecież świetnych specjalistów, zespoły techniczne, zajmą się tym bez problemu. Niezbyt mocno i długo zastanawiamy się nad sensem tego, czy wstawić tam dostępność 99% czy 99,9%. Z włączeniem czy wyłączeniem konserwacji? Jak często planować aktualizacje i wdrożenia zmian? Czy umiemy wszystko naprawić bez przerw w dostawie usług? 

Chcemy przecież być konkurencyjni, chcemy by klient wybrał właśnie nas. Nie skupiamy się na takich błahostkach, bo czy 99% a 100% to naprawdę taka duża różnica? 

365 dni w roku to 8760 godzin. Zatem: zobowiązując się do utrzymania dostępności usługi na poziomie 99%, otrzymamy dopuszczalny limit w wysokości niecałych 88 godzin (3,5 dnia) w skali roku, czyli 1,5 godziny tygodniowo. Dla 98% będzie ona rocznie wynosić 7 dni. Dla porównania: dla dostępności na poziomie 99,9% czas przewidziany na przerwy w dostawie usługi wyniesie poniżej 9h rocznie, czyli 10 minut tygodniowo. Jak myślisz: wliczać te konserwacje i naprawy czy nie? Przypomnij sobie teraz wszystkie sytuacje, w których trzeba się gdzieś zalogować, a tam wyskakuje powiadomienie o trwających aktualnie pracach konserwacyjnych i o tym, kiedy usługa będzie znów dostępna.

Bardzo ważna jest świadomość takich ograniczeń i dokładna wiedza na temat tego, do czego się zobowiązujemy. Wyniki musimy przecież jakoś raportować, jakoś przedstawiać. Pokazać, w jakim stanie jest świadczona przez nas usługa. Metryki i wskaźniki to osobny i przeogromny temat. Jest mnóstwo artykułów i publikacji na temat tego, co mierzyć, jak mierzyć, jak usprawniać i automatyzować. Pragnę jednak zwrócić Waszą uwagę na inny aspekt. W pogoni za statystykami zapodzialiśmy gdzieś wartość nadrzędną – zaufanie i zadowolenie klienta. O co tak naprawdę chodzi w naszej usłudze? Co z tego, że statystyki mamy piękne i zielone, metryki wzorowe, wszystko zautomatyzowane, jeśli nasz klient jest po prostu ciągle zawiedziony czy niezadowolony?

Nie tylko metryki są ważne

W zarządzaniu usługami informatycznymi zapędziliśmy się troszkę w zdobywaniu coraz to nowych certyfikatów. Szkolenia i przerost teorii procesów nad praktyką ich zastosowań przesłoniły nam widok na to, co ważne. A chodzi nam przecież o zadowolenie klienta. O jego bezpieczeństwo i zaspokojenie jego potrzeb. O zaufanie i jakość. Uważam, że dbając o potrzeby klienta, jest się skutecznym i wartościowym właścicielem usługi – bez względu na nowe technologie. 

Wiadomo, że istnieją klienci bardzo trudni we współpracy i choćby człowiek dwoił się i troił to nie dogodzi ich ciągle zmieniającym się zachciankom i rosnącym wymaganiom. Zastanówmy się jednak nad tym, co nami kieruje. Czym tak naprawdę jest ta nasza usługa? Każdy produkt cyfrowy coś nam daje, na czymś musi się opierać, powinien mieć jakieś ramy czy zakres funkcjonowania, cechy priorytetowe, grupę docelową. Szef produktu będzie zatem dbał o produkt – jego konkurencyjność czy funkcjonalności. Deweloperzy o naprawę błędów, usprawnienia, nowe opcje. Scrum master zadba o planowanie, przegląd kandydatów do poszczególnych sprintów, historyjki i punkty. Zajmie się też pogodzeniem wizji i potrzeb product ownera z wydajnością i możliwościami zespołu. A właściciel usługi będzie czuwał z boku i pilnował, by w trakcie całego tego twórczego procesu nikt nie oberwał rykoszetem, a klient był zadowolony.

Uprzedzę tutaj potencjalne wzburzone głosy obrońców szkoleń – zgodzę się, że w przypadku umiejętności technicznych certyfikaty i szkolenia z nowych technologii są bardzo istotne. Często stanowią przecież wymóg w konkretnej ofercie pracy – na danym stanowisku oczekuje się znajomości systemu czy języka kodowania na określonym poziomie i jest to regulowane certyfikatem, który po prostu potwierdza konkretne kompetencje. To jest rzemiosło, oczywiście. Ale znam mnóstwo przypadków zapalonych samouków z pasją do działania, bez żadnego formalnego wykształcenia czy certyfikatu, którzy potrafią skakać między narzędziami i pokonać w locie tych, którzy posiadają całą kolekcję certyfikatów. I klienci ich uwielbiają – a to jest sztuka!

W poprzednim artykule wspominałam o roli crisis managera – zbieraniu i sortowaniu informacji, przekazywaniu ich w bardziej zrozumiałej i przystępnej formie dalej. Polega ona też często po prostu na służeniu pomocą i radą, ponieważ taka osoba jest dla innych. Właściciel usługi sam też powinien innym „służyć”. Podpowiadać, gdzie coś znaleźć, jaka norma czy mechanizm to reguluje, na co zespół czy właściciel produktu musi się przygotować. Powinien też wiedzieć, na czym klientowi najbardziej zależy, czyli z jaką intencją podejmuje współpracę nad tworzeniem czy doskonaleniem danego produktu cyfrowego.

Jeżeli chodzi o usługi i kompetencje przywódcze, to umiejętność dostosowywania się do zmiennych warunków otoczenia jest jedną z najważniejszych cech dobrego i skutecznego service ownera/service managera. 

We wspomnianym artykule o zarządzaniu kryzysowym (#8 PDMAG) zaznaczyłam, jak ważna dla mnie jest praca zespołowa i docenienie ról czy umiejętności, które mamy w grupie. Współpracę zawsze warto zaczynać od wsparcia i życzliwości. Rola product ownera i service ownera to nie role konkurencyjne, a wspierające się i uzupełniające nawzajem.

Czy zatem rola IT Service Managera ma sens?

Skoro prawie wszystko teraz mamy zautomatyzowane, po co taki pośrednik między właścicielem produktu a zespołem? Osobiście nie postrzegam tej roli jako pośrednika, a bardziej jako konsultanta z boku. Albo jeszcze inaczej: dobrego duszka. Takiego, który wesprze zespół tam, gdzie będzie potrzebny, a zniknie z pola widzenia, jeżeli wszystko będzie sprawnie funkcjonować i po prostu nie będzie przeszkadzał. I do tego potrzebne są kontekst i intencja, bardzo trudne do zastąpienia czy zautomatyzowania. 

Sprawna i stale dostępna usługa to mnóstwo niewidocznej pracy w tle. Dbanie o testy wytrzymałościowe i przełączeniowe, zarządzanie jakością, pojemnością, przepustowością, opieka nad zmianami, zarządzanie incydentami, dokumentowanie napraw, wyciąganie wniosków na przyszłość, analiza problemowa, a także odnawianie pozwoleń, certyfikaty sieciowe, audyty, cyberbezpieczeństwo, przeglądy cykliczne… Im bardziej kompleksowy produkt i „regulowana” branża, tym więcej pracy w dbałości o usługę. 

W przypadku produktu globalnego, który wszędzie ma mieć takie same funkcje i właściwości, menedżer produktu zadba o to, by ten produkt był wszędzie spójny, a menedżer usługi o to, by spełniał wszystkie normy i wymagania potrzebne w danym kraju czy jednostce organizacyjnej, która będzie z niego korzystać. Współpraca między kierownikiem produktu a właścicielem usługi jest zatem kluczowa i nieodzowna.

Service manager nie zna każdej nowej pojawiającej się na rynku technologii i wcale nie musi ich znać. Ma natomiast obowiązek wiedzieć dokładnie, czym zajmuje się zespół albo na czym polega usługa, którą świadczy w ramach swojego produktu cyfrowego. I nie ma najmniejszego znaczenia, jaką metodologię czy system zarządzania obierzemy, ponieważ zawsze gdzieś pod spodem dana usługa będzie przez jakieś prawa i wymogi regulowana. I niemożliwym jest dla zespołu projektowego czy właściciela produktu znać te wszystkie przepisy. Ich zadaniem jest praca z produktem, planowanie kolejnego sprintu (czy jakiejkolwiek innej formy porcji pracy w następnym etapie projektu), wyciąganie wniosków, planowanie strategiczne na kilka tygodni w przód. Albo zastanowienie się i rozpracowanie, jak usprawnić kod bez przerwania dostępności usługi, bez „impaktu na biznes”, bez wpływu na inne zespoły, często korzystające z tego samego kodu bazowego. Zespół powinien znać zależności pomiędzy funkcjami i rolami.

Service manager ma natomiast obowiązek znać ten zespół. Musi wiedzieć, kto czym się zajmuje i jakie składowe wpływają na finalny produkt, z czego mogą wyniknąć opóźnienia, jak się przed nimi uchronić lub zabezpieczyć, które zadania można wykonać równolegle, a które zależą od siebie wzajemnie i muszą na siebie czekać; musi mieć świadomość tego, które wdrożenia będą wpływały na wygląd produktu, a które będą dla użytkownika transparentne. To service manager zna i analizuje wymagania indywidualne dla branży, przepisy obowiązujące klientów, zarówno przy tworzeniu całkiem nowych usług, jak i dla wprowadzania usprawnień czy zmian w produkcie lub usługach już istniejących (będą się one bardzo często różnić z uwagi na lokalne regulacje w poszczególnych krajach).

Przemysł farmaceutyczny, wydobywczy, finansowy będą miały swoje specyficzne prawa czy regulacje i to service manager powinien mieć to na uwadze – bacznie śledzić plan wdrożeniowy i na jego podstawie przygotować swój plan działania. Powinien powiadomić zespół projektowy o czyhających potencjalnych opóźnieniach, wynikających z przyznawanych wszelkiego rodzaju pozwoleń, certyfikacji, przeglądów czy ważnych dat. Czasem będzie to konflikt z innym wdrożeniem, wykonywanym przez odrębny zespół, a czasem po prostu okres ochronny dla jednego z krajów, w którym produkt należy usprawnić czy zmienić. I dzięki działaniom service managera będzie można doprowadzić projekt na czas lub przed czasem. 

Mówi się, że człowieka sukcesu wyróżnia umiejętność budowania sieci kontaktów i maksymalne pozostawanie w łączności z innymi ludźmi – dlatego uważam, że service manager z pewnością nie może być odludkiem. Udana współpraca z zespołami projektowymi, inżynierami, konsultantami, administracją, kierownictwem jest warunkiem koniecznym do osiągnięcia sukcesu w projekcie. To również życzliwość, transparentność, uważność, wyrozumiałość, empatia, zaufanie, komunikacja, zaangażowanie – jasne i przejrzyste przedstawianie na forum grupy wszelkich ryzyk (czy to środowiskowych czy projektowych) i potencjalnych opóźnień pozwala na ich zniwelowanie. Ale nie zniwelujemy czegoś, czego nie jesteśmy świadomi. Zamiatanie problemów pod dywan i modlenie się, by nie wybuchły, nie jest odpowiednim podejściem.