Oct 12, 2026

Buying an ERP Is Not Institutionalisation

SAP, Nebim or another ERP can strengthen a company's data and process infrastructure. But on its own it cannot fix unclear authority, undefined processes and weak decision discipline.

Strategy

Family Businesses

ERP & Transformation

Problem

You cannot institutionalise by buying an ERP. If you design institutionalisation, an ERP can help it scale.

A company decides on a major ERP investment. In the vendor presentation, production planning, stock, orders, finance, reporting and integration all appear on a single screen. The founder relaxes: "Now we are institutionalising." The project runs for months. The software goes live. Some time later the same debates continue in the same meetings: Why is the stock wrong? Why was the order late? Who opened this product code? Who changed the price? Why don't the reports reconcile?

Because an ERP is not a management model; it is the infrastructure a management model runs on. You cannot buy decision discipline by buying a program. The business has to clarify its own processes and turn new habits into daily work.

The first mistake: handing the software project only to IT

An ERP is a technical implementation, but the decisions it affects are commercial. The product card affects marketing; stock affects purchasing and sales channels; accounts affect finance; pricing affects commercial management; production orders affect the factory; returns affect the customer experience. If IT is the project's only sponsor, departments focus on "is the screen ready?" and the question "who will take which decision based on which data?" is left without an owner.

Sponsorship from top management is needed. In addition, a process owner from the business should be appointed for every critical process. IT carries the discipline of architecture, access, security and integration; finance, sales, production and logistics own the correctness of business decisions.

Causes

The second mistake: carrying dirty data into the new system

In a textile company the same product may be recorded under different codes, with wrong size–colour combinations and missing variant information. In cosmetics, different pack sizes, lot/serial information or channel codes may be mixed up. If the new ERP is built on top of these problems, reports may be produced faster but still wrong.

That is why master data governance is central. Who opens a product card? What is the unit-of-measure standard? How are duplicate customers and suppliers prevented? Which fields are mandatory? Who approves product or price changes? When is an unused code deactivated? Correct data is protected not by cleaning it once, but by owning it continuously.

Data cleansing is not a migration task; it is a permanent business responsibility.

The third mistake: digitising a bad process

If a sales representative phoning the owner for every order is turned into an automatic approval button in the system, the process does not speed up; only the screen changes. If a store manager has to convince three people to request a transfer, an ERP request screen can legitimise that complexity. In process improvement, the decision and control logic must be redesigned first.

This chain can be used for the process map: Where does the request originate? Who checks it? Under what condition does it proceed automatically? Which exception is escalated? Who is the economic owner of the decision? How is an error recorded? In which report does the data appear? Only after this should the software be turned into a workflow.

Success criteria to measure in an ERP project

Opening the software on time is only one measure of success. What really needs tracking is stock record accuracy, order-to-delivery time, the share of manual transactions, reconciliation time, return closing time, the number of data corrections, user adoption, the reliability of critical reports and control breaches. For each indicator the baseline, definition, data source and target must be clear.

For example, if order entry time shortens with the new system while the cancellation rate rises, it is not right to say we have only gained speed. If data quality improves while price approval processes slow down, the decision architecture should be revisited. ERP value is created not in the technical go-live report, but in changes in operational behaviour.

The particular challenge of ERP in textile retail

In apparel, a product is not just a stock code; there are style, season, colour, size and channel variants. Sending products to a store cannot be solved by balancing total units: the best-selling size may be missing in one store while a slow-moving size stays in the warehouse. Price periods, end-of-season markdowns, inter-store transfers, the central warehouse, returns and e-commerce orders must speak through a single data model.

That is why, when evaluating retail-focused solutions such as Nebim, not only accounting but variants, store stock flow, point of sale and omnichannel scenarios should be tested with real transaction examples. A software's general capabilities and the modules actually implemented in a company are not the same thing; the module selection must be verified from project documentation.

Charts on a performance monitoring screen

In Depth

Multichannel cosmetics and manufacturing face other tests

In a business that produces cosmetics or does contract manufacturing, needs differ: raw materials, formula/recipe, production orders, quality, lot traceability, expiry date control where applicable, B2B orders and distribution terms. Squeezing production for a private label customer and retail orders for one's own brand into a single uniform data logic can create new problems.

Broad enterprise platforms such as SAP can offer options for these processes; but specific modules, scope and gains can only be proven by real project documentation. The point here is not brand names, but the business's own process architecture. Software should be chosen according to need; "the biggest system on the market" should not be the only criterion.

The biggest risk is not go-live day, but the habits of the first three months

If users do not know the new screen, managers do not let go of the old Excel report and product codes are still changed by email, the ERP can turn into a parallel bureaucracy. That is why role-based training, user acceptance tests, an authorisation matrix, data migration reconciliation and a support desk must be designed from the start.

At go-live in particular, orders, invoices, stock, till/POS and critical integrations need to be tried with end-to-end scenarios. A "the screen opens" test is not enough. Demanding examples such as unauthorised price changes, stock going negative, returns and cancellations, partial deliveries and wrong product variants should be part of the pilot scope.

The right phases of a transformation project

Diagnosis: The current workings of critical processes, points of loss and decision authorities are mapped. The business objective is written down.

Design: Process owners, a data dictionary, master data rules, integration and the authorisation model are defined. The minimum necessary customisations are selected.

Pilot and testing: End-to-end scenarios are run in a controlled area such as one store, one warehouse or one business line. Old and new data are reconciled.

Cutover: Critical business continuity scenarios, access security, backups, rollback/remediation plans and support resources are ready.

Improvement: In the first 30, 60 and 90 days, data errors, user habits and operational KPIs are monitored; the process is readjusted.

These phases do not follow the same timetable in every business. Supply chain complexity, legal obligations, existing data and the number of integrations change the duration.

The hidden items of an ERP budget

Licence and implementation fees are not the whole cost. Data cleansing, employee time, external integrations, consulting, infrastructure, testing, training, support and process redesign are also part of the investment. Moreover, the most expensive item is sometimes customer trust lost in a faulty cutover. That is why management assesses the project's return not only against software cost, but together with risk reduction, transaction efficiency and decision quality.

It is also wrong to eliminate every exception in the name of process standardisation. There may be different kinds of work that arise from genuine customer needs. What matters is that the owner, reason and cost of each exception are visible.

Roadmap

Where to start in the first 90 days?

First 30 days: Postpone the question "which ERP?" and define the business objective. Examine data quality, critical order flows, stock reconciliation and decision owners. Appoint the project sponsor and process owners.

Days 31–60: Create a data dictionary for product, customer and price data. Redraw the processes with the most frequent errors. Set measurable acceptance criteria for the pilot.

Days 61–90: Test two or three end-to-end transactions with real data. Start user training with managers taking part. Track the operational KPI report from the very start of the project.

Conclusion

Conclusion: software does not give a company judgement; it helps judgement work

Institutionalisation means removing the need for the founder to take every decision, and getting the right data to the right person at the right time. An ERP can be a powerful tool that makes this possible. But if the organisation has no decision rights and no process ownership, the system turns into a new shop window.

You cannot institutionalise by buying an ERP. If you design institutionalisation, an ERP can help it scale.

Frequently asked questions

Why do ERP transformations fail?

Causes such as unclear processes, data quality, insufficient ownership, poor integration and weak user adoption can act together.

Is using SAP or Nebim institutionalisation on its own?

No. Decision rights, process management, data governance and a performance system are also needed.

What is the most critical data in an ERP?

It depends on the business model; ownership of product, customer, price, stock, account and transaction data is usually fundamental.

How is ERP success measured?

Beyond the technical go-live, by error rates, stock accuracy, transaction speed, user adoption and business results.

Sources and further reading

Buying an ERP Is Not Institutionalisation

SAP, Nebim or another ERP can strengthen a company's data and process infrastructure. But on its own it cannot fix unclear authority, undefined processes and weak decision discipline.

Strategy

Family Businesses

ERP & Transformation

Problem

You cannot institutionalise by buying an ERP. If you design institutionalisation, an ERP can help it scale.

A company decides on a major ERP investment. In the vendor presentation, production planning, stock, orders, finance, reporting and integration all appear on a single screen. The founder relaxes: "Now we are institutionalising." The project runs for months. The software goes live. Some time later the same debates continue in the same meetings: Why is the stock wrong? Why was the order late? Who opened this product code? Who changed the price? Why don't the reports reconcile?

Because an ERP is not a management model; it is the infrastructure a management model runs on. You cannot buy decision discipline by buying a program. The business has to clarify its own processes and turn new habits into daily work.

The first mistake: handing the software project only to IT

An ERP is a technical implementation, but the decisions it affects are commercial. The product card affects marketing; stock affects purchasing and sales channels; accounts affect finance; pricing affects commercial management; production orders affect the factory; returns affect the customer experience. If IT is the project's only sponsor, departments focus on "is the screen ready?" and the question "who will take which decision based on which data?" is left without an owner.

Sponsorship from top management is needed. In addition, a process owner from the business should be appointed for every critical process. IT carries the discipline of architecture, access, security and integration; finance, sales, production and logistics own the correctness of business decisions.

Causes

The second mistake: carrying dirty data into the new system

In a textile company the same product may be recorded under different codes, with wrong size–colour combinations and missing variant information. In cosmetics, different pack sizes, lot/serial information or channel codes may be mixed up. If the new ERP is built on top of these problems, reports may be produced faster but still wrong.

That is why master data governance is central. Who opens a product card? What is the unit-of-measure standard? How are duplicate customers and suppliers prevented? Which fields are mandatory? Who approves product or price changes? When is an unused code deactivated? Correct data is protected not by cleaning it once, but by owning it continuously.

Data cleansing is not a migration task; it is a permanent business responsibility.

The third mistake: digitising a bad process

If a sales representative phoning the owner for every order is turned into an automatic approval button in the system, the process does not speed up; only the screen changes. If a store manager has to convince three people to request a transfer, an ERP request screen can legitimise that complexity. In process improvement, the decision and control logic must be redesigned first.

This chain can be used for the process map: Where does the request originate? Who checks it? Under what condition does it proceed automatically? Which exception is escalated? Who is the economic owner of the decision? How is an error recorded? In which report does the data appear? Only after this should the software be turned into a workflow.

Success criteria to measure in an ERP project

Opening the software on time is only one measure of success. What really needs tracking is stock record accuracy, order-to-delivery time, the share of manual transactions, reconciliation time, return closing time, the number of data corrections, user adoption, the reliability of critical reports and control breaches. For each indicator the baseline, definition, data source and target must be clear.

For example, if order entry time shortens with the new system while the cancellation rate rises, it is not right to say we have only gained speed. If data quality improves while price approval processes slow down, the decision architecture should be revisited. ERP value is created not in the technical go-live report, but in changes in operational behaviour.

The particular challenge of ERP in textile retail

In apparel, a product is not just a stock code; there are style, season, colour, size and channel variants. Sending products to a store cannot be solved by balancing total units: the best-selling size may be missing in one store while a slow-moving size stays in the warehouse. Price periods, end-of-season markdowns, inter-store transfers, the central warehouse, returns and e-commerce orders must speak through a single data model.

That is why, when evaluating retail-focused solutions such as Nebim, not only accounting but variants, store stock flow, point of sale and omnichannel scenarios should be tested with real transaction examples. A software's general capabilities and the modules actually implemented in a company are not the same thing; the module selection must be verified from project documentation.

In Depth

Multichannel cosmetics and manufacturing face other tests

In a business that produces cosmetics or does contract manufacturing, needs differ: raw materials, formula/recipe, production orders, quality, lot traceability, expiry date control where applicable, B2B orders and distribution terms. Squeezing production for a private label customer and retail orders for one's own brand into a single uniform data logic can create new problems.

Broad enterprise platforms such as SAP can offer options for these processes; but specific modules, scope and gains can only be proven by real project documentation. The point here is not brand names, but the business's own process architecture. Software should be chosen according to need; "the biggest system on the market" should not be the only criterion.

The biggest risk is not go-live day, but the habits of the first three months

If users do not know the new screen, managers do not let go of the old Excel report and product codes are still changed by email, the ERP can turn into a parallel bureaucracy. That is why role-based training, user acceptance tests, an authorisation matrix, data migration reconciliation and a support desk must be designed from the start.

At go-live in particular, orders, invoices, stock, till/POS and critical integrations need to be tried with end-to-end scenarios. A "the screen opens" test is not enough. Demanding examples such as unauthorised price changes, stock going negative, returns and cancellations, partial deliveries and wrong product variants should be part of the pilot scope.

The right phases of a transformation project

Diagnosis: The current workings of critical processes, points of loss and decision authorities are mapped. The business objective is written down.

Design: Process owners, a data dictionary, master data rules, integration and the authorisation model are defined. The minimum necessary customisations are selected.

Pilot and testing: End-to-end scenarios are run in a controlled area such as one store, one warehouse or one business line. Old and new data are reconciled.

Cutover: Critical business continuity scenarios, access security, backups, rollback/remediation plans and support resources are ready.

Improvement: In the first 30, 60 and 90 days, data errors, user habits and operational KPIs are monitored; the process is readjusted.

These phases do not follow the same timetable in every business. Supply chain complexity, legal obligations, existing data and the number of integrations change the duration.

The hidden items of an ERP budget

Licence and implementation fees are not the whole cost. Data cleansing, employee time, external integrations, consulting, infrastructure, testing, training, support and process redesign are also part of the investment. Moreover, the most expensive item is sometimes customer trust lost in a faulty cutover. That is why management assesses the project's return not only against software cost, but together with risk reduction, transaction efficiency and decision quality.

It is also wrong to eliminate every exception in the name of process standardisation. There may be different kinds of work that arise from genuine customer needs. What matters is that the owner, reason and cost of each exception are visible.

Roadmap

Where to start in the first 90 days?

First 30 days: Postpone the question "which ERP?" and define the business objective. Examine data quality, critical order flows, stock reconciliation and decision owners. Appoint the project sponsor and process owners.

Days 31–60: Create a data dictionary for product, customer and price data. Redraw the processes with the most frequent errors. Set measurable acceptance criteria for the pilot.

Days 61–90: Test two or three end-to-end transactions with real data. Start user training with managers taking part. Track the operational KPI report from the very start of the project.

Conclusion

Conclusion: software does not give a company judgement; it helps judgement work

Institutionalisation means removing the need for the founder to take every decision, and getting the right data to the right person at the right time. An ERP can be a powerful tool that makes this possible. But if the organisation has no decision rights and no process ownership, the system turns into a new shop window.

You cannot institutionalise by buying an ERP. If you design institutionalisation, an ERP can help it scale.