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.

W poprzednim artykule opisywałem proces zarządzania katalogiem usług. Bardzo mocno z nim powiązany jest proces zarządzania poziomem usług. Tak naprawdę kiedyś zarządzanie katalogiem usług było w ramach procesu zarządzania poziomem usług, ale zostało wydzielone do oddzielnego procesu. Nie dziwi więc fakt, że oba procesy są spokrewnione i zarządzanie poziomem usług bez katalogu usług nie miałoby co robić, bo poziom świadczenia określa się dla usług zdefiniowanych w katalogu usług. Ponieważ katalog usług jest bardzo ważnym produktem i narzędziem w zarządzaniu usługami IT, według mnie dobrze się stało, że został do jego zarządzania powołany dedykowany proces. Co zatem zostało w procesie zarządzania poziomem usług?

Cele

Podstawowym celem procesu zarządzania poziomem usług jest zagwarantowanie, że wszystkie aktualne i planowane usługi, są dostarczane na uzgodnionym, wymaganym poziomie. Osiąga się ten cel poprzez ciągły cykl negocjacji, uzgadniania, monitorowania, raportowania i przeglądania wymaganych (dopuszczalnych) wartości parametrów SLA.

Proces koncentruje się na:

• Definiowaniu, dokumentowaniu, uzgadnianiu, monitorowaniu, mierzeniu, raportowaniu i przeglądaniu poziomu, dostarczanych usług IT. Jeżeli jest potrzeba wprowadzane są środki naprawcze
• Zapewnieniu i poprawie relacji i komunikacji z biznesem i klientami
• Zapewnieniu, że zostaną określone, konkretne i mierzalne cele (wartości dopuszczalne) dla wszystkich usług IT
• Monitorowaniu i poprawie satysfakcji klienta z jakości świadczonych usług
• Zapewnieniu, że IT i Klienci mają jasne i jednoznaczne oczekiwania co do poziomu świadczonych usług
• Zagwarantowaniu, że nawet jeżeli wszystkie wymagane wartości poziomu usług zostaną spełnione, będą podejmowane proaktywane działania, mające na celu ciągłą poprawę kosztową usług

Zakres

Rysunek z książki ITIL Service Design

W zakresie procesu zarządzania poziomu usług jest zapewnienie regularnych kontaktów i komunikacji z klientami i menedżerami biznesowymi, w zakresie związanym z poziomem świadczonych usług. W tym względzie proces SLM powinien reprezentować dostawcę usług IT przed biznesem i biznes przed dostawcą usług IT. Zakres procesu SLM obejmuje również:

• Współpracę z procesem zarządzania relacjami biznesowymi (proces na etapie strategii), w zakresie osiągnięcia celów procesu SLM
• Negocjacje i uzgodnienie przyszłych (planowanych) wymagań na poziom usług i wartości dopuszczalnych (Service Level Requirements – SLR) dla wszystkich usług
• Negocjacje i uzgodnienie aktualnych wymagań na poziom usług i wartości dopuszczalnych (Service Level Agreement – SLA)
• Rozwijanie i zarządzanie odpowiednich umów OLA, które zagwarantują dotrzymanie celów w umowach SLA
• Przeglądanie i zarządzanie umowami z dostawcami zewnętrznymi (Underpinning contracts),które zagwarantują dotrzymanie celów w umowach SLA
• Proaktywne zapobieganie awarią usług, minimalizowanie ryzyka i poprawa jakości usług
• Raportowanie i zarządzanie rzeczywistym poziomem usług i przeglądanie wszystkich przekroczeń poziomu usług zdefiniowanego w SLA
• Okresowe przeglądy SLA, OLA i zakresu usług
• Identyfikowanie możliwości usprawnień i wprowadzanie ich do rejestru usprawnień
• Inicjowanie i koordynowanie planu poprawy usług (Service Improvement Plan – SIP)

Proces zarządzania poziomem usług nie obejmuje:

• Negocjacji i uzgodnienia wymagań funkcjonalnych, oprócz tych funkcjonalności, które mogą wpływać na poziom świadczonych usług
• Pilnowania aktywności, które są konieczne do zapewnienia wymaganego poziomu usług, ale są realizowane przez inne procesy takie jak zarządzanie dostępnością i zarządzanie pojemnością.
• Negocjacji i podpisywania umów z dostawcami zewnętrznymi, za które odpowiada proces zarządzania dostawcami. SLM dostarcza tylko dane wejściowe i wymagane konsultacje.

Korzyści

Efektywnie funkcjonujący proces zarządzania poziomem usług zapewnia:

• Interfejs dla biznesu, dla wszystkich zagadnień związanych z poziomem usług
• Uzgodnione SLA z określonymi celami (wartościami dopuszczalnym) oraz informację zarządczą, że te cele są spełnione
• Wyjaśnienie przyczyn źródłowych przekroczenia SLA i podejmowanie działań, które zagwarantują nie powtarzanie się tych przekroczeń
• Wiarygodny kanał komunikacji i zaufane relacje z klientem i biznesem

Rodzaje SLA

SLA możemy definiować na kilka różnych sposobów.

• SLA zorientowane na usługę, definiujemy jedno SLA dla usługi, chociaż może z niej korzystać wielu klientów. Problemem może być zróżnicowanie poziomu SLA, jeżeli usługa korzysta z tych samych elementów konfiguracji
• SLA zorientowane na klienta, definiujemy SLA dla jednego klienta, uwzględniając wszystkie usługi jakie dla niego świadczymy
• Wielopoziomowe SLA, którego przykładem może być trzypoziomowe SLA: poziom korporacji, poziom klienta i poziom usługi

Podsumowanie

To zaczyna się robić nudne :-). Zarządzanie poziomem usług to kolejny bardzo ważny proces w zarządzaniu usługami IT. Jest odpowiedzialny za ustalenie z biznesem, na jakim poziomie będą świadczone usługi IT. Musi przy tym uwzględniać wymagania biznesu i klienta, możliwości organizacji IT, posiadane zasoby sprzętowe i softwareowe oraz obowiązujące umowy z dostawcami zewnętrznymi. Żąglowanie tymi wszystkimi elementami, wymaga nie lada umiejętności od Menedżera poziomu usług. Potrzebne jest również doświadczenie w negocjowaniu, komunikacji, budowaniu relacji i balansowaniu pomiędzy biznesem a IT.

Pytanie: Jaki rodzaj SLA stosujesz najczęściej i dlaczego?

Artykuł Zarządzanie poziomem usług 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.

Od 12 lat zajmuję się zarządzaniem usługami IT. W mojej pracy wykorzystuję najlepsze praktyki ITIL i doświadczenie zdobyte na przestrzeni tego okresu. Świat jednak nie stoi w miejscu i zmienia się bardzo szybko, szczególnie w obszarze technologii. Czy ITIL, który został wymyślony w latach dziewięćdziesiątych poprzedniego wieku, spełnia oczekiwania dzisiejszego IT, które musi sprostać wysokim wymaganiom biznesowym? Czy wersja trzecia ITIL, która ukazała się w 2007 roku, nadal jest aktualna i stosowanie jej przynosi spodziewane korzyści? Jak zmieni się ITIL w wersji 4, która jest zapowiadana na ten rok? Czy ITIL ma szanse w konfrontacji z DevOps, które obecnie jest jednym z najbardziej popularnych i pożądanych podejść na funkcjonowanie IT? Za dużo pytań jak na początek artykułu :-). Spróbujmy znaleźć na nie odpowiedzi.

ITIL

ITIL w wersji 3 wprowadził usługowe podejście do IT i cykl życia usługi. Cykl życia składa się z pięciu faz:

• Strategii
• Projektowania
• Wdrożenia
• Utrzymania
• Ciągłej poprawy

Cykl ten się powtarza, ponieważ zawsze możemy coś zrobić aby usługa była świadczona lepiej, taniej i na wyższym poziomie.

To podejście objęło cały cykl wytwórczy dla usługi, czego nie było w poprzedniej, drugiej wersji biblioteki. Całkowitą nowością była faza strategii. Natomiast pozostałe fazy zostały rozszerzone o brakujące procesy.

Wiele organizacji IT nadal funkcjonuje w oparciu o procesy opisane w ITIL, z uwzględnieniem ich potrzeb i wymagań. Według mnie nie straciły one nic ze swojej aktualności, chociaż mogą się wydawać „ciężkie”, mało zwinne i bardzo sformalizowane. Czy ich biurokracja jest w stanie sprostać, wymaganiom na wykonywanie kilku wdrożeń dziennie?

Rys 1. Na podstawie książki ITIL Service Transition.

DevOps

Po drugiej stronie mamy DevOps, który mocno się rozpycha i pokazuje, że można do wytwarzania i wdrażania usług, rozumianych jako oprogramowanie i infrastruktura sprzętowa, zastosować takie rozwiązania, które pozwolą szybko, sprawnie i bezproblemowo, dostarczać na produkcję nowe funkcjonalności i aplikacje. W największym uproszczeniu, DevOps to połączenie wytwarzania usług (development) z ich utrzymaniem (operations). Usuwamy odwieczny mur pomiędzy rozwojem i utrzymaniem, i tak organizujemy pracę zespołu aby mógł szybko dostarczać wartość biznesową na produkcję. Nie chodzi tu oczywiście tylko o ludzi ale przede wszystkim procesy i narzędzie. Musimy zastosować pełną automatyzację testów, ciągłą integrację, infrastrukturę jako kod i kilka innych specyficznych dla DevOps rozwiązań.

Rys 2. Na podstawie wideo What is DevOps

Wspólne elementy

Czy to oznacza, że nie można pogodzić DevOps z ITIL? Na pierwszy rzut oka, wydaje się, że są to dwa różne światy, jednak po bliższym przyjrzeniu się znajdziemy kilka części wspólnych.

• Cykliczność. Oba podejścia uwzględniają cykliczne działanie, które ma na celu ciągłe doskonalenie wytwarzanych i implementowanych rozwiązań. Łatnie to widać na dwóch powyższych rysunkach. Oczywiście częstotliwość tych cykli jest inna ale można ją próbować synchronizować.
• Procesy. W obu metodykach wykorzystywane są procesy, które muszą być dobrze zaprojektowane, dostosowane i wdrożone do potrzeb organizacji. Co ciekawe niektóre tak samo lub bardzo podobnie się nazywają: zarządzanie zmianą, zarządzanie wydaniami, zarządzanie pojemnością i zarządzanie konfiguracją. Nie trzeba wyjaśniać, że np. proces zarządzania zmianą w ITIL aby działał na potrzeby DevOps musi zostać odpowiednio zmieniony, zaadaptowany i zautomatyzowany.
• Ciągłe doskonalenie. Nie ważne czy nasz cykl wytwórczy trwa jedną godzinę, jeden dzień czy jeden miesiąc, mamy świadomość, że nie dostarczymy idealnego rozwiązania i będziemy musieli je poprawiać, usprawniać i rozwijać. Tak samo do tego zagadnienia podchodzą obie metodologie i to daje szansę na ich wspólne funkcjonowanie.
• Narzędzia. Do wsparcia procesów zarówno w ITIL jak i DevOps potrzebne są specjalistyczne narzędzia. Oczywiście są to innego rodzaju narzędzia, bo specyfika jest różna ale bez narzędzi, obsługa procesów nie byłaby możliwa.

Chociaż ITIL i DevOps, wydają się dwoma, odmiennymi światami, to można znaleźć kilka cech wspólnych, które pozwalają na funkcjonowanie obu podejść jednocześnie w tej samem organizacji. ITIL nie wyklucza DevOps i DevOps nie wyklucza ITIL. Można wykorzystać obie metodologie i stworzyć własne rozwiązanie dopasowane do potrzeb organizacji. Wydaje się, że to ITIL, zgodnie z dewizą „adopt and adapt” musi dopasować się do DevOps a nie odwrotnie. Wymaga to jednak poważnego zastanowienia się jak to zrobić.

Pytanie: Czy uważasz, że można pogodzić ITIL i DevOps i dlaczego?

Artykuł Czy ITIL i DevOps można pogodzić? pochodzi z serwisu Mariusz Siek.

Przejście z etapu projektowania i wytwarzania do etapu eksploatacji usługi IT, oprócz procesu walidacji i testowania, wymaga jeszcze zarządzenia wydaniami i wdrożeniami, które te wydania wprowadzą na produkcję. Żeby nie było, mamy dedykowany proces, który się tym zajmuje i pomaga nam abyśmy o niczym nie zapomnieli. Jakie są najważniejsze elementy tego procesu, chciałbym napisać w tym artykule.

Cele

Proces zarządzania wydaniami i wdrożeniami odpowiada za zaplanowanie, zaharmonogramowanie i kontrolę budowania, testowania i wdrażania wydań oraz dostarczenie nowych funkcjonalności dla biznesu, jednocześnie zapewniając integralność istniejących na produkcji usług.

Realizacja tej odpowiedzialności wymaga:

• Zdefiniowania i uzgodnienia planów wydań i wdrożeń z wszystkimi udziałowcami, w tym z klientem
• Przygotowania i przetestowania pakietu wydania, składającego się z elementów konfiguracji, które są ze sobą spójne
• Zapewnienia integralności pakietu wydania oraz komponentów wchodzących w jego skład, w całym procesie wdrożenia
• Przechowywania pakietów wydań w repozytorium wydań (Definitive Media Library)
• Wdrożenia pakietu wydania z repozytorium wydań na produkcję, zgodnie z planem i harmonogramem
• Zagwarantowania, że wszystkie pakiety wydania mogą być monitorowane, instalowane, testowane, weryfikowane, odinstalowywane i wycofane
• Zagwarantowania, że nowa lub zmieniona usługa, w zakresie technologii i organizacji, dostarcza oczekiwane wymagania funkcjonalne i niefunkcjonalne
• Rejestrowania i zarządzania ryzykami i zagadnieniami, związanymi z nową lub zmienioną usługą oraz podejmowanie działań naprawczych
• Zagwarantowania transferu wiedzy do użytkowników aby mogli lepiej wykorzystać dostarczane usługi
• Zagwarantowania przekazania umiejętności i wiedzy do zespołu utrzymania, aby mógł świadczyć wsparcie zgodne z SLA

Zakres

Zakres procesu zarządzania wydaniami i wdrożeniami obejmuje procesy, systemy i funkcje, wymagane do przygotowania pakietu, testowania i wdrożenia wydania na produkcję.

W szczególności dotyczy elementów konfiguracji takich jak:

• Infrastruktura sprzętowo-programowa
• Zasoby wirtualne jak serwery i dyski
• Aplikacje i oprogramowanie standardowe
• Szkolenia na użytkowników i zespołów utrzymania
• Usługi oraz związane z nimi umowy np SLA, katalog usług

Proces zarządzania wydaniami i wdrożeniami:

• Odpowiada za testowanie wydania, jednak samo testowanie jest wykonywane w ramach procesu walidacji i testowania
• Nie odpowiada za akceptację zmian, która jest przeprowadzana w procesie zarządzania zmianą

Korzyści

Dobrze i efektywnie działający proces zarządzania wydaniami i wdrożeniami, przynosi następujące korzyści:

• Zmiana dostarczana jest szybciej, optymalnie kosztowo i ze zminimalizowanym ryzykiem
• Gwarancja wykorzystania nowych lub zmienionych usług przez klientów i użytkowników, w sposób, który wspiera cele biznesowe
• Poprawa spójnego podejścia do wdrożenia w zakresie zmiany biznesowej, zespołów usługowych, dostawców i klientów
• Przyczynienie się do spełnienia wymagań audytowych, związanych z monitorowaniem w całym procesie wdrożenia
• Zmniejszenie kosztów dostarczanej usługi – zespoły IT nie muszą rozwiązywać problemów związanych z wdrożeniem

Pilot

Bardzo użytecznym rozwiązaniem przy wdrażaniu nowych usług jest skorzystanie z pilota, czyli wdrożenie usług tylko dla wybranych użytkowników. Należy jedna zwrócić uwagę na właściwe dobranie liczby użytkowników. Jeżeli użytkowników będzie za mało, to weryfikacja będzie nie wystarczająca i nie zostaną wykryte błędy, które wystąpią następnie na produkcji. Jeżeli użytkowników będzie za dużo, to nie uzyskamy odpowiedniej elastyczności i prędkości, w osiągnięciu oczekiwanych korzyści pilota.

Ważne jest aby dobrze ustalić kryteria, na podstawie których będziemy oceniali, czy pilot zakończył się sukcesem i możemy wdrożyć usługę dla wszystkich użytkowników.

Odpowiednie przygotowanie i przetestowanie wydania, pozwala na jego sprawne przeprowadzenie na produkcji i zminimalizowanie niedostępności usług dla biznesu. Bardzo dużo zależy od pakietów instalacyjnych, które wykorzystywane są do wdrożenia wydania na produkcji, dlatego trzeba zwrócić szczególną uwagę, na ich przygotowanie. Najważniejsze aspekty to kompletność i instrukcje instalacji oraz poprawność przygotowanych paczek. Dobrze wykonana praca, zaowocuje krótszym czasem trwania wdrożenia i mniejszą ilością błędów, które podczas niego wystąpią. Warto poświęcić czas i energię w proces zarządzania wydaniem i wdrożeniami, aby zagwarantować sobie wysoki poziom usług na produkcji.

Pytanie: Jak często wdrażasz wydania na produkcję?

Artykuł Zarządzanie wydaniami i wdrożeniami pochodzi z serwisu Mariusz Siek.

Wielka majówka trwa, komu by się chciało czytać wpisy na blogu. Pomyślałem jednak, że mimo tego wolnego czasu, warto napisać coś, co jest interesujące. Temat lżejszy, bo i pogoda za oknem nas rozpieszcza i trudno skupić się na czymś siedząc, a właściwie stojąc przed komputerem. Wczoraj skończyłem czytać książkę „Śmiało” (angielski tytuł Bold) i chciałem na gorąco, nomen omen :-), podzielić się z Wam moimi wnioskami. Książkę polecił mi Michał Wawrzyniak vel Kołcz Majk, dzięki któremu została przetłumaczona na język polski. Jednego z autorów Petera Diamandisa znałem już wcześniej i wiedziałem, że warto zapoznać się z tym co ma do powiedzenia. Drugiego Stevena Kotlera, nie miałem okazji poznać ale uznałem, że dla Diamandisa, warto zapoznać się z tą pozycją.

Bądź otwarty

Autorzy pokazują w książce, jak zmienia się świat i to co jeszcze 20-30 lat temu, było możliwe dla państwa i dużych korporacji, teraz jest w zasięgu ręki każdego, kto ma pomysł, mocno w niego wierzy i jest w stanie poświęcić wiele, aby go zrealizować. Otwierają oczy i umysł, na zagadnienia śmiałej technologii, śmiałego myślenia i śmiałego tłumu. Pokazują konkretne przykłady i gotowe przepisy, jak skorzystać z doświadczeń, które zdobyli oni lub inne firmy, które podzieliły się z nimi tą wiedzą. Szybkość zachodzących zmian uświadamia, że żyjemy w szczególnym czasie, który daje ogromne możliwości i szanse. Wystarczy tylko je poznać i z nich skorzystać aby być śmiałym i zapisać się na kartach historii.

Śmiała technologia

W realizacji naszego śmiałego marzenia pomaga nam dzisiaj technologia. Rozwija się tak szybko, jak nigdy dotąd. Jej rozwój jest wykładniczy a nie liniowy, co w istotny sposób wpływa na zachodzące zmiany. Dzisiaj dzięki internetowi można, komunikować się z każdym na świecie i wykorzystywać rozwiązania, które nie były dostępne w poprzednim wieku. Diamandis wskazuje pięć obszarów, które mają największy wpływ:

• Oprogramowanie i dostęp do nieskończonej mocy obliczeniowej. Nie musisz być pracownikiem na uniwersytecie czy w dużej korporacji, aby móc skorzystać z super komputerów i nieograniczonej mocy obliczeniowej, która Ci jest potrzebna. Za pomocą oprogramowania, sam możesz stworzyć nowy produkt i wydrukować na drukarce 3D.
• Sztuczna inteligencja (AI). Zmieni nasze życie w ciągu najbliższych 5-10 lat, zmieniając również rynek pracy
• Drukarki 3D. Już niedługo będą wykorzystywane do masowej produkcji, która będzie mogła być spersonalizowana
• Roboty. Już wkrótce zastąpią na wielu stanowiskach człowieka. Może nie jak w filmie „Ja Robot” będą nosić za nami zakupy ale wchodzą bardzo szybko do ludzkiej rzeczywistości
• Genomika i biologia syntetyczna. Programowanie DNA może brzmieć niepokojąco ale jest faktem, który stanie się częścią naszego świata.

Śmiałe myślenie

Żeby realizować śmiałe pomysły i marzenia, nie można myśleć jak wszyscy i utartymi schematami. Nie uda się wynaleźć czegoś nowego i korzystnego dla ludzi na świecie, jeżeli nie zmienimy naszego myślenia. Nie jest to proces łatwy ale możliwy, jeżeli skorzystamy ze wskazówek zawartych w książce. Śmiałe myślenie wymaga specjalnego środowiska, odcięcia się od tego co znaliśmy do tej pory, odizolowania od otoczenia, które może mieć na nas negatywny wpływ. Jako przykład podana jest firma Google, i jej innowacyjne podejście. Ważne jest też aby osiągnąć i działać na swoim flow, wtedy w naturalny i łatwy sposób będziemy dążyć do naszych celów. W codziennym działaniu, pomagają również zasady, taki kodeks, którym się kierujemy aby osiągnąć swoje marzenia. Można poznać zasady Diamandisa. Autorzy pokazują również na przykładzie Elona Muska (Tesla, SpaceX), Richarda Bransona (Virgin), Jeffa Bezosa (Amazon) oraz Larego Paga (Google), jakie cechy powinien mieć przedsiębiorca myślący śmiało.

Śmiały tłum

Do realizacji śmiałych planów i marzeń potrzebni są ludzie. Nie uda się zrealizować żadnego przedsięwzięcia w pojedynkę. Również w tym przypadku, przychodzi nam z pomocą technologia i nowe rozwiązania takie jak crowdsourcing i crowdfounding.

• Crowdsourcing. Nigdy nie było łatwiej mieć dostęp do tysięcy specjalistów na całym świecie, którzy za niewielkie pieniądze, pomogą nam rozwiązać każde zagadnienia techniczne. Dzięki powstałym platformom internetowym, można skorzystać z programistów, matematyków, technologów i prawie każdej specjalności, aby zrealizować nasz pomysł.
• Crowdfounding. Nie masz pieniędzy na zrealizowanie swojego marzenia? Nic prostszego, zaangażuj ludzi aby pomogli Ci zebrać potrzebne fundusze i stali się Twoimi fanami i stworzyli Twoją społeczność. Poproś ludzi o pomoc a jeżeli twoje marzenie jest śmiałe, to na pewno Ci pomogą.

Jeżeli jeszcze Cię nie przekonałem do śmiałego działania i myślenia, przeczytaj książkę. Zresztą według mnie to lektura obowiązkowa dla każdego, kto chce zrealizować swoje marzenia oraz chce korzystać ze zdobyczy dzisiejszego świata, a nie być ich ofiarą. Książka, nie jest tylko teoretycznym wykładem ale zbiorem konkretnych reguł i zasad postępowania, które można wykorzystać i wcielać w życie. Pokazuje konkretne przepisy, które zostały sprawdzone przez Petera Diamandisa, podczas realizacji jego pomysłów. Bądź śmiały i zacznij działać, a na efekty nie trzeba będzie długo czekać.

Pytanie: Co robisz śmiało?

Artykuł Śmiało pochodzi z serwisu Mariusz Siek.

Napisałem już dwa artykuły o zarządzaniu zmianą, jednak cały czas mam nieodparte wrażenie, że nie wyczerpałem tematu. Po pierwsze dlatego, że proces jest bardzo złożony i może mieć kilka wariantów. Po drugie, jest jednym z ważniejszych procesów ITSM w każdej organizacji. Na co jeszcze warto zwrócić uwagę, co jest istotnym elementem, który decyduje, czy dobrze czy źle działa on u nas w firmie?

Rodzaje zmian

Mamy trzy rodzaje zmian, które możemy wprowadzać w organizacji: standardowa, pilna i normalna. Z każdą wiąże się inny sposób postępowania i inny jest cel jej zastosowania. Można powiedzieć, że dobieramy narzędzie do pracy jaką mamy wykonać.

• Zmiana standardowa stosowana jest w sytuacji niskiego ryzyka, powszechnie wykonywanych aktywności, dla których określone są procedury i instrukcje i jest wstępnie autoryzowana
• Zmiana pilna wykorzystywana jest, gdy musimy wprowadzić zmianę tak szybko jako to możliwe w celu rozwiązania krytycznego incydentu lub wdrożenia poprawki bezpieczeństwa
• Zmiana normalna obejmuje pozostałe przypadki, nie wskazane dla zmiany standardowej i pilnej.

Zmiana standardowa

Każda zmiana standardowa powinna korzystać z ustalonego modelu zmian, który określa jak z nią postępować, począwszy od tego, jak powinna być rejestrowana, przez sposób zarządzania po jak powinna być wdrażana.

Dla zmiany standardowej jej autoryzacja jest zdelegowana z menedżera zmian na inną rolę, np zarządzającego licencjami, service desk, dział zakupów itp.

Najważniejsze elementy związane ze zmianą standardową to:

• Ustalone zdarzenie wyzwalające zmianę takie jak service request lub wyjątek powstały w procesie zarządzania zdarzeniami
• Zadania są dobrze znane, udokumentowane i sprawdzone
• Autoryzacja zmiany jest z góry przekazana do innych ról
• Akceptacja finansowa jest z góry ustalona lub pod kontrolą wnioskującego o zmianę
• Ryzyko jest zwykle niskie i dobrze rozumiane

Jeżeli zmiana spełnia powyższe kryteria, może być wdrażana w tym trybie. Jest to duże ułatwienie i uproszczenie, dla wprowadzania znacznej ilości zmian. Sprawdź jak dużo zmian możesz wprowadzać w ten sposób i korzystaj z niego codziennie.

Zmiana pilna

Ten rodzaj zmiany powinien być wykorzystywany tylko w wyjątkowych sytuacjach. Głównie gdy usługa IT przestaje działać a sposobem na jej uruchomienie jest wprowadzenie zmiany. Mimo krótkiego czasu na procesowanie zmiany nie należy zapominać o:

• Uzyskaniu akceptacji zmiany przez radę ds. zmian pilnych (ECAB). Szczególnie taka zmiana wymaga akceptacji, odpowiednich osób, aby nie wprowadziła więcej i większych problemów, niż te które ma rozwiązać. Procedura dla zmiany pilnej musi jasno określać, kto podejmuje decyzje o wprowadzeniu tego rodzaju zmiany.
• Przetestowanie zmiany, przed wdrożeniem na produkcję. Mimo pośpiechu i chęci jak najszybszego przywrócenia usługi IT do działania, nie można pominąć kroku związanego z skutecznym sprawdzeniem, czy zaproponowane rozwiązanie jest prawidłowe i efektywnie rozwiąże awarię. Tylko w szczególnych przypadkach, można zdecydować o wdrożeniu zmiany, bez jej testowania. Powinna to jednak być świadoma i podjęta jednogłośnie decyzja.
• Ocenie wpływu zmiany w jednej usłudze na działanie pozostałych usług. Analizy wpływu musi być przeprowadzona i być podstawą do podjęcia decyzji o akceptacji zmiany.

Zmiana normalna jest nudna, dlatego nie będę się o niej się rozpisywał :-). Chciałem jednak zwrócić uwagę na jeden element, który powinien występować, dla każdej z rodzajów zmian.

Plan wycofania

Plan wycofania to bardzo ważny element dla wprowadzania zmian. Zawsze może coś pójść nie tak i musimy mieć plan postępowania na tę okoliczność. Wiem, że większość zespołów zakłada, że wszystko pójdzie dobrze i po co tracić czas na przygotowywanie planu wycofania. Jak jednak pokazuje życie, może zdarzyć się taka sytuacja i musimy być na nią przygotowani. Pamiętajmy, że plan wycofania powinien być przetestowany i uwzględniony w czasie trwania zmiany, a tym samym niedostępności usługi. Plan wycofania musimy mieć opracowany i przetestowany, zarówno dla zmiany normalnej jak i pilnej. W przypadku zmiany standardowej, możemy mieć go uwzględnionego w procedurze lub instrukcji, na podstawie której wykonywana jest zmiana.

Miałem świadomość, że proces zarządzania zmianą jest obszerny ale nie sądziłem, że pokazania jego najważniejszych elementów jest tak trudne w kilku artykułach. Wygląda na to, że będę musiał jeszcze pociągnąć ten temat w kolejnym tygodniu.

Podsumowując. Korzystaj ze wszystkich rodzajów zmian a zwiększysz sprawność swojej organizacji w zarządzaniu zmianami. Nie zapomina tylko, że każda zmian musi być zaakceptowana (autoryzowana), przetestowana i mieć plan wycofania.

Pytanie: Które rodzaje zmian najczęściej stosujesz i dlaczego?

Artykuł O czym zapomniałeś zarządzając zmianą? pochodzi z serwisu Mariusz Siek.

Tak jak obiecałem w jednym z poprzednich wpisów, dzisiaj recenzja książki. Kupiłem tą książkę aby dowiedzieć się coś o DevOps. W podtytule było napisane „Powieść o IT, modelu DevOps i o tym jak pomóc firmie w odniesieniu sukcesu”. Trzej autorzy Gene Kim, Kevin Behr i George Spafford, są liderami ruchu DevOps, tak przynajmniej jest napisane na odwrocie książki. „Projekt Feniks”, bo o tej książce piszę wciągnęła mnie od początku. Wyobraziłem sobie, że to moja historia i mogłaby zdarzyć się w moim życiu :-). Czy dowiedziałem się coś o DevOps? Przeczytajcie sami :-).

Fabuła

Książka „Projekt Feniks” opisuje losy firmy Parts Unlimited (PU), produkującej części do samochodów, gdzieś w USA. Poznajemy jej historię z perspektywy działu IT, gdy nie wiedzie się jej zbytnio. Główny bohater Bill Palmer zostaje poproszony o zajęcie stanowiska wiceprezesa ds. eksploatacji systemów informatycznych w PU, po zwolnieniu CIO i jego poprzednika. Tak naprawdę to nie jest prośba tylko ultimatum i nasz bohater nie ma innego wyjścia, jak podjąć się tego, wyglądającego na samobójcze, zadania. Bill ma wieloletnie doświadczenie w firmie, jest rozsądnie myślącym i zrównoważonym człowiekiem. Od początku spadają na niego wszystkie możliwe kataklizmy i musi radzić sobie z trupami w szafie, zostawionymi przez poprzedników. Trzeźwo jednak podchodzi do napotykanych trudności i odważnie stawia im czoła.

Ponieważ akcja dzieje się głównie w dziale IT, jest mi bliska, bo to moja działka. Dodatkowo opisywane sytuacje, pasują do tych doświadczanych przeze mnie, w trakcie mojej pracy zawodowej. Niektóre są tak podobne do tych, które miałem okazję obserwować lub w nich uczestniczyć, że aż nieprawdopodobne :-).

Nie zdradzam szczegółów abyście mieli większą przyjemność z czytania książki.

Dla kogo?

Chociaż książka koncentruje się głównie na historii Billa i patrzymy na Parts Unlimited oczami IT, to według mnie książkę powinni przeczytać wszyscy z działów biznesowych, którzy współpracują lub zależą w jakimś stopniu od IT. Czyli obecnie wszyscy, bo nie wyobrażam sobie biznesu, który funkcjonuje bez wsparcia i pomocy rozwiązań IT. Dlaczego? Bo pokazuje, jak ważna jest współpraca pomiędzy biznesem i IT i nie stosowanie kultury obwiniania. Widzimy że IT daje realną wartość dla biznesu a nie jest tylko dostawcą i wsparciem dla świadczonych usług.

Nie muszę mówić, że dla osób z IT jest to lektura obowiązkowa. Pozwala lepiej zrozumieć jak ważne jest wspólne działanie, nie tylko podczas „gaszenia pożarów” ale w codziennej pracy.

Lekcja

„Projekt Feniks” to również lekcja jak kierować i zarządzać organizacją IT i nie tylko. Uczymy się razem z Billem, który odkrywa nowe zagadnienia i obszary. Nie jest w tym poszukiwaniu osamotniony. Ma mentora w osobie Erika, kandydata na członka rady nadzorczej. Na podstawie fabryki produkującej części samochodowe, Erik uczy Billa, jak zarządzać organizacją IT. Wbrew temu co mogłoby się wydać analogii i podobieństwa jest bardzo dużo. Poznajemy cztery rodzaje pracy w IT, trzy drogi i wiele pożytecznych informacji w planowaniu i wykonywaniu pracy. Jak likwidować wąskie gardła i uniezależnić się od jednego super specjalisty, który całą wiedzę ma w swojej głowie, a bez niego nie można rozwiązać trudnych problemów lub wykonać skomplikowanych zadań. Bardzo dużo interesującej wiedzy, którą można zastosować w swojej organizacji.

DevOps

Jak dla mnie trochę za mało jest o DevOps, chyba że nadal nie wiem, co się kryje pod tym skrótem. W trzeciej części książki pokazana jest bardzo bliska współpraca programistów, testerów i zespołu utrzymania (eksploatacji) w wytworzeniu rozwiązania dla marketingu o nazwie „Jednorożec”. Erik stawia wyzwanie aby robić wdrożenia dziesięć razy dziennie. Dla wszystkich wydaje się to niemożliwe ale postanawiają, że zobaczą co można zrobić. Automatyzują testy, przygotowują środowiska testowe, tak jakby było to oprogramowanie. Na początku udaje im się zmniejszyć czas pomiędzy wdrożeniami z 3 miesięcy do 1 tygodnia a następnie do jednego dnia. Co ciekawe, tak wytworzone i zweryfikowane rozwiązanie odnosi spektakularny sukces, po tylko jednym miesiącu pracy. To chyba jest DevOps, przynajmniej w jakimś stopniu. Po dalszą wiedzę, muszę sięgnąć do innej książki.

Chociaż nie jest to kryminał ani thriller, akcja toczy się wartko i wciąga. Jesteś ciekawy co zrobi Bill, jak się potoczą kolejne wątki. Co nowego powie tajemniczy Erik. Czy wszystko zakończy się sukcesem czy spektakularną porażką. Jeżeli chcesz się dowiedzieć zachęcam do przeczytania tej pozycji, nie tylko nerdów z IT ale również lisów z biznesu.

Pytanie: Co rozumiesz pod określeniem DevOps?

Artykuł Projekt Feniks pochodzi z serwisu Mariusz Siek.

Tak jak obiecałem, poruszam temat zarządzania zmianą IT. Jest to jeden z najważniejszych i kluczowych procesów w zarządzaniu usługami IT, który ma wpływ na pozostałe. Od jakości funkcjonowania procesu zarządzania zmianą IT zależy, jaka będzie dostępność usług, czy IT będzie spełniało oczekiwania biznesu, na wprowadzanie wymaganych zmian, jak będziemy dbali o bezpieczeństwo informatyczne. Zarządzanie zmianą jest postrzegane w organizacji, jako biurokracja i zbędny nakład pracy. Czy takie opinie są słuszne i właściwie oceniają rolę procesu? Przyjrzyjmy się najważniejszym zagadnieniom w procesie zarządzania zmianą aby rozwiać powstające wątpliwości.

Źródła zmian

Generalnie możemy wskazać dwa źródła zmian:

• Pierwsze wynikające z działań biznesowych mających na celu wdrażanie nowych usług lub usprawnianie już istniejących. Nazywane bywa również proaktywnym.
• Drugie wynika z obsługi incydentów i problemów i nazywane bywa reaktywanym.

Mamy tu pewną analogię do procesu zarządzania problemami i podobieństwo w podejściu.

Dla kogo proces zarządzania zmianą?

Proces zarządzania zmianą można zastosować w każdej organizacji. Może on być bardzo złożony albo bardzo prosty. Znajdzie swoją implementację w różnej wielkości i rodzaju organizacji. Można z niego skorzystać wprowadzając małe i duże zmiany, na każdym etapie cyklu życia usługi. Nie ma znaczenie czy zmiana ma duży czy mały wpływ oraz jak jest planowana. Można go zastosować do zmian o różnym budżecie i poziomie finansowania. Jednym słowem proces zarządzania zmianą można zastosować wszędzie.

Cele i oczekiwania

Celem procesu zarządzania zmianą jest nadzorowanie cyklu życia wszystkich zmian, w celu umożliwienia wdrożenia korzystnych zmian, z jak najmniejszym zagrożeniem dla działania produkcyjnych usług IT. Dobrze wdrożony i funkcjonujący proces zarządzania zmian powinien:

• Odpowiadać na zmieniające się wymagania biznesu, poprzez zwiększanie wartości oraz zmniejszanie incydentów, zagrożeń i dodatkowej pracy
• Odpowiadać na żądania zmian z biznesu i IT, które będą spełniały potrzeby biznesu
• Zapewniać, że zmiany są rejestrowane i oceniane, a zatwierdzone zmiany mają określany priorytet i są planowane, testowane, wdrażane, dokumentowane i przeglądane w kontrolowany sposób.
• Zapewniać, że wszystkie zmiany do elementów konfiguracji są rejestrowane w systemie zarządzania konfiguracją (Configuration Management System – CMS)
• Dążyć do optymalizacji całego ryzyka biznesowego, zarówno go minimalizując jak i akceptując, jeżeli daje szansę na korzyści dla biznesu

Zakres

Informację o zakresie zacznijmy od definicji zmiany według ITIL

„Dodanie, modyfikacja lub usunięcie dowolnego elementu konfiguracji, który może mieć wpływ na działanie usługi IT”.

Szczerze mówiąc bardziej podoba mi się definicja z książki „Projekt Feniks”.

„Dowolna fizyczna, logiczna lub wirtualna operacja dotycząca aplikacji, baz danych, systemów operacyjnych, sieci oraz sprzętu, która może wpływać na świadczenie usług”

Zmiany mogą dotyczyć wszystkich elementów konfiguracji w całym ich cyklu życia, takich jak:

• zasoby fizyczna jak serwery, macierze, przełączniki, routery itp.
• zasoby wirtualne jak serwery wirtualne lub macierze wirtualne
• zasoby informacyjne jak umowy i porozumienia, w tym katalog usług, SLA itp.

Zarządzanie zmianą. Dotyczy wszystkich zmian związanych z pięcioma aspektami projektowania usług:

• Rozwiązania dla nowych lub zmienianych usług, zawierające wymagania biznesowe
• Narzędzia i systemy do zarządzania informacją oraz zarządzania i kontroli usług w ich cyklu życia
• Architektura w zakresie technologii i zarządzania, wymagana do dostarczenia usługi
• Procesy potrzebne do zaprojektowania, wdrożenia, działania i poprawy usługi
• Systemy, metody i metryki pomiarowe dla usług, architektury, komponentów i procesów

Poza procesem zarządzania zmianą są zmiany związane z:

• Znacznie większym wpływem niż zmiana usługi, np zmiana struktury organizacyjnej
• Zmianami na poziomie operacyjnym np. naprawa drukarki lub innych standardowych komponentów

Zarządzanie zmianą nie odpowiada za koordynowanie wszystkich procesów zarządzania usługami IT, mające na celu bezproblemowe wdrożenie projektu. Te aktywności są przeprowadzane przez proces planowania i wsparcia wdrożenia.

Korzyści dla biznesu

Proces zarządzania zmianą daje wymierne korzyści.

• Ochrona biznesu i innych działających usług, podczas wprowadzania zmian
• Wdrażanie zmian, które spełniają uzgodnione wymagania klienta i są optymalne kosztowo
• Zmniejszenie nieudanych zmian, a dzięki temu zakłócenia działania usług
• Zmniejszenie nieautoryzowanych zmian, a w konsekwencji zakłócenia działania usług oraz czasu obsługi incydentów
• Bezzwłoczne dostarczanie zmian zgodnie z wymaganiami biznesu
• Śledzenie zmian przez cały czas życia usługi
• Przyczynianie się do lepszego szacowania jakości, czasu i kosztu zmiany
• Ocena ryzyk związanych z wdrożeniem usługi
• Zwiększenie produktywności pracowników poprzez zmniejszenie nieplanowanych i pilnych zmian, co przekłada się na większą dostępność usług
• Zmniejszenie MTRS (średniego czasu odzyskiwania usługi) poprzez szybsze i bardziej skuteczne wdrażanie działań naprawczych
• Współpraca z procesem zarządzania zmianą biznesową w celu identyfikowania możliwości usprawnienia biznesu

Zmiana, RFC, rekord zmiany

Bardzo często pojęcie zmiany, RFC (Request for Change) i rekordu zmiany traktowane są jako tożsame. Tak jednak nie jest. Zmiana określona jest poprzez definicję w punkcie Zakres. RFC to formalna propozycja zmiany, zawierająca szczegółowe informacje związane ze zmianą. Rekord zmiany zawiera wszystkie szczegółowe informacje związane ze zmianą, w tym dokumentuje cykl życia zmiany. Nie mylmy więc tych trzech pojęć ponieważ oznaczają coś innego.

Proces zarządzania zmianą, powinien być oczywiście wspierany przez narzędzie (narzędzia), które pozwolą na wystawianie RFC i procesowanie zmiany w trakcie jej cyklu życia. Dobrze aby proces był zintegrowany z CMDB a najlepiej z CMS aby można było oceniać wpływ zmiany na elementy konfiguracji i działające usługi oraz zasięgać informacji o usługach IT i ich parametrach SLA.

Pytanie: Jakie zmiany wprowadzasz najczęściej?

Artykuł Zarządzanie zmianą IT – proces pochodzi z serwisu Mariusz Siek.