Siedem krótkich pytań pomoże ocenić ryzyko związane ze zmianami oraz oszacować efektywność procesu zarządzania zmianami.
Wielu menedżerów usług informatycznych oraz osób stosujących zasady ITIL z niecierpliwością wypatruje ukazania się książki "Business Perspective Volume II", która jest długo oczekiwaną kontynuacją "Business Perspective: the IS View on Delivering Services to the Business". Są ciekawi, jakie korzyści im ona przyniesie, licząc na to, że nie będzie to jedynie zwykłe przypomnienie dobrze znanych zasad, na których opiera się proces wsparcia i dostarczania usług informatycznych.

Nie będą rozczarowani.
Szeroko rozpowszechnione i dobrze zilustrowane książki poświęcone wsparciu i dostarczaniu usług informatycznych stanowią do dziś podstawę biblioteki ITIL. Jednak publikacja "Business Perspective Volume II" ze swoją wnikliwą analizą kwestii biznesowych jest kompendium wiedzy, zwłaszcza dla wyższej kadry kierowniczej, która szuka pomocy w tak złożonych zagadnieniach, jak ład informatyczny, struktura organizacyjna i zarządzanie strategiczne.

Szczególnie cenna jest lista kontrolna w rozdziale dotyczącym ciągłości biznesu. Można z powodzeniem z niej korzystać przy ocenie ryzyka związanego ze zmianami oraz szacowania efektywności procesu zarządzania zmianami. Lista zawiera siedem prostych pytań. Każde przedsiębiorstwo, które ich sobie nie zadaje, a w konsekwencji nie odpowiada na nie, narażone jest na podwyższone ryzyko, jakie niosą ze sobą zmiany, co niekorzystnie wpływa na poziom świadczonych usług informatycznych.

To ryzyko może być istotne, zwłaszcza na współczesnym rynku informatycznym, który stawia codziennie nowe wyzwania biznesowe. Kto nie wypracuje efektywnych procesów zarządzania zmianami, może stanąć przed koniecznością częstych przerw w wykonywaniu usług, a jest to coś, czego odbiorcy nie tolerują. Dlatego właśnie nowe analizy zawarte w książce "Business Perspective Volume II" są tak pomocne dla osób, których celem jest zapewnienie niezawodnych i elastycznych cenowo usług informatycznych.

Pytania, które zdaniem autorów powinna zadać sobie każda firma informatyczna, są następujące:

1. Kto zgłosił zmianę?
Brzmi prosto, jednak bez odpowiedzi na to pytanie nie można mieć pewności, czy zmiana była uprawniona. Nieuprawnione zmiany są zmorą informatyki. Biorąc pod uwagę istnienie wielu punktów dostępu, zainteresowanych osób i piętrzenie się źródeł zmian, trudno się dziwić, że to zjawisko sprawia tyle problemów. Jednym ze sposobów rozwiązania problemu uprawnień jest rozwój systemu centralnego zapisu zmian. Taki system musi być wyposażony w metody kontroli wykrywające zmiany obejmujące różne obszary funkcjonalne. Pojedynczy system zapisu jest szczególnie przydatny podczas audytów.

2. Jaka jest przyczyna zmiany?
Kto nie zna odpowiedzi na to pytanie, nie będzie w stanie uniknąć zmian, które niosą ze sobą ryzyko, ale nie przynoszą żadnych korzyści biznesowych.
W praktyce bez procesu oceny odpowiedzi na to pytanie strategiczne innowacje mogą być zepchnięte na boczny tor przez natłok zmian taktycznych, zwłaszcza że 75% budżetu przeznaczonego na informatykę pochłania utrzymanie istniejącej infrastruktury. Bez względu na jej rodzaj każda duża zmiana powinna podlegać ocenie i być zatwierdzana na podstawie wielu kryteriów analizy. Taka ocena zapewni nadanie zmianom odpowiednich priorytetów i wykryje większość potencjalnie błędnych decyzji, zanim pochłoną one zasoby informatyczne.

3. Jaki efekt powinna przynieść zmiana?
Niezwykle ważną sprawą jest zrozumienie przyszłych efektów zmiany, zwłaszcza rentowności finansowej, co umożliwi określenie priorytetów zmian strategicznych i związanych z projektami. Niemniej jednak, choć w ITIL przy rozpoczęciu procesu zarządzania zmianami znane są dwa zagadnienia (problemy i innowacje), nie ma zbyt wielu wskazówek, w jaki sposób regulować innowacje. Zarządzanie finansowe ITIL dla usług informatycznych może dostarczyć wielu użytecznych informacji odnoszących się do kosztów. Wymagają one jednak uzupełnienia miarami wartości, aby można było obiektywnie wyznaczyć aspekt finansowy zmiany.

4. Jakie ryzyko niesie ze sobą zmiana?
Każda zmiana wiąże się z pewnym ryzykiem. Pytanie, jak duże jest to ryzyko. Pewnych rodzajów ryzyka można uniknąć, inne zmniejszyć, pozostałe trzeba zaakceptować. Należy zrobić wszystko, aby ocenić potencjalny wpływ zmiany na infrastrukturę. Należy także opracować strategię rezerwową, jeśli stanie się najgorsze. Konieczne jest również określenie ryzyka związanego z niewykonaniem zmiany. Koncepcję "istotności", funkcjonującą w bibliotece ITIL, stosuje się zarówno wobec potencjalnego ryzyka, jak i rzeczywistych problemów. Jakie są najlepsze i najgorsze scenariusze w sytuacji, gdy sprawy nie ułożą się zgodnie z naszymi oczekiwaniami? Nikt nie jest jasnowidzem, warto jednak starać się przewidzieć jak najwięcej przed wykonaniem zmiany.

5. Jakie zasoby są niezbędne do przeprowadzenia zmiany?
Przez pojęcie zasobów rozumiemy zarówno ludzi, jak i sprzęt informatyczny.
Odnośnie do ludzi muszą istnieć mechanizmy oceny umiejętności potrzebnych do wdrożenia zmiany oraz czy dane osoby takie umiejętności posiadają. Podobna analiza dotyczy sprzętu. Należy sobie postawić pytanie, jaka infrastruktura jest potrzebna do przeprowadzenia zmiany oraz czy jest ona dostępna? Musimy także wziąć pod uwagę wpływ innych projektów. Jeśli do obsługi zmiany zostaną przydzieleni ludzie i sprzęt, to jaki będzie wpływ tej sytuacji - w aspekcie czasu i kosztów - na inne wykonywane projekty?

6. Kto jest odpowiedzialny za tworzenie, testowanie i wdrożenie zmiany?
Wszystkie osoby zarządzające rozwojem aplikacji muszą znać odpowiedź na to pytanie. Niezbędny jest odpowiedni podział odpowiedzialności za te zadania, zwłaszcza w świetle wymagań zgodności z normami i audytów. Podział odpowiedzialności nie powinien być jednak ograniczony wyłącznie do rozwoju aplikacji. Musi być rozpoznawalny, egzekwowalny i wykonalny w całym procesie zarządzania zmianami, od zgłoszenia zmiany do jej wdrożenia.

7. Jaki jest związek pomiędzy tą zmianą i innymi?
Przy tak wielu zmianach zachodzących równolegle we współczesnych, złożonych środowiskach informatycznych odpowiedź na to pytanie może nie być łatwa. Związki między zmianami należy określić wewnątrz i pomiędzy różnymi obszarami funkcjonalnymi. Brak takiej oceny może doprowadzić do przedłużenia okresu planowanego przestoju, np. z powodu niepoprawnej lub niezoptymalizowanej kolejności wykonywania zmian. Pomóc może tu opracowanie wspólnego harmonogramu planowanych zmian, a także analiza wpływu zmian i mapowanie ich powiązań za pomocą zintegrowanej bazy danych zarządzania konfiguracją (Configuration Management Database - CMDB)

Określenie odpowiedzi na wszystkie te pytania zapewnia liczne korzyści. Po pierwsze, daje przedsiębiorstwom możliwość zastosowania wielu miar umożliwiających bardziej obiektywną ocenę ryzyka związanego ze zmianą, co stanowi duży krok w kierunku zwiększenia niezawodności i dostępności usług dla klientów. Po drugie, te pytania stanowią doskonałą metodę oceny stopnia zgodności procesów zarządzania z obecnymi wymaganiami, a także identyfikacji braków, które można uzupełnić dzięki automatyzacji procedur i zastosowaniu nowoczesnych technik.

Wdrożenie i konsekwentne stosowanie audytowalnego systemu zarządzania zmianami jest obecnie niezwykle ważne, ponieważ firmy są w dużym stopniu uzależnione od usług informatycznych i nowych regulacji prawnych. Stawiając sobie te siedem prostych, choć często wymagających pytań, firmy informatyczne są w stanie osiągnąć wysoki poziom dyscypliny wprowadzania zmian.

Brian Johnson i Peter Waterhouse
Brian Johnson pracuje jako światowy menedżer ITIL w firmie CA i był członkiem powołanego przez rząd brytyjski zespołu opracowującego strukturę biblioteki ITIL Jest współautorem książki Business Perspective Volume II.

Peter Waterhouse jest dyrektorem ds. korporacyjnego zarządzania zasobami informatycznymi i rozwiązaniami marketingowymi w firmie CA. Posiada 15-letnie doświadczenie w dziedzinie zarządzania systemami korporacyjnymi, specjalizując się w zarządzaniu IT i opracowywaniu dobrych praktyk.