A company may have an ERP system, production planning software, warehouse data, machine information and extensive reporting, yet still not know exactly what is happening on the shop floor and which situations require action.
A coherent view of operations does not require a single system. It requires clearly defined responsibility for data, a controlled method of exchanging it, shared rules of interpretation, and information about how current and complete the data used to assess the situation is.
The goal is therefore not to collect everything in one place, but to build an information flow that makes it possible to determine where execution is deviating from the plan, what is causing it and whether a response is needed.
Why does ERP not always provide a complete view of the current situation?
ERP may be the most important business system in a manufacturing company and still not contain all the information needed for day-to-day production control.
It may store orders, deadlines, product structures and production orders. Assessing the current situation may also require the schedule, operation progress, material availability or information about resource unavailability.
That is why the answer to the question “Can this order still be completed on time?” is often not available directly in a single system.
This does not mean that the ERP system is unsuitable. The information needed for a decision may simply emerge only after data from several sources has been combined.
What does a coherent view of operations mean?
A coherent view of operations is not about displaying all available data on one screen. It is about being able to determine quickly:
- whether execution is proceeding according to plan,
- where a deviation has occurred,
- what caused it,
- how it may affect subsequent operations or deadlines,
- which situations require action,
- whether the data allows the situation to be assessed reliably at all.
A list of orders, statuses and deadlines presents data. A view that identifies a specific deviation, its cause, its expected impact and the freshness of the information provides a basis for making a decision.
The details should still be available. However, users should not have to reconstruct the entire analysis themselves every time by comparing several systems.
Integration should be designed around decisions, not systems
A better starting point is not the question “How do we connect ERP, MES and WMS?”, but:
“What decision do we want to make, and what information are we currently missing in order to make it?”
Suppose we want to know whether the next operation can start according to schedule. We can then work through the following elements:
business question -> required information -> data -> source -> rules -> required freshness -> method of presentation or action
The required information may include, for example:
- the planned start time of the operation,
- completion of the preceding operation,
- availability of the required materials,
- availability of the machine and other resources,
- the status of material preparation for the workstation.
The assessment rules must then be established.
A delay in the preceding operation does not necessarily indicate a problem if the schedule includes enough time buffer. Similarly, material that has not yet reached the workstation does not necessarily present a risk if preparing and delivering it will take less time than remains before production starts.
From a technical perspective, the data must be made available, transferred and processed. Its meaning, however, follows from the process, planning rules and operating methods of the specific company.
How to connect ERP, planning and production data
Integration should create a controlled flow from source data to the information used in decisions. Access to several systems alone is not enough.
At a high level, three layers can be distinguished:
data sources and exchange -> data model and business rules -> presentation and action
1. Data sources and exchange
The first step is to determine where the information required for a given process originates.
In one company, most of the information may reside in ERP. In another, the schedule is created in an advanced planning and scheduling system, or APS, while execution is recorded by a manufacturing execution system, or MES. Warehouse operations may be handled by a warehouse management system, or WMS.
Not every company needs all of these systems. What matters is where the required information is actually created.
Data can be obtained through an API, an interface that allows systems to exchange data, or through exchange files. Updates may occur at regular intervals or in response to a specific event. ETL processes are used to extract, transform and load data into the target environment.
Older systems may also allow data to be read directly from the database. In that case, it is necessary to verify whether the access method is supported by the vendor, what load it creates and whether it will remain compatible with future versions of the system.
The method of exchange should reflect the needs of the process. If the data only needs to be refreshed once a day, a mechanism that responds to every event may be unnecessary. If a machine stoppage should affect the assessment within several dozen seconds, synchronisation once an hour will be insufficient.
2. Data model and business rules
Obtaining data from several systems does not yet mean that the data can be combined directly.
The same object may have different identifiers, statuses and meanings. “Operation time” may mean planned time in one system, actual machine working time in another, and include changeover time in yet another.
Relationships must therefore be defined between elements such as:
- customer order,
- production order,
- operation,
- material,
- resource,
- deadline,
- current execution status.
Only then can shared business rules be applied and information calculated that does not exist directly in any of the source systems.
3. Presentation and action
The result may be provided as a report in a business intelligence tool, an operational dashboard, a list of alerts, a dedicated screen or a function within an existing system.
A new application is not always necessary. Some of the required capabilities may already exist in the ERP system, planning tool or analytics environment. Before creating new functions, it is worth reviewing the capabilities of the systems already in use.
If users only need to analyse the result, presenting it is sufficient. If they also need to take action, it is necessary to determine which system should record and execute the change.
A comment or the assignment of a responsible person may remain in the operational layer. A change to the schedule, the priority of a production order or warehouse data should be sent to the system responsible for that information.
Users should be able to see whether an instruction is awaiting execution, has been executed in the target system or has failed. Accepting a request does not mean that the change has actually been applied. The operation must also respect the permissions and rules in force in the target system.
How to divide responsibility for data between ERP, APS, MES and WMS
In integration, determining which system is responsible for specific data and in which system that data can be changed is more important than copying the same information into multiple systems.
For example, ERP may be responsible for the production order, the planning system for the current schedule, MES for recording actual execution, and WMS for specific warehouse operations.
For important data, it is necessary to establish:
- where it originates,
- where it can be modified,
- which system is the system of record,
- which other systems need a copy,
- in which direction synchronisation takes place,
- how quickly a change should be transferred,
- what should happen in the event of a conflict or missing update.
Where possible, it is worth avoiding a situation in which several systems independently modify the same attribute and synchronise it in both directions. Without clear rules for resolving discrepancies, such a model increases the risk of conflicts and makes it difficult to determine which value is authoritative.
The integration should also make it possible to detect when the data flow has stopped working correctly.
Does all data need to be available in real time?
No. Data should be updated as quickly as required by the process and the maximum acceptable response time.
| Need | Example of required data freshness | Example |
|---|---|---|
| rapid notification of an event | seconds or nearly immediate | machine failure, line stoppage, critical deviation |
| ongoing operational monitoring | several to a dozen minutes | order progress, workload, selected material statuses |
| analysis and reporting | hours or once a day | costs, trends, historical data |
Requiring a very short update interval may increase the complexity of the solution. If a manager reviews the state of production every several minutes, an update every five minutes may be entirely sufficient.
However, three different moments must be distinguished:
- when an event or status was recorded or confirmed in the source system,
- when the integration retrieved that information,
- when the user’s view was refreshed.
A successful synchronisation at 10:00 does not automatically mean that the data describes the actual state of production at 10:00. If execution is recorded in the source system with an hour’s delay, retrieving the data more frequently will not provide a current view of the situation.
On the other hand, the time of the most recent record change alone does not determine data freshness. A status may not have changed for an hour, but the system may still be confirming that it remains valid.
The freshness of the source status, the synchronisation and the presentation are three different things.
In an operational solution, it is also worth separating process status from data quality. The absence of a detected risk should not be treated in the same way as a situation in which there is too little data to make a reliable assessment.
Where should KPIs, statuses and business rules be defined?
There is no single correct location for all metrics and rules.
KPIs are key performance indicators. Those used in reporting can be calculated in a shared analytical model, including within a BI tool.
Rules that affect the current process should be treated differently. If an “order at risk” status triggers an alert, task assignment or change in the way work is performed, its logic should be available to the solution that supports the process rather than existing solely as a formula in a single report.
If the appropriate system already calculates the required result, an oversimplified version should not be created unnecessarily elsewhere. This applies, for example, to dates calculated by the planning system or material availability established by the source system.
The most important thing is to have one agreed definition. Where possible, the same logic should not be recreated independently in successive reports and applications.
When assessing production, it is also necessary to distinguish between:
- execution of the plan approved at the beginning of the shift,
- compliance with the current schedule after subsequent changes,
- meeting customer deadlines.
Each of these comparisons answers a different question and should not automatically be reduced to a single “plan attainment” indicator.
The system should also be able to say: “I do not have enough data”
The system should not conceal missing or outdated data.
If the data required for an assessment has not been recorded, its current status cannot be confirmed, or some sources are unavailable, the correct result may be:
“Insufficient data.”
This is more useful than a green status suggesting that there is no problem.
A single synchronisation error does not necessarily invalidate the result automatically. If the most recent reliably confirmed status still falls within the defined freshness threshold, the assessment may remain valid. On the other hand, successful synchronisation does not guarantee that events are recorded in the source system without delay.
What should a reliable operational dashboard show?
A dashboard should not present only the result. For information used in day-to-day decisions, users should be able to check at least:
- what caused a given status,
- which data it was based on,
- how current that data is,
- whether all required sources were available,
- what limitations the assessment has.
If the result is unreliable because data is missing or too old, this should be shown just as clearly as the production deviation itself.
At the first level, the dashboard should indicate what requires attention; at the next, why; and then allow the user to move to detailed data or an action.
BI, operational dashboard or application: what does the company need?
The difference concerns the purpose of the solution more than the specific product.
| Need | Main question | Most common direction for the solution |
|---|---|---|
| analysis | “What happened and why?” | BI, analytical model, data warehouse |
| monitoring | “What is happening now?” | dashboard or operational view |
| action | “What needs to be done?” | task and approval workflow, operational application or capabilities of an existing system |
In practice, the boundaries are not rigid. A BI tool may support some monitoring, ERP may contain task and approval mechanisms, and a dedicated application may both present data and record actions.
The process should therefore not begin with selecting a product category. The first step is to determine whether users need to analyse, monitor or also change the course of the process.
Example: how is the risk of late material delivery determined?
Consider a single production operation. The assumed values are used solely to demonstrate how the assessment is produced.
Suppose the time is 9:55.
| Information | Source | Value |
|---|---|---|
| planned operation start | planning system | 10:30 |
| required component | ERP | X-27, 40 units |
| component availability | warehouse system | 40 units reserved for this operation and approved for issue |
| preparation and delivery status | warehouse system | the process has not started |
| estimated preparation and delivery time | logistics process rule | 45 minutes |
The material requirement and the task associated with delivering the component are linked to the same production operation. The integration must therefore map the identifiers used in the individual systems correctly.
There are 35 minutes left before the operation is due to start. Under standard conditions, preparing and delivering the material takes approximately 45 minutes, and the process has not yet begun.
The rule may therefore state:
“If preparation has not started and the estimated time required to prepare and deliver the material exceeds the time remaining before the operation starts, the system indicates a risk of delay.”
The result should not state:
“The operation will be delayed.”
Based on the available data, the system can identify a risk:
“Risk of a delayed operation start: 35 minutes remain before the planned start, while preparing and delivering the material takes approximately 45 minutes according to the accepted estimate.”
Such a message shows not only the status but also the basis for assigning it.
This rule applies to the stage before material preparation begins. Starting the task itself does not mean that the risk has been eliminated. From that point, the assessment should take into account the expected material delivery time to the workstation and compare it with the planned operation start.
What about data freshness?
Suppose additionally that at 9:53 the warehouse system confirmed that material preparation and delivery had not started. The integration retrieved this status at 9:54, and the view was refreshed at 9:55.
If this status is sufficiently current for the process, the assessment can be performed.
However, if the most recent reliably confirmed status were from 9:20 and it were impossible to determine whether material preparation had started since then, the data might not meet the defined freshness requirements. The system should then indicate that a current assessment is not possible and should not present the most recent result as current.
The correct message would be:
“No current warehouse data: the risk cannot be assessed reliably.”
From information to action
After a risk is detected, the user may refer the issue to logistics. If the priority of a warehouse task is changed, the change should be executed in the system responsible for that process.
The operational view should show whether the instruction:
- is awaiting execution,
- has been executed in the warehouse system,
- has failed.
Raising the priority does not by itself mean that the problem has been resolved or that the material has reached the workstation.
The assessment should be recalculated after the data changes and often enough as time passes. Even when statuses remain unchanged, the time available to deliver the material may be decreasing.
This creates a closed loop:
data -> assessment -> action -> update or passage of time -> reassessment
How to implement a shared view without rebuilding the entire IT environment
There is no need to begin by integrating every system and process. It is better to select one important operational scenario and test it using actual data.
This might be, for example:
- material availability before an operation starts,
- on-time completion of orders,
- downtime monitoring,
- utilisation of a key resource,
- a selected type of quality deviation.
1. Define the decision and scope
Instead of saying “we need a production dashboard,” it is better to specify:
“We want to identify, early enough, operations whose start is at risk because material may not be delivered on time.”
2. Define the data, sources and rules
It is necessary to establish:
- what data the assessment requires,
- where it is recorded,
- which system is responsible for it,
- how current it must be,
- how the rule works,
- who approves it and is responsible for updating its parameters,
- what should happen after a problem is detected.
There is no need to retrieve the entire contents of ERP or MES if the first scenario requires only a dozen or so specific fields.
3. Build a minimal but controlled flow
The first integration may include only a few sources.
However, it should account for:
- unambiguous record identification,
- handling synchronisation errors,
- controlling data freshness and completeness,
- monitoring integration operation,
- the ability to determine the source of a result,
- a way to indicate situations in which an assessment is not possible.
4. Validate the solution using real cases
It is not enough to check whether the system generates correct alerts.
Situations in which a real problem occurred but the solution did not identify it must also be analysed.
The validation should answer questions including:
- whether the problem is detected early enough,
- how many irrelevant warnings the system generates,
- whether important cases are missed,
- whether the user understands the reason for the status,
- whether the data is sufficiently current,
- whether the subsequent action actually reaches the correct process.
Before launch, it is also necessary to agree on the acceptable data delay, the method of indicating failures and responsibility for restoring the integration.
5. Expand the scope after validating the first scenario
After the solution has been validated, further sources, rules and processes can be added.
The initial scope may be small, but the integration method should not prevent such development or lead to a series of independent scripts and one-off connections.
When does ERP integration make more sense than another manual report?
Not every report requires automated data feeds.
If a report is prepared occasionally, does not require many sources and does not affect day-to-day decisions, manual preparation may be entirely reasonable.
Integration is worth considering when:
- the same data is regularly retrieved from several systems,
- manual preparation of information delays the response,
- errors or outdated information have significant consequences,
- the same process is repeatedly reconstructed by different people.
The key question is:
“Is it enough to improve the report, or should data retrieval and preparation also be automated?”
Integration does not have to replace the report itself. It may enable an existing report or dashboard to be supplied with data automatically and according to consistent rules.
Before starting the project, it is also worth comparing the cost of the current process with the cost of implementing and maintaining the integration, and checking whether the required result can be achieved by configuring the systems already in use more effectively.
Does one view of the situation require one system?
No. ERP, the planning system, MES, WMS and other solutions may continue to perform their specialised roles.
The key is to determine which data each system is responsible for, how information is exchanged between them, which rules produce the result and when that result can be considered reliable.
In this application, integration is intended to provide useful information earlier than the current process, without manually assembling it from several places and without concealing situations in which there is simply not enough data for a reliable assessment.
FAQ: ERP and reporting integration in a manufacturing company
Can ERP be integrated with Power BI?
Yes. Power BI can use data from ERP, APIs, databases, data warehouses and other sources. However, the technical connection alone does not ensure consistent reporting. Clear definitions of data and indicators, as well as rules for updating them, are also required.
Does ERP integration require a data warehouse?
Not always. A data warehouse is particularly useful when analysing historical data from multiple systems. In a simpler operational scenario, direct integration of several sources or use of the capabilities of existing systems may be sufficient.
Does ERP data need to be synchronised in real time?
No. It should be available with the level of freshness required by the decision and acceptable response time. It is important to remember that frequent synchronisation will not provide a current view if the events themselves are recorded in the source system with a delay.
Are APS and MES required to build a shared operational view?
No. The required solution depends on the available data and how it is recorded, not on the number of systems in place. In one company, most of the required information may reside in ERP; in another, it will come from several specialised applications.
Does ERP need to be replaced to build a shared operational view?
Usually not. If the ERP system performs its role correctly and the required data can be accessed, it is often enough to connect the existing sources properly and supplement the missing functions.
How to integrate ERP with a production planning system
First, determine which information should flow between the systems, which system is responsible for changing it and in which direction synchronisation should occur. Only then should the technical mechanism and frequency of data exchange be selected.
Can an older ERP system without a modern API be integrated?
Often, yes. Available interfaces, exchange files, an intermediate layer or, after a risk assessment, controlled database access may be used. With older systems, it is particularly important to assess security, stability and the effect of the integration on future upgrades.
