|Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search|
|Implementation Options | Technical Basics | Internet Commerce Model | Architecture ||
Factors to Consider when Choosing Implementation Options
|Discovery and Negotiation Decisions|
|Business Content Decisions|
|Information Exchange Timing Options|
|Business Integration Decisions|
|Messaging and Communications Decisions|
|Project Delay Factors|
|Back to Basics of eBusiness Implementations|
Discovery and Negotiation Model portion of ICM
Business Content Model portion of ICM
The business content model is used at design time to create the trading partner
agreement, to specify business processes and to specify business document or
data file contents, and maps for transforming data to/from a proprietary
format, or to/from another standards format.
At run time, the business process specification and maps created at design time are invoked. Data may be validated against a data dictionary to test for compliance to the standard.
Information Exchange Timing Options
|Business Integration Model portion of ICM|
|Messaging Portion of ICM|
In general, there is a relationship between the communications methods and the business content standards, messaging standard and/or business integration standards. The choice of exchange method may drive the decision to use a particular messaging and/or communication option. The choice of communications method may dictate or limit messaging options. Or, the data content standard chosen may dictate or limit messaging options. Changes in the various standards are overcoming some of these types of limitations. Additionally, just as VANs provided protocol translations for traditional EDI in the past, such services are now being provided for internet connections, so that partners can focus on business process and business content, and allow service providers to worry about the technical communications.
These are things to be taken into consideration when determining what the most cost-effective implementation option may be in a given environment.
Project Delay Factors
This is based on a Pareto analysis of several actual implementation projects. These are some things that have actually happened:
Key player (either trading partner) goes on vacation or on a business trip, or is out ill for extended period of time and has no backup for the project.
Key player (user expert, buyer, sales contact, IT contact, whatever) changed jobs and new player had to be brought up to speed (happens frequently).
Partner doesn't have resources available at the same time that you have resources available; by the time partner has resources freed up, your resources are tied up in another implementation or project.
Supplier or division has other priorities that impede getting to project tasks.
Supplier in the middle of installing new gateway and/or translator.
Supplier in the middle of installing new order management system.
Supplier in the middle of integrating systems.
Your own business group in the middle of migrating to next-generation systems like SAP, Oracle, Baan, etc.
The left hand doesn't talk to the right hand.
Supplier's gateway not correctly configured.
Partner doesn't have software correctly installed.
Partner doesn't have correct version of standard installed.
Partner doesn't have system configured to accept the transaction/message type from you.
Setup step left out (#1: forgetting to set the EDI/EC flag to 'Y' in the backend application).
Install step left out (like registering a file type for one of the hops in the internal network).
Partner needs to setup special sender/receiver IDs for new business process (different sender/receiver ID than currently used with already implemented business processes).
Partner splits into two companies.
Partner merges with another company.
Partner needs to modify current back-end application for the business process.
Partner needs to acquire or develop a new application for the business process.
Project is dependent on another group or party to complete part of the setup/configuration and have to wait on them. (e.g. waiting on ASP, ISP, VAN, exchange, or other 3rd party to do their setup).
Your internal business group changes their mind about setting up the partner you've been working on and wants to start on another partner.
Partner didn't map according to your specs and had to fix mapping.
Partner doesn't actually test map until they get first integration test file from you.
Supplier not familiar with the standards (previous implementations, if any, were with simple, transactions/messages).
Partner has to do re-coding/re-testing of application interface, from bug-fixes to major overhauls.
Change made incorrectly in back-end application that caused incorrect partner number to be used (and therefore incorrect Partnership ID in file which could not be matched to gateway's registry).
Gateway configuration typo.
Partner's eBusiness software cannot read the data; dependent on their third party software vendor to fix and send out new software.
Partner's third party software provider introduces new bugs when fixing supplier's software.
Partner has no way to configure gateway or back-end to receive two different document types that both use a single transaction/message standard, e.g. can't accept both a discrete purchase orders (850/ORDERS/3A4 etc.) and blanket orders (also 850/ORDERS/3A4 etc. but with different content and different mapping and business rules).
Partner changes partner identification number and/or name.
Partner gets eBusiness software from one provider, and network from the other provider, and neither knows how the other works and they give conflicting instructions to the partner.
Response document (use ASN as example) mismatching because partner's production ASNs aren't compatible with your requirements (can't always catch these in test).
Problems with customer's MRP run.
Power failure when MRP was running - yep, it happened ... and it wasn't in California ;-)
Last updated 02 March 2003