B2B to Be

For my inaugural post on this blog, I want to revisit one of those “solved problems” that still dogs many of the companies we talk with, namely, how to handle B2B integration requirements that don’t involve standard EDI. Companies still find it difficult to cope with the full range of B2B connections and content types needed to integrate with large and small trading partners, including:

  • Standard EDI (and in some cases, EDI that does not fully conform to standards)
  • “Standard” XML, which ranges from well-developed, horizontal standards like RosettaNet to hundreds of loosely-defined vertical transaction sets
  • EDI-like flat file standards (most of these are older, vertically-focused cases)
  • EDI-based web forms
  • Proprietary, partner-defined flat files
  • Proprietary, partner-defined spreadsheets
  • Proprietary, partner-defined web portals
  • Proprietary, partner-defined documents sent by email or fax

Did I miss any? Probably. But the point is that standard EDI is just one of numerous conventions used for B2B integration.  Of course, standard X12 and EDIFACT EDI are still the mainstay of B2B integration. And there is little evidence to suggest that companies are ready to invest in replacing all of their EDI connections with something “better”.  In fact, EDI adoption is increasing.

But despite dramatic progress in lowering the cost and complexity of EDI integration, the great majority of companies around the world are not EDI-capable.  And that’s a problem, because globalization of value chains depends on efficient business-to-business integration. And standards play a major role in making B2B integration efficient.

It’s relatively easy for very large companies to establish their own “standards”, pressuring their trading partners to adopt B2B connection methods that suit their needs. Wal-Mart, for example, has influenced its large supplier community to adopt AS2, global data synchronization, and other B2B standards, to complement its use of X12 EDI. And where industry standards are absent or fall short of meeting business needs, Wal-Mart has established de facto standards, like its Retail Link portal, to fill the gaps.

That’s all well and good for the Wal-Marts of the world, but not so helpful for the remaining 99% of companies that exert little or no influence on their partners, and are forced to accommodate the demands and limitations of individual customers, suppliers, and business partners. And it’s not always large, dominant players like Wal-Mart who make their lives difficult. That offshore manufacturer who can supply just the part you’re looking for might be capable of little more than emailing spreadsheets, for example.

So are most of the world’s businesses destined to cope with a never-ending procession of one-off B2B integration requirements? Based on what we can see today, the answer is “yes”.  But there are ways that companies can mitigate the business and IT impact of new B2B demands, reduce implementation costs, shorten time to production, and lower ongoing lifecycle expenses. And the first step is to think strategically about B2B integration, looking for patterns and common requirements where leveraged actions can be taken.

B2B integration is layered and multi-faceted, and in future posts, we will examine key insights, strategies, and technologies for solving common B2B integration problems. But along the way, we also want to shed light on the most important aspects of the B2B integration problem.

So what do you think?  Do the biggest gains lie in improving standard EDI integration?  Or should businesses pay greater attention to taming the non-standard, one-off cases?  Are web services a part of the solution, or does the ad hoc nature of REST just exacerbate the problem?  And what about Software-as-a-Services (SaaS) and cloud computing?  Do they muddy the water, or are they useful prods in the right direction?  Or have we reached the point where the best strategy is to outsource the problem altogether, to a managed services provider?

Send us your thoughts, by posting a comment, or sending an email to blog@extol.com. We’ll follow-up on your ideas in future posts.

2 thoughts on “B2B to Be

  1. Eddy

    EDI is 2 things. Message content and message delivery.

    EVEY company has the ability to send and receive ad-hoc files, but for some reason EDI is more complicated. Why?.

    You listed 8 broad categories of message content standards including “Standard EDI … that does not fully conform to standards”. Multiple standards, none of which is dominant, is useless. For those partners not fully technologically up to speed, and EDI Standard encoded message/document is less usefull than “Proprietary, partner-defined documents sent by email or fax”, as you put it.

  2. joleary

    Eddy, thanks for your comment. I agree with your point that EDI is less useful to less technically sophisticated partners than proprietary docs, because spreadsheets and even some flat file and XML documents can be produced (and with more effort, consumed) without coding, and without a dedicated translator / integration broker. But a key goal in such cases should be to enable automated processing on the other end – faxes and free-form emails are poorly suited to that goal, but spreadsheets are rather well suited.

    One area I intend to explore in future posts is the first statement in your comment. Yes, EDI is message content and message delivery, but it is also business process, because there are stateful aspects to EDI (request / response message pairs, FA generation and reconciliation, general error handling) that are also important. If you broaden the definition of “EDI” to include EDI-like mechanisms like RosettaNet and even web services, the process element becomes more explicit.

    Again, I appreciate your note, and look forward to future exchanges.

Leave a Reply

Your email address will not be published. Required fields are marked *