先定流程再上系统：632项目EPF流程框架与六大系统落地实践

简介这份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 场景。这个习惯是从类似项目里踩坑踩出来的——早期总想一次性把边界划准后来发现边界是迭代出来的不是设计出来的。希望帮到你。本文还有配套的精品资源点击获取