Bogdan Bereza Rola analizy biznesowej w ulepszaniu procesów IT Rola analizy biznesowej w ulepszaniu proceso w 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
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
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
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
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, bogdan.bereza@victo.eu Strona 5 z 5