Blog

Probably this post should have been one of the first of this blog, but it’s not too late. Derek Singleton pointed me
his article about the differences between APS and
MRP systems and after reading it I can say that I largely agree with him about the differences between the two types of systems by the point
of view of the business environments where they can be used more profitably. His article has been an occasion for me to look for a good definition
of APS, to better communicate the usefulness and role of these kind of systems. The definition in the APICS dictionary doesn’t help too much in narrowing the concept:

“Techniques that deal with analysis and planning of logistics and manufacturing
during short, intermediate, and long-term time periods. APS describes any computer
program that uses advanced mathematical algorithms or logic to perform
optimization or simulation on finite capacity scheduling, sourcing, capital planning,
resource planning, forecasting, demand management, and others. These techniques
simultaneously consider a range of constraints and business rules to provide real-time
planning and scheduling, decision support, available-to-promise, and capable-to-promise
capabilities. APS often generates and evaluates multiple scenarios.
Management then selects one scenario to use as the ‘official plan’. The five main
components of APS systems are (1) demand planning, (2) production planning, (3)
production scheduling, (4) distribution planning, and (5) transportation planning.”

This definition is mostly based on what aps do (listing of modules) and less on how they do it. The most of commercial packages usually
considered APS don’t cover the complete range of
modules provided by APICS definition but only some of them and they are the same considered APS. So there should be also something else that make an application an APS.
I think that a definition should
stress also on ‘how’ the system operates to help planning. And the main features are:

• great speed of computation (achieved by advanced mathematical algorithms but also, often, by means of in-memory dbms)
• powerful visualisation features to let the planner analyze data more easily
• good tools for system integration to fasten the collection of data that can be meaningful for production planning and scheduling.

The main reason the originated APS was that MRP procedure on transactional systems where too slow to let frequent replanning. After
this constraint has been reduced, the visualisation and data navigation features prevent the planner from being the new bottleneck
of the planning process. Data integration is another important aspect that let the planner not to waste time to retrieve data
which are useful for the planning sessions.

I’ve been asked this question several times: what can we push to finished product warehouse using only materials and components that
we already have in house? This question may arise for different reasons: late supplies, problems with paying suppliers, will to consume
certain types of materials. In any case it’s not trivial to solve this problem in an optimal way and it’s not feasible to solve it in a satisfying
way with usual production planning software. An approach that is easy to follow with Cowry for a sub-optimal but good solution is this: create
forecast records for one piece for every finished product beside current customer orders, run MRP, fully peg the forecast records and mark the ones not linked (directly or indirectly)
to purchase orders, increase these forecast records by a predefined amount and run again mrp and pegging until there is no increasable forecast record.
At the end of the process you’ll get the list of forecast records deliverable with in house material.
Of course this approach could be refined considering capacity constraints using the finite capacity features of Cowry or your APS’.