Mierzenie i co dalej?

Kiedy zaczynamy mówić o przyszłości, niewiele jest pewnych rzeczy w informatyce.

Kiedy zaczynamy mówić o przyszłości, niewiele jest pewnych rzeczy w informatyce.

Ale już dziś mogę powiedzieć wszystkim programistom, projektantom, analitykom, administratorom, itd.: za 5 lat ich środowisko pracy będzie bardziej opomiarowane, niż jest dzisiaj. Czasy artystów i tego, co nieuchwytne, mijają. Dokładniej mówiąc: artyści zakładają start-upy i potem wchodzą z nimi na giełdę, zarabiając miliony. Albo też bankrutują w pierwszym roku. Reszta zaś musi stopniowo profesjonalizować swoje działanie.

Wydaje mi się, że generalne "opomiarowywanie się" przez informatykę i informatyków jest per saldo korzystnym trendem, będącym prostą konsekwencją przekształcania się naszej dziedziny w dojrzałą gałąź inżynierii. O ile jednak jestem pewien, że jesteśmy w stanie wyznaczyć pewne wielkości, odpowiednio zebrać dane oraz w jakiś sposób je zaprezentować, o tyle mam wątpliwość, jak i do czego zostaną one potem wykorzystane.

Spójrzmy na firmę software'ową. Dość oczywistą miarą jej sprawności, którą należałoby zebrać, jest liczba błędów w produktach, które przedsiębiorstwo dostarczyło do swoich klientów. Im więcej błędów, tym gorsza praca programistów; im mniej, tym lepiej. Proste?

Niezupełnie. Być może większa liczba błędów to po prostu pochodna wzrastającego rozmiaru systemu? A może wymagania nie są dość jasno sformułowane, w związku z tym użytkownicy zgłaszają jako błąd coś, co de facto nim nie jest? Zaś firma dysponuje naprawdę szybkim i skutecznym mechanizmem aktualizacji swoich produktów (dzisiaj wbudowywanie takiego mechanizmu w produkty informatyczne zaczyna być standardem) i poprawienie błędu jest bardzo szybkie, proste i tanie. Opłaca się więc (i to obu stronom) wypuszczać do klienta produkt z błędami i aktualizować go za pomocą internetowych łączy.

Inna, wydawałoby się, oczywista miara, to całkowity koszt utrzymania rozwiązania informatycznego (TCO). Tylko w jaki sposób go policzyć? Teoria mówi, że ponad połowa tego kosztu to koszty pośrednie, np. samoobsługa użytkowników wywołana brakiem dokumentacji, niemożnością dodzwonienia się do helpdesku itd. Ja dodałbym jeszcze do tego koszty utraconych szans rynkowych oraz błędnych decyzji wymuszonych przez systemy informatyczne. Niedawno sam zrezygnowałem z zakupu biletu lotniczego dla dziecka od firmy LOT, bo nie mogłem tego zrobić przez stronę internetową. Projektant po prostu nie przewidział, że w polu "liczba podróżujących dorosłych" pojawi się cyfra 0. Jak więc zmierzyć TCO? Co taka informacja nam powie? Jak znajdziemy przyczyny wysokiego TCO systemu i w jaki sposób je zmniejszymy?

Proszę poszukać w jakiejś księgarni internetowej - znajdą Państwo kilkadziesiąt pozycji o tym, jak mierzyć IT. Wiele z nich zawiera tzw. gotowce: aby osiągnąć to i to, sięgnij po taką a taką wielkość. Założę się, że za pięć lat ci sami autorzy zaczną pisać, że nie ma "jedynie słusznego" zestawu miar i narzędzi. Wrócimy do źródeł - czyli dobrego zrozumienia celów firmy, jej procesów i czynników przewagi konkurencyjnej. I będziemy wpływać na jej działanie nie tylko poprzez umiejętne manipulowanie miarami, ale także sposobami bardziej tradycyjnymi i "miękkimi": np. kształtowaniem wartości, postaw i kultury oraz odpowiednim przywództwem.

Nie, nie przestaniemy mierzyć. Po prostu będziemy widzieć nasze miary, narzędzia pomiarowe, widzieć wszystko w szerszym kontekście: co nam mówią i jak możemy je wykorzystać do zarządzania. Wtedy dopiero naprawdę nauczymy się zarządzać informatyką.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200