a day in the life of edi at - gsec gec hub of using edi by implementing edi as part of your business...
TRANSCRIPT
What is EDI?
Electronic Data Interchange (EDI) is direct
computer-to-computer (requiring NO manual
or human intervention) transfer of business
information.
It was created to be used as an expedient
method for communicating and processing
data electronically.
Benefits of using EDI
By implementing EDI as part of your
business strategy, your company will benefit
in the following ways:
• Facilitate ‘Just in Time’ processes
• Speeds communication and data exchange with
ALL tiers
• Increased revenue by expanding your
geographical market
• Preserve existing revenue by forming stronger
relationships with existing suppliers and
customers
Benefits of using EDI (cont.)
Reduces costs by reducing or eliminating
paper-based documents, storage costs, and
retrieval costs.
Reduces paper consumption
Eliminates data entry errors
Expedites transfer of business information
EDI Conventions
The two most commonly used formats to
transfer EDI documents today are:
• ANSI X12, which is used mainly in North
America
• UN/edifact, which is used worldwide
NOTE: There are older standards still in use
by other companies
EDI Conventions (cont.)
There is one emerging format to transfer EDI
documents:
• XML
NOTE:
• XML standards are plentiful
• Until one standard is accepted and adopted,
there will be many versions of XML to support
• Ford Motor Company has settled on OAG
(Open Applications Group)
• The auto industry as a whole has yet to agree
on one standard
EDI @ Ford
Ford utilizes EDI to transfer many
documents or messages to and from trading
partners in standard formats on a daily basis
These messages include, but not limited to:
• Planning Schedules (830/DELFOR)
• Shipping Schedules (862/DELJIT)
• Advance Ship Notices (856/DESADV)
• Purchase Orders (850/ORDERS)
• Functional Acknowledgements (997/CNTL)
EDI Systems
Data is
sent/received
By Ford
applications.
(CMMS,
CPARS,
MSIII,
eVEREST,
CMMSIII,
Health Care,
etc.)
Data is
received
by supplier.
Supplier then
Acknowledges
Receipt.
Data received
by the
GEC Hub
Data received
by SOLMIS
Data Warehouse
Ford Internal resources
Access data, metrics, etc.
Via website
External sites with
FSN id and password
Access data, metrics, etc.
Outbound Data Processing @ Ford
1. All Ford internal data is compiled in a Ford
proprietary format called CIF (Common
Internal Format)
2. All CIF from an application, outbound to a
trading partner (supplier, carrier, LLP,
customer, etc.) is translated to one of the
industry standard formats (X12 or
UN/edifact)
3. The trading partners system (ERP, etc.)
retrieves the data and then integrates it into
their system for processing
CMMS,
ACSG,
CPARS,
ETC.
GEC Hub
or
SOLMIS
Trading
Partner
Inbound Data Processing @ Ford
1. The trading partners system (ERP, etc.)
processes their response to our data, and
sends it to our EDI system in one of the
industry standard formats
2. All data from the trading partners is received
by the EDI system at FMC and translated
from the industry format into the Ford CIF
format
3. Data from the trading partner, now in CIF
format, is passed to the appropriate Ford
internal application in CIF format
CMMS,
ACSG,
CPARS,
ETC.
GEC Hub
or
SOLMIS
Trading
Partner
Complexities of EDI @ Ford
Specific to the CIF:
• All internal applications (CMMS, MSIII, ACSG,
etc.) use the same CIF format for a given
message (i.e. 830, 862, etc.)
• Any change to the CIF could impact the other
applications and their ability to send/receive the
CIF
• All changes to the CIF need to be
communicated and coordinated across the
enterprise of Ford Motor Company
Complexities of EDI @ Ford (cont.)
Specific to the translator:
• Any change to the CIF where the application is
expecting the trading partner to receive and
process new or additional data requires a
change to the translation code (which changes
the CIF to X12, or the X12 to CIF)
• Any change to the message where the
application and trading partner expect to share
the information requires a change to the
translation code
Complexities of EDI @ Ford (cont.)
Specific to the translator:
• Any change to the translation code requires
communication to ALL other application teams
• All other application teams must be allowed to
test in order to assure they are not adversely
impacted. (At least one other application in FMC
is using the same translation code)
• NOTE: The GSEC team has coordinated
translation and specification changes, along with
the communications regarding those changes to
the other applications via the EDI coordinators
meetings
Complexities of EDI @ Ford (cont.)
Specific to the trading partners:
• Changes to the formal “EDI Specification”
documents that Ford publishes for it’s trading
partners benefit are required with any change to
the translation code! (inbound to Ford or
outbound from Ford)
Complexities of EDI @ Ford (cont.)
Specific to the trading partners:
• These changes need to be communicated to all
trading partners:
• Trading partners need to be given time to react:
Making changes in their internal code
Contracting with their software vendor to make the
necessary changes
Contracting with an outside consultant to make the
necessary changes
• NOTE: The GSEC team coordinates
specification changes and communications
regarding those changes to the trading partners
Complexities of EDI @ Ford (cont.)
Specific to the trading partners:
• Trading partners and application teams need to
perform end-to-end testing
• Which involves:
Data validation must occur at both points of the
message flow (sender and receiver)
Assuring the recipient is able to process (i.e.
translate and integrate the new or additional data to
the ERP system)
Validating the sender is able to generate and
transmit the data correctly