简介美的集团632项目流程变革框架整体规划方案是一份132页的PPT面向企业管理者、流程变革与数字化规划人员。方案以EPF企业流程框架咨询方法论为基础系统梳理六大运营系统PLM/APS/SRM/ERP/MES/CRM、三大管理平台BI/FMS/HRMS及两大技术平台MIP/MDP的总体布局并给出从系统归并、企业模板试点到模板推广完善的分阶段实施路径。其中还包含项目大事记与主数据管理机制可帮助读者理解多事业部集团建设端到端流程、统一主数据及632系统的整体思路。资源为单个PPT文件约4.4MB已有59人学习适合用于集团数字化转型规划、流程架构设计及IT系统整合的参考。 一份132页的数字化规划PPT在圈子里面被反复传阅了十来年这本身就不常见。美的集团632项目就是这样一个特殊存在——2012年启动当时美的营收已过千亿十几个事业部、上百套IT系统各事业部连ERP都有多个品牌在跑同一颗螺丝钉在不同系统里的编码完全对不上。632项目要解决的表面上是系统统一本质上是一套流程、一套数据、一套标准的重构。这篇文章我把这套方案背后的流程变革框架拆开讲清楚它到底在解决什么问题、架构是怎么设计的、变革为什么能落地以及今天做数字化转型的人还能从中借鉴什么。1. 百亿规模背后的管理乱局632项目到底在解决什么问题1.1 规模增长掩盖下的系统与流程失序要理解632的价值必须先回到2012年前后的美的。那是一家典型的“事业部制”企业家电全品类覆盖空调、冰箱、洗衣机、小家电各自成军每个事业部都有自己的产供销体系。这种组织模式在规模扩张期效率极高谁都能在各自的赛道里快速响应市场。但代价也很大——集团层面缺乏统一的流程和信息化底座各事业部自建系统、自定标准IT系统数量超过100套光ERP就有SAP、Oracle、金蝶等多个版本并存。这个状态放到今天叫“烟囱式架构”但当时很多企业都是这么过来的。问题在于美的的体量已经大到这个模式撑不住了。一个很典型的场景是经营分析会十几位事业部总经理坐在一起汇报各自的利润率、库存周转、应收账款因为系统口径不同同一类业务的数字经常对不上会开成了“数字打架会”。另一个场景是质量管理——一台空调出现质量投诉要追溯是哪批物料、哪个供应商、哪条产线生产的往往需要人工把几个系统的数据导出来拼在一起效率极低追溯不完整。1.2 高层决心与“633”战略的推进逻辑2012年美的集团层面下定决心推进“333战略”——用三年时间、投入三十亿元实现“一个美的、一个体系、一个标准”。632项目就是这个战略在流程与IT层面的落地载体。集团成立了由董事长挂帅的项目领导组下设流程、数据、IT、变革管理四条线各事业部一把手全部纳入项目责任体系。这里我想多说一句632这种量级的变革成败的第一要素永远不是技术而是高层有没有“必须做成”的决心。美的当时面临的局面是各事业部已经习惯了各自为政统一意味着权力和资源的再分配。如果没有董事长级别的强推流程框架画得再漂亮也落不了地。2. 632到底在说什么一套平台化的企业架构设计2.1 架构全景三个数字代表的三层逻辑632这个名称本身就把方案的核心架构说清楚了但大多数人在看这份方案时容易把它简单理解成“上9套系统加2个平台”。实际上它的设计逻辑非常清楚——三层架构、一条主线。层级组成部分解决的核心问题6大运营系统PLM、APS、SRM、MES、ERP、CRM打通“研产供销服”全价值链的端到端业务流转3大管理平台BI商业智能、HR人力资源、FMS财务管理系统支撑集团级的管理协同、决策分析与资源共享2大技术平台MIP集成平台、MDP开发平台解决系统之间的互通问题和个性化扩展问题这三层的关系是底层技术平台负责打通数据与接口中间运营系统承接具体的业务流程上层管理平台面向管理和决策层做数据的汇总与穿透。这其实就是今天常说的“业务中台数据中台”的早期雏形。2.2 6大运营系统的业务链条拆解6大运营系统是整个632的核心它们覆盖了一家制造企业最核心的价值链环节。PLM管理产品研发和生命周期数据APS负责高级计划排程SRM管供应商和采购协同MES管制造执行过程ERP管财务与资源计划CRM管客户和销售前端。这里值得注意的一点是这6个系统不是简单并列而是严格按业务流程串联起来的。从产品立项、物料清单构建、供应商准入、采购下单、生产排程、车间执行、完工入库到销售发货、售后反馈业务数据在这套链条里是“一次输入、全程共享”的。以前各事业部可能在PLM和ERP之间还要靠人工导BOM在632的框架下这些系统之间通过MIP集成平台实现无缝对接BOM从设计端到制造端自动流转。2.3 2大技术平台为什么必不可少很多企业做系统建设时常忽略技术平台的重要性结果系统越上越多接口越接越乱。632方案把MIP集成平台和MDP开发平台单独拎出来是很有先见之明的。MIP承担所有系统间的接口集成、数据同步和消息转发相当于企业IT系统的“中枢神经”MDP则是统一开发平台各事业部有特殊需求时必须基于统一的技术规范做二次开发不允许另起炉灶。这套架构设计带来的直接收益是未来的系统建设从“每个系统一套技术栈”变成“一个底座上长应用”。可以从一个生活化的角度来理解——以前的系统建设像是每间屋子自己拉水管、装水表各用各的管道标准632做的是一次全屋水电改造先统一管道走向和水压标准再按需接卫生间、厨房、阳台。前期工程量很大但后期接任何新设备都极其顺畅。3. 流程先于系统这套流程变革框架的完整推进逻辑3.1 为什么不能先买软件再造流程632项目很容易被误解为“上一批软件”。但方案里有一条贯穿始终的原则流程先于系统。这个顺序一旦搞反项目大概率走偏。很多企业做ERP、CRM时喜欢先选型、先买软件、再让业务部门来匹配软件的标准流程理由是“国际大厂的软件封装了最佳实践我们学习它就行”。这个思路在局部项目里可行但在集团级变革中会很危险。原因是软件固化的是通用的业务逻辑而美的当时的问题是各个事业部连同一个业务的定义都不统一——什么叫“订单有效”什么叫“标准成本”各有一套说法。如果直接上软件等于在沙地上盖楼底层的数据标准和管理口径没统一系统上线后一定是一堆数据垃圾。632的做法正好相反先把集团的流程架构梳理出来定义清楚端到端流程有哪些、每个流程的边界在哪、输入输出是什么、需要哪些数据然后再去配置和定制系统。系统是流程的载体不是流程的定义者。3.2 流程分级从L1到L6的金字塔体系方案中有一个很核心的流程分级方法把企业流程从上到下分成六个层级。这里我用自己的理解做一个说明L1流程价值链级回答“企业靠什么创造价值”比如产品研发、订单交付、售后服务这样的大域L2流程组每个L1下的子域比如产品研发下可以拆出需求管理、概念设计、详细设计、验证等L3流程端到端的可操作流程比如“新品从立项到上市”L4子流程L3流程内更细分的环节L5活动具体的工作步骤L6任务岗位级的操作说明。这套分级的价值在于它让上万名员工能在同一个流程语言体系下对话。以前各事业部说“研发流程”可能指千差万别的东西现在L1到L6一摆大家明确知道自己讨论的是哪个层级。方案中的流程框架图基本就是按照这个金字塔一层一层画出来的这也是132页PPT里最有干货的部分之一。3.3 流程Owner让每条流程都有一个“话事人”流程梳理出来之后最怕的是挂在墙上没人管。632方案明确设置了流程Owner机制——每条端到端流程指定一个业务负责人比如面向订单交付流程的Owner可能是供应链副总裁研发管理流程的Owner可能是研发体系的负责人。流程Owner不是挂名他们要对流程的绩效、执行中的问题、IT系统的支持需求负全责。这一点对于做流程管理的人来说太关键了。没有Owner的流程一旦出现跨部门协作问题就是“铁路警察各管一段”没人愿意为端到端的效率负责。设置了Owner之后问题就有了“第一责任人”很多长期扯皮的问题在机制上就解决了。4. 从试点到全集团覆盖这种体量级的变革怎么控制节奏4.1 试点选择的“中等复杂度”原则632项目覆盖美的所有事业部如果一次性全部切上线风险极大。方案中采用的是“试点先行、分批推广、全面覆盖”三步走策略。选试点时有一条很务实的标准不选最复杂的也不选最简单的而是选业务复杂度中等、管理基础较好、配合意愿高的事业部。选最复杂的事业部试点容易因为特殊情况太多而导致方案反复调整项目拖垮选最简单的试点跑通了也没有说服力别的事业部会说“它那里本来就简单”。中等复杂度的事业部跑通既能验证方案的普适性也能让各种典型问题浮出来统一解决后续复制时才更有底气。4.2 横向复制统一模板与共性优先试点跑通之后最难的不是技术而是“横向复制”。美的各事业部的业务形态差异很大——大规模制造、小批量定制、出口贴牌、内销品牌流程细节都不一样。632方案面对这个问题时的处理原则是共性流程全集团统一个性需求在MDP平台上做有限度的适配不允许模拟两可。实际操作中项目组把试点事业部沉淀出来的流程模板按照“70%共性30%个性化”的比例去推广。共性的部分强制统一比如采购申请、费用报销、订单管理等通用流程全集团一个版本个性化的部分比如不同产品线的特殊检验环节走统一的变更管理流程在MDP上做配置开发。4.3 项目治理日清、周结、月复盘与灯号管理一个几百人的项目团队持续三年多如果没有一套严格的治理机制很容易“前面一团糟、后面赶工补”。632项目的管理机制在方案里写得很细日清会解决当天的共性问题周结会检查里程碑和风险事项月复盘向集团高层汇报阶段成果和下一步计划。另外还有一个特别值得借鉴的“灯号管理”——每个模块、每个事业部的实施状态分三色灯绿灯表示按计划推进黄灯表示有风险但可控红灯表示问题严重需要升级到集团层面协调。这套机制让项目管理层一眼就能看清全局状态避免问题被一线团队捂着盖着直到爆发了才被高层知道。5. 比系统更难啃的硬骨头主数据统一与流程IT一体化5.1 一物一码主数据统一是一场“数据清洗战争”632项目里最繁重、最枯燥也最容易出问题的活其实是主数据治理。物料、客户、供应商、组织架构、人员、会计科目这些基础数据在原来的上百套系统里各有一套编码和属性定义。以物料为例同一颗标准螺丝在不同事业部、不同系统里的编码可能有三四个版本有的叫“螺丝M4*10”有的叫“ST4.2X13”有的干脆只有一个编码没有描述。方案里对主数据管理设了一条铁律一物一码。全集团的物料编码规则统一由专门的物料数据小组负责清洗和规范所有系统接入前必须先按新编码体系映射。这项工作的难度完全可以和具体的系统上线相提并论——数据清洗期间各事业部要停下手中的正常业务配合梳理历史数据业务部门的人白天干活晚上还要加班核对编码。整个过程非常痛苦但如果不做这一步系统就算上线了也是各说各话。5.2 数据Owner与数据标准委员会数据治理还不只是清理历史数据更关键的是建立长效管理机制。632方案中明确要求建立数据标准委员会定义每一个关键数据的业务口径、编码规则、维护流程和责任人。每类主数据有一个业务Owner单位比如物料主数据由供应链管理部门负责客户主数据由营销体系负责供应商主数据由采购体系负责。谁的数据谁负责、谁维护、谁对质量兜底。这个设计在今天看来毫不过时。很多企业做数据治理项目时往往把它当成IT部门的任务业务部门不参与结果治理出来的数据标准没人认执行不下去。632的做法是“数据问题回归业务管理”从机制上解决数据质量责任的归属问题。5.3 流程IT一体化打破业务和技术“两张皮”632项目还有一个组织层面的创新就是在集团层面把流程管理和IT职能整合到一个部门。以前大多数企业的流程管理挂在运营管理部门IT挂在信息中心两个部门互相不买账——业务说IT不懂业务需求IT说业务需求天天变。632的推进过程中跨部门协同的问题太频繁了必须有专门的组织去协调流程与系统的关系于是就有了流程与IT一体化部门。这样做的好处很明显流程设计的时候同步考虑IT可实现性系统开发的时候围绕流程目标展开业务与技术的目标对齐到同一条线上。这比“业务提需求、IT做实现”的传统协作模式在大型变革项目中更高效。6. 把632放到今天再看这套方案还有哪些启示和需要诚实面对的问题6.1 规模化的企业如何借鉴632的架构思维今天很多企业也在谈数字化转型有的已经投入了几年、十几个亿回头一看效果寥寥。对照632项目的经验我觉得第一个要学的是“架构先行”。很多企业数字化转型失败不是因为没有好的应用场景而是没有想清楚整体架构——各个系统之间的边界是什么数据怎么打通流程要不要统一这些问题没想明白就上了一个又一个的“智慧”系统最后还是在堆烟囱。632给出的思路是先把流程框架定出来再设计系统架构再分步实施。哪怕一开始不能像美的那样做全集团的大重构至少在启动一个新系统建设之前先问清楚它在整个流程链条里处于什么位置和上下游的流程与数据接口是什么。这个意识比上什么系统重要得多。6.2 中小企业不能照搬但可以学什么有一个诚实的提醒是632这种量级的项目并不是所有企业都有必要照搬。它需要几个前提条件——足够大的体量让统一投入有规模效益、足够强的集团管控权威、以及能够承担多年高投入的财务实力。中小企业和规模还不大的成长型企业如果把632的完整框架拿来直接套大概率会把自己拖垮。但可以学的部分依然很多流程分级的思考方法、流程Owner机制、先数据后系统的实施顺序、试点复制的推广策略。这些方法论是通用的不依赖企业规模。小企业可以选一个核心流程域比如订单交付或研发管理用632的逻辑先做局部打通跑出效果再逐步扩展。6.3 一个常被忽略的代价流程标准化与业务灵活性如何平衡聊632的时候很多文章只讲它的成功很少讲代价。一个客观的现实是全集团统一流程和系统必然会牺牲一部分业务的灵活性。统一之前某事业部要上一个新业务模式可以自己改了流程就跑统一之后所有变革都要走流程变更审批经过系统开发排期响应速度必然变慢。所以632之后美的也在不断做调整——把一些业务场景做细颗粒度的区分让共性的归共性、个性的归个性同时基于MIP和MDP平台做更灵活的流程编排在保证“一个标准”的前提下尽可能支持一线业务的快速试错。这其实是所有做流程标准化的人都要面对的一道长期考题统一是手段不是目的不能让管控变成一个业务响应速度的枷锁。回到那份被传阅多年的132页规划方案它最大的价值不是某个具体的系统选型或界面设计而是提供了一套“大型制造企业如何进行流程与IT整体重构”的完整思考框架。今天再翻开它很多理念依然值得反复琢磨包括我对流程Owner、数据先行这些原则的理解也很大程度上是做这类项目时逐步加深的。这套方案的细节可以更新但底层的变革逻辑经得起时间检验。本文还有配套的精品资源点击获取