Analysis and Design Phases

During the analysis and design phases, the project finally shifts from planning to doing, and with a well thought-out and endorsed project plan in hand, the organization can now begin to analyze and redesign the procurement process. There are normally several areas of focus.

Collecting Information to Confirm the Business Case

Apart from the cost/benefit analysis on the current process, remember also that total project costs will be much greater than those associated with simply purchasing and implementing a system. Consulting, additional software, integration with legacy systems—in other words, total implementation costs—will run normally at levels from 5 to 10 times the cost of the software platform alone. And although ORM and most aspects of MRO may be fairly straightforward in terms of process design, direct procurement will be a major undertaking, involving changes to nearly every process and system in your entire supply chain. It is therefore usually worthwhile benchmarking total costs, when possible.

It is important that realistic expectations for total cost are set at the outset. If price expectations are set too low, executives can suffer “sticker shock” and be tempted to declare victory after phase one, without getting the true business benefits that require a larger and longer-term investment.

Confirming Supplier Support and Compatibility Levels

As we have seen, it is important to make certain that you design your e-procurement process with present and future supplier needs and capabilities in mind. This is particularly true if you have not kept up with a strong program of supplier consolidation and are unaware of their strategies or current transition programs. It is important to determine early on how many of your key suppliers are ready to take the leap toward electronic connections via the Internet, and to also know how many, if any, are currently developing similar collaborations with other buying companies. Do they have EDI at present, and if so, what is their plan for migrating to XML? Many large or specialist industry suppliers may already be planning to participate in vertical industry e-markets, and therefore may be already wondering how to provide electronic catalogs, either directly or through that industry portal.

Redesigning Business Processes

Redesigning business processes involves many workshops and detailed process-mapping sessions, and along with a sense of perspective (and humor), practitioners should be careful to keep several broad principles in mind:

• Use automation, whenever possible, with the view of minimizing human intervention (create a hands-off procurement process).

• Shift the responsibility for ORM goods purchasing, whenever possible, to the users’ desktops.

• Make the process exception only by rethinking approval criteria.

• If both technical and financial approvals are necessary, make these happen on parallel and simultaneous paths.

• Reduce one-off product purchases to a minimum.

• Introduce data only once, at source, and make that data available to parties that require it simultaneously (suppliers, central purchasing, the employee-buyer, accounts payable, etc.).

• Reexamine and clearly define all roles and responsibilities from buyer through supplier.

Completing an Implications Analysis on Changes to Activities and Employee Jobs

One of the most often neglected, but easily completed, portions of the project is the implications analysis. This analysis is completed by the design workgroups, either during initial design or in some cases as late as software implementation, depending on approach. The implications analysis simply records the changes between the current state and the future state of the process, but focuses specifically on the work activities that will be changed or eliminated. For example, if the purchase order is no longer typed by hand but done automatically by the system, the team captures the fact that those specific manual production activities will no longer exist. As the team members work their way through the entire procurement process at activity level, they build up a significant profile of the changes to employees’ future work activities.

By reducing the process to an activity level and then comparing manual with system-based approaches, this exercise provides a much more accurate and detailed understanding of what a company is trying to achieve with the new system, allowing the design team to make detailed system adjustments before implementation, or, alternatively, helping them to shift the company toward accepting built-in leading practices that are inherent to the software. Equally important, this approach provides an instant picture of the relative gap between the current and future ways that employees will work—no more faxing, or no more reconciliation of the invoice and the purchase order—down to the specific activity that will be eliminated. The steps of the implications analysis include

• Identifying changes in work (at activity, process, and unit level)
  
  
• Understanding what will not be done in the future
  
  
• Noting what changes in order, omission, and so on will require major organizational or structural changes (altered reporting lines, new decision-making responsibilities, etc.)
  
  
• Identifying skill changes necessary for current employees to complete the new activities
  
  
• Mapping of the future workforce (at skill level only, not by name) against the current procurement workforce in terms of what is done and who does it
  
  

Technical and process teams often worry that noting down specific activities and jobs that will be eliminated because of automation will cause too much political disruption to the project and within the company. They rightly appreciate the amount of resistance and concern that occurs when it becomes widely known that specific positions associated with the procurement process will be combined or eliminated. And yet, as with ERP, unless those activities—and therefore positions—are eliminated, the system’s value is greatly reduced. Employees will probably know, or at least suspect, that these types of positions are at risk anyway, and it is both unfeasible and unwise (as some consultancies still advocate) to try to make the design team’s deliberations a secret.

I once was called in to help with a large company project where the design team members had sequestered themselves away in several conference rooms; on the doors, they had hung hand-made signs depicting skull and crossbones with warnings of “Confidential Material” and “No Entry.” Within weeks, the employee population was rife with rumors of wholesale layoffs and staff cuts, fueled by the total lack of a communication plan and the exclusive and clandestine airs of the project teams. After several “tell-us-or-else” demands were made to management, the CEO finally agreed to a rather enfeebled effort to explain that it was only an IT system. Unprepared, the CEO was trapped into admitting that the aim was, in part, to eliminate labor. Unable to put forward a convincing business case, afraid to pledge openness, and having given no thought to a personnel transition plan, the management team simply pledged that no job changes would be made, thereby undermining the entire point of a multimillion dollar software implementation.

The lesson, then, is that it is important to understand the likely implications on process and people as soon as possible, to develop a change transition plan, create project champions to promote the initiative and to communicate openly, and to elicit broad employee participation and input through employee workshops. Above all, employees should understand that they are genuinely responsible for the success of the e-procurement, and should be encouraged, as much as possible, to take “ownership” of that success themselves.