Setting the Stage for a Successful Implementation

With the d preferably in parallel. These things—tasks, analysis, even marketing of the project internally—are covered in the next few pages.

Promoting Buy-in Throughout the Company

At this point, senior-level folks have certainly signed off on the project. However, other executives typically must be convinced that the business units are on the right track. This is where the Project Sponsor spends his time initially, gaining consensus within business areas, functions, and the various IT organizations that will ultimately contribute to supporting the project.

As one of a few central figures within the SAP project’s Steering Committee, and generally the person responsible for putting together the membership of the Steering Committee, the Project Sponsor’s role is key indeed.

I discuss the role of the Project Sponsor and makeup and functions of the Steering Committee in more detail later in this chapter. For our purposes here, though, the Steering Committee continues to build upon the momentum put in action by the Project Sponsor, gaining buy-in and “talking up” the project throughout the company. By working with the various business units to help them understand how important they will be to the project, and how much better the project will address their needs, excitement and buy-in around the project will continue to grow in these early days.

Finally, until a project-dedicated Project Manager representing the business organizations is identified, the Project Sponsor wears this hat, too. Thus, through these important roles, the Project Sponsor must

• Project confidence, presenting the SAP implementation with an air of competence in any forum. To this end, the Project Sponsor must be prepared to give a formal presentation at the drop of a hat, without the presentation appearing too “canned.”

• Be well-versed in the SAP project from Total Cost of Ownership and Return on Investment perspectives.

• Tailor language to his audience, be it the board room, shop floor, IT group, or functional organizations like Accounts Payable or the supply chain group.

• Be aware of the politics inherent to the various organizations involved. This includes determining who the informal decision makers are, as well as the ones granted this authority through organization charts.

• Be truthful and up-front about everything—both personal and professional credibility are on the line at all times. It’s impossible to have all the answers all of the time, especially in a complex enterprise planning project. Admitting “I’m not sure, but I’ll find out” makes a lot more sense than trying to dodge questions or skirt issues.

Nailing Down the Real Business Requirements

Although momentum is growing, a team of key business organizations should be working through the goals of the SAP project. I call this identifying the “must haves,” the “should haves,” the “nice to haves,” and the “blue sky stuff.”

• “Must haves” are core capabilities that can simply not be lived without, like the need to track and manage inventory and finished products, and produce accounting statements, and so on.

• “Should haves” might include the ability to run reports against an integrated information repository. “Should haves” can be worked around and lived without, but often provide the core foundation of value-adds to a solution.

• “Nice to haves,” or extras, might represent the key differentiators provided in certain business solutions, like the ability to access a solution using a standard Web browser. They do not represent requirements by any means, and often add more cost to a project than value.

• “Blue sky stuff” includes extras that would be really exciting to include, but simply cost too much, or are too complicated to implement, or represent other huge risks. The ability to securely make available your supply chain system to customers, suppliers, and vendors still represents “blue sky stuff” to many organizations, for example (even though it’s quite feasible from a technology perspective).

The same list of business benefits put together to get initial approval for pursuing the idea of implementing SAP will suffice as a starting point.

Mapping Business Requirements to Solution Characteristics

Using your list of business benefits as a solution foundation, the business and a few select IT professionals need to address the specific required characteristics of the solution, like the level of availability, performance, scalability, manageability, and so on that are desired.

Something I call the “Solution Characteristics Matrix” is often useful in ensuring not only that each characteristic is considered, but that all of the appropriate stakeholders have a say in how important they believe each characteristic is to the business. The matrix becomes documentation in and of itself, too, and will be referenced again and again throughout the project. For starters, I have included a sample matrix on the Planning CD, with the actual characteristics identified as follows:

Remember to gather input from every single business group that will ultimately be serviced by the project. By doing so, you’ll not only have a better understanding of the business needs driving the solution, but also gain valuable project buy-in through your endeavors, as previously discussed.

Determining Realistic Service Level Agreements

The term Service Level Agreements (SLAs) is by no means new or specific to SAP. As with any IT project, though, certain minimum requirements need to be communicated by the end-user community to the IT organization tasked with supporting the project. And this needs to be done fairly early in the project, as the technology base on the SAP project itself will be shaped to some extent by these minimum requirements. Why? Because these minimum requirements become the service levels against which the project will eventually be measured.

Service levels take a variety of shapes:

• Percentage of uptime, or availability

  For example, a system might need to be in place that will provide 99.9% availability throughout the year.

• Planned versus unplanned downtime

  This is usually expressed in hours per month, or percent achieved per year. A number of our medium-sized SAP customers plan on 4–8 hours of downtime per month, for example, to implement changes to Production or test failover and other high-availability processes. Database backups, database reorganizations, and the archiving of SAP business objects represent other common planned downtime events.

• Reactive service levels and related support contracts

  If the system suffers unplanned downtime, the business expects that the problem will be addressed in a certain time period, and resolved within a specific period of time as well. These metrics must be established up front, and then leveraged to draft service agreements with SAP Solution Stack hardware, software, and systems integration partners.

Work closely with the business groups to nail down SLAs, and then document these, as they will later need to be clearly understood by various SAP Solution Stack hardware and software vendors.

How to Estimate ROI Early in the Game

Entire volumes of books and complicated expensive software packages have been written with regard to estimating Return on Investment (ROI). In fact, Chapter 5 covers total cost of ownership and return on investment analysis for SAP in detail. What is important in the earliest stages of the SAP implementation project is “simply” comparing the total one-time expected implementation costs of the project to the in-place systems, and then factoring in recurring costs over something like a three-year time period.

It should be noted that an ROI or TCO analysis examines the following areas (and as shown in Figure 2.4), in terms of costs and expense:

• Processes

• People

• Technology

Ultimately, a number of sources may be leveraged to gather industry-standard costing data on the “future” solution, from excellent objective resources like Gartner and IDC, both well-known market research institutes. More challenging, though, can be collecting useful company-specific information when it comes to these areas.

Underneath this umbrella of processes, people, and technology lie budgetary/cost categories including the following:

• Acquisition (technology and people)

• Facilities

• Administration and overhead specific to the solution

• Break/fix labor

• Downtime

• Help Desk

• Installation/labor

• Management (asset and systems)

• Operations (computer/systems)

• Planning/evaluation

• Scalability

• Standardization

• Training

After data is finally collected on the in-place/current systems, a “first-round” and very rough vision of the future solution needs to be assembled. This exercise, though preliminary in many respects, will prove useful time and time again in the next few months, though. For example, the ROI exercise will be refined via the detailed approaches and processes described in Chapter 5. It will also impact the solution vision, covered in Chapter 3. And ultimately the combined ROI analysis/future vision will help drive the sizing process (Chapter 7), designing and staffing the SAP Technical Support Organization (Chapters 4, 8, and 12), training (Chapter 9), systems management and operations (Chapter 14), and disaster recovery solution design (Chapter 6).

Translating Solution Characteristics into Technology Drivers

Given the requirements identified by the business units in terms of availability, performance, scalability, manageability, and so on, we are now in a position to begin mapping these requirements into technology drivers. They are called this because they drive the configuration of the SAP solution’s technical specifications. Nearly all of Chapter 7 is focused on covering this process in great detail.

At this point, a very knowledgeable and experienced SAP Solution Architect or senior Basis/Infrastructure consultant is worth his or her weight in gold. The goal is clear—to analyze all of the data collected via the Solution Characteristics matrix, SLA discussions, and various meetings and so on, and then to come back with an order of magnitude hardware/software design/plan that reflects these requirements/constraints. In the real world, this is an ongoing exercise culminating with formal hardware sizings or more comprehensive solution sizings (I usually refer to them all as simply sizings), which are custom-crafted solution-oriented documents typically generated from SAP’s hardware and software partners. The sizings reflect the entire SAP system landscape—the need for a Development system, a Test system, perhaps a Technical Sandbox or dedicated Training system, the Production system, and so on. A comprehensive solution sizing speaks to all of the infrastructure needed as well—network infrastructure, racks for mounting all of the hardware in the data center, power and cooling considerations, administrative or management servers/appliances, and so on. And the solution sizing usually details database layout requirements, the need for bolt-on applications, and more (as requested by a potential customer, or offered by a particular vendor).

The Importance of a Methodology

Obtaining buy-in from every stakeholder, understanding each and every business requirement, and so on can only at best lead to a mediocre implementation costing more than otherwise possible. It’s the methodology employed, the structured and repeatable approach to SAP implementation, that makes all the difference in the world. SAP AG recognized that their customers would benefit from a standard roadmap to SAP deployment, and developed their ASAP methodology in response. ASAP, or Accelerated SAP, was originally intended for smaller implementations where the primary implementation partner was not necessarily a “Big 4” consulting firm. But the approach proved successful in larger SAP rollouts as well, and continues to be used quite successfully even today. ASAP consists of five high-level milestones, including

• Project Preparation

• Business Blueprint

• Realization

• Final Preparation

• Go-Live and Support

ASAP evolved into GlobalSAP and ultimately ValueSAP, adding methodologies for Evaluation and Continuous Business Improvement to its core Implementation methodology. The roadmap changed a bit as well, shrinking to four implementation phases instead of five. With the adoption of mySAP.com solutions growing throughout 2001 and 2002, however, SAP sought to release both an improved delivery vehicle and a more comprehensive methodology that better reflected the challenges inherent to mySAP.com deployments. SAP’s Solution Manager was introduced in late 2001 with Web Application Server (WebAS) 6.10, and was later updated in June 2002 to the much-improved version found on WebAS 6.20. By the end of 2002, this version was the first Solution Manager truly ready for prime-time, offering not only multiple roadmaps to implementation but also improved content (sample docs, new templates, a repository for canned business processes, and more) and better project management tools.

SAP Solution Manager is clearly superior in terms of capabilities, too. For example, Solution Manager may be used to support ongoing operations as well as implementation and continuous improvement activities. Robust project monitoring and reporting capabilities exist as well. Plus, it provides for a variety of ways to help you manage your project team’s educational goals, including Learning Maps, which are role-specific Internet-enabled training tools featuring online tutoring and virtual classrooms. And with training and related support of the ASAP and ValueSAP methodologies expected to completely fade out by the end of 2003, the best game in town from SAP AG will soon be Solution Manager.

The only downside is the software and hardware requirements recommended to run Solution Manager—a separate WebAS instance is required, for instance. And best practices dictate that a two-system SAP landscape be created solely for Solution Manager, one system for production purposes, and another to be used for testing updates and changes to the SAP Solution Manager solution stack. Fortunately, server and disk requirements are reasonable. A dual processor server with 1GB of RAM and 50GB of disk space meets SAP’s minimum requirements.

Although SAP’s Solution Manager may arguably represent the best methodology for mySAP deployments, this is not to say that other methodologies do not exist or cannot be leveraged for successful project outcomes. On the contrary, all of the Big 5 and most of the large SAP technology partners offer a methodology for implementing SAP. The key is the degree of experience that the implementation team has with a particular approach, combined with the methodology’s ability to support specific mySAP.com components and the challenges inherent to implementing some of these solutions.

Pinning Down the Initial Implementation Budget

Finally, with all of the data gleaned during the activities described in the last few sections, you can begin to put together more than simple preliminary budget figures. Remember, you’re just getting the ball rolling at this stage—the actual budget numbers will become more apparent as you move through the first few phases of the project plan and gather all of the details surrounding people, processes, and technology. Until that time, though, a rough budget will go a long way toward ensuring that the business requirements and potential technology solutions are in line with each other dollar-wise.

Specifically, you can assemble the following costs for the entire system landscape (whether that’s a traditional three-system landscape or larger), as well as some of the basic “people costs”:

• Data center space capable of housing, powering, and cooling everything below

• Special power requirements (UPS, power distribution units, redundant power feeds, and so on)

• Server hardware (database server, application servers, WAS/ITS servers, other Internet servers, management appliances, infrastructure servers such as domain controllers, and so on)

• Disk subsystem hardware (each system in the landscape requires a database server, and thus a disk subsystem, database, license, and so on)

• Network infrastructure (switches, hubs, routers, and all cabling)

• License fees and ongoing annual maintenance fees for the operating system for each server

• License fees and ongoing annual maintenance fees for the Database Management system for each database server in every system of the SAP system landscape (a three-system landscape will require three database licenses)

• mySAP.com license fees and ongoing annual maintenance fees

• Management system costs (typically an SAP-aware application capable of monitoring the systems holistically)

• Incremental Computer Operations costs

• Incremental Help Desk costs

• Break/fix hardware maintenance contracts

• System installation (server, disk subsystem, OS, database, and each specific SAP component or product)

• Training costs (again, the entire SAP Solution Stack)

• Costs associated with hiring the project manager(s), project coordinator(s), project librarian/documentation specialist, and so on

• Costs related to technology-focused team members like the Solution Architect, database administrators, SAP Basis and other technical specialists, and so on

• Costs related to functional specialists, ABAP programmers, and other development/business-process experts

• Opportunity costs sacrificed by temporarily assigning people to the SAP project, and back-filling their previous line-of-business, technology support, or other roles within the company.

Certainly these numbers will change many times in the next few months. But the value of calculating a budget number, even if only 80% accurate, is worth a lot at this stage.