Wstęp

Praktycznie każdy klient pyta mnie:

Czy wybrany dostawca oprogramowania będzie przeprowadzał własną analizę pod kątem wdrożenia z Pana aktywnym udziałem?

Na co zawsze odpowiadam, że:

Dostawca składa ofertę w odpowiedzi na otrzymane zapytanie, zawierające między innymi Raport z Analizy Biznesowej oraz Wymagania. Wybrany Dostawca jako pierwszy krok, na podstawie dokumentów jakie otrzymał, opracowuje Koncepcję Wdrożenia. Koncepcja Wdrożenia to dokument opisujący to, jak Dostawca planuje przeprowadzić wdrożenie swojego produktu, czyli jak spełni Wymagania. Składając ofertę Dostawca potwierdził, że jest w stanie wdrożyć Rozwiązanie i spełnić Wymagania, więc jakiekolwiek powtarzanie analizy firmy Zamawiającego nie ma prawa się wydarzyć. Wszelkie informacje potrzebne do opracowania Koncepcji Wdrożenia, Dostawca czerpie z treści otrzymanego Raportu z Analizy Biznesowej [z materiałów dostarczonych przez Zamawiającego], w razie dodatkowych pytań, Raport ten jest uzupełniany [przez jego autora w ramach nadzoru autorskiego]. Jeżeli dodatkowe pytania tego wymagają, mają miejsce dodatkowe konsultacje moje [autora analizy] z Zamawiającym. Takie podejście minimalizuje wszelkie (niestety bardzo częste) próby wpływu i perswazji Dostawcy na Zamawiającego w celu niekontrolowanego [przez Zamawiającego] wpływu na Wymagania.

Podsumowując: nie ma żadnego powodu, by Dostawca prowadził (powtarzał) jakąkolwiek “analizę”, opracowuje Koncepcję Wdrożenia, po jej zatwierdzeniu realizuje ją. Bardzo ważne! Umowa powinna zawierać klauzulę, gwarantującą obu stronom możliwość rozwiązania umowy w przypadku braku porozumienia co do treści Koncepcji Wdrożenia. (źródło: Jarosław Żeliński – Analizy i Badania Systemowe organizacji)

________

Tak więc analiza przedwdrożeniowa to jest jakaś praca, jej produktem mogą być różne treści. Dlatego właśnie warto pytać wykonawcę takiej analizy o to, co będzie jej produktem i do czego on posłuży. (źr. Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa ? gdzie różnica?).

Metodyk wdrożeniowych jest tyle ilu dostawców systemów i analityków. Ich przegląd pozwala je jednak uogólnić do następującej postaci:

1. Analiza przedwdrożeniowa.
2. Opracowanie koncepcji wdrożenia.
3. Wdrożenie.

Z opisów wynika, że pierwszy etap to najczęściej wywiady (warsztaty) z pracownikami, w ich wyniku powstaje specyfikacja wymagań. Równolegle lub później powstaje (najczęściej z udziałem kadr IT zamawiającego)  dokument: wymagania pozafuncjonalne (interfejsy, wydajności, platforma, bezpieczeństwo itp..). Najczęściej dostawcy oprogramowania piszą, że:

Nasi konsultanci zbierają od przedstawicieli firmy informacje o tym, jakie zadania ma realizować aplikacja (co?), a następnie przedstawiają najefektywniejsze rozwiązania funkcjonalne i techniczne (jak?) wraz z harmonogramem ich realizacji (kiedy?).

Kolejny przykład:

Koncepcja wdrożenia systemu, podczas której szkolimy Grupę wdrożeniową, przygotowujemy listy wymaganych raportów, wzorów dokumentów, instrukcji roboczych, opracowujemy koncepcję migracji danych i przygotowujemy procedury pracy. (dostawca oprogramowania)

Tu już temat wymagań spadł z listy, po prostu aplikacja ma być, a martwimy się się jak to zrobić by była. Inny pomysł, dostawca idzie jeszcze dalej – cel jest taki sam zawsze:

…proponujemy zwykle pewne sprawdzone rozwiązania, które przyniosą Klientowi mierzalne korzyści. Każde wdrożenie traktujemy indywidualnie, ale cel zawsze jest taki sam – wdrożyć system w zakładanym przez Klienta zakresie i czasie oraz przy kosztach nie wyższych niż planowane

Tak na prawdę dostawcy oprogramowania z reguły od razu zaczynają od punktu: koncepcja wdrożenia systemu XXX. Pojawia się często pojęcie sprawdzone rozwiązania. I nigdy nie wiem co to jest: wzorzec projektowy czy model referencyjny. Pierwszy jest tylko metodą (nadal nie mamy rozwiązania), drugi to najczęściej kopia pomysłu poprzedniego klienta.

Nie zmierzam do krytyki tego podejścia, chce pokazać, że to naturalna, z perspektywy dostawców oprogramowania, koncepcja, bo biznesowy cel każdej z tych firm to sprzedaż i wdrażanie oferowanych przez siebie produktów.

Do czego zmierzam?

Do tezy, mówiącej: skoro dostawcy oprogramowania zaczynają od opracowania koncepcji wdrożenia swojego produktu, to ktoś powinien przed nimi opracować w ramach analizy przed, specyfikację potrzeb. Aby powstała specyfikacja potrzeb powinien ktoś zdefiniować problem, wskazać możliwe rozwiązania i ocenić ich wykonywalność.

Nie ma także sensu szukanie problemu na siłę tylko po to, by wdrożyć jakieś oprogramowanie bo jego sprzedawca tak chce. Dostawcy gotowego oprogramowania powinni się w końcu pogodzić z prostym rynkowym faktem: to oni są wybierani a nie oni wybierają, dokładnie tak jak każdy inny produkt na rynku.

Analiza systemowa jako analiza przedwdrożeniowa

Posłużmy się czymś takim jak Klasyczna analiza systemowa.

Analiza systemowa to “dziedzina wiedzy dotycząca poznania układów organizacyjnych i sposobów ich działania. Umożliwia łączenie dorobku różnych dziedzin nauki wokół wybranych problemów. Ma charakter interdyscyplinarny i syntetyzujący, służąc projektowaniu przyszłych struktur i działań w oparciu o kryteria sprawnościowe. Doskonali i upowszechnia skwantyfikowane metody analizy wykorzystując metodę modelowania matematycznego i teoretyczne konstrukcje odzwierciedlające w uproszczony sposób rzeczywistość. Badania operacyjne stanowią podstawę analizy systemowej. Analiza systemowa ? to sztuka poznawania i określania systemów drogą budowania modeli.

Występujące w otaczającym nas świecie zjawiska np. przyrodnicze, społeczne, gospodarcze, techniczne, bez względu na ich rodzaj, zwykło się w potocznym rozumieniu nazywać systemami. Za systemy uważa się również konstrukcje abstrakcyjne, takie jak liczby, informacje, pojęcia, zadania, teorie. Analogicznie jako system traktuje się także zbiorowości wskazanych wyżej towarów konkretnych i abstrakcyjnych. (źr.http://mfiles.pl/pl/index.php/Analiza_systemowa)

Produkty pośrednie i końcowy takiej analizy:

1. Ograniczenia, cele, kryteria
2. Opis wariantów
3. Scenariusze i ich skutki
4. Rekomendacje jako wynik analizy

Jakich produktów należało by oczekiwać w analizie przedwdrożeniowej czyli, jak sama nazwa wskazuje, poprzedzającej jakiekolwiek wdrożenie. Ano, bazując na produktach klasycznej analizy systemowej:

1. Opis aktualnej sytuacji firmy i cel jaki chce zrealizować
2. Opis i ocenę możliwych wariantów realizacji tego celu.
3. Analiza scenariuszy dla każdego wariantu, materiałem do pracy tu są modele organizacji analizowanej  (tu są i po to modele procesów biznesowych), możliwe, że jedną z metod osiągnięcia celu jest ich optymalizacja.
4. W wyniku analizy wyników tych testów (proof-of-concept) mamy rekomendacje, to one zawierają listę tego czym powinno się charakteryzować oprogramowanie, jeżeli okaże się, że to możliwy sposób na realizacje celu (bo nie koniecznie).

Tak więc, gdyby uznano, że należy kupić i wdrożyć oprogramowanie to należy dokonać jego wyboru. Mając modele (procesy i taksonomie) pokazujemy je dostawcy oprogramowania i pytamy czy jego produkt pasuje do naszego modelu. Może pasować w części lub całości. Po ocenie kilku takich ofert:

1. Znajdujemy oprogramowanie pasujące do całego naszego modelu i wdrażamy.
2. Znajdujemy oprogramowanie pasujące tylko do części naszego modelu, wybieramy najlepsze. Dla pozostałych potrzeb  wykonujemy projekt ich logiki: to projekt budowy (mechanizm działania) brakującego modułu, usługi aplikacyjnej lub odrębnej aplikacji.

Mamy więc analizę biznesową i specyfikowanie wymagań poprzez opracowanie weryfikowalnych modeli a nie tylko listę potrzeb, której niestety nie da się zweryfikować co do kompletności i spójności bo nie ma narzędzia sprawdzającego. Co jest takim narzędziem? Ano modele i to, że powstały (jeżeli powstały) przy pomocy sformalizowanej notacji.

Projekt taki ma trzy wyróżnione etapy i produkty zarazem. Pierwszy, analiza biznesowa, to tworzenie modelu procesów biznesowych i taksonomii organizacji. Celem tego etapu jest stworzenie modeli, które w dalszej części prac niejako zastąpią nam firmę (opisują ja w sposób kompletny). Są one zawsze testowane a jeżeli zajdzie taka potrzeba, także optymalizowane. Jest to kluczowy etap całej analizy przedwdrożeniowej. Są to podstawowe modele, posłużą do testowania hipotez (scenariuszy) opisujących cele biznesowe i rentowność (patrz wcześniejszy opis analizy systemowej) a później będą podstawą ewentualnego projektowania oprogramowania.

Kolejny etap to specyfikowanie wymagań. Rzadko kiedy daje się dostawcom oprogramowania model procesowy z uwagi na to, że nie precyzuje on dokładnie zakresu projektu (opisuje cała firmę). Dlatego dla dostawcy oprogramowania tworzy się Specyfikacje Wymagań, powstaje ona w języku dostawcy. Zależnie od konwencji powstaje specyfikacja zawierająca: opis koncepcji rozwiązania, stanowi ona opis i kontekst całości.  Kolejnym elementem są wymagania funkcjonalne (usługi aplikacji, jej przypadki użycia) i ich ograniczenia (ja raczej nie stosuje terminu wymagania pozafunkcjonalne). Ograniczenia są kojarzone z poszczególnymi wymaganiami a uogólniane na całość. W tej części stosuję modele przypadków użycia (notacja UML).

Ostatni etap to projektowanie. Polega na przeprowadzeniu analizy obiektowej i zaprojektowaniu koncepcji architektury rozwiązania oraz opracowania modelu dziedziny czyli modelu realizacji logiki biznesowej pzrez przypadki użycia (patrz wcześniejsze artykuły).

Analizę biznesową wykonuje zawsze z powodów chyba oczywistych. Specyfikowanie wymagań, jeżeli przedmiotem projektu będzie oprogramowanie. Projektowanie dotyczy tych elementów, które nie znalazły się w gotowym oprogramowaniu i potrzebne są dedykowane podsystemy.

Czy to kosztowna metoda? Z moich wyliczeń ryzyka finansowego wynika, że progową wartością jest budżet na cały projekt rzędu ok. 75 tys. zaś analiza jest ustalonym procentem tej wartości (odzwierciedla postrzegane ryzyko projektu).

Dla dostawców powstaje tu kluczowe ryzyko: ich produkt może, w części lub całości, nie spełniać wymagań określonych przez model firmy i specyfikację wymagań. Może się okazać się, że ich produkt zupełnie nie nadaje się dla tej konkretnej firmy. Dlatego dostawcy często od razu sugerują opracowanie koncepcja wdrożenia, która tak na prawe jest  studium możliwości wdrożenia konkretnego produktu, w konsekwencji powstaje lista tego co wymaga modyfikacji i lista tego co nie zostanie zrealizowane. Produkt gotowy z definicji ma ograniczenia wdrożeniowe bo jest, mimo deklarowanej parametryzacji,  gotowym produktem a nie narzędziem programistycznym. Z tego powodu moim zdaniem, można już zauważyć na rynku pakiety ERP zmierzające w stronę bycia środowiskiem programistycznym. Tu warunkiem ich podatności na zmiany jest to, czy wewnętrzna integracja realizowana jest poprzez współdzielenie danych czy poprzez ich wymianę (pomiędzy modułami). Pierwsza metoda w moich oczach dyskwalifikuje produkt, bo praktycznie jego modyfikowalność jest bardzo ograniczona.

Czy dostawca oprogramowania może wykonać tak opisaną analizę? Może. A może sam kupujący? Też może. więc o co chodzi? O posiadane kompetencje i ryzyko braku obiektywizmu:

Bardzo często spotykam się ze stosowaniem normy IEEE opisując specyfikację wymagań (napisałem o tym dwa lata temu, przeczytaj). Norma ta, IEEE830-1998,  jednak w żadnym stopniu nie opisuje jak specyfikacja ma powstać, opisuje tylko co ma  zawierać dokument i zwraca uwagę, że dokument powinien być spójny a wymagania weryfikowalne, opisu jak to osiągnąć nie ma.

Problemem jest nie to, jak zapisać wymagania, bo to mały problem, a to skąd je wziąć.

Inny cytat na koniec:

jest wiele metod, narzędzi, sposobów zapisu i modelowania wymagań, pewnie moglibyśmy długo się sprzeczać, które są lepsze, a które gorsze. Chodzi jednak tak naprawdę o wartości jakimi powinniśmy się kierować specyfikując wymagania – powinny one być zrozumiałe dla przyszłych czytelników, powinny być jednoznaczne, spójne, weryfikowalne, łatwe do zmiany, kompletne i poprawne. (źr. Blog O wymaganiach)

_____

Tak więc?

Obecnie już widać, że najskuteczniejszą formą dokumentowania wymagań, przekazywanych dostawcy rozwiązania, jest opracowanie projektu. Dokładnie tak jak w każdej innej “inżynierii”. Słowny i para-słowny (tabelki itp.)  opis koła zębatego nigdy nie zastąpi rysunków technicznych…