Skip to Content

To Blueprint or not to Blueprint – that is the question.

I have recently been working with part of SAP’s RDS development team and they have been sharing some of their secrets. On first impression I am very impressed. A project that may normally take 3 months could be performed in less than half of that time which is amazing. I was so taken aback by this I decided to compare the various phases to see how they save so much time. Please note the scope for an RDS solution will be much lighter and simplistic compared to a standard implementation.


One of the first differences I spotted was the lack of a Blueprint within the RDS service. The rationale behind this is the RDS package the scope is always exactly the same and therefore there is no need for a Blueprint. To contextualise this we are not looking at a RDS to implement an ERP system from scratch but providing new functionality to a mature ERP system. Based on a project that takes 3 months to implement – roughly 25% of the implementation duration would be spent on producing the Blueprint document and signing it off.


I remember fondly working on my first full ERP implementation some years back now and we had 6 months to write a Blueprint. It was a massive document that started life as a modular solution and then the integration consultant went through the document to ensure no integration issues. To be honest the customer could not really add any value regarding the Blueprint and they had to wait until the testing phase to confirm if the solution was what they actually required. A customer cannot really validate a Blueprint document unless they have seen the proposed screens and processes to be utilised. It you don’t know how a system will actually work, how can you confidentially sign off a Blueprint?


On smaller implementations customers tend to believe a Blueprint provides some form of comfort and reduces their risk. They have been educated that a Blueprint is required to specify the scope of the solution and expect SI’s to provide a Blueprint. On a personal note I would suggest detailing a scoping document (a lighter version of a Blueprint) for smaller implementations (2 – 4 month implementations). However to inform a customer that their implementation would come without a Blueprint may be a step too far for some customers.


The RDS argument is simple. The scope is standard, the price is fixed and therefore the risk is reduced. The solution will be the same and you have the ability to enhance it if you wish to at an extra cost. The RDS solution will need to work (replace existing process), and it will work but the solution will be basic and may not meet all of the customer’s requirements or expectations. My concerns with the RDS solution is the scope cannot change based on the pricing structure and the advertised timeframes. Customers will be sold the dream that a project that would normally take 13 weeks can now be done in less than 6 weeks. However the solution proposed to be implemented in 6 weeks may not meet the business stakeholder’s requirements and the actual implementation time will grow. Normally when working on new functionality a process change would be required as well. This would therefore mean change management would be required. The change manager would be providing updates to say the project would be live in say 6 weeks, however the extra scope could move this to 8 weeks. In terms of how this is perceived within the business this could be seen as a failure as the project over ran and more than likely went over its budget. However in reality a project that would have normally taken 13 weeks being implemented in 8 weeks is, as far as I am concerned is a very positive message.



So what could customers do? Normally during the sales cycle a customer will provide a list of functionality or processes that they wish the system to perform. In theory the customer is defining the scope, not SAP or the Partner detailing the scope they plan to implement. The customer could provide their scoping requirement to the customer and ask SAP or the Partner to confirm that they can meet all of these requirements. This would even work for an RDS solution. SAP could detail what is available as standard within the RDS, and what would need to be added to the RDS. This is the true way to reduce the risk to the customer and to ensure correct implementation times are provided.


My message to the RDS team is simple. The sexy headlines of implementing CRM in X amount of time are great but the sales message needs to be clear around the scope. Customers should be told to expect to add some extra time to customise the solution to meet the true business requirements to make the project a true success. If a customer does not add any extra functionality then they will come in under the expected time, and if extra functionality is added the customer will gain true benefits from the solution. As my testing manager said – the RDS is like a bunch of grapes, but the customer wants a meal, and not many people will view a bunch of grapes as a satisfying meal.

You must be Logged on to comment or reply to a post.
  • Nice blog, Mark.

    I had previously mentioned my view on RDS here

    RDS is SAP’s version of what SIs have long done – go into projects with some prebuilt solutions, so that everything does not have to be done from scratch. Templates have been in use for at least the time I have been a consultant. And to date – I have never seen a client in 3 continents that said “lovely template – that is all I need”. No – it always needed extensions .

    Mark is completely right about positioning RDS – fixed price, fixed scope are all the same things people do without RDS too. It is only when scope increases to fit the actual needs of business that change orders will start coming, and everyone says project is delayed and over budget.

    What RDS does well is that the first iteration is extremely fast. From there on, it is like any other project. It does not reduce risk any better than other fixed price deals that are around today. Scope changes always will happen, and they will always come at a price.

    It is a different story that you can declare victory unilaterally after the vanilla flavor is done on time and on budget.

    • I agree other SI’s have accelerators but I dont believe they have invested in the technology and methodology that SAP have.

      The standard test scripts and training scripts whilst deemed to accelerate are pretty standard.

      The scope of the RDS is in fact the Blueprint and I think this might put off certain customers.

      If customers have their eyes wide open an account for some re-work then I believe it will be cheaper than a standard project – even when an SI has standard content.

      Proof is in the pudding and I will keep on with my RDS journey.

  • I’m still skeptical that this will ever get traction in the market. I still can’t think of any meaningful amount of functionality in ERP that could be rolled out this way.  It just sounds more like a Proof Of Concept because the scope is so tight…  not big or small, but tight in the sense that the boundaries are brick walls and can’t move an inch.  Of course, corporations have so many of their own nuances that implementing even a small piece of ERP requires a significant dialogue about their needs and the features of the solution.  You have to match those two sides up somehow, and voila, you have a blueprint.

    I really liked your commentary about the blueprint doc.— 
    “massive document… To be honest the customer could not really add any value regarding the Blueprint and they had to wait until the testing phase to confirm if the solution was what they actually required. A customer cannot really validate a Blueprint document unless they have seen the proposed screens and processes to be utilised. It you don’t know how a system will actually work, how can you confidentially sign off a Blueprint.” 

    The Blueprint process certainly isn’t perfect.  Customers get a 6″ document and an invoice for a few $million but they usually start Realization the next Monday.  Don’t they review them?  Most of the time, they don’t because they really can’t follow it to the extent that the consultants can.  I think some of the SIs intentionally incorporate as much SAP-based solutions into the blueprint as possible if only to make it harder for a new customer to validate.


    • I was very skeptical and so have forced my way into the RDS to get under the skin.

      I admit I am impressed. I can see the value and I can see that customers will not only buy them but will have great use case studies off the back of them.

      They will be called RDS implementations – but SAP or a Partner will need to enhance them slightly so the customer really is happy though.

      With regard to Blueprinting – I dont believe it is needed if both parties go in eyes wide opened. For a brand new ERP client – or even a re-implenent the Blueprint will be critical and it is up to the SI to ensure the customer knows what they are signed up to.

  • Guys, thanks for the informative post and comments.

    I have spoken at detailed length with multiple RDS customers to understand how RDS fits into their overall IT plan and also how IT integrates into their business at large.

    Although nothing is perfect, my strong impression is that experienced customers recognize the purpose and value of RDS and use it as such. However, it is also true that less experienced customers may not fully understand that RDS is a starting point to get up and running fast with core functionality.

    There is one point that bothers me about the RDS discussion, however. We know that implementations are too expensive and too often screwed up. So, please focus on how we can make it better. No solution is perfect, I think we need more discussion about ideas to improve implementations. Certainly, I do think RDS is an important step in the right direction.

    • I agree that an RDS for the right solution for the right customer will be a step in the right direction.

      The issue is selecting the correct RDS for the customer and setting the correct level of expectation to the customer.

      From what I can see very few customers will take an off the shelf RDS. However they will buy they and use SAP or other SI’s to enhance the solution – potentially after go live to meet their detailed requirements in a timeframe that normally would be unachievable.

  • Hi Mark,

    I went through 2 or 3 RDS scope in detail like TRM and HCM.  Though I do believe that RDS is a step in right direction, the partners/SAP have to convince the customer that RDS is only a base platform and a bare minimum. 

    It is like a starting point and have to be further fine tuned according to customer requirements.  But what I find as a positive for RDS is that, customers do see the actual working of the solution very quickly which makes them understand/realize what they want pretty quickly and easily so that the next phase of implementing customer specific requirements will have lesser risks. Basically the customer is much more informed on the solution when it comes to the second phase.


  • I don’t really understand beyond setting hardware/hosted environments why an accelerated solution should take more than four weeks especially for basic SFA CRM scenarios with a take it or leave it functionality.

    I especially question this when I know you can have one person configure a system from scratch and make UI changes without any accelerators in the SAP CRM in a week or less if you are worth your bill rate ;). 

    I would expect more for 8 weeks of prepackaged content.  The system is not that difficult to configure ;).

    Take care,


    • Hi Stephen,

      The great thing with RDS is that Partners can release their own versions.

      Therefore if they believe they can reduce time further then they can reduce the timeframe, effort and probably cost.

      I would be interested if you could share the 8 week content.

      Part of that I would guess would be to define the scope, build the solution, test it and then perform training.