Imagine spending a day as an air traffic controller. When you arrive at work, you are confronted with a host of problems: planes arrive ahead of schedule with no available gates, mechanical problems delay the take off of other planes, pilots request changes to flight plans, several planes that are in holding patterns are requesting landing permission (you're not sure why they are in holding patterns, they were that way when you arrived), and ground personnel clamor about missed connections. Sounds rough. Now imagine that on top of this confusion, planes are changing major components in flight, pilots and ground crews speak different languages (translators are few and far between), connections between flights are coordinated by pilots with no centralized control, and the controllers know any change to these operations can create a set of new, unanticipated problems. Now suppose that we're talking about information technology (IT) rather than the airline industry—welcome to a day in the life of an IT administrator.
Change is constant in business, and IT is a nexus for much of that change. Threats and opportunities arise as a result of advances in technology and globalization, changes in government regulation, and a range of other market factors. The challenge facing organizations is not to prevent or even slow change, but to manage it effectively. Doing so is the purpose of enterprise change management (ECM). As I will describe in this chapter, changes in one part of an organization can quickly produce changes, side effects, and unintended consequences in other parts of the enterprise. Recent history is witness to several factors that have introduced and accelerated the pace of change in business—and created the need for ECM.
Although the motivation to make a change in an application or process may come from a single source, the effects of that change often spread to multiple points in an organization. A change to A requires a change to B, which in turn, requires a change to C, and so on. In some cases, the ripple effects of a change are localized to a single application or process. More often, the effects extend further as the following examples describe. To effectively manage these series of changes, organizations require ECM systems that capture asset configuration, dependencies, and attributes and provide real-time access to administrators and managers across the enterprise.
A simple change to a database is easily understood. If the longest name allowed in a database record changes from 20 characters to 30 characters, several parts of the database will need to be modified (including the table that stores the name, data entry forms that reference the name, reports that print the name, and extraction processes that move the name to other applications). A single modification creates the need for a series of changes, as Figure 1.1 illustrates. In addition to keeping up with the parts of the database that will require change, IT staff would need to inform users that a new maximum length is allowed and determine whether applications that import data from the database need updating. Administrators still need to confirm that small changes conform to requirements, are tested, and comply with relevant standards. Even the simplest example is not so simple.
Figure 1.1: A simple change to an application can still lead to secondary changes.
Figure 1.2 illustrates a slightly more complex change—a change in one type of asset, such as an application, causes changes in other types of assets, such as business processes, training methods, and documentation. For example, suppose a user upgrades a word processing program. The new application has a variety of new features that require more memory than is available on the user's desktop computer. The user then places a memory upgrade request, which is handled by tech support. Tech support approves the request, updates the configuration database, and installs the added memory. IT informs the user that despite the installation of the latest version of the word processor, the user will have to save files in a format supported by an earlier version of the program because most desktops in the organization are not running the latest release. Users' collaboration processes change to accommodate the software upgrade.
Figure 1.2: Moderately complex changes cause ripple-effect changes to a variety of assets.
The most complex changes cause secondary changes in a variety of assets, to varying degrees of importance, and in a number of process directions, as Figure 1.3 depicts. Consider the following scenario. An online retailer has received a growing number of complaints from customers about the quality of some of its products. Executives decide that it is time to revise the company's procedures for handling customer complaints. Call center supervisors will now have the authority to override the return material authorization (RMA) system to allow returns after the standard 30-day return period. What needs to change, the executives ask? Off the top of her head, the systems manager cites several changes:
Figure 1.3: Complex changes cause ripple effects in multiple directions and between artifacts in unpredictable patterns.
In addition, the executives realize that the following further changes are required:
In addition to these changes, the original change initiates several other business processes, which themselves entail change management. For example, within the IT department, the requested modifications will be evaluated by and approved by the change-control committee, scheduled by an IT manager, developed by a programmer on a development system, tested on a test platform, and deployed to production during a maintenance cycle. Within each of these steps there are procedures for creating a new version of RMA system modules, checking-in and checking-out the code during development, updating system documentation through version control procedures, and so on.
Changes are rarely localized to a single application or process; however, identifying all related secondary changes is difficult, especially when dealing with distributed systems.
This example highlights several issues common with application and system changes:
When assessing the scope of changes, be sure to consider how changes in one area, for example IT applications, create the need for change in other areas, such as training and Help desk support.
This example, while realistic, is somewhat idealized. We often do not know how the effects of a change in one system will affect another. How did the systems administrator know that the accounts receivable system would also need to be changed? Are there other systems affected by this change? Changes can easily introduce unintended consequences.
Suppose that the word processor upgrade described earlier also included new macro features that allow macros to run automatically when a document is open. As a further benefit, macros can now invoke other applications. A user could, for example, open a word processor document and then automatically open a related spreadsheet using this new feature. Several weeks after the upgrade, the user receives an email with a word processor document attached. The document embeds a macro that launches a virus that copies itself to other desktop computers on the network. The virus lies dormant for a few months, then replaces critical operating system (OS) files with bogus versions. Users across the department start to experience unexplained system crashes. The Help desk and IT support respond. They determine the cause of the problem, repair damaged systems, and upgrade virus scanners on desktops. Systems managers configure additional security measures on the email server and train users about the potential problems of macro-based viruses. Finally, the IT department updates policies and procedures to monitor for the newly discovered security threat.
To avoid such a scenario, when assessing the impact of change, consider the security consequences as well as the functional, documentation, policy, and training changes.
Even when change is managed, the risk of introducing an unintended consequence is always present, especially with the pace of change in technology trends, standards, best practices, and environments. Effective change-management procedures, however, give managers the tools they need to identify the causes of those unintended outcomes.
There is no single cause for the increasing complexity and challenge of enterprise change. Some of the most prevalent sources of change are rooted in trends that reach back a decade.
The business dynamics of the past decade have created unprecedented demands on IT. Deregulation, globalization, technological advances, and evolving management structures apply competitive pressures to every dimension of an organization—research, procurement, production, marketing, sales, and others. These competitive pressures force organizations to operate more efficiently. One common source of inefficiency is poor integration of business processes.
Department-level applications can efficiently address narrow operations. Delivering goods and services, though, typically requires linking a series of these operations. When applications are integrated, the links are fast and cost-effective. When links are based on manual intervention, processes are slowed and costs increase. As Figure 1.4 illustrates, much of the total time required to complete a process can be spent on inter-application manual procedures.
Figure 1.4: When applications are not efficiently integrated, manual operations are often required to complete a business process.
We now understand that additional efficiencies are gained by coordinating and managing change across the enterprise. Designers engineer better products with feedback from the production line. Inventories are better controlled when sales projections drive production schedules. Sales campaigns are more effective when tied to marketing initiatives. These efficiencies are realized when the enterprise uses closed-loop communications across business processes.
Efforts to improve operational integration and business process design were popular in the 1990s. IT has played a central role in several types of strategic initiatives undertaken since then:
Each of these developments represents a response to the evolving market dynamics that organizations have encountered in the past decade.
Enterprise applications such as ERP, CRM, and SCM systems have radically changed how organizations build and deploy applications. Prior to the 1990s, businesses often purchased offthe-shelf applications or built custom systems to meet departmental needs. If the procurement office needed a database to track suppliers and contracts, that department purchased the application. When shift supervisors needed a program to manage workers' schedules, one was built. The shipping department needed a database to track orders, so it put a database in place. The finance department had to track accounts payable, accounts receivable, and payroll, so it used an accounting package. These solutions typically met the localized needs of each department; unfortunately, these systems rarely worked well together.
In many organizations, the various applications often duplicated data. Customer information could be found in the shipping department's database as well as through the accounting package. Employee data was tracked in department scheduling programs as well as through the payroll system. In well-run IT shops, data is shared between systems. The payroll system, for example, might provide source data for the shift scheduling program. One system is designated the master, the others are the targets, and all changes are made in the master and propagated to the target systems. In practice, this scenario solves problems, but creates many problems as well.
Organizations have long realized that integrating department-level applications improves efficiencies. However, the cost of integration has been a significant barrier to implementing integrated systems.
This master-target scenario requires that the systems administrator develop or purchase a program to extract the data from the source system and load it into the target. (This requirement, in turn, creates yet another application to maintain.) The organization now requires procedures to control when the data loads occur, describe how to recover from failures, identify who is responsible for data and application maintenance, and expound on other change-management issues. However, the most troubling aspect of this approach is the potential for a growing number of systems needed to support these point-to-point integrations.
As noted earlier, organizations gain efficiencies by integrating applications that support a business process. In the past decade, IT staff has found itself linking applications in varying combinations because many applications were designed with departmental requirements, rather than business process requirements, in mind (see Figure 1.5).
Figure 1.5: Narrowly focused applications rarely support a complete business process.
Developers are left with the often tedious, error-prone job of linking these separate systems. Batch extracts and loads are a common, but crude, integration technique. In an attempt to improve data-sharing processes and minimize the chance of "reinventing the wheel," developers have begun using middleware applications to link disparate systems.
Point-to-point integration is a partial solution to the problems that businesses encounter through a silo-application setup. Unfortunately, this integration introduces new change-management issues. As the number of point-to-point integration systems increases, change management becomes more difficult.
Middleware is a class of applications that provide a common method for moving data between systems and invoking applications or procedures from external systems. Early middleware systems, such as remote procedure calls (RPCs) and remote database access, offers developers a common transport mechanism for moving data and invoking services. It does not, however, solve the larger organizational problem of aligning IT systems with business processes.
Middleware has evolved into more sophisticated mechanisms such as message queues and distributed transaction processing systems. With these techniques, developers can more easily implement full business operations. For example, when a patient submits a healthcare claim, the insurance company will need to verify the patient's coverage, validate the physician information, calculate deductibles, issue payments, and generate explanation-of-benefits letters. These steps are all part of the claims processes that might require several applications that are governed by complex workflow rules. If one step fails, the entire process fails. It is difficult to implement transaction processing logic using point-to-point integration schemes. Middleware, however, gets us one step closer to the ideal of one unified application for a business process.
Middleware provides a general mechanism for moving information between applications, as Figure 1.6 illustrates. One of the key advantages of middleware over point-to-point systems is the support for distributed transactions. These transactions allow developers to treat an entire business process, such as claims approval, as a logical unit of work. If one of the systems required by the process is down, the claim is not processed, and the operation is rolled back. Applications do not need to be aware of the implementation details of other applications in the process because these details are handled by the middleware.
Figure 1.6: Middleware, like message queues, reduce point-to-point connections but still do not solve the fundamental mismatch between applications and business processes.
Middleware solutions are definitely an improvement over point-to-point systems, but middleware solves only part of the problem. Business processes are still dependent upon multiple independent systems, each with their own purpose and lifecycles. Changes in one system can impact another. Dependencies are not always clear or well documented. When business processes change, multiple systems will have to change (and each of those changes potentially creates ripple effects causing still further changes).
Enterprise applications promised to solve these problems, and they did—to some extent. ERP systems integrate large-scale business processes such as manufacturing operations. Databases are unified and information is shared across departmental boundaries. Point-to-point integration is no longer necessary (or is at least significantly reduced). Middleware, when needed, is integrated into the heart of the ERP system.
However, implementing enterprise applications is more challenging and expensive than many adopters anticipate. Failures and delays are common. The industry and its customers underestimate the difficulty of implementing these systems. There are technical challenges, of course, but another source of problems centers on change management.
Unlike earlier system implementations that required coordination within a department, ERP, CRM, and SCM applications span organizations. Changes in one department ripple through to affect others. Thus, organizations, including designers and developers, have to change how they work. Programming mavericks ready with quick fixes for requirement changes and bugs are not welcome, and coordination is critical. As the scope of applications expands, so does the impact of changes.
Enterprise applications solve many process integration issues but introduce a new level of change management considerations.
Enterprise applications change the way employees work. These applications change the way supervisors manage. They change executives' expectations. They change IT. As previously mentioned, three common forms of enterprise applications are:
Each type tackles organizational processes from a different perspective, but all three cross departmental and sometimes LOB boundaries. Another common characteristic among these enterprise application types is that some of the most significant costs of these systems entail change, including:
Just as transaction processing systems evolved into enterprise-scale systems, decision-support systems grew to encompass broader views of the organization. The following list highlights the effects of enterprise applications on change management:
Executives and managers have long needed management information about production levels, sales quotas, quality control, and other key performance measures. Prior to the emergence of data warehousing, executive-management and decision-support systems drew data from several systems in an ad hoc manner to provide a unified view of core business processes. These early systems required custom coding and were often planned around immediate requirements rather than specific design principals. Fortunately, change management was easily controlled because these systems had few users and a small number of developers.
In addition to the development of enterprise applications, the 1990s witnessed the rise of a more systematic approach to executive information systems—the data warehouse. The data warehouse was not only a reporting system but also an enterprise-scale application for gathering, storing, and analyzing a broad range of topics. Data warehouses provide a historical, integrated view of an organization.
Data warehouses consist of four principal components: source systems; the extraction, transformation, and load system; the data repository; and reporting and query tools. Figure 1.7 shows a typical configuration.
Figure 1.7: Data warehouses provide a framework for standardized delivery of decision support information.
Source systems are typically transaction-oriented applications such as ERP, CRM, and financialmanagement systems. Multiple sources are typically required to gather all the information required to report on key performance indicators.
Extraction, transformation and load (ETL) systems collect data from the source systems. ETL systems then combine data streams, reformat data, derive calculated measures, and store aggregated data in a format suitable for use with ad hoc query tools.
Data repositories are usually either relational databases (such as Oracle 9i, IBM DB2, and Microsoft SQL Server) or online analytic processing (OLAP) databases. Relational databases are reliable, scale well, and provide robust management services. OLAP databases are designed for rapid response to multidimensional queries such as, what is the difference between this year's sales in the eastern region and last year's sales in the same region?
Reporting and analysis tools provide a range of functionality. Dashboards provide summary information of key performance indicators. Ad hoc query tools allow users to "slice and dice" data along multiple dimensions. OLAP tools support advanced functionality such as time series analysis and forecasting.
Data warehouses have emerged as the standard for delivering business intelligence to users across the enterprise. With this service, come demands on ECM. The following list highlights the effects of data warehousing on change management:
When e-commerce emerged in the late 1990s, the hype about the Internet changing the nature of business overshadowed the real changes underway in many organizations. (The fundamentals of business did not change—well-run companies that meet customer expectations and generate shareholder value survive, others do not.) The real story of change centered on how a new sales channel, the Web, provided low-cost access to a vast market while simultaneously opening the organization to a wide array of competitors. At the same time, the Web brought business closer to suppliers and enabled more efficient procurement operations.
Initially, businesses needed to implement basic applications, such as online catalogs, contentmanagement systems, and secure transaction processing. Then they needed to address customer support, marketing, promotion, and other ancillary functions. The most innovative businesses integrated the Internet channel directly into ERP and CRM systems. Multi-channel selling—for example, call center support for online shoppers—further improved customer options while introducing more complexity to the IT infrastructure.
E-commerce makes demands on virtually every area of IT. Mainframe and client/server programmers were finding that their programs needed to adapt to a new development model. Network administrators and engineers became well versed in firewalls, router security, demilitarized zone (DMZ) architectures, key systems, and virtual private networks (VPNs). Operational managers accustomed to nightly maintenance windows had to adjust to 24 × 7 system uptime. But IT was not the only department affected.
Selling online is not the same as selling in the brick-and-mortar world. The Web lets customers move to a competitor's site in a few clicks of a mouse. Marketing executives, copywriters, and graphic designers had to change their craft to conform to the Web audience's expectations. Usability became a focus of attention. Technical staffs started working directly with their marketing colleagues. The Web was eliminating degrees of separation within businesses. The following list highlights the effects of e-commerce on ECM:
The Internet brings threats as well as benefits to organizations. Unless properly configured, networks open businesses to a range of threats from system disruptions to theft of confidential information. Organizations are subject to:
Reducing security threats requires detailed knowledge of system vulnerabilities and methodical attention to change management. As new systems are introduced to networks, the systems must be secured. IT staff must configure local elements, such as administrator passwords, system processes, and network ports to provide required services without running unnecessary processes that might be vulnerable to attack. Systems administrators work to ensure that new servers don't operate in conjunction with other systems to open the network to hackers. For example, a hacker may not be able to connect directly to a vulnerable database server but could tunnel through HTTP and, once inside the firewall, execute an attack on the database.
Systems administrators today maintain a guarded skepticism when introducing new applications. As many have realized, sometimes too late to prevent problems, the introduction of new technology entails risks. As researcher Diomidis Spinellis noted in Software Reliability: Modern Challenges "[M]odern computer processors are often delivered with errors....Operating systems and programming languages are becoming increasingly complicated and their implementations less trustworthy. In addition, component-based multi-tier software system architectures exponentially increase the number of failure modes, while Internet connectivity exposes systems to malicious attacks. Finally, IT outsourcing and blind reliance on standards can provide developers with a false sense of security."
Again, as with enterprise applications, data warehouses, and e-commerce, a series of fairly localized changes in the overall IT infrastructure creates a web of interdependencies. The following list offers the effects of security threats on ECM:
As we've explored in the last section, the IT administration profession has adapted rapidly changing technologies to evolving business structures and processes. From implementing enterprise applications, business intelligence, and e-commerce systems to responding to security threats and protecting computing infrastructure, IT departments have played a central role in the success of many organizations. But they have also been closely tied to failures.
For IT professionals, it is difficult to hear that many of our projects have been failures; that if cars were designed like computers, they would crash twice a day; or that projects will not be funded because they do not generate a sufficient return on investment (ROI). The perception that IT has failed to meet many expectations is fueled by three distinct problems:
IT has had more successes than failures, and it remains an essential element in business strategy for virtually all organizations, but that does not get IT off the hook. As change-management consultant Jim Love described it in "Return to Value" (Intelligence Enterprise, May 13, 2000), "Every period of excess has its hangover. The last decade ended with the revenge of the nerds, but this one begins with the revenge of the accountants. The free-flowing cash is gone, and resource-strapped companies have found themselves struggling to make every dollar count. No corporate division has paid a greater price for past excesses than IT."
American companies started the 1990s allocating 30 percent of capital expenditures to IT; they ended the decade spending almost 50 percent of all long-term investment on IT (as cited by Nicholas Carr in "IT Doesn't Matter" in the May 2003 issue of Harvard Business Review). Unfortunately, ROI was one acronym rarely heard in developer bullpens, machine rooms, and IT conference halls. A combination of intuition, herd mentality, and blind faith in technology allowed IT to avoid the rigorous capital expenditure analysis to which other business units were subjected. Those days are gone. IT projects have to pass the same financial muster their brickand-mortar counterparts do.
To pass muster, ROI analysis must be based on quantifiable, tangible savings. Are you deploying a supply chain–management portal to reduce the number of documents mailed to vendors? Doing so leads to quantifiable savings in printing and postage and is likely a sound investment. Are you deploying an enterprise information portal so that knowledge workers can collaborate and save time searching for information? The ROI for this project is not as clear as for the previous example, but the project may still be justifiable. Do you want to deploy an HR portal so that employees can get corporate news, look up leave-time balances, and check email from the Web? As far as ROI is concerned, this project doesn't stand a chance. A combination of poor performance in high-profile projects and increased visibility of IT projects is driving the demand for better control of IT capital spending.
The increasing visibility of IT projects contributes to the need for effective ECM.
Trade magazines regularly feature stories of troubled big-ticket projects at Fortune 500s, overspending on software licenses, and "how-to" techniques for saving failing implementations. For example, in 1999, Hershey made news when its broad SAP/R3 implementation ran into trouble during one of its busiest times of the year. However, internal concerns are not the only factors driving IT to better manage capital projects.
CEOs and CFOs are always pressured by market conditions, but changes in government regulation are adding momentum for them to better understand IT expenditures. In the United States, the Sarbanes-Oxley Act of 2002 enacted widespread changes in corporate governance and
financial disclosure. CFOs are signing off on quarterly financial reports that include IT expenditures, so accurate reporting is essential. Corporate officers, boards of directors, and shareholders are closer now to enterprise projects than ever before.
Government regulation as well as market factors are accelerating the demand for ECM.
As if poor ROI isn't bad enough, businesses have received systems that did not meet requirements or reflected inaccurate requirements. Consider the following:
Clearly, tighter communication between users and designers and architects is required. More emphasis is needed on processes and workflows rather than simply on isolated behavior of individual components and subsystems. Unfortunately, if communications are clear and development is managed, the ultimate results might still be less than expected.
Meeting the localized needs of a department or LOB does not guarantee the best outcome for the enterprise as a whole. "[I]t has been demonstrated time and again that local optimization leads to global suboptimization, contrary to the popular belief that what is good for the function is good for the enterprise. As an example, a functional area might "batch" inbound work so that each item dealt with the least common effort, although that ultimately delays almost every aspect of the process" (quoted from Alec Sharp's "A Briefing on Business Process" in Business Briefing: Data Management and Storage Technology 2002 at http://www.wmrc.com/businessbriefing/pdf/data_2002/publication/sharp.pdf).
Increasing spending on IT rarely translates into superior financial results for companies overall.
In the results of a survey performed by Alinean of 7500 large United States companies, the top 25 performers spent only 0.8 percent of their revenue on IT while the average company spent 3.7 percent. A similar study by Forrester Research showed those companies that spent the most on IT rarely realized the best results (cited by Nicholas Carr in "IT Doesn't Matter"). If Carr is correct, and the numbers seem to back his argument, then managing risk, using technology efficiently for generic operations, and leveraging innovative, proprietary processes are key to aligning business and IT strategy.
Beware of measuring local impact of change, it may not correspond to the overall benefit or cost to the organization.
Businesses in general and IT departments in particular are reacting to the failures, missed opportunities, and changing market drivers of the recent past. Some of these changes implement improved financial controls, some create closer collaboration between IT and LOBs, and others draw IT deeper and broader into business processes that span the enterprise.
IT operations are becoming more closely aligned with LOBs. This realignment comes in several forms:
Closer alignment of IT operations with business units' day-to-day operations improves communication and control of technology projects. Situations such as the previously sited example of the CRM system that was cumbersome, confusing, and unfriendly are less likely to occur when users "in the trenches" actively participate in system development.
Weaving IT operations into the fabric of LOBs also allows for improved project portfolio management. When IT projects are segregated from other projects, the organization is likely to miss the optimal combination of projects. This missed opportunity can occur in two ways: First, because projects are selected from separate groups, the value of each is compared with others in the group instead of from across the organization. Second, the ultimate set of projects selected may not be the best mix of projects. For example, an e-commerce initiative funded through IT may not realize its potential ROI because a complementary marketing campaign was not funded. Techniques such as enterprise portfolio analysis prevent this type of problem by determining the optimal mix of projects, investments, and activities based upon an organization's strategic goals. The trend toward value management and portfolio management can lead to a cost savings of more than 30 percent according to some industry analysts.
This closer union between business and IT units has led to several successful patterns for improving the overall benefit of IT operations, including:
The relative benefit of each of these approaches varies among organizations, but the following sections describe the most common benefits and risks.
Risks to business from IT infrastructure have many forms—security breaches, system failures, and unintended consequences of changes, to name just a few. Minimizing risks requires technical knowledge as well as an understanding of business processes. As we've explored, as systems become more integrated, changes to one application can cause ripple effects that propagate to other systems. LOB managers and system designers need detailed information about interdependencies, process flows, and the timing of events. Silo-based change-management procedures are no longer sufficient.
Efficient use of technology not only requires vision but also requires technical savvy and business discipline. Areas for obvious savings include software licenses. According to one Gartner study, companies that buy more licenses than they actually need will increase total cost of ownership (TCO) of the software by 20 to 30 percent by 2005. Do companies even need to spend any money on software licenses? This question is gaining greater scrutiny as companies investigate the viability of open-source software.
Open-source OSs and Web servers such as Linux and Apache are the most well-known opensource products, but a wide variety of products are available under open-source licensing. Even commercial enterprise applications have open-source competitors such as Ohioedge CRM Server (http://www.ohioedge.com/factsheet.html) and Compiere ERP and CRM Business Solution (http://www.compiere.org/), both of which are designed for the small and midsized company market. Organizations are more likely to consider open-source alternatives as companies realize that the success or failure of a project is not only determined by the software but also by how business processes are implemented and adapted to the applications.
Another trend that demonstrates the commoditization of IT is outsourcing. Companies with core competencies in financial services, healthcare, transportation, energy, and retail are applying the long-understood principal of division of labor to IT. Standardization of hardware, enterprise applications, and networks are reducing barriers to outsourcing. Simultaneously, globalization is creating opportunities for cost-competitive IT service firms outside the United States and Europe to enter lucrative international markets. The trends are clear (the following statistics are from the META Group):
Outsourcing creates new management challenges. Designers and architects may be half a world away from developers implementing designers' plans. Understanding requirements is difficult enough in close-knit teams; international outsourcing adds geographic distance, time delays, and the potential for cultural misunderstanding. Much IT is now a commodity. Strategic advantage is gained not by technology alone, but by the integration and optimization of business processes within the corporation and beyond to suppliers and customers.
Technology alone does not provide strategic advantage to a company. Competitive advantage arises from applying technology to proprietary business processes.
Executives and LOB managers are realizing the need to manage business processes and related changes across the enterprise. Both market forces and government regulation are driving this trend.
Operational integration can lead to significant gains when proprietary business processes are extended by traditional organizational boundaries. For example, consider Dell Computer Corporation and Walmart. Both companies sell commodity products in highly competitive markets, yet they are more successful than most competitors. One technique used by both companies is tight supply-chain integration.
After September 11, 2001, the sale of American flags surged and two retailers, Walmart and Target, sold a majority of the flags. Walmart's point-of-sale system is tightly integrated with its suppliers, so replacements were automatically ordered as inventory began to drop. By the time Target placed its restocking orders, it was too late—the sole supplier was out of stock. Wal-Mart beat Target to the punch.
Dell also uses close-knit supply-chain integration. In addition, the company extends its information sharing to customers. Customers are segmented into eight categories: global enterprise accounts, large companies, midsized companies, federal, state and local, education, small companies, and consumers. Programs are customized for each segment based on information gathered from customers. As Michael Dell describes it, information about customers is essential to the company's success. "It's a key part of why rivals have great difficulty competing with Dell. It's not just that we sell direct, it's also our ability to forecast demand—it's both the design of the product and the way the information from the customer flows all the way through manufacturing to our suppliers…We simply couldn't do it without customers who work with us as partners" (quoted from Joan Magretta's "The Power of Integration: An Interview with Dell Computer's Michael Dell" Harvard Business Review, March-April 1998). In some cases, tight management controls are not optional, they are required by law.
Change-control boards are centralized bodies that review change requests and project plans, monitor project development, and provide a communication channel for stakeholders involved with application development. The advent of change-control boards brings new policies and procedures that govern IT. Change-control boards may focus exclusively on IT operations; however, in many industries, it is becoming clear that change must be managed across full business processes. Government regulations, for example, are driving several industries to broaden the scope of change control.
Regulatory demands from federal, state, and international governments are imposing strict requirements on change management within particular industries. Several recently enacted laws in the United States, for example, are forcing organizations to implement change-management procedures that span the breadth of operations:
Administration (FDA) has initiated a program to identify current good manufacturing practices (cGMP) for the pharmaceutical industry. The objective of the program is to improve the overall quality of medications while promoting innovation and continuous improvements in the industry. The regulations regarding cGMP, referred to as 21 CFR Part 11, cover the breadth of pharmaceutical manufacturing. Topics addressed include:
Across these topics, there is an emphasis on the importance of data integrity and records management. These regulations mandate that pharmaceutical companies implement two dimensions of ECM: application change control and data integrity. Once operational systems are validated, change-control procedures must be in place to ensure unapproved changes are not made. According to the FDA, changes made after systems are deployed are the cause of almost 80 percent of all software failures in recalled medical devices. Change-management controls, including audit trails, are key tools for identifying and correcting those bugs.
The regulations also specify record retention requirements for data generated by these systems. Data must be accessible for the duration of the record retention period, so manufacturers have two options for managing the data. The time capsule approach uses the original electronic media and system that generated the data. With constant improvement in instruments, software, and storage media, this approach requires that companies maintain legacy systems to remain in compliance while upgrading technology to remain competitive. The second approach, electronic records migration, copies records to new storage devices as the devices become available. With this method, companies must ensure the integrity of data throughout the records migration process. This requirement is met through the use of validated systems, audit trails, and enforced policies and procedures. Change-control procedures enable companies to remain in compliance with regulations without unnecessary expense or the need to maintain obsolete systems.
Each of these laws defines requirements for the way in which data is accessed, stored, transmitted, and audited. These are not technology regulations, they are enterprise-wide regulations covering several business processes. Change management is no longer the sole responsibility of one department or LOB but spans the organization.
These three regulations are just examples of the types of regulatory requirements that are affecting a wide range of industries. Other governments, including state governments in the United States and the European Union, are also passing regulations that make greater demands on ECM.
Government regulations are introducing new demands for ECM. Individual applications and business processes are not regulated—broad abstract entities, such as healthcare information, and entire production processes, such as the development of drugs, are the subject of these laws. Silobased approaches to change management are no longer sufficient to meet these requirements. Change-management processes must encompass the entire organization, address procedures and systems and artifacts, and support closed-loop communication to maintain control of operations.
IT departments across industries are assuming more responsibilities. Businesses can no more function without IT than they can operate without electricity or telephone service. Technology is woven into the fabric of business processes. The processes span the organization and, by necessity, so does IT's reach. IT's responsibilities are growing along three dimensions:
Each category represents a distinct set of demands.
The demands on IT departments from a technical perspective are well understood. IT staff are responsible for a range of systems, including:
Each of these areas requires distinct expertise and careful attention to interdependencies between systems. In addition to the breadth of applications, the characteristics of these systems are changing. For example, as Web services become more established, they could radically increase the number of integration points between systems. Businesses are demanding information faster. Real-time data warehousing provides updated information to decision makers throughout the day. Integrated supply-chain–management systems update inventories and initiate orders as goods are purchased. IT permeates most, if not all, core business processes.
As systems become more integrated and as the need to keep systems constantly online grows, the maintenance challenges increase. ECM techniques are needed to assess the impact of changes. Executives and managers are demanding information that allows them to proactively prepare for change and reduce emergency change orders.
From the organizational perspective, IT serves a diverse user base. Internal users range from finance and HR executives who are managing to key performance indicators to scientists and engineers who are using a wide range of instruments and specialized software for research and development. Of course, the user base does not stop at the company doors. Supply-chain partners are integral components of core business processes. Customers are a growing base of users for many organizations. The Web enables direct sales, marketing, and support to customers. And Web self-service is rapidly emerging as a cost-effective alternative to call center support for many businesses.
The variety of needs of these distinct users requires that IT not only maintain systems but also understand how customers' needs relate and create networks of dependencies. For example, if a mobile telephone manufacturer provides online access to technical support databases, resellers can deploy self-service Web support directly to the manufacturer's customers. The reseller must then maintain close communication on changes to the support database that affect end users. Analyzing patterns of use in the self-service site supplied by the reseller can provide insights to the manufacturer about usability, reliability, and the need for new features.
In the past, IT departments were considered overhead operations. Their services were not directly related to revenue-generating operations. Decisions about which new technology to deploy or which systems to upgrade were made based upon a broad conception of the overall good of the company. More and more, IT services are tied directly to costs and revenue lines. CIOs are responsible for profitability. IT departments charge back expenses to LOBs that make decisions about technology expenditures. In some cases, IT staff report directly to mangers in operational units. This distribution of financial and human resources make management and coordination of IT operations even more difficult than when IT was highly centralized.
IT staffing models are also changing. Outsourcing is increasing and companies are turning to subcontracting to maintain staffing levels without increasing the number of full-time employees. Virtual teams bring vendors, consultants, subcontractors, and internal staff together on an ad hoc basis to meet specific objectives.
At a time when IT responsibilities are growing, the traditional centralized-management structure is being eliminated. This transformation compounds the need to create and maintain closed-loop communication channels so that changes in one area of operations are accommodated by related operations. In effect, IT organizations are asked to manage more complex infrastructures with fewer staff and more complicated management structures. Clearly, new types of procedures and tools are required to control this dynamic environment.
Although we might sometimes think we are in the middle of a new and radically different world from anything seen before, we should remember Oliver Wendell Holmes' insight that "a page of history is worth a volume of logic." Organizations are managing new competitive pressures, leveraging new technologies, and adapting to shifting customer expectations and government regulations. Those that will survive and thrive will do so by focusing on business fundamentals:
We only need to consider the history of the mainframe to see the persistence of patterns in the history of business and technology. In the early days of IT, mainframes were the dominant technology. Minicomputers introduced the first of a set of alternative technologies that eventually evolved into client/server computing. Today, the benefits of centralized computing are rematerializing as large organizations consolidate servers and turn to running heterogeneous applications and OSs on mainframes. The return to mainframes, while enabled by technical advances such as Linux on the mainframe, is driven by fundamental business objectives such as cost control.
ECM is one of the fundamental technologies for ensuring organizations meet their objectives. Disciplined change management enables essential management objectives such as:
Throughout this book, I will discuss specific elements of ECM, such as the software development lifecycle, hardware configuration management, and document control. All of these factors contribute to the overall objective of harnessing change to advance the objectives of the enterprise.