Chapter 11. Guiding Principles for Developing an E-Procurement Initiative

As we have seen, an e-procurement initiative, done well, requires dramatic changes in strategy, organization, process, and systems, and affects functions throughout the organization. Although ORM projects tend to be more straightforward, projects focused on the direct materials side—which involves rethinking the entire order fulfillment process, from customer to supplier—require significant changes to the way employees work and how a company organizes its supply chain and purchasing processes.

The U.K. government is a good example. In 1999, U.K. officials had set for themselves a target of cutting some £1 billion from all government procurement costs over the next three years. Having announced their intentions last year of participating in a shopping–mall type of arrangement for ORM materials, which required the use of pretendered catalogs, they have now put a halt to the program, citing fears that the combination of poor back-end systems integration, a volatile marketplace, and the need for rethinking their current paper-based processes means that they are in no position to move forward with an e-procurement program of this scale. For many organizations, this combination of market volatility and a growing appreciation for the need to restructure their processes before implementing sophisticated systems has left them unwilling to commit to a broad e-procurement program.

The good news in all of this is that e-procurement projects can be treated in much the same manner in terms of strategy, project approach, and change management as the enterprise-wide ERP initiatives of the last five years. We have learned a lot about what to do and what not to do to make those enterprise-wide projects a success. The bad news is, implementing companies and consultancies have seldom incorporated this leading-practice project approach, and many, if not most, organizations had a pretty rough time of ERP implementation because they failed to do so.

It is worth noting that a majority of businesses still claim that they failed to get the business benefits that they had hoped from ERP implementations. This was seldom because the software platforms lacked functionality, but rather because organizations focused on implementing piecemeal, technical solutions, forgoing the difficult and controversial changes to long-established processes, reporting structures, and reward systems—and, too often, the organizations avoided taking on the even more contentious issues associated with worker activities (and often, therefore, positions) eliminated through automation.

Experience has now shown that most projects go wrong (or simply never really get off the ground) because the organization—and therefore the supporting consultancy and the software vendor—fails to take into account the fundamentally different nature of a true enterprise-wide transformation project from that of traditional software implementation. Typically, best intentions and great enthusiasm give way to multiple, overlapping initiatives and broad disagreement over what is in and out of scope, organizational quarrels over which initiatives should take priority, and frustration and bewilderment of executives who think it is all about simply implementing a software solution.^[1]