ERP

software

by

industry:

what

does

your

sector

need?

Why does every industry have different ERP requirements?

Every industry has different requirements because its core process is different. Standard ERP packages were historically built around administration and trade: buying, selling, keeping track of inventory and invoicing. The further your core process sits from that, the sooner you hit the limits of the package.

A wholesaler buys and resells. That process is close to what Exact, AFAS, Microsoft Dynamics 365 Business Central or SAP Business One support out of the box. A manufacturer, on the other hand, makes something on the shop floor, with machines, semi-finished goods and changing lead times. A food producer works with recipes and batches that perish. A retailer sells through stores, a webshop and sometimes a marketplace at the same time. And a logistics company earns its money with the flow of goods itself, not with trading them.

So the question behind this article is: how far is your core process from a standard trading process? The bigger that gap, the more likely you need something next to your ERP. That does not automatically mean custom software. Often a well-configured package with the right business software around it is enough. This article covers the industry-specific side: per sector, where a package is enough, where it pinches and what you can do about it.

ERP for wholesale.

ERP software for wholesale revolves around three things: inventory across multiple locations, customer-specific pricing and the connection with sales channels. For the first, a standard package is often perfectly fine. The other two are where it starts to pinch.

Which processes does it need to support?

A wholesaler lives on volume and margin. The ERP has to handle purchase orders, inventory per warehouse, order processing and invoicing, often with barcode scanning in the warehouse and EDI messages to and from large customers. Dropshipping, where the supplier ships directly to your customer, is increasingly part of it as well. This is the ground packages like Exact, AFAS and Business Central were originally built for. If your wholesale business runs on a standard range, standard prices and one sales channel, you probably do not need custom software. Configuring your package well will then pay off more than extra software.

Where does a standard package get stuck?

It pinches at the commercial logic that sets your wholesale business apart. Three areas come up again and again.

1. Customer-specific pricing agreements. Volume discounts per customer group, project prices, contract prices with a term, discounts per product group instead of per item. A package can handle price lists, but as soon as agreements start stacking up, the logic disappears into Excel or into an account manager's head.

2. Assortment logic. Which customer may see and order which item? With a large range and dealer-specific selections, managing that becomes heavy in a system that was not designed for it.

3. The connection with webshop and portal. Your customers want to order themselves, with their own prices and their own order history. That means a B2B webshop or a dealer portal has to show the same prices and inventory as your ERP in real time. Product data often comes from a separate PIM system, which also has to connect.

What custom software adds here is usually a layer next to the ERP: pricing and discount logic the package cannot express, and a portal or webshop that reads directly from the ERP. Print service provider Nou, which sells devices and supplies to business and private customers, chose that route. Cube built a DMP, customer portal and webshop on top of its existing AFAS environment. The webshop is fully integrated with AFAS, which made an external platform such as Shopify or Magento unnecessary. AFAS remained the source. Read more in how Nou connected ordering to AFAS.

ERP for manufacturing.

ERP for manufacturing has to follow the shop floor: what is being made, with which materials, on which machine and at what cost. That is exactly the part furthest removed from a trading process, and therefore where standard packages fall short most often.

Which processes does it need to support?

A manufacturing ERP revolves around the bill of materials (BOM): the list of components and semi-finished goods that make up an end product. Around it sit MRP (material requirements planning), capacity planning, production orders, shop floor data collection and post-calculation per order. In discrete manufacturing an MES often comes on top, a manufacturing execution system that records execution on the floor. A standard package usually handles the administrative side, purchasing, sales and finance, just fine. Many packages also have a production module. The question is whether that module can handle the way you produce. How Cube works with manufacturing organizations is described on the sector page.

Where does a standard package get stuck?

Bills of materials with variants. Once a product comes in dozens or hundreds of versions, you cannot create every variant as a separate item with its own BOM. You need configurable items: rules that determine which components belong to which choice. That is what a product configurator is for: it translates the configuration into a BOM the ERP understands.

Machine scheduling on the shop floor. An ERP plans in days and weeks, the shop floor in hours and minutes. If you want to know when a cutting machine or press brake is free, you need data from the machine itself. In steel and metalworking this matters a lot: sawing and cutting machines that have to receive jobs from the ERP and report remnant lengths or consumption back to inventory. A standard package has no ready-made connection for that.

Post-calculation per order. What did this order really cost in materials, machine hours and labor? If registration on the floor happens on paper or in a separate app, the post-calculation in the ERP is never quite right.

Semi-finished goods and work in progress. Products that sit in stock halfway through the process quickly become invisible in a trade-oriented package.

What custom software adds here is the link between the ERP and the shop floor: a connection with the machinery, configurable items and shop floor registration that writes back to the ERP. The ERP remains the administrative source. Window frame manufacturer Direct Een Kozijn shows what that looks like: contractors configure their frames in a configurator, and a DMP passes those orders on automatically, from order to accounting. Read the background in the Direct Een Kozijn case.

Retail ERP.

Retail ERP revolves around inventory across channels: what is in which store, in the warehouse and in the webshop, and how much of it is actually sellable? Where a wholesaler thinks B2B in customers and margins, a retailer thinks B2C in channels and collections.

Which processes does it need to support?

A retail ERP connects purchasing, central inventory and finance with the points of sale. Those are the tills (POS), the webshop and any marketplaces. On top of that come store inventory, store replenishment, returns and season or collection planning. Packages such as NetSuite and Business Central are often mentioned in retail. Whichever package it is, they handle the administrative core.

Where does a standard package get stuck?

Real-time inventory across channels. A shopper orders a product online that the webshop shows as in stock, while the last item was just sold in a store. That happens when till, webshop and ERP sync with a delay. Selling omnichannel requires one view of inventory that is correct within seconds, not after the nightly batch. That principle is called a single source of truth: for each piece of data, one system is leading.

The connection between POS, webshop and ERP. Every channel has its own system with its own data model. A return bought online and brought back to a store touches all three. Which online store integrations you need depends on the packages you use.

Returns flows. In retail, returns are not an exception but a constant flow. Does a return go back into sellable stock, to an outlet or back to the supplier? That process rarely fits the standard flow.

Collection and season logic. Colors, sizes, collections that only last one season: the item structure in retail is different from that of a wholesaler with a fixed range.

What custom software adds here is the layer that keeps the channels together: real-time inventory sync, a connection between till, webshop and ERP, and dedicated returns handling. For Hartman, which produces garden furniture and sells it through dealers in almost forty countries, Cube built a DMP that feeds consumer websites and a dealer portal from one source, with the existing PIM system as the product source. See how that was set up in the Hartman case.

Logistics ERP: where ERP and WMS meet.

A logistics ERP system is in practice almost always a combination: the ERP handles the financial and administrative flow, the WMS (warehouse management system) the physical flow in the warehouse. Most problems arise where the two meet.

Which processes does it need to support?

A logistics company needs warehouse management with storage locations, order picking, inbound and outbound handling, and often cross-docking: goods that come in and go straight out without being stored. Transport plays a role too, with a TMS (transport management system) for planning and carrier integrations for labels and track and trace.

In this picture, the ERP does what it does well: invoicing, contracts, financial processing. The physical execution happens in other systems.

Where does a standard package get stuck?

The bridge between ERP and WMS. An order is created in the ERP, picked in the WMS and then has to come back to the ERP as shipped and invoiced. Every step is a sync moment. If one fails, inventory is no longer correct or something is invoiced that was never delivered.

Carrier integrations. Every carrier has its own API, its own labels and its own status messages. A standard package supports a few. If you work with ten, you need a layer that translates all of them.

Track and trace for your customer. Your customer wants to know where their shipment is. That information sits with the carrier, not in your ERP.

Location and routing logic. Where do you put incoming goods, and in what order do you pick? That is WMS territory, but it has to match what the ERP expects.

What custom software adds here is middleware between ERP, WMS and carriers: an intermediate layer that translates messages, guards the sequence and provides real-time inventory insight. The ERP and the WMS each keep doing what they are good at.

Food ERP software for the food industry.

ERP software for the food industry revolves around traceability and shelf life. For every end product, you need to be able to trace which batches of raw material went into it, and which batches of end product are with which customer. That is the basis of every recall scenario.

Which processes does it need to support?

A food ERP registers batches and lot numbers from receipt of raw materials to delivery. It manages the best-before date per batch and drives stock rotation on FEFO: first expired, first out. Add to that recipe management, ingredient management and allergen registration, which has to carry through all the way to the label. For the ERP, that means every movement of a batch has to be recorded and traceable.

Where does a standard package get stuck?

Batch and lot tracking with a recall scenario. Many packages can store a lot number. Fewer can show in one overview which raw material batch went into which end products and which customers have them now.

FEFO instead of FIFO. Standard inventory logic often works with FIFO: first in, first out. In food, the best-before date leads, not the date of receipt. A batch that came in later but expires sooner has to go out first.

Recipes with variable yield. In the process industry, the same recipe does not always produce the same quantity. Yield varies with the raw material. A BOM that assumes fixed quantities is a poor fit.

Weighing and labeling. Products with a variable weight have to be connected to the scale, and the label has to show the correct allergens and best-before date.

What custom software adds here is a traceability layer next to the ERP: FEFO logic, recipe and weighing integrations, and a recall overview that follows batches through the entire chain.

How do you extend a standard package without replacing it?

You extend a standard package by connecting to it instead of replacing it. The ERP remains the source for administration and finance. Whatever the package cannot do, you build next to it and connect to the ERP through an integration or a middleware layer that translates data between systems. Technically, that usually runs through an API integration. An integration handles the exchange: orders, inventory and prices move back and forth automatically. What an integration does not solve is a process that is not set up properly in either system. Bringing several sources together is what data integration is about.

When do you not need custom software?

You do not need custom software when the problem is not in the software. Three situations in which we advise organizations not to build.

1. Your processes seem unique, but they are not. Many organizations believe their way of working is different, while on closer analysis it comes down to a standard process with a few exceptions. Then adjust the process first, not the software. That is cheaper, and you stay closer to your package's updates.

2. You have no internal owner for the system. Custom software needs someone who knows why it was built that way, who guards changes and who makes choices. Without an owner, custom software becomes legacy within a few years: software nobody dares to touch anymore.

3. The pain is in the configuration, not in the package. An ERP that was set up years ago and has grown along with workarounds quickly feels like the wrong package. A reconfiguration by your implementation partner often solves more than a new layer on top.

If you recognize yourself in one of these three, start there. Custom software is a means for processes your package truly cannot carry, not for processes that are not yet clearly defined.