Blog o zarządzaniu IT

Pojeździłem ostatnio po kraju. Od spotkania do spotkania. Od warsztatu do warsztatu. A w większości to spotkania w firmach, które tematy ITSM “popychają” od jakiegoś czasu, ale na pewno ponad 12 miesięcy. Podchodzą do usługowości i procesów ITSM różnie, mają różne możliwości, branże i budżety. Są jednak pewne elementy wspólne, o których warto napisać, a które razem przyczyniają się do wzrostu abstrakcyjnej wartości jaką jest dojrzałość. Jak rozpoznać wysoką dojrzałość? Co to w ogóle jest?

Po pierwsze można ją zbadać. Najlepiej przez zewnętrzny ogląd, przegląd czy jak kto woli audyt (Ci od ISO powiedzą może audit – nawet słownik to odrzuca). Już sama wola wykonania przeglądu jest wyrazem dojrzałości. Niektórzy wprawdzie (niedojrzali) mówią, że jest wyrazem samobójczych instynktów lub głupoty (bo szef dowie się, że mamy braki). Ale Ci, w których głowach znajduje się olej powyżej poziomu rezerwy, sięgną po przegląd, bo dowiedzą się w jakich obszarach mają słabości i zagrożenia, gdzie doskonalenie przyniesie im rezultat, a gdzie będzie tylko biciem w wielki dzwon i działalnością PR. Dowiedzą się też jaka jest optymalna roadmapa działań na 12 miesięcy, czyli dostaną plan do wykonania (o ile znajdą do jego realizacji ludzi to skorzystają). Taki bilans otwarcia nie jest drogi, a przynosi wartość i ustawia praktyczne działanie. Oczywiście jeżeli prowadzone w obrębie sensownej metody i przez doświadczonego eksperta.

Po drugie patrzymy na plany doskonalenia. Czy są zdefiniowane? Czy są realistyczne? Czy mają pokrycie w zasobach? Jeżeli widzę wystąpienie CIO, który świadomie definiuje kolejny etap programu ITSM, definiuje cele dla kolejnej iteracji to sobie myślę o tych “….” (brakuje mi słowa, a nie chcę obrazić), którzy mówią, “W roku 2008 wdrożymy PRINCE’a, 2009 to rok na ITIL, a potem Governance, ….). No cóż. Zapominamy, że proces to nie projekt. Po projekcie jego wdrożenia, zaczyna się niekończąca się faza doskonalenia. Proces był tylko na poziomie 1. Po projekcie wdrożenia osiągnął 2, ale nadal nie jest zarządzany, optymalizowany i doskonalony. Wymaga zatem kolejnego doskonalenia, 12, 18, 24 miesięcy na osiąganie poziomów 3, 4 i 5, o ile to uzasadnione biznesowo.

Po trzecie rozmawiam z ludźmi i obserwuję ewolucję ich nastawienia i wiedzy. To buduje najbardziej. Czuję się jak stary belfer, który cieszy się, że proces nauczania coś dał. Jak widzę,  że zatwardziały admin czy też developer stają się Service managerami, jak wspierają użytkownika, jak świadczą świadomie usługi. Jak z reaktywnej postawy “Czego …” przechodzą na “Czego … pan sobie życzy” To jest prawdziwy wzrost dojrzałości, to źródło skoku jakościowego, obszar fundamentalnych zmian kulturowych. Czasami bez inwestycji w narzędzia i nawet procesy, zmiana postaw powoduje, że jakość obserwowana przez biznes skacze o rząd wielkości.  Czapki z głów przed tymi, którzy odpowiednio motywują, rozwijają postawy i budują kulturę usługową.

Po czwarte narzędzia. Nie bagatelizuję tematu. Umiejętność właściwego wyboru i wdrożenia nie jest powszechna. Jest także miarą dojrzałości organizacji. Mówi się, że pierwszy dom dla wroga, .., a trzeci dopiero dla mnie. Tak samo z narzędziami wspierającymi. Trzeba się nauczyć na jednym wdrożeniu, żeby zebrać doświadczenia. Szkoda, że czasami dostaje się niewinnemu dostawcy, który źle trafił, bo na niską dojrzałość. Ale trzeba go “zabić” biznesowo, bo jest winny. I pewnie trochę jest , bo się nie stawiał, nie edukował i sprzedał byle sprzedać. Cóż rok kryzysu mamy. Różne już warianty widziałem.

I tu ostatnia na ten odcinek refleksja. Standard i dobra praktyka jest zazwyczaj przemyślanym modelem działania i sprawdzonym w praktyce. ITIL, ISO 2000 na pewno. Pojawia się zatem pytanie, czy dojrzały zespół bierze je takimi jakimi są i “wdraża”? Czy też dojrzałość oznacza odrzucenie niektórych elementów i tak zwane “elastyczne i praktyczne” podejście? Nie będę ukrywał, że w tym temacie jestem dość ortodoksyjny. Wierzę w kompleksowe modele działania, sprawdzone przepisy i w strategię “adapt and adopt”. Dostaje mi się i mojemu zespołowi czasami za “konserwatywne podejście”, za to, że dla dobra jakości usług nie godzimy się na tak zwaną “elastyczność”. Wierzymy, że trzeba być jak gumka w kąpielówkach. Zbyt mocna spowoduje ból (ale będzie trzymać), a słaba spowoduje, że po skoku do wody wypłyniemy jak Adam (co oczywiście może w pewnych sytuacjach być całkiem ciekawe). No cóż wracamy zatem do projektów, gdzie elastyczność doprowadziła do kilku przebiegów jednego procesu, wielość narzędzi, niespójność rejestrów, braki w raportowaniu i odejściu od praktyk usługowych jako niepraktycznych, sztywnych, biurokratycznych. Pozostaje żałować i trzymać kciuki, że nastąpi zmiana w pojmowaniu dojrzałości, konsekwencji, zaufaniu do praktyk, gotowych przepisów i funkcjonalności narzędzi.

Wpis utworzony w kategorii ITSM / ITIL, Ogólne. Czytnik RSS RSS 2.0. Możesz dodać komentarz