初生牛犊式工作流系统

在论坛中常常会看到一些初生牛犊发布的，我设计的工作流系统 等等。对这类的帖子我都会饶有兴趣点击进去，准备仔细观摩和研究，但往往是一略而过，失望而归，或许是我的期望太高了，以为能得到更多的借鉴和启发。

 

更多的经验和启发还是得来自项目实施中，根据更多的用户使用情况来归纳和总结，再反应到产品中。

 

在论坛和博克中看到的大多还是很初级的工作流系统设计，甚至是只为实现一个项目中的某种特定的流程而设计的，特别是如为了实现审批流而设计的流程管理，将很多审批的过程和记录等都固化在流程引擎中了，甚至很多人都认为工作流就是审批流，能够处理好审批流，就是工作流系统了。这其实不叫工作流系统，更不能算是工作流产品了，只能是做的审批流项目。

 

一个工作流软件产品，是能适用到各个行业，并且流程引擎的模型设计很健壮，利用流程引擎的模型能设计出各式各样的业务流程。顺序流，条件流，循环，分支，合并，子流程，回退，自由跳转等等这些都是基本的功能，还会有很多特殊的功能设置。

 

一套工作流系统要做好，要有长时间的积累，人力，物力，时间，经验，设计能力等等一样都不能少，不是做一两个项目，满足了项目的需要，就是工作流系统了。短时间构造出来的，只能是1.0的测试版本，还需要更多的项目实践来验证和提高。如果基础构架不好，后期很可能走进死胡同，无法升级和扩展，仅局限于这一亩三分地了。

 

好的流程引擎设计，能够适应变化，在给业务流程建模时，可能还会有多种实现方式，就像我们利用工具来编程实现功能一样，最终的目的是一样的，可是写法不一定完成相同，代码功底强的人，实现的简洁明了，初学者费了很大劲最终也能实现，但是代码的可读性和后期维护性就差很多了。

 

一套好的工作流系统，首先要有好流程引擎的模型，就是我们常说的工作流规范，先制定好一个规范，然后按照这个规范去给流程建模。就类似我们学面向对象编程一样，首先要有类，接口，继承，多态，等等这些基本的概念和规范，再利用这些去发挥，编写自己的实现，就像站在巨人的肩膀上一样。

 

当然初生牛犊式的工作流系统也有一定的运用场景，如有些业务系统中，只是要简单的运用一下流程，甚至客户也没明白工作流是做什么用的，只是有的地方需要按顺序等的流转一下，自己设计只是为实现项目需要而做的简单的工作流，能满足项目的需要，解决客户的问题，就也ok了.

 

术业有专攻，客户点名提出要上的工作流系统，还是交给我们专门做工作流产品的公司来处理了。

 

一般的开发和设计过程如下图：


 

 

我们公司的eworkflow自定义工作流系统，集成eform自定义表单后，就是类似上面的那种工作顺序了，可视化的给业务流程建模，可视化的设计表单，设计完成后，立即可以在线运行，查看跟踪流程流转的结果，将一些业务系统的开发和流程的流转运行变得简单和快捷了。

 

 

 

这位兄弟，国内企业流程应用的情况非常复杂，很多业务模型连企业管理者都无法描述清楚，企业让自己的技术人员依据自己企业的实际情况来做一套简单易用的工作流系统，这样大大降低管理和开发成本，这无可厚非吧。。。

再说国内的专业流程软件企业也不一定敢保证，自己的经验和能力可以应付所有的情况。。这样一来，是不是需要以宽旷的胸怀来看待这些敢于发布自定义工作流系统的初生牛犊们？  他们不仅仅不是你们的竞争对手，反而会带个你们更加广阔的思路和视野

我们的工作流事业不是哪一个人，哪一个企业，哪一个门派能够包揽的了的，甚至可以这样说，现在这个阶段是大家博采众家之长，广纳意见，吸收各种先进的设计和开发思路的好时机，如果一门技术在其发展过程中，始终处于某个强大的单一门派的支配和控制下，我想这门技术的前途是非常暗淡的。。。。。。

企业让自己的技术人员依照自己企业的实际情况做的简单的工作流系统

这种应该只是按项目的方式来实现流程功能，按项目的实现，能满足自己项目的需要，就是成功的。但是要做成产品还需要更多的经验和时间的积累。

当然。。那是肯定的。。。。