对工作流的一些看法

   最近接触了JBPM，感觉有点郁闷，工作流到底给我们带来了什么？
   就拿一个简单的文件审批系统来说，下属写好文章了，提交给上一级
   也就是流转到下一个流程，然后领导再进行审批。。。
   不同的角色登陆系统的时候，显示的内容和操作是不一样的。
   对于这样一个简单的系统，可以直接对数据库进行存取就OK了
   当下属写好文件后，他点提交，我可以把文件存入数据库
   当领导登陆系统的时候，再去读取数据库，看是否有要处理的文件
   通过简单的数据库存取操作，就可以解决的问题。
   没有必要用到工作流，JBPM之类的。那不是自找麻烦吗？
   实在是不解，难道是考虑数据库的存取问题，还是考虑其他的什么问题？
  
   以上是我学习工作流后的一些看法，真的看不出工作流带给一个OA系统的好处
   也许是我没接触深，也许是我不了解，不过这是我的感觉，和浅陋的看法。
   有高人的话，可以分析下。

单纯的简单审批流程，工作流确实“没有突出优点”，不过业务复杂了，可能工作流能理清一些思路。

任何东西都有其应用场景，这一点必须坚持。

我虽然一直研究工作流，但是非常反感言必称Workflow。就像我现在非常反感言必称SOA一样。

工作流的思想是把流程管理起来。理论上企业公务流程的变动只需要调整流程配置文件就可以变更，甚至可以直接用已有的部分流程组合就可以生成新流程。无论是JBpm还是其他的BPEL都是向着这个目的前进，但是受客观现实的束缚，还需多多努力。
如果采用手工代码控制流程，则每次均需要大量的代码修改。

我觉得工作流的目标是把单纯的流程和业务分开，从而可以让系统在面临流程变更或者重组时候能轻松一点。
如果是按照楼主说的数据库+代码控制，那如果变动时候就痛苦了。

3楼不错哦，一针见血，如果真正能够实现分离起来，确实不错，只是现有的工作流框架都还没成熟，希望能够成熟完善起来

应该从用户的角度去想，就明白为什么要用工作流了。

比如，我希望可以用xml配置流程，然后把所有需要传递的表单数据丢给一个map，然后到什么流程需要什么内容，直接输入流程ID就获得，于是就有了osworkflow里的propertyset。

然后我希望最初级的员工可以设计这个xml，就需要一个设计器。

我又希望上面的map可以持久化到各种数据库，于是又出现了各种数据库接口。

反正用到最后，才会忽然感觉，设计得太合理了，果然应该是这样的。^_^

审批流!=工作流
OA!=工作流

以上

一个良好的企业，他的管理或者业务，以及所处的行业的都是有规范的，标准的，这些规范和标准，结合企业自身的文化和背景等，固化下来就是变成了这个企业的管理模式：业务流程（日常审批，采购等）。现在我们所说的“工作流”（从业务驱动流程模式<OSWORKFLOW等>或者从流程驱动业务模式<JBPM等>），都从技术角度出发，来解决和实现企业的“业务流程”需求。
   其实企业应用的“工作流”才是 企业文化和管理等等内容 真正的体现。
以上观点个人的理解和体会。

也非常赞同： 楼上 jili的观点。

LZ说的不错,简单应用自己就可以设计一个简单的工作流,一样可以使单据进行流转审批,不过这种只能应用在简单的应用上,复杂的应用将会带来很多的问题(如:流程变更,自定义流程,表单创建,并签,会签,代签等等),用户的需求是无止境的,如果靠不停的修改代码来解决,将会是一个可怕后果!workflow也并不是一个很简单的东西,不然有些ERP系统也不会用第三方的workflow,因为去开发完善的workflow并非易事.