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 firstname.lastname@example.org. We’ll follow-up on your ideas in future posts.