12/23/2006

Business Process Mapping: A deep dive into the weeds

Having just completed a large scale enterprise-wide process mapping initiative for a financial institution I thought it would be helpful to post some ideas and suggestions that may help you in your process mapping initiatives in your organization.

Who would benefit from this information?
Any process engineering group, Six Sigma practitioner or person in Enterprise IT who are being tasks to help the business create an "as-is" (current state) of the business processes.

Why this post?
There are many books and articles written on the subject of process mapping, Lean Six Sigma current state, etc. You might find it helpful to get a view "from the trenches" of tackling a complex set of process in your current state documentation.

How do you capture current state?
Many financial organizations, especially those contending with the Sarbanes Oxley requirements, have begun capturing their transactional activities from a compliance standpoint. In most cases this consists of "process documentation" documents which are usually in text form.

The "current state" of core business processes that I refer to here is an entirely different beast. It is the shift from functional-area optimization to true business process management (BPM). BPM is the meta-framework which envelopes common business tools such as Lean Six Sigma, Balanced Scorecard, TQM, etc. It is the state-of-mind shift from "I am responsible to get my department to work in the most efficient manner" to "I am responsible to deliver a streamlined efficient experience and the value demanded from me by the customers of the process I am in charge of".

This means that production managers can not be solely interested in efficient production processes. They are a part of the larger value chain. In a Lean manufacturing environment which produces on-demand they are part of the order delivery value chain. This value chain begins in the order taking (call center, sales reps, etc), through order assembly (create order, order parts, order assemblies) continues through production processes and ends in the order being delivered to the requester. Does this sound too "manufacturing-ish" to you? Not at all! A custom life insurance quote could follow the same value chain. A custom marketing material as well. What about the order for a new custom hosting services from an ISP?

All of the above examples are transactional in nature and help illuminate one key point: If each of the individuals who participate in the entire value chain is only interested in the optimization of their work area then who is looking out for the customer between the hand offs? How can we assure timely delivery if requests are queued in the inboxes of each department tasked with requests for the next phase of the value chain? Who is asking the most fundamental questions about the customer's true needs?

If this all seems to digress from the topic at hand, mind you it is not! Business process mapping requires that the "mapper" align themselves to the value chain which they are documenting. This means that if you are being asked to map a narrow aspect of a much larger value chain, stop and think if you are not erring in a too narrowly defined scope.

The importance of a model
So you have properly defined the scope of the business processes you will be mapping. Perhaps this was done in the context of a Lean Six Sigma Define Phase, which creating a project charter. Next you next to determine how will you present processes that span multiple functional areas.

A hierarchical representation of these processes is essential to the success of your effort. This allows you to create a top level enterprise wide model, and drill down levels of detail before you even start tracking the activities and hand-offs that are part of your business processes.

Example 1:

You are capturing the core business processes for the credit card operations of a financial institution. At the highest level you will probably list the following possible core business processes in what we, at CC Pace, like to call "Level 0":



  1. Product Management: This would include the creation and modification of new credit cards and account types, including all benefits attached, regulatory filings, SarbOx requirements, etc.
  2. Application Processing: This high level process would incorporate all the processes that begin with an individual or business entity applying for participation in one of the product groups managed by Process #1
  3. Account Servicing: Sending out statements, handling inbound calls/customer service, web account services and contested charges processing.
  4. Funding Processing: Processing of check payments, roll-overs from other credit card accounts, online payments, etc

This would be a great opportunity for you to create a nomenclature for designating a code to each business process. If we are capturing the as-is state of a credit card LOB within a banking organization, perhaps we would call these CC1, CC2, CC3 and CC4. Whereas retail banking Level 0 processes would begin with RB1, RB2, etc.

You might come up with more examples, but the ultimate result is a limited inventory of very high level processes without which your line of business would not be operating as a credit card company.

Once you have created the Level 0 diagram you are ready to inventory all the processes underlying the Level 0 core processes in a Level 1 diagram. What does account servicing exactly entail? Should we group or bundle similar processes? Level 1 processes for CC3 - Account Servicing would possible look like this:

  • CC 3.1: Statement Handling
  • CC 3.1.1: Paper Statement Generation
  • CC 3.1.2: Paper Statement Mailing Consolidation
  • CC 3.1.3: Electronic Statement Generation
  • ...
  • CC 3.2: Customer Servicing
  • CC 3.3: Web Processing

At this level (Level 1), you are still creating an inventory of business processes.

It is at the next level - Level 2 and beyond where you will start creating process flow swim lane diagrams. Swim lane diagrams represent how activities within a process are organized by roles, systems, and business units and are useful for understanding the hand-offs between and among people and systems.

You might want to check out Laury Verner's article posted on BP trends: The challenge of process discovery.

One picture is better than a thousand words

The most imporant part of your process mapping initiative lies in your presentation. Many people have tried to capture business processes and the chances are someone has already done so in your organization. What you may be doing differently is in helping create an enterprise-wide view of the core business processes, break it down to a layered structure (Level 0, Level 1, Level 2) and only then start capturing the actual activities that these processes consist of. How you represent Level 0 and Level 1 is up to your creative ingenuity. The more thought you put into migrating away from text towards graphical objects, the easier it will be for others to understand your thinking.

Using a reference model

When you embark on your journey you will be asked for the methodology driving your implementation. Aligning yourself to an industry standard can go a long way to creating a common understanding that is supported by benchmarks and best practices that were developed by an industry group. There are great reference model out there that you can align your project to, which will help you to quickly populate your Level 0 and Level 1's in addition to the benchmark/best practices benefits. Here are a few examples:

Supply Chain Management Reference models: SCOR, DCOR, CCOR: These standard frameworks are high-level supply chain definitions used by over 700 members of the Supply-Chain Council. Using standardized supply chain process definitions and their associated performance metrics allows your organization to identify and benchmark your processes with the same processes of another Supply-Chain Council member

Open Standards Group (OSG) ITIL: an industry standard source for information technology activities and best practices which facilitates the strategic management of IT by identifying strategic objectives for IT. These objectives define the different perspectives for how the business views the overall value delivered by IT.

TelManagement Forum (TMF) Telecom Operations Map® (eTOM): is the TeleManagement Forum’s industry standard business process framework used by telecommunications service providers and their suppliers of all kinds.

Good luck in your work! Let me know how I can make this information more helpful to you in the future!

Tiran

No comments: