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

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 7 komentarzy

  1. Mateusz Kurleto

    Polecam jako lekturę obowiązkową każdemu planującemu jakiekolwiek (nie tylko ERP) wdrożenie.
    Polecam też aby następnie przeanalizował czy lepszy jest bucik najtańszy, który się rozsypie po 2 tygodniach, czy może ręcznie szyty, skórzany który wytrzyma lata. Tutaj istotną kwestią – jak i przy buciku – jest dojrzałość klienta. Dziecku nie zawsze opłaca się kupić super buty, bo szybko wyrośnie. Ale jak noga rosnąć szybko przestaje okazuje się, że kupując bucik tańszy musimy go zmieniać, bądź naprawiać tak często, że przez 2 lata wydamy więcej na posiadanie obuwia niż kosztują dobre buty wytrzymujące lat 3 i więcej jeśli się je pastuje (maintenance).

  2. Jakub Mendys

    Kolejny dobry artykuł. Ma Pan dar łatwego opisywania trudnych rzeczy – jak na analityka przystało.

    W powyższym opisie zabrakło mi wzmianki o jednej rzeczy. Mądra organizacja traktuje wdrożenie nowego systemu jako część wprowadzania zmiany w jej funkcjonowaniu (a nie utrwalenia stanu obecnego). W takim wypadku model procesów, struktury organizacyjnej (rzadziej reguł) powinien uwzględniać oczekiwany stan przyszły, a nie obecny.

    1. Jarek Żeliński

      Słuszna i bardzo mądra uwaga a odpowiedź jest zawoalowana w tym artykule i w jednym z poprzednich:). Model bez uproszczeń (ale z ograniczeniami) to model opisujący naturę, więc wszelkie zmiany w tym modelu są tak samo możliwe jak w naturze, którą ten model przedstawia (modeluje). Druga ukryta “prawda” to czas życia “rozwiązania”. Skoro dziecko szybko rośnie nie ma ekonomicznego sensu kupowanie bucików zbyt drogich. Nie ma sensu także kupowanie nadmiernie uniwersalnych… Słuszna uwaga: model powinien uwzględniać stan oczekiwany i przyszły. Co z tym zrobić? Czy stan obecny to ten jednodniowy, rok budżetowy, pięć lat strategii? Nie ma to prostej odpowiedzi (o ile w ogóle jest taka). Dlatego pozostaje uznać fakty (nikt nic nie wie) i starać się tworzyć modele “naturalne”. Model który wytrzyma próbę czasu to model uwzględniający rzeczy zmienne i niezmienne. Zmienne to najczęściej reguły biznesowe ale także np. struktura organizacyjna. A co jest niezmienne? To, że prace wykonują ludzie, to że zawsze mają jakieś kompetencje, to że reagują wzajemnie na swoje zachowania itp. Innymi słowy: las żyje, zwierzęta w nim także ale nie znaczy to, że nie da się zamodelować lasu. Po protu model musi uwzględniać ten fakt: las żyje i zmienia się. Z organizacjami jest tak samo. Czy to łatwe? Nie :), czy możliwe? Sądzę że tak (trzeba się starać). Po co? Bo dobry model prowadzi do powstawania dobrych systemów 🙂

    2. Jakub Mendys

      “Skoro dziecko szybko rośnie nie ma ekonomicznego sensu kupowanie bucików zbyt drogich. Nie ma sensu także kupowanie nadmiernie uniwersalnych?”

      Ekonomia inwestycji w IT to osobny temat zbyt często zaniedbywany i pomijany. W ilu przypadkach na 100 pada pytanie o rentowność inwestycji w IT? Najczęściej wygląda to tak: operacje czy sprzedaż chcą automatyzacji by ograniczać swoje koszty, IT jest dobre i drogie (bo drogie IT jest dobre) więc dostarcza “fajne” rozwiązania, a cała firma traci bo koszt rozwiązania (jego amortyzacja i utrzymanie) jest nieadekwatna do korzyści których dostarcza i kosztów wdrożenia.

    3. Jarek Żeliński

      Niestety tezę, że nie liczy się rentowności IT bo ono “musi być”, lansują niektórzy dostawcy tegoż IT… ciekawe dlaczego…

  3. Marek Kuszneruk

    Metafora patyczka – proste i na temat. Bezcenne.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.