What's on the 'SAP Menu'?
In the heat of the summer, there is nothing like fresh fruit and vegetables. Since it is dinner time, first and foremost on my mind is food - and with this preoccupation with food on both my mind and stomach, it occurred to me that this is a great way to simply explain the concept of SAP Rapid Deployment Solutions (RDS).
SAP RDS is like the well-crafted menu of the restaurant I plan to visit tonight; I know there is a salad that will meet all my requirements; a healthy, filling (and most likely spicy) meal. But it is also quite clear to me that modifications are a la carte and if I want extra cheese, I can have it for a few extra cents. I know what to expect, I know how long I’ll have to wait for it, and I know how much the check will be. (I like known quantities, especially when I have limited time, am on a budget, and am quite hungry.) RDS touts pre-determined business outcomes, just as a well-crafted menu has something for everyone.
What is the customer having for lunch?
At SAP, I am an Associate Project Manager in the US East Region. Having been with the company for a few years, I had heard a great deal about our Rapid Deployment Solutions, but had not yet fully grasped how these projects are approached. Recently, I was part of a project team from whom I learned a heaping portion about the RDS approach.
My most recent customer engagement was with a customer who was comparable to a hungry patron with a short lunch break. This customer; a global industrial machinery manufacturer, had a need to apply a solution in a very short period of time in order to get an existing factory which was dedicated to a new product line more effective and back on track. Not only did they want to have the solution quickly in place, but they also wanted to apply this to get a second and brand new site operational as soon as possible to meet the demand for this new product. Our customer decided on the rapid-deployment approach; they took a look at the ‘SAP menu’ and picked an approach that would satisfy them.
But a good restaurant server needs to ensure the diner’s needs are met; and like a good server, SAP still needs to check that the pre-configured solution will meet the customer’s objectives. For this customer, we performed two rounds of workshops to ensure all requirements and objectives would be met by the RDS solution; that the ‘salad’ they selected had all of the necessary elements to satisfy them. Our team guided them through the ‘menu’ and determined that they had ordered the correct ‘meal’, and then supplemented with the few ‘extra toppings’ the customer needed. This is how the RDS approach differs from the traditional blueprinting approach.
For example, If you were very hungry and in a hurry (like our customer), you would not want your server (SAP) to ask you, “Please describe all of the ingredients in your ideal salad…” and then come back with something the chef makes from your list of ingredients and directions on how to make it. In this situation, a creative and iterative approach is not appropriate… you’d never really know what your dinner will taste or look like in the end. Assembling it piece by piece would take up your valuable time (you may pass out in your bread plate out of hunger before it arrives!)
Cooking from scratch... traditional blueprinting
In the traditional blueprinting approach, SAP sets up a set of workshops on specific topics and then asks about customer requirements in that area and then explain how it would fit with standard SAP, just like customizing your plate of greens. Understandably, there is a time and place for this personalized approach, but imagine what it would take to eat every meal at a fancy five course restaurant where everything was cooked from scratch. Additionally, with a from scratch approach, there are so many points of failure that don’t pop up until later, whereas with RDS you are starting out with a menu of best practices, known quantities, and business outcomes. RDS solutions are built by teams that know the best recipes and that cover the common requirements in that
particular area – RDS best practices are developed from more than 200,000 SAP customer implementations; our ‘chefs’ have the experience of serving thousands of customers.
In our case, the SAP ERP for Manufacturing solution would typically have taken one year to implement, was handed to my customer in about 4 months. This experience taught me that there are some critical ingredients for a successful RDS implementation:
- Qualification:
- RDS must be qualified as the correct approach for the customer’s timeline, budget, and strategy. The customer and SAP must work together to determine that the set ‘menu’ will have what the customer needs.
- Leadership:
- The appointed leadership (from both SAP and customer) must have strong and clear vision about the strategy and outcomes.
- Partnership:
- SAP resources are well-versed and trained in the limitations & strengths of the solution, as well as common pitfalls and /or what has worked for other customers.
- Finally, it is critical that the customer has assigned resources / team members who can make fast and informed decisions particularly when it comes to addressing gaps in regards to the business process. This is especially important for decisions for aspects of the project that have long lead times that could affect the end date of the project.
- Communication:
- Focused and frequent communication is the element that harmonizes the three prior ingredients. Not only is communication important in order to achieve the objectives with the accelerated pace, but also because RDS methodology implies the combination of local and virtual teams from different locations, time zones, and cultures.
For more information on our RDS methodology, check out this blog: What is the SAP Rapid Deployment Implementation Methodology? Does it work?
Bon Appétit!
Click here for more info about SAP Rapid Deployment Solutions.
