The cause and effect diagram was created by Kaoru Ishikawa in the 1960s. It's a formal brainstorming tool for identifying possible root causes. The purpose of a cause and effect diagram is to gather information and ideas from as many people as possible and to explore all possible causes of a problem. It allows you to identify, explore and display a problem and all the possible causes in a structured way. Strangely this tool has three commonly used names. Ishikawa called it a cause and effect diagram. Others called it an Ishikawa diagram in his honor. And because of its appearance, many people call it a fishbone diagram. These are all names for the same tool. There are a lot of ways to brainstorm ideas. The fishbone or Ishikawa diagram is a somewhat structured approach to brainstorming, specifically aimed at identifying potential causes. This is the basic layout of a fishbone or Ishikawa or cause and effect diagram, you see it looks like the skeleton of a fish. And our analysis is intended to identify major factors, those are the big bones, that contribute to the problem. And then further break these down in to more elementary causal factors, the little bones, that cause these factors to create or prevent problems. There many different suggested categories for fishbone diagrams, but you don't need to be constrained to follow any of them. The major reason for these labels is to get participants to think of different types of causes. This scheme is probably the first one that was widely used. And you can make up your own categories, whatever fits your department or your application best. Do not confine yourself to a certain number of categories. The number of major bones is not critical, but it's usually four to six. Let's consider a few other examples. Oftentimes, customer service problems are caused by an institution's policies. Legitimate and necessary policies may cause problems for a variety of reasons. A policy intended for one purpose may have unintended consequences in another area. Policy may have become absolute, but remains in place. A policy maybe applied incorrectly because it's poorly understood or ambiguously defined. A policy maybe causing problems because no one has bothered to identify legal approaches to living within the policy and still accomplishing what needs to be done. Procedures are a frequent source of perceived waste in customer service problems. When a customers looking for a service, they're not likely to enjoy being told that they must follow some lengthy procedure that from their point of view has little or nothing to do with the service they're expecting. Long lists of required signatures, multiple forms requiring redone the information in inexplicable waiting periods cause people to feel like the procedures rather than their needs are what is driving the process. Service enterprises involve lots of people who interact directly with customers. As such, people represent our greatest opportunity to delight customers and our greatest opportunity to disappoint them. People must have the knowledge, skills, and authority to provide the services that our customers are looking for. Every time one of our employees has to say to our customer I don't know how to do that or I tried, but it didn't work or I'm not allowed to do that, we create at the situation where our people disappointed our customers. Finally, we have potential problems with our physical plant or facilities. This can include lack of facilities or lack of access to these facilities, or old and outdated facilities that do not meet customer requirements. Some naming schemes seem to fit different situations better than others. It's really not important which scheme you use or whether you create your own, the important thing is to consider lots of different types of causes. To use a fishbone diagram, first draw the fish bone structure with the problem at the head. If you've carefully constructed a problem statement, including measures, it should go there. Then add your categories, remember, these are just to spur different ideas, different areas of thought. Don't agonize over the categories. Now you're ready to brainstorm with your team. One approach is to use post-it notes. Just write the idea on a post-it and stick it next to the appropriate bone. Do not let the team get in a debate about which bone is the best fit, this is a distraction. Either pick a bone or write the idea twice. When the diagram is complete, you can take a picture to preserve the work for subsequent use. Here is a customer service example. A precise problem in the head is a good idea, but it can be a general statement of the problem, it can be a product or a process or a service. And the causes can be thought of more as enablers, rather than sources of problems. This tool can be a lot of work to set up and use. It's small groups that are often simpler tools for identifying root cause. But, if a problem is particularly complex or difficult, or if you want the input of a large number of people, there's an alternative to the small group brainstorm. You can create a large fishbone diagram perhaps on four by eight foot foamcore. Then supply post-it notes and mount the diagram in an area where anyone and everyone will see it. Anyone walking by can read the diagram, and contribute by posting a note. Used this way, the diagram must be actively managed. At least once a day you should organize the notes, and remove any that are not serious suggestions. You might leave it up for a week. And you can get suggestions from people on other shifts, even from suppliers or customers visiting your work space. Cause and effect diagrams may be an effective tool for generating ideas from small or large groups. This is a brainstorming tool. It generates a large quantity of ideas about possible causes. It does not identify root cause. The team needs to investigate all of the ideas and use other means to identify probable causes.
