Poniższa metodyka to efekt doświadczeń zbieranych od 1989 roku, stale prowadzonych prac badawczych oraz studiowania światowej literatury na temat analiz systemowych, modelowania i projektowania systemów. Jest zgodna z zaleceniami dostawców narzędzi programistycznych jak i gotowego oprogramowania wspomagającego zarządzanie, w szczególności systemów klasy ERP. Firmy te zalecają poprzedzanie projektów pełnymi analizami i projektowaniem, a w zakresie wdrażania gotowego oprogramowania zalecają analizę luki (rozbieżności cech gotowego produktu z udokumentowanymi wymaganiami) po czym zaprojektowanie i wytworzenie brakujących funcjonalności. Wbrew wielu ofertom firm wdrażających, producenci systemów ERP odradzają wszelkie ingerencje w kod ich systemów, tak zwane kastomizacje. Opisana tu metodyka dotyczy produktu analizy a nie zarządzania projektem analitycznym.

Powszechnie uważa się, że analiza wymagań na oprogramowanie to prosty, ale pracochłonny proces prowadzenia wywiadów i skrzętnego zapisywania tego, czego oczekuje przyszły użytkownik. Nic bardziej błędnego – jest to najgorszy sposób. Metody polegające na zbieraniu życzeń przyszłych użytkowników z pomocą ankiet, sesji warsztatowych, pisania tak zwanych user story, to metody nie poddające się żadnej weryfikacji ani ocenie kompletności. Możemy jedynie wierzyć, że nikt o niczym nie zapomniał, i że tak powstały opis jest spójny, co przy obecnej złożoności funcjonowania nawet małych firm, graniczy z cudem.

Audyt struktur i zasobów organizacji

Struktura organizacyjna, przetwarzane dokumenty, ludzie którzy sie tym zajmują, zasadność każdej czynności i ryzyka ich pominięć, ryzyka zaniedbań, reguły biznesowe, ograniczenia prawne. To tylko kluczowe elementy składające się na całość funkcjonowania organizacji. Większość firm posiada udokumentowaną strukturę organizacyjną, zakresy obowiązków pracowników. Jednak jak sprawdzić logikę i spójność powiązań tego w jedną całość? To, czy nie ma "bezpańskich" obowiązków, zbiorowej odpowiedzialności, przerośniętych kompetencji, niezdefiniowanych reguł biznesowych?

Formalne, poddające się weryfikacji spójności, metody opisu organizacji to nie jest tylko opisowy i obrazkowy zapis tego jak opowiedziano to podczas wywiadu z pracownikiem. Poprawny model organizacji opisuje ścisle zdefiniowane powiązania pomiędzy wszystkimi istotnymi elementami zarządzania:

Jak obniżyć koszty wdrożenia systemu IT nawet o 60%?

• Ryzyko wyboru złego oprogramowania,
• Ryzyko błędów w specyfikacji wymagań (brakujące wymagania, niespójność, zły model danych, wymagania "pod wykonawcę"),
• Ryzyko utraty metorycznej kontroli nad dostawcą oprogramowania,
• Ryzyko przejęcia "wiedzy i pomysłu" (know-how) zamawiającego przez dostawcę oprogramowania i sprzedawania ich kolejnym klientom.

Zły wybór oprogramowania i błędów w specyfikacji

Typowym, proponowanym przez większość dostawców gotowego oprogramowania (ERP, CRM, inne) procesem, jest zawarcie umowy na zakup i wdrożenie oprogramowania jeszcze przed analizą potrzeb. Wszelkie prace - w tym także analiza wymagań - rozpoczynają się dopiero po zawarciu umowy. W takim przypadku najczęściej pojawia się duży koszt procesu dostosowania systemu do odkrytych po zawarciu umowy, potrzeb kupującego.

W takim przypadku nabywca nie panuje nad projektem (prowadzi go dostawca), a także nie ma żadnej wiedzy na temat tego czy ów dostawca (nawet składający ofertę w dobrej wierze) dostarczył optymalne rozwiązanie, bo nie mamy żadnego porównania z innymi.

Analiza przed wyborem produktu

Sytuacja zmienia się diametralnie, gdy analiza wymagań zostanie wykonana jeszcze przed wyborem systemu i jego dostawcy.

W toku takiej analizy wykonujemy kompletny opis nie tylko samych wymagań, ale także logiki biznesowej i obiektów biznesowych, czyli tego co jest "wnętrzem" oprogramowania. Mając taki opis organizujemy konkurs ofert (przetarg) pytając dostawców o to, na ile ich produkt przystaje do Państwa oczekiwań, wybieramy produkt najlepiej zaspokajający potrzeby w planowanym budżecie. 

Wymagania (funkcjonalności) brakujące, niedostępne w produkcie "z półki", wymagają dodatkowego opracowania i wykonania jako odrębne, uzupełniające komponenty (moduły). Producenci gotowych systemów (np. ERP) odradzają modyfikowanie ich produktów ponieważ modyfikacje takie prowadzą uzależenienia się od firmy realizującej to wdrożenie natomiast po dokonaniu takich modyfikacji niemożliwy jest upgrade oprogramowania (uaktualnienie do nowszej wersji).

Proces i metodyka prowadzenia analizy

Metodą minimalizującą ryzyko błędów w specyfikacji wymagań jest iteracyjne modelowanie firmy i testowanie tych modeli z pomocą rzeczywistych dokumentów.

 

 

Wypracowałem metodykę polegającą na wykonywaniu tak zwanego proof-of-concept, czyli weryfikacji wymagań poprzez tworzenie i testowanie modeli. Tymi modelami są modele procesów biznesowych oraz modele reguł biznesowych i logiki systemu (model dziedziny systemu).

Analizy i projekty, które realizuję, dają w efekcie dokumentację praktycznie pozbawioną braków, zaś koszt jej opracowania jest znacznie mniejszy niż późniejsze koszty modyfikacji i dopasowań (kolejnych kastomizacji) w wyniku odkrywanych podczas wdrożenia, błędów niespójności i braków.

Produkt analizy

Produktem takich analiz jest dokumentacja zawierająca (zależnie od zakresu projektu):

 

1. sformalizowany opis modelu biznesowego firmy (organizacji),
2. zoptymalizowane i sformalizowane modele procesów biznesowych,
3. specyfikację reguł biznesowych,
4. specyfikację ról w procesach odniesioną do struktury organizacyjnej i czynności w procesach,
5. specyfikację przypadków użycia systemu i ich ograniczenia (wymagania funkcjonalne i poza funkcjonalne),
6. opis obiektów biznesowych i logiki biznesowej (model dziedziny systemu i realizacje przypadków użycia),
7. model architektury wysokiego poziomu(tzw. model HLD ang. High Level Design), 
8. dokument Opis Przedmiotu Zamówienia (jeśli wymagany), 
9. zestawienia, w tym: macierz zależności celów i wymagań biznesowych, macierz dokumentów i miejsc ich użycia wraz z poziomem odpowiedzialności (RACI), macierz wpływu i ryzyk.

Prawo autorskie: czyj jest ten projekt?

Posiadaczem praw autorskich do projektu zawsze jest jego autor. Jeżeli więc analizę i projekt wykona dostawca oprogramowania, staje się on automatycznie właścicielem logiki rozwiązania i zaprojektowanego oprogramowania.

Jeżeli analizę wymagań i wystarczająco szczegółowo opisany projekt ich realizacji, wykona niezależny analityk projektant, chroni to Państwa organizację przed tym, by Wasze wewnętrzne, wypracowane latami rozwiązania organizacyjne, nie stały się referencyjnym, powielanym na rynku produktem, zaoferowanym później Waszemu konkurentowi, gdy kupi oprogramowanie od tego samego dostawcy co Wy. Jeżeli Twój (ewentualnie potencjalny) dostawca neguje to (a robi to prawie każdy), skontaktuj się ze mną bo nie ma racji. Wielu dostawców oprogramowania także z tego powodu forsuje tezę, że tylko oni mogą mają kompetencje by prowadzić analize wymagań, co jest nie prawdą. Chroń swój biznes!

Standardy

Standardy gwarantrują wysoką jakość i poprawną komunikację w projektach. Twierdzenie, że poniższe metody komplikują projekty, podnoszą ich koszty i przyczyniają się do ich niskiej zrozumiałości to próba obrony nierzetelnych i niekompetentnych dostawców. Metodyka, ktorą stosuję bazuje na:

1. Standardowej notacji BPMN i BMM w obszarze analizy biznesowej (www.omg.org)
2. Standardowej notacji ArchiMate w obszarze architektury korporacyjnej TOGAF (http://www.archimate.org/, Business Rules Group)
3. Standardowej notacji UML w obszarze projektowania i specyfikowania oprogramowania (www.uml.org)
4. Standardowej metodyce Syntropy/Catalysis w obszarze analizy obiektowej i projektowania oprogramowania (http://www.catalysis.org/)
5. Standardowej metodyce obiektowej zalecanej przez Microsoft w projektach dotyczacych produktów tej firmy (http://msdn.microsoft.com/)
6. Obiektowych wzorcach projektowych w szczególości MVC (http://msdn.microsoft.com/en-us/library/ff649643.aspx), (http://java.sun.com/blueprints/patterns/MVC-detailed.html).