简介：这份PPT面向企业流程变革与信息化规划从业者，聚焦美的集团632项目的端到端流程框架设计，适合需要理解大型集团如何整合流程、主数据与IT系统的中高级读者参考。压缩包内仅含1个pptx文件，约2.76MB，以图文页形式呈现项目整体思路与咨询设计成果。内容围绕六大运营系统与三大管理平台展开，涵盖EPF企业流程框架的L1至L4分层设计，包括流程要素明确、流程串接、流程打开与IT落地实现，并给出主流程加主数据加632系统的整体架构，以及2013至2015年系统归并、模板试点、推广完善与复制推广的实施路径和大事记节点。已有107人学习，可帮助读者掌握集团级流程框架的搭建逻辑、主数据统一管理与多事业部推广节奏，为流程变革方案编写与项目排期提供可借鉴的模板与思路。
1. 流程变革：为什么“先定流程再上系统”不是口号，而是632项目能落地的根
大多数企业上 ERP 的顺序是反的：先选型、再实施、最后让业务去适配系统。结果就是流程被系统“锁死”，改一个审批节点要走三个月变更单。632 项目最反直觉的地方在于，它把顺序彻底倒过来——先用 EPF（企业流程框架）把 L1 到 L4 的流程定义清楚，再让 PLM、APS、SRM、ERP、MES、CRM 这六大运营系统去“承接”流程，而不是“发明”流程。这套流程变革思路解决的核心问题是：多事业部、多地域运作的公司，如何在不牺牲各业务单元灵活性的前提下，拿到集团级的集约效益。搞懂它，你就明白为什么很多企业的数字化投入打了水漂——不是系统不好，是流程框架没搭对，系统之间没有共同的“语言”。
2. EPF 流程框架：L1 到 L4 的分层到底在分什么
2.1 流程模块与具体流程：一级流程为什么“同行业基本一致”
632 项目对流程层级做了一个非常关键的澄清：流程模块和具体流程定义是两回事。一级流程是业务流程主干，比如“市场到订单”“研发”，这类东西在同行业内基本一致，因为它描述的是价值链的总体顺序。二级流程才开始分化——同样是“渠道管理”，在渠道分销业务场景下需要部署，在直销业务场景下根本不适用。这就是为什么流程框架必须先于系统选型：系统是按二级、三级流程的能力需求来选的，而不是反过来。
常见的实现思路是，L1 定义价值链主干，L2 定义运营模式层面的业务子流程，L3/L4 定义实现运营模式所需的业务能力和业务活动。这个分层的关键在于：L1 和 L2 是“业务逻辑”层面的，与 IT 系统选用不相关；到了 L3/L4 才结合特定系统描述业务与系统的交互。很多企业翻车就翻在这里——把 L3 的活动直接当成 L1 来管，导致流程框架失去了结构化蓝图的意义，变成了一堆操作手册的堆砌。
2.2 自上而下建框架、自下而上做匹配：两种建模方法的分工
项目里明确对比了 Top-down 和 Bottom-up 两种方法。Top-down 先构建流程全貌，层层分解到细节，优点是能建立体系全貌、避免流程重复和无法连接，缺点是需要有清晰的 L0 框架作为输入，且对原有流程体系改动大。Bottom-up 从细节流程入手，挑选合并生成上一级流程，优点是建立基于实际的流程应用、最大限度保证共享复用，缺点是通过底层合并非常困难，很难形成完整体系。
632 的做法是“从上而下建立流程高阶框架，自下而上进行流程匹配”。这个组合不是折中，而是有明确分工的：高阶框架保证完整性和可检验性，底层匹配保证业务场景的选择不脱离实际。我一般会这么理解——Top-down 负责“不漏”，Bottom-up 负责“不虚”。只做 Top-down，框架漂亮但落地时发现业务场景对不上；只做 Bottom-up，局部最优但拼不出端到端。
2.3 流程框架的四个检验标准：业务覆盖、结构严谨、反映逻辑、体现差异
一个好的流程框架要满足四个条件：业务覆盖全面（覆盖集团/事业部不同层次、价值链与管控职能不同领域）、体系结构严谨（流程模块之间有必要的层级与逻辑关系，全覆盖且没有交集）、反映业务逻辑（价值链总体顺序、运营领域内的生命周期、业务开展的逻辑方法）、体现业务差异（不同业务场景模式下需要不同的业务能力/流程模块）。
第三条和第四条是最容易被忽视的。反映业务逻辑意味着流程框架不是组织架构图的翻版，而是业务开展方式的抽象；体现业务差异意味着框架必须能容纳 B2C 渠道分销和 B2B 直销这两种截然不同的模式，而不是强行统一。这也是流程变革里最血泪的一课：标准化和差异化的边界，必须在框架层面就划清楚，不能等到推广阶段再吵。
3. 流程串接与打开：端到端协同为什么是流程变革的硬骨头
3.1 从“部门流程”到“端到端流程”：供需平衡协调这类跨职能场景
项目对外部经验的总结很直白：多事业部地域运营公司的管理维度包括业务价值链流程提升、管控职能流程提升、标准化、集约化。现有运营基础里，价值链业务流程在部分较具规模事业部有相对成熟定义、有系统支撑，但跨职能流程端到端协同尚不完善，比如供需平衡的跨职能协作。职能管控流程在集团层面已形成一定规范，但纵向管控能力弱化。
这就是流程串接要解决的问题：把“销售预测—需求计划—生产排程—采购寻源”这条链上的断点接起来。常见的实现思路是，先识别端到端流程的关键短板领域（渠道收入确认、供需平衡协调、统一分层报表），再比照业界最佳实践逐步提升。注意这里的关键词是“串接”而不是“打通”——串接强调的是流程要素之间的逻辑关系和数据流转，打通只是系统接口连通。两者差了一个数量级的工作量。
3.2 流程打开：L4 活动级拆解与 IT 落地的衔接点
流程打开是把 L3 的业务能力拆到 L4 的活动级，描述业务与 IT 系统的交互过程/工作流。这一步通常需要结合套装软件的选择，基于标准流程定制、修改。项目里举的例子很典型：渠道分销商信息更新工作流，编辑录入新的渠道分销商信息操作手册。
这里有个容易被忽略的设计取舍：L4 的活动描述必须与 IT 系统的交互过程对齐，但又不能变成纯粹的系统操作步骤。前者是流程资产，后者是用户手册。632 的处理方式是把 L4 定位为“结合特定 IT 系统的业务与系统交互过程”，而把“用户在 IT 系统中的具体操作步骤”单独列为详细规范层。这个分层的好处是，系统升级时只需要改详细规范层，流程资产层保持稳定。
3.3 流程要素：主数据为什么必须和流程框架同步设计
项目把主数据管理（MDM）定义为支持企业核心业务、衡量企业实体绩效而需要建立和维护的企业级范围数据信息管理，主要包括产品、物料、客户、供应商、财务等主数据标准与管理机制。632 项目的主流程、主数据、632 系统是三位一体的——主数据不是流程的附属品，而是流程串接的前提。
举个具体的：如果物料主数据在各事业部编码规则不一致，“采购寻源到生产制造”这条端到端流程在系统里根本串不起来，因为同一个物料在不同系统里是两个东西。所以项目在 2013 年 9 月完成集团六大类主数据建设，这个时间点卡在流程框架推广之前，不是随意排的。流程变革里主数据先行，是一条用无数返工换来的经验。
4. 632 系统架构：六大运营系统与三大管理平台怎么承接流程
4.1 六大运营系统的分工边界：PLM、APS、SRM、ERP、MES、CRM 各管哪一段
632 系统的结构是六大核心业务运营系统支持端到端的核心价值链，加上三大管理支持平台提高集团管控能力。六大运营系统对应价值链的不同环节：PLM 管产品研发（市场分析、产品规划、产品研发、平台研发、技术研究），APS 管计划（需求计划、供应链计划、生产排程），SRM 管采购（寻源、供应商管理），ERP 管制造与资源（生产管理、质量管理），MES 管制造执行，CRM 管销售与服务（销售目标、销售预测、渠道管理、售后服务、客户满意度）。
这个分工的关键在于边界清晰：APS 做排程、MES 做执行，两者不能混；SRM 管供应商关系、ERP 管采购订单执行，职责不能重叠。常见的翻车场景是 APS 和 MES 的功能边界在实施时被模糊掉，导致排程结果和生产实绩对不上，计划员和车间各说各话。632 在框架阶段就把这个边界定死，系统实施时才有据可依。
4.2 三大管理平台的管控逻辑：FMS、HRMS、BI 如何支撑分权模式
三大管理平台是财务管理（FMS）、人力资源管理（HRMS）、决策支持（BI）。项目的定位很明确：财务一体化深化建设，提供更多增值服务和决策分析支持；战略型人才布局，推进国际化人才和高级管理人才的管理；建立集团级风险管控机制，支持内控管理，建立经营分析系统、仪表盘。
这里的设计动机值得细看：集团分权模式下，管控不能靠收权，只能靠“看得见”。FMS 做财务一体化是为了让集团能看到各事业部的真实经营状况，HRMS 做人才布局是为了在分权下保持关键岗位的统一标准，BI 做经营透视是为了让决策层有统一的数据口径。三大平台本质上是分权模式的“后悔药”——平时不干预，但随时能看清。
4.3 两大技术平台：MIP 统一门户与 MDP 集成开发平台的粘合作用
MIP（统一门户平台）和 MDP（集成开发平台）是技术底座。MIP 解决的是“入口统一”问题——六大系统加三大平台，用户不可能记九个地址；MDP 解决的是“集成统一”问题——系统之间的数据流转和接口开发需要统一的开发平台，否则每接一个系统就多一套集成方式。
这两个平台在流程框架里的位置很微妙：它们不直接承载业务流程，但决定了流程串接的技术可行性。如果 MIP 和 MDP 没建好，前面 L1 到 L4 的流程设计得再漂亮，落地时也会变成九个孤岛。所以项目把两大技术平台列为 632 系统的一部分，而不是附属设施，这个定位是对的。
5. 实施策略与避坑：分批推广、系统归并背后的现实约束
5.1 三阶段实施路径：系统归并、模板试点、复制推广的时间账
632 项目的整体实施策略分三个阶段：系统归并（简单化、去差异化，通过归并系统复制内部最佳流程和系统，提升部分单位 IT 应用水平，为统一流程管理奠定基础）；企业模板试点（建立集团级端到端流程、主数据管理机制、标准目标与实施路径，632 集团级系统规划、试点实施，建立全球模板）；企业模板推广完善（各单位全球模板推广、不断完善）。
时间线是 2013 到 2015 年，13 个大项目实施。大事记显示：2012 年 9 月到 2013 年 3 月是项目准备阶段，2013 年 4 月到 12 月是主流程、主数据建设阶段，2014 年 1 月到 2015 年 7 月是 IT 系统试点建设阶段，2015 年 7 月到 2016 年 12 月是 IT 系统复制推广阶段。以半年为周期、按 3 到 4 个事业部为批次进行复制实施。
这个节奏安排的核心约束是：流程框架推广和系统上线必须错开，不能同步推。流程框架先推广到非试点事业部（2014 年 12 月完成），系统上线后跟进（2015 年 1 月家用空调事业部系统上线，2015 年 7 月厨电事业部系统上线）。如果流程和系统同时推，业务部门会分不清是流程不合理还是系统不好用，问题定位成本翻倍。
5.2 避坑：流程变革项目里最常见的五个翻车点
现象一：流程框架做完，业务部门说“这不是我们干的活”。原因：Top-down 建模时没有用 Bottom-up 做场景匹配，L3/L4 的活动描述脱离了实际业务场景。解决：在 L2 到 L3 的分解阶段就引入代表性事业部的成熟流程做校验，框架定稿前必须经过业务场景走查。
现象二：主数据编码规则各事业部不统一，端到端流程在系统里串不起来。原因：主数据建设排在流程推广之后，或者主数据标准由各事业部自行制定。解决：主数据标准必须先于流程推广冻结，六大类主数据（产品、物料、客户、供应商、财务）的编码规则由集团统一发布，事业部只能提例外申请。
现象三：APS 排程结果和 MES 生产实绩长期对不上，计划员和车间互相甩锅。原因：APS 和 MES 的功能边界在实施阶段被模糊，排程颗粒度和执行反馈颗粒度不一致。解决：在流程框架的 L3 层面明确 APS 输出的是工序级计划、MES 反馈的是工序级实绩，两者的时间颗粒度和物料颗粒度必须对齐。
现象四：系统归并阶段把“去差异化”做成了“一刀切”，部分事业部的合理业务差异被抹掉。原因：归并时只看了系统数量，没看业务场景差异。解决：归并的对象是“重复且差异化开发”的系统，不是所有差异化系统；对确有业务模式差异的场景，保留定制化流程领域，在框架里显式标注。
现象五：流程推广批次排得太密，前一批的问题还没收敛就推下一批。原因：项目里程碑倒排，推广周期被压缩。解决：每批次推广后留出至少一个季度的稳定期，把上一批的流程例外和系统缺陷收敛完再启动下一批，否则问题会累积放大。
5.3 项目执行原则：七条杠杆为什么比工具更重要
项目列了七条执行原则：战略为本（解读公司发展愿景与战略方向，提炼对运营模式的影响）、价值聚焦（尽早聚焦主要价值链和管控流程及关键短板领域）、框架搭高效流程（从业务模式出发，考虑各事业部及国内国外业务特性）、可实施（重用有效实践，借鉴代表性事业部的成熟流程模块，利用现有 IT 系统模板）、权衡标准化与差异化（以价值为依据权衡标准化、集中化程度）、高层驱动（关键业务领导作为流程负责人）、长效机制（确保流程管理和转型 PMO 管理的团队和制度保障）、速赢保势（分阶段设计实施，设置阶段价值目标）。
这七条里，最容易被低估的是“高层驱动”和“长效机制”。流程变革本质上是利益重新分配，没有业务领导作为流程负责人对结果负责，PMO 推不动任何跨部门决策。而长效机制解决的是项目结束后的持续运营问题——流程框架不是一次性交付物，需要有团队持续维护和迭代。很多企业的流程变革项目验收即巅峰，之后框架逐渐腐化，就是因为缺了长效机制这一环。
6. 设计取舍：标准化与差异化的边界，到底该划在哪里
632 项目最值得琢磨的设计取舍，是标准化与差异化的权衡。项目原文说得很清楚：流程框架的推广最终要实现集团集约效应，并支撑事业部高竞争力的运营，需充分考虑产品及地域的特点，以价值为依据，权衡标准化、集中化的程度。这句话翻译成工程语言就是：标准化不是目的，是手段；差异化的保留与否，取决于它对业务价值的贡献，而不是它对管理便利性的影响。
从实施结果反推，632 的边界划法大致是这样的：L1 价值链主干和主数据标准完全标准化，没有商量余地；L2 运营模式层面的子流程按业务场景分化，比如渠道分销和直销各自有适用的二级流程；L3/L4 的业务能力和活动在集团模板基础上允许局部定制，但定制必须显式标注并经过流程负责人审批。这个三层边界的好处是，标准化保住了端到端串接的基础，差异化留住了业务单元的竞争力。
验证这套边界是否合理，有个很朴素的方法：看端到端流程的断点数量。如果标准化过度，断点会集中在“业务场景不匹配”上，表现为业务部门绕开系统走线下；如果差异化过度，断点会集中在“数据对不上”上，表现为系统间接口频繁报错。632 在推广阶段以半年为周期、3 到 4 个事业部为批次推进，本质上就是在用批次间的反馈来校准这条边界。
我自己的习惯是，每次做流程框架评审，都强制走一遍“断点归因”：把每个流程断点归类到标准化过度、差异化过度、还是框架缺失，三类问题的解法完全不同。标准化过度要放开定制审批，差异化过度要收紧主数据，框架缺失要补 L2 场景。这个习惯是从类似项目里踩坑踩出来的——早期总想一次性把边界划准，后来发现边界是迭代出来的，不是设计出来的。希望帮到你。
本文还有配套的精品资源，点击获取
