我们经常讲“抓核心问题”，但比核心问题更重要的是“边际问题”。
1. 核心问题和边际问题的区别
什么是企业的核心问题？核心问题就是阻碍业务价值流发生的难点问题。
什么是边际问题？边际问题就是影响核心问题的非关键因素。
“抓核心问题”这种口号，每个人都知道，真正的难点是如何识别什么是核心问题。
我们总认为自己就是那个可以一眼看穿问题本质的天选之人。真实情况恰好相反，我们找到的经常是看上去非常重要，其实是鸡毛蒜皮的小事。
如何识别核心问题？
正确的做法是建立一套有效的反馈系统，逐步逼近“核心问题”。
首先，假设我们发现的问题是核心问题；
然后，收集所有影响核心问题的因素，优先处理能处理的，剩下难以处理的就是关键因素；
最后，将所有关键因素重新搭建起来，审视一下重新组装后的问题，还是否是当初的“核心问题”？
如果是，则针对关键因素继续攻坚；
如果不是，要重新建立一套围绕核心问题的分析框架，重新走一遍以上循环。核心问题和关键因素之间建立起来的联系，就是核心问题的架构，这个架构稳定以后，就只需要攻坚关键因素了。
*Tips：
处理关键因素的时候，若是我们能掌控的，原假设的问题大概率是真问题；若关键因素是我们无法掌控的，那我们只是发现了一个伪命题，要果断舍弃。
为什么要先排除非关键因素呢？因为非关键因素好识别，不容易出错。
这些非关键因素的集合就是边际问题。
一家消费电子的大型研发企业，每年Q4开始制定第二年的全年财务预算。其中人力预算最难，因为要和大量部门沟通，先确定项目规划清单，然后逐一确认单项目概要预算，来回砍个三两次，最后汇总。
小李是这家企业的一名硬件项目经理，负责的是震动马达的预研与开发。一般这种项目规模也就3~5个人。今年公司规划了一个跨部门协同的项目，想让小李来带。项目是要根据不同的场景，从用户体验全链路出发，优化一系列的震动响应体验。比如，用户正在玩原神，针对不同角色，不同招式，触发不同任务情节等，都设计一系列的从感知到响应的震动体验。
这个项目的复杂度非常高，除了马达的预研与开发之外，还要协同软件的同事。而对于没有软件开发经验的小李，迈出第一步就非常困难，他不知道需要去找哪些软件工程师？小李找到当初规划项目的系统工程师老王，两个人先把需要的软件工程师列了一下，确认这些工程师大概在哪些部门。其中A部门，正好小李认识里面的一个陈工，从陈工那打听到，在小李要找的工程师都归属同一个中心下不同部门而已，这是一个好消息。接着陈工推荐了助理小蔡，她是这个大中心下项目管理部的助理。
小李兴冲冲的找到小蔡，解释一通后，希望能帮忙找到对应的研发。结果，留言发出去一天，到了下班也没有回复。第二天一上班，小李就给小蔡打电话。客客气气解释完目的后，小蔡那边只是一句，我也不知道找谁，然后就挂了。小李又一次陷入了困境。这都两周过去了，连个真正的对接人都没找到。没有办法，小李硬着头皮，直接拉了该中心负责人和自己部门领导建了一个群里，又把事情描述了一遍。幸亏大领导还是给力，立刻指派了资深项目经理董工对接。在董工的协助下，很快几个部门的相关技术代表就都聚齐了。大家在群里相互传资料，视频会议，充分研讨……到了周五，终于事情谈的七七八八了。
第4周的周三，小组成员开了一场线下会议，把前几天总结的项目范围和计划做了一次集中澄清，总共涉及软件的4个小组参与，每个小组提供1~4名开发人员。按照公司给的预算模板，4个小组分别去填写自己的人力投入。第5周周四，小李参加了硬件系统项目预算第一次评审大会。轮到小李讲自己项目的预算情况。刚打开共享文件，就发现软件研发四组的人力数据是空白。领导有点不耐烦了，后面还有几十个项目等着排队汇报，就让小李先讲下项目目前讨论的范围和目标，已经确认的人力情况等。小李闹了个大红脸，但还是要抓紧时间先从范围和目标开始讲。等到讲到人力预算的数据时候，软件三组的代表发话了：“这个人力数据不对吧，我让xx去填写的，xx你在线吗？怎么这个人力这么少……啊？你填错了表格，我们最新讨论的人力，你填写到另外的地方去了，没有汇总上来？”整个会议开完，领导对小李很不满意，让他下次一定把数据准备好了才上会。
开完会，小李不敢懈怠，每个组的成员一一电话沟通，保证所有人都准时获得正确的信息，也不断确认有没有把准确的人力数据填写到指定的共享文档里。到了第7周周一，第二次给领导做项目预算汇报，顺利通过评审。此时的小李已精疲力尽，同时和一二十个人打交道，实在是太难了，就是1~2个人月的数据，要确认清楚，都要沟通几个来回。1个半月的折腾，终于把200多人月的预算做完了。
第8周周一，所有项目的数据汇总到财务，准备两周后给公司高管汇报。这时候财务发现有几个部门的人力汇总已经超出了人力编制，要整改。小李立刻收到了来自董工的电话，说项目要砍预算。小李叹了一口气，心里埋怨，为什么开始的时候不能卡柱上限呢？
这个案例中，小李遇到的难题有3个：
1、沟通干系人多，每个项目至少2~3个协同部门。项目经理经常找不到正确的沟通对象。因为对接人实在太多，外加上不称职的接口人，一问三不知，沟通成本非常高；
2、预算过程版本难以管控统一。一般都是用Excel或者在线文档进行数据填写，如果填写规范没有明确，哪怕是一个项目名字都可能没法做到统一，最后都是一本糊涂账。不用说沟通中，人力数据经常变动，一会是没有估算准确，一会是哪位领导要增加一个内容等；
3、处理过程中，信息无法实时汇总和共享，就没有办法执行特定的约束，或者策略。比如一定要等到最后汇总，才发现A部门的人力投入超出原编制2~3倍；
那么其中什么才是非关键因素呢？
1、沟通关系人多，重要的是能快速分配正确的对接人。但企业一般有信息安全的要求，不能大范围公开研发成员名单。要先确认需要哪个开发组的人，然后才告诉你找谁具体谈。而这里的非关键因素就是能否快速的完成对接分配的工作，因为这个环节并不产生核心价值，真正的价值产出（关键因素）是项目经理找到承接小组，和具体做开发的人沟通项目目标和范围，才能做出人力评估。而对接人分配环节，极大制约了这个步骤的效率，所以我们应该先解决如何高效匹配正确沟通对象的问题；
2、数据版本多，难以管理。几乎所有的多人协作业务都会涉及到。开会评审材料时，一会这个数据有问题，一会那个数据有毛病。十几个人的会议最后讨论了个寂寞，结论就是重新对齐数据再上会。而对齐数据的过程又非常曲折，会有两种结果：
1）碰到负责任的牵头人，他会组织大家，逐一排查，追溯到每一条数据正确的版本并修正；
2）碰到二传手型牵头人，就直接在大群里@全员，发一条词不达意的通知，然后就不管了。等到上会前，再群发一次通知。最后还是一团乱糟糟的数据上会。这时候领导可能也疲惫了，糊弄一下就过了。
这种情况下，非关键因素就是数据版本如何管理的问题？有三点要做到：1）数据规范清晰，并且用IT约束。不需要更改的数据一定要固化，能用选项的一定不让大家手填；2）数据同源，只有唯一数据共享文件链接；3）管控变更，每个人只能改自己负责的部分，甚至是只能看到自己需要看到的部分；
3、过程信息实时同步。信息实时汇总到数据库，分层分级的看板展示统筹后的汇总数据。充足的信息让一线员工能第一时间处理问题，成本最低
【显性收益】我们把预算制定的边际问题都解决了，能得到什么呢？最容易想到的就是制定预算过程的效率提升。以我带过的真实预算项目为例，一般持续2个月，总共有400人参与，大约每人每周投入2人天左右。如果通过IT手段处理边际问题，可以解决一般的人力投入，且数据不会出错。
【隐形收益】预算制定，最核心的价值是对战略执行的可追溯性提供保障。如果最后输出的预算质量不高，就不能作为追溯战略落地的抓手。
为什么这个项目不做了？预算没有预留xxx部门的资源；这个项目是谁提出来的，之前没详细对过，开发的东西没什么用；我们部门有个需求要立刻解决，新增加一个项目，预算就从xx里扣一些，反正xx项目预算做多了一倍……
我统计过，一年150多个规划项目，真正符合预算规划并执行落地的不到40%（按目标，投入有效的人力执行。不包括，只需1个人就能做，却要了10个人的预算。虽然最后落地了，但是9个人都是空打卡）。最常见的是，以预算不准为借口，不按时投入。甚至，有的领导安排下属轮流打卡，造假完成工时任务。企业投资效率极其低，这里浪费的就是机会成本。
以800人年的预算来看，最多400人年是真正去执行了规划的项目，其余400人年都是浑水摸鱼。按现在大厂研发人员薪资60万计算，大约2.4亿的投入都是打水漂的。更有甚者，为了敷衍公司，投入一些毫无价值的项目，把部门人撑大，而且都是一些只知道巴结领导的无用之人。长久看，能人流失率会进一步升高，谁愿意跟垃圾们一起共事？这就是一个恶心循环。
但这一切，都可以因为一张信息准确的BP人力预算表而产生巨大的改善。
按照解决边际问题的思路，结合市面上的RPA+AI工具，能带来的效率提升远不止10倍。