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. Możliwe jest zastąpienie go jednodniowym szkoleniem/warsztatem on-line dla zespołu. Jest to dodatkowa, płatna usługa w projekcie.

Jest to opis dla każdej osoby i 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.

Kanały komunikacji

W toku współpracy przed i po zawarciu umowy używam:

1. na etapie nawiązywania kontaktu jest to email i Formularz Zapytania
2. na etapie składania oferty, negocjowania i zawierania (podpisywania) umowy oraz prowadzenia rozliczeń (faktury) jest to platforma on-line Freshbooks.com
3. na etapie prac analityczno-projektowych jest to platforma 0n-line Postmania (rezygnacja z tej platformy na rzecz wymiany edytowalnych dokumentów docx, podnosi pracochłonność o ok. 30% i wydłuża czas realizacji audytów i analiz ponad dwukrotnie).

Zapoznaj sie z moim Modelem Działania.

Forma dokumentowa

Dziennik Ustaw Dz.U.2024.1061 t.j. Akt obowiązujący, Wersja od: 29 sierpnia 2024 r.,
Art.  772.  [Forma dokumentowa]
Do zachowania dokumentowej formy czynności prawnej wystarcza złożenie oświadczenia woli w postaci dokumentu, w sposób umożliwiający ustalenie osoby składającej oświadczenie.

Oznacza to, że wszelkie treści przekazywane drogą elektroniczną, muszą być podpisane jak wyżej. Oznacza to także, że materiałem źródłowym są tak przesłane dokumenty np. pdf, a nie linki do stron czy loginy do aplikacji (patrz trwały nośnik: https://uokik.gov.pl/zwrot-i-rekompensata-od-mpay-i-revolut-bank-uab)

Komunikacja asynchroniczna i synchroniczna

Kluczowe 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).

Praca zespołowa i zarządzanie czasem oraz efektywność wymagają planowania. Spotkania jako źródło danych, są najmniej efektywnym sposobem pracy audytorsko-eksperckiej. Dlatego od wielu lat dzieli się komunikację 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. Dlatego od wielu lat pracuję zadaniowo, zdalnie, metodą asynchroniczną.

Na spotkaniach statutowych omawiane są wyłącznie kwestie organizacyjne. Wszelkie spotkania o charakterze edukacyjnym rozliczane są jako dodatkowe warsztaty i szkolenia.

Komunikacja w projekcie

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).

Jest to typowa 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” .

Oprogramowanie Visual Paradigm

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, może on tworzyć jej kolejne wersje o ile zaopatrzy sie w narzędzie do ich edycji, lub prace te kontynuuję jako autor dokumentacji w ramach zleconego mi nadzoru autorskiego 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 struktury dokumentów

Definicje:

Proces biznesowy – zdefiniowany zestaw aktywności biznesowych, które reprezentują etapy pracy wymagane do osiągnięcia celu biznesowego, obejmuje przepływ i wykorzystanie informacji oraz zasobów.
Aktywność – określona praca wykonywana przez organizację w ramach procesów biznesowych, może być atomowa [niepodzielna] lub nieatomowa (złożona).

Notacja BPMN, Glossary

Dlatego model procesów biznesowych to diagram obrazujący łańcuch aktywności i ich celów (dokumenty jako informacje). Zasoby są reprezentowane przez wykonawców, którzy ich używają. Detale każdej aktywności, jeżeli są wymagane, dokumentowane są osobno jako nieformalne komentarze lub formalne 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). Inna dostępna wersja legendy symboli: BPMN Poster.

Model procesów biznesowych zawiera nazwy dokumentów. Ich struktury to osobne diagramy, które niosą detaliczne informacje o przetwarzanych danych i związkach między nimi:

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 (nie pokazany tu przykładu), jednak kluczowe pojęcia dziedzinowe, dodatkowo weryfikujemy z pomocą modelu pojęciowego budując tak zwaną ontologię (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 (“test prawdziwości”):

• 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 dla dewelopera (wytworzenie oprogramowania) jest model jego działania: Opis Techniczny Oprogramowania (patrz: proces ICONIX). Poniżej opisano jego kluczowe 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-projektanta .

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 potrzeb tych elementów otoczenia. 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 procesów biznesowych i opracowanie ich modeli, oraz wskazanie na tych modelach aktywności, które chcemy wesprzeć oprogramowaniem (transformacja modelu procesów na model wymaganych usług aplikacji). W efekcie powstaje 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 wobec tych usług. 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.

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