私有化部署探索之路-新手篇

链接
写在前面

SaaS企业服务随着国内公有云技术发展并兴起，在市场的演进过程中，SaaS产品私有化部署成了很多行业客户的明确诉求。但在实际的业务团队中，负责私有化项目的同学可能是PM、是PD，也可能是设计师，绝大多数人并不具备丰富的交付项目经验。因此，今天想从项目管理的角度，跟大家聊一聊如何通过设计思维与方法解决私有化初期的管理问题，希望能够将过程中沉淀的通用经验分享给在实操阶段迷茫的项目管理者们，至少让大家在起步阶段知道从何入手。

文章概览

本文共有4811字，大概需要8分钟阅读。

部署

私有化部署是一种应用的部署方式，又称为“本地化部署”，与之相对应的还有公有云部署及私有云部署。

私有化部署

指产品应用运行在客户本地服务器/计算机中，企业客户需自行搭建资源环境；

优势： 企业私密数据的安全性更高；内网环境中，网络传输速度更快；应用与其他企业应用可集成性更高；

劣势： 费用更高，涉及硬件费用、软件费用、部署实施费用、后期维保费用等成本；

公有云部署

是SaaS应用的主要部署方式，云资源（服务器、存储等）均由云服务商提供，用户通过互联网获取应用并使用；

优势： 成本低、扩展性较强；

劣势： 资源与数据均存在云端，数据缺乏控制性与保密性，网络性能相对本地来说缺乏稳定性；

私有云部署

指企业传统数据中心在云上进行延展，针对性的进行算力加强或存储扩容。私有云大多为一个客户而构建与使用，也可由该组织、第三方或两者联合使用、管理与运营。

优势： 相比公有云，数据、安全与服务质量均有更高保障；客户具有构建云的技术设置，可在此技术上进行应用部署；

劣势： 安装成本高，高度安全性可能会导致远程访问困难等问题。

对于SaaS工具型产品来说，私有化部署能力的建设主要有以下3个核心价值：

1. 客户的安全需要

私有化部署作为具有中国市场特色的产品服务模式，需求主要来源于政府、金融相关的企业。客户使用云平台时，需严格满足监管部门的安全合规需求。当SaaS产品支持私有化后，系统数据完全私有化，可以有效降低企业数据丢失和泄露的风险，大大提高企业数据的隐私和安全性，能够更好地满足此类行业客户的诉求；

2. 行业竞争

私有化部署具有交付难度大、人力成本高且回款周期长等特点，但在争夺客户的关键时期，竞争对手都已具备相应的服务能力，且客户需求已非常明确时，这个能力就变成必须要补齐的短板。

对于工具性产品，私有化部署也是产品商业化的重要组成部分。通览各行业SaaS产品，相对有效的商业模式是SaaS订阅（中小企业）与私有化部署（大企业与特定行业）相结合，用户需要什么我们都有对应的模式和解决方案能够提供，并保证持续优化与共同发展。

3. 挖掘客户需求的有效渠道

相比商务与架构师，产研等职能岗位处于客户服务周期的中下游，对于产品/服务设计，私有化客单沟通过程是一个极好的需求挖掘渠道。1. 与决策层更近，可以对“客户需求”“管理诉求”进行深入挖掘和试探的绝佳场景。2.更容易了解不同行业不同组织在运作及机制方面的痛点与需求，是一个非常好的从【需求定制化-功能/模式标准化】的探索过程。

私有化部署在项目前初期可粗略的分为两个阶段：产品启动阶段（0-1）与服务运行阶段（1+）。产品启动阶段是产品能力从0到1的建设阶段，当服务模式跑通后，即可进入服务运行阶段，后者要做的更多是对不同服务节点的优化工作。

由于产研团队有限的人力与资源，用体验设计的“效率”思维来进行项目推进是一个不错的选择。“效率”推进的核心点在于：【借平台】 与 【标准化】 。

借平台，是要尽可能多的了解集团内已存在的商业化工具与平台，无论是营销平台、产品管理平台还是合同流程平台等，利用其扩展我们自身的产品、服务与销售能力，释放项目人力；

标准化，需将输出物（产品、流程、文档……）在交付时尽力保证其标准化，可复用，能拼装，提高协同与交付效率。

对于SaaS工具产品的私有化部署，产品或设计的同学大多是在做项目管理的工作，也会补位售前、售后等工作。项目启动阶段，更多精力会投入在产品本身的功能调整与适配、完成定价方案、补充完善各类文档及跑通产品上架相关流程。

1. 产品改造

与SaaS版本不同，私有化部署对应的产品版本往往需要进行或多或少的改造，来保证产品在客户网络环境中的可用性。在项目初期，尽可能提供相对标准的产品版本，减少定制开发需求，如必须进行定制开发，可根据产品属性谨慎评估，适时引入供应商。

由于客户部署环境的特殊性与不可控性，在产品版本输出时可优先关注以下通用模块：

• 登录模块： 由于服务器处于内网环境，常用的手机扫码、三方授权等登录方式均无法使用，此时需根据客户需求或产品本身规划的能力来进行方案调整，如网络环境允许可选择SSO单点登录，也可选择更为传统的邮箱+密码登录；
• 账号与人员管理模块： 由于登录方式的调整，与之相对应的人员管理、账号管理等模块也需要进行相应的调整与升级；如果业务包含更多形式的应用或插件，这些模块也需要考虑兼容方案或剔除。
• 消息通知模块： 内网环境中，对于主流的短信消息推送、小程序、服务号应用推送等均无法正常使用，产品需提供兜底的消息通知能力。如客户期望能够与其内部OA系统进行打通，那么需基于客户需求、产品实际人力、供应商报价等多因素综合评估后，才能推进采买与交付流程。
• 基于三方合作的功能模块： 如果产品中集成了很多开发平台或合作平台的能力，那么这些功能在私有化部署时需【阉割】掉，除非客户财大气粗会为了某些功能而私有化掉一个其他产品，但在SaaS商业中，想想也不是特别合理。。。
• ……

2. 刊例价设定

定价对于一个产品是非常重要的环节，是一整套基于“钱”的销售策略。私有化部署的收费包含的项较为复杂，一般由产品标准费+产品买断费+产品部署费+产品定制化费用+产品运维费组成。产品初期的定价方法推荐：竞争定价法&成本定价法，但实际报价大多会结合实际的人力投入成本来综合定价，同时，也会给商务设定对应的折扣空间。

• 产品标准费： 甲方对软件/系统的所有权购买费用（不包含源代码），基于目标客户 / 当前客户群优化过的产品或服务标价。常用的定价方式有按用户数量定价、按使用量、分层定价、统一定价、功能定价等多种模式，可根据自己的产品特性综合分析后设定。
• 产品买断费： 甲方对软件/系统的所有权购买费用（包含源代码），可对源码进行占有、使用及改造。
• 产品部署费： 实施交付所需的服务费用，一般部署周期在2周内，按实际项目复杂度进行报价与统计。
• 产品定制化费用： 基于客户提出的定制需求来进行评估的服务费用，不同场景与需求，定制费用也会有很大差异，大多需要有明确的功能方案后才能进行报价。
• 产品运维费： 包含产品的升级维护、bug修复、培训及问题咨询等。

产品前期，能够基于产品自身价值拟定出定价方案已经是最佳策略。在定价推出后的一段时间，需保持与商务及供应商代理的紧密沟通，来验证定价方案与理想客户的匹配程度，为后续的策略优化收集证据。

3. 标准化文档【重要】

为了能够快速将私有化服务的商业模式运行起来，便于不同服务环节中的人员沟通与协同。项目前期优先提供核心文档，保证每一个输出的文档足够标准化，并能为后续的内容变形做准备，提高编写效率。依赖以下5个核心文档，基本可以做到商机进入后，项目成员、合作方甚至合作伙伴能够快速了解产品与服务，并进行商机跟进与推进。

• 产品功能清单： 此文档对内对外都很重要。对内，便于产研团队内部沟通对于功能模块的调整与删减；对外，方便销售与客户快速了解产品能力与功能模块。主要包含1级功能与2级功能即可。
• 产品使用手册： 对于工具型产品可直接复用帮助文档内容，根据私有化部署的实际功能清单，对帮助文档内容进行优化与调整即可。
• 产品白皮书： 需对产品进行全面综合的整体介绍，主要用于客户查阅产品及能力的资料；需包含的模块：产品综述、产品架构、产品优势、核心功能、客户案例。
• 竞品分析： 为了让销售更快了解我们的产品特性与价值，建议前期就要准备的内容。需包含的模块：行业总览、竞品优劣势、自身缺陷规避、打击竞品的要素等。
• 私有部署版安装手册： 技术文档，通过此文档可清楚了解技术方案与安装流程。此文档需技术同学输出并形成标准化文档。

4. 完善标准化流程

在产品商业流程和机制方面，不同体量的公司会有较大的差异性，但对于产品来说，我们仍保证“效率”优先，在人力有限的基础上让模式先运行起来，因此，以下两个维度可以优先考虑接入标准化流程中。

• 【基础】商业化产品管理平台：如果产品初次进行商业化，需要将产品信息、定价信息等录入至商业化产品管理系统，此系统可能会与企业合同、财税等业务模块挂钩，可供销售完成产品采购、供应商服务采购、结算、折扣审批等合规流程，保证交付项目的流程效率与流程质量。一般情况下，未接入商业产品管理系统的产品将无法对外进行客户交付。
• 【效率】营销知识内容平台：此平台多为销售商务相关职务的同事设置，产品同学需将产品的相关信息、文档等同步在平台，同样是为了提升销售、商务、架构师等在销售环节对产品信息的快速了解与商机推进的效率。当产品沉淀更多经验后，核心文档可进行更细致的内容拆分补充，例如补充客户案例库、标前指引、常见问题标准化话术、销售标准化话术等，产品介绍也可以针对不同的受众进行通用版及高层汇报版的拆分，逐渐完善产品信息，并为商务的售前工作提供充足的弹药。

私有化的商务与交付流程环节多，链路长。产品初期，我们更多的是在尝试跑通全流程，磨合交付机制，每个产品也会有各自的行业属性与特征。在这个过程中，产研角色主要参与在售前服务环节和交付售后的客户沟通环节，在此阶段需关注以下三点：

1. 商机处理：

产研项目组成员参与的商机主要来源于两个渠道，一是通过产品本身流量转化来的商机，另一类则来源于行业销售或商务，第三类生态伙伴所带来的商机可自己形成闭环，暂不在我们此次讨论范围。其中，来源于商务的商机处理流程相对简单，产品只需要解答问题，全流程配合商务进行成单推进。而产品自身流量转化来的商机则需要产品团队自己先明确商机的倾向性，是寻单、比价还是存在真实需求，明确客户目标后，建议立即引入专业的销售同学。客户关系是专业销售最重要的业务模块，不完美的说话艺术+不专业的售前服务可能会为后续的推进带来一些不必要的麻烦。

2. POC版本设置：

POC是Proof of Concept的缩写，意思是为观点提供证据，简单理解就是产品试用与测评。此环节多发生在金融客户内部的比标环节，用以对不同产品进行评估后完成最终选型，是一个极其重要的项目里程碑。对于产品设计的同学，需要尽早将需求同步项目组，并明确POC版本中的限制条件。POC限制大多会通过双条件限制来进行：账号数量+试用时长。

3. 合作模式：

• 与内部伙伴

腾讯云作为腾讯自研产品对外商业化的唯一渠道，可以提供更细分更专业的同事来一起进行商业化共建与推进。因此，产品项目组需与商务、法务、合规等伙伴进行紧密的配合，无论是销售服务、产品上架合规还是合同跟进等重要节点，都需要让专业人士介入，更有助于提升成单效率。

• 与生态伙伴

由于人力的吃紧，交付经验的缺乏，产研团队更需要与专业的生态伙伴进行合作，合力推进产品商业化的步伐。他们既能够帮忙我们完成最终交付、后续运维及定制化需求的支持，部分伙伴也具备自己的销售渠道，可以帮忙卖货。但从伙伴的引入-磨合-独立接单的过程中，还是会出现很多不可控的实际问题，因此在与生态伙伴的合作也需要一个比较长的磨合期。在此之前，更多的交付压力还是会在项目组内消化。

以上内容主要是总结了实操过程中一些关键点，私有化项目的人员配合与交付本身的难度远比想象中复杂且不可控，项目推进与优化需并行，也更需要项目管理者用进化的思维去看待与衡量。我们可以在已有的模式基础上持续优化，在商业市场中不断验证，加速迭代与打磨，才是商业产品该有的态度～

快乐工作，快乐生活
Happy work , Happy life
/
Join us