在咱们计算机界，实现架构倒是讲了不少，在大层面有企业应用架构模式，在方法上有面向对象面向服务，在描述手段上有UML，在微观上有设计模式。但说起切面领域，如ERP领域，应该也有架构方法和架构模型。我个人曾从事过医疗行业和汽车行业这两个领域的信息化工作，这两个行业在国外都是成熟严谨的行当，汽车制造代表现代工业，医疗代表生命。在医疗信息化行当有HL7标准，在汽车信息化行当有汽车信息总线CAN标准。我当年初见HL7，好么，针对每个角色每个流程每个实体都有详细的数据与接口的描述，这样的信息化是多么正宗正道、完备啊。如果各个行当都有信息化标准，那信息化就有据可循了。只有制定规则，才能革命与领导。
ERP软件是为企业管理而用的，所以它这个软件应该和企业有一定的映射性。
ERP软件有架构，那说明企业就一定有架构，否则双方如何映射。架构就是框架的意思，描述一个事物的概要线条，就如同素描前的勾勒。
所以论ERP架构，不得不谈到企业架构，而ERP架构更多是一种功能应用架构。ERP架构往往有三部分组成，一部分是业务功能模块的架构，最主要是关注模块间的关系；第二组成部分是基础业务功能模块的架构，如组织结构、权限、主数据、登录门户；第三组成部分就是纯技术平台架构，有各种引擎、类库。
ERP，从本质来讲，重点关注的是流程的协作，以及在流程中输入、处理、流动变化、输出展示的数据。
流程的协作，大致分为两类，一类是流程各个环节在各个岗位上的审批管控。管理，不外乎是管关键环节和关键产物，另外就是管理异常例外，紧急处理后就又形成规矩。另一类流程的协作是多岗位多部门多组织的协作，这往往通过状态条件来管控，如日期、金额、状态、类型。你把企业日常业务处理环节你画出来你看看，大量的if..else，这就是这些分支条件。所以在ERP中不少这样的业务开关参数、状态字段。因为这些状态类型经常被多个环节所更改，所以我们一般会记载他们的变化流水日志，而且不同状态下的数据特征是什么样，也需要提前明示以及被巡检。
所以，就单说业务功能模块的架构，在技术实现层面、业务功能模块切割和模块间组织关系分析层面，我们要明示接口。我们也得重点关注这两类流程协作的架构，以及两类流程之间的关系。这都是应用架构。
而数据。企业在永续经营过程中，在使用ERP过程中，会有大量的单据、报表，这些都是数据。切面专门研究数据之间的关系、数据特征、数据变化处理的管控，这也是一门架构。我们既然有数据库架构师，那就不仅仅只在数据库产品层面发技术力（况且大家大量使用的数据库还都是商业化产品），更重点的是要在数据架构层面多思考多设计。
所以，从整体来说，从大视野来说，ERP架构应该分为：
1、业务模型层面：企业架构
2、功能模型层面：功能模块架构、审批流程架构、业务状态协作流程架构
3、实现层面：基础业务平台架构（诸如组织、权限、主数据）、平台架构、数据架构
而业务模型架构和功能模型架构应该能存在一种映射关系，放能从现实业务映射到ERP软件。所以我一是在投入研究企业架构应该如何完备性描述，二是在投入研究这样的企业架构如何映射到软件应用架构。
虽然业界有不少EA（企业架构）方法，最流行的是TOGAF，但它更主要讲述的是从业务到软件到技术到实施到运维全生命周期，而在每个环节却又不具体，尤其是企业业务架构这方面，可能是TOGAF制定的时候企业管理者参与较少，所以一直没有明确架构模型，这甚遗憾。
于是，没办法，放下TOGAF，我看了不少企业管理和近百年企业管理演进的书，希望从中找到企业架构模型。
阅读来阅读去，觉得应该这样描述企业架构（当然，这些块和层是否都需要和都能映射为ERP软件，也不见得，可能现在也不需要）：
1、精神层面：愿景、社会责任、企业文化、员工关系、合作伙伴关系
2、公司层面：董事会、公司治理结构、股权上市与融资
3、战略层面：基业长青、战略、竞争战略、蓝海战略、领导力、变革与创新
4、管理层面：组织、管理者职能组织梯队构建、计划协作组织推进管控、员工沟通激励考核
5、业务层面：预算、财务、生产、产品质量、供应链、仓储、物流、营销、客户、人力、品牌...
在微观层面还有流程梳理、动作分解、工艺改进，这就偏业务流程和专业技术的结合了。尤其现代企业更融入了自动化的实现和信息化的对接，更需要两个领域的专家在大层面构筑统一模型了。
从哲学上理解，企业需要管理吗？是企业管理者，还是企业服务者？如果战略目标清晰、组织分工配合职责清晰、每个岗位专业、考核清晰、行动计划清晰，那是否企业的管理者就可以弱化为一个服务者，而非主导的管理者？
但，现实是一个动态变化的。所以需要不断根据内外异常的变化而调整，否则团队还会按照既定计划和方法去走。这就需要管控。另外，现实总差强人意，一个计划要执行到位，人的意识、能力、数量、梯队、团队分工配合、沟通磨合、时间点契合、财务资源和物品资源都从质量和数量上到位，这么多配合环节和配合点，就如同一台汽车的各个零件一样要配合无间，那是多么难的一件事。而汽车能运转，因为汽车全是物理零件，而企业经营，大部分是人，人就一定会有各个方面的例外。一个心情不好都能影响不少东西。所以还是需要管控。
基于我个人的苑囿，目前还未有明确方法从完备的企业架构如何映射到ERP软件应用架构，也无明确的方法来解构ERP软件应用架构、数据架构。这都是需要我们上下而求索的。也可能方法和标准早已经有，如SAP这样的实践派，如ISO这样的理论派。但我目前苦苦追寻这两大派的资料，还无所获，实在局限所致。
有志同道合者，让我们来一起交流讨论辩论吧。
【编辑推荐】
- 浅谈ERP项目中的后期运维研究
- 如何成为一名合格的架构师？
推荐阅读
来这家公司从事信息化工作已经也有三个年头了。有必要对这三年的工作和成长以及不足之处做一个总结。刚来公司的时候，领导决策要将系统做重建开发。有的是成熟的业务逻辑，老的搬过来就可以了。当然，由于随着企业的>>>详细阅读
本文标题：ERP架构分析
地址：http://www.17bianji.com/yunwei/9276.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示