0 前言
“已有的研究表明，不像人们想象的那样，复杂系统一定都要有很大的规模，都要由大量的元件组成......但是引起系统复杂行为的主要原因并不是元件的数量，而是元件之间的交互。”这句话同样适用企业信息系统，企业信息系统的复杂性是由于不同系统和模块之间的交互。降低系统复杂性将使得迭代优化非常方便，这将使得系统建设成功比例的提高，同时也将实现成本的降低。最终会实现让“使用、构建、测试的用户能够感到由衷的高兴”的美丽架构。
从上世纪90年代开始，企业架构的方法论开始在国际上逐渐得到接受和使用。目前来看，能够站在全局实施EA的企业非常的少。一些IT作为其核心竞争力的大公司开始有步骤地全面在展开，如一些世界500强的银行。而在中国国内，由于对于IT价值的认识还远远落后于发达国家。这也导致许多方法论的实施无法得到企业最高层的重视和理解。而企业架构是业务战略流程和IT架构的有机结合，是IT支撑企业实现灵活、快速、透明、智能的业务方法论。如果没有最高层的理解和支持，可能变成了画虎不成反类犬了。对于大而全的企业架构方法论，目前在中国的许多企业实施会面临着许多的挑战，有时这也会带来不必要的复杂性。
“根据我的经验，企业架构的成功一般都和复杂性相关。企业架构越复杂，它成功的可能性就越小。换句话说，你期望企业架构给你带来的越多，你成功的可能性就越小。” 因此对于许多企业而言，通过“解耦”实现分而治之，可能更加现实。由于解耦后问题变得简单，从而可以集中资源实现最大的效果。
企业架构的框架和方法论已经有了Zachman、TOGAF、FEA、GARTNER和企业总体架构。目前使用较为广泛的是TOGAF，它也定义了明确的开发方法，如图1所示。状态B包括业务建模、详细业务分析和技术需求文档。业务架构在企业架构中是基础，合理地进行业务架构的分层和分解可以有效地降低后面设计的复杂性。
图1 TOGAF架构开发方法（ADM）
根据TOGAF标准，状态E首先要“把重点放在短期的项目，以此来促进长期的项目”。“所以，我们应该竭力寻找那些投入少，产出多的项目。这样的项目大多出自组织的痛处，让企业确信采取企业架构策略的最初的地方。”（明确这里的论述来自哪里）但是同时可以发现，由于方法论中缺少对于复杂性的分析，很多时候，都陷入了琐碎的事物中忘记了方向。ADM作为方法论如果能够有效地结合降低复杂性的分析，将会得到可以迭代的少投入、快产出的项目。从而实现可不断进行迭代优化，这不但可以保障项目的成功，也符合当前市场竞争环境下的业务变化的需求。
贯穿本文的核心观点是通过迭代的方式降低企业架构实施的复杂性，从而有效降低风险，实现最大的收益。特别需要强调的是，本文不是完备的方法论，而是对于基本方法论缺少论述的复杂性的思考及解决方案。具体的EA方法论可以参考TOGAF或者企业总体架构，企业架构的构成请参考图2。
图2 企业架构的构成
本文的组织如下：
第1部分将提出根据企业战略，在最高层次对业务进行解耦，这里将借鉴企业精简架构的ABC（自治业务能力）的方法论。并且对于汽车行业以OTD为例进行说明。
第2部分将描述信息架构，根据业务架构来定义信息架构。这里将会涉及到业务分层以及主数据的分级管理问题的讨论。将以企业生产管理和生产管控系统为例进行说明。
第3部分将描述技术架构降低复杂性的方面。许多企业在IT技术方面已经投入了许多资金，IT技术架构也可以采用逐渐迭代的方法实现复杂性的降低。这里也将举一个小型机+开放平台的案例。
第4部分将综合进行分析，讨论如何通过迭代的方式让企业架构方法论离大家不再遥远，真正能够在给企业带来最大的价值。
1 业务架构
对于企业实施业务架构，如果开始时就进行全业务范围的分析，无疑是没有必要的。但是这里需要强调的是，需要在企业价值链层面进行第一层次的ABC划分。然后选择重点期待研究的业务，进行第二层的ABC划分。在第二层中也可以挑选重点领域进行深入的ABC划分。最终实现的目标是根据业务重点划分出具有较为自治的业务功能，各业务功能之间具有较低的耦合，也即相互之间的信息交换最小化。具体的划分方法论可以参考《企业精简架构》一书。
下面举一个例子来说明如何进行业务第一层的ABC划分。对于汽车主机厂而言，OTD是其核心价值链， OTD涉及到的业务包括销售线索管理、需求预测、订单管理、产品研发和制造管理、零件采购与入场物流、生产排产和执行、整车物流。OTD的各环节及相关业务见图3。
图3 汽车OTD流程
由于OTD的复杂性，因此对于该业务必须进行详细的分析才能够发现问题的复杂性。仅仅从图3来看，无法发现各业务深层的联系，因此我们需要对各业务进行进一步的分解。
图4 汽车OTD流程层次分解图
从以上的业务关系来看，可能重新将业务分组打包后，业务关系更加明确，见下图所示。
图5 重新分组后的关系图
从上图可以看出，重新分组后，每组间的关联性变小，而组内的业务关联性是较大的。下面将说明重新分组打包后的好处。
1 业务耦合降低，职责明确。如感知与预测由市场部负责，订单管理与执行由销售部负责，生产与采购部分由生管部负责。大部分业务属于部门内部，业务流程清晰明确。
2 由于每个包内耦合度较高，包间耦合度较低。因此整体的业务优化就变成了在满足外部较少约束前提下的独立优化。这将大大降低业务优化的复杂性。
3 系统规划时，可以将每个包做成一个系统或者模块，从而实现了系统之间的解耦。降低了系统之间信息交互的复杂性。
以上仅仅以OTD的业务流程为例进行了分析，并且分析的层次仅限于比较高的层级。如何进行业务ABC的分解，《企业精简架构》一书中有着较为严密的定义及方法论。这里需要特别强调的是，由于各种限制条件（如保护投资、距离限制）等，不见得能够完全实现ABC的分解。但是，这里再次强调，业务架构是未来系统建设的前提。如果业务架构不能够非常仔细地推敲，不能够把业务模块之间的信息流描绘清晰。未来的系统建设在这个阶段就已经埋下了隐患。举例来说，就如汽车各总成系统的关联都没有分析清晰，就期待能够做出质量和操控感都好的汽车一样。
2 信息系统架构
信息系统架构包括了对于应用架构和数据架构。这里不再介绍具体的方法论，而是考虑如何在设计信息系统架构时有效地避免复杂性。在应用系统层面将通过分层和配置的方式来简化应用系统，从而可以获得简单的架构。在数据架构层面将通过分层主数据的思想来考虑我们如何来管理主数据。
2.1 应用架构
来看一个业务应用场景。企业从生产/采购计划开始，到生产/采购管理，以及现场制造的执行。可以将应用系统划分为两种模式，如图6所示：
图6 生产/采购应用系统划分
左：同一个系统，不同的模块；右：根据层次，分为两个系统
乍一看，好像统一的应用系统比较理想。但需要站在业务的角度重新思考：
1）计划和管理的紧急度和执行不同。有些企业的计划是月度或者周间计划，有些是每日的计划。但是生产执行的系统其要求的程度是分钟级别。
2）计算模式不同。生产/采购计划含有大量的批处理，主要利用的是计算处理能力。而生产/物流的执行涉及到大量的信息采集和信号控制，因此需要快速的交互能力。
3）对于不同响应级别的系统，其系统需要的高可用和运维级别差异较大。如生产/物流执行系统需要实时热备，而计划和管理对于一般制造业而言，具备小时级别的恢复能力就可以了。
而这里没有把计划和管理分开基于两个模块的交互信息多，而且其响应级别差异不大，因此将其放在同一系统中。在汽车行业内，计划/管理一般作为MRP系统，而执行一般作为MES系统。
谈完了系统的分层问题，下面再谈谈关于实现和配置的复杂性问题。图7是一个具体的例子，其中类型是应用的类型，实现指具体的系统实现，配置是指对应用系统配置完成具体的业务功能。图中上半部分指对于生产线的信息采集和发送类型的应用，经过多年的发展，形成了一个非常复杂的系统群。这导致了架构复杂，数据重复，管理运维困难，升级困难等问题。
图7 信息采集应用系统
而经过分析，发现这些应用系统的基本功能有许多共同之处，发现系统的类型可以归结为信息收集和发送。通过设定不同设备接口的配置，可以实现配置实现对生产现场的信息采集以及控制。因此简化后的应用系统如图7中的下图所示。造成这种复杂性的原因是系统在建设时缺少统一的规划，尤其是缺少未来系统增多时的灵活扩展的考虑。最终造成了出现了大量的烟囱。
2.2 数据架构
在业务架构进行合理划分以及应用系统进行有效分层后，许多时候就将一些数据应该存在的范围定义下来了。但是企业内部存一些许多系统都会使用到的数据，这些数据称之为主数据。有的解决方案看起来很美，如下图：
图8 主数据的管理和使用
但是，对于许多企业而言，这种做法不见得是最有效的，有时可能就是一个灾难。而且由于涉及到数据的管理流程更多，主数据管理又需要独立的系统，因此有必要考虑一种简单的主数据管理方式。首先考虑HR系统，真的有必要把HR系统的主数据独立于HR的应用系统放在主数据系统中吗？同样对于生产的车型信息放在主数据中管理也带来了较大的复杂性。因为这些系统只提供数据，而且它们的变化速度很慢，外部的系统也不会修改他们的数据。他们只要定期将变化点发送到相关系统即可。因此借助ESB的概念，利用ESB来定期更新其他系统的数据即可，如图9所示。
图9 有效利用整合工具来管理主数据
此外的一种数据，比如对于银行或者汽车企业的顾客信息。由于其来源广，信息的真实性以及信息变化后的更新都有较高的要求，可以借鉴主数据管理的流程。但是需要说明的是，可以将同顾客信息紧密相连的应用进行改造，使得它们变成天然一体的应用系统。对于其他需要用到顾客信息的系统可以利用ESB获取顾客信息以及顾客信息的变化。
《理想的数据架构的研究和实现》给出的层次模型我比较认可，见图10。但对于主数据而言，其实现模型值得商榷。从业务架构、应用架构和数据架构综合考虑才能够确定是否需要集中的MDM。至少，对于许多已经具有许多系统的企业而言，根据业务和应用系统将主数据的管理分散在不同系统中是个明智的选择。当然也不能忘记，有些数据虽然不列为公司层次的主数据。但是它们在应用系统中仍然得到大量的使用，可以借鉴主数据的管理思路来有效地管理它们，实现在应用系统层面的集中管理。从而使得应用系统简单和高效。
图10 理想的数据架构
对于交易型系统而言，尽可能做到数据量最小化，这将使得交易系统的性能优良。此外，也使得运维便利。但是数据架构的这些内容最好最到对于用户透明，通过Portal可以让用户的体验就像在一个系统中一样。
3 技术架构
关于技术架构，站在现在的IT发展阶段来看。虚拟化和云应该是一个方向，基础平台的虚拟化，软件平台的统一化将极大地降低复杂性。但是，站在历史的角度来看，许多企业的软硬件平台繁多，软件版本不同。如何去做才能够即降低复杂性，又能够降低风险呢？在该部分主要探讨对于小型机应用和开放平台并存的企业，如何在保护已有投资的基础上降低复杂性。
随着虚拟化技术的逐渐成熟，许多企业将小型机的应用逐渐向虚拟化平台转换。而且应用平台也逐渐向开放平台转变，比如从RPG语言向Java的转变。以第2部分应用架构为例，由于历史原因，其生产和物流相关的系统多种多样，企业的生产/采购相关系统如图11所示。这样就造成了系统分散和接口复杂，维护困难。
图11 生产/采购相关系统（优化前）
结合第二部分的讨论，由于生产/采购计划和管理结合紧密而且计划层面有非常大量的批处理计算，因此可以分步实施降低复杂性，从而保证整合的成功。因此第一步可以考虑结合应用架构的讨论得到第一步。
图12 生产/采购相关系统（优化后）
更进一步，可以考虑将生产/物流管理剥离到开放平台，最后将生产/采购计划也可以迁移到开放平台。
4 迭代实现简单的架构
在《人月神话》一书中，作者给出了对于大型软件项目人员和时间关系图，如图13所示。从图中可以发现，如果任务能够有效分解，人员的投入可以有效降低交付时间。而对于无法进行有效分解导致关系错综复杂的任务，人员的投入可能会导致任务更加复杂，从而需要更多的时间去解决问题。
图13 大型软件项目人员和时间关系图
站在系统论的角度来看，系统的功能大于各元件（或者子系统）功能之和，这是系统的特点。那么对于企业IS而言，如何有效地减少子系统的复杂性而不影响总体系统的功能呢？或者换句话说，如何能够有效地分解系统，形成功能较为独立的子系统，而又能很好地实现系统的总体功能呢？结合系统论和IS系统的特点以及上文的一些讨论，作者给出了一些关于企业IS建设的建议：
一、子系统的分割：
1.1 快慢系统最好在软硬件上进行分割，通过有效地设计通讯接口服务实现数据的交换。比如单独的生产实时控制系统和其他业务系统的分割。
1.2 对于业务功能耦合度低的系统进行有效分割，尽最大可能解耦系统，分割成独立功能的子系统或者功能模块。实现单独业务系统对外的数据服务接口。
1.3 不同安全级别系统进行有效的分割，比如研发系统、生产系统和办公系统进行有效分割，其数据交换接口设计为具有安全检测功能的服务接口。
1.4 业务处理系统和业务分析系统的分割，确保业务处理系统尽可能轻量级。
以上分割的基本原则即考虑了系统的解耦，也考虑了较优的投资回报。
二、子系统的整合
2.1 构建统一用户安全管理平台，管理用户权限和系统使用安全。
2.2 构建星形的数据交互平台，而不要让各子系统直接通讯，形成太多不必要的耦合。
2.3 对于主数据管理，建立适当范围内的主数据。可以考虑分为公司级及应用系统级别（部门级）。
通过有效地分割和整合，可以实现不同子系统独立优化，随着技术的变更或者流程的变更而实现灵活的变更。
架构的规划大部分内容是否可以交给供应商呢？当然可以，不过不能够完全依靠供应商，即使是世界最知名的IT咨询供应商。IS部门必须培养出较为强大的系统架构能力。因为这是既想节省成本，又想提升IS价值必须培养的能力。(关于新型IS组织的必要能力请参考《新型CIO》领导)
最后我还想用汽车行业举一个例子：一辆汽车目前有上万个零部件，各个级别的供应商加起来可能有上千个。那么到了汽车制造厂的总装车间，会发现组装汽车好像很简单，利用经过简单培训的工人即可完成。但是，要看到背后大量智力的投入，那就是良好架构的设计。同样的，系统的架构设计同汽车设计人员的工作一样，把系统有效分解，最后实现通过简单的“拼装与组合”就可以实现有效支持业务的系统。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：实施精简的企业架构
本文网址：http://www.toberp.com/html/consultation/1082004684.html
相关文章
