Świadomość ITIL-a

Wczoraj uczestniczyłem w prezentacji ITIL-a zorganizowanej przez krakowski SPIN (reklamowała to inicjatywa ITwKrakowie). Wystąpił Pan Ireneusz Górniok współpracujący z CTPartners. Oprócz wyjaśnienia istoty ITIL-a (z dowcipnym odniesieniem geograficznym) usłyszałem dlaczego należy stosować ITIL (a właściwie ITSM). Otóż jak stwierdził prelegent "po co wymyślać koło?". W tym miejscu całkowicie się z nim zgodzę - przeczytanie nawet skróconego opisu procesów ułatwia menedżerowi IT zarządzanie infrastrukturą - wszystko jakby staje się naturalne i oczywiste. Jest jeszcze drugi powód - również wspomniany w prezentacji: pieniądze. Dzięki ITIL-owi menedżerowi IT łatwiej jest sprzedać swoje usługi, względnie uzasadnić wydatki na sprzęt i oprogramowanie. Mało tego - dzięki podejściu usługowemu studzi się szkodliwe emocje pod tytułem: "kupimy nowy serwer, od razu się poprawi" - usługa wymaga zaplanowania, wdrożenia i ustabilizowania się w utrzymaniu... Przejście infrastruktura-usługa jest analogiczna jak aplikacja-projekt. Biznes zaakceptował już potrzebę istnienia projektów, zaakceptuje więc istnienie usług.

Pytałem Pana Ireneusza czy spotkał się z praktyką, że Dział Programistyczny (Developmentu) wdraża usługę? Nie potrafił podać takiego przykładu. I tu moim zdaniem tkwi sedno kłopotów z wprowadzaniem ITIL-a. Dopóki cały dział IT nie zacznie myśleć usługowo nie będzie pełnego sukcesu z wprowadzenia zarządzania usługami. Trzeba w tym miejscu zaznaczyć, że zmiana świadomości developerów jest trudna, choć możliwa i konieczna. Analogiczne opory mentalne mają administratorzy przy zaakceptowaniu wagi projektów i zarządzania projektami.

Jak jednak zmienić świadomość całego działu IT? Po pierwsze nie rozdzielać Project Management od Service Management. Sprytny menedżer infrastruktury IT powie tak: "OK będziemy wspierać projekty z ponadprzeciętnym zaangażowaniem, ale jest jeden warunek: to muszą być projekty usług!" Po drugie zamieniać się rolami - niech programista trochę posiedzi w Service Desku, a administrator niech poużera się z biznesem przy projektach...

Na koniec podam kilka wartościowych linków, które udostępnił Pan Ireneusz:

• sporo materiałów na blogu dot. ITSM
• kolejna społeczność ITIL-owców
• o ITIL-u w formie Wiki

10 warunków na udane wprowadzenie ITIL

Polecam dobry tekst! Hank Marquis opisuje jakie cechy powinna mieć organizacja, która z sukcesem wprowadzić ITIL (lub ITSM):

1. Cała organizacja IT musi zaangażować się we wprowadzanie ITIL-a, a nie tylko Dział Infrastruktury, Operacji czy jak go tam zwał (analogicznie ma się rzecz z metodyką projektową)
2. Wprowadzenie ITIL-a to sprawa IT, a nie biznesu, tak jak inwestujemy w sprzęt, aby lepiej działało, w kompetencje pracowników tak należy zainwestować w organizację pracy!
3. Bez zgody najwyższego kierownictwa i zaangażowania większości menedżerów ani rusz
4. Dobra rada dla konsultantów: wprowadzenie ITIL-a trzeba zaplanować z uwagą na "quick wins" - biznes i Top Management musi szybko widzieć pozytywne rezultaty, z czasem można rzadziej planować "quick wins", jeśli zwiększy się cierpliwość w/w
5. Wprowadzenie ITIL-a to program trwający 1-3 lat, trzeba podzielić zagadnienie na krótkie projekty, które ewolucyjnie przekształcają organizację. Rewolucja zajdzie w sposobie myślenia, rozmawiania i zarządzania.
6. ITIL wymusza myślenie procesowe: role i przepływy.
7. ITIL wymaga ciągłego usprawniania, a więc podejścia jakościowego (CSIP, PMF, QMS, kaizen)
8. Wprowadzenie ITIL-a musi podlegać rygorom Project Managementu, z wszystkimi tego konsekwencjami - budżet, czas, efekty.
9. Największym ryzykiem jest niechęć pracowników do zmian. Jak tego uniknąć - osobiście ich zaangażować w poprawę.
10. ITIL-a nie zrobią za organizację doradcy, trenerzy czy sprzedawcy oprogramowania. ITIL-a kierownictwo musi chcieć ("change desire") i włożyć niemały wysiłek w naukę, zmianę i jej utrwalenie. Doradcy, trenerzy jedynie pomagają w konkretnych trudniejszych kwestiach z uwagi na ich doświadczenie oraz moderują nasze wysiłki, aby nie wejść w przysłowiowe "maliny".

Ja bym to skrócił do następujących kwestii:

1. Właściwe nastawienie kierownictwa (#1, #3, #9, #10)
2. Odpowiednie podejście (#4, #5, #8)
3. Adekwatne cele (#6, #7, #2)
   

Lektura na wolne wieczory (o ile jeszcze istnieją;))

Dziś wpadł mi w oko króciutki artykuł o obowiązkowych lekturach dla menedżera. Ja wybrałbym trzy:

• "The 7 Habits of Highly Effective People" by Stephen Covey, about improving your (working) life
• "To do, Doing, Done" by G. Lynne Snead and Joyce Wycoff, on project management and organization
• "Managing in turbulent times" by Peter F. Drucker

ITIL dla MŚP

Dziś jeszcze coś dla MŚP. Malcolm Wheatley przytacza 3 przypadki wprowadzenia ITIL do małych organizacji IT (6, 10 i 43 osobowych). Najważniejsze według niego to zacząć od procesu, który nam najbardziej doskwiera (może to być Change Management, którego brak może powodować do 80% incydentów). W większości przypadku jest to jednak Incident Management, dalej wybiera się kolejne procesy i praktyki, ale zawsze wedle klucza "które nam pasują", czyli ITIL-owe "adopt and adapt". Niecierpliwym trzeba przypomnieć, że ITIL to nie jednorazowa akcja, ale ciągłe doskonalenie działalności małymi krokami (kaizen!). Sama "zgodność" z ITIL, czy certyfikacja ISO jest sprawą przydatną, ale niekonieczną.

The four big questions ITIL

Dziś przyglądnę się "czterem wielkim pytaniom ITIL" Roba Englanda.

Pierwsze pytanie: "Should We do ITIL?", czyli po polsku Czy powinniśmy zajmować się ITIL-em?.
Z punktu widzenia społeczności ITIL odpowiedź jest oczywista: Tak, w końcu to uznane praktyki, a po za tym napędzi to nam biznes... . Jeśli jednak przypomnimy sobie, że ITIL to tylko jeden ze schematów zarządzania usługami (ITSM), odpowiedź już nie jest taka prosta: Być może, ale na pewno powinniśmy robić zarządzanie usługami. Kwestia wyboru schematu zarządzania to temat na co najmniej pracę magisterską, jeśli nie doktorat, punkty startowe znajdziemy u Roba i tu.

Drugie pytanie: "To what level should we do it?".
Załóżmy, że chcemy robić ITSM i wybraliśmy ITIL. To w końcu kilkanaście tomów dobrych praktyk? Wszystko zaimplementować? Myślę, że powinniśmy się tu kierować racjami ekonomicznym: wprowadzanie praktyk ITIL to swego rodzaju inwestycja w organizację - musi się zwrócić. Jeśli zyski z wymyślenia, przećwiczenia i sformalizowania pewnych procedur są niezauważalne (n.p. bo Availability Request występuje raz na miesiąc) to po co się wysilać? Tylko po to, aby nakleić nalepkę "100% ITIL compliant!".

Trzecie pytanie: "How do you do it?"
Zanim jednak odpowiem na pytanie trzeba się zastanowić co będziemy "robić". Czy ITSM czy ITIL? Jeśli ITSM - to moim zdaniem sprawa jest prosta - trzeba "jedynie" dopasować IT do biznesu, a więc:
1) "przemalowujemy" tak interfejsy systemów IT, aby użytkownik widział "Service Architecture", a nie Configuration Items,
2) wprowadzamy User Friendly Service Support, a więc Service Desk (jako SPOC - Single Point of Contact), a zgłoszenia obsługujemy wedle Service Catalogue,
3) wprowadzamy Service Delivery i Level Agreements (SLA/OLA) najlepiej poprzez specjalnego "oficera łącznikowego biznes-IT",
4) wprowadzamy Service Development i Decommisioning, aby się samo kręciło.
Jeśli zaś chcemy "zrobić" ITIL - sprawa jest trudniejsza: trzeba skonstruować coś w rodzaju mapy implementacji procesów i żmudnie krok po kroku zgodnie z cyklem Deminga planować, wypróbowywać, weryfikować i formalizować. Niestety sprawa wydaje się być niekończącą się opowieścią, gdyż biblioteka puchnie, praktyk przybywa, a proces wprowadzania praktyk jest nader uciążliwy i wolny.

Czwarte pytanie: "How do we show we did it?"
Analogicznie do trzeciego pytania w przypadku ITSM sprawa jest prosta - pokazujemy Architekturę Usług (Service Architecture), Katalog Usług (Service Catalogue). Potem oprowadzamy po Stanowisku Obsługi Zgłoszeń (Service Desk) i przedstawiamy osobę odpowiedzialną za kontakty biznes-IT, która pokazuje Uzgodnienia poziomu usług (Level Agreements). Na koniec jeszcze możemy pokazać metodykę wdrażania usług i ich wycofywania.
W przypadku ITIL-a będzie trudniej - trzeba omawiać proces po procesie i uważać, żeby ktoś nie powiedział "to jest niezgodnie z biblioteką, patrz strona XX, wers YY, książka ZZ" :(.

Zapoznałem się pobieżnie ze standardem ISO 20000. I jakie wnioski?
Odradzam kupowanie obu standardów (przeszło 160 zł). Moim zdaniem w zupełności wystarczy przeczytanie (20% ceny - 12 zł) w serwisie eNormy części pierwszej (ISO/IEC 20000-1:2007). Jest to specyfikacja, a więc to co potencjalnie będą wymagać audytorzy. Można też zapoznać się z prezentacją audytora wiodącego ten normy, Pana Marcina Majdeckiego z DNV. Wartościowe są też komentarze "dyżurnego sceptyka IT", Roba Englanda.
Norma na pierwszy rzut oka wydaje się być mocno niedopracowana. Tłumaczenie jest miejscami dziwaczne, można porównać ze świetnym słownikiem ITIL opracowanym przez itSMF Polska. Ponadto część 2 ma stanowić rozwinięcie części 1 o dobre praktyki, ale jakoś obie części nie przystają do siebie (na przykład część o systemie zarządzania). Spaprany został opis cyklu Deminga - o ile wyjaśnienie trzech pierwszych literek (PDC) ma sens, o tyle A (ang. Act) jest określone jako "ciągłe doskonalenie (działaj)". Tymczasem w oryginalnej koncepcji Deminga A oznaczało "Zastosuj" w sensie ustawodawczym (notabene angielskie ustawy nazywają się właśnie "Act"). Właściwe znaczenie całkowicie się zagubiło. Na usprawiedliwienie twórców normy można podać przykład książki OGC "Introduction to ITIL", gdzie Act znaczy tyle co "adjust plan" i też nie mogłem tego zrozumieć.
Ponadto widać znaczące uproszczenia w stosunku do ITIL (na przykład w rozdziale dotyczącym incydentów klient (!) zgłasza incydenty, żądania usługi oraz dostaje powiadomienia o obniżeniu poziomu usług). Jest to jednak zrozumiałe - trudno byłoby zestandaryzować cały zasób wiedzy ITIL - taka norma byłaby zupełnie nieużyteczna.
Mimo wszystko uważam, że pierwsza część (ISO/IEC 20000-1:2007) powinna być obowiązkową lekturą dla każdego ITSM-owca (ITIL-owca ;)). Wprowadza pewien punkt odniesienia co do tego, co znaczy "wdrożyć zarządzanie usługami". Przeczytam i z niecierpliwością będę czekał na wersję poprawioną.
A tak zupełnie na marginesie to przyszedł mi pomysł na nowy temat do analizy: czym jest tak naprawdę ITIL, ITSM, ISO 20000?

PS. Dla fanatyków jest fachowe porównanie normy i biblioteki, jak również draft 3-ciej części normy. Zabawne: wczoraj draft o numerze N3934 jeszcze był w sieci, a dziś już nie mogę go znaleźć. Dobrze, że mam kopię w PDF...