让我们透过Workday来看下一个大型SaaS企业管理软件是怎么实施的，以及实施在整个产品体系中的特殊地位，还有富有争议的“定制”问题。

01. 实施体系概述

架构设计，交互体验，和学习培训基本都是产品的前期的投入和准备工作，而实施则是一个产品真正为为公司创收的开始。

如果把前期的准备和投入比作是农作物的种植过程的话，产品实施就有点像是是农作物种收割环节。

农作物要有好的收成（营收）不仅仅需要在种植过程中辛勤打理，认真进行灌溉，施肥，打药（产品的打磨）。

收割的过程也需要仔细盘算，你要有好的工具，等待合适的时机和天气，快速完成收割，并晾晒到一定程度，及时运到仓库，整个季度的种植工作才算是大功告成。

在整个种植的周期中，即使平时打理的都不错，如果在收割的时候不用心，不好好计划和执行，最终的收获就会大打折扣，之前的辛苦也都白费了，那是非常可惜的一件事。

产品也是一样，不仅仅要在设计开发阶段好好打磨产品，也要在实施阶段兢兢业业满足客户需求，才能顺利收款、赢得口碑。

聊SaaS软件实施我们在聊什么

几年前刚入行时总觉得实施不就是把开发好的产品给用户安装、部署、配置好吗，就像一个电视机设计好了，生产好了，最后给用户送到家里，安装好。实施顾问就像上门安装的师傅，电视安装好，接通电源，配置一下，出图像了，工作就算完了，好像没有什么大不了的。

但是做了几年SaaS管理软件“上门安装师傅”，就知道了，一个SaaS管理软件的实施和一个电视机的安装好像还真不是一回事。那我们就和电视机的安装对比，看下一个大型SaaS企业管理软件的实施是怎么回事。

业务诉求实现问题

首先，用户对一个SaaS管理软件的需求比一台电视机的需求复杂很多，客户想要通过一个电视机实现的功能，是有限的，清晰可见的，每个用户对一台电视机的诉求基本上都是一致的：收看电视节目和网络节目。

因此一个电视机的形态，使用方式，可以提供的能力在它出厂时也都基本是预置好的，基本上是开箱即用的状态。

而一个用户对一个SaaS管理软件的诉求则复杂很多，他们希望通过软件实现业务的办理，流转，审批，数据的记录、沉淀和提取展示。而这些东西因为企业规模，行业属性，文化传统的不同在客户间会有很大的差异。

因此一个SaaS管理软件一般都有很强的可塑性，大多数SaaS管理软件出厂时只是一个空壳，大量的功能，流程都需要在实施过程中被配置，创造，或者说被释放出来。

数据迁移问题

其次，安装一台电视机是不涉及什么历史数据的迁移问题的，最多把你的使用偏好再设置一遍。而一个SaaS管理软件除了提供操作功能以外，还有一个隐形的功能是数据存储。

所以当你安装你一个新的SaaS管理软件时，一个必不可少的步骤就是数据迁移，你需要把以前的系统上的数据按照新系统的数据格式导入进来，或者你以前没有系统，你也需要把现实中的数据录入新系统中，这样系统才可以正常运转。

因为系统间数据格式往往存在很大差异，或者数据量的问题，这个过程往往是一个比较繁琐和耗时的过程。

系统集成问题

还有，一台传统的电视机其实是独立的一个系统，就是看电视，它不需要与其他设备连接（当然，物联网和智能家居兴起以后，可能会有改变）。

但是一个SaaS管理软件，往往不是一个独立的系统，它经常需要与其他系统，比如生产业务系统，财务系统，OA系统，薪酬系统，BI系统，考勤机等等进行连接打通，彼此进行数据共享。

项目管理问题

基于以上这些点，我们也可以看出，一个SaaS管理软件的实施的复杂度和时间跨度都是安装一台电视机不是一个量级的，所以聊到SaaS管理软件实施，另外一个不得不聊的话题就是项目管理。

项目管理甘特图示意-非WD

复杂度主要有三个来源：需求复杂、工作内容复杂、和过程复杂。

因为需求复杂，就需要考虑如何保障用户的需求是被准确实现的，是符合验收标准的，实施团队离场后用户是可以独立运作的。

因为工作内容复杂，就需要考虑项目团队按什么维度去分工（比如功能模块、接口和数据）以及大家应该如何配合。

因为工作过程复杂，就需要更科学的实施步骤，比如什么时间可以开始需求调研，什么时间可以进行数据的收集，什么时间可以进行接口的配置，以及彼此的先后顺序。

另外更长的时间跨度，也需要项目有常规的进度跟踪和成本跟踪，以保证项目是可以按照计划的时间点准时上线的，并且项目人力预算可以支撑到项目结项。

希望这一章节可以给到大家一个关于SaaS软件实施的初印象，让大家知道我们聊实施的时候是在聊怎么样的一个事情。

从好产品到现金牛

实施的背后是成本

这两年当我回头去看自己做过的一些项目，并把实施和产品体系的其他环节放在一起看时，除了感悟到实施是一个“收割”的环节，我也开始越来越明白实施在整个体系中的更深层意义。

在我的理解中，一个大型管理软件的实施不再是一个系统的安装、部署、配置那么简单，它是仅次于产品设计与研发，决定产品生死存亡的第二大命脉。

因为实施的背后是成本，而成本代表着复制能力，代表着变现能力，代表着盈利能力，也代表着生存能力。

成本的意义

首先成本控制的重要性对各行各业各类产品来说都是毋庸置疑的，不管产品是实体的，数字的，抑或仅仅是一种服务。

如果一个产品很好，但是成本极高，这个时候又想定一个有吸引力的价格，企业是非常难盈利的。如果定价高一点，这时候产品就像奢侈品，可能仍然会有人买，但是销量就很难提升，总体盈利能力仍然有限。

所以在以同等价格提供同等质量的产品的情况下，成本就是竞争力，如果你的成本够低，你就可以比竞争对手活得更长，活的更好。

记得在一本书中读到过，苹果公司的产品理念是：以略高于同类产品的价格，提供质量远远好于竞争对手的产品。

即使是这样的价格策略，它仍然能成为全球最赚钱的企业之一，并长期处于全球企业市值的榜首。

这背后不得不归功于苹果生产成本控制能力和超强的供应链管理能力。Tim Cook被乔布斯选为CEO接班人，也离不开他在这个供应链及成本控制层面的贡献。

软件公司利润公式

成本控制对于一个硬件产品的成功非常重要，而在软件行业，成本的影响就更加明显。

上世纪90年代软件行业催生了像比尔盖茨这样的世界首富，就是因为一个秘而不宣的常识：“软件产品对比其他产品有超低的复制成本。”

一家软件公司的盈利公式简单来说是这样的：利润 = 单位价格*销量 - 研发成本 - 单位复制成本*销量 - 市场及运维等其他成本

一家软件公司只要有足够好的产品，足够大的用户群体，足够宽的护城河，它就无敌了，因为它复制成本比较低，复制起来非常快。

比尔盖茨财富的早期积累就在于微软开发了非常优秀的软件（操作系统和办公软件），这些软件几乎每个人都会用的到，最关键的是它的复制成本几乎为零，几乎可以做到一次生产，无限复制，无限盈利，“一本万利”说的就是这种事情吧。

当软件行业兴起之后，排在富豪榜榜首的更多是互联网行业和软件行业的，而不再是造房子或者卖衣服的，这与软件的复制成本不无关系。

这也让我想起前一段时间看到一个问题，“为什么麦肯锡作为最顶尖的咨询公司，这么有名，却不是世界五百强呢？” 看到有一个回答是我比较认同的：“因为麦肯锡卖的是最顶尖的咨询顾问和他们的想法，而人才和咨询过程都是不能大规模快速复制的。”

管理类SAAS软件的成本分析

既然软件产品的复制成本这么低，那为什么说实施是决定管理软件类产品生死存亡的第二大命脉呢？

是的，系统软件和个人应用类软件的复制成本几乎为0（最早只需刻成光盘进行分发，现在通过网络就可以进行下载），所以这些软件的复制成本虽然起作用，但往往不被计算在内。

但对于管理软件来说，复制成本的因素却不得不被高度的关注。因为一个SaaS管理软件的复制成本就是实施成本，虽然实施成本比起研发成本来说确实很低，但是并不为0。

上面我们也聊过一个SaaS管理软件的实施其实是一个比较复杂的过程，因为这个过程存在且成本不为零，通过软件利润公式，我们就可以清晰看出它是怎么影响最终利润的。

在我在研究Workday实施体系的时候，我发现几乎所有Workday做的努力（标准化、方法论、实施工具、外包模式、顾问知识及信息获取等等）都是在围绕“降低复制成本”这一个主题。

首先，如果有更好的实施模式，更好的实施工具，可以时间上更快，资源耗费更少地为客户实施一个系统，在价格不变的情况下就会为产品增加更多利润空间。如果希望通过价格吸引更多客户，降低的成本也可以为产品提供更多降价空间。

另外特斯拉一个深谙降低复制成本之道的企业，虽然不是软件领域的，但是道理是相通的，特斯拉投入了大量的资金去研究“一体铸造技术”，并打造了世界上最大的铝铸造机制造单体模块，取代70个粘接和铆接在汽车后部车身上的部件，这些看似破天荒的动作都是为了降低复制成本，这也是特斯拉可以快速实现大规模量产的最关键因素之一。

其次，实施成本对总体盈利的影响是呈倍数效应的，软件的研发成本基本上是相对可控的，每家厂商的研发成本可能有多有少，但基本只发生一次（一个版本一次），但是只要你的客户足够多，实施成本可能是无限发生的。每降低一点单位实施成本，就可以成倍增加整体利润。

实施是一个软件开始创收的开始，实施/复制成本也是好产品成长为现金牛必须跨过的门槛。

小结

我永远认为产品的质量对于一家企业的成功来说是第一位的，好的质量（满足用户需求，带来卓越体验）为你带来用户，让你活下来。但是同时拥有优秀的成本控制能力和利润复制能力，才可以让你活的更好，最终走向伟大（至少财务层面）。

这也是为什么我说”实施的背后是成本“的原因。

理解了实施背后的这一层意义，再看Workday在实施方面的很多举措就非常容易理解了。

定制 or not？

说到Workday实施，绕不开的一个话题就是Workday“几乎不支持定制”，这也是外界对Workday乃至大部分SaaS软件争议比较大的一个点。

什么是定制化？

先澄清下这里所讲的“定制化”的概念，本文讲的定制化是指需要通过代码开发对原有产品进行一些内在逻辑修改、或者在原有产品基础上新增一些功能或页面的产品交付行为。

Workday除了支持custom object（客制化对象），custom field（客制化字段）这样的一些简单扩展以外，新增页面、新增业务流程种类、新增功能、修改现有功能逻辑或计算逻辑这些一概不支持，也就是所谓的“几乎没有定制能力”。

这里也澄清下一个容易混淆的点，Workday能有现在这么大的客户量和体量，Workday当然不是用户的任何需求都不满足，而是它提供了一个很大的能力范围，用户可以在这里能力范围内配置实现自己想要的各种东西，但是超出Workday这个能力范围以外的需求Workday并不会特别为某一个客户去实现。

如果把需求收集设计成一个用户调查问卷的话，Workday的模式更多是让用户去做选择题，而不是做问答题。Workday告诉你我们的系统提供了很多模式供你选择，你要选那个？我们的很多功能都设计出了很多选项，你可以根据你的选择搭配出一个你想要的套餐。

但是Workday不会直接问你想要的功能是长什么样的，并按照你的想法去帮你设计和实现，这也是SaaS标准化模式下的实施的一个特点。

如果这个概念还不是很好了解的话，也可以打开特斯拉官网，看看特斯拉是怎么买车的，特斯拉其实也是采用了类似的一种模式。

特斯拉不会问你想要什么颜色，也不会问你想要几个电机，我们帮你特别设计。

而是告诉你我们有单电机版和双电机版，你要选哪个？我们有黑白灰蓝红五个颜色，你要选哪个？自己去选择搭配出一款你想要的车。

面临的抉择

很多用户说Workday这样不够灵活，其实所有走标准化路线的产品都无法逃避这个所谓的“问题”，Workday也不会不知道用户对“不能定制”的抱怨。

如果一个事情“得一利而有十弊”，你还会做吗？Workday在做出“是否支持定制”时就面临着这样的问题。

支持定制化开发可能会让一部分想要个性化或者需要定制功能的用户满心欢喜，但却会给厂商和用户带出一系列的麻烦事。

比如开放多大程度的定制能力合适？比如如何保证定制功能不会影响到其他现有功能的运转？定制化谁来实现，成本如何核算？定制是否能在公有云上做？定制之后，各个模块的体验如何保持统一？定制的内容如何进行升级和维护？做了定制之后系统是否还可以升级？如果可以升级，怎么保障不影响定制功能的运转？如果不可以升级，这样的产品用户是否还想要？

这些问题解决不好，对Workday和用户来说就可能是很多额外的成本，随着定制化用户和定制化功能的增多，Workday也很可能会陷入尾大不掉、积重难返的被动局面。

Workday对于这些麻烦事的解决，貌似还没有想到一个比较好的方案，在把这几个问题想清楚之前，我想Workday是不会趟这个浑水的。

当下的答案

我理解Workday对待定制化开发的策略基本上是“战略性舍弃”，也许Workday早已确信定制化开发天生就不适合纯SaaS的云产品。

如果用三句话总结Workday这方面的态度的话就是：

第一，目前明确不支持定制，所有用户统一一个版本，升级方便，维护简单。

第二，如果希望有求必应，实现各种定制化功能，那就别选我们，选了我们就按照我们设定的规则玩。

第三，虽然我们不支持随心所欲的定制，但是我们会沉淀和抽象出越来越多用户在意的参数，提供越来越丰富的选项和配置能力尽可能地实现用户想要的“个性化”。

不支持定制也是降低复制成本和运营成本的考虑，现在的答案是否正确还有待时间验证。但对于当下的Workday来说，虽然被抱怨，但是如果这样可以让自己走的更放松，走的更轻快，走的更远，又有何不可呢。

来源：人力资源产品设计观察