Integrating Your ERP with Planning Software: What You Need to Know

The integration between an ERP and a planning platform is where most of the practical difficulty in a planning project lives. Get it right and the plan is current, trusted and cheap to maintain. Get it wrong and the business runs two versions of the truth with an overnight job in between.

## What the integration actually has to carry It helps to separate the flows, because they have different requirements:

• Master data, including items, customers, suppliers, locations, bills of material and calendars
• Demand signals, such as orders, forecasts, shipments and returns
• Supply signals, including inventory positions, open purchase orders, work orders and capacity
• Planning output returning to the ERP, typically planned orders and adjusted dates
• Reference data, such as prices, costs and units of measure

Master data is the largest and least glamorous of these, and it is where most integration problems originate.

## Batch, near-real-time, or event driven The right choice depends on the decision it feeds. Item and customer hierarchies can move nightly without harm. Inventory positions and capacity consumption often need to be closer to real time if the plan is to be usable during the day. Event driven integration is more capable and more expensive to build and support. Decide per flow rather than for the whole interface, and be honest about whether the business will actually act on a number that is an hour old.

## The master data problem Planning systems expose master data weaknesses that transactional systems tolerate. Duplicate items that never mattered at order entry will distort a forecast. Missing lead times will produce nonsense in a supply plan. Hierarchies that do not reflect how the business sells will make every report arguable. Agree the source of truth for each field before build, and accept that the cleanse is part of the project, not a prerequisite someone else will complete.

## Who owns what A planning platform should not become a second ERP. The usual division is that the ERP owns transactions and the plan owns intent: the ERP records what happened and what is committed, the planning system decides what should happen next. Writing that division down, field by field, prevents the slow drift where both systems start maintaining the same data.

## Testing that reveals the truth Testing reconciliation is not enough. The test that matters is whether the same question asked in both systems returns the same answer, at the same grain, on the same day. Run it in parallel for a full cycle, including a period-end and a promotion, and reconcile the differences one by one. The differences are where the real understanding lives.

## Planning the cutover Sequence the cutover so that the flow that feeds the most important decision goes live first. Keep the previous method available for a defined period rather than indefinitely, and name the date it stops being tolerated. Our solution architecture team designs these interfaces, and data management covers the cleanse. Book a demo to discuss your landscape.