Back due to popular demand: We're bringing this Plus series out from behind the paywall so all procurement professionals can start using design thinking to inform their procurement architecture — and learn how user-focused software enables this process. Read the first three installments in the coming weeks, or download the white paper today to get the full story all in one PDF!
In the 1980s, GM learned a difficult lesson about technology when it copied Japanese auto manufacturers in their use of robotics — but didn’t copy anything else. GM figured that large capital investments in expensive technology were the key design element in the Japanese supply chain. Unfortunately, the technology itself was complicated and was not used within the context of a broader supply chain design that emphasized lean manufacturing principles. These principles translated customer-focused product design (e.g., value engineering) back to supply chain attributes of value flow (with no waste), simplicity (insofar as to reduce waste) manufacturing flexibility (via fast reconfiguring of smaller machine tools), and process enablement and improvement through empowered process participants.
Now, consider not just a physical supply chain of cars to consumers, but rather, the flows of products and services into a corporation and then back out to its customers. As supply chains externalize and digitize at breakneck speed, procurement organizations are struggling to design their operating models to keep the value flowing at the speed of stakeholder demand and volatile market supply. Even just within the “sourcing factory” or “savings factory,” sourcing managers are trying to see and shape demand rather than just reacting to it.
Just as world-class supply chains are agile and flexible by design to cope with product demand uncertainty, world-class procurement organizations must similarly design agility into their “services value chain.” The problem, though, is that so many things are broken. Take the GM example and the giant monolithic robots it purchased to solve its problem. The machines were so complex that when they broke down, the value stopped flowing, and complex services were needed to fix the complex machines. GM’s Japanese counterparts, however, empowered their workers to be knowledge workers that could own and reconfigure modular tooling as demand changed.
Now consider the “procurement services factory” and how older-generation on-premise ERP suites could be considered the big robots (or, more aptly, the one-size-fits-all, six-axis machining centers). For these mega systems, it’d be easy to cite issues such as the infrequency of software upgrades, the implementation challenge of those upgrades, the lack of configurability to support many unique spend categories or industry-specific needs. But the bigger issue is not just about software TCO or implementation time, but rather about the impact on procurement’s agility and its ability to add value at the cadence of the business. This in essence requires the mass customization of procurement services to deliver flexibility that goes far beyond simplistic center-led models.
Adding value means not just performing sourcing efficiently with minimized waste but also helping solve problems — i.e., moving from an internal services provider to an internal “solution provider.” This term might seem uncomfortable, but having stakeholders view you as a partner that helps them solve their problems is not a bad thing. This is the same issue with SaaS providers. Just serving up software over the Internet doesn't make it a solution. Software is not a solution until it’s used to deliver actual value.
So, the question then becomes how to most effectively translate procurement services and procurement software into a procurement solution that stakeholders value? The answer lies in design.
Many people use the term “innovation,” but if you look at the process of innovation, it does tend to focus on the design process. Design is typically associated with a process to create products (and services and everything in-between) for customers. But, it is much more. Wikipedia defines design as “the creation of a plan or convention for the construction of an object or a system.” Note that the word “system” can have two meanings: a software system or a management System (with a big “S”). So, the convention for building a top notch procurement software system or a procurement management System — often called a procurement operating model — is based on a set of principles that are best explained by example rather than a long treatise on industrial design.
As such, we decided to write a series on how design-centered thinking can be applied to not only product and service design, but also to the design of:
- the supply chain creating the products and services
- the procurement organization itself as an internal services-based solution provider
- a platform and portfolio of software-based and services-based solutions that procurement deftly taps and embeds into its agile operating model
We’ll examine lessons learned from consumer facing technology and services, and then also show where such design is being applied within B2B procurement, both for procurement organizations and for supporting solution providers of all forms. It’s an extensive series that we’re excited about. We hope that you enjoy it as well.