The Challenges of Modernizing B2B/EDI Landscapes

WRITTEN BY

When two businesses decide to exchange EDI documents, they must agree on the specific EDI standard and version. Businesses typically use an EDI translator; either as in-house software or via an EDI service provider – to translate the EDI format so the data can be used by their business applications and thus enabling the processing of transacting documents.

Many large enterprises have invested heavily into EDI solutions, typically in an internal EDI translation system or middleware. Most such enterprises today are looking at modernizing this landscape due to the typical IT needs around consolidation, licence expiry, end of support and reduction of TCO.

To embark on an EDI modernization journey – It is a path not easy to traverse. There are many challenges that customers must factor in as part of their migration planning. This article will look to discuss them, with possible solutions that can be embedded into the planning process.

Challenge 1 : Lack of legacy knowledge

Usually one of the most common and the crucial of all challenges is when there is little or no expertise around the legacy EDI estate. While the customer has an operations team (in most cases a very lean one keeping the lights on), over the course of time has lost most of the knowledge of the finer technical details. Lack of documentation or updated specifications (functional or technical) adds more fuel to the fire. This is typically a result of ‘stabilized’ environment over long period of operation. The challenge thus becomes that during the modernization exercise, the migration team will have little support in de-compiling mapping specifications which are the crux of any EDI migration exercise.

While some legacy platforms provide the configuration and mapping implementation as exportable files (csv mostly), there are aspects that has to be documented, for example the use of lookup tables or cross references, routing logic based on rules etc that will be at the risk of being missed.

Solution: Any EDI modernization program should factor in sufficient time in form of analysis. The legacy team should be deeply embedded into the program along with the migration team. This can not only help facilitate a meaningful analysis phase but also help identify technical challenges and other risks up ahead in the project life cycle.

This partnership between the legacy team and the migration team should continue through out the project. Where possible, the EDI migration team can also take forward the knowledge thru this engagement to help de-compile the legacy EDI solution. This is a possibility over the course of the project and helps accelerate the migration.

A pilot release/early release with a contained/minimal/low impact scope should be planned before the larger scope of the project is fully initiated. This will help the project team fine tune the approach and also for the wider stakeholders to appreciate the challenges of migration upfront.

And remember, document everything from day one!

Challenge 2 : Heavy Customization

This is typical of almost all legacy landscapes where over the years customized code has engulfed the EDI landscape. Custom maps, custom EDI types, flat structures and in-house developed structures would have been constantly creeping into the EDI estate. More the customization, more complex the migration.

Solution : The modernization project should be wary of this and not look at doing a one to one migration. Most times, simplification could be the answer to address such situations. As part of the analyse and design phases, the project should look for opportunities;

• To rationalize and consolidate
• Adopt Standard EDI messages
• Design with re-usability as the core principle

Challenge 3 : Poor Governance

Due to poor governance structures and processes, legacy landscapes are usually plagued with multiple versions of code, duplicated efforts, inefficient exception handling and longer RCA time.

Solution : Like any integration landscape, establishing a governance model is important. The modernization initiative should not only look at migrating off from the legacy platform to the latest technology platform but also put in place a process around governing the landscape as part of the ongoing operations. SOA principles around governance can be tweaked to help establish best practices in the modernized landscape.

Challenge 4 : Long cycle times around trading partner onboarding

A spillover of the challenges around points 2 & 3, on-boarding a trading partner is usually seen as a cumbersome activity. This is usually due to the multiple rounds of conversations to get to a mutual agreement around message exchanges, transfer protocols, transformation logic, and business rules.

Solution: Enforce standards as much as possible. While appreciating that there will be customization, it is important that where possible standard messages sets are leveraged. Where customizations are needed, extend the standard set rather than creating a completely new custom structure.

Trading partner management (TPM) functionalities as part of the EDI platforms are also highly recommend to be leveraged. TPM provides a flexible configuration driven framework to quickly provision an EDI flow for trading partners. TPM helps create a template-based implementation which is an important accelerator.

Once again, designing with re-usability and agility (standards adoption, re-usable libraries, configuration framework, BRMS etc) becomes the key mantra.

Challenge 5: Disruptive Migration

Most stakeholders are concerned about disruption to business during the cutover to the new EDI platform. This is a major challenge as some EDI platforms are responsible for almost 70-80% of the business transactions of an enterprise. Long cutover or prolonged downtime can prove fatal despite a strong business continuity plan. Post go-live, multiple defects or bugs can hamper the platform adoption and the confidence of IT/business.

Solution : During the planning of the project, there are multiple aspects that need to considered. Involvement of trading partners for UAT, a strong SIT/Quality testing prior to UAT using production files, setting a benchmark/matrices around testing, possible automation of test suites are the very basic to a successful migration.

Most project fail or the migration run into long timelines due to crunched testing or rather the poor quality of testing. Make the availability of production files/data for testing mandatory. The more the test data, better your chances of catching defects early on.

Also equally important is the execution of the cutover plan. Keeping all stakeholders like the legacy , infra, network/security teams along with the trading partners and the internal business contacts constantly informed is crucial. Do cutover plan walkthroughs and identify clear owners before the D-Day.

It is also recommended that deployments are done in a staggered manner. This helps manage risks and the post go live defects (if any) much efficiently.

We look forward to meeting you at the SAP Sapphire and ASUG Annual Conference 2018, 05-07 Jun, Orlando, FL. We are at Booth-1089C.
To make an appointment with us: Click here
To see Session Catalog: Click here