Underestimating Process ChangesThis is far from the only way that the business/technology disconnect can reveal itself. Our next example of a real-world disconnect is framed by a common dilemma that IT professionals face: After installing a new enterprise application, they find a gap between the business processes it supports and the processes that are already in place. To bridge this gap, they face a critical choice ”to either pay for expensive modifications to the software, or change how the company does business to fit what the technology supports out of the box. Carl Wilson, Executive Vice President and CIO of Marriott International, Inc., is a strong proponent and successful practitioner of alignment. Marriott, lauded for its progressive alignment initiatives, enjoys the fruits of Wilson's previous experience and lessons learned. Throughout his extensive career in IT, Wilson has witnessed firsthand how disconnects caused by underestimating the impact of process changes can bring about real damage to the business. In this example, he recounts the story of a CEO who wanted better visibility into his human resources (HR) information so that he could assess his company's equal opportunity compliance:
The CEO quickly kicked off what he expected to be a straightforward project: implement an HR system for the company. But in the end, the disconnect between the new software and the company's established business processes, ended up costing the company millions. From the start, the project was put on the fast track, and the company hired a large, high-profile consulting firm to implement the system. After a short evaluation period, the consultants recommended three ERP packages from leading vendors . The consultants were under intense pressure from the executive team to fix the problem as quickly as possible. To save time, they assumed that all HR processes were essentially the same, and brokered a deal with a vendor whose product had been successfully installed a number of times for companies in the same industry. The contract, Wilson remembers, was the standard consultant's contract; there was minimal negotiation, and the company signed right away. Early on, however, it became apparent that the installation wasn't going according to plan. When the new system came online, employees clung to their familiar business processes and demanded that the software be customized to fit the processes they were used to. The team eventually yielded and undertook a massive customization program. As a result, the project, which was originally budgeted at $4 million, instead ended up taking three years longer than expected and costing $9 million. Consider what happened in this example: The project started out with the sound business objective of better visibility into HR. But because process changes weren't addressed until after the technology had been designed and implemented, a disconnect cropped up between process and technology (see Fig. 1.2). Modifying this technology to match up with the processes cost millions. Figure 1.2. In Wilson's story, a disconnect resulted when process changes weren't addressed until after new technology had been finalized
A better solution, of course, would have been to adjust what were essentially low-value HR processes to fit those that the software supported out of the box. But the consultants on the project didn't make the connection between the new software and its affect on existing processes. They never collaborated with the end-users to find out how their processes were carried out today, and never communicated how those processes would have to change. As a result, Wilson says, end-users fought change from day one, even though doing so cost millions in customization:
Projects that overlook processes when they make changes to technology do so at their peril. Instead, Wilson argues, companies need to acknowledge that process management is a central component of IT change:
|