Modelování událostí, incidentů a story - obecně
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.
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ář 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í:
-
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.
Začněte kliknutím na záložku Incidents a na tlačítko Add new Incident.
Otevře se formulář pro vytvoření nového incidentu s názvem Create new incident template.
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í:
-
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.
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štrě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
linkaa 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.
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:
-
Actor ID:
stroj- Asset type:
/assets/Linkový stroj - Zdůvodnění: Chceme simulovat různé stroje, ne vždy stejný
- Asset type:
-
Actor ID:
linka- Asset type:
/assets/Výrobní linka - Zdůvodnění: Problém se může vyskytnout na různých linkách
- Asset type:
Incident uložíme tlačítkem Save template.
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 int”:
- 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:
-
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
- Asset type:
-
Actor ID:
stroj- Asset type:
Linkový Stroj - Výběr: Asset selected at random
- Zdůvodnění: Monitorujeme různé stroje v provozu
- Asset type:
Událost uložíme tlačítkem Save template.
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:
-
Actor ID:
stroj- Asset type:
/assets/Zařízení
- Asset type:
-
Actor ID:
linka- Asset type:
/assets/Výrobní linka
- Asset type:
Událost uložíme tlačítkem Save template.
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í.
-
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
Nyní máme definovaný incident a události, takže můžeme sestavit komplexní story, která zahrnuje:
- ✅ Vznik incidentu (překročení servisního intervalu)
- 🔥 Eskalaci problému po 120 minutách
- ✅ DVĚ možné cesty řešení (rychlá revize vs. pozdní revize)
🎯 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).
- Klikneme na záložku Stories
- Klikneme Add New Story
- Zadáme název story:
Zastavení výroby z důvodu chybějíci revize
📍 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
- 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)
💡 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
📍 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)
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 dokonce kontaktování externího servisního technika.
📍 KDE JSME V tomto bodě máme DVĚ možné cesty ukončení:
- Hlavní cesta: Obnova revize trvá delší dobu, než je domluvený rámec, jsou upozorněni všichni dotčení a stroji je doplněna revize pozdě.
- Alternativní cesta: Revize byla doplněna ještě před samostatnou 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
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
🔑 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.
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)
📍 KDE JSME Story je připravená k uložení a je třeba vybrat konkrétní položky z Modelleru, aby bylo jasně vědět, která konkrétní osoba má být upozorněna, případně který asset je událostí dotčen.
- 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
Celou story uložíme tlačítkem Save story.
Máme hotovo, vytvořili jste komplexní story s:
- ✅ Třemi eskalačními úrovněmi
- ✅ Alternativními cestami řešení
- ✅ Přiřadili jsme konkrétní položky pro použité události
- ✅ Správně nastavenou story lze ověřit pomocí tlačítka Run na přehledu stories
🔧 PROBLÉM: Story se nechová, jak očekáváte?
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”)
📋 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
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.
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:
- Upravte názvy aktérů (stroj → server, linka → datacenter, …)
- Změňte časové intervaly podle reálných SLA
- Přizpůsobte notifikace (technik → IT admin, BOZP → Security Officer, …)
- Zachovejte stejnou strukturu eskalace
Pro vytvoření podobné story v jakémkoli odvětví:
-
Analýza situace
- Identifikujte klíčové aktivum
- Definujte měřitelnou podmínku vzniku problému
- Stanovte eskalační stupně podle závažnosti
-
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
-
Vytvoření incidentu
- Definujte srozumitelný Incident subject
- Vyberte vhodný Incident type pro agregaci
-
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í
-
Přiřazení actors
- Doplňte konkrétní osoby, zařízení, lokace pro sestavení finální 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