SAP's telling us there is new corporate world order coming. It's a world driven top down by process and not bottom up by technology. Your IT department may be ready, but is your organization?
The New Corporate World Order
Something about SAP's proposed new corporate world order has been sticking in my craw since the beginning of
SAPPHIRE (I am not sure where my craw is physiologically, but I am sure I can
feel something in it). I didn't really understand what it was until I talked to Ismael
night. Ismael is the CEO of Intalio, the leading open
source provider of BPM solutions. He’s already forgotten more about in-the
field business process design and implementation than I’ll ever been able to
learn. He’s also one of our SAPPHIRE bloggers so he is in the middle of
all our conversations on the SAPPHIRE floor. Here’s the epiphany
that Ismael helped me get to last night:
The major basic premise of NetWeaver, Duet, the move to SOA, the second coming of ERP, etc.. is that your company actually has the infrastructure to connect business need to IT implementation at a business process level. I chose the generic word “infrastructure” because I view the issue as a two sided coin: technology infrastructure on one side, organizational infrastructure on the other. What Ismael helped me understand is that for companies to realize the process-centric vision that SAP is laying out at SAPPHIRE, there are in fact major roadblocks on both sides. On the technology infrastructure side, oddly enough, the issue isn’t that SAP is ignoring the problem. To the contrary, SAP is doing everything they can to bring you the technology infrastructure you need to work at a business process level. This comes in a number of forms: Visual Composer, Web Dyn Pro, industry best practices, ESA services repository, open industry roadmaps, and Solution Manager based business process best practices. Despite the technology advances, the real question is that we’ve all had the chance to do this before. Remember SAP Workflow, PeopleSoft WorkLists, Siebel Workflow, etc..? The adoption rate has anecdotally rivaled George Bush’s latest approval ratings. Given our collective history with workflow, what would make anyone think the future will not repeat itself in the BPM world? I did receive one encouraging and somewhat zen comment about this from Peter Graf last Tuesday. Peter is SAP’s Executive Vice President of Solution Marketing and works for Shai out of SAP Labs in Palo Alto. “Sometimes implementation must be preceded by integration [and we’ve done the integration part for you now].” Woah! Do some serious tech meditation on that one for a second. Maybe our technology answer lies in there somewhere. I promise to get out the crystals and incense and cover the implications of that statement, what it means to the future of SAP and NetWeaver, and how things might be different in a BPM world – all in a technology-focused counterpart to this post. For now, let me focus on the other side of the coin: organization infrastructure.
Before I wade into the details around organizational infrastructure, let me ask you to perform a quick test. Go to three functional people in any department (HR would be a good place) and ask them to define a common business process (the new hire business process would do just fine). I’ll wager anyone that you come back with three very different answers. To go further, Dennis Moore, SAP’s General Manager of Emerging Systems, pointed out another expected result. His guess was that not only would the three people give you different process definitions, but they would probably all start their definition with a different step (and maybe that step would be in a different application). How could this be? You’d think by now that companies would have this process stuff down pat. Well, the reality is that the technology capability to design and manage business processes has outpaced the organizational structure to do the same.
To prove my point, ask yourself who in your company really owns a business process? If you’re struggling with the answer, come at it from a different angle. If you personally have the need for a business process to change, who in your organization do you go to and make this request? Now ask yourself, when a business process changes, who in your organization is responsible for communicating this change and retraining all your staff on the new process? If you’re batting a thousand so far with great answers, ask yourself one final question: are these people paid under your IT department budget or another department’s budget? Ha! This last one was a trick question. Any way you answer that question leaves you with a problem. If business process owners are in your IT department then there’s a great chance they are not talking to the people that matter (employees, customers, business partner, marketplace vendors). If they are in other departments, chances are they know very little about the technical implications of whatever process changes they conjure up. You see, the organizational structures of our businesses aren’t really ready for this process-centric vision of the world yet. Now, if it hasn’t dawned on you yet, consider that you are probably making a huge IT investment into an application platform that requires a process-centric view of the world and you have no formal way to support it organizationally. Again, Whoa!
So what really needs to happen here? Well, the truth is that while you are spending immense amounts of time and money evolving your IT infrastructure to be incredibly process-centric, you might also need to be doing the same at an organizational level. The key is to get someone in place and make them important enough that they fundamentally own all business processes. They shouldn’t be in IT (as the technology tail usually ends up wagging the process dog), and they shouldn’t be distributed throughout various departments (aren’t business processes meant to be integrated across departments?) What you need is for someone to be sitting smack dab in the middle, and I’d argue, reporting directly to the CEO. What you need is a Chief Process Officer.
There I said it. I’m probably not the first (well, definitely not as there is a wikipedia entry already). But we have been thinking about this at Newmerix for quite a long time now. Tonya McKinney, Newmerix’s VP or Marketing saw the wave coming early and did what any entrepreneurial futurist does first – she registered the domain name ChiefProcessOfficer.com.
So why did Tonya and Newmerix get an early glimpse over the horizon here? Well, it was actually quite accidental. Newmerix works directly with our customers at the most detailed level of business process understanding: testing. To understand how to automate the testing of a business process, you need to have it defined at an incredibly discrete level. Remember, while automated testing products are good a specifics, they are not good at figuring out semantics (“When you typed in that date, did you mean today or the last day of the quarter?”) There is a big difference in the way a human describes a process and the actual 30 specific steps spanning multiple applications and screens that it takes to perform the process.
So after three years of experience working with functional users on a daily basis, we have learned to always ask the same question first: please define your business process for me. And I can tell you, I have never had the experience where a customer says “No problem, let me just go to my CPO portal and get the business process map for the new hire process”. Usually a functional user roots around in a file cabinet, pulls out a dog-eared Excel print out, and says “I think this is what I do on a daily basis. Well, at least that’s what I sign off on when I test.” More often than not, they simply fire up PeopleSoft and walk us through it. And herein lies the problem for most organizations trying to realize SAP’s vision.
Good process definition takes both an understanding of the business need as well as the applications and semantics of the data being entered during the process. You’ll find that once you delve into semantics, you quickly become intimately tied to understanding how the application itself works. As an example, dig a few layers underneath the covers of Oracle’s BPEL Designer (their application for process modeling) and you’ll find you need to have a pretty detailed understanding of how each web service works. Just open the web services XML parameter passing dialog and you’ll see how deeply technical this gets when it comes to actual implementation.
How does this tie back to the need for a CPO? Well, not only will you need a CPO, they will need lots of very smart Process Managers underneath them. Ismael offered the term “Process Analyst” during our conversation, but I’ve come to realize the management aspect is so fundamentally important as well here. Not surprisingly, a quick Google search on “Process Manager” comes up with about 15 products named “Something Process Manager” but no descriptions of available jobs openings with that title. A Process Manager in my view needs to have a unique mixture of technical and business skills. If you’ve got business analysts, this is who they would report to. Wikipedia actually has a very good description of the Business Analyst position, with a heavy emphasis on a background as an engineer or similar technical position. With the coming wave of business process modeling applications, you’re going to need someone with the technical chops capable of working with the IT group at this level.
To some extent the closest analogy to a Process Manager would be that of a Product Manager. Wendy Lea, Newmerix’s CEO, offered me a great quote about the attitude of Siebel (to whom she sold her last company) towards hiring Product Managers, “They [Product Managers] were some of the smartest people in the building.” And keep in mind, they reported to marketing, not IT (no intended offense here Tonya, my point is that they were intentionally not part of the IT function.) You see, good Process Managers, just like good Product Managers, would have to split their time between a number of competing interests: speaking to process constituents (customers, internal users, process partners, etc..), managing the overall vision for how a process fits into the evolving business landscape (process are meant to integrate departments together), and working with their business analysts to define the process semantics at the technology level. And more than anything, they need to be good change managers. Consider the future you are embarking on. You’re going to have 1000s of business processes to maintain. And in an SOA world, not only will they be interrelated at the process level, but now they will be interrelated at the technical level too. Changing one process step might actually affect 100s of overall processes and thus the users and partners that are involved in them.
Let’s consider a simple example: finance decides that every new vendor must have a credit check performed on them before they can purchase your products for their inventory. Not a big thing to ask. But what if you are working with 2 and 3 tier VARs. Can the credit of these VARs be considered valid credit for their redistributors? If the VAR has a similar credit checking facility in place, can they forward their distributor’s credit credentials to you? What is the format? What credit checking services does your company allow versus what your VARs may use? What new information would be required in the vendor sign up process to ensure a credit check can be performed correctly? How often should credit be rechecked (if they pass once, do you never need to know their current credit status ever again)? Think of the number of processes that would be affected by this potential new process requirement from finance. It’s not about technology assuming you have the technical requirements to slap in a credit checking web service. This should be easy if you buy into SAP’s or Oracle’s SOA vision. It’s the tough part of understanding how it affects the 100 processes related to vendor purchasing. Change management, retraining, VAR communication. It’s all very complicated and will need a focused group of people in your organization to keep it straight.
So what is the world going to look like if you go down the path of hiring a CPO? The first thing you’ll need to do is give them their own budget and team. CPOs will become successful if they can accumulate the necessary knowledge from all departments in the company. Reassign the army of business analysts you have to the CPO budget. Find the right Process Managers to organize them, and empower the CPO at the executive level to weigh into your ever accelerating business transformation at a powerful level.
Second, your CPO will need to get all of your business processes into a standard form. There are numerous tools to start doing this, many of which can now exchange data in common formats (the BPEL standard is a blessing here). This will be a lengthy process as many times process knowledge is really just tribal knowledge - the nooks and crannies contained in many disparate users’ heads. Only if you write it down, can you change and manage it correctly.
Third, you’re CPO will need to invent a standard Process Development Lifecycle (PDLC). There are some great lessons to be learned from the history of Software Development Lifecycles (SDLC), but ask anyone involved in it, and you’ll see there is huge debate over the waterfall/agile methodologies that are emerging. I expect these debates will infest the PDLC conversation as well. As a side note, one of the things that I hope SAP does with its increasing Lifecycle Management focus is to conceptually extend this to business process management as well. Talking to Matthias Melich, Product Manager for SAP’s Solution Manager product, I get the feeling this is on the horizon, but we’re still a ways away from any formal approach.
Fourth, last, and possibly most important, is that in today’s compliance-nervous environment, the CPO will need to own SOX compliancy effort across your ever changing business process landscape. This in fact could be a good enough reason to put a CPO in place. Talking to many packaged application owners, the early days of SOX compliancy have created a schism in organizations in terms of who owns compliance. For some organizations, the finance department carries the ball (SOX 404 is heavily focused on finance related changes), for others, it is the IT department who’s responsible. For most though, there is a little ownership in both camps. In fact, Newmerix Automate!Change product has found an immense amount of interest in IT departments tasked with managing their compliance exposure during the Application Change Management (ACM) process. The need for centralization of this activity is clear, and the CPO is just the right person to manage it. To that end, one of the announcements at SAPPHIRE that I found encouraging in relation to the rise of the CPO and the PDLC function was that SAP has created a complete business unit around compliance. While they have not yet ascribed its birth to the organizational necessity of having a CPO yet, I can only imagine this will be the case in hindsight. In general, it is rare for large companies like SAP to have business units without a specific buyer (or budget) in mind and the CPO sounds like just the right buyer to me.
Who knows if I will be proven correct about the organizational need for a CPO. As I look at it, all the right signs are there. Historically, business change happens both at a technology level and at an organization level. Yes, some organization shifts are only temporary (you’ll be hard pressed to find the title of Web Master in many organizations any more). But remember, before businesses came to depend on IT as the heartbeat of their organization, no one had ever heard of a CIO.
I hate it when I scooped! I swear I didn't read this before I wrote my piece. That's what I get for sitting on my thumbs for a few days after SAPPHIRE. Check out SAP's Business Process Expert addition to SDN for more. But hey, we still own ChiefProcessOfficer.com!