In IT projects where a business application must be integrated with the ERP system, the cost of creating the data interchange routines can be very high, sometimes
as expensive as the business applications that must be added. Reasons for this are related to the fact that the company that wants to connect the applications can
work only with the manufacturer of two systems, especially if the integration technologies used by these are not accessible to the IT department of the company
(because the source code of the applications is needed or because legacy technologies must be used). These types of problems are faced also when we want to introduce
a planning system in a company and limit the diffusion of these systems only to big companies. All this is much true for older APS systems, which usually
feature less recent integration technologies. One of the most flexible and innovative approach to this problem is that used by Sikuli, a tool developed by MIT
(and used by leading company, as the website states) which has reached production grade status. It is an application that can be programmed not writing
code but describing the operations to be accomplished by the images of the button to be clicked, the text control to be filled and so on.
By the point of view of the processes where APS systems are involved, this tool enables the transfer of data towards the ERP database emulating a user who interacts
with his ERP user interface. It is a tool that can be used both for data entry (we used it to upload item master records on the ERP) and for routinely transfer
production orders or purchase requests. This means that the company that wants to export data from APS to ERP is able to create the interchange procedures on her own
and quickly, reducing the project’s costs. Further, from some systems (also from Cowry) it is possible to launch Sikuli directly, giving to it the order list or other data
as input. Systems’ integration accomplished this way it’s easier to do and to be tested and can reduce costs and lead time of the project’s integration phase.
Blog
Lean integration technologies
APS and MRP
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.
Finite capacity for a specified horizon
Finite and infinite capacity planning can be mixed in a planning session in different ways: they can be applied distinctly to different
resources (as told in another post of this blog) or they can also be combined to the same resource (workcenter, tools or other facilities). In other words, it is often convenient
to set the finite capacity constraint to a resource over a specified horizon from the current date and leave infinite capacity beyond that horizon.
This way we can model the case when we cannot change capacity in the short run but we can acquire additional resources or capacity in the medium/long period. Is trivial to setup this in Cowry.
Schedule a product line phase-out
Your APS can be used to decide when giving up selling product line A given that you are introducing a new product line (B) which
improves A and will be sold to A customers at a higher price than A. So, for how long are you going to sell the A products after B products’ launch?
Well, this kind of decisions must be related to the obsoletes’ value at the end of A sales and the relative cost of going on manufacturing A products to avoid
shortenings before the phase-out date. An handy approach for this purpose using your APS is preparing a set of possible phase-out dates and running your computing
engine for each date and at each step remember to cancel the independent demand for A product beyond the phase-out date and to smooth away safety stock not to have
undesired stocks at the end of A sales. The KPIs to evaluate each scenario could be the value of unbound stock of A products at the end of the planning horizon
and the workload or future expense generated by A products planned orders.
