Procurement Transformation - Be Careful What You Wish For

By Jeff Stovall, CIO, City of Charlotte, NC

Jeff Stovall, CIO, City of Charlotte, NC

Last summer, the City of Charlotte launched its biggest Procure-to- Pay change in over a decade. After using the same mainframe-based financial system for more than 30 years, the Charlotte City Council approved a $21 million project in 2011 for a new ERP system to modernize financial and procurement processes. Nearly three years later, after much toil and effort, we were ready to go-live on the new system in July 2014 for the start of the new fiscal year. We survived the launch, but just barely.

At first everything seemed to be working well: all city departments had indicated their readiness to convert to the new ERP system; the new system was stable in the production environment; users were able to enter transactions; our external auditor had praised our approach in managing the hundreds of decisions required to implement a system change of such a large magnitude. However, by the 60th day after the launch, problems started to surface. Users were complaining that the workflows for requisition approval were too complicated; some requisitions were taking weeks to get through multiple levels of sign-off. More ominously, vendors were starting to complain about late payments. By the 90th day, it was clear that changes would be needed immediately to keep small, cash-flow sensitive vendors afloat and to deliver delayed payments to vendors with multi-million dollar contracts. What went wrong?

Diagnosing the problem

The fundamental issue was not how well the new ERP system operated; it was how we designed it to work. In the 30-plus years with the previous financial system, the city had grown a sprawling ecosystem of major applications, ‘shadow’ systems and side processes which featured minimal procurement controls and limited reporting capabilities.

The old set of controls were sufficient for financial accounting purposes, but fell far short of the mark, for modern managerial practices in an organization that has more than doubled in size since the 80’s main frame. However, the old ecosystem was balanced in the number of resources it took to run it and the status quo expectations we had for process management and reporting.

It was believed that with the introduction of new system technology, the time was also ripe to implement procurement controls that would be more reflective of 21st century practice. For example:

• The old system made only minimal use of formal purchase orders to acquire goods and services, which made forecasting committed spend a day-to-day challenge.

• The imaging system used to process invoices was not integrated with the main purchasing system, resulting in a lot of manual work to enter and validate transactions across both the financial and the invoice payable systems.

We found ourselves needing to transform much more than just our technology to survive and thrive in the change

As a consequence, many new requirements and approvals were imposed in the new ERP that were not in place previously. The new processes were not well-regarded by end users, which largely saw them as hurdles to purchasing what they needed to support departmental services.

Process change versus technology change

It is important to delineate the impacts caused by the technological changes versus the procure-to-pay process changes. By imposing more PO requirements, work shifted from the procurement back office to the departmental users upon initial entry. The city moved from an environment where we would inspect and audit activity after purchase to one where positive approvals were needed before the order was placed and after the order was received

What would we could have done differently?

• Define a clear, measurable procurement strategy before implementing a financial system change

Our procure-to-pay strategy was murky, using terms like “effective” and “efficient” without realistic measures and targets or a visionary view of the future procurement environment. Our strategy was largely built by internal management teams that did not have broad, external knowledge of how such strategies were executed in other environments. Our plans tended to devolve into tactics with which people were familiar versus challenging us to reconsider our strategic intent. What the executive team did do well was to recognize the signs when things were not proceeding well and to bring in outside expertise to help re-evaluate our current position and avert catastrophe.

• Match the pace of change to what can be readily absorbed by the organization

After having the same base system for 30-plus years, our employees were not used to seeing much change and evolution in procure-to-pay processes. The last major change was in 2004, when an electronic imaging system replaced our manual routing of paper invoices through interdepartmental mail. Ten years later, nearly everything about the purchasing process was changing. A better approach would have been to phase in process changes over a longer period of time, giving each a little time to solidify and get refined before moving to the next one.

• Simplify and focus on the user experience

The old mainframe-based system was not user-friendly, but it was familiar. Moving to a graphical, point-and-click user interface alone did not guarantee a better user experience for our employees. The new environment required more keystrokes and process steps largely to arrive at the same end result. The executive team recognized where the system could be reconfigured to reduce user frustration and eliminate process steps after launch that proved to add little immediate value.

• Re-evaluate conventional wisdom

After consulting with many cities that had implemented ERP systems, the vast majority seemed to prefer a single, vendor-integrated system to a “best of breed” approach. For systems implemented in the early 2000’s, that was the best practice. However, by 2014, Gartner had forecast how “post-modern ERP” would be the new best practice, integrating cloud and on-premise systems with the use of seamless APIs. We had been advised later in the project that the public sector Procure-to-Pay capabilities of many of the established ERP vendors were less advanced and functional than those of competing procurement specialists. The executive team changed direction mid-course, to avoid the limitations of ERP-vendor provided functionality and sought to re-evaluate components that could be better delivered with third-party software.

Procurement process transformation had been on the city’s wish list for many years but when it arrived, we found ourselves needing to transform much more than just our technology to survive and thrive in the change.