Introduction

This app provides process monitoring in realtime for SwiftMQ.

Event Input

Events are received from a configurable SwiftMQ topic.

An event is a simple JSON containing 3 fields:

• Unique id of the business process, such as an orderid.

• Name of the stage (activity) in the process, such as Shipment Ready.

• A numeric value of the process to compute a KPI, such as orderamount.

Events must arrive in the order in which the corresponding stages are performed.

Process Model

Events form a dynamic process model as shown here:

Not every process will run through the same stages. There are deviations - called variants - from the optimal path (aka happy path):

This picture's variants result from re-ordering products from producers in a warehouse system caused by empty racks and create delays at various stages.

Process monitoring helps you identify and optimize these variants.

Happy Path

The Happy Path is the optimal path of a process. It can be defined statically during setup:

It then turns into a reference path of the process with all other variants are deviations from it.

If you don’t define a static Happy Path, the Process Analyzer builds it dynamically by weighting the links between stages. Links with the highest weight form the Happy Path. The base of the weight is either the throughput of a link or the average value. Depending on which data you display, the dynamic Happy Path might be different.

Event Output / Automation

You can react to dynamic process model changes by defining events sent to other SwiftMQ topics at the same or a different SwiftMQ router.

These events are:

• Stage events (stage created, process checkin, process checkout)

• Link events (link created, process travels a link)

• Alerts (process stays for too long at a stage)

For example, in the above model, you could define an event for process checkin on stage Shipment Ready and send it to Pulsar topic shipment_pickup for the pickup.

Benchmarking

Every 15 minutes, a snapshot of the current process model is taken and stored in history for up to 10 days. This allows you to perform benchmarks of your current model against a model from the past:

You can compare the number of processes or the value field of the events, which both result in KPIs per stage:

You can also compare the live model to: 

• Yesterday, same time

• Last week, same time

These comparisons are rolling, so the time of the history snapshot advances with the current time.

You can also compare two snapshots from the past.