Skip to Content

RDS – The new paradigm in SAP implementations

Rapido!! Speed!! Faster ROI!!


 As Many of us have noted during out exeperiences with numerous customer SAP implementations “Rapid” and “SAP”  usually never show up in the same sentence.

This is exactly the paradigm that SAP wants to break. Many of us know that, it turns out to be the reality in many customer implementations, because of either the customer’s lack of end vision or the partner’s inability to assert into the CxO or stakeholder organization, this stands to be fact.

Changing times, Changing SAP 

With a lot of customer feedback, partner inputs and extensive research SAP has come out with their latest offering called “Rapid Deployment Solutions” . RDS Attempts to take care of the three things that have been affecting the SAP penetration in a market that SAP leads by leaps and bounds:

  • Scope creep and business ambiguity

  • Ease of Licensing and software cost

  • Endless Implementation Schedules

RDS Advantage

The RDS Advantage: 

With RDS the top 3 issues are taken care of by these unique steps that are encompassed into the RDS methodology:

Scope Creep:

In the RDS process there is “No Blueprint” phase at all !!! How cool is that ?

The scope for each RDS package is “pre-determined” and “sold as-is” to the customer, so there is no more deliberation, and only a “Push” strategy.

The picture below show how this is achieved:

Zero Blueprinting effort on RDS

Ease of Licensing and Software Cost:

In the RDS mode of implementation the packages are modular and have a clear software and licensing cost per package. Customer are smiling away as the complexity is out of the door.

Endless Implementation Schedules:

With scope creep, and never ending business requirements for custom configuration and reports, many a implementation project heads the titanic way!!

With a fixed scope, and “zero” custom in the mix RDS cuts the chase and keeps it simple, and to the point. The customer only gets what he is sold, and provides sign off without a sweat.

Since RDS allows for customers to pulg-n-play the business processes that they really need via the specific RDS packages they need, it makes life easier for the CIOs to arrive at their “Make or Buy” decisions.

Some of the packages in the offering are as below, with SAP published timlines:

RDS Packages and their release schedules 

RDS also allows for shorter bid cycles, as the customer is approached with the final price, and doesn’t need to go through the pain of “Price Haggling”, which will end up being a blessing for your sales team.

In summary, RDS is the new paradigm, and customers and partners alike will benefit by this shift, enabled by SAP.

The opportunities:

 Im my personal opinion here are some potential packages and the relevant opportunities you could explore with the packages. Please also note that most of the RDS packages need the customer landscape to be at ECC 6.0 and EHP 4:

SAP Treasury and Risk Management [TRM]:

Assume you have a customer who has recently done an ECC 6.0 upgrade, and has not spent time on or ponedered about TRM as a solution due to time or cost contratints. TRM via the RDS route could serve as a solution; as it provides precise and core functionalities that are needed, and there by adds this to the 2011 or 2012 portfolio.


SAP Employee Self Service [ESS]:

We all know many customers who SAP HR or HCM in its different flavors. There will be a strong case for such customers to consider using the RDS route to establish a ready out-of-the-box solution for managing operational activities in HR via the enterprise portal.

The list can go on, and possibilities and opportunities are unlimited, its time for you to explore.

You must be Logged on to comment or reply to a post.
  • “The scope for each RDS package is “pre-determined” and “sold as-is” to the customer, so there is no more deliberation, and only a “Push” strategy.”

    Can you give me an example where a sane and knowledgable customer would buy something that is implemented via RDS?  Because I’m highly skeptical of any solution where the customer has no input into the final solution.  Enterprise software does not lend itself to rigid packaged solutions.  When you pay big $$$, you expect the software to solve your specific problem.


    • Hi Nathan,

      I completely agree with you that the scope offered through RDS will certainly not be sufficient for any customer. 

      However, I do feel that RDS will put in a platform for building further.  If you take the case of treasury, the most widely used components of treasury viz. money market, forex etc. and also the components which can be implemented with a relatively 90% commonality are the ones offered through RDS. Hence customers who are a bit skeptical about going for a full fledged treasury implementation with all functionalities can actually look to RDS as a base where the customer knows what he is going to get upfront. Then once he is comfortable with the RDS functionalities he can always build on other. 

      I feel RDS is aimed at showcasing SAP’s abilities at a relatively lower cost.  It is more like a trial version without any validity restrictions..:)    


      • I’m skeptical because SAP has been down this road before and it hasn’t worked.  It’s widely acknowledged that SAP Applications are complex…  ERP, BI, SCM, PLM, CRM, etc.  SAP has tried to make them easier and quicker to implement but it’s never been accepted by the market because there is enough variation amongst customers to justify more in-depth blueprinting, configuration, development…  and voila, you have yourself a project!  Maybe ByD and B1 can do this via pre-configured solutions but they haven’t been able to make it work with their business suite in the past and I don’t see how a change in methodology will fix that.  Unless the solutions themselves are augmented in some way to make them more flexible, I don’t see how you can implement them quickly.
        • Hi Nathan,
          As mentioned in my earlier replies, the fact that customers have been used to getting ZSAP from the partners, which is nothing but SAP configured to match their legacy systems, there will be a shift in the paradigms.

          I can also share with you that, in my discussions with a lot of CXOs, and SVPs, the general concern they are sharing revolves around their “Custom Developments”, as they tend to become their roadblocks for future catch.

          RDS is a building block in that direction, where customers will be allowed to explore the core functions of reporting and analytics that come out of the box, rather than make custom objects.

          • The problem is you make the assumption that all custom developments are a result trying to make system look like legacy, when most of the time the ones that survive are a result gap between the packaged software and the real-world process.

            I also share some valid skepticism with the RDS, but I could see it working for processes that are relatively generic(IT Service Management) and could be accepted 100% out of the box.  I don’t expect however an RDS that could implement say order to cash using pure vanilla(no code, pure customizing, all out of the box analytics/reports) and meet the requirements for typical company.

            Take care,


          • Hi Stephen,
            when I referred to ZSAP, I was was referring to customers getting a lot of flexibility in adapting SAP standard reports or features into customer suitable form, which does not really need to mock the legacy systems.

            Your observation is right about the application of RDS that it can be used to supplement the existing base set up with these quick to rollout functionalities that address the core needs in a specific area. All custom development would be analyzed as part of the customer’s ongoing block point strategies.

          • Hi Stephen,
            Your viewpoints and observations are correct in the fact that this does not replace a traditional implementation for an O2C or P2P process. What it does it make it easier and modular for customers to augment their existing SAP footprint.

            What RDS also does is that it addresses the areas which are “Master Data Independent” there by eradicating the need for a Business Blueprint phase.

            I’ve pasted links below of some RDS packages being offered which might throw additional light on the topic.



            Neeraj Sripuram.

          • Neeraj,

            That makes perfect sense, let’s eliminate reviewing the requirements of the business in a blueprinting phase and hope that whatever we implement will work.  It sounds like a great path to project failure.

            If you believe you can eliminate the blueprinting of business requirements, I have some bridges that I can sell you at decent price.

            Take care,


          • Hi Stephen,

            I agree that we are at a very early stage of RDS adoption and we tend to have varied view points.  But let us look at it from a different perspective.  When we say there is no blueprint, I agree it is an over exaggeration because even in RDS approach there is a requirements gathering phase which is not called as blueprint.  But what it does is that, the components that have been chosen as part of RDS are those which require little master data as well as those processes which are pretty standard across most industries.  Thus it does not have a much elaborate business process blueprint. Moreover there are a lot of accelerators like predefined test cases etc which would enable it to be implemented in a rapid way. 

            I would see it as a demo version showing the capabilities which would enable to customers to jump start with the component adoption.   I am just taking an example of example of Treasury RDS wherein it is aimed at customers who are currently managing their operations in a lets say excel environment and who do not have a standardised process/approach.  Now instead of fully going ahead with a SAP treasury solution which they would certainly be skeptical about as well as turn out costly, they can implement Treasury RDS which will be done in quickly as well as enable them to have a feel and move in to a more standarised environment and adopt other components which would require intense blueprinting in normal methodology.  Instead of having nothing, it would enable them to start of adoption which I see as a good method.  The anomaly I look at is instead of SAP coming up with a new version of ERP it comes up with enhancement packs with little features in every pack thus enabling a little bit easier adoption.

            There are projects inside treasury which already follows modular approach or an agile methodology.  In RDS, it is just that the first phase is pretty standard. Also the customer pretty well knows well in advance what he is going to get and how his system looks like for the price he pays. The RDS approach might not be acceptable for everyone as of now because it is at a nascent stage but only time can tell whether this works out.


      • Ravi,
        you do bring up a good point, in that about being able to test the waters with RDS. That apart the RDS approach also is focussed on areas that are not Master Data Intensive, as those are the areas that need a extensive “Blue printing” and will consume a lot of time and resources.
    • Nathan,
      Your views and skepticism is understandable as this is a new approach, and a shift in the normal. With every change, there will be new learning, so will be the case with the RDS approach.

      There will be a slow and steady acceptance, as this will make it a base or startpoint for customers to consider investing further into the product at large.

      A very good example for adoption, is the RDS package for Treasury and Risk Management[TRM]. There are a lot of customers who don’t want a huge investment to get started on TRM, and will find this as a great reason get started with.

      In terms of the money spent by  the customer, these packages a fraction of a typical implementation, because of the reduced scope.