Informatyzacja jest przedsięwzięciem drogim. Czy nie nazbyt drogim? Pomocą w ocenie efektywności IT mogą być standaryzowane i powszechnie dostępne, sprawdzone w praktyce metody.

Praktyka stanowi niezbity dowód konieczności stosowania informatyki. Jeśli ktoś ma tu jakieś wątpliwości, niech wyłączy komputery w swojej firmie, a nie będzie miał nawet na czym policzyć lawinowo rosnących strat. Zatem, istnienie IT: tak, ale za jaką cenę? W początkowej fazie rozwoju informatyki, w sposób niewolniczy i z przesadną precyzją formy, próbowano stosować klasyczny rachunek inwestycyjny dla wykazywania "na siłę" efektywności komputeryzacji. Prawo Groscha, za pomocą matematycznej formuły, jednoznacznie wiązało wydajność konfiguracji komputerowej z jej ceną, a państwowe normy w minutach określały ilość czasu potrzebnego programiście na wygenerowanie linii kodowej.

Z reguły zdziwienie budził potem fakt, że tak znakomite teorie nie bardzo pozostają w zgodzie z praktyką. Zapominano bowiem, że informacja jest fenomenem kontekstowym oraz jakościowym, mającym charakter dyfuzyjny wobec innych wymiarów działalności przedsiębiorstwa, takich jak przepływy materialno-energetyczne, strumienie finansowe, ramy czasowo-przestrzenne czy tzw. czynnik ludzki. W efekcie pojawił się niemal aksjomat niemierzalności efektów IT, a wraz z nim zjawiska kryzysowe w branży informatycznej, takie jak niedotrzymywanie terminów, przekraczanie budżetów i spadek funkcjonalności systemów.

Paradoksalnie ów "dogmat" przyjmowano dość chętnie. Skoro bowiem nie ma jednoznacznych metod oceny zastosowań IT, to równie trudno jest wykazać ich efektywność, jak i jej brak. Ten stan rzeczy chroni instancje decyzyjne przed ewentualnymi sankcjami, co prowadzi do rozluźnienia dyscypliny inwestycyjnej. Sprawę komplikuje dodatkowo złożoność wdrażanych systemów. Jeśli specjalista twierdzi, że potrzebował tygodnia na uruchomienie programu, któż zdoła mu udowodnić, że praca była do zrobienia w dwa dni? Zdarza się przecież, że faktycznie występują nieprzewidziane trudności i z jednego planowanego miesiąca raptem robią się w praktyce dwa.

Mapa drogowa

Stopniowo zaczęto jednak dostrzegać, że obalenie opisywanego dogmatu wymaga wyjścia poza klasyczną rachunkowość ekonomiczną oraz modelowania przedsiębiorstwa jako całości, wraz z jego otoczeniem. W ten sposób pojawiło się pojęcie ładu korporacyjnego (IT-Governance), jako zasadniczego czynnika zarządzania firmą, optymalizującego wspomaganie misji (strategie i cele przedsiębiorstwa) przez IT. Widać zatem, że ów nowy czynnik łączy, jako nadrzędny, dwa występujące już wcześniej: IT-Management (zarządzanie) i IT-Alignment (ukierunkowanie na cele firmy). W tym miejscu natychmiast pojawia się pytanie: jak zagwarantować taką optymalizację w praktyce? Faktycznie, istnieje tu bardzo wiele metod o charakterze uniwersalnym oraz cząstkowym. W sferze integracji systemów możliwym podejściem jest np. BPM (Business Process Management, patrz A. Bielewicz, "Kolej na procesy", CW 20.11.2007).

Czy można pokusić się o stworzenie mapy drogowej (road-map) rozważanego obszaru? Istnieje wiele metod oceny technologii IT i wiele modeli referencyjnych, ale można podzielić je na dwa duże obszary:

• wybór nowej technologii;
• pomiar efektywności istniejącej technologii.

Pierwszy z nich wiąże się z zarządzaniem zmianą, cyklem życia produktu (technologii), a więc np. modelem kaskadowym czy spiralnym oraz kryteriami oceny nowych technologii w fazie wyboru (modyfikacji) i w związku z tym organizacją projektu IT, także z prognozowaniem oraz rachunkiem inwestycyjnym. Drugi obszar to także punkty wyżej wymienione, a więc również kwestia przyjętych kryteriów oceny (mierników) i przełożenie problemu oceny na konkretnie istniejące rozwiązania. Tych najbardziej rozpowszechnionych, stanowiących standardy de facto, nie jest już tak wiele. Wymieńmy tu takie jak:

• COBIT (Control Objectives for Information and Related Techno-logy);
• ISO (International Organization for Standardization);
• ITIL (IT Infrastructure Library);
• CMM/CMMI (Capability Maturity Model/Capability Maturity Model Integration);
• TOGAF (The Open Group Architecture Framework);
• TQM/EFQM (European Foundation for Quality Management);
• PMBOK (Project Management Body of Knowledge);
• PRINCE (PRojects IN Controlled Environments).

Wiąże się z nimi szereg narzędzi, takich jak:

• siatka Zachmana (Zachmans Framework);
• kwestionariusz oceny ryzyka Thomsetta (Risk Assessment Questionnaire);
• lista zagrożeń McConnella;
• diagram Ishikawy;
• SixSigma (nie tylko statystyka, ale też pewna metodyka).

Zarządzanie ryzykiem

Jaką metodę zatem wybrać, dokonując wyboru technologii IT? Przede wszystkim należy wziąć pod uwagę kryteria oceny, takie jak:

1. Minimalizacja ryzyka inwestycyjnego;
2. Poziom uwzględnienia wymagań systemowych;
3. Stopień integracji procesów organizacyjnych;
4. Minimalizacja czasu i kosztów wyboru technologii IT, a następnie skojarzyć je ze strategią wyboru technologii, np.:

• projekt z doradcami i udziałem użytkowników,
• zadanie dla kierownika IT,
• zadanie dla doświadczonego pracownika (libero),
• arbitralna decyzja typu "uścisk dłoni prezesa".

Nie ulega wątpliwości, że podejście d) pozwoli nam zminimalizować czas i koszty wyboru technologii IT, ale nic poza tym. Wieloletnie statystyki projektów IT (Standish Group) pozwalają na identyfikację kilku głównych czynników sukcesu:

• Wsparcie kierownictwa (18%);
• Zaangażowanie użytkowników (16%);
• Doświadczenie wykonawców projektu (14%);
• Jasne cele biznesowe (12%);
• Minimalizacja zakresu projektu (10%);
• Inne (30%): użycie standardów informatycznych, niezmienność podstawowych wymagań, formalna metodologia, wiarygodne oszacowania.

Widzimy zatem, że jeśli tylko zdecydujemy się na projekt z zaangażowanym kierownictwem i użytkownikami oraz doświadczonymi wykonawcami (doradcami), to mamy statystyczną gwarancję ponad połowy sukcesu. Zawsze warto jednak używać standardów referencyjnych lub choćby prostych narzędzi do "samodzielnego" użytku w przypadku mniejszych przedsięwzięć, aby minimalizować ryzyko inwestycyjne. Można przy tym skorzystać z dostępnych kwestionariuszy, np. General Project Risk Assessment (http://www.its.monash.edu.au/staff/projects/project-management/risk/generic-risk-assessment.doc) i na tej podstawie (arkusz kalkulacyjny) dokonać adaptacji wag przypisywanych poszczególnym odpowiedziom, np. punkty ryzyka dla pytania o poziom języka programowania: bardzo wysoki poziom (SQL)/niskie ryzyko/2 punkty, wysoki (PL/1)/niskie ryzyko/6, średni (java)/średnie ryzyko/10, niski (asembler)/wysokie ryzyko/16.

Wypełniony kwestionariusz kwalifikuje całkowite ryzyko projektu, ponadto mamy możliwość analizy poszczególnych pytań i obszarów ryzyka: ryzyka biznesowe (klienci, użytkownicy, środowisko docelowe), projektowe (zespół i jego środowisko), techniczne (złożoność, nowe technologie). Możemy identyfikować zagrożenia za pomocą listy McConnella (http://www.construx.com) w celu ich bezpośredniego zmniejszenia (jeśli to możliwe), ale przede wszystkim dla opracowania planów awaryjnych oraz śledzenia ryzyka, tj. alternatyw wykonania, ustalenia odpowiedzialności za śledzenie ryzyka, metod jego śledzenia, procedur uruchamiania planów awaryjnych i przydziału zasobów w związku z nimi.

Model nie tylko z nazwy

Dla oceny i poprawy funkcjonowania złożonego systemu powinniśmy skorzystać ze standaryzowanego modelu referencyjnego. Mogą to być normy ISO (np. ISO 20000 dla zarządzania usługami informatycznymi), interpretowane jako zbiór celów, podczas gdy techniki ITIL stanowią tu swego rodzaju zbiór odpowiedzi na pytanie: jakie działania są konieczne do realizacji tych celów. Innym przykładem jest COBIT, czyli wytyczne sterowania technologiami IT i skojarzonymi, wg ITGI (IT-Governance Institute). Technologia ta jest próbą przełożenia doświadczeń i precyzji regulacji finansowych na normy zarządzania systemami IT i wywodzi się z COSO (Committee of Sponsoring Organizations of the Treadway Commission) - organizacji wspierającej prawidłowość finansowego kontrolingu i reportingu.

Według ISACA (Information Systems Audit and Control Association), organizacji zrzeszającej w 140 krajach kilkadziesiąt tysięcy audytorów, 95% dużych firm używa COBIT-u lub jego elementów, co jest możliwe, bo różne modele referencyjne mają wiele podobnych cech, a duże firmy mają ustalone mechanizmy funkcjonowania i procedury certyfikacyjne. Ustalanie celów w COBIT odbywa się metodą top-down (od firmy do konkretnych procesów), a pomiary metodą bottom-up (od wyników cząstkowych do całości), co tworzy cykl sterowania obejmujący definiowanie celów, pomiary, poprawianie efektywności i definiowanie miar, m.in. dla kilkudziesięciu wyróżnionych procesów.

Szereg wymienionych wcześniej modeli referencyjnych zawiera wiele cech podobnych jak w przypadku COBIT-u:

• wspierane są przez rządowe bądź niekomercyjne instytucje, udostępniające dokumentacje, szablony opisów funkcji biznesowych czy kart procesów;
• stosowanie modelu referencyjnego wymusza standaryzację dokumentacji, co gwarantuje wysoki poziom dojrzałości procesowej oraz efektywną powtarzalność projektową;
• modele korzystają ze sprawdzonych w praktyce technik i narzędzi.

Minusy modeli referencyjnych z reguły nie dotyczą ich samych, ale wadliwych metod ich stosowania, tj. syndromu MINO (Model In Name Only), czyli modelu tylko z nazwy, tzn. wybiórczego stosowania modelu w odniesieniu do pojedynczych składników, bez głębszej analizy i zwracania uwagi na całość metodyki:

• dokumentacja, która jest nieodzowna podczas stosowania modelu referencyjnego, staje się celem samym w sobie, prowadząc nawet do niepowodzeń projektowych wskutek przerostów biurokracji organizacyjnej (problem bardzo dużych firm);
• konieczność regularnej wymiany informacji między uczestnikami projektu prowokuje niekończące się ciągi bezproduktywnych spotkań, ograniczające ilość czasu na rzeczywiste implementacje;
• dla małych projektów zbyt ścisłe przestrzeganie procedur referencyjnych może być bardzo pracochłonne i w takim przypadku niezbędna jest adaptacja modelu uwzględniająca lokalne realia biznesowe.