Ten tekst to samouczek dla zespołu ekspertów i recenzentów firmy analizowanej. Zawiera między innymi legendy symboli używanych w dokumentacji schematów blokowych. Zastąpienie go szkoleniem/warsztatem on-line to dodatkowa, płatna usługa w projekcie.

Jest to opis dla każdej firmy zawierającej ze mną umowę. Proszę się dokładnie zapoznać z poniższą treścią, ten dokument opisuje standardowy sposób komunikacji w każdym moim projekcie. W tekście tym opisuję dlaczego pracuję na dokumentach i jakich narzędzi używam do prowadzenia komunikacji i wymiany treści. UWAGA! Firmy produkcyjne powinny dysponować raportem z audytu produkcji, ja nie prowadzę takich audytów ani wizji lokalnych.

Wymagane materiały źródłowe zostały opisane poniżej i oznaczone szarym tłem. Rolą członków zespołu Zamawiającego jest nie tylko dostarczanie materiałów źródłowych ale także aktywny udział w roli recenzentów powstających treści, dlatego poniżej opisano podstawowe typy i cele tworzenia określonych schematów blokowych, legendy użytych symboli oraz przykłady ich użycia. Opisano także narzędzie służące do komunikacji. Wystarczającą umiejętnością recenzenta jest czytanie tych schematów, ich opisów i zgłaszanie merytorycznych uwag (co jest nieprawdą, czego brakuje).

Wszelkie wątpliwości są wyjaśniane na spotkaniach statutowych.

Komunikacja asynchroniczna i synchroniczna

Praca zespołowa i zarządzanie czasem oraz efektywność wymagają planowania. Spotkania są najmniej efektywnym sposobem pracy audytorsko-eksperckiej. Dlatego od wielu lat dzieli się komunikacje na synchroniczną (komunikacja odbywa się w czasie rzeczywistym, spotkanie, telekonferencja, komunikatory) oraz asynchroniczną (korespondencja).

Nie jest możliwe wyeliminowanie synchronicznej komunikacji (np. krótkie spotkania statusowe w projektach) jednak znakomita większość prac analityczno-projektowych tych spotkań nie wymaga spotkań i warsztatów, prace tego typu są znacznie efektywniejsze jako praca realizowana zadaniowo.

Dlatego od wielu lat pracuję zadaniowo, zdalnie, metodą asynchroniczną. Spotkania to standardowe cotygodniowe jednogodzinne omawianie postępów w projekcie, dodatkowe spotkania na żądanie Zamawiającego są rozliczane jako czas dodatkowy. Standardowo pracuje na przesłanych mi materiałach, eksperci analizowanej organizacji, standardowo mają na odpisywanie mi czas do dwóch dni.

Metody i narzędzia komunikacji w projekcie

Narzędzia:

• mój adres email: j.zelinski@it-consulting.pl lub info@jaroslawzelinski.biz,
• dokumentacja projektowa on-line: Postmania (powiadomienia przychodzą z adresu: support@visual-paradigm.com),
• oferty, zamówienia i rozliczenia: FreshBook (powiadomienia przychodzą z adresów: mail@fb02.freshbooks.com, mail@fb05.freshbooks.com, welcome@fb02.freshbooks.com).

Podstawowym celem komunikacji jest dostarczanie mi materiałów źródłowych i recenzowanie (uwagi do treści) powstającej lub aktualizowanej dokumentacji analityczno-projektowej: jest nią Analiza Biznesowa i Opis Techniczny Rozwiązania (dalej Specyfikacja). Dostawcą materiałów źródłowych jest zawsze zespół organizacji analizowanej (tu Recenzent).

Powyższa pętla to raz kilka godzin a raz natychmiastowa odpowiedź. Jest to typowa tak zwana komunikacja asynchroniczna. Uczestnicy piszą lub odpisują w dogodnym dla siebie momencie, co nie zaburza ich normalnej codziennej pracy i obowiązków. Tak powstająca i aktualizowana dokumentacja projektowa (analiza biznesowa, specyfikacja wymagań) to tak zwana “Żyjąca dokumentacja” .

W trakcie projektu nie używam pakietów biurowych, nie tworzę arkuszy kalkulacyjnych ani dokumentów w edytorach tekstów. Produktem “do czytania” (i do ewentualnego druku) jest dokument PDF stanowiący pełną specyfikację z diagramami i opisującym je tekstem. Jako produkt pracy przekazuję także edytowalny plik źródłowy (Visual-Paradigm oraz w uniwersalnym formacie XMI) zawierający wszystkie opisy, opracowane modele i struktury.

Dodatkowe spotkania i warsztaty na życzenie Zamawiającego (nie dotyczy spotkań statusowych) są rozliczane jako dodatkowe prace T&M.

Do zdalnej pracy wykorzystuję, i udostępniam klientom, jedno z najlepszych narzędzi wspierających takie projekty na rynku: oprogramowanie PostMania firmy Visual-Paradigm, z którego korzystają największe koncerny na świecie (lista i referencje wybranych użytkowników pakietu Visual-Paradigm, bezpieczeństwo wykorzystywanego repozytorium VP). Visual-Paradigm to narzędzie CASE (ang. Computer Aided System Engineering, komputerowe wspomaganie inżynierii systemów). Stosuję go w całym procesie analizy i modelowania, oraz w toku tworzenia dokumentacji projektowej i zarządzania nią.

Wszystkie przesłane mi dokumenty są na serwerze chronione (kodowane), ich kopie zapasowe są wykonywane w trybie dobowym. Powstające treści są wersjonowane, wprowadzane zmiany są śledzone i dokumentowane. Każda nowa treść lub jej zmiana (zwana korektą – revision) jest odnotowywana, oznaczona w czasie i numerowana.

Zapoznaj się z opisem: Visual Paradigm PostMania – Przewodnik Recenzenta.

Analiza biznesowa – materiały źródłowe i produkty analizy

Na tym etapie powstają: opisy biznesowych celów projektu, model struktury organizacyjnej, modele procesów biznesowych, opisy dokumentów biznesowych, biznesowy słownik pojęć. Podstawowym materiałem źródłowym są wszelkie wewnętrzne i zewnętrzne regulaminy i zasady, przykładowe dokumenty i opisy, wypełnione ankiety.

Na czym polega realizacja projektu analitycznego?

Pełny zakres projektu analitycznego to opracowanie tak zwanej Architektury Korporacyjnej. To nic innego jak zestaw powiązanych schematów blokowych (modeli) opisujących organizację od jej strategii rynkowej, przez procesy biznesowe, do infrastruktury IT, w sposób identyfikujący ich wzajemne powiązania i wpływ. Poniżej schemat obrazujący te modele i powiązania:

Pełny zakres analizy to opracowanie: modelu map i modeli procesów biznesowych (Business Process), listy potrzeb wobec systemu IT (Business Services), architektury integracji wysokiego poziomu (Components). Dostawcy systemów oferują swoje rozwiązania i dostarczają specyfikacje techniczne swoich produktów (Operational Resources). Kluczowe dla całości są: definicje zadań i tego jak będą (są) realizowane w systemie IT (task definition, task implementation) oraz ich odwzorowanie na systemy IT (Interface defined by enterprise semantic and requirements).

Zakres projektu może być ograniczony po uzgodnieniach z Zamawiającym.

W toku analiz powstają kolejne schematy blokowe i modele. Na etapie trwania prac analityczno-projektowych operujemy draftem opracowania. Zamawiający i recenzenci mają dostęp “tylko do odczytu”. Po przekazaniu dokumentacji Zamawiającemu (prawa majątkowe wraz z prawem do tworzenia utworów zależnych), może on tworzyć jej kolejne wersje (jako autor przekazuję także prawa do tworzenia utworów zależnych) lub prace te realizuje autor dokumentacji w ramach zleconego mu nadzoru autorskiego i nadzoru merytorycznego nad pracami dostawców systemów.

W dalszej części opisano powstające w toku analizy i projektowania produkty i wymagane materiały źródłowe (oznaczono szarym tłem).

Biznesowy cel projektu

Zalecanym początkiem analizy jest określenie biznesowego celu projektu na tle misji i wizji organizacji (patrz: Audyt spójności wizji i misji organizacji z jej działaniami):

• misja: (jak sobie wyobrażamy nasz przyszły rynek),
• wizja: (nasz wkład w osiągnięcie powyższego stanu rzeczy),
• cel biznesowy organizacji: (planowana pozycja na rynku, fuzja, inne),
• kluczowy problem: (co jest głównym powodem inicjacji projektu).

Struktura organizacyjna

Podstawą zrozumienia działania organizacji jest jej struktura organizacyjna. Jest ona także słownikiem ról i kompetencji na modelach procesów biznesowych. Dokumentowana jest poniższą metodą:

Powyższy schemat to sformalizowana struktura organizacyjna zobrazowana jako “drzewo zależności przełożony-podwładny” (lub komórka nadrzędna podrzędna). ‘Unit’ oznacza komórkę lub rolę (odpowiedzialność).

Przepływ pracy i dokumentów czyli procesy biznesowe

Definicja procesu biznesowego brzmi:

zdefiniowany zestaw działań biznesowych, które reprezentują kroki wymagane do osiągnięcia celu biznesowego, obejmuje przepływ i wykorzystanie informacji oraz zasobów.

Notacja BPMN, Glossary

Dlatego model procesów to diagram obrazujący łańcuch aktywności i ich celów (dokumenty jako informacje). Zasoby są reprezentowane przez role wykonawców. Detale każdej aktywności, jeżeli są wymagane, dokumentowane są osobno jako komentarze i ich procedury (patrz opis: Proces a procedura)

Na powyższym schemacie pokazano proces biznesowy: aktywności oraz ich dane wejściowe i wyjściowe. Wszelkie dodatkowe detale niosą dokumenty (symbole z zagiętymi rogami na diagramie powyżej), reguły biznesowe (spisywane w postaci zestawienia w treści opracowania lub na schematach np. powyżej: Budżetowanie. BR002).

Model procesów biznesowych zawiera nazwy dokumentów. Ich struktury niosą detaliczne informacje o przetwarzanych danych i związkach między nimi, są dodatkowo dokumentowane jako szablony, np. jak ten poniżej:

Struktury te uzupełniamy regułami ich poprawności (reguły biznesowe), definicje pól i obszarów to element biznesowego słownika pojęć (zawiera między innymi nazwy wszystkich kluczowych elementów na diagramach opisujacych dokumenty i formularze).

Biznesowy słownik pojęć – ontologia

Podstawą zrozumiałości i jednoznaczności dokumentacji jest jednolity, spójny i kompletny słownik pojęć dla całego projektu (generalnie dotyczy całej organizacji). Celem jest zapewnienie jednoznaczności treści nie tylko dokumentacji projektowej ale też wszystkich elementów na modelach procesów, dokumentach (formularzach) i ekranach systemu jakim jest oprogramowanie. Co do zasady słownik ma postać alfabetycznej listy, jednak kluczowe pojęcia dziedzinowe, dodatkowo weryfikujemy z pomocą tak zwanego modelu pojęciowego (diagram klas UML, lub model faktów SBVR, ). Jest to schemat blokowy, na którym umieszczamy wybrane pojęcia i łączymy je związkiem generalizacji lub określonym faktem (predykat). W ten sposób sprawdzamy, czy pojęcia te tworzą parami poprawne i prawdziwe zdania w języku naturalnym danej dziedziny wiedzy. Np. poniżej:

Powyższe czytamy:

• kopia dokumentu i oryginał dokumentu to rodzaj (typ) dokumentu
• faktura jest typem dokumentu
• system kancelaryjny zapewnia poprawny obieg dokumentów
• dokument jest przyporządkowany do sprawy

UWAGA! Ten diagram to nie jest proces biznesowy! To model pojęciowy stosowany do modelowania i weryfikacji słownictwa dziedzinowego, podobny jak te budowane w systemach sztucznej inteligencji.

Wymagania na oprogramowanie

Wymaganiem na oprogramowanie jest treść opisu jego działania: Opis Techniczny Oprogramowania (patrz: proces ICONIX). Poniżej jego kluczowe opisano elementy. Jednak gorąco odradzam tu samodzielne spisywanie “co i jak system ma coś robić” albo, co gorsza, samodzielne tworzenie niesformalizowanych schematów blokowych i opisów procesów czy systemów IT, gdyż przynosi to więcej szkody niż pożytku: samodzielne opracowywanie tych schematów prostymi programami biurowymi, przez nieprzygotowane do tego i niedoświadczone osoby, jest pracochłonne a uzyskane efekty i tak zawsze wymagają analizy i formalizacji przez analityka .

Usługi systemu czyli Co system ma robić

Każde oprogramowanie (aplikacja) można opisać skończoną listą usług jakie to oprogramowanie świadczy elementom swojego otoczenia (użytkownik i inne aplikacje). Jeżeli to oprogramowanie jest dopiero planowane do zakupu, to lista taka jest zbiorem wymagań wobec tego nowego oprogramowania. Na tym etapie nie ma znaczenia to czy będzie to oprogramowanie standardowe czy dedykowane.

Do zbudowania takiej listy można użyć burzy mózgów, jednak z powodów opisanych na początku, znacznie efektywniejszą metodą jest analiza biznesowa i wskazanie na modelach procesów aktywności, które chcemy wesprzeć oprogramowaniem (transformacja modelu procesów na model wymaganych usług aplikacji). W efekcie powstaje prosty diagram (diagram przypadków użycia UML), stanowiący zobrazowanie usług aplikacji jakich oczekujemy od nowego oprogramowania:

Potrzeby Zamawiającego czyli wymagania biznesowe

Kolejny etap to zebranie listy potrzeb przyszłych użytkowników. Są to wyrażone językiem biznesowym (naturalnym) oczekiwania wobec tych usług.

Kluczowe pojęcie na tym etapie to

Wymagania biznesowe (także capability requirement) to zestawienie potrzeb wyrażonych jako ‘potrzeby interesariuszy’. Sa one przypisywane do usług aplikacji (przypadki użycia, poprzedni rozdział). Zestawienie to należy dostarczyć w postaci zestawienia:

Mechanizm działania systemu

Każda usługa aplikacji cechuje się określonym mechanizmem jej realizacji. Standardowo przypisuje się jej określony dokument z modelu procesów a ona sama stanowi osobny komponent systemu.

Stany i statusy dokumentów

Na etapie dokumentowania usług aplikacji mogą sie pojawić inne, uzupełniające schematy blokowe:

Poszczególne dokumenty/formularze mogą mieć stany i statusy. Modelowane są one jak poniżej:

Architektura systemu

Na etapie opisu wymagań nie wiadomo, które usług aplikacji zrealizuje wybrane oprogramowanie (np. ERP). Aplikacje dedykowane wymagają opisania architektury HLD i LLD. Z uwagi na specyfikę każdej organizacji wymagane jest także zaprojektowanie integracji systemów. Jednak adresatem tych dokumentów są inżynierowie dostawców, nie są one recenzowane przez Zamawiającego.

Spotkania

W ramach realizowanej usługi odbywają się spotkania statusowe (ustalenia planowanych działań w projekcie). Wszelkie dodatkowe warsztaty inicjowane przez Zamawiającego stanowią dodatkowe płatne spotkania.

Spotkania są realizowane jako video- i tele- konferencje. Standardowo wysyłam link do spotkania on-line. Jeżeli macie Państwo w swojej firmie wdrożony swój własny system wideokonferencyjny, może być on używany w projekcie. Jedynym ograniczeniem jest brak konieczności instalowania dedykowanego oprogramowania na moim komputerze.

Etap realizacji po wyborze dostawcy

Po wyborze Wykonawcy, na podstawie dokumentu Analiza Biznesowa i Opis Techniczny Systemu (Analiza), Wykonawca opracowuje dokument Koncepcja Wdrożenia, który zawiera opis sposobu spełnienia wymagań opisanych w Analizie (pierwotnie stanowi ona załącznik do Zapytania Ofertowego). Dotyczy to każdego Wykonawcy z osobna: modele integracji są w Analizie.

Wszelkie wątpliwości dotyczące treści Analizy (brakujące detale, niejednoznaczności itp.) Wykonawca wyjaśnia zadając pytania do treści Analizy (pytania przekazuje autorowi Analizy lub Zamawiającemu). Po wypracowaniu odpowiedzi po stronie Zamawiającego Analiza jest aktualizowana i przekazywana wykonawcy jako odpowiedź na zadane pytania. Co do zasady Analiza jest jedynym dokumentem źródłowym dla Wykonawcy.

Koncepcja Wdrożenia, stanowi szczegółowy opis tego co wykona i dostarczy Wykonawca. W toku realizacji jeżeli Wykonawca pyta o kolejne potrzebne mu detale, w odpowiedzi dostaje uszczegółowioną Analizę. Na tej podstawie aktualizuje Koncepcję Wdrożenia o kolejne detale realizowanej implementacji (wdrożenia). W takim cyklu postępują kolejne prace wdrożeniowe.

W ten sposób, w dniu zakończenia projektu dokument Analiza stanowi dokument opisujący firmę Zamawiającego na dzień zakończenia wdrożenia, a dokument Koncepcja Wdrożenia stanowi dokumentację powykonawczą dostarczonego rozwiązania . W całym projekcie Analiza i Koncepcja Wdrożenia, to jedyne formalne dokumenty projektowe. Pisemne wnioski o ich uzupełnienie stanowią wyłącznie historię przyczyn zmian, załączniki.

W całym projekcie podstawowym narzędziem komunikacji jest system Postmania. Inne narzędzia wymagają uzgodnienia, jednak sam proces nie ulega zmianie: jedynym źródłem informacji dla Wykonawcy jest analiza, wszelkie inne robocze dokumenty (notatki ze spotkań i rozmów) stanowią materiał źródłowy do aktualizacji Analizy.

Źródła