Jeżeli uznamy, że modelowanie zachowania organizacji w postaci modelu procesów polega wyłącznie na tworzeniu diagramów zawierających kolejno wykonywane detaliczne czynności, to znaczy że wszelkie powyżej opisane zachowania znajdą się jako "równoprawne" aktywności na tych diagramach. Powstają monstrualne nieczytelne schematy blokowe, zawierające setki detali, trudne do interpretacji, trudne i kosztowne w utrzymaniu (aktualizacja), i przede wszystkim nie pozwalające na wyprowadzenie wprost z nich wymagań na oprogramowanie. Można w zasadzie zaryzykować tezę, że tak tworzone modele, w których cała wiedza o organizacji została zapisana jako łańcuchy detalicznie zobrazowanych czynności, tak na prawdę do niczego nie są przydatne. [...] Czemu więc służą żmudne wywiady, warsztaty, burze mózgów w toku analiz firm? Zaryzykuję, tezę, że niczemu nie służą.
Jaki opis powstanie po przeprowadzeniu kilku dni warsztatów z graczami, którzy grają od lat, zasady gry znają na pamięć, bywa ze podejmują próby łamania zasad dla osiągnięcia doraźnych efektów? To będą długie, nie raz niespójne wywody. Każdą z wymienionych gier opisują jednak jednoznacznie dwa bardzo krótkie dokumenty: reguły gry oraz minimalne umiejętności i wiedza każdego z graczy. Z takim dokumentem każdy projektant oprogramowania sobie poradzi bez problemu.
Tak więc, warto rozważyć stosowanie reguł biznesowych i słowników pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to sprawdzona i bardzo przydatna technika analizy i dokumentowania logiki biznesowej. Polecam także stronę The Business Rules Group i zamieszczony tam Manifest Reguł Biznesowych. Tworzenie monstrualnych dokumentów wymagań, zawierających dziesiątki razy powielane "walidacje" prowadzi do wielu kłopotów z utrzymaniem spójności i kompletności takich specyfikacji. Pomijam już ich uciążliwą objętość. Jako materiał dla programisty są one wtedy trudne w użyciu, do tego skłaniają do najgorszych praktyk, jakimi jest między innymi umieszczanie logiki biznesowej w kodzie formatek ekranowych.
Jak widać, z zupełnie z innej strony "odkryliśmy" coś co nazywamy architekturą korporacyjną. Skoro każda analiza wymagań w istniejącej organizacji, to każdorazowa analiza od poziomu motywacji biznesowej projektu, przez wymagane usługi aplikacyjne, integracje aż do platform sprzętowo-systemowych, to mamy nic innego, jak projekt dokumentowania architektury korporacyjnej. I na koniec bardzo ważna moja uwaga: za jakość wymagań odpowiada i ponosi konsekwencje w 100% kupujący, nigdy dostawca!
I teraz sedno czyli co nam daje dobre narzędzie CASE? otóż powyższe macierze (takie i każdą inną) oraz model analizy wpływu, są generowane i aktualizowane automatycznie. Wystarczy opracować standardowe modele w BPMN i UML jak powyżej, wskazać związki pomiędzy elementami jako ich parametry (nie trzeba do tego celu tworzyć sztucznych diagramów) i skorzystać z możliwości automatyczne dokumentowania tych związków.
Patrząc na powyższe można przyjąć, że ?działania operacyjne na pewno mają wpływ na skuteczność działań z zakresu wzrostu jakości i skuteczności w obsłudze klientów. Patrząc zaś na wyniki ankiet można uznać, że priorytetem jest wzrost, a wzrost firmy to głównie wzrost przychodów. Jeżeli uznać, że ankietowani nie mieli na myśli kosmetycznych wzrostów a rynek jest nasycony, to moim zdaniem, "duży wzrost" jest możliwy głównie poprzez przejęcia. Strategia przejęć niewiele ma jednak wspólnego ze sprawnością operacyjną.
Wymagania na złożone systemy, zdefiniowane jako zestaw testów są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna specyfikacja prostych funkcji. Tworzenie testów wymaga jednak określenia biznesowego celu wdrożenia i zrozumienia tego jak organizacja funkcjonuje (opracowanie modeli).
Praktyka pokazuje, że koszt analizy i opracowania takich testów jest znacznie niższy niż nieplanowany dodatkowy koszt projektów (średnie przekroczenie budżetu to ponad 60%).
Być może więc za specyfikowanie wymagań na oprogramowanie powinny odpowiadać urzędy centralne od razu po tym, jak nałożą jakiś ustawowy obowiązek na podległe im urzędy? Wtedy mamy "osobę" analityka, który wykona analizę nowej ustawy i opracuje wymagania na oprogramowanie. Firma, która wygra przetarg, zapewne w ramach swojej analizy i opracowania koncepcji rozwiązania, popyta urzędników o jakieś szczegóły w rodzaju wewnętrzna organizacja pracy urzędu, struktury obowiązków i kompetencji itp. ale nie o to co urzędnik ma robić a czego nie!
I dokładnie takie samo podejście polecam firmom: zanim wybierzecie produkt lub wykonawce oprogramowania, jako interesariusze własnych projektów, zlećcie analizę i opracowanie specyfikacji i dopiero potem pozwalajcie własnym Waszym pracownikom decydować o Waszych firmach, nie to będą przynajmniej wasze kadry kierownicze.
Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!
Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.
Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.
Pierwszym etapem analizy, bardzo trudnym, jest opracowanie modelu pojęciowego. Celem budowy tego modelu jest zrozumienie na poziomie komunikacji (tak zwany biznes z developerem -> zagwarantowanie jednoznaczności) oraz zrozumienie tego co jest przedmiotem projektu (modelując magazyn raczej planujemy oprogramowanie symulujące kartoteki magazynowe a nie produkty w magazynie). Ważne jest by na oprogramowanie patrzeć jak na narzędzie, bo ono nim jest. Oprogramowanie wspomagające zarządzanie magazynem, nie zastępuje tego magazynu i towarów w nim...
Tak więc oprogramowanie, nazwy w nim używane, muszą spełnić warunek zgodności ze "słownikiem biznesowym": biznesowy słownik pojęć (zgodność z nim) to jest wymaganie.
