Reflections on the systems integration enterprise

Reflections on the systems integration enterprise

Reflections on the systems integration enterprise

For a number of years now, IT-using organizations have invested heavily in systems integration. Enterprise resource planning (ERP) systems are an obvious manifestation of that trend. In this viewpoint for the special issue of BPMJ on ERP, I would like to share some observations about the systems integration enterprise from my several years on research on ERP systems and related technologies.

Integrated systems require more integration

First, information systems (IS) researchers cannot afford to study ERP systems in isolation from other systems investments. ERP systems are fascinating. They are enormously complex, and implementing them is difficult, expensive, and failure-prone (Bashein et al., 1997; Markus and Tanis, 2000; Markus et al., 2000a, forthcoming). They raise new technical and managerial issues. However, for most adopting organizations, ERP systems must be integrated with a variety of other systems and technologies. IS research and teaching should focus on the entire package of systems and technologies, not just on the individual components. (Indeed IS research and teaching should also focus on the non-technological aspects of systems, see Stijn and Wensley, "Organizational memory and the completeness of process modeling in ERP systems", this issue.)

The original vision of the ERP system was an environment of seamlessly integrated data and processes, created by a single software package that handles every business need. In reality, however, most ERP adopting organizations do not have a seamlessly integrated environment. Instead, they must, and do, actively integrate their ERP systems with other applications and technologies (see Themistocleous, Irani and O'Keefe, "ERP and application integration", this issue).

Organizations have "seamful" environments for several reasons.

1. 1.

   To call ERP systems "integrated" is something of a misnomer. The software may be integrated, but to make the software work, organizations must integrate the software with a technology platform of hardware, networks, database software, etc. Research shows that the integration of ERP software with an operating environment is a non-trivial task.

2. 2.

   To reduce implementation risk, companies may decide to implement ERP systems in stages. During the transition, they must integrate ERP system modules with legacy applications.

3. 3.

   Some companies choose to implement only one or a few modules of an ERP system. They never plan to replace their legacy applications completely. Therefore, some degree of integration with legacy applications is required.

4. 4.

   ERP packages may lack essential company-specific or firm-specific functionality. (See Clemmons and Simon, "Control and coordination in global ERP configuration", this issue.) Therefore, companies may be forced to integrate the ERP system with legacy systems or with bolt-on packages designed to work with the offerings of a particular vendor.

5. 5.

   Some companies prefer to choose the best modules from each of several ERP vendors in a "best-of-breed" implementation (see Light, Holland and Wills, "ERP and best of breed", this issue). This strategy requires systems integration.

6. 6.

   ERP packages are designed to process transactions and do not meet companies' needs for reporting and decision support. Most ERP adopting companies, therefore, find themselves also implementing data warehouses, with which their ERP systems must be integrated.

7. 7.

   Companies' decision support and analysis needs cannot be entirely addressed by the internal transaction data captured by their ERP systems. They may, for example, need to query historical data that were never loaded into the operational databases of the ERP system. Or they may need to analyze their sales and customer data in conjunction with purchased marketing data. For these reasons, they need data warehousing technology as a complement to their ERP systems.

8. 8.

   ERP systems are designed to address companies' needs for internal data and process integration. They do not satisfy companies' need for external data and process integration. Consequently, companies seeking tighter coordination with customers and suppliers must integrate their ERP systems with other applications and technologies.

This list of reasons is probably incomplete. Suffice it to say that, for most organizations, ERP systems are not a standalone IT investment, no matter how expensive and challenging they are to implement. Today, most ERP adopting companies have complex assemblages of ERP systems, other applications, data warehousing technology, and infrastructure technologies knitted together with the technologies of integration (called "middleware" or "enterprise application integration") (Bashein and Markus, 2000).

In many companies, the process of integrating systems and technologies has come to overshadow application development, application maintenance, and package implementation in level of effort and importance. Yet systems integration is not well understood in the IS field, it is not the subject of much IS research, and it is rarely taught in schools. Clearly, this situation cannot continue if we are to remain responsive to the changing conditions of practice. Systems integration must become a major focus of IS teaching and research. (See Hawking, Ramp and Shackleton, "IS '97 model curriculum and enterprise resource planning systems" and Stewart and Rosemann, "Industry-oriented design of ERP-related curriculum – an Australian initiative", this issue, for two such proposals.)

Integrated systems may be unintegrated with the business

Second, IS research needs to understand that (and how) systems integration can "successfully" proceed without business alignment. It is a truism in the IS field that successful IT implementation requires business involvement and alignment. (Consequently, much IS research rightfully addresses the roles of executives in system adoption and implementation. See Dong, "Modeling top management influence on ES implementation" and Bernroider and Koch, "ERP selection process in midsize and large organizaitions", this issue.) However, in my research on ERP systems and systems integration, I have found to my surprise that there are perfectly valid reasons for pursuing systems integration independent of business needs. Consequently, organizations may acquire more systems integration than they need for business reasons or they may have the wrong kinds of systems integration that they need for business reasons. IS teaching and research should address this important issue.

I make the distinction here between techno-economic and business (or strategic) reasons for adopting integrated information technologies. Examples of techno-economic rationales include: adopting an ERP system will reduce systems maintenance costs by outsourcing maintenance to the vendor and spreading the cost over many other users, or implementing a data warehousing and analysis environment will reduce the IS effort required to produce the business reports demanded by users, freeing IS personnel to concentrate on other important activities. Examples of strategic business rationales include: systems integration will enable a decentralized company to present one face to the customer or, by implementing an ERP system, this globally dispersed company will achieve global inventory visibility.

Some readers may object to this distinction on the grounds that both types of rationales provide business benefits – saving money on its IS operating environment is, after all, of value to any company. Therefore, it may be argued that achieving any kind of business benefit is a measure of IT investment success. But I defend the distinction. I have learned that it is possible for IT investments to be techno-economically successful but a failure in strategic business terms. And I believe that making this distinction is key to the realization of strategic business success.

Let me give some examples from my research (Markus, 2000, forthcoming). Organizations can suffer from lack of systems integration in many ways. Aging legacy systems may have high operating costs owing to mainframe processors and demands for maintenance. Business people may be unable to obtain needed reports and analyses without expensive custom programming. As a result of unintegrated systems, sales people may be unable to tell a customer how much of the company's products the customer buys in total; they may be unable to respond quickly to customers' inquiries about product availability; and marketing people may be unable to enforce a consistent pricing policy across the company sales' regions.

Clearly, such organizations can benefit from better systems integration. But it is possible to achieve the techno-economic benefits of systems integration without also satisfying the business needs. And my research suggests that this situation of partial success is quite common.

Achieving one face to the customer, global inventory visibility, and better management decision making requires more than just the technologies of integration: it requires business coordination. For example, the different divisions of a company may need to agree on a common product or part numbering scheme; they may need to adopt common configurations of an ERP system; they may need to standardize definitions of important business terms like "sale" or "full-time equivalent". Many organizations find it easy to implement the technologies of integration without performing the more challenging business coordination. As a result, they achieve some benefits, some measure of success. But the business needs may remain unfulfilled. In my research, for example, I saw two similar manufacturing plants in the same division of a company implement ERP systems from different vendors (Markus et al., 2000c). This division may have reduced its IT operating expenses, but it certainly did not achieve business integration from its ERP implementation (though it may later have done so with an additional investment in enterprise application integration).

IS research and teaching has assumed an equation between business alignment and implementation or investment success. This is a type of reductionist thinking on our part, just as businesses may engage in reductionist thinking by seeing ERP systems as a panacea (see Wood and Caldas, "Reductionism and complex thinking" (forthcoming)). The reality is more complex. It is possible to achieve success without alignment. Not full success, perhaps, not strategic success, but certainly enough success to justify a large financial investment in systems integration. Unless we IS academics make finer-grained distinctions between types of investment rationales and types of business benefits, we may be unsuccessful in convincing business people to improve their practice.

Integrated systems may not support inter-enterprise integration

Lastly, IS research and teaching should address fit (or lack of fit) between today's systems integration paradigm and tomorrow's business integration needs. My growing concern is that there is a major disconnect between society's large-scale enterprise of internal systems integration and society's needs for smoother business-to-business interactions.

Through ERP systems, data warehousing, and enterprise application integration, companies have been striving toward ever tighter internal integration of information systems, data, and business processes. In theory, at least, our technologies of integration have developed to the point where we can tightly integrate the internal workings of entire large, complex organizations. (In practice, we are still well short of this goal for the largest multi-divisional global enterprises.)

But the focus of much business attention today is on how well businesses integrate externally with customers and suppliers (and sometimes even with competitors given the current culture of "coopetition"). I believe that today's paradigm of tight internal systems integration will not extend gracefully to the needs of inter-organizational business. I can see at least five business trends or potential trends that pose serious challenges for strategies of systems integration.

Mergers and divestitures. Even with today's "standard" packages and technologies, companies have unique internal systems environments. As just a single, simple example, most companies use idiosyncratic schemes to number parts and products: translations are required when dealing with customers and suppliers. When two companies merge, combining their operations usually requires changes in both the business practices and the systems of at least one partner. When Cardinal Health became a national drug wholesaler through the merger of separate companies, it had something like 11 different order entry systems (with different product numbering schemes) in 12 different business entities (Bashein and Markus, 2000).

Companies have been observed to spend much time and huge sums implementing ERP systems, only to abandon their investments after they merge (Larsen and Myers, 1997). A similar concern has been raised about the technology of enterprise application integration. Today, these are proprietary, closed technologies. When two companies that have integrated their systems using EAI from different vendors merge, one of the two may have to abandon its investment (Spender, 2000).

Like all immature technologies, however, EAI tools have their shortcomings and potential pitfalls. … But no matter how much time or money an integration project consumes, it will likely still fall short of providing the full system integration that has become the ambitious goal of every CIO. While EAI tools are handy for connecting a single application to another, few – if any – can provide"many-to-many" integration, or link multiple applications to other application sets under a common interface. … Many-to-many integration becomes even more complicated when one of the integration targets is another EAI tool. Companies facing post-merger or post-acquisition integration projects are often forced to develop EAI-to-EAI hookups. But EAI vendors have, for the most part, not focused on developing tools to link each other's applications. However, if two companies have systems tied together by EAI applications, those applications need to interface with each other and serve as a point of connection between systems. Furthermore, the still-maturing EAI market simply hasn't produced many tools aimed at facilitating the difficult process of integrating the integration tools."I don't think anybody makes middleware that adapts middleware to middleware", Spano says. "They want you to replace it. That's definitely going to become an issue" (Spender, 2000).

And what happens when companies are divested or spun off? Huge efforts are often required to disconnect their operations from those of parent companies.

Given the pace of business integration and disintegration, today's strategies of internal systems integration seem extraordinarily wasteful and ineffective. It has been said that the life of a business strategy today is six months. What does it mean when it can take 18 months or more to achieve systems integration or disconnection? The business need seems to be the ability for companies to quickly connect and quickly disconnect from each other. Today's systems integration paradigm does not afford this capability.

Increasing numbers of business partners. An interesting business development of recent months is the appearance of purchasing and trading exchanges in industries where business has traditionally occurred without intermediaries. One of the benefits claimed for such exchanges is that they will increase the number of partners (suppliers or customers) to whom companies have ready access.

Today, the plan seems to be for the exchanges to pass basic transaction data between the transacting parties. Each party redundantly processes and stores information about the transaction. Complex interactions between the parties (contact negotiations, sharing production schedules) would require, as today, specialized interconnections such as extranets or electronic data interchange. These connections are dyadic – they need to be customized for each pair of partners and individually maintained. So, more partners mean more interconnections, putting increasing pressure on companies' systems integration capabilities.

Some people put their faith in XML as a solution to these interconnection problems. But experts warn that XML is not a panacea – at least not yet.

As we have already noted, however, XML is not yet a panacea. … Finally, much of the content used by corporations does not lend itself well to conversion to XML. In reality, only structured data or documents that currently contain richly descriptive metadata are good candidates for conversion. Without descriptive meta-tags, XML documents are simply long blocks of text, and the conversion process requires enormous overhead with no demonstrable gain (Plumtree, 2000, p. 7).

As of today, companies must agree on meta-tags, just as they must agree on the formats of EDI transactions. One wonders if a simpler solution is just to let the exchanges do the information processing for participating members.

Business process outsourcing. Another interesting trend is the outsourcing of business processes. Among manufacturing firms, it is increasingly common for companies to outsource to a logistics partner all tasks associated with arranging for the shipment of parts from suppliers and the shipment of finished goods to warehouses, distributors or customers. Instead of dealing every day with many suppliers, customers, and shippers, the companies deal only with the logistics partner who manages all other transactions. More recently, large companies have begun to outsource administrative processes such as human resources benefits administration.

These changes simplify a company's information processing tasks, but they require tighter systems linkages with the intermediating process outsourcing firms. Whose systems are used? In some cases, one imagines, the outsourcers rely on the customers' systems. But as customers expect to benefit from their outsourcers' expertise, the outsourcers may increasingly use their own systems.

Interfacing the outsourcers' systems with those of customers (and other parties such as the customers' customers and suppliers) will create a growing burden on companies' systems integration capabilities. I studied a subsidiary of a large corporation, in which the subsidiaries had independent information management regimes except for financial systems, which the parent managed for them. The subsidiary was having great difficulty integrating its sales and manufacturing systems with the financials of the parent, which was essentially providing a financial application hosting service. As business process outsourcing gains popularity, these problems will only grow.

N-way transactions. Purchasing exchanges and business process outsourcing are examples of transactions involving three or more parties instead of the traditional two. As organizations become "virtual" and networked, the number of transactions involving multiple parties will surely grow.

Cisco reportedly manufactures fewer than 40 per cent of the products it sells, a fact that is not in itself uncommon. However, in many cases of outsourced manufacturing, the selling company buys manufactured products from suppliers then resells them to customers in what is essentially a pair of two-way transactions. But this is not what Cisco does. Cisco takes orders and payment from customers, then transmits orders and (a different) payment to suppliers, who ship the products directly to the customers. Thus, Cisco never owns nor even touches many of the products it sells.

Today's ERP systems are not designed to handle n-way transactions like the one described above (Wouters et al., 1999). One popular ERP package does not allow (without modification) companies to account for products it does not own.

With n-way transactions, all three or four parties have information needs. All three or four parties will be trying to track their sides of the transactions, while sometimes lacking visibility about other sides. Multiply this situation by many partners, and ask yourself whether today's system integration paradigm is up to the challenge. I think you will agree with me that it is not.

Collaboration facilitation. A particularly interesting sort of n-way transaction involves supply chain facilitation. It has long been recognized that supply chains can improve their collective performance (less inventory in the system, fewer stockouts for the customer) by sharing information about inventory, production capabilities, and needs. But in some supply chains, the business partners do not trust each other enough to provide this information freely and accurately.

Consequently, third parties are proposing to act as trusted intermediaries in the facilitation of information sharing in supply chains (Wouters et al., 1999). Instead of providing raw information to each other, supply chain members provide it to a third party (often a logistics company in partnership with an ERP or e-commerce system vendor) who produces optimized production and shipment schedules which are then shared with the members.

Again, one wonders about the information processing arrangements collaboration facilitation entails. It could be of course that each party will provide the facilitator data from its own system and take as input to its system the output provided by the facilitator. Certainly, the ERP vendors hope this will be the case, since it favors the sale of their systems. But another possibility is for the supply chain facilitator to take over supply chain related information processing for members. This arrangement could substantially reduce chain-wide information processing costs, which like inventory reductions, would increase the competitiveness of the chain.

In short, these five business trends all suggest that there may be a better way to manage external business integration needs than attempting to apply today's internal systems integration paradigm with business partners in a pair-wise fashion. (Naturally, also, there are many objections and barriers to the implementation of a better way.) If so, what might the future of systems integration be? Naturally, my crystal ball is no clearer than anyone else's, but the possibilities include the following (Markus et al., 2000b, forthcoming).

IT managed by third parties and consortia on a shared basis. In the future, IT applications and infrastructure might be built or configured, operated, and managed on a shared basis, rather than individually for each participating company. The providers of such services could be a consortium of members of the exchange, industry, or supply chain. Or, it could be a third-party such as the exchange manager, the business process outsourcer, or the supply chain facilitator.

Data integrators. Many companies are likely to participate in several exchanges or outsourced business processes. They would need integrated data (if not also integrated processes) to coordinate these disparate arrangements. It is likely that some third-parties would arise to integrate data from these varied sources, combine it with purchased external data such as marketing and economic research data, and provide an integrated environment for companies' reporting, analysis, and data mining needs.

Industry-wide data standards. Industry-wide agreements about the naming and descriptions of parts, products, and services, would facilitate e-commerce regardless of the other developments discussed here. And it is already starting to happen, notably in the pharmaceutical industry.

Industry-wide process standards and shared data. Less plausibly, certain business communities might decide that they can gain cooperative advantage from common business processes and shared data. This is more likely to occur, I believe, where smaller firms join forces to compete with a dominant firm. Even then, trust among the partners would be critical to the success of such tight external business linkages.

Mobile technologies triggering the paradigm shift. Information technology has a great deal of inertia. That is the implication of the term "legacy system". Companies do not usually make radical changes in their IT investments until those investments reach the end of their useful lives. Only the looming threat of Y2K, for example, motivated many companies to install ERP systems. Now that their ERP systems are up and running, there is not much interest in ERP application hosting since it is a big change for little benefit. One of the primary advantages of application hosting is that companies can get up and running more quickly than with in-house installation. In today's fast moving business environment, "quick to market" can be a major advantage – but only if you are not already there.

Not surprisingly, ERP application hosting is of greater appeal to companies who are now installing or replacing ERP systems. And companies with established ERP systems have been much more willing to consider application hosting for the newer customer relationship management systems. These factors suggest that if companies are not willing today to abandon their in-house systems integration paradigm for shared systems, they may be willing to do so when they decide they need major changes in internal systems functionality.

That time could be close at hand. Much of the talk today concerns mobile computing and commerce. Like the PCs of the early 1980s, mobile devices today have only limited integration with corporate IT infrastructures. Over time the pressure mounted to integrate PCs with mainframe applications and databases. The eventual result was a new IT architecture – today's client-server ERP systems. We may see a similar process with mobile computation. Pressures for integration may make existing integrated systems seem inadequate and inflexible – at the same time their failure to meet external business integration needs becomes more apparent. When companies decide to replace today's legacy systems, shared and collaboratively managed externally integrated systems may well seem to be the solution.

In short, today's painfully and expensively integrated internal systems may not satisfy tomorrow's needs for external business integration. Before companies overinvest in tight internal systems integration, it behooves IS researchers and educators to understand where business is heading.

M. Lynne MarkusCity University of Hong Kong, Hong Kong

References

Bashein, B.J. and Markus, M.L. (2000), Data Warehouses: More Than Just Mining, Financial Executives Research Foundation, Inc, Morristown, NJ.Bashein, B.J., Markus, M.L. and Finley, J.B. (1997), Safety Nets: Secrets of Effective Information Technology Controls, Financial Executives Research Foundation, Inc., Morristown, NJ.Larsen, M.A. and Myers, M.D. (1997), "BPR success or failure? A business process reengineering model in the financial services industry", Proceedings of International Conference on Information Systems, Atlanta, GA, pp. 367-82.Markus, M.L. (2000), "Paradigm shifts – e-business and business/systems integration", Communications of the AIS, forthcoming.Markus, M.L. and Tanis, C. (2000), "The enterprise systems experience – from adoption to success", in Zmud, R.W. (Ed.), Framing the Domains of IT Research: Glimpsing the Future Through the Past, Pinnaflex Educational Resources, Inc., Cincinnati, OH, pp. 173-207, http://www.pinnaflex.com/framing/contents.htmMarkus, M.L., Petrie, D. and Axline, S. (2000b), "Bucking the trends: what the future may hold for ERP packages", Information Systems Frontiers, Vol. 2 No. 2, September, pp. 181-93.Markus, M.L., Tanis, C. and van Fenema, P.C. (2000c), "Multisite ERP implementations", Communications of the ACM, Vol. 43 No. 3, April, pp. 42-6.Markus, M.L., Axline, S., Petrie, D. and Tanis, C. (2000a), "Learning from adopters' experiences with ERP – successes and problems", Journal of Information Technology, Vol. 15, forthcoming.Plumtree Software, Inc. (2000), XML and Corporate Portals – Technical White Paper.Spender, L. (2000), "Enterprise application integration – damned if you do… , CIO Magazine, 15 September.Wood, T. and Caldas, M.P. (forthcoming), "Reductionism and complex thinking during ERP implementations", Business Process Management Journal.Wouters, M.J.F., Sharman, G.J. and Wortmann, H.C. (1999), "Reconstructing the sales and fulfillment cycle to create supply chain differentiation", International Journal of Logistics Management, Vol. 10 No. 2, pp. 83-98.