Wprowadzenie

Zanim napiszę dlaczego prawnik to świetny analityk biznesowy, opiszę problem jaki jest do rozwiązania. O prawniku będzie w drugiej części.

Od ponad 20 lat prowadzę analizy biznesowe, projektuję informatyczne systemy przetwarzania danych, zarządzające przepływem informacji. Obserwuję stały postęp narzędzi oraz rozwój metod prowadzenia analiz, ale także brak (ale nie w 100%) postępu w uzyskiwanych efektach :

Czemu tak sie dzieje? Metody realizowania projektów przez większość dostawców IT nie zmieniły sie od 30 lat: rozmowy, wywiady, kodowanie, kosztowne narzędzia (C++, Java). Od 20 lat wiemy, że napisanie programu w C++/Java to dwukrotnie większa pracochłonność w porównaniu do identycznego efektu uzyskanego językami skryptowymi . Stała popularność C++/Java ma swoje źródło: większość dużych systemów w branży fin/tech powstała w latach 90-tych, nie są unowocześniane a jedynie uzupełniane są o kolejne funkcjonalności mimo, że nie jest tajemnicą jak dokonać migracji do nowszych techniologii i architektur .

Powody są dość prozaiczne: dopóki jest popyt, dostawcy technologii nie mają żadnego interesu w unowocześnianiu swoich produktów i sprzedają permanentny dług technologiczny .

Skąd się u wielu użytkowników technologii IT bierze dług technologiczny już w momencie podpisania umowy na wdrożenie? Stąd, że zlecono analizę przedwdrożeniową wymagań dostawcy technologii, a w jego interesie jest dostarczyć to co ma, a nie to czego potrzebuje klient.

(https://it-consulting.pl/2011/11/20/czego-najwieksze-firmy-technologiczne-nie-mowia-swoim-klientom/)

Dlatego nadal mówi się i pisze, by nie powierzać dostawcom technologii prac nad analizami wymagań i zarządzania wdrożeniami:

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

(https://www.techradar.com/news/what-hertz-v-accenture-teaches-us-about-failure-in-systems-development-projects)

Tak więc pozostaje zrobić to samemu, ale jak? Wiemy też na pewno, że nie jest dobrym pomysłem przeprowadzenie wewnętrznych warsztatów z pracownikami i samodzielne spisanie “wymagań”, gdyż tak powstają najbardziej niespójne i niekompletne opisy wymagań . Więc jak?

Ideałem jest zaangażowanie zewnętrznego analityka projektanta, z zastrzeżeniem że nie może on być dostawcą systemu. Jest to metoda znana od lat, ale nadal rzadko stosowana z uwagi na to, że “mało kto tak robi”, oraz z powodu powszechnego przekonania, że “dostawca ma lepszego analityka i projektanta” (mimo, że teza taka nie ma żadnego uzasadnienia w faktach ). Powodem jest także to, że zaufanie do osób z zewnątrz w wielu firmach jest bardzo małe, co powoduje, że nie każdy zarząd decyduje się na taką współpracę.

Orientacja na artefakty

Jak już wspomniano wywiady z pracownikami dają jako produkt niespójny i niekompletny opis organizacji. Dlatego od wielu lat mówi się, że organizacje doskonale opisują artefakty jakie ona ona wytwarza i to na ich podstawie, a nie na podstawie wywiadów, należy prowadzić analizy i projektować systemy. Czym są te artefakty?

Artefakt to konkretny, możliwy do zidentyfikowania, samoopisujący się fragment informacji, który może być wykorzystany przez osobę prowadzącą działalność gospodarczą do jej prowadzenia. Czasami określamy artefakty jako dokumentację biznesową, a niektórzy ludzie biznesu wydają się preferować tę terminologię. Aby artefakty były przydatne do rzeczywistego prowadzenia biznesu, w przeciwieństwie do abstrakcyjnego modelu do analizy, muszą być rozpoznawalne; to znaczy, muszą zawierać informacje w jednym miejscu. Wszyscy słyszeliśmy zwykłe stwierdzenie frustracji: “Ale ja nie mam tu wszystkich potrzebnych informacji”. Wymagania dotyczące bycia wrażliwym na potrzeby biznesu i samoopisującym się są napędzane bardzo mocno z perspektywy poznawczej właściciela biznesu. Artefakty są traktowane jako jedyna jawna informacja zawarta w biznesie; to znaczy, że jest to zbiór zapisów biznesowych reprezentujących zawartość informacyjną biznesu.

Innymi słowy: artefakty to dokumenty operacyjne i ich treść, przetwarzane i wytwarzane w toku funkcjonowania organizacji, oraz wszelkie ślady i skutki tego przetwarzania.

Podejście skoncentrowane na artefaktach biznesowych traktuje dane jako integralną część procesów biznesowych, a procesy biznesowe i ich operacje definiuje w kategoriach współdziałających kluczowych artefaktów biznesowych (BA, business artifact). Każdy typ BA jest charakteryzowany przez model informacyjny i model cyklu życia. Model informacyjny rejestruje wszystkie istotne z punktu widzenia biznesu informacje o instancji BA w miarę jej przemieszczania się w przedsiębiorstwie. Cykl życia określa wszystkie możliwe ewolucje instancji BA w czasie. Jako przykład BA, rozważmy bank CheckingAccount, który rejestruje wszystkie informacje o koncie od momentu jego otwarcia przez klienta do momentu jego ostatecznego zamknięcia i zarchiwizowania, z cyklem życia rejestrującym wszystkie istotne stany konta, możliwe przejścia, operacje, itp.

Metody analizy i projektowania oparte na artefaktach są także w literaturze opisywane jako evidence-based system engineering .

Klasyczna metoda prowadzenia analizy nadal w cenie i nie raz już tu była opisana, a czy jest jakaś alternatywa? Tak! Jest światełko w tunelu!

Prawnik jako analityk

Tak! Od kilku lat eksperymentuję z Regulaminami (regulaminy sprzedaży, świadczenia usług, itp.) jako podstawowymi źródłami potrzeb biznesowych. I okazuje się, że bardzo często stanowią one prawie doskonałą specyfikację potrzeb, na podstawie której można nie raz zaprojektować nawet 80-90% całości systemu! Owszem bywają niespójne regulaminy, ale to się zdarza bardzo rzadko. Najczęściej opracowanie takiego regulaminu zleca się prawnikom, a Ci bardzo skrupulatnie analizują wszelkie obowiązki i ryzyka na każdym etapie realizacji obsługi klientów czy też realizacji zadań wewnętrznych (poza regulaminami obsługi klientów mamy też różne regulaminy wewnętrzne).

W efekcie zamiast pracować z niespójna i pełną sprzeczności (typowe efekty warsztatów i burz mózgów) listą życzeń pracowników organizacji, znaczenie efektywniej pracuje się z Regulaminem. Jeżeli ma powstać sklep internetowy będzie to np. Regulamin Sklepu Internetowego, jeżeli ma postać system CRM doskonały materiałem będzie wewnętrzny Regulamin Obsługi Klienta. Jeżeli ma powstać system zarządzania przepływem faktur kosztowych należy zacząć prace od opracowania Regulaminu Przepływu Faktur Kosztowych (tu raczej dział księgowości będzie wiódł prym).

Przyjęcie założenia, że na podstawie regulaminów można zaprojektować oprogramowanie jest sprawdzone, warunkiem jest: (1) zakres projektu to obszar opisany tymi regulaminami, (2) zakres projektu to obszar administracyjny (obsługa zapytań i zamówień to też ten obszar, nie przypadkiem zwany nie raz back-office), (3) regulaminy nie odnoszą się do (nie zawierają w treści) nazw i cech narzędzi i oprogramowania a jedynie do czynności, reguł ich wykonania i wzorów dokumentów. Ten ostatni warunek jest najważniejszy i niestety często nie jest spełniony, w toku analizy staje rekomendacją do zmiany.

Dwa alternatywne warianty:

Wariant 1 to standardowe podejście: decyzja o projekcie i planowanie i analiza biznesowa. Na podstawie wyników analizy biznesowej i rekomendacji prawnicy (Organizacja analizowana) opracowują Regulamin (usługi, portalu itp.), całość stanowi sobą wymagania i projektowany jest docelowy system. Tu opracowanie Regulaminu polega na wykorzystaniu wyników analizy biznesowej.

Wariant 2 to rzadsze podejście, polegające na wykorzystaniu wcześniej wykonanej pracy nad opracowaniem Regulaminu. To sytuacja w której taki wypracowany Regulamin już istnieje, albo – do czego nie raz zachęcam moich klientów – Regulamin jest opracowany celowo jako element przygotowania materiałów do analizy. Dość często w organizacji jest dział prawny lub ma ona stałą obsługę prawną. Są to osoby znające firmę, i praktyka pokazuje, że mają duża wiedzę o swoim kliencie. Mają też tę zaletę nie są to emocjonalnie związani z firmą jej menedżerowie. Prosze nie zapominać, że pracownicy firmy zaangażowani w proces zbierania wymagań na przyszły system informatyczny są emocjonalnie związani ze swoim obecnym stanowiskiem i dotychczasowym stylem pracy, mają więc pewien konflikt interesu i nie zawsze są obiektywni. Czy to ich zła wola? Nie, to emocje które są ryzykiem projektu, a nie złą wolą tych ludzi.

Podsumowanie

Ścisła współpraca z działem prawnym firmy analizowanej potrafi przynieść duże korzyści. Bardzo często są to ludzie dobrze znający firmę, obyci w opracowywaniu zasad świadczenia usług, reguł postępowania. Regulaminy to dokumenty na dość wysokim poziomie formalizacji, co bardzo pomaga w pracy z nimi. Projektowanie na ich podstawie logiki biznesowej systemu informatycznego jest znacznie łatwiejsze niż na podstawie opisów przygotowanych przez tak zwany “biznes”.

Od kilku lat testuję tę metodę projektowania systemów, w ww. obszarach sprawdza się bardzo dobrze. W czasie prowadzenia zajęć laboratoryjnych ze studentami na kierunku Inżynieria Oprogramowania uczą się oni wychwytywania w Regulaminach sformułowań, które stanowią materiał na słownik pojęć i reguły biznesowe, na aktorów i nie raz nawet na moduły aplikacji. Są to metody oparte na ontologicznych analizach tekstowych . W połączeniu z metodami opisu reguł biznesowych z użyciem tablic decyzyjnych, stanowią bardzo dobre narzędzie do pracy nad artefaktami jakimi są teksty biznesowe, a regulaminy do takich należą .

Przykładowe projekt i analiza na podstawie Regulaminu

Poniżej do pobrania dwa pliki pdf, opracowania wykonane w całości tylko na podstawie Regulaminu.”

Drugi to wynik analizy Regulaminu i rekomendacje do poprawy jego jakości:

Źródła