The New Corporate World Order

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 Ghalimi last 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.

---

Author's Post-Amble:
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!

Comments

[Jon Bellman]

Organizations doing process improvement (or a rose by any other name) or large technology deployments when there is no urgency amble around the critical path rather than finding the rails. Process work makes sense in a business in which most of the variables are relatively static and there is a true opportunity to measure for improvement. In a rapidly changing environment, both process and technology often obscure the customer's requirements of the moment.

Spend the money on hiring better salespeople. The best process improvement opportunities present themselves on the fly.

[BigJim]

There is a best practice for simplifying business processes. It's called the KISS principle (keep it simple and straightforward or better known as keep it simple stupid). I'm consistently amazed and astounded at how complex some business processes are if for no other reason it makes for easier reporting at the executive level. The acrobatics that the underlying technology underneath has to go thru seem to be meaningless, even if it's sucking away dollars from the bottom line because of consulting and implementation costs.

Another thing that makes me wretch is the whole "we make the technology fit the business, not the other way around" approach most executives, at least the old school ones, still have. You bought SAP, your entire business RUNS on SAP. Last time I checked, SAP is a technology platform with boundaries and constraints. It's not a piece of playdoh that you mold to your liking. The companies that did that are still searching for the ROI from the initial implementation and are maintaining armies just to keep the system running. For that, build your own ERP system. They aren't separate children where one is more important than the other. They are siamese twins joined together and decisions need to be made considering both, not just one in a vacuum forcing the other one to adjust.

My .02.

[Steve Walker]

Niel,

My years of ERP experience have led me to agree with your stance on process management. Customers seem very reluctant to change processes but more than willing to do custom program development. True, we don't want the technology tail wagging the process dog but over and over again I see companies failing to seize the opportunity for process improvement. And I think you've hit the nail on the head as to why - people often do not know why a particular process is the way it is. They simply do it the way the person before them did it and don't question why. They don't want to challenge it because they don't own it and are afraid of the consequences of doing so. The CPO role, in my view, is a big step in the right direction.

[Jason Wood]

Niel,

I applaud the journey but I'm not sure I agree with the destination.

We're in an IT constrained environment, spending isn't increasing and CIO/CTOs are being asked to do more with less...what companies are going to OK the creation of a new layer of CxO complexity?

[Dennis Howlett]

Nice idea but I can't see how this is practical. SAP is offering a proscriptive approach to the issue of managing that most volatile of commodities - human beings.

I don't believe there is such a thing as a generalised 'best practice' for any process, except at a moment in time. Then circumstances change and poof - you're off again, trying to figure the next best practice.

If current developments around the edge are teaching us anything, it should be that people adapt rapidly to change, especially when they're offered simple solutions - eg any of the 37Signals stuff, wiki, blogs, podcasts and video blogs. Not as a social media experiment but as a way of communicating how the job gets done or plugging a nagging gap.

Surely the requirement therefore is to capture the distilled wisdom/knowledge of that coming from the bottom up and incorporate THAT into our so-called process maps.

We've had 15+ years of SAP imposing processes upon large enterprises. Has it delivered value? If it hasn't - and most would agree ERP implementations have only delivered one shot cost savings, then I'd argue this is a flawed approach. Unless SAP knows something about top down management the rest of us are missing. The last time I checked, it reeked of mushroom compost.

[rk366]

This sounds very similar to the argument for the CASE tools in software development in early and mid 90's, very top down process. Good luck with the CPO trying to define "the" best process and trying to get the buy-in from business/operational owners. SAP will defnitely create a business unit around compliance as the less agility required in the business process the better for them :)