锁定老帖子 主题:国内主要工作流厂商分析
精华帖 (0) :: 良好帖 (12) :: 新手帖 (0) :: 隐藏帖 (3)
|
|
---|---|
作者 | 正文 |
发表时间:2011-03-02
原文发表于INFOQ 尽管在企业应用中工作流应用的越来越多,但对国内的工作流厂商们来说,这并没有给他们带来期望中的快速增长,这并不奇怪,因为国内工作流产品基本上全部面向开发者和系统集成商,解决的是编程问题,旨在简化对流程进行支撑的软件创建,这个定位决定了当越来越多的系统集成商开始自己研发工作流和越来越多的开发者采用开源工作流时,原有的工作流厂商发现生存日益艰难。
一、 现状大部分的工作流产品都实现了WFMC工作流参考模型(参见附录)的接口1、接口2、接口3和接口5:
除去对工作流参考模型的支持,基本上所有的工作流产品都实现了电子表单,在处理以数据填报及数据收集为主的应用中(数据不需要过多的逻辑处理和没有复杂的关系关联),电子表单能够显著的增加生产力,但是更现实的情况是企业应用大都具有复杂的业务逻辑,在这一方面,电子表单不是银弹。 通观所有的工作流产品,尽管有些产品不乏闪光点,但是整体用乏善可陈来形容是合适的,有些产品甚至可以用非常初级来描述,这不能责怪厂商,因为他们所要解决的问题域决定了他们产品所能解决的问题域。 乏善可陈表现在6个方面:
图1不同层次流程所对应的问题
1、 工作流与平台几乎所有的工作流厂商都提供平台,携创是个例外,但是这让他的市场非常狭窄。为什么会提供平台?我们先来看看工作流要解决的问题域,工作流旨在简化对流程进行支撑的软件创建,既然是简化编程,那么更进一步提供平台就显得水到渠成了。 平台分为两种,一种是快速开发平台,一种是业务平台(或者提供相关的业务套件)。
与单纯的快速开发平台相比,业务平台显然站在了一个更高的层次上。在软件开发中,最大的浪费往往并不在于技术本身,而是在于对业务的不熟悉,在于核心领域模型的频繁变动。对用户而言,根据需要选择合适业务平台和相关服务无疑能够产生最大的价值。 为什么有的厂商提供快速开发平台,而有的厂商提供业务平台呢?这取决于两个方面,一是厂商切入工作流市场的年限,年限越长,越积累有丰富的项目经验,这些经验很容易转化成业务套件;二是厂商的客户定位,不难发现提供快速开发平台厂商的客户都是系统集成商,自己并不承接相关项目。而反观这些快速开发平台,很难发现有特别突出的技术优势,大部分都是对Struts、Spring、Hibernate、Ibatis简单封装后的CRUD框架,加上代码自动生成和Eclipse插件支持,没有任何闪光点(普元是个例外,但是我们同样对其平台发展持不乐观态度,这可以再开一个话题)。 我们的观点是:快速开发平台没有太大价值,提供行业应用的业务套件/模块才是正道。 2、 客户观察台湾地区的工作流应用和国内的工作流应用,我们能够明显的发现:台湾地区的应用大部分集中在制造业(私企),而国内的应用则集中于政府、电力和金融行业(国企)。为什么会出现这种情况,作为制造业的大国,为什么工作流的应用却只集中在国企和政府,答案不得而知。 抛开工作流应用,工作流厂商的客户包括了以下2种:
3、 厂商的层次分类根据上面的讨论,我们不难将工作流厂商分为3类:
二、 挑战与机遇尽管在企业应用中工作流应用的越来越多,但对国内的工作流厂商们来说,这并没有给他们带来期望中的快速增长,单纯的工作流产品甚至面临销售越来越困难的窘境。 1、困境工作流厂商面临的压力来自于3方面: 系统集成商由购买转向自主开发。这是工作流厂商发展受阻最重要的原因,工作流应用越来越多,没有集成商愿意将这个重要的中间件依赖于他人。大多数集成商选择的方式是直接购入现有工作流厂商的源代码,也有基于开源工作流进行开发的,但是不多。 开源工作流的竞争。对于中小软件公司来说,如果遇到有流程的需求,他们的第一反应是采用开源工作流,而事实是开源工作流做的并不差,除去对国情的支持较弱外,开源甚至比一些商业产品还要好,尤其在对标准和模式的支持上。 不能面向最终用户。这是最根本的问题。工作流解决问题域的限制让最终用户根本感觉不到工作流产品价值的存在,而又没有一家工作流厂商能够做到像英特尔公司那样:组装电脑时指明要一颗奔腾的心。于是发展严重受限于系统集成商。 2、机会那么,工作流厂商的机会在哪里?最重要的就是:将产品面向最终用户。
三、 总结国内工作流产品全部面向开发者,解决的是编程问题,旨在简化对流程进行支撑的软件创建。 国内工作流厂商分为3类,分别是工作流、工作流+开发平台、工作流+业务平台/套件。 工作流厂商面临困境的主要原因在于产品不能面向最终用户,这样当越来越多的系统集成商开始自己开发工作流和越来越多的开发者采用开源工作流时,生存日益艰难。 工作流厂商的机会与困境相对,就是将产品面向最终用户,这包括了自己实施项目、转向BPMS以及提供云中的流程服务。 附录WfMC之工作流参考模型 图2 WFMC工作流参考模型 图2是工作流管理联盟(WFMC)提出的工作流管理系统参考模型,工作流执行服务器周围的接口是WAPI(Workflow APIs),通过这些接口可以访问工作流管理系统的服务,这些接口还控制工作流控制软件与其他系统组件间的交互。在这5个接口中的许多功能,都是被2个或更多个接口同时拥有的,因此WAPI可以看作是统一的服务接口,可以交叉使用这5个接口来支持工作流管理功能,而不是单独的使用其中某个接口,其中各个接口的具体含义如下:
工作流引擎:它是工作流管理系统的核心,工作流引擎对使用工作流模型描述的过程进行初始化、调度和监控过程中每个任务的执行,在需要人工介入的场合完成计算机应用软件与操作人员的交互。另外它的另外一个重要的功能是完成与应用软件及操作人员的交互。
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2011-03-02
最后修改:2011-03-02
转向BPMS的意思是不是让国内厂商放弃自己的流程格式标准?
云这个东西就更悬了,呵呵 |
|
返回顶楼 | |
发表时间:2011-03-02
”版本更新迟缓,没有持续投入。很多工作流产品早已停止更新。“
这种说法好像有点不太客观哦。。。 |
|
返回顶楼 | |
发表时间:2011-03-02
“工作流厂商面临困境的主要原因在于产品不能面向最终用户”
哈哈,这种产品仅仅是国内众多工作流产品里面的一种类型,不能以偏概全哦。。。 |
|
返回顶楼 | |
发表时间:2011-03-02
看完之后,感觉某些势力在唱衰我们的厂商哈。。。
|
|
返回顶楼 | |
发表时间:2011-03-02
最后修改:2011-03-02
我从设计流程引擎的角度讲讲,为什么目前国内工作流产品有些没有面向最终用户
流程图的设计是一个无法确定的人工模拟的过程,而流程引擎对流程的处理模块和代码是由机器执行的确定性的代码,这两者自己存在着天然的矛盾,在没有很好的理论能够解决这个问题之前,是无法完全依靠确定性的代码来处理不确定的流程图的,至少我个人认为国外的厂商对此也没有什么太好的解决办法,ThoughtWorks 分析师先生 你觉得呢? |
|
返回顶楼 | |
发表时间:2011-03-02
政府、电力、烟草的正式工是不会去定义流程的。要不是劳务工,要不是厂家
|
|
返回顶楼 | |
发表时间:2011-03-02
我们做的 电力MIS系统 工作都是我们按照他们的意思给他们定义好工作流的
|
|
返回顶楼 | |
发表时间:2011-03-02
国内那些乱七八糟的流程啊
|
|
返回顶楼 | |
发表时间:2011-03-03
最后修改:2011-03-06
楼主似乎把workflow 与 BPM的用途搞混淆了。一个如此不专业的人写这么多,这么长令人感动,同时对于其错误的结论也深表理解。
什么叫面向最终用户的工作流???工作流能代表企业的一切吗?伴随流程的还有业务规则和业务逻辑,这些东西你要最终用户自己写吗?如果谁能做到这一点,那么SAP,金蝶,用友以及大大小小的应用软件开发商都要关门大吉。为什么?因为一切都是流程,而流程居然可以由客户自己完成,只需要你们提供给客户一套工作流就可以了,这不是滑天下之大稽吗? 另外,国内工作流之所以不行,主要有两个原因: 1.客户还没有进化到流程工作。 2.工作流厂商只关心流程定义和流程引擎,而与流程定义密切相关的组织架构,角色等定义不够灵活,总之,不能为进行灵活的流程定义。 |
|
返回顶楼 | |