赞
踩
这篇文章是新书第二章的节选,这部分内容写了较长时间,对第一版书中的产品分类做了较大调整,个人对新版本的产品分类更加满意,而且我觉得新的分类很好地体现出了B端产品特性以及在商业化上的显著区别。终于把前两章写完了,因为对很多基本概念有了全新的解释,所以前两张章其实改动比较大,大概新写了40%的内容,改了20%的内容。最近疫情紧张,大家都注意防护,本来计划下周末去青海湖,都筹划了小半年,结果忍痛放弃了,最近一些培训客户估计也要延期了。不过也好,有更多时间写书了!
我们已经了解了互联网行业的最新发展特点、市场对B端产品经理的旺盛需求,以及从事B端产品工作对个人成长的意义。现在,我们来进一步介绍B端产品的分类方向,帮助你对B端产品形成更全面、深刻的认识。
根据产品特点,我将B端产品粗略的划分为四个方向:支持多人协作,达到某个业务目标的业务型产品;解决某个明确场景问题的工具型产品;支撑企业商品服务售卖与履约的交易型产品;以及为架构和软件抽象设计服务的基础服务产品。这四个方向基本覆盖了典型的B端产品线。下面就来详细介绍一下这四类产品方向。
业务型产品,是B端产品分类中较为复杂的一类,具备B端产品所有的关键特征,在企业中用来支撑多人协作达成业务目标,产品背后的业务链条长,业务复杂性高,业务个性化明显。
业务型产品可以进一步分为垂直业务型和办公协作型,前者一般情况下涉及企业的关键业务运作,个性化比较强,很多企业选择自研,或个性化定制开发;后者相对来讲是企业职能部门使用的支持性系统,从业务角度来讲标准化程度相对更高,因此很多企业选择采购成熟软件产品。
在很多互联网企业,垂直业务型B端产品往往属于业务线的产研团队负责,而办公协同相关产品往往由IT团队或信息化团队负责。
常见的业务型产品如下图所示。
PLM:Product Lifecycle Management,产品生命周期管理。常见于制造业中的产品创新与设计管理。
SCM:Supply Chain Management,供应链管理。广义的SCM包括完整的供应商管理、采购管理、仓储和配送管理;狭义的SCM指供应商管理。
ERP:Enterprise Resource Planning,企业资源计划管理。广义的ERP是一套庞大复杂的体系,涵盖供应链管理、原材料管理、仓储配送管理、财务管理,甚至还包括客户管理、销售管理等;狭义的ERP常常被理解成财务系统,或轻量级的进销存系统,或电商交易系统。
MES:Manufacturing Execution System,制造执行系统。生产制造业的制造执行管理系统。
WMS:Warehouse Management System,仓储管理系统,用来支持仓库管理业务。
TMS:Transportation Management System,运输管理系统,用来支持配送管理业务。
CRM:Customer Relationship Management,客户关系管理。广义上的CRM包括从客户开发、管理、营销、服务的客户全生命周期管理;狭义的CRM是指给销售人员使用的销售过程管理软件。
CallCenter:呼叫中心。广义的呼叫中心包括客服平台与话务平台,涉及软件、硬件、通信这一套完整体系;狭义的呼叫中心是指支持客服进行呼入呼出业务的软件系统,包括客服系统、质检系统、知识库系统等。
HRM:Human Resource Management,人力资源管理软件,包括招聘、简历管理、入职管理、薪酬管理等功能。
OA:Office Automation,办公自动化。主要提供资料查询、单据审批等功能,是最基本、最常用的办公软件。
KMS:Knowledge Management System,知识管理系统。帮助企业沉淀知识并进行传承分享的管理软件系统,有些KMS还会包括培训考试模块。
IM:沟通工具,有条件的公司会选择自研,多数公司会选择钉钉、企业微信、Lync(外企常用)等。如果不用内部IM会怎样?假设你的公司用微信沟通,工作中建立了多个群组,每当有员工离职时,及时找到他所在的群并在每个群里删掉该员工,就是一件让人崩溃的事情。
业务型产品与迈克波特价值链模型
迈克波特(Michael Porter)是全球最著名的管理思想界大家,竞争战略之父,其创造的价值链理论(value chain)在今天的商界依然被广泛应用。在价值链理论中,波特将企业创造价值的过程分为基本活动和辅助活动,基本活动创造价值,辅助活动进行支撑,如下图。
我们所探讨的业务型产品,正好契合了价值链模型中的各类关键活动。
首先,垂直业务线产品覆盖了所有基本活动,以及部分辅助活动,例如,PLM、SCM支撑了技术开发和采购活动,ERP和MES支撑了内部后勤与生产经营,WMS、TMS支撑了外部后勤,CRM支撑了市场销售,CallCenter支撑了服务。
其次,办公协同产品支撑了大部分辅助活动,例如,HRM支撑了人力资源管理,OA、KMS、IM都是企业基础设施。
业务型软件产品正是企业经营运作的核心,支撑了整个业务的开展。
工具型产品,同样是为了解决企业某一类业务与运作问题,但解决问题的颗粒度更低,场景更加聚焦且明确,背后的业务链条短,复杂性相对较低。
典型的工具型产品包括电子签名、视频会议、文档协同、营销自动化、企业网盘等等。工具型产品解决问题的场景特别明确,而且多数工具产品体现出了C端产品特征,即个人使用,用完即走,并不涉及复杂的多人协作和流程。
但是工具型产品毕竟是为了解决企业运作问题而存在的,虽然应用场景偏向于个体,但背后依然会涉及到多组织多角色问题,所以算是比较独特的一类B端产品。
在现代商业环境中,没有一家企业不会将自己的交易过程线上化、数字化。承担企业售卖产品和服务的线上化交易与履约的系统,就是交易系统,因为他实在太重要了,所以我将交易系统单独提取出来,归为交易型产品。
在银行、保险等行业,交易系统属于核心业务系统,是曾经企业信息化建设中最核心的命脉;而经典的 ERP系统本身也包含了交易履约的模块,例如订单模块(OMS,Order Management System),商品管理模块等;而现代企业广泛应用的电商系统,也属于典型的交易型产品,只不过电商系统体系更加庞大,除了需要具备交易履约这些底层能力,还需要强大的C端获客、转化能力。
一般典型的交易型产品要包含支撑商品服务售卖的最小能力闭环,即客户下单的C端,以及管理整个交易业务的后台模块,包括订单、商品、营销、清结算等能力。
不同的商业模型对交易系统的诉求不同。典型的商业模型包括单边市场和多边市场两种模式。在单边市场中,企业向消费者直接提供商品售卖和服务,例如海尔、美的这类家电企业,背后就是典型的单边交易模式(单边市场);而在多边市场(也叫多边平台模式)中,企业本身不提供商品和服务的售卖,而是作为一个平台,将供应商和消费者聚在一起,撮合几方完成交易,例如天猫、京东POP就是典型的多边市场(具体应该叫双边市场)。
对于多边市场模式下的交易型产品,在基本能力的基础之上,为了保证平台的持续、良性运转,需要对入驻的商家进行资质审核和服务管理,因此还要实现企业内部使用的商户管理系统,以及提供给商家使用的强大的经营管理后台,方便商家进行自主管理。
交易型产品的部分模块可能会发展为公司的基础服务产品,例如支付模块就可能发展为集团的公共服务,为所有业务线提供支持;而订单模块也可能成为集团的订单中台,为多业务线提供订单履约的核心能力。
在一家公司的软件产品体系中,不同软件产品是存在共性需求的,例如各个产品都需要进行权限管理,各个C端产品都需要消息推送管理。如果为每个产品都实现一遍这样的需求,将会严重浪费开发资源,且导致软件架构冗余。因此,在软件体系搭建过程中,有必要将各个系统都需要的、功能重复的软件模块抽象出来,统一建设维护,所提供的服务叫作基础服务(当然有时候也可以被称为中台,其实名字如何并不重要,重点在于背后抽象设计的思维模式,这个话题在全书中会持续的深入讲解)。
MDM:Master Data Management,主数据管理。主数据管理是企业数据架构设计中非常重要的概念,简单来讲,一家企业在很多业务领域和主题中,应该有且只有一套相关的资料存储系统,以保证数据管理的一致性和唯一性。
Auth:Authorization Management,权限管理平台。公司的业务人员经常要访问不同的内部业务系统,如果针对每个业务角色在各个业务系统分别设置管理权限,那么管理成本将很高,并且浪费研发资源。常见的做法是通过集中的权限管理平台,把全公司业务系统统管起来。
Org:Organization Management,组织架构管理平台。公司不同的业务团队有各自的管理层级,需要一套系统来统一管理业务团队的组织架构,并且允许其他业务系统获取组织架构数据。
Push:消息推送服务。用于在APP推送消息的基础服务;另外类似短信服务也可以统一设计成基础服务,背后封装不同短信供应商的通道。
SSO:Single Sign On,单点登录服务。单点登录服务可以让用户只登录一次系统,就能访问所有接入单点登录服务的其他业务系统。单点登录服务是非常重要的业务系统基础服务,可以给用户带来极大的方便。
BPM:Business Process Management,业务流程管理,一般等同于流程引擎。流程引擎是给技术团队使用的,用来快速定义、开发业务流程的工具。
基础服务产品线涉及的这些概念和知识,可能会让很多读者觉得非常抽象、难以理解。不要着急,随着本书内容的深入,大家会逐渐理解这些产品及其背后的设计思路。
我们将上述介绍的产品方向汇总起来,绘制一张B端产品方向的整体示意图,如下图所示。
请大家注意,图中只是列出了一些常见的产品和模块,并不是企业中可能涉及的全部产品。而且,有很多产品不能归于某种单一类别,例如,支付产品既可以归于交易平台类,也可以归于基础服务类。另外,很多数据产品本身也属于B端的范畴,例如,BI(Business Intelligence)与报表引擎(其实这两类产品已经越长越像了),也可以归类于工具型B端产品。我们的重点在于从整体上理解B端产品的范围,形成宏观的感受,而不必给每个产品贴上一个严格的类别标签。
以上四类B端产品方向,不仅产品特点不同,在设计的方法论、产品标准化程度、商业化售卖的业务模式上也完全不同,我们首先来看下边这张对比表格。
业务型B端产品,背后服务的业务运作链条长,涉及协同角色多,并且个性化需求非常强烈,例如ERP在企业中的实施,很少有通过简单配置就能直接运行的,而是需要由专业顾问、实施团队,进行全面的业务分析和梳理后,进行个性化的调校、配置甚至定制开发,才能运作起来。
因此,业务型产品标准化程度一般都比较低,很难通过少量的配置功能设计就能覆盖多数客户的诉求,而是需要做复杂的配置能力,甚至要依托底层的PaaS平台(主要是工作流和对象定义与表单,后续我们会持续深入讲解),来尽量低成本的支持繁杂的客户化需求。
我们放眼市面上的业务型软件产品,不论是Oracle EBS、SAP这样的商业级巨无霸应用,抑或是Salesforce、北森、销售易这样的SaaS应用,都投入了大量的资源研发PaaS平台,作为标准化产品的基座,来解决个性化需求以及多行业拓展的诉求。
因为业务型产品服务于企业的核心业务板块和环节,实施后对业务的影响巨大且深远,因此业务型产品的购买往往由甲方企业的高层以及业务负责人来共同决策,并且决策周期长,决策过程复杂;所以对于软件公司来讲,不论是IT项目制厂商,甚至是SaaS厂商,在销售环节,都需要由专门的销售人员长期跟进,经过很多努力,最终拿下客户。
工具型产品解决单一场景下的明确问题,不同商业模式客户在这些单一场景的诉求都高度类似,个性化诉求很少,因此,工具型产品的标准化程度非常高,往往做一套工具型产品,通过简单地配置设置,就可以完成在客户方的部署落地。大家可以想一想,类似于法大大这样的电子签章软件,以及腾讯会议这样的企业会议软件,是否需要复杂的定制化开发才能使用呢?实际上并不需要。
因此,工具型产品背后并不需要PaaS平台来强化产品能力,可以说工具型产品是SaaS化的理想类型。SaaS产品最大的麻烦之一是如何做好标准化产品和个性化需求之间的平衡,在这方面工具型产品具备天然优势,天生服务的是需求高度收敛的场景。
因为工具型产品背后的业务场景单一,甚至很多时候只是一个局部问题,因此,工具型产品在甲方的采购可能并不需要企业高层管理人员参与,企业业务部门的中层甚至可能是关键一线人员就能做出采购决策。例如基于微信生态的SCRM产品,使用人员一般是增长部门的私域运营人员,对于这类产品,很可能增长部门负责人,甚至是其中私域流量运营的核心骨干就能决定采购,因为这些工具是直接用来帮助专业性很强的业务一线达成业绩的助手。
基于甲方采购的特点(采购决策链条短,周期短,涉及利益方少),工具型SaaS产品,在获客和转化上的运作,更像是一家SaaS公司该有的样子,通过线上获客、专业内容的输出沉淀、自动化营销工具的使用,持续的孕育影响潜在消费者,最终完成自发性转化,并持续复购和增购;这也是SaaS业务最希望达到的低成本规模化的营销模式,然而这种模式对于业务型SaaS产品,显然还是有挑战的。
交易型产品围绕着交易发生和履约的场景,可以只聚焦于线上买卖,也可以包括完整的供应链体系(包括采购、仓储和配送)。交易型产品的标准化程度中等,既没有业务型产品那么复杂多变,也没有工具型产品简单。
对于相同业务模式的交易型产品,标准化程度较高,一套产品通过配置即能给不同客户使用;但不同的交易模式下,标准化程度就很低了,例如,在实物电商中,类似于3C数码、服装这类的标品售卖,就和生鲜这类非标品的售卖区别非常大,一套实物电商的交易系统,基本无法在生鲜行业使用。
交易型产品作为企业的核心业务系统,承载者商业线上化的关键任务,在产品的购买决策上,决策也相对复杂、冗长,需要非常慎重。
基础服务产品更多的是为了支撑企业的软件应用架构建设、软件的抽象化架构设计而存在。绝大多数基础服务都体现出标准化、组件化的特征,例如给APP发推送的Push服务,任何一家公司的诉求都是相通的,对Push服务来讲没有个性化的诉求,因此像激光推送这样的厂商提供的Push服务产品标准化程度非常高,基本无需定制化。
基础服务产品一般会选择自研或者外采,如果外采,一般购买决策由IT团队、技术来负责;当然,对于聚合支付、短信服务商这样的涉及到运营成本的产品,可能业务部门也会参与购买决策。
以上介绍了不同类型B端产品的不同之处,最后,我们再聊一聊这几类产品设计方法论上的不同。
工具型产品设计,产品经理更加聚焦场景洞察和探索,采用C端产品设计的方法论将更加合理,例如KANO模型、用户故事地图等工具的应用;而业务型、交易型产品设计,除了洞察分析场景,还需要将场景背后的业务本质进行提炼,进行高度抽象的设计,需要兼具C端方法论以及传统软件工程和需求分析的方法论,例如UML、ER建模等工具的应用。
虽然同样是B端产品,但不同类型产品设计的方法论完全不同!本书在后续章节所探讨的设计方法论,主要是针对业务型产品的设计,也部分适用于交易型和基础服务产品,但并不适用于工具型产品!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。