Identifying and Staffing the Remaining TSO Roles

Consistent with our project management approach to writing this book, and based on the foundations laid in Chapters 4 and 8, you by now should have a well-oiled SAP Technical Support Organization in place. Key positions have been staffed for some time, your mix of consultants to internal resources tends to favor the consultants, and the assembled team represents an elite group of folks adept at supporting much of your unique SAP Solution Stack in place today. In fact, your team members are by this time experts in ensuring that the SAP solution is indeed available to be used by the various developers, business process analysts, functional consultants, and other testing/development-focused individuals, who at this point represent the TSO’s primary customers.

The business-focused implementation team members continue to play as key a role as ever. Some members of the technology-focused support team have probably transitioned back to a combination of their former and current roles, though, as their tasks have been completed or future tasks lie “on hold” awaiting the completion of future milestones. Other technology-focused individuals will find themselves in a similar position soon, too, as the project plan dictates.

But the SAP support organization is by no means complete. In fact, based on my recommendations in Chapter 8, the team should only be about 80% staffed. Much of what is missing of the remaining 20% can probably best be described as either subject matter experts in certain layers of the SAP Solution Stack, or long-term operations, help desk, and other such support providers.

Throughout this final chapter on SAP staffing, I will discuss these few remaining positions. In addition, I will note appropriate methods of staffing or otherwise fulfilling the jobs and tasks to be accomplished by these late-comers to the SAP project. My hope is to leave you with a sense of the critical nature of these final positions with regard to the success of your SAP implementation project, including real-world organizational structures, tools, and approaches.

Where Exactly Are the Holes in Your TSO?

Before it makes sense to begin talking about how to staff for the remaining technical positions, a brief discussion on the typical “holes” that remain at this point in the project is in order. To start with, the biggest, most gaping, holes center on SAP operations, systems management, and help desk activities. These represent sustaining positions that will be around long after the majority of the SAP functional team disbands, and the other consultants are let go. I will cover these holes in great detail later in this chapter.

Additional staffing holes exist around various specialists, including security, performance, specific SAP components like EBP or Enterprise Portal, and so on. Specialists involved with integrating components or legacy systems within the context of the larger SAP solution, not to mention high-availability and disaster recovery experts, will assist us in filling in critical staffing holes, too. In all of these latter cases, the tasks to be accomplished are typically short in duration but require the advice of SAP Subject Matter Experts (SMEs) to keep the project plan on track.

Holes in the realm of “testing” exist at this point in the project plan, too. Functional or integration testing, along with general systems testing and full-blown SAP stress-testing, will occur soon, and therefore need to be planned for, executed, analyzed in terms of testing results/output, and so on. The tuning and tweaking that comes out of the results of testing (which, after all, is often the goal of the testing in the first place) also eventually needs to be accomplished. This testing provides feedback to the rest of the SAP support team when it comes to configuration parameters that need to be changed, SAP solution stack elements that need to be tweaked, and so on—to ultimately better serve the patiently awaiting user community. Accomplishing this goal is not trivial, and therefore requires competent people knowledgeable and experienced in both testing and analyzing those same test results.

Finally, preparation for Go-Live may require additional specialists and analysts simply for the sake of risk mitigation. That is, it is common and very advantageous to plan in advance for SAP Solution Stack experts to be onsite the week before as well as the actual week of SAP Go-Live.

Having said all of this, it is imperative to get busy identifying which specific roles are missing in your particular organization, as you continue reading ahead on the subjects of different methods and approaches for staffing the missing “twenty percent.”

How Big Is “Big Enough?” in the Real World

In the past, I have been asked “How big should my SAP technical support organization be?” Although no single answer fits everyone, a couple of thoughts come to mind. Consider the following:

• For every technology-focused group, there tends to be a business-focused group with similar interests. These two groups need to communicate effectively with each other and operate in lockstep with one another.

• The more complex the SAP Solution Stack, the more critical it becomes to have subject matter experts either on staff, or quickly available (that is, through what I call “consulting on demand” arrangements).

• From a cost/value perspective, determine whether an onsite resource is more advantageous, or an offsite “on-call” resource makes better financial sense. Either approach can make a lot of sense, depending upon the situation or environment. That is, if the weighted risk versus cost of downtime exceeds the cost of keeping an incremental resource on hand, it makes good business sense to keep the resource on hand. Otherwise, it probably makes more sense to simply arrange for quick access to consultants and other “pay-as-you-go” assistance.

• Technical support organizations tasked with supporting lots of users will tend to be larger than those tasked with supporting fewer users. The number of users ultimately drives help desk calls, shrinks windows of available downtime (to perform system maintenance, for example), impacts the growth of the SAP databases, impacts the number (and therefore complexity) of application servers and ITS/WebAS servers, and so on. Each organization is challenged to achieve the best degree of balance.

• An SAP TSO responsible for a larger geography or multiple time zones, or in some other way distributed, will tend to be larger simply by virtue of the support required (and therefore the number of persons needed from a pure staffing perspective). Refer to the organizational charts at the end of this chapter for a view into how small, medium, and global entities attack supporting SAP.

In the end, work with your vendors and partners to compare your operation to similar mySAP operations. For example, I often provide what I have coined an SAP Comparative Analysis to my SAP customers and prospects. The comparative analysis consists of raw data covering hundreds of my own SAP customers that can be sorted and analyzed by factors like the following:

• Number of average concurrent users

• Hardware, operating system, or database platform

• Version of SAP, that is, R/3 4.6C or BW 3.0B

• Monthly average growth in database size

• Average user/dialog, background, and other response times

• Print volumes

• Operations staffing model

• Size of SAP Basis team

• Much, much more

A sample comparative analysis is shown in Figure 12.1.

Of course, no real customer names are provided here or in my sample on the Planning CD (so as to maintain client confidentiality), but I have found over time that everyone gains value from this kind of information. And in the end, it lets a company “benchmark” its own SAP project against others, helping a company understand similarities and differences between its own implementation and other implementations across the world.