Czym jest Model i Notacja Zarządzania Przypadkami (CMMN)

Organizacje zawsze dążą do poprawy sposobu swojej pracy, aby zwiększyć efektywność i zredukować błędy. Wymaga to analizy i ciągłego doskonalenia ich metod pracy, które mogą obejmować bardzo zorganizowane przepływy pracy w przewidywalnych sytuacjach, a także protokołów do reagowania na dynamiczne sytuacje, w których niemożliwe jest określenie stałego procesu.

CMMN jest graficzną notacją używaną do uchwycenia metod pracy opartych na obsłudze przypadków wymagających różnych działań, które mogą być wykonywane w nieprzewidywalnej kolejności w odpowiedzi na rozwijające się sytuacje. Używając podejścia skoncentrowanego na zdarzeniach oraz koncepcji teczki sprawy, CMMN rozszerza granice tego, co można modelować za pomocą BPMN, w tym mniej zorganizowane wysiłki robocze oraz te prowadzone przez pracowników wiedzy. Użycie kombinacji BPMN i CMMN pozwala użytkownikom objąć znacznie szerszy zakres metod pracy.

Oto kilka powodów, dla których potrzebujemy CMMN oprócz BPMN:

  • Tradycyjnie badania i praktyka systemów informacji biznesowej koncentrują się na dobrze zorganizowanych procesach biznesowych. Jednak wiele procesów biznesowych jest trudnych do modelowania.
  • Jest to szczególnie prawdziwe w przypadku zadań wymagających dużej wiedzy, takich jak zarządzanie incydentami, doradztwo czy sprzedaż. W rzeczywistości wiele działań jest rozpoczynanych i prowadzonych w sposób ad-hoc, a nie planowanych z wyprzedzeniem.
  • Dotyczy to szczególnie działań wymagających dużej wiedzy lub opartych na projektach, które często stanowią kluczowe kompetencje organizacji.

Proces Ad-Hoc

Procesy ad-hoc to zestawy działań biznesowych i odpowiadających im artefaktów (np. informacje, decyzje i produkty), które można standaryzować tylko na wysokim poziomie agregacji. Rzeczywiste rodzaje działań i ich kolejność różnią się w zależności od przypadku.

Oto cechy Procesu Ad-Hoc:

  • Chociaż niektóre działania można przewidzieć, wiele z procesu nie może być w pełni określone na początku, ponieważ wymaga informacji, które stają się dostępne dopiero w trakcie projektu.
  • Jeśli założymy, że w kontekście procesów ad-hoc następny krok nigdy nie jest określony, ich wykonanie nie może być kontrolowane przez klasyczne systemy informacji opartych na procesach, w większości przypadków to pracownicy wiedzy kontrolują proces.
  • Wydaje się niemożliwe, aby pomyśleć o wszystkich możliwościach dla procesu ad-hoc w czasie projektowania, taki model procesu stałby się złożony i trudny do zarządzania

BPMN vs CMMN

W ostatnich dziesięcioleciach skupiono się na modelowaniu i automatyzacji dobrze zorganizowanych i rutynowych procesów. BPMN najlepiej nadaje się do dobrze zorganizowanej i wysoce przewidywalnej pracy, w której pracownicy wiedzy głównie wykonują zadania, podczas gdy CMMN obejmuje sekcję mniej przewidywalnych procesów z aktywnym udziałem pracowników wiedzy podejmujących decyzje i planujących w czasie rzeczywistym

Zarządzanie przypadkami (CM) zostało wprowadzone jako narzędzie dla pracowników wiedzy przez van der Aalsta w 2005 roku. W maju 2014 roku OMG opublikowało standard zarządzania przypadkami zwany Modelem i Notacją Zarządzania Przypadkami (CMMN). Jego celem jest wspieranie nieprzewidywalnych, wymagających dużej wiedzy i słabo zorganizowanych procesów. Zarządzanie przypadkami to rodzaj technologii procesów biznesowych, która nie używa przepływu kontroli do opisu procesu.

Zarządzanie przypadkami polega na upoważnieniu pracowników wiedzy poprzez zapewnienie im dostępu do wszystkich informacji dotyczących sprawy oraz danie im swobody i kontroli nad tym, jak sprawa się rozwija. Zarządzanie przypadkami nie dotyczy procesu, lecz pracowników. W przeciwieństwie do klasycznych procesów, określony cel i zapewnienie możliwości wyboru są ważniejsze niż sposób osiągnięcia samego celu.

Oto różnice między BPMN a CMMN:

Notacja Deklaratywna nie próbuje modelować przepływu problemu; ustala pożądane wyniki, tj. określa, co chce, aby się wydarzyło, ale nie jak to powinno się wydarzyć. SQL jest przykładem programowania deklaratywnego, ponieważ nie próbuje kontrolować przepływu programu; po prostu stwierdza, co chciałoby się pojawić, ale nie jak to jest zrobione.

Notacja Imperatywna, z drugiej strony, próbują modelować przepływ problemu; na przykład imperatywne języki programowania, takie jak Java czy C++, ustalają polecenia, które powiedzą kompilatorowi, jak chcą, aby kod działał, ale nie określają wyraźnie, co chcą, aby się wydarzyło.


Proces Zorganizowany vs Przypadek vs Proces Ad-Hoc

Czas Projektowania vs Czas Wykonania

Nie ma modelu przepływu sekwencji w CMMN. Wykonanie zadania zależy od zdarzeń i warunków zwanych strażnikami. Strażnik rejestruje wystąpienie określonego zdarzenia lub spełnienie warunku w ramach sprawy. Strażnicy są używani jako kryteria wejścia i wyjścia. Zauważ, że czarne i białe romby reprezentują kryteria.

Sprawa ma dwie wyraźne fazy, które są czasem projektowania i czasem wykonania, opisane jak poniżej:

Czas Projektowania

Podczas fazy projektowania analitycy biznesowi zajmują się modelowaniem, które obejmuje definiowanie Zadań (elementów planu), które zawsze są częścią z góry określonych segmentów w modelu sprawy, oraz Zadań „uznaniowych”, które są dostępne dla pracownika sprawy i mogą być stosowane opcjonalnie w zależności od jego/jej uznania.

Czas Wykonania

W fazie wykonania pracownicy sprawy realizują plan, wykonując zadania zgodnie z planem, a opcjonalnie dodając zadania uznaniowe do instancji planu sprawy w czasie rzeczywistym.

Diagram CMMN w skrócie

Ten przykład ilustruje proces pisania pracy modelowany za pomocą CMMN. Załóżmy, że pisanie pracy to intensywna praca wymagająca wiedzy i może być realizowane na różne sposoby. Przyjrzyjmy się temu przykładowi nieco bliżej:

  1. Proces ma dwa kamienie milowe, które muszą zostać osiągnięte:
  • Szkic ukończony
  • Dokument ukończony
  1. Kilka zadań (np. Utwórz spis treści) pozostawione są do uznania autora.
  2. Przygotuj szkic etap z Napisz tekst i Zintegruj grafikę zadania są obowiązkowe.
  3. Ten etap ma zdefiniowaną regułę powtarzania, co jest symbolizowane przez dekorator powtarzania (tj. hash).
  4. Podczas gdy temat badawczy jest obowiązkowym zadaniem, zadanie zorganizuj odniesienia ma być decydowane w czasie rzeczywistym. Jest podobne do stwórz grafikę i wygeneruj listę rysunków.
  5. Proces zostanie zakończony, gdy dokument zostanie utworzony lub termin zostanie osiągnięty

* Wyciągnięte z specyfikacji modelu zarządzania przypadkami OMG i notacji

Uwaga

  • Model planu przypadku jest przedstawiony za pomocą kształtu „Folder”
  • Nazwa przypadku może być umieszczona w lewym górnym prostokącie.
  • Różne elementy modelu planu przypadku są przedstawione w obrębie granicy kształtu modelu planu przypadku.
  • Diagram pokazuje przykład modelu planu przypadku.

Podstawowe pojęcia CMMN

Pełny model zachowania przypadku jest uchwycony w modelu planu przypadku. Dla konkretnego modelu przypadku, model planu przypadku składa się ze wszystkich elementów, które reprezentują początkowy plan przypadku oraz wszystkich elementów, które wspierają dalszą ewolucję planu poprzez planowanie w czasie rzeczywistym przez pracowników przypadków. Istnieją cztery typy elementów planu:

Zadania

Zadanie to jednostka pracy. Istnieją trzy typy zadań:

Zadania (Zadanie uznaniowe)

Zadania są zawsze częścią z góry określonych segmentów w modelu przypadku. Oprócz zadań istnieją zadania uznaniowe, które są dostępne dla pracownika przypadku, do zastosowania opcjonalnie w zależności od jego/jej uznania. Zadanie uznaniowe jest przedstawione w kształcie prostokąta z przerywanymi liniami i zaokrąglonymi rogami. Zauważ, że każdy typ zadania może być uznaniowy:

Nasłuchiwacze zdarzeń

Zdarzenie to coś, co dzieje się w trakcie przypadku. Na przykład, włączenie, aktywacja i zakończenie etapów i zadań, lub osiągnięcie kamieni milowych.

Kamień milowy

Kamień milowy reprezentuje osiągalny cel, zdefiniowany w celu umożliwienia oceny postępu przypadku. Żadna praca nie jest bezpośrednio związana z kamieniem milowym, ale zakończenie zestawu zadań lub dostępność kluczowych wyników (informacje w teczce przypadku) zazwyczaj prowadzi do osiągnięcia kamienia milowego. Kamień milowy może mieć zero lub więcej kryteriów wejściowych, które definiują warunek, kiedy kamień milowy jest osiągnięty.

Na przykład, mamy umowę o poziomie usług (SLA) w procesie zgodnym, która może być modelowana za pomocą nasłuchiwacza zdarzeń czasowych i kamienia milowego, jak poniżej.

Etap i etap uznaniowy

  • Etap można traktować jako 'fazę’ w przypadku i zazwyczaj grupuje szereg zadań.
  • Jest to kontener elementów, z którego budowany jest plan przypadku i który może dalej ewoluować.
  • Etapy mogą być uważane za „epizody” przypadku. Mogą być traktowane jako podprzypadki (podobnie jak podprocesy w BPMN) i również działają równolegle.
  • Etap jest przedstawiony w kształcie prostokąta z kątami pod kątem i znacznikiem w formie znaku „-” w małym prostokącie w dolnym centrum („-” oznacza rozszerzone etapy).
  • Etap uznaniowy może być dodany 'opcjonalnie’, 'ad-hoc’, do planu według uznania użytkownika.

Rysunek poniżej pokazuje rozszerzony etap z jednym podetapem i trzema zadaniami.

Kryteria

Kryterium pozwala nam opisać, kiedy zadanie, etap lub kamień milowy powinny być dostępne do wykonania (kryteria wejścia) lub kiedy przypadek (plan przypadku), etap lub zadanie powinny zakończyć się w sposób nieprawidłowy (kryteria wyjścia). Kryteria mają następujące dwa opcjonalne elementy:

  • Jedno lub więcej zdarzeń wyzwalających (nazywanych onParts). Są to zdarzenia, które spełnią ocenę kryteriów wejścia lub kryteriów wyjścia

Możemy myśleć o kryteriach tworzących zdanie w następujący sposób,

([ on < Zdarzenie 1 >[, on < Zdarzenie 2 >[, . . .]] ]) OR ([ if < Warunek logiczny > ])

Zauważ, że:

  • Gdzie nawiasy kwadratowe ([ ]) wskazują opcjonalne części zdania, a nawiasy kątowe (< >) są miejscami do zastąpienia.
  • zarówno onPart, jak i ifPart są opcjonalnew zdaniu, ale aby miało to sens, przynajmniej jedno z nich musi być obecne.

Kryteria wejścia

Kryterium wejścia opisuje warunek, który musi być spełniony, aby etap, zadanie lub kamień milowy były dostępne do wykonania. Etapy, zadania lub kamienie milowe bez kryteriów wejścia będą dostępne do wykonania, gdy tylko zostaną utworzone. Kryteria wejścia mogą być umieszczone w dowolnym miejscu na granicy etapu, zadania lub kamienia milowego.

Przykład

W poniższym przykładzie oba etapy: reklamacje produktów i reklamacje usług potrzebują kryteriów wejścia, ponieważ mogą być wykonane tylko wtedy, gdy reklamacja jest ich typem. W większości przypadków tylko jeden z dwóch etapów zostanie wykonany, chociaż w niektórych sytuacjach reklamacje mogą obejmować oba etapy.

Kryterium wyjścia

Kryterium wyjścia jest podobne do kryterium wejścia, ale jest używane do zatrzymania pracy nad etapem, zadaniem lub przypadkiem (planem przypadku), gdy jest spełnione. W procesie reklamacji dodamy kryterium wyjścia dla przypadku. W sytuacji, gdy klient dzwoni i anuluje reklamację, musimy zatrzymać pracę nad przypadkiem. Modelujemy ten scenariusz, mając element pliku przypadku do anulowania, którym może być nagranie głosowe rozmowy z klientem lub list od klienta.

Plik przypadku

W CMMN każda instancja przypadku zawiera pojedynczy plik przypadku (nazywany również folderem przypadku, lub po prostu przypadkiem), a pracownicy przypadków mają dostęp do wszystkich danych w tym pliku przypadku. Pracownicy przypadków mogą dodawać, usuwać i modyfikować dane w pliku przypadku, nawet jeśli nie wykonują żadnego zadania w przypadku, o ile mają wystarczające uprawnienia. Dane w pliku przypadku nazywane są elementami pliku przypadku.

Wszystkie dane i struktury danych nazywane są elementami pliku przypadku. Wszystkie elementy pliku przypadku są przechowywane w pliku przypadku. Elementy pliku przypadku są używane do reprezentowania wszelkiego rodzaju danych, w tym wartości danych w bazie danych, wiersza w bazie danych, dokumentu, arkusza kalkulacyjnego, obrazu, wideo, nagrania głosowego itp. Oprócz podstawowych danych, elementy pliku przypadku mogą również reprezentować kontenery, w tym katalog, folder, zestaw, stos, listę itp.

Przykład

Tabela planowania

Etap lub zadanie ludzkie może mieć Tabelę planowania wskazującą, czy elementy uznaniowe są wizualizowane (-) czy nie (+). Gdy użytkownik 'rozszerza’ Tabelę planowania, zawarte w niej elementy uznaniowe stają się widoczne w ramach Etapu lub poza Zadaniem ludzkim. Dla elementów uznaniowych związanych z Zadaniem ludzkim, planowanie jest dostępne tylko w aktywnym stanie Zadania.


Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文

Leave a Reply

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *