ERP系统中的工作流和业务流

avatar 2020年3月13日10:58:49 评论 350

首先解释两个概念:

工作流,将工作分解成几段不同的任务,然后通过一定的规则和过程来执行这些任务并对它们进行监控,达到提高工作效率,降低生产成本,提高企业竞争力等目的.它大多应用于办公自动化领域.

业务流:它是企业内部资源之间的数据流动,一般通过企业资源计划系统(ERP)对企业中的物流、资金流和信息流进行全面集成管理.

但是在实际的企业中,常常有些需求,需要在OA系统和ERP系统中来回切换,比如:采购用款申请,付款,做凭证则是ERP系统中的功能(如下图)。

此外,企业在利用oa系统进行工作流审批后,会产生一些业务数据,而这些业务数据又可能是ERP系统中的外部数据源,比如上图的采购费用申请的数据。为了避免数据的重复且保证数据源的唯一性,就产生了工作流系统和业务流系统集成的需求.

目前常见的集成方法,归纳起来两大类

1):基于接口的集成封装模式,利用OA,ERP各自提供的的接口(这个接口的含义包括:数据库表结构,web service接口,其它自定义接口),实现两数据之间的互访.

2):基于中间表的互访模式,以相同的数据模型存储不同的系统之间的共享数据, 通过直接对两系统的数据表进行操作的方式,实现不同系统间的数据访问,以及数据的一致和实时传递.

由上分析可知,这种集成还是有难度的,至少需要不同程度的二次开发,如果是采用二次开发,我个人倾向于web service,web service就是我们常常听到的soa架构,它是一种整合各种服务的架构平台,核心点就是实现服务和技术的完全分离,从而在最大限度上实现服务的集成和重组.(注,如果在erp开发中,我是强列反对用soa架构的,我一直觉的soa只用在一些特定的业务场景,最适合的莫过于对外提供服务接口),为什么不采用表呢?因为
ERP的审批流还比较特殊,它流程的执行实际上就是控制权在两个子系统之间的转移,如果是基于表的互访问模式,这是一种紧耦合的集成方式,它将影响系统的灵活性和扩展性,阻碍业务流程的调整和优化,不利于企业的发展.

最近在研究国内的一个开源系统FireWorkflow(http://www.fireflow.org),并对它的源代码进行了分析(先做个广告,接下来我会把源码分析的过程写成blog,供大家交流,指正).

Fireworkflow提到的一些理念,甚合我意,比如,一个普通的请假流程

该流程图的执行过程描述如下:

首先,工作流子系统启动一个新的业务流程实例,然后创建一个新的任务实例——“申

请”,并将控制权交给业务子系统,业务子系统等待申请人填写表单。申请人完成表单后,控制权再次被交给工作流子系统,由它决定下一步的路由。这个工作是由称为Synchronize r 的元素完成的(图中标有"S"的圆圈)。在这个业务示例中,它通过计算得出下一步操作是“部门经理审批”。于是创建一个名字叫做“部门经理审批”的任务实例,并将控制权交给业务子系统,业务子系统等待部门经理做审批操作。

图中的工作流逻辑和业务逻辑分得非常清晰,审批之后执行哪个业务操作是由工作流逻辑子系统的一个“操作”决定的。业务逻辑子系统中的“审批”操作仅仅负责完成业务特定的逻辑,其他的与之无关,这正是我所想要的结果,一个好的erp,理应包含工作流子系统和业务流子系统,而这两个子系统既是毫无关联的又可以相互协作,不关联指的是少了其中的一个,另外一个都可以正常工作。相互协作指的是它们可以互相利用,更好的为企业发展服务.

avatar

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: