内部系统转变成SaaS,要踩多少坑?

5 评论 12452 浏览 46 收藏 15 分钟

为了提高公司运转效率,以及抢占蓝海市场,SaaS行业成为近年来的香馍馍。SaaS系统千千万,其中由内部系统演变而来的最为特殊。内部系统转SaaS的路上,到底遇到多少难题,我们应该如何应对?一起来文中寻找答案吧。

01 去特色,找共性的转变之路

SaaS系统的诞生初衷多种多样,但其中最特殊,当属由内部系统演变而来。

根植在企业特定文化,带着特定的任务,有着特定的特色,从0到1的过程也是【去特色】,以及【找共性】的历程。

短短六个字,大坑无数,写满不少企业的身先士卒。

平安科技,历时5年,烧钱不少,最终放弃了内部系统对外的战略。

飞书也是由字节自己的内部系统转变而来,在找对味的客户的路上,遇到了不少卡点。

那么,内部系统转SaaS的路上,到底遇到多少难题,我们应该如何应对?

我们不妨从一个真实案例改编的故事开始。

02 一个故事

1. 高层的一拍即合

“我们是时候做出新的改变了”,团队年会上,业务总裁一锤定音。

他说的改变是指,对外提供内部管理系统的能力。

背后的理由:“同样是一个领域,A细分市场已经有上市企业,B细分市场也被占领,而我们自己从事的,尚在发展的C市场一定也能走出一个技术独角兽。”

负责内部系统实现的技术总裁应下任务。于他而言,这是一个从成本中心转成收入中心的机会,但摸不透老板有多坚决,于是几番权衡,定下策略:产品放手去试,但需要注意,控制研发成本。

2. 读客户千遍也不厌倦

接到任务的产品,开始了风风火火的工作。

常年的业务积累让启动并不困难,系统里躺着成百上千个合作方,都可以当作广义的目标客户。

走过一轮问卷发放,定量分析出炉。虽然这是一个较为传统的行业,有超过5成的客户没有使用过系统,但占比70%以上的客户愿意使用系统来改善当前的经营问题,希望解决的问题也有较好的一致性,至于他们的担忧,主要集中在信息泄漏和价格问题。

再回过头来检查样本数量和质量,看到覆盖范围广泛,数据值得信任。团队被这样高的意愿度打上了强心剂,信心满满挑选有意愿的客户,开始一对一的定性访谈。

客户的故事丰富出乎意料。

  • “喂……你说什么!@#¥%……”信号不佳,间或夹杂老板指挥下属干活的声音。
  • “我们准备转行了,实在不好意思。”很有礼貌,我们也祝福客户的选择。
  • “行业太难了,这几年……”时局不好,不少客户都提过这句话,信息有效性被反复的情绪稀释。
  • “你在哪里啊?哦哦,XX城市真是个好地方,我当年……”这是喜欢唠嗑发散的客户。
  • “我们早几年就自己开发了统计和算账平台了,不然上游和下游根本算不过来。”虽然客户已经超前实现了自己的信息化系统,但看到这样先进的意识,总让人欣慰。

欢迎来到真实的世界,五花八门的客户才是SaaS要去征战的市场。

纷杂的信息就像沙砾,用结构化的框架,筛选出沙砾里的闪光金屑,接下来要做的是,呈现出这些金屑。

3. 业务和产品的视角PK

约好了总裁们的时间,希望把过滤后的信息带给大家,谋求共识以及明确资源投入。

这次调研分享的信息包括:

1)调研背景

2)调研目标

1.广泛了解客户对于系统化的看法

  • 深入了解:确认客户对系统化的定位以及诉求,了解不同客户的诉求和差距在哪些方面,了解诉求背后的不同客户画像
  • 初步了解:阻碍实现目标的因素 初步了解:市场竞争关系

2.圈定用户画像

基于获得的信息,帮助后续抽象用户需求,以及设计系统。

3)调研范围

分两方面陈述客户背景:

1.业务侧

  • 业务规模
  • 客户类型
  • 团队规模
  • 服务区域
  • 发展意愿

2.系统侧

  • 客户对系统的定位和认识
  • 使用顾虑
  • 领导者意识

不足:认识不到系统价值,认为当前不需要

有一些:认可部分价值,一般希望管理结果

较强:希望管理到业务过程

极强:除结果和过程管理外,还关注风控,人效等数据

4)调研结论

1.客户分析

1.1客户业务目标

以对系统的定位+领导者意识为维度,区分不同场景下客户需要达成的目标和投资资源

1.2 阻碍客户使用的原因

2.客户画像

2.1 客户画像与客户诉求

2.2 客户画像与商业价值

2.3 理想客户画像

3.需求分析

业务目标与产品需求:说明不同产品定位下需要的资源

需求分析:共性诉求/个性诉求

打动用户:打动决策人的需求/打动执行人的需求

4.市场竞品

如上文所言,这次汇报主要是希望各方视角能对我们的客户有生动的认识,明确我们主要抓哪部分客户,为客户提供什么价值,以此确立我们自己的产品定位和边界。

但汇报后,业务视角下给到的信息是:这些都是既定结论,根本不用去论证,客户对我们这类系统一定是有需要的,业务的同事们都在行业里那么多年了,这些事情还搞不清楚吗?

这是一次业务和产品视角的PK,业务认为经验足够就能下判断,判断客户是否需要我们的系统,知道这些客户有什么特质并不重要。

产品认为:所有需求都是从客户的业务目标而来,我们资源有限,必然无法同时满足所有客户的所有业务目标。

在一个时间,只能服务于某一类客户,这类客户的难点是我们着重要解决的,我们要先定下客户是谁,再来看系统怎么做。

另外,我们不能直接去拿现在的产品直接去找用户,没有企业面临的问题是一模一样的,就算找到和我们自己情况类似的企业,有些用户只需要其中的A模块,有些用户需要B模块,那我们应该做一个有强大的A模块的产品,还是做一个有强大B模块的产品呢?

对于这两种观点,你的看法如何呢?欢迎留言。我们继续讲故事。

4. 启动之难,难于上青天

调研沟通后,产研没有能从业务这里拿到足够拍板的信息,于是只有尽可能花小代价去做,最快的剪枝掉当前内部定制的能力,提供了一套简单的版本出来。

开始对之前感兴趣的客户做demo,让客户亲眼看到系统样子和交互,明确客户是真的有需要。走到demo步骤的客户,大概有一半愿意接受产品到现场实施,指导员工使用系统。

飞到客户当地,产品伙伴们大呼大开眼界。

作息上、工作强度、工作规范性上老板几乎都没有太多的管理,一个人往往身兼多个角色,和系统上设计的角色分工也并不完全契合。大家设想的能提升人效,对老板来说基本不太重要,因为无法通过提升效率减少一个身兼多职的员工。

老板们对数据的及时性并不像他们声称的那么看重,平时忙于飞来飞去谈业务,更习惯月初月末看看财务的账单。

似乎推动系统进展,更像是老板一时热血的产物。事实证明了大家的猜想,在离开客户一两周内,大家还在就客户提出的问题,不断开发和优化,而客户,已经渐渐地不再登陆,甚至在通讯录上不再回复。

03 几点心得

故事讲完了,我们来聊聊几点心得。

1. 关于项目

老板目标不够清晰,我们到底应该怎么做?

在故事中,我们能看到以经验决策的老板,以及技术负责人,都有自己做事的目的和初衷。

但产研视角和业务视角的天然不一致,以及层级的差距,让项目在落地的时候,往往缺少上层的方向指导。这种情况下的话,再高的自由度也都是枷锁。

所以我们需要引导各方来定义自己的指标。

放弃极其高远的长期主义和宏观视角,要的是每一个阶段成功和失败的指标。

例如上面的客户转化图,我们可以把每一次转化都视作当前的工作阶段,那我们每个阶段,如何定义自己的成功和失败?这是可以和老板探讨的内容。

客户维护谁来做?

客户demo完成后,事实上应该由专职的销售或者客户成功介入。

让客户使用有的时候更像是一个关系问题,而非如何体现产品价值的问题。

2. 关于用户和产品

真正最小化启动是什么?

故事中,我们采用了把企业内部个性化的内容删除,只提供通用能力的方案,另建了一套SaaS系统。

但实践上,还可以用更小的方式mvp。

例如改造当前系统的权限模块,给客户主要角色开设权限,每一个客户都作为一个业务主体,让客户能查看和管理自己业务范围内的数据。前期不需要让客户各个角色都参与进来,只需要主要角色能够尝试使用,跑通流程即可。

是先有客户,还是先有产品?

内部系统最容易陷入的问题,就是拿着自己的雷神之锤,到处去找能下嘴的钉子。

故事中的业务思维就是我们有啥,就去找类似的客户,而产品的思路是先找客户,再来在现有的产品上改造。

事实上,也可以结合两者的思路。

我们要明确适用于内部的系统之所以好用,是有无数的管理流程和规范,无数技术支持和优化,才让他能产生对应的业务价值,也具备不错的体验。但我们把这么一个庞然大物都吐出给客户,能完美适配的又有几家?哪怕主要诉求相同,面对扑面而来的多种概念,很多客户一接触就晕掉了。

我们还要明确的是,C端用户可以打痛点和痒点,而B端客户只能打痛点。老板每天要解决的事情林林总总,不痛的事情无法引起关注,哪怕短暂的进入todolist,也很快就会被遗忘。

这就是为什么当很多客户体量大了,才会操心某些场景下的效率问题。

例如大量的对账,算薪,在每天算10笔的情况下,无论是员工自己还是老板都承受得起,如果每天来到上千笔,业务吐槽工作量大,老板面临多请人带来的成本提升,相关人员收款慢,存在流失风险,同时公司还要承受错漏的情况,问题陡然变得严重。

再拿这两年的出海热来说,其实是很多客户准备出海了,才会担心合规和安全问题,同时这类的产品才有立足空间。

阶段不同,问题的重要程度确实不同。

综上,我们要明确的是:

  1. 现在产品的优势在哪里,哪些画像的客户最能理解和匹配我们的优势?
  2. 我们的优势在客户的经营里,是多急需解决的问题?
  3. 结合1,2点,我们是否需要另建优势?

而在另建优势的部分,是老板和业务同事更适合使用行业经验的部分,访谈他们经历的痛点,看看市场上的竞品,或许能给我们一些启发。

专栏作家

假装是运营,微信公众号:SaaS学姐,人人都是产品经理专栏作家。10年产品,专注B端,负责过行业头部SaaS产品并经历过完整的生命周期。熟悉金融、物流行业。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 做产品大小厂都呆过,有几个感想分享一下。
    1、B端,最好项目转化产品,客户有了以后再考虑转化成标准化产品。前期有解决方案,ppt,高保真界面就够了。不然回本压力巨大。
    2、提效、降本、增收、保质、风控,只要干B端,逃不出这10个字。奈何老板,最喜欢听,能省多少钱
    3、一件事的难易度取决与大环境,顺势而为,B端国央企、政府的需求,基本都得私有化部署,不可能把数据存到别人的服务器。在政策上就制约了saas发展。民营企业在寿命、盈利、业务上变化大,需求侧不稳定,saas不太好发展。

    来自北京 回复
  2. 业务体量和产品不匹配,这是我踩过的最大的一个坑。系统能承载几十万人的业务,在几十人的小公司身上就翻车了。小公司一问三不知,基本上没法完成交付

    来自浙江 回复
  3. 公司正准备SaaS化,太难了

    来自广东 回复
  4. 看到“飞往客户调研那段”实在是绷不住了。怎么会有人可以用这么简短的文字如此准确的描述这段奇妙而复杂的心路历程。

    来自广东 回复
  5. 内部系统转为产品级系统,大多数需要基于业务沉淀的基础上进行产品架构层面的重构。

    来自上海 回复