W czym problem z kiepskiej jakości analizami i modelami? W tym, że ich autorzy podejmują próby dodawania nowych symboli do notacji, psując spójność i jednoznaczność diagramów, stosują symbole notacji niezgodnie z nadanymi im znaczeniami albo łamią zasadę wyłączonego środka mówiącą w uproszczeniu, że jeżeli coś jest czymś to znaczy, że nie jest już niczym innym (np. jeżeli coś jest zdarzeniem to na pewno nie jest ani czynnością, ani danymi, ani regułą decyzyjną). Innymi słowy: jeżeli jakieś ziarno węgla jest kostką to na pewno nie jest ani groszkiem, ani orzechem ani miałem.
A co jeżeli jednak wynik analizy jest opisem w języku naturalnym lub zestawem diagramów łamiących zasady notacji? Wtedy tak naprawdę analitykami są programiści, bo oni i tak muszą to zamienić na kod w języku programowania, którego używają. Czy to dobry pomysł? Pozostawię odpowiedź czytelnikowi...
Jeśli coś jest skomplikowane, złożone, możliwym rozwiązaniem jest dodanie zasobów i właściwych procedur. Jednak jeśli coś jest trudne, potrzebny jest po protu ktoś, kto potrafi. Czemu o tym piszę? A bo właśnie mam przed sobą kolejny dokument o nazwie SIWZ, wykonany podobną techniką (w obszarze wymagania), jakimś kosztem (czas pracowników albo koszt konsultanta pracującego tą właśnie metoda) opracowano tę specyfikację wymagań a teraz zamawiający sam przyznaje (po rozstrzygnięciu przetargu), że analiza wymagań jest potrzebna bo ów SIWZ jest "niespójny, ma braki i wymaga korekty i uzupełnień". Z tego powodu także nie ma pewności, że w ogóle dobrze opisano Przedmiot Zamówienia".
Niestety wiele projektów programistycznych to odkrywanie wymagań "w trakcie" dostarczania produktu. Po dostarczeniu jakiegoś fragmentu (lub nie raz prototypu całości) beneficjent stwierdza: "to jest dokładnie to czego chcieliśmy ale zupełnie nie to co jest nam potrzebne"...
proszę programistów: róbcie to co rozumiecie i nie wmawiajcie nikomu, że wiecie lepiej jak zarządzać firmą Waszych klientów. Róbcie to co każdy dobry stolarz: poproście klienta o rysunek tego co ma powstać i zróbcie. Nie zapominajcie, że dobry stolarz to nie to samo do dobry projektant, jak klient nie potrafi rysować (a najczęściej nie, bo nie to jest jego kompetencją), dobry stolarz zawsze odeśle do projektanta po rysunek. Między innymi dlatego, by później nie być posądzonym o stronniczość czyli rysowanie tylko tego co jest łatwe w wykonaniu. Rzecz w tym, że nie ma być łatwe dla stolarza a dobre dla klienta.
Stosowanie analizy systemowej, modelowania oraz formalnych notacji do tworzenia modeli, powoduje, że wyniki analiz są daleko bardziej wiarygodne. Z reguły celem pracy analityka biznesowego czy projektanta jest opracowanie opisu rekomendowanego rozwiązania. Może nim być docelowy model organizacji czy też opis oprogramowania jakie należy dostarczyć (bo nie zawsze wytworzyć!). W procesie formalnej analizy systemowej (nie jest to analiza systemu informatycznego, to analiza dowolnego systemu), powstają modele, które testujemy. Taki model to najpierw hipoteza, a po weryfikacji, jest to opis rozwiązania (projekt tego co ma powstać). Idealną sytuacją była by taka, a której mamy narzędzia do modelowania każdej analizowanej dziedziny. W klasycznej inżynierii jest to rysunek techniczny i zasady obliczania wytrzymałości, sformalizowany system tworzenia schematów elektrycznych i elektronicznych i wiele innych (zależnie od dziedziny), notacje UML w inżynierii oprogramowania. W sferze zarządzania mieliśmy do niedawna biała plamę, teraz mamy już BMM czy ArchiMate. Moim zdaniem utrzymywanie, że można coś skutecznie analizować metodami nieformalnymi świadczy raczej o niewiedzy i braku kompetencji.
Zbiegły się dwa fakty: gorąca dyskusja na forum na temat umiejętności programistów i przy okazji ich roli w procesie wytwarzania oprogramowania oraz przesyłka z kolejną nową książką na moja półkę. Ale po kolei. Najpierw fazy cyklu wytwarzania oprogramowania a potem kilka uwag. Zakupiona książka opisuje całość, ja tu skupie się na jej wstępie. Nie będę jej tłumaczył a jedynie opisze idee. Zwrócę także uwagę na pewne aspekty związane z dostarczaniem gotowego oprogramowania, np. systemów typu ERP lub ich komponentów.
Celem jest oprogramowanie a dostawcy oprogramowania najmniej ryzykują gdy dostaną jego specyfikuję czyli gotowy projekt. Tak wiec przetestowany model oprogramowania realizujący cel zamawiającego jako wynik analizy systemowej stanowi nic innego jak opis produktu, który ma powstać. Oczywiście nikt nie projektuje od zera oprogramowania biznesowego bo to nierozsądne, wykorzystuje się tak zwane szkielety oprogramowania. O szkieletach już było tu: Frameworks Introduction ? czyli jak się psuje dobre ERP. A teraz zapraszam do obejrzenia tego co tu napisałem po mojemu czyli na diagramie :) (tak zwane mapy myśli czasami sie przydają :)).
Warto tu zwrócić uwagę na jedną rzecz: ewentualne zmiany rozwiązania i korekty modelu (czyli projektu) odbywają się nadal na etapie analizy i projektowania, a wiec o rząd albo dwa taniej, niż podczas implementacji. Jest to główna przewaga tej metody nad analizą w postaci sesji [[JAD]] i opracowywania strukturalnych dokumentów.
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. Dobrze wykonany model nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt wykonania modelu a także nie raz stanowią zbędne ograniczenia. 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, jeżeli tak to 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 dostawca musi zdeklarować, że jego produkt pasuje do modelu.
Tak wiec zanim wybierzemy system ERP wyobraźmy sobie, że wdrożenie zmusi nas do przeniesienia naszej wiedzy z głów na małe karteczki, zmusi nas do powiązania tego wszystkiego setkami niteczek, pogodzenia się z tym, że dopóki będziemy mieli ten system niewiele będziemy mogli później w tym wszystkim cokolwiek zmienić. Jedną z poważniejszych wad systemów zintegrowanych jest to, że są zintegrowane gdyż nadal większość z nich to integracja poprzez współdzielenie danych.
Co robić?
Wiele firm programistycznych ma etatowych, tak zwanych analityków wymagań, jednak oni z reguły nadal nie są projektantami. Raczej zapisują, w z góry ustalony sposób, to co mówi Zamawiający (z reguły zresztą bez pełnego zrozumienia co powiedziano). Bywa, że projektanta lub programistę wysyła się w roli analityka. To też nie działa z tych samych powodów komunikacyjnych, co potwierdza praktyka.
Czy wykonawca może mieć dobrego analityka projektanta? Może mieć, niejeden nawet ma ale... z jakiegoś powodu uznano, w znacznie starszej niż inżynieria oprogramowania, branży budowlanej, że Wykonawca nie powinien być autorem tego co należy wykonać dla Zamawiającego. Zamawiający także nie powinien być projektantem. Dlaczego? Każda firma (jej Prezes) dąży do maksymalizacji swojego zysku (tu rentowności naszego projektu), interesy Zamawiającego i Wykonawcy są więc sprzeczne dlatego wymagana jest trzecia rola: niezależny projektant. I tak własnie to wygląda w projektach budowlanych, w których architekt to osobny podmiot. Zachowuje on także prawo nadzoru autorskiego nad realizacją swojego projektu by także na etapie realizacji panować nad nim. W trakcie realizacji nadal interesy Zamawiającego i Wykonawcy sprzeczne - Zamawiający maksymalizuje funkcjonalność czyli forsuje wzrost kosztów to zaś niszczy zysk Wykonawcy, który stara się tę funkcjonalność minimalizować.
Wiele się mówi o regułach biznesowych jednak definicja tego pojęcia nie jest taka oczywista. Czym są te reguły? Po przejrzeniu Internetu i literatury uznałem swego czasu, że podejmę próbę stworzenia takiej definicji a raczej usystematyzowania tego co można przeczytać, bo faktycznie nowej definicji nie wymyśle i nie mam takich ambicji. Po drugie uporządkowania nazewnictwa w tej sferze wymaga formalizowanie modeli biznesowych: reguła biznesowa jako pojęcie musi, na użytek modeli, być dobrze zdefiniowana w tych modelach. Na początek warto przypomnieć czym jest model biznesowy: jest to opis tego w jaki sposób firma…
Procesy biznesowe to nie kolejny termin do opanowania, lecz codzienność każdego przedsiębiorstwa. Z naszym udziałem, bądź nie ? procesy zachodzą. Tylko od podejścia kierownictwa zależy, czy będziemy nad nimi panować i sprawnie zarządzać, przyczyniając się do poprawy funkcjonowania firmy. Czy nam się to podoba, czy nie, procesy biznesowe to element naszej organizacji. Świadome i odpowiedzialne podejście pozwoli zarządzać nimi mądrze.
Każdy model procesów nie spełniający powyższych zasad można nazwać właśnie naiwnym modelem czyli takim, w którym dowolne symbole, bez zdefiniowanych zasad zostały połączone ze sobą tak jak usłyszano np. w rozmowie z pracownikiem analizowanej organizacji. Modele takie są bardzo często narzędziem do planowania zmian organizacyjnych, specyfikowania wymagań na systemy IT, specyfikowania centrów kosztów w metodach ABC zarządzania kosztami, w wielu innych sytuacjach. Użycie w którejkolwiek z tych potrzeb złego, naiwnego modelu skazuje cały projekt na niepowodzenie.
Tak więc model procesów bez zdefiniowanej i rygorystycznie przestrzeganej semantyki (słownika symboli), syntaktyki (zasad dopuszczalnych relacji pomiędzy tymi symbolami), pragmatyki (co modelujemy i jak) należy odrzucić!
