Organizacje to wielkie mechanizmy, złożone z funkcjonalnych bloków (komórki organizacyjne), te z mniejszych elementów, a te zaś wymagają zasobów: są nimi ludzie i narzędzia jakich używają, nawet te w pełni zautomatyzowane. Koszt systemów komputerowych to w 2020 roku ok. 8% przychodów firm (ok. 10% w branży finansowej). Udział ten stale rośnie, a to oznacza, że jakość tych systemów ma stale rosnący wpływ na marże i konkurencyjność firm (https://www.flexera.com/blog/technology-value-optimization/it-spending-by-industry/).

Wprowadzenie

Trzy lata temu pisałem o projektowaniu urządzeń zawierających bloki funkcjonalne realizowane przez komputer. Komputery coraz częściej (tam gdzie to tylko możliwe) zastępują swoje mechaniczne funkcjonalne odpowiedniki, zgodnie z tezą “komputer to uniwersalny mechanizm” [zotpressInText item=”{5085975:ZCXJ2S7U}”]. Poniżej publikowany wcześniej uproszczony schemat blokowy pralki. Elementy zaznaczone kolorem pomarańczowym zostały zastąpione komputerem (komputer to: procesor, pamięć, program).

Niedawno opisywałem systemowe podejście do całych organizacji pokazując ich model (tu jeden dział pionu produkcji) w duchu MBSE [zotpressInText item=”{5085975:RA6YBH48}”]:

Artykuł powyższy kończyłem słowami:

Czym są więc wyma­ga­nia na opro­gra­mo­wa­nie? To ta część mecha­ni­zmu dzia­ła­nia orga­ni­za­cji, któ­rą chce­my zacząć reali­zo­wać jako dzia­ła­ją­ce opro­gra­mo­wa­nie lub jego ele­ment. Wymagania na opro­gra­mo­wa­nie to nie są cele użyt­kow­ni­ków! Wymagania na opro­gra­mo­wa­nie to mecha­nizm ich osiągania.

źr.: Modelowanie systemów – organizacja jako mechanizm – Jarosław Żeliński IT-Consulting

Oprogramowanie “w czymś” czyli embedded software

Pod pojęciem “oprogramowanie wbudowane” (ang. embedded software) rozumiemy:

Oprogramowanie wbudowane to oprogramowanie, które nie jest bezpośrednio widoczne lub wywoływane przez ludzkiego użytkownika, ale jest częścią systemu. Na przykład oprogramowanie osadzone jest w telewizorach, samolotach i grach wideo. Oprogramowanie wbudowane jest używane do sterowania funkcjami urządzeń sprzętowych.

[zotpressInText item=”{5085975:TZ4JHR35}”]

Autor zwraca uwagę, że jest to “oprogramowanie wbudowane to oprogramowanie, które nie jest bezpośrednio widoczne lub wywoływane przez ludzkiego użytkownika” jednak w drugiej części zdania generalizuje, że to oprogramowanie, które “jest częścią systemu”. W streszczeniu pisze:

Nauka o obliczeniach systematycznie abstrahowała od świata fizycznego. Systemy oprogramowania wbudowanego, jednakże, angażują świat fizyczny. […] Obowiązujące abstrakcje systemów obliczeniowych pomijają “niefunkcjonalne” aspekty. [wyjaśniamy] dlaczego oprogramowanie wbudowane nie jest tylko oprogramowaniem na małe komputery i dlaczego potrzebuje fundamentalnie nowego spojrzenia […]. [autor] Proponuje architektury komponentów oparte na zasadzie zwanej “projektowaniem zorientowanym na aktora” […]. Następnie sugeruje, że aktorzy mogą definiować interfejsy, które deklarują dynamiczne aspekty, które są istotne dla oprogramowania wbudowanego […]. Te interfejsy mogą być zorganizowane w “system”, który wspiera rodzaj sprawdzania w czasie projektowania i w czasie działania, z którego korzysta konwencjonalne oprogramowanie.

[zotpressInText item=”{5085975:TZ4JHR35}”]

Tu już widać ogólniejsze, i zorientowane na użytkownika, podejście bardziej “holistyczne”. Najczęściej nadal jednak pod pojęciem oprogramowanie wbudowane uznajemy, że “Oprogramowanie wbudowane jest używane do sterowania funkcjami urządzeń sprzętowych.” co oczywiście jest prawdą.

Rosnący udział oprogramowania w urządzeniach pokazano na poniższym wykresie:

Jak widać funkcje realizowane przez oprogramowanie stanowią co najmniej 80% całości kosztów. Tu autorzy badali co prawda roboty przemysłowe, jednak jak już wspomniano oprogramowanie wbudowane jest także “osadzone jest w telewizorach, samolotach i grach wideo” [zotpressInText item=”{5085975:TZ4JHR35}”]. Wystarczy spojrzeć na smartfon, który jako telefon, był kiedyś w 100% urządzeniem elektromechanicznym, później elektronicznym, obecnie jest to system składający się z urządzeń peryferyjnych (nadajnik, odbiornik, głośnik, ekran video, zasilacz) [zotpressInText item=”{5085975:I7N5YSN4}”]. Trend nie jest taki nowy [zotpressInText item=”{5085975:2JAV96GM}”]. Więcej [zotpressInText item=”{5085975:NLT4Z5MI}”].

Robert C. Martin, w swojej książce Czysta Architektura [zotpressInText item=”{5085975:PUGG63YC}”], wskazuje na konieczność projektowania oprogramowania w taki sam sposób jak urządzenia i firmy, którego jest ono częścią (patrz rozdz. 29: Clean Embedded Architecture).

Oprogramowanie w organizacji

Do napisania tego artykułu skłonił mnie wpis “Software ? the Elephant in the MBSE Living Room” Douga Rosenberga (tak, to między innymi ten od ICONIX) [zotpressInText item=”{5085975:Y3KLU3JX}”]. “Słoń w pokoju” to popularny w j. angielskim idiom oznaczający

?? ważny lub ogromny temat, pytanie lub kontrowersyjna kwestia, o której wszyscy wiedzą, ale nikt o niej nie wspomina lub nie chce o niej rozmawiać, ponieważ sprawia, że przynajmniej niektórzy z nich czują się niekomfortowo ??

https://dictionary.cambridge.org/dictionary/english/elephant-in-the-room

W naszym języku popularnie mówi się “temat tabu” lub, zależnie od kontekstu, “temat zamiatany pod dywan”. Takim tematem jest oprogramowanie jako część czegoś większego. Dlaczego to taki temat tabu? Moim zdaniem dlatego, że od dekad wmawiano nam, że oprogramowanie (inżynieria oprogramowania) rządzi sie jakimiś innymi prawami niż “klasyczne inżynierie”. Mamy rok 2023 i okazuje, że raczej nie, i okazuje się że dowodem jest to, że oprogramowanie zawsze jest częścią czegoś większego, a ta większa część to nic innego jak produkt “tradycyjnej inżynierii”. Skoro więc pralka, telefon, telewizor czy samolot powstają w cyklu: wymagania, projekt, testy, prototyp, produkcja, to znaczy, że rygor ten dotyczy także każdej części składowej: komputera z jego oprogramowaniem także. Trudno będzie przekonać np. producenta samolotów, że Auto Pilot (obecnie komputer), będzie powstał z pominięciem któregokolwiek z tych etapów.

Takim nadrzędnym bytem dla oprogramowania jest także każda firma, urząd itp. Nigdzie oprogramowanie nie jest samodzielnym wolnostojącymi bytem, organizację inwestują w “oprogramowanie wspomagające zarządzanie”. Innymi słowy, każdy system informatyczny to coś co zastępuje urządzenie (jego fragment) lub w człowieka, w pracach możliwych do opisania (model) określonym mechanizmem.

Wbrew temu co wielu ludzi pisze, organziacje sa i będa silosami z prostego powodu: i ekonomia i organizacje, i urządzenia, i ludzie są zorganizowane zasobowo. Patrząc na to: organizacje budują ekonomię, a ludzie i ich narzędzia budują organizacje. Więc gdzie są te mityczne procesy? To nic innego ja spojrzenie na silosy z perspektywy tego, co i w jakiej kolejności powstaje wewnątrz organizacji. Każdy elementarny proces biznesowy to nic innego jak produkt wytworzony z pomocą określonego zasobu: ludzi i ich narzędzi. To dlatego każdy system modelowany z użyciem notacji UML/SysML, jest modelowany z perspektywy swojej wewnętrznej struktury (architektura systemu) oraz z perspektywy zachowań siebie i swoim komponentów.

Poniżej, bardzo dobrze znany diagram opisujący wewnętrzny łańcuch wartości: kluczowe procesy biznesowe i zasoby w firmie.

Warto tu zwrócić uwagę na to, że wyraźnie oddzielono część operacyjną od części zabezpieczającej zasoby. Warto także zwrócić uwagę że to silosy. Modelując np. firmę skorzystamy z poniższego jej metamodelu: każda firma podzielona jest (składa się z) na komórki organizacyjne, te zaś grupują ludzi i ich narzędzia (zasoby):

Mając zdefiniowane typy bloków systemu jakim jest firma, można zbudowac jej model:

Na powyższym modelu pokazano kluczowe bloki funkcjonalne czyli komórki organizacyjne. Pełny model tej firmy byłby bogatszy, jednak byłaby to hierarchia kilku czytelnych diagramów. Tak zobrazowane przepływy pokazują mechanizm działania firmy jako systemu. Na kolejnych modelach, od ogółu do szczegółu, można pokazać nawet poszczególne stanowiska produkcyjne (tak zwane cele). Na innych modelach, w tej samej notacji ale z innej perspektywy, można pokazać strukturę produktów do modelowania BOM. Te modele to nie są modele procesów biznesowych, to modele organizacji z perspektywy mechanizmu jej działania. Pamiętajmy, że model np. samochodu czy nawet całej ich floty, nie jest modelem korporacji taksówkowej.

A gdzie procesy biznesowe? Osobno, na kolejny kilku prostych modelach BPMN przepływ pracy rozumiany jako odbierane, tworzone i wysyłane dokumenty. A wszystko to powiązane “śladowaniem” czyli macierzami pokazującymi związki zasobów z procesami, dokumentami itp. Pamietajmy, że np. na produkcji fizycznie przemieszczają określone np. dobra konsumpcyjne a zupełnie osobne dowody księgowe (dokumenty) opisujące gdzie i do czego doszło. Nie da sie na jednym diagraie (typie diagramu) pokazać na raz wszystkiego.

Bardzo ważne jest dobieranie właściwych metod i narzędzie modelowania (notacja, paradygmat) do celu jaki chcemy zrealizować w toku przygotowania do wdrożenia. Tam gdzie mamy do czynienia z dokumentami tworzymy analityczne modele z użyciem notacji BPMN (np. obszar finansów, sprzedaży, itp.). Tam gdzie mamy do czynienia z projektowaniem produktów CAD/CAM ich produkcją (dowolny poziom) stosujemy modele systemowe MBSE i notacje SysML (np. systemy MES, PLM, tu warto znać podstawy normy ISA-95). Tam gdzie chcemy modelować blok będący komputerem wraz z oprogramowaniem (wymagania na oprogramowanie), stosujemy UML [zotpressInText item=”{5085975:WCZIC2ZZ},{5085975:8G9TUWIG}”].

Poniżej poglądowy schemat tych zależności:

A gdzie gdzie jest słoń?

Popatrzmy na kolejny poniższy diagram:

Nasz słoń jest tu zasobem: to komputer i oprogramowanie. Systemy IT to integralna część organizacji: to nasze “oprogramowanie wbudowane” w nią. Każdy podsystem np. FK, workflow, WMS czy MES, to takie właśnie “embedded systems” firmy, i nie ma żadnego uzasadnienia do traktowanie tych systemów inaczej niż pozostałych zasobów. Innymi słowy: nie należy patrzeć na oprogramowanie ERP jak na “coś innego”, oprogramowanie jest integralną częścią nadrzędnego bytu jakim jest organizacja.

Podsumowanie

Powoli kończy się era “świętych krów” inżynierii. Inżynieria oprogramowania, po prawie 20 latach “zwinnego” podejścia do tej gałęzi inżynierii, zaczyna dojrzewać do bycia “prawdziwą inżynieria” z analizami, projektowaniem i testowaniem na “desce kreślarskiej”, jaką są systemy CASE i podejście MBSE, jakimi stanowią uniwersalne systemowe podejście do multidyscyplinarnej inżynierii (mechatromnika) [zotpressInText item=”{5085975:Y3KLU3JX}”].

Organizacje to też systemy i ich inżynieria: mamy inżynierię procesów biznesowych, inżynierię zasobów, inżynierie finansową. Organizacje to systemy i tak należy je traktować i modelować [zotpressInText item=”{5085975:NHWMP6KJ}”]. Koszty utrzymania i rozwoju systemów IT to już ponad 8% przychodów firmy i wartość ta powoli ale nadal stale rośnie. Rośnie także dyscyplina ich tworzenia, wdrażania i zarządzania ich kosztami.

Z perspektywy organizacji i rynku, oprogramowanie wbudowane to jest to oprogramowanie, którego używa się wewnątrz firmy ale którego nie widzą, nie mają z nim kontaktu, klienci tej firmy.

Żródla

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Tym razem natchnieniem do napisania tego tekstu była krótka dyskusja w internecie i to stwierdzenie jednego z jej uczestników:

“…strategia budowana przez Zarząd”. Gdyby chciał Pan na tym bazować to w przypadku 90% małych i średnich firm w Polsce bazowałby Pan na niczym. Nawet jeśli któraś z tych firm ma strategię (lub wydaje się jej, że ma) brzmi ona mniej więcej tak: “W najwyższym możliwym stopniu zaspokoić potrzeby klientów przy minimalnych możliwych kosztach własnych”. Obaj wiemy, że to nie jest żadna strategia. Trzeba szukać innego fundamentu.

…nie zgodzę się. Firma i jej właściciel, która istnieje na rynku kilka lat ma strategię tyle, że bardzo intuicyjną i nie uświadomioną. Tu analiza polega na zrozumieniu tego, dlaczego dana firma, mimo przeciwności losu, nie upadła i istnieje np. 10 lat …. Co do zaś “W najwyższym możliwym stopniu zaspokoić potrzeby klientów przy minimalnych możliwych kosztach własnych” to proszę poczytać prospekty emisyjne spółek giełdowych, jest dokładnie to samo …  … a ten tekst nie jest strategią a raczej manifestem maksymalizacji zysków , który uprawia większość korporacji, dlatego w toku analizy warto po prostu pochylić się nad firmą i zrozumieć jakim cudem udało się jej nie zbankrutować . 

W poprzednim artykule, Czy system pełni rolę w procesie?,  pojawiła się polemika, która jest dość powszechnym problemem:

[czytelnik] Są to procesy (lub podprocesy), które zostały zastąpione w 100% i alternatywna ich obsługa będzie możliwa tylko w przypadku wystąpienia jakiegoś błędu.

Przykładem takiego procesu jest zautomatyzowanie rejestracji dokumentów (wprowadzenie kanału mailowego, odcięcie całkowite możliwości wykorzystania papierowych dokumentów). Test odłączenia prądu odetnie organizację od świata zewnętrznego. Wyobrażam sobie wiele biznesów opierających się w większości o chmury, usługi, których wycięcie sprowadzi ten akurat biznes do poziomu średniowiecznego.

[moja odpowiedź] odłączenie prądu spowoduje zmuszenie do przemyślenia i nazwania procesu ?przyjmowanie dokumentów? a mail to tylko przyjęta metoda, tu błędem było nazwanie procesu biznesowego ?odbierani maili? zamiast nazwanie go ?tym czym jest? czyli ?przyjmowanie korespondencji?.

Jest to klasyczny przykład braku uogólnień i abstrakcji w modelach, co prowadzi do “zamulania” ich nadmiarem szczegółów, maskowania prawdziwego sensu (istoty) zjawiska.  Problem stosowania abstrakcji w modelowaniu a konkretnie, problem nie radzenia sobie z abstrakcją, jest często w literaturze nazywany “utratą panowania nad szczegółowością projektu”.  Monstrualne ilości diagramów procesów, monstrualne ilości detali na diagramach, to efekt braku abstrakcji.

Warto pamiętać, że modele procesów biznesowych to element opisu architektury biznesowej. Po raz kolejny przypomnę diagram:

Najniższa warstwa to implementacja procesów, tu dopiero mamy wszelkie szczegóły takie jak: zakresy obowiązków, instrukcje stanowiskowe i podręczniki użytkowników, procedury, wymagane umiejętności, konkretne rozwiązania np. oprogramowanie. Są to te elementy, których nie umieszczamy na modelu procesów, bo procesy biznesowe to “czynności przekształcające stan wejścia w stan wyjścia”. Proces biznesowy to jeden “bloczek” wraz z jego wejściem i wyjściem (proces definiują te trzy elementy) na schemacie blokowym będącym modelem (mapą) procesów.  Bloczek reprezentujący czynność (aktywność, kwestia nazewnictwa), jest abstrakcją procedury, umiejętności, instrukcji obsługi, itp. W dokumentacji więc powołujemy się na te np. procedury (stosowne dokumenty), a nie odtwarzamy ich “obrazkowo” na modelu procesów, bo to prowadzi po pierwsze do dublowania istniejącej dokumentacji oraz do strasznej komplikacji diagramów obrazujących procesy.

Problem ten dobrze opisuje autor tego artykułu:

One of the key characteristics of architecture is looking at the ?big picture?, but a major challenge is that we can?t present the big picture on one great big piece of paper ? it has to fit on a single sheet or model. In order to do that, we have to come up with new concepts that summarize the overall picture into a small number of elements and relationships. We can do this through a variety of techniques, like divide-and-conquer, categorization, generalization, and so on. (BPTrends | Business Archicture: Abstraction in Business Architecture).

Tak więc brak (umiejętności) stosowania abstrakcji w modelowaniu czyni te i inne modele (także UMl itp.) nieczytelnymi, trudnymi do interpretacji, kosztownymi w wytworzeniu i potem w utrzymaniu. To ostatnie powoduje, że większość takich dokumentów szybko kończy życie na półkach, bo dezaktualizują się jak tylko dojdzie do jakiejkolwiek, nawet najdrobniejszej, zmiany w organizacji. Co ciekawe, biorąc pod uwagę czas trwania przeciętnego wdrożenia oprogramowania, taki zbyt szczegółowy model nie ma szans być przydatnym w toku takiego projektu, tu rację mają developerzy, którzy twierdzą, że im takie dokumenty im w niczym nie pomagają.

No ale te szczegóły są potrzebne. Owszem pytanie: które oraz czy na pewno musimy je obrazkowo przepisywać np. z dokumentów działu HR czy jakości. W dokumentowaniu (modelowaniu) organizacji stosujemy różne “perspektywy”, kilka prostych schematów lepiej modeluje organizację niż jedne, na których ktoś upycha “wszystko co wie” (jak to robić lepiej opisałem w artykule Gdzie są te … szczegóły).

Tak więc dokumentowanie “szczegółów” owszem jest potrzebne, ale nie na diagramie procesu. Umiejętności i wiedza wykonawcy to rola w procesie:  każda powinna mieć osobną dokumentację (lub odwołanie do dokumentów w HR). Szczegóły realizacji zadań (czynności, aktywności) to procedury, na które znowu się powołujemy, lub takie dokumenty jak macierz RACI i specyfikacja polityk i reguł biznesowych (opisałem to w artykule RACI … i wcześniejszym RACI i SIPOC).

I tu mały prztyczek dla sponsorów projektów zlecających takie analizy: żądania wobec analityka w rodzaju “a ja chcę zobaczyć jeszcze to … na tym schemacie” to zabijanie projektu. Są uznane dobre praktyki, między innymi modelowanie od ogółu do szczegółu, stosowanie abstrakcji i perspektyw. Nikt rozsądny nie będzie podejmował  prób tworzenia planu miasta, na którym będą wszystkie te rzeczy, które w danym mieście są np. przystanki środków komunikacji publicznej, podmioty gospodarcze, ale także wysokość gruntu, znaki drogowe, sklepy itp. Taka mapa, zakładając jej rozsądną wielkość, była by nieprzydatna, więc żądanie takiej od analityka także nie ma żadnego sensu.

Wstęp

Kwestia “liczby poziomów modelowania procesów” pojawia się na każdym moim szkoleniu w postaci pytań uczestników. Często także spotykam się  z tym “zagadnieniem” w projektach i w literaturze. Można np. spotkać modele z procesami ponumerowanymi poziomami modelowania: procesy główne 0.1; 0.2 itp., procesy pierwszego poziomu: 1.1; 1.2; 1.3, dalej 2.2.4 itd. W czym problem?

Definicje

Po pierwsze: proces np. archiwizacji dokumentu może się pojawić na każdym z tych poziomów, jaki numer mu nadać? Po drugie pewne obszary działania są mało złożone i możliwe, że wystarczy jeden “poziom”, inne złożone i potrzebne będą może cztery poziomy?

Elementarny proces, podobnie jak klocek LEGO, może się pojawić wszędzie, niezależnie od poziomu, np. realizacja zobowiązania finansowego, czyli zapłata za coś, może się pojawić jako zapłata za fakturę wystawioną przez kancelarię prawną w procesie negocjowania umowy handlowej (czyli bardzo “wysoko”) jak i w procesie regulowania zobowiązań za dziurkacze (raczej nisko w takiej hierarchii).

Najpierw dwie kluczowe definicje za normą terminologiczną ISO 9000 (jakość zarządzania):

Proces to: każde działanie, które przekształca wejście (dane wejściowe) na wyjście (dane wyjściowe). Proces może w swoim “wnętrzu” zawierać zbiór różnych operacji (działań) wzajemnie ze sobą powiązanych i na siebie oddziałujących.

Procedura to: określony sposób realizacji działań lub procesów.

Powyższa definicja jest łatwa do  przyjęcia i często stosowana, jednak jest zbyt uboga (pojęcie proces jest tu dość pojemne) by stanowiła podstawę do formalnego modelowania organizacji, dlatego  dodatkowo przytoczę tę, nieco pełniejszą:

(cytat, str. 41) Proces biznesowy jest chronologicznym i logicznym ciągiem funkcji (zadań) wykonywanych w toku pracy nad określonym obiektem w ramach racjonalnego działania. [zotpressInText item=”{5085975:UQN54LMV}”]

(cytat, str. 431) Proces biznesowy stanowi zbiór powiązanych ze sobą czynności ukierunkowanych na realizację określonego celu biznesowego w oparciu o wykorzystywane zasoby. Proces biznesowy jest sterowany poprzez strategię organizacji definiującą cele oraz produkty tworzone przez procesy. [zotpressInText item=”{5085975:UQN54LMV}”]

Przeglądając literaturę przedmiotu (w tym powyższe) można dojść do następującej definicji procesu biznesowego:

Proces biznesowy: czynność, lub logicznie powiązany chronologiczny łańcuch czynności, przekształcający stan wejścia procesu w stan jego wyjścia, mający wartość dla odbiorcy. Proces do wykonania, wymaga określonych zasobów, sposób jego realizacji może być ograniczony. (opr. własne)

Do modelowania procesów obecnie używa się najczęściej notacji BPMN (obecnie tak zwany standard de’facto), specyfikacja tej notacji tak definiuje proces:

A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows that define finite execution semantics. Processes can be defined at any level from enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped together to achieve a common business goal. [zotpressInText item=”{5085975:JSERUS7B},{5085975:QJUPRFNR}”]

Warto zwrócić uwagę na fakt, że z perspektywy notacji, ta jest jedynie językiem wyrazu, proces to “sekwencja aktywności w organizacji, której celem jest dostarczenie określonego efektu”.  Dalej: proces jest obrazowany z pomocą grafu złożonego z elementów o określonej semantyce (mających sztywno określone znaczenia). Proces może być definiowany na dowolnym poziomie. Procesy na najniższym poziomie mogą być grupowane  np. wspólnym celem. Tyle notacja. Definicja procesu w BPMN jest zgodna z ISO.

Tak więc procesem jest tu każdy przepływ pracy, zaś procesem biznesowym są te przepływy, których granice (początek i koniec) wyznaczają produkty biznesowe (określone obiekty, cele biznesowe).  

Co to oznacza?   Oznacza to, że skoro celem biznesowym jest np. wystawienie faktury za dokonaną sprzedaż, zaś przygotowanie samej treści faktury jest jedynie jednym z etapów jej tworzenia (krok), procesem biznesowym jest wystawienie faktury,  ale nie jest nim samo jej zredagowanie (krok, kolejne zadanie) bo poza redagowaniem mamy także czynności sprawdzenia, księgowania i wydruku. Tak więc na najniższym poziomie hierarchii mamy proces Fakturowanie, dalsze szczegóły wystawienia faktury to procedura jej tworzenia składająca się z kolejnych, ustalonych kroków (zadań do wykonania).

Proces biznesowy Fakturowanie może być (i z reguły jest) częścią nadrzędnego procesu Realizacja zamówienia. Pierwszym produktem tego procesu jest Zamówienie gotowe do wykonania, proces ten to np. sekwencja Rejestracja Zamówienia i Weryfikacja Zamówienia. Cały proces Realizacji zamówienia ma więc dwa podprocesy:   Rejestracja zamówienia oraz następujący po nim proces biznesowy Fakturowanie. Produktem pierwszego jest Zatwierdzone zamówienie a produktem drugiego Faktura sprzedaży.

Poszczególne wewnętrzne kroki obu procesów, same z siebie, nie tworzą produktu (np. zarejestrowane ale niesprawdzone Zamówienie nie ma wartości biznesowej, to krok który należy wykonać ale nie jest to samodzielny proces biznesowy).

Popatrzmy na poniższy diagram:

Pokazuje trzy kluczowe poziomy procesowego opisu organizacji: na samym dole mamy zasoby, ich umiejętności wspierane procedurami. To warstwa realizacji, ta która jest udokumentowana w każdej niemalże organizacji jako zakresy obowiązków, procedury i zarządzenia. Najwyższa warstwa to kluczowe elementy strategii, architektura kluczowych procesów. Na tym poziomie można mówić o tak zwanych procesach end-2-end czyli o tym jak organizacja reaguje na bodźce zewnętrzne (np. na każde zapytanie ofertowe odsyłana jest oferta). Ten poziom także jest prawie zawsze udokumentowany jako strategia i plan marketingowy. Warstwa środkowa, procesy biznesowe, to abstrakcja opisująca (modelująca) logikę działania organizacji – jej wewnętrzny łańcuch wartości.

Popatrzmy teraz na jeden ze sposobów ustalenia liczby poziomów modelowania, bardzo często spotykany:

1. Level 1 ? End-to-end processes: Span across functions, e.g. market-to-cash.
2. Level 2 ? Main process areas: Typically function-specific, e.g. accounts receivables.
3. Level 3 ? Sub-processes: Sequence of related activities, e.g. goods invoicing.
4. Level 4 ? Activities: Key steps within sub-process, e.g. printing invoices.
5. Level 5 ? Tasks: Specific user actions or system transactions, e.g. send invoice to print. A step contains a description of how to perform the task.

(źr. Process Improvement at Carlsberg powered by ARIS from Software AG).

Poziom oznaczony Level-1 jak najbardziej mamy “zawsze”. Różnica pomiędzy poziomami 4 i 5 jest dla mnie niezrozumiała. Angielskie słowa acitivity i task to odpowiednio czynność i zadanie. Trudno mi sobie wyobrazić drukowanie faktury bez wysłania faktury do druku.  Czy to dwa poziomy szczegółowości? To co tu widzę, i nie tylko tu, to mieszanie  obszaru działania organizacji (ludzi) z obszarem realizowanym przez “zasoby”. To troszkę (podane przykłady) jak by ktoś uznał, że czynność (poziom 4) to zmiana biegu w samochodzie a zadanie (poziom 5) to zazębienie się właściwych kół zębatych w skrzyni biegów.  Ma to sens?

Poziomy 2 i 3 to modele procesów, liczba tych poziomów może być różna o czym dalej.

Przykład

Poniżej procesy end-2-end (celowo nie nadałem im rzeczywistych nazw by nie sugerować się konkretną firmą czy branżą):

Pokazuje jak organizacja reaguje na zdarzenia  generowane przez jej otoczenie biznesowe. Kolejny etap (poziom ?) to model (diagram) dla każdego tego procesu:

– proces A

– proces B

Proces A zawiera (tworzy) pośredni produkt (Dane 5) oraz produkt Dane4. Zgodnie z definicją procesu, oznacza to, że A składa się dwóch podprocesów, pierwszy tworzy produkt Dane5 a drugi Dane4. Proces tworzący Dane5 jest wykonywany np. na bazie wiedzy wykonawcy (rola), który posiada wymaganą umiejętność, ta jest opisana w dziale HR więc powielanie zapisów z karty obowiązków jest zbędne, wystarczy się na nią powołać w dokumentacji procesu. Czynność tworząca Dane4 jest na tyle  “złożona”, że wiedza wykonawcy to za mało (albo jest ryzyko, że się pomyli) dlatego dokumentujemy (formalizujemy) sposób tworzenia produktu Dane4 jako proces C składający się z określonych czynności:

Proszę zwrócić uwagę, że proces B i C to procedury (wewnątrz nie powstają produkty biznesowe), to tylko opis kroków jakie należy wykonać by powstał produkt procesu.  Procedury z powodzeniem można, zamiast tworzyć takie diagramy,  opisać znanym z projektów ISO strukturalnym tekstem, diagram raczej nie wnosi tu wartości dodanej.  Tworzenie diagramów dla procedur miało by sens, gdyby zrezygnować z procedur w formie tekstowej, w przeciwnym wypadku tworzymy redundantne opisy wymagające synchronizacji. W praktyce robi się tak, dokumentuje procedury diagramami, w przypadkach  gdy procedura jest złożona i jej opis tekstowy może być nieczytelny lub trudny w zrozumieniu. Analogicznie ma się sytuacja w przypadkach gdy sposób tworzenia produktu (proces biznesowy) w 100% jest efektem wiedzy posiadanej przez wykonawce (rola): tu powołujemy się wyłącznie na stosowne zapisy w dziale HR, nie tworzymy ich kopii w postaci diagramu.

Zobrazowanie powyższych diagramów, ich powiązań:

Tu mamy diagram obrazujący “podległość”, czyli to jak się one wzajemnie zagnieżdżają i to jak najbardziej obrazuje strukturę całego modelu.  Jednak próba ponumerowania konkretnych procesów i zbudowania ich hierarchii zachowującej drzewiastą logikę jest nierealna z powodu własnie tego, że procesy są inicjowane zdarzeniami, te zaś nie są “poziomowe” (np. proces opisany na początku archiwizacji dokumentu może się pojawić na każdym poziomie/diagramie). Numerować hierarchicznie jednak można diagramy, które jak widać, mają strukturę podobną do systemu folderów.

Ile więc mamy poziomów modelowania organizacji? Trzy (patrz pokazany wcześniej diagram BPTrends): najwyższy czyli strategia i procesy end-2-end,  najniższy czyli procedury i instrukcje stanowiskowe (implementacja) oraz środkowy czyli abstrakcję – model procesowy – opisującą jak to się wszystko do siebie ma (środkowy poziom ma strukturę zagnieżdżania się diagramów/modeli procesów jak wyżej ale procesy mają jedynie swoje nazwy jako identyfikatory).

Proszę zwrócić uwagę, że:

1. w zasadzie każda organizacja ma udokumentowany poziom najwyższy (strategia) i najniższy (procedury, zarządzenia, instrukcje)
2. warstwa środkowa jest tworzona wtedy, gdy chcemy zrozumieć wewnętrzne zależności, których może być dużo, i mogą być złożone  (zawiłe); to ile “poziomów” powstanie w warstwie środkowej, zależy wyłącznie od stopnia złożoności danej organizacji i zawsze jest to indywidualna jej cecha, tylko w części zależna od wielkości organizacji.

Często można się spotkać z nieformalnymi (o niezdefiniowanych granicach procesów) diagramami w postaci:

Poziom  najwyższy:

i poziomy niższe:

Czy taki diagram nam coś nam daje? Jest w zasadzie graficzną formą tekstowego (niejednoznacznego) opisu. 

Modelowanie procesów biznesowych to nie rysowanie diagramów, to tworzenie modeli, które poddają się walidacji i testowaniu zgodności z rzeczywistością. Poprawne modele pozwalają przewidywać reakcję organizacji na planowane zmiany. 

Na zakończenie

Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości “map procesów”, które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia.

Po więc robimy te modele? Przytoczę znowu cytat inicjujący pewną dyskusję na forum: 

I think the only reason to conduct any project is to improve one or more processes. This means that if you don’t know which process(es) you are trying to improve, you should not start the project. Comments? (Process before project | LinkedIn).

W wolnym tłumaczeniu ;):

jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.

Procesy modelujemy więc po to, by zrozumieć jak działa organizacja oraz po to, by przewidzieć jak się ona zachowa, jeżeli jakiś proces zmienimy, bo może się nie raz okazać, że nie warto się pewnych projektów podejmować z uwagi na skutki.

Modelowanie, jak widać, nie jest procesem obrazkowego zapisu tego co wiemy od pracowników tej czy innej firmy, to jest stenotypia. Modelowanie to trudny proces odkrywania prawdziwej logiki działania organizacji (i wypada mi teraz zaprosić na moje szkolenia :)).

Polecam także wcześniejszy artykuł o modelowaniu organizacji z perspektywy systemów zarządzania jakością ISO, bo projekty IT to nie jedyny przypadek gdy modelowanie organizacji bardzo pomaga.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Najpierw kilka faktów:

(źr. predkosc) oraz pewna statystyka:

Ograniczenia prędkości

Pisałem już nie raz o heurystykach jakimi posługuje się mózg człowieka i o tym, że ich celem jest ratowanie życia poprzez zwolnienie mózgu człowieka z myślenia (gdy nie ma na to czasu). Przytoczę jedną z definicji:

Heurystyki wydawania sądów ? uproszczone reguły wnioskowania. Ludzie automatycznie i bezwiednie posługują się nimi po to, aby wydawać szybkie sądy. Stosowanie heurystyk często prowadzi do wystąpienia błędów poznawczych. (więcej: Heurystyki wydawania sądów ? Wikipedia, wolna encyklopedia).

Problem w tym, by absolutnie nie używać heurystyk (tego trzeba się nauczyć!) w analizie (tu trzeba akurat dużo myśleć). Jak one wypaczają osądy? Posłużę się przykładem fotoradarów, a konkretnie ograniczeń prędkości i osądów o ich zasadności:

Piractwo to chamskie interakcje z innymi użytkownikami drogi, a limit prędkości można przekroczyć będąc absolutnie samemu na drodze, nikomu w żaden sposób nie szkodząc.  (cytat z komentarza pod artykułem: Piraci drogowi nie oszukają nowego prędkościomierza z WAT).

Większość ludzi wyciąga taki oto wniosek: skoro nikogo nie widzę przed sobą to znaczy, że w nikogo nie wjadę (to jest heurystyka). I jest to “prawie” prawda czyli często ale nie zawsze.

Powyższy “diagram” to prosty rysunek obrazujący często spotykaną sytuację: droga, w połowie łuku  skrzyżowanie (miałem kiedyś stłuczkę właśnie jako włączający się do ruchu, ten co we mnie wjechał też uważał, że “pusta droga oznacza można jechać szybko”, mimo że było ograniczenie jak wyżej).

Przed łukiem (diagram) jest ograniczenie do 40km/h. Kierowca pojazdu włączającego się do ruchu (droga idąca od dołu na rysunku) musi mieć czas na ruszenie z miejsca, wjechanie na właściwy pas i nabranie żądanej prędkości. Zrobi to, jeżeli zobaczy, że nikt nie nadjeżdża i zdąży się włączyć do ruchu. Jego widoczność to odcinek oznaczony strzałkami (linia pod znakiem), aby zdążył, nadjeżdżające pojazdy nie mogą jechać szybkiej niż 40km/h (wyliczone dla tego odcinka i jego długości). To prawa fizyki, są takie same w południe i o północy.

Poniżej, dla zilustrowania, badania drogi hamowania:

Tak więc, mam nadzieję, że widać, że znak ograniczenia do 40km/h ma tu sens, bez zmniejszenie prędkości przez pojazdy nadjeżdżające główna drogą, nikt nie włączy się bezpiecznie do ruchu z tej podporządkowanej drogi.  

Tu widać, że heurystyka “będąc absolutnie samemu na drodze, nikomu w żaden sposób nie szkodzę” nie ma żadnego sensu. Powyższy przykład to dość trywialna sytuacja i mam nadzieje pokazująca, że “stopień pustości drogi” nie ma tu żadnego znaczenia, to ograniczenie prędkości ma głęboki sens nawet w środku nocy. Nie ma żadnego znaczenia jakie jest prawdopodobieństwo wyjechania na drogę kogoś z tej bocznej drogi, bo dla osoby jadącej tą główną drogą  (tu z lewej strony), to jest rzut monetą (nie zna historii na tym odcinku więc nie wie nic). Poniżej obszerne opracowanie na ten temat.

https://it-consulting.pl//wp-content/uploads/2013/06/zasady_uspokajania_ruchu-EKKOM.pdf

A teraz system, reguły biznesowe i kryteria decyzji

Nasz systemem  to jest to, co znamy z Kodeksu drogowego: uczestnicy ruchu i ich otoczenie. Model tego co zna każdy kierowca, wygląda np. tak:

Przypuszczam, że wielu z czytelników jest zaskoczonych jego prostotą 🙂 (do utworzenia modelu tego system użyto diagramu klas notacji UML, jest to obiektowy model ruchu drogowego). Złożoność nie tkwi w tym co na drodze: mamy jedynie uczestników ruchu i środowisko, w którym ten ruch się odbywa. Czy uczestnicy są jakość ze sobą skojarzeni? Nie, dlatego diagram nie zawiera nic ponad to co widać :). Tu mała uwaga: inni uczestnicy ruchu dla siebie nawzajem to element środowiska jakie postrzega każdy konkretny uczestnik, nie wyróżniamy tu żadnych “asocjacji” pomiędzy wieloma uczestnikami ruchu bo ich nie ma. Uczestników ruchu może być cała masa, ale każdy z nich “żyje własnym życiem” czyli jedzie i reaguje na otoczenie.

Gdzie tkwi złożoność? W Operacjach. Mamy tu metodę operacji reakcjaNaStanŚrodowiska, oto opis jej metody:

Tak więc cała “wiedza” to właśnie powyższa tablica (model został uproszczony, cały Kodeks byłby tu “nieco większy” ale objętościowo mniejszy niż  oryginalny Kodeks ;)).

Typowa heurystyka to Reguła 1. i 2. Gdzie problem? Problem w tym, że Działanie A2. u większości kierowców nie oznacza prędkości dopuszczalnej zgodnie z Kodeksem Drogowym (Warunek C2) na danym odcinku drogi, a prędkość “maksymalna dopuszczalna” z ich subiektywnego punktu widzenia. Problem w tym, że ten punkt widzenia (ludzka heurystyka) ma wady opisane powyżej.

Na zakończenie

Artykuł ten napisałem z dwóch powodów. Pierwszy to odpowiedź na cytowaną tezę, pochodzącą z komentarzy pod artykułem o radarach laserowych rodem z mojej Alma Mater (WAT). Sugeruję kierowcom nie używać na drodze prostych heurystyk tylko przestrzegać znaków drogowych, z dwojga złego lepiej zwolnić na źle oznakowanej drodze niż kogoś zabić lub okaleczyć.

Drugi powód to przestrzec przed prowadzeniem analiz wymagań metodą wywiadów wierząc, że “skoro klient mówi to wie i tak chce”, bo niestety w większości przypadków jest to nieprawda (żądanie zamawiającego wobec rozwiązania to jego wizja rozwiązania problemu, należy zamawiającego pytać nie “co” chce, a “po co” to chce). Niestety większość znanych mi analityków w firmach IT i nie tylko, to ludzie posługujący się w swej pracy tym czym nie powinni: heurystykami, których jednak tu należy się wyzbyć (po raz kolejny przypomnę: dobry analityk to nie dyktafon czy sekretarka od notowania tego co Klient mówi).

____

O wpływie prędkości na liczbę wypadków drogowych oraz na liczbę ofiar tych wypadków napisano bardzo dużo, przeprowadzono setki badań. W bezpieczeństwie ruchu drogowego na podstawie wieloletnich badań określono model zależności między prędkością a liczbą wypadków drogowych. Według tzw. power model, opracowanego jeszcze w XX w. przez szwedzkiego naukowca Gorana Nilssona, związek między prędkością a wskaźnikiem wypadków drogowych nie ma charakteru liniowego, ale narastający wykładniczo. Warto również wspomnieć, że w ostatnim raporcie IRTAD zaprezentowano skumulowane wyniki z wielu badań, z których wynika, że obniżenie prędkości pojazdów do 45 km/h na drogach miejskich, do 75 km/h na drogach pozamiejskich i do 115 km/h na autostradach zmniejszy liczbę wypadków z ofiarami śmiertelnymi o 28 proc. Podsumowując: masowe przestrzeganie limitów prędkości miałoby bardzo pozytywny wpływ na redukcję liczby wypadków drogowych i ich ofiar. (źr: Prędkość. Czy to jedyna przyczyna wypadków? – Motoryzacja w INTERIA.PL)