分类
原创

SaaS – Solution as a Service

SaaS,相信绝大多数从业者都知道其是 Software as a Service 的缩写。然而在企业服务这个行业里工作快四年后,我却更愿意使用 Solution as a Service 这个说法,为何?

当我们谈到 Software as a Service 时,Service 固然是让这个模式性感起来的核心要点之一,但它的开头毕竟还是 Software(软件),这让从业者更多从自己开发的软件的视角去理解这门生意。但软件是内部推演的结果产物,它往往体现的是公司主观的意志,很难避免从自身视角去理解行业和市场。这直接导致不少团队在早期会出现单个功能很具创新性和竞争力,但面对市场需求和客户场景的真实考验时,却往往受挫。

而 Solution (解决方案)则是帮助你从行业视角去不断修正市场、客户认知的一个极佳切入点。因为当我们谈到解决方案时,它是为了解决某一特定领域的特定需求、痛点而构建出的一套方案。它有明确的待解决的问题,有明确的场景,有明确的甲乙方参与角色。是一个从终点开始倒推的逻辑,而不是正向推演。

同时,从解决方案视角切入,也让你能更多的关注 SaaS 这门生意中,除了“软件”以外的那些事情,比如方法论、服务、客户组织现状、……

让我们以一个假想的案例来说明,比如说“咱们开发一个招聘系统吧”,你会如何展开这个命题?是不是脑中已经开始构思这个系统应该有哪些组件?它应该需要简历收集、筛选组件,面试流程管理组件,面试反馈组件,offer发放组件,……。想明白系统结构后,就开始针对这些组件,去做内外部的需求调研,我相信最终会回收回来非常大规模的需求,甚至是新的组件诉求。

于是我们针对每个组件反馈最多的需求进行研发,看起来非常的顺畅,每个组件诉求最多的需求都得到了实现,甚至在某些组件上相比同行还有创新带来的竞争优势。然而真的上线后,却发现在各个种子客户那,都跑得不太顺,一些提需求时表示感兴趣的客户连尝试都不愿意尝试,市场反应很差。我们经常会说,这是新功能 GTM(Go To Market)工作没做好。

可 GTM 做不好的真正原因是什么?我就一个具体的需求场景展开来讲讲:HR 和面试官在面试流程中的互动和管理。

经过调研,之前市面上的面试系统普遍存在一个问题,就是面试整个过程中 HR 和面试官之间的通知流程做得不够好,面试官不能很好的知道自己的面试安排,面试过程中的简历查看和反馈记录也不方便。综合收集到的需求,我们最终决定通过整合企业微信、钉钉、短信,甚至是企业日历,来将面试安排及时的通知给面试官,并且在推送的通知或日历详情中,还包含可以直接打开候选人简历的页面链接,面试完毕可以直接在该页面写反馈。这一切真是太顺畅了。

然而在种子客户 A 这边推广时,却遇到了难题。A 公司给员工配备的都是台式机,面试时并没有可以移动的电脑可供使用。在我方的劝说下,面试官开始尝试用手机打开链接看简历,但没过几天就纷纷反馈手机屏幕太小,简历根本看不清楚,并且一边看手机一边面试也让部分候选人觉得不受尊重,被投诉了。因此该公司最后还是回归到了使用纸质简历。而恰恰,我们主打的市场里,绝大多数公司都是使用的台式电脑。

从这个假想的案例中可以看到 Software 的运作是机器逻辑,是对现实(所有用户都用笔记本电脑办公)有不少假设下的预想流程。而企业服务软件的真正“运作”需要将人、组织的因素考虑进去,如果 Solution 中没有考虑人、组织的因素,那么最终会导致 Software 本身也运作不起来。这样的案例,我见过不少。

讲到这里,你也许会好奇,那我们如何才能设计一个好的 Solution 呢?有几点建议,可供你参考:

  • 明确的痛点&场景描述
    • 一定要坚持从客户及市场中获取真实的痛点,避免坐在办公室臆想出来的“需求”,哪怕这些表述非常的原始,没有逻辑和可行性,但在这一步要收集的就是不经加工的真实表达。
    • 围绕痛点,去收集客户现场与之相关联的不同角色在当前困境中的场景信息,这些信息通常包括角色身份、使用环境、组织结构、使用者能力素质、利益动机等。
  • 客户成功小故事
    • 作为产品的设计者,应该能够准确描述客户使用本产品后,他的痛点和需求将被如何解决,以及解决后会为他带来怎样的价值。
    • 此小故事的结构可参考:
      1. 原来的状态:描述目标客户面临的挑战,他在这个挑战下追求的目标是什么,需求是什么。
      2. 转变:通过一系列事件,展现你的产品如何帮助客户达成目标,克服挑战。
      3. 更好的未来:描述你的客户在克服这些挑战,满足这些需求后,如何有成效的工作着。
    • 一个好的客户成功小故事,有助于在团队内部统一对于客户痛点及场景的认知,从而保证研发过程中能够时刻围绕客户进行迭代。
  • 需求列表&角色列表
    • 产出需求列表时,可以用一个二维表将角色与需求对应起来,明确各个需求在客户内部是被哪些不同角色使用。
    • 因为“企业”并不是我们产品的真正使用者,企业里的“人”才是。因此按角色对需求进行分类,有助于我们保持角色视角,方便发现一些不顺畅的流程。
  • 交付方案
    • 除了设计产品和技术方案外,应该同步进行交付方案的设计,确保设计出来的产品对于服务团队来说是可交付的。
    • 利用角色扮演的方法,来推演交付过程中有可能遇到的客户内部角色、组织结构带来的问题,思考是通过修改产品亦或是服务的方式去解决。

Solution as a Service,虽然某种意义上只是一个文字游戏,但却能让我们日常对市场和客户保持敏感度和敬畏。希望日后的你,也能够经常跳出“软件”的限制,更加全局的来理解这门生意。


原文首发于牛透社《思想洞见 2021》

发表评论

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