W artykule o szkoleniu i analizie na bazie standardu IIBA i BABoK napisałem, że „warto planować, projektować i analizować, bo wtedy projekty są przewidywalne zamiast być loterią.” (źr. IIBA czyli ?jak to niektórzy robią w Ameryce? | Jarosław Żeliński – rynek IT, analiza biznesowa i projektowanie systemów.)
Pisząc to mam świadomość tego, że przytłaczająca większość dostawców oprogramowania wmawia swoim klientom, że ocena rentowności jest niemożliwa w projektach IT i należy kupić co dają a nie jęczeć. Niestety wielu kupujących w to wierzy i inwestuje nie raz wielokrotnie więcej niż miało by to ekonomiczny sens.
(moja uwaga rok 2019: teraz mogę ocenić, że większość oprogramowania jakie audytowałem, miała nawet o rząd wielkości więcej kodu niż mogłaby mieć!)
Popatrzmy więc na pierwszy etap analizy biznesowej, budowę wizji projektu i ocenę wykonywalności. Pierwszy etap to analiza strategiczna.
Analiza strategiczna działalności to analiza relacji pomiędzy celami biznesowymi a biznesowymi funkcjami wspierającymi je. Wizja rozwiązania powinna odnosić się do szansy biznesowej i celu biznesowego. Tak więc powinna powstać wizja realizacji celu biznesowego (a najpierw sam cel oczywiście). Wizja ta najczęściej jest pewnym ideałem, który nie zawsze jesteśmy w stanie zrealizować (i często tak jest). Jednak ideał ten należy zdefiniować bo stanowi on nasze zrozumienie celu biznesowego, celu do którego firma dąży.
Jak zapewne pamiętamy z podstaw marketingu: wizja firmy do stan (swój lub swojego otoczenia rynkowego), który postrzegamy jako idealny, misja firmy to sposób dążenia do osiągnięcia tego celu.
Projekt rozwoju analogicznie, powinien mieć wizję (idealne rozwiązanie), plan (osiągalne rozwiązanie) i strategię osiągnięcia tego planu. Całość powinna być osadzona w budżecie firmy i jej rachunku przepływów gotówkowych. I nie chodzi jedynie o umieszczenie kosztów projektu w budżecie i ocenę czy firma to wytrzyma (metoda bardzo często forsowana przez sprzedawców rozwiązań IT). Chodzi o to by powiązać te koszty z odpowiadającymi im przychodami ocenić zasadność ich ponoszenia.
Tak więc mamy trzy elementy projektu:
- stan obecny,
- wizję
- oraz planowany zakres projektu
W ramach analizy biznesowej powinien najpierw powstać opis stanu obecnego. Opis ten nie musi być kosztownym modelem procesów biznesowych „na stan dzisiejszy”. Opracowanie szczegółowego i kosztownego opisu stanu obecnego nie wiele wnosi do projektu a jest bardzo kosztowne. Stan obecny, tak zwany opis as-is, to efekt tego jak poszczególni menedżerowie zarządzają swoimi zasobami, a to zaś jest efektem zadań jakie im postawiono. Pastwienie się nad tym bardzo rzadko wnosi wartości do projektu.
Ważnym elementem projektu jest zdefiniowanie „po co to robimy” i nie powinien to być argument „bo inni mają”. Benchmarking na tym etapie, polegający na porównaniu zasobów jest złym pomysłem. Porównanie wskaźników (czyli właśnie benchmarking) nie jest porównaniem zasobów! Porównując się np. z konkurencją porównujemy cudze osiągi z własnymi, jeżeli mamy taką możliwość, to poza przychodami także koszty itp. Ale porównanie takie to nie jest ocena „czym oni jeżdżą” a ocena „jak oni jeżdżą”.
Po drugie kolejna marketingowa zasada:
nie da się skopiować cudzego biznesu, można co najwyżej ustawić się obok. To jak w sporcie, goniąc kogoś możemy co najwyżej iść po cudzych śladach za kimś, ale to nie to samo co zajęcie cudzej pozycji bo to nie możliwe tą metodą. Wyprzedzanie polega na zmianie toru ruchu by obejść konkurenta!
Tak więc pierwszy krok to wizja. Drugi krok to analiza wymagań, trzeci to ustalenie zakresu projektu czyli opracowanie studium wykonywalności. Dalej ma miejsce uszczegółowienie planu w zakresie projektu.
Określenie obszaru rentowności projektu. Należy to zrobić na samym początku przy okazji budżetowania i analizy przepływów gotówkowych. To tu są dane o tym jakim kosztem i jakie korzyści chcemy osiągnąć.
Gdybyśmy mieli wstępną specyfikację wymagań biznesowych, to z każdym kolejnym wymaganiem przyrasta łączny koszt implementacji całości. Korzyści pojawiają się dopiero od pewnego miejsca, pewne minimum musi być zaimplementowane, żeby system w ogóle był przydatny. Idąc dalej osiągamy próg minimalny: korzyści zrekompensowały nakłady. W miarę implementacji kolejnych wymagań rosną korzyści jednak od pewnego momentu ten wzrost się załamuje. Dalsze ulepszenia powodują, że koszt ulepszeń „zjada” powstające korzyści. Osiągamy górny próg rentowności.
Po wykonaniu takiej analizy wskazujemy optymalny zakres projektu: miejsce gdzie bilans korzyści jest najkorzystniejszy. Jest to stan to-be czyli zaplanowany świadomie zakres projektu.
Jak prowadzić taką analizę?
Po pierwsze należy opracować specyfikację wymagań biznesowych. Każde z tych wymagań powinno uzyskać priorytet, np.:
- Bez niego potrzeby biznesowe nie zostaną zrealizowane
- Bez niego rozwiązanie będzie miało ograniczoną użyteczność
- Bez niego rozwiązanie zrealizuje potrzebny w podstawowej, prostej formie
To pozwoli odrzucić wymagania, które powodują przekroczenie budżetu rentowności, a które nie powodują zbyt dużego pomniejszenia osiąganych korzyści.
Proces ten jest iteracyjny, mając jako model finansowy rachunek przepływów gotówkowych, możemy testować wpływ wymagań na koszt projektu i jego rentowność. Aby było to możliwe należy w całym procesie analizy wymagań prowadzić testy projektu. Polegają one na tak zwanym śladowaniu. Cechy użytkowe rozwiązania muszą się mapować na potrzeby (cele) biznesowe. Stałe testowanie tego mapowania to właśnie „śladowanie”. Zakres projektu to w efekcie lista cech planowanych do realizacji w projekcie (wymaganych do realizacji wizji). Śladowanie to, w całej dokumentacji obejmuje sprawdzanie mapowania:
Potrzeby biznesowe <?> Cechy użytkowe wizji i zakresu <?> Wymagania <?> Specyfikacja
Projekt analizy wymagań na każdym etapie jest testowany, walidowany. Walidacja to sprawdzenie czy wymagania są właściwe. Kolejnym krokiem jest wyspecyfikowanie rozwiązania. Zależnie od projektu (może to być projekt zmian organizacyjnych, projekt wdrożenia nowego oprogramowania) walidowane są wymagania np. na nowy, procesowy system zarządzania firmą (np. wymagania w stosunku do nowej struktury organizacyjnej) albo na nowe oprogramowanie wspomagające zarządzanie (np. ERP). Weryfikacja to testowanie rozwiązania, określenie czy rozwiązanie spełnia wymagania.
Walidacja wymagań
Walidacja polega na przetestowaniu czy nasze wymagania zaspokajają realizację celu biznesowego. Aby taki test przeprowadzić, należy zbudować model firmy, który będziemy testowali (raczej nie ma sensu robienie tego na „żywym ciele”, było by to bardzo kosztowne). Te modele tu, to nic innego jak modele procesów biznesowych. Jednak model procesu to nie model „wszystkiego co się dzieje”. Model procesu do testów to „wewnętrzny model przepływu wartości”.
Modelujemy wyłącznie procesy (przepływ pracy), nie procedury, nie zakresy obowiązków i nie kompetencje czy reguły biznesowe. Pozostałe szczegóły to obszar zarządzania zasobami czy zakresami kompetencji (tu więcej o modelowaniu). Mając poprawny model procesów, możemy przetestować każde wymaganie i jego wpływ na procesy.
Biznesowa specyfikacja wymagań opisuje tak zwaną „czarną skrzynkę”, czyli nie znane nam od środka rozwiązanie. Wymagania na tym etapie to tak zwane przypadki użycia. Walidacja polega wyłącznie na mapowaniu (śladowaniu) celów biznesowych na te wymagania.
Weryfikacja rozwiązania
Kolejny, ostatni etap analizy biznesowej to wersyfikacja rozwiązania. Mając tak zwalidowaną listę wymagań (tak zwaną Specyfikację Wymagań Biznesowych) możemy zabrać się za weryfikację rozwiązania. Tu scenariusz wygląda tak:
- zapraszamy do składania ofert dostawców gotowego oprogramowania przekazując im specyfikacje wymagań,
- dostawca pracując nad ofertą weryfikuje na ile jego rozwiązanie spełnia wymagania (wykonuje tak zwaną [[analizę gap/fit]]), powinien przedstawić listę tak lub nie spełniania wymagań i swoją wycenę,
- jeżeli na tym etapie, oferty są niesatysfakcjonujące, opracowujemy specyfikację każdej funkcjonalności (każdego wymagania) czyli projektujemy rozwiązanie, którego nie znaleźliśmy na rynku.
Na tym etapie zapada decyzja o architekturze rozwiązania: podział na elementy (podsystemy) gotowe i dedykowane. Dedykowane muszą zostać zaprojektowane. Projekty te (modele) są także weryfikowane.
Kolejny etap to zapytanie o oferty na realizację zaprojektowanych podsystemów. W przypadku projektów IT kompletne wymagania to: przypadki użycia, reguły biznesowe, ograniczenia (wymagania pozafunkcjonlane). Zaleca się (nie umieszczono na diagramie) uzupełnienie modelu procesów o tak zwaną taksonomię.
Jeżeli pojawi się potrzeba zaprojektowania dedykowanego rozwiązania, pojawi się model dziedzinowy systemu wraz z uszczegóławiającymi go diagramami stanów. Weryfikacja tej części specyfikacji polega na tak zwanym testowaniu „białej skrzynki” czyli projektu rozwiązania. Tu są to diagramu sekwencji UML.
Całość procesu analizy i weryfikacji bazuje na opisanej już wcześniej Analizie Systemowej. Jeżeli zaś ktoś proponuje jako wynik analizy wymagań, nieweryfikowalne wielostronicowe opisy w rodzaju user story lub wypunktowane listy jako wyniki wywiadów, burzy mózgów czy sesji JAD, to warto mieć świadomość, że to bardzo ryzykowne, bo nieweryfikowalne i nietestowalne dokumenty.
Specyfikacja zawierająca setki wypunktowanych szczegółowo wymagań to nic innego jak niezrozumienie faktu, że lista taka nie poddaje się żadnym walidacjom, a dla dostawcy gotowego oprogramowania jest bezwartościowa z uwagi na zbytnią szczegółowość. Z taka listą analiza gap/fit wykaże prawie całkowitą niezgodność z tym co ma w ofercie i u zdesperowanego dostawcy wygeneruje ofertę na tak zwane kastomizacje, te zaś zabiją budżet projektu.
Czy to warte zachodu
Praktyka takich analiz pokazuje, że proporcje projektów: analiza i projektowanie vs. realizacja, mają następującą postać (dane skorygowane dla projektów znanych autorowi w Polsce):
1. Czasowo: 50/50% (dane z USA: 75/25),
2. Kosztowo: 20-30/80-70% (dane z USA: 50/50, rozrzut zależy od stopnia złożoności dziedziny systemu),
(zależnie od specyfiki projektu i jego złożoności mogą pojawić się pewne odstępstwa). Tak więc jak bumerang wraca ta sama wartość progowa projektów, dla których warto takie analizy robić. Jeżeli uznamy, że opisana tu analiza wymaga pewnych niemałych kompetencji i doświadczenia oraz pewnego minimalnego czasu jaki należy poświęcić na zbadanie i opracowanie modelu firmy to jej koszt zaczyna się od kilkunastu tysięcy, dajmy na to 15 tys. W takim razie budżet całego projektu powinien wymości co najmniej 5 x 15 = 75 tys. zł. (pamiętamy, że koszt analizy to 20% wartości projektu). Analiza taka (dla tego nieskomplikowanego przypadku) wraz z projektowaniem trwa, biorąc pod uwagę czas oczekiwania na przygotowywanie danych przez firmę analizowaną, ok. jednego miesiąca.
Ktoś może zarzucić powyższej kalkulacji nierealizowalność wdrożenia w takim czasie. Odpowiem z praktyki tak: wdrożenia systemów ERP pozbawione etapu tak zwanej „kastomizacji” są bardzo sprawne. Koszty kastomizacji zaś to nawet 75% kosztów całego wdrożenia (warto popatrzeć na oferty, a można tych kosztów uniknąć!).
Firmy programistyczne mające dobry projekt realizują go i oddają do użytku z reguły już w pierwszym podejściu. Tak zwane prototypy, testy, odkrywanie wymagań itp. to cechy pracy na źle, zbyt ogólnie i bez testowania (np. tak zwane user story) określonych wymaganiach. Jeżeli projekt jest już wykonany i przetestowany na etapie analizy i weryfikacji, firma programistyczna musi tylko wykonać implementacje.
Jeżeli ktoś mimo to zaprzecza powyższemu to musi mieć świadomość, że neguje potwierdzone dokonania ostatnich 20 lat wielu dobrych firm analitycznych na świecie, a od niedawna także w Polsce. Działalność IIBA i jej członkowie są na to żywym dowodem (na dowód mam także swoje referencje).
Dlaczego takich analiz wykonuje się mało? No cóż, nie są one w interesie dostawcy, który twierdzi, że jego system np. ERP jest „na pewno dobry”. Po drugie wiele firm kupujących oprogramowanie uznaje, że ich nie dotyczy ryzyko projektowe i pomijają analizy, a te są przecież niczym innym jak obniżeniem ryzyka niepowodzenia takich projektów. Pamiętajmy, że ponad 80% projektów wdrożeniowych w IT to projekty z silnie przekroczonymi budżetami i terminami, część z nich (szacuje się je na ok. 16%) to projekty zaniechane z tego powodu.
Każdy z Państwa sam musi sobie odpowiedzieć na pytanie: czy 20% budżetu jest warte tego by chronić pozostałe 80%.
(źr. badania Cortex), dostęp 2011)
