Structuring AS-IS and TO-BE Process Improvement Discussions using the Fishbone Diagram

Featured
120735 Views
7 Comments
30 Likes

Fishbone Diagram (Ishikawa diagram)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.

Use the fishbone or Ishikawa diagram to identify improvement opportunities

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 – [email protected].


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

Like this article:
  30 members liked this article
Featured
120735 Views
7 Comments
30 Likes

COMMENTS

Derek Weeks posted on Wednesday, November 3, 2010 9:54 AM
Mr. Monteleone, you article is certainly helpful to those approaching business process improvement initiatives. Taking a holistic view of process improvements, certainly will improve the overall quality of the analysis.

One thing I would appreciate seeing is a way to prioritize potential improvements on the rib bones. Perhaps a color-coding of rib bones with hot-spots that need to be addressed, assuming some ribs are performing optimally and others need more analysis and optimization.

derweeks
chrisM posted on Wednesday, November 3, 2010 11:27 PM
I agree, useful article. I'm happy to see performance measurement included in your model. I just finished reading "Measuring the performance of business analysts" by Adriana Beal, and more than ever I'm convinced of the importance of adopting performance measures, including for measuring the results of any adopted improvement initiative.
chrismonerat
Derek Weeks posted on Thursday, November 4, 2010 9:03 AM
Chris,

You bring up a good point about "measuring the results of any adopted improvement initiative". I wonder if that means that you are first establishing a performance baseline for the current project, and then quantifying how new process improvements will improve from that baseline? I wonder what the best ways are to quantify and communicate those improvements?

Cheers,

Derek
derweeks
Theo Kukard posted on Sunday, November 7, 2010 5:10 AM
It's always good to see an article that gives structure to an area like this, giving focus to a lot of expert thought. I have just one comment - the references in the article are over 20 years old (1985, 1988) ... I do find it a little disconcerting in the year 2010 when an article uses such dated references.
theo.kukard
Derek Weeks posted on Monday, November 8, 2010 7:27 AM
Theo,

On the past couple of weeks I have heard people reference practices from Peter Drucker from the 70's, Einstein from the 30's, and Dave Packard from the 80's. Sometimes, it is completely relevant to reference best practices from the past. I like you, enjoyed the article for what it was worth.

Cheers,

Derek
derweeks
zarfman posted on Wednesday, November 10, 2010 5:17 PM
Greetings;

I really can’t get my mind wrapped this fishbone diagram thing. I am somewhat familiar with the works of Deming and Ishikawa. Unfortunately that doesn’t seem to help.

To me an iterative process is one that changes over time. Process improvement typically is not instantaneous. I don’t see any time in figure one or the diagram above it.

I’m not sure which way figure one flows, I suspect it is from left to right. If this is true, I would expect the process to be improved to be on the left and the result of all the fish boning, namely the improved process on the right. Moreover, to actually find out if the process was in fact improved it has to be implemented. Then we have to wait some period of time to find out if the improved process is actually improved.

I don’t understand how Ishikawa’s technique works for a dynamic system. For example how does it work in the situation where an exogenous variable(s) caused an enterprises year to date profits swing from profit to a loss in the fourth quarter.

What am I missing?????

Regards,

Zarfman
zarfman
gres posted on Tuesday, September 26, 2017 11:09 PM
Dear Mr. Monteleone.
Thank you very much has wrote and publish this article; very helpful to me.

Regards
Bonagres
Medan - North Sumatera - Indonesia
bonagres
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC