Zapytania o produkt mający wdzięczną nazwę “Analiza potrzeb i opracowanie wymagań na system ERP” (w miejsce ERP można wstawić dowolny innych skrót w rodzaju CRM, BI, SCM, workflow itp..) najczęściej rodzą oczekiwania w postaci “lista wymagań funkcjonalnych i poza-funkcjonalnych”.

Lista taka jest znana z inżynierii oprogramowania i jest powszechnie stosowana do projektowania i wytwarzania tego oprogramowania. Ale jest pewien problem gdy celem jest zakup gotowego oprogramowania, bo w końcu gotowego nie projektujemy, bo podobno ma być tańsze niż pisanie od początku.

Niedawno napisałem:

Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu, bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą Martina Fowlera:  grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każdą przyszłą partią.

Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć dla użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną ?obsłużone?. (Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.).

Wydawało by się, że wszystko jasne. Ale? Popatrzmy na poniższy diagram:

Czas trwania analizy i specyfikowania (pracochłonność, więc także koszt) rośnie liniowo w takt kolejnych dni pracy nad analizą. W miarę powstawania kolejnych udokumentowanych szczegółów, ryzyko, że wybierzemy zły (niepasujący nam) produkt maleje. Jednak ryzyko jest, jak widać,  funkcją nieliniową (jest to prawdopodobieństwo złego wyboru, które nigdy nie dojdzie do zera) zaś wzrost kosztów jest liniowy. W efekcie od pewnego momentu, dość bliskiego początkowi tej pracy, koszty takiej analizy rosną szybciej niż korzyści z jej szczegółowości. Tak więc w typowym projekcie w zasadzie skazani jesteśmy na kompromis i uznanie pewnego (nie tak małego) ryzyka, że jednak wybór będzie zły (mimo, że produkt spełni skończoną listę wymagań).

Przekroczenie pewnej umownej granicy “rozsądku” – analizy i spisywania szczegółów –  popycha taki projekt w kierunku projektowania nowego systemu, a miało być tanio, bo chcemy kupić system gotowy. Krótkie wyliczenie: typowy system ERPII to ok. 6 tys. cech. Samo ich spisanie ze zrozumieniem to:

• opis jednego wymagania to 500 znaków  (średni wynik z kilku znanych mi dokumentów)
• jedna strona maszynopisu to 1800 znaków
• 6 tys cech to 6000 x 500 znaków / 1800 strona = 1667 stron tekstu
• z rozmów z wykonawcami analitykami wiem, że efektywnie piszą ok. 7 merytorycznych stron dziennie (to dość optymistyczne założenie)
• w efekcie 1667 stron / 7 dziennie = 238 dni roboczych, stawka bardzo taniego konsultanta to np. 1000zł/dzień, otrzymujemy: 238 tys. złotych i ponad roczny projekt.
• Jeżeli uznamy, że jednak specyfikowanie jest poprzedzane analizą, dla uproszczenia (znowu bardzo optymistycznie) przyjmę, trwająca tyle co spisywanie jej wyników, mamy dwa lata pracy i pół miliona złotych.
• Skrócenie tego poprzez zatrudnienie nie jednego a np. czterech analityków podniesie koszty o ok. 30% (znam takich, którzy by tu dodali 50% i pewnie mają nie raz rację) na koordynację, kontrolę zgodności, poprawki wynikające z “uspójniania pracy różnych autorów”.

Urealnienie tych wyliczeń (choćby stawki analityków) wywinduje ten budżet na kwotę znacznie ponad milion złotych! Na to sobie mało kto sobie pozwoli. W większości przypadków nie jest robiona tak długo trwająca analiza i za nie takie pieniądze. Zaryzykuje tezę, że – obserwując statystyki projektów IT – nie ma to, takie podejście, żadnego sensu. Tak więc tak opracowane specyfikacje, są jednak upraszczane z uwagi na koszty, są z zasady niekompletne!

Teraz przyszła pora na mojego serdecznego przyjaciela, który zjadł zęby na korporacyjnym rynku IT (wybaczycie mi Państwo, że dane jego zachowam dla siebie). Oto co mi niedawno powiedział podczas podobnej dyskusji:

Nawet przy kupnie konkretnej kiełbasy kryteriów wyboru sklepu może być wiele i zakładamy, że ktoś ma czas/pieniądze aby je wszytkie zastosować, by podjąć decyzję. Przy kupnie samochodu czy komórki ilość funkcji, które trzeba porównać jest tak duża, że porównywanie to już spora praca. Nie zawsze ma się zasoby, aby ją wykonać. Nabywca z dobrym działem zakupów ma schematy oceny wielokryterialnej skomplikowanych towarów i usług, Ale kto poświęci 2 godziny na decyzję, jaki kupić sobie długopis? Pewnie nikt, ale na podjęcie decyzji kupna komórki 2 godziny to stanowczo za mało, choć błędna decyzja jest kosztowna lub wiąże nas na 2 lata z modelem, który nie spełnia oczekiwań.

Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły.

I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów? Czy to znaczy, że kupno gotowego systemu nigdy nie ma sensu? Ależ ma ale…

Gotowe oprogramowanie jest adresowane z zasady do wielu różnych odbiorów, skazane jest więc na znaczny nadmiar funkcjonalności “na zapas” (popatrzmy z jakiej części cech telefonów czy pakietów biurowych korzystamy). Skoro więc potrzebujemy czegoś co ma 100 potrzebnych nam cech a wybieramy coś gotowego na rynku co ma ich 1000, ale zawiera te potrzebnych nam 100, to sama nasuwa się teza, że powyżej pewnego progu uniwersalne rozwiązanie kosztuje więcej (uwzględniając koszty decyzji) niż korzyści z cech wymaganych i zapewne nie raz warto wykonać coś “pod nasze potrzeby”.  I tu pojawia się haczyk: należy te potrzeby bardzo dobrze – z minimalnym ryzykiem – opisać. Bo wszyscy wiemy jak się kończą projekty programistyczne, w których “klient nie wie czego chce”.

Jak to robić lepiej? Po pierwsze nie kupować “dużych i drogich zintegrowanych systemów” bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować i tworzyć te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać.

Niestety nie ma prostej odpowiedzi na pytanie jak to robić “dobrze”. Chyba, że będzie to propozycja następującego procesu:

1. analiza biznesowa,
2. zdefiniowanie celu,
3. zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), tu zmierzamy w kierunku tak zwanej [[architektury korporacyjnej]],
4. zidentyfikowanie oczekiwanych od oprogramowania usług (wymagania), podzielić je na odrębne ale spójne obszary dziedzinowe,
5. dla każdego obszaru dziedzinowego opracować wymagania na oprogramowanie,
6. wybrać rozwiązania.

Zwracam uwagę na drobny szczegół: wyboru produktu i jego dostawcy dokonujemy na końcu, nigdy na początku! A kto i dlaczego nas przekonuje, że należy najpierw kupić a potem analizować?

(artykuł ukazał się także w ERP-Viev.pl)