Best Practices Approach to Staffing the SAP TSO
The SAP Technical Support Organization (SAP TSO) is the single most valuable resource an SAP customer has. That is, a carefully selected group of support personnel can impact every facet of the system, from minimizing downtime through intelligent change management/planning, to proactively monitoring system performance and database statistics, to ensuring an excellent user experience, to working calmly through emergencies and crunch times. In Chapter 4, I set the stage for designing and initially creating the TSO. Key positions were staffed, and important organizational decisions were made. Here, we take this initial work to the next level. With information gleaned from other chapters in terms of what your own general SAP solution stack will look like, and which SAP components you will implement, it is now time to begin the critical tasks of staffing the bulk of the TSO.
Not all staffing decisions can be made at this time, however. In fact, consistent with best practices, my goal at this point is to staff to the 50–75% level. You must focus on filling positions that directly support your near-term objectives covered in Chapters 10 and 11, which are to develop and begin installation/implementation of the SAP Data Center. Skillsets and experience related to the following areas will therefore be crucial, or of the utmost importance, at this stage:
Data Center infrastructure, the foundation of any IT project—this includes finding folks versed in calculating requirements for and implementing power, thermal/cooling, and space/rack solutions.
Network infrastructure, especially in areas of static routing, designing highly available public links, designing high-performance backend links, and knowledge of three-tier client/server architectures.
Note
The individuals tasked with supporting these first two areas—network infrastructure and Data Center infrastructure—will all probably work under the leadership of the SAP Data Center Lead discussed in Chapter 4.
Server and rack configuration, including capabilities in building out servers, loading OSs, optimizing rack infrastructure, addressing cable management, and so on.
Disk subsystem design/review and installation. The disk subsystem and server/rack support specialists most often report to the SAP Infrastructure/Basis Lead.
Security, high availability, and disaster recovery specialists (with enough knowledge and skills to facilitate the initial installation of the SAP system landscape, based on the Solution Architect’s needs). In my experience, these folks report to the SAP Infrastructure/Basis Lead or the Solution Architect himself.
Database administration experts, to work hand-in-hand under the leadership of the Senior Database Administrator (another one of the core SAP TSO positions covered in Chapter 4).
Basic knowledge of operational activities like backup/restore, help desk requirements, and other traditional data center “operations” tasks.
Experienced SAP basis-layer installation, including knowledge of bolt-on or complementary software components. For example, if SAP Enterprise Buyer Pro is on the schedule for implementation, you will need more than just SAP basis skills on the team—you will need Requisite BugsEye expertise, experience with Java Virtual Machines, and more. These folks also report to the SAP Infrastructure/Basis Lead.
On the other hand, people skilled primarily in performance tuning and tweaking, interface-level integration, and operations/help desk roles will not yet be required.
Not to say that you can’t start looking for qualified people too early! However, if a particular phase of a project is not scheduled to kick off for six months, the people in the job market will be completely different by then—you’re probably wasting everyone’s time if you begin the process too early.
| ▸ | To read more about when and how these final “holes” in the SAP Technical Support Organization will be filled, see “Identifying and Staffing the Remaining TSO Roles,” p. 425 in Chapter 12. |
Three Ways to Approach Staffing
In response to historically inconsistent staffing practices, I have seen the rise of three different ways to staff SAP IT organizations. The method employed most often to staff the bulk of the organization is sometimes called the resume-to-interview process; even today, this is still the most common approach. Companies typically engage their human resources organization to seek out resumes of qualified candidates, hopefully based on really good input from the SAP hiring manager or team. Because this input is subject to technical interpretation, though, a series of phone screens and quite a few one-on-one interviews are required to even begin to qualify hopeful applicants. Not only does this process take time, but it puts a lot of faith into what was written in the resume.
A second method of staffing thus naturally evolved out of the necessity to ensure that a candidate’s resume reflected their actual skills. Called the staff-testing approach, it forgoes much of the screening-focused interview process in favor of instead dumping a pre-qualified SAP candidate into a typical situation (or real-time hands-on “test,” hence the name). The candidate then has a certain period of time to solve the problem, or configure the system, or design a solution—whatever is applicable to the job being filled. What a prospective employer discovers using this approach helps them to qualify a candidate in terms of the following:
How the candidate approaches the problem at hand, from a number of different perspectives—organizational skills, problem-solving aptitude, and so on
Actual abilities versus what was presented in the resume
How well the candidate performs under real-world stress
The staff-testing approach has its own limitations, though, in that some folks simply don’t test as well as others. And the test itself may not be an accurate representation of what the work environment will be like. Finally, when word of the “test” gets out, it tends to lose its impact or surprise-potential, and other tests therefore need to be created on a regular basis.
Out of the shortcomings of these first two staffing approaches came a third approach, try-before-you-buy (similar to the more traditional probationary period approach). This approach shortcuts the interview process, and eliminates the requirements around creating and maintaining tests, by focusing exclusively on putting a candidate to work not only immediately, but for “free.” Then, their ability to interact successfully within the framework of the team, and the quality of their actual work, speaks volumes for them. This approach is tempting when there seem to be two or three equally qualified candidates vying for the same position. Try-before-you-buy is limited in that it’s only really possible when a candidate hails from a consulting organization; the consultant is therefore paid by his consulting organization, but no bill is ever presented to the potential customer during the try-before-you-buy period. This approach is risky, too, in that you are letting a relative “unknown” potentially impact your project. Past working references are therefore critical, as is creating a structured environment for the try-before-you-buy time period of anywhere from a few days to a few weeks. This makes it easier to evaluate and determine whether the candidate is truly a “keeper.”
As is obvious, all of these approaches have good points and not-so-good points. What you really need, though, is an approach that lets you verify the skills of the candidate, and how well they interact in real-world situations, without spending too much time and money playing around with multiple interviews, test scenarios, and so on. What you need is a comprehensive and quality “rapid deployment” approach to staffing the SAP TSO, covered next.