Todd Herman Associates e-Update — July 2010

Avoiding MEGO

MEGO. You've experienced it — we all have. It sneaks up on you. You're talking with a technology-savvy colleague, who breaks into geek talk, and you think, "I am not understanding a word he says! Maybe I'll just fake it and nod knowingly." But you can't really fake it — your eyes betray you. That's a common reaction — My Eyes Glaze Over, or MEGO.

This month's e-update features a case study involving a lot of great technology! But I don't want MEGO to happen to you. So, I've tried to construct this case study to feature only enough "behind the scenes" technical stuff to help tell the story.

And the story is really about how our consultants jumped in the foxhole (see: In the Foxhole — THA e-update November 2009 ) with our client when no one else would. Not their system vendor, not their value added network provider, no one.

Once a project is completed and presented in a case study format, it all seems so tidy and simple — that's only because someone worked very hard to distill its essence. To really appreciate just how hard this project was, take a look at the lettered graphics. Imagine trying to write the rules and translations to create Item B, having only a few instances of Item A and Item C. Looking at all the bits and bytes is tedious. Developing the logic and program code to reliably and consistently generate them is even more so.

So when the case study says "The final specifications documents were iteratively developed by trial-and-error", understand that at least 5 iterations were required to develop each specifications document — and over 74 specifications documents were created during this project.

While our consultants are comfortable immersing themselves in a project's technical details, they never forget our purpose — to get business results by using technology and improving processes, as practiced for over 20 years. Our consultants work hard to avoid inflicting MEGO on client personnel, by minimizing geek speak and technical jargon.

Oh — the technology we developed to automatically receive, parse, translate, and interface inbound EDI transactions (and similarly handle the outbound transactions) is really cool, too. Explaining that would most definitely cause MEGO, so I'll spare you.

Sincerely,

Todd L. Herman

A Case Study:

Incorporating EDI Documents and Automated Processing into an ERP System

Situation...

This not-for-profit organization provides contract warehouse and distribution services for a large agency of the Federal government. While this organization was implementing a new ERP system, the agency informed our client it was changing its method of sending information electronically, from an outdated proprietary method to an XML-based EDI method.

Problem...

This change was a requirement for our client to keep this contract, and the deadline imposed was extremely short. Neither the ERP software vendor nor the Value Added Network (VAN) provider for the EDI service was willing or able to work with our client to develop the required software, interfaces, and EDI definition documents. Furthermore, the agency was responsible for developing its own EDI specifications, and these specifications were still in development at the deadline specified for our client.

Solution...

The biggest challenge to be overcome in meeting the agency's deadline were the constantly changing EDI specifications — and having up to 33 parties involved on behalf of the agency only compounded the challenge. Nonetheless, we worked with our client to:

• Obtain the best available specifications from the agency,
• Develop the XML-based specifications documents to support these,
• Repeatedly receive and process test EDI transaction, and
• Compare these results against source documents provided by the agency.

In short, the final specifications documents were iteratively developed by trial-and-error.

We also developed the software to automatically receive, parse, translate, and interface inbound EDI transactions into the main ERP system. This software also works in a similar manner to package outbound transactions from the ERP system into the agency's appropriate EDI document format.

 

 

Results & Benefits...

Beyond the most important benefit of meeting changed requirements for its largest customer, our client achieved many advantages from implementing EDI for this Federal agency, including:

• Automatic receipt and processing of inbound documents — This eliminates human errors and procrastination from the process.
• Immediate visibility of orders to process — Real-time knowledge of items to handle enables better scheduling and improves on-time shipment performance.
• Enhanced transparency and accountability — Information is now available to routinely evaluate performance against contract requirements and work to become "best in class" among peer vendors.

The organization's Executive Director noted this was a large and important project, and its benefits certainly justified the time and effort put into it.

Conclusion...

Our client achieved many benefits from implementing EDI with a Federal agency, and they are now planning to extend this to their commercial customers to gain the same efficiency and effectiveness from inbound and outbound EDI documents.

Take the Poll

What was the level of "geek speak" in this month's e-update? Too much — MEGO set in. Just right — thank you! Not enough — I want more! Current Results

For More Information...

To discuss how technology usage and business process improvements could be applied to the issues facing your business, call us at 336.297.4200 to schedule a no-obligation consultation, or click here to contact us online.