Role-ing Along Toward E-Commerce

IT responsibilities change with the times, but not always for the better

Some of you may have noticed our absence from Intelligent Enterprise over the past few months. We haven’t been idle; rather, we’ve both changed jobs to join a new, exciting company developing software to revolutionize healthcare administration — an environment that sorely needs help. At eHealthDirect, we’re the CTO and CIO-general manager of the data services group, respectively. In debating and discussing the structure we were going to apply at the company, an idea for this column took shape as well: taking a historical perspective on the senior roles in the IT environment and how they affect the beliefs, understandings, and insights in present-day IT roles.

As we think about the evolution of the corporate technology organizational environment, we view four critical historical roles:

• Business sponsorship — the responsibility for determining what the technology group does

• Technology management — the responsibility for managing the day-to-day activities of the enterprisewide technology organization

• Applications implementation — the responsibility for developing, deploying, and operating an organization’s underlying systems

• New technology — the responsibility for investigating new technologies and introducing them into the organization.

We’ll need a context to discuss these roles. For this purpose, we’ll use the technology adoption cycle context we introduced in our column “You Say You Want an Evolution” (Nov. 16, 1999).

To recap, business computation began with the use of computers as sophisticated calculators in the tabulation phase. In the automation phase, businesses created shared electronic records to enable distributed operations. The productivity phase was marked by improved individual tools and processes, allowing individuals broader business scope and reduced specialization. The workflow phase enabled reduced hand-offs and shorter cycle times. The reengineering phase introduced simplified and streamlined business processes with focus on value-add. Most recently, the e-commerce phase delivers consistent real-time and customized direct customer interaction at any time through any channel.

Clearly, management roles and requirements have shifted significantly over time.

The Tabulation Phase

When businesses first used computers during the tabulation phase, IT departments were very small and the department heads played trivial roles in the companies. Applications were typically focused on the accounting area (gun elevation tables were somewhat specialized). In this phase, IT organization was very simple — somebody, typically an engineering-inclined accountant or perhaps a specialist, had general responsibility for programming, operating, and maintaining the machine, and he (we’re not being sexist; we don’t know of any women in that job) usually reported to the controller or CFO.

The approach and structure worked very well. Everyone understood what they needed to do, prioritization was straightforward, and results were achieved. In fact, the structure worked too well. Applications for the new technology spread and the growing uses for computers outside the financial area made the practice of having all the technical resources report to the head of accounting or CFO no longer make sense.

It’s not that every company realized that having applicability outside the accounting sphere made IT reporting outside the CFO’s organization appropriate. In fact, the organizational hallmark of progression to the automation phase is not the reorganization of IT away from finance, but simply the promotion of the head of the technology group.

The Automation Phase

As IT progressed in its organizational development, the impetus for system development activities came from a widening range of sources. Fortunately, these new requests were almost always close derivatives of the activities automated for the finance group, so the approaches were straightforward and the results were often successful. Unfortunately, the requests fragmented across operating groups with little or no thought toward integration, and almost no thought toward process redesign. The assumption, as we have written before, is that the machines were unreliable and would break down, so the design philosophy was simply to observe current operations, write them down, and write code to automate them (the “methods and procedures” approach).

Interestingly, and embarrassingly enough, this approach is still prevalent in many aspects of IT. Consider the now-typical ERP implementation. Originally, installing an ERP system was an expensive, arduous process that involved adapting company practices to the best demonstrated practices (BPDs) inherent in the ERP systems. Implementations were painful, but fruitful, and the “fruit” won out. But over time, the willingness of the later adopters to accept “pain-to-gain” results evaporated, and the “typical” ERP installation process is now expensive, arduous, and focuses on adapting the ERP software to the company’s practices. The process is not as painful for business users, but not nearly as fruitful.

IT organizations grew into their new roles. Typically, the group head, now called the VP of MIS, came from the data center world. In this phase, a substantial percentage of the IT costs were in hardware and most of the rest were in packaged software. The hardware side of the business seemed, and was, more well-defined, making the hardware guys far more acceptable to their business partners. Applications development reported to an AVP or director who reported to the VP of MIS. To the extent that companies had an R&D function, the person in charge usually reported to the VP of MIS, and spent their time running around trying to get people to share hardware, or at least to reduce risk and expense by using products from the same manufacturer.

Eventually, many cost-conscious CFOs and controllers (which is pretty redundant in our experience) realized that helter-skelter, fragmented, as-is automation wasn’t achieving business goals and drove the move into the next phase of corporate technology development. Making that move required business line management to take responsibility for the results of technology initiatives and thus, the formal role of the business sponsor was born.

The Productivity Phase

Don’t get us wrong: We’re not advocating “business sponsors,” although we obviously believe in business sponsorship. As we’ve written before (see “Ham and Eggs,” March 20, 1999 at www.intelligententerprise.com/993003/cio.jhtml), we don’t believe in creating “ham and eggs” problems, and the notion of business sponsors tends to formalize the problems, which is bad.

When the CFO pushed financial responsibility for projects to the business units, line managers reporting to the CEO or COO had to take responsibility for the financial payback of systems’ projects. For the first time, people began to focus on the actual financial results of systems projects. And the results weren’t always so good. Systems people, left to their own devices, solved systems problems. Moreover, because the VPs of MIS were frequently data center people, their core projects involved making the existing systems run in a more stable way. We’re only surprised this situation surprised anyone. Typically, the corporate response is organizational, and the organizational response was to promote the people developing applications, asking them to either report to the business unit heads or “dotted line” report to the business unit heads while continuing to also report to the VP of MIS.

Achieving better business results required two fundamental changes in the process and environment. First, merely modeling current business processes was no longer acceptable — we had to actually improve them. This change gave rise to the business analyst role and business technology groups. Second, with cost and break-even analysis came systematic prioritization approaches, which gave rise to the IT accountant.

With decentralization came loss of control, and to counteract the chaos and focus on reusability, many VPs of MIS began to develop R&D groups, headed by someone frequently called the director of new (or advanced) technology. The groups started to experiment with nonmainframe and mainstream distributed technologies for business applications. These technologies are new to the business, not usually new technologies, per se. But here’s the irony: In an organizational move designed to tighten the linkage between the operating business units and the technology groups that support them, a group charged with finding better uses for technology emerged in support of the businesses objectives buried deeply within the technology organization. However, that group was often positioned in the worst possible manner to make these breakthroughs or implement them.

Which brings us to the beginning of the “modern” phase of corporate technology, where we see the growth of the CIO and CTO roles and the acceptance of IT as a, or even the, critical skill in the New Economy. Stay tuned….