Are Small Businesses Ready For EDI?

Clearly, some small businesses know a lot about EDI and see it as either an opportunity or a threat, while others are completely ignorant and don't know what to think. In general, small businesses have heard about EDI, they seem to have some perception of EDI. A major reason for their being aware of EDI comes from their relationship with their bigger customers-Fortune 1000 companies who have adopted EDI, who have recognized (or not recognized) the benefits, and are pushing EDI onto their smaller trading partners.

To answer the question `is small business ready for EDI?' depends on a number of factors, with probably one ranking at the top of the list: "What is in it for me?" Do I get a free lunch, do I buy into a "hype'? What are the benefits? Can I afford new software and equipment? When is the payback? Am I forced into EDI to maintain ongoing business relationships? Can I improve these relationships?

Because small businesses usually do not have the resources of their bigger counterparts, their decision to implement EDI or not is based on practical considerations.

Once they decide that there is something in it for them, they also realize there is no such thing as a free lunch. EDI involves investing in software, manpower, procedures and approaches. It also involves the intangible effects of change, such as: fear, education, job security, uncertainty, and training. EDI means re-engineering the way we do business. Technical people need to know more about the business processes, users need to become more informed about technology. Business in general has to be able to recognize the opportunities EDI offers and no longer focus on "the way it is done" but rather take a new look at business procedures, filing systems, approval mechanisms, communications, etc., within the company and outside. It takes re-thinking and creativity to come up with a better solution for the company. For example, Peat Marwick demonstrated this once using the analogy of an ice cube: melt and then re-freeze it in the form needed.

EDI Project. Two major ingredients go into the EDI project: 1) EDI Management Issues; 2) EDI Implementation Issues.

EDI Management Issues. Organizations resist change. Everyone knows it. Involvement of upper management usually applicable to big corporations, also applies to small businesses : ideally, it should start right at the top with the blessing of the president. Once obtained, EDI will be supported throughout the entire organization.

Project success depends on the relationship between decision-making and implementation skills. Good examples are the relationship between the technical department and the order processing department, or technical department and the financial department. Some people think in graphics, others in numbers. Keep this in mind when preparing presentations and proposals. There are people with good organizational and creative skills who adapt to these changes naturally - the catalysts of a company. There are others who have to be taught how to do it.

Involve the `catalysts' of the company to get the EDI project started. Their enthusiasm may positively effect the more conservative employees. A guest speaker once mentioned at an EDI Users group meeting: "...fold your arms as you usually do." And that was quite easy and felt comfortable. "Now, fold your arms the other way," he said. It wasn't so easy and it felt awkward to do, but it could be done. If you continue to fold your arms the new way, after a time it will feel right. It's like that with EDI and people and the relative changes associated with EDI. Whenever there is change, there are people afraid of new technology, not so much because of the change itself but rather because of fear of losing, and having to re-learn and rethink the new enviroment.

Be considerate of the employee's sense of value in the organization. How to overcome resistance? For EDI to be successfully implemented, people need to understand it, and feel comfortable with it in order to support it. If an order entry clerk is concerned about her job, she is not going to embrace the new technology, and her attitude may spill over to other employees of the company. To defuse this fear, talk honestly to the employees and let them know about the change that is about to happen. Tell them that it is not going to be easy and that it may be frustrating; tell them the reasons for undergoing the change and the long-term benefits to be gained such as high profitability for the company, which leads to personal benefits to the employees such as implementation or improvement of employee incentive plans for health, medicare, dental, life, vacation, etc.

Or let them know that the feared lay-off won't happen, they won't lose their jobs. In essence, management should relate to its employees how the company as well as its employees will benefit from the change to EDI.

A successful implementation plan has to include these issues and they have to be communicated effectively to the employees. In retrospect, small businesses can learn from the experience of big corporations to help people survive the transition stage (see Figure 1).

Figure 1: Tips for Successful EDI Management

	Explain possible problems and opportunities and acknowledge the difficulty in the change process
	Specify the changes - tell people what they are expected to do.
	Have strong sponsorship commitment - strong and visible sponsors who can pass on EDI knowledge like an EDI coordinator
	Provide some anchor people can grab onto - for example continue using some the the same reporting procedures during transision
	Offer job security - their jobs will be easier to maintain, they won't lose their job
	Offer incentive programs - pay raise for job well done, improve healthcare, bonuses, etc.
	Involve the experts of the company: peoplewho are familiar with their job and understand the business process, Especially for a small company it is critical to implement EDI with it's key people

Advantages small companies have over their bigger trading partners who implemented EDI at an earlier stage is that they can leverage off thier experiences (see Figure 2).

EDI Software. Software issues are a key element for a company's successful EDI implementation. There is plenty of EDI software available but it needs to be carefully analyzed and evaluated. It must be compatible with or integrated with the company's in-house accounting system, otherwise the company ends up with not only increased cost but also increased work load. While integrated software in general is still lacking today, there are there are three kinds of software that adress this need:

• Bridging Software
• EDI Management Software
• Translation Software

Bridging Software. Bridging software `bridges' X12 transaction sets from a translation software into the company's in-house accounting application. It is referred to as a `seamless' interface as it looks and feels like the company's application software. As a result, the learning curve for the employees is reduced dramatically. The employee feels comfortable in learning about EDI as he continues to work in a familiar enviroment.

This type of software is usually developed by third party developers or off-the-shelf software manufacturers.

Exhibit A illustrates the process of an incoming ANSI X12 850 purchase order document into the bridging software and from there into the application: Bridging software receives the purchase order document from a trading partner, either by a third-party network or as a direct link from their computer and converts it to the receiving company's order entry system of their accounting application, then generates reports and updates the order entry module. The advantage here is that the process between the sender of the 850 and the user's in-house acconting system is fully automated.

Steps involved in processing EDI documents are as follows: First establish an electronic communication link between your computer and your EDI mailbox. Your selected communication software is designed to establish the link. Next, log onto the EDI network, send required passwords, check your mailbox for incoming mail or EDI documents, transfer your mail or EDI documents, log out of the EDI network, and disconnect the link. That process should be set up to be completely automated.

After receiving an EDI document, such as a Purchase Order, the document is translated. The process is analogous to a paper purchase order described below:

This is what you would do in a manual process--receiving a paper purchase order:Someone looks at the order, identifies who sent the order, where the items are to be shipped, changes item numbers into your item numbers, and prepares the order for entry into your Order Entry system. If you only have a flat file translator, you must still handle these orders in the same manner, since all you receive from the translator is a paper purchase order.

Once the EDI document file has been downloaded to your computer, bridging software translates each field of incoming information and converts it to the specifications needed by the in-house application software with a resulting audit list and error report (if errors have occured during the translation process). The user can usually correct errors quickly by accessing that menu function and then reprinting the audit list. If no more errors are detected, the bridging software posts the purchase order to the order entry module of the company's in-house accounting application. At that point, the in-house application software takes over by updating the inventory systems. The order entry module is now ready to issue a customer invoice. The clerk--familiar with the process--continues as he normally would. When a customer invoice is issued and posted, the in-house application software updates accounts receivables, accounts payables, and the general ledger.

Up-to-date management reports are available for instant printing. Thus, bridging software had enabled the user to fully automate the process at a minimal amount of time. There was no rekeying required, error potential was eliminated, and technical issues were kept at a minimum. The learning curve for the user is substantially decreased, as bridging software looks and feels like the in-house accounting application.

Another example of bridging software relates to Financial EDI between a financial institution and a company's in-house accounting application. Bridging software for financial transactions is much the same as described in Exhibit B.

Bridging software communications with the bank, receives or sends an ACH or 820 transaction set, converts it and updates the company's in-house accounting application.

Some of the concerns expressed using bridging software for vendor payments relates to float issues: `I'm losing my float if I pay electronically,' is one denominator, and an important one as well. How to address that? Previously we said that `EDI requests re-engineering the business process.' To apply this here, for example, would be to renegotiate new terms with your vendors/ suppliers. Discount structures should be reviewed; payments due in 30 days may be renegotiated for payments due after 33 days depending on two factors:

• float through the postal service
• internal process time by the supplier

Both payee and payor should acknowledge benefits they both obtain: no more paperhandling, minimizing filing of documents, reduced data entry, actual cash position, planning tool, etc.

Good bridging software should do more than facilitate electronic payments. For example, it should also download a company's bank account activity, (821 Financial information reporting) facilitate wire transfers, stop payments, send E-mail for ordering check forms, deposit slips, etc. If data cannot be transmitted in the ASCI X12 format, other formats should be used such as ASCII, BAI, etc. to make information available. The primary objective of any software should focus on benefits to the business. It would be ideal to be able to use X12 transaction sets to transmit all those benefits.

EDI Management Software. Another way to integrate EDI into a company's application software is provided by EDI management software.

For example, a large manufacturer of luggage uses an EDI management software for integration into its own application, its choice of software paid for itself 100-fold, says their specialist and EDI coordinator.

While this process is not as seamless as the one inherent in bridging software, EDI management software does provide the tools for integration. Source code issues may have to be addressed too. Usually there is additional programming required to establish the link between it and the in-house accounting application. As long as these tools are part of the EDI management software, the user minimizes the risk in having to rekey an incoming/outgoing EDI document.

The best approach seems to be EDI integration through bridging software or EDI management software. The difference between them is that EDI bridging software is a seamless interface into the application vs. EDI management software which provides mapping of ASCI X12 transactions directly into a file used by the in-house application.

Companies who prefer bridging software do so for the following reasons:

• Incoming/outgoing EDI document is entered only once.
• Bridging software looks and feels like a company's in-house accounting application.
• Mapping is an integral part of the bridging software.
• Technical aspects are kept at a minimum and remain most often transparent to the user.
• Learning curve is strongly reduced.
• User confidence level is increased because of the familiar enviroment.
• Cost is competitive with translation software.
• Bridging software uses a generic approach to EDI across industries.

Companies that decide against bridging software do so for the following reasons.

• Lack of availability.
• Lack of other industry standards.
• Concern that translation software companies may not cooperate with bridging software.
• Concern the VAN's may not cooperate with bridging software developers.

Translation Software. What about translation software companies and their products? Translation software vendors are more responsive to company's in-house systems and have started addressing some of the biggest integration hurdles.

Says a small trading partner of a utility company: "Translation software without integration options to the in-house application is not addressing my needs. If EDI requires that I input the same information twice, I might as well return to a manual system."

Typically, translation software without integration capability into the in-house accounting application requires two steps to handle one transaction:

Step 1. Prepare the information according to trading partners' requirements and remit via fax, modem, or as a paper document.
Step 2. Prepare and then re-enter the same information into the company's in-house application software.

"In addition to increasing the work load," he continues, "there is a potential increase for errors in transmission as well."

When evaluating translation software, consider the following:

• Translation software should fully support all ANSI X12 standards, UCS, EDIFACT, and TDCC. They should be table-driven to allow for easy changes current with the ongoing standard development.
• Integrated communications features for all major network carriers, and the ability to automatically generate a communications link.
• Built-in hooks to import/export a file to and from any in-house accounting software.

Summary. No doubt, EDI is the tool of the future. Fortunately or unfortunately, the future is now. Small businesses are increasingly playing a major role in the widespread use of EDI. They are the ones who demand integrated EDI software for cost justification.

While EDI was developed as a standard approach to facilitate the paperless exchange of business transactions, in reality it is a customized process into a company's in-house application software or a commodity by itself. It is also a thriving business for programmers and consultants.

In order for EDI to be successful embraced by the majority of companies world wide, a generic solution has to be offered. As one EDI manager said: "Today, EDI is a special tool. I'm involved in an EDI project is like saying `I'm going to pick up the phone and talk to a person.' In a few years, you won't consider it a special tool, you will just do it." What will it take? Perhaps more bridging software for off-the-shelf accounting packages, perhaps more EDI management software, perhaps an easier programming approach - object oriented coding, or perhaps a computer chip.

[ Home | Products | Reviews | Published Articles ]
[ Contact | Location ]

©1996 Datatech EDI Systems.