Channel Insider content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Despite the amazing technical advances of recent years, and all the talk about agility and real-time information, the information systems that link customer to supplier remain woefully limited. A 2004 report from the National Institute of Standards and Technology estimated that each year, inadequate integration between supply-chain partners costs the automotive and electronics industries combined around $9 billion in lost income and business opportunities. What’s the problem? It’s partly the mind-boggling complexity of the technology. But according to M. Lynne Markus, a professor of information management at Bentley College in Waltham, Mass., the real reason is as old as EDI itself: the difficulty of getting partners to adopt these systems and use them well.

Markus, a researcher who has taught at City University of Hong Kong, Claremont Graduate University, the University of California at Los Angeles and the Massachusetts Institute of Technology, is equally at home with the human and the technical sides of information systems. She has written unusually readable and practical studies of ERP systems and open-source development. Recently, Markus, with Barbara Bashein, a San Diego-based consultant, completed a report on the challenges of developing a cost-effective electronic partner integration infrastructure for the Society for Information Management’s Advanced Practices Council. The report on “Interorganizational Technochange” is available at SIM’s website.

Successful partner integration largely depends on understanding both industry trends and your company’s business relationships. But as Markus recently told Executive Editor Allan Alter, “When we look at how we deploy information systems, we have to focus on change management. How do we change our ways of thinking about our relationships in order to use our new IT-enabled processes more effectively?” Success, she insists, requires a variant of the Golden Rule: “ ’My benefits depend on your benefits, so what can I do that will benefit you while benefiting me?’ I’m not talking here about altruism for its own sake,” she continues. “I’m talking about a very self-interested view: ‘How can I help you to help me?’”

An edited version of their conversation follows:

CIO Insight: What shape is electronic partner integration in today?

Markus:
When we talk about electronic partner integration, we’re talking about the ability to exchange information electronically, across organizational boundaries, ideally in real time, and without manual intervention. That is not the state of affairs today for most organizations. By and large, only the largest organizations have implemented EDI, and they only use EDI with a few of their partners for only a few of their transactions: purchase orders, sales notices and advanced shipment notices. There are many more transactions and types of collaboration that can occur, but usually don’t, such as collaboration around sales and order forecasting. It is still the case today that a very large number of small and medium-sized enterprises do not do business via EDI. Although increasing numbers of them are using Web interfaces, they are corresponding with their partners largely through fax and e-mail.

The Golden Rule of Partnering

Your message in the report for SIM’s Advanced Practices Council is very simple: Maximizing your benefits from EDI requires maximizing your partners’ benefits as well. What do you mean by that?

We need to think about benefits in systems-dynamics terms. Most organizations think about how they will exchange information with their partners from their own perspective. The notion is, “If I can improve matters for me, using some sort of EDI, it will be better for our partners as well.”

But what they often don’t see is how each organization makes choices individually may add up to something that is collectively less than optimal. If I am imposing my way of doing things on my partners, that’s going to be good for me, but it will not work for them, because they will not be using the same interfaces, transaction formats, data formats, etc., to communicate with all their partners. Because of this, electronic communication has not spread all the way through the network. We see pockets of electronic interactivity. And generally speaking, the organizations that tend to be left out the most are the small and medium-size enterprises, which we know account for a very significant part of economic activity.

Is the failure to maximize partner benefits why so many companies still haven’t achieved real-time collaboration with partners?

Yes. Companies are focusing on their individual benefits. And when they do that, they impose costs on their partners. Many companies are saying to their smaller partners, “Well, you don’t have to use EDI to communicate with us, but we do want you to communicate electronically. Therefore, you should use a Web interface.” But the Web interfaces are not integrated with the partner’s back-end systems, and as a result, the partners have to enter data twice. When they do that, they have additional costs, and they introduce the probability of errors. So the system-level costs go up, even though it appears that the costs are going down for the initiating organization.

What are the most important decisions that must be made when companies pursue their integration strategies?

The first thing is that you need to decide where you need partnerships, and where you can have more casual, short-term or arm’s-length relationships. Essentially, companies have to decide whether they can afford to have a very limited integration strategy, with either a few customers or partners, or whether they should automate the vast majority of their relationships. Basically, it depends on the business model. Some organizations have only a few major suppliers, but many customers. Others have many suppliers but very few customers. It’s particularly complicated where you’re trying to manage several tiers of the supply chain simultaneously.

To make such integration decisions, you need to understand developments within your industry. Some industries have made a much greater effort than others to build infrastructure for interorganizational collaboration. For example, the New England Healthcare EDI Network is a peer-to-peer platform for exchanging information on a many-to-many basis between healthcare providers and insurers. That kind of infrastructure, built upon HIPAA data standards, really supports using a shared solution.

When should companies focus on creating a private network, and when should they join a shared network with others?

The main driver for proprietary networks is the desire to gain competitive advantage. And I think that strategy works well for the very largest organizations and for the ones that are among the first in their industry to do it. Another factor favoring proprietary networks is the creation of dedicated sets of relationships. For example, if I have a supplier that supplies just me, and not other companies like me, then it makes no sense to have a shared infrastructure. It’s only when you have relatively dense networks of interactions across organizations that you start seeing the value of shared infrastructures. Another reason to consider shared infrastructures is the presence of many small players. Large companies may be extremely well-automated with their large partners, but many of their transactions with small players are handled through phone, fax, e-mail and so forth, and these transactions are very costly to automate.

Bringing Partners On Board

What do companies that succeed at partner integration do that unsuccessful companies don’t?

In the companies I’ve studied, the most successful ones either make up a large share of a small and medium-size company’s business, or they use a standardized approach that smaller companies can use with their other partners. Intel has implemented this sort of proprietary network and is trying to migrate all its partners to this way of doing business, and it is doing so quite successfully. Part of what they have done is to allow the smaller enterprises to connect via RosettaNet standards, which is a solution that the smaller enterprises can then leverage with other partners in the industry.

Now, there are other things companies like Intel have done. One is to give partners many different ways of interacting with them technologically, and not forcing them to integrate. Naturally, companies appreciate not being forced to do something. Intel has made that strategy work by outsourcing the maintenance of some of the different ways of connecting. By allowing people many different choices of ways to connect, and by not requiring them to invest heavily in IT or process changes, companies like Intel ultimately help draw their partners into the integration game.

Another thing is that large organizations are recognizing that they will benefit disproportionately from integration, so it makes sense for them to shoulder a larger share of the costs. They can subsidize the cost of the software needed for the connection, or they can negotiate an arrangement with a value-added service provider for a lower connection cost. In some cases, companies are providing direct technical support themselves, or engaging a third party to provide that support to their partners.

Are industry standards a strong incentive for getting your second- and third-tier suppliers on board?

They are, because they help convince companies that if they are going to integrate via standards, they will be able to leverage that investment in learning and technology with their other partners. The inability to use technology across multiple partners is really one of the major barriers to partner integration. Standards significantly reduce that barrier. It’s not a magic bullet, but it helps.

What other benefits can companies share with suppliers and customers to get them onboard?

When companies take their partners’ point of view, they often find they can offer considerable benefits that cost relatively little to provide. One of my favorite examples is Lawrence Livermore National Laboratories, which implemented an Internet-based purchasing system. They learned that what would be of great benefit to their suppliers was improved payment terms and much speedier payment. They successfully used that as an incentive to migrate people to their online purchasing system.

Another example is Enterprise Rent-A-Car, which was trying to partner more closely with its insurance company customers. One way they could provide benefit was by online sharing of information between automobile repair shops and the insurance companies. A lot of this information was passing back and forth by telephone, and this was interrupting the mechanics as they tried to work. The electronic network Enterprise put in place provided an opportunity for those repair shops to communicate once a day about the status of all the cars they were repairing, reducing interruptions.

How can companies make sure to offer their partners benefits that will actually make a difference?

You know, in the field of human/computer interactions, we often find that when we sit users down in front of the computer and watch what they’re doing, we can learn a great deal about what works with the interface, and what doesn’t work. Sometimes we only need to work with a handful of users before we start seeing the same thing over and over again. The analogy with electronic partner integration is a good one. If we can take time to visit some of our partners, understand the conditions under which they are working, and look at how working with us creates both benefits and problems for them, I think then we have much better intuition.

Overcoming Obstacles to Integration

What do you see as the major obstacles to integration?

One is lack of technical knowledge, and skills and resources of various kinds, in partner organizations—particularly with smaller partners. That’s a very significant barrier, and that’s where I think these collaborative, shared infrastructures are particularly useful. However, there are some very significant barriers on the other side, too. The reason that some organizations are offering, or imposing, proprietary solutions on their partners is that those organizations themselves do not have very integrated, Web-enabled infrastructures that would allow them to use a more open type of interface with the partners. Even when systems are relatively integrated, another problem can be organizational complexity. If your organization has many different units interacting with people on the partner’s side, chances are that it will be very difficult to integrate smoothly.

Some of the biggest problems, though, are mental. The belief is still fairly commonplace that we don’t really need to collaborate, or that the goal is to benefit at the expense of our partners. In many industries, there’s a very long history of adversarial relationships between companies and their partners, and these get translated into how they work together around IT.

There’s one more obstacle: Too often, in our own organizations, we do not take an integrated approach to the improvement efforts we make. Many companies are quite excellent in this regard, but the vast majority of approaches to integration or organizational improvement are balkanized. The organizational-development people on the one hand are proposing certain kinds of solutions, while IT people are doing their own thing. Meanwhile, the alliance professionals—the people whose job is to worry about strategic partnerships and how to manage them—are not working with the technology people either.

Are today’s technologies capable of enabling companies to -integrate the way they would like to integrate?

Oh, probably not. The problem is that you can’t buy it in a box. You can integrate. You can integrate internally and you can integrate externally. But generally speaking, these are very complex solutions that require many different technology components, and there’s a great deal of time, money, expertise and effort required to put all of those pieces together effectively. We have those capabilities, generally speaking, in large organizations. We don’t have them in smaller ones.

It’s hard enough to manage a conventional IT project well. How tough is it for two organizations with -different goals and interests to work together?

Collaboration of this sort is extremely challenging to do, and organizations have to work very, very hard at it if they’re going to succeed. Given that, you need to be clear that this is something you want to do.

It’s very important to think of these interorganizational collaborations facilitated by IT as cross-disciplinary change efforts. This is not just an IT project. This is not just an alliance situation. This is not just an organizational development or change-management issue. It’s all of those things at the same time. If I could give advice to organizations, I would suggest that they spend time thinking about how to take an integrated approach to their efforts to work with their partners.