Pół roku temu napisałem:

Tak więc: najpierw analiza tego co i jak robimy. Potem podział tego na obszary standardowe, które obsłużymy narzędziem uniwersalnym, i pozostałe (których z reguły jest bardzo mało ale są bardzo ważne dla nas) i zróbmy je po swojemu ale nie pakujmy się w niszowe lub przestarzałe technologie. Nie dawajmy także wiary w to, że kupno tego co ma (powielenie tego co robi) nasz konkurent uczyni nas bardziej konkurencyjnymi bo praktyka pokazuje coś zupełnie odwrotnego. (czytaj Wymagania na oprogramowanie ERP wspomagające zarządzanie: dwie kupki).

Pojawia się jednak wiele kontrowersji w samej definicji: czym jest projekt o nazwie Analiza wymagań na oprogramowanie a czym projekt Analiza przedwdrożeniowa oprogramowania?

Kupujemy buciki

Krótki przykład z dziedziny, którą wielu z nas (może nawet większość) zna. Aby kupić buty małemu dziecku z wielu powodów nie ciągniemy malucha po centrach handlowych. Jak jednak kupić te buty i nie żałować? Rozwiązaniem jest przygotowanie patyczka o długości równej długości stopy dziecka od pięty do końca dużego palca (pisze dla pewności ;)). Z tym patyczkiem udajemy się do sklepu i szukamy bucików. Aby dokonać tego wyboru dysponujemy dwoma podstawowymi narzędziami: patyczek oraz ograniczenie (tu nasze doświadczenie), które mówi nam, że bucik będzie dobry jeśli patyk się zmieści, może być mały luz (np. maks. 5 mm) ale absolutnie nie dopuszczamy faktu, że mógłby się nie zmieścić. Drugim ograniczeniem jest budżet: planujemy wydać na buciki np. 90zł. Doskonale wiemy dlaczego tak, a nie inaczej postępujemy: bucik zbyt duży będzie po protu nadmiarowym zakupem, którego i tak nie wykorzystamy zaś bucik zbyt mały po protu nie ma sensu z powodów oczywistych. Cel ograniczenia wartości tego wydatku chyba nie wymaga komentarza (po prostu na tyle nas stać). Tak więc mamy skutecznie określone wymagania: patyczek jako model (uproszczenie) stopy dziecka i ograniczenia na jego użycie: zakaz zakupu zbyt małego i umiar w zakupie zbyt dużego.

Wyobraźmy sobie, że tak wyposażeni trafimy na sprzedawcę, który powie, że ma super buciki, kupują je dzieci znanych aktorów i polityków, ale musimy troszeczkę skrócić patyczek i pogodzić się z wielka cholewką w zamian ;), kredyt (są znacznie droższe nią planowalismy) on także załatwi.

Ciekawostka: jeżeli wyślemy pocztą nasz patyczek i nasze ograniczenia do sklepu to ryzyko, że tak zamówione buciki będą złe jest bliskie zeru! Dlaczego? Unikamy nieuczciwej perswazji sprzedawcy  …

A teraz wymagania na system ERP.

Już widzę uśmiechy na twarzach czytelników :). Tak, dobra metoda to mieć model i dodatkowe ograniczenia oraz nie dać sobie wcisnąć czegoś czego nie potrzebujemy. Niestety bez tych dwóch pierwszych (model i ograniczenia) nie mamy żadnej broni ani przed sobą samym (np. emocje) ani przed dostawcą – jesteśmy bardzo podatni na zakup czegoś zupełnie niepotrzebnego. Niektórzy opisują patyczek kolorem, poziomem wygładzenia,  ornamentyką, skomplikowaną procedurą jego użycia i wieloma innymi cechami jednak tak na prawdę maja one znikomy wpływ na skuteczność dokonanego wyboru: liczą się w 99% długość patyczka i ograniczenie: patyczek musi wejść.

Czy tak można z oprogramowaniem?

Oczywiście! Wystarczy mieć model naszej organizacji oraz ograniczenia nałożone na użycie tego modelu. Czy mając patyczek jest możliwa jakaś perswazja ze strony sprzedawcy butów? Nie! A bez patyczka? Kto dał sobie sprzedać nieco za małe buty w swoim życiu i czy je potem nosił (czasem tak, bo pieniądza na buty wydano i drugich nie na razie kupimy)? Czego nie lubią nieuczciwi sprzedawcy butów? Nie znoszą klientów z patyczkiem! Są nawet tacy, którzy wmawiają, że patyczek należy wyrzucić bo buciki są super i się rozchodzą, w skrajnym przypadku wytniemy otwór na palce (kastomizacja gotowego bucika).

Jak wykonać patyczek?

Tu pojawia się moja nieukrywana niechęć do metod polegających na prostym spisywaniu wymagań na oprogramowanie metodą spisywania explicite konkretnych funkcjonalności.

Co będzie skuteczniejszym zamówieniem: bogaty opis tego do czego można użyć korby bez jej projektu (rysunku) czy raczej jej rysunek?

W przypadku analizy wymagań na oprogramowanie, nawet jeśli będą to warsztaty, spotkania nawet wszystkich pracowników i wielkiej burzy mózgów, nic z tego nie będzie (w sensie skuteczności) mimo, że powstają kosztowne mega-dokumenty. Skoro każdy z nas jest w stanie pominąć coś istotnego przygotowując listę kilkunastu sprawunków idąc do sklepu to jak zagwarantować by braków takich nie było w podobnie wykonanej specyfikacji wymagań liczącej nawet setki pozycji?

Należy przygotować nie opis bucika a patyczek (nie opis planowanych zastosowań korby a jej rysunek)! Ma same zalety: ryzyko złego wyboru jest bliskie zeru, jest poręczny, można go nawet wysłać do sklepu pocztą i spodziewać się mimo to dobrych bucików.

Jak nie trudno się domyśleć mowa o modelowaniu biznesowym. Patyczek jest modelem stopy a rysunek korby jej modelem. Jak wykonać minimalny skuteczny model organizacji? Jest to trudne jednak nie niemożliwe. Paradoksalnie zaś, praktyka pokazuje, opracowanie modelu jest tańsze niż prowadzenie wywiadów i opracowywanie bogatej specyfikacji, że nie wspomnę o ryzyku użycia każdej z tych metod. Chyba najgorszym wyjście jest zafundowanie sobie dokumentu wymagań w postaci listy na kilka tysięcy (tak są takie!) pozycji. Tego NIKT NIE CZYTA!

Co zawiera taki model?

Organizację definiują skutecznie:

1. to co i kto i po co robi (w tym [[model biznesowy]] całej organizacji)
2. to jakie kompetencje (umiejętności) musi mieć ten ktoś
3. to co jest w organizacji przetwarzane (zmieniane)
4. to czego nie wolno (ograniczenia)
5. to jakimi się powyższe rządzi prawami

Jak to pokazać a nie opisywać? Nie da się (nie sądzę) stworzyć jednego mega-modelu. Powinny powstać osobno:

1. [[model procesów biznesowych]] by pokazać: kto, co i po co robi a także w odpowiedzi na co (co inicjuje każde działanie)
2. [[struktura organizacyjna]], która pokaże kto i co może robić i od kogo zależy
3. [[reguły biznesowe]], innymi słowy [[ograniczenia systemu]] czyli [[model pojęciowy]] oraz [[system wartości progowych]].

Dobrze wykonany model nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt wykonania modelu a nie raz stanowią zbędne ograniczenia. Dobry model powstaje z użyciem standardowych notacji: [[BPMN]] w obszarze modelowania procesów oraz [[UML]] w pozostałych obszarach. Używanie formalnych notacji pozwana zagwarantować weryfikowalność poprawności modeli.

Użycie takiego modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne: wystarczy go rozesłać do dostawców i zapytać: po pierwsze czy ich system pasuje do niego, ile kosztuje ten produkt rok po roku.

Z takim modelem kupujący nie musi udowadniać, że jego oczekiwania mają sens (co nie raz zdają się podważać dostawcy) a to dostawca musi zdeklarować i wykazać, że jego produkt pasuje do tego modelu (czyli do naszej firmy). Lepiej: model jest doskonałym narzędziem testowania dostarczonego produktu.

Użycie notacji niestandardowych, bez zdefiniowanych reguł, prowadzi do powstania nieweryfikowalnych modeli a to całkowicie dyskwalifikuje ich skuteczności metody i jej przydatność. Tak wykonane modele są nieweryfikowalne i niejednoznaczne.

Tak więc analiza wymagań to jest praca wykonana by opisać czego oczekujemy i dokonać wyboru. Analiza przedwdrożeniowa to praca wykonywana przez dostawcę, którego wybrano, w celu opracowania specyfikacji prac jakie należy wykonać by wdrożyć dany produkt. Zapoznaj się z opisem Metodyki.

A co gdy żaden mega produkt nie pasuje co jest bardzo prawdopodobne? O tym w kolejnej części.

P.S.

Na bazie tego tekstu opublikowałem także artykuł w COMPUTERWORLD:

https://www.computerworld.pl/news/Od-czego-zaczac-wdrozenie,372047.html