Analiza przedwdrożeniowa jest na swój sposób fundamentem całego projektu wdrożeniowego. Jej zadaniem jest nie tylko zdefiniowanie funkcjonalnych i technicznych wymagań względem systemu. Analiza poprzedzająca wdrożenie powinna również ostatecznie potwierdzić zasadność całego projektu. Po podpisaniu umowy od wdrożenia nie ma już odwrotu. Wbrew pozorom, analiza przedwdrożeniowa nie jest jednak tym samym, co opracowanie wymagań względem systemu. Wymagania powinny być traktowane jako produkt analizy. W obliczu wielomiesięcznego projektu wdrożeniowego trudno oprzeć się jednak pokusie skrócenia analizy do minimum i oszacowania wymagań w mniej czasochłonny sposób - np. zbierając listy oczekiwań od użytkowników. Zwykle jest to błąd. W jaki sposób warto zabrać się za specyfikację wymagań? Posłużmy się analogią.

Z systemem jak z dzieckiem

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ć? Po pierwsze, przed zakupem warto sprecyzować, w jakich sytuacjach i warunkach akurat te buciki będą zakładane. Będziemy więc musieli sobie zrobić notatki w rodzaju: kolor, sposób wiązania lub zapinania, wysokość oraz rodzaj wykorzystanego materiału. W przypadku butów kluczowym parametrem jest oczywiście rozmiar. Jednak standardów numeracji, podobnie definicji funkcji oprogramowania biznesowego, jest wiele. Bywa też, że nawet w ramach jednego standardu numeracji buty różnych producentów różnią się wielkością.

W większości przypadków zakupy butów dla dziecka wyglądają tak, że z drugim rodzicem, czasem także babcią, wybieramy się na wyprawę pod tytułem "kupujemy dziecku buciki". Pamiętamy numer stopy dziecka, mamy jakieś luźne wyobrażenie o tym, jakie buciki mamy zamiar kupić. W każdym sklepie najpierw sami studiujemy zawartość półek, a później wysłuchujemy rekomendacji sprzedawcy. Nad każdą interesującą parą bucików debatujemy w naszym gronie, każdy jednak ma inną wizję i bucików i tego, kiedy będą noszone. Jednocześnie, w takim zespole każdy czuje się ważny - także sprzedawca znający ofertę swojego sklepu. Widać analogię? Idźmy dalej.

Doświadczenie pokazuje, że po wielu odwiedzonych sklepach, dziesiątkach obejrzanych butów i długich debatach wracamy do domu skłóceni z rodziną oraz nieco za dużymi bucikami w jaskrawych kolorach. Buciki są za duże, bo sprzedawca poradził, że dziecko dłużej je ponosi zanim wyrośnie. Natomiast kolory to efekt gorącego kompromisu w sklepie. Podobnie jak modne klamerki zamiast klasycznych sznurówek. Dodatkowo kupiliśmy buty dwukrotnie droższe niż pierwotnie planowano - sprzedawca poradził, że skoro są nieco za duże i będą noszone dłużej, to warto zainwestować w dużo lepszy materiał.

Zderzenie z rzeczywistością

Zderzenie naszego zakupu z rzeczywistością niestety zwykle nie jest przyjemne. Dziecko często zdejmuje buciki, bo są lekko za duże. Równie często zsuwają się one same, ponieważ modne klamerki okazały się być strasznie nieporęczne. Po krótkim użytkowaniu także po kolorach nie ma śladu. Jak zwykle w takich przypadkach, skończyło się na tym, że dziecko dalej nosiło stare buciki. Niestety po zbyt długim chodzeniu w starych, nieco za małych bucikach, dziecko nabawiło się kłopotów ze stopami. Ortopeda zalecił zakup dopasowanych, wygodnych i łatwych do zapięcia butów. Ostatecznie rodzice z porad ortopedy nie skorzystali, gdyż uznali, że poprzednio po prostu mieli pecha. W efekcie maluch nabawił się poważnych kłopotów ortopedycznych. Najlepiej było po prostu pójść do sklepu z kartką i zapytać sprzedawcę, czy ma w ofercie buty opisane na kartce. Ale co na tej kartce powinno być napisane?

Definicja wymagań

Rozwiązaniem problemu z rozmiarem jest przygotowanie patyczka o długości równej długości stopy dziecka. Z tym patyczkiem udajemy się do sklepu i - bazując na naszym doświadczeniu i umiarze, szukamy bucików. Jednak sam patyczek to za mało. Wcześnie oceniamy, jaką kwotę możemy zapłacić za buty, konkretnie określamy rodzaj butów, jakich szukamy oraz w jakich warunkach dziecko będzie z nich korzystać, a co za tym idzie - z jakiego materiału powinny być wykonane. Bazujemy też na opiniach zaprzyjaźnionych rodziców. Tak wyposażeni, możemy udać się do sklepu. Zapewne sprzedawca w pierwszej kolejności zaoferuje nam najdroższe buciki, które noszą dzieci znanych aktorów i polityków, będziemy musieli tylko trochę skrócić patyczek i pogodzić się z wielką cholewką. Dzięki wcześniejszej analizie wymagań my jednak będziemy dobrze wiedzieć, czego szukamy. Dzięki temu zmniejszymy również ryzyko niepowodzenia. Kto raz dał sobie sprzedać nieco za małe buty i później musiał je nosić, ten wie, o czym mowa.

Najlepsza metoda na udany zakup to mieć przygotowany model i dodatkowe ograniczenia. Bez nich jesteśmy bardzo podatni na zakup czegoś zupełnie niepotrzebnego. Warto dodać, że przygotowując model, powinniśmy skoncentrować się na cechach najważniejszych z perspektywy kupowanego rozwiązania. Niektórzy opisują wspomniany patyczek wieloma zbędnymi cechami, jednak tak na prawdę mają one znikomy wpływ na skuteczność dokonanego wyboru. Z kolei sprzedawcy często przekonują klientów, że patyczek należy wyrzucić, bo nawet dużo za małe buciki się rozchodzą, a w skrajnym przypadku wytniemy otwór na palce.

Przemyślany zakup

Systemy ERP to przede wszystkim narzędzie wspierające kadry kierownicze w bieżących działaniach. Mogą one jednak funkcjonować tylko na bazie danych źródłowych. Te zaś trzeba wprowadzić zanim oprogramowanie zacznie być wykorzystywane. To truizm, o którym jednak często zapomina się w projektach analitycznych. Problem tkwi w kolejności: najpierw myślimy o tym, jakie informacje chcemy uzyskać i czego oczekujemy od systemu, a dopiero na tej podstawie określamy, jakie dane źródłowe mają zostać wprowadzone.

Tak naprawdę wymagania na oprogramowanie wspomagające zarządzenie to lista funkcjonalności. Lista tego, jakie informacje i dane chcemy uzyskiwać. Te dane to z jednej strony aktualnie wystawiona faktura na podstawie zamówienia i tego, czym dysponujemy w magazynie, z drugiej strony statystyki sprzedaży z uwzględnieniem regionów, produktów czy sprzedającego pracownika.

Specyfikacja wymagań więc to lista tego, co chcemy uzyskać oraz lista danych, jakie muszą zostać wprowadzone, by ten cel osiągnąć. Na czym polega problem? Na tym, że lista ta będzie długa. Im dłuższa, tym łatwiej o pominięcie czegoś istotnego. Niestety nieprawdą jest, że listę taką można stworzyć na bazie wywiadów i sesji burzy mózgów z pracownikami. Tak opracowana lista wymagań jest głównym ryzykiem projektu. Powód? Człowiek nie jest w stanie w głowie wyobrazić sobie obiektu tak złożonego jak przeciętne oprogramowanie. Spisanie rozmów i nawet podzielenie takiego tekstu na tematyczne sekcje nie rozwiązuje tego problemu, gdyż nadal nie mamy narzędzia do oceny spójności i kompletności tak powstałego opisu. Powyższy problem z bucikiem to tylko namiastka tego, co czeka zespół projektowy pracujący nad taką specyfikacją wymagań.

Problemy tego rodzaju skutecznie rozwiązuje się podobnie jak w innych obszarach inżynierii: należy określić kluczowe cele, zanalizować i zrozumieć możliwość ich osiągnięcia i opracować sposób, by to osiągnąć. Produktem tych działań jest przetestowany model. Raz jest to makieta samochodu, innym razem samolotu. Nawet krawiec szyjąc garnitur, posługuje się manekinem zastępującym mu ciało klienta.

Jak przygotować skuteczny model?

Poprawny model firmy na potrzeby analizy wymagań to: mapa procesów oraz już poza nią - ale powiązane referencjami z tą mapą - dokumenty takie jak procedury dla wybranych czynności, specyfikacje stanowisk i kompetencji, wzory dokumentów, reguły biznesowe. Mapa procesów to obraz przepływu pracy w firmie. Każdy podmiot będący organizacją ludzi, którzy wykonują jakąkolwiek celową pracę, da się opisać w postaci procesów, czyli łańcuchów czynności wymagających czegoś na swoim wejściu i dających w efekcie coś na wyjściu. To ostatnie to nic innego jak cel danej pracy. Jednak modelowanie procesów nie ma nic wspólnego z prostym, obrazkowym zapisywaniem czynności poszczególnych pracowników. Model procesowy firmy to jej wewnętrzny łańcuch wartości. Szczegóły działań to metoda ich osiągania w konkretnej firmie. Jeżeli model zawiera te szczegóły, to staje się kompletnie nieprzydatny, bo ukrywa sedno sprawy. Dobry model rozgranicza: łańcuch czynności, reguły biznesowe oraz ograniczenia. Kolejne czynności są kandydatami na potrzebne funkcjonalności nowego systemu. Jednocześnie system powinien pozwalać na zarządzanie regułami biznesowymi i definiowanie procedur. Częścią modelu powinien być również uporządkowany model informacji. Ta swego rodzaju taksonomia powinna opisywać powiązania między obiektami biznesowymi - np. faktura VAT powstaje na bazie zamówienia od klienta lub zamówienia wewnętrznego, jest powiązana obligatoryjnie tylko z jednym pracownikiem, który ją wystawił itd. Dopiero na etapie analizy wymagań decydujemy, czy czynność fakturowania będzie włączona w zakres projektu wdrożenia. Jeśli tak, to analizujemy, czy użytkownik sam wpisze potrzebne dane, czy - i w jaki sposób - zostaną one wyliczone.

Użycie modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne - wystarczy go opisać dodatkowo zakresem projektu i rozesłać do dostawców oraz zapytać, czy ich system pasuje do modelu, a także ile ten produkt kosztuje rok po roku. Jednocześnie dobrze wykonany model organizacji nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt jego wykonania, a często stanowią zbędne ograniczenia. Dobry model powstaje z użyciem standardów i dobrych praktyk. Do typowych standardów należą: notacja BPMN (Business Process Modeling Notation), UML (Uniefied Modeling Langualge), AchiMate/TOGAF, Siatka Zachmanna, Business Motivation Model. Do dobrych praktyk np. wzorce projektowe czy zalecenia Business Rules Group.

Z takim modelem kupujący nie musi udowadniać, że jego oczekiwania mają sens. Dostawca musi natomiast zdeklarować i wykazać, że jego produkt pasuje do modelu. Przygotowany wcześniej model jest też doskonałym narzędziem testowania dostarczonego produktu.

Autor jest związany z branżą IT od 1991 roku, od 2004 roku działa na rynku jako niezależny analityk wymagań i projektant oprogramowania.