The Trusted Guide to Marketing Thought Leadership

EIPP Adoption: Integration is Key


mThink Knowledge's picture

mThink Knowledge - Posted on 30 September 2002

Printer-friendly versionSend to friend
Authored by: 
Madhavi Mantha;
PDF File: 
BCE Emergis
Electronic invoice presentment and payment (EIPP) is inherently a community activity. In order to drive widespread adoption, solutions must do a better job of connecting trading partners, leveraging their existing systems, and either preserving or improving their existing workflow processes.

Executive Summary

It was nearly three years ago when the first Internet-based solutions for business-to-business electronic invoicing and payment (EIPP) were introduced. Using the ubiquitous World Wide Web to bring billers and payers together, these solutions have driven tremendous efficiencies in invoicing and payment.

First-generation EIPP solutions provide undisputed benefits. Easy to use and inexpensive to deploy, they automate the movement of documents between companies and in the process save about $7.25 per bill sent and paid, according to a recent Gartner study.1 But as with any first-generation solution, they have not gone far enough to drive adoption on a broad scale. This paper provides a perspective on EIPP adoption, focusing on the connection of trading partners and service providers as a necessary catalyst to widespread adoption. The available choices for deploying EIPP in a more integrative environment are also explored.

EIPP is Inherently a Community Activity

The table below summarizes the invoicing, payment, and settlement processes that sellers, buyers, and banks execute today. All of these organizational processes can be improved electronically, but for true efficiency most require collaboration beyond the boundaries of a single enterprise. The benefits of an electronic solution, and therefore the likely adoption, are greater if the improvements automate processes across companies – that is, if they bring trading partners and service providers together into a community that accommodates and leverages existing systems and processes.

The benefit of interconnecting is nothing new.

EDI solutions introduced as many as 40 years ago were built specifically to automate the exchange of documents between companies. But the costs and complexities associated with EDI-based business integration limited adoption to only the largest of trading partners. While Web-based EIPP does not face the same cost hurdles from a connectivity standpoint, it nonetheless limits adoption if it fails to offer the same level of data exchange EDI affords.

Because of its lower cost the Internet has raised the bar for connecting businesses. Whereas EDI has been limited to only large businesses with similar environments, such as ERP-driven operations, Web-based solutions target businesses of any size and sophistication level. Interconnecting these businesses requires a far broader understanding of, and support for, those myriad trading partner environments including the ones that benefit from EDI today.

Furthermore, as solutions target smaller trading partner organizations with lower strategic stakes in their relationships, adoption can be easily derailed by issues such as devoting IT resources to the implementation process and introducing new business processes unique to a specific partner. The value offered must be immediate and at a reasonable cost that allows for a quick return on the trading partner’s investment. The solution should minimize business process change by sidestepping user interaction and reducing it to an exception process. Ideally, the solution should also be shared among a broad base of current and potential trading partners so one connection investment reaches a wide audience of participants.

The Challenges to Community

Specifically, next-generation EIPP solutions should address the following B2B integration issues in addition to delivering invoicing and payment functionality:

  • Mitigate the need for point-to-point connections
  • Provide extensive communications and messaging capabilities
  • Enable management and self-administration of the community

Point-to-Point Communications

A significant challenge faced by organizations seeking to extend an EIPP application to trading partners is the need to build and manage individual, point-to-point connections with each partner. The initial building of each point-to-point connection is essentially a multistep project covering numerous activities including:

  • Gathering of trading partner information and requirements
  • Map development or other integration activities
  • Communications testing and certification
  • Message testing and certification
  • Confirmation of end-to-end traffic flow
  • Post-implementation support and maintenance

Managing these connections is an expensive undertaking requiring significant investment in both proprietary software as well as an extensive data communications infrastructure. Furthermore, this activity is handled by typically scarce IT resources who must implement and maintain connections – sometimes using outdated technologies and tools – that may necessitate frequent manual intervention to ensure proper message exchange with each trading partner.

Communications and Messaging

A communications and messaging infrastructure is a fundamental element of most integration solutions. It is also fraught with complexity as any solution truly facilitating widespread adoption must support numerous connectivity protocols and data formats to accommodate trading partners of various sizes and sophistication levels. The solution must be sufficiently broad

to address integration needs of various ERP or other legacy systems. Key characteristics that a comprehensive communications and messaging infrastructure support include:

  • Physical connections, transport protocols, communications models, and security – A comprehensive solution must address the connectivity and security requirements of each trading partner – ranging from leased lines to e-mail servers and from standard data encryption to complex certificate-based authentication.
  • Multiple message formats and standards – Given its relative ubiquity, a complete solution must support EDI standards. It must also support new message formats, such as XML, that are better suited for business process integration as well as ERP formats or adapters to facilitate back-end integration and financial formats to facilitate the settlement process via the organization’s bank.
  • Data transformation and routing – These functions are key to system-to-system integration (i.e., the “holy grail” that limits human intervention to exception processing). Data transformation provides the logic for converting business information from one trading partner’s format to another, such as the sorting, validation, and translation of messages to comply with a trading partner’s required information representation. Routing refers to the sending of messages to one or more destinations based on predefined rules.
  • Message delivery options – Sometimes referred to as “queuing functions,” message delivery options include guaranteed delivery, “once-only” delivery, delivery notification, the ability to schedule messages for later delivery, and the like. These capabilities are particularly key to applications, such as EIPP, where a payment process may be triggered upon delivery of a message.

Community Management

Often an underestimated task, the building and maintaining of dynamic trading partner relationships is a critical success factor for EIPP and other e-business initiatives. The right solution includes the methodology, technology, and expertise to drive the community’s adoption of the solution. This includes organization, user-level registration, and ongoing maintenance of those relationships. It also encompasses information, such as business and technical contact information, and more complex directory information, such as trading partner identification codes.

Despite the progress of new industry initiatives such as universal description, discovery, and integration (UDDI), there is still no standard way of identifying organizations globally. Some solutions rely on data universal numbering system (DUNS), while others rely on internal trading partner identification codes that are meaningless outside the organization. A community management capability must include a strategy for addressing directory information because most data transformation and routing activities rely upon this information for successful execution.

 

The Complexities of Community: A Partial List of Requirements

Physical connection options:

  • Internet
  • VAN/Interconnects
  • Frame Relay/ISDN
  • Leased Line
  • Dialup

Transport Protocols (IP- and non-IP based):

  • FTP
  • SMTP
  • HTTP/HTTPS
  •  SNA
  •  X.25
  •  Fax

Communications Models:

  •  Synchronous
  •  Asynchronous

Security Options:

  •  Virtual Private Network
  •  Digital Certificates
  •  Private Physical Connection
  •  Pretty Good Privacy

Messaging Formats:

  •  EDI standards including: ANSI X.12 and  EDIFACT
  •  XML standards including: RosettaNet, ebXML,  xCBL, cXML, OAG
  •  ERP or other proprietary flat-file formats  including:  SAP/R3 iDoc, PeopleSoft, Oracle  Applications, J.D. Edwards WorldSoftware, etc.
  •  Financial formats such as ACH, SWIFT, etc.

 

 

Getting to Community: The Benefits of a Service-Based Approach

It becomes clear from the discussion above that integration is not an easy task. However, for organizations to achieve the maximum return from EIPP implementation, they cannot afford to limit trading partner relationships to only those where integration is easy. This has been the shortcoming of first-generation solutions.

Integrative EIPP can be achieved through building internally, purchasing and installing separate integration software, or making use of integration capabilities as a service. Whether built or purchased, if an integrative solution is software-based it is acquired, installed behind a firewall, and operated internally. This is a reasonable approach for applications that don’t focus on broad-based trading partner connectivity. However, if the application supports even a fraction of the systems and formats used by trading partners, the software user must install (and often create), operate, and maintain the point-to-point connections, communications and messaging features, and community management functions. The cost and complexities involved force a limited focus on select groups of trading partners – ironically, the same quandary created by the introduction of EDI. This does not even factor in the benefits of connecting providers offering ancillary services to the trading activities, such as the financial institutions that settle the trades.

Third-party providers offering integration as a network-based service can remove the burden of providing and maintaining these logical connections. Much in the same way managed service providers offload operating and maintaining the application and hosting (or physically connecting) the users; a network-based integration service offloads the logical connections. As a result, loss of control – often cited as a disadvantage of networked solutions – is more than offset by the broader target community the solution now addresses.

A network-based integrator will address most, if not all, of the requirements listed in the sidebar and will support the latest emerging technologies. As with any hosted solution, users access and pay for only the required integration and security services, and only on a per-use basis. Therefore, network-based integration mitigates key financial, technology, and human capital risks associated with a software-based solution.

Finally, the ideal network-based integration service is one designed and built with specific processes in mind, rather than a generic service offering. This ensures priorities for integration are closely aligned with business processes, such as EIPP, that are the target of the integration. It also ensures that the application and integration infrastructure continue to evolve together to drive widespread adoption. 

Endnotes

1 A. Litan, “Biller Perspective: Reducing Interaction Costs With E-Billing,” Gartner, Inc. Research Note, 23 May 2002.

 

 

About the Author
Title: 
Sr. Director, Product Strategy & Marketing
BCE Emergis
Madhavi Mantha is senior director of product strategy for BCE Emergis. Ms. Mantha sets and implements product strategy for the company’s U.S. unit. Prior to joining the company, she held various positions of increasing responsibility in the tele- communications and e-commerce industries, specifically in the areas of information technology, product development, product management, and marketing. Ms. Mantha holds a bachelor of computer science degree from Concordia University as well as an MBA from McGill University in Montreal, Canada.

Sponsors