The Structure and Role of the Steering Committee

Together, we have looked at quite a few planning activities thus far. The SAP Steering Committee has driven some of these tasks, and the Project Sponsor specifically has put in his share of long hours by now, too. At this time, it makes sense to describe the Steering Committee’s structure as a high-level group tasked with maintaining a focus on creating a high-quality and relevant SAP solution. Primary members of the Steering Committee include the following (see Figure 2.5):

• The Chair (normally the senior executive tasked with making SAP a reality, that is, the Chief Operating Officer or one of his senior appointed delegates).

• A representative of each functional area to benefit from SAP’s re-engineering efforts. For example, this might include representatives from Finance, HR, Manufacturing, Logistics, and World-Wide Sales.

• The Project Sponsor, if not already identified earlier.

• A senior representative of the Chief Information Officer, or the CIO himself.

• The company-internal Project Manager (as opposed to other PMs who will be appointed from consulting and integration partners and SAP itself).

• Manager or Director of Enterprise Computing Systems (or equivalent title, usually responsible for the systems currently in place that will be augmented or retired by the addition of SAP).

• A senior-level SAP Solution Architect, or sometimes SAP’s appointed Project manager (someone who can act as the committee’s technical liaison). We refer to this position generically as the SA.

As I said before, the primary role of the Steering Committee is to focus the efforts of the company with regard to how SAP will solve problems of a business nature. It is responsible for setting the scope, time, budget, ROI expectations, and general boundaries for the project. Thus, the committee will be out of necessity heavy with business representatives, who will be required to make decisions that are driven by the nature of SAP and the cost/benefit/capability tradeoffs of technology. Making these decisions will require understanding the impact of the information presented; to make good decisions, the committee will need to familiarize themselves with SAP’s disciplined and thorough approach to designing business processes. Very early in the process, the committee will need to validate decisions made in regard to the very structure of the business hierarchy as represented within SAP, too, including the mapping of business functions against SAP business objects. For example, every company consists of multiple business units, but how will these units be represented in mySAP? As separate clients, or legal entities? As different sales organizations? Through the implementation of completely different SAP instances? The choices, and the impact of the choices, impact the very fabric of the solution, underscoring the fact that the committee’s business representation is vital to the project’s success.

But to keep the Steering Committee grounded from a technology perspective, specific IT-related representatives are required as well.

In practice, I tend to see a separate smaller subcommittee or team that coordinates the work “handed off” to the Solution Architect or SAP Project Manager, thus allowing these critical resources the bandwidth to focus on strategic committee-relevant issues rather than low-level technical questions. The smaller technology team reports their findings and observations to the SA and/or PM on a regular basis, who then reports back to the Steering Committee as required.

With the structure and role of the Steering Committee explained, let’s now move into describing some of the committee’s and Project Sponsor’s more important activities.

Business Unit Buy-in

With buy-in achieved at executive and senior management levels, the job of the Project Sponsor and Steering Committee is to push this buy-in “down” the organization. In other words, all of the various business and IT organizations need to understand that their full support will be required to successfully implement SAP, and that their managers back them 100% in this regard. Formal and informal meetings and conversations with key contacts in each functional organization, and anyone who plays a key role in designing and supporting the business processes employed by these organizations, are key. I cannot say enough about this—picking up the phone and discussing the project may be good enough for some folks, but this will be the time to really foster and develop relationships face-to-face, too. Success is about embracing change, and then putting in the hours to make it happen. If the business units and their key personnel don’t fully embrace the changes that SAP will impose, the implementation will struggle along in two key areas:

• Customization—This is the process of configuring the mySAP components or application modules to align SAP business processes with an organization’s workflow processes. Normally this is an adaptive exercise in which the organization’s workflow actually changes to take advantage of the built-in methods embodied by SAP. But without an organizational subteam in each business area anxious to assist in deploying SAP, even the best functional consultants and experienced programmers will be at a loss to get this done right, much less quickly.

• Day-to-day business—The pure investment in terms of hours will never materialize in organizations not completely on board with the SAP project. Not only will the project falter in these business units, but accomplishing day-to-day business will be more difficult as well. Why? Because an organization that is not embracing the changes SAP brings with it will instead be fighting hard to keep these changes at bay, and that fight will consume a great deal of time and energy otherwise expended in achieving the company’s operational goals.

The “Napkin” Plan—Identifying Major Milestones

While you are developing buy-in of the various business units, you may also begin assembling the pieces of what will eventually become your SAP Implementation (or Infrastructure) Project Plan (SIPP). My team has developed so many of these that even our preliminary Napkin Plan—the initial high-level plan named for the fact that often it’s tossed together by the Steering Committee on something as unlikely as a napkin—is in reality quite comprehensive.

At this stage, the plan is focused on big-ticket items and questions, such as

• When will we nail down the SAP component/solution set that will meet the business’s needs? In other words, which mySAP components are we actually implementing?

• When is the right time to share what we know and have, and invite SAP Solution Stack Vendors to either participate in the RFI/RFP process or begin completing their SAP sizing questionnaires?

• When can we get started putting together the SAP Technical Support Organization (SAP TSO)?

• How will we address training our SAP technical staff? What about our development staff?

• How much lead time do we need to fashion an SAP Data Center, and what is on the critical path?

• How soon can we get a development environment and hopefully a technical sandbox in place? What other requirements or tasks need to be addressed first?

• How will we move real data into SAP, to begin the process of configuring and refining business processes?

• When can we begin the Testing phase? Staging? When do we bring in the final Production gear?

• How and when do we perform integration testing?

• Should we run a stress-test or load test? When? How?

• What day do we think we can actually go “live” on our new mySAP solution?

• Do we need to run the old systems concurrently for some period of time? Will we phase in different plants or facilities over time, or will we cut-over to the new system all at once (a Big Bang approach)?

All of these questions and more are addressed in greater detail throughout the book. For now, you want to lay out the project plan, and see what kind of time frames you’re looking at. Then, you want to do your best to work “backwards” from Go-Live, so that you can better identify the milestones and tasks that lie on the critical path to Production. This process of working backwards from Go-Live to Planning is covered next.

Working Backwards to Develop Timelines

It’s advantageous to work “backwards,” especially when hard deadlines exist in regard to specific milestones. I often run into hard deadlines around getting plugged into the SAP project management team, crafting/designing the SAP Data Center, deploying the SAP Development environment(s), and getting our Solution Architects engaged. In many cases, I am also engaged to help drive the sizing process with our clients, working directly with our own or other SAP Solution Stack vendors and partners, including their SAP Competency Centers (which are organizations within a company dedicated to learning and embracing SAP design, installation, support, and other best practices). When to start technical and incremental “new product” training can also represent hard deadlines for organizations completely unfamiliar with these new technology enablers.

If the time needed to complete each task is understood, and intertask dependencies are clear, it is a simple matter to plug in the numbers and arrive at a critical-path-oriented schedule. With this, you can then look forward again, building and identifying slack-time, concurrent activities, and so on into your Napkin Plan, in effect building a full-fledged SAP Implementation Project Plan along the way.

A Closer Look at the SAP Solution Stack

As was covered earlier, the SAP Solution Stack represents all of the technology layers culminating in a productive SAP installation. But the solution stack applies to each system, and indeed every computer or other piece of gear found in the SAP Data Center. So the solution stack not only applies to the Production SAP system—the one deployed to actually service the needs of the company—but it also applies to all of the supporting systems that make the Production system possible.

Maintaining a bunch of SAP systems to support a single and perhaps small Production system may seem like a lot of trouble and expense to go to. After all, each system will require its own hardware, software, and so on—each is a full-blown SAP solution in and of itself.

The SAP System Landscape

Before we get ahead of ourselves, then, let us drill down into the specific purpose or roles that each of these systems will play from a change management perspective. As illustrated in Figure 2.6, I have noted both business-process-related changes and technology-driven changes, with the understanding that all of these systems ultimately support and help to maintain a well-performing Production system, but not all are required for every different mySAP implementation.

• Technical Sandbox System—This system is reserved for use by any present or future member of the SAP technical support team to practice and perfect configuring and tuning the SAP Solution Stack, especially in regards to software component installations, upgrades, integration with other solution components, setup/testing of data replication, backup and restore processes, high-availability hands-on training, and so on. In the best of worlds, then, it should be identical to the Production system from a topology perspective (same components), though to save money it does not necessarily have to be configured as robustly (fewer number of drives, processors, application servers, and so on may be acceptable). Note that because of its technical support role, it is not involved with development activities per se. Development is initiated in the next system discussed.

• Business Sandbox—Similar in scope to the Technical Sandbox, but used by the Development team (SAP ABAP, HTML, and Java programmers) in support of learning, testing, and practicing their trade.

• Development System—This system is created and maintained for continued SAP configuration and/or customization, maintenance, and steady-state updates/bug fixes. This instance also serves as the originator of business-process-related configuration and customization changes that will eventually be “promoted” into Production.

• Test/QA System (also known as the “Quality Assurance” System or the “Integration System” in some circles)—One of the most common systems seen in even the smallest of implementations, Test/QA is maintained for integration and testing of business process configuration changes and so on, prior to eventually promoting these changes into the Production SAP system. In other words, all functional changes are promoted from Development here, and thoroughly tested to ensure that neither it nor other business processes “break” as a result of a configuration change. It should also be noted that technical changes are made here first if, for example, a Technical Sandbox is not in place and the Development system is deemed too critical to initiate changes that may impact availability.

• Training System—Usually reserved for larger implementations, this system is maintained for ongoing internal training of SAP end-user personnel (that is, “How to use the SAP GUI,” SAP 101 classes, functional business-area training, and so on). In smaller implementations, this role is often served by the Test/QA system.

• Staging System—Usually identical to Production, this system is used as the last stop for changes in the largest or most mission-critical of implementations. The Staging system is often subjected to stress/load tests and other performance tests that reflect what is expected to be seen on the Production system, so as to determine the probable impact of a change in the actual production environment before this change is promoted to Production.

• Production System—This system supports the business groups and provides for the business needs addressed by SAP. It is the system the end users leverage in their daily activities after Go-Live, the reason why SAP was implemented in the first place.

• Disaster Recovery (DR) System—This system is implemented when the cost of unplanned downtime exceeds the cost of implementing, maintaining, and supporting a copy of Production. The Disaster Recovery system (which is therefore usually identical or nearly so to the Production system) is located in a different physical location from the Production system, and used “in case” of a disaster, that is, when the production system fails for an extended period of time, or is otherwise unavailable. Note how business process changes are applied to the DR system—not from development, but typically from Production itself, in the form of a replicated database or replicated transactions applied to the DR system’s database on a regular basis.

Many companies adopt a three-system or four-system strategy in regards to SAP, deploying Development, Test/QA, and Production, along with a combination DR/Staging system or Technical Sandbox. In fact, one of my customers refers to their Technical Sandbox as their “best-kept secret” when it comes to maintaining a highly available production operating environment. That is, changes are introduced in the Production system only after testing them in their nearly identical sandbox environment, and then further ratified via the development system. And the entire team at this customer site—SAP Basis, DBAs, even Computer Operations—is very familiar with the solution stack as they have implemented it, because of their technical sandbox. Further, new-hires and others with the need to familiarize themselves with how the Production system’s high-availability cluster operates can do so safely in their hands-on Technical Sandbox rather than trying to schedule Production downtime.

Two General Approaches to SAP Solution Sizing

Although the real work of solution sizing is discussed in Chapter 7, the Steering Committee’s IT liaison should begin giving thought to how the solution will be presented to the various hardware vendors anxious to compete for their share of the SAP project dollars. Two schools of thought exist in regard to configuring servers, server components, and computing appliances. In the first case—sometimes called Future Growth Strategy or In the Box Growth—CPU, memory, disk, and peripheral I/O slot system configurations are designed to meet a minimal supported level of fault tolerance while allowing for future growth of the systems. That is, in server configurations where the hardware needed to meet the user requirements would require filling up or using all disk drive bays, or all memory slots, or all CPU sockets of the selected computing platform, a larger disk drive, higher-density DIMM kit, and so on is used in its place. In this way, fewer CPUs or disk drives are required to provide the same level of capability—and the larger kit ensures that there is built-in “upgrade” capacity within the platform to permit future hardware upgrades, because extra DIMM slots of disk drive bays are left unused and therefore available. Such an approach to configuring allows for “built-in capacity growth” of the individual servers and appliances within a given solution—nothing is “maxed out” from the beginning, so each hardware component can therefore be upgraded in the future.

A second school of thought for configuring individual servers and appliances within a solution suggests that a Maximizing strategy allows for lower total cost of ownership. Rather than leaving memory slots, CPU sockets, drive bays, and so on available—and perhaps wasting this potential bandwidth in the years to come before the solution is retired—defenders of the Maximizing strategy seek to provide maximum capability in what amounts to a fewer number of servers or disk subsystems. They only pay for what they believe they need. In addition, proponents of this school of thought believe that the typical cost associated with “opening a box”—planning and taking down a server or other hardware component in the SAP Solution Stack, to carry out hardware upgrades—exceeds the delta in cost between configuring it for future growth and “maxing it out.”

Neither school of thought seeks to sacrifice availability at the expense of anything else, however. Availability through redundancy—maintaining “2x” or “1+x” servers when only “x” is required to address a given load—still applies completely to both schools of thought. In the first case, though, three lightly configured servers may be specified, whereas in the latter, two heavily configured servers are preferred.

Different companies and their IT organizations tend to subscribe to one or the other school of thought. In the last few years as hardware costs continue to drop, it seems that more and more of our clients go with the second approach. Experience has also shown many of these organizations that the downtime associated with bringing a server offline for a hardware upgrade is often not worth their effort. Regardless of the approach, though, this needs to be documented and later shared with all of the prospective hardware vendors.

Giving Attention to Change Control

The complexity of an SAP implementation can really create problems in this critical area—not embracing good change control practices. A system-wide approach to managing change must be developed and followed, and it needs to start here and now. There are too many examples of missed SAP Go-Live dates, and too many botched implementations, to ignore change management.

Ultimately, change control (or change management—the terms are used interchangeably) minimizes system downtime while still allowing the system to benefit from enhanced business functionality or increased future stability due to “bug fixes” and other software/firmware patches. One of our SAP clients describes change control as “staying behind the curve enough to keep the system up.” It’s a good definition, actually—if a company decides not to jump on the latest and greatest service packs or bug fixes or SAP support packages in their production environment, instead opting to test these changes elsewhere in a methodical manner, that company will enjoy greater system availability.

The Role of the SAP Technical Support Organization

With a project plan in development, and progress being made toward a general solutions architecture, you can now turn your attention to considering the organization tasked with bringing the technology together, and ultimately managing it—the SAP Technical Support Organization, or SAP TSO. A number of forces drive the size and scope of the organization tasked with designing, building, and supporting an SAP implementation. Indeed, the support organization will revise itself shortly before, and again after, the Production system goes “live,” but for our purposes, we will focus on the following “pre–go-live” requirements that drive how and when the SAP TSO is staffed:

• Functional or “capability” requirements

• Accessibility requirements

• Availability/high-availability requirements

• Performance requirements

• Scalability requirements

• Security requirements

• Administration requirements

• Other requirements

We will drill down further into each of these requirements in different chapters throughout this book, too, as the role of the SAP TSO morphs and changes. In particular, Chapter 4 provides insight into designing the TSO, whereas Chapters 8 and 12 detail when and how to staff it.