Skip to main content
ALTWORX Dokumentace
Přepnout tmavý/světlý/automatický režim Přepnout tmavý/světlý/automatický režim Přepnout tmavý/světlý/automatický režim Zpět na domovskou stránku
  1. ALTWORX Dokumentace
  2. /
  3. Implementátorská dokumentace
  4. /
  5. Modelování
  6. /
  7. Modelování událostí, incidentů a story - obecně
Upravit stránku

Modelování událostí, incidentů a story - obecně

Modelování nové události

Na úvodní stránce Story Modelleru najdete tři záložky Stories, Events a Incidents. Při vytváření příběhů (stories) je nutné nejprve vytvořit události a incidenty, z kterých story poskládáte.

Úvodní stránka Story Modelleru se záložkami Stories, Events a Incidents

Klikněte tedy na záložku Events a zde, vpravo nahoře, na tlačítko Add new Template. Tím se vám otevře formulář pro vytvoření nové události s názvem Create new event template.

Formulář pro vytvoření nové události (prázdný)

Formulář obsahuje tato pole:

  • Button name: do tohoto pole zadáváte pojmenování události, pod kterým bude uložena ve Story Modelleru.

  • Event text: sem napíšete text, který se u události zobrazí v UI.

Pro proměnnou použijete syntaxi ${actors.actor_id}.

  • Event type: zde je nutné uvést název typu události.

V sekci List of actors, přidáváte aktéry události pomocí tlačítka Create new actor a vyplněním těchto polí:

Formulář pro vytvoření nového aktéra události

  • Actor ID: název proměnné - uvádí se zde pouze název, nikoli celá syntaxe použitá v Event text.

  • Asset type: typ, do kterého aktivum patří.

Událost nezapomeňte uložit tlačítkem Save template.

Vytváření události můžete zrušit tlačítkem Cancel.

Modelování nového incidentu

Začněte kliknutím na záložku Incidents a na tlačítko Add new Incident.

Záložka Incidents s tlačítkem Add new Incident

Otevře se formulář pro vytvoření nového incidentu s názvem Create new incident template.

Formulář pro vytvoření nového incidentu (prázdný)

Formulář obsahuje tato pole:

  • Definition: do tohoto pole zadáváte pojmenování incidentu, pod kterým bude uložena ve Story Modelleru.

  • Incident name: pojmenování incidentu, tj. text, který bude zobrazen ve widgetech UI.

  • Incident type: typ incidentu, tj. text, podle kterého se bude agregovat počet současně otevřených incidentů.

  • Incident subject: sem napíšete text, který se u incidentu zobrazí v UI.

Pro proměnnou použijete syntaxi ${actors.actor_id}.

V sekci List of actors, přidáváte aktéry incidentu pomocí tlačítka Create new actor a vyplněním těchto polí:

Formulář pro vytvoření nového aktéra incidentu s volbou firstID/random

  • Actor ID: kam zadáme název proměnné - uvádí se zde pouze název, nikoli celá syntaxe použitá v Incident text.

  • Asset type: kde vyberete typ, do kterého aktivum patří. Dále zvolíte, jak se má při vzniku incidentu vybrat konkrétní aktivum z vybraného typu.

Incident nezapomeňte uložit tlačítkem Save template. Vytváření incidentu můžete zrušit tlačítkem Cancel.

Ilustrace modelování událostí

Pro ilustraci uvedeme způsob vytvoření událostí a incidentů pro situaci Nedodržení servisního intervalu klíčového stroje. Všechny události a incidenty budou sdílet společný kontext - pravidelnou údržbu výrobního stroje - abychom v závěrečné části mohli ukázat, jak z těchto událostí postavit komplexní story s eskalačními kroky a alternativními cestami řešení.

Tip
Před začátkem modelování si připravte kompletní seznam aktérů, které budete potřebovat. Ušetříte si opakované návštěvy formulářů. V našem případě to jsou: stroj, linka, BOZP manažer, výrobní proces, technik a vedoucí výroby.
Poznámka
Asset type při definování aktérů (actors) vychází z vytvořené sítě reality popsané v kapitole Vytváření sítě reality.

Přehled používaných aktérů v tomto příkladu:

  • stroj → /assets/Linkový stroj (hlavní lisovací stroj)
  • linka → /assets/Výrobní linka (výrobní linka A)
  • bozpmanazer → /assets/Osoba (manažer BOZP - Eva Novotná)
  • vyroba → /assets/Proces (výrobní proces primárního produktu - VP1)
  • technik → /assets/Osoba (revizní technik - Marek Černý)
  • vedoucivyroby → /assets/Osoba (vedoucí výroby - Jan Novák)
Pozor
Konzistence názvů aktérů je klíčová! Pokud v jedné události použijete linka a v jiné vyrobnilinka, systém s nimi bude zacházet jako se dvěma různými entitami. Doporučujeme si vytvořit seznam aktérů předem a držet se ho.

Incident - Nedodržení servisního intervalu klíčového stroje

Tato událost reprezentuje okamžik detekce problému - zjištění, že stroj má překročený servisní interval. V tomto bodě vzniká incident, který reprezentuje stav vyžadující řešení v čase. Jedná se o vstupní bod (událost) celé story.

Formulář vyplňte následujícím způsobem:

Definition: Nedodržení servisního intervalu klíčového stroje

Description: Neplatné revize stroje

Incident name: Nedodržení servisního intervalu klíčového stroje

Incident type: Nedodržení servisu

Incident subject:

Přístroj ${actors.stroj} nebyl včas zkontrolován. Je blokována linka ${actors.linka}
Poznámka
Incident type se používá pro agregaci – systém podle něj počítá, kolik incidentů stejného typu je aktuálně otevřených. Vybírejte názvy, které dávají smysl pro reporting.

List of actors:

Pomocí tlačítka Create new actor přidáme jednotlivé aktéry:

  1. Actor ID: stroj

    • Asset type: /assets/Linkový stroj
    • Zdůvodnění: Chceme simulovat různé stroje, ne vždy stejný

  2. Actor ID: linka

    • Asset type: /assets/Výrobní linka
    • Zdůvodnění: Problém se může vyskytnout na různých linkách

Incident uložíme tlačítkem Save template.

Vyplněný formulář incidentu 'Nedodržení servisního intervalu klíčového stroje' s aktéry stroj a linka

Událost 1 - Detekce chybějící revize na klíčovém stroji

Tato událost reprezentuje moment zjištění problému - detekci, že stroj nemá aktuální platnou revizi. Jedná se o informativní událost, která není přímo spojena s incidentem, ale slouží jako varování nebo monitoring informace.

Myšlenkový proces
Tohle je “kontrolní bod” – systém průběžně monitoruje platnost revizí a jakmile zjistí, že něco není v pořádku, vytvoří tuto událost. Na rozdíl od události “Nedodržení servisního intervalu”, která rovnou zakládá incident, tato událost může sloužit jen pro logování nebo preventivní notifikace.

Formulář vyplníme následujícím způsobem:

Button name: Detekce chybějící revize na klíčovém stroji

Description: (ponecháme prázdné nebo můžeme doplnit interní poznámku)

Event text:

Stroj ${actors.stroj} na lince ${actors.linka} nemá aktuálně platnou revizi

Event type: Detekce chybějící revize

Tip
Event type “Detekce chybějící revize” jasně odlišuje tento typ události od jiných. Můžete pak snadno filtrovat a reportovat, kolikrát za měsíc byla detekována chybějící revize.
Poznámka

Rozdíl mezi touto událostí a “Nedodržení servisního intervalu”:

  • Detekce chybějící revize = monitoring, varování, bez incidentu
  • Nedodržení servisního intervalu klíčového stroje = skutečný problém vyžadující řešení, s incidentem

List of actors:

Pomocí tlačítka Create new actor přidáme jednotlivé aktéry:

  1. Actor ID: linka

    • Asset type: Výrobní Linka
    • Výběr: Asset selected at random
    • Zdůvodnění: Chceme detekovat problém na různých linkách

  2. Actor ID: stroj

    • Asset type: Linkový Stroj
    • Výběr: Asset selected at random
    • Zdůvodnění: Monitorujeme různé stroje v provozu

Událost uložíme tlačítkem Save template.

Vyplněný formulář události 'Detekce chybějící revize na klíčovém stroji' s aktéry linka a stroj

Událost 2 - Doplněná revize na klíčovém stroji

Tato událost reprezentuje pozitivní řešení - dokončení nápravného opatření. Použije se v optimistickém scénáři, kdy technik provede revizi.

Myšlenkový proces
Tohle je “happy ending” pro náš incident. Technik dokončil revizi, stroj je zkontrolovaný, můžeme pokračovat ve výrobě.

Button name: Doplněná revize na klíčovém stroji

Event text:

Stroj ${actors.stroj} na lince ${actors.linka} má obnovenou revizi

Event type: Doplněná revize na hlavním stroji

List of actors:

  1. Actor ID: stroj

    • Asset type: /assets/Zařízení

  2. Actor ID: linka

    • Asset type: /assets/Výrobní linka

Událost uložíme tlačítkem Save template.

Vyplněný formulář události 'Doplněná revize na klíčovém stroji'

Notifikace

Notifikace slouží k informování relevantních osob o změnách stavu incidentu. V našem modelu máme připraveno několik typů notifikací, které se rozesílají v různých fázích.

Poznámka
Notifikace se vytvářejí jako samostatné entity v záložce Events. Notifikace je rovněž událostí.
Seznam notifikací využitých ve story

Notifikace použité v ukázkovém modelu:

  • Notifikace manažera BOZP o chybějící revizi na stroji

  • Notifikace - Výrobní proces zastaven

  • Notifikace revizního technika o chybějící revizi

  • Notifikace vedoucího výroby o eskalaci

  • Notifikace - Obnova výroby

  • Notifikace manažera BOZP o obnově revize na stroji

  • Notifikace revizního technika o obnově revize stroje

Kompletní Story s eskalací a alternativními cestami

Nyní máme definovaný incident a události, takže můžeme sestavit komplexní story, která zahrnuje:

  1. ✅ Vznik incidentu (překročení servisního intervalu)
  2. 🔥 Eskalaci problému po 120 minutách
  3. ✅ DVĚ možné cesty řešení (rychlá revize vs. pozdní revize)
Kompletní přehled story s eskalačními kroky, tlačítky a událostmi
Myšlenkový proces
Reálný svět není lineární – incident může být vyřešen rychle, nebo může eskalovat. Story Modeller nám umožňuje modelovat rozhodovací body pomocí alternativních přechodů (Alternative transitions).

Postup vytvoření story:

  1. Klikneme na záložku Stories
  2. Klikneme Add New Story
  3. Zadáme název story: Zastavení výroby z důvodu chybějíci revize

Krok 1: Vznik incidentu (0s)

Kde jsme
Start story – právě jsme detekovali, že stroj nemá aktuální revizi.
  • Klikneme na ikonu (Add new incident)
  • Vybereme událost: Nedodržení servisního intervalu klíčového stroje
Výběr události 'Nedodržení servisního intervalu klíčového stroje' v kroku 1
  • Klikněte na ikonu (Add new step)
  • Klikněte na ikonu (Add incident transition)

Nastavíme parametry přechodu:

  • Status: start
  • Event type: incident_updated
  • Description: 
    Nelze pokračovat ve výrobním procesu. Řeší technik ${actors.technik}
  • Severity: 1 (Low/Medium - zatím jen detekce)
  • Duration: 0s (okamžitý vznik)
Dialog Incident transition s nastaveným Status, Severity a Description (text notifikace)
Tip
Description se zobrazí v detailu incidentu v UI – pište ji tak, aby byla srozumitelná pro operační tým, který bude incident řešit.

Přidejte události pomocí ikony

  • Detekce chybějící revize na klíčovém stroji
  • Notifikace manažera BOZP o chybějící revizi na stroji
  • Notifikace - Výrobní proces zastaven
  • Notifikace revizního technika o chybějící revizi

Krok 2: Eskalace problému (120 minut od počátku)

Kde jsme
Problém stále není vyřešen. Situace je závažná – hrozí havárie stroje nebo porušení bezpečnostních norem. Informaci o incidentu obvykle postupujeme na vedoucí pozice.
  • Klikněte na ikonu (Add new step)
  • Kliknete na ikonu (Add incident transition)

Nastavíme parametry:

  • Status: eskalace 120 minut
  • Event type: incident_updated
  • Description: 
    Stroj nemá stále platnou revizi. Řeší ${actors.technik}
  • Severity: 2 (Medium/High - informovace vedoucímu pracovníkovi výroby)
Krok 2 - Eskalace se Severity 2 a tlačítkem 'eskalace 120 minut'

Přidejte události pomocí ikony

  • Notifikace vedoucího výroby o chybějící revizi

Uložte tlačítkem Save.

Myšlenkový proces
Toto je moment, kdy se do hry zapojuje vyšší instance ovlivněná incidentem. V reálném scénáři by zde mohla být i další eskalace, ve které by byly kontaktovány nejvyšší instance hierarchie – např. CEO, automatické zastavení výroby, nebo kontaktování externího servisního technika.

Krok 3: Řešení incidentu

Kde jsme

V tomto bodě máme DVĚ možné cesty ukončení:

  1. Hlavní cesta: Obnova revize trvá delší dobu, jsou upozorněni všichni dotčení a stroji je doplněna revize pozdě.
  2. Alternativní cesta: Revize byla doplněna ještě před eskalací a není třeba notifikovat další osoby.

Hlavní přechod:

  • Klikněte na ikonu (Add new step)
  • Klikněte na ikonu (Add incident transition)

Nastavíme parametry:

  • Status: stop
  • Event type: incident_updated
  • Description: 
    Revize na stroji ${actors.stroj} byla obnovena
  • Severity: 1 (Resolved - problém vyřešen)
  • Duration: 1s
Krok 4 - řešení s událostí 'Doplněná revize' a uzavíracími notifikacemi

Přidejte notifikace pomocí ikony

  • Notifikace - Obnova výroby
  • Notifikace manažera BOZP o obnově revize na stroji
  • Notifikace revizního technika o obnově revize stroje
  • Notifikace vedoucího výroby

Přidejte události pomocí ikony

  • Doplněna revize na hlavním stroji

Přidání alternativního přechodu (dřívější řešení)

Klíčová funkce
Alternative transitions umožňují modelovat rozhodovací body a různé scénáře. V našem případě: “Co když technik provede revizi před eskalací a výpadek výroby je krátkodobý?”

  • Klikněte na tlačítko vytvořené tranzice start (Edit incident transition)

  • Klikneme na tlačítko Show future transition

  • Zaškrtneme pole Next transition scheduled

  • Klikneme na tlačítko Create alternative transition

  • Zde lze vidět, že následující krok tranzice je eskalace s informací: Revize ještě nebyla obnovena.

Dialog Incident transition s alternativními přechody (Next transition a Alternative transitions)

Nastavíme alternativní cestu:

  • Status: (prázdné)
  • Event type: incident_updated
  • Alternative transition description: 
    Revize na stroji ${actors.stroj} byla obnovena
  • Severity: 1 (Resolved - problém je vyřešen)
Poznámka

V sekci Alternative transitions vidíte náhled: Severity: 1 Description: Revize na stroji ${actors.stroj} byla obnovena

Tato alternativa se použije, když technik stihne provést revizi ještě předtím, než dojde k dalšímu kroku.

Uložíme tlačítkem Save.

Praktický příklad
  • Scénář A: Technik provede revizi včas → Story jde cestou Krok 1 → Krok 3 (stop)
  • Scénář B: Technik provede revizi po 120 minutách → Story jde Krok 1 → Krok 2 → Krok 3 (stop)

Krok 4: Přiřazení actorů

Kde jsme
Story je připravená k uložení. Je třeba vybrat konkrétní položky z Modelleru, aby bylo jasné, která konkrétní osoba má být upozorněna, případně který asset je událostí dotčen.
Přiřazení konkrétních hodnot do assetů dle actors kategorie zvolené při vytváření událosít a incidentů
  • Klikneme na tlačítko Show actors

Přidání konkrétních assetů

  • Nyní obecně zvolený typ actors nahraďte specifickým assetem definovaný pomocí ID
  • Pokud se některá položka v actors vyskytuje opakovaně, je automaticky doplněna již po prvním výběru
  • Při vyplňování konkrétní hodnoty lze vidět náhled výsledné notifikace s již doplněnými hodnotami
Dialog přiřazení konkrétních hodnot do assetů s náhledem výsledné notifikace

Celou story uložíme tlačítkem Save story.

Uložená kompletní story s přehledem všech kroků, eskalací a alternativních cest
Máme hotovo

Vytvořili jste komplexní story s:

  • ✅ Třemi eskalačními úrovněmi
  • ✅ Alternativními cestami řešení
  • ✅ Přiřazenými konkrétními položkami pro použité události
  • ✅ Správně nastavenou story lze ověřit pomocí tlačítka Run na přehledu stories

Doporučení pro pokročilé použití

1. Řešení problémů pro vytvořenou story

Problém

Story se nechová, jak očekáváte? Projděte tento kontrolní seznam:

  • Mají všichni aktéři konzistentní Asset type napříč událostmi?
  • Jsou Duration správně nastaveny? (pozor na jednotky – s, m, h)
  • Existuje cesta z každého kroku ven? (Jinak incident “uvízne”)

2. Organizace notifikací

Doporučení

Používejte konzistentní prefixing v názvech notifikací:

✅ Notifikace - Obnova výroby ✅ Notifikace - Výrobní proces zastaven ✅ Detekce chybějící revize na klíčovém stroji

❌ Obnova výroby ❌ Revize chybí ❌ Email o problému

3. Severity strategie

Doporučené mapování:

Severity Význam Kdy použít Reakce
1 Low/Info Detekce, monitoring Notifikace zaměstnanci
2 - 4 Medium - Critical Otevřený incident Notifikace vedení
1 Resolved Vyřešeno / Uzavření incidentu Potvrzovací notifikace
Pozor
Severity 1 se používá JAK pro nízkou závažnost, TAK pro resolved stav. Rozlišuje se podle kontextu v rámci story.

4. Přenositelnost do jiných odvětví

Tento model nedodržení servisního intervalu stroje můžete adaptovat například na:

Odvětví Aktivum Interval Incident Type
IT Databázový server Backup window Backup SLA Breach
Logistika Nákladní vozidlo STK termín Vehicle Compliance Violation
Zdravotnictví Ventilace na JIP Povinná revize Critical Equipment Non-Compliance
Energetika Transformátor Diagnostika izolace Grid Safety Risk
Potravinářství Chladící zařízení HACCP kontrola Food Safety Incident

Klíčové změny při adaptaci:

  1. Upravte názvy aktérů (stroj → server, linka → datacenter, …)
  2. Změňte časové intervaly podle reálných SLA
  3. Přizpůsobte notifikace (technik → IT admin, BOZP → Security Officer, …)
  4. Zachovejte stejnou strukturu eskalace

Shrnutí postupu

Pro vytvoření podobné story v jakémkoli odvětví:

  1. Analýza situace

    • Identifikujte klíčové aktivum
    • Definujte měřitelnou podmínku vzniku problému
    • Stanovte eskalační stupně podle závažnosti

  2. Vytvoření událostí

    • Událost detekce problému (s vytvořením incidentu)
    • Událost řešení (bez vytváření incidentu)
    • Případně události pro různé fáze eskalace

  3. Vytvoření incidentu

    • Definujte srozumitelný Incident subject
    • Vyberte vhodný Incident type pro agregaci

  4. Sestavení story

    • Začněte vznikem incidentu
    • Přidejte eskalační kroky s časovými přechody
    • Definujte alternativní cesty řešení
    • Přiřaďte notifikace/události podle fází

  5. Přiřazení actors

    • Doplňte konkrétní osoby, zařízení, lokace pro sestavení finální story
Výsledná story

Výsledná story odpovídá zobrazení na úvodním obrázku, kde je vidět:

  • Eskalační tlačítka (start, eskalace 120 minut, stop)
  • Přiřazené notifikace v jednotlivých krocích (barevné bloky)
  • Přechody severity: 1 → 2 → 1 (resolved)
  • Alternativní cesta řešení incidentu
gdoc_arrow_left_alt Popis Situace Altworx Modeller gdoc_arrow_right_alt