SaaS实施交付流程(实施方法论)

您所在的位置:网站首页 软件部署流程怎么写 SaaS实施交付流程(实施方法论)

SaaS实施交付流程(实施方法论)

2023-07-14 13:27| 来源: 网络整理| 查看: 265

上一篇回顾了SaaS实施交付的“前世今生”,阐述了SaaS里实施交付和Onboarding的区别以及实施交付里SaaS和传统软件的区别。

实施交付属于软件工程中的一部分,也属于项目管理,早已有相对成熟的方法论,这一篇,以产品和交付相对较重的管理型软件为例,聊聊SaaS实施交付流程(实施方法论):

SaaS实施交付流程一,项目启动项目实施为什么要做项目启动?因为项目有风险。

工具型SaaS,产品较轻,业务和管理属性弱,上手较快,在企业内部推广使用相对容易。

但管理型SaaS,上系统可能涉及甲方的核心业务,需要多部门多层级的需求调研和流程梳理,不仅在短期内改变员工工作方式,增加工作量,甚至涉及组织架构调整,权责利再分配。往大了说即甲方为达成公司战略目标而发起的流程变革和组织再造。这个过程中,实施阻力重重,经常发生:

1,甲方人员拒绝接受信息化变革,不愿意配合;

2,甲方人员意识不到自己是项目实施主体,协作不积极,拖沓;

3,实施过程中,甲方时不时变动需求;

4,双方项目经理所在内部的资源支持不够,协调困难等等;

以上皆导致项目实施周期过长,交付延误,项目成本增加,严重的话导致交付失败。

如何应对风险?

以上风险无非是双方对项目重视度不够或项目管理能力较弱导致。凡事预则立,不预则废,有风险就有对应的策略。比如项目启动阶段的启动会就是策略之一。

以下表格将启动会的会前准备和启动会的细项,具体描述以及对应的主要交付物已罗列清楚。

一,项目启动启动会的目的?

提升双方认知,尤其是甲方,提高重视度。

信息化建设是一场流程再造,组织提能的变革,若要成功,必须关键人物参与其中,高层背书,且必须通过启动会明确实施主体,明确执行责任,立下承诺,才有希望保障项目顺利交付。

项目启动会不仅仅只是让甲方意识到重要性,乙方内部也需要对重要项目做专门的启动会,毕竟项目经理内部调动资源也未必很顺畅。

二,需求调研

需求调研和蓝图设计非常考验实施顾问的咨询能力。(同时也是管理型SaaS,比如营销类,销售管理类,人力资源类SaaS经常提到的CSM能力之一:不同程度的咨询能力,产品越重,客户越大,业务越复杂,咨询能力要求越高)

SaaS一般是通用型(标准)产品,配置,测试等问题不大,不像定制化产品的交付。SaaS实施更重要是充分调研并且输出尽可能满足需求且能跑顺畅的蓝图。

调研什么?

详尽调研业务,流程,管理,数据等需求。

面向谁调研?

使用对象。比如SaaS CRM,模块涉及市场管理,销售管理,服务管理,订单合同管理,工单管理等,实施就自然涉及这些部门不同用户的调研。

调研失败风险

1,甲方内部流程不成熟,各部门信息化管理水平参差不齐

2,调研对象不懂系统以及相关知识,不知道需要提供什么信息给到实施顾问

3,不同层级需求不一,比如决策需求,管理需求,使用需求等,实施顾问不能只重视决策和管理需求,而忽略了一线的关键需求。

如何应对风险?

实施顾问需要会提问,引导以及反复确认所获悉的信息,才能在有限的时间内了解到全貌,尽量减少理解偏差。

需求调研的目的:

输出调研报告,作为蓝图设计的主要依据。

二,需求调研三,蓝图设计

蓝图设计是基于调研报告,输出的最佳系统建设方案。是将甲方自身业务流程转化成系统业务流程的关键环节。

三,蓝图设计蓝图设计的价值?

给决策层和管理层重申项目目标,项目范围,展示蓝图方案等再塑项目价值,调动高层信心,持续甚至更强有力的提供各类资源和支持,保障项目顺利进行下去。

蓝图汇报包括哪些内容?

蓝图汇报是实施过程中非常关键的节点,不仅是对前期工作的一个回顾,总结,也是项目目标的重申,项目价值的再次体现,以及下个阶段更为具体可行的规划。

蓝图设计的目的?

下一阶段将参照蓝图方案中的《业务流程图》,《系统流程图》,《系统设计方案》等进行系统配置。将“纸上谈兵”搬到“作战现场”。

四,系统配置

如果是定制软件实施,下一阶段将进入开发等环节,但SaaS为标品,不需要产品二开,根据蓝图进行方案实现,系统配置即可。

四,系统配置注意事项

在配置环节,实施顾问需要建议和协助甲方成立系统上线后的运维或者IT小组。一是需要IT参与系统实现,二也是需要IT对系统逻辑架构,各配置清单,文档等非常清楚,便于后续运维工作。

虽然听上去这很Old school,但现状下SaaS并没有我们想象中那样“开箱即用”无需维护。原因不展开了,想了解可参见上一篇《SaaS实施交付的前世今生》

上线前的准备工作:风险规避

1,历史数据导入。在一家历史悠久,业务形态并不简单的企业里,这可能是个大问题,清洗和整理数据可不是数据专员就能迅速搞定的,有可能需要动员全员对数据进行清洗和盘点。这很可能会造成,要么延长交付周期,要么为了赶着上线,降低导入数据的质量,在正式使用后不断返工。

数据清洗和盘点,实施顾问需推动甲方做前置处理,不到等到上线前才做。

2,对配置好的系统进行测试,包括操作测试,集成测试,系统和设备兼容性测试等。确保核心业务和数据流转通畅。

五,上线和验收五,上线和验收上线前准备

1,上线之前需要给全员做系统培训,项目实施其实是知识和技能的转移,比如CRM系统的培训,不仅仅只是操作,针对不同的培训对象,也会有业务技能,管理方法论等等的知识输出。当然,操作以外的赋能不仅仅在实施交付中出现,交付后也是CSM持续传递给客户的价值点之一。

2,系统上线还伴随着甲方内部出台新的管理制度,确保执行到位,系统可以更长久的运行下去。

验收前准备

上线后试运行一段时间如果甲方认可,就能签字验收了。

SaaS和传统软件在此阶段的差异

传统软件的实施交付,甲方验收了,乙方收到回款,才叫银货两讫,《系统验收报告》是依据。

而SaaS软件,虽然开通了即可在财务上确认收入,但签收验收报告的仪式感和意义依然挺重的。

六,交接CSM

项目验收意味着双方的项目实施就算是结束了。但对于SaaS厂商来说,系统在客户企业落地才迈出了万里长征第一步。因此,项目交付后,双方可能会发生人员更替,此时厂商内部的客户交接,CSM对外的客户对接都必须衔接到位。

CSM交接有两个核心点:顺利交接和客户健康

1,内部交接给CSM最重要的是交付物。

交付物在整个项目实施中非常重要,所有的信息资料都要以文档形式存底。

一是必须作为交付物提供给甲方,甚至在实施每个阶段交付物都还需要甲方签字盖章才能往下推进工作。其次对内也要交接给CSM便于持续服务客户。

2,客户健康:是SaaS和传统软件实施的差异点。传统软件多私有化部署,无指标衡量客户使用是否健康,SaaS有客户行为数据,比如活跃度,健康度等指标客观反映客户使用状态。详见指标体系构建系列。

范特西:客户成功指标体系构建(一)——常见指标范特西:客户成功指标体系构建(二)——常见指标范特西:客户成功指标体系构建(三)——指标拆解范特西:客户成功指标体系构建(四)——指标应用和优化

项目交付后即使交接给CSM,实施顾问也要在一段时间内对客户的使用负责,绩效或奖金也和客户健康指标挂钩,这样才能让实施交付以客户成功为导向而非一味的追求验收和回款。

六,交接CSM

以上就是以较复杂的管理型SaaS产品为例的实施方法论和交付流程。当然,不少SaaS产品的实施也不需要这么复杂,可能一两天就能走完以上所有阶段。

客户生命周期走完了“实施交付”,再往下走,就到了客户成功运营流程,下一篇会详细写到客户成功运营流程,有机会再写一遍以活跃度为基础的健康度指标。

2021/01/01补充:

今天和两位从事传统软件多年转型SaaS的老朋友杨大侠和郭老师,聊了聊SaaS实施,有几点认知和看法觉得挺有意思的,值得深思:

1,杨大侠说:“我对实施交付的核心认识,是让客户保持安全感的一个过程。你只要时刻让客户感觉到自己是安全的,项目交付就是成功的,客户也会用好。”

比如项目实施交付流程中有两个阶段就很敏感:

一是项目启动阶段:甲方选型时主要和乙方销售和售前团队打交道,商务阶段结束后乙方将由实施交付的团队接手项目。

二是项目验收阶段:此时乙方又将更换人员如CSM和甲方对接,负责后续的系统落地。

这两个阶段,甲方一般两次付款,首款和尾款。付款后马上面对不熟悉的乙方人员。在这个过程中,如何给予客户充分的安全感,不让客户产生质疑?

所以杨大侠认为,站在乙方的角度,从销售阶段就应该开始设计,如何在接下来的每个阶段让客户有足够的安全感。

2,郭老师则是另一个视角,认为项目管理(实施交付)和SaaS天然相悖,因为项目管理一定有ending,有可交付的成果;而SaaS在理论上是无尽的,永远在迭代。

我说国内SaaS早期也没有实施交付一说,由轻到重发展至此,眼下SaaS也达不到开箱即用,即使产品功能再多,也未必能直接拿给客户用,还是需要形成方案去交付的。SaaS实施交付也是借鉴了传统软件。

郭老师说:如果没有借鉴学习,SaaS说不定还真有一条康庄大道。

嗯,我想想,很对。

非常感谢我的搭档林雨潇(文末上照片),提供了非常多专业意见和实战案例让我得以完成这篇文章。

客户成功路上有点孤独,如果你觉得文章还不错,欢迎点赞评论和转发,让笔者获取更多交流和反馈,得以完善。



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3