When Manufacturing Data Analytics Ends Up Making You Mad

Imagine, the founder of a manufacturing data analytics company telling you about how analyzing your machines and analyzing your manufacturing data could ultimately end up really bumming you out? That’s exactly what I’m prepared to do.

It’s true, I speak as an expert at a lot of major manufacturing events and the “data” is overwhelmingly telling me this is the case (data = what good manufacturers tell me).

Most manufacturers start their journey towards better data by saying, “We just need to know this simple handful of things”. The theory being that those simple things would provide some pretty dramatic improvements.

It makes sense on paper, but it always ends with manufacturers being really frustrated. Then, they do one of two things…

  1. Nothing
  2. Something that costs them too much money

How to collect simple manufacturing data

Collecting simple manufacturing data isn’t that hard. Most manufacturers that are seeking to understand the simple stuff — like when the machines are up, when they are down, when they are producing to schedule, and when they underperforming — run into the same problem.

They do the bare minimum to achieve fairly accurate representations of this information and then ask why?

Why are we producing less during the second shift?

Why is downtime higher in the evenings?

Why did we produce 50% less according to schedule on Tuesday the 9th?

Using free — or very cheap — tools to understand basic OEE metrics and manufacturing KPIs leads to overwhelming frustration. That’s where I come back to my two bullets above.

manufacturing data analysis

Why simple manufacturing data drives leadership crazy

Not being able to understand why something isn’t the way it’s supposed could drive anyone crazy, but it becomes even worse once you know exactly whats wrong but don’t have the ability to dig into why its happening.

This is a common scenario I see manufacturing floor managers run into all the time with manufacturing executives. They now have data showing some of the errors occurring on the plant floor.

It’s almost always stuff that the people working on the floor can tell you about in one-off scenarios, but cumulatively, it is not really being recorded in any way. This results in those simple metrics highlighting the accumulation of all these little things in reports that leadership sees.

Why were the machines down Tuesday around 3pm? Maybe unscheduled maintenance, maybe the shift was short-handed and needed to perform a fast changeover, maybe Jerry went on a break???

Leadership wants to know why, and this usually means one of two decisions is rendered…

  1. Data is deemed not helpful and abandoned (money down the drain in many different ways)
  2. The company wants to understand why and thinks they will need a lot of custom tools and configurations to do so

Doing manufacturing data analysis without spending a stupid amount of money

So, let’s pretend that neither option sounds good. Good idea. Neither are good.

How do you get the data you want without spending ungodly amounts of cash on something like Tableau?

Well, step 1 is avoiding business intelligence solutions like Tableau. It’s not that you cannot configure these tools to deliver exactly what you need to know… they can tell you everything you want to know… but…

  • These tools do not acquire data. They rely on existing databases. Companies must deploy new data acquisition tools in each factory and synchronize that data into Tableau (i.e. buy more software).
  • These tools do not automatically contextualize any data. The existing data must be processed to add production standards, shifts, part numbers etc (consultants or internal employees will rack up hours doing this)
  • Any KPIs have to be built from scratch in Tableau, nothing comes out of the box (this can really take a long time if you think your business is different from other manufacturers).

So… you probably want to hear the part about not spending a lot of money. Well, it is a bit shameless on my part, but that’s why I built SensrTrx. To solve this exact problem. Manufacturers want good data without buying any additional software, configuring anything using consultants or internal IT staff, and they would prefer it not be a big costly hassle.

SensrTrx aside, that’s the whole point of industry-specific analytics solutions.

Why data analytics systems need to fit manufacturers

Out of the box, manufacturers should be looking for an analytics solution that can tell them WHY. Why were machines down, why are the machines producing less… etc.

Look for a solution that fits your budget that will allow you to understand a simple question like:

I see the machines were down and we didn’t produce to capacity on Tuesday between 3-5pm, why?

You want to be able to see things like changeovers, machine error/alarm codes, and trends in performance during similar time periods.

What about all my manually entered one-off data?

This is actually one of the things we have been finding has helped manufacturers the most recently. When trying to digitally capture the nature of how your shop floor is running, it is nearly impossible to start without being able to record all the weird stuff that happens on a nearly daily basis.

Being able to input, capture, and record manual data is really important, and something that is often missed even by the most expensive and sophisticated systems.

If you’re just starting out, make sure you find ways to capture and record events from the people that actually have boots on the ground.

I just want simple manufacturing data analytics

We all do. But what you likely really want is data presented in a simple way, that allows you to dig down deep into details as needed.

This is what you should strive for right off that bat.

Projects that spend the bare minimum to capture top-level data are almost always longterm failures. Those systems are quickly outgrown (usually day 1), and then manufacturers are forced to make one of those two awful choices — or I would be thrilled if you took a look at a 3rd option that I think is perfect for this scenario.