Utility Industry Group Implementation Guideline for Electronic Data Interchange
2 |
Business Issues |
|
2.1 |
Implementation Considerations |
|
When implementing EDI consider the following: 2.1.1 Obtaining Management Support to Create an EDI Internal Committee. The committee will establish liaison and gain support of the concept with all functional areas impacted. It is imperative that the EDI committee have well defined and understood missions statements for itself and the designated project teams. The Committee is the focal point and control element for direction and communication. Representation should include Information Systems, Materials Management, Purchasing, Sales, Financial, Legal, and Audit. The EDI committee will designate Project Teams to manage segments of the total project, for example, implementation, resource planning, technical requirements, etc. The EDI committee should also be responsible for establishing meeting dates, schedules, and project deadlines. The EDI Committee will determine internal costs inclusive of potential charges necessary to application systems and determine the departments responsible for funding the project. The committee will also identify potential trading partner implementation costs and determine how EDI costs are distributed between trading partners, for example, Value Added Network charges and software purchase/distribution costs. |
||
| 2.1.2 EDI Cost Justification Short and long term benefits need to be established. These benefits need to support the industry or corporate strategies. |
||
| 2.1.3 Strategy for Implementation Information needs to be collected in order to:
|
||
Based on information collected from business partners, develop an overall EDI plan. Conduct meetings/conferences with trading partners and Value Added Network (if used) to define EDI plans and dates. Consideration should be given to those trading partners capable of doing EDI and having the desire to participate. |
||
If a Value Added Network is being used, coordinate the completion of the service and license agreement and any other documents required to activate EDI. This step is particularly important when a Hub company has determined that a specific Value Added Network will be used with its trading partners. 2.1.4 Transaction Sets Determine the required transaction sets and the minimum transactions set data necessary to satisfy the application. Agree upon the acknowledgements that will be used. It must be determined whether all transmissions or only exceptions will be acknowledged. |
||
2.1.5 Pilot A pilot program is a method of initiating EDI, which provides the ability to test concepts and practices prior to establishing EDI policies. An implementation schedule should be initiated. Guidelines should be set to determine the next step after the pilot, for overall implementation. |
||
2.1.6 Test There are various types of tests you should consider:
Once these tests have been completed, you are ready for live processing to be run in parallel. Continue parallel processing until you and your trading partners are satisfied. 2.1.7 Education Education of internal and external personnel is vital to the success of EDI. Educate user personnel as to why the company is implementing the standards and what impact it may have on the current procedures. Trading partner education regarding your EDI transactions and future plans can be accomplished on an individual basis or through sponsoring trading partner conferences. |
||
2.2 |
Timing of Transactions |
|
| Determine when the business transaction is made available to the trading partner, i.e., release of remittance advice prior to funds settlement. Issues to be considered and resolved with your trading partners are: | ||
Mail Box rules for acceptance/rejection of offers/contracts such as:
|
||
Determine the method of handling Legal Holidays as well as deadlines for receipt of business/application acknowledgments. Determine when the business transaction will be made available to the trading partner. This involves decisions on warehousing, release, cancellations and returns, dependent on the type of business transaction. Example: Should a Payment Order/Remittance Advice be released to the payee prior to the initiation/settlement of the electronic funds transfer (or other payment method). Determine the ability of the existing computer systems to respond within some time definition (dependent on business application). System changes might be necessary to accommodate the identified business needs (processing times and windows). |
||
2.3 |
Modes of Operation |
|
Basically, most transmissions would be in a production mode. However, some provision must be made for a testing mode as new version/releases are implemented. Identify contingency plans for communicating between trading partners when either partner's application is down or not working properly. |
||
2.4 |
Security |
|
Security precautions taken by EDI applications within a company's computer center should be a least as good as those for the most secure existing application with which EDI is to be used. When the translation to EDI format takes place, every option may be added to completely secure contents of the message. The security functions may also be included as a part of the company's existing data transport services. |
||
2.5 |
Backup and Recovery Procedures |
|
Establish backup procedures to provide for retransmitting EDI messages such as:
For batch transactions, such as the Purchase Order and Invoice, a 1 to 2 week immediate access backup should be the minimum. |
||
The backup and recovery system must be thoroughly documented to allow anyone with the proper authority to access the system to retransmit data. The Functional Acknowledgement (997) transaction set can be used to provide a level of automation in the backup and recovery area. If the EDI system expects to receive a Functional Acknowledgment for every transaction it sends, the EDI message should be available for retransmissions until a Functional Acknowledgement corresponding to a specific EDI message is received. Once the Functional Acknowledgment is received, the original EDI message can be archived regardless of the normal archive timing. The system could be designed to provide a degree of flexibility. The use of Functional Acknowledgments could then vary based on business requirements. It may be appropriate to send/receive Functional Acknowledgments by trading partner, transaction, some combination of the two, or some other variable unique to your EDI requirements. If a Third Party Network is used, there will be additional costs to send/receive Functional Acknowledgments. Your level of risk must be known when considering whether the additional costs of including a flexible Functional Acknowledgment component in your EDI system and sending/receiving Functional Acknowledgements are justified. |
||
2.5.1- Recovery Procedure ConsiderationsEstablish recovery procedures to allow for controlled management of unusual telecommunications problems. Some potential problems that should be managed by the EDI system: A trading partner's computer that won't answer when your computer calls to pickup or deliver EDI messages A bad connection that causes continuous or an excessive number of retransmissions. Determining how the EDI system can notify someone when a predetermined threshold number of errors are encountered. |
||
2.5.2- Disaster Recovery ConsiderationsDisaster recovery becomes correspondingly critical to the amount of business that is conducted through the EDI channels. Consider the consequences to you and your trading partners if were you suddenly unable to telecommunicate for a week. It would be unwise to assume that you could fall back on a paper-based system. Your trading partners may not be able to quickly switch from EDI messages to mailing their business transactions to you. You may not have immediate access to the resources within your organization needed to process paper transactions when many departments all require the same resources and with the same urgency. Have a plan to deal with extreme problems, such as a total loss of a Data Center or computer system and a loss of a phone company switch station servicing your area. |
||
2.6 |
Audit Considerations |
|
One of the first questions raised when considering the use of EDI relates to its impact on controls. Without a signed document and a paper audit trail, how will one know when a transaction is valid and approved? EDI is not a ticking time bomb ready to explode out of control. The same elements of control will exist in EDI that exist with paper flow. In addition, people will be put in positions of reviewing and controlling their information rather than just processing it. New creative methods, such as personal retina or palm recognition, will be devised to improve controls in the EDI environment. These methods are now being developed commercially and will probably be used only in situations requiring a high degree of confidentiality. Most controls related to EDI fall into three categories: confidentiality, integrity, and authenticity.
Do only authorized persons have access to the transactions?
Have the data been validated?
Are these actual or real transactions that belong to you? |
||
Almost all problems that arise in assuring proper controls are followed may be identified in one of three categories.
When an unauthorized person merely has access to and can use the information they have no right to.
When an unauthorized person received information they have no right to and made changes to the data to their advantage before passing the information on for processing by the rightful owners.
Errors that occur throughout the cycle of any information flow when human intervention is required. |
||
Following are examples of controls for each of the three categories of control.
Encryption is a method of logically scrambling the EDI information with an encryption key and giving the key only to persons who have a right to that information. The key is an electronic code for this procedure. The browsing of files can be controlled by password protection. Passwords should be changed often for maximum effect. Some companies are using a stand-alone computer to interface with other companies rather than allow access to their main computer. The EDI information can then be uploaded to the main computer for use in applications. An interesting control when using an electronic purchasing system is to allow goods purchased by a location to be delivered only to that location. Integrity of the information is extremely important in EDI because the same data is used many times in the interchange process. EDI is at its best when data is validated at the front-end of the process so it is correct for the rest of the steps in the process. Senders of EDI data should satisfy themselves as well as the receivers that adequate controls exist within the sender's system to assure that data at the beginning of the process has a good chance of being correct. Value Added Networks (VANs) provide additional controls, such as checking for alpha characters in a numeric field and looking for the existence of critical data fields. ANSI X12 provides controls, such as the functional acknowledgment document and various record and segment counts. Conversion tables must be updated to assure adequate conversation to the user's codes. If one party in the interchange receives someone else's information in error, there will probably be a large number of mismatches on normally valid table look-ups. By creating mechanized trend or exception reports that compare current data with those of a past period, significant variances can be detected. How can the party to data interchange be certain that the transactions being received are the "real thing?" Controlled authorized trading partner codes. This process, as well as other areas of agreement, should be clearly spelled out in the signed trading partner agreement. Trading partner agreements are an important tool in the control and accountability of EDI. Once the user codes are agreed to, they should be mechanically compared to a list of valid codes before transactions are accepted. User codes could be password protected to have a double level of protection. Once data has been transmitted, the file that contained the data should be erased to prevent a retransmission of the same data. This does not mean all files related to the transmission should be erased. These files may be needed for backup if there is a need for a valid retransmission. Date conventions on processing data should be observed carefully to avoid duplicate transactions. |