Understanding SAP’s Service Parts Maintenance Solution

Service Parts Maintenance is an SAP Multi Module Solution


I had heard the term Service Parts Maintenance (SPM) in relation to SPP, however, I never paid it very much attention. However, upon re-reading the SPP training documentation I found a very detailed explanation as to what it is. According to the SAP documentation SPM is a combination of SPP, BW, SRM, SNP and EWM. Also the documentation is that this is the template that was selected and used by Cat and Ford. In the documentation which is clearly direct from SAP product management they are very strongly encouraging the use of this SPM design and set of components for other clients. At one point in the documentation, the article notes that some modules can be removed, but then the implementing company “will lose functionality.” This seems like a strange thing to point out, as it is axiomatic that when one does not implement a software component that functionality is reduced.

High Risk Strategy?

Generally SPP has not found a big following in industry. I believe that the design and approach of SAP with regards to SPM is one very big reason. There are a bunch of problems with promoting the implementation of so many modules. First and most obvious is it reduces the likelihood of success of the project. Second, there is no way that these modules would work together as simply as proposed, that is proposed as an integrated solution. A much more logical approach would have been (and can be, because there is no reason this strategy can’t be changed) to focus on targeted SPP implementations and getting a sold base of SPP installs before rolling out the “master plan” for a multi component integrated service parts solution. If I had any involvement with SAP product management in SPP I would push for this approach to be reversed. I get a certain amount of deja-vu with this specific topic. I personally dealt with product solutions that were promoted before they were ready when I worked for i2. Looking back on that time now, I seriously question the sanity of many of the people I used to work with. We had development teams that would continually fail to meet their development deadlines, but continue to grow the future promised functionality. Due to the stock bubble of the time it was considered de rigueur to “think big.” Well it all came crashing down, and everyone of those sales people and developers who told me I needed to “get with the vision” of the company owes me a nice apology (no one ever calls unfortunately, they must be too busy building more sand castles in the sky and reducing value from the economy to call me.)

Should SAP Have Control of Your Entire Solution Design For Service Parts

I would say they shouldn’t. There is nothing particularly “service partsy” about BW. While service parts planning requires specialized software, reporting certainly does not. Possible the best fit for the company may be Teradata or some other smaller innovative vendors in the BI space. Who knows? This is a decision for the data warehousing team, and in case SAP is unaware, the service organization at most companies does not exactly draw a lot of water with the data warehousing team. How about the other recommended tools? Just because a company wants to use SPP, should it use SAP SRM? There is no reason to think so. This same logic applies to each all the modules. Each needs to be evaluated on the basis of the fit with requirements, not with its fit with SPP. I have been working with planning solutions for some time, different planning applications to SAP and non SAP systems. I generally do not consider integrating different systems a big deal and non-fancy flat file interfaces held together by Unix batch jobs and Awk scripts (for data manipulation) work perfectly fine. I never needed fancy integration tools to get the job done.


While I like SPP and service parts planning in general, I would never say that my expertise in service parts planning enables me to propose what other software components that are completely unrelated to planning should be. I don’t think there is anyway around each company performing a detailed evaluation of every module it purchases to ensure it will add the maximum business value. I have always thought that software selection is the most important part of the project. I would recommend not short circuiting that process in order to buy into a vision.