企业级业务系统（BPMS）特点分析与应对思路

摘要

 

1、文中分享了对于企业级管理软件的理解。

2、文中整理和分析的业务流程管理系统的特征。

3、文中针对讨论的风险和挑战，也提出了应对的方法，领域内业务系统的产品研发难度从来不在使用的技术上，而在于对领域内业务的理解程度和架构师的设计功力。

4、分享了Merge开发平台信息，作为架构设计思路的一个案例，可用于交流和参考。

 

若有不合适内容，欢迎沟通指正。

 

参考资料： 

1. 可变性设计

2. Merge开发平台（http://merge.wang/wiki/）

 

分析内容

 

业务系统的核心功能

数据化和逻辑化两点构成了业务系统中的核心功能，信息化仍然是业务系统的主题，为用户提供舒适便捷的操作体验，通过系统的使用提升业务执行效率，降低企业运行成本也仍是企业对业务系统需求最痛的点。

 

1. 业务数据化

 

将企业运作过程以结构化数据在系统中进行存储，一方面作为信息化档案长期备查，另一方面提供给系统用户作为业务执行的支持信息。

一般分为字典类数据、基础类数据、业务类数据、日志类数据

 

下图是MES（制造执行系统）系统的业务场景，MES系统的主要痛点就在于支持生产相关业务活动的执行，建立信息化标识（一维码、二维码、RFID等），并采集生产活动过程中产生的各种信息（包括并不限于人机料等方面），并为客户提供执行情况分析报告。

 

2. 业务逻辑化

 

在复杂的业务场景中，基于客户提供的需求，对各个业务环节的工作内容进行支持和约束，将以人治为核心的工作方法进一步升级为系统化、规范化、流程化的工作流程。

以系统作为媒介，将业务流程中的参与者链接在一起，分工协作完成整体业务流程工作。

 

下图是将MES系统进行的数据流图分析，真实项目中的业务场景会更加复杂和细致。

 

 

业务系统的风险与挑战

 

3. 业务逻辑的不稳定性

企业内的组织结构、业务部门、运作模式是一个实时都在变动的，随着人员流动、生产设备的购置、新系统的启动、管理理念的升级、运作模式的变化等等，都会在具体业务执行层面被体现。这些变化是客观存在的、不可避免的在某一时间被识别、被需求、被处理的。

需求规格说明书得到用户的确认，仅代表在确认的时刻，系统的设计可以勉强的满足业务运行中客户提供的不完整的业务需求。而业务的变化却不会因此而停止，仍然会进行不间歇的量变，直至产生质变，突破了原定需求范围和内容。

对于研发团队而言，这是个漫长而痛苦的过程，100天的需求变更可能会被拆分为20个（或更多）5日内的小型需求变更，以间断的方式被提交——有一种温水煮青蛙的感觉。研发成本会因此而难以控制，甚至研发团队被拖垮。应对这个问题，主要依赖研发团队的项目经理对于需求变更内容的把控，系统设计师对于业务的理解成熟度，以及前期过度设计的程度，高级设计师会在设计过程中增量设计25%，以应对基于业务经验识别的潜在业务变化。

 

4. 业务的不完整性

一般情况下，新实施的业务系统都会和企业内的遗留系统有业务联动，建立不同形式的业务接口。新系统所负责的业务可能是闭环业务，也可能是非闭环业务，可能缺失业务起点或业务终点。在跨系统业务过程协作过程中，大概率会出现业务反复、信息反复、业务逆流程等需求场景。

 

5. 业务权限化需求

业务系统随着业务复杂度提升和参与协作人群或角色的增加，对权限的控制需求也逐步的提升。一般来讲一个业务单据的处理过程包括创建环节、审批过程和生效处理三个阶段。

创建过程是单据的发起环节，这个阶段系统主要进行数据有效性验证、格式验证、数据存储等处理。

审批过程相对来说较为复杂，一般会分为若干级审批，或理解为若干个工作流环节，单据信息可能在创建阶段填写完成，也可能在审批过程中得到补充和修正，审批过程中各个环节通过审批结果“同意”或“驳回”，控制单据流程的后续走向，在工作流程设置中存在分支的情况下，单据的某个业务属性或业务逻辑也会影响工作流的走向。

审批过程常见以下的情况：

 

• 静态工作流，即工作流环节的数量和审批人的角色在系统内预置，单据可预知后续工作流程的信息。

• 动态工作流，即工作流环节数量不确定，根据系统逻辑动态构建单据工作流，后续工作流程信息依赖系统逻辑设计而定。

 

6. 业务逻辑碎片化

处理复杂的业务流程时，设计师常采用分治法将一系列复杂的问题，分解为许多细小的业务流程，再根据其业务相关性将业务流程分为几个业务模块。

在复杂的业务场景中，业务模块内也会有横跨数个业务部门的业务流程，此时一个含义完成的业务流程会被进一步拆分为各个含义更小，更不完整的小环节。

举个例子，在一条设计有十几到工序的流水作业的生产线上，一般只有下线工位的产出是完整的产品，可在前几道工序感受就会很模糊，其工序的内容可能仅是要将待加工的原材料或零件调整一下摆放的位置或方向。

 

7. 业务流程的复杂性

有人说做一个操作系统都要比做一套业务系统简单，我十分赞同这句话，经过了一个个量身定制的项目研发工作后，切身的感受就是——欲壑难填。

企业的业务流程体现了企业的管理目标和思想，其复杂性常有一下几个方面：

• 多变分支，也可以理解为多场景切换逻辑。整体业务流程可模拟为一系列相对独立（聚焦内容、便于理解）的业务场景，而单据中的某项属性和某个业务逻辑，会引导系统为此单据由一个业务场景转向另一个业务场景。这期间的链接我们理解为业务流程，而业务流程随着管理方法、业务部门的变化而变化。

• 业务依赖，即业务间的逻辑依赖，需要考虑为主从依赖或业务依赖，前者指大业务流程的变化与其对应的子级业务流程的联动逻辑或相反的约束逻辑。后者则一般指业务操作的一些涉及到其它业务、模块依赖逻辑。可以理解为树型的数据结构，父节点的某项业务操作与其对应的子级节点的联动处理，或对同级别其它节点的逻辑依赖。

• 可逆/可反复，即逆流程和之后的正向流程运行，出于成本考虑，一般情况下设计师会更多考虑系统内的业务闭环，业务流程/场景的转换和控制逻辑。逆流程常被视为费力不讨好的低价值工作。一般情况下可以考虑在25%的过度设计内体现一些逆向流程的设计，系统上线初期或中期，系统数据不稳定，业务人员使用不熟练，系统各种问题层出不穷，逆流程设计在其中为实施团队提供了更多回旋的余地和可能，同时会一定程度上减少数据运维为研发团队带来的成本损耗。

 

8. 应用工作流的机遇和挑战

工作流模式是用户相对于传统的数据调度模式，有了新的体验——系统会在制定好的逻辑化驱动各个业务单元的资源（人、机、料、系统）进行业务活动的处理和推进，这其中的关键点在于“驱动”两个字，而现实往往是骨感的，系统更多的情况下仅仅是在机械的执行编制好的代码，仅此而已。

机遇，通过人工智能完成资源（人、机、料、系统）调度

在这方面人们做了很多的尝试，但绝大多数情况仍然是系统在机械的执行，我理解的人工智能在调度资源方面，要起到几个方面的作用，分别是：决策、驱动和监督、分析和汇报。

决策：直到能决策的时候，人工智能才称得上是智能。当决策的人和机器得到了同样多的信息的情况下，机器是可以得出正确的决策结果的，或者是次优解或可接受的解。

驱动和监督：调度角色将指令发送至各个执行单元，并监督其适时响应、汇报进度。

分析和汇报：基于任务运行信息，进行整理分析、生产进展情况报表。

挑战，工作流与业务环节的连通性设计。

随着工作流模式的设计不断完善，基本可以应对常见的任务创建、调度、执行、监控、完成等控制。但作为业务系统，工作流避不开的问题在于如何处理和业务单据的关系，或者反过来说，业务单据如何配合工作流的设置完成处理过程。

个人建议：操作体验方面由工作流为单据引导用户进入，设计方面由单据向工作流靠拢，由其时业务单据的工作流模式应用比重较大的系统，可以将工作流的模式作为单据设计的预置模式——即单据（系统功能或模块）从设计之初中就认为是建立在工作流上运行的。

 

 

应对方案

针对上述种种困难和挑战，要应对也不是没有办法。复仇者联盟电影传达出这样一个观点——不要试图解决还没有出现的敌人，这个观点应用在软件行业也是合适的，但也不意味着不做任何的准备，我们更喜欢未雨绸缪。

在这方面我的想法说起来很简单也容易理解——以可变应万变（这部分具体实现思路在后面 =^_^= ），无论多复杂的设计，一旦写完就进入了“固化”状态，除非进行再次的编辑，若设计过度的幅度比较大时可能达到举一反三的效果，但同样付出了更多的成本（开发人月，以及复杂设计所带来的一系列不稳定和风险因素），压缩了原有的利润空间，客户也不情愿为了不确定会出现的场景投入更多的资金。

 

应对方法

 

1. 领域建模与业务流程设计

这部分时老声常谈，但这部分确实最重要的一部分，也是变数产生的起点。无论是做产品研发还是项目实施，在需求分析阶段的把控永远是最重要的，这里的蝴蝶扇一下翅膀，在后续就是一阵大风。而这部分工作十分依赖项目经理或负责人对于业务领域需求的掌控程度，不同的负责人的拆分方式可能差别会很大，甚至同一个人在不同时期的拆分结果都是不同的。

所以我们要认可这一点，即指导后续工作进行的业务设计很可能是不完整甚至不正确的，但在问题出现之前，只能认为其是正确的。

 

2. 可变性设计

设计的目标或宗旨是在性能和设计之间的权衡，有些设计从复用性方面考虑，有些设计从可用性方面考虑，有些设计从可维护性方面考虑，而面对客观上一定会产生而主观上又不可预知的需求变更，则可以通过可变性设计方法，进行对变化进行预先设计和管理。

可变性设计方法，结合到某一个领域的项目研发和产品研发设计中，其有效性十分依赖设计团队对目标业务领域需求和其变化规律的了解程度。

 

在对要进行设计的流程进行分析后，可识别出一部分可能会变化的流程或环节，可能包含以下几种情况：

• 可预见大概率会变化且能够预见后续分支的流程。

• 需求定位模糊大概率会产生业务变更的环节。

• 流程设计中已经涵盖的流程分支判定环节。

对于变化，我们从将其视为不可预知的、突发的情况，改变为视其为客观存在的，会不定期出现的存在，将其作为设计工作的一部分处理，将其作为一种常规性业务进行管理。

 

3. 业务流程可以高效率开发

即便应用了一系列的方法以应对未知的需求变更，但实际工作中的需求变更仍然会在我们计划外的某一点出现，而业务架构如何能够高效的应对，并完成业务功能的重构开发，对设计架构的复杂度控制和可维护性提出了更高的要求。

 

4. 业务流程化整为零，逐层精化

这个环节是整个应对方案的核心，从领域建模开始，所有的设计资源几乎都处于不稳定的状态，通过管理手段可以进行一定程度的版本控制，但从架构设计的角度考虑，如何能够支持需求、设计等材料在版本更替过程中，使开发的资源能够平滑的完成过渡，也是对架构设计的一方面挑战。

逐层精化点在“层”，而每向上抽象一层，业务性越强，实现细节越少，每向下一层，业务性越弱，实现细节越多。层级过少，设计体现更加刚性，可变的程度较低；层级过多，会产生更多的“节点”，增加了治理的难度。

 

 

架构设计（以可变应万变）

思路很简单，实现有难度，应用很灵活，设计是重点。前期重注流程开发，后期注重流程使用。

 

1.设计思路

• 代码直到执行的时候，才确定执行的内容。

• 处理资源（代码流）可以热插拔，在系统服务运行中识别、修改和调用。

 

2. 案例参考

在Merge开发平台（http://merge.wang/wiki/）中，业务流程以活动图的形式进行设计和使用，活动图的节点涉及数据处理和流程调用相关操作，以数据处理为设计核心，UML活动图设计过程为主要的操作体验。

设计结果以json格式存储，作为运行资源被所部署的平台识别和使用。