本文主要是介绍讨论一下你觉得一个工作流产品好的标准，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
工作流现在已经应用的非常广泛了，审批OA等等自然不必多说，许多业务系统里也有大量的应用。前两天的一个项目就是使用工作流将整个项目管理的过程进行整合，包括了前期预算、项目进度管理、合同管理等等。
可供选择的工作流也很多，商业的、开源的。那么你是如何评价一个工作流产品的好坏的呢？你的标准是什么？当然，用户也经常会问我这个问题，我的回答是：根据你实际的业务。是的，不管是什么样的工作流，都是为了满足业务的需要，你把你的需求提出来，我们看看是否满足，不能直接满足，最合适的间接方式又是什么。你说，我要有催办。是的，我们有。你说，我要有任意回退和任意流。是的，我们有。你说，我想对流程实例进行分级管理。oh,没有也，重要吗？让我们想想其他办法。你说，你们符合BPEL标准吗？这个。。。你说，你们采用了petri网模型吗？汗。。。你说，你们是SOA架构吗？。。。
我的衡量标准是这样的：
1、流转功能
包括了基本的工作流模式实现，串行、并发、分支、汇聚、循环等等。这个是最基本的。其实打开流程设计器拖拖拽拽很快就能知道这个产品到底实现了哪些流转模型。实际这个的实现也是引擎的核心。有多种模型可以选择。petri 模型应该是最灵活的了，也有很大的实现难度。但是流程模型做这么灵活，到底实际能用上多少……就我个人的经验来说，大部分的复杂性都是由流程的分支并发（m/n）引起的，最坏的办法是强制要求客户将这些并发的任务改成 step by step 的执行。这样牺牲一点效率，还是可以把项目做成的。
2、业务的内在支持
比如说催办、时间服务、收回等等。我觉得这个与实际业务挂钩，反而是最为主要的考虑。因为采用间接的方式必然会产生编程，而很显然会耗费成本。
3、与业务的契合方式
流程维护流转。业务还是自己实现。如何将这两者很好的衔接起来。同时这个过程还存在权限的限定，每个运行节点对业务的权限肯定存在差别，是否有一套完整的解决方案？当然这其中也包括了组织机构的适配，对各种组织模型的支持。
4、定义良好的API
通常会存在工作流无法直接满足的业务场景，那么肯定需要程序直接调用工作流的API，清晰且简洁的API。
5、流程的仿真
这种仿真比较简单，目的在于检验所定义的流程是否正确。出错要有明确的提示信息。普元的单点调试？
6、电子表单
我始终觉得电子表单目前实际应用并不理想，它仅仅只能处理简单的业务。但是销售的经验告诉我，这是一个巨大的闪光点。用户喜欢自己动手。流程定义实际最终用户很难实际操作。我在想：简化版本的流程设计器+电子表单也许会有很好的售前 效果。
7、良好的售后
8、良好的最终用户体验
9、性能
10、最好能够和标准扯上关系，可是谁知道我是否真的有关系呢？
这篇关于讨论一下你觉得一个工作流产品好的标准的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
