MES Software: Vendors, Features & Costs Compared 2026
MES software compared: vendors, functions per VDI 5600, costs (cloud vs. on-premise) and implementation. Honest market overview 2026.
The Ishikawa diagram — also called fishbone diagram or cause-and-effect diagram — is a root-cause analysis tool that maps every potential cause of a specific problem into structured categories, displayed as "bones" branching off a central spine that leads to the "head" (the problem statement). Invented by Kaoru Ishikawa at the University of Tokyo in 1943 and popularised through Toyota's quality circles in the 1960s, it remains the most widely used root-cause analysis tool in manufacturing — because it forces a team to think systematically rather than jump to the first plausible explanation. In DMAIC, the Ishikawa diagram is the primary tool of the Analyse phase. In daily shopfloor management, it is the structure behind every serious "why did this happen?" conversation.
The classic manufacturing Ishikawa uses 6 categories — the "6Ms." Each M represents a family of potential root causes. The team brainstorms specific causes within each category and places them as sub-branches on the fishbone.
| Category (M) | What it covers | Example causes (OEE drop on press line 3) | MES data that supports the analysis |
|---|---|---|---|
| Machine | Equipment, tooling, automation, sensors, PLC logic | Hydraulic pressure fluctuation. Worn die insert. Sensor drift causing false rejects. | Alarm history, downtime Pareto, process parameter trends (pressure, temperature) |
| Method | Work instructions, procedures, process parameters, recipes | Changeover procedure not standardised. Pressing speed set 5 % above specification. No documented startup sequence. | Cycle time distribution, changeover time analysis, recipe parameter comparison across shifts |
| Material | Raw materials, components, consumables, incoming quality | Material lot 2024-B7 has higher hardness → increased tool wear. Sheet thickness variation at upper spec limit. | Scrap rate per material lot, process parameter correlation with incoming material properties |
| Man (People) | Operators, training, experience, staffing, shift patterns | New operator on night shift not trained on die alignment. Understaffing → delayed changeover response. | OEE per shift / per operator, downtime reason classification per shift, changeover time per operator |
| Milieu (Environment) | Temperature, humidity, dust, lighting, vibration, layout | Shop floor temperature above 35 °C → hydraulic oil viscosity drops → pressure instability. Dust on optical sensor. | Environmental sensor data (if connected), correlation of alarm frequency with seasonal temperature patterns |
| Measurement | Gauges, calibration, inspection criteria, data accuracy | Go/no-go gauge out of calibration → good parts rejected. OEE appears low because quality counter is wrong. | Reject rate trends, SPC data, comparison of automatic vs. manual count data |
Not every Ishikawa uses all 6Ms. Some manufacturing teams add a 7th M (Management — decisions, priorities, resource allocation). Service industries use different categories entirely (4Ps: Policies, Procedures, People, Plant). The categories are a thinking framework, not a rigid template. Use whatever structure forces the team to look in corners they would otherwise ignore.
| Step | Action | How to do it right | Common mistake |
|---|---|---|---|
| 1 | Define the problem | Write a specific, measurable problem statement at the head. "OEE on press line 3 dropped from 72 % to 58 % in week 14" — not "press line 3 has problems." | Vague problem statement → vague causes → no actionable countermeasure |
| 2 | Draw the spine and bones | Horizontal arrow pointing to the problem. 6 diagonal branches for the 6M categories. Use a whiteboard, flip chart or A3 sheet — physical is better than digital for the initial brainstorm. | Building it alone in PowerPoint → no team input, no cross-functional perspective |
| 3 | Brainstorm causes | For each M, ask: "What factors in this category could contribute to the problem?" Write every cause on the branch — no filtering, no judging. Include operators, maintenance, quality and engineering in the room. | Only inviting engineers → missing operator knowledge about what actually happens on the shift |
| 4 | Add sub-causes | For each primary cause, ask "why?" and add sub-branches. "Hydraulic pressure drops → why? → Oil viscosity too low → why? → Oil temperature too high → why? → Cooler filter clogged." This is where Ishikawa meets 5-Why. | Stopping at the first level → treating symptoms, not root causes |
| 5 | Verify with data | This is the step most teams skip — and it is the most important. Take the top 3–5 suspected causes and check them against real data. Does the alarm history confirm pressure drops? Does the OEE comparison between shifts confirm an operator-related pattern? Does the scrap rate correlate with material lot B7? | Accepting brainstorm hypotheses as conclusions → fixing the wrong cause |
| 6 | Define countermeasure | For each verified root cause: who does what by when? Document on an action tracker. Review in the next shopfloor meeting. | Completing the diagram and putting it on the wall → no follow-up, no action, no improvement |
The entire process takes 30–60 minutes for the brainstorm (Steps 1–4) and 1–5 days for data verification (Step 5). The brainstorm without the data is opinion. The data without the brainstorm is directionless. The Ishikawa diagram is the bridge between the two.
| Method | Where Ishikawa is used | What it connects to |
|---|---|---|
| DMAIC (Six Sigma) | Analyse phase — to generate and structure root-cause hypotheses | Follows process mapping and data collection from the Measure phase. Feeds into Design of Experiments or hypothesis testing in Improve. |
| 8D Report | D4 (Root Cause Analysis) — to identify all potential causes before verifying the true root cause | The verified root cause from the Ishikawa feeds D5 (corrective actions) and D7 (preventive actions). |
| A3 Problem Solving (Lean) | Root-cause analysis section of the A3 sheet | Connects brainstorm to countermeasure on a single page — the Ishikawa is often sketched directly on the A3. |
| Jidoka Step 4 | Root-cause investigation after the machine stops and the immediate fix is applied | The Ishikawa ensures that the Jidoka cycle leads to permanent countermeasures, not just repeated fixes. |
| Daily shopfloor meeting | When a recurring downtime event or quality defect needs structured analysis beyond "we'll look into it" | The team identifies the problem from the MES dashboard, builds the Ishikawa at the shopfloor board and assigns actions. |
The Ishikawa diagram has one structural weakness: it works on hypotheses. The brainstorm generates 20–40 potential causes. Without data, the team either (a) picks the loudest voice's favourite theory, (b) picks the cheapest fix, or (c) tries to address all 40 causes simultaneously. All three lead to wasted effort.
An MES transforms Step 5 (verify with data) from a multi-day manual investigation into a 10-minute dashboard exercise:
The result: the team completes the Ishikawa brainstorm in 30 minutes and verifies the top causes with MES data in the same session — because the data is already on the screen. No one needs to "go back and check." The gap between hypothesis and verified root cause collapses from days to minutes.
How many causes should an Ishikawa diagram contain?
There is no fixed number. A typical manufacturing Ishikawa has 15–30 primary causes across the 6 categories, with 2–4 sub-levels of "why?" on the most promising branches. If you have fewer than 10, the brainstorm was too narrow — you probably missed a category. If you have more than 50, you are over-detailing before verification. The rule: brainstorm wide, verify narrow. Generate many hypotheses, then use data to eliminate 80 % of them.
Is the Ishikawa diagram the same as the 5-Why method?
No — but they are complementary. Ishikawa maps all potential causes across categories (broad). 5-Why drills into one specific cause chain (deep). The best practice: use the Ishikawa to identify the most likely cause categories, then apply 5-Why to the top 2–3 branches to reach the true root cause. Ishikawa without 5-Why stays at the surface. 5-Why without Ishikawa risks drilling into the wrong cause chain.
When should I use an Ishikawa diagram vs. a Pareto chart?
Pareto tells you what — the Ishikawa tells you why. Start with a Pareto analysis of your MES downtime or scrap data: "The top 3 downtime reasons account for 65 % of total losses." Then build an Ishikawa for the #1 reason: "Why does alarm #3012 fire 47 times per week?" The Pareto prioritises where to focus. The Ishikawa explains why the problem exists. They are sequential tools, not alternatives.
Can the Ishikawa diagram be used for OEE improvement?
It is one of the most effective tools for OEE improvement — if applied correctly. Define the problem as a specific OEE gap: "Availability dropped from 88 % to 79 % on line 4 in March." Then build the Ishikawa with the MES availability loss data as input: downtime reasons, alarm patterns, changeover times, maintenance events. The 6M structure forces the team to look beyond the obvious ("the machine is old") and into the systemic ("the preventive maintenance interval is based on calendar time, not actual running hours — and the MES shows the machine ran 30 % more hours than planned").
Related: DMAIC · 5-Why · Six Sigma · Kaizen · Jidoka · OEE Explained · SYMESTIC Alarms Module · MES: Definition & Functions
MES software compared: vendors, functions per VDI 5600, costs (cloud vs. on-premise) and implementation. Honest market overview 2026.
OEE software captures availability, performance & quality automatically in real time. Vendor comparison, costs & case studies. 30-day free trial.
MES (Manufacturing Execution System): Functions per VDI 5600, architectures, costs and real-world results. With implementation data from 15,000+ machines.