Custom software for industry – when an off-the-shelf MES/ERP system stops being a sensible choice

An off-the-shelf manufacturing execution system or ERP can be a sensible choice, but only if the actual production flow can be represented without material simplifications. Otherwise, the system tidies up record-keeping at the expense of process control. That is the point at which the feature list stops mattering. The real question is whether the plant will continue to manage its own production, quality, and maintenance, or begin adapting its work to the tool’s limitations. If critical decisions, exceptions, and interlocks operate mainly outside the system, dedicated industrial software is not a luxury. It becomes a way to restore data consistency, accountability, and operational control.

Not every production process can be honestly fitted into an off-the-shelf system

An off-the-shelf manufacturing execution system or ERP works well where the process is genuinely repeatable, responsibilities are clearly defined, and the data model does not distort the reality of the plant. Under those conditions, standardisation brings order to information flow, reduces local interpretation, and supports decisions based on a consistent event record. The problem arises earlier than missing features. It starts where the actual flow of production, quality, maintenance, and planning no longer fits the system logic without losses to the process.

That is the boundary between sensible standardisation and loss of operational control. If the organisation starts bending its own process just to make the data “fit the system,” the information architecture stops serving production. It starts distorting it. Some rules can safely be standardised through configuration or procedure, but there are also technological dependencies, control points, and lines of responsibility that cannot be blurred without harming product quality, process safety, or decision traceability. That is why the “off-the-shelf or custom” debate is usually framed the wrong way. A better question is: which parts of the process are a shared standard, and which define the plant’s competitive edge, source of risk, or area of compliance obligations and therefore must be represented faithfully.

In practice, the most expensive issue is not missing modules, but the workarounds that quietly become the daily way of working. Spreadsheets maintained alongside the system, manual re-entry of data between the shop floor and the office, operator notes, informal handling of exceptions, and parallel information flows are not minor inconveniences. They are a sign that the process control model is breaking down. At that point, it is worth measuring not the number of features, but the number of manual data handoff points between production, quality, maintenance, and planning, the number of critical exceptions handled outside the system, and the share of operational decisions made on the basis of data not taken directly from the source record. If these indicators are rising, the problem usually does not stem from poor configuration, but from the false assumption that the process can be bent to the tool at no cost.

This is especially clear in plants where the progress of an order depends not only on the process routing, but also on the actual condition of the machine, in-process inspection results, material approvals, input batch, setup parameters, and decisions made under time pressure by several functions at once. If an off-the-shelf system cannot maintain these dependencies within one reliable data chain, the truth about the process fragments across several locations. Part remains in the system, part at the machine, part in quality documents, and part in people’s knowledge. That makes production process mapping more difficult, complicates the responsibilities of implementation contractors, and increases project risk during integration with automation and systems that affect machine safety. Custom software makes sense not when a plant simply wants “something of its own,” but when it needs to preserve the unity of the process, source data, and decisions wherever simplification would mean a real loss of control.

From a compliance and operational oversight perspective, this distinction is fundamental. If key rules and control points exist only in team practice and are not enforced, or at least clearly represented, in the system, accountability becomes conditional. In some industries this will primarily be a matter of quality and batch history reconstruction; in others it will also involve sector-specific requirements, traceability, change management, or the boundaries of responsibility between the plant operator, the integrator, and the software supplier. That is why the decision to subordinate the process to the system, or the system to the process, should be preceded not by a feature presentation, but by an honest analysis of exceptions. Only then does it become clear which of them reflect organisational chaos and which reflect real technological, information, and safety requirements.

Cost rises where the system cannot see the real risk

The cost of a poorly matched system is highest not in simple work-order flows or daily reports, but at the interface between production, quality, maintenance, and process safety. That is where a decision must be made quickly, documented, and based on the full context: the current machine status, batch parameters, intervention history, quality release status, and active interlocks. If an off-the-shelf manufacturing execution system or ERP sees only part of that picture, the cost goes far beyond user inconvenience. Operational variability appears. Different shifts make similar decisions based on different data, exceptions are handled at discretion, and responsibility becomes blurred between the system, the procedure, and shop-floor practice.

The key problem begins when the system does not reflect the real sequence of actions, interlock conditions, versioning of process parameters, or responsibility for approving a deviation. On record, everything may look correct, while execution followed a different path. A gap emerges between the event and its digital trace. That forces very specific design decisions: whether critical process interlocks should operate in the system or only procedurally; whether machine data is operational evidence or supporting material; and whether exceptions should be handled through a designed decision workflow or left to discretion. If the plant relies on manual notes, extra spreadsheets, or interfaces that require constant human intervention, data credibility should be judged not by whether a final report can be generated, but by whether the course of a single nonconformity, complaint, or line stoppage can be reconstructed without dispute.

A particular risk becomes visible in plants with extensive machinery, where the system must work with automation, operator stations, and test and measurement equipment. If device integration is partial, process data collection is inconsistent, and change history is scattered across the controller, panel, production database, and service notes, batch traceability and product genealogy become conditional. The same applies to managing process changes. A change to a recipe, tolerance threshold, or changeover logic may be formally approved, but without consistent versioning and archiving it is impossible to prove later which configuration was actually in force at the time of the event. This is not a matter of system architecture aesthetics, but of reproducibility, root cause determination, and the boundaries of responsibility between production, maintenance, quality, and integration suppliers. In such cases, integration with automation and systems that affect machine safety becomes part of the core risk picture.

The cost of such a mismatch is rarely visible in the implementation budget. It appears later as diagnostic downtime, more manual work, complaints, disputes over the cause of an event, and the loss of the ability to reconstruct the process unambiguously. That is why, when evaluating a solution, it is not enough to ask whether the system “supports production.” You need to check how many interfaces require manual correction, how many critical parameters are not automatically versioned or archived consistently, and how long it takes to reconstruct a single operational incident. If the answer is: a long time, inconsistently, and using several independent sources, then the issue is not user convenience but risk controllability. This is exactly where a custom solution, or at least a dedicated layer on top of an off-the-shelf system, may be justified: not to report the past better, but to support safe operational decisions when the plant is operating under time pressure and accountability.

From a compliance perspective, this means one more thing. Wherever software affects the course of decisions that matter for quality, traceability, or process safety, the scope of critical functions should result from a real risk analysis, not from a catalogue of standard modules. This applies in particular to machine integration, handling exception states, and points where the system is meant to enforce a specific sequence of actions or block progression to the next stage. In such areas, it is worth separating record-keeping functions from those that become part of operational control and require stronger design justification, also in the context of machine safety and the integrator’s responsibility.

Design the decision first, then the code

A sound decision on system development in a plant does not start with a feature list, but with a map of the operational decisions the software is meant to support or enforce. You need to establish who makes the decision, based on what data, within what time, and with what effect on production, quality, traceability, or process safety. Only then does it become clear whether an off-the-shelf manufacturing execution system or ERP addresses the core of the problem or merely tidies up records after the fact. If what matters is not the registration of the event itself, but blocking the start of the next operation, the condition for batch release, confirmation that machine settings are compliant, or the handling of a deviation, then the question is not “does the system have it,” but “can it enforce the right decision at the right moment.”

This way of thinking also brings order to architecture design. In practice, a hybrid setup usually works best. A standard ERP or manufacturing execution system should remain where the process is shared, repeatable, and well described by a mature data model: planning, production accounting, warehouse management, and basic records for orders and batches. A dedicated layer makes sense when it takes over logic that is critical to a specific plant: machine integration, validation of events from multiple sources, exception handling, approval workflows, audit trail, and linking decisions to a specific batch, machine, and responsible person. The condition for success, however, is to define the boundaries of responsibility in advance. The team must decide what belongs to the technological process and stays on the automation or control side, what falls within the ERP or manufacturing execution system domain, what is handled by the integration layer, and what must still remain within organisational procedures.

Without that split, costly improvisation follows. The same condition may be recorded in several places, exceptions are resolved manually, and after a few months no one can clearly identify which system is responsible for the decision that blocks or releases the process. A good dedicated project is therefore not about replicating an off-the-shelf solution on a smaller scale. Its purpose is to close a specific decision gap. That is why, already at the design stage, it is worth listing the critical decisions that currently have no system support or enforcement, and then comparing them with the number of process exceptions the solution must handle from day one. That matters more than an extensive screen specification.

A practical example is straightforward. An off-the-shelf system may correctly account for production, material consumption, and warehouse receipts, yet still fail to cover specific quality holds related to conditional batch release. A batch may be formally produced and posted, but it still should not move to the next stage without confirmation of specific test results, the line changeover status, or closure of a deviation from the previous operation. If such a condition is currently managed by phone, spreadsheet, or a signature on a printout, this is not a matter of process aesthetics but a gap in responsibility control. In that situation, rebuilding the entire ERP or manufacturing execution system is usually unjustified. A dedicated layer is enough: one that collects data from machines and source systems, checks event completeness, launches the correct approval workflow, and passes an unambiguous batch status to the higher-level system. The standard remains standard, while critical logic is recorded where it can actually be managed and maintained.

If the plant does not yet have cost data, there is no need to guess. It is enough to start measuring how much time each month is consumed by manual workarounds, additional reconciliations, batch corrections, and verification of discrepancies between the system and the actual process state. This makes it possible to distinguish a justified dedicated layer from a project written “just in case.” It also helps assign the right roles on the business side. The scope of logic embedded in the system should not be decided solely by the IT department or by the integrator alone, but jointly by production, quality, maintenance, those responsible for digitalisation, and, where relevant, cooperation between the integrator, software house, and maintenance department, as well as machine safety and operational compliance.

From the standpoint of project accountability, this has one more consequence. The closer software gets to process transition conditions, operation interlocks, the correctness of action sequences, or data coming directly from the machine, the less it can be treated as a neutral IT add-on. In that scope, explicit design assumptions are needed, along with a description of operating and maintenance boundaries, change management rules, and a verifiable record of who approved the critical logic and on what basis. That is why, before writing the first line of code, it is worth approving not only the functional requirements but above all the decision design: what the system must enforce, what it must not allow, and at what point a person remains the final instance of responsibility.

Compliance is the result of good design, not decoration added after implementation

In an industrial plant, software is not a neutral add-on to the process but part of how the process is carried out. It can determine the sequence of tasks, block progression to the next stage, enforce data completeness, direct the approval workflow, and decide whether the course of decisions and responsibility can be reconstructed after an event. For that reason, compliance does not begin with adding formal requirements at the end of implementation. It begins with design, where it is consciously defined which decisions the system makes on its own, which it only supports, which data it treats as binding, and who owns the rules, exceptions, and changes.

If this structure is not established at the solution architecture stage, any later reference to quality requirements, process safety, or documentation obligations becomes little more than a formality. This matters especially when the system affects decisions that are critical to product quality, process safety, or interaction with machines and equipment. In that context, compliance requirements must be understood operationally: as the need for consistent operation, accountability, change control, and a solution that is appropriate to its actual use. It is not enough for a function simply to be available; it must also be possible to demonstrate why it works in that specific way, who approved its logic, and how the effects of its modification are assessed.

Most problems usually come to light not at startup, but after several months of operation. The plant adds a new production variant, changes acceptance criteria, connects another workstation, or shifts part of the responsibility from the operator to the system. If it was not defined earlier which classes of decisions and records must leave an audit trail, a dispute quickly arises over whose change affected quality, caused downtime, or triggered an incorrect system response. Only then does the difference become clear between a solution that works and one that can be managed. In the latter, it is known in advance which elements of the logic require a formal approval path, who governs the reference data, who maintains integration with automation systems, and whether the project documentation is sufficient for audit, maintenance, and the safe handover of the system to another contractor.

• which decisions the system makes or helps shape in the areas of quality, safety, and interaction with the machine,
• which events, changes, and approvals must leave a traceable record,
• who owns the business rules, data, and exceptions, and who approves changes to them.

Only after this has been put in order does it make sense to assess the project against the legal and normative requirements applicable to the specific plant, product, industry, and method of integration with machines or equipment. In the Polish and EU context, the question is not simply whether the solution works, but whether the organisation can demonstrate why it works in this way, on what basis the rules were approved, and how change is managed without weakening accountability. The scope of this analysis always depends on the application: a reporting system is assessed differently from logic that affects the course of the process, and differently again from an integration that interfaces with machine operation, risk assessment, or the scope of the integrator’s responsibility.

The conclusion is straightforward. Dedicated software makes sense when it clarifies responsibility and reduces risk exactly where an off-the-shelf manufacturing execution system or ERP would require costly compromises in process logic, change control, or action traceability. So the point is not to build everything from scratch, but to separate the standard layer from the critical logic in such a way that the system supports the plant’s real process instead of simplifying it at the expense of quality, safety, and accountability.