Ask the SAP Career Expert Archive

SAP Career Questions for B2B Workforce, March 2008 edition I am an SAP professional with two years of ABAP experience, currently working as a techno-functional resource in the SAP-SD module for the last 11 months in a maintenance project. I am thinking of shifting into the cProjects domain of ECC, how will it suit my profile? It will be helpful if you can explain a bit of cProjects's future. JR: This is an excellent question because it gets to the heart of how SAP is repositioning its functionality in the ERP core, perhaps with Enterprise Services in mind. To get the bottom of where cProjects is headed, I checked in with Brian Trout, SAP Practice Manager with B2B Workforce. Brian explained that cProjects began as a PLM- based function to extend project collaboration around the Engineering Change Management (ECM) function. Obviously, PLM is a product that is not part of SAP's core "ECC" functions (SAP now considers ECC to be the central ERP functions within the SAP ERP 6.0 release, so the "ECC" lingo is being phased out). PLM is currently one of SAP's Business Suite components. If we were considering cProjects solely as part of PLM, we would be talking about a skill that is tied to a niche SAP product - one that could be very successful, but is never going to have as broad a presence as, say, SAP Financials or even SAP HCM. But Brian reports that SAP has broadened the use of the cProjects functionality: "Right now, we have a CRM developer on a B2B Workforce project who is helping his client with a Portals-based cProjects initiative that will help their sales team estimate costs against the sales in the pipeline. This is a Java-centric NetWeaver Portals project that involves the use of iViews to present this information to the sales team in a form they can use and consume." Brian believes that the cProjects functionality is a powerful way to "push" some of SAP's project costing functionality into outward-facing roles where users in revenue-producing capacities, such as external sales teams, can use cProjects to make sure that the products and services they are selling will indeed be profitable for the company once the sale is closed. It may sound simple, but if companies can't tie product or project costs to particular kinds of sales, there is no way for the sales team to know if the revenue they are booking is truly profitable when costs are projected against it. That's why the integration between "edge" applications like CRM and the core ERP system is so crucial from an "integrated business process" perspective. It looks like cProjects can play an important role here. The next thing Brian pointed out was how this CRM-based project points to an overall SAP trend: "This is a great example of how SAP is conceiving of its product differently in light of NetWeaver and eSOA. SAP's use of cProjects, where they are pulling functionality out of one context, in this case, PLM, and applying it to others, such as CRM, is very similar to SAP's own message to its customers: you can be more efficient if you re-use certain functionality and apply it as web services or even composite applications. I think we can expect to see SAP re-use many aspects of its functionality, taking applications that are effective in one part of SAP and applying it to another, with the NetWeaver framework driving it all." Brian's take on these broader trends makes perfect sense. So with all that in mind, let's revisit this reader's question. One aspect of the question was the future of cProjects consulting. Based on cProjects having relevance in more than one area of SAP, we can see that the demand for cProjects skills should be broader than if it was just limited to PLM. We also know that cProjects can help customer-facing teams (in this case sales agents) improve their performance and sell more strategically. As a rule, any SAP functionality that involves customer-facing roles and also integrates with the back end is going to be in demand. We can never say for sure which areas of SAP will be marketable years from now. With that in mind, I do think cProjects will be a good skill to have going forward. However, let's remember that there is a big difference in between adding a tool to your skill set versus focusing on that area exclusively. At this juncture, I like cProjects better as a tool in the skill set versus an SAP consulting focus. Our final step, now that we have identified these market factors, is to assess how logically this particular tool fits into the background of the consultant. For this reader, who has a techno-functional ABAP and SD background, cProjects would fit in nicely, perhaps pushing him a bit towards Portals and Java-based development, and adding either PLM or CRM to the ABAP/SD background. A combination of core and cutting edge skills is always the ideal mix, so in this case, I like the idea of moving in the direction of cProjects. Jon, looking ahead ten years, what would be the best choice, SAP Basis or Security? Also, what is the scope of FI/CO has for next ten years? JR: I always chuckle when I get a question asking me for a ten year view of the SAP market. To be sure, I'm flattered that anyone out there would trust me to give them a ten year roadmap to SAP. But I'm afraid my roadmap would be worth about as much as a trip to the fortune teller. Even predicting the world of SAP five years out is incredibly difficult. The main reason? The corporate economy that drives SAP innovation is hardly predictable. With those disclaimers aside, I'm going to take a stab at this question and get as "futuristic" as I can. Let's start with SAP Basis - what we call "Basis" will be going away sooner rather than later. I challenge anyone to go on the SAP.com home page, or on their Solutions pages, and find a single reference to the word "Basis." It's probably out there, but it's not common. The problem is that there is no obvious term to replace Basis with yet. Strictly speaking, Basis, or "SAP R/3 systems administration," is giving way to "NetWeaver systems administration." But there is no handy abbreviation for the latter phrase. Perhaps some creative person at SAP will come up with something. But putting the need for a handy catchphrase aside, let's look ahead. Clearly, as long as there is SAP, there will be a need for some systems administration. However, I think we can expect a trend of less desktop and on site installations, and more and more remote and Internet-based updates. For the next five years, I think the NetWeaver system admin function will be alive and well, but ten years out, I expect companies to be able to do a lot of what they need online with "plug and play" applications and remote data farms. I'm sure internal systems admin won't go away completely, but I don't really like the ten year "skills demand forecast" for SAP Basis all that well. SAP Security, on the other hand, looks strong. No matter where systems live or how they are hosted, there will always be a need for state-of-the-art security specialists trying to keep up with the latest in hacking techniques and adversarial data attacks. That's the reality that today's CIOs must contend with, and I don't see that changing. The nature of that SAP Security work will surely change, but I do think there will be demand in ten years for this skill set. Keep in mind that SAP Security has always been more of a "tool in the technical toolkit" than a specialization. Yes, there are some SAP Security specialists doing very well in the consulting world, but you might be surprised by how few specialize solely in security. I don't see that changing much. As for SAP Financials, the future of SAP Financials is pretty bright over the next five years. I believe we'll see a couple of upgrade waves fuel the demand for SAP Financials experience. Anytime you see upgrades to SAP's enterprise core, that bodes well for SAP Financials consultants. SAP's push into the mid-market will also keep the need for SAP Financials experts high. However, it's important to realize that in most areas of SAP, we are going to see a shift between easily outsourced, "commoditized" skills, and more cutting edge functions. This shift should affect functional areas as well as technical. Therefore, basic Financials functions should have less "sex appeal" as a consulting skill, but more cutting edge areas within financials such as project and product costing, portfolio management, executive reporting, financial business intelligence, and SOA-driven tie-ins should drive the market. We'll see this phenomenon across SAP, I believe, in the next five years. We can see a good example of this in the HR/HCM space, where basic payroll functions are routinely outsourced, but increasingly, the emphasis in the HR space is on the strategic aspects of HCM such as Talent Management. So that's the five year SAP Financials view. It may take a while for this to take hold in some areas due to compliance and regulatory reporting issues, but I think those things will be tackled. By the end of five years, the SOA-driven enterprise will really have a lot of momentum. Ten years from now, I think SAP Financials consulting will still be a viable field, but ERP as we know it will be radically different, with much more of a "plug and play" architecture than we have now, with different business processes available as components that can be easily installed and reconfigured on the fly. All this points to a functional consulting market where the importance of industry expertise and process knowledge is going to eventually be much more important than the "module configuration" skills that are the key to the functional skill set today. Of course, we're talking about a gradual transition, but we can start on that path by committing ourselves to a deeper level of excellence than mastering some SAP tools and tricks. I heartily recommend the SAP BPX community for anyone looking to get a handle on where the functional SAP skill set is headed. Also be sure to listen to the podcast I did for B2B Workforce on the SAP Business Process Expert skill set with Marco ten Vaanholt, Director of the SAP BPX Community. Finally, I want to wrap up this answer by saying that I don't really agree with the approach of picking an SAP career focus based on this kind of market projection. Market factors are one aspect of career planning, but not the only aspect. If I were choosing between ABAP, Basis, and Financials, I would start by looking at my skills to date: where do I have competencies that would translate well into one of these areas? Then I would look at which areas in SAP I find most compelling. This may sound surprising, but it is better to pursue an area of SAP you find compelling that is less marketable than to ignore your own interests and just go after what is most marketable. The reasoning is simple: over time, we succeed in the areas we excel at, and we excel in areas where we are seriously invested. There are consultants having success in all areas of SAP. For example, while we can say that in general, the APO area is a sluggish area for consulting, there are some APO specialists doing very well right now. They live and breathe the stuff and wouldn't have it any other way. So, now that I've tried to look into a crystal ball, my advice is to throw out the fortune teller and try something more old-fashioned: pursue something you really enjoy and adjust for market trends as you go. Many great SAP careers were built this way. Ask the SAP Career Expert Archive