如果这四类受众都打算进行协作,就有必要避免图解的混乱状态。我的意思是说,对于某一特定流程,以单个图解的形式把每一种受众的每一个需求都记录在案将导致信息过载。这将最终危及每个人的理解能力,然后这四类受众会迅速回到各干各的状态。 那么这四类受众如何才能在分享对业务流程的理解的基础上一同工作呢?最有可能成功地方式是找到一个共同点,这个共同点应该是一个简单的图解标记格式,可为四类受众所理解。
很显然这应该是流程的业务(“绿色帽子”)视图,因为90%以上的受众以及所有四类利益攸关者均能理解它。 那么我们如何才能把其他三类受众(IT、系统提供商及风险合规检查)的需求集成进这个简化的流程视图呢?其需求……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
如果这四类受众都打算进行协作,就有必要避免图解的混乱状态。我的意思是说,对于某一特定流程,以单个图解的形式把每一种受众的每一个需求都记录在案将导致信息过载。这将最终危及每个人的理解能力,然后这四类受众会迅速回到各干各的状态。
那么这四类受众如何才能在分享对业务流程的理解的基础上一同工作呢?最有可能成功地方式是找到一个共同点,这个共同点应该是一个简单的图解标记格式,可为四类受众所理解。很显然这应该是流程的业务(“绿色帽子”)视图,因为90%以上的受众以及所有四类利益攸关者均能理解它。
那么我们如何才能把其他三类受众(IT、系统提供商及风险合规检查)的需求集成进这个简化的流程视图呢?其需求可以覆盖到流程的业务视图之上,利用以下三种技术:
- 附加信息——信息链接(文档、表格、策略、工作指令)可被添加到流程图的对象上,这样就不会有晦涩难解的图形搞混,使得基础的图解复杂化了。
- 交叉引用链接——可添加在流程模型和相应技术系统(如ERP、工作流、软件配置环境等)之间。如果有必要的话,可以是流程活动业务视图及活动从自动化角度的技术视图之间的交叉引用。比如说,链接到一个流程自动化系统中的一个技术过程流。
- 个性化——根据每个用户在组成员中的角色需要显示或隐藏附加信息及链接,对于大多数(业务)受众来说,图解仍保持简洁、清晰并易于理解,同时也提供了其他三类受众所需的各项特性。
因此,通过提供前后关联的额外信息访问,图解并未显得更为复杂,而每一类受众需求均能无损地得到满足。流程的绿色帽子扮演了一体化中心的角色,其他的流程视图和系统均向其汇拢,潜在地为多种类型的业务流程之间提供了凝聚力。这个方案将终止似乎已经浮出水面的业务与IT之间的权利争斗,在这场争斗中,双方似乎都认为流程模型就是单一实体,必须争个你死我活。
关键是核心业务流程模型及关联的信息系统是平行管理的,因此它们是保持同步的。举个例子,一个绿色活动,比如开发票,对于保持要素更新来说,每一个组(白、蓝、绿、红)都有分担的责任,而软件应用则自动维护着这种交叉关联。
这对任何打算管理潜在多模型和交叉关联的流程管理应用都提出了迫切需求。在选择单个应用时,可能要求来自每一组更多的需求细节来取得折衷,单还有些核心需求是你必须坚持的:易于建模,关系管理,可审计的治理周期,通过访问权限进行多视图控制,可伸缩性以便服务全体用户——潜在包括每一位员工及有选择的第三方。
作者
相关推荐
-
AWS PaaS来也:炎黄盈动为业务流程管理带来无限价值
随着容器、微服务等技术的使用,企业的应用程序也变得越来越趋于组件化;同时,为了这串连起这些组件,开发人员却需要 […]
-
在iBPM和BPM间做选择 不一定非此即彼
大多数系统都有一样的能力,在很多人看来,除了BPM或者iBPM这两个标签以外,实际上它们之间并没有任何区别。
-
Red Hat披露更加架构驱动的BPM模型愿景
Red Hat的一个更加结构化的BPM设计方案有望搭设应用开发界与业务流程管理的桥梁,让企业架构师、开发者和业务侧的人更快速更容易地实时新的业务流程。
-
SOA治理模型核心:人
治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。