通过前面的步骤,我们已经发现了活动、创建了“现状”业务模型、对它们进行了分析并获取到如何改进的一些想法,业务限制和改进要求也已正式定义, 现在,我们将视线转移到业务流程的重新设计上。
应选择最适合组织并最支持过程设计目标的过程建模工具。在发现和分析环节,我们可能已经使用了某些建模工具,但这些建模工具一般不支持解决方案设计、仿真或应用程序生成。在这种情况下,(如果有钱有技术的话)可以选择使用完整的BPMS工具,以支持应用程序生成,预留应用程序和数据的接口。当然,我们也可以(一般也是这么做的)使用更传统的方式构建应用程序支持和接口,使用当前的建模工具来设计“ To Be”业务模型。
在分析阶段,我们列出和确定了流程、子流程、业务功能和活动(在业务部门内)进行可能的更改。这可以清楚地显示当前流程存在的问题,有助于决定将要重新设计的内容和优先级顺序。一旦选择了要更改的业务领域,就可以继而评估更改的程度,以进行增量或大规模的系统更改。有时,只要对未来状态有清晰且可以接受的看法,频繁进行小的更改就可以对过程性能产生与大的变革同等重要的影响。
业务设计团队需要了解支持业务改进的设计、构建和实施的技术方法。同样,技术团队将需要理解业务转型方法。如果流程设计将通过BPMS生成应用程序来支持,则约束和选项将与所支持的更改有很大不同。甚至是基于COBOL的遗留应用程序系统。由于这些选项和约束将对新业务和IT支持设计产生影响,因此必须在设计过程的开始就对其进行识别和定义。
实际设计将在流程层次结构的所有级别进行。所有内容都必须进行任何更改,并且在考虑下游活动时必须使用所有内容。
尽管团队在设计新流程时所采用的方法会有所不同,但某些关键活动应在流程管理的设计阶段进行。
最常见的关键活动有:
- 在所有适当的细节级别上设计新流程(请参阅流程层次结构)
- 定义新流程中的活动,并确定工作流和依赖性
- 定义业务操作方案并围绕这些方案进行模块化
- 定义所有数据需求
- 定义控制活动的规则
- 定义功能组之间的流程切换
- 从变更中定义客户价值,并将其与成功度量联系在一起
- 在新流程中定义所需指标
- 定义和设计业务和绩效报告
- 差距与现有分析的比较
- 创建业务和技术系统变更规范/要求
- 创建物理设计
- IT基础架构分析与设计
- 模型仿真,测试和验收
- 生成或构建支持应用程序
- 设计和构建与旧版应用程序和数据的接口
- 使用应用程序支持,旧界面和规则测试所有业务活动
- 创建并执行实施计划
重要的是要注意,尽管上面列出的这些关键活动按逻辑顺序出现,但不一定按该顺序发生,并且许多活动将同时发生。另外,这是一个部分列表,并不与任何公司的内部方法、步骤或流程制度相冲突。它旨在为在项目、公司层面优化设计未来流程提供一种对应考虑的活动的建议。


原 文 
评 论