SAP Skills Convergence: The Morphing of “Geeks” and “Suits”
For a long time, I've advocated that SAP professionals needed to have some level of techno-functional know-how to become a top shelf SAP professional, a.k.a. a real "rock star." Historically, I always felt that the best mix was 80 percent technical and 20 percent functional, or vice versa.

The 20 percent meant you knew just enough about what was happening on the other side of the fence to be able to speak their language. The 80 percent ensured you didn't drift too far from your area of SAP skills mastery. SAP is simply too vast to master across the board.

For every true SAP guru who knows five modules, I run into nine "jack of all trades" types whose skills are spread too thin in a futile effort to be all things to all projects.

In the last couple years, however, my view on the 80/20 mix has started to change. The SAP BPX community has had a lot to do with my shift in philosophy on this. Why? Well, for one thing, we're starting to see the emergence of two new job roles, the SAP Enterprise Architect and the SAP Solution Architect. By "emergence," I mean that these job titles are showing up on job requirements and actual business cards. These new roles are pretty much 50/50 functional/technical, give or take.

Enterprise Architects are often a bit more technical, looking at architectural and system landscape issues, usually from the vantage point of service-oriented architecture. The Solution Architect is often more on the functional side, mapping out SAP functional solutions, communicating with the Enterprise Architect to ensure that the functional solution is aligned with the NetWeaver landscape.

Note: these job role definitions do vary wildly at this point (some define the Solution Architect in more technical terms), so how I've defined may be different than how you encounter them.

Of course, these "SAP Architect" jobs are not commonplace today. But it's evidence that the technical and functional skills sets are converging. These days, suits are better off being geeky and geeks are better off if they can wear a suit from time to time. I heard someone call this new skill set a "suite," but that name won't stick as it sounds more like a software program than a person. Nicknames to be decided, the impact of the BPX skill set is real. But we must be careful: getting too futuristic about skills is dangerous. Chasing tomorrow's skills is not the right approach for today's job market.

I have written extensively about the impact of BPX skills on SAP professionals, and so have others in the SAP BPX Community. If you want a head start on this, if you haven't already, read Process First: The Evolution of the Business Process Expert, written by BPX Global Director and SAP SCN Vice President Marco ten Vaanholt in conjunction with the SAP BPX community.

I also wrote a detailed SCN blog post on the topic, entitled, "So What Does it Take to Become an SAP Business Process Expert?" The short version? I believe we need to see BPX skills not as a futuristic view of new project roles, but as a menu of skills all SAP professionals should be striving to add. BPX skills should be incorporated in a gradual manner, with priority placed on the skills best suited for your particular role.

Here's a quick rundown of my favorite high-impact BPX skills:

Experience with process modeling tools: Most of these modeling tools are still intended for technical users, but with time, more are being geared toward business users. It doesn't matter which tool you work with at this point, the key is to understand the principles behind their usage.

"Web 2.0" skills: To distinguish Web 2.0 consumer tools from business-friendly tools, I often use the term "Enterprise 2.0." For the aspiring SAP pro, I see three relevant areas in Enterprise 2.0:

1. Knowledge of online collaboration tools like wikis and "Waves";
2. Ability to improve the enterprise UI experience, informed by knowledge of popular social networking tools and UIs, and
3. Understanding how to expand the company's SAP network beyond organizational walls to collaborate on projects and/or get quick answers to technical questions.

Obviously more hardcore E 2.0 business use cases are coming along. Those who stay on top of open development standards and the potential for managing cross-company projects in a (secure) online fashion will add some sizzle to their SAP skill set.

"Soft" skills: Soft skills is a distinct category which existed long before "BPX," and it's as mushy to define as it sounds. In fact, I'm sinking into skills quicksand even as I type this. Just remember that "soft skills" don't have to be that "soft" - sometimes implementation methodology knowledge is classified as a soft skill. I recommend all SAP professionals know something about SAP's implementation (ASAP) and post-go live (Run SAP) methodologies. SAP is also working on a new implementation methodology which adds BPM principles to the classic ASAP approach.

We could also put the ability to make a business case for one's project in this "soft skills" category, and we could toss in "change management" as well, which we can roughly translate as the ability to get everyone in the organization on the same page so they don't reject the new tools before the lights go on.

Suddenly soft skills don't seem so soft.

Industry know-how: I'm hearing a frequent refrain from hiring managers: SAP professionals need more industry experience. This has special relevance to those who want to remain relevant on site and not be easily outsourced. And yes, technical pros can benefit from industry depth also.

Knowledge of the end-to-end business processes that relate to your SAP skills focus: Historically, SAP professionals functioned in "silos" such as HR or Financials. But increasingly, SAP customers are approaching ERP in terms of end-to-end business processes, such as order-to-cash or procure-to-pay or hire-to-retire. SAP's own Business Suite is actually structured around such processes, known as "Value Scenarios."

While this doesn't mean that configuration of tables is going away anytime soon, a "process-driven" approach to ERP means a broader understanding of how module configuration supports a cross-module business process. SAP is currently upskilling all of its application consultants in its own BPX curriculum. The end result will be called "process consultants" (see the video interview I posted with SAP BPM guru Ann Rosenberg from SAP TechEd Phoenix for more on this transition and what it means for SAP pros.

Some would also classify Business Intelligence skills in this BXP skills mix, and I expect us to see more overlap between the BusinessObjects community and the BPX community in 2010 as these connections get made.

In sum...

-It makes sense to grapple with these skills now, rather than dismiss them as being tied to futuristic job roles that don't even exist yet.
-Skeptics who think BPX means "overly futuristic" should consider this: "BPX skills" are a factor on job interviews!
-On a regular basis, I see BPX skills separating individuals from the crowd during the job interview process.
-It's the ability to interact, rather than huddle in a cube, that sets the elite SAP performer apart. It's not about being an ace "hired gun" anymore. It's about sharing knowledge and making your team better.

So here's the big question:
Now that we have a grasp of these skills trends, how do you put it all together in one marketable skill set? And what happened to that 80/20 skills mix we talked about earlier? Is it really 50/50 now? Let's check it out.

<Previous  Back to Main  Next>