Deciphering Procurement Systems and Tools (Part 3 — Moving Forward)

Spend Matters welcomes a guest post by Len Prokopets, and Bob Derocher, Principals with Archstone Consulting (part of The Hackett Group) and Pierre Mitchell, Director of Procurement Research and Advisory at The Hackett Group.

In the first two posts on this topic, we covered the current environment and how we got here and discussed key elements of a Procurement technology footprint. These posts outline the myriad of choices, considerations, and pitfalls that Procurement groups face as they consider technology options and navigate the Procurement technology market.

In this final post of the series, we provide lessons-learned, guidance, and recommendations for successful navigation of the Procurement technology path:

1. Procurement Technology is an enabler, not an end-point
Even enlightened Procurement groups can become overwhelmed and confused when assessing technology options. Frustration can quickly set in when facing too many vendor claims, few true success stories, and too many possible paths. We recommend addressing several key questions to point the way:

  • What are the key business benefits targeted? Few organizations have fully achieved desired benefits through technology implementation because many hurdles stand in the way: acquiring the right tool, integrating with current systems and data, configuring capabilities, and scaling the implementation across users, suppliers, functions, regions, etc. Clear definition of the specific benefits desired up front is essential to achieving them later.
  • What new or improved business capability will enable those benefits? It is essential to begin with a clear definition. As we previously described, the broader Procurement market has not landed on a mature definition, and systems vendors claiming to offer these capabilities have, to date, done a poor job of pre-assembling and pre-configuring their tools for out of the box capability support. Be prepared for a long and arduous process of mapping, assembling, and configuring tool components into something that supports your desired vision.
  • What are the requirements for enabling desired capabilities? Some vendors claim capabilities such as SRM, Category Management, or Risk Management without actually meeting requirements. A key step for organizations is to detail the functional and technical requirements associated with the capabilities they seek to enable. Only then can vendor claims be examined and alternate approaches be compared. In particular, a major pitfall is the ability to scale Procurement solutions broadly (across suppliers, categories, users, etc.). In addition to defining basic functional and technical requirements, it is essential to identify the requirements for fully scaling the solution. Still, the technology requirements are only half the battle to achieving the benefits, especially since the ROI is built on technology-enabled change, not the technology itself. For example, a spend analysis tool has Zero ROI on its own. Rather, it should be bundled into a broader sourcing, compliance, and demand management change effort to fund it.

2. There are many ways to approach Procurement technology (but some are easier than others)
Procurement capabilities can be assembled from a single best of breed system (e.g., Ariba or Emptoris), from an ERP package (e.g., SAP, Oracle), from multiple niche best of breed providers, or from custom-built components (or, most typically, a mixture of the above). The particular path selected plays a major role in robustness of capabilities, overall project economics, project risk, deployment time, and IT resource impact.

  • Which emerging best practices are applicable?
    While end-to-end success stories are scarce, technology best practices are emerging. Identifying, understanding, and leveraging those can help mitigate risk. Procurement groups should identify early adopters of advanced Procurement capabilities and understand the capabilities adopted, technology enablers, and lessons learned. For example, we spend a lot of time helping clients design their overall Procurement architecture to have "loosely coupled applications, but tightly integrated information" to enable flexibility in choosing best-of-breed approaches without "application anarchy" so feared by IT.
  • What capabilities are available from existing tools?
    Once requirements have been identified, it is important to understand what requirements can be met with tools on hand. Most organizations own a surprising array of tools, including systems for Business Intelligence, ERP, document management, portal technology, team collaboration environments, etc. In many cases, the functionality of existing tools is as good or better than corresponding components in specialized procurement systems, and they don't have to be mutually exclusive. There is no reason why MS-SharePoint can't co-exist with ERP or spend management suites. Understanding what is available and how it maps to requirements will enable a smarter ultimate decision.
  • Does the organization take a "why not SAP (or Oracle)" approach to technology?
    Many large organizations have distilled their years of technology strategy decision-making into a simple credo of using the corporate standard ERP when possible. It is certainly possible in the Procurement space, but the cost can be higher and the functionality limited. If that is your organization's path, be prepared to make the case for needed point solutions to fill in any gaps until your ERP vendor's procurement capabilities mature.
  • Is SaaS an option?
    As we mentioned in our earlier posts, SaaS has become the predominant Procurement systems model. This is with good reason; acquisition costs are lower, IT resource impact is lower, functional upgrades tend to be faster and easier. However, flexibility can be limited, whether the solution is truly a standardized software offering or simply a hosted system instance. We believe that SaaS will continue to dominate and will benefit from further evolution and innovation in cloud-based computing. So, if SaaS is not an option today, it may be in the future.
  • How will the supply base be on-boarded?
    Several areas of Procurement systems are dependent on linkage with and adoption by suppliers (e.g., score-carding, collaboration, supplier data management, etc.). Developing a strategy, cost model, and communications for supplier on-boarding is key. Established supplier networks (e.g., Ariba's Supplier Network) can play a major role in this area, enabling the major linkages required. In fact, we have seen clients with ERP-based procurement environments include 3rd party supplier networks as part of their overall solution.

Addressing these initial questions is critical to making effective decisions in Procurement technology. In addition, a variety of secondary questions should be addressed on the path to Procurement technology enablement including:

  • How will spend, supplier, and performance data be managed?
  • How should systems capabilities be deployed across the organization?
  • How will Procurement systems be integrated with existing systems and data sources?
  • What level of training and education will be required?

Looking forward, information and intelligence will be fundamental to procurement's success as a "solutions assembler", so procurement will need to develop a strong technology management competency in order to elevate itself beyond the "plumbing" issues with procurement technology. Procurement must view the procurement technology market just like any other supply market and apply all of the appropriate best practices to tap that market power in the short term, but also coherently reconfigure the technology footprint in the longer-term, and tie it into a broader procurement transformation effort. This is no small task, but the art and science of procurement transformation is what we as practitioners do to justify our value and have fun along the way.

- Len Prokopets, and Bob Derocher, Principals at Archstone Consulting, and Pierre Mitchell, Director of Procurement Research and Advisory at The Hackett Group

Discuss this:

Your email address will not be published. Required fields are marked *