基于商业模式画布的产品规划分析和思考总结

基于商业模式画布的产品规划分析和思考总结

今天基于商业模式画布的思路来谈下我们自己的产品规划分析,对于商业模式画布的概念已经提出多年,出现在商业模式新生代这本书里面,因此在谈结合商业模式画布的产品规划前,仍然是先初步整理和归纳下对商业模式画布核心内容的理解。

商业模式画布

基于商业模式画布的产品规划分析和思考总结

商业模式描述了企业如何创造价值,传递价值和获取价值的基本原理。再看下现在的价值营销,基本也是这个思路。

对于商业模式我前面给出一个核心内容即可持续的盈利模式,一个是需要盈利,一个是可持续。而现在我们来回顾这个说法并不完全正确,包括当前很多处于亏损状态的企业仍然能够IPO和上市并得到大量投资机构的认可。

在商业模式新生代这本书里面,将商业模式分为四个视角,基础设施,提供物,客户,财务,然后再延展到9个核心要素。前面三个视角即如何提供,提供什么,为谁提供,再回来看这三点刚好又是经济学经常说的最基本的内容。

商业模式九个基本构造块:CS客户细分,VP价值主张,CH渠道通路,CR客户关系,RS收入来源,KR核心资源,KA关键业务,KP重要合作,CS成本结构。形成了商业模式画布。对于该书的重点就是该书对商业模式的问题进一步进行了结构化和可视化,给出一套商业模式的要素和围绕这些要素的分析方法。

基于商业模式画布的产品规划分析和思考总结

价值主张是商业模式的核心

价值,或者说一种可持续的价值主张,不论是提供的产品还是服务,都是商业模式最核心的问题。定位的重点就是价值主张,在STP思路下是首先分析了市场需求,确定了目标市场和客户细分,在清晰的勾划出明确的定位和价值创造。

为何这点如此重要,个人的一个理解是只有这种模式VP和CR间的关系,在明确的价值主张下是市场驱动了销售,而非无目标的销售约束了市场。

对于整个画布的顺序的理解

首先是打通从价值主张到客户细分的收入线,其次才是进一步打通根据基础设施和资源能够创造价值的价值提供线,最后再统一汇聚到成本结构和收入来源统筹考虑的财务线。

所有的价值体现最终都将汇聚到最终的财务管控上的可持续盈利上面。

渠道,传统的4P(产品,价格,渠道,促销)营销理论的核心内容,过渡到进一步关注客户的4C(顾客,成本,便利,沟通),再过渡到4R理论(关联,反应,关系,回报)。关联重点是CR客户关系的长久维持,反应体现竞争,而回报真正融合了成本和收入两方面的内容,即价值驱动下的可持续盈利。

关于盈利之重点在于是否可持续性上面,其实这是我们在进行定位和价值创作,以及模式思考的一个核心问题。对可持续的思考带来了对价值创造的深入思考,需要将价值创作分为两个层面来考虑,即基础价值创造,增值服务价值创作

注:基础价值创造是拓展市场和建立客户关系,增值服务是在市场规模壮大后的长尾思路下的持续盈利。没有此处的思考不能算一个完整意义上的价值主张和价值传播思考。

CH渠道是建立产品提供物和客户间的通路,而CR客户关系是后续的维护。渠道是一种销售达成前的行为,而客户关系是销售达成后的行为。客户关系的重点往往是一个销售后的行为,却可能转化为一个市场传播行为,进一步拓展渠道和增加客户。

基础设施-关键业务和核心资源

在基础设施层面有两个重要的内容,一个是关键业务,一个是核心资源。注意是关键业务实现价值主张,而核心资源支撑关键业务。而不是核心资源实现价值主张。

为何明确的提出这点,就是是企业的核心价值链创造了价值,而关键资源只是价值链中的一个要素而已。在只谈资源不谈业务系统的时候,最大的问题就是没有明确的业务模式来支撑价值创造,或者说企业核心的业务能力没有沉淀。以关键资源构建商业模式推荐的方法更多的应该是对企业内部价值链上的能力要素进行整合,以创造更加具有竞争力的价值链产品。

注:对于很多软件企业同样存在类似的问题,即整个公司的核心全部依托在关键人力资源上,而没有构建公司的核心业务系统和可沉淀业务资产。

采用客户视角是整个商业模式设计过程的指导原则。应该让客户视角来指引我们关于价值主张、渠道通路、客户关系和收入来源的选择。我们最终定位出来的价值主张,生产出来的产品如果不是客户想要的,自然无法转换到收入来源和实现赢利。

基于商业模式画布的产品规划分析和思考总结

最后对于商业计划书有市场驱动和技术驱动两种讲述方式,最近看到很多人在谈论商业计划书的问题,个人认为该书给出了一个很好的讲述思路和方法。

市场驱动讲述重点是首先STP模式确定清楚定位和价值提供,进一步分析到客户关系和渠道建设,产生收入来源;再来考虑核心业务价值链的构建,基于核心业务价值链来分析关键资源的获取和利用,产生成本结构;最后从成本角度来分析盈利和财务健康情况。

技术驱动则是首先根据关键业务和核心资源来主动考虑价值创造,最后再来考虑细分目标市场和客户,通过营销模式产生收入来源。个人理解是技术驱动型更加看重的是长远目标和对技术趋势的把控,在技术驱动模式下没有前期大量资金投入很难真正保证持续的现金流供给。

对产品规划分析的再思考

基于商业模式画布的产品规划分析和思考总结

实际上我们在规划一个新产品的时候,一定首先考虑的就是产品本身的价值主张,即产品为客户提供的最终核心价值究竟在哪里?最终的上游资源,合作伙伴,解决方案,下游的客户和渠道最终都是为产品的价值主张服务。

任何一个产品推出,一定是能够解决某一个特定领域客户的痛点问题,你解决的越高效,越智能,那么产品的核心价值就越大。

在考虑自研ESB产品的产品规划时,对于中小型企业,包括信息化薄弱的中大型企业,ESB总线都不是直接业务需求驱动的产品,同时也属于是可有可无的产品,即企业整体的IT规划架构,集成架构的复杂度还不足以让企业意识到需要上一个重量级的ESB服务总线,甲方IT部门本上的IT治理管控水平也不足以需要上ESB总线。而对于轻量的SOA总线或服务网关产品,网上找一个开源的往往就能够先凑合着用起来,也很难真正原因花钱去实施ESB产品。

从价值主张角度,对于大型大型集团型企业和中小型企业述求完全是不同的。

  • 大型集团型企业:IT建设的复杂度已经迫切需要上ESB提供IT治理管控水平
  • 中小型企业:通过ESB来减轻接口定义,开发,测试,部署的工作量并自动化

由于价值主张不同,那么你产品研发的侧重点就会不同,对于大型集团企业重点是后期的SOA管控运维,性能监控分析能力;而对于中小企业可能更多的是老的DB,FTP,JMS各种接口快速适配和发布。

因此,价值主张的核心仍然是在理解市场,理解用户后,对市场和用户的细分,只有细分市场后,才能够有针对性的提出产品研发的核心价值,明确目标受众。

虽然我们已经自主研发ESB和实施SOA项目很多年,但是发现自研ESB总线离产品化还有不小的距离,导致我们ESB总线仍然需要搭配一定的实施工作量。而对于大型企业实施SOA项目,由于采用国外类似Oracle SOA套件产品,我们本身基于产品进行实施,并定制开发SOA管控治理平台,在这种模式下我们的实施,SOA整体管控反而变成了核心竞争力。

一个软件如果越容易被产品化,那么它的价格就一定会不断的降低,因此很多时候一味的强调产品化往往并不是好事。

而真正重要的还是基于我们实施对整个SOA方法论的落地能力。

包括对于SOA,在价值主张上,我们前面也很多文章在谈到,企业实施SOA,不仅仅是提升了整个IT管控治理水平,更加重要的是帮助企业的CIO提升在企业中的地位和话语权,如果是CIO推动的SOA项目,这一点价值主张在说法CIO上是相对重要的内容。

上游和下游协同

基于商业模式画布的产品规划分析和思考总结

对于关键合作伙伴,客户,客户关系和渠道等可以归类到上游和下游里面来统一思考。以后对于大型项目,特别是对于大型的IT平台型项目你会看到,更多的都是大集成类的项目,需要上下游高度协同往往才能够完成整体项目的实施和交付。

类似Oracle,当前更多的是我们的合作伙伴,即销售机会和售前的来源,因为大型集团型企业往往一开始就选中国外大型ESB总线产品,而不会选择类似我们自研的ESB,而我们更多的是为Oracle SOA产品提供咨询和产品落地实施服务。这本身就是很好的一个上游渠道。

对于集团型大型企业很多有ESB总线产品的需求,类似刚才的Oracle伙伴是很好的一个切入点,同时类似找到其它有市场资源的合作伙伴也是很重要的一点。否则对于大型项目实际要在公开招标中切入相当困难。

而对于下游的合作伙伴,这几年对我们的产品线或产品,不是在扩张,而是进一步聚焦和收缩,专注在我们的核心价值提供上。当这种收缩后你核心产品能力提高了,但是可能你就很难做大而全的所有功能,即我们可以提供大而全的整体解决方案,但是里面的部分子系统一定要找外围的合作伙伴去集成,而不是全部都自己开发。

从问题到解决方案


基于商业模式画布的产品规划分析和思考总结

当我们提出价值主张的时候,实际上已经明确了关键的客户需求或问题,并提出了有针对性,包括可能有通用性的解决方案去解决,并进一步抽取产品的核心价值主张。

产品价值主张一定是问题驱动的,并一定能为客户带来价值。

在原来谈售前解决方案制定的时候,我就提出个一个关键的概念,即将客户的需求和问题进行分解,在分解完成后给出完整的解决方案,同时将解决方案能力映射到我们当前完整的产品上。

即针对不同的问题和场景,虽然我们的产品是一套产品,但是我们解决方案可以是多套,我们需要根据实际客户的问题和痛点,来思考究竟给出什么样的解决方案才是最重要的。比如:

  • 有的客户的关键诉求是短平快,价格低
  • 有的客户的需求是提升后期整体IT管控治理水平
  • 有的客户需求是减少对各种软件开发商的依赖和绑定
  • 有的客户需求是提升IT部门的IT服务能力和话语权

那么对于不同的问题和诉求,我们解决方案的重点都不同。关键是客户真正的痛点和问题,要能够和你的解决方案去匹配,将客户真正关心的点体现出来。

关键资源,如何去实现解决方案

这里面只有两个关键问题,第一就是你输入的需求是否是真正的需求,第二就是你当前的研发团队是否真正能够高质量,高效率的按需求开发出需要的产品。我们可以看到,一个产品真正搞砸原因主要包括以下几个方面:

  • 有真实需求,有好的产品实现,但是市场和营销太差了,酒香也跑巷子深
  • 有好的产品实现,客户关系和渠道也很好,但是做出的产品不是客户真正需要的
  • 有真实需求,也有明确市场,但是自己研发团队没有把产品和交付做好,搞砸了

我们现在很多创业团队,往往就是在犯这个两个方面的错误,一方面是自己凭空想需求,自己给出很多无法实现的假设,最终产品推不出去;其次就是市场在,需求也很明确,但是研发团队效率低,质量差,第一波用户没逮住,丧失了竞争机会。

你的产品的竞争壁垒是什么?

基于商业模式画布的产品规划分析和思考总结

实际上这个是最难回答的问题,产品的核心竞争壁垒究竟在哪里?

要称得上竞争壁垒,那么一定不是你的竞争对手能够快速的模仿和开发出来的核心产品功能,如果是的话那就根本谈不上产品核心竞争壁垒。我们大大小小做了相对多的软件项目,也孵化了很多小的产品,但是真正实现能够批量产品化的基本没有。这里先不说竞争壁垒,而是产品一丢到市场上去你会发现,你本身竞争力就弱,更加谈不上你有哪些差异化的优势。

如果不专注,不持续在一个产品上长期投入和积累,那么就很难真正形成竞争壁垒。

而既然谈到产品化,那么我们的核心竞争力是在产品核心功能上面的,而不是在最终产品咨询规划和实施上面的,这样这个资产才能够真正落地。

类似ESB产品,我们可以说竞争优势在大数据和大文件的集成能力上,在服务封装接入的全自动化上,但是很难说在性能和高可用性上面,因为对于基本的性能和高可用性是所有ESB产品都必须具备的。从差异化竞争角度,对于ESB总线类产品,你完全可以考虑提供部分MDM主数据的能力,这种错位的产品融合往往更加具备竞争力。即客户一个项目同时解决了SOA和MDM两个方面的问题。


分享到:


相關文章: