Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

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.

9 Comments