When Barry joined the small consumer-products company as their CIO, he found a mess -- not just a mess of systems, but business units that had grown quickly and paid little attention to their fundamental business processes.

The basics weren't working well, and the company was struggling as a result. One business unit struggled to deliver its products. Another delivered products just fine, but then couldn't get invoices out!

Prior to Barry's arrival, the CEO had convinced the venture capitalists who own the company to invest in ERP. He saw it not only as a replacement for the jumble of legacy systems, but also as a way to clean up business-unit operations and to gain business synergies through common business processes.

This makes a lot of sense, right? Read on....

Implementing ERP

Barry was tasked with implementing the ERP project. As you'd expect, he managed the software vendor selection process with involvement from the business units, and then hired a technology integration consulting company to help with implementation.

As suggested by the consultant, Barry then identified "Business Process Owners" whose task was to represent their business units, redesign their business processes, and ensure clients' "buy in." A reasonably senior manager was selected from each business unit.

It quickly became apparent that IT couldn't get any time from the business, even from those Business Process Owners who were supposed to be on the project team. They were just too busy fighting fires, that is, running their businesses.

To solve this problem, the consultant suggested that the Business Process Owners be assigned to the project full time.

Again, on the surface, this makes sense, right?

Take Them Out of the Business?

Fortunately, Barry had seen this strategy before, not just in past jobs but throughout the industry. And he knew exactly where it would lead.

He knew that as soon as the Business Process Owners were assigned full time to the ERP project, they'd no longer represent the business. Virtually overnight, clients would view them as IT staff and no longer as business-unit people.

Meanwhile, having given up these people to IT, the business units would feel even less obliged to participate in the project. Short on headcount and without any significant role in the project, they'd certainly have no time for IT.

These Business Process Owners had the knowledge to come up with sensible business processes. But if they were assigned to IT full time, they'd no longer run the business and so they'd have even less legitimate authority to approve these changes in the business. Meanwhile, the people who'd be left running the business would not be involved at all.

So when it came time to implement those new processes, IT would find itself in a head-on collision with the business units. And IT would not be likely to win that battle. In a fight between a "staff" function like IT and "line" managers (remember them -- the ones who make money around here?) you know who's going to come out on top. All the logic and business cases in the world wouldn't save the ERP project then.

Barry knew that taking these people out of the business would be going in the wrong direction.

Clients' Point of View

Barry also knew that the perspective of the business units was very different from his perspective as corporate staff.

They're measured on their bottom lines, and that means keeping their businesses running.

It's not that they wouldn't change and improve. They knew they needed change. But they certainly wouldn't hand over to Barry (who doesn't have accountability for their bottom lines) any authority over their businesses.

Worse, the business units understood that IT intended to implement common business processes, which meant they'd have to do things the same as all the other business units. Clearly, IT didn't understand or respect their unique strategies, competitive pressures, customer demands, and product differences.

To business clients, IT was the enemy -- the corporate evil empire that demanded authority without accountability, stole their people, and intended to impose on them overly simplistic common business processes that may or may not work and were certain to disrupt their operations.

Their lack of time for the project was a symptom of a deeper issue -- one that Barry wisely treated as a valuable warning that was not to be "overcome" but rather to be heard and analyzed.

What's Going On Here?

The root cause of Barry's problem was straightforward: From the business units' point of view, ERP was an IT project, not a business project.

The business units felt more like victims than beneficiaries.

Why would they view it this way, when the intent was to help them?

The answer was simple. It was because the CEO assigned the project to Barry, not to the business-unit presidents.

It was all upside down. Barry was asking for help from the business units for his project. They heard Barry saying, "Give me your people's time and some authority over your business so I can accomplish my goals (and potentially harm your business)."

Such a deal!

Back to Basics

Barry knew this wasn't going to work. If he pressed on, using the backing of the CEO to force the project through, he'd probably run into all kinds of implementation problems -- passive resistance -- and ultimately get blamed for a failure. Worse, he'd antagonize the very people he's supposed to be supporting, and throw away any chance of partnerships with the business that are essential to discovering really strategic systems.

This is not a new lesson. IT never has successfully implemented a business application without a willing client.

Said another way, IT will fail if it tries to sell the CEO a change in the business. The only way IT can succeed is if the business units want to change, and want IT to help them by selling them new technologies and perhaps the design of new business processes.

ERP is no exception to this obvious principle, even if the project has CEO sponsorship. Barry knew his customer had to be the business units, not the CEO.

Barry figured out that there are three types of customers for ERP -- essentially three levels of ERP implementation. Figure 1 summarizes these three situations, ranging from easy to difficult but with increasing benefits.

Level 1: Common technology configured for each business unit's existing processes.

Benefits: technical, plus a common technology platform as a foundation for future business synergies.

Degree of change: requires no changes in business processes.

Level 2: Common technology implemented with business process redesigns unique to each business unit.

Benefits: technical and business, plus the promise of future business synergies.

Degree of change: business units individually change their processes.

Level 3: Common technology and common business processes.

Benefits: technical, business, and corporate synergies (the real promise of ERP).

Degree of change: business units must agree on common processes.

Recognizing that technology synergies and business synergies were two different things, Barry understood his path forward.

ERP Strategy

Barry's solution was three pronged.

First, he issued a new "ERP Policy," summarized in Figure 2, consistent with his vision of a customer focused internal service provider.

* If a business unit wishes to replace an IT solution that's within the functionality of ERP, it will be built on the chosen ERP platform by the Corporate IT department. Variances must by authorized by the executive committee.

This way, even if the business units choose not to change their existing processes, at least they'd get the benefit of technology synergies. And by implementing their custom solutions on a common platform, future business synergies through shared data and common processes become more attainable.

* If a business unit chooses to buy an ERP solution from Corporate IT, it will not be forced to change its business process (although it may if it wishes). Corporate IT is willing to customize solutions to fit each business unit's unique requirements.

Of course, when a business unit chooses to clean up its business processes in the course of replacing its systems, they'll also get the benefits of improved processes.

* Corporate IT will bring to the attention of business-unit executives their opportunities for shared business processes, but it will not force them to change. If they form a consortium, then Corporate IT will help with the design of common business processes and shared solutions.

Thus, to make common business processes feasible, some or all of the business units would have to band together in a "consortium" and buy from IT both systems and process designs.

Second, Barry explained the situation to the CEO. He suggested that the CEO task the business units with coming together on shared processes. Then, and only then, would IT support them with process design consulting and a shared solution.

That put the project right side up.

Instead of selling the CEO an ERP implementation and buying cooperation from the business units, IT serves willing clients with process design consulting and solutions so that those in charge of the business can produce better results for their boss, the CEO, and their shareholders.

Third, Barry worked with the business units to sort out their roles and IT's, and to define clear contracts for the specific products and services they willingly chose to buy from him.

Barry's approach will lead to feasible projects and positive results, with or without the CEO's involvement. But if the CEO tasks business-unit leaders with finding the synergies, the chances of Level 3 benefits are greatly improved.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....