Executive summary

This case study presents an operational improvement project at a frozen-food wholesaler. According to the historical source, the company operated 8–12 refrigerated vehicles daily in summer, falling to 2–3 in winter. Seasonal variation alone presented substantial capacity and cost-planning challenges, but the business also faced more serious operational risks.

Inventory management relied on an outdated PDA solution without real-time synchronisation. Recorded and physical stock could therefore diverge regularly. The source reports theft reaching 10–15% of product inventory under weak controls. Administrative support for HACCP and traceability requirements was also insufficiently stable.

The solution was therefore more than replacing a warehouse application. It reshaped the operating model: real-time stock and delivery information, documented goods movements, minimum–maximum stock rules, dynamic sales responses to approaching expiry, digital returns and picking, partner stock tracking and an internal administrator role connecting daily operations with the system.

Project profile

SectorFrozen-food wholesale and refrigerated logistics
Initial seasonal workload8–12 refrigerated vehicles daily in summer; 2–3 in winter
Main risksStock discrepancies, internal misuse, traceability gaps, administrative overload and seasonal underutilisation
InterventionIntegrated stock, delivery, returns, online shop and control processes built on Pandora ERP
Documented outcomeThe previous 10–15% stock loss ceased; seasonal operations became more balanced; the system was still in use when the historical source was prepared.
Today's Kyntrax interpretationActual operations → target state → controlled execution: Mirror → Compass → Tunnel

1. Mirror — uncovering actual operations

1.1. Symptoms are not root causes

Several connected symptoms formed the starting point. Inventory records were inaccurate, some goods movements were not adequately traceable, management lacked a consistently reliable stock and delivery picture, and compliance administration involved excessive manual effort. Each could have been treated as a separate technical fix. The real risk was that they appeared at different points in the same operational system.

A discrepancy between warehouse records and physical stock may arise from synchronisation faults, incorrect entry, undocumented movement, responsibility gaps, misuse or a combination. Replacing the screen or input device while leaving event controls unchanged can preserve the problem in digital form.

1.2. The critical information gap

The outdated PDA system lacked real-time synchronisation. Operationally, this allowed several time-separated “truths” about the same stock: physical reality, warehouse records, goods on vehicles, delivery status and management-visible system data did not necessarily agree.

1.3. Uncontrolled goods movement as an organisational risk

The source describes recurring theft under weak internal controls, potentially reaching 10–15% of product inventory. From an operational diagnostic perspective, this was more than a theft issue: the evidence chain between goods movements and responsibility points was insufficient.

If it cannot be reconstructed reliably when a product moved, under which documented event, to whom, onto which vehicle, in what quantity and what happened afterwards, management struggles both to detect misuse and to distinguish innocent operational errors from deliberate discrepancies.

1.4. Compliance and administrative overload

HACCP and traceability requirements were not consistently supported, partly because of technological gaps and partly administrative overload. This illustrates how compliance issues may stem from the same weak information flow and event recording that cause stock inaccuracies and management uncertainty, rather than requiring an entirely separate compliance project.

2. The causal map of the problem

The historical source is not a comprehensive forensic root-cause analysis. The following map therefore separates documented facts from Kyntrax's interpretation. It illustrates the connections a modern operational diagnosis would examine, without manufacturing retrospective certainty.

Observed phenomenonFact recorded in the sourceKyntrax professional interpretation
Stock discrepancyThe PDA system did not synchronise in real time; records could differ from physical stock.Data freshness and event-recording gaps meant the decision picture did not coincide with physical reality.
10–15% stock lossThe source reports recurring theft that could reach this level.Prevention requires transaction-level evidence and a responsibility chain, as well as inspection.
HACCP/traceability riskTraceability supporting compliance was not reliably assured.Compliance relies on the same authoritative event data as stock and logistics management.
Seasonal fluctuation8–12 refrigerated vehicles daily in summer; 2–3 in winter.A substantial share of fixed capacity was seasonally idle; a separate business model was needed to use it.
Administrative overloadThe source partly attributes compliance risk to administrative overload.Automation's value here is automatic evidence creation from operational events, rather than fewer clicks alone.

2.1. Why would buying new software have been insufficient?

The problem crossed several organisational and information layers. Conventional procurement might have listed stock, transport, online shop and reporting modules. That feature list alone would not define which business events needed evidence, where responsibility boundaries required controls or when the system should respond automatically.

The project's strength was connecting technology functions to operational problems. GPS event logging made goods movements demonstrable. Minimum–maximum logic formalised decisions between excess stock and shortages. Expiry-related discounts were a loss-prevention response, not merely an online shop feature.

3. Compass — defining the target state

The source records five management objectives: real-time stock and delivery data; automatic product identification and dynamic discounts linked to expiry; eliminating theft and manipulation; auditable HACCP and traceability operations; and a logistics model more responsive to seasonal fluctuations.

3.1. Turn objectives into measurable operational statements

“Real-time stock” is not precise enough. An executable target state defines which events change stock, when data becomes valid, and how goods in transit, returns, partner stock, reserved quantities and saleable quantities are handled. Delivery also has distinct states: has the vehicle departed, have the goods been handed over, or has the customer accepted them?

3.2. Target state: event-based, traceable operations

3.3. Seasonal capacity as a business problem

The response to the winter downturn is particularly instructive: some spare vehicle and labour capacity was hired out. This was a business-model intervention, not an ERP feature. The system made capacity, workload and operational status clearer, enabling management to use available resources for other revenue-generating purposes.

4. Tunnel — implementing the operating model

4.1. Transaction-level delivery control

With Pandora ERP, drivers could see their consignments on smart devices, while the system logged transactions using GPS. The source describes undocumented goods movements as becoming impossible. More broadly, goods movements became digital events linked to time, location, task and responsibility.

Such controls address three problems together: reducing opportunities for deliberate manipulation, distinguishing genuine operational mistakes from intentional discrepancies, and creating data that can support disputes, stock complaints or compliance checks.

4.2. Minimum–maximum stock logic

Inventory management used minimum–maximum automation. The source describes lower and upper stock targets for each product, adjusted dynamically using actual consumption and seasonal trends. Falling below the minimum could generate or suggest replenishment; approaching the maximum alerted the stock owner.

This differs substantially from record keeping alone. The system supports “do we need to act?” using business rules, as well as “how much do we have?”. Transaction data becomes decision-support input.

4.3. An automatic business response to approaching expiry

The system immediately flagged products nearing expiry and, according to the source, automatically discounted them in the integrated online shop. The key is information speed: a risk originating in the warehouse reached the sales channel directly and triggered a business response.

4.4. Returns, picking and delivery in one process

Returns, picking and delivery were digitalised and made transparent. Stock accuracy rarely fails at only one warehouse operation: picking, loading, delivery, failed handover, returned goods, scrap and corrections can all change stock. Reliability requires these events to share one operational logic.

5. Beyond company boundaries: partner stock and automatic replenishment

The source states that the system also tracked retail partners' stock levels and supported automatic order initiation. Operations thus extended beyond optimising the company's own warehouse: the information connection with partners became a means of preventing stockouts.

5.1. Why is this more than integration?

Technically, this can be called partner-stock integration. Business questions are more important: which stock data is authoritative, how often is it updated, what triggers an order, is physical partner stock the same as saleable stock, how are reservations handled, and what happens when data is incomplete or late?

These questions are even more critical for AI-based business systems. An automated recommendation or agent can operate reliably only when a claim such as “this partner needs replenishment” rests on authoritative, well-defined data.

5.2. The Pandora admin as an operational role

According to the source, an important implementation factor was the “Pandora admin”: a designated internal specialist supporting daily system operation and users while reducing pressure on the development team.

Many digitalisation projects treat deployment as a technical handover. Real operations continuously generate exceptions, misunderstandings, new employees, data-quality issues and small configuration needs. Without an owner for these matters, users build workarounds and the system gradually diverges from actual operations.

5.3. Change management as a control

The source reports that new drivers joined with working expectations supported and enforced by the transparent, digitally traceable system. Technology and organisational norms reinforced one another: the system made the desired behaviour part of the role itself, rather than merely recording it.

6. Documented results and strength of evidence

The historical source records several clear outcomes, but does not provide a detailed measurement method or financial calculation for each. This study distinguishes numerical claims, qualitative outcomes and professional inferences that cannot be quantified without further data.

OutcomeWhat does the source record?Interpretation / limitation
Stock lossEarlier theft could reach 10–15%; the source reports that it ceased entirely after implementation.A strong historical claim, but the documentation provides no separate audit sample or time series.
Inventory accuracyMore immediate, automated inventory management and event tracking were established.The source gives no percentage accuracy KPI.
Expiry lossesProducts approaching expiry were automatically discounted in the online shop.The mechanism is documented; the financial value of stock saved is not quantified.
Seasonal utilisationWinter capacity was used by hiring out vehicles and labour, making operations more balanced.Additional revenue is not quantified.
EmploymentUsing spare capacity helped retain employees.A qualitative outcome; no headcount or turnover time series is provided.
System longevityAt the time the source was prepared, the company continued using the system and adding modules.This indicates longer-term usability;

6.1. What we do not claim

7. What does this project teach us about SME digitalisation today?

7.1. Inventory problems are often information flow problems

If physical stock, system stock, goods on vehicles and partner stock do not share an event chain, more disciplined data entry alone rarely resolves accuracy. Processes should make the business event itself create or update the required data.

7.2. Control is not bureaucracy

Well-designed controls need not add administration. Normal transaction execution can create the evidence. Poor controls require separate forms and retrospective checks; good controls are embedded in the workflow.

7.3. Systems need to respond as well as record

Minimum–maximum levels and expiry discounts illustrate the same principle: data creates value when connected to a known decision rule. The system need not always decide automatically, but should at least prepare the appropriate response at the right time.

7.4. Seasonal problems do not always call for cost cutting

Hiring out winter capacity shows that operational improvement can create revenue opportunities as well as reduce losses. Clearer visibility of resources and workload makes this possible.

7.5. Real operations begin after implementation

The Pandora admin demonstrates that long-term value depends on more than development quality. An organisational mechanism must keep processes and the system aligned: interpreting exceptions, handling user questions, feeding discrepancies back into processes and managing change. The author reports that the person holding the Pandora admin role changed three times during the 12-year period examined.

8. What would this mean today with enterprise AI?

The original solution was not an AI project. It nevertheless shows why operational reality needs to be organised before AI is introduced. AI recommendations depend on information made available with the right meaning, freshness and permissions.

8.1. AI stock recommendations without real-time stock

If system stock regularly differs from physical stock, AI may generate replenishment suggestions faster without making them more correct. Incorrect inputs can produce faster decisions rather than better ones.

8.2. AI and business meaning

“In stock” may mean physically present, unreserved, saleable, deliverable or available to promise for a specific date. These distinctions are critical in operations like Nelan Food's. AI can answer safely only when business concepts and sources are clear.

8.3. AI and authorisation boundaries

Recognising expiry risk is different from having authority to change prices or initiate orders automatically. Modern Kyntrax thinking separates recognition, recommendation, decision preparation and execution.

8.4. The project's legacy for AI readiness

9. Frequently asked questions

What was the main problem in the Nelan Food project?

It was not a single technical fault. Stock inaccuracies, insufficiently controlled goods movements, substantial internal losses, compliance workload and seasonal capacity swings formed a connected operational problem.

Why is this more than an ERP implementation case study?

Technology elements were grounded in specific operational causes and decision points. The objective was more transparent, controllable operations, rather than ERP use itself.

What did real-time inventory mean in practice?

Stock changes were intended to appear more reliably and closer to actual movement events, allowing management, warehousing, delivery and sales to share the same operational picture.

How were opportunities for misuse reduced?

The source links deliveries and transactions to smart devices and GPS-based logging, reporting that undocumented goods movements were eliminated.

What was the role of minimum–maximum stock logic?

It supported replenishment or warning responses based on lower and upper stock levels, accounting for consumption and seasonal patterns as well as recording stock.

Why does the Pandora admin role matter?

It established internal ownership of the connection between daily operations and the system, reducing developer dependence and sustaining operational discipline.

What is the most important lesson for Kyntrax today?

Establish operational reality and a demonstrable event chain first. Build ERP, automation or AI on that foundation.

Can the same approach apply to other trading SMEs?

The principles can, but the solution should not be copied mechanically. Stock definitions, delivery models, responsibilities, seasonal patterns and compliance requirements differ between businesses.

10. Sources, evidence and publication context

Historical project description: Nelan Food — Frozen Food Wholesale Operations (English). This English page adapts Joseph Bakus's detailed 2026 Hungarian analysis.

10.1. Kyntrax professional interpretation

The causal maps, modern AI-readiness conclusions, evaluation of evidence strength and lessons expressed through today's Mirror–Compass–Tunnel framework are professional interpretations. They analyse the documented project rather than reproduce the historical source verbatim.

10.2. Historical product names

Pandora ERP is the historical system name used in this project. Today's Kyntrax is not automatically identical to that implementation. This study presents its operational and methodological heritage without claiming technical identity between the earlier product and current Kyntrax.

10.3. Author and methodological background

Joseph Bakus
Founder & System Architect, Kyntrax
Creator of the Kyntrax operational methodology and system architecture.

Related Kyntrax topics

© 2026 CLOUD DEVELOPMENT AND SERVICES LTD · Kyntrax. All rights reserved. Detailed terms of use and intellectual property are available on the Kyntrax website.

Terms of use and intellectual property →