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:
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |