Rola analizy biznesowej w ulepszaniu procesów IT

Bogdan Bereza Rola analizy biznesowej w ulepszaniu procesów IT
Rola analizy biznesowej w ulepszaniu
procesow IT
Selenium, Cucumber oraz Ruby
W „Przewodniku po rynku szkoleń IT” (Computerworld, wrzesień 2012) możemy przeczytać,
jakie wymagania pojawiają się najczęściej w ofertach pracy. Widzimy tam następujące nazwy:
systemy klasy ERP firmy SAP, systemy klasy ERP firmy Oracle, systemy wspierające zarządzanie
relacjami z klientami CRM, projektowanie aplikacji internetowych […] wirtualizacja,
oprogramowanie klasy ERP Comarch, Java, .Net, HTML, C++, PHP, Delphi, Oracle, MySQL,
Microsoft SQL Server, IBM DB2, Linux, Oracle, Unix, Microsoft, HP, Cisco, IBM, Vmware, Novell…
Zupełnie brakuje na tej liście określeń takich jak: inżynieria oprogramowania, inżynieria
wymagań, zapewnienie jakości, zarządzanie projektami informatycznymi, testowanie,
projektowanie systemów, udoskonalanie procesów.
Gdyby analogiczna sytuacja była na przykład w budownictwie, to firmy szukałyby nie murarzy,
zbrojarzy, hydraulików, inżynierów budowlanych czy architektów, tylko… specjalistów w
zakresie określonych marek klejów, cegieł i rur oraz rodzajów domów, np. „specjalistów
budowania domów jednorodzinnych w terenie podmokłym dla czteroosobowych rodzin,
mających dwa samochody, psa i kota”.
Jak w tej sytuacji usprawniać procesy, a nawet tworzyć choćby pojedyncze, ale dobre
rozwiązania IT, skoro nie zwraca się uwagi na to, jaki jest cel i sens biznesowy danego
rozwiązania, ani jaka skuteczność i opłacalność metod IT, lecz koncentruje się na detalicznej,
przemijającej znajomości technologii?
Struktura rynku szkoleń IT jest znakomitym odwzorowaniem tego stanu rzeczy. Teraz podobno
dobrze się sprzedają kursy dla użytkowników modnego narzędzia Cucumber (jedno z setek,
akurat dzisiaj cool, narzędzi do wykonywania tzw. testowania przy pomocy słów-kluczy), kursy
języka programowania Ruby (jeden z dziesiątków obiektowych języków programowania,
sympatyczny, ani gorszy, ani lepszy od innych) oraz Selenium – jednego z wielu narzędzi do
testowania aplikacji webowych. Spróbujcie jednak sprzedać wiedzę pozwalającą naprawdę
zrozumieć te zagadnienia ponad technologicznymi szczegółami – nie uda się, zbyt mały jest
popyt. Mało kto chce rozumieć, wszyscy chcą tylko umieć, szukają gotowych przepisów na jedną
sytuację.
Podsumowując: zafascynowani selenem, ogórkiem oraz rubinem (dlaczego IT wymyśla takie
odjechane, nic nie mówiące nazwy?), nie znając inżynierii oprogramowania, realizujemy
projekty IT ad hoc, kierując się zawodnym instynktem, lub opierając na ratujących sumienie
menedżerów gotowcach (następny akapit). Dopóki to się nie zmieni, dopóki analiza biznesowa
oraz inżynieria wymagań nie znajdą się na szczycie listy w przewodniku po rynku szkoleń dopóty udoskonalanie procesów będzie w dużym stopniu grą pozorów i fikcją.
Strona 1 z 5
Bogdan Bereza „Quo Vadis, analizo?”
Moda na gotowce: BEPL, UML, ITIL, PRINCE 2
Nie mam nic przeciwko ani tym znakomitym językom (BEPL i UML), ani tym niezłym standardom
(ITIL, PRINCE 2). To dobre narzędzia pracy. Niestety, nie zastąpią myślenia – a takie próby
niekiedy są podejmowane. Tak samo jak niestosowne jest sięganie po młotek, zanim się wie, co
do czego trzeba przybić i czy w ogóle przybijać, tak mija się z celem modelowanie w języku UML
wymagań, które są niepoprawnie pozyskiwane, czy wręcz można się ich tylko domyślać.
Moda na gotowce utrudnia udoskonalanie procesów: skoro już zainwestowało się spore sumy
we wdrożenie UML, to niełatwo znaleźć czas na zastanowienie się, czy ten sposób modelowania
jest zawsze stosowny; jeśli firma – często pod naciskiem zewnętrznym – weszła w świat PRINCE
2 – trudno jej z niego zrezygnować w tych projektach, gdzie nie przynosi on korzyści.
Słowem, aby móc naprawdę oceniać jakość procesów i usprawniać je, punktem wyjścia muszą
być rzeczywiste cele biznesowe i realne wymagania, a nie narzędzia, które mogą (choć nie
muszą) usprawnić realizację tych wymagań – dotyczy to zarówno narzędzi wysokich, jak BEPL,
jak i niskich, typu ogórek, selen czy rubin.
Od samuraja do Deminga i Jurana
Po co w ogóle bawić się w ulepszanie procesów? W porównaniu z ogórkiem, rubinem i selenem
brzmi to mało konkretnie, budzi podejrzenia, że chodzi o zaspokojenie potrzeb jakichś leśnych
dziadków (i leśnych babć, oczywiście, także), czy wręcz o modną poprawność polityczną – a nie o
budowanie wypasionych aplikacji, ani nie o biznesowy sukces i zysk.
Jest jednak dokładnie odwrotnie – to fiksacje technologiczno-narzędziowe z jednej strony, a z
drugiej – nawiedzony, niejasny język biznesu i marketingu, służą głównie zaspokajaniu potrzeb
rozmaitych młodych wilczków (pojęcia „młode wilki” i „leśni dziadkowie” niekoniecznie odnoszą
się do daty urodzenia – raczej do sposobu pracy i systemu wartości), a mało – biznesowym,
finansowym korzyściom. Zapoznajmy się z klasycznym przykładem.
Lata sześćdziesiąte ubiegłego wieku – raczkujący japoński przemysł motoryzacyjny budzi śmiech
i politowanie, podczas gdy amerykańskie krążowniki szos zachwycają i budzą podziw. W tym
czasie dwaj słynni dzisiaj leśni dziadkowie, Deming i Juran (Juran rzeczywiście żył 104 lata, jak na
leśnego dziadka przystało: 1904-2008) głoszą swoje teorie jakości. Napakowane, pewne siebie
amerykańskie firmy motoryzacyjne nie chcą ich słuchać, bo po co, skoro dysponują
najnowszymi, motoryzacyjnymi odpowiednikami ogórka, selenu i rubinu? Procedury – to dobre
dla mięczaków!
Deming i Juran pojechali więc do Japonii, gdzie gospodarze uważnie ich słuchali… i posłuchali. W
japońskich fabrykach zaczęto odchodzić od starego paradygmatu produkcji taśmowej, gdzie
kontrola jakości skupiała się na końcu taśmy, a wykrywane na taśmie braki albo odrzucano, albo
naprawiano… wielokrotnie, gdyż wciąż powracały. Zamiast tego nowa kontrola jakości pojawiła
się na każdym etapie produkcji, zaś wykrywane braki wykorzystywano przede wszystkim do
tego, by wykryć ich przyczynę i trwale ją usunąć. Mówiąc językiem IT, zamiast obszernych i
Strona 2 z 5
Bogdan Bereza „Quo Vadis, analizo?”
bardzo kosztownych testów systemowych i wdrożeniowych, zaczęto stosować mało sexy, ale
znacznie skuteczniejsze testy wymagań, testy statyczne kodu źródłowego oraz testy
jednostkowe, a wykryte defekty wykorzystywano przede wszystkim do tego, aby usuwać ich
technologiczne lub procesowe przyczyny, a nie do nerwowego debugowania! Kiedyż, ach kiedyż
IT dojrzeje do tego samego?
Co zrobili Japończycy z amerykańskim przemysłem motoryzacyjnym, dobrze wiemy: „1980 Japan surpassed the United States and became first in auto manufacturing”
(http://en.wikipedia.org/wiki/Automotive_industry_in_Japan). To samo zrobią z innymi za
najwyżej 10 lat firmy, których działy IT skoncentrują się na ulepszaniu procesów, zamiast na
rubinach, ogórkach, selenie, oraz na – wymienionych wcześniej – „wirtualizacji,
oprogramowaniu klasy ERP Comarch, Java, .Net, HTML, C++, PHP, Delphi, Oracle, MySQL,
Microsoft SQL Server, IBM DB2, Linux, Oracle, Unix, Microsoft, HP, Cisco, IBM, Vmware, Novell”.
Żeby ulepszać, trzeba mierzyć
OK, więc ulepszajmy, skoro tyle na tym wygrali Japończycy. Agile! – krzyczą jedni.
Programowanie ekstremalne! – krzyczą drudzy. TDD! SPICE! COBIT! CMMI! PMBOK!
Jeśli wygrało Agile, nagle wszystko staje na głowie i zamiast robić oprogramowanie, wszyscy
chodzą na treningi współpracy w grupie (firmy oferujące naukę miękkich umiejętności
biznesowych zacierają ręce), kierownicy stają się nagle mistrzami młyna, wymagania –
zaległościami (backlog), a kolejne etapy projektu – przebiegami. Wow, tylko co to zmienia?
Nawet przyjąwszy, że agile jest cudowną bronią (Wunderwaffe, silver bullet), to co z
procedurami czynności innych, niż samo pisanie oprogramowania – tymi, z powodu których
CMM stało się CMMI?
Więc może CMMI, może COBIT? Świat się biurokratyzuje, jest smutniej, a efekt biznesowy jest
mizerny – nawet po osiągnięciu kosztem znacznych nakładów magicznego poziomu CMMI-5.
Nie wystarczy wdrożyć procedury, których domaga się – w zasadzie słusznie – jakiś zewnętrzny
standard. Trzeba koniecznie mierzyć, ile ich wdrożenie i przestrzeganie kosztuje, jakie przynosi
efekty jeśli chodzi o jakość i o wydajność, i jaki jest ich ostateczny skutek biznesowy, mierzony
obrotami, zyskiem, udziałem w rynku. Bez tego – cała robota na nic: najwięcej na świecie firm IT
mających poziom dojrzałości procesów CMMI-5 jest w Indiach, ale jakoś indyjski przemysł IT
dotąd świata nie podbił.
Trzeba więc mierzyć prawdziwe koszty zarówno zbudowania systemu IT, jak i jego poprawek,
modyfikacji, kosztów utrzymania. Próbować choć oszacować efekty biznesowe wdrożenia
systemu, i porównać z oszacowaniem biznesowych skutków zaniechania takiego wdrożenia.
Działo finansowy każdej w miarę dobrze prowadzonej firmy ma dane i narzędzia, aby takie
porównania zrobić, tylko musi otrzymać odpowiednie wytyczne od kierownictwa firmy, a dane –
z działu IT.
Pomiary wydajności oraz kosztów w IT nie cieszą się dobrą sławą. Począwszy od doświadczenia z
bystrymi inaczej firmami doradczymmi, usiłującymi mierzyć wydajność IT liczbą przyciśnięć przez
Strona 3 z 5
Bogdan Bereza „Quo Vadis, analizo?”
pracowników klawiszy klawiatury na godzinę, a skończywszy na obawach przed rozbudowaną
papierologią: pół dnia się pracuje, a drugie pół – wpisuje w odpowiednie formularze, co w tym
czasie się robiło.
Nie! Tak rozumiane „pomiary wydajności” oczywiście nie działają. Trzeba to robić inaczej –
automatycznie. Wtedy dopiero, bez żmudnych, nudnych, dodatkowych nakładów, będzie można
bez trudu dowiedzieć się, co ile czasu zajmuje w projektach IT, i ocenić efekty ulepszeń. Jak, w
szczegółach, można to robić? Polecam artykuły:

„Między biurokracją a chaosem”
(http://www.computerworld.pl/artykuly/321693_2/Miedzy.biurokracja.a.chaosem.html)

„Dramatyczny wzrost wydajności dzięki IT”
(http://www.computerworld.pl/artykuly/361381/Dramatyczny.wzrost.wydajnosci.dzieki.IT.html)

„Jakość warunkiem wydajności” (http://victo.eu/PL/Wiedza/jakosc_warunkiem.pdf).
Sukces w biznesie a udoskonalanie procesów
Po co udoskonalać procesy IT? Po to, żeby docelowo zwiększyć, lub co najmniej utrzymać, zysk
firmy. Docelowo, czyli:

albo zwiększywszy stopę zysku przy tych samych co wcześniej obrotach;

albo zwiększywszy obroty, na przykład wprowadziwszy nowe produkty / usługi;

albo utrzymawszy / zwiększywszy udział w już istniejącym segmencie rynku.
Zarówno dla firm IT, które tworzą oprogramowanie na zamówienie, jak i działów IT w firmach
zajmujących się innym biznesem, kluczem do sukcesu są wymagania: żeby miały biznesowy
sens, żeby były dobrze zdefiniowane i opisane, i wreszcie sprawnie – możliwie szybko i niedrogo
– zrealizowane.
Usprawnianie procesu pozyskiwania, konsolidacji, weryfikacji, zarządzania i realizacji wymagań,
czyli po prostu całego procesu informatycznego (procesu tworzenia oprogramowania) jest dla
firmy równie ważne (jeśli nie ważniejsze) jak – lepiej znane, rozumiane i doceniane – ulepszanie
procesów zarządzania finansami, marketingiem, sprzedażą, procesem dostaw.
Strona 4 z 5
Bogdan Bereza „Quo Vadis, analizo?”
Proces produkcji oprogramowania nie jest – w przeciwieństwie do procesów produkcyjnych w
tradycyjnym przemyśle – wytwarzaniem wielu kopii tego samego produktu. Każdy projekt IT jest
inny, realizuje odmienne wymagania. Dlatego, aby móc stwierdzić, na ile skuteczne są próby
udoskonalenia procesu IT, trzeba znaleźć miary, pozwalające porównywać ze sobą projekty i
produkty IT. Taką miarą są wymagania, ich trudność i złożoność.
W tym miejscu łączą się ze sobą trzy obszary, tradycyjnie taktowane jako odrębne:

inżynieria wymagań i wykonywane na podstawie wymagań oszacowania pracochłonności;

zarządzanie projektami informatycznymi;

metody udoskonalania i oceny jakości (głównie wydajności) procesu informatycznego.
To temat dobry do kolejnego artykułu, dość sformalizowanego: jak zastosować sieci
bayesowskie oraz metodę Monte Carlo do projektowania oraz weryfikacji skuteczności
ulepszeń procesu IT? Nie wiem jednak, czy zainteresuje on Czytelników - jeśli tylko niewielu, i
CW nie zechce go opublikować, zapraszam do kontaktu mailowego z autorem.
Bogdan Bereza, [email protected]
Strona 5 z 5