Before talking about a Minimum Management Backbone, let's look at one of the most common mistakes in ERP implementation, which is to think that:
The more data we collect, the better the system.
In reality, that is not the case. Both extremes hurt management:
Too much data that is
not used, not serving decisions, not updated correctly, or creating too many tasks. It does not help the business manage better; it can make the system heavy, frustrate users and make the project fail.
Too little data to
follow the flow, measure deviations, trace causes or support Kaizen. When simplicity comes first and almost every recording point is cut, the system no longer has enough data to manage.
So the important question is not:
"Should we collect a lot of data or a little?"
But rather:
"What is the minimum data the business needs to manage its flow of operations?"
This is the thinking behind the Minimum Management Backbone.
This article continues the previous article on the management value of data.
What is a Minimum Management Backbone?
A Minimum Management Backbone can be understood as:
The minimum set of data points and transactions that lets a business see its flow of work, control the main deviations and trace problems when they happen.
It does not try to describe every detail of the business. It only focuses on what is needed to answer three questions:
Where is the work now?
What is off plan?
Can the cause be traced at a basic level?
If it does these three things well, the business already has a management foundation very different from running on gut feeling or scattered files.
Why SMEs need "enough to manage" thinking even more
SMEs usually have three big constraints:
Limited resources
The team available for implementation is small.
Non-specialist users
Most users are not system specialists.
Low data discipline
The ability to maintain data over time is still limited.
If a very detailed system is deployed from day one, the business easily runs into:
- too many fields to fill in,
- processes that are too long,
- users skipping steps,
- incomplete data,
- leaders feeling that the software "adds work".
Conversely, if the design is too simple, the business gets no management value. So for SMEs, a sensible principle is:
Start from the minimum data that is enough to manage, then add detail only when there is a real management need.
A Minimum Management Backbone in a manufacturing company
Take a mechanical company that manufactures to order. Its flow of operations can be:
Order
BOM
Materials
Production
Quality
Delivery
Cost
This is the backbone. For each link, the minimum data and its purpose are:
1. Order
Customer, product, quantity, committed date, main requirements. Goal: know what demand must be met.
2. BOM / product structure
Main materials, quantities, units of measure, operations or routing at the level needed. Goal: know what it takes to make the product.
3. Materials
Available or short, quantity, expected date, source of supply. Goal: know whether materials block production.
4. Production
Manufacturing order, main operations, status, actual output. Goal: know where the product is in the flow.
5. Quality
Pass or fail, defect quantity, main defect type if needed. Goal: know whether the output meets requirements.
6. Delivery
Expected delivery date, actual delivery date, completion status. Goal: know the ability to keep commitments to customers.
7. Cost
Materials, labor or machine hours at the level needed, main direct costs. Goal: know whether the order or product delivers the expected financial result.
A BOM with main components, quantities, units of measure and the operation each one is consumed in.
Component status on each manufacturing order shows whether materials block production.
There is no need to collect everything from the start. Just make sure this flow is never broken.
The level of detail should grow with management needs
This can be divided into three levels.
Level 1 - Traceable
Know where the order is, whether materials are ready, whether production has started, which operation is running, whether goods have passed QC and whether they have been delivered. Goal: no work disappears from management's view. No need yet to record every minute, every detailed defect cause or every small action.
Level 2 - Measurable
Add start and end times, planned and actual output, consumption, defects and variances. Goal: know where deviations are. Lead time, cycle time, WIP, defect rate, material variance and productivity can then be measured.
Level 3 - Optimizable
Only when deep Kaizen is really needed, add cause codes, root cause, downtime, reasons for delay, classification of incidents and detailed data by person, machine or operation. Goal: know where to improve and why.
Level 1: the status of each operation shows which one is running and which is waiting.
Level 3: a quality alert records the root cause and corrective and preventive actions.
Not every business should be forced to start at this level.
A typical example: how detailed should routing be?
Suppose a mechanical product goes through:
Cutting → Turning → Milling → Drilling → Welding → Grinding → Painting → Assembly → QC
If the business only needs to know which workshop the order is in and whether the product is late, the steps can be grouped:
Machining → Welding → Painting → Assembly → QC
But if after a while the data shows that "Machining" is the biggest bottleneck, only then should it be split further into Cutting → Turning → Milling → Drilling.
Operations on the BOM can start at a grouped level and be split later when the data calls for it.
Only increase detail when that detail helps the business make better decisions. Don't digitalize deeply from day one just because the system can.
Likewise, the BOM does not always need "maximum detail"
A BOM can be built at several levels.
Main materials are enough when
the business only needs material planning, purchasing and basic cost of goods sold.
Multi-level, detailed BOMs are needed when
the business wants to analyze losses by part, trace defects to each component, manage semi-finished goods or analyze cost in depth.
The level of detail of the BOM must match the level of management the business wants to reach.
Minimum data does not mean sloppy management
This is easy to misunderstand. "Minimum" does not mean "as little as possible". It means:
As little as possible, but enough.
For example, a business drops BOM data altogether to reduce tasks. The result: material needs cannot be calculated, consumption cannot be controlled and product cost cannot be calculated reasonably. That is not simplification. That is:
cutting away management capability.
Conversely, asking engineering to fill in 30 fields that nobody uses is not good management either. The balance lies between the two extremes.
Keep a piece of data when it protects a management capability
It can be tested with one question:
If we drop this data, what capability does the business lose?
Drop the committed delivery date
You lose the ability to measure on-time delivery (OTD).
Drop the BOM
You lose the ability to calculate material needs and control consumption.
Drop operation status
You lose the ability to follow the flow of work.
Drop actual times
You lose the ability to measure cycle time.
Drop defect causes
You lose the ability to analyze root causes.
This question separates data needed for management from data that only makes the system heavier.
Implement Viindoo along the backbone, not by number of modules
A common mistake in ERP implementation is: "Turn on one module for each department the business has." This easily splits the project into pieces. A better way is to look at the value stream, for example:
Customer orders → engineering defines the configuration → materials are purchased → the warehouse issues materials → production → QC → delivery → costs are recorded
Viindoo is then configured so that data flows through this whole chain. The goal is not "implement Sales, Purchase, Inventory, Manufacturing..." but to make sure an order can go from demand to result without the data being broken.
This is the real foundation for Kaizen across departments.
With the Make to Order and Manufacture routes, confirming the sales order creates the manufacturing order, reachable from the Manufacturing button.
Not every data point needs manual entry
A Minimum Management Backbone must also go together with automation. For example:
- transaction creation date: recorded by the system,
- status: updated by the workflow,
- material needs: derived from the BOM,
- stock: updated by inventory transactions,
- values: calculated by the system,
- reports: aggregated automatically.
Users should only enter data the system cannot infer by itself. This keeps enough data while reducing the operational burden.
A quality control point is set only for the products and operation types that need checking; the system then generates the checks.
"Enough to manage" must come before "enough to optimize"
From day one, SMEs often want to know each person's productivity, each machine's efficiency, the ROI of each operation and the cause of every type of defect. But if the business does not yet have a standard BOM, clear work statuses, material data and basic production progress, trying to collect deep indicators will be very hard to sustain. The order should be:
Traceable
Measurable
Analyzable
Optimizable
This is a much more realistic roadmap for SMEs.
Minimum data also creates a baseline
An important benefit of the backbone is that the business starts to have a baseline. Before digitalization, it may not know the average lead time, waiting time, defect rate or consumption level. After a few months of minimum data, the numbers start to appear. Only then can it:
- identify problems,
- choose Kaizen points,
- measure before and after,
- calculate the real ROI.
Material and operation costs of a manufacturing order become a cost baseline.
Quality Checks, Quality Alerts and Alert Actions Analysis reports turn quality data into a baseline.
A Minimum Management Backbone is not the end goal. It is the foundation that shows the business where to dig deeper.
In practice: start from the "flow that must not break"
A simple question to ask when surveying a business:
"If you could choose only one business flow to see end to end, which one would it be?"
Manufacturing
Order → BOM → materials → production → delivery → cost
Trading
Lead → quotation → order → stock → delivery → receivables
Services
Opportunity → contract → project → task → timesheet → acceptance → invoice
Just do this main flow really well first. Other data can be added later.
Viindoo's role in the "enough to manage" model
Viindoo fits this approach because data can be linked across operations on one platform. Data created at the start of the flow can keep being used further down, for example:
Sales Order
creates demand
BOM / Manufacturing
creates material needs
Purchase / Inventory
supplies materials
Manufacturing / Quality
makes the product
Delivery
completes the order
Accounting
reflects the financial result
The manufacturing order keeps the sales order as its source document, so data from the start of the flow is reused downstream.
The implementation goal is not to make each module very complex. The goal is:
Connect enough key points for the business to see its whole flow of operations.
5 principles to avoid an overly heavy ERP
1. Don't collect data nobody uses
If you cannot say who uses it, review it.
2. Don't go more detailed than you can maintain
An ideal process that nobody updates has no value.
3. Don't make people enter what can be automated
Reducing tasks is part of system design.
4. Add detail only when a new management question appears
Add data only when the business needs deeper analysis.
5. Always protect the core data flow
However lean you go, never break the flow: demand → execution → result.
Conclusion: a good system is not the one with the most data
A good ERP system is not judged by the number of data fields, workflows, reports or modules turned on, but by:
Whether the business can see and control its flow of operations.
So: more data is not always better. Just enough to manage, but truly enough. That is the spirit of the Minimum Management Backbone. With Viindoo, the right way to implement is:
Build the minimum data backbone
Run it stably
Get a baseline
Pick Kaizen points
Add detail where it matters
Automate
This helps SMEs avoid an overly heavy system without giving up their ability to manage.
Frequently asked questions about the Minimum Management Backbone
It is the minimum set of data and transactions that lets a business follow its flow of work, spot deviations and trace causes at the level needed.
No. "Minimum" means as little as possible, but still enough to protect the management capabilities the business needs.
Start at the Traceable level, following the flow of work, then expand to Measurable and Optimizable.
Detailed enough for purchasing, production, consumption control and costing, according to the business's real management needs.
Viindoo connects data across sales, BOM, purchasing, inventory, manufacturing, quality, delivery and accounting on one platform, helping the business keep a continuous data flow.
Next in the series: How detailed should data be? Sales Order, BOM and production
In this article we established that a business does not need to collect all data, but it must keep its management backbone. The next article looks at a more concrete case: how detailed should a manufacturing order be, from the Sales Order and BOM to production, to be just enough to manage without overloading users? It will be one of the most practical articles in the series.
