When something goes wrong, the first fix is usually for the symptom. These two tools dig for the cause.
5 Whys
The Lean Enterprise Institute describes 5 Whys as asking why, again and again, to get past the obvious symptom to the root cause. Their example comes from Taiichi Ohno at Toyota:
- Why did the machine stop? A fuse blew from an overload.
- Why the overload? The bearing wasn't lubricated.
- Why not? The lube pump wasn't pumping enough.
- Why not? The pump shaft was worn.
- Why? There was no strainer, and metal scraps got in.
Replace the fuse and it happens again. Add the strainer and it stops. LEI notes that five isn't the point. Keep going until you reach a cause you can remove.
A bot example
A bot's weekly report shows last month's sales figure.
- Why? It read an old file.
- Why? There were two files with similar names.
- Why? Someone saved a copy instead of a new revision.
- Why? Nothing says where the current file lives.
- Why? The skill points to a folder, not a file.
Fix: point the skill at one named file and keep earlier revisions in a separate folder. See The current version at the point of use.
The fishbone
The fishbone, or Ishikawa diagram, after Kaoru Ishikawa, sorts possible causes into categories. The problem is the fish's head. Each category is a bone. ASQ lists it as one of the seven basic quality tools.
The classic categories are the 6 Ms: materials, machinery, methods, measurement, manpower and Mother Nature. For bots, a translation helps:
| Classic | Bot version |
|---|---|
| Materials | Input files and data |
| Machinery | Model and connectors |
| Methods | Skills and playbooks |
| Measurement | The checks and tests |
| Manpower | The person's request and review |
| Mother Nature | Outside changes: a site, an update, the date |
Ask a bot to fill every bone for a failure before picking a cause. It stops the bot grabbing the first plausible explanation.
Where bots differ
A bot can't see its own reasoning the way an engineer can retrace steps. When a bot answers "why did you do that?", it's giving a plausible account, not a replay. So base the whys on evidence: the files it read, the log, the instructions it had. Not its recollection.
And a bot can give tidy whys that sound right. Each answer should point to something you can check.
Back to Engineering tools for bots.