Podcast: The On-the-Job Realities of the SAP Business Process Expert - with Jim Link

podcastlogo_jonerp.gif"A real-life look at an SAP Business Process Expert - challenges of the role and bottom-line impact"
Podcast Interview Date: July 25, 2010
Podcast: Listen Now!
[PC users: "right click" to download file]

When I met Jim Link at SAPPHIRE Orlando and he handed me his business card, I was in for a shock. Emblazoned on the card was the job title "SAP Business Process Expert." After all the years of talking about this skill set and debating the emergence of these roles, here was a guy living the role day in and day out. As part of the ten person Forest City business process expert team, Jim and his colleagues have a great story to tell about how they are impacting the business and the challenges they have overcome along the way.

During this 20 minute podcast, Jim gives me the project-tested scoop on many key BPX topics, including: how does a BPXer justify their value to the business, who do they report to, what role do process modeling tools play, and what SAP technical and functional skills do they need to succeed in the SAP Business Process Expert role. Obviously, there are no universal answers to these questions - they are still being sorted out on a company to company basis. But for those listeners who want to understand how the pure BPX role can fit into the existing SAP personnel structure, and interact with Enterprise Architects, I trust you'll find this conversation as interesting as I did.

Editor's note: Some additional context for this podcast can be found in the "SAP Project Roles Puzzler" podcast by the Enterprise Geeks I did a guest appearance on earlier this year. The SAP BPX roles - separating truth from hype video I did after that podcast also provides context for this talk.

Podcast Highlights

2:20 Jim's role on a daily basis - meeting with the business users, understanding what their requirements are, plan training on relevant modules, meet with business users, make sure they are aware of what SAP's capabilities are, and that they are getting what they need out of the system.

3:00 How Jim evolved into an SAP Business Process Expert: started as Financial Auditor with PWC. Was invited to join the SAP implementation team by his corporate controller. Have had interest in financial systems since college, and have gained experience in the modules FI, CO, and SEM-BCS, as well as BusinessObjects Planning and Consolidation.

4:18 Is SAP pushing SAP BPX roles prematurely or do we really need them? Jim: I think we do need these roles. It helps to have someone who understands the business side of things, and with my accounting background, with my previous history with Forest City on the business sides of things, I can speak the terminology of the business users, who are really who the system is designed for ultimately. In my role, I can explain the things that need done to the development team, and I can also do the work myself.

5:18 Give us a sense of your team and who you report to? Jim: We've got ten of us in our group, we've got collectively 100 years of experience at Forest City, so we've got some really seasoned people on the team - we all came from the business side of Forest City, and we were all assigned to the ERP implementation as well as BW. To date, we have been focused on our individual modules we worked in previously, but hopefully in the future we can cross-train so we can get more into the end to end side of things. We do communicate really well as a team. We know what the others are working on, and we know the touchpoints between the modules, but in the future, we're headed to a system-wide, end to end process understanding for each person on the team.

6:15 Jon to Jim: That's always been the challenge of this kind of role - encompassing the process-wide knowledge. Right now, each one of you has a piece of that, but hopefully eventually you all develop the process-wide know-how. So what advantages does that give you working with the technical and functional teams? Jim: We've been focusing, as many organizations are due to the economy, on trying to centralize our lines of business, we've got five distinct lines of business as a real estate company, but when you boil it all down, you should be able to get down to one standard way of doing things.

Our business unites are kind of in silos, but we should be executing our processes the same way. We've spent the last year and a half trying to standardize and centralize some processes. Some of the initiatives we have been involved with and are rolling out are really key to getting the information we need out of the system to make good business decisions. Some of those initiatives have really helped us cut some costs as well, and redeploy our assets to do things that are more meaningful to the business.

8:04 Jon to Jim: Part of what I wanted to understand on our conversation today was how the BPXer justifies their value, and you've pushed that to the focal point of our conversation. So how do you do that? In this economy it's not enough to be an innovative process thinkers, you have to be bottom line folks too, so how do you go back and say, "Here's how we saved the business money this year"? Jim: we had some really big initiatives over this past year. When we went live, we had each business unit doing their own thing, which as you can imagine from a support perspective, does not allow a support person to centrally help those five different ways of doing things. We've been able to consolidate our support operation, for example, we've move all of our accounts payable processing to our shared services department. Obviously you don't need as many AP people when you get moved into a central department, so we've been able to deploy some of those AP resources to other lines of the business where they can add additional value.

9:22 Jon to Jim: So streamlining processes saves money, that's the bottom line. Except there is a human dimension to streamlining processes, so you must have some people on your team who are highly skilled at cultural change management and talking people through the process of adjusting their roles and buying into the new processes. Jim: Everybody is well trained in terms of working with our end users and explaining to them how they need to be performing the processes. We also work closely with the learning and development team, they're change management experts - we incorporate them into our process changes as well. We make sure the users are trained on the new way of doing things, the standard way of doing things.

10:10 What was the challenge of finding the right home within the organization? Jim: When we first went live, we were reporting up through IT, and what we found was that didn't appear to be the right home for us at first. The individual we were reporting up to at that point in time - it just didn't make sense. We ended up reporting up through our corporate SBU, reporting up through the same line as our shared services. That didn't work out as well either, reporting up to our corporate SBUs, it didn't seem as apparent to our revenue producing SBUs that we were really at their disposal. So we moved it back into IT, by that time we had hired an Enterprise Architect. Ever since then, we've been reporting up through the Enterprise Architect and it's been a very good fit.

11:20 When we map the process-driven enterprise, the Enterprise Architect plays an important role. What did the Enterprise Architect bring to the project that resolved your line of reporting issues? Jim: He brought to the table a vast knowledge of SAP, 20 years of experience on multiple implementations. That was something we liked - the BPXers were really the hands-on part of our implementation team. For the most part, our IT department did not get involved in the actual configuration of SAP. So in our initial reporting through IT, we were lacking that "homey feel," but coming back in with an established Enterprise Architect, it was a much better fit.

12:45 Jon to Jim: So the Enterprise Architect brought a knowledge of SAP that helped you to map your process flow into SAP? Jim: That's exactly it. We were able to speak "SAPese" with the Enterprise Architect. Speaking to IT people who had limited background in SAP at that point previously didn't work. Jon to Jim: It's not longer a white board exercise anymore, because with knowledge of what the SAP system can and can't do you can map your processes right into the system? Jim: That's exactly right.

14:02 Another question: Jon believes BPXers should have a technical knowledge of SAP. What does Jim think? Jim: at the very least, a BPXer should have a basic technical understanding of SAP, so that you can take the requirements you've received from the business and translate them into functional and technical requirements, and at least work with the technical team to flesh out those requirements so that they meet the business needs. Jon to Jim: You also probably got some good technical SAP exposure working on the SEM-BCS side? Jim: we were kind of left alone on the SEM-BCS side. Working with the SAP consultant, I got a lot of the configuration experience with SEM-BCS. Getting that hands-on experience was vital for me.

16:33 Process modeling - it's often pitched as the heart of the SAP BPX skill set. How important was it to your work? Did you model processes and did you use a particular tool and did it have relevance to what you were trying to do? Jim: we did use modeling of some of our processes, and when we did, we did use Visio. We intend to look at some of these modeling tools that are more comprehensive that link into SAP.

18:20 You're an SAP Business Process expert now, and these new roles seem to represent another possible skills evolution and career path, which I discussed with the Enterprise Geeks on the Project Roles Puzzler podcast - where do you see the challenges and growth? Jim: I'd like to get my hands on other areas of SAP, other related modules, develop more of an end to end view of how they all get wrapped together. Whether I become a BPX lead or become a candidate for the Enterprise Architect, if it opens up in the future... those are the kinds of things I'd aspire to.

19:50 And what are your team's biggest challenges or goals? Jim: we need to get in a better position to upgrade to ERP 6.0 - we're not there yet, we need to improve our cross-functional know how, get the Financials person more familiar with Project Systems, get the Project Systems more familiar with Asset Accounting, and so on. We need to cross-pollinate more. I'm not saying everyone has to be an expert in everything, that's probably not possible, but just to give everyone on our team a firm understanding of how we're using SAP across modules would be a great challenge and a great goal to achieve over the next couple of years.