追趕跑跳碰
EDI系统主要有3个功能，如下：
1，数据传输
数据传输即安全可控文件传输（MFT），也就是企业系统之间基于AS2、AS3、AS4、OFTP、FTP、SFTP等传输协议建立EDI连接。提供全功能的可控文件传输方案、可替换低效的、过时的或安全性较弱的文件传输方案。
RSSBus Connect EDI系统支持AS2, AS4, OFTP, SFTP, FTP等任一国际标准传输协议，不限制传输的数据格式，支持标准EDI报文, VDA, XML, CSV, PDF, Excel, JSON及TXT等。
目前，AS2在物流、零售等行业使用较为广泛。AS2只需要Internet就可以进行安全可靠地数据传输，并且通过数据加密和数字签名生成数据包，基于HTTP（或HTTPS）通过互联网或任何TCP/IP网络就可以进行安全可靠的数据交换，使得数据传输过程保密且不可抵赖。RSSBus Connect EDI系统的AS2 Port，实现了AS2协议所有功能并通过了Drummond官方认证。
另外还有OFTP（2.0）协议，该协议是由Odette OFTP2专家组提出，并且支持数据加密、认证和EERP等重要功能，目前在汽车行业应用较为广泛。RSSBus Connect EDI系统的OFTP Port，实现了OFTP2协议所有功能并通过了Odette官方认证。
2，报文转换
报文转换就是文件格式转换，也是通常行内说的Data Mapping，RSSBus Connect EDI系统无需定制开发，即可实现标准的EDI报文和XML格式之间的转换。当然，通过定制开发还可以转换为其他标准格式或是自定义格式。
对于多数业务系统较为成熟的企业，通常会选择集成业务系统实现数据自动化处理，这个后续再聊，另外还有部分企业尚无成熟完善的业务系统，那么可以选择Excel方案（将EDI标准报文转换为Excel格式）快速解决与交易伙伴实现数据传输问题，进行业务往来。
3，系统集成
系统集成功能实际是EDI系统功能的一个延伸，根据用户实际需求，深入分析用户企业IT及业务现状，定制属于你的系统集成方案，实现EDI与业务系统集成，自动处理数据，减少人工操作失误，提高数据流转效率，为企业用户供应链协同助力。
关于业务系统集成方案细节，这里涉及面儿比较多，简要列举一下几点：
旋转吧陀螺
对于做过 BI 开发的朋友，ETL 并不陌生，只要涉及到数据源的数据抽取、数据的计算和处理过程的开发，都是 ETL，ETL 就这三个阶段，Extraction 抽取，Transformation 转换，Loading 加载。从不同数据源抽取数据 EXTRACTION ，按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION，最后处理完成的输出到目标数据表中也有可能是文件等等，这个就是 LOADING。再通俗一点讲，ETL 的过程就跟大家日常做菜一样，需要到菜市场的各个摊位买好菜，把菜买回来要摘一下，洗一洗，切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源，做好的菜就是最终的输出结果，中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。在开发的时候，大部分时候会通过 ETL 工具去实现，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 SQL SERVER 里面的 SSIS 等等，在结合基本的 SQL 来实现整个 ETL 过程。
也有的是自己通过程序开发，然后控制一些数据处理脚本跑批，基本上就是程序加 SQL 实现。哪种方式更好，也是需要看使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的，碰到数据类项目会比较喜欢用程序控制跑批，这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发，当然也有一上来就写程序脚本的，这类 BI 开发人员的师傅基本上是程序人员转过来的。用程序的好处就是适配性强，可扩展性强，可以集成或拆解到到任何的程序处理过程中，有的时候使用程序开发效率更高。难就难在对维护人员有一定的技术要求，经验转移和可复制性不够。用 ETL 工具的好处，第一是整个 ETL 的开发过程可视化了，特别是在数据处理流程的分层设计中可以很清晰的管理。第二是链接到不同数据源的时候，各种数据源、数据库的链接协议已经内置了，直接配置就可以，不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用，起到简化的代替一部分 SQL 的开发，不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则，高度配置化，这个也不需要写代码实现。所以在大多数通用的项目中，在项目上使用 ETL 标准组件开发会比较多一些。ETL 从逻辑上一般可以分为两层，控制流和数据流，这也是很多 ETL 工具设计的理念，不同的 ETL 工具可能叫法不同。控制流就是控制每一个数据流与数据流处理的先后流程，一个控制流可以包含多个数据流。比如在数据仓库开发过程中，第一层的处理是ODS层或者Staging 层的开发，第二层是 DIMENSION维度层的开发，后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。数据流就是具体的从源数据到目标数据表的数据转换过程，所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节，目标数据表的链接，这两个直接通过 ETL 控件配置就可以了。中间转换的环节，这个时候就可能有很多的选择了，调 SQL 语句、存储过程，或者还是使用 ETL 控件来实现。有的项目上习惯使用 ETL 控件来实现数据流中的转换，也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。我们通常讲的BI数据架构师其实指的就是ETL的架构设计，这是整个BI项目中非常核心的一层技术实现，数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流，每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章，大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计，还有很深的ETL项目管理和规范性控制器思想，包括后期的运维，基于BI的BI分析，ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL，框架的顶层设计就很重要。
sw634365102
EDI是Electronic Data Interchange 的缩写,在大陆译为电子数据交换,有时也译为无纸贸易.香港译为电子资料联通.国际标准化组织将EDI定义为一种电子传输方法,用这种方法,首先将商业或行政事务处理中的报文数据按照一个公认的标准,形成结构化的事务处理的报文数据格式,进而将这些结构化的报文数据经由网络,从计算机传输到计算机.除了硬译的这个定义之外,我们应该正确地理解一下EDI的含义.从译名上可以看出有许多不同的理解,例如,不少文献将它译为无纸贸易,在贸易领域中来说,这一名称很形象地说明了它的状况及效果.然而,从基本意义来说,电子数据交换的意思并不限于贸易活动,例如医院中的信息交流,现在也已采用EDI的思想与方法,并已在国外一些地方实际使用.因此,严格地讲,无纸贸易是EDI在贸易领域中的实际应用,EDI的概念应当更广泛一些.当然,在现实的应用中,贸易领域的应用是发展最快,应用最多的方面,目前在这一方面的成果,标准,软件也是最多的.有的同志正确地指出：EDI的实质在于“数据不落地”,用技术语言来说,那就是信息存储及传递的介质从纸张转为电磁设备。
妖妖小雯雯
CMM通常定义5~6个成熟度级别。 P418
==【角色和职责。 工具。活动。标准，可预测性。自动化程度。数据流动。】== 见下图15-2
0 级:无能力 。无组织状态。为了定义才被设定的。 P418
1 级:初始/临时 。==有限工具集==进行通用的数据管理。很少或根本没有治理活动。数据处理==高度依赖于少数专家==，角色和责任在各部门中分开定义。管理数据的方案有限。==质量问题普遍存在==。 基础设施支持处于业务单位级别。 评估标准: 对任意一个流程进行控制，如记录数据质量问题。 P418
2 级:可重复 。有==一致的工具和角色定义==来支持流程执行。使用集中化的工具，有更多的监控手段。角色定义和流程==并不完全依赖特定专家== 。对质量问题有认识。开始认识到主数据和参考数据的概念。 评估标准: 组织中正式角色定义。 P418
3 级:已定义:新兴数据管理能力 。数据管理==流程制度化==。将数据管理视为组织促成因素。数据==复制受到控制==。总体数据质量提高。有协调一致的政策定义和管理。==流程少人工干预==，结果更可预测。 评估标准: 制定数据管理政策、可扩展过程的使用、数据模型和系统控制的一致性。 P419
4 级:已管理 。在 1-3 级经验能使组织在开展新项目任务时==可预测结果==。开始==管理风险==。有==绩效指标==。==工具标准化==。结构良好的集中规划和治理功能。 评估标准: 与项目成功的指标、系统的操作指标、数据质量指标。 P419
5 级:优化 。流程自动化和技术变更管理，==高度可预测==。==关注持续改进==。工具==支持跨流程==查看数据。防止不必要的复制。更易于理解的指标来管理和度量数据质量和过程。 评估标准: 变更管理组件、流程改进。 P419
每个能力级别都有与正在评估的流程有关的具体评估标准。 P419
在任何级别上,评估标准都将按照一个尺度进行评估,如1—未开始、2—正在进行、3—能使用、4—有效。 P419
当使用可映射到DAMA-DMBOK数据管理知识领域的模型进行评估时,可以根据语境关系图中的类别制定标准：活动、 工具、标准、人员和资源。 P419
许多供应商都开发了自己的模型,在选择供应商或开发自己的框架之前,组织应该先评估如下几个模型。 P420
能力成熟度评估(Capability Maturity Assessment,CMA)是一种基于能力成熟度模型(Capability Maturity Model,CMM)框架的能力提升方案,描述了数据管理能力初始状态发展到最优化的过程。 P415 CMA概念源于美国国防部为评估软件承包商而建立的标准。20世纪80年代中期,卡内基梅隆大学软件工程研究所发布了软件能力成熟度模型。 P415
成熟度模型通过描述各阶段能力特点来定义成熟度的级别。能力水平有既定顺序,不能跳过任何等级。 这些级别通常包括： P415 1)0级。无能力级。 2)1级。初始级或临时级:成功取决于个人的能力。 3)2级。可重复级:制定了最初级的流程规则。 4)3级。已定义级:已建立标准并使用。 5)4级。已管理级:能力可以被量化和控制。 6)5级。优化级:能力提升的目标是可量化的。
基于评估结果,组织可以制定路线图以 实现以下目标: P415 1)与过程、方法、资源和自动化相关的高价值改进机会。 2)符合业务战略的能力。 3)为定期基于模型评估组织能力开展治理项目。
数据管理成熟度评估(Data Management Maturity Assessment, DMMA)可用于全面评估数据管理,也可用于聚焦单个知识领域甚至单个过程。无论其焦点是什么,DMMA都可以帮助弥合业务部门和IT部门在数据管理实践的健康状况和有效性方面的观念冲突。DMMA提供了一种用于描述数据管理知识领域进展情况的通用语言,也提供了一种可以根据组织的战略优先事项进行调整的基于阶段的改进路径。 P416
数据管理能力评估的主要目标 是评估关键数据管理活动的当前状态,以便制订计划进行改进。评估通过分析具体的优势和弱点,将组织置于成熟度水平量尺上,从而帮助组织认知、确定优先次序和实施改进机会。 P416
业务驱动因素: P416
在实现其主要目标时,DMMA可以 对文化产生积极影响。它有助于: P417
评估的目的是揭露当前的优势和改进的机会,而不是解决问题。 P422 评估是通过向业务、数据管理和信息技术参与者征求意见来进行的,目的是在证据的支持下就当前的状态能力达成共识。 P422
评估本身包括收集和评估输入、沟通结果、建议和行动计划。 P422
路线图或参考计划应包括: P425
应定期进行重新评估,它们是循环往复持续改进的一部分: P426
在选择DMM框架时,应考虑以下标准: P426
DAMA-DMBOK可用于为DMMA准备工作或建立标准。 P427
这种快速的检查表方法可用于确定需要更深入分析、表示差距或指出修复热点的领域。 P427
DMBOK作为评估规划工具提供了额外的优势:有大量的专业知识人员使用DMBOK作为跨行业的指南,围绕DMBOK的使用创建了一个实践社区。 P427
就绪评估/风险评估。 见下图 15-4. P428
优质英语培训问答知识库
