Engaging the SAP Solution Stack Vendors : Selecting Your SAP Solution Stack Partners, Executing the SAP Infrastructure Planning Sessions

9/26/2012 1:32:02 AM

Selecting Your SAP Solution Stack Partners

The goal at this stage in the sizing process is to now perform a thorough “Side-by-Side Sizing Comparison” between the various SAP solution vendors that have made the grade thus far, to ultimately select the best SAP Solution Stack partners for your particular mySAP.com implementation. This final evaluation involves the following:

  • A detailed sizing review

  • Verification that each vendor’s proposed SAP solutions are indeed supported by SAP AG

  • Verification that you will not be the first customer to do something “new” (unless that is part of a vendor’s value proposition and is consistent with your company’s technology perspective)

  • Discussions with vendor-provided SAP Production references

  • A review of your TCO numbers

I cover each of these key concerns next.

Pulling Out “New and Different” Sizing Data

With your Sizing Evaluation Team reconvened, the work of reviewing each vendor’s latest iteration at sizing an SAP system capable of meeting your business needs is necessary. Your first order of business is to be on the lookout for “extras” that you did not request. It is generally in the best interests of each vendor not to include these extras, as they tend to inflate the vendor’s solution cost. Things like ITS servers, or a SAN rather than a less-capable and less-expensive traditional direct-attached storage system, and even extras like enterprise management consoles and domain controllers need to be pulled out of sizings. In the end, each vendor’s sizing should be similar enough to facilitate a true apples-to-apples sizing comparison.

Of course, I have seen cases where a customer failed to completely understand the technical requirements of a requested solution, and therefore failed to request required components or failed to understand that an “extra” was indeed no extra at all, but more like a minimum requirement. In these cases, it’s critical to verify that the addition is indeed required, and then to share the new requirement with the other vendors so that they can update their own mySAP sizings. You also need to be sure to give extra points, so to speak, to the vendor who identified the shortcoming; this speaks well of their SAP Competency Center, and needs to be duly noted.

Verify Support for Architected Solutions

More than a few times I have seen an SAP technology partner recommend a solution component not actually certified or supported by SAP. Further, I have seen ambitious hardware partner account teams recommend SAP configurations not even supported by their own SAP Competency Centers. It happens. Technology changes quickly, but certification processes take time. Be sure to go through each proposed solution stack with a fine-toothed comb, taking care to review all recommended hardware and software components. If you have doubts or know that a particular piece of technology is quite new, don’t be afraid to check with SAP AG directly; leverage your SAP account team or SAP project manager. And be sure to work with each vendor’s SAP Competency Center to ensure that they, too, support the proposed mySAP solution—hopefully, they drafted the sizing for you in the first place, but this is not always the case. In the end, the time spent verifying the integrity and supportability of your stack is time well spent, as it not only helps weed out troublesome or ill-prepared vendors, but also helps you avoid nightmarish post-Go-Live support issues.

Verifying Your Risk Level

Even though a particular solution or approach may be supported by SAP AG and its SAP technology partners, someone has to be first—one company somewhere in the world will be the first to implement a new technology or embrace a new implementation methodology in their mySAP project. With this dubious honor comes risk, of course, followed closely by potential reward. For example, many technology companies offer significant discounts to their customers “brave” enough to bet their business on new technology solutions and approaches. My biggest concern here is simply in regard to credibility. Ask to see previously used implementation plans or project schedules. Seek templates, vendor-published white papers and best practices, and other evidence of experience. Work with the vendor’s Competency Center to gain a sense of their feelings towards the risk versus reward equation. Finally, prepare to spend time with the vendor’s reference accounts, too, discussed in detail next.

Working with SAP Production References

Serious SAP Solution Stack vendors maintain a list of reference accounts that they can use to reinforce their credibility with potential customers. Your goal in speaking with a reference account is to validate the following:

  • Your proposed solution stack is out there in the real world, running a production SAP solution.

  • Their implementation and configuration experiences were in line with your own expectations, and what you have been told by your potential SAP sizing partner.

  • The system actually performs well.

  • Planned and unplanned downtime numbers are no surprise, or are explainable.

  • Ongoing operations and support are consistent with your expectations, too.

This is a good way of checking on a vendor’s general past performance as well. If it’s possible, I especially recommend meeting with a reference face-to-face and spending time with a few members of their technical team, where you can often get unofficial or “off the record” information in addition to the usual data.

Revising Your TCO Analyses

Given everything that you have learned over the last few weeks and months regarding SAP sizing, it’s safe to say that something along the way probably changed. Perhaps your original goal of a monolithic big-box solution fell apart. Or maybe your best-of-breed strategy began to look too difficult to support long-term. Whatever the reason, I am confident that at this point in your SAP project, you need to revisit the topic of Total Cost of Ownership  and revise your own costing numbers. New numbers may well change your plans, after all. Only with new TCO numbers in hand can you truly be equipped to take the sizing process to the next level, and assemble the SAP partners and products necessary to solve your unique business problems.

Additionally, after the final round of SAP Solution Stack vendor reviews is pending, pricing is usually revisited as well. During this time, it’s business-as-usual for vendors to take a fine-toothed comb to their overall solution pricing. Even a few percentage points can add up to big savings in projects ranging from hundreds of thousands to many millions of dollars. It is also common for you to structure a holdback or price/performance guarantee at this stage in the sizing process, too. In this way, your solution partners will continue to be motivated to perform to the best of their ability (and rapidly address inevitable integration, performance or service issues) all the way until the day of Go-Live and beyond.

Finally, understanding hardware acquisition costs versus ongoing operational and management/support costs for each potential solution needs to be revisited. Why? Because the grass may indeed be greener one way or the other. That is, over a three year life cycle, my own analysis has shown that Wintel-based mySAP solutions generally provide a better return on investment in most cases, for most customers. But I have also seen what happens when business requirements change overnight, or when an initially straightforward mySAP implementation grows to include many components and a hundred servers. In the end, my colleagues who talk of “pay me now or pay me later” acquisition versus management costing philosophies have a valid point in these cases. So I stress that you have this last opportunity to work through the numbers again before making a final decision—treat this opportunity to measure your end-to-end total cost of ownership seriously, and take advantage of it.

Selecting Your Core SAP Solution Stack Partners

With final pricing, apples-to-apples solution comparisons, and a host of other solution and partner-relevant data collected and analyzed, you can now work towards selecting your core SAP Solution Stack partners with confidence. This is often achieved by holding onsite vendor presentations, where any final questions can be answered and each vendor has an opportunity to present their overall value and solution proposition.

However, keep in mind that there is no single best way to assemble your final SAP Solution Stack. That is, in many cases I have seen an SAP customer select their products first—the various solution stack components necessary to deliver on their mySAP vision—and then select vendors. But in other cases, I have seen customers select enterprise-savvy SAP technology and consulting partners first, only later to fine-tune the actual combination of hardware, operating system, database, and even mySAP Business Suite components necessary to achieve their business vision. Either approach can prove successful, though you place a lot more faith in your technology and consulting partners in the latter approach—as you would expect, if they are truly strategic partners.

Evaluating Specialized Solution Stack Vendors

With your core solution stack products and partners selected, you are in a good position to begin filling in any “holes” left in your solution architecture. These holes may be the result of special high-availability requirements, disaster recovery requirements, the need to support special types of system accessibility, and so on. Thus, specialized or “niche” SAP Solution Stack vendors like disk subsystem manufacturers, makers of Internet-facilitating or load-balancing gear, test-tool vendors, enterprise management and other specialty software vendors can be brought in after your core SAP Solution Stack partners are identified.

The key to assembling a smoothly working solution from multiple vendors, rather than one or a few, is to first of all limit the players—if similar solutions are available from two different vendors, lean towards leveraging the vendor with whom you already use in your SAP or other enterprise environment. Next, in cases where different vendors are brought in, plan in advance how support issues will be addressed. In other words, you will need to iron out all of the details regarding how support is handled and how inter-vendor problems will be approached and solved before you ever arrive at a problem. SAP AG models the best support approach I’ve ever seen by way of their PartnerPort facility in Waldorf—here, many vendors work side by side with SAP AG and to some extent each other. Outside of PartnerPort, the best SAP technology partners also host Joint Escalation Centers, support relationships, and similar support mechanisms between various hardware, software, and other vendors. I suggest that you work to identify exactly with whom your core SAP Solution Stack partners have their best relationships, and lean towards taking advantage of these communication and escalation bridges whenever possible.

Executing the SAP Infrastructure Planning Sessions

Now that your primary and probably most of your specialized solution partners have been selected, you need to commence the post-sizing implementation planning and scheduling sessions. In my experience, all of your solution partners should be engaged in the initial kick-off meeting, subsequent sessions of which actually span a number of days. This includes your hardware partners, OS and database (software) partners, your SAP project manager, and any other project managers already identified. Further, the data center manager and any key technical resources should also be present at the kick-off meeting.

Initiating the SAP infrastructure implementation represents a critical milestone in your SAP project plan, and is indicated as so in the SAP Implementation Project Plan (SIPP) found on the Planning CD. As such, there are many tasks and related milestones of a smaller magnitude that need to be identified, discussed, assigned, and managed.

Day One

Day One of the infrastructure planning sessions revolves around introductions of key personnel, review of the scope of work to be accomplished, review of the key hardware and software vendor’s products and responsibilities, and reiteration of how the infrastructure planning sessions fit into the SAP implementation big picture. In the past, I have adopted an agenda for Day One that looks like the following:

  • Introductions—Key personnel from each solution stack partner, SAP, and the client’s project team are introduced. Contact information is shared, as is a “job description” for each organization and for each person assigned to the project.

  • Vision and Definition—The reason for implementing a mySAP solution is quickly reviewed, followed by a high-level review of the scope of work to be accomplished by the assembled team. Like the pieces of a puzzle, each partner is made aware of how their own contributions augment every other partner’s contributions, in the end making the project possible.

  • Project Sponsorship and Accountability—The role of each partner and the importance of each role are discussed. The term project sponsor is used loosely here, as it refers to the individual person from each partner organization tasked with responsibility for completing their piece of the overall SAP project. Normally, the client has long ago identified what they expect from each partner. At this meeting, though, the partner comes prepared to put forth the name of their project sponsor—a high-level single point of accountability representing the partner’s interests in the SAP project.

  • Project Management—Each partner must also come prepared to introduce their incarnation of a project manager, another loosely used term that simply refers to the single person charged with completing tasks relevant to their role in the project. In my experience, it’s best to clarify these roles as much as possible, especially with regard to expectations. The skillsets and qualifications of each project manager are reviewed, too, as are the number of hours expected to be consumed in project-management-related activities.

  • Project Structure—Here, the project reporting hierarchy is identified, discussed, and usually revised. That is, the structure of the project’s key players, in terms of who reports to who and how issues are escalated, is covered. In large projects, it’s common to publish a project organization chart along with a scope statement. Status reporting, the use and timing of meetings, and other control and communications processes are ironed out as well. Finally, a schedule for regularly updating the master SAP Project Plan should be put in place.

  • Key Milestones—As they are currently understood, key milestones are identified and discussed. These are subject to change in the next two days of meetings, but discussing them at a high level now helps to prepare everyone for the project in general, and the next day in particular.

  • Quality Management—Processes for continuous improvement need to be developed over the next few days and embraced by the team. These processes need to be designed in, rather than “inspected” in. For instance, the use of workflow diagrams, recipes and checklists, and Pareto charts (a bar chart format useful in identifying tasks that fall into the 20/80 rule, where 80% of a project’s issues are related to 20% of the tasks or resources) represent quality tools. They promote feedback and continuous updating of documentation, lending themselves to fine-tuning simply by virtue of their use, rather than something that is performed once and never used again.

  • Project Administration—How to address time and expense reporting, billing/invoicing, change control, and other administrative functions conclude Day One. This might also include any contract administration that remains to be addressed, including updating contracts to reflect delivery and payment schedules, pricing, discounts, performance bonds, and more.

As you can see, this first session addresses the big picture. In doing so, it sets the stage for the next two days, preparing you to turn your attention next to project timelines with regard to the actual technology solutions and system landscapes being implemented.

The Second Day

Day Two commences with a quick synopsis of the previous day, and then the floor is turned over to the client or SAP project manager who leads discussions detailing the following points:

  • Go-Live Date—By establishing the desired Go-Live date, an experienced SAP project management team can “work backward” to identify when critical production milestones must be accomplished and therefore when tasks supporting these milestones must commence. This is a good way of constructing or validating a high-level project plan, too, as it typically contains no slack time (free time between tasks) and therefore clearly identifies the project’s critical path (project milestones spaced in time such that they represent the shortest possible number of days in which a project can be completed). This by no means results in a truly usable project plan, however! Rather, it serves as a high-level template or perhaps simply as a tool for developing the actual plan.

  • Critical SAP System Landscape Milestones—After production’s Go-Live date is nailed down, you can work backward to determine when other SAP system landscape systems need to be in place, too. Thus, the need and timing for implementing production, Test/QA, training, development, a technical sandbox, and so on can all be determined based on your production Go-Live and how much lead time needs to be given to tasks related to other activities.

  • Key Risks—Identifying risks to the project plan is an excellent method of promoting and then refining timeline discussions. Any risk to successfully completing a particular milestone related to each partner’s set of responsibilities needs to be covered, and addressed or mitigated. For key risks, a contingency plan needs to be developed as well.

  • Landscape Assistance—As each component within the system landscape is discussed, it naturally promotes the discussion of how much assistance the client thinks they will need in achieving SAP system landscape-related milestones. For example, my team often gets involved with technical sandbox and development implementations, but less so with other environments (outside of production or at least a review of the production environment prior to Go-Live). Why? Because after we train our clients in how to plan for and install a mySAP component, and leave them with a detailed recipe or checklist for repeating the installation, they usually want to not only prove that the recipe works, but also to train their own folks and save budget money by doing it themselves.

  • Identify Realistic Timelines—With the critical path and key milestones identified, and an idea as to which partners will be engaged to support achieving these milestones, it is desirable to pencil in hard timelines for Go-Live of each mySAP component to be implemented as well as each landscape system. Add as much slack time as possible, and spread it out among the various tasks (I like to see each solution stack partner allotted some amount of slack time). Working backward with these realistic figures should give you an idea as to when hardware actually needs to hit the ground, and therefore when the data center needs to be prepared. Everything else going forward can then be filled in pretty easily on the third day.

  • Knowledge Transfer—Before leaving for the day, work to clearly understand both when and how much knowledge transfer needs to take place between the various technology partners and the client. Assign names of responsible parties, assign and document the actual tasks associated with this knowledge transfer, and document the method by which the knowledge will be transferred; hands-on training, written process/procedure documentation, use of high-level or detailed checklists, creation of Web-accessible content, and so on. In the consulting world, we call these deliverables, as they represent something tangible that my colleagues and I deliver to our SAP clients prior to concluding our part of a project.

The second day of planning sessions can run pretty long. I recommend that each partner and the client come prepared with their individual project plans or detailed timelines. In this way, the master plan can be more easily updated, and valuable time is not wasted trying to recall how long certain tasks take to complete, or how critical dependencies relate between tasks. As an aside, it should go without saying that if your partner cannot produce at least a template project plan based on previous SAP implementations, you should be very nervous—if you are paying for specific expertise in a particular mySAP component of supporting technology, you deserve to benefit from other project’s efforts. A previously and successfully used project plan is proof of this experience, for example, and equates to at least a minimum level of credibility in my eyes.

On the Third Day

Whereas the second day of planning sessions focused on the timelines and the technology being implemented, this final day concludes the planning sessions by assigning names and responsibilities to project plan tasks. Thus, by the end of the day, everyone leaving the sessions will understand not only their own roles, but the roles of the entire team and how everyone’s tasks relate to the project as a whole. And in doing so, you will conclude the sizing process, taking it from inception through planning the deployment of your physical SAP system landscape. Tasks to address on the third day include

  • Put names to Solution Stack technical roles—Each partner needs to be prepared to commit the technical resources necessary to achieve their unique solution-stack-related milestones. This will include SAP Basis/Web AS technical leads, Server Hardware Buildout specialists, SAN/Disk Hardware specialists, OS Installation/Tuning specialists, DBA/Disk Subsystem specialists, mySAP Component SMEs, ITS specialists, and Front-End Client specialists. A discussion of the skillsets required to perform the work associated with each partner’s tasks, and how their resource fulfills these requirements in terms of experience and education, is standard.

  • Put names to other technical roles—Each partner must also be prepared to identify their resources satisfying other technical roles, like High-Availability/Failover specialists, Stress-Test/Load-Test experts, Functional Testing specialists, SAP Solution Tuning specialists for their particular contributions to the SAP Solution Stack, and so on.

  • Identify administrative key roles—More than just technology folks need to be identified. Each partner’s project administrator or coordinator, account manager, documentation specialist, and other support and administrative contacts need to be documented and shared with the team. In small engagements, it’s common to see these people wearing multiple hats, perhaps even sharing technical responsibilities with administrative ones.

  • Identify client contacts—Although this varies, I tend to see most of the following positions held strictly by my clients. Regardless, it’s important to understand who is actually responsible for the following areas that fundamentally support or underpin the SAP project: environmental/datacenter manager and specialist, network infrastructure specialist, data and application migration specialist, training coordinator, operations manager, and help desk manager.

  • Refine timelines—With the details surrounding the technical implementation understood now, it should be possible to refine the timelines associated with each task such that the hours and days expected to complete each specific task are documented. This is called a Work Breakdown Structure (WBS) in project management circles, as it breaks down a project into smaller elements and then ultimately into work packages, which are simply tasks that can be accomplished in 80 hours or less.

  • Refine and validate budgets—Although all partners can now provide their final costing numbers, not everyone needs to be involved with reviewing the budget numbers. Normally, this kind of activity is reserved instead for project management representatives tasked with managing the project’s financials. This exercise also helps validate how close each partner came to estimating their costs, based on the imperfect information provided to them during the sizing process.

Students of project management have probably noticed that the three-day planning sessions covered many core project management fundamentals. The sizing process in and of itself represents a large subproject of your overall SAP implementation. So it only makes sense that managing scope, timelines, cost, quality, risk, procurement, human resources, and communications needs to be given the same level of attention here as at the higher overall SAP implementation project level.

Tools and Techniques

I have included a slew of sizing-related documents on the Planning CD, some of which facilitate number crunching, whereas others simply provide for side-by-side sizing comparisons. Miscellaneous SAP/hardware questionnaires have been included, as have sample tools and sizing documents in Word or Excel format. I included a special document entitled “LINK - Quicksizer SAP Solution Brief and Other mySAP Sizing Links,” too, which points you to a variety of Web-based publicly accessible SAP sizing-related documents and resources.

  •  Visual Studio Team System 2008 : Command Line (part 2)
  •  Visual Studio Team System 2008 : Command Line (part 1)
  •  System Center Configuration Manager 2007 : Configuration Manager Network Communications (part 4) - Site-to-Site Communications - Tuning Status Message Replication
  •  System Center Configuration Manager 2007 : Configuration Manager Network Communications (part 3) - Site-to-Site Communications - Configuring Senders, Configuring Sender Addresses
  •  System Center Configuration Manager 2007 : Configuration Manager Network Communications (part 2) - Client-to-Server Communications
  •  System Center Configuration Manager 2007 : Configuration Manager Network Communications (part 1) - Intrasite Server Communications
  •  External Drive Western Digital My Book Thunderbolt Duo
  •  IP Camera Eyespy247 EXT+ - Cloud-Based Home And Office Video-Monitoring System
  •  Set-Top Box Philips HMP2000
  •  A Partnership Fizzles
    Most View
    HTC Desire X - Last Applause For An Ex-Flagship Product (Part 1)
    How To Choose A Printer (Part 2)
    Creating Custom Workflows with SharePoint Designer 2010 (part 3) - Testing Our Workflow
    Viewpoint Of Getting Out And Playing
    Scan 3XS Graphite LG5 - Netbook-Sized Gaming Laptop
    Multifunction Printer Group Test (Part 2) : Epson Stylus Photo PX730WD, HP Photosmart 5520 e-ALL-in-ONE
    Apple MacBook Pro Retina 13in Vs Samsung Ativ Book9 Plus
    Sony Vaio T11 Hands On - Now You’re Talking About ‘Ultranets’
    BMW 1 Series M Coupé - Global Hyper Colour (Part 2)
    Installing or Upgrading Windows 8 : Customizing the Boot Configuration Data (part 1) - Using Startup and Recovery to Modify the BCD
    Top 10
    Sharepoint 2013 : List and library essentials - Sorting and filtering lists
    Sharepoint 2013 : List and library essentials - Using list and column validation rules
    Sharepoint 2013 : List and library essentials - Editing and deleting list columns
    Sharepoint 2013 : List and library essentials - Creating list columns
    Sharepoint 2013 : List and library essentials - Adding and editing list items
    The Porsche 911 Targa – Wind Blast From The Past
    The Mercedes-Benz E-Class – The New Face Of Mid-Size Luxury
    BMW F10 M5 - Gentleman’s Express (Part 3)
    BMW F10 M5 - Gentleman’s Express (Part 2)
    BMW F10 M5 - Gentleman’s Express (Part 1)