ARTIFICIAL INTELLIGENCE, DATA & ANALYTICS
BESPOKE DATA VISUALISATIONS
AI ADOPTION SOLUTIONS
CUSTOM SOFTWARE DEVELOPMENT
CLOUD & OPERATIONS
EMBEDDED SOFTWARE
DATA & AI ADVISORY
IOT, CLOUD, DELIVERY & ENABLEMENT
Ask most operations leaders how long a reliable weekly or monthly report takes to produce, and the honest answer is usually “longer than it should.” One person pulls data from the Enterprise Resource Planning (ERP) system. Another exports data from the Manufacturing Execution System (MES). A third checks quality figures in a separate log or spreadsheet. Then someone spends a lot of time reconciling it all into one version a leadership team can trust. This can easily become accepted as part of the reporting process.
The problem is that manual reporting is rarely just an administrative issue. It usually shows gaps between systems, definitions, or processes. The real cost is not just the time spent preparing a report. It is also the delay between something happening on the factory floor and management being able to understand it and act on it.
The main reason is not usually a lack of data. In most manufacturing businesses, the data already exists. The challenge is that it was created for different purposes, in different systems and often in different formats.
Each system may work perfectly well on its own. The difficulty appears when you need to combine information into one consistent view. For example, the same production line might be called Line 01 in one system, L01 in another and Assembly Line 1 in a local spreadsheet. Product codes, machine names or downtime categories can have similar differences.
Timing can also create problems. One system may report by calendar day, while another follows production shifts. A night shift that starts on Monday and finishes on Tuesday may therefore be recorded differently depending on the source. Common measures can also be defined differently. For example, one team may include planned stops in downtime, while another excludes them.
None of these issues is particularly difficult to solve on their own. The problem is that when the same matching, checking and correcting has to happen every reporting cycle, it creates a process that is slow and heavily dependent on manual work.
The obvious part of manual reporting is copying and pasting data. But in many cases, that is not where most of the effort goes. They usually spend that time checking the data.
Someone notices that the production total in the report does not match the number they expected. They go back to the source system and check whether an order was completed. They may then contact someone in production or finance to confirm which figure to use.
The same thing happens when different departments use slightly different definitions. Take on-time delivery as an example. The logistics team may consider a delivery on time if the truck leaves the site as scheduled. The warehouse team may measure it based on when the goods are loaded and ready for dispatch. The customer service team may consider it on time only when the shipment reaches the customer.
Each measure can make sense from that department’s point of view, but management still ends up with different numbers. At that point, the meeting starts with a discussion about which number is correct instead of why deliveries are late and what can be done about it.
Having an ERP, MES and BI platform does not automatically mean that data will flow cleanly from production to management reporting. These systems were created for different jobs.
An ERP mainly covers business processes such as orders, materials, inventory, planning, and finance. An MES is closer to production and focuses on what is happening on the factory floor. BI tools then take data from those systems and turn it into information that people can analyse.
This separation is normal. The gap appears when the information moving between systems is incomplete, inconsistent, or not designed for how the business now wants to report. Each system may describe a different part of the same event, while a management report needs to connect them all. If that connection has never been built properly, somebody often ends up creating it manually.
The first cost is employee time. If several people spend part of every week collecting, correcting and reconciling information, those hours add up. But the higher cost can be the effect on decision-making.
Imagine a production line that has been missing its target for three weeks. The raw data already exists, but the weekly performance report requires information from production, maintenance and quality. Because the report takes a few days to prepare, managers are always reviewing information that is already several days old. The issue may still be visible, but the business has lost valuable time.
There is also a less obvious cost: trust. When managers repeatedly see different figures for the same KPI, they start questioning the reports. People create their own spreadsheets to check the official numbers, and those spreadsheets then become additional versions of the truth.
Over time, more effort goes into proving the numbers than understanding what they mean.
Some manual work will always exist. For example, a monthly board report may require commentary and explanation that cannot simply be automated. The warning signs appear when people repeatedly do work that shouldn’t need repeating.
If two or more of these sound familiar, the problem may not be the report itself. It may come from how the data is collected, defined, or brought together. That does not necessarily mean you need new technology. A better starting point is often to understand where the manual work comes from and why it is still needed.
Start with the report that causes the most pain. Choose a report that regularly causes disagreement or delays, or takes too much time to prepare, and work backwards from it.
Where does every number come from? Which system owns it? What is changed manually? Which calculations happen in Excel? Which steps are repeated each time? Where do people normally find errors?
This exercise usually shows quite quickly where the real problems are. For example, you may discover that 80% of a weekly report is already available automatically and only a small part requires manual work. That remaining 20% is where the investigation should focus.
Perhaps downtime reasons are stored as free text. Maybe product codes do not match between systems. Perhaps one plant records quantities in pieces while another uses cases. Or the logic used to identify completed production orders is different between systems.
These are much more specific problems than saying, “Our reporting is too manual.” And specific problems are easier to solve.
A better process does not necessarily mean every report is fully automated. It means that people spend less time preparing information and more time using it.
Regular reporting data should come from agreed sources. Important measures should have clear definitions. Repeated transformations should happen in a controlled process rather than in somebody’s personal spreadsheet.
There should also be a clear difference between data preparation and business commentary. For example, a manager may still need to explain why output was below target. That requires operational knowledge. But the manager should not need to spend an hour finding the correct production volume before writing that explanation.
A useful test is simple: if the same manual step happens every reporting cycle and follows the same rules, ask why it is still manual. There may be a good reason, but sometimes the answer is, “Because we have always done it this way.”
A common misconception is that improving reporting means replacing existing systems and starting again. In most cases, that is not necessary. The existing systems often already contain most of the information the business needs. The main issue is how that information is connected, defined and prepared for reporting.
A practical approach is to improve what happens between the systems. This may mean creating better integrations, using automated exports or adding a reporting layer that brings data together without changing how teams work day to day.
Teams should also agree on definitions before focusing on technology. If different teams use different meanings for “downtime” or “on-time delivery”, a new tool will not solve the problem. The same applies to product codes, machine names, or plant identifiers recorded differently across systems.
It also makes sense to automate the most repetitive work first. Replacing five Excel files with one BI report is not a major improvement if someone still has to prepare and upload the source files manually every week.
The goal is not to remove every human step. Some manual work will always remain, especially where judgement is required. The aim is to reduce repetitive preparation, improve consistency and make reliable information available when the business needs it.
Consider a manufacturer shipping goods to customers every day.
One system contains customer orders and planned delivery dates. The warehouse system shows when goods were picked and loaded. Transport data shows when trucks left the site and when deliveries reached the customer.
In the old process, someone has to export data from each system, match shipment numbers and check for missing or inconsistent records before the weekly logistics meeting. If one team measures on-time delivery from when the truck leaves the site, while another uses the actual customer delivery time, the final reported figures may require further discussion.
A better process does not require replacing these systems. The data can be brought together automatically, with agreed definitions for measures such as on-time delivery. The weekly report can then show which deliveries were late, whether the delay happened in production, loading or transport, and which customers or routes were most affected.
Instead of spending time preparing and reconciling the numbers, the team can focus on the real questions: Why did these trucks leave late? Was the problem caused by production, warehouse capacity or the carrier? Is the same issue happening repeatedly?
That is what better reporting should achieve: not more reports, but less time preparing them and more time using the information to make decisions.
Reducing manual reporting starts with understanding which parts of the process repeat, where figures are checked manually, and which systems or definitions create extra work.
A practical review can map the current reporting process, identify the biggest sources of delay and show where better integration, clearer definitions or automation could remove unnecessary effort. The aim is not to automate everything, but to make reliable information easier to produce and easier to use.
Jagoda Adamczyk
Data Engineer, Holisticon Insight
Our guide, “Making Better Use of Manufacturing Data,” explores six common manufacturing data issues, including slow reporting, conflicting numbers, delayed production information, and problems that can affect AI projects.
Have a question about your manufacturing data or AI plans?
Get in touch with the Holisticon team to talk through what is happening today and where it may make sense to start.