一家年营收两亿的软件公司老板发现了一个让他头疼的问题销售部和研发部天天吵架。销售抱怨研发交付太慢研发抱怨销售乱承诺客户。老板先后尝试了三种解决办法——第一次他开了一场“团结大会”在会上语重心长地讲了两个小时“团队协作的重要性”。大家鼓掌表示赞同散会后该吵还是吵。第二次他调整了组织架构把销售和研发合并到一个事业部让一个负责人统管。结果负责人自己就成了新的“吵架中心”——两边都不满意他夹在中间焦头烂额。第三次他制定了一份《跨部门协作管理办法》洋洋洒洒写了二十页。发下去之后没人看也没人执行。老板崩溃了“为什么我用了这么多方法问题还是解决不了”我说“因为你一直在‘试方法’而不是‘设计机制’。方法和机制的区别是什么方法是‘头痛医头’机制是‘系统治病’。你需要的不是下一个‘方法’而是一套‘设计机制的方法’。”一、为什么很多“机制”最后都成了“废纸”在辅导企业的过程中我见过太多“流产”的机制——老板花了几十万请咨询公司设计了一套“完美的制度体系”结果推行了三个月就没人执行了。老板亲自起草了一份“绩效考核办法”结果员工抵触、中层敷衍最后不了了之。老板借鉴了同行的一套“流程体系”结果水土不服反而拖累了业务。这些机制之所以失败原因无非三个原因一问题没找准。很多机制的设计是基于“老板的感受”而不是“真实的问题”。老板觉得“员工执行力不行”就设计了一套“执行力提升方案”。但真实的问题可能是“目标不清晰”或“激励不到位”。问题没找准机制就是“药不对症”。原因二规则没共识。很多机制是老板或职能部门“闭门造车”设计出来的没有让“使用者”参与。结果设计者觉得“很完美”使用者觉得“很难用”。没有共识的机制注定会被抵制或敷衍。原因三落地没闭环。很多机制设计出来后发个通知就算“推行”了。没有培训、没有试点、没有反馈、没有迭代。机制成了“挂在墙上的装饰品”而不是“嵌入日常的操作系统”。要解决这些问题你需要一套系统的方法论——机制设计五步法。二、第一步定义问题——找到“真问题”而不是“表面问题”机制设计的第一步不是“写规则”而是“找问题”。很多老板在发现问题后急于给出解决方案。但如果没有搞清楚“真问题”解决方案就是“瞎开药”。怎么做1. 区分“现象”和“问题”。现象销售部和研发部天天吵架。问题为什么吵架是因为目标不一致信息不对称责任边界模糊还是利益机制冲突现象是“冰山之上的部分”问题是“冰山之下的根因”。2. 用“5Why分析法”深挖根因。为什么销售和研发吵架——因为销售承诺了研发做不到的交期。为什么销售会承诺做不到的交期——因为销售不知道研发的生产排期。为什么销售不知道研发的生产排期——因为没有信息同步机制。为什么没有信息同步机制——因为没有人觉得这是“自己的事”。根因缺乏一个“销售-研发信息同步”的流程和责任人。3. 把问题“写清楚”。模糊的问题“跨部门协作不好。”清晰的问题“销售部在签约前无法获取研发部的产能信息导致承诺的交期无法兑现平均每月因此产生5起客户投诉。”清晰的问题定义是机制设计成功的50%。三、第二步分析根因——找到“病灶”而不是“症状”找到问题之后不要急着“开药方”先做“病理分析”。怎么做1. 从三个维度分析根因。机制维度现有的制度、流程、规则是否存在缺陷比如没有信息同步机制、考核指标冲突、责任边界模糊。能力维度相关人员是否具备完成任务所需的能力比如销售不懂技术所以不知道什么承诺是合理的。意愿维度相关人员是否有动力去解决问题比如研发的考核是“按时交付”所以他们不愿意为了销售的承诺而调整排期。2. 区分“主要原因”和“次要原因”。用“帕累托原则”80/20法则找出那20%的主要原因。优先解决主要原因次要原因可以后续处理。3. 画出“因果链”。把问题的因果关系画出来让团队成员都能看到“问题的全貌”。这有助于达成共识避免“各说各话”。四、第三步设计方案——从“根因”到“规则”找到根因之后开始设计方案。这一步的核心原则是“对症下药而非头痛医头。”怎么做1. 针对根因设计解决方案。如果根因是“信息不对称”解决方案就是“建立信息同步机制”。如果根因是“考核指标冲突”解决方案就是“调整考核体系”。如果根因是“责任边界模糊”解决方案就是“明确RACI矩阵”。2. 遵循“最小可行机制”原则。不要试图“一步到位”设计一个“完美”的机制。先设计一个“够用”的版本跑起来之后再迭代。一个机制如果超过一页纸说明它还不够“最小可行”。3. 让“使用者”参与设计。邀请一线员工参与讨论听取他们的意见和建议。他们最清楚“什么好用、什么不好用”。参与感本身就是“执行力”的一部分——自己参与设计的机制执行起来更有动力。4. 设计“配套工具”。机制不能只停留在“文字”层面要有配套的工具支撑。比如流程图、检查表、模板、系统。工具越简单执行越容易。五、第四步试点验证——在小范围内“跑通”再推广很多老板犯的错误是机制设计出来后马上在全公司推行。结果一出问题就全盘否定机制“夭折”。正确的做法是先试点再推广。怎么做1. 选择“试点单元”。选择一个最适合的团队或部门作为试点。这个团队应该有“代表性”且负责人愿意配合。不要一开始就在全公司推行风险太大。2. 设定“试点周期”和“成功标准”。试点周期一般1-3个月。成功标准什么样的结果算“成功”比如销售-研发信息同步率达到90%、客户投诉减少50%。3. 在试点中“观察”和“调整”。密切观察试点的执行情况收集数据和反馈。发现问题及时调整不要等到试点结束再“秋后算账”。机制是“跑”出来的不是“设计”出来的。4. 试点成功后总结经验。试点结束后总结“什么做对了、什么做错了、什么可以优化”形成“最佳实践”为全公司推广做好准备。六、第五步推广固化——让机制“嵌入”日常工试点成功之后就可以在全公司推广了。但推广不是“发个通知”而是“系统落地”。怎么做1. 培训宣贯。让所有相关人员理解“为什么要推行这个机制”“机制的内容是什么”“他们需要做什么”。培训不是“走过场”要确保每个人都能“听懂、记住、会用”。2. 配套激励。在新机制推行的初期需要配套激励措施来引导行为。对“执行得好”的团队和个人给予奖励对“拒不执行”的给予适当惩戒。3. 建立反馈渠道。让一线员工可以随时反馈“这个机制哪里不好用”。对有效反馈给予奖励让员工成为机制的“共建者”而不是“被动执行者”。4. 定期复盘迭代。每季度或每半年对机制进行一次复盘。看看机制是否还在发挥作用是否需要调整是否需要升级机制是“活的”不是“死的”。要随着业务的变化而不断进化。七、一个完整的案例用五步法解决“销售-研发扯皮回到文章开头的案例。我用五步法帮那家软件公司解决了销售部和研发部的扯皮问题。第一步定义问题。通过5Why分析我们发现根因不是“销售乱承诺”或“研发太慢”而是“销售在签约前不知道研发的产能信息”。这是一个“信息不对称”问题。第二步分析根因。从三个维度分析机制维度没有“销售-研发信息同步”的流程。能力维度销售不懂技术不知道什么样的交期是合理的。意愿维度研发的考核是“按时交付”没有动力配合销售。第三步设计方案。针对根因设计了三个机制信息同步机制每周一上午销售和研发开30分钟的“排期对齐会”同步本周的订单情况和产能情况。能力提升机制每月一次“产品技术分享会”由研发向销售介绍产品功能和开发周期。考核调整机制在研发的考核中加入“销售满意度”指标权重20%。第四步试点验证。选了一个产品线作为试点试运行两个月。第一个月还有一些磨合问题第二个月基本顺畅。销售-研发信息同步率从30%提升到了95%客户投诉减少了60%。第五步推广固化。试点成功后在全公司推广。配套了培训、激励和反馈渠道。每季度复盘一次持续优化。半年后销售部和研发部的扯皮基本消失。老板跟我说了一句话“以前我靠‘劝’和‘骂’来解决问题现在我发现靠‘机制’才是最省力的方式。”八、给老板的“机制设计”自查清单如果你正在设计一个新的机制请对照以下清单自查第一步定义问题。我找到的是“真问题”还是“表面问题”我有没有用5Why分析法深挖根因我能不能用一句话把问题说清楚第二步分析根因。我从机制、能力、意愿三个维度分析了吗我找到那20%的主要原因了吗我和团队对根因达成了共识吗第三步设计方案。我的方案是针对根因的吗我的方案是“最小可行”的吗我让使用者参与设计了吗我有配套的工具吗第四步试点验证。我选择了合适的试点单元吗我设定了明确的试点周期和成功标准吗我在试点中及时观察和调整了吗第五步推广固化。我做了充分的培训宣贯吗我有配套的激励措施吗我建立了反馈渠道吗我有定期复盘的机制吗机制设计是一门“手艺”很多老板把机制设计看成“写制度”——找几个模板改一改发下去就行了。但真正的机制设计是一门“手艺”。它需要你像医生一样先诊断再开药。它需要你像工匠一样精雕细琢、反复打磨。它需要你像园丁一样播种、浇水、施肥、修剪让机制“生长”出来。机制设计五步法就是这门“手艺”的基本功。定义问题让你找准方向。分析根因让你对症下药。设计方案让你有章可循。试点验证让你降低风险。推广固化让你落地生根。掌握了这五步你就不再是“头痛医头”的救火队长而是“系统治病”的组织设计师。机制设计五步法从“问题”到“规则”到“落地”的闭环
