A CIO viewed IT as a means of supporting clients' business processes. This was a rather limited view of the potential of IT; but at least he wanted to focus staff on business rather than just technologies.

Based on his view, he dedicated a group to each of the company's core processes. Gail was given responsibility for the corporate product-development process. Jerry looked after the entire order-to-invoice process. And Tom supported all the company's financial and administrative processes.

• Gail, product-development process
  
• Jerry, order-to-invoice process
  
• Tom, financial and administrative processes

Each group was expected to become familiar with the workflows, and design solutions that optimized these business processes.

In practice, this structure produced some serious problems....

Redundant Learning Curves

The various processes all required many common skills. This caused a lot of parallel learning curves.

For example, under the influence of innovative clients in R&D, Gail was the first to develop applications on then-new mobile devices. Later, when Jerry embarked on a sales-force automation project, his group had to research the same technologies.

Similarly, Jerry had developed electronic data interchange (EDI) solutions to better interface with suppliers' systems. Then, when Gail's developers wanted to share data with professional communities outside the company, Gail had to replicate Jerry's learning curve.

While they helped one another with advice when they had time, they weren't able to flexibly deploy existing expertise to one another's project teams. So staff still needed to spend time learning what others already knew, which increased costs and delayed projects.

Redundant Work

Parallel efforts led to redundant work. For example, both Gail and Jerry developed document-tracking modules. This drove costs up further.

Even in the applications themselves, there were problems. A business process uses a variety of types of data, so each group needed experts on many different data objects (types of IT applications).

Reduced Specialization

Skills needed by multiple processes were scattered among the groups, reducing staff's ability to specialize.

For example, Gail and Jerry both needed expertise in product data. Jerry and Tom both worked on customer, sales, and financial data. And all three worked on human resources data. They became specialists in clients' business processes, but generalists with regard to their own profession of engineering specific types of applications. Performance naturally suffered.

Product Dis-integration

Each group independently developed its own versions of financial, customer, and product databases. Fragmented data caused confusion when different reports gave clients conflicting views of the "same" data.

When they did collaborate on a few common applications and databases, other problems occurred. They each enhanced the same applications at various times. As a result of "patch on patch," systems integrity deteriorated.

Weak Client Relationships

The CIO expected that this structure would bring IT closer to clients. However, this was not evident.

Most business units were involved in numerous business processes. For example, Manufacturing was involved in both product development and production. Thus, both Gail and Jerry served Manufacturing executives, focusing on different aspects of their jobs.

With no single point of contact for a client like Manufacturing, it appeared that the various IT groups were competing for the clients' attention. IT appeared poorly coordinated.

This also meant that clients had to determine which workflow they wished to discuss before they could know whom to call. As a result, IT's client liaisons were not included in clients' thinking early on, where the real strategic discoveries are made.

Furthermore, since processes touched multiple clients, IT managers couldn't focus on just one business unit. With more business units to cover, they had less time to get to know the people in each. This also distanced IT from clients.

Finally, some clients weren't involved in any of the core business processes. This doesn't mean that they weren't important. For example, top executives are rarely engaged in routine business processes. Clients such as the president and the executive vice president of planning and business development had no designated client liaisons, and received poor service.

Biased Business Diagnosis

A group dedicated to a business process is naturally biased in favor of automating that workflow. Gail, for example, was paid to believe that automating the product-development process was the most important thing to do.

However, the corporate engineering function might have benefited far more from solutions that improve the effectiveness of key individuals -- for example, engineering design tools -- solutions that have nothing to do with automating the workflow.

Similarly, a Manufacturing executive might be involved in a critical decision, like consolidating plants, that requires decision support or collaboration tools -- challenges that have nothing to do with any of the chosen processes.

Due to the bias for automating business processes built into this structure, high-payoff opportunities were missed.

Bottom Line

Dividing Engineers into groups dedicated to clients' business processes creates many dysfunctions, and doesn't achieve its intent.

A better answer is to separate relationship managers (Sales) from Engineers, and dedicate some relationship managers to clients' processes (Function Sales). In parallel, Engineers should be divided into groups by engineering specialty.

Then, once the needs of a client process are defined (by Sales), the right team of Engineers can be assembled to develop a customized, but integrated, solution.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....