Saas for EDI -- Is it Always the Less Expensive Solution???

The following was stated in a question about ranking EDI processing. The 1st option was stated in the following manner:

EDI SaaS Model Delivering 40-45% EDI Cost Reductions



I do NOT necessary recommend the utilization of SaaS (Note: that when most EDI marketers reference EDI SaaS (Software as a Solution, and they really mean Translation as a Solution (TaaS). They are not the same thing.). TaaS may not be as effective, controllable, and cost effective as it is often touted (and in comparison against what??). My recommendation of an architectural solution such as TaaS is determined AFTER an architectural evaluation. Taken into consider are:




• Current and future volumes
  
• Types and complexity of EDI/B2B transactions
  
• Types of communication protocols.
  
• Robustness 3rd Party Solutions
  
• Costs analysis and various types of models
  
• Reputation for service of 3rd Party TaaS vendors.
  
• Management capability of the client to oversee their 3rd party TaaS provider.

I have seen some companies outsource their EDI programs and later bring them back – Hewlett Packard, for example, here in Silicon Valley. This requires dismantling their processes from their 3rd party TaaS vendor, while reestablishing their in-house EDI team and processes -- a costly and disruptive effort at best. There are several large EDI/B2B providers of TaaS, with numerous boutique firms also in the fray. For several small transactions and volume, TaaS may be the way to go. This solution is not always the cheapest. If you go with the cheapest, the support suffers. However, if you hire one of the major providers, you are locked into them. If you are enhancing your processes over time, you will need to negotiate change requests & costs with your provider. All of this need to be considered when making this critical decision.


Another low-cost, but effective model I often suggest is: the installation of an in-house translation product such as Softshare’s Delta and ECS (disclaimer – I am a partner). A consultant can install the product and create the maps. Softshare and several other providers offer robust, fast, low-cost solutions that can be easily implemented. In Softshare’s case, they also have a reputation for excellent service, and have been in existence nearly 25 years with the same owners, and management team.


An internal resource can be trained on monitoring the daily activities and raising a flag if there are problems. They do not necessarily need to have the skills to resolve mapping issues.


This solution may be more controllable, and result in lower cost than paying a SaaS provider monthly processing fees. And the client has greater flexiblity and understanding of the process.

Minimize Disruption with Your EDI Partners

An analyst from an Italian bank posed a series of questions on initiating his EDI project. He made the initial mistake of believing that using the latest version of a standard is best. Following are my responses.

"I'm starting a project in order to create a mapping from EDIFACT to a
banking XML format.
I read of the different directories (version) of the EDIFACT
standard but what I can't find are the differences and compatibility
issues between the different directories."


ANSWER

You might be putting the cart before the horse.

My 1st step would be to contact some major trading partners to discuss
what version/structure of the targeted transaction they wish to use
& gather the guidelines. Other banks may be willing to share their
guidelines with you.


The standards are so wide, there can be major differences in usage by
trading partners even within the same version.
I would not pull the latest version and necessarily start from there,
but would create my baseline map and guidelines from the
version/structure most commonly used in the trading community-- unless there is a compelling reason to go to a later version. The goal is to limit the disruption to your trading community while meeting your business needs.

"If I create my 1st map using EDIFACT D08B
(the last version), will it be possible to map also previous EDIFACT
versions (ie, do the standards have backward compatibility)?

ANSWER

No you cannot assume that the standards are backward compatible.
Sometime they are, but sometime they are not.

"Which is the de facto standard version? I saw lot of material on the
D96A... Why?"


ANSWER

In the electronics and high tech industry, I most commonly see D97.A. The reason you see many guidelines at this release or around this release is that many of the
standards were mature (ie contained nearly everything a business would
need), and there was a big push in the 90's for EDI adoption. Most
businesses have no reason to spend the time and $$ to upgrade to the latest version
once they have a stable and reliable EDI /B2B system in place. In the
US, many companies use version 4010 because it was the 1st one to
address Y2K & there was a big push in the late 90's to migrate to this.

One exception is in the US, the HIPAA (health care) transactions have
been in development because of US law.

For more detailed article on implementing EDI/B2B, please read my article Seven Steps for Your Successful B2B Project.

Orlando Oracle Collaborate Updates

Today was the first day at IOUG (Independent Oracle User Group), OAUG (Oracle Applications Users Group), and Quest in Orlando Florida. For the EDI (really EBIZ) SIG, I had the opportunity to demo Softshare's Delta/ECS and e-SupplyLinks ComplyLink product. It seems that a number of audience members were using GXS managed services for their translation. A few had integrated into Oracle with XML Gateway, but most were using EC Gateway.

I later attended the Logistic's SIG with a presentation by Oracle's Director of Applications, Jennifer Sherman. Although B2B/EDI messaging was a minor part of her presentation, she later elaborated that Oracle was now recommending messaging integration using Application Integration Architecture (AIA), and suggested that I attend sessions. Very interesting, as this is the 1st that I've heard of this recommended processing from Oracle.

ROI for EDI in Health Care? Hmmm…

In Rick Dana Barlow’s article, ROI for full EDI? Hmmm… he makes a very tepid case at best for the adoption of EDI in the health care industry. All of us in the business of data integration understand that EDI isn’t for everyone, and doesn’t solve all problems. But, EDI adoption for Health Care: it's a natural, enthusiastic YES! Supply chain behemoths in the commercial world became aggressive adopters of EDI in the 1980’s and 1990’s-a few even before–resulting in reduced costs while increasing customer satisfaction. The ability of global industries to manage and gain visibility into their world-wide vendors is–in part—due to the adaption of EDI (including XML), and the associated automation of data into ERP systems. All this did not happen over-night, but was due to iterative processes. The health care industry needs to begin to emulate processes analogous to their commercial brethren to shrink bloated manual processing, and error correction costs.

You can read Mr. Barlow's full article below:
http://www.hpnonline.com/inside/2009-04/0904-fastforeward.html

Just last month, I spoke to a CIO and his team responsible for payments for health care services. They are currently processing manually over 1500 claims each day. No EDI. They use an optical scanner to “read” the claims, but still require clerks for corrections; resulting in high error rates as sometimes the optical or human readers find it difficult to read FAX’s. “l” could be a letter “L”, “I’ or the number one, etc. We all know the issues with optical scanners, manual data entry, inconsistent formats, and blurry faxes. As in any organization, fixing the errors can be costly. Worse-in his industry-if the payment is delayed too long, they must pay penalties.

That being said, hiring a knowledgeable consulting firm able to install a good EDI software solution or managed services; and, able to analyze and streamline business processes would result in a much more efficient-and cost effective-processing.

There is not a one solution fits all. I sell and implement both off-the-shelf B2B products, and also offer managed services. There is a place for both.

Stanford University’s Supply Chain Management Forum presented the paper in 2007, Driving Business Value Through B2B Outsourcing by Barchi Gillai et al. The authors analyzed survey’s of 25 companies, and concluded ROI’s of nearly 250% were achieved. Skeptics (I include myself in this category) doubt the conclusions of the paper that these impressive ROI’s were due solely to the adaption of an outsourced Translation as a Service (TaaS) model; and also are skeptical of the 250% ROI. However, we can conclude some form of B2B adoption with competent consulting support, and internal management support, creates a very impressive ROI. “Many”-to use the paper’s quantifier of the analyzed 25 survey respondents-had a combination of both outsourced and in-house B2B models.

According to Bill Roberts-an independent writer, the author-Dr. Barchi Gillai-met other skeptics of her conclusions when she presented her results to B2B executives at the computing and electronics’ industry forum (ComTIA/EIDX). In his article, he says:

“Gillai’s presentation prompted a spirited discussion among the EIDX members, including some whose companies had considered B2B outsourcing and decided against it, because they found it too costly compared to internal solutions.”

You can find his full article here:

download.microsoft.com/download/9/a/7/9a791c44-6ae6-4b84-9c05-96078fd9d008/SUMMIT/OutsourcedB2B%20Processes.pdf

The Stanford Global Supply Chain Forum might have also tainted the credibility of their analysis as the project was funded by GXS, a prominent provider of B2B outsourcing services. In stark contrast to their conclusions, the researchers had to look no further than their prominent next door neighbor-Hewlett Packard-to find an example of a firm that tossed out their B2B outsourcing vendor, and returned to managing EDI/B2B in-house.

Still, one cannot help to conclude that EDI adaption-–when implemented properly--most often creates a significant ROI–-maybe not 250%--but very good. There were many studies on this back in the early ’90, when it was “EDI or DIE.”

Here is a list of potential reasons to adopt EDI processing:

• Reduction of data entry time and effort
  
• Reduction of data entry errors and time required for resolution
  
• Drastic reduction of filing time and costs
  
• Reduced disputes and time spend resolving disputes
  
• Reduction or elimination of penalties.
  
• Drastic reduction of costs for paper storage vs. electronic storage
  
• Easier retrieval time
  
• Cycle time reduction
  
• Savings in paper, fax machines, and ink
  
• Reduction in energy
  
• It’s green. Says Thomas Friedman: “The New Red, White and Blue is Green”.
  
• Easier to audit
  
• Creates infrastructure for continued Business Process Improvement
  
• Processing errors can more readily be captured, quantified and fixed.
  
• Consistent processing
  
• Conforms to government regulations and recommendations
  

Naturally, these benefits need to be weighed against the costs of:

• Software licenses (or managed services fees)
  
• Yearly maintenance fees
  
• Initial implementation costs
  
• Servers
  
• Upgrades
  
• Training
  
• Documentation
  

I did feel the frustration in Mr. Barlow’s statement: “Trolling for software shouldn’t be a seduction of the innocent or the ill-informed or a clever exercise in sophistry.” In the EDI industry, we all know some firms with great marketing, but inferior, costly, and complicated products.

Yet, methodologies for the vendor and software selection processes do exist.

ASN (Advanced Shipment Notice)

The Advanced Shipment Notice.is a terrific transaction when implemented properly. It is a critical component of JIT (Just int Time) programs, and is indispensable to global supply chain controls and operations. The “Advanced” is typically a misnomer as the transaction normally occurs at the shipment moment. Therefore, the receiver of the transaction receives notice in “advance” that the shipment is coming.

The ASN transaction is transmitted to the customer (or their agent) and used to update the receiving center’s database. The serial number identifying the shipment is bar coded on the label, so the receiving dock worker only needs to “wand” the serial number with a bar code reader to identify the shipment in their ERP system and designate the contents as received. Depending on the certification of the vendor, the customer may accept the contents of the shipment as detailed in the ASN, or may perform an additional inspection to verify the count, contents and/or quality of parts in the shipment.

The logistics operations can also utilize the ASN item/quantity details for scheduling deliveries, assigning locations in the warehouse, staging the inventory on the assembly line, create alerts if the shipment/cartons are not on time, and researching lost transactions by the tracking numbers and carrier details.
This is a large amount of data if manually entered or managed on paper documents.
The ASN message can be constructed to contain carrier, tracking numbers, manifest numbers, packing lists, pallet, RFID (Radio Frequency ID number) and other details. The ANSI X12 856 contains a flexible hierarchy. This flexibility can also add complexity because company usage varies dramatically.
I was invited to participate on the CompTIA/EIDX subcommittee on the XREF project and specifically did analysis for the ASN. The goal of the committee was to create “metadata” or common business data and then map this information across various standards such as: ANSI X12, UN/CEFACT, RosettaNet, xCBL, OAGIS, and UDEF. I first analyzed nine ANSI X12 856 ASN transactions and noted that there a number of differences in hierarchical loops utilized (except for Shipment and Item), data content, and location of data in the document. The good news is the ASN 856 is very flexible. The bad news is that is hardly standardized in its usage. RosettaNet does not contain the hierarchical flexibility of the ANSI X12 document. But it is a massive document in comparison to its X12 counterpart.
I predict the usage of the ASN growing as the global supply chain increases, and the US and other countries prevail upon importers to control and report on the goods coming into their countries. In the March 23, 2005 email from the U.S. Customs and Border Protection Commissioner, Robert C. Bonner he discusses the C-TPAT and baseline security initiatives. Although the document does not address ASN and similar B2B messaging specifically, tightening controls by the incorporation of messages and status is implied. You can read the complete email at: http://www.cbp.gov/xp/cgov/import/commercial_enforcement/ctpat/security_criteria/criteria_importers/commi_importer_criteria.xml

“The Customs-Trade Partnership Against Terrorism (C-TPAT) is the largest and most successful government-private sector partnership to emerge from the ashes of 9/11. Launched in November 2001, with only seven major importers, today C-TPAT has grown to more than 8,800 enrolled companies, which include United States importers, customs brokers, terminal operators, carriers, and some foreign manufacturers—all major players in the global supply chain. “
“From the beginning, voluntary participation and jointly developed security criteria, best practices, and implementation procedures were the guiding principles for C-TPAT. As the program has grown, so has our need for more clearly-defined security criteria to establish the minimum, baseline security expectations for membership in this voluntary, incentives-based program.”

So, I predict five major factors for the increase usage of the ASN:

• Globalization of industry, suppliers and service providers
  
• Increased emphasis on automation of supply chain operations especially as global inventories, and in-transit times are key factors in inventory and transportation costs.
  
• Emphasis on controls as entry points into the country from foreign entities is a continued terrorist threat.
  
• Risk mitigation and quick implementation of alternative supply sources in the case the supplier cannot deliver as promised due to hurricanes, floods, fires, epidemics, earthquakes. or in the case of political, labor instability or transportation disruptions.
  
• Shift in the growth of industry and consumer demands in the BRIC economies.
  

In Ian Bremmer’s February 7, 2006 article for Fortune Magazine, “Taking a Brick out of BRIC”:

"Ever since a team of Goldman Sachs economists coined the term "BRIC" in 2003--for Brazil, Russia, India, and China--this group of emerging-market countries has assumed greater importance in the international investment community's imagination. The firm's economists argued that, given sound political decision-making and good luck, the BRIC economies together could become larger than those of the world's six most developed countries in less than 40 years. In other words, the research predicted nothing less than a profound shift in the global balance of power."

You can read his full article at: http://money.cnn.com/magazines/fortune/fortune_archive/2006/02/20/8369169/index.htm

Emphasize Business Knowledge in EDI/B2B Implementations

This was originally posted on a former blog
Friday, April 13, 2007


Recently, someone observed that recruiters frequently list in great detail a number of technical requirements about an EDI/B2B position -- but mention absolutely nothing about the business processes or vertical of the hiring business. The "soft" knowledge of business and people skills are totally overlooked.

Why often the emphasis is on the technical aspect is no mystery to me. One reason is in the early days of ebXML, RosettaNet, and other XML "standards" bodies, the early XML advocates made the case -- and some still do -- that their respective committees have brought together all the experts from hundreds of companies and the business issues have been resolved -- by committee. All you need to do is register your company at an internet registry, use their business models, & suppliers/customers can come to you & "plug & play" the B2B process. What many EDI/ebiz folks do not understand is that this message was -- and still is -- conveyed to senior management of a very large number of companies and by organizations/universities that should know better. A Silicon Valley rumor is that executives were advised they should fire their EDI folks as they were no longer needed, and think of the cost savings of getting rid of these "expensive resources." In fact, many EDI/B2B managers or analysts have a wealth of information on the business and technical requirements of their customers; and the internal workings of their ERP systems.

The high-tech management was especially susceptible because they wanted to believe an internet solution was cheaper and the business process issues just dissolve because of the use of the internet. They did not realize that EDI since the early 1990’s could also be transmitted over the internet. In addition, EDI syntax and content was also based upon a number of committee meetings. I remember participating on the early EIDX committees for Distributor specific ship & debit transactions and invoicing. They were shown "easy-to-read" XML comparisons to "hard-to-read" EDI, not understanding these were not "standards-based" XML examples.

Several years ago, a director of IT said to me. "Why do we have to meet (with our customer) and test these EDI transactions? Haven't these standards existed for years?" Many managers do not understand nor appreciate the level of sophistication required to implement complex processes across companies. In the early days of eBusiness, it was not uncommon for large companies to have one group piloting the "new" eBiz transactions based on web/XML, and another "old" legacy EDI group doing that were implementing and maintaining processes that management presumed would be "dead" in a year or two. Then some of the management begin to understand that the two groups were facing the identical business issues; XML did not prove to be faster, more accurate and less costly to implementation; AND EDI was not dead. There was no magical silver bullet out on the internet that solved their business issues or created standardized business processes.

Normally, I like to reference my sources, but the person who wrote this in 2002 is respected in the B2B industry; and (I hope) would now be embarrassed by his comments.

"The cost of installing a basic XML application can be as much as 50% less than an EDI link. Any browser that is capable of presenting the transmitted data is an adequate client, and the costs per transmitted message are significantly lower when compared to EDI. Additionally, with EDI, data must often be re-entered before it can be processed further with a company's other applications, such as its internal accounting software, or its merchandise information system. XML, on the other hand, enables data to be easily exchanged between different applications and then processed directly."

Misinformed (to me) as the above quote seems, it was the basis used by a Harvard B-school publication written by one of their professors to recommend XML standards. EDI was not considered to be a viable option. Quoting from a promotional piece from the VP of Sales of a very small company is not the usual rigorous Harvard B-school quantitative methodology one would expect. Stanford University gets in the act, too.

In their paper, "Measuring Benefits of RosettaNet Standards -- Final Report", in their ROI analysis they include instructions for their worksheet.

This worksheet includes the detailed calculations of the expected reduction to be realized in [...EDI-related...] manpower costs [...] -- due to the move to non-EDI type(s) of transactions}. In another part of the paper they say: "Lower costs and increased efficiency are expected even if previous processes were not manual, but were rather based on EDI transactions. In addition, the accuracy of the data is increased."

I say put the Business back into B2B. Understanding business processes is just as import as understanding the B2B syntax.

Susan http://www.linkedin.com/in/susanstecklair

Preparing for the Exit

Note: This article was first published on April 4th, 2007

This weekend, I read a very worthwhile article, Preparing for the Exit by Ranjay Gulati, Maxim Sytch and Parth Mchrota in the Wall Street Journal (March 3-4). As you know, I am a proponent of negotiating an exit plan during the initial discussions with your targeted outsourcing partner. The article points out:

”There is no doubt this can be challenging. Like a prenuptial agreement, in which the couple discusses divorce options on their way to the alter, negotiating exit options while still at the formation stage of an alliance seems almost counter to human nature. For one thing, neither partner wants to admit that things could go awry. What’s more, there’s an eagerness to get the deal done – and a fear that raising the worst-case scenario will undermine the euphoria and trust that often accompany a new deal. “

“But partners ignore the issue at their own risk. Discussing the trigger points for exiting, as well as the disengagement process itself, while still in the negotiation stage is paramount to an effective partnership. In many cases, exit planning may actually enhance the alliance’s performance and longevity”.

When outsourcing your supplier chain EDI/B2Bprocesses, the contract and negotiations should address the formal process for communicating the end of the relationship, the ownership of the maps, trading partner setups, mapping instructions, etc. and the process to migrate these to another service provider or to bring these services in-house when the relationship ends.

April 4, 2007