This is a blog redux from 2008 during which time I was finalizing a large Order to Cash (O2C) and Finance transformation for a global manufacturer. While some of the topics and names (e.g. "SafeGuarding") have changed, a Solution Design Review (SDR) remains a very valuable offering for SAP customers to consider and I continue to have these discussions as a way to ensure SAP deployments are maintainable post-go live. - WDN
I’m fond of telling my clients that SAP is a vast, strategic technology platform whereby many business scenarios can be described in a variety of ways. This is important for SAP as it allows a certain “creative freedom” of the software to address unlimited business needs in the global marketplace.
There comes a time, however, where it is important for an organization to define the best way to articulate its business inside the SAP environment. This allows for an increase in maintanability once the system is implemented, reduction in overal total cost of ownership (TCO), and simplification of the architectural design.
One way to accomplish this is through a Solution Design Review (SDR) which SAP offers as a part of its Safeguarding® product offering. Safeguarding® was introduced in 2004 as a way for SAP to understand more clearly how their customers were using the software platform and to provide feedback to the customer. The net benefit to the customer, particularly in situations where the project is either internally realized or internally managed using contractor resources, is access to very senior and experienced SAP professionals (typically platinum consultants with multiple implementation experiences in a particular domain) on a time-bound, fixed-price exercise.
Not Consulting, Not a Service
Your SAP account executive will be the first to tell you that a SDR is not a substitute for consulting or integration services. It is part of a product offering (Safeguarding®) which can be available to purchase similar to Value Engineering®, software, or maintenance. While there may be SAP professionals front-and-center during SDR activities, similar to maintenance it is a fee-based product offering.
Generally an SDR provides three particular areas of benefit during review activities:
- A documented “snapshot” of the design of the system, regardless of its position in the ASAP methodology timeline.
- Business community and executive level involvement to confirm or re-confirm the business outcomes of using SAP in the execution of business operations.
- Alignment of technical and contractor resources in the design and realization of the system environment so everyone is “in the right seat, on the right bus.”
I recommend using SDR as a way to validate the business blueprint of a new system implementation or for a significant new set of capabilities to be added to an existing SAP environment. As one CIO commented to me, “given the amount of money we are about to spend on realization activities, the cost of completing an SDR is a rounding error.”
It also allows SAP as a software company to have a greater awareness of what business solutions and applications its customers are creating in the marketplace. It creates a greater dialogue, in some cases where dialogue may have been missing or strained between new or long-standing customer project and SAP account teams. SAP has a “vested interest” during this process, as it can provide documented comment on the risks and opportunities of a program moving forward after SDR activities are accomplished.
An Intensive Process – Not for Everyone
One of the characteristics of SDR that struck me was its similarity to quality assurance and risk audits. For small and mid-size businesses the use of SDR is questionable. Similar to quality audit processes, sometimes the commitment to the SDR process can be economically disadvantageous for a company to undertake as it has a noticeable impact to business resource availability. However for large implementations where dedicated or partly-dedicatd staff are already committed to the SAP program, an SDR can be easily scheduled. It is an intensive process divided into three activity sets:
- Pre-review. During pre-review activities, there is a kick-off workshop typically a full day, scheduled roughly 30 days in advance of the actual SDR. Prior to this workshop the SAP SDR lead will outline the specific areas, both in terms of SAP function and customer business scenario, that will be included in the review. During the kick-off workshop, the SAP SDR lead will review the business scenarios and functional areas, propose a basic framework for the review, and meet the relevant business and technical staff that will participate in review activities. The SAP SDR lead will also review pre-work the program team will need to complete prior to the actual review, and a list of documentation required prior to and during the review. The lead may also conduct specific interviews with key business and technical (customer and contractor) stakeholders prior to actual review activities.
- Review. The review can vary in length depending upon the nature of the solution considered, but generally allow for a full week (five business days) for the review. There can be multiple tracks of review activities, in one review recently the customer utilized a facilitative approach to have joint sessions of two operational solution reviews meet together in the morning and evening with breakout sessions specific to each operational solution review during the day. Be prepared to review all business scenarios, including to-be processes, and specific functional expressions of those buisness scenarios. Be prepared to “defend your position” when asked why the solution is to be expressed in a particular way in the SAP environment, and be prepared to hear of other ways based on the relevant expertise of the SAP SDR lead on how to accomplish program objectives. At times this can become consultative between SAP and the customer, but the extent of that consultation will be limited to ideas and recommended areas to pursue that will be highlighted in post-review activities.
- Post-review. At the conclusion of the review, the SAP SDR lead and any SAP team members will provide a findings presentation of the review. This findings presentation will generally provide overall comment and feedback on areas of maintainability and proficiency in the customer solution under review, with a summary as shown in . It will also provide an action set of areas where the SAP SDR lead may feel are critical to address moving forward, including specific risks that should be addressed moving forward in the SAP program. The final report typically will include these areas as well as areas to consider the future use of other SAP software capabilities that were not explicitly a part of the review.
From start to finish the SDR process can be completed within 30-60 days, so plan appropriately when to introduce and execute an SDR in the SAP program lifecycle.
Limitations and Expectations
Even for appropriately-sized programs, a SDR has its limitations and these limitations should be considered carefully before embarking on such a review. First, SAP will only be able to comment with conviction on the use of SAP software. If you are working in a heterogeneous environment with multiple applications running in multiple business operations or units, I recommend that you focus your expectations on how the SAP SDR team would best suggest you leverage the SAP software platform. Second, an SDR is not a panacea for correcting a bad design or restructuring a poor SAP program. While an SDR can, for example, call-out the non-standard use of standard SAP capabilities, the SAP SDR lead and team will not correct those deficiencies for you (remember, it’s not a substitution for consulting). In fact the review could call into question the appropriate use of the SAP environment, so conducting the review earlier in the ASAP methodology program lifecycle is better than later. Finally, an SDR is only as valuable as the information used during the activities. If a customer witholds information, excludes key business stakeholders, or otherwise does not leverage the process accordingly, the review will demonstrate less value. In these cases SAP SDR leads are pretty experienced and savvy, don’t be surprised if these shortcomings are actually noted in the final review presentation and report.
To Review or Not to Review
To restate my recommendation, an SDR is not for everyone. It is time-consuming, intensive, and rigorous. But it may be the insurance policy that an organization needs to commit to a significant undertaking, both from a stakeholder buy-in and from a technical quality assurance perspective. In an age where most SAP program fail due to non-technical reasons, this may be a good insurance policy indeed.
