FACHWISSEN · PROJEKTE & TRANSFORMATIONINSIGHTS · PROJECTS & TRANSFORMATIONAPPROFONDIMENTI · PROGETTI E TRASFORMAZIONECONOCIMIENTO · PROYECTOS Y TRANSFORMACIÓN
BPMN-Zeitereignisse: Warum eine Erinnerung und ein Abbruch verschiedene Prozesspfade brauchenBPMN timer events: why reminders and cancellation need different pathsEventi temporali BPMN: perché un promemoria e un’interruzione richiedono percorsi di processo diversiEventos temporales BPMN: por qué un recordatorio y una cancelación necesitan rutas de proceso diferentes
Eine Aufgabe bleibt länger offen als vorgesehen. Der Prozess soll nach einer Frist reagieren. Doch soll die Aufgabe weiterlaufen oder beendet werden? In einem ausführbaren Prozessmodell ist diese Unterscheidung wesentlich. Eine Erinnerung und ein Abbruch können denselben Zeitwert verwenden und trotzdem völlig unterschiedliche Wirkungen haben.
Die Wirkung des Randereignisses verstehen
Ein unterbrechendes Randereignis beendet die zugehörige laufende Aktivität und startet den vorgesehenen Ausnahmeweg. Bei einem nicht unterbrechenden Ereignis bleibt die Aktivität aktiv, während ein zusätzlicher Pfad beginnt. Nicht jede Ereignisart erlaubt beide Varianten; die gewählte Notation und ihre technische Umsetzung sind deshalb zu prüfen.
Ein fiktiver Freigabeprozess
Nach zwei Tagen soll eine offene Prüfung eine Erinnerung auslösen. Die prüfende Person darf danach weiterhin entscheiden. Wird stattdessen ein unterbrechendes Ereignis modelliert, kann die ursprüngliche Aufgabe beendet werden. Soll nach fünf Tagen wirklich abgebrochen werden, ist das eine andere fachliche Regel mit eigenen Folgen für den Vorgang.
Den Ausnahmeweg zu Ende denken
Eine Erinnerung benötigt möglicherweise eine adressierte Rolle und eine Begrenzung wiederholter Meldungen. Ein Abbruch braucht dagegen einen klaren nächsten Zustand: zurück zur Klärung, alternative Prüfung oder fachlich geschlossener Fall. Ein auslösender Timer allein beantwortet nicht, welche Daten übernommen werden oder wie Beteiligte den neuen Zustand erkennen.
Die beiden Fälle getrennt testen
Ein Test sollte zeigen, was vor und nach dem Fristablauf noch möglich ist. Kann die Aufgabe nach einer Erinnerung erledigt werden? Wird eine verspätete Entscheidung nach einem Abbruch kontrolliert behandelt? Solche Prüfungen machen Unterschiede sichtbar, die in einem ähnlich aussehenden Diagramm leicht übersehen werden. Für das Modell zählt nicht nur, wann etwas passiert, sondern welche Arbeit danach noch aktiv ist.
A task remains open longer than expected and the process must react after a deadline. Should the task continue or be terminated? This distinction matters in an executable process model. A reminder and a cancellation can use the same time value while producing very different effects on the work.
Understand the boundary event effect
An interrupting boundary event ends the associated running activity and starts the defined exception path. A non-interrupting event leaves the activity running while initiating an additional path. Not every event type supports both variants, so check the selected notation and its actual implementation rather than relying only on visual similarity.
A fictional approval process
An open review should trigger a reminder after two days. The reviewer must still be able to decide afterwards. Modelling an interrupting event instead may terminate that original task. If the process should genuinely cancel after five days, that is a different business rule with its own consequences for the case.
Follow the exception path through
A reminder may need an identified recipient role and limits on repeated notifications. Cancellation needs a clear next state: return for clarification, alternative review or business closure. A timer alone does not specify which data remains valid or how participants recognise the changed state of the transaction.
Test the cases separately
Tests should demonstrate what remains possible before and after the deadline. Can a task still be completed after a reminder? Is a late decision handled appropriately after cancellation? These checks expose differences that are easy to miss in similar-looking diagrams. The model must describe not only when an event occurs but also which work remains active afterwards.
Un’attività rimane aperta più a lungo del previsto e il processo deve reagire allo scadere di un termine. L’attività deve proseguire o essere terminata? Questa distinzione è essenziale in un modello di processo eseguibile. Un promemoria e un’interruzione possono utilizzare lo stesso intervallo temporale e produrre comunque effetti molto diversi sul lavoro.
Comprendere l’effetto dell’evento di confine
Un evento di confine interrompente termina l’attività in corso a cui è associato e avvia il percorso di eccezione previsto. Un evento non interrompente lascia invece l’attività in esecuzione e avvia un percorso aggiuntivo. Non tutti i tipi di evento supportano entrambe le varianti: occorre quindi verificare la notazione scelta e la sua effettiva implementazione tecnica, senza affidarsi soltanto alla somiglianza grafica.
Un processo di approvazione ipotetico
Una verifica ancora aperta deve generare un promemoria dopo due giorni. La persona incaricata deve poter decidere anche in seguito. Se si modella invece un evento interrompente, l’attività originaria può essere terminata. Se dopo cinque giorni si vuole davvero interrompere la procedura, si tratta di una diversa regola operativa, con conseguenze proprie sul caso.
Definire il percorso di eccezione fino alla fine
Un promemoria può richiedere un ruolo destinatario identificato e limiti alle notifiche ripetute. Un’interruzione richiede invece uno stato successivo chiaro: ritorno per chiarimenti, verifica alternativa o chiusura del caso. Un timer, da solo, non stabilisce quali dati restino validi né come i partecipanti riconoscano il nuovo stato della pratica.
Verificare separatamente i due casi
I test devono mostrare che cosa resta possibile prima e dopo la scadenza. L’attività può ancora essere completata dopo un promemoria? Una decisione tardiva viene gestita in modo controllato dopo un’interruzione? Queste verifiche evidenziano differenze facilmente trascurate in diagrammi simili. Il modello deve descrivere non soltanto quando si verifica un evento, ma anche quale lavoro rimane attivo in seguito.
Una tarea permanece abierta más tiempo de lo previsto y el proceso debe reaccionar al vencer un plazo. ¿Debe continuar la tarea o terminarse? Esta distinción es esencial en un modelo de proceso ejecutable. Un recordatorio y una cancelación pueden utilizar el mismo intervalo temporal y, aun así, producir efectos muy distintos sobre el trabajo.
Comprender el efecto del evento de borde
Un evento de borde interruptivo termina la actividad en curso a la que está asociado e inicia la ruta de excepción definida. Un evento no interruptivo mantiene la actividad en ejecución y abre una ruta adicional. No todos los tipos de evento admiten ambas variantes; por ello deben comprobarse la notación elegida y su implementación técnica real, sin confiar solo en el parecido visual.
Un proceso de aprobación hipotético
Una revisión pendiente debe generar un recordatorio al cabo de dos días. La persona revisora debe poder decidir después. Si se modela en su lugar un evento interruptivo, la tarea original puede terminarse. Si el proceso debe cancelarse realmente al cabo de cinco días, se trata de otra regla de negocio, con consecuencias propias para el caso.
Definir la ruta de excepción hasta el final
Un recordatorio puede necesitar un rol destinatario identificado y límites para las notificaciones repetidas. Una cancelación necesita un estado siguiente claro: devolución para aclaración, revisión alternativa o cierre del caso. Un temporizador por sí solo no determina qué datos siguen siendo válidos ni cómo reconocerán los participantes el nuevo estado de la operación.
Probar los dos casos por separado
Las pruebas deben mostrar qué sigue siendo posible antes y después del vencimiento. ¿Puede completarse la tarea tras un recordatorio? ¿Se trata de forma controlada una decisión tardía después de una cancelación? Estas comprobaciones revelan diferencias que pueden pasar inadvertidas en diagramas parecidos. El modelo debe describir no solo cuándo ocurre un evento, sino también qué trabajo permanece activo después.