1. 为什么蓝图设计阶段直接决定ERP项目一年后的死活很多企业上ERP习惯性把注意力放在选型上软件厂商比了一轮又一轮合同一签实施方进场需求调研问卷一发业务部门随便填一填顾问们闭门画几页未来流程图PPT一汇总蓝图评审会开两小时就过了然后直接进系统配置。这种项目十有八九会在上线半年后陷入漫长的修修补补严重的直接推倒重来。我见过太多这样的案例不是软件不行而是蓝图没画对。蓝图阶段是ERP实施周期里唯一一次把企业的战略、组织、流程、数据、系统边界、权力分配全部摊在桌面上一次性达成共识的机会。一旦进入配置和开发阶段再想动蓝图里的任何一个决策都要付出数倍甚至数十倍的代价。这就跟装修一样效果图阶段改一个插座位置只是一个橡皮擦的事等墙砌好了贴完砖了再改那就是砸墙重来。先说清楚一个概念ERP蓝图设计不是画几张好看的业务流程图给领导汇报它是整个实施项目的技术总纲和业务宪法。蓝图里定义了未来系统长什么样、每个业务环节谁来做、数据从哪里来到哪里去、一个单据从创建到归档走什么路径、出了问题找谁。系统配置只是把蓝图翻译成系统的过程翻译本身不难难的是蓝图本身有没有把业务想透。所以一个合格的蓝图阶段至少要输出四样东西现状差距分析目前业务的痛点在哪里哪些流程要推倒哪些只需优化。未来业务流程设计分为几个业务域每个业务域的端到端流程长什么样关键控制点设在哪里。系统功能与技术架构哪些需求用标准功能实现哪些需求要二次开发哪些需求根本不该进系统。数据与集成方案主数据谁来维护系统间接口如何走历史数据如何迁移。很多项目把第四样东西当成技术细节丢给架构师去弄结果上线前发现数据迁移量远超预期集成联调时间被严重压缩这是后话。蓝图阶段偷的懒全部会在上线前连本带利还回来。还需要强调一个容易被忽视的点蓝图的评审主体是业务方而不是IT部门。蓝图不是IT部门内部的系统设计它是业务部门对未来作业方式的承诺书。签字确认的那一刻等于业务部门承认未来就这么干活。没有这个承诺后面出现的每一个这个流程怎么和以前不一样的抱怨都会演变成需求变更和二次开发。2. 大型集团蓝图设计的总框架四层架构与页面分配逻辑一个92页的PPT看起来是给领导汇报用的实际上它的页面组织逻辑必须反映蓝图设计的完整思考路径。我见过很多蓝图PPT前20页讲数字化转型趋势中间40页放几十张看不出差别的流程图最后几页放上线计划信息量低到令人发指。真正能指导实施的蓝图PPT本质上应该是一套分层级、分业务域的结构化设计说明。我在大型集团项目里习惯用的框架是四层架构加十个业务域的组合。2.1 四层架构从战略到落地的推导链条第一层是战略与目标层。这层解决的是为什么变。集团的战略目标是什么数字化要支撑什么核心能力ERP在整体数字化版图里的位置在哪里。这一层不需要太多页3到5页就够但必须讲清楚否则下面所有的设计都缺乏判断依据。第二层是业务架构层。这层解决的是业务怎么变。集团层面有哪些业务板块每个板块的核心价值链是什么研产供销服各环节如何衔接管控模式是战略管控、财务管控还是运营管控这直接决定了ERP里组织架构怎么搭。这一层是整个蓝图的灵魂也是最难设计的部分往往要占20页以上。第三层是应用架构层。这层解决的是系统怎么建。核心的ERP覆盖哪些业务域外围系统如CRM、SRM、WMS、MES、OA、BI各自承担什么职责系统之间的边界在哪里接口怎么走。很多集团在蓝图阶段就开始争论这个功能到底放ERP里还是放外围系统里这正是应用架构层要解决的问题。第四层是数据与技术架构层。这层解决的是数据怎么管、平台怎么支撑。主数据策略、数据标准、集成平台选型、技术栈约束、部署方式是私有化还是混合云都需要在这一层定下来。如果这一层不明确后续的系统配置和开发会陷入无休止的扯皮。2.2 十大业务域蓝图的核心展开单元大型集团ERP蓝图设计业务域的划分是关键动作。我一般建议按十大业务域来切分业务域蓝图设计核心内容财务核算会计科目体系、核算规则、合并报表逻辑资金管理资金计划、收付款流程、银企直联预算管理预算编制、控制规则、预算分析采购管理供应商管理、寻源、合同、订单执行库存管理库存模型、出入库策略、盘点与库存分析生产制造BOM、工艺路线、计划排产、车间执行销售管理客户管理、价格策略、订单履行、发货开票人力资源组织人事、薪酬、考勤、绩效主数据物料、客户、供应商、会计科目主数据治理系统集成与外围系统的接口与数据流设计每个业务域在蓝图里占4到8页不要试图在一个业务域里把一个流程的每一个操作细节都画出来那是详细设计阶段的事。蓝图阶段要表达的是这个业务域的核心流程框架、关键控制点、与其它业务域的衔接关系。2.3 页面的纵向推进逻辑从页面顺序上我习惯的结构是这样的开头是封面、项目背景、术语说明控制在5页内。然后是现状诊断与差距分析8到10页这一步很多项目会跳过但恰恰是最能说服业务部门的材料。接着是总体蓝图四层架构10到12页。再往下是一个业务域一个业务域展开每域4到8页。最后是集成架构、数据架构、实施路径和上线策略15到20页。这样算下来正好90页左右信息密度和汇报节奏都比较合理。92页这个数字很有讲究太少说明设计不够深入太多说明没有讲到重点。3. 集团型企业蓝图设计绕不开的五个特殊课题大型集团和单体企业上ERP最大的区别在于组织复杂度。单体企业画流程图就好集团企业首先要回答的是组织、权限、规则如何在系统里结构化表达。3.1 多组织架构设计法人、利润中心、成本中心的三角关系集团的ERP组织架构绝对不是简单建几个公司代码就完事的。一家年营收几百亿的集团下面可能有几十家法人主体、上百个利润中心、几百个成本中心三者之间是典型的N对N关系。蓝图阶段必须把组织建模规则定义清楚会计主体按法人维度设置利润中心按管理口径设置成本中心按责任部门设置。三者之间的过账关系和分配规则如果不定义清楚月底合并报表阶段就是灾难。我见过一个真实案例某制造业集团为了做内部利润考核强行把利润中心挂在法人主体下面结果同一家工厂生产跨法人销售的产品时成本无法按实际业务归集财务每个月要手工调几百张凭证。正确的做法是在蓝图阶段就画出组织的三维矩阵明确每一个组织维度的用途和管理颗粒度再据此设计过账逻辑。该做内部结算的消息单必须在蓝图里定义清楚定价规则和结算科目而不是等上线后让财务去灵活处理。3.2 集权与分权的平衡拿捏管控力度集团管控模式决定了ERP里的权限和审批流设计。财务管控型集团下属企业只需要报数那ERP架构就偏向集中核算和报表合并战略管控型集团各子公司独立运营集团抓投融资和重大决策那ERP就要做分布式部署或者数据隔离。这个问题的难点在于几乎没有哪家集团是纯某一种管控模式往往是分业务板块差异化管控。所以蓝图里的组织职责矩阵和权限矩阵不能只画一张流程图要把哪些事必须上报集团、哪些事子公司自己拍板逐条列清楚。这里我强烈建议用RACI矩阵来辅助把每个关键业务活动的R负责、A批准、C咨询、I知会角色定义好。很多集团一把手在蓝图评审时对组织、权限、审批流的内容最关注因为他们能从这些设计里看到自己到底还能不能管住这家企业。蓝图设计团队如果在这里含糊其辞评审基本过不了。3.3 业财一体化流程衔接处的魔鬼细节业财一体化是所有ERP项目的一等一难题。业务做业务的财务算财务的两张皮是中国企业ERP实施最常见的症状。蓝图阶段要做的不是把财务的凭证规则抛给业务而是要设计清楚每一个业务动作在什么节点触发财务核算。以采购到付款这条流程为例采购订单审核通过、收货过账、发票校验完成这三个节点分别在系统的哪个过账规则下生成什么凭证如果收货数量和发票数量不一致是三单匹配搁置还是直接按收货结算。这些细节不设计清楚ERP上线后第一个月就会出现大量财务数据不平的情况。我习惯的做业财一体化蓝图的方法是把财务科目映射表的前置工作放到业务流设计阶段来通盘考虑业务顾问和财务顾问坐在一起梳理每一张业务单据会触发哪些过账方向是什么金额取数来源是哪里。把这一步做扎实后面上线后的为什么总账和业务模块对不上之类的问题会少很多。3.4 主数据治理一物一码是终极目标还是奢望集团主数据之乱乱到超乎想象。同一个物料子公司A叫1.5mm冷轧钢板子公司B叫薄钢板C1500ERP一上线物料档案倒进去两万多条其中起码三千条是同一种东西但编码、规格、单位全不一样。这个账后面无论怎么分析都是糊涂账。蓝图阶段的主数据设计不是简单的编码规则制定而是要明确主数据的归口管理部门、申请流程、审核流程、发布流程和分发范围。更关键的是存量数据清洗策略哪些历史数据要清洗、清洗到什么程度、谁来清洗、清洗质量如何验收。这些都是实打实的脏活累活但蓝图阶段不安排上线阶段就会爆雷。3.5 集成架构明确ERP的边界与定位今天没有任何一套ERP能包打天下。大型集团的系统环境里一定有OA、MES、WMS、CRM、SRM、BI等各类系统ERP只是这些系统里的一部分。蓝图设计里最忌讳的是把所有的数据接口都做到9999张而是要浇盆冷水先理清楚ERP的边界在哪里。集成方案设计有一条黄金法则一个数据项有且只有一个责任系统。物料主数据由哪套系统来创建和维护订单信息以哪套系统的数据为源是推还是拉是实时还是T1这些在蓝图阶段必须逐条确定下来。集成设计不是画一条线象征性地连着两个系统而是要细化到接口字段级至少要在蓝图里定义清楚接口清单和字段映射关系。4. 蓝图设计里的流程梳理方法论从现状访谈到底层设计4.1 流程清单与流程分类分级蓝图设计的第一步是把企业的流程全景图拉出来分门别类地记录它们的主干与分支。大型集团业务流程动辄几百条如果不分级分类设计会陷入混乱。流程分级通常按L1到L5来定义L1是流程域比如采购到付款L2是流程组比如采购寻源采购执行供应商管理L3是流程比如标准采购订单执行流程L4是子流程L5是操作步骤和系统字段级的说明。蓝图阶段一般要做到L3核心流程下沉到L4。L4的目标是业务和系统顾问能看懂产出后台配置的需求说明。流程分级还有一个实际价值帮实施团队控制范围。蓝图阶段业务部门常常会提很多细枝末节的需求流程分级可以让我们在对话时不断追问这个需求是L4还是L5的粒度、属于哪个L3流程粒度层面不匹配方案就容易跑偏。4.2 AS-IS现状调研不要放过单一数值和例外场景现状调研做得好不好直接决定将来方案是否好用。我总结出一套务实的调研清单不见得学术化但实用性很高每个流程当前要经过哪些角色和部门现在用的是哪套系统/Excel/手工方式处理一个典型业务单据的实际耗时是多少当前流程里的瓶颈和手工干预点在哪里经营层面的例外账务、特批业务、特殊规则数据质量的真实水平例如物料档案里有几条在用主记录、重复率多高不同岗位的真实需求特别是底层操作人员的核心诉求调研里最容易踩的坑是调研对象只讲正常流程不讲例外流程。例外的货物冻结、无合同发货、挂账开票等往往是蓝图中最容易被忽略的盲点而这些场景在业务真实运行中占比可能达到两成以上。我在每次调研提纲里都会专门设计一组问题这个流程在什么情况下会走不下去你会怎么处理有没有走特殊通道的情况这些问题的答案往往比正儿八经的流程说明更值钱。4.3 TO-BE设计的三步法找参照、架框架、钉规则TO-BE流程设计不能坐在会议室里拍脑袋我建议按三步走。第一步是先找行业参照。同行业、同等规模的企业是怎么设计这条流程的系统里有没有行业最佳实践可以参考这一步靠的是顾问的行业经验也是实施顾问最大的价值所在。第二步是搭整体框架。从核心价值流的角度把一个业务域里L1和L2级的流程关系先理顺明确流程之间的输入输出关系。不要一上来就沉到L4去画细节先搭骨架再填肉。第三步是钉规则。同一件事在不同子公司做法不一样怎么办哪几种做法是可以统一标准的哪些是必须保留差异的差异的触发条件是什么。这个统一与差异的取舍是TO-BE设计里最考验功力的一步。4.4 访谈与Workshop的组织技巧蓝图阶段的会议质量基本决定了蓝图的输入质量。我参与过太多次失败的研讨会几十个人挤在会议室里前面投影放着流程讲了十分钟就开始有人刷手机两小时下来结论是再商量商量。一些实操技巧访谈对象要分楼层集团层面由高层说话各子公司派业务骨干参加一线操作人员单独抽访。研讨会之前要把材料提前发出去要求参会人提前读现场只讨论不现场教学。另一个关键是永远不要放过沉默的部门。大型集团里总有一些部门在业务链条里存在感不高比如一个仓储部、一个质检部但是流程里卡脖子的却是它。访谈安排里如果漏了这些部门等流程图画出来再返工时间成本已经付出去了。5. 92页蓝图PPT的表达方式让方案看得见、翻得完、落得地5.1 页面组织的核心原则一页只讲一个观点蓝图PPT之所以容易糊是因为设计团队想把一个业务域的流程、组织、权限、表单全部塞进一页里最后出来的图线和框密密麻麻谁也看不懂。我的一页一观点的原则很简单这一页想清楚我要让评审的人看完之后记住什么然后围绕这一件事组织内容。讲流程就突出主链路的流向讲组织就把职责和边界说透讲集成就画清楚系统之间的通讯方式不要混着来。页数分配强烈建议做到心里有数总页数92页不是随手写的每部分约占比如下内容模块参考页数说明项目背景与目标4强调变革必要性现状与差距分析8从业务问题切入总体蓝图与原则12四层架构展开各业务域蓝图40每个域5-8页集成与数据架构12接口清单与数据规范实施路径与保障10上线节奏与里程碑附录与术语表4含风险清单合计90-92精准控制5.2 图文与表格的配合策略蓝图PPT里最常见的错误是全是图或者全是字。全是图评审会上看个热闹散会之后什么也没记住。全是字业务领导根本看不进去。图文搭配的一个实用法则观点用一两句话讲清楚放在页面顶部下面是支撑这个观点的图或表。如果页面下方要写字幕说明的注脚每个图旁边要配不超过50字的说明解释看这张图时应该关注什么。业务域的页面上核心流程建议用泳道图画法角色/部门用泳道纵向是时间或阶段顺序。泳道图比自由软流程图好看且容易理解。关键控制点用红框或三角标出来旁边用注释标明这个控制点是为了防什么风险。权限归属和审批规则用表格展示不要把十几个人名写进图里。6. 蓝图阶段最容易翻车的坑与避坑经验6.1 需求蔓延把所有的想要都装进篮子蓝图评审会上最常见的场景是业务部门看到流程图之后产生大量新想法说既然上了系统顺便把XXX也做了吧。这种需求蔓延如果不加控制蓝图范围会膨胀50%以上项目成本和工期都会失控。应对策略是在蓝图启动时就明确需求决策机制。建议设一个需求管理专员所有的新增想法统一记录在需求清单里每周评审一次。评审时用统一标准来判断这个需求是否支撑战略目标、是否合法合规、是否在合同范围内如果不在合同范围内要给出变更新增的工作量评估和时间影响。重点在于把评审会的焦点从能不能做引导到做了之后有什么代价、收益有多大的理性决策上。6.2 数据清洗责任不清上线前最大的地雷数据清洗这个事咨询顾问和业务部门经常互相推。顾问说我们有数据标准你去把数据整理好业务说我们不懂你们的标准你们来清洗设备部门又说我们的设备编码规则是集团的国标不能按ERP的规则改。为了避免这种扯皮蓝图阶段就建议把数据清洗职责写进项目章程。建议的做法是系统实施方负责定义数据标准和清洗规则业务部门负责根据标准整理各自的数据数据组负责数据的查重、合并与质量检查这个分工最大的好处是让业务部门理解到数据是他们自己的整理出来的数据本身就在服务自己未来的日常作业不是替IT干活。6.3 忽视了签字确认这个动作蓝图评审会上大家都说没问题散会后业务骨干在微信群里写一堆异议这种情况不是少见。如果蓝图没有明确的签字确认流程后期系统配置阶段一旦出现我当时不是这个意思我没同意这个方案的争议项目就会陷入麻烦。我的经验是蓝图评审不要只开一次会。第一轮是分业务域的专项评审解决专业问题第二轮是整体的高层评审解决资源与决策问题。两轮评审都要留下正式的会议纪要和蓝图签字页。签字页上要明确经确认后如需变更需走正式变更流程的字样这一句话能在后面几个月内帮你挡掉大量无效的需求变更。6.4 把顾问的标准方案当成万能药有些实施团队拿着厂商的标准方案到集团里宣讲一遍就完事美其名曰业界最佳实践。结果蓝图评审时被业务部门问得哑口无言因为标准方案里根本没有结合这家集团自身的管理特色和行业特性进行调整。这里的关键是把握好标准与定制的尺度跨行业通用的财务管理等可以放心采用标准方案而行业特性突出的业务环节比如某些港口的理货作业、某些制造集团的委外加工管理必须把行业洞察补充进去。蓝图设计不是不采用标准方案而是在标准方案上进行适配和演绎整理出真正适用于目标企业的方案。6.5 变革管理被当作上完线再做的事蓝图设计掺杂着大量组织层面的变革信息例如岗位职责调整、审批权力上收或下放、线下习惯变为线上操作。这些变化蓝图阶段如果不提前和基层做沟通上线时的阻力会非常具体。所以在蓝图输出的文档集中除系统设计图外我建议增加一份流程变化对组织与岗位的影响分析列出流程变化带来的岗位角色变化、技能要求变化、部门职责调整跟人力部门一起评估这些变化对人员编制和绩效考核的意义。这一步做在前面变革管理工作就不是空喊口号而是有了明确的工作计划和跟进抓手。补充一份92页设计和项目落地之间的联系聊到这里建议把92页蓝图文档在项目全生命周期中的定位讲透。它不是一份放在网盘里落灰的汇报材料而是后续所有工作的源头文件。详细设计阶段要对着蓝图把流程细化为可配置的功能点开发团队要照着蓝图里的接口清单去写接口说明书测试团队要按蓝图里的业务场景去设计测试用例上线切换时数据迁移范围也直接来源于蓝图主数据策略。蓝图如果质量不高后面这些工作要么返工要么凭各自的推演自由发挥。这也是为什么我一直强调蓝图阶段是花钱最值、省事最多的时期。前期多投入一天详细讨论主数据规则可能会帮项目减少上线初期几十天的手工整理工作量。从我这些年的项目经验看高质量的蓝图最需要的不是技术大牛而是懂业务、有行业经验、又愿意去倾听现场声音的顾问团队。他们在蓝图里做的每一条取舍都会在系统上线后的每一天里反复被验证、被使用成为企业数字化基座的重要底层支撑。