A case where the right AI decision was not to deploy AI

Green Idea is a Czech manufacturer of cosmetics, dietary supplements and veterinary products with 50 to 249 employees. Revenue was growing, yet the profitability of parts of the business had become difficult to understand. Management could not confidently explain where margin was being lost or why.

A case published by the European Digital Innovation Hubs Network identifies an unexpected cause. For ten years, Green Idea had invested in a proprietary internal system connected to the Helios ERP. The interface appeared functional, but the layer was obscuring critical data. The company could not properly plan production cycles, reserve raw materials, calculate costs or compare margins.

Instead of adding a new AI analytics tool, Green Idea returned to the core ERP and retired the proprietary layer. That restored access to accurate data, cost and margin calculations, production planning and KPIs. In parallel, the company distributed responsibility among professional managers and reduced dependence on both the founder and a single IT specialist.

It is a valuable anti-hype case: AI was within the transformation program's scope, but the first useful outcome was not a model. It was the removal of a digital dead end.

Why the production problem was harder than it looked

Green Idea makes multiple products and packaging variants. Changing the format parts on a production line takes several hours. If that change happened several times a day, output would approach zero. Orders therefore need to be grouped into production cycles, while raw materials must be reserved in advance.

That decision requires connected data:

  • confirmed demand and order deadlines;
  • formulations and consumption standards;
  • stock, batches and expiry dates;
  • line and workforce availability;
  • changeover duration between formats;
  • production cost and quality constraints.

If some of this information is trapped in a separate application, stale or inconsistent with ERP master data, even a strong model will produce a convincing answer on a weak foundation. The central problem is not model hallucination. It is the absence of a single observable version of the business process.

What is confirmed—and what the source does not quantify

The EDIH publication confirms the functional and organizational changes: the proprietary system was abandoned, Helios ERP became the core again, and the company gained cost and margin calculation, cycle planning and KPIs. It also reports that the organization became more stable and that generational succession moved onto a manageable path.

The source does not publish:

  • the amount previously invested in the custom software;
  • migration cost;
  • profit changes after the transition;
  • reductions in inventory or changeovers;
  • payback period;
  • a technical integration design.

It would therefore be wrong to attach a specific savings percentage to the ERP return. The reusable lesson comes from the order of decisions: restore data visibility and control first, then make analytics and automation possible.

Why “add RAG” does not repair an opaque system

RAG is effective at finding meaning in documents such as procedures, production cards, instructions and specifications. It does not replace transactional records for stock, orders, batches and actual output. Loading exports from an opaque system into a knowledge base merely creates a convenient search interface over the same contradictions.

An AI agent cannot create a missing management model either. ERP access lets it read or write fields, but does not explain which field is authoritative, when an order becomes confirmed, or who may change the production plan.

Before RAG or agents, the organization needs ordinary agreements:

  • an owner for every critical master-data set;
  • units of measure and rounding rules;
  • order and batch states;
  • refresh timing and acceptable delay;
  • error-correction rules;
  • a change log and an owner for exceptions.

This is not preparatory bureaucracy. It is the specification for the future AI product.

A suitable architecture after the cleanup

Returning to ERP does not mean all analytics must be built inside it. A safe pilot can keep ERP as the system of record and add a small controlled layer next to it.

**1. Export or read-only API.** Orders, stock, batches, formulations and actual operations flow into a read-only store. The AI receives no direct permission to alter production records.

**2. Canonical views.** The pilot exposes a few tables or views with clear business terms: available stock, confirmed demand, series duration and changeover cost. Finance and production jointly verify and document each calculation.

**3. Quality controls.** Missing values, duplicates, negative stock, inconsistent units and late events are checked before use. A problem enters a correction queue instead of being silently replaced by an average.

**4. Narrow local service.** A local model may explain deviations, draft a report or answer questions against approved views. RAG contributes procedures and production documents, while numeric values always come from structured records.

**5. Human approval.** Initially, the system proposes a production batch, review priority or question about the data. A production manager approves any ERP change through the existing process.

This preserves role separation: ERP records the transaction, deterministic rules calculate constraints, the model helps interpret the situation, and a person makes the decision.

Where a local model is genuinely useful

Once data is under control, local AI can help where commercial confidentiality, repeatability and integration with internal documents matter:

  • explaining why actual margin differs from plan;
  • finding related production instructions;
  • drafting a daily operating summary;
  • routing exceptions to process owners;
  • translating a manager's natural-language question into a safe query over approved views;
  • comparing production-series options while explaining constraints.

The model should not calculate product cost from prose or invent stock figures. Deterministic rules perform numeric calculations; the model receives calculated metrics with references to the supporting records.

Local deployment can reduce exposure of formulations and financial data to an external provider. It still requires access control, logging, backup, monitoring and controlled model updates.

How to tell whether custom software has become a dead end

Custom software is not inherently a problem. It can be a competitive advantage when it supports a unique process. The warning signs are different:

  • a report cannot be reproduced without one specialist;
  • the same concept is calculated differently on different screens;
  • data cannot be exported in a documented format;
  • master data is duplicated and synchronized manually;
  • an ERP update breaks the integration unpredictably;
  • change cost rises while time to answer business questions does not fall;
  • the system hides the origin of a metric.

“Rewrite everything” can be as risky as maintaining the old layer forever. Start with a map of critical decisions and data sources, then compare three options: retain and document, reduce to a thin integration layer, or retire.

Economics: count future costs, not sunk investment

Ten years of investment creates a strong sunk-cost effect. Past spending does not prove the value of another year of maintenance. The decision should compare future cash flows.

Over a 24-to-36-month horizon, include:

  • maintenance and development of the existing solution;
  • departure risk for the key specialist;
  • planning errors and manual reconciliation;
  • migration and training;
  • configuration cost for the standard ERP;
  • value of faster management decisions;
  • future data and AI-pilot expenses.

Measure the time from a management question to a verified answer separately. If software technically works but the finance director needs several days and manual spreadsheets to explain margin, its real cost is higher than the server invoice.

A practical four-week pilot

**Week 1.** Select one decision, such as assembling a production series. Record the owner, inputs, source of truth and cost of error.

**Week 2.** Build a read-only ERP view. Test completeness, duplicates, units and change history against closed operating periods.

**Week 3.** Create a report without AI: constraints, options and supporting records. If users do not trust it, a model is premature.

**Week 4.** Add a local model only to explain the result and retrieve procedures. Compare preparation time, correction count and the share of cases in which the manager can verify the evidence.

A successful pilot is not an attractive chat interface. It is a shorter path to a verifiable decision without loss of control.

The central lesson from Green Idea

Green Idea refused to become captive to a decade of sunk investment. It recognized that a seemingly functional layer obstructed visibility into production, returned to the system of record and redesigned governance at the same time. The published case does not prove a financial effect as a percentage, but it offers an unusually honest sequence: data, process and accountability before AI.

For small and medium-sized businesses, that sequence can save the most expensive resource: months spent asking a model to compensate for unmanaged data. Sometimes the best first step toward local AI is to remove the system standing between management and the facts.