企业官网建设流程全解析

简介：这份PPT面向企业流程管理、IT规划与数字化转型从业者，系统梳理美的集团632项目的流程变革框架与落地路径，可用于理解大型集团端到端流程重构、主数据统一和多系统集成的规划方法。压缩包仅含1个pptx文件，约2.76MB，以流程图、框架图和汇报页为主，适合快速浏览、方案复盘或制作内部培训材料。内容覆盖EPF企业流程框架的L1—L4设计、流程要素与串接、流程打开及IT实现，并展开市场、研发、计划、采购、制造、销售、服务等核心价值链环节，以及六大运营系统、三大管理平台和两大技术平台的协同关系；同时涉及2013—2015年实施策略、13个大项目推进、里程碑管控、主数据建设与632办公室的组织机制。已有106人学习，适合需要参考集团级流程变革方案、咨询设计成果或搭建汇报材料的中高级读者。

1. 流程变革：为什么“上系统”解决不了流程本身的问题

很多企业做流程变革，第一反应是买系统、上平台，结果几个亿砸下去，流程还是各走各的。这份方案里有个反直觉的判断：问题不在系统，在流程框架本身缺一层结构。方案把流程拆成 L1 到 L4 四级，先定义“干什么”，再定义“由谁干、用什么系统干”。L1 是价值链主干，同行基本一致；L2 是运营模式差异；L3/L4 才是业务能力和具体活动。真正难的是 L2：同一条“渠道管理”，分销场景要部署，直销场景根本不适用。不分场景地把流程套到所有事业部，就是把差异化当成不规范来治，越治越乱。搞懂这套分层为什么能既统一又不僵化，比记住六大系统三大平台有用得多。

2. 四级流程框架：L1 到 L4 各管什么，为什么不能跳级

流程框架最容易出问题的地方，是把“流程模块”和“具体流程定义”混为一谈。方案里专门做了一次概念澄清，这个澄清其实是整套方法的地基。L1 是业务流程主干，比如市场到订单、研发，同行业内基本一致，它回答的是“企业靠哪几条主干创造价值”。L2 是运营模式层面的业务子流，比如渠道管理，它在分销业务场景下要部署，在直销业务场景下不适用。也就是说，L2 才开始承载业务模式的差异。L3/L4 是为实现运营模式所需要的业务能力和业务活动，比如渠道规划与开发，这一层和 IT 系统的选用还不相关。再往下才是结合特定系统的交互过程和工作流，最底层是基于特定系统的操作手册。

这套分层的巧妙之处在于：差异被限制在 L2 这一层表达，往上收敛、往下展开。集团层面统一 L1，保证端到端价值链不被部门墙切断；事业部层面在 L2 上按业务场景选择部署哪些模块；L3/L4 落到能力和活动，供具体系统去承接。如果跳过 L2 直接从 L1 铺到 L4，结果就是所有事业部被要求长得一模一样，一线只能靠线下表格绕过去，系统上线即废弃。

2.1 两个维度切分：价值链横轴与管理层次纵轴

框架不是一张平铺的树，而是两个维度交叉定位。横轴是业务价值链：市场、研发、市场营销、供应链、售后支持，从市场分析一路到客户满意度。纵轴是管理层次链：规划与建设、执行与监控。比如研发这条价值链上，“规划与建设”对应市场导向产品企划、科技规划，“执行与监控”对应产品生命周期管理、科技研发、研发管理。供应链上，“规划与建设”是供应链规划，“执行与监控”才是计划、寻源采购、生产制造、仓储物流、退货管理。

这个二维切法的价值在于，它天然暴露了“规划了但没人执行”或“执行了但没有规划依据”的断点。企业管控和支持流程（财务、人力资源、内控审计、IT、战略）则作为纵向贯穿的一列，不占价值链的某一环，而是支撑每一环。用一张二维表定位每个流程模块，比画一堆层层嵌套的框图更不容易漏、不容易重叠——方案里对“好的流程框架”的定义就两条硬指标：业务覆盖全面、体系结构严谨，模块之间有必要的层级与逻辑关系，全覆盖且没有交集。

2.2 自上而下搭骨架，自下而上做匹配

方案对两种建模方法的取舍写得很直白。自上而下是先构建流程全貌，再层层分解到细节，优点是能建立体系全貌、容易检验和修订、避免流程重复重叠和无法连接，缺点是需要有清晰的 L0 框架作为输入，而且要对原有流程体系做较大修改。自下而上是从细节流程入手，挑选合并后生成上一级流程，优点是建立基于实际的流程应用、最大限度保证共享和复用，缺点是看不到全貌、底层合并非常困难、很难形成完整体系。

方案的结论是组合使用：从上而下建立流程高阶框架，自下而上进行流程匹配，兼顾流程的完整性和业务场景的选择。这个组合不是和稀泥。自上而下负责“不漏”，保证 L1/L2 的完整性和互斥性；自下而上负责“不虚”，用事业部已有的成熟流程去填充 L3/L4，验证框架落得下去。方案里提到已有约七成流程基础，部分较具规模的事业部有相对成熟的定义且有系统支撑，所以自下而上的素材是现成的，缺的是把它们收敛进统一框架的那一步。

3. 主流程、主数据、主系统：三者为什么必须一起动

这份方案把 632 项目的内核压缩成一句话：主流程 + 主数据 + 632 系统。改造前的状态是流程、数据、系统三者分散且差异化；目标状态是端到端流程、统一的主数据平台、统一的 632 系统。注意这个顺序不是随意的，流程在前、数据居中、系统在后。原因很实在：流程决定需要哪些数据，数据决定系统之间怎么对接，系统只是最后的承载。倒过来做，先选型再倒推流程，就会陷入“系统能干什么，流程就只能是什么”的被动局面。

3.1 六大运营系统与三大管理平台的分工边界

六大运营系统撑的是端到端核心价值链：PLM 管产品生命周期，APS 管高级计划排程，SRM 管供应商关系，ERP 管企业资源，MES 管制造执行，CRM 管客户关系。方案给每条价值链环节都标了对应的系统归属，比如计划环节对应需求计划、供应链计划、生产排程，落 APS；采购环节对应寻源、供应商管理，落 SRM；制造环节对应生产管理、质量管理，落 MES。这种“一环节一主系统”的划法，目的是让系统边界跟着流程边界走，而不是跟着部门边界走。

三大管理平台则是纵向管控：FMS 财务管理平台做财务一体化，深化财务一体化系统建设，提供增值服务和决策分析支持；HRMS 人力资源管理平台做战略型人才布局，推进国际化人才和高级管理人才的管理；BI 决策支持平台建立集团级风险管控机制，支持内控管理，建立经营分析系统和仪表盘。另有两个技术平台：MIP 统一门户、MDP 集成开发平台。管理平台的定位是“确保集团分权模式下的高效运作”——分权不等于失控，靠的是统一的数据口径和可透视的经营分析，而不是把审批权往总部收。

3.2 主数据为什么是流程落地的前置条件

方案对主数据的定义很清楚：为支持企业核心业务获取业务交易、衡量企业实体绩效结果，而需要建立和维护的企业级范围的数据信息管理，主要包括产品、物料、客户、供应商、财务等主数据标准与管理机制。关键词是“企业级范围”和“标准与管理机制”，不是“把数据洗干净”。

为什么主数据必须先于系统实施？设想同一个供应商在 A 事业部叫一个编码、在 B 事业部叫另一个编码，采购流程再标准，跨事业部比价、集中采购、供应商绩效统算全都做不了；同一个物料在不同工厂有不同描述，APS 排程拿到的需求和生产对不上，排出来的计划就是废纸。端到端流程的本质是跨边界的数据能被同一个口径读懂，主数据就是那个口径。所以方案的实施路径把主数据建设放在 IT 系统试点之前，2013 年 9 月完成集团六大类主数据，2014 年 1 月才完成 ERP、APS、SRM、PLM、IMS、OMS 的实施供应商组建。

3.3 流程要素怎么落到 IT：串接、打开、落地三步

方案把流程落地 IT 拆成三个动作，这三个动作是有先后依赖的。第一步流程串接，把 L1/L2 层面各流程模块之间的输入输出关系接上，回答“上一个环节交付什么给下一个环节”，这一步暴露的是跨职能协同断点，比如供需平衡这类需要跨部门协作的场景。第二步流程打开，把 L3/L4 展开成业务能力和业务活动，明确每个活动需要什么数据、产出什么数据、由什么角色承担，这一步还不绑定具体系统。第三步流程落地，才结合特定 IT 系统描述业务与系统的交互过程和工作流，以及用户在系统中的具体操作步骤。

这个顺序的意义在于把“业务设计”和“系统实现”解耦。流程打开阶段如果发现某个活动在现有系统里没有承载点，那是一个业务决策——是改流程还是补系统；如果一上来就对着系统界面画流程，这个话题根本没机会被提出来。方案里对 L3/L4 的定义特意加了一句“与 IT 系统的选用不相关”，就是在保护这一层的独立性。常见的实现思路是：L3/L4 用统一的流程建模规范和模板产出，交给 IT 做差距分析，差距清单反过来驱动系统选型和定制开发，而不是让 IT 反过来裁剪流程。

4. 分批推广与避坑：为什么“一次性全铺”必然翻车

方案的实施策略是三个阶段：系统归并、企业模板试点、企业模板推广完善。第一阶段做简单化和去差异化，通过归并系统复制内部最佳流程和系统，提升部分单位的 IT 应用水平，为统一流程管理打底；第二阶段建立集团级端到端流程、主数据管理机制、标准目标和实施路径，完成 632 集团级系统规划和试点实施，建立全球模板；第三阶段各单位推广全球模板并持续完善。时间跨度 2013 到 2015，大事记里能看到清晰节奏：2013 年 9 月完成六大领域 1 到 4 级流程框架，2014 年 1 月完成 5 级流程打开，2014 年 12 月完成非试点事业部流程框架推广，之后以半年为周期、按 3 到 4 个事业部为批次复制，2015 年 1 月第一个事业部系统上线，2016 年 12 月完成集团整体覆盖。

4.1 试点选谁：模板可行性的验证逻辑

试点事业部的选择标准不是“最大的”或“最听话的”，而是能否验证模板跨事业部标准化推广的可行性。方案里写得很清楚：验证流程模板跨事业部标准化推广的可行性，补充主要的业务场景，完善流程体系，提出必须局部定制化的流程领域。这句话里藏着两个产出：一是确认哪些流程真的能统一，二是明确哪些领域必须允许定制。后者往往被忽略，但它才是推广不翻车的关键——如果试点阶段只证明“能统一”，推广时一遇到业务模式不同的单位就得推倒重来。

试点还有一个隐含作用：产出可以复用的“场景清单”。L2 层的模块在不同业务模式下部署与否不同，试点就是把代表性事业部的成熟流程场景摸清楚，形成一份“哪些场景需要哪些模块”的对照关系。后续批次推广时，新事业部先对照场景清单勾选自己适用的模块，而不是从零讨论要不要。这把推广从“重新设计”变成了“配置选择”，工作量和争议都大幅下降。

4.2 常见问题与排查

现象一：流程框架画得很漂亮，一上线一线全在用线下表格。原因多半是 L3/L4 没有对应到系统里的可操作活动，或者活动要求的输入数据现场拿不到。排查方法是从末端倒推：随机抽一个岗位，问他每天做的事在流程文件里对应哪一条 L4 活动，如果对不上，说明流程打开这一步是关起门来做的。解决办法是回到流程打开阶段，用自下而上的方式把岗位实际活动补进去，再判断是改流程还是补系统能力。

现象二：同一份报表，两个事业部数字对不上，会上吵半天。这是主数据口径不一致的典型症状，不是报表工具的问题。排查时先查客户、供应商、物料三类主数据在两个单位是否存在重复编码或一物多码，再查指标定义是否统一。解决只能从主数据标准和维护机制入手，靠事后对账永远对不完。方案把主数据放在系统实施之前，就是为了避免这个坑。

现象三：试点单位效果很好，推广到第三批就开始走样。原因通常有两个：一是试点时靠强人推动，没有沉淀成机制；二是推广批次之间没有统一的准入检查。方案里强调“长效机制，确保流程管理和转型 PMO 管理的团队和制度保障”，以及“高层驱动，由关键业务领导作为流程负责人”。排查时要看每个批次上线前有没有做流程符合性检查、有没有流程负责人在验收单上签字。缺了这两样，推广就变成各单位自由发挥。

现象四：流程负责人挂名，出了跨部门问题还是找不到人。跨职能流程的断点，比如供需平衡协调，天然不属于任何单一部门。如果没有明确的流程负责人对端到端结果负责，断点就会被两个部门互相推。排查方法是把每条 L1 主干流程列出来，看是否有一个具名的业务领导对其端到端绩效负责。方案的原则里写的是“由关键业务领导作为流程负责人，推动变革，对结果负责，用业绩导向的方式赢得高层持续关注支持”，挂名的不算。

现象五：为了统一而统一，把该差异化的地方也抹平了。这是另一个方向的翻车。方案的原则里明确“权衡标准化与差异化，流程框架的推广最终要实现集团集约效应，并支撑事业部高竞争力的运营，需充分考虑产品及地域的特点，以价值为依据，权衡标准化、集中化的程度”。排查方法是看 L2 层的模块清单里，有没有标注“适用场景”和“不适用场景”。全是“必须执行”的清单，基本可以判定没有认真做场景区分。

4.3 组织与节奏：把变革做成工程而不是运动

方案在项目执行原则上列了七条，其中三条是节奏控制的关键。一是“速赢保势，分阶段设计实施，设置阶段价值目标，确保部分成果的快速见效，保持公司内部的变革势能”——变革最怕战线太长、中途失去关注，所以要主动设计能快速见效的节点。二是“高层驱动”，由业务领导而非 IT 部门主导。三是“长效机制”，PMO 团队和制度要能长期运转，而不是项目结束就解散。方案里 2012 年 11 月成立 632 办公室，2013 年 3 月成立咨询项目组，这个组织先行的顺序也说明了同一件事：先有常设的推动主体，再谈流程和系统。

从大事记的时间分布也能看出节奏设计的用意。2013 年全年集中在流程框架和主数据这类“地基”工程，一年内完成六大领域 1 到 4 级框架和六大类主数据；2014 年才做 5 级打开和系统实施供应商组建；2014 年底开始非试点事业部的框架推广；系统上线从 2015 年 1 月才启动。也就是说，从项目启动到第一个事业部系统上线，中间隔了两年多。这个节奏在很多企业看来太慢，但地基没打完就上线系统，后面返工的成本要高一个数量级。

5. 设计取舍：标准化到什么程度，才是这套框架真正的难点

整套方案最值得琢磨的地方，不是四级框架本身，而是它在“标准化”和“差异化”之间划的那条线。线划在 L2：L1 统一，因为价值链主干同行业基本一致，统一它才能做端到端协同和集约化；L2 允许按业务模式分化，因为渠道分销和直销需要的能力本来就不同；L3/L4 落到能力和活动，用统一规范描述但不强求一致；再往下才绑定具体系统。这条线的本质是把“统一”定义在结构和口径上，把“差异”定义在场景和实现上。很多流程变革失败，是把统一错误地定义成了“所有单位做一样的动作”，于是要么强行抹平差异导致一线绕行，要么因为差异太多干脆放弃统一。

用这个视角回看那几个设计选择，逻辑就串起来了。主数据先于系统，是因为统一口径必须先于统一动作成立；自上而下搭骨架、自下而上做匹配，是因为结构必须统一、素材必须来自实际；试点要验证“可行性”还要“提出必须局部定制化的领域”，是因为推广的前提是把可统一和不可统一的分界线摸清楚，而不是假设全部可统一。

如果要验证一套流程框架是否真的立住了，我一般会看三件事。第一，随便挑一个跨部门场景，比如从销售预测到生产排程，能不能沿 L1 到 L4 一路走通，中间每一跳的输入输出都有明确归属，没有“这块不归我管”的黑洞。第二，看 L2 的模块清单有没有场景标注，能不能回答“我们这种业务模式该部署哪些模块、不该部署哪些”。第三，看主数据的维护责任有没有落到具体岗位，而不是停留在“由信息部门统一管理”这种说法上。这三条都能过，框架才算从文档变成了运行机制。

还有一个容易被低估的取舍：流程框架的完备性和可维护性之间的平衡。理论上可以把 L4 甚至 L5 做到极细，覆盖每个操作细节，但那样维护成本会高到没人愿意更新，最后框架和现实脱节，变成一份没人看的文档。方案停在 L4、把操作手册单列一层，是务实的选择——框架管结构和能力，操作细节交给系统和手册去管，各管一段。

这套规划文件真正有价值的地方，是它把“流程变革”从一句口号拆成了可执行的层次：框架怎么分层、数据怎么先行、系统怎么跟着流程走、推广怎么分批、组织怎么保障。每一层都有明确的交付物和判断标准，而不是停在理念层面。

提示：读这类规划方案时，重点看它怎么定义“不做什么”和“哪里允许不一样”，比看它列了多少系统、多少阶段更能判断落地难度。

从那以后我每次看流程变革方案，都会先翻到场景区分那一页，看它敢不敢明说哪些地方不统一。一份只讲统一、不讲差异边界的方案，我基本会打个问号。希望帮到你。

本文还有配套的精品资源，点击获取