从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端产品忙的不亦乐乎时，团队其他产品经理已经被组件化抽取伤到了，当前大局动荡还未定论阶段大家多少是有点沮丧的，我需要提供思路及落地的方法给到大家，让大家知道这个事情是可行的，并重新建立信心。

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

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

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

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

​Read More