Hidden Costs of Outsourcing and Offshoring for Financial Services...
Cloud Computing Benefits Procurement in Two Ways
Procurement Transformation - Be Careful What You Wish For
Strengthening the Relationship between Federal IT, Procurement and...
Balancing Customization and Business Process Change in an eProcurement Implementation
By Benjamin Ho, Deputy Procurement Officer, City of Chicago Department of Procurement Services
The City of Chicago is a national leader in procurement transparency. A vendor, a contract, and payment information are posted online. Behind the scenes is a highly paper-intensive process that we are on the point of changing under the leadership of Mayor Rahm Emanuel and the city’s Chief Procurement Officer, Comptroller, and Chief Information Officer. Since 2002, the City has had an Oracle ERP, which was implemented with a significant number of customizations. This system tracks purchase orders, invoices, receipts, and payments. However, the solicitation and contracting process generate huge volumes of paper, despite online advertisement.
In order to change the focus of City procurement from moving paper to cost savings, negotiation and supplier management, the City is adding eProcurement modules, iProcurement, iSupplier, sourcing, and contracts, to its ERP. In a nutshell, these modules streamline the procurement process by allowing City staff to submit documentation for requisitions and solicitations electronically, collaborate to create solicitations and contracts based on templates.
Furthermore, the modules will enable suppliers to bid online and the City to evaluate and award online. In addition to improving the efficiency of procurement, the City is taking the opportunity to improve the IT infrastructure of its ERP by maximizing the use of off-the-shelf functionality and minimizing customization.
Business users gain the most in processing efficiencies and error reduction when business rules and validations are built into a system. When using off-the-shelf functionality, many of the required business rules and validations are not available except through customization of the system. Also, an off-the-shelf solution may require a “dance of clicks” to access commonly used functionality, increasing training and support costs. All these are potential justifications for customization. The downside is that customizations increase project costs and make the system difficult to upgrade, support, and maintain. This tension between the business’ goal to meet as many requirements using the system and IT’s goal of keeping the system easy to maintain creates challenges in an eProcurement implementation.
Changing the business process to center around the functionality available in a new system is a partial solution. Business process re-engineering can reduce, but not eliminate the requirements for customization.
Requirements remaining after business process re-engineering for which customizations are not approved still exist and require business process workarounds. Given the City’s goal of using standard functionality and minimizing customization while meeting many requirements after business process re-engineering, the City’s eProcurement implementation involves many business process workarounds.
A close partnership between IT, Procurement, and Finance has resulted in fulfilling our goals of streamlined procurement processes online as well as minimizing customization
Determining a business process workaround is tricky business. It requires the end-user subject matter experts and implementation consultant to understand what can and should be done in the system and what is to be done outside the system. For the workaround to be effective and result in smooth running daily operations, a clear process must be spelled out, detailed training materials must be developed, and end-users must be well-trained.
Business process workarounds and customizations were determined during the implementation, which followed a conventional methodology. The City provided its requirements to our implementation consultant prior to and during a first conference room pilot (“CRP1”). Our consultant then configured the system and identified gaps between requirements and system functionality based on input from CRP1. This was followed by a second conference room pilot (“CRP2”), where users provided final input and identified additional gaps based on the configured system. This was followed by training for the user acceptance testers, and then user acceptance testing. The City decided which gaps should be filled with customizations, and which ones should be handled with business process workarounds, identified and outlined at a very high level.
A very effective tool for limiting customizations is supplying cost information to the requester of the customization and letting them make the cost-benefit decision. Whenever a customization was identified or requested, we asked our implementation consultant to provide a quote. This quote was then shared with the requesting department, which would have to fund the customization. Amazingly often, previously unacceptable workarounds or business process changes would suddenly become acceptable.
High-level descriptions of business process workarounds must be must be turned into step by step instructions and incorporated into daily operations. A challenge in doing so is that it is very little or no time during the requirements gathering, development or testing process for diving deeply into the details of the business process. Subject matter experts know the current process and their domain-specific knowledge. They need to see the system and walk through scenarios in order to flesh out the detail of a future-state high-level business process. Even if there were time, at this early stage, SMEs do not understand the new system well enough to devise a detailed business process workarounds.
Adding to the need for detailed process development were the many situations where we used standard functionality in an unconventional way in order to accommodate a business requirement. Here the business process development is not a workaround, but spelling out the details for the end-users in a process is just as important. For example, the standard document collaboration feature of the Oracle Sourcing module is well-tailored to developing bid solicitations and turning them into contracts. This functionality falls short for complex contracts arising from requests for proposals (RFPs) requiring extensive back-and-forth negotiation. For such contracts, it lacks the “track changes” feature that is required by negotiation teams. It is still possible to use the Sourcing module for the RFP and the contract by using Microsoft Word attachments, but the “how to” requires many hand-offs between system processes and external processes.
Many business process workarounds require significant engagement by the business departments. This extends through development, documentation, training, and enforcement. To provide time for development of a detailed business process, the City provided a pilot process at the beginning of rollout and an extended phase-in period. The pilot period is also where training materials and support processes are evaluated and revised if necessary.
The City has successfully rolled out iProcurement to its internal users. Since fall 2015, departments are submitting their requisitions with electronic documentation instead of paper. By the time you read this, we will have begun our phased rollout of online bidding and supplier access to purchase orders, receipts and payments. A close partnership between IT, Procurement, and Finance has resulted in fulfilling our goals of streamlined procurement processes online as well as minimizing customization.