The Value Proposition for Integration: eProc and eSourcing for Purchasing Utopia?
|The Value Proposition for Integration: eProc and eSourcing for Purchasing Utopia?
by David Bush
November 7, 2007
I have been on the strategic sourcing side of procurement for quite a long time now and my knowledge center for the tactical side has grown steadily over the years. However, I have never been closely tied into it, so I have been trying to diagnose the value across the spheres of functionality and whether there is a value proposition to a question I hear occasionally regarding the business case for integration between eSourcing and eProcurement. I have been trying convince myself of the procurement nirvana which is seamless systems all working in harmony. I've even thought of an example:
An organization goes through the requisition process over a short period of time for something like laptop computers. As the numbers grow during the period, a critical mass is achieved where the sourcing team can issue a competitive bid using the data collected over the past week or two. The resulting auction or RFP then is concluded with a true market price at that moment. This is a fantastic idea in concept but the problem is that you need to be the US Government to actually pull out enough volume that you can source that way. To me, this is more of a slick PowerPoint slide than a practical application.
Since we now employ numerous individuals that come from both backgrounds, I immediately turned to one of my colleagues who has had years of experience in this area to get her thoughts on the topic. Various conversations led to the following summarized thoughts:
- Most large purchasing software tools today are complex. Whether that is exclusively because of integration or not, no one will deny that integration raises the level of complexity.
- This complexity makes it difficult for us to learn these tools, adopt them and make them a common practice. After all, we all want tools that make life easier, not more complicated. So from the get go, there is an inherent problem with – what I call – ‘integration illusion’. Isn’t adoption the key to streamlining processes, achieving additional cost savings and ultimately showing a positive ROI? You’d be surprised at the number of companies I talk to that spent millions achieving some state of integration so they can run reports that show that most users are not utilizing the software. Why? Because it was never intuitive in the first place.
- The base of suppliers is always changing so getting suppliers to understand all contingencies associated with a fully integrated tool is nothing short than frustrating. An example: Why is a Tax ID number needed to do an RFI for a supplier that a company may never do business with? When adding suppliers to an integrated software system, one has to collect all kinds of information from them prior to sending them the RFIs so they can be “enabled”. I thought that was the whole reason for the RFI in the first place, to ask them questions like - what is your Tax ID number?
- Data is as good as the person who keys it in. Most of the time integration only brings already “murky” data from one system to the next. It is already difficult to get good, clean reporting data and integration only makes it worse – what system did the data come from? Where do we clean it up? How do we keep both systems updated?
- The decision makers are typically not from a procurement background and the key drivers are financial and/or IT led. All this complexity requires an army of permanent resources to maintain, support, and oversee. So, large integrated systems are cumbersome, hard to learn, and hard to maintain….Integrate – why? This seems like a whole lot of work with minimal return.
- e-Sourcing does not need a lot of data from e-Procurement and vice versa. POs, Shipments, Invoices - although all important and used as data points in the sourcing process, do not have to be gathered via large scale integration projects.
- Large integration illusions are great in theory and make for a good sales story but most of the time they are not applicable in real life. If you were starting a new company from scratch, then maybe you could model your processes around these integrated software packages but in real life, most of these tools are being forced to fit into processes that are already there. People jam them against current ‘cultural’ processes. A great example – A large integrated e-Procurement application requires purchasing professionals to do a Contract Request in order to eventually be able to create a Purchase Order – now in real life, how many purchasing professionals start out that way when at the last minute, they are asked to buy something?
- Should a company change its overall cultural processes to accommodate large integrated software packages? I am a believer that a company’s processes are the key to competitive advantage as well as differentiation. A company is only good as its processes (unless of course they are the only ones selling a product that is in demand). And yet large integrated software packages are created with the thought of standardizing and implementing their large scale solutions throughout the entire organization and across all companies. What competitive advantage is left at that point?
- Which begs the question - Are these fully integrated standardized processes best in class? Well, when was the last time that any software or consulting business purchased textiles from China, or sold drugs in Europe or distributed food to supermarkets in the United States? What makes companies think that anyone would know better than they what makes sense for their organization or for that matter for their entire industry? Software companies offer a recipe but everyone knows that meals can taste very differently depending on the ingredients used, the person cooking, and the taste of the guests.
- Most integrated software is sold with the end game in mind – making software bits that need each other so that a customer will continue to buy and upgrade. Amazing how we, in Purchasing pick functionality based on what we think we may need vs. figuring out what we need and then buying as necessary.
- One of the key commandments in Lean Manufacturing speaks to this topic: Choosing low cost, reliable solutions as an alternative to costly new technologies.
- Finally, and possibly most importantly, think about the cost to achieve Day 1 integration. It will likely take an army of developers weeks, or months, of time (=$$$$) to get to the point that everything is passing data back and forth. There is a very high likelihood that this effort could cost in the millions of dollars. How long will it take for the new, high efficiency system to achieve payback ROI? That’s a lot of money to make up simply with integrated platforms. Uh oh, did I mention there is a new upgrade coming…time to bring in the consultants to fix it again.
My thoughts - Less integration, more down to earth, good basic purchasing functionality with an opportunity to achieve a positive ROI quickly. Not a million dollar pipe dream, but a cost effective timely reality. Hit the ground running and customize your processes to support the platforms that help to achieve concrete goals.
Final Conclusion:All of my points might be taken to imply that I am a non-believer that procurement and sourcing exist symbiotically and can benefit each other. This is not true, I certainly believe this. However, I also believe that this Utopian concept is more likely to drag resources and money down a rocky road. To me, a business decision is much like the US Marines philosophy of 70% information = decision. Things move too fast in business to try to solve all problems with one mega-uber-solution. Make multiple good decisions and use human intelligence to bridge the gaps. You will take much of the risk out and be able to generate successes quickly.