An Interview With Deb Boykin: Associate Director of Process Excellence, speaking about BPM and its affect on leadership, culture, and the individual striving to become a part of the BPX community
Marilyn Pratt: Hi, this is Marilyn Pratt, Community Evangelist of the Business Process Expert Community, and another installment of our podcast series. I’m here with Deb Boykin, Associate Director of Process Excellence at one of our pharmaceutical companies, who has a very rich background in business transformation, and expertise with the ARIS toolsets. Some of you might have heard her in a recent webcast that she did for ASUG. She will be speaking with Patrick Fitzgerald, who for the last few months has been interviewing customers, partners and employees engaged with the BPX and business processes improvement activity. Patrick?
Patrick Fitzgerald: Thank you, Marilyn. Hi, Deb.
Deb Boykin: Hello.
Patrick Fitzgerald: I’d like to just start off with the first question. I understand you’ve been working with SAP Solutions for about seven years now, and you come to them in the context of Business Process Management (BPM) and process-focused business transformation – something you’ve been focused on for a much longer time. So before we get into specific tools, I wonder if you can talk about BPM in general and how you came to it?
Deb Boykin: Well, actually I’ve been doing BPM for the past seven years almost – and how I actually came into it? I didn’t come directly into it. I actually started out in the BPM arena in the context of business process architecture, and when I was at my previous assignment which was with a beverage company, I was hired on actually to fulfill a need of a tool vendor – that being the ARIS product suite from IDS Scheer. This particular beverage company had just purchased the product, ARIS, and really did not have any expertise in how to actually leverage the tool that had been purchased. So, with that, I was brought in and asked to develop a new program for documenting the business processes. As I was doing that I did create a methodology and in the steps of going about creating this documentation to leverage ARIS, it became apparent to me that it was more than just doing process architecture, that there was a much bigger area that needed to be addressed. So with that, I pretty much just started using the word “business process management,” because it needed to be managed. So, I just started using that whole vernacular. And it actually caught on within this organization because business process architecture, while needed and certainly is extremely important, is not the only role that it takes to perform business process management. So, in regards to your question, how did it come about? Well, it was just pretty much an evolution from business process architecture into a greater need.
Patrick Fitzgerald: OK, what do you see as the distinction, then, if we can dig down a little bit more, between business process architecture and BPM?
Deb Boykin: Well, I see, again, I see BPM as the umbrella. And it is the thing that we do in order to manage our business processes within our organization, and it’s kind of like – I just read an article recently whereby, it was talking about BPM as a body. In order to make the body work we have many different functions, and these functions, these bodily components all have to work well if we are going to lead healthy active lives; and it’s the same within a company. If we do manage our business processes well, we are going to be able to compete a lot more aggressively within the marketplace. If we have underdeveloped processes, we are not going to be that competitive within the marketplace. And so in terms of looking at what it takes to actually perform BPM, business process architecture is definitely one of those components, but there’s a lot of other roles that have to be addressed in making BPM work. These roles reside both within the IT community as well as the business community.
Patrick Fitzgerald: That was one of the things that interests me, is the sort of split, say, between the technical side and the business side. I wonder if you can talk about that a little bit. How real is this split? How does it play out? Do you think one side should be in a position of driving a BPM initiative with the other side playing a supportive role? What tools exist to bridge the gap? That’s sort of thing.
Deb Boykin: That’s a very good question Patrick, and I don’t think I am the ultimate authority to have the final answer on that, so I think, again, it becomes a cultural issue, in how to best leverage BPM within your organization. But from my experience, what I’ve seen is that most of the time within the organizations that I’ve been a part of there has not been a clearly defined area for housing BPM itself. There have been business process owners well defined. There has been the business process steward or the process governor type role which is a part of the business community. Then there’s also been the process architect – and the process architect normally resides within the IT department. I have seen it within the HR area, so again I don’t think there’s any hard and fast rule on where these roles actually reside. What I do think is important is the fact that they are defined, and that an organization understands clearly what roles are required to make BPM work effectively. What I have seen work best is when your business architect does reside within the IT department. Now the reason I say that is because I think part of the role of the business architect is to bridge the gap between IT and the business, and it seems like from my experience that it’s easy to get the business to understand the need for business processes. It’s been a little bit more difficult and challenging to get IT to understand the value of the business process and a lot of times what we see within the IT site is the fact that they just want to document the processes at a transactional level or they only see the system side of things, and I think that’s been part of the problem in fully documenting our business processes from a business context. A lot of times that business context is misunderstood or it’s just left out completely. So, I think it’s very important that we get the entire landscape of the process defined and again, like I said, it takes many different roles contributing to the BPM space. Also I think as the maturity of an organization grows within BPM, you’re going to see a lot more IT roles coming into place. One of the things that we’re doing at the pharmaceutical company I’m now with is actually looking at pushing our process data out to the individual workspaces who are responsible for leveraging certain processes. What that looks like is that we’ve got processes defined and what we’re doing is working with the IT folks to create portals, and within these portals then the individual would come in to perform their work on a daily basis, and this portal would provide the information for the particular process that they are responsible for. So again I think you’re going to start seeing more and more of this instead of individuals being responsible to go after the information to do their work, the information is going to start coming to them. To me this is the ultimate of what BPM is all about – when we can start linking the business and the IT together in a way that provides a seamless transition and transparency to the individual doing the work, because overall it’s all about making a decision and getting the information into the users’ hands for them to be able to perform their job in a very effective and efficient manner.
Patrick Fitzgerald: I’ve thought that there would be some anxiety, say, on the business side in trying to deal with some of the technical issues. This goes to the point of bridging the gap – and by the same token yes, the IT folks will have a tendency to focus on transactions and technology and that sort of thing. So yes, there is a need to bridge the gap. On the business side, do tools exist for, say, a business user to define a process and build a process? And how far can that business person go on their own, without engaging IT?
Deb Boykin: Well definitely there are tools available. There’s quite a few tools available on market, and again you can give a tool to anybody but what I would caution is the fact that there has to be a well-defined methodology in order to design your business processes. Part of my past experience with the beverage company situation that I initially entered into was that there was a lot of different methodologies floating around that organization on how to develop process. Some of the methodologies supported a bottom-up approach; others supported a top-down approach. And as you can well imagine at the end of the day, there was not a lot of consistency, and there were a lot of areas where the processes did not integrate well, and reuse was very minimal. And so in order to leverage your global processes it really takes a very well-defined methodology, and it also takes some governance somewhere within the organization that’s actually watching the development of these business processes. Again, I am a big advocate of developing the processes from a top-down perspective. The reason I say that is because it’s very difficult for individuals who are not familiar with the business or the business process to come in at a bottom level and try to fit them into the context of something when there’s no information available in terms of what’s going on basically. To me it’s much easier when you come in from the top-down perspective being able to understand clearly where you are within the context of the certain area that you’re looking at, and then drill down for subsequent levels of details.
Patrick Fitzgerald: I’m wondering if we can sort of define terms. I’m assuming bottom up is IT driving the process and top-down is the business saying OK, this is the way we want the process to be – and that’s filtering down to IT and then IT delivers the service, is that correct?
Deb Boykin: Well, you know, I don’t know if I would say IT or the business. You know, it seems like it’s worked out that way. IT coming up bottom-up because of the transactional level that they are SAP oriented but a lot of times what I’ve seen is more the [Microsoft] Visio-based diagramming. There’s no rigid rules on how to perform leveling, how to perform architecture, tribe-related activities and I liken it to the old programming days prior to structured programming. Back in the seventies before structured programming came about or was introduced, you had people developing computer programs and basically what you had was spaghetti code, and they were going all over the place. To me what I’m saying is that we’re kind of making the same mistakes when we’re developing business processes; there is no structure, there’s no governance to how these designs are to be put together, and therefore you’re coming out with a spaghetti code mess of a process. I think it’s just a very important that you have rules that you follow in terms of how you go about designing your business processes, and that they’re well understood across the organization. Within the beverage company that I actually worked at, one of the first things that we did was to define a top-down design method for creating our process maps. That particular methodology was communicated across the entire organization, and it worked quite well for integrating the process information. Also from a reuse perspective, all the business processes and process components that we developed were all developed in like manner. It was very easy to snap those components together so that we could interface from one component to the next.
Patrick Fitzgerald: We’ve been talking about tools a little bit, and I’m wondering if you can talk about the tools that you use where you are today?
Deb Boykin: The tools that I’ve been primarily using is the ARIS tools from IDS Scheer and I use the Business Architect and the Business Publisher for publishing the processes that we are actually designing. We’re looking at some performance monitoring tools from IDS Scheer. PPM. We’re also looking at the BI Modeler tool in order to more effectively manage our KPI information. Those are kind of coming down the road, but the primary tool like I said is the design tool, ARIS, that we are using. Again this is just for the design portion of the whole BPM lifecycle, but as the organization matures we will certainly be moving into more advanced tools so that we can actually monitor the health and performance of our business processes.
Patrick Fitzgerald: Right, so this gets you into monitoring and a continuous improvement — that sort of thing.
Deb Boykin: Absolutely. And also, I failed to mentioned, we are a big SAP shop, and so we also use SAP Solution Manager and we are synchronizing from the Solution Manager product to ARIS and then back again.
Patrick Fitzgerald: So the ARIS tools as I understand sort of plug into Solution Manager?
Deb Boykin: Yes they do.
Patrick Fitzgerald: Can you explain how they are integrated or how you might use one with the other?
Deb Boykin: The Solution Manager takes care of the IT side. This is not an area where I am a real expert in, so I’m going to stay away from that a little bit. But the premise here is that in order to configure a system you really want to start with your business requirements. The business requirements are actually developed within the ARIS Product Suite. What you want to do is design your business requirements in terms of a graphical design. Once that graphical design is stabilized then you would actually do what we call a synchronization into the Solution Manager product. Once that information is synchronized over into Solution Manager, then the configurators can actually take that information and configure the SAP models in response to the business requirements of that end user.
Patrick Fitzgerald: Well then finally something that should be of particular interest to SAP BPX community members: What do you see as the career path for a BPX expert? To what extent are companies getting serious about defining the role of BPX, and what is the skill set required? What training exists if any — that sort of thing?
Deb Boykin: I think we are just touching the tip of the iceberg in this particular area. I asked last year at Process World, Gartner Group was talking about the need for a BPX career path. Right now in the company’s that I’ve been associated with, very little is being done in that particular arena. However I do think it is gaining momentum, and I think organizations are starting to see the need for a well-defined BPX career path. Right now I am seeing a lot more emergence of the business process architect, and getting those positions defined, but I also think that there’s a lot of other roles that need to play into this as well. I think within the SAP community, our configurators, our process leads, our processing centers, there’s just a host of roles that need to be defined, and that do contribute to the entire BPM solution. At the end of the day, it would be nice if we could come up with a list of those roles, and the actual competencies and skills required to score each of those roles. In terms of training, I do know that there are several universities around that are actually starting to develop postgraduate work in the training fields, but again, those are few and far between. And I just think this is an area where there’s a lot of opportunities. I applaud the BPX community on what they’re doing here, because I think this is a good way for helping individual practitioners understand a lot more clearly what it does take to actually implement a BPM solution. I think BPM – when people think about it – sometimes they think only the roles that are involved. Again when we look at BPM, I think it’s much broader than that. BPM itself affects leadership, it affects culture, it affects the individual who is striving to become a part of this community. There is a very specialized area of expertise that is required, and I just think it’s going to take some time. I don’t think it’s going to happen overnight, but I think we’re definitely on a journey, and I think there’s a lot more to come in terms of BPM and this overall BPX community.
Patrick Fitzgerald: All right! Well this concludes our interview. Thank you for being here with us Deb.
Deb Boykin: You’re quite welcome.
Patrick Fitzgerald: I’d appreciate having you. Bye bye.
Marilyn Pratt: And thank you both for this ongoing series on business process experts and expertise.