Cechy wyróżniające nowoczesną teorię organizacji to jej pojęciowo-analityczna podstawa, jej oparcie się na danych uzyskiwanych z badań empirycznych, ale przede wszystkim jej syntetyzujący, integracyjny charakter. Te cechy wyróżniające są zawarte w filozofii, która akceptuje założenie, że jedynym sposobem badania organizacji jest traktowanie ich jako systemów (Kostrzewski et al., 1979).

Wprowadzenie

Wbrew oczekiwaniom, tak zwane zwinne metody (agile manifesto, 2001 r.) nie poprawiły jakości projektów informatycznych, nie raz zaś spowodowały wzrost kosztów i wydłużanie terminów, a z uwagi na system rozliczeń “czas i materiał”, nie pozwalają na planowanie budżetu projektu. Średnie i duże projekty IT to nadal w ponad 80% porażki .

Dlatego sprawdzają się trudniejsze, ale znacznie skuteczniejsze, metody zorientowane na modelowanie (analiza systemowa i projektowanie) oraz rezygnacja z monolitycznej architektury systemów na rzecz architektury komponentowej, wdrażanej metodami iteracyjno-przyrostowymi . Metody te pozwoliły na projektowanie rozwiązań informatycznych i wdrażanie ich w takt zmieniających sie potrzeb. Pozwalają one także na planowanie kosztów i terminów już od początku projektu . Tak powstaje tak zwana Specyfikacja SWS (Specyfikacja Wymagań Systemowych).

Model Based Systems Engineering

Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm .

MBSE to skrót od Model Based Systems Engineering (ang. inżynieria systemów oparta na modelowaniu) . System to nie tylko “system informatyczny”, to także cała organizacja, a nawet Państwo.

Celem tego krótkiego artykułu jest pokazanie standardowej ścieżki analizy systemowej i poprawy organizacji, czyli metody prowadzenia analizy stanu obecnego i projektowania rozwiązań, opartej na analizie faktów i modelowaniu , których celem jest opracowanie rekomendacji do ulepszenia organizacji . W 2008 roku OMG opublikowało specyfikację Software & Systems Process Engineering Metamodel (SPEM?), opisującą proces prac nad budową systemów, jednak wygląda na to, że prace nad tą specyfikacją nie są kontynuowane. MBSE jako metoda, wydaje się być następcą tego pomysłu (patrz: Survey of Model-Based Systems Engineering (MBSE) Methodologies) .

Podstawą pracy z modelami w analizie systemowej organizacji jest idealizacja . Polega ona tym by w toku analizy i poszukiwania rozwiązania zaprojektować ideał (model organizacji w wersji idealnej), następnie opracowaniu studium jego wykonalności, uzupełnieniu ideału o poznane ograniczenia i wdrożenia tak zaprojektowanego systemu . Studium wykonalności ideału to oferty dostawców rozwiązań, których rola jest nie analiza a opracowanie koncepcji wdrożenia.

Implementacja

Implementacja, w przypadku oprogramowania, to:

• wybór i uruchomienie środowiska,
• implementacja opracowanego modelu w tym środowisku.

Poniżej wzorzec architektoniczny nazwany przez jego autora: architektura heksagonalna . Zakłada on całkowitą separacje kodu środowiska (wymagania pozafunkcjonalne) i logiki aplikacji (wymagania funkcjonalne) dzięki czemu znakomicie ułatwiamy ustalenie ról w projekcie oraz łatwość utrzymania i rozwoju.

Trzy poziomy modelowanie organizacji

Organizacje można opisać na trzech kluczowych poziomach:

Enterprise Level – (poziom organizacji) jest to poziom, na którym opisuje się i modeluje, strategie organizacji i jej rolę w otoczeniu rynkowym (rynkowy łańcuch wartości). Dotyczy to także instytucji publicznych. Taki opis jako krótki dokument, jest często dostępny na stronach WWW organizacji w zakładce “O nas”, w prospektach emisyjnych, statutach itp. Model powstaje w toku formalizacji tego opisu.

Business Process Level – to środkowy poziom, na którym tworzony jest abstrakcyjny model organizacji w postaci tak zwanego wewnętrznego łańcucha wartości (proces biznesowy). Znakomita większość organizacji nie ma takiego dokumentu lub jest on nieaktualny. Powodem tego stanu rzeczy jest to, że bieżącej pracy operacyjnej jest on niepotrzebny. Model taki przynosi jednak ogromne korzyści w przypadku podejmowaniu decyzji o zmianach. Jest to wtedy podstawowy materiał obniżający ryzyko wszelkich decyzji o jakichkolwiek zmianach organizacyjnych lub planowanych wdrożeniach.

Implementation Level – to poziom opisujący szczegóły realizowanej pracy i wykorzystywanych narzędzi. To obszar treści dokumentów takich jak: zakresy obowiązków pracowników i ich kompetencji, instrukcje stanowiskowe, procedury, zarządzenia i regulacje wewnętrzne, podręczniki używania sprzętu i oprogramowania oraz wiele innych dokumentów o podobnych charakterze. Dokumenty te są potrzebne w bieżącej pracy, jednak szybkie i skutecznie podejmowanie decyzji na ich podstawie ich treści jest praktycznie niemożliwe z uwagi na ich ilość i szczegółowość.

Analiza biznesowa polega na audycie dokumentów istniejących, czyli tych z poziomu pierwszego i trzeciego na powyższym diagramie, i opracowaniu na ich podstawie Modelu Procesów Biznesowych (środkowa warstwa). Model ten to mechanizm funkcjonowania organizacji, jej abstrakcyjny obraz, pozwalający zaplanować przyszłe wdrożenie i przewidzieć jego efekty.

W toku analizy ma często miejsce standaryzacja opisu działania i strategii. Jej celem jest formalizacja opisu organizacji, bez czego nie jest możliwe dokonanie jakichkolwiek porównań np. z konkurencją, wyznaczenie celów biznesowych i wskazanie w organizacji miejsc mających wpływ na te cele.

Enterprise Level – Model biznesowy organizacji

Strategia organizacji i jej rola w otoczeniu rynkowym są kluczowe dla zrozumienia osiąganych przez organizację efektów. Mimo tego, że większość organizacji dysponuje takim opisem, są one wykonane nieformalnymi metodami, tak różnymi, że jakiekolwiek porównanie dwóch organizacji lub tej samej na przestrzeni lat jest praktycznie niemożliwe. Dlatego opracowano standard zwany Model Motywacji Biznesowej .

Standard ten stanowi sobą pewien określony system kluczowych pojęć i związków między nimi. Jego celem jest standaryzacja pojęć takich jak: misja i wizja, strategia i taktyka, wewnętrzne i zewnętrzne czynniki wpływu, cele i mierniki osiągania celu.

Business Process Level – Model procesów biznesowych organizacji

Jest to model poziomu Business Process Level. To znaczy, że nie ma tu miejsca na szczegóły opisane w dokumentach na poziomie Implementation Level. Model procesów biznesowych ma (powinien mieć) jedynie odnośniki do szczegółów trzeciej warstwy, w szczególności do procedur, reprezentowanych na tym poziomie w postaci (abstrakcyjnych) nazwanych aktywności.

Jednym z najbardziej znanych wzorców opisu tego poziomu jest tak zwany Wewnętrzny Łańcuch Wartości M. Portera, jest on nadal podstawową wiedzą każdego absolwenta studiów MBA. Model ten zakłada podział procesów na wspierające (administracja) i operacyjne. Konkurencyjność i sprawność operacyjna ma dwa obszary: w obszarze administracji, ściśle regulowanym prawem, w zasadzie konkurujemy kosztami, ale w obszarze operacyjnym, dającym znacznie większą swobodę jego kształtowania, konkurencyjność to efekt sprawności organizacji, architektury procesów biznesowych i informacji.

Z ww. powodu w toku analizy i modelowania skupiamy sie na obszarze operacyjnym, gdyż obszar wsparcia administracyjnego, z powodu ścisłej zależności od prawa, można wesprzeć standardowym oprogramowaniem, łatwo dostępnym na rynku. Ewentualne dedykowane moduły są projektowane właśnie dla obszaru operacyjnego, bo to tu występują różnice między organizacjami i tu powstaje przewaga konkurencyjna (jeżeli dotyczy to organizacji konkurującej na rynku). Kluczem na tym etapie jest wskazanie miejsc do usprawnienia i opracowanie rozwiązania. Próby kompleksowego wdrażana “jednego systemu do wszystkiego” najczęściej kończą się niestety źle (kompleksowe wdrożenia monolitów ERPII mają bardzo złą renomę). Model Portera odnosi sie jednakowym stopniu do firm rynkowych jak i do instytucji publicznych.

Więcej w artykule Analiza organizacji i opracowanie Mapy Procesów.

Implementation Level – wdrożenie

Ten poziom i jego dokumentacja, to tak na prawdę efekt pracy operacyjnej i produkt wdrożenia norm jakości i procedur, strategii zatrudnienia, systemu informatycznego itp. (patrz Operational Resources w poprzednim podrozdziale). Tę dokumentację tworzą dostawcy rozwiązań oraz wewnętrzne służby administracji. Jako, że ona w różnych formach istnieje w każdej firmie, stanowi bazowy materiał źródłowy w analizach stanu obecnego. To dlatego analizę organizacji można przeprowadzić praktycznie w 100% bez kłopotliwych i kosztownych spotkań warsztatowych z pracownikami analizowanego podmiotu.

Rozwiązania informatyczne i wymagania

Niestety same spisane funkcjonalności programu czyli specyfikacja (lista) wymagań funkcjonalnych to wyłącznie idea jego powstania (wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94).  Precyzję opisu, dającą ochronę w postaci pełnego prawa do powstałego produktu, uzyskuje się dopiero opracowując projekt jego konstrukcji, struktur danych i mechanizmu działania, stosując wzory matematyczne, algorytmy, unikalne struktury i schematy blokowe.

Obecne czasy to wszechobecna cyfryzacja. Dlatego znakomita większość rozwiązań wspierających działania organizacji to systemy informacyjne wspierające procesy biznesowe.

Powyżej pokazano (znany od lat 90-tych ubiegłego wieku) model architektury systemów informacyjnych zorientowanej na usługi aplikacyjne. Pokazuje on związki pomiędzy procesami biznesowymi a systemami informacyjnymi, których docelowo w każdej organizacji jest więcej niż jeden.

Systemy informacyjne także modelujemy na kilku poziomach:

1. Business Services – jako nazwane usługi biznesowe wymagające określonych usług aplikacyjnych, wspierających określone aktywności w procesach, usługi aplikacyjne modelujemy jako przypadki użycia aplikacji (są to wymagania na rozwiązanie),
2. Components – jako nazwane i wyspecyfikowane komponenty aplikacyjne wraz z ich integracją (jest to opis rozwiązania),
3. Operational Resources – jako model opisujący faktyczne ich wdrożenie i rozlokowanie (jest to dokumentacja wdrożonego systemu).

Kluczowymi stosowanymi standardami notacyjnymi są tu BPMN, UML, SBVR. Więcej w artykule Analiza i opracowanie wymagań na oprogramowanie.

Opracowanie specyfikacji wymagań (modeli) nie powinno nigdy w obecnych czasach trwać dłużej niż kwartał, co oznacza, że im większy projekt tym bardziej specyfikacja wymagań jest polityką (architekturą) niż detalicznym opisem. Detale są specyfikowane już w toku wdrożenia w toku nadzoru autorskiego, zgodzie z polityką budowy i wdrażania systemu (architekturą). Wycena realizacji nie powinna sprawić kłopotu, żadnej doświadczonej, znającej wzorce architektoniczne, firmie ofrującej oprogramowanie.

Praca z dostawcami rozwiązań

Praktycznie zawsze pada pytanie: a co jeżeli dostawca też robi analizę przedwdrożeniową? Otóż tu już jej nie robi bo ją dostaje. Z uwagi na ryzyko projektu i potencjalny konflikt interesu, Dostawca z zasady nie powinien być autorem wymagań (projektu rozwiązania).

Dostawca musi opracować proponowaną przez siebie Koncepcję Wdrożenia oferowanego produktu, w odpowiedzi na wymagania wyrażone w postaci modeli procesów biznesowych, struktur dokumentów i reguł biznesowych (Model Biznesowy Organizacji). Z uwagi na to, że projekty takie zawsze realizowane są metodą iteracyno-przyrostową, w toku projektu ma miejsce stała współpraca: Dostawca rozwiązania żąda kolejnych detalicznych informacji o tym jak działa firma Zamawiającego, Zamawiający, z moją pomocą (nadzór autorski), odpowiada odsyłając stale uzupełniany Model Biznesowy. Dostawca dokumentuje kolejne etapy prowadzonego wdrożenia (aktualizuje Koncepcję Wdrożenia, która staje się dokumentacją tego wdrożenia) a ja je (te dokumenty) weryfikuję, i tak aż do zakończenia wdrożenia.

Na koniec wdrożenia Zamawiający dysponuje dwoma aktualnymi dokumentami: Model Biznesowy (środkowa warstwa opisu organizacji) i Dokumentacja Wdrożenia (opisany wyżej Poziom Implementacji).

Podsumowanie

Każdy projekt związany z reorganizacją i/lub wdrażaniem nowego oprogramowania (zmian, rozbudowy) można więc przeprowadzić metodą analizy organizacji i jej modelowania na z góry ustalonym poziomie szczegółowości. Modele te są ściśle zintegrowane z sobą, a całość ma charakter opisu “od ogółu do szczegółu”.

Podejście to gwarantuje spójność, kompletności i niesprzeczność opisu na każdym etapie projektu. Dzięki temu minimalizujemy ryzyko nieudanego wdrożenia a całość trwa krótko (żaden etap analizy nie powinien trwać dłużej niż kwartał!). Prosty ale obrazowy przykład opisałem TUTAJ.

Całość literatura przedmiotu opisuje od wielu lat, metody te są stale doskonalone. Poniżej proces tworzenia oprogramowania jako projektowanie systemu:

Przypadki użycia (use case) to wynik opisanej na początku analizy biznesowej (organizacja to także system) i wyodrębnienia celów biznesowych. Mamy rok 2021 i ogromny wybór dostępnego, gotowego oprogramowania wymagającego jedynie właściwego doboru i integracji. Tak opisany wyżej system to struktura i zachowanie się dobranych komponentów, nie koniecznie jest to “pisanie dedykowanego oprogramowania od zera”, bo to ma miejsce coraz rzadziej i dotyczy ewentualnie 10-15% dedykowanych potrzeb niektórych firm.

Obecne na rynku systemy wspierające analizy i projektowanie (CASE: Computer Aided System Engineering) oraz wzorce architektoniczne i narzędzia informatyczne, pozwalają prowadzić analizy i modelowanie etapami trwającymi pojedyncze tygodnie a nie lata. Iteracyjno-przyrostwe metody dostarczania oprogramowania pozwalają wdrażać nowoczesne rozwiązania w okresach kwartalnych a nie lat.

Więc kilka słów na zakończenia:

• jeżeli pracuje nad zrozumieniem logiki działania czegoś, nie ma znaczenia język programowania
• jeżeli chce udokumentować to co odkryłem, nie ma znaczenia język programowania
• jeżeli chce zaprojektować architekturę przyszłej aplikacji, nie ma znaczenia język programowania
• jeżeli chcę opisać wymagane algorytmy, nie ma znaczenia język programowania
• jeżeli chce te algorytmy rozłożyć na poszczególne komponenty, nie ma znaczenia język programowania
• jeżeli chce sprawdzić jak to zadziała i czy zadziała, nie ma znaczenia język programowania

Język programowania ma znaczenie dla dewelopera, bo to on się nim posługuje. Implementacja jest najkosztowniejszym etapem tworzenia systemu, więc należy minimalizować zaangażowanie dewelopera na rzecz analizy i projektowania.

Źródła