您现在的位置:e-works > 百味书屋 > 书籍列表 > 2017(第二届)工业软件与制造业融合发展高峰论坛论文集 > 企业信息系统一体化架构探讨

第二章 软件定义企业新能力

第五节 企业信息系统一体化架构探讨

欧喜投资(中国)有限公司 姚凯


前言
        随着信息化的发展,越来越多的软件被引入企业。目前,企业大部分实施了ERP系统。随着业务形态的不同,有的企业实施了MES、WMS系统,有的实施了电商平台,随着云计算的兴起,被引入企业的SaaS软件也逐渐增多。如何管理日益复杂的IT环境和系统,保证数据的一致性和完整性,成为企业IT管理人员急需解决的问题。
1. 企业信息系统管理面临的挑战
        目前,企业所拥有的大大小小的系统越来越多。对于一些企业,几十个系统很正常,上百个系统也不稀奇。
        随着会计电算化的兴起,企业首先建立了自己的财务系统。但财务系统仅仅解决了资金流的电子化。但是对企业而言,物流和信息流仍然是手工处理,信息仍然是割裂的。因此MRPII及后续的ERP系统逐步得到推广。但是,ERP仅仅解决了一部分的企业管理问题,有其局限性。例如,ERP系统不能跟踪销售过程,仅仅记录了最后的销售订单;ERP不能管理研发设计的配方和图纸,仅仅记录了产品的BOM;ERP不能监控工单的执行过程,仅仅记录了最后的产出情况;ERP不能实现动态的分析查询,仅仅提供固定格式的报表。
        为了解决企业业务上这样那样的痛点,越来越多的系统被引入,包括WMS、MES、PLM、CRM、BI……林林总总,不一而足。近年来,随着云计算的兴起,针对企业的某一特定问题而提供的SaaS软件也如雨后春笋。
        随着企业应用系统的愈加繁杂,一些问题也日益突出。
        1.1应用系统
        对于企业应用系统而言,主要的问题是系统功能的重叠和功能要求的差异。
        1.1.1 系统功能的重叠
        不管企业实施的系统是标准的软件包还是灵活的SaaS,其功能之间不可避免地存在重叠。例如CRM是追踪企业的整个销售过程,包括对潜在供应商的销售推广经过,客户的联系人员及彼此之间的关系等等。它管理的是从发掘销售机会开始,把潜在的机会转化为具体的销售订单的过程。从整个CRM管理的流程角度而言,销售订单只是这个闭环的输出。
        同样,对于ERP系统来说,销售订单也是其销售模块的核心。正是因为有了销售订单,企业才可以安排生产,备货及发运,以及财务的开票收款,从而实现企业物料、资金流和信息流的流转。
        与此同时,对于WMS而言,货品的发运命令来自于确定的销售订单。没有销售订单,相关的拣货、发运也无法完成。
        从上面的例子可以看出,尽管不同系统满足的业务需求不尽相同,但或多或少都需要相同或相近的功能和信息来完成相关的后续操作,这就不可避免地带来系统功能上的重叠。
        1.1.2 功能要求的差异
        尽管不同系统存在部分相同的功能,但各个系统对于该功能的要求是不完全一样的,还是以上面的例子来分析:
        对于CRM系统,销售订单是整个销售过程的结果,因此,销售订单的输入是整个销售过程的结束。系统需要记录的是最后确认的物品和价格的明细及相关的交付条件。
        对于ERP系统,销售订单有着多重意义。首先它是一笔潜在的风险,因此需要确认客户的授信额度。额度不足的客户需要提供额外的保证。其次,它是一笔潜在的收入,因此需要提供发票等一系列服务。第三,它是整个供应链活动的起点,根据销售订单需要触发企业安排采购,生产和发运活动。
        对于WMS系统,销售订单是发货的指令。因此,需要根据销售订单的要求,安排仓库的转储调拨,拣货下架和物流配送。
        因此,同一个业务在不同的系统内,考虑的出发点是不一样的,对功能的要求也不尽相同。
        1.2 数据
        多系统并存的另一个突出的问题是数据问题,包括数据来源不一致,数据口径不一致和数据冗余。
        1.2.1数据来源不一致
        正如上面的分析,不同的系统存在相同或相似的功能,因此数据可以从任何一个系统获取,例如销售订单是销售活动的产出,因此可以从CRM取得。同样,从企业统一管理的角度,ERP也包括销售订单。此外,其他系统也可能包括销售订单,如仓库管理系统,客户服务系统,分销系统等等。
        1.2.2数据口径不一致
        尽管相同的数据可能存在于不同的系统中,但各个系统由于管理要求的不同,存在数据口径的问题。这包括数据的时间,单位和定义等几个方面。
        从数据的时间来说,不同系统录入的时间存在差异,因此会出现数据的区别。例如,销售拿到订单,第一时间录入CRM系统,而仓库有可能要等到发运前才获取销售订单。
        另一个问题是数据的计量单位。不同系统内数据的单位可能存在差异。销售可能是以箱或吨为单位,生产可能是以片,袋为单位,存在数据转换的问题。
        第三个问题是数据的定义。同样是对于销售的认定,销售人员倾向于用合同签订作为节点,财务人员可能希望以收款作为销售的结束,因此对于数据可能存在几个月的差异,而且这个差异会一直滚动,持续存在。
        1.2.3 数据冗余
        同样,因为数据存在于多个系统,各个系统维度和包含的信息不尽相同,从而不可避免地出现数据的冗余。
2. 企业信息系统一体化架构
        为了解决这些问题,我们需要对企业内的系统架构进行梳理。而在架构方面,一个可供借鉴的方法是TOGAF的核心架构开发方法。
        TOGAF把企业架构分为业务架构和IT架构两大部分。业务架构是把企业的战略转化为日常运作。业务战略决定了业务架构,它包括业务的运营模式、流程体系、组织结构、地域分布等内容。IT架构指导IT投资和设计IT框架,是建立企业信息系统的综合蓝图。
        IT架构包括数据架构、应用架构和技术架构三部分。TOGAF描述了如何定义业务架构,数据架构,应用架构,和技术架构的步骤和方法。数据架构和应用架构是在信息系统架构环节实现的。整个TOGAF的ADM(Architecture Development Method,架构开发方法)环节如下:

TOGAF ADM方法

图1 TOGAF ADM方法

        在本文中,我们借鉴TOGAF的方法,聚焦于实现企业信息系统架构的目标和一些基本原则。
        2.1 目标
        高效的企业架构需要解决企业IT架构的一体化和信息的无缝流转的问题。因此,整个IT架构体系需要实现兼容性,以及高效和容错的目标。
        2.1.1 兼容性
        对于企业而言,信息系统存在着多样性,在不同的发展阶段,企业的信息系统是不一样的。信息系统的使用存在着生命周期的问题,企业的软件系统需要升级或换新。同样,对于同一个业务功能,市场上可供选择的系统也是多种多样的。因此,企业在设计其一体化的信息架构时,需要充分考虑这种多样性,保证整体架构的兼容性,从而在系统变更时尽量减少重复投资甚至推倒重来的情况。
        2.1.2 高效
        系统架构必须保证具有较高的效率,从而保证用户体验,且不会因为其中部分软件的变更,导致用户体验的下降。因此在架构设计时,对于功能的布局,某一功能应该放在哪个平台,是外购还是自主开发,是使用系统内嵌功能还是调用第三方系统处理,都要以效率为重要的考量因素,统筹兼顾。同时,整体的IT系统架构设计应该保证终端用户的可用性和信息的透明。
        2.1.3 容错
        系统架构涉及多个软硬件平台,系统的bug、硬件的故障、网络的中断、人为的失误都是不可避免的。如何保证故障不会影响业务的正常运转,以及在故障恢复后,系统的数据没有任何缺失,都是系统架构设计时要考虑的问题。我们需要提供一个稳健的系统架构,保证系统可以持续运行,充分支持企业业务运行。
        2.2 原则
        正如TOGAF的ADM方法所描述的,企业的IT架构受制于企业的业务架构,同一类型的企业,其业务架构可能大相径庭,因此一个通用的企业信息系统架构是不现实的。这里我们主要探讨设计企业信息系统架构,特别是应用和数据架构时的一些基本原则。
        2.2.1确定应用系统的边界
        企业应用系统整体架构设计的一个挑战是对于重复的系统功能的处理。在这种情况下,企业需要根据业务的要求和企业的系统功能特性,进行通盘考虑,评估这些相同的功能,放在哪一个系统中其用户体验最佳,系统流转最为高效。一般来说,在进行设计时需要考虑各个系统的功能的内聚性、管理的颗粒度、功能的契合度、以及开发的复杂度。例如,MES系统和ERP系统都有生产功能模块,在ERP中,生产是整体ERP资金流和物流的一部分,主要关注的是物料的消耗及相关的成本,而在MES中,生产关注的是工单的执行是否是一个稳定可控的过程。对于二者而言,MES的生产信息更为详尽,颗粒度更细。同样还有CRM、ERP、WMS之间的关系。对于销售而言,CRM管理的是整个销售过程,但最后其输出的销售订单需要进行信用额度等的检查,而CRM对此没有要求,因此从功能来说在ERP管理销售订单会更合适,如果放在CRM中需要进行定制开发。如果需要对系统的功能进行定制开发,不建议通过修改系统的标准功能,尤其是核心功能的方式来实现需求,如果必要,应该尽可能采用接口的形式来实现。
        2.2.2确定数据流转的方向
        为解决系统数据的冗余和数据的一致性,一个基本并且核心的原则是数据的产生只能存在一个唯一的源头。在MES系统和ERP系统都有工单的功能,在ERP中,工单是整体MRP统筹的结果,而MES中工单是系统运行的指令。在这种情况下,可以考虑工单放在ERP系统中,而后下达到MES系统中。这是一个总体和局部的关系。同样,对于MES的生产结果,可以汇报到ERP,作为工单的报工数据。因此,在确定数据源时,需要关注:
        1)共用的基础数据需要统一管理,跨系统分享。例如物料数据是所有部门共用的,需要有一个统一管理和分发的平台。需要注意的是有的数据只在某一个系统中产生和消费,这种情况下就没有统一管理的必要。例如,对于试验产品,可能企业存在多个试验产品,但目前都没有正式生产,有的甚至只处于报价阶段。这种情况下,就没有必要把这些产品信息分发到所有相关系统中,只有该物料确定生产后,才需要分发到如MES、WMS等系统。在此之前,根据企业的具体情况,数据可能只需要保存在PLM系统中。
        2)需要管控/审批的数据,需贴近管控/审批端。例如采购订单需要审批、销售订单需要进行信用审查,这些数据应该贴近管控端,可放在ERP系统的采购销售模块,或在BPM系统中创建相应的申请并将批准后的结果导入ERP系统。
        3)交易数据贴近用户。交易数据指每天的操作,包括仓库出入库,车间的领料生产质检等等。这些都应该放在相应的交易系统,如WMS或MES。只有这样,对于终端用户来说,系统的操作响应才是最及时的。
        4)从细颗粒度向粗颗粒度汇总。数据的产生应该是越细越好。采集到明细的数据可以很容易汇总,但采集到粗放的数据却很难细化。例如,可以在WMS中管理到库位和批次,但在ERP中,如果只是为了成本归集,到仓库和物料就可以了。在这种情况下,WMS的颗粒度就比较细,是数据产生的源头。
        5)合理的数据同步时间和频次。一般而言,数据同步应该放在系统交易量较低,资源占用较少的时段,如凌晨,这样保证对用户操作的影响最低。同时,对于交易而言,有的数据如物料,可能一天同步一次就可以了。而有的数据,如生产数据,在必要时可以每一批次就同步一次,或者每一小时同步一次。具体的设置取决于系统对数据可视性的最大允许延迟时间,每次数据包的大小,以及管理的要求。
        2.2.3 松耦合的关联
        为保证系统的灵活性,系统间的关联关系建议采用松耦合的形式。在接口形式上,可以考虑接口表,数据总线等形式,明确双方系统的数据格式要求,并对数据交互情况通过日志等形式进行监控。这样,如果保持接口格式规范不变,在其中一部分系统更新时,对其他系统的影响可以降到最低,甚至可以不用更改。于此同时,通过这种方式,系统与系统之前的责权可以界定得比较清楚,通过分析接口数据,可以很容易地确定问题所在。同时,如果系统出现故障,只要接口表的数据仍然存在,可以在最短的时间恢复数据同步,保证信息的一致性。正因为如此,采用直接调用API进行实时操作的方式,除非对数据要求响应特别高的特定业务场景下,一般而言是不提倡的。
结论
        针对目前企业普遍存在的多系统并存和交互的情况,本文提出了几点原则,以满足高效,容错,富有弹性的企业信息架构的目标。通过探讨,希望可以帮助广大企业建立一体化的信息架构,满足复杂多变的业务场景,从而实现信息的完整性和一致性。