There has been some debate going on about SAP’s new implementation methodology or offering Rapid Deployment Solutions (RDS). I am not going into details of it whether which is better. I would try to provide a neutral stand point without any sales pitch.
In the midst of HANA and mobility focus of SAP, there is one which is gaining prominence in SAP scheme of things - RDS. SAP definitely sees some good opportunity to do more business. It does open new segments, new customers, new avenues and thus more revenues. So what is RDS and what is new in it? It is not something very new as a concept. It is providing solutions which are modular in nature and easy and quick to implement. Or that is what SAP aims it. If that is the aim, then what it takes to achieve it? The core of RDS methodology is reusability. The test cases, training materials and in fact the configuration itself is going to be reused for all customers. Let us keep it simple. Any SAP component on its own is a huge module and has quite a lot of features which have been developed over the years across different countries and different SAP versions. There is a fair amount of flexibility to configure and customize any component according to individual customer requirements. The component can be anything from HCM to CRM to Core ECC itself with all sub components like FICO, MM etc. SAP does offer building blocks in different areas which can be used to configure the base for most of these components and is based on SAP best practices. The customers can use them for making a small Proof of Concept for analyzing and testing on how these components work for them. We will not get into those details. However building blocks do require SAP expertise in those areas and can involve some custom developments. Also most of the times it takes quite some time& effort to implement and test them. It cannot be exactly predicted on what the exact effort or time required and can sometimes overshoot the budget. Hence it is best kept for testing new solutions but never used as a full-fledged implementation in a productive environment.
So how is RDS different? Similar to building blocks, in RDS, the base solution is pre-configured, but most of the similarities stop there. RDS solution looks at using them in a productive environment. There are certain base features of the components which is pre-configured and packaged as a solution. But will it work for all the components? No. The answer is definitely a big NO. If you look at a pre-packaged solution for Financial Accounting or Controlling or Materials Management, it is something which is very specific to every customer. This definitely cannot be something which can be packaged and given as a common solution for all. If you try doing this, I guess it might end up in a failure. For these cases building blocks does appear to be good start up point from a customer perspective.
But RDS does help customers with certain niche/specific components like Treasury or Manufacturing Intelligence (XMI) or HCM where there is a certain amount of commonality. There are certain features inside these which are generally used in similar way across all the industries or countries. For e.g a fixed deposit is something which is going to be handled the same way across most of the countries or for that matter employee self service or personnel administration is going to be the same way in most of the companies. By this, I don’t mean there is a rigid structure. There might be some small variations or changes for individual specific customer. But on the whole the process is common and same across industries. It is these features that RDS pre-packages and delivers. The major advantage of RDS kind of delivery is that, it removes most of the delivery related risks as well as the skill or technology related risks for these niche components. Customers know upfront what they are going to be delivered, how it is going to be delivered, what are the business cases that are to be tested and what would be the involvement from the customer side. Most importantly, the cost he is going to pay and the timeline it is going to take. It is almost prefixed reducing or removing most of these risks.
RDS do offers a good way to start off with those components for customers where the current way of managing them is not very accurate. Let’s say a customer is evaluating a HCM solution from SAP and is in-fact more inclined towards it but is not sure on which components he would require, he can very well start off with base RDS packages and get the solution up and running with say less than 3 months. This would be done with very little customizations involved and more of a standard solution. But during the course of implementation as well as immediately after it, the customer would be placed at a much better situation to understand the overall capabilities in HCM side and then start to tweak the process as per his requirement. Also the features which are specific for individual customers can be implemented after the RDS implementation. This would enable the customer prepare a roadmap for HCM component pretty accurately. RDS will not work for components which require a lot of master data or for those processes which are specific for individual customers/countries. RDS typically is a joint exercise where the customer would be playing an equal role to that of an implementation partner. It is always best to keep the large custom solution developments after the RDS implementation because the customer would not be so well informed about the processes through SAP and thus would require some amount of time for them to settle down in order to go ahead with custom developments.
Due to the very nature of RDS, it would be ideal to have a quick study phase before the start of the actual RDS implementation. This phase can be utilized by the customers to understand the overall component let’s say treasury (sorry for my bias towards treasury- but I am sure it can be extended for other solutions as well) and what are the features which would be required for them and then decide on whether RDS is best suited for them. Let me give an example to illustrate that: Let’s take a treasury department. It deals with investments and debts and a good amount of securities (stocks & bonds). SAP treasury would support managing all these. However RDS will help them map their investments and debts in SAP but not securities because this would require a lot of master data and also the processes has good amount of adaptation specific for individual customers. Certainly implementing Hedges or derivatives (options or forwards) cannot be done in RDS mode. Now only the initial study phase would help in determining whether an RDS approach followed by implementation of securities would work or can the securities be implemented in parallel to RDS with additional efforts within those timelines or a normal big bang treasury implementation (not in RDS mode) is required for them. That also depends on what additional components like hedging, extensive risk management etc which are required.
Since we are at a very early stage of RDS adoption, the approach might undergo quite some refinements. However, the base does look strong for certain cases. But one thing is clear that, RDS will not/should not be applied for all components. Also we have to carefully study different components, the implementations that have happened around the globe and in various industries to choose the base for RDS. It is time to have a close look and follow it. I am particularly interested on what other components SAP/partners come up in RDS mode and also what other additions/changes that happen to RDS approach over time.
