We have already seen the importance of having good KPIs in industry and the importance of their visualization, as well as the most interesting plugins for displaying indicators in Industrial Grafana. But for a data project to be successful in industry, it is also essential to take into account the most common problems so as not to commit them.

Today we bring you a guide to 6 problems that exist in all production plants that, although they may seem trivial, have the potential to derail even the most promising projects.

But don’t worry, because these problems can be solved… We explain it below.

Most common problems in industrial data projects:

Not having a common language 🗣️

Imagine the situation: you are in a meeting and someone asks, ‘What is the OP329379 operation?’ and nobody has a clue, because it is the code that the PLC uses, or the code that the ERP uses, and nobody else uses it.

This kind of confusion arises when we don’t share a common language between different systems that handle data. The solution is simple, but crucial.

💡 Matching languages: the first thing is to standardize the language, making common links, usually with identifiers, between the different systems that handle data. Indicators must also be clear, well documented.

This exercise of putting the language in common so that we all speak the same language and know what we are talking about is essential, because otherwise problems arise and we suffer from: ‘No, this data is not valid, it is not good’. No, it’s that actually… you are talking about different things!

💡 The calculation must be global: it is very common in industry to hear the classic ‘I just don’t calculate it like that’. It is essential that you all agree and set standards, and make sure that KPIs are always calculated in the same way. This step is very important and is something you will always need to do, or you will run the risk of your projects becoming a tower of Babel of misunderstanding.

Working with bad data and not discarding it 🌊

Erroneous or inconsistent data can lead to the wrong conclusions. From exorbitant production estimates to inconsistencies between systems such as ERP and MES.

Your factory probably doesn’t produce 1000 parts in 1 hour, nor does your cycle time go below nanoseconds. That’s why it’s important to establish benchmarks and rule out these anomalies.

💡 Setting limits and filtering out anomalies to prevent small errors from becoming big problems.

In the example above, if we see that our hourly production is 1000 pieces, it’s easy to determine that we’re facing an error. But if you don’t delete it, when you add the data, or see it in an average, then that data that gave a peak is diluted. Those 1000 pieces will become a daily extra production of 40 pieces. And what was an obvious error before, now becomes difficult to appreciate, we will see it as a productive improvement that is not real and will be problematic for us.

💡 It is necessary to synchronize the different data sources: sometimes ‘someone lies‘ not because they want to, but because of a bad synchronization of data, because they don’t speak the same language, because identifiers are not related, because end of production times differ, and so on. And then we come across things like peak production time is sandwich time, because someone doesn’t press a button in the ERP… Solutions like Industrial Grafana allow centralizing and linking different data sources, solving this problem.

Difficult access to data 🔑

One problem we often encounter is access to data. Accessing machine data can be very difficult, either because there is no access, because machines are old or because the manufacturer does,’t give access.

Or yes, I give you access, but with the manufacturer’s own platform. They don’t work with standards, with OPC UA, with MQTT, etc. but have a proprietary protocol that usually involves reprogramming and paying for it.

 

💡 Sensorize the machinery: the solution is often, and especially in older machinery, to incorporate sensors that, although they do not replicate every metric of the machine, will give you valuable information about production.

Sometimes, just by counting parts we have a lot of data: when a machine is stopped, how much it produces…. And we can add, for example, temperature sensors for predictive maintenance.

💡 Buy prepared machinery: it is crucial that in any purchase of machinery that you make, even if you do not work with data, the machine is prepared, it can speak standard protocols, that data can be collected at no additional cost….

All of this is easier to negotiate when you are buying the machine than later, and remember that sooner or later you will end up wanting to get data out of it.

Of course, it must also meet cybersecurity criteria: it must not send data, or connect automatically, but you have to open a port on the router to do so.

Avoiding the human factor: Biases and Perspective 🧠

The tendency to want to ‘see everything’ can lead us to lose sight of what is important. It is important to be clear about what questions we want to answer, what issues we have and what data we need.

💡 Applying the Pareto principle can help us focus on the 80% of the data that provides the most useful information with less effort than the remaining 20%.

💡 In addition, it is important to be aware of biases that can distort our interpretation of the data:

• Selective approach: ‘I analyze quality, but I am only able to measure the end of the line, the rejects.’ In this case, I’m missing what’s going on in the middle. Sometimes we can’t measure absolutely everything, but be aware of it.
• Survivorship bias: Discarding for example data from the out-of-service machine history. This can lead to problems.
• False causality: ‘In August we have fewer defects’ Yes, because we produce less. Be careful, because sometimes the variables simply coincide without having anything to do with each other, or they are correlated but there is no cause-effect relationship.
• Sampling bias: Be careful with ‘I don’t care about premium lines’, and when we take the overall OEE of the plant I do it without taking into account the premium lines. Maybe these premium lines are hard for us to monitor, but we should be aware that we are not counting them.
• Gambler’s fallacy: If I don’t see one type of failure for a month, ‘Ah, it’s fixed’. Maybe we have fixed it, but maybe it’s just not happening.

Lack of simplicity and clarity in KPI visualisation 📊

Another classic problem in digitization projects is that moment of saying: ‘I want to go back to Excel, I want to download this dashboard and this data in Excel’. Let’s not forget why we started this whole project.

Defining complex KPIs that nobody understands is a path that leads to frustration.

💡 Choose simple and clear indicators that everyone knows. To learn how to use the best KPIs for your dashboard and properly display them, I recommend you take a look at how we can make Grafana a key tool for Industry: The best KPI for industry and how to display them in Industrial Grafana.

💡 Also, avoid common visualization mistakes:

• Not starting with the axis at 0: It depends a bit on what we want to do, but in general, it’s good practice to start with the Y-axis at 0. Otherwise, it may look like small variations are much bigger than they really are. This is a typical trick in political debates (in the following image, both graphs are the same, but the perception is completely different).

• Overusing doughnut charts: In typical pie charts, when you go beyond three categories, you see absolutely nothing. You are not able to tell which colour is bigger, and at that point we recommend using bar charts.

Excessive alarms and notifications: Less is More 🔔

Alarms must be carefully managed to avoid information overload.
The situation: ‘Hey, send me a report every day on a PDF, etc…’ and ending up not using it at all is quite common. And it’s better not to complicate things.

💡 We must be careful with alarms and try to distinguish them by levels of severity. And always notify the person who needs to be notified and on the right device.

💡 We must also be careful with mobile phone alerts, because they can be very intrusive. A mobile phone alarm should be reserved for situations that really require it. Otherways, there are other ways to report it, by email or just visually.

Most common problems in data projects: Conclusions ✍️

Addressing these 6 challenges will pave the way to more successful and efficient projects. Let’s remember that, in the world of data, sharing a common language, ensuring accuracy and accessibility of information, and keeping it simple are a solid foundation that will help you make the best decisions.

If you wish to see an example of how to properly manage these types of problems with Grafana for industry, we recommend you take a look at our demo: