B端产品的“全场景化、数字化、互联化、智能化”渗透，最终将形成平台化。
百度百科：
平台化是基于产业全链数字化相连而提供端到端的优质体验和差异化服务，保持运营的效率和灵活性，同时降低供需双方的交易成本与摩擦成本。我们可以看到，平台化是一个综合性的过程，主要可能涉及的创新就有服务创新、商业模式创新、客户体验创新、运营创新、组织创新。
未来的十年是产业互联网的时代，产业互联网的特点是数字化。
这意味着 各行各业急需数字化转型，行业想要转型离不开互联网管理系统（B端产品）。
AI大火、云计算集中爆发、5G商用、SaaS成抢跑赛道……所有新兴信号汇聚在一处，开始讲述产业生意的新故事。
在过去的这一段时间里：
我们见证了腾讯toB的决心，看到了金蝶云、Ucloud的破茧之路，体验了下沉市场过程中通过产业给小B带来的变化。
看到各个行业的种种变革，为了不让自己更被动，需要B端产品经理提前做好设计规划。
我在平时的工作中，总结了引领B端产品设计的四个理念，分别是全场景化、数字化、互联化、智能化，满足并超出客户的期望。
一、最常见的现象
我在工作中也会遇到这样的问题：严格按照客户的要求，辛辛苦苦开发出来管理系统，客户还是不满意。
不知道是否和大家一样？
为什么？
因为不深入客户现场，无法理解业务场景，无法获得真实的客户需求，从而无从谈起研发产品。
B端客户特征
我通过和客户的沟通，发现这个问题和B端客户特征有关系：
- 国内中小企业（小B）生命周期短、付费意识不强，五花八门的个性化需求。
- 大型客户（大B）虽然受政治或管理层影响极大，但付费能力强，也都急需管理标准化。
二、危机意识
它们所处的行业，原来都是管理者和员工线下去操作，去管理，但随着各行各业互联网工具的普及，这些行业的管理者们发现了一些问题：人力成本居高不下，信息反馈不及时，信息不对称等问题不断冲击的自己熟悉的领域，让自己逐渐失去了竞争优势。
于是，开始满世界寻找各种互联网软件，希望能帮助他们解决现在面临的问题。
但是行业是快速发展的，当B端客户购买完当前的管理系统，行业已经发生了变化。
当他们看到其他行业或者竞争对手有了新的管理系统，一定会提出新的要求，需要更多的功能来支持当前的变化。
三、行业发展方向引领产品设计
通过收集他们的需求反馈，你能感觉到这些行业想要发展的方向，希望产品设计提供一些参考。
1. 全场景化
现在一些B端客户，沿用了C端产品的思维，已经开始从线下和线下的多个场景触达用户。
比如：
- 现在的超市，顾客不仅通过线下传统的门店购买，还可以通过线上购买，实现及时配送。
- 原来已经发展了二三十年的传统制造企业，开始开通天猫、京东、云集、拼多多等线上平台。
- 一些高校继续教育学院开始通过建设门户网站，展示学校相关的培训信息，做SEO优化来增加面向C端客户的触达机会。
这就要求B端产品需要增加CRM管理、订单优惠管理、分销管理，移动办公管理等相关功能。
所以，这些不同行业，不同单位的管理者们都想通过多种用户场景实现线上和线下的融合。
2. 数字化
客户与产品经理沟通的时候，都会提到一个统计的功能，希望能按照自己行业的要求和规范，统计出自己想要的结果。
比如：
- 新零售行业统计各个产品的在各个阶段的订单销量，付费情况。
- 办公管理系统，希望统计各个月员工考勤情况，财务审批情况。
- B端客户希望通过平台采集到用户行为数据，消费数据等，进行可视化展示。
最明显的现象，就是最近各个公司和政府/事业单位开始采购用来展示数字化的大屏。
3. 互联化
B端产品管理的是一整套业务流程，各个部门的人员都会参与进来，于是采购系统的管理层，希望做成一个闭环，各个部门通力合作，把各个部门都会产生数据，放在一起比较，这些数据才有意义。
比如：
教育行业做招生部门的数据，他们的转化率，不仅和自己的广告投放渠道有关，营销话术有关，还和课程设计的质量，辅导老师的业务能力有关。
整个流程产生的数据，如果不沟通，不互联，就找不到解决问题的源头，提高不了转化率。
B端客户如果能通过管理系统实现数据整合，找到哪些流程需要改进，能够降本增效，较少库存与维护成本，才是真的实现事半功倍。
所以，B端客户需要协同，需要构建各个部门的线上、线下的流程，把数据统一起来做比较。协同互联，会让你的收入成曲线指数型上升。
4. 智能化
智能化的发展离不开大数据的支持，由于大量的数据融合到一起才能形成行业的标准。
B端客户引入标准的目的就是为了提高效率。
于是技术推动行业发展，创造出网格式的智能决策辅助管理系统，这样的管理系统才能真正赋能当前行业。
比如：
我们国家刚刚投入使用的北京大兴国际机场，就有很多智能化应用，最常见的就是根据人脸特征进行识别，检索乘客航班信息，然后利用大数据，给出其他提示信息，充分显示了机场的智能化程度。同时，乘客取票也可利用人脸识别系统完成。
我们的餐饮行业开始基于互联网和云计算技术为餐饮店量身打造的智能管理系统，采用自助点餐机、智能炒锅，智能机器人送餐等互联网智能化手段、来进一步节省餐厅中的员工数量、降低经营成本、提升管理绩效的综合因素。
我们的煤矿行业采用VR/AR/AI技术，给矿工强烈震撼式体验极大提高安全警示效果，提醒矿工平时容易忽略的致灾难的小细节。
未来在智能化的时代，B端客户希望能够通过管理系统把用户行为精准分析出来，提高自己的服务品质，才能获得更多的用户信赖。
过去的5-10年是消费升级，实现了消费场景的数字化和互联化，那么未来十年，B端产品如何发展？
B端客户希望通过全场景化、数字化、互联化、智能化来帮助自己，让自己活得更好，让自己在当前行业，当前领域实现差异化竞争。
这就要求B端产品经理，在发挥自身产品设计和用户体验优势的同时，将这四个概念渗透进来，在提升效率和缩减成本的原则下，让自己的产品超出客户的预期。
这四个概念的实现，最终形成平台化，我相信一定能够改变生产关系，让生产关系从博弈到共赢，实现新型组织的管理和创新。
转载： http://www.woshipm.com/pd/3074249.html
———————我是分隔线——————————
从产品角度来看，电商业务的需求有两个特点，业务需求多且繁杂；业务需求时效要求极高。这两个特定是由电商的特点决定的。对于电商来说：
1、消费者流失门槛低。对于电商来说，消费者流失门槛极低，因此需要时刻紧盯消费者的一举一动去讨好他们，偏偏人又都是喜新厌旧的动物，因此需要经常进行业务上的调整；
2、电商已是红海，同时行业抄袭成风，因此有新的业务机会需要尽快上马，战机稍纵即逝。
面对这两个业务上的特点，容易导致的情况是，开发同学被业务同学推着走，一见面就是这又有XX个需求，都很急啊，先做上线再说吧。这会导致的问题是，在如此短的时间内上线功能，难以进行系统性、全局的考虑，导致新的业务逻辑在原有系统逻辑上，像打补丁一样一块接一块，最后系统不堪重负，从而使整体的效率及稳定性降低。面对这样的问题，一般大家都会采用系统重构的方法来解决。
俗话说得好，船小好调头，小的系统重构起来很简单，大的系统上跑的业务多，依赖多，业务逻辑复杂，重构成本非常高，还是要尽量减少重构系统的次数。在不得不重构系统的情况下，怎么重构系统，才能在开发效率要求越来越高的情况下，实现可持续发展，尽量减少系统重构次数呢？这就涉及架构设计的问题。一个合理的架构，可以在提高开发效率的同时，使系统的可用性越来越高。
这就要有请我们本次文章的主角，平台化出场了。
在我的理解，平台化是一种底层功能的架构方案，其实现的是将业务从业务耦合，多头管理，刚性支撑到业务分治，归口管理，柔性支撑的架构转变。
这么说可能不太好理解，让我来解释几个概念：
1、业务耦合-业务分治
这里说的业务耦合，并不是指正常的业务耦合，而是是指过紧的，不健康的耦合。
与其对应的概念是业务分治，指的是业务分别治理，依赖业务之间保持较松的，健康的耦合关系。在业务发展初期业务较少的情况下，新业务处于摸索阶段或者业务边界模糊不清的情况下很容易出现业务耦合的情况。后续随着新业务、模糊业务中的双方都越来越复杂之时，若没有及时解耦，耦合就会越来越紧，系统维护成本原来越大，最终影响到两方各自的发展。
平台化，目标之一实现的是从业务的不健康耦合到健康耦合的转变，这就要求要划清业务边界，同时推动耦合双方共同完成解耦。
2、多头管理-归口管理
多头管理是一个下级同时接受多个上级领导的现象，在实际业务场景中，表现为一块业务，由多个团队进行维护的现象。这种情况导致的弊端主要有三个：
- 负责团队多，互相踢皮球；
- 不同团队之间团队墙导致的沟通成本过高；
- 业务难以标准化，业务方接入成本高。
无论如何，都是弊大于利。而归口管理，则是按业务范畴进行分工管理，不同团队，不同系统，不同模块各司其职，业务边界分明。平台化，目标之二是实现业务归属从多头管理到归口管理的转变，这要求明确业务功能，明确团队职责，确定接口团队，统一维护业务。
3、刚性支撑-柔性支撑
先来说柔性支撑。柔性支撑是从柔性供应链借鉴来的一个概念，是指外部的需求在需求小批量，多批次，时效要求高的情况下，以合理的成本水平迅速满足业务方需求的能力，需求完成的越迅速，付出的成本越低，其具有的支撑柔性越好。柔性的基础，是复用性，可拓展性，模块式的设计方式。其对应的是刚性支撑，即没有考虑系统柔性的支撑。在业务初期，刚性支撑能快速满足业务方的需求，但长此以往系统整体效率下降，开发的边际成本越来越高，显然无法适应业务的快速发展。平台化目标之三，就是实现业务的柔性支撑，这就要求抽象出业务模型，从此前的以点为维度的支撑，换为以面为维度的支撑。
二、为什么要做平台化
以上是我对平台化的理解，接下来说下做了平台化，我们能收获什么？
在我看来，平台化的效果主要有三点：
1、降本增效，提高效率。
电商作为轻资产行业，最重的资产其实是人才，而人才中，占比最大的往往是我们的技术同学们。在实行平台化之后，由于实现了柔性支撑的关系，能极大解放技术同学，使其快速能完成业务需求，有更多精力投入到比如稳定性，性能提高，技术改造，技术学习等其他重要事项中，这也提高了人效，从另一个方面降低了公司的成本。
2、快速支撑，响应业务。
平台化之后，由于能够快速支撑业务方的日常需求，也使得我们能更快把握住战机，同时在对外合作上，也更有谈判的筹码。
3、边界清晰，管理规范。
平台化会进行业务分治及归口管理，这需要对现有的业务进行梳理，业务边界会变得更加清晰。同时由于归口管理，各个团队对业务能进行更规范的管理，提高沟通效率，避免一件小事找了半天都没有人敢拍板的情况。
三、平台化误区
对于平台化，在推行的过程中由于概念较为抽象，不同业务线应用场景差异较大，因此在理解有很多误区，我也和大家沟通下我个人的一些看法：
1、平台化一定要有旗下很多应用，才可以做平台化？
平台化是一种架构方式的叫法，而不是做大的通用平台才叫平台化。在我的理解，只要被多应用场景，多业务方需求，高需求时效要求，不明确的业务边界搞得系统快hold不住的业务，就可以考虑进行平台化改造。
2、做个大的业务平台，就完成了平台化改造了？
做了大的业务平台，实现了业务分治，我个人感觉，是平台化的开始。业务分治，归口管理以及柔性支撑，其实是平台化由浅及深的三个阶段。每个阶段对生产效率都会有一定程度的提高，但全部实现之后，对生产效率的提升会达到一个全新的高度。路漫漫其修远，大家仍需加油。
3、无论什么业务都适合进行平台化？
并不是所有业务都适合进行平台化，我们也不提倡为了平台化而平台化。有一些业务，面对的业务方较少，业务变化少，系统压力小，此时是否需要做平台化，就需要讨论一下了。毕竟平台化改造，需要投入的资源，时间较多，如果投入产出比较低，则不一定要做。
四、平台化产品模型思考
这段时间，通过对于平台化的思考，我总结了平台化的通用产品模型，在此抛砖引玉，希望大家一起讨论下：
这个模型主要分4层，分为业务层，功能层，接口层，应用层。
1.业务层，是指业务分治后，划分清晰的不同业务。
这一层主要对应的是平台化中的业务分治的要求，要求业务边界划分明确，专业的人干专业的事。
2.功能层，是指为实现该业务运转需要的业务功能。
这一层主要对应的是平台化中的柔性支撑的要求。
我个人觉得业务功能可以由三种要素组合合成，分别为前端能力，后端能力以及业务规则组成，因此柔性支撑应该在这三种要素中均进行体现。具体的做法，就是通过前端的模块化，后端的流程可配置化以及业务规则的可配置化，来实现业务功能的柔性支撑。
3.接口层，是指对底层功能的封装层。
这一层主要对应的平台化中的归口管理的要求。通过接口层，由一个底层服务团队对多个业务方统一提供服务，从而做到底层功能的归口管理。
4.应用层，是指业务方的应用层面。
业务方只需要对应接口层，即可实现想要的功能，对他们来说，底部的功能实现都是黑箱的，他们是需要用类似SDK的形式来与接口层进行交互即可。
以上是我对于平台化的理解。综上，平台化架构是一个在面对需求小批量、多批次、时效要求高的业务场景下的好选择，对于生产效率的提高是有极大好处的。
0 条评论