我理解的 toB 产品框架(整合版)

近期梳理了下个人网站的定位,决定重新整理下以前写的文章,这篇文章是我之前写过的关于 toB 产品框架的整合版。

一、传统的 toB 产品框架

做产品,除了需要多看之外,还需要多想。但是光想是不够的,还需要将你想到的东西写出来。就像做产品,当你把流程图和线框图画出来后,你才发现,一个看上去很小的问题也可能会很复杂。

所以,我决定开设了一个名为「迟早会更新」的专栏,记录我对产品的一些思考。(产品菜鸟一枚,欢迎各位拍砖,也希望能通过这个专栏认识更多产品爱好者。)至于为何专栏名字叫「迟早会更新」,无它,就是我比较懒,所以可能会出现很久才更新的情况。

言归正传,专栏的第一篇连载,想跟大家聊聊toB产品框架。有些读者可能看过我的另一篇文章:什么样的产品可以称之为「好产品」?这篇文章算是我创业失败后的总结(不过没啥干货)。创业失败后,进入了一家toB企业。常常反思之前总结的产品模型,发现toB的产品跟toC产品差别巨大,很难再使用原有的toC产品框架去思考。(为何差别会那么大?之后会单独写一篇文章跟大家聊聊,恩,迟早会更新的。)

做C端的产品,大体是以一个核心出发,再定流程和扣细节。而B端的产品,核心需求其实比C端产品更好把控,因为企业的需求较为单一,且具有普世性。中小企业也好,大型企业也好,都是有报销、审批、签到等等需求。(人有各种各种各样的需求,而企业只有一个:利润最大化)但是它难就难在定流程上。

举例说来,不管你是用美团,还是用饿了么订餐,整个订餐流程是非常相似的,细节上与实现技术上可能会有差异,但是整个产品的使用流程基本上大同小异。但是对于B端用户,一个简单的审批可能都会有巨大的差异。现在的SaaS产品,如果按C端的玩法来玩,基本上是玩不转的。不能只是着眼于单一流程去做产品,需要跳出单一流程,以宏观的思维去看企业产品,不然做出来的产品必定是需要天天打补丁的产品。

现在大多数的B端应用,在我看来都是由两大部分构成。底层是权限系统,顶层是以表单为首的三大模块。各个模块自由组合,就构成了一个个的toB产品。

这里我用审批与签到做为例子介绍下这个产品框架。审批其实就是一个表单+流程引擎的产品,而签到则是由表单+数据分析组成。(只是签到的表单是个智能表单而已)但是不管是哪个产品,最关键的就是权限系统,以及流程引擎。如果一开始没有规划好权限系统,在后续的产品发展过程中,它会变成一个越来越深的坑。而流程引擎,则是带管控属性的产品的另一核心,同时也是toB产品的一个技术壁垒。数据分析,无需多说,往大的说来,它属于大数据范畴,往小了说,其实就是各种各样的报表与视图。

但是在这个框架中,有一块一直被多数toB产品低估的部分,那就是表单。钉钉、云之家以及企业微信的出现,标志着toB产品也进入了移动互联网时代。同时SaaS产品兴起,越来越多的创业者投入到了移动toB产品中,但是当你在使用这些产品时,你会发现市面上没有哪几个产品,是能够把表单做到足够智能与简单的。人们在使用这类产品时,仍然需要输入大量的内容。(而在手机上输入大量的内容时,你估计想死的心都有了。)

很多产品只是将原有的PC端的内容,改改交互就放到了移动端上。产品在设计的过程中,并没有充分考虑手机的诸多特性,比如定位、拍照、语音等。如果你是一名toB的产品经理,在思考与设计的过程中,不妨考虑下手机一些特性,尝试将表单做得更智能。(前文说到的签到,就是一个很好的例子,用户无需填写很多内容,轻轻一按,手机自动获取时间与地理位置信息,完成签到。)

当然,要想表单做得更智能,还可以往智能填充上想。比如现在很多的CRM产品,都会智能抓取企信宝的数据,帮助用户填写繁琐的表单内容。

二、当今 toB 产品的第一个趋势

而因为各种各样的App Store兴起,越来越多的toB产品开始往平台发展。而且微信的巨大成功,也让各种 toB 企业看到了成为巨头的希望。(顺便插一句题外话。我一直有个疑惑,中国模仿式创新创造出了阿里巴巴、百度、微博、嘀嘀这样的巨头,但是为啥没有 toB 的巨头呢?要知道很多世界500强的企业都是做 toB 的产品的呀~)

所以像钉钉与云之家就是采取类似这样的产品框架(只是大体上类似而已):

其实就是在原有的传统的 toB 产品框架上,增加了两大块。一个是IM模块,另一个则是应用平台。IM模块无需多说,就是一个聊天功能。而应用平台则是让各种各样的垂直 toB 或 toC 服务接入到基础产品中,从而达到场景互补的作用。

但是市面上的产品基本是做到了模块与模块的简单拼接。而近一两年的发展趋势则是要将各个模块打通。比如钉钉3.0发布会后,又举办了一场小发布会,就有讲到阿里商旅与报销对接功能,这个功能一眼看去就是为了解决报销繁琐的问题,看似简单,实际上从产品观的角度考虑,这是个巨大突破。要知道传统的私有云ERP系统就是一个信息孤岛。别说是信息交换了,就是单纯的信息输入都会有各种各样的权限限制。

而未来产品的框架就会有所变化,IM模块将会融合到传统的 toB 框架上,成为另一个基础能力。而在应用平台上的各个应用就可以调用平台本身拥有的能力。

他们的关系可以用软件与硬件做类比,比如你在使用滴滴出行叫车的时候,滴滴出行一般会使用GPS功能,帮助你快速定位上车点,而GPS功能滴滴是没有的,但手机有。滴滴只是调用手机本身硬件上的GPS模块而已。而未来的平台级 toB 应用也会是这样,在平台上的应用可以轻松调用本身平台的基础能力,比如流程引擎、权限系统等,这些应用都无需再去开发那么麻烦的东西,可以花更多的时间与资源去深挖业务场景,脏话累活基本上都由平台去干了。

比如我用钉钉提到的商旅报销的场景,对于商旅应用来说,其实它根本无需考虑权限问题,也无需考虑审批单据如何扭转。只要用户点击报销,商旅应用只需传输特定信息给平台,就可以了,剩余的事平台做就好。流程引擎收到需求,将数据自动填写到符合流程的特定表单中,再根据权限系统提供的参数,分配给特定的人进行审批。数据分析系统自动统计与监控整个流程,出现数据异常,马上反馈特定管理员。(当然这是理想状态下,这个流要跑通,估计实施成本会非常高)

三、当今 toB 产品的第二个趋势

如果说 toB 产品的第一个趋势是应用互联,那么另外一个趋势就是企业间的信息互联。像传统私有云的 toB 产品,基本上就是个信息孤岛,企业信息很少流出,或者与其它企业直接交换信息。举个例子:

你的客户需要订一批货物,销售一般会在公司的ERP或CRM系统录入订单或合同,然后走审批。该合同可能还需要快递到你的客户那里,然后又走一遍审批。最后完成生产和发货。整个流程异常繁琐,而且速度很慢。(这个场景已经算是快的了,还有更长更麻烦的。)另一方面,即使是简单的信息触达,可能都会很麻烦。拿钉钉做为例子:

你所在的公司在使用钉钉,内部交流一直是使用钉钉,但是当你需要跟你的合作伙伴、你的客户交流时,你还是需要打开邮箱、QQ或者微信,因为你的合作方不一定在使用钉钉。

第一个场景,将会是目前 toB 平台产品重点关注的切入点。即类似钉钉3.0推出的服务窗的概念。企业的外部好友(合作伙伴、客户、甚至供应商)都能通过这个服务窗发起订货、退货甚至联系客服等等。而这个服务窗的背后,将会是企业的ERP系统,甚至是企业的智能制造系统。其产品框架将会类似(A、B为不同企业):

理想化的场景将会是这样的故事(举例,非实际):

如果某经销商需要订购100箱面包,该经销商直接在面包生产商那订购,面包生产商收到订购订单后,系统自动进行库存盘点,如果发现货物不足,机器自动开始生产。同时发现面粉也不够了,会自动向上游的面粉厂订购面粉。这套产品框架貌似能跑通,但是实际上是个大坑。比如目前钉钉提供的服务窗能力对于 B2B 的企业估计就比较麻烦了,毕竟这种企业涉及的订单金额更大,流程也更加繁琐,人情交易也更多。如何在做到信息流动之余,还做到销售提速,将是产品需要突破的地方。单纯的信息流动并不能让企业用起来,只有让企业看到了利润才是最关键的。

另一方面,B2C的企业跑这套流程,可能也不太好使,因为C端的用户并不一定使用钉钉,不过阿里倒是可以考虑将旺旺与钉钉、微博与钉钉打通,从而解决B、C端之间的消息触达问题。但是仍然很难根本上解决消息触达的问题。所以就目前看来,谁最优机会根本上解决消息触达的问题?估计就是企业微信了。

小程序的出现,意味着未来企业微信也将会存在应用平台的能力,而且它的能力比我之前提到的 toB 产品框架还要强大,因为它在普通的框架上,还搭载了独特的程序框架,大大提高了体验,不像现在的H5应用那样需要实时加载。而且,因为页面可以调用小程序提供的组件,这些组件早已内置在微信客户端,它们的体验将会更加「原生」。所以我认为未来较为理想的 toB 的产品框架将会是这样:

平台除了提供带有 toB 属性的能力外,还会额外提供统一的设计、审核以及运营规范,甚至还会提供类似Swift那样的开发语言,或者类似微信小程序那样的特有语言。

四、未来的 toB 产品框架

那么未来的 toB 产品会怎么样?我想使用审批做为例子:用户初次使用产品,只需要设好组织架构,AI系统会自动推算出企业最优的审批模式。同时,在做审批的时候,不再需要人为做判断,而是系统判断同意或驳回。但当系统无法判断时,用户也只需要做少量干预即可。那么未来的 toB 产品依然是以底层权限为基础,在权限上搭载大数据分析系统,AI系统基于大数据分析系统所得的结果,做一定的机器学习,从而做到多数流程自动化。(目前最接近此形态的有苹果的Siri以及微软的Cortana)

同时表单将变得更加智能,传统的键盘输入,会被智能补全或者语音输入所取代:

五、One More Thing

前文提到: C 端产品与 B 端产品的差别巨大,为何会这样?以下是我的几点小思考:

  1. 多角色问题。C 端产品一般用户构成较为单一,人物画像构建比较简单,而且大体需求相差不多。但是 B 端产品角色必定是两个或以上,即客户与用户。客户是指为产品付款的人,多数是公司的管理者,而用户则多为员工。两者人物画像差别巨大,同时两者的需求还会出现矛盾的地方,客户需要的是管控,用户需要的是自由。
  2. 业务瓶颈。做 B 端产品,不只是需要了解企业,还需要了解业务,而一般的互联网从业人员可能很少拥有很强的业务能力。比如做CRM系统的人,可能根本没做过销售。在做产品时,很难将自己代入到用户那,因为自身就不是销售。
  3. 企业的潜规则。拿报销做为例子,如果按照互联网思维去做报销系统,一般会从提高体验,提高效率上着手去做。但是这不一定会有企业买账,因为对于企业来说,利润最大化才是企业的核心需求,报销速度越快,例如掉得越快。财务拖你一个月,企业就多一个月的流水。这就是企业的潜规则。那么做为一名产品经理,就需要同时考虑潜规则去做报销。比如是否能将报销前置,使得企业能削减成本的同时,满足员工的报销需求?(或者换个角度看,无需员工花钱)企业版滴滴,就是个很好的例子,企业提前买一定数额的里程,因为是提前购买,可以获得一定的优惠。企业将这些快车里程分发给员工,员工无需付费就能享受到快车服务。(报销的需求,要根本解决就是要换个角度思考,与其玩报销,不如玩赊账或提前付费)
  4. 不只需要了解客户与用户,还需要了解客户的客户以及客户的用户。这句话有点绕,其实就是在第三篇文章中,说到的一个趋势,平台未来会打破原有企业信息孤岛,对接上下游。这个时候,我们设计的产品不只是企业在用,可能个人也在用。
Comments
Write a Comment