How to Build Reengineering into Your Implementation Plans

Strategic Software Sales (SSS) and Business Process Reenginering (BPR) often go hand in hand. While some types of software (like office automation) can be installed in virtually any corporate environment, truly strategic software, like CRM, ERP, or PLM always require significant organization change (i.e. BPR) before it can be truly effective. The reason is simple. Automating a clunky business process is pretty much like strapping a jet engine to a covered wagon.

Unfortunately, whenever a software sale crutches on the requirement to do BPR, there’s a good chance that the customer won’t buy, because nobody likes BPR. In the classic Reengineering the Corporation, authors Hammer and Champy estimate that “as many as 50 to 70 percent of the organizations that undertake a reengineering effort do not achieve the dramatic results they intended.” That’s an abysmal track record and (since it comes from the guys who literally “wrote the book”) it’s probably overstating the number of actual successes. In the real world of corporate executives, it’s widely understood that BPR is likely to become a major corporate headache rather than a truly transformative experience.

This presents the software sales rep with a challenge. On the one hand, you don’t want to scare your customer away by pointing out that a painful BPR effort will be required in order to use your software effectively. On the other hand, you don’t want to lie to the customer and pretend that everything will work without some form of BPR, when you know that if the customer doesn’t change, the project will eventually fail. Here’s how to deal with this situation:

1. Never directly refer to BPR or anything else that sounds like BPR. Treat the corporate change effort as if it’s simply part of the implementation plan – and something that’s as simple and straightforward as the rest of the installation process.

2. Create a grassroots constituency for the software project. According to numerous experts, BPR usually fails when it’s driven top down, because there’s a fear (often justifiable) that one’s job might be “reengineered” out of existence. To overcome this passive resistance, work with key customer influencers in the rank and file to create a desire to make the project successful.

3. Obtain top management commitment that echoes the grassroots movement. Rather than getting top management to try to force change down employees’ throats, try to get top management to act as a benevolent overseer, providing resources and encouragement to make the project successful.

4. Build and execute a comprehensive training plan. Changing business processes almost always involves massive retraining. The failure to adequately budget for this can scuttle long-term success of any strategic software project. For example, a CRM implementation based upon a consultative sales process, if installed in a company with a transactional sales process, will need a complete retraining of the sales force in consultative sales techniques in order to be effective. To ensure the success of your project, build a long-term training plan that gradually acclimatizes employees to both the new processes and the software layered atop them.

5. Create a communications infrastructure. BPR typically requires the participation of multiple departments to make the change successful. However, as the ripples proceed outward from the original source of the change, the sense of urgency declines, making it unlikely that the other organizations will make necessary changes. To counter this tendency, encourage the sharing of information and create a sense of shared purpose. For example, have the customer create a “team page” for each group involved in the BPR effort. Each team page consists of photos and biographies of individuals on the team, along with relevant project documents. These team pages help break organizational boundaries, getting groups to work together more effectively.