In analysis meetings, the question that follows “what is the problem?” is very often “who did it?”. Yet the right second question is: what conditions produce this result?
The Ishikawa diagram — widely known as the fishbone — forces you to ask exactly that second question. That is why we favour it both in our methodology and in our analysis work.
What is an Ishikawa diagram?
It is a root cause analysis tool popularised in quality management in the 1960s by the Japanese quality expert Kaoru Ishikawa. The problem sits on the right (the fish’s head), a main spine runs to the left, and categories (the bones) branch off the spine:
People Method System
\ | /
\ | /
\ | /
───────────────────────────────────────────────► PROBLEM
/ | \
/ | \
/ | \
Data Measurement EnvironmentPossible causes belonging to each category are written under its bone. The aim is not to lengthen the list; it is to make the causes visible so you can discuss which ones really matter.
Why we favour this tool
It separates the symptom from the root cause. “The stock balance doesn’t add up” is a symptom. The diagram forces us to talk about how the count is done, which transaction is entered late, who uses which screen.
It looks for causes, not culprits. Because the categories are built around conditions rather than people, the language of the meeting changes. You can’t get information from a team that has gone on the defensive; you can from a team looking for causes.
It gathers collective intelligence on a single page. Knowledge from accounting, production and IT sits side by side on the same sheet. Often the root cause emerges from combining what two departments know, not what a single person knows.
It reminds you of the forgotten area. An empty bone is information in itself. If the “measurement” bone is empty, that process is probably not being measured at all.
It leaves a record. The diagram documents why the actions were taken. Six months later, you have the answer to “why did we set it up like this?”.
The bones we use in ERP projects
We adapt the classic manufacturing categories (people, machine, method, material, measurement, environment) to the context of enterprise software:
- People — training gaps, role distribution, staff turnover, competence
- Method — process steps, approval flows, how exceptions are handled
- System — screens, integrations, performance, missing functions
- Data — master data quality, code structure, missing or conflicting records
- Measurement — what is measured, how often it is looked at, who receives the report
- Environment — organisational structure, prioritisation, regulation, seasonal peaks
These six headings cover almost all of the problems we encounter in ERP projects.
How we run it
1. We write the problem in one sentence. Measurable and neutral: for example, “Shipment confirmation is delayed by 2 days on average”. If the problem statement is vague, the diagram will be vague too.
2. We fill in the bones with the team. The people doing the work are in the room. At this stage we don’t filter; we collect ideas.
3. On each important branch we keep asking “why?”. We use the fishbone together with the five whys technique:
System
└─ The order screen is slow
└─ Why? The report query runs every time it opens
└─ Why? The filter's default is "all records"
└─ Why? The default wasn't changed during setup
└─ Why? It's not on the go-live checklist ← root cause4. We validate with data. The diagram produces hypotheses, not evidence. We test which cause really dominates by looking at the data in the system.
5. We tie it to action. Every validated root cause gets an owner, a date and a measure. If it doesn’t, the meeting was just a conversation.
When it isn’t enough
To be honest, the fishbone is not enough on its own.
It doesn’t validate hypotheses; that takes data. It doesn’t tell you which cause weighs more; that is where Pareto analysis comes in. And in complex systems with interactions that feed each other, it can be too linear.
So we don’t use it on its own but together with process maps and data analysis. Its strength lies in making you ask the right question in the right order.
From analysis to solution
Once the root cause is clear, the work changes: sometimes it takes training, sometimes a process change, sometimes a screen or an integration. At this stage our Process Consulting and ERP Project Management work comes into play; when the result needs to be measured, we track it with ErpwareBI.
Two of our posts on this topic may also be relevant: Failed ERP Project and Common traits of failing businesses.