The key ingredients of an ACM case – the Hotel Booking Case in terms of adaptive case management

In a recent post I have introduced the key concepts in Adaptive Case Management (ACM). In the article you are reading now, I want to show an example of a specific case. This example should provide some clarity on exactly how the core aspects of a case are specified and how these provide the foundation for the case as it will be managed  by the ACM engine of choice (for example Oracle BPM Suite 11g).

The example I use – inspired by the surroundings of the Oracle Fusion Middleware Partner Community event on Malta (February 2014) – is a hotel. The scope of the case is the booking and stay of a guest or party of guests. The case starts with the potential guest enquiring after prices and availability. It can conclude in several ways – ranging from the guest having had a pleasant stay to either cancellation, no show or even no booking at all.

This article does not yet discuss the implementation of the case. It introduces the key components that should be produced during design phase of the case and that provide the ingredients for implementing the case as an ACM process.

note: I am not striving for a complete case definition. I am sure many hotels would use different, more extensive case definitions. This article’s objective is only to provide an example to demonstrate the various constituents of an ACM case definition.

Milestones

The milestones identified in my fictitious hotel case are:

1. Booking made: possibly based upon the quote provided to the guest, a booking has been made
2. Booking cancelled
3. Cancellation deadline passed: a guest can cancel a booking up 24 hours before the arrival data; when that deadline has passed, the booking enters a new phase: the hotel starts making preparations and the guest has to pay now – even upon no-show or (late) cancellation; note: this is a special milestone, one that is brought about by passing of the time rather than by an event in the case
4. Guest Checked-in
5. Check-out performed
6. No-show declared
7. Guest Complaint received
8. Guest Complaint handled
9. Case Closed

Not all of these milestones will have to be reached in a case instance. In fact, several are mutually exclusive. Some may be revokable: even when the milestone has been reached, the case stakeholders can be decide that on second thoughts it is not reached after all (for example: after no-show was declared, the guest arrives or after the guest complaint as declared taken care of, the guest persists with the complaint).

Stakeholders

Various stakeholders can be associated with the case. Whether they will have direct to an automated system that orchestrates the case is not yet determined. However, each stakeholder may directly or indirectly influence the case. Some of these stakeholders are internal (from the viewpoint of the hotel) while others are considered external. Not all stakeholders listed have to be involved with every instance of the case.

• sales department (handling quotes and accepting bookings)
• reception desk (handling all interaction with guests during their stay)
• customer care team (dealing with complaints, guest surveys and follow ups)
• general  hotel staff (anyone working at the hotel and potentially in contact with the guests)

External stakeholders:

• guest (the representative of a party of one or more that are part of a booking)
• guest party member
• travel agent (mediating between the guest and the hotel in making the booking)

Associated with each stakeholders are permissions: what can they do to the case? This involves the activities the stakeholders can initiate, the data they can see and manipulate and other case related operations they can perform.

Data & Documents

Associated with each case is data. In fact, the whole notion of a case is based upon some core data elements that identify the essence of a case. Typically, documents are associated with a case as well – providing additional evidence, supporting data, communication trail etc. Some data is stored as part of the case – the case payload or the state of the case. Other data is stored apart from the case and associated with it through references from the case data. The case payload is ideally kept small and limited to the data that is required to identify the case, evaluate the rules that determine when milestones are reaches and when activities are available or should be withdrawn. The payload also has to contain the references to the case data stored external from the case.

Case Payload

Data stored in the payload of the case itself includes:

• booking number
• guest name
• arrival date
• date of departure
• party size
• assigned room number(s)

External Case Data

Associated with the case, but stored externally (perhaps in a database) are data such as:

• the personal details of all party members (note: even though the guests may have stayed in the hotel before, we will store a ‘snapshot’ of these details for each case, to record the immutable state of these details at the start of the case
• details of the use of hotel services including restaurants, minibar, movies, spa, tennis courts, bars; for each at least a transaction number, the time and the total cost is recorded

Documents

For this case of the hotel booking, documents that have been identified include communication (letters, emails, telephone transcripts?) with the guest or travel agent, a copy of the guest’s passport, any bill linked to the room number and signed by the guest, the final bill as made available to the guest.

Activities

The case activities describe the “atomic units of action” in the case. A case activity can be a very simple operation or it can represent a complex process. Activities can refer to human actions or to automated process or to a combination of the two.

Many activities in a case are not always available for execution. Only when certain milestones are reached in the case or specific conditions are met, will the activity be applicable. Activities can be withdrawn: when  they are no longer relevant, they should not be presented to stakeholders. Generic activities can always be instigated throughout the life time of the case [instance], though not necessarily by all stakeholders.

Activities are frequently associated with one or more stakeholders (indirectly, via roles and permissions). Stakeholders play a role in an activity; they initiate the activity or play another role.

Other attributes of case activities include whether they are required, can be repeated and are triggered automatically. Of course at some point we have to specify what exactly the actions are that make up the activity – from simple human task to complex BPMN process.

This table contains a number of activities that have been identified for the hotel booking case. The Pre-condition is a first, crude attempt at describing the rules for activating the activity. The same applies to the Triggered Milestone column that is a first stab at the rules for reaching the case milestones.

Pre-condition	Generic?	Activity	Triggered Milestone	Stakeholder
–	Yes	Provide Feedback		Guest, Travel Agent
–	Yes	Make Enquiry		Guest, Travel Agent
–	Yes	File complaint	M7	Guest, Travel Agent
–	Yes	Add comment		All internal stakeholders
–	Yes	Add document		All internal stakeholders
Not M2, M5	No	Request Price/Availability		Guest, Travel Agent
		Provide Quote		Sales Department
		Make Booking	M1	Guest, Travel Agent
M1, Not M2, Not M3, M5		Cancel Booking	M2	Guest, Travel Agent
M1		Update Booking		Guest, Travel Agent
M1		Book shuttle		Guest, Travel Agent
M3		Assign a (new)Room & Prepare		Reception Desk
Not M2		Check In	M4	Reception Desk
M4		Review Bill		Guest, Reception Desk, Sales Department
M4, not M5		Room Service		Guest
M4		Check Out	M5	Reception Desk
M3, not M4		Declare No Show	M6	Reception Desk
M5		Guest Survey		Guest
M4		Rate Guest		All internal stakeholders
		Follow up customer care	M8	Customer Care Team
M2 or M8 or (M4 and not M7)		Close Case	M9	Customer Care Team, Sales Department

Some of these activities are very simple – such as add document or review bill – whereas others represent multi step processes – such as check in and check out. These latter activities are themselves expressed through a BPMN process. The activity ‘Follow up customer care’ that is executed for guests who have filed a complaint and with a random sampling from all satisfied guests – is one that itself represents a case – a subcase so to speak of this hotel booking case.

Rules

Rules are an important element aspect of a case. They embody the flow logic of the case. Rules determine when activities are available, both when they become available and when they are withdrawn. Automated activities are executed automatically when a rule decides to trigger them, so rules can drive part of the actual processing as well. Rules are defined in terms of milestones (that have been reached or not), other activities that have been executed and the data of the case.

Rules also determine when a milestone has been reached. Based on similar elements (other milestones, activities and the case data), a rule can trigger the completion of a milestone.

Rules are typically expressed in an IF..THEN format: IF <these conditions are met> THEN <make these things changed or happen>. If multiple rules are created with a similar set of conditions (using the same facts – case data, milestone status, activity status, events – checking for different values), they can conveniently presented in what is called a Decision Table. A very simple example of a Decision Table is shown here:

Conditions	Rule 1	Rule 2	Rule 3
milestones reached	M3, not M4
activities performed		check in	check out
case data	current timestamp > latest checkin time
event occurred
Actions
set milestone		M4	M5
initiate activity	declare no show
set case data
trigger custom event

Events

An event in a case is an occurrence of an expected, predefined situation at a certain time and with an associated data context. Many events are generated by simply progressing through a case (instance): reaching a milestone, triggering an activity, completing or withdrawing an activity are all examples of events. Additionally, the definition of a case may include user defined events: events that are specific to the case. These events are explicitly raised, either by stakeholders, from rules or by external systems.

Events are important in a case for several reasons. The events are recorded to provide an audit trail of the case. Events trigger evaluation of the rules that in turn may lead to a  milestone to be declared reached, an activity to be triggered, case data to be manipulated an additional events to be published.

An example of a custom event for the Hotel Booking case could be “Guest has died” or “Technical issues in room”. And if you think about the various episodes of Fawlty Towers I am sure it will be easy to come up with additional events.

Stages or Phases

In many cases, we can discern different phases or stages. Activities may be associated with a specific phase, multiple phases or they can be un-related to phases. There can be a relationship between phases and milestones – but there need not necessarily be. Stages are not always included in a case instance.

In our current case of the hotel booking, several phases are easily identified:

• acquisition – pre-booking
• pre-stay – the booking has been made
• stay – the period during which the guest is actually in the hotel
• post-stay

Sub-cases or inter-case relationships

Cases can have relationships with one another. When a guest returns multiple times to the hotel, each stay results in a case instance [of the hotel booking case]. These instances are related because of the fact that the same guest is a stakeholder in each of them. At a higher level, the CRM department of the hotel could identify a Guest Case that bundles these case instances together – and perhaps itself involves activities such as send a congratulatory email on the guest’s birthday.

The same hotel booking case instances could also have relationships with other case instances for different reasons. All booking cases during Christmas could be considered bundled or even all cases that have overlap, involve participation in the same conference taking place at the hotel or all involve vegetarians.

When designing the case definitions, one challenge is to get the right the level (or granularity) of the case. Is it a case per guest – involving all stays throughout the life of the guest – or a case per booking and stay. Does my physician have a single case [file] on me as a patient, or is a new case opened for each ailment I come discussing with her. Or do both levels exist with some relationship between them. Acknowledging the various inter-case[-instance] relationships is important. When later on we discuss implementation, our tooling should help case workers with finding out about these relationships and provide functionality to leverage information from one case instance in another.

Summary

This article provides an example of how for a specific case – the hotel booking – the essential ingredients that determine the case and the way it is orchestrated could be defined. Once the basic definition of a case is available, in terms of milestones, stakeholders, data, events, activities and rules, we can start thinking about the implementation. In a next article, I will look at the use of Oracle BPM Suite 11g and its built in ACM engine to bring this case to life.

Resources

Prequel to this article: ACM: organizing the chaos and flexing rigid process structures through adaptive case management  – https://technology.amis.nl/2014/02/21/acm-organizing-the-chaos-and-flexing-rigid-process-structures-through-adaptive-case-management/

Introduction to Adaptive Case Management, CMMN (the modeling notation standard for ACM) and the CMMN Web Modeler (not free) for visually designing cases – http://www.cmmnwebmodeler.com/

The ACM Poster from the Masons of SOA (the MSOA team) – outlining all elements of CMMN and there mutual relationships – http://www.opitz-consulting.com/fileadmin/redaktion/pdf/sonstiges/acm-in-practice_poster-a3_sicher.pdf. Also see Torsen Winterberg’s blog: http://torstenwinterberg.blogspot.nl/2013/10/download-our-new-poster-adaptive-case.html

The CMMN draft specification at OMG (the object management group): http://www.omg.org/spec/CMMN/

More background on what is/why and when Adaptive Case Management – Case Management: Contrasting Production vs. Adaptive: http://social-biz.org/2012/09/12/case-management-contrasting-production-vs-adaptive/