EDI(ElectronicDataInterchange),即电子数据交换,旨在实现两个企业之间业务系统数据的交换。
比如,一家公司可以通过电子数据交换平台,向另一家公司发送订单、查询库存、通知发货等信息。帮助企业整合供应链、降低库存、实现精益生产。
知行之桥是中国制造的拥有自主知识产权的中文版EDI系统,基于知行之桥EDI系统搭建的企业级EDI解决方案,遍布汽车、物流、电子、零售、快消品、能源化工、IT软件服务商等行业。
EDI的迅猛发展,其影响已波及全球,小至个体零售商,大至汽车主机厂、国际物流枢纽等,凡是需要传输数据,就可以用到EDI。
多数国内客户初次接触或是实施EDI,是为了响应国外交易伙伴要求。随着国内外贸易合作的深入以及大家对EDI技术的了解,已经逐渐由之前的被动实施变为主动推进,国内越来越多的企业主动搭建EDI系统,对接上下游交易伙伴,提升企业数据传输自动化水平,提高企业市场竞争力。
相比EDI,API已耳熟能详,国内不少企业已在供应链管理解决方案涉及了API。由于国内EDI发展势头愈发强劲,很多企业不得不停下API的脚步开始思考:相对于传统API的方式而言,EDI究竟有什么优势呢,能够在全球范围内有如此的推广成果呢?
搬个小板凳开始听课啦
API与EDI各有优势,API的使用范围更广,功能层面上也比EDI更强,可以实现更精细化的功能,但技术门槛高,需要专业看法人员才能实现,这在无形中也增加了成本。EDI为解决通用性的问题,可能损失了一些小细节,但因其标准化程度高,且技术门槛低,大大降低了开发及运维成本。
在某些特定情况下,比如企业间的数据交换,使用API技术,这时API就是EDI。EDI的全称是电子数据交换,它的出现就是为了实现企业间的数据交换。
在此应用场景下,既然API和EDI都是电子数据交换,那使用哪个技术,更容易且成熟度够高呢?
先从数据结构开始
使用API,API的设计者一般会根据企业自身的业务逻辑涉及数据结构,在涉及数据结构时,需要开发人员与业务充分深入的沟通,完全理解业务含义,甚至要考虑未来业务扩展等,预测未来可能出现的变动,基于此,再去设计API的数据解耦股,对于开发人员的要求太高了,若非对供应链业务有足够了解,很难一次到位,设计出完美的数据结构。
提及EDI,EDI拥有标准化的商业文档,最常见的有X12和EDIFACT等。X12是由美国国家标准委员会在年创立的认可标准委员会(ASC)X12制定的EDI报文标准,而EDIFACT则是联合国欧洲经济委员会(UN/ECE)为简化贸易程序促进国际贸易活动,公布的一套用于行政、商业和运输业的EDI国际标准。这些商业化标准,是国际组织结合各大型企业、各个行业产业的业务场景和逻辑,制定出的一套几乎能够覆盖所有常见的业务场景、满足绝大多数企业需求的商业规范文档。
EDI标准化商业文档拥有经典数据结构,兼容所有常见业务,能够解决行业内99%的问题,在全球范围内通用。并且支持业务扩展,在扩展时不会影响到之前已经实现的合作伙伴。
(那么问题来了?从0开始设计数据结构呢?还是使用全球经典、且通用的数据结构呢?)
说到这里,可能有人对API还有些疑问:“我对我们开发人员能力有着充分的信息,我们已在涉及数据结构时考虑的非常全面,尽可能把数据解耦股设计的足够完善”。
杠精附体
EDI数据结构是国际组织经过几十年的探索与实践,应用于数以亿计的企业用户的成功产出物,你确定企业要白白耗费人力,财力,物力再去做这些重复的工作?
API设计者自定义的数据结构,设计到极致,可能得到的就是类似EDI标准化的数据结构
某供应链专家,苹果的两大成功是产品和供应链,产品的成功是不可复制的,那就复制苹果的供应链,悄悄告诉你,苹果也在通过EDI贯穿着上下游所有企业
拥有超强IT实力的Amazon,同时支持API和EDI,但在年订单量超过某个数字,就必须使用EDI。
Tesla供应链,IT实力牛逼呀,但在订单量超过某数量的情况下,也必须使用EDI。
......
诸如此类的例子太多,就不一一列举并抬杠了。
继续开始讲传输方式的不同
使用API,会用到
转载请注明:http://www.0431gb208.com/sjszlff/7836.html