Overview—What Is an SAP Infrastructure TSO?

At this point, your SAP project is funded, and a vision is in place that addresses business requirements while simultaneously balancing cost, performance, availability, manageability, and so on. You also have your SAP Steering Committee and general project management structure in place. Your goal now is to begin designing an SAP Technical Support Organization (TSO) committed to the SAP infrastructure element of the project. The TSO can be broadly defined as the organization charged with addressing, designing, implementing, and supporting the SAP system landscape and its requisite components. By nature in a technical organization, the SAP TSO generally reports directly to the SAP Steering Committee’s senior IT representative (who in turn reports to the company’s CIO) or less often directly to the SAP client project manager or Director of Enterprise Computing Systems. Later, sometime before Go-Live, this technical support function will become part of the company’s IT organization. I cover this transition later in the book, however.

What exactly does “technical support” refer to? The answer is a bit complex, and revolves around the term support. If I were to sum up the technical support role, it would consist of an appropriately staffed and skilled team responsible for ensuring the planning, design, implementation, evolution, and ongoing operations of the technical infrastructure underpinning SAP. Consider the following:

• The SAP solution being implemented, however comprehensive, will not be able to completely manage and monitor itself. Thus, a team of subject matter experts knowledgeable in every layer of the implemented SAP Solution Stack must be constructed.

• The SAP solution will encounter issues that need to be addressed, both reactively and proactively. Again, a broad team of experts that understands how to troubleshoot issues, and how to leverage resources available from other organizations, plays just as important a role in supporting SAP as does the individual/team solving the issues.

• The SAP solution will evolve or change over time, the result of business and other drivers, and these changes will create issues as well.

Given the preceding, some kind of team needs to be held responsible and accountable for ensuring that the SAP solution is indeed available to provide value to the company. Hence, the SAP Technical Support Organization is born.

Given the typical complexity of an SAP implementation from an infrastructure perspective, the SAP TSO fulfills critical functions throughout the SAP life cycle. But the key lies in the attention given to ensuring that the solution addresses the business needs of the company. That is, it’s the business that drives the need for the SAP TSO. The TSO merely responds to the needs of the company to support the “business” of being in business. The business exists to service the company’s external customers, whereas the TSO services internal customers—the business folks. In this way, the SAP TSO indirectly services a business’s customers, as shown in Figure 4.1.

The SAP Infrastructure TSO includes everyone involved in ensuring that the SAP Solutions Stack is designed, implemented, managed, and otherwise supported. Thus, as shown in Figure 4.2, it includes every technical area or array of expertise needed in support of the SAP infrastructure, or SAP Basis layer.

The SAP TSO—What It Is Not

The TSO addresses support needs up and down the SAP Solutions Stack. And it covers these needs from inception of the SAP solution through Go-Live, future systems upgrades, and so on. In the context in which we approach the TSO here, though, functional SAP development and support is not included. That is, the programming and development staff charged with customizing the SAP solution for the company at hand is not covered by the SAP Infrastructure TSO. These SAP developers—ABAP/4, Java, HTML, and other technical coding and business-process functional experts—typically find themselves in another “box” within the SAP project organization charts. And, as shown in Figure 4.3, this box tends to align itself at a level equal to the SAP Infrastructure team/TSO, with both organizations reporting to the SAP Project Manager. Together, then, the Infrastructure and Functional teams comprise the entire project’s technical team.

If we say that that the SAP TSO is held responsible and accountable for ensuring that the SAP solution is available to the company, it makes sense to say that the SAP Functional Team is ultimately held accountable to ensure that the SAP solution works. That is, the Functional Team is chartered by the business to implement the business processes necessary to stay in business. This is therefore an absolutely critical function, key to the overall success of the project. It should be apparent by now that neither the SAP TSO nor the Functional Team can be found lacking—everybody loses if either party is not up to the support task at hand.

Fortunately, we find ourselves at an unusual time in the SAP job market. Whereas only two years ago SAP Project Managers, Basis, Functional, and other SAP infrastructure experts commanded hourly rates or salaries approaching that of sports stars (well, not quite), the burst of the dot-com bubble and general state of the economy has brought these rates in line with other high-value IT positions. I take a closer look at how to leverage these conditions in the next section.

Leveraging the SAP IT Job Market

Today, the SAP job market is saturated with what I refer to as “junior” SAP consultants, functional experts, and Basis/SAP infrastructure technology resources. These junior SAP technologists were typically on the fringe in previous SAP projects, or were simply new to SAP two years ago when we collectively hit the “mature” side of the SAP hourly rate bell curve. However, with less experience than their more senior colleagues, these important team members have accepted positions all over IT, waiting for their SAP ship to come back in.

On the other hand, the market also contains a few folks that were on top of the curve and have simply refused to take substantial pay cuts. These folks jump from project to dead-time to project, struggling to maintain lifestyles that were easily supported two years ago. If you have the budget and absolutely require the best of the best SAP “gunslingers,” these people are right for your project.

Still others, after their current SAP projects no longer needed them, decided to add SAP “bolt-on” experience to their resumes, and pursued extended enterprise projects around specialty or complementary software packages, Web-enabling technologies, and so on. These are the people who work in areas that touch SAP in one form or another, but typically do not represent core SAP support roles. Their value could be immense to your new SAP project, too.

General programmers/developers, network technologists, enterprise systems integration specialists, and other “generalists” fall into the SAP job market category as well. So, too, do people in the middle of retraining and retooling themselves (often at their own expense, at the conclusion of their last SAP project). In my experience, the generalists can bring some very SAP-relevant experience to the table, if you’re weak in say, for example, network infrastructure or basic ABAP coding. Be forewarned, though—their salary expectations might be higher than anticipated. As for the folks retooling themselves in a hot area like mySAP CRM or SRM, I have the highest regard for their proactive efforts to add incremental value to their resumes. If you are assembling a team for a specific mySAP solution implementation, and find yourself in need of a person trained in the solution component, though not necessarily experienced in it, this person’s “go-getter” mentality and personal drive will only add value to the team.

Of course, many SAP professionals are still engaged in thriving SAP implementation and upgrade projects today. These are probably the cream of the crop in the overall SAP IT market, as they possess current skills, and are therefore the most sought-after and sometimes the most difficult to recruit. But I should also point out the obvious about these folks—by the very fact that they are working today, they are harder to entice away from their employers. That is, I tend to assume that a gainfully employed SAP professional probably shows up at work every day and takes care of business, that he is competent at what he does, tends to have few or no interpersonal problems, and so on, regardless of whether any of these assumptions are actually true.

Finally, there are other individuals who simply left the realm of SAP consulting completely, to pursue new careers in enterprise computing or other fields altogether. As shown in Figure 4.4, the market is therefore quite fragmented—SAP expertise resides in pockets across widely disparate technology focuses, careers, companies, industry verticals, and unemployment lines.

Another interesting observation that can be made is that the SAP IT human resources market seems to have more than its share of mature technology workers. Sure, there are plenty of young bright professionals in the world of SAP projects. But when you think about the knowledge and experience required to really support the SAP solution stack, it becomes very clear that the average resume of a seasoned SAP consultant or other professional reflects a lot of time in the trenches. Couple this with the fact that many former mainframe and other legacy IT computing folks moved into supporting SAP in the mid to late 1990s, only to find themselves the most expensive resources of a project (and the first to be let go when other factors were equal), and it’s no wonder that the SAP IT human resources market is age-unbalanced today.

Hey, no surprises! The fact that companies and project teams shed their most expensive resources first unfortunately represents what we all see in every industry whenever there is a turndown. Companies consolidate, pile more work on fewer workers’ plates, cut expensive contractors in favor of less expensive ones (or to save employee jobs), and so on. Of course, then, an organization’s mature workforce usually represents a high concentration of jobs that are eventually eliminated. What’s really interesting is that the “job” per se does not actually vanish from importance, though—database administrators still need to continue to monitor and plan for database growth, for example. Instead, the tasks associated with the job are moved to another person, and priorities are shifted between a shrinking support staff.

Think about the skillsets and experience out there in the job market! One project’s loss is another project’s gain. A senior SAP technologist caught in a downsizing has probably proven himself time and again as adaptable, eager to learn, and capable of doing the job. Consider the following advantages of senior technology professionals, given their tenure and experience in enterprise computing:

• They are equipped. They have the skills and experience necessary to support an enterprise computing solution. With their experience gleaned from supporting legacy environments, these folks have a keen understanding of many layers of the SAP solution stack. They have seen IBM mainframes replaced by Compaq, HP, and Dell server platforms, they have seen IMS and Adabas databases replaced by SQL Server and Oracle, and they have watched transactional systems evolve from green screens to full-featured distributed GUI-based wireless-enabled solutions.

• They are mature. With maturity often comes acceptance of things that can and cannot be changed. Thus, the senior technology professional possesses a wisdom rare in many organizations. He will be willing to take a step backward, or take time to invest in himself again in terms of training/retooling, because he has done it several times before in his career. He has little control over downsizing, but much control when it comes to personal and professional growth—and he knows it.

• They understand change control. In short, they understand how to support an enterprise environment, usually as the result of supporting mainframe and then later SAP R/3 and other enterprise environments. Some things never change, and the philosophy behind sound change control practices is one of these.

• They better understand the fact that work is indeed work, and unlike newer generations of employees, not necessarily fun all of the time.

• They are flexible and eager to contribute. That is, they are accustomed to personal change and sacrifice. They are also usually willing to negotiate compensation levels and positions within a project organization, to again become part of a project. The root of this is simple—these technology professionals enjoy working and contributing to a project where they are truly appreciated.

Those mature professionals who don’t embody the characteristics in the preceding list will probably retire or otherwise remove themselves from the SAP job market. You’ll never see them (their resume, that is). I suggest that you take advantage of these experienced folks in your own projects, and leverage the capabilities and cost advantages of the other folks that comprise the SAP job market today, as you begin to think through designing and staffing a balanced SAP Technical Support Organization.