Dział informatyki jako usługodawca

Jak najbardziej realne są prośby kierowane do informatyków o pomoc w budowie prezentacji Power Point, czy sprawdzenie poprawności stylistycznej e-maila itd. I zawsze wtedy pada odpowiedź: ''My się tym nie zajmujemy'' - i zaraz potem świadomość, że skąd niby użytkownik miał to wiedzieć. W każdej firmie prędzej albo później powstanie potrzeba sformułowania katalogu usług IT.

Jak najbardziej realne są prośby kierowane do informatyków o pomoc w budowie prezentacji Power Point, czy sprawdzenie poprawności stylistycznej e-maila itd. I zawsze wtedy pada odpowiedź: ''My się tym nie zajmujemy'' - i zaraz potem świadomość, że skąd niby użytkownik miał to wiedzieć. W każdej firmie prędzej albo później powstanie potrzeba sformułowania katalogu usług IT.

Większość przedsiębiorstw rozpoczyna budowanie swojego katalogu serwisów "od dołu do góry". Inwentaryzuje to, czym się zajmuje, i stara się określić ramy swojej działalności w odniesieniu do posiadanych kompetencji i zasobów.

Nic bardziej błędnego. Tworzenie katalogu powinno się zacząć od analizy potrzeb klienta - czy to wewnętrznego, czy to zewnętrznego. Zrozumienie, na czym polega jego biznes, na czym mu zależy i jakich usług oczekuje od działu informatyki - to klucz do właściwego zorganizowania działu.

Tak naprawdę wiele firm zaczyna jeszcze wcześniej - od określenia klienta. Paradoksalnie, może być to zupełnie niebanalne zadanie. Przykładem niech będzie pewna znana firma handlowa, w której dział IT musiał zdefiniować, czy świadczyć będzie usługi wyłącznie "centrali", czy też wszystkim oddziałom. Decyzja miała konsekwencje organizacyjno-finansowe, rozstrzygnąć musiał ją zarząd i w efekcie ponaddwukrotnie trzeba było zwiększyć obsadę osobową działu wsparcia użytkownika.

Tylko klient może nam odpowiedzieć na najistotniejsze pytania. Czy przywrócenie działania Internetu po półgodzinie jest tylko dyskomfortem, czy już poważnym problemem biznesowym? W których sytuacjach ważne jest jak najszybsze przywrócenie działania, a kiedy trzeba starannie sprawdzić wszystkie elementy infrastruktury przed uruchomieniem po awarii? Czy od któregoś serwisu zależy ludzkie zdrowie albo życie? Na te pytania należy odpowiedzieć zanim zacznie się definiowanie usługi.

Definicja serwisów

Aktualnie najbardziej dojrzałym standardem jest ITIL. W obszarze Service Delivery definiuje 5 podstawowych procesów: zarządzanie incydentem, zarządzanie problemem, zarządzanie zmianą, zarządzanie konfiguracją, zarządzanie wersją oraz jedną funkcję: biuro serwisów (Service Desk). Rozsądek karze każdej organizacji, zanim zacznie ponownie wymyślać koło, skupić się na tych 6 podstawowych obszarach usług i przede wszystkim przyrównać potrzeby klientów do modelu ITIL.

Opis serwisu zaczynamy od określenia jego wizji i misji. Każde z nich to po prostu zdanie, np. "Misją procesu zarządzania zmianą jest pełne kontrolowanie modyfikacji w środowisku informatycznym organizacji". Właściwe definiowanie serwisu zaczyna się w momencie rysowania mapy procesu. Należy je zacząć od określenia początku i końca procesu (z reguły w tym momencie pojawiają się pierwsze kontrowersje) oraz jego klienta i dostawcy. Informatykom mapa procesu wyda się na pewno tworem znajomym - bardzo przypomina blokowy opis algorytmu. Mapowanie procesu to nic innego jak "programowanie organizacji".

Każdy proces funkcjonuje w otoczeniu organizacyjnym; musi mieć właściciela i wykonawców. Powróćmy na chwilę do procesu zarządzania zmianą: zmiana musi zostać najpierw przez kogoś zaproponowana, potem zaakceptowana (w ITIL takie ciało nazywa się Change Advisory Board), następnie przygotowana, wdrożona oraz zweryfikowana i udokumentowana (najlepiej w bazie konfiguracji). Opiszmy taką zmianę jeszcze bardziej konkretnie: przypuśćmy, że ktoś postanowił wymienić dyski. Musi najpierw stanąć przed CAB i uzasadnić taką potrzebę ("bo przy takim przyroście bazy danych za miesiąc skończy się miejsce", "bo stara technologia dysków nie jest już wspierana przez producenta"), następnie uzyskać decyzję ("możesz to zrobić w niedzielę od 10 do 12"), opisać całą procedurę (przeniesienie danych, demontaż starych dysków, montaż nowych, odtworzenie danych), przygotować testy oraz przewidzieć plan awaryjny (np. co, jeśli nowe dyski nie zadziałają). Na koniec powinien uzupełnić opis danego serwera w bazie konfiguracji, tak by uwzględniał dane o nowych dyskach. A wszystko to za pomocą zawczasu przygotowanych stron intranetowych, szablonów dokumentów i wedle szczegółowych wytycznych.

Od informacji jakościowych, jak proces, jego granice, produkty i powiązania z innymi procesami, powinniśmy przejść do ilościowych. Najważniejszy parametr to oczekiwany poziom serwisu. Na przykład w przypadku procesu zarządzania incydentem oczekujemy, że będziemy w stanie incydenty rozwiązywać w ciągu 24 godzin od wystąpienia - i mierzymy, czy rzeczywiście to się nam udaje. Miara, którą posługujemy się na co dzień, to poziom serwisu - czyli w ilu procent wystąpień udaje się zmieścić we wspomnianych 24 godzinach.

Serwisy i ich ograniczenia

Opis procesu ITIL wg TSO OGC, "Planning to Implement Service Management", v. 2.0

1. Nazwa i zwięzły opis

2. Wizja i misja

3. Zakres, cele i warunki użycia

4. Opis procesu

a. Wejście

b. Podprocesy

c. Kroki

d. Wyjście

e. Wyzwalacze

f. Produkty

g. Narzędzia

h. Komunikacja

5. Role i odpowiedzialność

a. Właściciel procesu

b. Uczestnicy

c. Klienci

d. Inni

6. Dodatkowa dokumentacja

7. Interfejsy

a. Do innych procesów usługowych

b. Do innych procesów IT

c. Do procesów biznesowych

8. Cele formalne

a. Pomiary

b. Metryki

c. Oczekiwana wydajność

9. Przeglądy, audyty i ocena

10. Raporty z procesów

a. Częstotliwość

b. Zawartość

c. Odbiorcy

11. Słownik

Mając zdefiniowane serwisy i pożądany ich poziom, możemy przystąpić do wskazywania ograniczeń. Jednym z pierwszych jest zawsze skalowalość. Powróćmy do wspomnianego zarządzania incydentem - jeśli przy 20 zgłoszeniach dziennie udaje się nam rozwiązywać 100% problemów w ciągu 24 godzin, to jak będzie w przypadku 100 incydentów dziennie? Każdy serwis pomyślany jest na pewną skalę i w jego specyfikacji należy wspomnieć, przy jakiej skali jesteśmy w stanie zapewnić poziom danej usługi. Taką informację bezwzględnie należy zawrzeć w katalogu.

Drugie ograniczenie to dostępność ludzi. Zawsze istnieje ryzyko, że danego dnia dany człowiek po prostu się rozchoruje. Czy możemy go wtedy zastąpić? Czy jesteśmy w stanie zapewnić taki sam poziom serwisów? Odpowiedzi na te pytania będą zależeć oczywiście od konkretnej firmy, natomiast osoba tworząca katalog serwisów musi pamiętać, że kluczowe ryzyka świadczenia serwisów wiążą się z konkretnym człowiekiem, który w konkretnej chwili i miejscu musi wykonać konkretną czynność.

Analogiczny charakter ma dostępność zasobów technologicznych. Jeżeli przedsiębiorstwo posiada tylko jeden napęd taśmowy do robienia kopii zapasowych, ma obowiązek przewidzieć ewentualne obniżenie poziomu usług w przypadku jego awarii lub okresowego czyszczenia. A jeśli firma chce mieć absolutną pewność, że rzeczywiście zawsze będzie w stanie wykonać backup w określonym czasie - to musi się liczyć z poniesieniem odpowiednich nakładów.

Czasami ograniczenia serwisów mogą mieć charakter instytucjonalno-prawny. Na przykład Ustawa o ochronie danych osobowych pozwala na dostęp do baz danych zawierających takie dane pod warunkiem zapewnienia pewnych proceduralnych i technicznych warunków bezpieczeństwa. Dość łatwo można sobie wyobrazić, że w firmie, która musi przetwarzać dane o swoich klientach, serwisanci mają utrudniony dostęp do bazy danych. Nie mogą tak po prostu zalogować się z pełnymi uprawnieniami do systemu DBMS i wykonać dowolne potrzebne czynności. Każde tego typu działanie musi być autoryzowane i odnotowywane w logach - co bardzo mocno może wpłynąć na szybkość rozwiązania problemów i środki, które zostaną w to zaangażowane. Tworząc katalog serwisów, a w szczególności określając poziomy usług, należy pamiętać także o tego rodzaju subtelnościach.

Kwestia narzędzi i pieniędzy

Katalog serwisów pisze się w gruncie rzeczy łatwo, bo papier jest zawsze cierpliwy. Prawdziwe wyzwanie to jednak świadczenie ich na oczekiwanym poziomie, przy ścisłej kontroli wszystkich miar oraz - i tutaj dochodzimy do najważniejszego - kosztów.

Wróćmy jeszcze raz do standardu ITIL. Proces zarządzania finansowego wymaga, by firma znała koszt każdego procesu i była w stanie wycenić każdą usługę. Łatwiej powiedzieć, trudniej zrobić. Podajmy powody: dział informatyki w przedsiębiorstwie z reguły znajduje się w tym samym budynku co reszta firmy i korzysta z tych samych, "dzielonych" serwisów świadczonych przez inne komórki - np. księgowości, usług kadrowo-płacowych itd. "Wycena serwisów informatycznych" nie może być robiona w oderwaniu od generalnego zarządzania kosztami przedsiębiorstwa. W planie minimum przybiera ono postać rachunkowości zarządczej, w której wiele jest kluczy podziałowych i uśredniania. W planie maksimum - wdrażana jest metoda ABC (Activity Based Costing) i każdy krok każdego zdefiniowanego procesu posiada określoną wartość. Wtedy daje się wyliczyć dokładną cenę serwisów informatycznych, a także dokonać porównania - czy np. outsourcowanie części działalności będzie tańsze czy droższe niż wykonywanie jej wewnątrz przedsiębiorstwa. Nawiasem mówiąc, wiedza ta pozwala łatwo skonfrontować z rzeczywistością liczne mity, którymi obrósł outsourcing. Liczenie kosztów daje też bazę do poprawy efektywności - można śledzić, jak w czasie rozkładają się koszty serwisów i czy działania prowadzą do ich ograniczenia lub podniesienia.

A skoro o efektywności mowa - każdy wie, że sposobem podnoszenia efektywności jest informatyzacja procesów. Jest to prawda także dla usług, jakie dział informatyki świadczy swoim odbiorcom. W ostatnich latach nastąpił w tej dziedzinie znaczący postęp i istnieje kilkadziesiąt (!) narzędzi informatycznych, które ich producenci określają mianem "zgodne z ITIL". Do najpopularniejszych należą dostarczane przez Axios Systems, Computer Associates, IBM Tivoli, Peregrine Systems, Remedy, HP. Nie ma na razie wśród nich narzędzia open source, co na pewno zmartwi tych informatyków, którzy szczególnie miłym okiem patrzą na środowiska linuxowe.

Jednak traktując wdrożenie narzędzia, nawet z ładnie wyglądającym logo ITIL czy itSMF, jako substytut uporządkowania serwisów informatycznych, nie osiągnie się nic poza zwiększeniem kosztów. Informatycy, pomimo iż niemal codziennie powtarzają powyższe zdania użytkownikom informatyki, czasami są jakby impregnowani na ten argument, gdy zastosować go do ich "podwórka".

Mając opisany, zmierzony i wyceniony proces biznesowy, ma się znacznie lepszy punkt startu do jego digitalizacji za pomocą narzędzia.

Poziom serwisu

SL = (ND / Opp) x 100%

Gdzie:

SL (Service Level) - poziom usługi

ND (Non-defective occurrences) - liczba sytuacji, w których efekt był zgodny z uzgodnionym (np. czas rozwiązania problemu został zachowany)

Opp (Opportunities) - całkowita liczba realizacji danej usługi


TOP 200