This is one of the most important questions for SAP professionals to ponder. We can take it further: the decision over generalization-versus-specialization affects virtually all professions. Often, we hear blanket statements such as: “generalize during tough economies; specialize during growth periods.” I find such broad recommendations limiting. In this blog entry, I’m going to answer this question in terms of hands-on SAP professionals, and limit that focus further by focusing on independent SAP consultants – though I’m sure much of this would apply to the full-time employee working in SAP as well.
First: on the theme of SAP generalization and specialization. I actually see this as a false dichotomy. The philosophy studies of my youth taught me that underneath two apparent dualities is often a “paradoxical unity,” and such is the case for the apparent duality of “specialization versus generalization” for SAP consultants. In fact, it’s important to cultivate a general foundation of SAP skills, and combine it with a specialization that stems logically from that core area. In some cases, expert SAP folks can have several related specializations stemming from the same core – for example, several different flavors of GUI development - but beyond that, a consultant becomes less marketable as their SAP skills become too broad. Focus and repetition leads to mastery, and mastery of the right area leads to market demand for your skills.
In his blog, Michael raised a very important point: if you err on the side of a poorly chosen specialization, you can find yourself struggling to find projects. Examples of a questionable specialization in SAP include technologies that are becoming outdated (perhaps ALE or SAPscript or R/2 functional skills). Remember that you can also err on the side of being too far ahead of the curve, specializing in emerging areas where the project work has not yet developed a sufficient skills demand to spill over into a consulting need. Examples of this might include SAP RFID, NetWeaver BPM, or SAP Duet Consulting (as of today, I see no SAP Duet jobs in 63,000 Dice.com IT listings).
Admittedly, it’s better to have a too-far-forward specialization than one rooted in an older technology, but neither is ideal. The best SAP skills combinations mix a core of foundational skills that are still in demand, topped off with a well-chosen specialization that is still gaining traction, where you can be ahead of the curve.
Any way you look at it, specialization is always risky, and that was one of Michael Koch’s most important points. However, I don’t think you can let the risk deter you. Independent consultants need an expert focus that is narrow enough to make them stand out from the pack and serve as the “missing skills piece” on larger project teams with more generalized know-how.
Although you can’t eliminate the risk of SAP skills specialization, there are two ways of reducing it. One is to do your best, as we’ve noted, to choose a specialization that is ahead of the pack without being too far ahead. The other is to make sure that specialization extends logically from your core skills. This way, if the specialization starts to run dry, you can fall back on a reliable core of skills that can always land you a gig, though often at lower rates.
To give you a better sense of how this works, here are some excerpts from the comment I posted on Michael Koch’s blog:
“In many cases, I think there can be both a core and an emerging skill. An example might be an ABAP-BW programmer who decides to add MDM programming to their core. MDM is a good logical extension of BW skills, but since the MDM product still has a smaller level of market acceptance, it doesn’t make sense to put all eggs in the MDM basket unless you are a true expert. So, combining the core ABAP-BW with MDM could make sense. Another direction for the ABAP-BW person could be towards Business Objects functionality, which would mean learning more Java-related tools - though this can be a good thing as well!
Here’s another example of a technical profile that can be very effective: someone who started as an ABAP ALE-EDI-IDOC specialist (remember that stuff?), then moved into best-of-breed EAI technologies like Tibco and WebMethods, and then into XI programming. This is a profile I’ve seen a few times that works very well. It’s just one example, but what I like about it is: the person in question has some cutting edge skills, but over time, they have been true to their skills foundation and so they have a deep base of core expertise to draw on.”
Since my examples for Michael’s blog were more on the technical side, let me offer a couple of functional examples: one might be the SAP HR consultant who has extended a base of payroll/benefits skills into more cutting edge SAP HCM areas, such as E-recruitment or ESS (Employee Self-Service) or Talent and Performance Management. From a base of skills in SAP Financials, you can move into all kinds of specializations, from SAP Financial Supply Chain Management (FSCM) to Treasury and Funds Management to the New General Ledger to Product Costing. It goes without saying that experience in the most recent version of SAP that pertains to your core skills is more important than any other factor, so that must be in place as well.
After I wrote this piece, I realized it has one flaw to this point: it reads like obvious, common sense. What’s important to understand is that many SAP professionals do not operate this way. I frequently get emails from folks who are always in pursuit of what is hot in SAP without regard to how it connects to their existing skills inside and outside of SAP. The most common example is the ABAP programmer who is looking to bail out, perhaps into CRM or whatever "the next big thing" might be. The problem here is that if you are always chasing skills your resume tends to fragment. If a Basis person moves into SAP Supply Chain Management, and then SCM projects come slowly, it’s hard to fall back on the Basis work because it’s now become dated. If, on the other hand, the Basis person moves into NetWeaver XI/PI, then if there aren’t enough opportunities in PI yet, the work they are doing still relates directly to their technical core competency, so it’s easy to fall back on the Basis foundation if needed.
People forget that there are hot areas spread throughout SAP. It’s better to extend your skills into something that is more closely connected to your current skills and worry less about whether it’s the hottest aspect of SAP or not. It’s not as sexy, perhaps, to think about just mastering what you know, but I’m always amazed at all the areas of SAP that folks can find success in when they are passionately focused on it. Another example: sometimes I hear from R/3 functional folks who are more worried about getting into SOA work or into Business Suite applications when they should be concerned about updating their existing skills into ERP 6.0 first. Once your skills are "upgraded" to the latest releases, you are in a better position to assess how much demand there will be for them, and whether you need to extend them further.
So we now have a better sense of the art of combining general and specialized SAP skills. But what about this third skill area I was referring to? In addition to core and niche SAP skills, SAP consultants must also be cultivating general consulting skills. What is interesting is that many of these general skills, sometimes unfairly diminished by the so-called “soft skills” label, are now found under the SAP “Business Process Expert” (BPX) skills umbrella. Some JonERP.com readers I have known since the mid-90s have made a point of letting me know that the best SAP consultants have always had these well-rounded BPX skills. I’ve written elsewhere on this site about BPX skills transitions and will return to this topic in more detail later. If you’re interested, my SAP BPX skills webcast is a good place to start. This article on BPX job roles could be of interest also.
When we think about BPX skills, we can certainly put some of them in the “classic” consulting skills umbrella, which might include change management, implementation methodology know-how, project management skills, end-user training and team-building skills, and full life cycle implementation experience (as opposed to coming in just for the configuration piece and moving on).
However, in the modern BPX context, we can add more skills to this “general” mix, including industry expertise as well as modeling experience that allows you to take a process-driven perspective to your SAP work. The BPX era is about the convergence of functional and technical skills, so more than anything, adding the BPX component is about making a concerted effort to understand how to connect your skills to the “other side” of the implementation (whether that means functional or technical), in the interest of offering greater business value to the implementation.
Of course, this raises interesting questions as to what the right skills mix for an SAP consultant is. I still find that the “80/20” mix of functional and technical, with one side as your expertise and the other side as your additional know-how, to be the ideal mix, but in some ways, we are looking at moving towards more of a 50/50 techno-functional skills blend as BPX skills come into clearer focus in the years to come. Right now, we’re not there yet, we may never get there. Why? There is simply too much in SAP to master for most of us to get away with straddling a 50/50 fence. For now, I would set the goal to cultivate an 80/20 mix - just make sure that other 20 percent is super solid.
I hope that this entry has given some idea of the SAP skills strategy you should employ to take that core SAP skills foundation, extend it into a couple of sensible specializations, and wrap it all in a well-rounded BPX consulting skill set that is more about being an outstanding consultant than anything else (though as tools like NetWeaver BPM hit the marketplace and mature, there will be more tools needed in this area as well). If you want to get a better sense of which SAP skills in your area are hot now, check out the hot SAP skills section of JonERP.com.
The SAP generalist-versus-specialist discussion is a very healthy debate that cannot be resolved in one blog entry. There are exceptions to any broad statements about skills, but I hope that this piece helped to provoke your thinking. I look forward to seeing reader comments on this important topic.
Oh, and I should close by saying that what I recommend here applies to any economy, though the one thing about a sluggish economy is that there is less margin for error with any of these decisions, and factors about which types of SAP projects are moving ahead should be taken into account as well.