Three levels of abstraction in BPM - Part 1: Business Unit Level

  • Article

I identified, in an earlier post, that I believe that there are three levels of abstraction in business process modelling.  The highest level (what is often called the 30,000 foot view), is the Business Unit Level.

This blog entry will discuss some of the attributes of models at the Business Unit level and some of the rules that should be followed to keep your models clear, consistent, and useful.

To see the overview, visit:
https://blogs.msdn.com/nickmalik/archive/2004/09/14/229641.aspx

At the business unit level, you are modelling the interactions between business units involved in a set of related business processes.  A business unit may be departments within a company, or may represent partner relationships, or customer relationships.  One example I am somewhat familiar with is the flow of medical claims data from a medical provider to one or more insurers who may (or may not) provide some payment against the claim. 

It is important to note that different departments in a single organization may very well be part of the model.  This level is not restricted to showing only the boundaries created by actual business ownership.  However, to keep this level of abstraction clean, you need to know the boundary for where to start, and where to end. 

The boundary for the business unit level begins when a business document is completely defined.  For example, a medical claim may contain information about the ambulance charges, room charges, durable medical equipment, and doctor's fees for procedures provided through the institution.  An entire process may take place to create the medical claim (it usually does) and an ongoing process may take place to validate, modify, and/or supercede it.  However, this process is outside the scope of our business unit level model until the business document is created.

In some scenarios, the fact that a document has been communicated to a partner actually defines its existence.  For example, if I send a claim to an insurer, I will assign a claim number that is unique to me.  In some systems, the claim number is not assigned until I send the claim, and at that point, it becomes a claim.  Before that, no claim exists.  Additional charges for the same patient would be sent on another claim.  In this sense, the fact that the document needed to be transmitted stands as the "moment of creation" for the document.  When defining the business unit level processes, this is a boundary.

As I mentioned in my overview, the business unit level of workflow description is characterized by a single set of steps, one "thread" of interaction.  Of course, business doesn't really follow a single pathway.  However, the interaction will follow a single "typical" thread which can be modified by the addition of messages.

So, in our example:

    • The hospital sends the insurance claim to Blue Cross. 
    • Five days later, the hospital sends a message to Blue Cross asking them for status of the claim. 
    • Two days after that, Blue Cross sends a message asking for more information. 
    • The next day, a reply arrives with the results of a particular test (for example). 
    • A week later, a message is sent from Blue Cross to the hospital providing information on a payment that the insurer is making to the institution to cover the charges.  Blue Cross sends a document to their bank instructing payment to be forwarded to the hospital.

Some definitions:

Business Document: A business document is a self-contained, uniquely identifiable document that exists as a snapshot of data in existence at a point in time.  

Message: A message is a self-contained request or command that is passed from one party to another with the expectation that the message itself, or the response to it, will affect the business processes in one of the parties involved.  Messages refer to documents.  They do NOT refer to people, or entries in a database (both of which change over time).  Messages refer to a document that does not change. 

Some considerations:

The life-span of the workflow model matches the lifespan of the document.  If a document continues to live, on one side or another, after the primary interaction is through, then the workflow model continues to exist as well.  As a result, a great deal of document management issues, as well as information archiving and retrieval, can creep into workflow.  Remember that, at this level of detail, we deal with documents and messages.  The methods that a business unit may employ to fulfill their committment to respond to a message are not useful details at this level of abstraction.

One document may give birth to another document.  In our example, a claim gives birth to a payment.  Note that a payment is not a message.  It stands alone from a claim. A document may be sent from the insurer to the hospital informing them of the existence of a payment, along with messages that tie the payment to specific claims. These two documents may (normally will) have different lifecycles.

So, in conclusion, the Business Unit Level illustrates the interaction between business units, is tied together with the creation of a document and continues through it's lifespan, and describes the interactions in terms of the document and messages that refer to it.

[minor edits made in Aug of 2008]