I’m sitting in on a panel discussion today with two long-standing industry pros (consultants, not CPO-types) at an all-hands procurement department meeting for a large company. The panel is broken down into 3 sections followed by a Q&A – I’m looking forward to it. Many of the questions the moderator is planning to ask are great topics for discussion here at CPO Rising too. For example –
Q: What are the most important/common challenges facing procurement organizations today?
A: When you talk to procurement organizations large and small about the primary challenges that impede that group’s ability to “take it to the next level,” certain common themes rise quickly to the surface. We’ll talk about a few over the next couple of articles and the strategies that leading CPOs employ to overcome them. Here we start with one that remains near the top of the list in good times and in bad: the misalignment of systems and processes.
It is a major challenge for many enterprises and one reason why the adoption of supply management solutions is as low as it is – the automation of the entire source-to-settle process within the Global 2000 remains the exception and not the rule – (Sidebar: How many of the G2K (do they call them that?) cut manual payroll checks, send interoffice memos, file their Q’s and K’s using only excel? That manual functions are viewed as acceptable for sourcing/procurement is one of the reasons why I began this site and my new firm – our goal is to work with procurement leaders and the solution providers to change this situation for the betterment of both sides).
But, where the problem really rears its ugly head is in the generally poor adoption and usage of solutions after they have been deployed (another primary reason for the new ventures). While this challenge is universal, some of the underlying causes of this misalignment have shifted over time. Let’s turn back the clock to the mid-to-late 90’s when the first supply management solutions were brought to market. At that time, the promise of process automation for the standard enterprise sourcing and procurement processes was compelling. Unfortunately the solutions, in general (not all) could not deliver and support the underlying business process in a way that enabled broad adoption – the problem was with the technology and many procurement organizations used and lost political capital in the implementation and launch of these early systems (many of these initiatives did ultimately succeed, but they fell short of what could have been accomplished). A few years later the technology marketplace had changed to a point in the mid-2000’s where many (not all) solutions were relatively elegant in how they could support unique and/or complex processes (Sidebar: The advances in technology continued in the second half of the last decade with improved front-end functionality and with major strides in many of the back end capabilities like those tied to integration and application administration – increasing the speed of deployment and levels of adoption).
In my years working on process design (sourcing primarily, but some P2P) and the implementation of solutions (both sourcing and P2P) with companies across a range of industries (almost always large enterprises – revenues > $5B), I tended to see two approaches to process design. We’ll talk about the first today and conclude (on Friday) with a discussion of the second and include suggestions on how to avoid them.
The first approach was to turn the specific process over to the design experts and let them have a field day. The typical result was a process flow that was dynamic, detailed, and robust….. but, also wildly complex, completely over-the-top, and reminiscent of no process ever completed in that enterprise’s history. At one client, the strategic sourcing process was so complex that they had to print the final design on a special printer that could handle a double-wide legal sheet – ask my friend, Marty Melvin, when he gets back from vacation, if you don’t believe me. While the need for a special printer was a one-time experience, a baseline process with layers upon layers of complexity was all-too-common.
In many respects, that process design result is understandable when you put internal process experts (who are not always the process practitioners) in a room with technology consultants who are eager to show that their solution “can do that” and external process junkies who bill by the hour.
Does this sound like the process design projects at your enterprise? How has your team tackled the universal challenge of misaligned systems and processes?