- Technology and the Workplace
- Business Case Models: Life in the Real World
- Technology as a Cost Center
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Business Case Models: Life in the Real World
If a company's business is publishing, manufacturing, or insurance, chances are good that its IT services will be either a completely separate business unit or a subunit within a segment, division, or department. Traditionally, there was some definitive organizational line between business managers and IT managers in most organizations, even technology organizations. For some reason, this line—real or imagined—can seem considerably more difficult to cross than other organizational boundaries. For instance, it's not too difficult for a human resources manager to understand the job of a purchasing or office manager. But beyond "making the computers work," it's difficult for most non-techies to know just what technical managers do and how they do it.
This complexity can have many forms and variations, depending on the nature of the business, the technology it uses, and of course the people who use it. But we can still learn a great deal from general examples. Let's examine two case studies.
Case 1: Driven by Business
Harrison-Murphy, a Fortune 500 publishing company with a 130-year history, has a dilemma. Having been one of the first major publishing companies to embrace computer technology in the 1950s, 40 years later they find themselves in a quandary similar to that of their allies, competitors, and rivals. Their technical infrastructure, consisting primarily of mainframe applications and the systems and people that support these applications, are no longer applicable or sufficient. The most modern application, supporting the fulfillment of their publications to over 30 million readers a month, is almost 20 years old. Although the application still performs its function adequately, it's constantly asked to do more. The demands of the publisher and marketing managers are unfulfilled by the application's limited abilities. More importantly, the technical support staff doesn't have the ability to easily reprogram the application to fit current needs. This failure is not because of any lack of competency or skill; there's simply not enough money or staff to handle the programming load. In addition, the fulfillment software's pricing is based on the mainframe economies of 20 years ago. Software updates alone can cost hundreds of thousands of dollars.
There are many reasons why the organization should turn to more flexible and less expensive software. The technical personnel are quite eager to learn new and more marketable technology. However, since most of the staff have been there almost as long as the application has, upper management prefers to avoid spending time and money on educating the staff on new technology. The new software may be less expensive to purchase than the old software is to maintain, but the cost of implementation and integration frightens senior management.
Senior management's view is that it would be far more cost-effective to outsource new product development to cutting-edge technologists to develop the applications that publishing staff and customers demand. In the meantime, a younger, more savvy technical group can be put together to replace veteran programmers. Of course, this policy causes the morale of the current IT staff to plummet. Middle-aged programmers feel betrayed after giving years of service to a company formerly noted for its loyalty to its employees. In fact, the programmers have been working in their current environment for so long that they've missed out on several technological trends and feel it's too late to catch up.
Of course, when trying to find new personnel with cutting-edge technical savvy, senior management finds a labor market in which, with only two to three years of experience, a twenty-something demands as much money as the 20-year veteran already on board—or more. Additionally, these new programmers make it clear that they have no interest in long-term commitments to or from the company. As long as the technologies they work on are current and marketable, they'll stay. When they're no longer interested, they'll move on. With so many opportunities available, why become technically obsolete like the programmers they're meant to replace?
Case 2: Driven by Technology
A division of a large pharmaceutical company delivers pharmaceutical information nationwide to hospitals, chemists, researchers, and pharmacies on new developments in their local areas. This division has developed several electronic products to deliver this information via a proprietary distributed-mainframe network. Customers must subscribe to the service and lease the required terminals to access the network that distributes the information. Almost a monopoly for 20 years, the business is profitable, but suddenly finds itself besieged. First competitors formed around the PC-based client/server model; now they're competing via the Internet.
Once relatively strong, earnings are rapidly being eroded. There are fewer and fewer new customers every month. Within two years, operating expenses could exceed operating income for the first time in decades.
Senior management's response is to implement a series of initiatives to migrate the company's legacy-based products to PC-based network applications, and then, as the technology matures, to the Internet. However, they find that progress in launching these initiatives is not what they had hoped. The core group of technical managers and programmers comprising the technology division seem to actually be resisting these initiatives, even though these changes are clearly in their best interest and that of the entire company.
Although in this case senior management is willing to underwrite training costs, reengineering, and development, the technical managers and programmers resent having new technology forced on them. Their resistance is not forceful or dramatic; it consists primarily of discussions within the technical staff about their perceived inability to migrate their current technology to ones they don't know, don't understand, and, at heart, feel they don't need. They don't have or can't find the people who know these new technologies in time to meet senior management's deadlines. And it would take even longer to retrain a talented (albeit one-dimensional) staff of already skilled programmers.