Events You Are And Events You Shall Return

This article is actually part 4 of my Process Event Streams: What You Need To Know series. I thought I’d be a little more creative with the title of this one. You might want to read part 1, part 2 and part 3 in the series before reading this post.

I’d like to make two propositions:

• Proposition 1: A simulation scenario can be defined entirely by a set of events.
• Proposition 2: The output of a simulation scenario is a set of events.

Taken together: a simulation model is a function of a set of events and results in a set of (virtual) events:

In this article, I’d like to discuss the first proposition. What this proposition says is that all the inputs or parameters required to specify a simulation model can be defined by a set of events. Practically speaking, some of the events will have been abstracted into a format that is more natural for describing some of the simulation model parameters, however, these abstractions have their basis in sets of events.

One way to explore this assertion would be to identify the components of a simulation model and see if they can each be related to a set of business process events. The Sim4BPM proposal formalizes what defines a simulation model and so we can explore each component of the Sim4BPM specification as a means of organizing our thoughts:

Process Model

This is specified as a diagram or formal description (e.g. a BPMN diagram) and represents a case where events have been abstracted into a more natural format that is easier to grasp and/or specify: a process model. To demonstrate that a process model is in reality ultimately defined by a set of events, we turn to process mining. One outcome of process mining is the use of process event logs for the purposes of process discovery. In this case, there is no existing description of the business process, so event logs are used to ascertain the structure or a description of the business process. In cases where process discovery is not, or cannot be used to define a business process, it seems reasonable to assume that our ability to manually model a process is based on a knowledge of the events that occur, or could occur in a business process. When someone manually creates a flowchart of a business process, I believe they are intuitively walking through the events that can occur in that process and abstracting that into a diagram or description.

Resource Parameters

It is not difficult to see that the availability of resources are based on events. For example, the events of coming on shift and going off shift. Proficiencies at a certain task or set of tasks is based on the historical productivity of the resource at a task or set of tasks. This is calculated based on a set of events corresponding to when work at these tasks was initiated and completed when being performed by each specific resource. Even the skill sets of resources can be ascertained by looking at the events corresponding to work of a given type at a given task being reserved by a specific resource.

Activity Parameters

Things like activity durations and the routing of completed work are based on the relationship between events. For example, activity duration can be calculated by using the initiation and completion of specific instances of the activity, and the relative number of post processing outcomes. Data associated with these events (or data associated with the process instances or activity instances associated with the event) suggest the condition or business rule for doing one thing vs. another after a given activity is completed.

Event Parameters

In the Sim4BPM specification, event parameters represent where tokens of work need to be injected into the simulation model. For example, the arrival pattern of work, and the initialization of the model with work in progress are all cases where tokens are injected into the model. The relationship to business process events should be obvious and is pretty much one to one. In particular, these parameters are based on events that originate outside the scope of the model, but effect processing inside the model.

Border Events vs. Modeling Events

One distinction that is useful to make is between events that originate outside the scope of the model, but whose occurrence directly effect processing inside the model, which I will call simulation border events, and events that are used to model the activities and processing rules inside the simulation model, which I will call simulation modeling events.