I had an epiphany in Seoul, Korea. I was working for IBM. I was modeling the sales operations business process for Samsung. If you have ever modeled a business process, you know that we always look for non-valued added steps in process. The delta between an “AS-IS” model and “TO-BE” model always includes some waste products.
At the time, I was using IBM WebSphere Business Modeler Advanced. One of its features is the ability to simulate workload with multiple variables. The analytics report summarizes the analysis. I noticed how much time was spent on the “exceptions”. I also noticed the percentage of exceptional transactions was high (30%+).
My epiphany . . .
Knowing now (simulated data) that most of the cycle time and cost are consumed by the “exceptions”, I DESIGNED FOR EXCEPTIONS instead of designing for the norm. This had 3 significant effects:
- Forced the internal and joint development teams to rethink the process design process, which led to significantly higher performing process designs.
- Produced significant demonstrable savings (albeit simulated) in cycle times and cost (both transactional and operational).
- Refocused the implementation on automation and middleware versus change management.
An easy example:
On an imaginary piece of glass in front of you (phone, pad, computer), you see 3 options
In this process flow you are an “approver”. The entire workflow downstream requires your approval on this content object before the process can resume. It’s a long running state process with the ability to back track and undo. As soon as you click on “Ask Question” you initiate an <ExceptiontoCatch>.
A process designed to optimize “ask question” TRUMPS “accept” (the norm).
Significant business results achieved when 2 user interface issues are resolved:
- The 80/20 rule applies to asking questions. 80% have already been asked. The trick is to automatically refine the FAQ presentation on the Approver’s glass as he/she types in realtime. This significantly improves cycle times by eliminating 50% of the “ask question” exception handling process.
- DOC automatically fills in tags, IDs, permissions, team profiles, workflow instructions, business rules, etc. The only data the Approver enters is the long description. Long description is unstructured alphanumeric language with codes. This has a 2 fold benefit:
- The Approver ONLY needs to focus on the question. That’s it!
- About 99% improvement is data quality trust.
DOC & FAQ subroutines:
DOC subroutine automatically fills in the form except for the long description.
FAQ subroutine launches and consumes all tags and meta data from DOC. Simultaneously FAQ reads your question (long description) in real time as you type to refine the search results. Search results are dynamic with each word typed. FAQ asks the Approver “Did that answer your question?”. If yes, it initiates Approve and Reject.
My advice to you
- When designing your first To-Be model on any given project, focus on the exceptions. What “triggers” the exceptions should be well documented and understood prior to your first design run.
- Only AFTER you do a design using “design for exceptions” should you think outside the box. If you greenfield prior to DfX, you will waste a few days. Use those 3 days to do more homework on the triggers
- Imagine your “handlers”. Don’t worry if the code is too complex. Imagine an utopian handler and insert her into the process design. Make sure to document your notes on the handler while you are designing her. Not later. You will forget.
John Rector is the President of Mind Media Group, LLC and the Creative Director for Social Media Target, LLC. He lives at the intersection of Business Process Management (BPM) and Social Media. You can reach him at +1-843-327-6008 or email@example.com