Using Excel in itself does not mean losing control of data. The problem begins when, without manually combining information from ERP, spreadsheets and other systems, a company cannot clearly determine the current state of production, order fulfilment or inventory.

Warning signs include different figures describing the same situation, reports that depend on specific people, data available with a delay, and the inability to reconstruct how a result was calculated. Replacing the ERP system or abandoning Excel is usually not the solution. The first step is to determine which data is needed for decision-making, where it originates, who is responsible for it, and how it is currently processed.

Why does a company still use Excel even though it has an ERP system?

Using Excel alongside ERP is perfectly natural. New planning, reporting and analytical needs often emerge outside the scope supported by the ERP system.

A new report, an additional metric or a change in the planning method may be needed. Modifying the system takes time or requires the vendor’s involvement, so someone exports the data and prepares a solution in Excel.

At first, the spreadsheet may be entirely sufficient. Over time, more columns, formulas, data from other sources, imports or macros are added. The file begins to be used by several people, then by an entire department, and a solution created for a single situation becomes a permanent part of the process.

In a manufacturing company, ERP is usually not the only system. It may be accompanied by systems supporting production execution, warehouse management, quality control and maintenance, as well as solutions that collect data directly from machines.

The risk grows when Excel starts filling the gaps between these systems and becomes the basis for daily decisions.

When does Excel stop being a tool and become an operational risk?

Excel works well for ad hoc analyses, simulations, calculations and one-off reports. Risk appears when a spreadsheet starts acting as a process application, a database, an informal integration layer or the foundation of recurring reporting.

If a planner downloads data from the ERP system to test several schedule variants, Excel is serving its natural purpose.

However, if the current production plan exists only in that planner’s spreadsheet, and without the file no one can determine the order in which jobs should be completed, the spreadsheet has become part of the operational process rather than merely an analytical tool.

The same applies to reports. The mere fact that the final report ends up in Excel does not have to be a problem. The problem begins when preparing it requires downloading several files, copying data, handling exceptions manually, running custom formulas and finally checking whether the result looks credible.

One question provides a useful test:

What will happen to the process if the spreadsheet becomes unavailable or the person who knows how to use it is absent for two weeks?

If the report stops being produced, the plan is not updated, or no one can reconstruct how the result was calculated, the spreadsheet is a critical component of the process rather than merely a supporting tool.

How can you tell that a company is losing control of its data?

The problem should not be measured by the number of spreadsheets. What matters more is whether the information needed for management is unambiguous, current, reproducible and available without manually assembling it from multiple places.

Typical warning signs include:

• production, sales and logistics provide different values for the same job,
• preparing a report requires exporting data from several systems and combining it manually,
• information is copied manually between files or applications,
• only one person knows how to prepare a particular report,
• a meeting begins by determining “which number is correct”,
• a report shows the situation from several hours ago or from the previous day even though decisions must be made in real time,
• two people calculate the same metric and obtain different results,
• managers do not trust the data in the system and maintain their own reports,
• values are corrected manually, but it is later difficult to reconstruct the reason for the change,
• the same object — for example, a product, material, job, batch or machine — has different identifiers in different systems,
• no one can clearly identify the source of a number shown on the dashboard.

If several of these situations occur regularly, the problem no longer concerns a single report. It concerns the way the company creates, processes and uses data.

“Will we meet the plan?” — where does the answer really come from?

Consider one of the production director’s fundamental questions:

Will we complete the production plan by the end of the week and meet customer order deadlines?

The ERP system shows orders, jobs and due dates; the manufacturing execution system shows the actual completion of operations; and the warehouse management system shows material availability. Information about failures and planned downtime is kept in the maintenance system, while the quality system identifies batches that are blocked or awaiting a decision.

At the same time, the planner maintains a separate spreadsheet with the current production sequence, changed, for example, after a machine failure.

Each of these sources may contain correct data. Even so, the answer to the director’s question does not exist in any one of them.

It emerges only when someone gathers the information, combines it, accounts for exceptions and interprets the result.

Data freshness is a separate issue. Some information is refreshed almost in real time, while other information is updated only after the planner manually completes the spreadsheet. It is therefore necessary to know not only whether the data is correct, but also whether it describes the same point in time.

A company may have all the data it needs and still lack an answer to a basic operational question.

If such an analysis is a one-off exercise, manual work may be justified. However, if someone performs the same steps according to the same rules every day or every week, the problem is no longer a lack of data. It lies in the way the data flows and is used.

Why does ERP not necessarily provide a complete picture of production?

ERP supports specific processes and records the related events and transactions, but answering a management question often requires combining the plan with actual execution, material availability, quality status and the situation on the machines.

This does not mean that the ERP system is working incorrectly. The information needed to make a decision simply extends beyond the scope of one process and one system.

The problem is not data fragmentation itself, but the lack of unambiguous sources, combination rules and agreed requirements for data freshness.

A single source of truth does not mean a single system

Organizing data does not require moving all information into one application.

It is far more important to define clearly where each type of data comes from and which source should be treated as authoritative.

ERP may be responsible for order data, the production system for the actual completion of operations, the warehouse system for inventory levels, and the quality system for batch status.

The company therefore does not need one system containing all information. It should, however, have a consistent view of the situation based on clearly defined data sources.

Not every piece of business information has a single source. A metric for timeliness, efficiency or availability may be the result of calculations based on data from several systems.

For source data, an authoritative source must therefore be identified; for derived information, a common calculation rule must be defined.

Merely identifying sources and calculation rules is also not enough if individual systems use different identifiers for the same products, materials, jobs, batches, operations or machines. Common identifiers or unambiguous mapping rules are needed.

The level of detail at which information is to be compared must also be established. An analysis of an entire job differs from an analysis of a single operation, batch or machine cycle. Data may be correct in its source systems and still be unsuitable for direct comparison if it relates to different levels of detail.

Definitions are also important.

What exactly does “job completed” mean?

When is downtime counted?

What does “available material” mean — physical presence in the warehouse, or the quantity that can be used for a specific job?

Without such agreements, even a technically correct integration can provide different answers to the same question.

Manual reporting costs more than employees’ time

The greatest cost of manual reporting is not always the time spent preparing a report. As the problem grows, reconciling data before making a decision — rather than preparing the report itself — becomes the greater cost.

The first consequence is delayed information. If a report on the previous shift is ready several hours later, the decision may be based on a state that is no longer current.

The second is the risk of error. The more exports, copying, custom formulas and manual corrections are involved, the more the result depends on how the report was prepared.

The third is the inability to reconstruct the result. After several weeks, it may be difficult to determine which source a value came from, who changed it and why.

The most serious consequence, however, is often a loss of trust in the data.

A manager maintains a separate spreadsheet because they do not trust the central report. Sales prepares another report. Production prepares yet another. More versions of the information emerge and later have to be reconciled again.

The mechanism begins to feed itself:

lack of trust -> separate reports -> more versions of the data -> even less trust

As a result, managers spend part of their time establishing the facts rather than making decisions.

How to reduce manual reporting without replacing the ERP system?

Improving reporting should not begin with selecting a tool. The first step is to determine what information is genuinely needed for decision-making and how it is currently produced.

Start with business decisions

Instead of beginning with the question “what data do we have in ERP?”, it is better to identify the most important operational questions:

• Will we meet the plan?
• Which jobs are at risk?
• Do we have the materials needed to complete the upcoming jobs?
• Where does the most downtime occur, and why?
• Why is on-time delivery declining?

Only then should the company determine which data is needed to answer these questions reliably.

Define metrics and their definitions

If a decision is based on metrics, it is necessary to define not only how they are calculated, but also what the input data means.

Two departments may use correct data and still report different results if they understand “completion”, “downtime”, “shortage” or “timeliness” differently.

Standardizing definitions is often just as important as integrating the systems themselves.

Identify data sources, owners and required freshness

For each important piece of information, it is worth answering three questions:

Where does it come from?

Who is responsible for its definition, quality and maintenance rules?

How current must it be for a decision to be made on its basis?

A data owner is a person or business role responsible for the definition of the data, its quality requirements and the rules for maintaining it. They do not have to be the administrator of the system in which the data is stored.

Freshness is equally important. A report may use the correct source and still be useless if its data is updated once a day while decisions must be made every hour.

If data is incorrect, the correction should be made in the source system or through a controlled correction mechanism, not only in the final spreadsheet. Otherwise, the same problem will return with the next export.

Map the full decision-and-data flow

The analysis should begin with the decision and work backwards to the required metrics and data. The next step is to trace how the data moves from its sources, through successive transformations, to the report, alert or recipient.

The following map can be useful:

decision -> metric and its definition -> required data -> sources and owners -> identifiers and level of detail -> required freshness -> processing rules -> report or alert -> recipient

Such an analysis reveals the points where data is re-entered, duplicated, corrected manually or processed according to rules known to only one person.

It also helps distinguish a system problem from a problem with the process, the data definition or responsibility for maintaining it.

Only then choose the integration and reporting method

Once it is clear which sources are correct, how current the data should be and which rules should govern its interpretation, a technical solution can be selected.

The choice depends, among other things, on the required data freshness, the number and type of sources, the integration capabilities of existing systems, the need to retain historical data, the scale of the data and the criticality of the process.

The scope of the solution may include a simple data exchange and automatic report generation, a shared data layer with a BI tool, or merely the removal of several manual steps without rebuilding the entire architecture.

The target flow can be reduced to a simple model:

source systems -> controlled data flow -> agreed data and rules -> reporting and alerts -> decisions

Excel can remain an analytical tool used by the recipient of the data. It should not, however, serve as an uncontrolled integration layer on which the company’s day-to-day operations depend.

Maturity does not mean that a company does not use Excel. It means that critical processes and decisions do not depend on manually assembling data in it.

Why will implementing a new ERP or BI tool alone not solve the data problem?

When the number of manual reports grows, the natural response is to try to replace them with a new tool. Technology can be part of the solution, but it does not remove the source of the problem on its own.

A new ERP system may be justified if the current system genuinely limits the company’s growth. It will not, however, automatically standardize data definitions or responsibility for updating the data.

A dashboard or another BI tool can significantly improve access to information. However, if it is connected to inconsistent sources, it will primarily display a more readable version of the existing discrepancies.

A data warehouse may be an appropriate part of the architecture, but collecting data without clearly defined business needs can easily lead to a large technology project with unclear value.

Banning the use of Excel, meanwhile, removes the tool employees often used to fill a genuine gap. If a better way to perform the same task is not provided, the gap will remain.

The goal should therefore not be to eliminate a particular program. The goal is to remove the dependence of critical processes on the manual and uncontrolled flow of information.

Where to start organizing data in a manufacturing company?

There is no need to begin with a complete inventory of all systems, reports and spreadsheets.

A better starting point is to select 3–5 important operational decisions. Priority should be given to areas where data or reports:

• are needed regularly,
• require a great deal of manual work,
• lead to disputes about data correctness,
• depend on the knowledge of specific people,
• arrive too late to support the decision,
• have a significant impact on production or order fulfilment.

For each of these decisions, it is worth first working backwards to the required data and its sources, then tracing how the information is processed and delivered to the recipient.

Such an analysis shows where the real problem lies: an unclear data definition, several sources showing different versions of the same information, the lack of an owner, insufficient data freshness, manual processing or a lack of integration.

Only then can a meaningful decision be made about what actually needs to change.

The first question should therefore not be: “Which system should we implement?”

It is far better to begin with different questions:

Which data do we use to make our most important decisions? Where does that data come from, who is responsible for it, and how is it processed? Is it current enough at the moment the decision is made?

The greatest benefits of AI in manufacturing usually come not from the projects that look most impressive in a presentation, but from those that reduce the cost or impact of a specific operational problem and use reliable data. It is important to distinguish between the time required to launch a solution, the time to the first measurable result, and the payback period.

A system that works with technical documentation can be launched relatively quickly, allowing its usefulness to be assessed early. A model that predicts rare but very costly failures may require considerably more preparation while still offering greater long-term financial potential.

This is why the question “where can we use AI?” is rarely a good starting point. A better question is: which operational problem is worth solving, and which technology is best suited to it?

In brief

Where does AI deliver a fast return?
Where the expected loss caused by the problem is high, the data is available and sufficiently reliable, and the achievable benefits can cover the full cost of the solution within an acceptable timeframe.

Does every problem require AI?
No. Integration, conventional automation, or mathematical optimization is often a better choice.

Does messy data rule out AI?
No. Unstructured or fragmented data is not the same as unreliable data.

When does AI automate chaos?
When it accelerates a poorly defined process or works with information that does not reflect how operations actually run.

Where does AI deliver the fastest return in a manufacturing company?

The application with the greatest financial potential is not always the best choice for a first pilot. The scale of the problem, the availability and reliability of data, the cost of launching the solution, and the time needed to achieve the first measurable result all matter.

It is worth distinguishing three concepts from the outset:

An application that can be tested quickly does not always deliver the highest return. Conversely, the project with the greatest potential does not have to be the best first implementation.

Technical knowledge and documentation

One application that can be verified relatively quickly is the use of generative artificial intelligence to work with existing technical knowledge.

In many companies, the problem is not a lack of information. Machine manuals, procedures, service documentation, tickets, and records of previous failures exist, but they are scattered across folders, systems, and formats. A technician has to know where to look, find the right document, and analyze its contents independently.

An AI system can significantly reduce the time needed to find and analyze information. Simply connecting a model to a folder of documents is not enough, however. The solution should take into account the current versions of documents and user permissions, identify the source of its answer, and be able to decline to answer or clearly state that the available information does not support a reliable conclusion.

Deviation analysis and exception prioritization

Processes in which an employee reviews numerous reports, records, alerts, or events every day solely to find the few cases that require action are also good candidates.

A system can detect deviations at an initial stage, group events, and direct attention to those with the greatest operational significance.

The value does not lie in producing yet another automatically generated report. The value lies in reducing the amount of information a person must review manually before noticing a problem that requires a decision.

A similar approach can be used in purchasing and materials management. The system does not have to place orders automatically – it can identify the components most at risk of shortage, delivery delay, or excess inventory.

Is predictive maintenance a good first AI project?

Not always. Predictive maintenance can have very high potential, but it usually requires a longer, more consistent, and better-described data history than simpler AI applications.

A model trained to predict a specific type of failure will usually need a sufficient history of events and information about the signals that preceded earlier problems.

Prediction accuracy alone is not enough. A forecast must arrive early enough for action to be possible. A model that accurately warns of a failure five minutes before a machine stops may provide no practical benefit if the maintenance team needs two hours to intervene. Too many false alarms will also quickly undermine trust in the system.

It is therefore worth considering simpler applications as well: access to knowledge, diagnostic support, analysis of fault history, or detection of unusual machine behavior.

Quality control – not just image recognition

AI also works well where quality can be assessed using repeatable data: images, measurement results, process parameters, or nonconformance history.

Computer vision can support product defect detection. Machine learning models can analyze relationships between process parameters and quality outcomes. Generative AI can help classify descriptions of nonconformances and find similar cases.

If experienced inspectors regularly assess the same cases differently, the acceptable criteria, escalation rules, and cost of both types of error must be established before automation: allowing an actual defect to pass and unnecessarily rejecting a correct product.

Production planning – AI does not replace optimization

Planning clearly shows why AI should not be treated as a single technology.

A machine learning model can predict a more realistic operation time. Generative AI can assemble source data and present the factors that influenced a risk assessment in a readable form. Such an explanation should be based on data or an analytical model, not solely on the narrative produced by a language model.

Algorithms and optimization engines, meanwhile, are used to build a schedule under multiple constraints.

Even a mathematically optimal result is only as good as the completeness of the process model. If a critical constraint is omitted – for example, the availability of a specific operator, tool, or material – the system may produce a plan that is mathematically correct but impossible to execute on the shop floor.

The best solution may therefore combine prediction, optimization, and decision support.

Should every operational problem be solved with AI?

No. If a problem can be solved reliably with a simpler mechanism, AI may only increase the cost, complexity, and number of components that will later require maintenance.

If data needs to be sent to the ERP system after an order is approved, an integration is needed. If an order above a defined threshold requires additional approval, a business rule is sufficient. If the task is to find the best combination among many alternatives under known constraints, mathematical optimization may be the right tool.

AI is particularly justified where unstructured information must be interpreted, patterns recognized, items classified, outcomes forecast, or situations handled that cannot reasonably be described by a complete set of rigid rules.

In complex processes, the last option is often the most useful.

A planning support system can retrieve data through conventional integrations, use a predictive model to estimate operation times, an optimization engine to build a schedule, generative AI to present the context and factors affecting the risk assessment, and business rules to control operations that require human approval.

The best solutions that use AI do not have to be systems built around AI. They should be systems that solve a specific business problem, with AI responsible only for the part of the task where it improves the outcome or reduces cost.

Does AI make sense if a company has messy data?

Yes – if the problem is the unstructured form or fragmentation of the data. Incorrect or outdated information, or events that the company does not record at all, are much greater obstacles.

“Messy data” can refer to at least three different situations:

There is no need to organize all of a company’s data before the first project.

If the goal is to reduce failure diagnosis time, the most relevant data concerns machines, tickets, previous repairs, and technical documentation. Sales or financial data does not need to be part of that project.

Can AI work with PDFs, spreadsheets, and emails?

Yes. The fact that information is stored in these formats does not rule out its use by AI.

What matters, however, is readability, structure, the ability to extract the content reliably, versioning, and context.

A poor-quality scan, a complex spreadsheet with macros, or a document without version information may require additional preparation.

The problem is not the PDF itself. The problem may be five PDFs describing the same procedure when no one knows which one is current.

What should be done with data fragmented across ERP, MES, and other sources?

First and foremost, it must be given a shared context.

The ERP system may contain order and due-date data, the MES may hold information about current production progress, the warehouse system may contain materials data, and an additional spreadsheet may record exceptions not handled by the other systems.

Each source may be correct. The problem arises when it is unclear how records should be linked, which source is authoritative for a given type of information, how statuses should be mapped between systems, and what the absence of a particular value means.

An AI model should not guess the meaning of statuses, identifiers, or relationships between data.

Can AI fix poor-quality data?

Only partially.

It can detect unusual values, classify data, identify inconsistencies, and help organize it. It cannot, however, reliably reconstruct an event that the company never recorded.

If a machine stopped but the downtime was not entered into the system, that information simply does not exist. If employees select a random failure cause solely to close a ticket, the failure history does not reflect the actual causes.

AI can help organize information. It cannot create a reliable picture of operations where the company itself does not record reality.

When does AI automate chaos instead of improving a process?

When it increases the speed of a process before the company establishes whether the process is correct, the data is unambiguous, and the result can be verified.

This is most often visible not in spectacular failures, but in manual workarounds to the official process: additional spreadsheets, decisions made by phone, statuses interpreted differently by different departments, or knowledge available to only a few people.

Operational reporting is a good example.

Suppose a model is expected to prepare a daily summary of production results based on the ERP system, a production report, and a management accounting spreadsheet.

If all sources use the same definitions and it is known which source is authoritative for each metric, the system can quickly identify deviations and provide their context.

If, however, each source defines efficiency differently, calculates it at a different stage of the process, or uses a different time interval, AI may produce a highly convincing summary based on data that contradicts itself.

A fluent and logical answer is not proof that the input information is correct.

How can you determine whether a process is a good candidate for AI?

A good use case combines a significant business problem, sufficient process and data readiness, and an acceptable risk of error.

How should the consequences of an error be assessed?

Before comparing the potential benefits of individual projects, a broader question must be answered:

what will happen if the system returns an incorrect result, fails to provide it on time, or is unavailable?

A solution that incorrectly classifies an internal document is assessed differently from a system whose recommendation may lead to a product being rejected, a machine being stopped, or the schedule of an entire line being changed.

Risk depends on the impact of an error, its probability, detectability, the time available to respond, and whether the decision can be reversed.

It is easier to reduce when mechanisms exist to identify situations requiring additional review, a decision can be passed to a person, an operation can be reversed, or the process can switch to a safe mode.

A fallback mode must also be defined: how the process works without the AI solution and who takes over the decision when the system is unavailable or cannot provide a result within the required time.

If an error can cause serious consequences that are difficult to reverse, the scope of automation should be correspondingly smaller.

Value and readiness matrix

After assessing risk, the use case should be considered across two dimensions.

The combination of high value and high readiness means the problem is significant, the right data is available, the process is understood, and the result can be measured.

High value with low readiness does not mean that AI makes no sense. If the cost of a machine failure is very high but the appropriate event history is missing, the first stage may be to improve the way those events are recorded.

Low value with high readiness is the category in which it is easy to implement AI simply because it is technically straightforward. The fact that something can be automated easily does not mean it is worth doing.

Low value with low readiness usually means there is no justification for investment.

Five business questions before starting an AI project

After assessing risk, it is worth answering five questions:

1. What exactly is the operational problem we are solving?
2. What cost does this problem generate, and which operational outcome does it affect?
3. Which decision or activity do we want to improve, how is it performed today, and who is responsible for it?
4. What data do we need, and can we trust it sufficiently?
5. How will we know unambiguously that the solution works better than the current way of working?

If the answers lead to the conclusion that an integration or conventional automation is sufficient, the analysis has done its job.

The purpose of qualifying a project is not to prove that AI is needed. It is to select a solution whose expected outcome justifies its cost, complexity, and risk.

Proof of Concept, business pilot, and operational deployment – how do they differ?

These three stages answer different questions and should not be treated as interchangeable.

A PoC can demonstrate that a model correctly classifies documents or answers questions using instructions. It does not yet prove that an employee will work faster as a result or that the solution will be cost-effective.

A pilot should use real or representative data, involve target users, and include the most important elements of the future process.

A pilot does not have to operate at a large scale. It can be limited to one line, product type, group of machines, or several users. However, elements that may determine the outcome should not be removed – for example, an integration if access to current data is the project’s main risk.

A baseline must be defined before the pilot

Without a reference point, it is impossible to know whether an improvement has occurred.

If the system is intended to support diagnostics, measurements may include the time spent searching for information, the time required to identify the cause, and the mean time to repair and restore equipment to operation.

If it is intended to detect deviations, the relevant measures are analysis time, the number of cases requiring action, and the time between the occurrence of a problem and its detection.

When comparing results before and during the pilot, parallel changes in volume, product mix, staffing, materials, or process organization must also be taken into account.

Positive user feedback is important, but on its own it does not demonstrate a return on investment.

Should a pilot assume full autonomy from the outset?

No. During the first pilot, an AI system should primarily recommend, prioritize, or classify rather than independently make decisions with major consequences.

This makes it possible to observe how often a user accepts a recommendation, in which situations it is rejected, and when the system lacks sufficient information.

Formal human approval alone is not an adequate safeguard. The user must have access to the sources, criteria, and information needed to assess the recommendation, as well as enough time to verify it properly.

Only observation of actual cooperation between a person and the system shows which decisions can safely be automated to a greater extent.

Quality must still be measured after launch

Operational deployment does not end the work on the system.

Processes, products, documentation, machine parameters, and user behavior change. A model that worked well during a pilot may require renewed validation after several months.

Monitoring should cover not only application availability, but also output quality and changes in key process parameters.

Example: what might an AI pilot in a manufacturing company look like?

Consider an illustrative company in which a planner analyzes several hundred deviations related to production orders every day. Most require no action, but some may lead to a delay, a material issue, or a conflict with another order.

This is an illustrative scenario, not a description of a specific implementation.

Problem: the planner spends a significant part of the day reviewing information manually to find the small group of events that require action.

Baseline: before the pilot begins, we measure analysis time, the number of cases reviewed each day, the number of cases that actually require intervention, and the time between the emergence of a significant problem and its detection.

Data: the ERP system provides information about orders and due dates, the MES or another system that records production execution provides current progress data, and the warehouse system provides information about the availability of key materials. First, it must be established whether identifiers and statuses allow this information to be combined reliably.

Pilot scope: instead of changing the schedule automatically, the system assesses risk and prioritizes events. The planner still makes the decision. The pilot covers one line or a selected group of orders.

Safeguards: an incorrect indication does not change the plan automatically. A false alarm means an additional review by the planner, while a failure to flag an order that is genuinely at risk is recorded and analyzed.

Comparison with a simpler alternative: the model’s result should also be compared with a simple rule-based mechanism. If a few transparent rules identify at-risk orders just as effectively, there is not enough justification for using AI.

Success criteria: before the pilot begins, the main metrics and the minimum values that would justify further development of the project must be defined. These might include:

• a defined reduction in manual analysis time,
• the maximum acceptable percentage of important problems missed by the system,
• the required reduction in response time,
• an appropriate percentage of warnings that enabled effective intervention, provided that a sufficient number of such events occurred during the pilot.

Diagnostic metrics: it is also worth monitoring:

• the number of false alarms,
• the percentage of recommendations rejected by the planner,
• the types of cases for which the system performs worst,
• the impact on on-time order completion, if the scope and duration of the pilot allow it to be assessed reliably.

Decision: if the system meets the predefined criteria, reduces manual analysis, and improves response time with an acceptable error rate, the scope can be expanded. If inconsistent statuses between systems turn out to be the greatest problem, the next investment may be to improve the data and integrations rather than to develop a more advanced model.

Such a pilot answers a business question. It does not merely test whether the model “can analyze data.”

How should the return on AI in a manufacturing company be measured?

Return on investment is assessed by converting a change in operational performance into monetary value and comparing it with the full cost of the solution over the same period. The number of users, model queries, or generated reports describes use of the tool, not its profitability.

It is worth distinguishing three basic measures.

Net benefit:

monetary value of benefits over the period analyzed – total cost of the solution over the same period

Simplified ROI:

(monetary value of benefits over the period analyzed – total cost of the solution over the same period) / total cost of the solution over the same period × 100%

Payback period:

the time after which cumulative benefits, less ongoing costs, cover the initial investment.

Not every project requires an elaborate financial model, but these concepts should not be treated as interchangeable.

If a benefit cannot be converted into monetary value reliably, it is better to present it as a separate operational outcome than to include it in an apparently precise ROI calculation.

The KPI should follow from the problem

For maintenance, relevant measures may include downtime, mean time to repair and restore equipment to operation, or the number of unplanned stops.

In quality control, relevant measures may include the scrap rate, inspection cost, or the percentage of products that pass the process correctly the first time.

In planning, these measures include on-time performance, lead time, and the number of urgent schedule changes.

A system that supports work with documentation may primarily reduce the time spent searching for information and diagnosing problems.

There is no need to force every project into the same KPI.

Time freed up does not always mean cost savings

If AI reduces the time needed to prepare a report from two hours to thirty minutes, it frees up one and a half hours of work.

This does not automatically mean a saving equivalent to one and a half hours of pay.

The benefit arises when the employee can handle greater scale, respond to problems faster, reduce overtime, or use the time for more important tasks.

It is therefore important to distinguish between time freed up and the benefit achieved through that time.

The benefit may come from avoiding a loss

For failures, quality problems, delays, or material shortages, the main benefit may be avoiding a costly event.

Such an outcome must be calculated carefully. A warning about a potential risk does not necessarily mean that the system prevented the entire possible loss.

The greater the benefit attributed to avoided events, the more important a reliable method of comparison with the previous way of working becomes.

The cost of AI is much more than the model

The total cost of ownership should include, among other things:

• process analysis,
• the time contributed by subject-matter experts and users involved in the project,
• data preparation,
• integrations,
• implementation,
• infrastructure,
• licenses or APIs,
• training and changes to ways of working,
• security, access control, and audit,
• monitoring,
• maintenance,
• revalidation,
• handling cases that require human intervention,
• changes following updates to source systems.

The model itself does not have to be the most expensive part of the project. In operational solutions, integrations, exception handling, and embedding the system in daily work often account for a large share of the cost.

Model accuracy is not yet a business KPI

A model with high overall accuracy may be highly useful or completely unacceptable.

Imagine a process in which only 1% of products have a defect. A system that classifies every product as correct would achieve 99% overall accuracy while failing to detect a single defect.

For rare events, the types of errors made are therefore far more important than overall accuracy alone: how many real problems the system misses and how many false alarms it generates.

The cost of each of these errors also matters.

An incorrectly labeled document may simply be sent for manual review. Allowing a critical product defect to pass may be unacceptable even when the model’s overall performance is very high.

Where should a manufacturing company start with AI implementation?

With the problem, not the technology.

First, identify several areas in which the company regularly loses time or money or faces significant risk. Then compare them in terms of potential benefit, process and data readiness, and the consequences of an error.

The next sequence is straightforward:

problem -> process -> data -> technology -> pilot -> measurement -> scaling decision

The outcome of the analysis does not have to be an AI project. The company may need an integration, simpler automation, an improvement in how events are recorded, or a change to the process itself.

That decision is better than implementing AI simply because it can technically be built.

Frequently asked questions about AI in manufacturing companies

Does AI in manufacturing require a large amount of data?

No. The amount of data required depends on the type of application.

Generative AI can work with existing documentation, procedures, and event descriptions without building a large training dataset from scratch. A predictive model created for a specific process may, however, require a sufficiently long and representative history.

The question should therefore not be “do we have a lot of data?” but “do we have the data needed to solve this specific problem?”

Is an MES required to implement AI in manufacturing?

No. An MES can be a highly valuable source of information, but it is not a prerequisite for every project.

Data can come from ERP systems, production execution systems, warehouse systems, quality systems, machines, documentation, or spreadsheets. What matters more is whether it describes the necessary part of the process with sufficient reliability.

Does a company need its own data science team?

No. For a first, limited project, a company can use the expertise of an external team.

It must, however, involve people who understand the process and the data well and can assess whether the system’s output is correct.

As the number and significance of AI solutions grow, the company will need greater internal capabilities in architecture, data, security, monitoring, and system management.

Does an AI solution have to run in the cloud?

No.

Cloud, on-premises, and hybrid architectures are all possible. The choice depends on the type of solution, source systems, required performance, cost, security, and data-processing rules.

The technology should follow from the project’s requirements, not the other way around.

Can AI use confidential company documentation?

Yes, but the architecture must be designed deliberately.

It is necessary to establish where data is processed, what information leaves the company’s infrastructure, who can access it, how long it is stored, under what rules it can be deleted, and whether it may be used to train or improve models.

Access-control, activity-logging, and audit mechanisms may also be needed.

The confidentiality of documentation does not rule out the use of AI. It does, however, affect how the solution should be built.