Informatyka należy zmierzyć i mądrze nim zarządzać

I właśnie takie jak powyżej książkowe podejście powoduje "piękne katastrofy" w znanych mi próbach stosowania ITIL''a. Zasadniczy problem większości teoretyków polega na podejściu "ITIL rozwiąże nasze problemy, bo wcześniej to była epoka kamienna w sensie procesów i przepływu informacji w obrębie IT. A my wam teraz zrobimy to na cacy bo wiemy jak wykonać waszą pracę lepiej" <sic>. Co na dzień dobry jest kompletną bzdurą. Większość większych profesjonalnych działów IT miała już znacznie wcześniej procesy związane z implementacja zmian, cyklem realesowym, czy zarządzaniem problemami. Wdrożenie ITIL''a ma skutkować ujednoliceniem istniejących procesów zgodnie z najlepszymi praktykami (których ITIL jest tak naprawdę przykładem o czym sami autorzy zresztą mówią), a nie wtłaczaniem istniejącej i działające organizacji w sztywne ramy wymyślnej przez kogoś kto przeczytał te kilka książek i zrobił sobie cert z ITIL''a. W praktyce firmy zamiast "stosować" ITIL, zaczynają go "wdrażać" tak jak uruchamia się kolejny, system bezkrytycznie przyjmując jak słowo objawione każdy termin z ITIL''a. Fundując sobie w ten kompletną dezorganizacje dotychczasowego sposobu działania przy braku okrzepłych i przetestowanych nowych procesów. Co przy istniejących procedurach pomiarów wskaźników SLA, powoduje zwykle znaczne obniżenie poziomu usług ;-) Zwykle tłumaczone "no ale potem będzie lepiej", ale "potem" to już bywa różnie. Konkludując żeby coś zmienić trzeba bardzo dobrze wiedzieć jak coś działa, samo święte przekonanie że wie się lepiej jak powinno działać to świetna recepta na "piękną katastrofę".

Generalną słuszność artykułu osłabia dramatyczny brak kropki nad i – to znaczy brak jednoznacznej, pozytywnej sugestii, jak wybrnąć ze sprzeczności pomiędzy potrzebą skutecznego zarządzania, a twórczą atmosferą, pomiędzy radosnym twórczym bałaganem, a rozliczalnością efektów i reakcji serwisowych. Odpowiedzią jest ujęcie roli działu IT w kategoriach procesów i usług. Oprzyrządowania dostarcza tu ITIL wraz z paroma innymi stowarzyszonymi standardami, bibliotekami i normami. Zwłaszcza ITIL w versji 3, który sytuuje każdą usługę IT w każdym etapie jej cyklu życia w kontekście przydatności i korzyści dla biznesu. Przypomnienie o tych standardach jest często irytujące dla informatycznych konserwatystów i informatycznych fanatyków, którzy uważają, że "jakiś ITIL", czy inne fanaberie, to tylko zbędne wymysły. Jednak wyważanie drzwi do najlepszych rozwiązań ITSM dawno już otwartych przez ITIL jest marnowaniem czasu. O ITIL-u trzeba przypominać na każdym kroku. Podobnie jest ze sferą nazywaną "People" w schemacie 4P służącym w ITIL-u m.in. do analizy procesów "service strategy". Procesy te spróbował skategoryzować Paul Wilkinson, posługując się dorobkiem psychologii i socjologii pracy. Zbudował on koncepcję ABC of ICT – czyli postawy (Atitudes), zachowania (Behaviors) i kultura organizacji (Culture) ICT i wyszukał w tych sferach najbardziej podstawowe czynniki dysfunkcjonalne. Warsztaty pozwalające na ujawnienie i analizę tych czynników stają się czasami momentem swoistego katharsis dla organizacje, gdzie się je przeprowadza. W terminologii i w podejściu ITIL v 3 oraz „aneksu” ABC of ICT da się ująć dokładnie wszystkie obserwacje oraz pozytywne sugestie omawianego artykułu. Dlatego też tak mi bardzo brak w nim było ITIL-owych odniesień.