Zwyczajnie dobra robota

Niemal każdy dział informatyki w przedsiębiorstwie słyszy od swoich odbiorców, że kosztuje zbyt wiele. Jednak komórka, która pochłania duże środki, jeszcze częściej będzie pytana: czy pracuje dobrze? I co to właściwie znaczy "dobrze pracować"?

Niemal każdy dział informatyki w przedsiębiorstwie słyszy od swoich odbiorców, że kosztuje zbyt wiele. Jednak komórka, która pochłania duże środki, jeszcze częściej będzie pytana: czy pracuje dobrze? I co to właściwie znaczy "dobrze pracować"?

Model wydajności organizacji IT konstruowany jest często w czterech wymiarach: dopasowanie do biznesu, dojrzałość procesów, dojrzałość technologii i wydajność ludzi. W każdym przypadku odpowiedzialność można podzielić na dwa obszary: robienie właściwych rzeczy (takich, które dobrze służą rozwojowi) oraz robienie ich w sposób właściwy (wydajny, efektywny kosztowo i skuteczny). I z każdym z tych obszarów można związać zestaw miar, które powiedzą, czy organizacja działa dobrze czy źle.

Robić rzeczy właściwie

Wiele organizacji informatycznych w ogóle nie formułuje pytania "czy robimy właściwe rzeczy", bo nie podejmuje decyzji na tym poziomie. Oczekiwania wobec IT dane są na tyle szczegółowo, że wystarczy je realizować. Zacznijmy więc od "robienia rzeczy właściwie", czyli skuteczności i efektywności w działaniu. Dział IT w firmie spełnia przede wszystkim funkcję usługową. Można powiedzieć, że "sprzedaje" pewne serwisy na określonym poziomie, za co ich odbiorcy "płacą", ponosząc koszty ich utrzymania oraz uzależniając swoje działania (sprzedaż, usługi, produkcję, handel) od poprawnego funkcjonowania środowiska informatycznego.

Tak więc pierwsza, najważniejsza miara efektywności działu IT to dostępność świadczonych serwisów. Z reguły używa się do tego miary procentowej. Serwis może być zdefiniowany na poziomie technicznym (funkcjonowanie łącza internetowego), aplikacyjnym (możliwość korzystania z programu finansowo-księgowego) albo procesowym (informatyczne wsparcie procesu zamówień). Każda organizacja zdefiniuje inne serwisy i każda zrobi to na trochę innym poziomie. Ważne jednak, by definicje te były spisane i uzgodnione oraz by istniał najprostszy nawet mechanizm ich raportowania i rozliczania. Na przykład, aby raz w miesiącu szef IT musiał rozliczyć się przed zarządem m.in. z dostępności systemów wsparcia produkcji, a dla wszelkich poważnych przypadków ich niedostępności musiał wskazać przyczynę i działania, które przedsięwziął, by takie sytuacje nie powtarzały się w przyszłości.

Ale zasadnicza trudność to zdefiniowanie i pomierzenie serwisów. Czy w firmie, w której istnieje 15 stanowisk komputerowych, niedziałanie Internetu na 10 komputerach jest już niedostępnością serwisu czy jeszcze nie? Czy niezawiniona przez IT instalacja krytycznej poprawki do systemu operacyjnego, przedsięwzięcie absolutnie konieczne, ale powodujące niedostępność systemów, powinno być liczone? A co ze spadkiem wydajności systemu transakcyjnego w wyniku koniecznego zamknięcia miesiąca? Czy po godzinie 17.00 użytkownicy mają prawo do telefonicznego wsparcia? Odpowiedzi na te pytania powinny znaleźć się w księdze usług.

Wspomnijmy jeszcze o kosztach świadczenia serwisów, bo mają one niebagatelne znaczenie. Z reguły CIO mógłby świadczyć lepsze usługi, gdyby jego użytkownicy chcieli za nie zapłacić. Ci zaś oczekiwaliby nieustannego podwyższania jakości świadczonych serwisów za tę samą cenę; ewentualnie chcieliby dostawać to samo, tylko taniej. Mówiąc o mierzeniu efektywności kosztowej, powinniśmy pamiętać o wskaźniku TCO - koszt funkcjonowania IT nie powinien być wyższy niż grupy porównawczej. Odpowiednie benchmarki można kupić.

Drugi, nie mniej ważny czynnik to na ile skutecznie dział IT wspiera firmę w realizacji jego celów biznesowych. Nieustannie zmieniający się klient, otoczenie biznesowe i presja ze strony rynku powodują, że liczy się szybkość i skuteczność dostarczania nowych rozwiązań i modyfikacji istniejących pod kątem nowych zadań.

Powyższy akapit można sprowadzić do kilku prostych stwierdzeń: jeśli firma stoi przed szansą, to rolą działu IT jest wesprzeć taką szansę od strony systemowej. A więc powinien zaplanować, kupić (lub zbudować), wdrożyć (ewentualnie zarządzać wdrożeniem), a potem utrzymać nowy system. A to wszystko - w kontekście zadań i procesów biznesowych, które dany system wspiera.

Szybkie, sprawne i skuteczne przeprowadzanie takich działań jest więc miarą efektywności działu informatyki. Efektywności związanej nie tyle ze świadczeniem bieżącego wsparcia, ile z nadążaniem za zmianą. Nie zapominajmy też o bezpieczeństwie informatycznym. Nawet najlepiej świadczone usługi i najsprawniej wdrażane rozwiązania zdadzą się na nic, jeśli naszą organizację unieruchomi wirus, wyciekną z niej ważne dane albo z korporacyjnych serwerów rozsyłany będzie spam. Nieuzasadnione oszczędności na zapewnieniu bezpieczeństwa informatycznego mogą odbić się nieefektywnością funkcjonowania całej organizacji w momencie, gdy jakiś słaby element zawiedzie.

Badanie bezpieczeństwa IT najlepiej zlecić zewnętrznej firmie i powinno ono przyjąć postać audytu oraz głębszych lub płytszych testów penetracyjnych. Liczba wykrytych luk technicznych lub proceduralnych oraz - ewentualnie - incydentów bezpieczeństwa da nam kolejną miarę efektywności funkcjonowania IT.

Robić właściwe rzeczy

Gdzieś na pewno są CIO, którzy nie muszą zastanawiać się jak przekuć hasło dopasowania do biznesu, bo ich zarząd dokładnie potrafi powiedzieć wedle jakich kryteriów będzie rozliczał lokalny dział IT. Są podobno także zarządy, które potrafią takie cele sformułować i rzeczywiście według nich postępować. Ale niestety większość szefów działów informatyki musi pracować w ramach ogólnych sformułowań w rodzaju "informatyka ma wspierać działalność firmy" lub "pan/pani prezes stawia środki do dyspozycji i oczekuje, że wszystko będzie działać". I obowiązkiem szefa informatyki jest wypełnić treścią w taki sposób, by odbiorcy czuli, że ich oczekiwania są spełnione.

Doskonałą ramę dla zdefiniowania "właściwych rzeczy" daje standard ITIL. Wydzielono w nim dziewięć obszarów, ale tak naprawdę dwa są najważniejsze: wsparcie (Service Support) i dostarczanie usług (Service Delivery). Pierwszy definiuje ramę dla operacyjnego ("codziennego") zarządzania IT w firmie. Logicznie przechodzi od zarządzania incydentem (którym jest niedostępność serwisu) poprzez zarządzanie problemem (nieznaną przyczyną źródłową incydentu), zmianą w infrastrukturze bądź aplikacjach, aż po zarządzanie wdrożeniem/wersją, czyli grupą zmian obejmującą także np. rozpowszechnienie oprogramowania, zmiany w procedurach czy szkolenia. To wszystko zaś oparte jest na procesie zarządzania konfiguracją, czyli tym, co środowisko IT zawiera i wspiera przez centrum usług (Service Desk).

Drugi, dostarczanie usług (Service Delivery), to rama dla taktycznego i strategicznego ("za miesiąc, za rok") zarządzania usługami. W jego skład wchodzi zarządzanie dostępnością, poziomem usług, pojemnością, ciągłością oraz zarządzanie finansowe.

Każdy menedżer IT, zadając sobie pytanie "czy robimy właściwe rzeczy", powinien rzucić okiem na standard i zastanowić się, czy w jego organizacji jest ktoś, kto dba o każdy z tych obszarów. Nie każdej musi towarzyszyć zdefiniowany proces, rozłożona odpowiedzialność oraz zestaw metryk i diagramów. Ale musi istnieć chwila zastanowienia, sprowadzająca się do prostych pytań i odpowiedzi: kiedy skończy się nam pojemność i wydajność (zarządzanie pojemnością), w jakim czasie reagujemy na problemy zgłaszane przez użytkowników (zarządzanie incydentem), czy nowy sprzęt i oprogramowanie wprowadzane są w sposób zorganizowany i nie destabilizują infrastruktury informatycznej (zarządzanie zmianą i wdrożeniem), jak będziemy działać jeśli zawiodą kluczowe systemy (zarządzanie ciągłością)...

ITIL nikomu nie gwarantuje spokojnego snu, natomiast - jako że bazuje na najlepszych praktykach - sprawia, że zarządzanie usługami i infrastrukturą IT ma "głowę i nogi", tj. oparte jest na kompletnym i sprawdzonym zestawie procesów. Trzeba jednak bardzo uczciwie powiedzieć, że standard sam z siebie nie odpowie nam "czy robimy właściwe rzeczy". Na przykład ITIL mówi "możliwie szybko przywróć serwis w przypadku wystąpienia incydentu, minimalizując jednocześnie skutki incydentu". Ale na pytanie "czy szybko to 2 godziny czy 15 minut", "w jaki sposób zbudować wewnętrzną organizację, by ten czas był możliwy", ani "ile taka obsługa powinna kosztować" organizacja musi odpowiedzieć sama - oczywiście we współpracy z użytkownikami.


TOP 200