业务架构_优化“价值主张画布”,助力企业数字化赋能
发布网友
发布时间：2023-02-25 23:04
共1个回答
热心网友
时间：2024-12-04 14:27
本人近10年都在从事企业数字化转型相关事宜，尤其近4年重点在做2B数据中台和数据应用产品。为了方便大家能更好得把“价值主张画布”真正用起来，更好得助力“企业数字化赋能”，谈谈个人目前对此画布的理解和建议。
1. 这张价值主张画布, 逻辑上看着很清晰， 主要强调的是“解决方案”要和“客户问题”相对应。
2. 但把“客户问题”分为"Pains”和 “Gains”, 容易产生重复和混淆。
对于同一个问题A， 从负面的角度来感受, 它就是 "Pain"（痛点），会出现在画布右边下方的“Pain区域”; 如果这个痛点问题解决了, 就会带来"收益"，换成正面的描述方式，就可以出现在画布右边上方的“Gain区域”。（大多数人会把“Gains"理解成“收益”）
与此同时，画布左边的解决方案，分成了上下2个区域，"Pain Relievers"的方案对应解决的是右边下方“Pain区域”的问题；“Gain Creators"的方案对应解决的是右边"Gain区域的问题。但对于我们这个case, 实际上解决的是同 1个问题。
这么分析下来，对于企业数字化建设而言，把右边问题区域分成"Pains, Gains”, 容易造成重复和混淆，并不是一个合理的分法。
3. 在企业数字化实践过程中，有 2 类主要问题，若能解决好，都能贡献业务价值 ：
一类是“痛点”（业务用户/外部客户，已感受到痛苦，期待解决）；另一类是“甜点”（往往是些创新点，用户尚无感，但如果做出来的话，可以带来明显的增值或让客户兴奋）。这2类问题，都需要解决；但都可以根据实际情况，选择短期临时解，或长期解决方案。
与此同时，老板们也越来越务实，不仅仅满足于定性的描述（“能带来这方面好处，那方面好处，......”），也需要有些定量的数字(比如: 新增收入, 新增利润等指标) 来看相关IT投入带来的业务价值产出，以便判断ROI是否合理，是否值得投入。
综合上述分析，我们在思考"企业数字化相关产品"的价值主张时， 个人建议采用优化后的 “ 价值主张画布 ”， 如下 ：
大的来说， 把 “ 价值主张画布 ” 分成 2 方面 ：一方面，是给老板们讲故事： 解决哪些痛点、哪些甜点，涉及哪个系统 / 功能，大概怎么解决； 另一方面，是向老板们立军令状（圆圈图，右上角区域的 Outcome/Benefits）： 如果老板们给予支持，能在哪方面、产出多少业务价值，便于日后度量产品或项目是否成功。
这么调整以后，价值主张画布各模块的逻辑会更加清晰。
1. 如果只需针对单个/ 单类别用户角色拟制"价值主张画布", 可参考上方的改进模板，针对具体的某1类客户角色，逐步列出痛点和甜点，并分别找出其短期临时方案 和 长期解决方案，然后总结出对客户的benefits, 这么一步一步就画出来了。(模板改进以后, 更符合MECE原则,不同模块之间不易重复和混淆 - 某个"需求点" 或 某个“方案”到底应该归入哪个模块/象限，变得更加简单清晰。）
2. 如果某个事业部或业务单元，有多种 “ 客户角色 ” 需要考虑 ，可以把主要角色分别画出来（以便于，分别针对特定干系人群体进行交流），最后需要进行梳理、合并，形成一张包含量化指标的画布。（不同企业可能要求不同，有的要求KPI, 有的要求OKR）
3. 如果某个 IT 产品 / 功能 , 有可能在集团里的多个事业部进行复用 ，建议您针对每个事业部分别画1张价值图, （便于和不同事业部交流，另外给业务高层介绍时可着重突出该事业部与其它事业部的不同之处。）最后，梳理、合并成一张集团层面的价值主张画布。（考虑到不同事业部，准备就绪的程度可能不同，具体实施会有先后，往往需要附以Roadmap, 以便集团高层能看到覆盖各事业部的整体落地计划。）
补充说明 - 原模板中的 Gains（收益）, 已被改进版的 "Benefit/Outcome"所取代。对于Role级别的画布, 只要能把"Benefit是什么"说清楚基本就可以了, 对于"事业部"/"集团"级别的画布, 在和事业部/集团高层汇报时, 需要提供 Outcome相关的KPI/OKR指标，以便于高层更直观的判断ROI、并进行决策。
希望这张优化后的价值主张画布，有助于大家更轻松得把画布用起来！更好地助力企业数字化赋能！
