Każdy użytkownik chciałby aby gdy pojawią się problemy z działaniem usługi, aplikacji, rozwiązania IT, mógł liczyć na kompetentną i szybką pomoc. Czy takiemu oczekiwaniu trudno sprostać? Okazuje się, że nie jest to trywialne zadanie i nie każdy zespół wsparcia, serwisu, utrzymania poradzi sobie z nim w satysfakcjonujący sposób. Na czym polega ta trudność? Co jest takiego szczególnego i będącego wyzwaniem w świadczeniu serwisu, czym nie każdy serwis będzie mógł się pochwalić?

Błędy, awarie, incydenty, problemy

Nie ma i w najbliższym czasie nie będzie systemu IT, który działa bezbłędnie. Każde, nawet najlepiej przetestowane rozwiązanie IT, po wdrożeniu na produkcję, będzie wymagało wsparcia dla użytkowników. Wręcz tendencja jest odwrotna. Użytkownikom udostępniane są usługi IT, które z definicji nie są dokończone aby to użytkownik „w boju” sprawdził rozwiązanie i zgłosił błędy i niepoprawne działanie. Co raz więcej mamy systemów w wersji beta, które są oddawane do użytkowników aby je testowali, tzw testowanie przez używanie. Z tego powodu, informacją zwrotną od użytkowników są zgłaszane incydenty i problemy. Użytkownik nawet rozumie, że coś może się zepsuć, nie działać lub funkcjonować niepoprawnie. Jednocześnie jednak oczekuje, że zgłoszone problemy zostaną rozwiązane, tak aby mógł korzystać z danego systemu, aplikacji, rozwiązanie i wykonywać swoje codzienne obowiązki. Aby to się działo w sposób uporządkowany, dobrze jest mieć ustalone SLA dla obsługi zgłoszeń, nie wspominając o ustalonych praktykach i narzędziach, które pomogą obu stronom: użytkownikowi i IT.

SLA

Dla uruchomionych na produkcji rozwiązań informatycznych, powinniśmy mieć zdefiniowane w katalogu usług, usługi oraz poziom ich świadczenia czyli SLA. W zakresie SLA powinno być ustalone, w jaki sposób użytkownik zgłasza pojawiające się niesprawności oraz jak szybko zespół wsparcia naprawi te niesprawności. Dwa parametry SLA są tutaj kluczowe: czas reakcji i czas naprawy. Dla obu powinniśmy mieć zdefiniowane wartości dopuszczalne, czyli po jakim czasie zgłoszenie zostanie potwierdzone oraz po jakim naprawione. Oczywiście użytkownik chciałby aby te czasy były jak najkrótsze a IT aby były jak najdłuższe. Musimy znaleźć kompromis pomiędzy tymi dwoma podejściami. Skracanie tych czasów aby uzyskać przewagę konkurencyjną a później ich nie dotrzymywanie, nie będzie z korzyścią dla nikogo. Czy jednak dobrze zdefiniowane wartości SLA dla obsługi serwisowej są wystarczającym warunkiem aby uzyskać satysfakcję użytkownika? Okazuje się, że nie koniecznie. Dostawca może spełniać wymagania SLA zawarte w umowie a użytkownik nie będzie zadowolony, ze świadczonych usług serwisu.

Przyczyny

Jakie mogą być przyczyny takiego stanu rzeczy? 

• Po pierwsze, sam fakt że błędów jest bardzo dużo może powodować irytację użytkownika i rozwiązywanie ich zgodnie z SLA nic tu nie zmieni.
• Po drugie, wartości dopuszczalne czasu reakcji i naprawy mogą być za duże, co oznacza, że użytkownik za długo czeka na rozwiązanie zgłoszonego problemu.
• Po trzecie, niska jakość świadczonych przez zespół wsparcia usług serwisowych. Nie mam tu na myśli SLA, tylko sprawy związane z komunikacją, uprzejmością, zrozumieniem, pomiędzy użytkownikiem i serwisem.

Zapewne przyczyn można podać więcej. Ja wskazuję te według mnie najważniejsze. Co więc zrobić aby użytkownik lepiej postrzegał IT i osoby, które wspierają go w rozwiązywaniu błędów?

Rozwiązania

Na pewno pomoże większa koncentracja przy tworzeniu rozwiązania IT. Należy już u źródła spowodować, że będzie popełniane mniej błędów, które później wpływają na pracę użytkownika. Można spróbować zweryfikować parametry SLA i dostosować je do oczekiwań użytkownika oraz możliwości IT. Jednak te działania mogą nie przynieść zamierzonego wyniku. Co więc jeszcze możemy poprawić? Obsługa serwisowa wymaga kontaktu pomiędzy użytkownikiem a pracownikiem zespołu wsparcia. Kontakt ten może być telefoniczny, przez komunikator, chat, mail, narzędzie klasy ITSM. Niezależnie jaka to będzie forma kontaktu, po obu stronach są ludzie i powinni umieć się „dogadać”. Nie musi to być wcale takie proste. Osoby w zespole wsparcia to techniczni guru, którzy znają się bardzo dobrze na rozwiązaniu IT ale już z komunikacją mogą mieć problemy.

Przyjacielski serwis

Potraktujmy użytkownika jak naszego przyjaciela. Na co można liczyć w przypadku przyjaciela?

• Na pewno na empatię. Osoby z zespołu serwisu muszą podejść ze zrozumieniem i szczególną uwagą do problemów zgłaszanych przez użytkownika, którego nie można traktować jako zło konieczne i naszego wroga. Wręcz przeciwnie to biznes, którego użytkownik jest przedstawicielem, płaci nam za świadczone usługi wsparcia. Wejście w buty użytkownika, na pewno zmniejszy dystans pomiędzy użytkownikiem a IT.
• Niezależnie co się dzieje, pracownik zespołu serwisowego musi być uprzejmy dla użytkownika. Wiadome jest, że użytkownik może być zdenerwowany występującym błędem, ponieważ uniemożliwia mu on wykonanie określonej czynności. Nie można pod żądnym pozorem być nie miłym dla użytkownika, nawet jeżeli on jest niemiły w stosunku do serwisu. Należy uspokajać sytuację a nie ją jeszcze nakręcać. Trzy proste słowa proszę, przepraszam, dziękuję mogą zdziałać cuda, a nie wymagają żadnego szkolenia i dużego nakładu sił.
• Słuchać, słuchać, słuchać. Umiejętność aktywnego słuchania, pomoże w zrozumieniu potrzeb użytkownika i przyczyni się do budowania relacji pomiędzy użytkownikiem a IT.
• Otwartość i elastyczność na wyrażane potrzeby. Nie zamykajmy się w sztywnych ramach SLA i obowiązujących umów, tylko wykażmy się inicjatywą i zaangażowaniem.

Czy serwis może być przyjacielski. Może. Czy łatwo jest to osiągnąć. Niestety trudno ale nie znaczy, że jest to niemożliwe. Wymaga to dużego zaangażowania kierownictwa w ustalenie strategii i konsekwentne jej realizowanie. Jeżeli nawet nie mamy ludzi z takimi umiejętnościami to można się ich nauczyć. Potrzebne są szkolenia, warsztaty a może nawet specjalny program, który na kilka miesięcy, a może nawet lat rozpisze działania, które są wymagane aby użytkownik zaczął postrzegać wsparcie serwisowe jako swojego przyjaciela a nie geeka i nerda z IT, z którym kontakt to najzwyklejsza męczarnia i katorgi. Takiego podejścia i przyjacielskiej relacji życzyłbym sobie w każdej organizacji, która świadczy wsparcie w obsłudze serwisowej.

Artykuł Jak świadczyć przyjacielski serwis IT? pochodzi z serwisu Mariusz Siek.

Każdy nazywa je trochę inaczej: utrzymanie, operacje, eksploatacja, produkcja, serwis. Zapewne określeń znalazłoby się jeszcze więcej ale nie to jest najważniejsze. Czy utrzymanie jest ważne i potrzebne do działania systemów i usług informatycznych? Najprawdopodobniej każdy z IT i biznesu powiedział by, że tak. Ktoś przecież musi dbać o to aby aplikacje, systemy i usługi dla biznesu działały nieprzerwanie a w przypadku incydentów i problemów rozwiązywane były zgodnie z SLA. Nie ma chyba obecnie firmy, która nie korzystała by z rozwiązań informatycznych, a co raz więcej z nich w swoim modelu biznesowym jest wręcz „uzależnione” od IT. Dlaczego więc utrzymanie jest na końcu, dosłownie i w przenośni, jako obszar w IT? Czy to jest tylko moje odczucie czy może faktycznie nie przykładamy właściwej wagi do utrzymania?

Trochę teorii

Niezależnie jakie dobre praktyki w zarządzaniami usługami IT weźmiemy pod uwagę: ITIL, DevOps, COBIT, LeanIT, znajdziemy w nich obszar związany z „utrzymaniem”. To prawda występuje on przeważnie zawsze na końcu cyklu produkcyjnego ale taka jest jego natura. Tego się nie zmieni i z tym nie zamierzam walczyć. Czy jednak fakt, że utrzymanie jest ostatnim elementem w zarządzaniu usługami IT, oznacza że powinniśmy zająć się nim dopiero po zakończeniu cyklu wytwórczego usług, aplikacji, oprogramowania IT? Niestety w większości organizacji utrzymanie ma niski priorytet w cyklu życia usługi IT. Kto by myślał i zastanawiał się nad utrzymaniem skoro jeszcze nawet nie wiemy, jakie są wymagania funkcjonalne, jaka będzie architektura rozwiązania IT oraz w jakiej technologii usługa będzie wytwarzana.

To jest jednak podstawowy błąd, jeżeli na wczesnym etapie wytwarzania rozwiązania IT, nie uwzględnimy wymagań niefunkcjonalnych, które są bardzo mocno związanych z utrzymaniem.

Wymagania niefunkcjonalne

Oprócz wymagań funkcjonalnych, które są kluczowe dla wytworzenia rozwiązania informatycznego, bardzo ważnym elementem każdej usługi IT są wymagania niefunkcjonalne. Główne obszary wymagań niefunkcjonalnych to: bezpieczeństwo, dostępność, niezawodność, wydajność, obsługa serwisowe, odtwarzanie po awarii (backup and recovery). Jak widać są to bardzo ważne i duże w swoim zakresie obszary. Aktualnie bezpieczeństwo ma co raz większe znaczenie i wymagania z nim związane powinny być dobrze zdefiniowane, zaprojektowane i wdrożone. Takie aspekty jak polityka haseł, sposób logowania i autoryzacji, nadawanie i odbieranie uprawnień, muszą zostać uwzględnione. Dostępność i niezawodność to chyba najważniejszy z obszarów, ponieważ od niego zależy na jakim poziomie będzie świadczona usługa IT. Wymagania od biznesu należy przełożyć na architekturę rozwiązania, które zapewni oczekiwany poziom dostępności. Wymagania na wydajność zagwarantują, że usługa IT będzie wspierała funkcjonowanie biznesu a nie je spowalniała. Wiemy, że usługi IT mogą się zepsuć, dlatego tak ważne jest aby określić w jakim czasie będą usuwane wszelkie awarie i usterki. Na koniec ciągłość działania, która zawiera wymagania związane z kopiami zapasowymi (backup) i ich odtwarzaniem (recovery). Uzbierało się całkiem sporo a przecież każdy z podanych obszarów wymagań niefunkcjonalnych to dziedzina sama w sobie.

Kto to zrobi?

Dla obsługi wymagań funkcjonalnych mamy dedykowane zespoły, które zwierają biznes, analityków, projektantów, programistów, testerów, scrum masterów itp. W przypadku wymagań niefunkcjonalnych jest już trochę gorzej. W ich przypadku już nie mamy takiego komfortu zasobów ludzkich, które za nie odpowiadają. Główną rolę pełni tu architekt systemowy, tylko czy jest w stanie zapanować nad wszystkimi wymaganiami z tych obszarów? Pewnie z działu bezpieczeństwa ktoś się znajdzie ale czy może poświęcić wystarczającą ilość czasu aby uczestniczyć w projekcie? Dobrze jak jest Service Level Manager, bo on jest w stanie dużą część wymagań niefunkcjonalnych obsłużyć. Jednak gdy go nie ma kto zadba o te wymagania? Już na etapie definiowania wymagań powinny w proces/projekt wytwórczy włączać się osoby z zespołów utrzymania (infrastruktura, aplikacje, bazy danych, service desk, managerowie ITSM). Bez ich udziału, trudno będzie oczekiwać, że po wdrożeniu na produkcje usługa będzie działać bez jakichkolwiek problemów.

Niestety pierwszym błędem jest nie wystarczająca ilość osób, które odpowiadają za te wymagania. Drugim jest włączanie tych osób na późnym etapie realizacji projektu, gdy już etap wytwarzania usługi IT jest bardzo mocno zaawansowany i nie można wpływać np. na jej architekturę.

Czy tylko brak zasobów ludzkich?

Powstaje pytanie czy tylko brak ludzi odpowiedzialnych za wymagania niefunkcjonalne jest głównym problemem? Oczywiście nie. Bardzo często biznes nie potrafi zdefiniować swoich oczekiwań co do wymagań niefunkcjonalnych lub brak jest kogoś kto te wymagania określa. Kluczową jednak przyczyną dlaczego tak się dzieje, jest presja czasu. Biznes oczekuje rozwiązań IT na wczoraj a jednocześnie nie chce się angażować w proces wytwórczy. IT aby sprostać oczekiwaniom biznesu dwoi się i troi, jednak ograniczenia czasowe nie pozwalają na rzetelną obsługę wszystkich wymagań. Dlatego w pierwszej kolejności odbija się to na wymaganiach niefunkcjonalnych, w szczególności tych najbliższych utrzymaniu. Projekt, rozwiązanie, usługę IT trzeba dowieźć na dany termin i zespół projektowy, wytwórczy zrobi wszystko aby to osiągnąć i zakończyć ten etap. Nie patrzy przy tym, jakie problemy będą występować na produkcji, bo przecież to nie jego odpowiedzialność. Nawet jak zespół developerski wspiera utrzymanie w obsłudze incydentów i problemów to robi to na innym etapie z innej pozycji. Wdrożenie zakończyło się sukcesem. Fakt, że później jest setki lub tysiące zgłoszeń już nikt z „projektu” nie analizuje. Niech się tym martwi utrzymanie a jak nie będzie sobie radzić to wspaniałomyślnie mu pomożemy.

Co dalej?

Nie wiem czy tak jest wszędzie ale ja mam takie doświadczenia i uważam, że nie są odosobnione. Kiedy zaczniemy patrzeć na usługę informatyczną jako na całość i nie będziemy budować murów pomiędzy wy development i my utrzymanie lub na odwrót. Kiedy osoby odpowiedzialne za cały obszar IT, zobaczą że myślenie o utrzymaniu, na jak najwcześniejszym etapie projektu, daje wymierne korzyści i przynosi widoczne efekty całej organizacji IT oraz biznesowi, który przecież za to IT płaci. Widzę bardzo ważną rolę utrzymania a w szczególności menedżerów ITSM w uświadamianiu i edukowaniu innych działów IT, jak ważne jest uwzględnianie aspektów utrzymaniowych na wczesnym etapie rozwoju usługi IT.

Artykuł Niedoceniane utrzymanie pochodzi z serwisu Mariusz Siek.

Odkąd zacząłem się zajmować zarządzaniem usługami IT, uważałem że wprowadzanie najlepszych praktyk ITIL należy zaczynać od katalogu usług. Nadal tak uważam, bo jak można zarządzać usługami nie wiedząc jakie mamy usługi i jaki poziom ich świadczenia (SLA) jest określony. Potwierdza to biblioteka ITIL, która w wersji 3 w 2007 roku, oprócz procesu „Zarządzanie poziomem usług„, wprowadziła dedykowany proces „Zarządzanie katalogiem usług”. Jeżeli mamy specjalnie dla katalogu usług proces do jego zarządzania, to chyba należy uznać, że katalog usług, jest bardzo ważnym narzędziem w zarządzaniu usługami IT. Zobaczmy co zawiera proces „Zarządzania katalogiem usług”

Cele

Celem procesu Zarządzania katalogiem usług jest dostarczenie i utrzymanie jednego, spójnego źródła informacji o wszystkich produkcyjnych i projektowanych usługach i zapewnienie, aby te informacje były dostępne dla jak najszerszego grona, uprawnionych odbiorców.

Proces koncentruje się na:

• Zarządzaniu informacjami zawartymi w katalogu usług
• Zapewnieniu, że katalog usług jest dokładny i odzwierciedla aktualny stan usług, które działają produkcyjnie lub są przygotowywane do wdrożenia na produkcji
• Zapewnieniu, że katalog usług jest dostępny dla wszystkich uprawnionych interesariuszy, w sposób który zapewnia efektywne wykorzystanie zgromadzonych w nim informacji
• Zapewnieniu, że katalog usług wspiera zmieniające się potrzeby pozostałych procesów zarządzania usługami, w zakresie informacji zawartych w katalogu usług

Zakres

Proces Zarządzania katalogiem usług, obejmuje swoim zakresem:

• Przygotowanie wsadu do definicji usług i pakietów usług
• Rozwój i utrzymanie opisów usług i pakietów usług, według ustalonych standardów
• Wytworzenie i utrzymanie prawidłowego katalogu usług
• Interfejsy, zależności i spójność pomiędzy katalogiem usług a portfolio usług
• Interfejsy i zależności pomiędzy usługami i usługami wspierającymi w katalogu usług i CMS
• Interfejsy i zależności pomiędzy usługami a komponentami wspierającymi i elementami konfiguracji, w katalogu usług i CMS

Proces Zarządzania katalogiem usług nie obejmuje:

• Gromadzenia, utrzymania i wykorzystania zasobów usługi i danych konfiguracji. Tym zajmuje się proces zarządzania zasobami i konfiguracją.
• Gromadzenia, utrzymania i spełnienia żądań o usługę. Tą aktywnością zajmuje się proces spełniania żądań (request fulfillment)

Korzyści dla biznesu

Efektywne zarządzanie katalogiem usług, pozwala na osiągnięcie następujących korzyści:

• Dostarcza biznesowi centralne źródło informacji o usługach IT, ich szczegółach, statusie, poziomie świadczenia, jakie procesy biznesowe wspierają, sposobie wykorzystania.
• Zapewnienie wspólnego rozumienia usług IT przez biznes i IT, skutkujące lepszymi relacjami pomiędzy klientem a dostawcą, poprzez wykorzystanie katalogu usług jako narzędzia marketingu i komunikacji
• Lepsza koncentracja dostawcy usług na wynikach klienta, dzięki powiązaniu wewnętrznych aktywności dostawcy usługi i zasobów usługi z procesami i wynikami biznesowymi
• Poprawa wydajności i efektywności pozostałych procesów zarządzania usługami IT, poprzez wykorzystanie informacji zawartych w katalogu usług
• Lepsza wiedza, dopasowanie i koncentracja na wartości dla biznesu, dla każdej usługi, po stronie dostawcy usług IT

Rodzaje usług

Katalog usług to nie zwykła lista usług ale pewna hierarchia i struktura, która pokazuje zależności pomiędzy procesami biznesowymi, usługami i SLA. Same usługi możemy podzielić na dwie główne grupy:

• Usługi udostępniane użytkownikowi, są to usługi które wspierają procesy biznesowe klienta, bezpośrednio dostarczające oczekiwanych wyników
• Usługi wspierające, są to usługi, które wspierają funkcjonowanie usług udostępnianych użytkownikowi i nie są przez niego widziane

Ja nazywam pierwsze usługami biznesowymi a drugie usługami systemu. Oczywiście nazw usług wspierających może być więcej: infrastrukturalne, sieciowe, aplikacyjne, techniczne itp. Niezależnie jak będą się nazywać, należy zadbać aby były jednoznacznie zdefiniowane, aby każdy zainteresowany rozumiał je w ten sam sposób.

Na poniższym rysunku (z książki ITIL Service Design) pokazano rodzaje usług, przykładowe usługi, ich relacje pomiędzy nimi, procesami biznesowymi i SLA. Daje on pewne wyobrażenie, co powinien zawierać katalog usług i jak ważnym jest narzędziem.

Podsumowanie

Proces Zarządzania katalogiem usług, jest jednym z najważniejszych na etapie projektowania usług oraz w całym cyklu życia usługi. Zapewnia, że:

• wszystkie usługi funkcjonujące produkcyjnie, będą w katalogu usług opisane
• będą określone relacje pomiędzy procesami biznesowymi a usługami udostępnianymi użytkownikowi (biznesowymi)
• będą określone relacje pomiędzy usługami biznesowymi a wspierającymi (systemu)
• informacje będą aktualne, prawidłowe i odzwierciedlające rzeczywistość produkcyjną.

Jeżeli zastanawiałeś się dlaczego potrzebny jest dedykowany proces dla zarządzania katalogiem usług, to teraz już chyba nie masz wątpliwości. Wykorzystaj go aby poprawić jakość świadczonych usług IT do biznesu.

Pytanie: Ile usług masz w katalogu usług i jakie są ich rodzaje?

Artykuł Zarządzanie katalogiem usług pochodzi z serwisu Mariusz Siek.

Jeżeli zarządzasz usługami IT, codziennie spotykasz się z problemami, które musisz ogarnąć i zapanować nad nimi. Ciesz się z tego powodu. Każda taka sytuacja pozwala Ci nauczyć się czegoś nowego. Każdy problem to szansa na poprawę poziomu świadczonych usług IT. Nie zniechęcaj się i nie martw, tylko zacznij działać, aby znaleźć najlepsze rozwiązanie. Może nie od razu będzie to ten idealny sposób ale jeżeli włożysz swoje serce i pot, to na pewno dotrzesz do właściwego rozwiązania. Jakie problemy mogą Cię spotykać i jak im sprostać, przeczytasz w poniższym wpisie.

Co miesiąc nie dotrzymuję SLA

To chyba jeden z najczęściej występujących przypadków. Jeżeli mamy uzgodnione SLA z biznesem i rozliczamy się z niego co miesiąc, wykazujemy w raporcie, jakie wartości osiągnęły parametry SLA. Niektóre z nich, niestety nie spełniają postawionych wymagań. W takim przypadku rzetelnie pokazujemy biznesowi, że nie daliśmy rady i bijemy się w pierś. Na tym jednak nasze działanie się nie kończy. Na każde przekroczenie parametru SLA, w ustalonym okresie rozliczeniowym, zakładamy problem w rejestrze problemów, w celu znalezienia jego przyczyny źródłowej. Szukamy rozwiązania do skutku, a o postępach naszych działań, na bieżąco informujemy biznes.

W moich zespołach jest duża rotacja pracowników

Jest to co raz częściej występujące zjawisko na rynku pracy, że pracownicy szukają ciekawszych i lepiej płatnych zajęć. Nie jest to tylko specyfika IT ale tendencja, która według mnie, co raz bardziej będzie się nasilać. Musimy z nią żyć i radzić sobie.

• Po pierwsze musimy budować kompetencje zespołów, w taki sposób, aby nie były w jednych rękach i głowie. Nie możemy uzależniać się od wiedzy i kompetencji jednej osoby, która może zachorować lub zmienić pracodawcę. Przynajmniej dwie osoby w zespole powinny mieć zbliżone kompetencje. Jedna może mieć trochę większe ale ta druga powinna w 1-2 tygodnie być w stanie zastąpić osobę wiodącą.
• Po drugie musi powstawać dokumentacja techniczna, która zawiera wiedzę i informacje, które są niezbędne do zarządzania aplikacją, systemem, serwerem, bazą danych itp. po odejściu pracownika. Wiem, że jest to wyzwanie, bo nigdy nie ma na to czasu oraz administratorzy i technolodzy nie cierpią pisać dokumentacji ale innej drogi nie ma.

Mam za mały budżet aby spełnić oczekiwania biznesu

Wiadomo, że pieniędzy jest zawsze za mało i każdy chciałby mieć więcej. Jak jednak lepiej nimi zarządzać?

Jeżeli chcesz lepiej zrozumieć swoje finanse w IT, musisz policzyć koszty świadczenia poszczególnych usług IT. Tylko posiadając rzetelną wiedzę, jakie są elementy składowe kosztów, możesz zacząć rozmawiać z biznesem, co i za ile możesz dostarczyć. Ta wiedza jest niezbędna przy uzgadnianiu SLA, przy jego raportowaniu i rozliczaniu. Wyposażony w niezbędną wiedzę o kosztach i ich związku z poziomem świadczonych usług, możesz usiąść do rozmów z biznesem, aby rzeczowo pokazać, co w aktualnym budżecie, przy obowiązującym SLA, jest możliwe do uzyskania. Język faktów i rzeczowych danych powinien uświadomić biznesowi możliwości IT.

Biznes cały czas narzeka na działanie IT

Narzekanie to chyba cecha narodowa Polaków. Po pierwsze należy wysłuchać tych żali i uzyskać od biznesu jak najwięcej rzeczowych i wiarygodnych informacji, co im najbardziej doskwiera i przeszkadza. Jeżeli te narzekania są uzasadnione, trzeba zaplanować działania, które pomogą w rozwiązaniu zagadnień, podnoszonych przez użytkowników. Aby te żale były przekazywane w cywilizowany sposób należy spotykać się regularnie z biznesem i słuchać co mają do powiedzenia. W ten sposób budujemy partnerską relację i tworzymy swój dobry wizerunek.

Bardzo dużo zmian do systemów IT, wprowadzanych w krótkim czasie

Otoczenie biznesowe oczekuje, nowych funkcjonalności i aplikacji, aby spełnić wymagania rynku i pokonać konkurencję. To skutkuje wdrażaniem bardzo dużej ilości zmian do systemów produkcyjnych. Nie jesteśmy w stanie zatrzymać tej tendencji. Wręcz przeciwnie będzie się ona nasilała. Wprowadzane nowe zmiany wymagają nowych kompetencji i wiedzy aby je sprawnie utrzymywać. Jak się przygotować na taką sytuację?

• Uczestniczyć w planowaniu zmian, które są przygotowywane przez zespoły deweloperskie i mieć na to planowanie wpływ.
• Pozyskać od zespołów wytwórczych wymaganą do utrzymania wiedzę i kompetencje, przed wdrożeniem zmian na produkcję.
• Oczekiwać od fazy wytwórczej przygotowania bazy znanych błędów, które zostaną wdrożone na środowisko produkcyjne, która pozwoli szybciej je identyfikować i rozwiązywać.

Problemy były, są i będą, a te podane przeze mnie, są tylko przykładowe. Sposób radzenia sobie z nimi, jest oznaką tego jak dobrymi jesteśmy managerami. Te trudności i niedogodności spowodują, że będziemy działać bardziej kreatywnie i innowacyjnie – nie lubię tego słowa :-). Co nas nie zabije to nas wzmocni i wyjdziemy z większą siłą i przekonaniem, że jesteśmy w stanie sprostać każdemu problemowi. Musimy tylko opanować emocje i rzeczowo zjeść tego słonia po kawałeczku, aby nie stanął nam w gardle :-).

Pytanie: Z jakim problemem w zarządzaniu usługami IT ostatnio się zmierzałeś i z jakim efektem?

Artykuł Problemy w ITSM i jak je rozwiązać? pochodzi z serwisu Mariusz Siek.

Ostatnia moja publikacja „Specjalista utrzymania – poszukiwany, poszukiwana”, wywołała dyskusję czy potrzebni są managerowi procesów ITSM. Zachęcam do zapoznani się z komentarzami pod artykułem. To spowodowało, że zacząłem się zastanawiać, jakich ludzi powinniśmy mieć w zespole IT. Jednocześnie nadchodzące święta Bożego Narodzenia, zainspirowały mnie aby poszukać w tym wszystkim człowieka. Kto jest ważniejszy: człowiek czy maszyna? Czy widzimy w ludziach ogromną wartość branży IT? Czy już myślimy tylko o robotach, sztucznej inteligencji i automatyzacji?

4P

ITIL w projektowaniu usług, posługuje się tzw zasadą 4P, która zwraca uwagę na cztery aspekty – People, Processes, Products, Partners:

• People, czyli ludzie to kultura, organizacja, kompetencje i umiejętności
• Processes, czyli procesy, dla których odpowiadamy na pytania: jak, gdzie, kiedy, kto i dlaczego?
• Products, czyli produkty to usługi, technologia i narzędzia
• Partners, to partnerzy tacy jak dostawcy i vendorzy

Według mnie najważniejsi są ludzie i bez nich żadnej usługi nie zaprojektujemy. Pozostałe P możemy sobie darować.

Ludzie

Dlaczego ludzie są tacy ważni i są kluczowym zasobem w projektowaniu usług IT? Dlatego, że ludzie to najróżniejsze umiejętności

• Analizują procesy biznesowe i przekładają wymagania użytkowników, klienta na język IT
• Projektują rozwiązanie informatyczne zaczynając od infrastruktury sprzętowej, poprzez oprogramowanie standardowe kończąc na aplikacjach „szytych na miarę”
• Programują zaprojektowane rozwiązania w wybranej technologii, tworząc aplikacje i systemy informatyczne
• Testują oprogramowanie wytworzone przez zespoły developerskie, podnosząc jego jakość oraz wydajność
• Wdrażają zweryfikowane rozwiązania na produkcję
• Utrzymują systemy informatyczne na produkcji w obszarach: aplikacji, infrastruktury i bezpieczeństwa
• Zarządzają zespołami i procesami utrzymania, pozwalając zapanować nad chaosem twórczym i utrzymaniowym

Usługi IT to ludzie i obecnie trudno sobie wyobrazić, aby mogło się to wkrótce zmienić. Nie zapominajmy o tym w naszym codziennym zabieganiu i walce o plany, cele, zadania i KPI.

Człowiek

Ludzie to jakaś większa grupa, bliżej nie określona i trochę anonimowa. A przecież na ludzi składa się pojedynczy człowiek.

• Czy pamiętamy o tym, że jest wyjątkowy, jedyny w swoim rodzaju i mimo, że tego może nie okazywać, ma uczucia?
• Czy w codziennej pracy zwracamy uwagę, jak osoby z którymi współpracujemy czują się w naszej obecności?
• Czy chcą z nami pracować czy wręcz przeciwnie unikają nas jak ognia?
• Czy mówimy przy każdej nadarzającej się okazji proste słowo dziękuję i uśmiechamy się?
• Czy mamy ludzkie odruchy, gdy ktoś akurat się źle czuje lub ma problemy osobiste?

Jeżeli będziemy radośni i szczęśliwi, to ta aura będzie udzielać się wszystkim, którzy mają z nami kontakt i pokonywanie problemów w pracy od razu stanie się łatwiejsze.

Boże Narodzenie

Wkrótce Boże Narodzenie, najpopularniejsze święta w Polsce. Łamiemy się opłatkiem, składamy sobie życzenia, obdarowujemy się prezentami. Spędzamy ten czas w rodzinnym gronie i nie koniecznie musimy jeść, pić i popuszczać pasa.

Mimo naszego zabiegania za ostatnimi prezentami, zakupów aby przygotować smaczne dania na stół wigilijny i dwa dni świąteczne, pamiętajmy o drugim człowieku. Zechciejmy zobaczyć drugiego człowieka w nielubianym koledze, niesympatycznej koleżance w pracy lub wrednym szefie. Jeżeli bardziej będziemy traktowali się po ludzku to na pewno atmosfera w firmie będzie miła i sprzyjająca do ciężkiej i wytężonej pracy. Mam nadzieję, że nie tylko przed Świętami Bożego Narodzenia. Tego Wam wszystkim życzę.

Prośba: Powiedz w tym tygodniu jakieś miłe słowo, każdej osobie w pracy, z którą będziesz się spotykał, kontaktował, rozmawiał.

Artykuł IT, ludzie, człowiek, Boże Narodzenia pochodzi z serwisu Mariusz Siek.

Ostatnio śledzę ogłoszenia o pracę na głównych portalach w internecie. Robię to ponieważ, szukam nowych możliwości i sposobów na rozwój swojej kariery zawodowej. Zwróciło moją uwagę, że jest bardzo dużo ogłoszeń dla stanowisk wykorzystywanych w procesie wytwórczym oprogramowania. Natomiast pojawia się mało dla osób, które miałyby to oprogramowanie i systemy, na których ono działa, utrzymywać. Skąd taka dysproporcja? Czy taka sytuacja jest naturalna?

Kierownika projektów IT zatrudnię

Wśród ogłoszeń z branży IT, występuje bardzo dużo ogłoszeń o pracę dla kierowników projektów, delivery managerów, programistów Java oraz innych języków programowania, testerów, architektów, analityków. To bardzo dobrze, bo oznacza że firmy tworzą nowe rozwiązania IT, aplikacje i systemy. Jest to siła napędowa rozwoju branży IT oraz całej gospodarki, która dzięki informatyzacji staje się nowoczesna, innowacyjna i konkurencyjna.

Nowe oprogramowanie i aplikacje, ułatwiają nam życie, pomagają w codziennych sprawach, zmieniają nasze postrzeganie świata i dają szansę na lepszą przyszłość.

Co dalej?

Wytworzenie dobrego oprogramowania i uruchomienie go na infrastrukturze, aby działało niezawodnie to bardzo żmudny proces. Wymaga on zaangażowania wszystkich osób z działów IT w tym zespołów developerskich, analitycznych, testowych i zarządzających infrastrukturą sprzętowo-software’ową. Kiedyś jednak oprogramowanie zostanie wytworzone i wdrożone na środowisko produkcyjne i co dalej?

Gdzie ci specjaliści, specjalistki?

Skoro wytworzenie jakiegoś oprogramowania i uruchomienie go na produkcji wymaga zaangażowania tylu różnych specjalistów, to czy jego utrzymanie jest prostsze i nie nastręcza tylu problemów?

We wspomnianych ogłoszeniach o pracę, jak na lekarstwo można znaleźć oferty dla takich ról jak: manager incydentów, manager problemów, manager zmian, manager poziomu usług. Częściej występują role związane z Service Desk, administrowaniem infrastrukturą, aplikacjami czy bazami danych.

Czy jednak bez odpowiednich specjalistów od utrzymania można świadczyć usługi IT na wysokim poziomie? Według mnie nie!

Specjaliści a poziom usług IT

Poniższe pytania, oczywiście retoryczne, powinny dać dużo do myślenia:

• Czy bez managera poziomu usług, można poprawnie zdefiniować dobry katalog usług? Czy jego brak pozwoli nam na właściwe zdefiniowanie wymaganego poziomu usług SLA?
• Czy nie posiadanie managera incydentów, umożliwi rozwiązywanie zgłoszeń w wymaganych czasach reakcji i rozwiązania, wynikających z SLA?
• Czy nieobecność managera problemów, będzie pomocna w znajdowaniu przyczyn źródłowych błędów i awarii oraz pozwoli na zmniejszenie liczby incydentów od użytkowników?
• Czy nie zatrudnienie managera zmian, pozwoli efektywnie zarządzać i wprowadzać zmiany w systemach informatyczny?

U nas bez zmian

Dlaczego tak mnie to dziwi i nawet irytuje? Czy to jest nowe zjawisko?

Po pierwsze dlatego, że od początku swojej przygody z zarządzaniem usługami IT, widzę tą dysproporcję pomiędzy procesem wytwarzania oprogramowania i późniejszym jego utrzymaniem. Zainteresowanie projektów, odpowiedzialnych za wytworzenie, dostarczenie i wdrożenie rozwiązania informatycznego, kończy się po jego uruchomieniu na produkcji. Większość organizacji wychodzi z założenia, że najważniejsze jest uruchomić aplikację/system na produkcji, a później jakoś to będzie.

Po drugie większość mojego życia zawodowego spędziłem po stronie zespołów utrzymania i często czułem, że nie są one wystarczająco doceniane i wynagradzane, za wykonywanie swojej ciężkiej pracy. Często zespoły utrzymania muszą naprawić to, co nie zostało wystarczająco dobrze przygotowane i sprawdzone w zespole wytwórczym, a w zamian nie otrzymują nawet dobrego słowa.

Niech nie dziwi nas, że użytkownicy narzekają na wdrożone nowe rozwiązania IT, które mają dużo błędów i niedoróbek, których zespoły utrzymania, nie są w stanie na bieżąco i sprawnie rozwiązywać.

Bez inwestycji w dobrze działającą organizację utrzymania, nie można świadczyć usług IT na wysokim poziomie, bo za wymagany poziom usług odpowiadają nie tylko hardware i software ale przede wszystkim ludzie, tworzący sprawnie funkcjonującą organizację utrzymania!

Pytanie: Co byś poprawił w Twojej organizacji utrzymania?

Artykuł Specjalista utrzymania – poszukiwany, poszukiwana! pochodzi z serwisu Mariusz Siek.

Czy potrafisz sobie wyobrazić obecne życie bez energii elektrycznej? Co by się stało, gdyby nagle na całym świecie nie było prądu? Czy świat popadł by w chaos? Do refleksji na ten temat skłonił mnie brak energii elektrycznej u mnie w domu.

Pada, pada śnieg

W czwartek 30 listopada padał w mojej okolicy bardzo intensywnie śnieg. W ciągu jednej doby napadało około 20-25 cm, co na polskie realia jest dużą ilością. Temperatura była dodatnia i śnieg był mokry i ciężki. Przyklejał się do gałęzi drzew i łamał je lub powodował, że się mocno uginały. To najprawdopodobniej było przyczyną awarii i spowodowało, że około około 21 w czwartek. został wyłączony prąd. Włączyli dopiero w piątek o 20:00 czyli po prawie 23 godzinach.

Skutki

• Nie działa piec do ogrzewania, więc w domu zaczyna być chłodniej niż powinno :-). Na szczęście mam dobrą izolację budynku i temperatura za oknem nie jest ujemna więc temperatura nie spada gwałtownie. Dochodzi do 16.5 stopnia.
• Brak prądu powoduje, że aby wyjechać do pracy, trzeba ręcznie otworzyć bramę garażową i wjazdową. Dobrze, że zabezpieczyłem blokady na siłownikach smarem wypierającym wodę (HSM 100), to nie mam problemów, żeby to zrobić ale już zdarzało się, że przy ujemnych temperaturach wszystko było zamarznięte i odblokować nie można było.
• Nie działa komputer i internet więc popracować również się nie da, chociaż to akurat aktualnie najmniejszy problem.
• Na szczęście mam gaz więc można ugotować wodę i nie tylko, chociaż trzeba mieć zapałki, które mam ale obecnie nie są już często widzianym produktem

Naprawa przez zakład energetyczny

Jako człowiek od zarządzania usługami IT, próbuję zgłosić w piątek rano awarię (brak prądu) do zakładu energetycznego (ZE). Na numer 991 trudno się dodzwonić, a jak już się uda połączyć to każą czekać na po rozmowę, do której nie dochodzi, bo połączenie jest rozłączane. Dopiero około południa, po trzeciej próbie połączyłem się z panem, który na pytanie kiedy zostanie usunięte awaria powiedział, że faktycznie maja awarie w tym rejonie i je naprawią. Doprecyzowałem pytanie czy naprawią do 15 czy 18? Otrzymałem odpowiedź, że do 19. Jak widać pan nie pomylił się za dużo bo prąd włączyli o 20:00.

SLA i obsługa klienta

Czy ZE ma SLA na usunięcie takiej awarii? Może prędzej OLA ale mi jest nie znane. Co prawda otrzymałem odpowiedź, że do 19:00 ale czy to można nazwać SLA? To jeżeli nie ma SLA, to przynajmniej może obsługa klienta na poziomie. Raczej nie. Po pierwsze nie mogłem się dodzwonić a jak już mi się udało to, nawet nie usłyszałem słowa przeprasza, mimo, że wiem, że to nie jest wina ZE tylko pogody. Chociaż może jednego i drugiego?

Wnioski

• W tym roku to już trzecia awaria, kiedy nie ma energii elektrycznej przez prawie dobę. Dwie poprzednie były dłuższe, tylko były w lato więc mniej dokuczliwe. Albo to zbieg okoliczności związany z pogodą albo infrastruktura elektroenergetyczna nie jest na odpowiednim poziomie.
• Muszę pomyśleć o kupnie agregatu prądotwórczego aby mieć rozwiązanie awaryjne na takie przypadki.
• Jak ludzie żyli bez prądu? Nie było to wcale tak dawno, jeszcze moi rodzice jak się pobierali (ponad 40 lat temu), to w domu mojej Mamy nie było energii elektrycznej. Życie było inaczej zorganizowane i nie było urządzeń, które by potrzebowały zasilania. Gotowało się na ogniu, ogrzewało piecem, świeciło lampą naftową a cykl życia i prac wyznaczały wschód i zachód słońca.
• Dzisiaj wszystko wymaga energii elektrycznej, nie mówię o komputerach, telewizorach, telefonach, lodówkach, kuchenkach, pralkach itp, ale nawet nowoczesny piec na ekogroszek lub inne ciała stałe nie będzie działał bez zasilania.

Nie wyobrażam sobie życia bez energii elektrycznej. Jakby zabrakło jej na całym świecie to byłby armagedon, szczególnie w dużych miastach, gdzie nie ma możliwości skorzystać z alternatywnych rozwiązań zasilania lub ogrzewania.

Pytanie: Co zrobiłbyś, gdybyś musiał przeżyć w zimę, tydzień bez energii elektrycznej w bloku w dużym mieście?

Artykuł Wyobraź sobie życie bez prądu pochodzi z serwisu Mariusz Siek.

W celu lepszego zrozumienia i pokazania jak należy tworzyć katalog usług wcieliłem się w postać Marka Zuckerberga, twórcy najbardziej znanego i najpopularniejszego portalu społecznościowego Facebook. Przygotuję katalog usług dla Facebooka dla wybranej usługi biznesowej i usługi systemu. Oczywiście będą to przeze mnie wymyślone usługi z parametrami jakie według mnie powinny posiadać ale jak najbardziej zbliżone do realnych. Może Mark z nich skorzysta ?

Definiowanie usługi biznesowej

• Nazwa usługi – Konto dla użytkownika indywidualnego

• Opis usługi – usługa umożliwia dostęp do konta na portalu Facebook dla użytkowników indywidualnych z urządzeń stacjonarnych i mobilnych. Użytkownik po zalogowaniu może korzystać ze wszystkich funkcjonalności w ramach swojego profilu

• Ważność dla biznesu– krytycza, ze względu na fakt, że jest to jedna z głównych funkcjonalności portalu. Oprócz niej są jeszcze inne takie jak np. FunPage, promowanie postów

• Termin wdrożenia na produkcję – 4.02.2004 (według https://pl.wikipedia.org/wiki/Facebook#Utworzenie)

Parametry usługi biznesowej

• Role – trochę przekornie podałem prawie wszędzie Marka Zuckerberga jako pełniącego wszystkie role (oprócz użytkownika) ale tak naprawdę w 2003/2004 roku tak było

  • Właściciel usługi biznesowej – Mark Zuckerberg,

  • Użytkownik/Użytkownicy – wszystkie osoby mające dostęp do internetu

  • Kierownik Projektu – Mark Zuckerberg

  • Service Level Manager – Mark Zuckerberg

  • Service Manager/Owner – Mark Zuckerberg

  • Analityk – Mark Zuckerberg

  • Architekt, Architekt infrastruktury, Architekt bezpieczeństwa – Mark Zuckerberg

• Ciągłość działania (BCP) – usługa jest krytyczna dla Facebook. Na niej opiera się najważniejszy biznes FB wię jest krytyczna i musi być uwzględniona w BCP. Nie robię analizy ryzyka ale od razu wiem, że wartości dla wartości dla dwóch parametrów powinny być następujące:

  • Recovery Time Objective (RTO) = 0 godzin 0 minut – FB nie może pozwolić sobie na niedostępność swojej krytycznej i najważniejszej usługi dlatego zostosowano rozwiązania High Availability, zapewniające ciągłość działania nawet w przypadku wystąpienia awarii

  • Recovery Point Obejctve (RPO) = 0 godzin 0 minut – FB nie może sobie pozwolić na utratę jakichkolwiek danych

• Bezpieczeństwo

  • metoda uwierzytelniania/dostępu – login i hasło, można ustawić two-factor authentication, który zwiększa poziom bezpieczeństwa poprzez potwierdzenia określonych czynności specjalnym kodem wysyłanym sms ma telefon komórkowy

  • polityka haseł – dostępna funkcjonalność, która pokazuje podczas zmiany hasła czy spełnia określone wymagania: długość, złożoność itp

  • odzyskiwanie hasła – działa funkcja przypominania hasła w przypadku jego zapomnienia

Definiowanie usługi systemu

• Nazwę usługi – Publikacja posta na profilu prywatnym

• Opis usługi – usługa umożliwia opublikowanie posta w formie tekstu, zdjęcia, wideo, aktywności na profilu prywatnym przez jego właściciela z urządzenia stacjonarnego lub mobilnego

• Ważność dla biznesu – krytycza, ze względu na fakt, że jest to jedna z głównych funkcjonalności profilu prywatnego. Oprócz niej są jeszcze inne takie jak np. wideo na żywo, like’owanie, komentowanie i dzielenie się postami innych użytkowników

Parametry usługi systemu (SLA)

Dostępność

• Kalendarz świadczenia – 24/7/365 – usługa musi być dostępna non-stop

• Dostępność w % = 99,999% w miesiącu – bardzo wysoka dostępność związana z krytycznością usługi

• Niedostępność = 26 sek w miesiącu – przeliczona z procentów na czas niedostępność usługi

Wydajność

• Wolumetria (pojemność) – rzeczywiste dane o wolumetrii Facebook dostępne są na stronach https://www.brandwatch.com/blog/47-facebook-statistics-2016/ https://expandedramblings.com/index.php/by-the-numbers-17-amazing-facebook-stats/. Zachęcam do zapoznania, niektóre liczby powalają.

• Czas odpowiedzi = 1 sekunda – takiego czasu odpowiedzi oczekują po kliknięciu na opublikuj posta

Obsługa serwisowa

• Przyjmowanie zgłoszeń – 24/7/365 – skoro usługa jest krytyczna i świadczona non-stop to przyjmowanie zgłoszeń również powinno być non-stop.

• Obsługa zgłoszeń – 24/7/365 – analogicznie jak przyjmowanie zgłoszeń przez https://www.facebook.com/help/

• Czas reakcji = 30 minut – wartość pożądana, której nie udało się potwierdzić na stronach FB

• Czas rozwiązania = 4 godziny– wartość pożądana, której nie udało się potwierdzić na stronach FB

• Okno serwisowe – od 00:00 do 06:00 GMT bez niedostępności. Architektura FB jest tak zaprojektowana i wdrożona, że wdrażanie poprawek lub nowych wersji nie wpływa na dostępność usługi dla użytkowników

Przedstawiłem przykładową usługę biznesową i systemy dla Facebook. Wierzę głęboko, że pozwoliło to przybliżyć tematykę tworzenia katalogu usług, dla osób które mają z nią pierwszy kontakt.

Zachęcam do dyskusji czy zdefiniowane przeze mnie usługa biznesowa i systemy oraz parametry je opisujące wiarygodnie opisują funkcjonalności Facebook, i które parametry mogą mieć wartości takie jak w rzeczywistości a które nie. Jeżeli masz jakieś pytania lub uwagi napisz je w komentarzy pod publikacją.

Artykuł Katalog usług dla Facebook pochodzi z serwisu Mariusz Siek.

W pierwszej części przedstawiłem jak zdefiniować usługę biznesową i jakie przypisać jej parametry w tym związane z SLA. W części drugiej zaprezentuję jak zdefiniować usługę systemu i jak określić dla niej parametry na poziom usług (SLA). Dana usługa systemu jest ściśle powiązana z konkretną usługą biznesową i dziedziczy po niej parametry usługi biznesowej.

Co jest potrzebne do zdefiniowania usługi systemu?

Definiując usługę systemu postępujemy analogicznie jak dla usługi biznesowej. Korzystamy z dokumentacji analitycznej przygotowanej przez zespół analizy oraz dokumentacji architektonicznej. Ponieważ co raz częściej zespoły wytwórcze pracują według metodyk zwinnych (Agile, Scrum) nie ma dokumentacji analitycznej a jedynym źródłem są historyjki. Dobrym sposobem jest spotkanie się z analitykiem i/lub architektem i pozyskanie niezbędnych informacji.

Definiowanie usługi systemu

Na podstawie uzyskanych informacji tworzymy usługę systemu. Pomagamy sobie definicją usługi systemu – jednoznacznie wyodrębniona w granicach systemu, funkcjonalność, która spełnia warunki: inicjuje ją użytkownik, daje określony rezultat i w ramach której wykonywane są operacje.

W oparciu o definicję tworzymy:

• Nazwę usługi, która pozwoli ją jednoznacznie zidentyfikować i będzie pozwalała na zrozumienie czego ona dotyczy

• Opis usługi, zawierający bardziej szczegółowe informacje o jej działaniu

• Ważność dla biznesu, określający jak ważna dla biznesu jest usługa systemu. Możemy wyróżnić trzy poziomy ważności: krytyczna, bardzo ważna i ważna. Ważność dla biznesu będzie miała wpływ na wyznaczenie poziomu usługi (SLA).

Katalog usług – Parametry usługi systemu (SLA)

Dla zdefiniowanej usługi systemu w katalogu usług, określamy jej poziom świadczenia następującymi parametrami SLA.

Dostępność

• Kalendarz świadczenia, określający w jakich dniach tygodnia i godzinach usługa jest świadczona dla użytkowników np. dni robocze 8:00-16:00

• Dostępność w %, określa jaki procent czasu usługa jest dostępna w ustalonym kalendarzu świadczenia za dany okres (najczęściej miesiąc) np. 99%

• Niedostępność, w inny sposób wyrażona dostępność w % pokazująca ile czasu (minut, godzin) usługa może być niedostępna w kalendarzu świadczenia za dany okres (najczęściej miesiąc) np. 101 minut w miesiącu (1 godz 41 minut), dla kalendarza świadczenia dni robocze 8:00-16:00 i dostępności w procentach 99%

Wydajność

• Wolumetria (pojemność), wyznacza maksymalną liczbę wywołań usługi systemu w jednostce czasu (minuta, godzina, dzień, miesiąc, rok), określając maksymalną pojemność dla usługi. Przykładowe parametry wolumetryczne:

  • Maksymalna liczba wywołań usługi w czasie

  • Średnia liczba wywołań usługi w czasie

• Czas odpowiedzi, określa czas oczekiwania użytkownika od momentu wywołania usługi do zwrócenia przez usługę odpowiedzi/wyniku np. 1 sekunda. Aby wyznaczyć czas odpowiedzi należy zdefiniować początek i koniec usługi systemu.

Obsługa serwisowa

• Przyjmowanie zgłoszeń, wskazuje przedział czasu, w którym przyjmowane są zgłoszenia (incydenty, service requesty, problemy) od użytkowników. Przyjmowanie zgłoszeń może być procesem automatycznym i różnić się od czasu obsługi zgłoszeń np. dni robocze od 6:00 do 18:00

• Obsługa zgłoszeń, wyznacza przedział czasu, w którym zespoły wsparcia obsługują zgłoszenia np. dnia robocze 8:00-16:00. Na zespoły wsparcia składają się I linia wsparcia (Service Desk), II linia wsparcia (zespoły utrzymania) i III linia wsparcia (zespoły wytwórcze lub dostawcy zewnętrzni).

• Czas reakcji, określa czas od przekazania zgłoszenia przez użytkownika (telefon, maila, narzędzie ITSM) do Service Desk do potwierdzenie przyjęcia zgłoszenia przez Service Desk np. 30 minut.

• Czas rozwiązania, wskazuje ile czasu zespoły wsparcia mają na rozwiązanie zgłoszenia (incydent, service request, problem) liczone od jego potwierdzenia przez Service Desk do dostarczenia skutecznego rozwiązania do użytkownika np. 4 godziny. Czas reakcji i rozwiązania można różnicować w zależności od ważności usługi dla biznesu (krytyczna, bardzo ważna i ważna)

• Okno serwisowe, podaje przedział czasu, w którym zespoły wsparcia mogą wdrażać rozwiązania zgłoszeń (incydenty, service requesty, problemy) oraz zmiany na produkcję np. codziennie 18:00-20:00. Okno serwisowe wiąże się przeważnie z niedostępnością usługi i powinno być poza kalendarzem jej świadczenia. Wyjątkiem są usługi świadczone w trybie 24/7/365.

Przedstawiłem najważniejsze parametry dla usługi systemu i na tym zakończę część drugą i ostatnią dotyczącą tworzenia katalogu usług. Oczywiście jeżeli są inne wymagania, można dla nich również zdefiniować parametry SLA. Mam nadzieję, że przedstawiona wiedza pomoże lepiej zrozumieć katalog usług i poziom świadczenia usług (SLA).

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Artykuł Katalog Usług – co powinien zawierać? Część 2 pochodzi z serwisu Mariusz Siek.

ITIL a model usługowy

ITIL już w 2007 roku wprowadził model usługowy prezentując trzecią wersję najlepszych praktyk w zarządzaniu usługami IT. Model ten zakłada, że usługa jest podstawowym elementem w zarządzaniu usługami IT. W tym celu został stworzony cykl życia usługi, który pokazuje etapy jej funkcjonowania od strategii, przez projektowanie i wytwarzanie, po wdrożenie, utrzymanie operacyjne aż po ciągłą jej poprawę. W ten sposób ITIL nie skupia się tylko na wdrożeniu i utrzymaniu usług ale wskazuje potrzebę zaangażowania na etapie strategii, projektowania i tworzenia usług oraz ich ciągłego doskonalenia.

Dlaczego więc 10 lat po wprowadzeniu tego innowacyjnego podejścia nadal wiele organizacji nie stosuje tych praktyk u siebie? Postaram się pokazać najważniejsze problemy i wskazać dla nich rozwiązania.

Strategia

Pierwszym etapem w cyklu życia usługi jest Strategia. Jest ona elementem przygotowywanym przez najwyższe kierownictwo organizacji (zarząd, dyrektorzy) i na tym poziomie nikt nie patrzy oczami usług tylko celów biznesowych, planów sprzedażowych, KPI. Poziom dyskusji jest na tak wysokim poziomie, że nie jest to właściwe miejsce do spojrzenia usługowym modelem. Jestem w stanie nawet zaakceptować takie podejście chociaż uważam, że w jakimś stopniu ten czynnik usługowy powinien być uwzględniony. Zarząd powinien wspierać się wiedzą managerów usług IT, którzy mają potrzebne kompetencje i doświadczenie i są w stanie przełożyć wysoko poziomową strategię na usługi.

Projektowanie i wytwarzanie

Kolejnym etapem w cyklu życia usługi jest projektowanie i wytwarzanie usług, w ramach którego większość organizacji nie myśli nadal usługowo. Powoływane są projekty, które mają za zadanie dostarczyć określone produkty, którymi najczęściej są aplikacje, systemy i rozwiązania, które nie koncentrują się na usługach dla użytkownika. Ponieważ nie mamy usług to nie są definiowane dla nich wymagania SLA, co oznacza że na etapie wytwarzania nikt nie myśli jak usługi będą działać po wdrożeniu na produkcję. Menedżerowie usług IT nie uczestniczą od początku w realizacji projektu i definiowaniu wymagań tylko są traktowani jako zło konieczne i angażowani na krótko przed wdrożeniem produkcyjnym, gdy podstawowe założenia są już określone i produkty są już w zaawansowanym stanie. Wtedy oczekuje się, że Service Level Manager zdefiniuje usługi, określi dla nich SLA i zweryfikuje wymagania podczas testów niefunkcjonalnych (wydajność, pojemność, dostępność). Nie ma w projekcie zaplanowanych zasobów na realizację testów niefunkcjonalnych i zaczyna się przepychanka, kto je wykona.

Czy można temu zaradzić oczywiście, że tak. Jak to zrobić?

• Powołać w projekcie rolę Service Level Managera, który od jego początku będzie uczestniczył w definiowaniu wymagań SLA (niefunkcjonalnych)

• Traktować wymagania niefunkcjonalne tak samo jak wymagania funkcjonalne, zapewniając zasoby projektu do ich opracowania i weryfikacji

• Zaplanować testy wymagań niefunkcjonalnych i uwzględnić przez projekt, zasoby potrzebne do ich przeprowadzenia

Wdrożenie

Kolejnym etapem w cyklu życia usługi jest wdrożenie usług na produkcję. Tu jest trochę lepiej jednak nadal nie wdrażamy usług tylko aplikacje, systemy, pakiety itp. Nie przekazujemy wiedzy o przygotowanym rozwiązaniu z zespołów wytwórczych do zespołów utrzymania. Jeżeli działamy w modelu DevOps to jeszcze mamy szansę na odpowiednie obsługiwanie błędów z produkcji ale przy innym podejściu do utrzymania już raczej szanse są minimalne. Nie jest tworzona w trakcie wytwarzania, baza znanych błędów i nie jest ona przekazywana do utrzymania.

Co można zrobić aby było lepiej?

• Rejestrować i procesować zmiany (Change Request) do usług a nie systemów

• Utworzyć bazę wiedzy i znanych błędów na etapie wytwarzania i przekazać do utrzymania w ramach wdrożenia

• Zaangażować osoby z utrzymania na etapie wytwarzania w celu lepszego poznania rozwiązania, które będzie wdrażane na produkcję

Utrzymanie operacyjne

Na tym etapie również nie lubimy modelu usługowego. Zespoły utrzymania odpowiadają za działania aplikacji i systemów, które składają się na usługi. Często jest tak, że dwa lub więcej zespołów odpowiada za aplikacje i systemy wchodzące w skład jednej usługi. W przypadku nie działania usługi lub jej niepoprawnego działania nie ma podejścia usługowego tylko każdy zespół sprawdza u siebie i wskazuje na inny zespół, że problem jest po ich stronie. Brak jest właściciela usługi (Service Manager/Owner) po stronie zespołów utrzymania, który by odpowiadał całościowo za jej działanie. Użytkownicy zgłaszają błędy do aplikacji a nie usług. Narzędzia wspierające obsługę zgłoszeń (ITSM) nie są skonfigurowane pod usługi tylko aplikacje/systemy.

Jak to zmienić?

• Powołać rolę Service Managera/Ownera, który w IT będzie odpowiadał za działanie usługi, niezależnie z jakich składa się aplikacji i systemów

• Zdefiniować w narzędziu ITSM usługi zamiast aplikacja i systemy

• Przeprowadzić kampanię edukacyjną wśród użytkowników z usługowego podejścia

Ciągła poprawa

Ten etap jest często pomijany i nie wykorzystywany. Duża ilość błędów na produkcji, niewystarczające zasoby ludzkie do ich naprawiania i ciągła presja czasu powodują, że nie ma kiedy i kim przeprowadzać ciągłą poprawę usługi.

Tutaj nie ma złotego środka. Trzeba przygotować Plan Poprawy Usługi (Service Improvement Plan), w takim zakresie, który pozwoli posiadanym zasobom ludzkim realizować go w ramach swoich obowiązków lub zwiększyć skład osobowy zespołów aby mogły wykonywać zadania związane z poprawą usług.

Mam nadzieję, że zwiększanie świadomości o potrzebie usługowego podejścia w IT zaowocuje zmianą percepcji na wszystkich etapach cyklu życia usługi, co będzie z korzyścią zarówno dla Biznesu i Użytkowników usług jak i działów IT dostarczających te usługi.

Artykuł Model usługowy – Dlaczego organizacje go nie wykorzystują? pochodzi z serwisu Mariusz Siek.