Nigdy nie uważałem, że “każdy/wszystko musi mieć model”, ale powtarzam po nauce: jeżeli chcesz w coś bezpiecznie ingerować, powinieneś najpierw rozumieć jak to działa.
(mój referat o modelowaniu)
Realizuję audyt i tworzę dokumentację, która odpowiada na pytania:
- Jak działa nasza firma?
- Jak nasza firma obsługuje klientów i dostawców?
- Jakie są moje obowiązki, za co odpowiadam?
- Jak działają nasze systemy informatyczne i kogo wspierają w pracy?
- Jak nasze systemy są zintegrowane ze sobą i jak wymieniają dane miedzy soba z systemami kontrahentów?
- Chcemy poprawić efektywność pracy naszej firmy, wdrożyć nowe oprogramowanie, jak opisać wymagania by dostawcą wiedział czego potrzebujemy?
- Czy ta dokumentacja będzie stale aktualizowana? Tak.
Praktycznie każdy projekt zaczynam od wykonania podstawowego audytu stanu obecnego. Celem jest doprowadzenie do sytuacji, w której aktualny stan organizacji i jej systemów IT jest znany i zrozumiały. Audyt taki często wykazuje luki w tej wiedzy i zrozumieniu całości organizacji, dlatego częstym kolejnym etapem pracy jest doprowadzenia tej wiedzy do jej kompletności i pełnego zrozumienia. Produktem jest zestaw powiązanych logicznie diagramów opisujących mechanizm działania organizacji wraz z kluczowymi zasobami. Projekt jest prowadzony zdalnie w 100% na bazie dostarczonych materiałów w formie dokumentowej.
UWAGA! Przed projektem, lub w trakcie, organizacja produkcyjna może wymagać np. Audytu procesu produkcyjnego.
Cel i korzyści
Kiedy taki projekt przynosi korzyści:
- Optymalizacja: Optymalizacja rozmiaru, kształtu, struktury i efektywnoi organizacji.
- Przygotowanie do transformacji: Identyfikacja luk między obecnym a docelowym stanem organizacji.
- Konsolidacja: Łączenie różnych obszarów biznesowych lub działów w celu zapewnienia zgodności kluczowych elementów (ludzi, kultury, technologii, procesów itp.).
- Planowanie strategiczne: Model jasno komunikuje zasady, cele i szczegóły operacyjne (wdrożeniowe) planowanej, nowej strategii biznesowej.
- Budowanie konsensusu: Uwzględnienie perspektyw wielu interesariuszy.
- Redukcja kosztów: Identyfikacja potencjału redukcji kosztów i nieefektywności.
- Zarządzanie ciągłością działania: Dokumentacja pozwalająca zachować ciągłość działania organizacji bez względu np.na rotację pracowników czy utratę części zasobów.
- Ochrona wartości intelektualnych (IP – Intellectual Property): “oderwanie” wiedzy od ludzi, czyli zarządzanie wiedzą o organizacji, jej dokumentowanie, w przypadku organizacji majątkowe prawa autorskie do ich dorobku (know-how).
Podstawowym celem analizy i modelowania całej organizacji, na z góry ustalonym poziomie szczegółów (a raczej poziomie ogólności), jest określenie kontekstu dla konkretnych lokalnych, dziedzinowych projektów. Model całości organizacji zawiera informacje o przepływie dokumentów (informacji) i użytych do tego systemów IT.
Kluczową korzyścią z posiadania udokumentowanej TOM jest nawet kilkukrotne obniżenie kosztów bieżącego zarządzania organizacją oraz nakładów na rozwój systemu IT. Mając modele procesów biznesowy i systemu informatycznego mamy:
- możliwość podejmowanie decyzji organizacyjnych natychmiast i bez ryzyka: udokumentowana informacja o mechanizmie działania każdej biznesowej usługi (procesy biznesowe), to możliwość wykonania natychmiastowej analizy wpływu każdej takiej decyzji na resztę organizacji,
- możliwość natychmiastowego podejmowania decyzji o wprowadzeniu potrzebnych zmian w systemie informatycznym: udokumentowana informacja o mechanizmie działania i architekturze systemu IT, pozwala natychmiast wykonać specyfikację “to-be” tego systemu, i wysłać ją np. do dostawców systemów ERP jako wymaganie (nie trzeba już robić żadnych dodatkowych analiz przedwdrożeniowych),
- możliwość wdrożenia zarządzania ciągłością działania organizacji,
- możliwość wdrożenia kontrolingu i systemu zarządzania kosztami działań (metoda ABC zarządzania kosztami).
Warstwy organizacji
Warstwowy model organizacji
Poniższy diagram to tak zwany Target Operating Model (TOM), spotykany także pod nazwą Business Process and Activities Pyramid. Modelowanie organizacji i systemów odbywa sie na dwóch pierwszych poziomach (schemat poniżej): to strategia organizacji oraz procesy biznesowe jako jej rozwinięcie “do wewnątrz”. Systemy informatyczne i procedury (trzecia warstwa) modelujemy tylko na poziomie logiki mechanizmów ich działania. Tu powstają: procedury i zakresy obowiązków (obszar HR) oraz dokumentacja logiczna systemów informatycznych (IT).
Na powyższym diagranie:
- Enterprise Level to mapa procesów biznesowych
- Business Process Level to modele tych procesów
- Implementation Level to treści procedur oraz modele systemów IT
Ostatecznie otrzymujemy opis jako tak zwaną żywą dokumentację:
Dwie górne warstwy to produkt mojej pracy. Trzecia najniższa to obszar wdrożenia. Opracowują ją kadry kierownicze, zespoły dewelopera, firma wdrążająca ERP, konsultanci ISO itp..
Organizacja rynkowa vs. administracja publiczna
To często zadawane pytanie. Paradoksalnie nie ma żadnej różnicy między firmą, korporacją a np. ministerstwem czy lokalnym samorządem.
| Poziom | Podmiot rynkowy | Jednostka administracji publicznej |
|---|---|---|
| Enterprise Level | Rola w rynkowym łańcuchu wartości np. nabywa surowce i sprzedaje przetworzone produkty, na bazie posiadanej infrastruktury świadczy usługi np. dostępu do Internetu, mając odpowiednie zasoby świadczy usług doradcze itp. | Zasilana środkami z budżetu, angażuje, tworzy i utrzymuje infrastrukturę, zapewnia świadczenie usług publicznych na określonym poziomie. |
| Business Process Level | System działań administracyjnych i operacyjnych opisany procedurami, przedstawiony i analizowany jako procesy biznesowe, czyli logicznie powiązane procedury zawierające opis wymaganych zasobów. | System działań administracyjnych i operacyjnych opisany procedurami, przedstawiony i analizowany jako procesy biznesowe czyli logicznie powiązane procedury zawierające opis wymaganych zasobów. |
| Implementation Level | Zasoby ludzkie oraz środki technologiczne (maszyny, urządzenia, komputery) cechujące się określonymi funkcjonalnościami wspierającymi aktywności w procesach biznesowych. | Zasoby ludzkie oraz środki technologiczne (maszyny, urządzenia, komputery) cechujące się określonymi funkcjonalnościami wspierającymi aktywności w procesach biznesowych. |
Modele
Pierwowzorem jest Architektura Zorientowana na Usługi (SOA, ang. Service Oriented Architecture):
Po prawej stronie, na diagramie powyżej, wskazano stosowane notacje i systemy pojęciowe. Od kilku lat standardowo używane są jedynie BPMN (mapy procesów biznesowych, system informacyjny, workflow), UML (architektura systemu informatycznego), SBVR (biznesowy sownik pojęć i reguły biznesowe). Interfejsy to odpowiednio od góry: przypadki użycia (UML, enterprise context) oraz API (UML, enterprise semantic) budowane na bazie dokumentów (komunikatów) i ontologii (SBVR) zbudowanej dla danej organizacji lub dziedziny (branży).
Kluczowe dla modelu TOM jest śladowanie (mapowanie) między modelami (warstwami), którego celem jest kontrola spójności całości tego modelu oraz możliwość wykonania automatycznej analizy wpływu dowolnego elementu na pozostałe (interfejsy miedzy warstwami, pionowe linie na ww. diagramie). Modele te, po ich opracowaniu, służą do zarządzania zmianą i automatycznego generowania wymagań na systemy informatyczne.
Wewnętrzny łańcuch wartości Portera
Modele procesów są w toku analizy dodatkowo dzielone na obszar operacyjny (Primary activities) i wspierający (Support activities):
Z uwagi na ścisłą prawną standaryzację procesów wspierających (finanse i administracja), bardzo często analizowany jest wyłącznie obszar operacyjny jako jedyny specyficzny dla badanej organizacji.
System informatyczny to wymagania (requirements) jakie stawia mu biznes, jego architektura (structure), mechanizm działania (behavior), oraz wzajemne powiązania tych trzech elementów (czarne linie). Bez względu na to, czy jest to model całego systemu IT (integracja) czy pojedynczej aplikacji (wewnętrzna architektura) zasady analizy i modelowania są takie same.
Zakres projektu
Powyższe oznacza, że w ramach audytu (analiza stanu obecnego) i projektu analitycznego (projektowanie rozwiązania) powstają kolejno od ogółu do szczegółu:
- model obrazujący misje i wizje organizacji oraz kluczowe mierniki jej oceny (Model Motywacji Biznesowej)
- mapy i modele procesów biznesowych (Business Process Diagrams) rozumiane jako przepływy pracy i dokumentów, pod pojęciem pracy rozumiemy zadanie opisane procedurą lub zakresem obowiązków, wykonane z użyciem notacji BPMN i SBVR, jednostką granulacji są zadania i dokumenty, szablony procedur i dokumentów są dołączane do modeli jako załączniki lub schematy blokowe (UML), powstaje od kilku do kilkunastu takich modeli,
- lista usług biznesowych (Business Services), które są modelowane jako przypadku użycia w notacji UML: przypadkiem użycia jest każde utworzenie lub aktualizacja dokumentu, są one mapowane na aktywności w procesach biznesowych modelowanych jak wyżej,
- model architektury integracji HLD (High Level Design, ang. arch. wysokiego poziomu), jest to model architektury systemu informatycznego, rozumiany jako schematy blokowe opisujące aplikacje oraz dane przesyłane między nimi, dane rozumiane jako treść dokumentów lub komunikatów, są to modele w notacji UML obrazują komponenty aplikacyjne (Components) mapowane na na zadania na modelach procesów biznesowych,
- projektowanie dedykowanego modułu (usługi) to specyfikowane (przepływy ekranów, scenariusze użycia, architektura LLD, ang. Low Level Design, itp.) jako:
- wymagania – jeżeli oprogramowanie jest planowane do zakupu lub wytworzenia,
- audyt stanu faktycznego – jeżeli oprogramowanie jest już eksploatowane a nie jest udokumentowane
- (opcjonalnie, jako uzupełnienie) model infrastruktury (Operational Resources), modelowany jako diagramy wdrożenia w notacji UML, to fizyczne systemy operacyjne i produkty rynkowe realizujące wyżej opisane komponenty i usługi, na ten model są mapowane ww. komponenty architektury HLD.
Powyższe można uzupełnić o istniejące misję i wizję organizacji (tak zwany Model Motywacji Biznesowej). Zakres projektu inicjującego obejmuje opracowanie rekomendacji wskazujących możliwe usprawnienia. Ogólna struktura powstającej dokumentacji ma następującą postać:
Pracochłonność i koszt
Standardowo opracowanie modelu i map procesów biznesowych zajmuje ok. trzech miesięcy. Pozostałe to specyfikacja usług aplikacji – projektowanie (to odrębna praca). Założeniem jest dostarczanie materiałów i udzielanie informacji na żądanie, w czasie nie dłuższym niż dwa dni robocze. Standardowa forma komunikacji to forma dokumentowa, spotkania są organizowane wyłącznie jako statusowe, oraz jako ewentualne szkolenia jeśli wymagane.
Po lewej obszar wdrożenia, niepodlegający analizie biznesowej i wymagań na systemy IT. Jest środowisko lokalne organizacji i to kadry kierownicze dostarczają materiały je opisujące. Jeżeli jest taka potrzeba zlecany jest niezależny audyt procesu produkcyjnego, i raport z tego audytu stanowi materiał do analizy, dlatego obecność analityka w organizacji analizowanej nie jest wymagana. Po prawej obszar działania systemu informatycznego, który należy zaprojektować. To obszar pracy analizy i projektowania tego systemu.
Organizacja analizowana wyznacza ekspertów dziedzinowych. Są to szefowie kluczowych komórek organizacyjnych (kilka, rzadziej kilkanaście osób). Zajętość czasu tych osób to jedynie czas na przygotowanie kopii żądanych materiałów źródłowych oraz ewentualne pisemne wyjaśnienia i uzupełnienia, komentarze. W skali miesiąca rzadko przekracza to kilka godzin. Po stronie Zamawiającego wyznaczany jest koordynator.
Co dalej czyli Continues Delivery
Każda organizacja to żywy organizm, który zmienia sie wraz z wymaganiami rynku, strategia działania. Organizacja to między innymi jej system informacyjny: model przetwarzania informacji w organizacji, oraz system informatyczny czyli środowisko techniczne i aplikacyjne, które realizuje te funkcje. Środowisko techniczne i jego utrzymanie to domena lokalnego działu IT.
System informacyjny to obszar działania inżyniera systemów nazywanego często “solution designer” (projektant rozwiązań informacyjnych). Jego rolą jest bieżące reagowanie na wszystkie potrzeby biznesowe. Tą reakcją jest zamiana tych potrzeb na wymagania wobec oprogramowania, wspólne ich przekazanie do dostawcy oprogramowania (deweloper), oraz nadzór nad odbiorem efektów:
Z uwagi na konflikt interesu, zarówno relacji biznes-developer (odbiorca-dostawca jak i wewnętrznej relacji przełożony-podwładny), podstawowym zalecanym na świecie podejściem jest obiektywizacja tego procesu poprzez angażowanie w roli Solution Designer osoby z poza organizacji (podobnie jak robimy to w przypadku wszelkich audytów).
Powyższe to ogólna charakterystyka zakresu projektu. Aktualne stawki i pracochłonność na każdym etapie prac dostępne na stronie z Ofertą kosztową. Polecam poniższe artykuły na temat zakresu i korzyści z posiadania tak zwanego Cyfrowego Bliźniaka:
