首先解释两个概念:
工作流,将工作分解成几段不同的任务，然后通过一定的规则和过程来执行这些任务并对它们进行监控,达到提高工作效率，降低生产成本，提高企业竞争力等目的.它大多应用于办公自动化领域.
业务流:它是企业内部资源之间的数据流动，一般通过企业资源计划系统(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,理应包含工作流子系统和业务流子系统，而这两个子系统既是毫无关联的又可以相互协作，不关联指的是少了其中的一个，另外一个都可以正常工作。相互协作指的是它们可以互相利用，更好的为企业发展服务.