ERP实施与支持--业务流程建模与业务建模

一、    业务流程建模

       不同的组织对这一活动的命名不同。它可以被称为业务流程建模或流程建模或流程映射。流程模型是流程中不同活动和步骤的可视化表示，包括流程不同步骤的数据流和输入-输出。它还可以显示哪个组织实体运行该流程。

       业务蓝图设计中的一个重要步骤是设计更好的流程。ERP 实施的价值主要来自于你如何更好地设计流程，而不仅仅是通过使用 ERP 自动执行当前流程。要设计更好的流程，第一步是了解流程今天是如何进行的。一种方法是了解流程，即将其所有步骤、不同的决策点、输入和输出生成下来，流程的每个部分由谁来完成等等。然而，人们经常看到，如果你使用几页纸（对于大型流程，可能会运行到数百页）来编写流程，仍然很难理解流程步骤和依赖关系。更重要的是，如果你正在记录此流程以进行一些流程改进，则需要向多个利益相关者展示当前和未来的流程以做出决策，一个运行到几页的文字文档是一个挑战。

       相反，一个解释流程、流程的几个步骤和流程的输入输出的简单图表可以提供很多帮助。它很容易记录，易于展示，如果人们看到当前流程图和重新设计的流程图并排，他们可以快速可视化改进的领域并做出决定。流程建模软件可以帮助在这方面以图表的方式表示流程。流程建模涵盖了将流程表示为捕获事件之间关系的流程图以及成本和资源限制。

      将业务流程放入软件中存在一个传统的挑战，那就是业务人员和 IT 专家通常不会说同一种语言（虽然业务所有者会谈论销售、库存，但 IT 专家会担心 Java 代码或 C++编程）。业务建模工具试图弥合这一差距。

建模是需要的，因为：

• 这是可视化的，易于理解。它可以快速显示流程下的活动和每个活动下的步骤。它还显示了它们之间的关系和数据流，以及由哪个组织实体执行。

• 易于识别当前流程中的改进领域 - 交接点、可以消除的不必要步骤等

• 对 AS IS 和 TO BE 流程进行快速比较。

• 可以帮助快速从业务场景导航到业务流程，再到活动甚至活动内的步骤。

• 弥合通常不会说同一种语言的 IT 人员和业务用户之间的差距。这是整个企业沟通的共同点。

流程建模/流程映射的一些经验法则

在映射或建模流程时，遵循一些经验法则非常重要，如下所示：

• 每个流程都应该有特定的输入和输出。

• 每个流程都应该跨越多个功能边界。

• 在映射流程时，专注于目标和终点，即流程的目的，而不是步骤，即流程是如何完成的。区分手段（表格、文件和程序）和终点（附加值、交付物）。如果满足流程目标，你总是可以想出不同的流程执行方式。

• 流程应该与客户及其需求相关，无论是直接相关还是作为其他流程的贡献者。

• 仅识别流程的输入和输出——流程存在的原因。

• 流程映射的创建必须由跨职能的高级管理团队来推动。

• 在设计流程时，假设没有组织结构或边界。如果你今天开始，并且必须以最好的方式完成，你会怎么做？这对于 TO BE 流程建模尤其重要。

• 跳出所有限制思考。流程设计就是创新。同样，对于 TO BE 模型来说，这一点也很重要。

AS IS 和 TO BE 建模之间的区别

       没有严格的规定。但是，一般的指导原则是 AS IS 模型需要进行更少的细节建模，而 TO BE 流程需要更高的细节。

AS IS 建模

       目的：流程改进。通常，在进行 AS IS 建模时，公司会忘记练习的最终目的，即流程改进。虽然可能会花费数月或数年的时间来了解流程中每个活动的执行方式、由谁执行、需要多长时间、使用什么表格或报告等细节，但这种练习可能没有太大价值，因为无论如何，该流程将在未来被抛弃. 这是分析瘫痪综合征。在 AS IS 建模期间，需要记住上述基本规则。了解流程存在的原因、流程的目的和流程目标很重要。在这里详细说明步骤并不重要，因为总是可以采用新的步骤来完成流程，重要的是了解流程的目的，因此，在大多数情况下，高级流程模型就可以满足目的。

TO BE 建模

       目的：向业务用户解释新的工作方式、ERP 配置。虽然TO BE建模需要进行足够详细的建模，因为可能会有新的步骤、新的数据流程、新的输入-输出关系、新的角色、新的组织结构来支持该流程和新的衡量流程绩效的措施。信息技术在 TO BE 设计中的使用方式可能与今天不同。所有这些都需要向组织中的所有人解释，以及与以新方式（TO BE 方式）执行此操作相比，他们过去的方式（AS IS 方式）的好处。因此，TO BE 建模需要足够详细地说明流程的每个活动和步骤、输入-输出关系、谁执行等。详细说明也很重要，另一个原因是。这些流程最终需要在 ERP 系统中进行配置。要执行此配置，任何 ERP 都需要步骤级别的详细信息，以便可以将其建模为 ERP 事务。如果建模没有足够的细节，这个目的就无法实现。

二、    业务流程层次结构

       业务流程层次结构是对业务场景、业务流程、活动和步骤进行逻辑分组。业务场景处于最高级别，可以由多个业务流程组成。业务流程是层次结构中的第二级，每个业务流程由一组活动组成，每个活动可以由一组步骤组成。一个示例内容：

1. 供应链管理是一个业务场景。

2. 供应链管理场景可以有多个流程，如订单管理、生产计划、采购到付款等。在本例中，订单管理流程进一步展开。

3. 订单管理流程可以由多个活动组成，例如接单、检查客户的信用价值、定价、交付计划等。在本例中，交付计划活动进一步展开。

4. 交付计划活动可以由多个步骤组成，例如交货日期计算、安排卡车交付、最终确定交付路线等。其中一个步骤“交货日期计算”在示例中显示。

业务流程层次结构在以下方面提供了各种帮助：

1. 它有助于在不同级别查看人员流程。公司的首席执行官或高级领导团队可能对查看场景级别感兴趣，流程负责人可能希望在流程级别查看，而工厂车间操作员或会计人员可能对他需要执行的步骤感兴趣.

2. 根据组织角色，人们可以展开和分析流程。财务人员可能只对财务活动感兴趣，并希望看到详细的步骤。

3. 从场景到流程、活动到步骤都很容易导航

4. 在不同级别定义角色很容易，即谁应该执行特定步骤，谁对活动负责，谁是整体流程所有者，谁为整体场景设定方向。这些角色定义在 ERP 实施期间非常重要，因为你现在知道谁应该做什么，如果事情没有按照计划进行，应该向谁跟进。

三、    业务流程和业务流程建模标准

业务流程定义标准

       流程设计和流程建模中最大的挑战之一是，没有关于你如何定义流程的硬性规定。例如，一家公司的订单履行流程 (OFP) 中包含的活动和步骤可能与另一家公司的订单履行流程 (OFP) 中的活动大不相同。一家公司可能将供应商付款活动作为采购到付款流程的一部分，而另一家公司可能将其作为财务流程的一部分。流程定义标准的缺乏，在试图将一家公司的流程与另一家公司集成时会产生问题，而这在当今由于合并和收购 (M&A) 或公司与其供应商和客户之间的合作等原因已成为常态.

        幸运的是，在过去的二十年里，各种形式的标准开始形成，如企业流程标准、特定流程领域的标准和特定行业流程的标准。虽然在定义流程时你不一定要遵循这些标准，但遵循这些标准总是有好处的，因为它们在全球范围内被广泛接受。这些标准的开发经过了数年的研究，越来越多的 ERP 供应商开始在其应用程序中支持这些标准。一些常见的流程定义标准如下：

企业流程标准-APQC 流程分类框架

       美国最领先的质量机构 APQC 定义了一个流程分类框架，其中所有业务流程都根据七个运营流程和七个管理和支持流程进行定义。这十四个流程中的每一个都详细到五个级别。一个组织可以遵循