The majority of the cost associated with integrating ERP systems with supply chain planning systems comes from the effort of getting the data out of the core ERP system. This has to be done even if the supply chain system is being provided by the ERP vendor, itself (e.g. data from SAP R/3 to SAP APO). A much smaller effort goes into getting the data mapped into the planning system. The reason for this is that the ERP systems are usually customized and each customized transaction can cause a hole in the integration. Also ERP's transactional interfaces are more expensive to set up than interfaces that run in batch. Before deciding on using a transactional interface (such as SAP's CIF Interface) make sure that you really need it. Ask how often will the planning system run? And how fast you need the data to transfer in order to run it? With the exception of real-time Available-to-Promise capability, most planning modules will work fine with batch integration.
A second overlooked but costly area in implementing a planning system is the use of analytic views (bucketed views of the plan that can be aggregated, sliced, and diced). They are very important for analyzing a plan, but they are not part of the core ERP-based supply chain planning systems. Both ORACLE and SAP rely on their generic business warehouse for analytic views since they are not part of their supply chain planning module. In both demand planning and supply planning, users require accurate analytical views to make timely decisions. Make sure you understand the cost of setting up SAP Business Warehouse or ORACLE Analytics. Not only do the views need to be set up in the warehouse, but you also need to integrate to it. Typically best-of-breed systems include analytics views as a memory resident capability. To pick the right planning system you have to find out what information is most important to your users and what it takes, in terms of cost and effort, to provide it to them.
One of the biggest cost areas in setting up a planning system is the configuration of the algorithm parameters and business logic, i.e. your business model. This is where the rubber hits the road for a planning system. If the system is not set up to properly handle the key business constraints you could easily end up with a useless plan and serious consequences, e.g. rising inventory, or bad commit dates. The configuration effort involves getting the knowledge out of your head and into the system. Think of all the constraints and business rules that you need to incorporate, and ask how they will be managed within the planning system. Ask how to customize the planning logic and enter custom constraints. Naturally, the system with the most flexibility and ease in setting up your business rules and constraints will be the one that will be most useful and least costly in terms of implementation.
We have noticed many times that companies struggle with a decision to go with either a Bolt-on planning system or their own ERP's planning system. Are there any other points that you are concerned about when it comes to this dicision?