Please do not make an application decision based solely on IT nerdy attributes. Focus on the business model first before evaluating commercial off the shelf software.
Elicit the Business Requirements
* What is the business driver? Are you moving from fully paper process to the first EDI implementation?
* Is this EDI solution Supply Chain (orders, ASN, invoice, et al) vs HIPPA Medical? If Medical then hire one of the expert companies in that niche who are represented on this listserv.
* In what countries will the business be done? US only vs global?
* What formats and protocols are required? X12 (retail vs grocery), EDIFACT, any flavors of XML?
* Is there a requirement for EDI outliers like FAX-to-EDI, EDI-by-Email?
* What is the future Support Model? Will business process performers (ex: customer service professionals, schedulers, etc) continue to support the DATA in EDI transactions? Will one or more EDI Specialists support only the IT part? Consider the staffing model carefully.
* Your company will save money if you design a systems that enables a new trading partner to be properly onboarded to EDI as quickly as possible.
* Is there a requirement for Records Management? How about PII? PCI DSS? Auditing? Segregation of Duties? IT Security? There are special requirements for EDI in the EU, and other places as laws mature.
* I favor a logical model that states the computers will handle all steady state transactions without human intervention at all, and that the most appropriate service provider will always receive a timely targeted and actionable alert on exceptions.
* Focus on cost/document, cost and time to onboard, regulatory compliance and records management, troubleshooting.
* Is there a business drive toward cloud? Does you company have a private cloud?
* Design and build highly reusable standardized ERP interfaces, so that a customer order by EDI or by call or by web form all use the same ERP interface.
* What is the error rate on inbound documents today? Ex: How frequently are current trading partners sending bad data?
* What is your company's sales channel strategy? Some VMI. some EDI, some web form, some other stuff?
* If you are willing, buy the latest Gartner Magic Quadrant report. Consider the findings.
* Carefully consider the trading partners. What is their technical capability? Is your company a supplier that is being forced to support EDI as a cost of doing business? Are your company's Sales Reps able to understand EDI well enough to influence the pre-contract negotiation to avoid EDI failure?
* Even if you buy COTS EDI software, you may be required to pay for one or more VANs as stipulated by the buyer.
* What is the scope and scale of the EDI requirement? How may documents per year? How many trading partners? How many interfaces, where 1 interface = 1 document type to/from 1 trading partner? How big is the data footprint in MB/year for the archive?
* If you go with COTS EDI software, then I recommend a license and training in one of the leading schema/MIG/testing tools like SpecBuilder or EDIsym or others. Consider schema definition files carefully.
* What is the service level of the EDI application? Is it 24x7x365 vs just regular business hours on one time zone? What spoken/written languages need to be supported?
* Is there an ERP change coming soon? If so consider changing EDI at the same time.
* If you host COTS EDI on-premises then you also need to design a secure transmission solution that is fully IT secure. I have had good success with Cleo VLTrader. Consider DRP and HA during the selection process.
* In Supply Chain business, I recommend a design and system that allows for fast/easy/cheap reuse (or sharing) of maps, AS2, and SFTP, and FTPS (SSL/TLS) if and only if the software allows me to enforce encryption level else don't offer it. For riskier transmission, consider a cost advantaged VAN only for transmission.
Just saying. This decision process is often led by an Enterprise Architect or experienced EDI consultant. The implementation project can be done in-house or outsourced.
Elicit the Business Requirements
* What is the business driver? Are you moving from fully paper process to the first EDI implementation?
* Is this EDI solution Supply Chain (orders, ASN, invoice, et al) vs HIPPA Medical? If Medical then hire one of the expert companies in that niche who are represented on this listserv.
* In what countries will the business be done? US only vs global?
* What formats and protocols are required? X12 (retail vs grocery), EDIFACT, any flavors of XML?
* Is there a requirement for EDI outliers like FAX-to-EDI, EDI-by-Email?
* What is the future Support Model? Will business process performers (ex: customer service professionals, schedulers, etc) continue to support the DATA in EDI transactions? Will one or more EDI Specialists support only the IT part? Consider the staffing model carefully.
* Your company will save money if you design a systems that enables a new trading partner to be properly onboarded to EDI as quickly as possible.
* Is there a requirement for Records Management? How about PII? PCI DSS? Auditing? Segregation of Duties? IT Security? There are special requirements for EDI in the EU, and other places as laws mature.
* I favor a logical model that states the computers will handle all steady state transactions without human intervention at all, and that the most appropriate service provider will always receive a timely targeted and actionable alert on exceptions.
* Focus on cost/document, cost and time to onboard, regulatory compliance and records management, troubleshooting.
* Is there a business drive toward cloud? Does you company have a private cloud?
* Design and build highly reusable standardized ERP interfaces, so that a customer order by EDI or by call or by web form all use the same ERP interface.
* What is the error rate on inbound documents today? Ex: How frequently are current trading partners sending bad data?
* What is your company's sales channel strategy? Some VMI. some EDI, some web form, some other stuff?
* If you are willing, buy the latest Gartner Magic Quadrant report. Consider the findings.
* Carefully consider the trading partners. What is their technical capability? Is your company a supplier that is being forced to support EDI as a cost of doing business? Are your company's Sales Reps able to understand EDI well enough to influence the pre-contract negotiation to avoid EDI failure?
* Even if you buy COTS EDI software, you may be required to pay for one or more VANs as stipulated by the buyer.
* What is the scope and scale of the EDI requirement? How may documents per year? How many trading partners? How many interfaces, where 1 interface = 1 document type to/from 1 trading partner? How big is the data footprint in MB/year for the archive?
* If you go with COTS EDI software, then I recommend a license and training in one of the leading schema/MIG/testing tools like SpecBuilder or EDIsym or others. Consider schema definition files carefully.
* What is the service level of the EDI application? Is it 24x7x365 vs just regular business hours on one time zone? What spoken/written languages need to be supported?
* Is there an ERP change coming soon? If so consider changing EDI at the same time.
* If you host COTS EDI on-premises then you also need to design a secure transmission solution that is fully IT secure. I have had good success with Cleo VLTrader. Consider DRP and HA during the selection process.
* In Supply Chain business, I recommend a design and system that allows for fast/easy/cheap reuse (or sharing) of maps, AS2, and SFTP, and FTPS (SSL/TLS) if and only if the software allows me to enforce encryption level else don't offer it. For riskier transmission, consider a cost advantaged VAN only for transmission.
Just saying. This decision process is often led by an Enterprise Architect or experienced EDI consultant. The implementation project can be done in-house or outsourced.
