分类： IT业界
2020-10-30 14:02:19
在当下的互联网时代，有越来越多企业，开始利用基于网络的，信息化集成工作流，来帮助自身提高运转效率。
为了解决好企业各阶段中的问题，工作流自然要随着时代不断发展发展。如今移动互联网已经普及，各终端设备性能算力越来越高，不少企业开始要求工作流的管理实现移动化和智能化，需保证兼容性，能随时随地处理业务。
1、工作流建模趋势
当前工作流的建模技术可谓是百花齐放，没有统一的模式，这也就是说在技术方面，相关解决方案依然不过成熟。归纳现在主流的建模方法，基本上可分成5大类：脚本语言、基于网的方法、基于规则的方法、基于逻辑的方法和代数方法。
（1）脚本语言
脚本语言自然不用多说，它通常包括控制流和数据流的语句结构。优势在于其提供了一种比较简便的描述方法，对于有经验的设计者来说，使用起来更加得心应手。当然，缺点也很明显，那就是它本身缺乏流程的形式化语意，语言的语义主要供语言解释器使用。
（2）基于网的方法
适合对流程可视化建模，一般都使用状态变迁网，流程中的活动用结点表示，控制流用边表示。
使用状态变迁网时需注意其是否有形式化的语义，大多数工作流产品的可视化建模方法都缺乏形式化语义。在具有形式化语义的状态变迁网中，使用得最多的就是Petr网和状态图(State Charts)。具有形式化语义的，基于网的方法，可转换成其它建模方法，如基于规则的、时序逻辑的和脚本语言的方法等。
（3）基于规则的方法
目前较为主流的基于规则的方法是ECA(Event/Condltion/Acton)规则，ECA规则最早用于AooDBS，而后又被用于工作流管理领域。ECA规则具有形式化基础，同样可以转换成其它的建模方法，但是ECA规则的可视化工作量比较大，且规则集较大时将难以管理。
（4）基于逻辑的方法
基于逻辑的方法适合于描述系统的动态性，其中时序逻辑是一种常用的方法，它具有很好的形式化基础，验证工作流模型的属性比较方便。但是时序逻辑的主要缺点是很难实现可视化．不容易转换成其它的描述方法，描述业务流程的系统行为太复杂。
（5）基于代数的方法
过程代数(Proees Algebra)主要还是局限在理论探讨上，在工作流管理领域用得很少，只有一种基于过程代数的描述语言LoToS被用于工作流管理领域。代数方法的主要缺点类似于基于逻辑的方法，其在自动执行和形式化验证方面的表现要比基于逻辑的方法差，建模方法缺乏直观性，难以理解。
根据以上的比较可以看出，各种建模方法各有优缺点。但从总体上来看，脚本语言、基于网的方法和基于规则的方法更具有吸引力。
2、工作流实施环境趋势
工作流管理系统应该支持异构、自治和分布环境中，应用系统的集成和互操作。提供融合老旧的应用系统的方法，以保护过去的投资，支持组织机构的改组，同时还需支持具有容错能力的动态企业(Dynamic Enterprise)技术，在有错误产生时工作流管理系统能保证工作流执行的正确性和可靠性。
后来也出现了一些基于Web的工作流解决方案。通过观察基于Web技术的工作流管理系统，发现多数产品仅可片面地使用Web，但面向Web是未来发展的趋势，这种趋势可以在一些研究项目（WebFlo、OzWeb、DartFlow）中体现出来。
由于Web及浏览器本身的限制，只能提供Client/Server计算模式，并且所使用的CGI接口只有有限的编程能力，在位置透明性、支持事务功能、安全性、性能等方面还有待于进一步改善。且工作流研究是一种跨多学科的研究，涉及到CSCW、人机交互、数据库、管理学、社会学等学科。任何缺乏多学科合作的研究，都无法让其成为通用的系统。
而企业在工作流的选择上，通常需根据自身业务特性，传统方式为委托软件公司或自组技术团队。在委托时一般仅提功能需求，对实现模式没有过多要求，忧点在于省心省力，而缺点则在于其难以后期维护。
曾有企业购买成品BPM，在业务变动后需升级系统，可企业缺乏相关技术人员，只能再次找到开发公司花钱升级，升级中的麻烦很多。即使有自己的开发人员，对现有软件升级也是大工程，毕竟没人愿意修改别人的代码，其中涉及的问题太多。
有问题，自然有人去想办法解决，于是，应运而生。其并非传统的成品软件，而是集合了各种功能组件的半成品框架，可以二次开发。企业仅需要少量开发人员，不用对开发者的技术有过多要求。
比如我接触过的相关框架，基本都含有代码生.成器、工作流、表单、权限、报表、微信集成等，在框架基础上进行简单配置，即可以迅速开发包括OA/ERP/CRM/移动APP/电商后台在内的企业应用系统，且基本上是源码交付，后续的业务变更也可以自己处理，很多东西不会受制于人。
这里推荐一个合作方的演示demo，可以先从基本架构了解一下快速开发的基本套路，再结合企业自身情况进行挑选。
演示地址：
