信息化 频道

XML 面向 B2B 供应链的信息重组

    【IT168 信息化

    对于中国的传统制造型企业而言,B2B电子商务既是一次机遇,也是一次挑战,如何借这股东风,实现传统的主导经济在Internet时代的转变与提升,是我们这一代人无法逃避的课题。而作为一名开发人员,具体在实际的B2B项目实施中,我们最为关注的就是,如何选用先进的计算机技术,在合理实现系统功能的同时,还能保证系统运行的成本控制、鲁棒性、安全性、可扩展性、可维护性等非功能性需求。

    什么是B2B供应链的信息流

    作为下一代互联网信息交互的核心技术,我们在进行系统分析时,显然无法漠视XML的存在,尽管XML目前在中国的应用还是少之又少,然而在IBM、微软、SUN、Oracle等各大IT厂商的全力扶植下,随着支持XML的软件平台与日俱多,XML的推广与商业应用已是大势所趋,谁能及早将XML运用到其企业的网络系统中,无疑就意味着在企业的计算机应用及信息标准化中领先了一大步。然而在我们确定选择XML作为系统中信息传递的规范前,有必要先来明确一下什么是基于Internet的B2B供应链以及一个完整的制造型企业的B2B供应链中应该包含哪些信息流和管理模块。

    一个典型的制造型企业的B2B供应链系统如下图所示(图一):
 

    在一个B2B电子商务平台上,作为主体的制造型企业应该可以通过互联网实现以下基本功能:

    ·企业标书的发布与响应 
    ·物料采购订单的发布 
    ·客户产品订单的接收 
    ·销售商/供应商信息管理 

    通常企业可以将此门户搭建于某ASP服务提供商的互联网平台之上,如企业此前已拥有了独立的以主机托管方式存在的互联网主页,也可将B2B电子商务网站的内容加入到托管主机中,与企业原主页共享一个数据库。

如果把前台的B2B网站比作企业电子商务的窗口的话,那么后台的企业内部ERP系统无疑就是整个B2B项目的核心,与金融业、零售业、医疗业、交通运输业等行业领域相比,一个制造型企业的ERP系统包含了对物流、资金流、信息流的集成管理,尤其是以MRPⅡ为引导的物流管理,决定了整个系统的模块划分与重心。事实上,当我们为某个大中型传统制造企业度身定造B2B项目时,正是以企业的产品生产流程为主要参考的。下图是一个基本的制造型企业的一般生产流程(图二): 
 

    由上图可知,无论我们采用哪种算法实现企业的MRPⅡ模型及计算机流程分解,其基本的几个管理模块通常是确定的,即产品/物料仓库管理模块、销售/供应客户管理模块、销售订单管理模块、生产计划管理模块、物料需求计划管理模块、采购计划管理模块、采购订单跟踪管理模块、财务管理模块,而如何根据企业实际的生产周期、组装工序、运输途径、销售方式、采购方式等特征,采用合理的生产计划、物料需求计划、采购计划分解算法,以保证产品/物料的最小库存及JIT产品生产供给,正是MRPⅡ软件的精髓所在,而所谓的ERP,就是在MRPⅡ的基础上有机结合了客户资源管理、决策信息管理、市场预测管理、产品质量管理、人力资源管理、金融资源管理等子系统,为企业提供了更高层次的管理模式与管理工具。而各子系统及子系统管理模块之间的电子数据交互、企业的前台B2B网站与后台管理系统之间的电子数据交互、销售商/供应商客户与企业前台系统间的电子数据交互便构成了其B2B供应链系统完整的信息流。

    对于绝大多数中国传统的制造型企业而言,B2B供应链系统的应用,不仅是一场技术革命,更是一场管理革命,供应链系统并不是一套单纯的商业软件,它不仅贯穿于企业运作的流程中,也是企业和外部商业系统交流的重要通道,因此实施B2B的主要目的之一就是通过系统的运行让企业的信息管理及交互明确化、简单化、规范化,并保证今后在花费较少成本的情况下便可实现系统的开放性与向后兼容,由此实现传统企业在新经济网络发展的浪潮中能与国际工业标准无缝接轨。为了达到上述要求,在B2B项目实施的同时,我们有必要对企业进行信息重组,去除信息流转中不合理的部分,并选择一种合理的数据交换标准。这种数据交换标准不仅应符合计算机系统中各应用模块对信息处理的一般技术要求,还应具备及适应该企业所在商业领域的特征和发展。

    XML的诞生与流行

    XML的诞生源自W3C不满于HTML语言对信息内在含义表现的贫瘠与局限性,基本上HTML只是一套定义数据外部表现格式的标记集,尽管人可以通过上下文理解HTML文档的涵义,但计算机却无法自动通过HTML标记知道其数据所要表达的内容并加以处理。然而随着互联网的高速发展,有越来越多的应用需要计算机具备自动理解Web文档的功能,在这种情况下,一种新的互联网语言呼之欲出。最简单的,我们可以想到,既然HTML已有的标记都是用于表征数据的显示格式的,当然也可以制定各种扩展标记以体现数据的实际涵义及相互关系,不过如要将万事万物都用特定的标记加以区分并汇于同一套标记集中,显然是不太现实的,于是W3C想到一种更好的方法,制定一种可以无限生成新标记的元语言,有了这套元语言,就再也无需担心会有某种数据无法用已有的标记表征了。1996年,以Jon Bosak为首的XML工作组,明确界定了下一代Web语言的发展定向:

    ·XML应该可以直接用于因特网(Internet)。 
    ·XML应该支持大量不同的应用。 
    ·XML应该与SGML兼容。 
    ·处理XML文件的程序应该容易编写。 
    ·XML中的可选项应无条件地保持最少,理想状况下应该为0个。 
    ·XML文件应该是人可以直接阅读的,应该是条理清楚的。 
    ·XML的设计应快速完成。 
    ·XML的设计应该是形式化的,简洁的。 
    ·XML文件应易于创建。 
    ·XML标记的简洁性是最后考虑的目标。

    1998.2月XML小组发表XML 1.0规范,如上所述,新的XML其实是SGML(标准通用标记语言)的一个子集,SGML是一种早期的创建标记语言的语言,它可以定义标记的数据类型、相互关系、属性、元素结构、以及标记本身的格式——它是一种完全可装配的元语言。

    SGML提供了描述文档和创建新的一致性衡量准则所必要的公共框架,它集中于信息的结构并通过结构而不是表现形式来约束数据,SGML具有以下特性:

    ·不提倡一种特殊的文档结构; 
    ·不存在必须使用的有限标注集; 
    ·不限制创造新文档标准的潜力。 

    几乎所有对象信息都可以通过SGML为其所创建的标记集来精确表征,然而,即使为了表示简单的客观事物,也需要通过大段的SGML代码来定义,其中包含了对标记元素及对象结构的不同方面的约定与描述,尽管选项使语言更灵活,功能更强,但也非常复杂,由于SGML结构完整性的定义,这种描述几乎是无法简化的。显然,如果直接引用SGML来表示Web文档,不仅会使文档变得繁琐冗长,而且对Web页面制作人的专业水准也有着很高的要求,这显然会大大降低互联网的大众性与亲和力。新的XML规范不仅利用了SGML的创造性在Internet上方便地实现多元化数据的传播与交流。同时也保持WEB原有的广泛性、简易性。事实上,简化后的XML只使用标准的树型结构来表征对象信息,并将标记元素可任选的特征数目减少到了最少(通常为0)。当然,如果使用XML表征内部关系非常复杂的实体,便有可能损失对实体中某些特性及复合结构信息的充分描述,并带来结构上的不合理性,这种局限是XML规范本身所决定的。

   尽管互联网是XML最大的应用方向,然而XML并不仅仅只是HTML的下一个版本,XML在最大程度上继承了SGML的优点——即XML是完全面向数据的。XML纯用于规范化定义数据对象,一个定义完整正确的XML对象具有良好的内聚性,并完全独立于数据的外部表现形式,除非这种联系是定义者特意添加的(如将显示形式作为元素的一种属性)。因此除了互联网之外,也完全可以在其它应用环境中引入XML,而没有附加的制约。事实上,在XML产生以后,除了某些复杂度极高的特殊应用环境,XML显然是较SGML更有效率、更实用、易于流行的信息流标准。
 

    在B2B供应链中应用XML的利弊分析

    XML作为现代计算机发展的一种新兴技术,已经成为一种潮流和标准,尤其在商业领域,随着各种主流的编程语言及软件平台纷纷提供了对XML的支持,使得我们可以快速开发出基于XML的各类商业应用。具体在我们的B2B电子商务供应链系统开发中,如果使用XML来传递与处理信息流,可以为开发者与使用者带来如下好处:

    ·XML是经过检验的国际标准,使用XML可以放心使用与其相关的现成技术; 

    ·XML是面向数据与具体应用无关的,因此在一个应用模块中引用XML不会影响到其它应用; 

    ·数据的定义与实际应用相独立,有利于模块化开发和测试工作。 

    ·产品BOM表结构通常都是树状的,使用XML可以方便的建立、修改、维护、查询BOM树; 

    ·在供应链系统中存在大量的单据信息,同一份单据可能在多个应用模块间流转,使用XML可以简单的对单据进行校验、转化、显示及同步; 

    ·XML的编程接口是一套中性的API,常用的编程语言如JAVA、C++、VB等都可以对XML数据进行编辑,检索,如果用XML进行数据传递,各应用模块就可以采用不同的编程语言编写; 

    ·通过外部定义的不同规格的DTD或Schema,可以对同一套XML数据作出不同的与环境相适宜的解析; 

    ·本系统将来若要与外部另一使用不同DTD定义的应用平台进行数据交换,只要做一DTD<->DTD的映射即可(通过XSLT),XML数据至XML数据的转换较传统的结构化数据转换要便捷得多; 

    ·由于使用了XML,将来另一批开发人员要开发一个应用程序与我们的系统进行通讯就非常方便,只要参照我们制定的DTD/Schema就可以了; 

    ·目前所有的主流数据库管理系统都开始支持XML,比如在ORACLE 8i以上,DB2 7.0以上,SQL Server2000中,都直接支持XML文档到数据库的双向数据读写; 

    ·XML采用了典型的树型结构,因此对一个XML对象的操作如遍历、查询、删减、添加、重建等只要遵循经典的树操作便可; 

    ·系统内部使用格式规范,定义统一的数据集,无需中间件的翻译,从而简化了数据流程、节约了系统资源。 

    尽管XML具有如此多优点,不过毕竟还是一种正在发展中的新技术,目前在中国还缺少成功的商业案例,而从一个开发人员的角度而言,把一个项目确实的完成是最重要的,所以在项目的可行性研究阶段还是应充分考虑使用XML有可能遇到的困难:

    ·如使用DOM接口编程,需要在内存中还原整个XML对象树,而这对于一些大的XML文档而言不仅会占用许多系统资源,还会造成处理的延时; 

    ·XML及目前基于XML的网络协议本身并不提供安全保密设置,由于XML默认使用Unicode编码,而且具有面向数据的特性,因此很容易在传输过程中被人破译出其中的商业机密; 

    ·若客户原有部分计算机应用并不想丢弃,而我们的项目要共享原有的数据库系统,由于采用了XML,势必对原数据库系统进行改造;如果为了保证原系统的完整性,将我们的系统独立运行于一个新的平台,显然又会造成资源的浪费; 

    ·XML的使用是全程的,这意味着对几乎所有开发人员而言,都必须了解XML的相关知识和编程接口,从而有可能延长开发周期; 

    ·使用XML的重要目的是想为系统带来优良的可扩展性,及将来在不同系统、不同平台间转换数据时可简化流程。然而这种期望是有前提的,即我们设计的这套DTD/Schema本身是科学的、灵活的、标准的。基于中国的国情、企业的规模,行业的专门性,如何定制一套合理的商业XML规范非常关键也非常困难; 

    ·XML目前是V1.0,还很不完善,将来也必然会有所改动,而且XML发展太快,尤其在中国,其未来的方向不可预见,将来几年内在某些行业是否会有标准推出尚不可知,如何与将来接轨,对于开发人员而言实在难以把握; 

    ·如何建立XML规范,XML对象树的根节点定义在哪一级上,是制定一个基本的XML规范,以后再在此基础上做向上兼容的标记扩充;还是制定一套完整的用于作为行业标准的XML规范,后一种,不仅需要有熟悉企业及行业机制的人士参与制定,还应参照已有的相关的国际标准如BIZTALK、EDI等,才有可能使其与国际标准相接轨; 

    ·对于一般应用,是否需要调用外部定义的DTD/Schema,还是将XML规范隐含在应用程序内部,这样,尽管会减少程序设计的负责度,但同时也会丧失基于XML信息处理的可扩展性; 

    ·XML能够为系统运行减少中间环节、节省资源是显然的,然而作为一种新技术,在系统设计中需要开发人员掌握新的开发知识,因此要先强化技术人员的XML知识、选择合理的XML开发工具,这些工作的时间量在安排开发周期时都必须考虑到。
 

    建立XML规范的原则是够用即可还是要尽量完整?

    通常视主体企业的规模、行业的特殊性、项目的目标、开发的成本与周期以及项目背后的支持,我们可以决定在多大程度和哪个层次上完善将要制定的XML规范。显然,制定XML规范的下限是够用,只要设计的DTD/Schema规范集能保证项目中确定部分信息流的有效性即可,不过这仅是满足了系统基本的功能性要求,在此基础上我们还要求DTD/Schema规范集能具有简洁性、合理性、开放性、兼容性,尤其是最后一项,由于不太可能在项目运行前就制定出一个完美的DTD/Schema规范集,以及XML标记本身具有易于扩展的特点,因此,我们应该在设计之初便为系统将来运行中XML规范的升级留出足够空间。并且这种思路是全程的,比如说我们在设计订单信息流的处理时,就应考虑应用层的业务逻辑是否能具备相当的灵活性,当单据的条款数目发生改变时,进行业务处理的函数仍能正确实现其逻辑及结果,而这就要求处理函数在编程时应充分利用文档类型定义实现对XML实体的逻辑判断、校验、定位等。显然,文档类型定义的向后兼容性很大程度上决定了整个系统未来的可扩展性。

    当我们为某企业在定制XML规范时,其中不仅会包含商业系统中相通的各种对象,而且也一定会体现出其行业的特点,这二者的有机融合体现了XML规范的完整性。对于技术人员而言,较为困惑的问题就是,如何使XML规范更贴近企业的行业标准并符合其行业的发展方向。通常,在制定与行业相关的XML规范时程序应更为严谨,一般要有该行业领域的专家顾问、国标/企标专家顾问、工商管理专家顾问、国家相关管理部门、企业管理层、系统分析员等共同参与制定,显然当XML规范在更高层次上实现时,其制定的难度也会直线上升,对企业和开发商的实力都是一个挑战。不过对于一些大型的制造型企业,其产品的市场占有率在行业中领先,处于Vertical Market的上游,而且往往与政府的职权部门有着良好的合作关系,因此在制定XML规范时,就可以有更高更广泛的要求,比如说希望在一定的商业领域内通过XML规范实现基于Internet的标准化供销存模式,包括主体企业与客体企业双方的商业操作规则。由于此类企业在行业中的典范作用,因此一般所制定的规范在很大程度上自然具备了一定的标准性,而对于与它合作的那些下游企业,一般对此类规范只有接收,没有太多异议的余地。

    对于国内一般的大中型制造企业,如果决定要引入XML,通常较为合理的还是先建立一套轻量级的XML信息流规范,但整个系统应用环境应为其留有足够的扩展空间,这主要是目前国内还缺少制定广泛XML标准的成功案例,也缺少大型的B2B供应链应用管理经验。因此,避免在项目开发期交过多的学费,而选择先让B2B供应链系统运行磨合到一个比较稳定成熟的阶段,并对XML信息化规范的应用有了一定的经验体会,此时再对系统进行阶段性的升级,不失为一个较为保险的良策。
 

    使用一个DTD/Schema还是多个DTD/Schema?

    事实上,如果在整个B2B供应链系统中全程应用XML的话,只定义一个DTD/Schema几乎是不可能的,那样的一个DTD/Schema会非常“胖”,而且有许多XML信息流在不同应用环境下其定义与用途是不同的,比如一份招标书在客体企业而言就是投标书,当投标成功后就成为一份完整的项目合同;一份采购预通知在审核后就成为采购通知单,当供应商确认后就成为一份订单,而当物料生产完送到主体企业工厂仓库时就成为一份送货单,当物料验收入库后又可以成为一份帐单……因此,我们的下一个问题就是,要怎么对DTD/Schema进行归纳划分。

    由于XML文档总是面向实体的,因此我们可以理出在一个制造型企业中会有哪些基本的实体,如单据实体、金款实体、文档实体、物料实体、产品实体、公物实体、项目实体、消息实体、客户实体、人力实体等等,通过DTD/Schema我们可以确实地给出每个基本实体的定义。然后由顶至下,我们希望可以系统地得出实体的划分细化方式,通常有三种不同的基本原则:按职能划分、按流程划分、按资源划分。

    传统的商业管理系统中,通常是按职能建立对象模型的,比较典型的就是MIS系统。然而近年来,这种对象划分方法已经逐渐落伍,因为它基本上只是表面地重现企业的物理组成,无法体现企业在更高层次上的抽象,当然也无法为企业带来真正管理上的优化。按流程分的基本思路是以计算机算术模型的方式重现企业生产运作的流程,通过抽象与统计,找出企业运作中的瓶颈,然后以调整或重组的方式来优化流程,最终达到提高企业效率的功能,其典型的案例就是MRP。流程管理能较合理地利用计算机建立企业的高级抽象模型,为企业决策与管理提供参考信息,不过仍有其不足之处,现代大型企业的信息化管理不仅是要求高效率,快节奏,更强调各管理模块的无缝集成,信息的综合管理及交互,而流程管理往往局限于一定的生产模式,无法对复合型的管理环境提供很好的支持,于是就有了更高级的对象划分方法,即按资源划分。在这种对象模型中,将企业的有形资产(资金、货物、人员等)与企业的无形资产(如客户、信息、企业文化等)通通定义为企业资源进行统一的集成管理,以期实现对企业资源的最高利用,而基于此的商业管理系统就是通常所说的ERP系统。其基本的商业管理对象包括:订单、采购、库存、生产计划、质量管理、分销、服务与维护、财务、人力资源、项目、配方、投资、客户、市场与营销等等——这也是我们对XML实体对象系统细化的重要依据。

    通常对于B2B供应链的前台与后台系统,我们会使用两套独立的XML规范,尤其当前台B2B网站构建在某个ASP的平台上时,这种选择几乎是必然的。前/后子系统间XML信息流的交互需要通过XSLT词汇表的转化,为节约开发成本,两套XML规范在局部可以是相同的,但并不强调可参照性。由于前台系统直接与客体企业的系统握手,因此其XML规范的制定更强调国际性、流行性、广泛性、友好性、开放性,通常会以某个XML电子商务国标为蓝本,并作少量的改动。后台企业的ERP/MRPⅡ管理系统则是内部闭合的,因此其XML规范的制定更强调专业性、简明性、功能性,一致性,相对前台B2B网站,后台系统XML规范对通用性的要求却较为松散,也就是说可以使用“方言”。比如我们对后台系统的XML信息流可以采用中文的XML标记及GB2312编码,而且可以根据具体应用的需求定制标记,但对于一个专业的B2B网站,通常就必须采用英文标记及Unicode编码。与前台系统相比,后台系统中XML标记的属性、类型等约束更细更严格,因为标记的逻辑涵义与限定通常是与详细设计的流程相关的,如某企业其 规定其常规件的采购提前期最大为20天,定于每月初采购一次,而其最小采购量为100单位,则常规件的采购订单Schema可以声明如下: 
 

    如上所述,企业后台管理系统的XML标记定义是与系统流程密切相关的,因此很难跟随或照搬某个XML的行业标准,不过它仍然是我们制定规范时重要的参考依据。目前国内还缺少可供参考的XML行业标准,在实际设计规范时除了参考一些国外XML行业标准外,还可以参考国内外相关的EDI单证、行业标准和SGML的行业DTD,其中有更多关于商业规则的约定。另外,我国的传统制造业多为社会主义制度下的国有企业,因此企业的XML规范也必然会带有鲜明的中国特色,比如在部门实体中就可以包括工会和党/团支部等子元素。

    目前,国际上关于电子商务类较为成熟的XML标准有Ariba推出的cXML,CommerceNet的CBL等,在此之上还有更完整的XML电子商务架构方案如SUN、OASIS、UN/CEFACT力推的ebXML,CommerceNet的eCo,微软的Biztalk,而我国在这方面还是刚刚起步,目前以中科院电子商务研究中心为核心的已开始着手制定符合中国国情的XML标准,各大公司/企业也可将其制定的XML规范发布到此站点上,相信在不久的将来,我们就能看到由国人自行设计的XML B2B商业规范。 

    名词解释:

    XML:可扩展标识语言(The Extensible Markup Language)

    SGML:通用标识语言标准(Standard Generalised Markup Language)

    HTML:超文本标识语言(HyperText Markup Language)

    DTD:文件类型定义(Document Type Definition)

    EDI:电子数据交换(Electronic Data Interchange)

    XSLT:可扩展样式表转型语言(extensible stylesheet language transformations)

    JIT:及时供应制(Just In Time)

    BPR:业务流程重组(Business Process Reengineering)

    ERP:企业资源计划(Enterprise Resource Planning)

    MRP:物料需求计划(Materiel Requirements Planning)

    CRM:客户关系管理(Client Relation Management)

    PDM:产品数据管理(Products Data Management)

    BOM:物料清单(Bill of Material)

    SCM:供应链管理(Supply Chain Management)

    TQM:全面质量管理(Total Quality Management)

0
相关文章