How manufacturers should choose a business system based on data flow

A new variant of a pump gets a new item number in the business system. Purchasing and the warehouse see the new item, but old images and spare parts lists stay in the customer portal for a week. Customers see a product version the business has already changed.

This usually isn’t because the company lacks systems. The same item can exist in the business system, product sheets, the web shop and a reseller’s copy. When each register is updated in its own way, it becomes hard to know which information applies.

That’s why you should assess business systems for manufacturers based on how item, price, stock and order data reach the website, the customer portal and resellers. You need to see how the flow works through the whole chain.

The business system is the hub for product, stock and orders

In a manufacturing company, business-critical information is created in several places. The business system usually handles transactions such as orders, stock and prices. A PIM system gathers product descriptions, images, documents and channel copy for publishing. The customer portal passes the information on to customers.

When the same field exists in several registers, someone has to keep them aligned. If the item number changes in the business system but the product sheet and portal don’t follow, the customer may order with the wrong information. If the stock level updates too late, the portal may show an item that can’t be delivered. Manual reconciliation at month-end then becomes a way of finding differences that should have been caught earlier.

Statistics Sweden describes a business system as software that shares information between functions such as accounting, planning, production, marketing and purchasing. For manufacturing, that means the system’s value depends on how well the same item, customer, order and stock data follow through the business.

A good starting point is a rule of thumb: every data field should have a clear owner. The business system can own item numbers, prices and stock levels, while the PIM owns descriptions and images. You need to confirm the exact division of responsibility against your own processes and systems.

When you compare solutions, you therefore need to work out which data objects are governed where, how changes are passed on and who handles an outage. That mapping shows whether the system you already have can actually deliver the right information to the right channel.

Six requirements that decide whether the system fits manufacturing

Bring concrete scenarios to the demo. Ask the supplier to follow a real order and show how the information moves.

Bills of materials and variants: ask whether variants and revisions are handled within the same item. A common gap is that variants are stored as copies of the item.

Stock levels: ask whether stock is updated in the portal in real time. A common gap is that it only updates in a nightly run.

Product attributes: ask where attributes are changed and by whom. A common gap is that the same field is edited in two systems.

Integration surface: ask whether there are documented interfaces and which versions are supported. A common gap is that the connection is built on a version that is no longer maintained.

Customer-specific prices: ask whether customer-specific prices and terms are governed in the system. A common gap is that the prices sit in a separate spreadsheet.

Upgrades: ask how compatibility is tested before a new version. A common gap is that testing first happens in production.

Bills of materials and variants require clear revision handling. If a new variant becomes a copy of an existing item, you get two records to maintain. In the demo, the supplier should show what happens when a component or product version changes.

Stock levels also need to be tested against your actual use. A nightly update can work for a channel with few orders but cause problems when customers expect current availability. The same principle applies to product attributes. If a weight or packaging unit is changed in two places, you risk publishing contradictory information.

The Swedish Agency for Economic and Regional Growth shows a difference between digitalising administration and using digitalisation strategically: nine out of ten Swedish companies use IT or digitalisation in administration, while 16 percent say they use digitalisation to a large extent for business development (the agency’s results on company digitalisation). A business system can therefore be well established without product and order data reaching the right channel.

Assess integration interfaces, customer-specific terms and upgrades with the same care as production functions. A weak signal is an answer that stops at saying the connection exists, without showing how errors are detected and handled.

End the demo with a connected scenario: a customer places an order in the portal, the order goes on to the warehouse and business system, and the customer gets back an understandable status. That shows whether the whole flow works.

Map who owns each data object before you choose

An Excel file with the range and prices sent to the reseller every Monday is a common finding in this mapping. The file works until a price change comes on Tuesday, and then the reseller sells on old terms for a week. That kind of manual step is what you’re looking for. It reveals which data flows actually reach your channels and which ones stop in someone’s inbox.

That is also where the real selection happens. Assess the system by which flows it actually delivers to the website, portal and resellers.

The following division of responsibility is a starting point to confirm in your company, not a universal rule. The business system normally owns item numbers, units and bills of materials, which are passed to the PIM and website whenever they change in the business system. It also owns stock levels, which go to the website and portal automatically, event-driven or on a schedule, as well as prices and customer-specific terms, which go to the website and portal when prices change. Orders and order status belong to the business system and flow in both directions on events.

The PIM normally owns product descriptions, images and documents, which go to the website, portal and resellers on publication. Channel-adapted copy and attributes go from the PIM to the channels on publication. Who owns spare part relationships, where they are sent and when they are updated is decided in your project, depending on how product information and aftermarket are handled.

Go through the chain from item and bill of materials to quote, order, stock, delivery and spare parts. For each object, document which system is the source today and which other systems or files copy the information. Mark every step where a person moves data by hand, like the weekly reseller file, and note how often it happens.

Decide what delay the business can accept. A later update to a product image may be manageable, while an old stock level can lead to an order that can’t be delivered. Then draw the flow from data source to channel and note which fields must be identical at both ends.

Bring the map to the supplier’s walkthrough and ask to see the same flow in the demo. An article on business systems and e-commerce can also help you identify where responsibilities and information flows meet.

The map shows where the integration sits, which is often where both cost and risk end up. If the spare parts order is correct but the portal shows an old stock level, you have a clear point of failure to investigate. The work takes time and requires production, purchasing and e-commerce to be in the same meeting.

Integrations that keep data aligned across channels

A business system in a manufacturing environment is judged by which data flows reach the website, the portal and the reseller chain. A direct connection between each system can be simple to start with. As more channels are added, each new connection becomes one more flow to test and maintain. An integration layer with defined flows for product master data, prices, availability, orders and customer-specific terms makes responsibility clearer.

What matters most shows when something goes wrong. Idempotency means a retry doesn’t create a duplicate order. Versioning shows which structure a message follows. Logging gives a traceable picture of what was sent, while re-runs let you process a failed flow again.

Consider a stock level that doesn’t update in time after an order. The portal then shows an item that is already reserved, and the next customer may place an order the business has to handle manually. Without logs, troubleshooting is slow. Without a safe retry, the correction can create a new discrepancy.

Measure operational health from the start with data quality per mandatory field, integration errors per thousand messages, sync latency and the share of orders processed without manual correction. These are suggested metrics, not measured industry values. They help you see whether the integration works day to day, not just whether it has technically been deployed.

A ready-made standard connection to your business system can fit when the standard flows cover your processes and responsibilities are clear. It may need extending if you have unusual order flows, special terms or product relationships that don’t fit the standard model. Ask the supplier to list exactly which fields reach the reseller, and with what delay. An article on ERP integration shows how such a layer can be structured in practice.

What ongoing management after go-live requires of you

Take an example. A platform release changes how a price field is exposed in the interface to the website. The order flow to the business system keeps working, but resellers’ prices in the portal stop updating. The release went through because no one was tasked with approving it against your data flows, and the error was only discovered when a customer called to ask why the price on screen didn’t match.

The scenario shows what ongoing management is really about. Every new version requires work even when you want to keep today’s behaviour, because someone has to assess the impact before it is released further. What decides whether a version is safe is that prices, stock and orders reach the website, portal and resellers unchanged.

In practice, that means a named product owner on your side, time set aside for acceptance testing and a documented rule for who approves a new version. An article on integration work shows what needs to be in place for compatibility to hold between system versions.

This approach fits less well when the scope is still unclear, when you want to own all the code yourselves or when the integration is so unique that no supplier can guarantee compatibility. You then need to sort out responsibility, documentation and internal capacity before committing to a management model.

When the solution works and can stay, Glanser can take it over as it is, run it day to day and make improvements at a fixed price when needed. Glanser Care covers version tracking, compatibility through upgrades and bug fixing at a fixed monthly cost, and responsibility for the solution continuing to work when platforms are updated is set out in the agreement. The model still requires you to be able to describe what works and who in your organisation approves changes.

Three questions to ask the supplier

First ask: what does the flow look like from a changed product in the business system to the portal, and who is notified if the sync stops? The answer shows whether the supplier can describe a documented connection or just a chain of individual fixes.

Then ask: which versions of the business system and the platform have been tested together, and what happens to your scope at the next upgrade? A concrete answer shows whether ongoing management rests on contracted responsibility or a hope that everything keeps working.

Finally ask: what does each function cost before work begins, and what isn’t included in the price? The answer helps you see where the uncertainty lies and who carries it when the scope changes.

The questions are useful, but the precision of the answers says more. Named systems, clear flows and concrete versions are better signs than general promises. A supplier that wants to finish by reviewing your actual website, e-commerce or portal is better placed to answer based on your business.

Make the decision based on your current solution

Demo environments show flows that always work. Your own website, e-commerce or portal shows where product data, prices and stock levels actually reach customers and resellers, and where they stop. That difference says more than any presentation.

In a 72-hour analysis, you spend two hours of your time. The result is one of three answers: the solution can stay as it is, it is fundamentally good, or it needs to be rebuilt. Every path leads somewhere. A solution that stays can be taken over as it is and improved at a fixed price when needed, and one that is rebuilt can be assembled from proven parts if a large share of the needs fits in the Function Library.

Start a 72-hour analysis if you want a basis for decisions built on your actual solution rather than a demo.