Skip to Content

SAP Rapid Deployment Solution – A consultants view

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.

You must be Logged on to comment or reply to a post.
  • Hi Ravi

    Interesting comments and view points.

    RDS are limited in many ways but they provide the core solution from a technical point of view.

    RDS's are aimed at specific customers, so massive worldwide SAP customers would not be able to use them.

    RDS is a new brand but the concept has been around a while. The benefits are that the implementation should be 40% quicker, which will reduce costs etc.

    The issues for some customers will be the scope. There is not too much in terms of flexibility, so if you like the BoM great, however if you think you can tailor a RDS then think again.

    • Hi Mark,

      Thanks for the comments.  You are right in saying that RDS is aimed at specific customers which is a right strategy.  But based on certain interactions with SAP, we could see that they would want to extend the solution offerings through RDS for many other solutions/components as well.

      As you rightly pointed out, the fixed scope will be of concern and would take a hit in terms of flexibility.  I would like an approach with some amount of flexibility - a  blend of fixed scope and some customizable features which would allow greater adaptability. 

      But instead, a more practical approach should be adopted in the implementations taking RDS scope as a reference to bring in customer specific requirements without compromise on the core of RDS - time.  This can happen with just some interactions (kind of study phase) with potential customers to finalize on what they expect out of RDS and map the same with RDS timelines.  I think this would bring in that flexibility component into RDS.  But caution should be exercised that, this approach can be done when customer is fully educated on the overall functionalities as well as what is available through RDS.


      • SAP have confirmed that they are investing in RDS and the team implementing them will grow.

        I am not an expert, but I believe the way SAP design  the RDS and benefit from the implementation duration reduction is via strict parameters.

        Having flexibly around scope will impact cost, and the idea is that a RDS is fixed price.

        The RDS leaves the door open for consultants to further enhance a RDS delivered solution after go live.