知识吧 知识资讯 从SaaS产品设计与OP产品设计,谈谈SaaS产品转型

从SaaS产品设计与OP产品设计,谈谈SaaS产品转型

在产品设计维度上,SaaS产品设计与OP项目交付的产品设计有很大区别,那么你知道区别在哪里吗?在当前的环境下,SaaS产品转型又可以从哪些方向进行规划?过程中又可能遇到哪些难点?不妨来看看作者的解读。

生产制造运营管理类的SaaS产品在第三年被按下了暂停键,获客难、交付难、续费难三大问题难以突破,不赚钱的业务都不是好业务,千万投资的产品如何商业化,产品转型迫在眉睫。

SaaS的产品设计与OP项目交付的产品设计有很大的区别,SaaS的产品是提供一个标准产品供客户使用,OP项目交付产品是80%的产品能力加上20%的定制,所以在产品技术形态和产品本身的形态都有很大的区别。

一、SaaS产品设计

1. 平台端:运营人员管理企业租户

SaaS型产品最难处理的是客户间的差异化,这个差异化包括:

  1. 行业包不同;
  2. 选择应用的不同;
  3. 应用执行某个功能不同。

这些不同会直接体现在企业门户中可看到的内容,因此在产品设计中平台端负责承担这部分配置,我们先划分版本,各个版本下挂应用和菜单甚至按钮,客户开通应用时,会给客户配置响应的版本,下发就会将运营端配置好的内容传递给企业门户,方便企业门户的内容显示。

当然运营端还囊括了平台端自身的管理权限、渠道管理、客户管理、版本管理、客户运营咨询、客户运营分析等等。

2. 企业门户:企业管理员维护企业组织、权限、主数据、业务规则等

工业企业在组织和角色划分上有很多相同之处,运营下发客户信息时有默认的配置模板,这可以减少企业管理员的工作量。但是仍需要根据企业实际情况去做调整和权限的授权。

授权分为两个方面,一个是功能层面的授权简单来讲就是哪些角色有哪些菜单&按钮的使用权,另一方面是数据权限,如不同的人是负责不同的车间、线体等。数据权限通常是跟主数据在一起的,处理完主数据后根据主数据再分配权限

业务规则有两个方面,一方面是跟具体应用挂钩的,比如启动了生产,就会有生产的规则配置如是否要齐套后才开工等业务类型的配置;另外一方面是模板配置,如打印模板设置、消息待办设置、预警监控设置等。

企业门户一般是有企业管理员做初始化配置,这些配置属于低频次操作。

3. 具体应用:企业业务人员处理具体业务

这部分就是具体的业务应用了,由业务人员进行操作。产品设计之初会圈定范围内置好角色及角色操作的流程,一般各个企业差别不大,只是有些角色名称会不一样,具体执行的工作细节差异是较大的。这部分一般会通过前面两个部分解决,从平台端下发的功能不一样,或者通过自行配置解决个性化的部分。

平台开发的应用均会注册到平台并跟企业门户的主数据及规则对接,实现平台统一控制的目的。

二、OP项目交付产品目标

OP的产品设计目前还没有完全启动,我们先从产品要实现的目标讲起:

1. 市场获客更聚焦

我之前在甲方工作时,之前跟财务的老大及供应商开会,供应商问我们你们想要啥,财务老大说你有啥,弄得当时气氛有点尴尬。

事后我问财务老大为什么要这样,她说供应商在我要的这个产品上有60%的契合度我才会考虑他并告诉他我的诉求,否则我说我要什么他说他都有都能做到,但是谁能保障他真的能做到呢?

纯项目制的交付如今越来越难了,好多时候在重复造轮子。我之前做项目时深有体会,光做主数据就要先来个2周左右,项目跟项目间差异大,即使是有相似的以前业务方案尚且可以借鉴,但是代码基本不行;项目上线了还没看到项目产生的价值呢就被调到新的项目上了,并没有真正的沉淀和提炼业务场景和业务价值,这也是很多以项目交付型的公司很难有产品的原因。

OP产品在产品企划阶段会完成5看3定,会规划产品的研发路标、销售路标、运营计划,在产品上市前也会做完整的产品运营资料,这对市场的聚焦有很大的好处,一方面可以提升市场成单转化率,另一方面减少交付难度,降低项目执行难度。

2. 快速实施:在不增加人员的情况下承接更多的单

快速实施体现在减少二开的工作量,如果产品力足够强,那么通过配置就可以解决大部分的业务问题,二开的工作自然就比较少,那么不论是本企业自己实施,还是服务商实施,在难度上都会降低,同时也会缩短交付周期,但在产品在设计上也提出了更高的要求。

  1. 通用能力:如组织、主数据、通用的业务组件;
  2. 工具组件:支持灵活配置如打印模板、编码规则等;
  3. 个性化二开简单可控:如可编程接口API、前端通用组件、外挂算法等。

我从未做过OP产品,早些年在做项目交付,后期一直在做SAAS,说来心虚,面对转型的不确定性也需要像小白一样重头再来。

三、SaaS产品转型的难度及规划方向

技术架构的转型(工具化组件、定制支持)主要有架构师来完成,我所需要做的是跟他目标对齐,并关注他的工作计划,当然当前阶段更多充当鼓励师和拉资源的工作,看能否通过哪些有经验且成功的大神的赋能帮我们搞定这个方向。

通用能力的抽取主要是我来负责的,前期我还在做的C端思路做B端产品忙的不亦乐乎时,团队其他产品经理已经被组件化抽取伤到了,当前大局动荡还未定论阶段大家多少是有点沮丧的,我需要提供思路及落地的方法给到大家,让大家知道这个事情是可行的,并重新建立信心。

通过前一周的努力我整理出了思路,但是还不确认思路是否是正确的,我的老板太忙了,在他还未确认的情况下已经开始让大家行动了,也许治愈焦虑最好的办法就是干活!

规划方向:转型想要快速见效,我们打算按照以下路径走,抽取组件、以最简单的方式快速复用到项目上,得到验证后再做工具化,最后再封装代码提供工具以便于服务商也可以做实施。

规划方向是上周聊的一位大神给的建议,跟他聊完很开心,集团是有能人的,我当前要做的是打破之前自己盲目的自信和乐观,寻求志同道合的大神和伙伴,一块做出一款能够被成功商业化的产品,并持之以恒的做下去。

看了很多成功的产品都不是短期就能成功的,作为一个产品经理,我所能做的是不断提升自己,融合更多有能量有力量的人帮助产品成长,最终在市场上获得认可。

本文由 @抹香鲸 原创发布于知识吧,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

本文来自网络,不代表知识吧立场,转载请注明出处:https://zhishiba.net/6166.html
上一篇
下一篇

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

返回顶部

Warning: error_log(/www/wwwroot/www.zhishiba.net/wp-content/plugins/spider-analyser/#log/log-2807.txt): failed to open stream: No such file or directory in /www/wwwroot/www.zhishiba.net/wp-content/plugins/spider-analyser/spider.class.php on line 2900