Statistics: (25878 Views) (6 Comments) Print Posted: Monday, November 01, 2010 Categories: Business Process Management (BPM), Analytical and Problem Solving Skills, Process Improvement (CMMI, Six Sigma, SPICE, etc.), General Business Analysis

In a process improvement project, the analysis team needs to model and examine several aspects of the current (AS-IS) value chain under study.  The purpose of the analysis is to create a visual diagram of the value chain along with its associated text and metrics and determine if there are possible areas of improvement (e.g., reductions in cost or time).  If improvements are identified, the team constructs a modified value chain model (TO-BE) with the improvements and then conducts a gap analysis on how to transition to the new value chain.  This article focuses on the analysis of the current value chain by providing a method for structuring the AS-IS and TO-BE process improvement discussion.

After an analysis team builds the AS-IS model using techniques such as simple flowcharting, the United Modeling Language (UML), or Business Process Model and Notation (BPMN)*, they need to examine what process improvements are possible to support a credible business case to justify a TO-BE implementation. 

The AS-IS and TO-BE analysis needs to be organized to ensure a comprehensive study.  One method is to use an iterative adaptation of the fishbone or Ishikawa diagram (1) commonly used for root cause analysis.  Essentially the use of the fishbone is expanded to not only determine root cause, but also to identify improvement opportunities.  The iterative adaptation is described below. 

1. Use the fishbone in figure 1 to search out what are the AS-IS process improvement opportunities within each rib aspect.

2. For each process improvement opportunity, place the opportunity as the fishbone head and use the fishbone again to determine why (root cause) the opportunity exists.  If the team discovers it is due to a rib aspect, then ask a series of why questions to determine the root cause – the 5 why technique (2).  The answers to these questions will lead the team to the “real” change needed to realize the improvement opportunity.

Figure 1. Process Improvement Fishbone Diagram

Figure 1 depicts a fishbone diagram with the process to be improved at the head of the fish and a process improvement aspect at each rib of the fish spine. Below is a list of questions that the team needs to pursue for each aspect. Note there is no specific aspect order for the team to follow and that iterations involving several aspects can be expected.

• Primary Users (swim lane participants)

  • Do the job descriptions need updating?

  • Do primary users have the adequate education, training, licenses, certifications, and/or experience need to perform the assigned tasks?

  • Are the business decisions assigned to primary users at the appropriate organization level?

  • Is the primary user inhibited due to the work environment?

• Management Control (nonfunctional requirements)

  • Are materials usage (controlled substances such as precious metals, currency, drugs) controls needed in the process?

  • Is separation of duties and/or authorization limits required?

  • Are physical and electronic security accesses required?

  • Is protection of Intellectual property needed?

  • Are conflicts of interest, consent forms, and/or nondisclosures required from primary users?

• Workflow Tasks (orchestrations)

  • Does each task add value to the final result? (audit caution – although tasks may appear not to add value it may be a necessary management control task)

  • Is there wait or idle time due to time triggers or delayed input?

  • Can serial tasks be done in parallel with little additional risk?

  • Is there movement of work product with no value added?

  • Are any of the tasks inhibited due to the work environment?

• System Interaction (choreographies)

  • Can tasks be accomplished more efficiently with systems directly interacting with other systems (e.g., B2B application)?

  • Can tasks be accomplished more efficiently with primary users interacting with a system?

  • Can the usability of an existing system be improved?

  • Do existing system interactions execute valid business rules?

  • Can the existing system be extended to eliminate delays in the process?

• Communication Network (process collaborations)

  • Are message flows effective communications between

    • primary users?

    • systems?

    • processes?

• Information Flow (data transfers between tasks)

  • Is the needed information provided to accomplish each task?

  • Is information stored appropriately per nonfunctional requirements (audit trail, data retention, backups, disaster recovery)?

  • Are there opportunities to gain efficiencies by automating tasks (see system interaction)?

  • Are there possibilities of implementing new or enhanced tools to the primary user?

• Performance Measurements (leading and lagging metrics)

  • Are adequate leading metrics established within the process to allow the process owner to investigate task performance in order to affect final results?

  • Are adequate lagging metrics established at the end of the process to allow for trend analysis of the final result?

• Business Decisions

  • Are the current business decisions based on valid business rules?

  • Can business rules be changed to allow opportunities for efficiencies (challenge business rule assumptions and constraints)?

Note to effectively utilize the business decisions rib aspect, the team needs to document the business rules separately from the process model (3). This facilitates:

• a simpler representation of a process without complex path choices

• a way of defining business rule combinations via rule families (tables)

• changes in either the business rules or process without impacting the other

After the AS-IS “what and why” iterations are complete, the analysis team then builds the TO-BE model depicting the changes cited in the AS-IS analysis along with a gap analysis on the transition.   The team should present the TO-BE transition as improvement alternatives and as stages depending on the risk tolerance of the value chain owner(s).  Metrics need to be included by the team to support change justification.  Most important, the team needs to ensure that the TO-BE model is viewed in the context of the whole value chain (4).  This will prevent a sub-optimal value chain.

Since this adaptation provides a visual and reuses a familiar technique from root cause analysis, the analysis team should find this method easy to utilize.  However, even with this structured guide, the team may still find value in having a facilitator guide the analysis.  After the analysis is complete, the team should follow-up with the Project Management Office or Center of Excellence to validate the lessons learned as new entries in the organization’s Best Practices database.

References

1. Ishikawa, Kaoru (1985) [First published in Japanese 1981]. What is Total Quality Control? The Japanese Way, New Jersey: Prentice Hall.

2. Ohno, Taiichi (1988), Toyota Production System: Beyond Large-Scale Production, Productivity Press

3. Von Halle, Barbara, Goldberg, Larry, The Decision Model: A Business Logic Framework Linking Business and Technology (IT Management), Auerbach Publications

4. Porter, M.E. (1985) Competitive Advantage, Free Press, New York, 1985.

* With the issue of BPMN 2.0, there is a subtle name change from “Business Process Modeling Notation” to “Business Process Model and Notation” due to the inclusion of a BPMN meta model.

Author:  Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University.  He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance, and certified in BPMN by BPMessentials.  He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business.  Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – mark.a.monteleone@sbcglobal.net.

Topmost article image © Marzky Ragsac Jr. - Fotolia.com