Removing a Module from Production

Interestingly removing SAP SCM modules from production is not often written about. The presumption to many articles appears to be that SCM will always be put in, and rarely taken out. However, all systems are eventually removed, and SCM is going into roughly is 11th year (but only its 8th or 9th with many installations), and removal of SCM modules that either have not met expectations, or which for some strategic reason a decision has been made to move away from SCM as a platform, means that SCM module removal will be a more common occurrence in the future.

Removing PP/DS

On a client I recently recommended the removal of PP/DS on the grounds that it was too complex for them to manage. The model was only managing scheduling and was essentially running two heuristics. The interim solution was to replace what PP/DS was doing with a spreadsheet. The client wanted the solution removed very quickly, but not necessarily permanently. Thus it was important to sideline the system while maintaining the configuration for future use. This can be important as it can push off the date of ultimate decision on a module, and also the day of reckoning with regards to writing off an IT investment.

The Removal Plan

This meant developing a new solution design, and a series of steps to remove the PP/DS module from production.

As with most planning systems, sidelining or removal of a system is easier than sidelining an execution system. Planning systems are generally an offline process flow (although real times systems like GATP, and EWM are the exceptions to this rule). Secondly, in applications such as SNP, DP and PP/DS specific jobs are scheduled, or run manually that cause the planning engine toperformwork. If these jobs are removed from the schedule, the planning module can persist as aconduitof data without affecting the data. This is important because this allows the pre-existing integration to continue, and for the configuration to keep stable in the SCM module, reducing the amount of work required to sideline the application. Finally, this has the added benefit of allowing the future possibility for the application to be brought back into service.

Future State Solution

The next step is either developing a custom solution to perform the work that PP/DS was performing, or initiating a software selection for a third party solution. At this company, the interim solution was to develop a custom solution, and after evaluating the internal tools at the company, it appeared that they were most confortable developing in an application called High Jump. I will be writing more about High Jump in other posts on other blogs, however, High Jump is very interesting because they offer supply chain applications, but they also offer a development environment which can be used to integrate to both SAP, but also to High Jump’s products as well as any custom integration performed in-house. Furthermore, because High Jump develops in a component software model, development created at one client can be easily ported to other clients. The video, which is at the following link (look in the middle of the screen below the two PDFs)

http://www.highjump.com/Products/WarehouseManagement/Pages/default.aspx

High Jump offers very interesting opportunities in that it allows for development objects to be called by external applications, and thus combines development environment with a wide array of supply chain applications, built on an SOA platform.

Conclusion

Several things have to happen to decommission an SAP SCM module. First the module must be neutralized and either taken out of service, or made to serve as a pass through of data. In this case it was easier to make PP/DS a pass through. Next a third party solution or internally developed solution (for the interim or long term) must be developed. Finally, the business users must be trained upon the new approach. Typically after a failed implementation, the users are very motivated to pickup another solution, so that can be the easiest part of the decommissioning of an SCM module.