Current State Structure Models

So far, our Business Engineering discipline has developed a mission or vision statement that provides direction and guardrails. We have also developed a capability map that identifies specific abilities an enterprise has and describes what the business does. Both of these are rather abstract. There are no specifics about how the organization accomplishes anything. This post will identify how to provide some of that detail.

In the capability blogs, a capability was defined as "an ability of an organization to perform some specific purpose using an assembly of people, process and things." This assembly or composition is something that can be leveraged to provide more information. More information on who provides the capability (people or teams), how the capability is provided (process) and what is used to provide the capability (things). We can provide detail for each of these, and we will do so within the bounds of a capability.

Before we venture any further I should mention that many considered sources say you shouldn't spend time capturing the current state of your business. That your efforts should be focused on where you want to be and on how you want to perform. While I agree with the intent of this position, it doesn't quite match what happens at ground level. This is especially true for larger organizations.

What really happens is your company delivers products and services by someone or some team of people following established processes and using available tools. Recall from the blog introduction how we defined what a business engineer does. Except for greenfield engineering, and still even then, you have some platform from which to start, and you are making changes to that platform. That effort is much easier if everyone involved understands the current state and shares the same thought space.

In the spirit of the agile philosophy that values "working [systems] over comprehensive documentation" and "just enough design", we want to capture the current state to the point where capturing more detail provides little or no additional benefit. This is different for every organization and every need, but I am specifically not advocating formal UML® or BPMN™. Indeed, capturing capability composition can readily be performed at a coarse-grained level with rudimentary tools.

• Who are the people involved? Identify the internal and external roles as actors; identify internal cost centers.
• What are the processes involved? Show the interactions between actors and black box systems.
• Which systems/applications/technologies are involved? Show the relationships between black box systems.

Some portion of all of the above can be captured in simple box and line diagrams. So, let's look at an example of something that would provide a skeleton to support the abstract concepts we have presented so far. This simple example is limited to a single level 0 capability - 4.0 Manage and Process Customer Claims from the capability map of my fictional health care company (HalenessHC) provided in an earlier blog post.

You should know that this diagram was created in a couple hours by someone (me) who has never done any work in the healthcare industry. Please be forgiving in your critiques.

What does this very simple model of a portion of the company's ecosystem tell us?

• We see major system components and several of their properties.
• We know if the components are developed in-house, are COTS (Commercial Off the Shelf) systems or are externally hosted/provided.
• We see the specific roles and stakeholders that depend on the system and the specific components they interact with.
• We see the relationships that exist between major system components.

We see all this within the context of managing and processing customer claims (capability 4.0).

What this diagram actually shows is data flow between roles and system components. Because of the data flow and the context provided by the capability, we can infer other things.

We can reason the impacts of changes to the environment or to functionality.

• If we want to outsource the Policy Management System, what interfaces need to be managed?
• If we want MyHealth to show claim information, do we build a new interface into the Claim Manager; do we only show settled claims captured in the document management system (IBM DMS)?

We can glean process flow.

1. A policy is created and stored in the Policy Management System. The information in the Policy Management System is supplemented by data from PolicyInfo.inc (a fictional source of insurer information to determine if a claimant has multiple coverage).
2. At some point a claim is generated. It is received via a clearinghouse (CortexEDI or ApexEDI) or from paper received and processed by Docufree.
3. The Claim Manager uses information from the Policy Management System and its internal rules engine to process the claim.
4. A claim may be flagged for adjudication.
5. The processed claim is paid using the Accounts Payable module of Oracle ERP which sends an ACH payment advice to Wells Fargo.
6. The Service Provider and the Claimant are notified of the processed claim via post or E-mail through Smart Communications system and the NCP service.
7. The processed claim is stored in the document management system.

Finally, we can fit this diagram into a series of similar diagrams that describe other capabilities. This allows us to see the larger ecosystem and the high-level flow suggested by the capability model.

While there are, admittedly, a number of holes in this diagram (error handling, audit, etc.), what it provides is a base of knowledge. You don't have to spend time and money discussing the current state to get everyone level-set. It provides a straw man at which you can throw darts. It is a starting point for discussions. This diagram provides all the above benefits with very little cost - MS Visio and a few hours.

I hope you also recognized that this current state model allows us to reason about the future state. We don't have a future state view to guide decisions, but we can at least discuss impacts and options. This allows discussion of possible future states.

So, spend a little time capturing the current state. It will help you get to where the considered sources say you should be - focusing more on the future and where you want to be. Small win!

Next Blog Topic: Bootstrapping Business Engineering - Current State Behavior Models

Happy Engineering!