ERP架构分析

运维 系统运维
在咱们计算机界,实现架构倒是讲了不少,在大层面有企业应用架构模式,在方法上有面向对象\面向服务,在描述手段上有UML,在微观上有设计模式。但说起切面领域,如ERP领域,应该也有架构方法和架构模型。

  在咱们计算机界,实现架构倒是讲了不少,在大层面有企业应用架构模式,在方法上有面向对象\面向服务,在描述手段上有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这样的理论派。但我目前苦苦追寻这两大派的资料,还无所获,实在局限所致。

  有志同道合者,让我们来一起交流讨论辩论吧。

责任编辑:黄丹 来源: 博客
相关推荐

2013-06-26 16:33:50

ERPSAP

2012-06-21 10:00:09

ERP系统架构

2012-01-11 13:02:23

移动商务ERP

2012-02-13 14:41:50

Titanium架构分析

2023-03-26 20:24:50

ERP网站系统

2016-12-14 19:20:07

Spark SQL架构分布式

2016-11-25 13:14:50

Flume架构源码

2024-01-03 15:00:01

数据分析人工智能物联网

2023-04-11 09:41:34

ERP云计算业务运营

2020-08-31 16:15:46

ERP项目风险

2014-07-23 09:26:46

大数据安全大数据安全分析

2011-03-23 11:01:55

LAMP 架构

2011-03-09 15:07:48

LAMP网站架构

2012-08-10 10:18:21

ERP

2011-04-25 09:38:58

ERP

2022-10-10 17:52:08

CPUERP系统

2016-11-29 09:38:06

Flume架构核心组件

2016-11-25 13:26:50

Flume架构源码
点赞
收藏

51CTO技术栈公众号