一、 业务流程建模
不同的组织对这一活动的命名不同。它可以被称为业务流程建模或流程建模或流程映射。流程模型是流程中不同活动和步骤的可视化表示，包括流程不同步骤的数据流和输入-输出。它还可以显示哪个组织实体运行该流程。
业务蓝图设计中的一个重要步骤是设计更好的流程。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 事务。如果建模没有足够的细节，这个目的就无法实现。
二、 业务流程层次结构
业务流程层次结构是对业务场景、业务流程、活动和步骤进行逻辑分组。业务场景处于最高级别，可以由多个业务流程组成。业务流程是层次结构中的第二级，每个业务流程由一组活动组成，每个活动可以由一组步骤组成。一个示例内容：
供应链管理是一个业务场景。
供应链管理场景可以有多个流程，如订单管理、生产计划、采购到付款等。在本例中，订单管理流程进一步展开。
订单管理流程可以由多个活动组成，例如接单、检查客户的信用价值、定价、交付计划等。在本例中，交付计划活动进一步展开。
交付计划活动可以由多个步骤组成，例如交货日期计算、安排卡车交付、最终确定交付路线等。其中一个步骤“交货日期计算”在示例中显示。
业务流程层次结构在以下方面提供了各种帮助：
它有助于在不同级别查看人员流程。公司的首席执行官或高级领导团队可能对查看场景级别感兴趣，流程负责人可能希望在流程级别查看，而工厂车间操作员或会计人员可能对他需要执行的步骤感兴趣.
根据组织角色，人们可以展开和分析流程。财务人员可能只对财务活动感兴趣，并希望看到详细的步骤。
从场景到流程、活动到步骤都很容易导航
在不同级别定义角色很容易，即谁应该执行特定步骤，谁对活动负责，谁是整体流程所有者，谁为整体场景设定方向。这些角色定义在 ERP 实施期间非常重要，因为你现在知道谁应该做什么，如果事情没有按照计划进行，应该向谁跟进。
三、 业务流程和业务流程建模标准
业务流程定义标准
流程设计和流程建模中最大的挑战之一是，没有关于你如何定义流程的硬性规定。例如，一家公司的订单履行流程 (OFP) 中包含的活动和步骤可能与另一家公司的订单履行流程 (OFP) 中的活动大不相同。一家公司可能将供应商付款活动作为采购到付款流程的一部分，而另一家公司可能将其作为财务流程的一部分。流程定义标准的缺乏，在试图将一家公司的流程与另一家公司集成时会产生问题，而这在当今由于合并和收购 (M&A) 或公司与其供应商和客户之间的合作等原因已成为常态.
幸运的是，在过去的二十年里，各种形式的标准开始形成，如企业流程标准、特定流程领域的标准和特定行业流程的标准。虽然在定义流程时你不一定要遵循这些标准，但遵循这些标准总是有好处的，因为它们在全球范围内被广泛接受。这些标准的开发经过了数年的研究，越来越多的 ERP 供应商开始在其应用程序中支持这些标准。一些常见的流程定义标准如下：
企业流程标准-APQC 流程分类框架
美国最领先的质量机构 APQC 定义了一个流程分类框架，其中所有业务流程都根据七个运营流程和七个管理和支持流程进行定义。这十四个流程中的每一个都详细到五个级别。一个组织可以遵循这些流程定义标准，因为它几乎涵盖了组织的每一个流程，并提供了足够的细节。今天的大多数领先 ERP 都支持 APQP 用于流程定义。（注意：APQC也在不断更新中）
供应链流程标准-供应链运营参考模型 (SCOR)
SCOR 是一个由全球 900 多家领先公司的供应链专业人士组成的机构。该机构将所有供应链流程分为五类，即计划、采购、制造、交付和退货。每一个都在更低的层次上进一步细分。SCOR 有标准的供应链流程建模方式，还提供了一套衡量供应链流程绩效的指标。SCOR 是一种广泛流行的流程标准，市场上所有领先的供应链应用程序都支持 SCOR 标准。
行业流程标准
一些行业也在提出自己的流程定义标准。例如，零售业有一个名为 ECR（高效消费者响应）的机构，该机构正在为品类管理、分类、商品管理等特定的零售流程制定标准。
协作流程标准
像 VICS（自愿行业商业标准）这样的组织正在为公司内部的协作流程定义标准，即VMI（供应商管理库存）和 CPFR（协同计划、预测和补货）等流程的标准。
业务流程建模标准
随着流程定义标准的不断发展，流程建模也有了标准。一些广泛接受的流程建模标准列如事件驱动的流程链 (EPC)、业务流程建模符号 (BPMN)、统一建模语言 (UML)
四、 流程建模软件
软件广泛用于流程建模。即使对于中型公司，流程的数量也可能在 40-100 个之间，活动的数量可能上升到几百个，步骤的数量可能上升到几千个。对于如此大量的对象，仅绘制视觉模型就非常困难。此外，复杂的建模，例如添加资源、数据和组织，几乎是不可能完成的，而无需借助软件工具的帮助。软件工具还可以帮助放大流程的一部分、进行高级模拟和其他分析。流程建模软件可分为两类——基本或简单的流程建模工具和高级建模工具。微软 Visio 属于第一类，即基本流程建模工具。IDS Sheer 的 ARIS 和 IBM 的 Websphere Busines Modeler 等工具在高级业务建模工具中很受欢迎。
五、业务建模
业务建模是对企业业务的一种可视化表示，将其视为一个大型系统，显示不同的子系统、它们支持的流程以及它们之间的相互联系，并显示不同子系统之间如何进行数据流。
很少有 ERP 项目是绿地项目，即公司没有任何系统，因此他们要去实施 ERP。在大多数情况下，公司使用了几个遗留系统，每个系统都支持一组业务流程，通过 ERP 实施，其中一些被替换。会有一些应用程序仍然保留，例如非常专业的公司特定流程，ERP 不支持。在开始实施 ERP 之前，了解当前情况并可视化未来的情况非常重要。
业务模型直观地显示了未来的应用程序格局，ERP 将负责哪些流程，哪些流程将保留遗留应用程序，以及 ERP 的不同模块和遗留应用程序之间将如何进行数据流。
业务建模可以在任何详细级别上完成。如果做得足够详细，它还可以显示每个流程如何通过不同的应用程序（ERP 的不同模块和遗留应用程序）运行，即流程的哪个步骤在哪个应用程序中完成，它需要什么输入数据以及它创建了什么输出数据，如何将此输出提供给下一个流程等。它还显示了当前由组织中的哪个个人运行该流程，以及未来应该由谁运行该流程。
业务模型需要根据公司的业务战略、长期目标和愿景来完成。例如，如果一家公司希望通过互联网销售产品或希望通过 RFID 跟踪产品的供应链，则这需要成为业务模型的一部分。公司未来的业务模型将直观地表示哪些应用程序将与在线订单预订系统对话，哪些应用程序需要启用 Web，这些前端应用程序（即 Web 订购）和后端应用程序（例如，会计）之间的数据将如何流动。
六、 集成数据建模
如前所述，ERP 是一个高度集成的系统，所有应用程序都位于一个数据库上。ERP 的实施可以替换公司的几个旧遗留应用程序和旧数据库。在实施 ERP 时是否需要进行数据建模？在一定程度上，如果你使用标准的ERP，答案是否定的。例如，如果你进行货物接收，它会自动更新库存、贷记供应商账户、更新库存估价，并且 ERP 的集成数据库会自动处理这些。
但是，如果你进行任何开发，即 ERP 的标准流程不符合你的要求，并且你需要进行单独的编程来满足特定客户的特定业务流程要求，那么需要为客户特定流程的那一部分开发数据模型。例如，如果你希望对客户信用检查有特定的逻辑，并且需要在 ERP 系统中进行一些开发，那么了解 ERP 相应标准功能（即 ERP 中的标准信用检查）的数据模型就很重要，它更新了哪些表，数据流程如何发生，输入和输出是什么，等等。了解这一点很重要，这样你就知道开发会影响哪些表，哪些相关的集成点会受到影响，等等。
ERP 数据模型可能非常复杂，任何更改或添加都需要非常小心，因为一个表中的条目可能会影响几个相关联的表，有时很难立即估计其影响。
