When somebody decides to write down how they find a fault, they almost always open a drawing tool. Visio, Lucidchart, Miro, or a whiteboard photographed on a phone. It feels right, because a diagnostic procedure genuinely is a branching thing and a flowchart is genuinely how you draw a branching thing.
It works for about twenty minutes.
Where it falls over
The first problem is that a real fault tree is bigger than it looks. A modest one for a single machine gets to fifty or sixty steps. On a canvas, that means you spend more time dragging boxes so the arrows do not cross than you do thinking about the fault. The layout becomes the work.
The second problem is that a drawing has no idea what it is describing. A box containing the text "check supply voltage at terminal 12" is, to the software, a rectangle with a string in it. It cannot know that this step expects a measurement, that the expected value is 24 volts, that anything under 20 means go left, or that there is a photograph of the terminal that would help. All of that has to be crammed into the box as prose, or left out.
The third problem is the one that actually matters. A drawing tells you nothing about what happened when someone used it. Which route did they take? Where did they end up? Did the tree send them to a component that turned out to be fine? A PDF on a shared drive cannot answer any of that, so the procedure never improves. It is written once, printed, laminated, and slowly goes out of date.
What a purpose built tool can do instead
If the software knows that a step is a diagnostic step, several things become possible that a canvas cannot offer.
- You stop laying out a diagram and start writing a sequence. Position becomes the tool's problem, not yours.
- A step can carry structure: a measurement to take, an expected range, a photo, a reference to a drawing sheet.
- The person following it sees one question at a time on a screen they can read at arm's length, rather than hunting for their place on an A3 printout in bad light.
- Every run leaves a record. Over a year you can see which branches get used, which ones never fire, and where people abandon the tree because it stopped being useful.
That last point is the reason BuntelliData exists at all. A fault tree that nobody revises is a document. A fault tree that gets corrected every time it sends someone down the wrong path is an asset that quietly gets better while your team is busy doing other things.
The honest caveat
None of this beats a flowchart for the first ten steps of your first tree. If you have one procedure and it fits on a page, draw it on a page. The case for a dedicated tool starts when there are twenty procedures, four people maintaining them, and no way of knowing whether any of them still reflect the plant as it stands today.
That is the situation I have watched play out repeatedly, and it is the one BuntelliSystems is being built for.
Previously: starting with a name and a domain.
Next: first look at the builder.