APS planning: when ERP is not enough

Management challenge

When production depends on capacity, routings, materials, batches, shifts and delivery dates, a simple calendar plan quickly becomes infeasible.

When the problem becomes visible

• Production repeatedly replans by hand
• Procurement discovers shortages too late
• Sales promises dates without checking capacity

How to design the solution

This approach keeps the discussion focused on management control rather than only on system functions.

• Digitise constraints
• Prepare routings and standards
• Agree order-priority rules
• Set up exchange with ERP

Common mistakes

The most common mistakes appear when a team trades architecture quality for launch speed.

These mistakes may be hidden during a demonstration but become visible in production operation.

• Implement APS before master data is ready
• Leave planning rules unchanged
• Test only simple orders

Key takeaways

• APS is used to make a plan feasible, not merely attractive.
• Constraints must be formalised.
• Integration with ERP is essential.
• Production, procurement and sales need shared planning discipline.

Answer for management practice

For “APS planning: when ERP is not enough”, define the outcome as a change in management practice. The central object is work centres and calendars; it needs an agreed source, decision owner and observable state after the action “identify the management object”.

The first evidence is not a solution presentation but a reproducible example of “orders compete for the same resource”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

Applied analysis: APS planning: when ERP is not enough

The question “APS planning: when ERP is not enough” becomes a decision about production routings. Before discussing technology, document the owner, a baseline example and the constraint that must survive the process change.

The team then links work centres and calendars to a role, rule and the action “identify the management object”. This framing allows options to be compared through one scenario without confusing mandatory requirements with interface convenience.

Evidence for materials and availability confirms the outcome only when its source is known and the method remains stable. Otherwise, the team decides whether to revise the data, process or architecture.

• Working object: Production routings.
• Diagnostic signal: Orders compete for the same resource.
• Response action: Identify the management object.
• Controlled risk: A scenario without priority rules.

Where the problem becomes visible

Diagnosis examines a concrete episode involving production routings. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “the plan cannot explain a delay” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Signal: Plans are repeatedly corrected manually. Evidence includes an example, frequency and consequence for plan, actuals and rescheduling causes.
• Event to test: bottlenecks are found after release. Evidence shows timing, frequency and consequence for orders and priorities.
• Indicator: Orders compete for the same resource. Analysis needs an actual example and the resulting change in production routings.

Subject model and boundaries

The subject model starts with two reference objects: production routings and work centres and calendars. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “assign roles and actions”.

The primary boundary is production routings. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Control record 1. Object: Orders and priorities. Observable signal: The plan cannot explain a delay. Accountability: semantic owner and quality owner.
• Boundary 2. Object: Production routings. Define the source, frequency, permitted transformations and response to “plans are repeatedly corrected manually”.
• Object 3: Work centres and calendars. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Bottlenecks are found after release.

Management question

The article addresses “APS planning: when ERP is not enough”. The adjacent management issue is when ERP is not enough. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “the plan cannot explain a delay”, the material risk is “a scenario without priority rules”, and the testable action is “assign roles and actions”. This chain turns a broad term into a concrete decision.

• Decision 1: object — orders and priorities; signal — bottlenecks are found after release; action — identify the management object.
• Decision 2: object — production routings; signal — orders compete for the same resource; action — assemble data and constraints.
• Decision 3: object — work centres and calendars; signal — material availability is disconnected from the schedule; action — assign roles and actions.

A practical decision model

The method is a sequence of decisions rather than a universal checklist. For work centres and calendars, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For production routings, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “identify the management object”.

• Step 1. Frame the problem. Output: plan, actuals and rescheduling causes.
• Identify the management object is the action at stage 2. The output documents orders and priorities.
• At position 3, the action is “assemble data and constraints”; its result is production routings.
• Stage 4: assign roles and actions. The working artefact describes work centres and calendars.

End-to-end scenario data

Describe data exchange as a contract between owners. For work centres and calendars, specify the triggering event, system of record, mandatory fields, pre-transfer control and the recipient's response to an error.

Choose the transport mechanism after frequency and resilience requirements are known. Check “orders compete for the same resource” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Record 5. Object: Plan, actuals and rescheduling causes. Required details: identifier, lineage, quality rule and update event. Signal: Material availability is disconnected from the schedule.
• Subject area 4: Materials and availability. Verification basis: system of record, owner authority and the signal “orders compete for the same resource”.
• Object 3: Work centres and calendars. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Bottlenecks are found after release.

Decision-rights matrix

For materials and availability, the role model determines more than screen access. In the action “identify the management object”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For materials and availability, this separation is especially important because of the risk “ideal standards instead of actual constraints”.

• Business owner: decision area — plan, actuals and rescheduling causes; control action — frame the problem.
• Architect is accountable for orders and priorities and confirms the action “identify the management object”.
• Role: Data owner. Decision object: production routings; verified step: assemble data and constraints.
• Project manager decides within work centres and calendars; the basis is prepared through “assign roles and actions”.

Evidence that the solution works

The acceptance criterion for materials and availability includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “the plan cannot explain a delay”, passes through an authorised decision and “assign roles and actions”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1: Orders and priorities; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Bottlenecks are found after release.
• Criterion 2. Object: Production routings. Test fields: baseline, target change, source and owner. Signal: Orders compete for the same resource.
• 3. Acceptance object: work centres and calendars; compare the baseline sample, expected change and confirmed actuals. Test signal: Material availability is disconnected from the schedule.
• Evidence item 4 describes materials and availability, comparable test conditions and the person accountable for interpretation. Signal: The plan cannot explain a delay.

Controlling critical dependencies

For the risk “a scenario without priority rules”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

An assumption concerning work centres and calendars remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• Risk: Ideal standards instead of actual constraints. Control: verify the outcome. Evidence: production routings.
• Risk condition 2: Excessive or insufficient granularity. Response: Frame the problem. Testable evidence: Work centres and calendars.
• The risk scenario “mixing planning horizons with dispatching” is addressed through “identify the management object” and confirmed using materials and availability.
• Controlled constraint: a scenario without priority rules. The owner performs “assemble data and constraints” and provides plan, actuals and rescheduling causes.

Materials for starting work

The first session examines one real case involving production routings. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “orders compete for the same resource”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “identify the management object”; assign an additional test or stop condition to the risk “ideal standards instead of actual constraints”.

• Step 1. Frame the problem. Output: plan, actuals and rescheduling causes.
• Identify the management object is the action at stage 2. The output documents orders and priorities.
• Evidence item 4 describes materials and availability, comparable test conditions and the person accountable for interpretation. Signal: The plan cannot explain a delay.
• Test 5 concerns plan, actuals and rescheduling causes. The method, interpretation owner and outcome source are documented. Signal: Plans are repeatedly corrected manually.