Pareto analysis of machine breakdown causes

A busy sewing floor can log a hundred or more machine stoppages a month. Looked at one by one, they feel random: a needle here, a belt there, a motor that will not start on Tuesday morning. Maintenance teams respond to each one, the month ends, and the next month looks the same. Nothing improves because nothing has been prioritised.

Pareto analysis is the simplest tool for breaking that cycle. It does not require software, statistics or a consultant. It requires a month of honest malfunction records and about an hour of sorting.

The principle in one paragraph

The Pareto principle, named after the Italian economist Vilfredo Pareto, observes that in many systems roughly 80 percent of effects come from about 20 percent of causes. The exact numbers vary; it might be 70/30 or 90/10 on your floor. What holds almost everywhere is the shape: a few causes dominate, and a long tail of rare ones share what is left. On a garment floor, the dominant causes are usually familiar ones such as broken needles, thread tension problems and skipped stitches, but you should never assume. Let the data name them.

Step by step: building the chart

1. Collect one month of malfunctions. For each one you need the machine, the reason and the downtime in minutes.
2. Group by reason. Add up the total downtime for each reason. Also note the count, but do not sort by it.
3. Sort by total downtime, highest first. This is the key choice. A fault that happens 40 times but takes two minutes each is 80 minutes. A motor failure that happens twice but stops a line for five hours each time is 600 minutes. Downtime, not frequency, is what costs you output.
4. Calculate the cumulative percentage. For each row, add its downtime to all rows above it and divide by the grand total.
5. Draw the line at about 80 percent. The reasons above that line are your priority list. Everything below it is the tail; deal with it later.

A worked example

Here is a realistic month from a 60-machine knitwear factory, with 3,000 minutes of total downtime:

Four reasons out of fifteen explain 80 percent of the downtime. Notice that the top reason, motor faults, happened only four times. Sorted by count, it would have been near the bottom, and the team would have spent the month on thread breaks while the real loss came from four long stoppages that probably shared a cause, such as unstable power or missing spare motors.

From chart to action

A Pareto chart is only useful if it changes what people do next month. For each reason on the priority list, ask two questions: why does it happen, and why does it take so long to fix? Typical answers from the example above:

• Motor faults: keep one spare servo motor per machine type and check the voltage stabiliser on that line.
• Thread tension: standardise thread quality per style, and add tension checks to the operator's start-of-shift routine.
• Hook timing: move the affected machines onto a weekly preventive check, as described in preventive vs corrective maintenance.
• Broken needles: check the needle size against the fabric weight of the current style; heavy fleece often breaks needles chosen for jersey.

Then repeat the analysis next month. If the actions worked, the top bars shrink and new reasons rise to the top. That is progress, not failure. You can also run the same chart by machine instead of by reason, which quickly shows the handful of machines that may be reaching the end of their useful life, a topic covered in the machine lifecycle.

Why free-text reasons ruin the analysis

The single biggest obstacle to Pareto analysis is how reasons are recorded. If each mechanic types whatever comes to mind, one month's log might contain "thread cut", "thread breaking", "خيط بيقطع", "tension" and "problem with thread". Grouping them by hand takes hours and depends on guesswork. Worse, vague entries like "machine stopped" cannot be grouped at all.

The fix is a fixed list of 10 to 20 reasons agreed with the senior mechanic, with "other" allowed but reviewed. When a reason is chosen rather than typed, the grouping is automatic and the analysis takes minutes instead of an afternoon. The same discipline helps with the downtime figures that feed MTBF and MTTR.

Using Nasij for the raw data

Nasij is built around exactly this discipline. Malfunctions are logged against the machine with one or more reasons chosen from a predefined list, together with the start and end time, the line, and the style and operation in progress. Supervisors open the machine by scanning its QR sticker with any phone, so the record is made at the moment of the stoppage. Because the reasons are structured and the downtime comes from real timestamps, a month of malfunctions groups cleanly by reason, by machine or by line, which is all a Pareto chart needs. The same records are useful when you review the daily numbers every factory owner should see.