在论坛中常常会看到一些初生牛犊发布的，我设计的工作流系统 等等。对这类的帖子我都会饶有兴趣点击进去，准备仔细观摩和研究，但往往是一略而过，失望而归，或许是我的期望太高了，以为能得到更多的借鉴和启发。
更多的经验和启发还是得来自项目实施中，根据更多的用户使用情况来归纳和总结，再反应到产品中。
在论坛和博克中看到的大多还是很初级的工作流系统设计，甚至是只为实现一个项目中的某种特定的流程而设计的，特别是如为了实现审批流而设计的流程管理，将很多审批的过程和记录等都固化在流程引擎中了，甚至很多人都认为工作流就是审批流，能够处理好审批流，就是工作流系统了。这其实不叫工作流系统，更不能算是工作流产品了，只能是做的审批流项目。
一个工作流软件产品，是能适用到各个行业，并且流程引擎的模型设计很健壮，利用流程引擎的模型能设计出各式各样的业务流程。顺序流，条件流，循环，分支，合并，子流程，回退，自由跳转等等这些都是基本的功能，还会有很多特殊的功能设置。
一套工作流系统要做好，要有长时间的积累，人力，物力，时间，经验，设计能力等等一样都不能少，不是做一两个项目，满足了项目的需要，就是工作流系统了。短时间构造出来的，只能是1.0的测试版本，还需要更多的项目实践来验证和提高。如果基础构架不好，后期很可能走进死胡同，无法升级和扩展，仅局限于这一亩三分地了。
好的流程引擎设计，能够适应变化，在给业务流程建模时，可能还会有多种实现方式，就像我们利用工具来编程实现功能一样，最终的目的是一样的，可是写法不一定完全相同，代码功底强的人，实现的简洁明了，初学者费了很大劲最终也能实现，但是代码的可读性和后期维护性就差很多了。
一套好的工作流系统，首先要有好流程引擎的模型，就是我们常说的工作流规范，先制定好一个规范，然后按照这个规范去给流程建模。就类似我们学面向对象编程一样，首先要有类，接口，继承，多态，等等这些基本的概念和规范，再利用这些去发挥，编写自己的实现，就像站在巨人的肩膀上一样。
当然初生牛犊式的工作流系统也有一定的运用场景，如有些业务系统中，只是要简单的运用一下流程，甚至客户也没明白工作流是做什么用的，只是有的地方需要按顺序等的流转一下，自己设计只是为实现项目需要而做的简单的工作流，能满足项目的需要，解决客户的问题，就也ok了.
术业有专攻，客户点名提出要上的工作流系统，还是交给我们专门做工作流产品的公司来处理了。
一般的开发和设计过程如下图：
我们公司的eworkflow自定义工作流系统，集成eform自定义表单后，就是类似上面的那种工作顺序了，可视化的给业务流程建模，可视化的设计表单，设计完成后，立即可以在线运行，查看跟踪流程流转的结果，将一些业务系统的开发和流程的流转运行变得简单和快捷了。