This chapter is from the book
This chapter is from the book
This chapter is from the book
Capturing Your mySAP Solution Vision
As you work through all the different system landscape characteristics, considerations, and options, it is necessary to document why a particular approach or product was selected, and how it impacts the vision of the project. This documentation eventually finds its way into a Knowledge Repository, which is simply a documentation vehicle where assumptions, constraints, and so on are all maintained. This information serves as a set of boundary conditions and assumptions, useful later as you eventually engage various solution stack partners in fashioning your SAP solution, as you see in Figure 3.7.
)
Figure
3.7 The Knowledge Repository will eventually provide input into either an
RFI process or in answering SAP sizing questionnaires provided by various SAP
Solution Stack vendors.
In this way, whether you elect to publish a Request for Information (RFI) or complete a number of SAP Sizing Questionnaires, all of your hard data and related explanatory reasons for implementing each mySAP component in a particular way will be at your fingertips. The ability to share all this data consistently with all the prospective hardware and software vendors is important—doing so enables a much better apples-to-apples comparison between different vendors' solution approaches later on, as you will see in Chapter 7. Further, as new information comes to light, or questions are posed by these prospective vendors, the Knowledge Repository will naturally lend itself to collecting and managing this incremental data of evolving constraints, assumptions, requirements, needs, and so on.
Leveraging SAP Sizing Questionnaires
Although the SAP Sizing Questionnaire is covered in detail in Chapter 7 and elsewhere, a quick discussion is in order here as it pertains to vision. Each vendor's SAP Sizing "Q" can potentially bring to light different areas of concern that you may not have yet considered. Microsoft's SAP Sizing Q is focused on their products and capabilities, HP's on their products and capabilities, and so on. As each organization's SAP Competency Center updates and republishes its respective Sizing Q, it tends to promote new high-availability, performance, manageability, and similar offerings. Thus, the Sizing Q in and of itself can prove valuable in terms of educating prospective SAP customers. This may in turn help you to fill in gaps in your vision, or facilitate getting you better acquainted with IT and business drivers that otherwise might not be identified until much later in the implementation.
Developing a Request for Information
Rather than completing a whole lot of different SAP Sizing Qs, and going through everything that such an approach would entail after the fact, many companies choose instead to author and publish a Request for Information (RFI). I still promote the idea of going through various SAP Sizing Questionnaires in the name of education, of course, but using an RFI approach can be a much cleaner method for moving a project along.
A good RFI takes time to develop, though—a lot of time, usually. I have included a sample RFI (and related appendixes) on the Planning CD, not only to have something to walk through here, but also for you to use as a template of sorts if need be. Keep in mind that my 20-page sample RFI is quite short compared to what you might need to publish, though. My RFI addresses only two products, R/3 and APO, and contains very little in the way of legal terms and conditions. Your RFP could very well exceed 100 pages if you choose to implement a number of mySAP components or if you employ an ambitious legal department.
An RFI should include or take into account the following:
General information, such as your company name and contact information, background data, and why the RFI is being published.
Instructions to each potential RFI respondent as to how to complete the RFI. This includes how to address questions, details on the proposal process, confidentiality details, any disclaimers, and other administrative details.
Terms and conditions, including the scope of the project, payment terms, minimum integration requirements related to existing/legacy systems, and so on.
Requirements that must be met by the respondent, including any vendor and account management information you want to capture, the need for other SAP References, details surrounding the pricing model (including lease versus financing discussions), how to factor in maintenance windows or other planned downtime windows required of the proposed solution, hardware quotes, requested professional services quotes (for installation, migration of data, training, and so on), and any other information that may help you make a decision (such as each respondent's relationship with SAP, or the various database vendors, or a particular disk subsystem vendor, and so on).
In addition to covering the basics, an RFI normally contains or references various appendixes, too, which are designed to either share supplemental information or to enforce a certain type of formatted response. Let's walk through the seven appendixes I've included on the Planning CD:
Existing Equipment Matrix—Documents what is in place today that must either be replaced by the new system(s) discussed in the RFI, or integrated with these same systems. This can also include a breakdown of existing SAP instances, or other enterprise application installations, that are currently productive. And if a current disk subsystem solution is already in place and expected to be leveraged by the respondent, details must be provided here as well.
Software to be Implemented—Here, the Solution Stack as you imagine it at this point is shared, including expected versions of each mySAP component, database systems, operating system releases, enterprise management packages, and so on.
Implementation Timetable—Represents an organization's hard requirements or possibly just a "best guess" as to when the new mySAP solution needs to be implemented.
Reference Form—Applicable to absolutely all RFI respondents, though most often focused on potential hardware, software, and implementation partners.
Cost Submission Worksheet—Consists of a standardized worksheet that forces an RFI respondent to price the project your way. This allows you to perform true apples-to-apples comparisons after all RFIs have been turned in.
Staffing Matrix—Encourages each RFI respondent to give thought to staffing in terms of pre-engagement, during the engagement, and post-Go-Live.
Sample Agreement with Terms and Conditions—Allows everyone responding to the RFI to understand up front what kind of legal constraints and financial commitments are expected.
Not all of these appendixes absolutely must be published with your RFI. In my experience, however, the kind of information provided in these seven appendixes is exactly what is needed by a respondent to either craft an SAP solution that really meets your needs, or to provide you with enough data to make an intelligent decision as to whether a vendor has what it takes to be your partner.
In Chapter 7, we will go through the remainder of the RFI process in detail, including how to compare and evaluate RFI responses, how to create a short list of RFI respondent candidates, approaches to making your final decisions, and more.
Revisiting the SAP Infrastructure Implementation Budget
With the information gleaned from refining our solution vision and building the basis for an RFI, we should be in a pretty good position to review our SAP Infrastructure Implementation Budget (SIPP) again. The SIPP needs to be updated to reflect new cost models, new business requirement-driven technology drivers, the need for incremental or other skillsets, and any other information that in effect changes our budget.
Based on these new budget numbers—one-time implementation costs as well as recurring license, administrative, operations, and similar costs—you should be in a position to truly consider outsourcing as a viable alternative to hosting everything internally. This is discussed next.