5.1. Make and Deliver Pizza

Image by monkik

A pizza service company takes phone orders for making and delivering pizzas, with the help of order takers, pizza makers, ovens and a crew of pizza delivery scooter drivers. From time to time the order takers cannot cope with the number of incoming calls, and then customers grow impatient and hang up the phone without placing an order.

For getting a quick impression, you can run this model from the OES GitHub website, or inspect its OESjs code.

Since there is a high number of lost orders due to long waiting times in the first model, assigning different responsibilities to organizational roles for allowing a more flexible use of human resources is considered in a variant of the first model.

Our Make-and-Deliver-Pizza modeling problem is based on the chapter "Example Model 3: Pizzeria operation" in the book The Art of Process-Centric Modeling with AnyLogic by Arash Mahdavi.

Conceptual Model

A pizza service company has resource pools for order takers, pizza makers, pizza ovens, delivery staff and scooters. While take order activities are performed by an order taker, make pizza activities require both an oven and a pizza maker. Finally, deliver pizza activities require a delivery staff member and a scooter.

Conceptual Information Model

The potentially relevant object types are:

  1. pizza service company,
  2. customers,
  3. orders,
  4. pizzas,
  5. order takers,
  6. pizza makers,
  7. pizza ovens
  8. delivery scooter drivers,
  9. scooters.

Potentially relevant types of events and activities are:

  1. pizza ordering calls coming in from customers,
  2. order taking (an activity performed by order takers),
  3. customers hanging up the phone when having to wait for too long,
  4. pizza making (performed by pizza makers using ovens),
  5. pizza delivery (performed by delivery staff using scooters).

Object, event and activity types, together with their participation associations, can be visually described in a conceptual information model in the form of a special kind of UML class diagram, called Object Event (OE) class diagram, as shown below.

conceptual information model describing object, event and activity types

The association end annotations «rr» and «rp» denote resource roles and resource pools. For instance, the activity type make pizza has two resource roles, pizza makers and oven. A pizza service company has resource pools for order takers, pizza makers, ovens, delivery scooter drivers and scooters.

Resource roles have resource cardinality constraints. For instance, a make pizza activity requires 2 pizza makers and 1 oven.

A conceptual OE class diagram like the one above, describes resource roles (like oven), resource role types (like ovens) and resource cardinality constraints (like "exactly 1") for all types of activities.

An organization defines organizational positions, which are filled by human resources. Each organizational position is characterized by a set of human resource roles to be played by position holders. In the Pizza Service organization, there are three positions: order takers, pizza makers and delivery scooter drivers.

Strictly speaking, order phone calls are immediate (zero duration) events while a take order activity is an event with a non-zero duration. For simplicity, though, we'll often say "events" instead of "immediate events" or "objects, events and activities" instead of "objects, immediate events and activities".

Conceptual Process Model

The following BPMN diagram shows a conceptual process model of the Make-and-Deliver-Pizza business process, with three swimlanes for the three performers of the process:

A conceptual process model in the form of a BPMN diagram

Notice the BPMN Boundary Timeout Event circle attached to the take order activity representing timeout events that cancel the activity. They are supposed to model the reneging behavior of waiting customers loosing their patience and hanging up the phone without placing an order. However, BPMN does not allow restricting such a timeout mechanism to the waiting phase of a planned activity, that is the time span during which the planned activity has been enqueued, but not yet started. Rather, it applies to the entire cycle time of take order activities, which means that also started activities, where the order taker is already listening to the customer, may be canceled due to reneging.

While BPMN allows modeling the performers of activities with swimlanes, it does not support modeling other types of resource objects. As a workaround, we have included the resource objects ovens and scooters in the form of BPMN Data Objects.

The third, and most severe, issue of the BPMN model is its uniform (semantically overloaded) use of "sequence flow" arrows for sequencing events and activities. While in the case of all three activities, incoming "sequence flow" arrows do not mean that an activity is started, but rather that a new planned activity is enqueued (and only started when all required resources become available), in the case of the event lost order, the incoming "sequence flow" arrow means that a new event is scheduled to occur immediately.

These three issues of BPMN have been solved in DPMN, where resource-dependent activity start arrows are distinguished from event scheduling arrows, as shown in the following DPMN process diagram:

A conceptual process model in the form of a DPMN diagram

Notice how the timeout event circle (with a clock icon) is attached to the three bars of the resource-dependent activity start arrow representing the queue of planned order taking activities waiting for the availability of an order taker. This implies that the timeout applies to the waiting phase, and not to the order taking activity.

A conceptual DPMN process diagram does normally not include any element representing a resource pool. Yet, it may display the performer roles of activity types, like order taker and pizza maker in the diagram above. It is assumed that for any organizational position described in the underlying OE class model, the organization under consideration has a corresponding resource pool.

Simulation Design

In our simulation design, we make the following simplifications. We consider only one particular pizza service company, which does not have to be modeled as an explicit object. Also, we abstract away from individual customers, orders and pizzas. And we merge the resource roles delivery scooter driver and scooter, keeping only scooters as resources of deliver pizza activities.

We consider a scenario with two order takers, ten pizza makers, five ovens and 20 scooters.

Information Design Model

An information design model, in the form of an OE class diagram as shown below, is derived from a conceptual information model by

  1. Abstracting away from items that are not design-relevant.
  2. Adding properties,functions and methods to object, event and activity classes. In particular, a status attribute is added to all resource object types, such as OrderTaker and Oven, and a class-level duration function is added to all activity classes.
Figure 5-1. An information design model defining object, event and activity types.

Notice how functions representing random variables, like the duration function of all activity types, are marked with the keyword (or UML 'stereotype') «rv» standing for "random variable". These random variable functions sample from a probability distribution function (PDF), which is symbolically indicated with expressions like Tri(30,40,50) standing for the triangular PDF with lower and upper bounds 30 and 50 and a median of 40, or DU(1,4) standing for the discrete uniform PDF with lower and upper bounds 3 and 6.

In the case of the event type OrderCall, the random variable function recurrence samples from an exponential PDF with five different event rates given for the five consecutive hours during which the pizza service operates.

The activity type TakeOrder is associated with the object type OrderTaker via the implicit resource role orderTaker (with a resource cardinality constraint of "exactly 1"), indicated with the association end stereotype «rr» standing for "resource role". A resource role assigns resource objects to activities.

Likewise, MakePizza is associated with PizzaMaker and Oven via the (implicitly named) resource roles pizzaMakers, having a resource cardinality constraint of "exactly 2", and oven, having a resource cardinality constraint of "exactly 1".

An OE class design diagram like the one above, defines resource roles (like pizzaMakers), resource role types (like PizzaMaker) and resource cardinality constraints (like "exactly 2") for all types of activities. Normally, in an OE simulation there is a one-to-one correspondence between resource role types and resource pools. By convention, a resource pool has the same name as the corresponding resource role type, yet pluralized and starting with a lowercase character. For instance, the name of the resource pool for PizzaMaker is pizzaMakers.

Notice that OrderCall events are exogenous, having a recurrence function defined case-wise for each of the five hours per day operation of the pizza service company (in the attached invariant box).

For implementing the waiting timeout event defined in the process model, the activity type TakeOrder has a class-level waitingTimeout function implementing a random variable with PDF U(3,6).
Process Design Model

A process design model, in the form of a DPMN process diagram as shown below, is derived from a conceptual process model by abstracting away from items that are not design-relevant and possibly adding certain computational details.

A DPMN process design model (like the one shown in Figure 5-2) essentially defines the admissible sequences of events and activities together with their dependencies and effects on objects, while its underlying OE class design model (like the one shown in Figure 5-1) defines the types of objects, events and activities, together with the participation of objects in events and activities, including the resource roles of activities, as well as resource cardinality constraints, parallel participation constraints, alternative resources, and task priorities.

Figure 5-2. A process design for the Make-and-Deliver-Pizza business process

It is an option, though, to enrich a DPMN process design model by displaying more computational details, especially the recurrence of exogenous events, the duration of activities and the most important resource management features defined in the underlying OE class design model, such as resource roles (in particular, performer roles can be displayed in the form of Lanes) and resource cardinality constraints. The following model shows an enriched version of Figure 5-2:

Figure 5-3. An enriched process design model

Such an enriched DPMN process design model includes all computational details needed for an implementation without a separate explicit OE class design model. In fact, such a process model implicitly defines a corresponding class model. For instance, the enriched DPMN model of Figure 5-3 implicitly defines the OE class model of Figure 5-1 above.

The notation for defining performer roles in Lanes consists of a performer role name (such as pizzaMakers) and and an object type name (such as PizzaMaker) denoting its range, separated by a colon. When the performer role name is appended by a multiplicity expression in brackets, as in pizzaMakers[2], this denotes a resource cardinality constraint (stating that exactly 2 pizzaMakers are required). When only a performer type prefixed with a colon (such as :OrderTaker) is provided, this means that the implicit performer role name is obtained by lowercasing the performer type name (as in orderTaker:OrderTaker).

The notation for defining a non-performer resource role, such as oven:Oven, consists of a named object rectangle, such as the :Oven rectangle in Figure 5-3, attached to an activity rectangle by means of a connection line with a small filled square representing a resource link, such as the line between the MakePizza activity rectangle and the :Oven object rectangle in Figure 5-3.

Notice that the model of Figure 5-3 does not include any element representing a resource pool. It is assumed that for any organizational position described in the underlying OE class model, the organization under consideration has a corresponding resource pool. By default , each resource role of an activity type is associated with a resource pool having the same (yet pluralized) name, such that its resources are instances of a corresponding resource role type, which is an organizational position in the case of human resources.

For instance, for the MakePizza activity a pool ovens is assigned to its resource role oven by default. The members of the pool ovens are instances of the (resource) object type Oven. Likewise, a pool pizzaMakers is assigned to the MakePizza resource role pizzaMaker. The members of this pool are instances of the organizational position PizzaMaker. These default pool assignments are normally not shown in a DPMN diagram, but an OE simulator takes care of them.

Combined with its underlying OE class design model, a DPMN process design model provides a computationally complete specification of a simulation model.
Model Variant: Orders May Also Be Taken by Pizza Makers

For decreasing the number of lost orders due to long waiting times, it is advisable to charge pizza makers with taking orders whenever no order taker is available. In resource management terminology, the organizational position pizza maker is redefined by adding the performer role order taker to its portfolio of organizational roles.

In a conceptual OE class diagram, this can be expressed by adding a subtyping arrow from pizza makers to order takers categorized as an alternative resource subtyping arrow with the stereotype «ar», as shown in the following diagram:

conceptual information model describing object, event and activity types

The OE class design diagram is extended in the same way, by adding an alternative resource subtyping arrow from PizzaMaker to OrderTaker.

The DPMN process design model is not affected by this change.