1.3 流程识别

业务流程管理首先要回答的问题是：组织里哪些工作可以被抽象为一个流程？每个流程解决了企业的什么问题，它的内容、范围和边界是什么？这些流程之间的关系是什么？回答这些问题的工作称为“流程识别”。流程识别的产出是流程清单，也称为流程架构，以此为基础，再详细逐一描述每个流程具体长什么样，就启动了流程梳理（process mapping）或流程建模。流程识别是流程全生命周期中各项业务流程管理工作的起点。

每家公司的运营都是一系列“业务流程”的集合，流程支持公司新产品的创造，促进服务交付，执行公司规章制度，维护合规，确保公司在任何时候都朝着总体目标前进。将流程作为工具来进行企业管理有多种方式，有些是局部性的，例如，某个精益六西格玛项目是将企业局部业务的“流程”提炼出来，用来分析并改进措施；有些则是全局性的，从整体上建立公司或者某个业务领域的总体流程视图，并且由粗及细地分解到最小颗粒度的流程，用管理咨询顾问的说法，就是用“相互独立，完全穷尽”（MECE）的形式来识别所有存在的流程。

我早年做ERP系统实施时，在项目启动后首先就需要做流程梳理，对现有流程逐一分析并制定未来流程，即制定“业务蓝图”。在这个过程中，我在项目上经常遇到来自客户的挑战是：究竟是先有流程，还是先有流程清单？

如果是先有流程清单，即根据过去的经验拿出一个流程清单来确定范围，再去逐个细化流程的话，会被客户挑战流程清单是否存在遗漏流程的情况；SAP软件标准实施方法论——ASAP方法，提供了一个参照性的四级业务流程清单，这个通用的流程清单比较理论化，而每个客户的实际业务情况千差万别，用这个清单很难完全覆盖客户的业务细节。

而如果是先有流程，即按照职能大模块（如财务、生产、销售、采购）去调研客户业务，发现一个业务问题就设计一个流程，并匹配软件系统的功能点的话，这种头痛医头、脚痛医脚的做法又会被客户认为流程设计缺乏体系性、完整性。我曾经遇到过某个民营企业老板，挑战项目团队提交的业务蓝图是否完整覆盖了ERP软件可以覆盖的所有流程，甚至要求我把SAP ERP系统打开，逐个功能演示给他看，生怕花巨资购买的软件把什么功能给漏掉了。

先有流程还是先有流程清单，就像一个“先有鸡还是先有蛋”的难题。做事一定要方法正确，如果把企业比喻为地理意义上的世界，流程识别就是看清究竟有多少条路，而找路有两种方法：一种方法就像是我们看百度地图，先总体俯瞰世界全貌，拉近到亚洲，拉近到中国，拉近到上海，再拉近到徐家汇，最后拉近到徐家汇的某一条街道，这样看清了所有道路，就得到了流程清单；另一种方法就像是人们在大航海时代去探索世界，本来世界是一片“黑暗”，你开辟一段航路，就“点亮”一片区域。企业内存在很多流程，它们是怎么被识别、被定义并被组织起来的呢？

首先，我们要形成对流程定义的前提假设，即我们做流程是为了解决什么业务问题，是供应链计划问题、生产问题还是财务管理问题，沿着这个问题来定义流程的范围。识别、定义流程有三种探索手段，这些手段在实际工作中会组合使用。

●循证式探索：我们可以找到各种各样的证据，研究一个流程是如何存在、如何运作的。这些证据一是各种政策、制度、单据、手册、作业指导、职位说明、组织结构图、系统操作说明书等业务文档；二是通过行为观察，例如以扮演顾客来体验客户服务流程的主动观测方法，或者以旁观者身份来研究从采购请求到采购支付等端到端流程的被动观测方法，来直接跟踪一个流程；三是针对信息系统的流程分析，对只涉及一个或者跨越多个信息系统的自动处理流程，例如保险公司的保险理赔流程，或公用事业公司跨越ERP和CRM系统的“表计到开账”流程，手工或者智能化地从信息系统的数据中提取出流程信息。后面我们还将详细讨论“流程挖掘”这种基于人工智能算法的流程发现的技术手段。

●访谈式探索：对流程相关的课题专家或流程用户开展访谈，询问组织内某个业务是如何运行的，从而一步步地发现流程。由于个体的知识和视角可能是局部性的，访谈者往往需要对多个被访谈者进行交叉验证，形成流程的完整拼图。可以从流程起点，即触发流程的事件开始顺流而下探索，也可以从流程终点，即流程结束的事件或状态开始逆流而上探索。例如探索订单到交付的流程，可以从请求创建订单开始，也可以从客户收到订单货物开始。

●研讨会探索：研讨会比较适合于已经有了一个初步的或宏观的流程框架或者流程模型，但还需要对流程进行细化讨论以探索细颗粒度流程或者对流程模型进行修正的情况，通常基于前面两种探索方式的产出。让研讨会参与者充分参与讨论的一种技巧是“牛皮纸练习”（或者叫“牛皮纸流程梳理”）。引导员在墙上贴上一大张牛皮纸，其上横向是某个端到端业务的范围，即某个业务的价值流，纵向是不同的部门或岗位，然后要求参与者使用各种颜色的便利贴来共同构建流程的概略草图，不同颜色的便利贴分别代表不同的活动/任务/事件、处理时间、当前问题痛点、衡量指标等。引导员将开始事件的名称写在便利贴上，并将其张贴在牛皮纸上的某个位置，然后问参与者接下来会发生什么，参与者会提到一个或多个可能的关键活动，并将这些活动以及处理时间、问题痛点等相关信息写在不同颜色的便利贴上，再贴在牛皮纸上，从左到右或从上到下梳理好活动顺序。这样做的目的只是探索流程，并不是进行精确的流程建模，因此无须对于流程规则、分支等画出连接线条。例如，对于某个关键活动可能有多个参与者提出更细节的活动，可能就会找到子流程嵌套关系。为了保证研讨会的效率，引导员必须把握参与者提出的活动的颗粒度，不宜太粗，也不宜太细。我曾经操作过的一个案例如图1-4所示。

其次，对于流程在组织内存在的形式以及如何被串接起来，有两种观点：其一，认为若干活动链条是相对独立的，每条链条都是为了完成一个特定的业务目的，叫“一个流程”，企业存在很多条流程，所有的流程都可以按照树状结构的分层逻辑被归类及组织；其二，认为企业所有流程都是相互连接的网状结构，就像世界上的路网一样，一个流程是这个网状结构中的一个局部。我曾经在一家企业见到他们的流程工程师用流程建模工具画了一张纵横交错的流程网络大图，并用工程绘图仪印出来贴在墙上，覆盖了一整面墙，甚是壮观。

从大多数企业的实践来看，第一种观点更常见一些。

尽管大多数公司都有流程管理的归口职能部门，但是很少有公司有足够的资源和精力识别出企业的所有流程，严格地分析和重新设计每个流程，为每个流程部署自动化技术，并持续地监控每个流程的绩效。企业每项管理活动都是有成本的，业务流程管理也不例外，对每个流程投入的管理成本如何产生管理效益，是管理者应该关注的问题。我经常见到企业招标全面流程管理项目，不过我不赞成企业搞“煮大海”式的业务流程梳理，那些试图事无巨细、360度无死角地梳理出企业所有流程的努力是很难见效的，我会建议企业的流程管理活动在特定的解决业务问题的目标和预设的前提下，或者在一个有明确范围和目标的流程管理项目的背景下，去开展具体的流程识别。

企业识别流程并形成流程清单的方法有三种：自上而下、自下而上和参考模型（见图1-5）。

1.自上而下

从组织的业务战略和商业模式入手，识别有哪些业务活动和业务能力，相应地解析出流程类或流程组，再从中分解出流程。定义包含若干流程的流程组通常有两种思路：一是用价值链里的职能域和业务域来构建流程组，二是用端到端流程来识别企业各种从需求到交付服务的领域。有些流程方法论认为这两种思路也可以结合使用。

价值链分析模型是由管理学家迈克尔·波特提出的，他在1985年的著作《竞争优势》中首次介绍了这个概念。该模型旨在帮助企业分析其内部活动，识别其核心竞争力，找到降低成本、提高效率和创造价值的机会。它是最广为接受的流程归类模型，最初区分了两类流程：核心流程（称为主要活动）和支持流程（支持活动）。后来又增加了第三个流程类别：管理流程。构成价值链分析模型的每个概念性单位都是一个企业职能领域，如财务、计划、生产、营销、销售、直接采购、间接采购等。

●核心流程涵盖了公司的基本价值创造，即生产客户所支付的商品和服务，包括设计和开发、制造、营销和销售、交付、售后以及直接采购（即制造产品或提供服务所需的采购，属于生产体系的一部分）。

●支持流程是支持那些核心流程执行的流程，包括间接采购（即行政办公、业务支持等方面的采购）、人力资源管理、信息技术管理、品牌公关、财务会计管理和法律服务等。

●管理流程为核心流程和支持流程提供方向、规则和实践指导，包括战略规划、计划预算、合规和风险管理，以及投资者、供应商和合作伙伴管理等。

“端到端流程”这个词本来是指客户需求从提出到得到满足的过程。实际上价值链的核心流程就是一个端到端流程，后来发展为泛指企业内任何跨职能的需求从提出到得到满足的过程，常见的企业端到端流程如下。

●供应链相关：订单到交付（order to delivery）或者订单到现金（order to cash）。

●采购相关：采购到支付（procurement to payment）。

●研发相关：创意到产品（ideation to product）。

●销售相关：商机到订单（opportunity to order）或者线索到客户（leads to customer）。

●客户服务相关：问题到解决（issue to resolution）。

●人力资源管理相关：雇用到退休（hire to retire）。

●财务会计相关：记录到报表（record to report）。

●战略管理相关：战略设计到执行（strategy design to execution）。

价值链和端到端流程有一定的概念交叉，在企业流程的顶层规划中，宏观流程域设置究竟是按价值链的职能域还是按端到端的流程域，似乎无法兼顾，因此常带来困扰。例如，你不能既设计一个“供应链管理”，又设计一个“订单到交付”，这两个概念是打架的。也有一些做法是把两种方式混在一起，因为“流程”本身的定义就是从一个开始事件到一个结束事件，所以从概念上说，任何流程都可以用“端到端”的方式来命名，例如一家项目型IT服务公司，假定其核心流程分为销售、交付两大流程域（流程类），流程域之下再细分子域（流程组），既可以用职能域方式来命名，也可以用流程域方式来命名（见表1-2）。

2.自下而上

过去企业在一些具体业务活动中会对流程进行梳理，这些活动包括质量管理、工作分析以及其他管理活动。通常这些流程工作是局部性的，缺乏公司体系性视角，也可能缺乏公司级的流程描述标准的支持，流程文档的规范性不高。例如，有些公司在贯彻ISO 9000标准、推行精益管理、应用六西格玛管理法的过程中，积累了不少流程资产，这些流程资产大多比较碎片化。需要对它们进行归集、去重、提炼、抽象，形成通用性更高的流程。

在全面质量管理（TQM）和六西格玛改进中常用的SIPOC模型也是一种流程识别模型，它的原理是将企业模型抽象为五个环节，而流程居于中心。

●Supplier（供应商）：提供流程所需的资源或材料。

●Input（输入）：流程所接收的供应商提供的输入。

●Process（流程）：描述了从输入到输出的具体工作步骤和操作程序。

●Output（输出）：流程生成的产品、服务或结果。

●Customer（客户）：接收并耗用流程产生的输出的最终用户或下游流程。

SIPOC模型的流程分析目标是通过发现问题，找到瓶颈，改善工作，清除无价值的工作任务并缩短周期，提升生产效率与企业竞争力。尽管SIPOC模型将自己定位于宏观流程定义，但如果从流程管理的角度来看，它实际上还是一种自下而上的分析方法。

3.参考模型

一些行业性机构、流程研究机构、套装企业管理软件提供了具备业务含义的流程清单，例如APQC PCF、SCC SCOR、ITIL等。

●APQC提出的PCF（Process Classification Framework，企业流程分类框架）是最有影响力的一个企业流程参考清单，它不仅有跨行业的通用版，而且有许多行业专用的流程清单，还根据各个行业的特点对通用版进行了简化或者细化，例如制造在通用版的制造流程组里有4个流程，而在航空和国防行业版里则有16个流程。这些行业流程清单都是APQC的行业代表性机构开发的或者它们跟有关行业标准协会合作开发的。

●SCOR（供应链运作参考）模型是一个广泛应用的、通用的、跨行业的供应链管理标准体系，由国际供应链理事会开发，其目的是促进企业和跨企业的供应链管理流程的协调、优化和改进。

●ITIL（Information Technology Infrastructure Library，信息技术基础设施资料库）是源于英国政府的一套企业级IT服务管理框架，它基于IT服务的服务价值体系、价值链和价值流的结构建立了一套IT运营管理流程，涵盖了从需求到交付服务的全流程，包括项目管理、关系管理、风险管理等管理流程，以及持续交付、持续部署等技术流程。

●一些大型企业管理软件公司（例如SAP）或者咨询公司（例如IBM、埃森哲等）为了支持自己的产品或服务走向市场，便于客户理解并使用产品，也都提出了基于自己产品或服务的流程框架。

●有些行业组织提供的参考模型虽然不是流程框架，可能以“企业能力模型”“业务架构”等命名，例如在电信业务运营领域，电信管理论坛（Telecom Management Forum，TMF）提供的电信运营图（Telecom Operation Map，TOM），全球领先银行、技术提供商和学者组成的银行业架构网络（Banking Industry Architecture Network，BIAN）提供的银行企业架构参考模型等，但这些模型也包含了流程参考模型，以及相应的信息系统和数据模型。

企业在选用参考模型时，可以从流程框架的涵盖范围、完整性、模块化程度、表达准确性、一致性、分级结构的合理性、总体可用性、自身相关性、市场普及性和成熟度等角度综合考虑，选择适合自身实践的流程框架。

图1-6是某大型集团（有三个业务不同的产品事业部）综合了APQC的PCF和端到端方法形成的企业流程框架（EPF）。

识别流程并形成流程清单除了上述三种方法，还可以利用企业架构方法来推导出流程架构。

流程是企业建立业务模型的一种方式或者是构成企业业务模型的一个部分。当前企业业务建模的主要方式称为“企业架构”（enterprise architecture），它旨在详细描述企业业务，并且将企业业务要素（包括战略、组织、活动、能力、流程等）与各种信息技术资源（包括IT应用、数据、基础设施等）整合进一个集成模型。企业架构将整个企业中优化流程的努力（包括手动的和自动的）——这些流程往往是零落、分散的——转化为一个集成的体系，使信息技术能对业务变化做出持续响应，并支持业务战略的交付。企业架构和业务流程管理存在着共同的发展渊源，今天很多建设了完善的企业架构管理的大型组织，在治理模式上都会将业务流程管理作为企业架构管理的一个组成部分。

在管理界和IT界有多种企业架构方法体系，其中使用最为广泛的是由企业信息技术国际标准化组织The Open Group提出的TOGAF（The Open Group Architecture Framework，开放群组架构框架），它分为四个架构域，涉及从业务设计到技术实现。

●业务架构定义了业务战略、治理模式、组织架构和关键业务流程，它描述了企业的组织、人员、职能和活动的构成关系。

●数据架构描述了一个组织的逻辑和物理数据资产，以及数据管理资源的结构。

●应用架构提供包含待部署的独立应用及其之间的交互作用，以及应用与组织的主要业务流程间的匹配关系的蓝图。

●技术架构描述了支持业务、数据和应用程序服务部署所需的数字化技术架构、逻辑软件和硬件基础设施，阐述了其功能、技术特性和标准。

企业的流程清单和流程图是业务架构的输出成果，而数据架构、应用架构和技术架构通常合称为“技术架构”。

在业务架构层面，TOGAF看起来很繁复，其架构元模型涉及几十种业务架构和技术架构的对象，对象之间的逻辑关系严密，概念表述比较拗口，例如描述对象的制品有目录（catalog）、指标（metrics）、图表（diagram）等多种形式，非专业人士很难看懂。为便于理解，我基于TOGAF的业务架构，将从业务战略推导出流程图的思路简单提炼为如图1-7所示。

●业务战略：业务战略涉及公司（即一个商业组织）的收入来源、利润来源、价值主张、目标客户、核心资源、渠道通路、竞争屏障等；组织可以用商业模式画布、战略地图等可视化方式来描述业务战略。

●组织架构：业务战略决定了一个公司的组织架构和管控模式，即各个组织单元的职能划分、权责分配和汇报关系。大型组织的组织单元可能涉及区域、客户类别、产品类别等多个维度的组织划分以及矩阵交叉关系，在不同的组织维度上形成业务单元。在运营上，需要厘清哪些业务是公司内跨业务单元的共性业务，需要标准化流程管理，哪些业务在基于共性的基础上可以集中处理，由“共享服务中心”来交付内部服务，例如间接采购、财务、人力资源；哪些业务应该根据业务单元的实际情况，制定个性化的流程。组织架构和管控模式是流程架构和流程设计的重要输入。

●价值流：价值流是指产品或服务从需求产生到价值实现的所有活动和流程，以及在这些活动和过程中创造和交付价值的方式；价值流图（value stream map）是对价值流的可视化呈现。价值流可以用来描述公司顶层业务设计，也可以用来描述公司里某个具体业务领域从工作目标到工作结果的全过程，“价值流”和前文的“端到端流程”概念类似。价值流来源于精益管理方法，可识别整个流程中的价值活动和浪费活动，有助于组织集中精力改善那些真正为客户创造价值的部分。把价值流放到业务架构中和组织架构平齐，就是在从横向集成的视角来识别跨部门的协同合作，有助于打破信息孤岛，识别组织优化和效率提升的机会。

●业务能力图：“业务流程”和“业务能力”是两个意思接近，很容易令业务分析人员混淆的概念。能力是指企业可以拥有或交换的某种优势，用以达到特定的业务目的；能力图（也可称为能力地图或者能力图谱）是对组织所有能力的图形化展示，IBM CBM是业务能力图的典型代表，图1-8是IBM CBM机械行业业务能力图示意。

业务能力提供了业务流程执行的目标、范围和可能性，所以，能力图是识别流程的前导性模型。能力框架和流程一样也可以分类（横向按照价值链的环节分，纵向按照战略关联性分，例如指挥性、控制性、执行性）和分级（由粗到细，分解为一级、二级、三级等）（见图1-9）。业务能力是怎么定义的呢？理论上有各种定义方式，有人认为是基于流程的抽象，即对细颗粒度业务流程的抽象，以找到可复用的流程能力，还有人认为是基于企业业务数据的抽象，即用信息技术手段对业务对象进行操作，定位对数据操作的能力复用。实际在能力梳理的架构设计工作中，存在基于流程、基于数据或两者结合的方式。

●流程架构：流程是实现业务能力的一系列业务活动、触发事件、控制机制的集合。如果咬文嚼字地来定义，业务能力用名词表示，流程则用动词加名词表示，例如：“订单处理”是一个能力，“审核订单”“下发订单”则是执行这个能力的流程。一个组织的所有流程全部集中起来，按照一定的逻辑规则来分级分类，所构成的结构化清单就形成了“流程架构”或“流程清单”。由于业务能力和流程二者的概念实在过于接近，也有学者认为二者有一一对应的关系，“能力”就是“能交付流程结果的力”，假如“制作面条”是一个流程的话，“交付面条”就是一个业务能力。业务能力和流程的关系并无一致性定论，各位在实践中可以自定分析方法。

●流程图：流程图是对被列入流程清单的每一个流程的可视化展现，企业的能力图是一个无始无终，能力之间弱关联的网状拓扑结构，而每个流程的流程图则是一个有起点和终点，活动之间强关联的线性拓扑结构。将构成一个流程图的每个对象实体，例如事件、活动、组织、文档、产品、逻辑规则、连接关系等用数字化方式来实现，就形成了流程的数字化模型。对流程数字化模型进行管理的信息系统叫业务流程管理系统（BPMS），后文会详述。而一个或多个流程里的活动还可以对应到企业应用软件里特定的功能，或称服务，这些服务通过流程被组织起来，就构成了流程自动化运行。

尽管我对TOGAF进行了简化，但是这个自上而下推导出组织内存在哪些流程的逻辑还是相当复杂的。在我过去的咨询工作中，很少有机会能够用这种方法来制定流程清单，辨析企业实际或者应该存在哪些流程。对照参考模板进行修改优化通常是更便捷的方式。在其他企业管理领域里有类似现象，例如在人力资源管理体系中，企业存在哪些职位和职族是怎么得出来的？学校里的HR管理教材会说职位是通过对员工的工作任务、动作分析进行观察、访谈从而提炼、总结、抽象出来的，这叫“职位分析”，跟前文提到的推导流程架构的方法非常类似。但是现实中，我很少见到职位是这么得出来的，这种说法太过于学术化了——大多数企业的职位定义都是以类似行业或企业的职位和职位体系的定义为模板稍加修改得来的。