CRM选型先答部署这道前置题，云端还是自建到底决定候选剩几成
CRM选型先答部署这道前置题，云端还是自建决定候选剩几成
一、部署方式不该留到最后再问
选型讨论通常从功能开始，谈到最后才想起问一句「这个能不能放在我们自己的机房里」。这句话问得太晚，前面所有比较都可能要重来一遍。
部署方式是少数几个能一次性砍掉大量候选的选项。它不像功能那样可以慢慢补齐，也不像价格那样可以谈，它是一个前置条件：满足就留下，不满足就出局。把它放在最后，等于把最省力的一道筛选放在了最费力的地方。
更合理的顺序是先问这一句，再谈其他的。范围一旦收窄，后面的比较会轻很多，参与讨论的人也不用在注定出局的方案上花时间。
- ● 部署方式是少数能一次性砍掉大量候选的选项
- ● 先问这一句，等于把最省力的筛选放在最前面
图1：数据放在哪里，先得有个答案
还有一类情况也会提前决定范围：企业内部有没有统一的账号体系。如果有，接入方式会直接影响使用体验；如果没有，就要考虑单独维护一套账号的成本。
这类问题属于技术侧的判断，但结论会影响业务侧的日常，所以最好一起讨论。
数据归属还有一种中间状态：一部分放在自己这里，一部分放在外部。这种安排在实际中并不少见，但它对两边的同步能力要求更高。需要提前确认可行。
三种安排各有代价，想清楚再选。
二、数据放在哪里，是这道问题的核心
部署方式听起来是技术问题，实际要回答的核心只有一句：数据最终放在哪里。
放在服务方的服务器上，好处是不用自己买设备、不用自己运维、开通就能用。多地协同也简单。不绕弯子，放在自己的机房里，好处是数据不出企业边界，出问题时能自己上手，也不受外部服务状态的影响。
两种做法没有绝对优劣，区别在于企业更在意哪一头。在意上线速度与运维投入的，通常选前一种；在意数据边界与自主掌控的，通常选后一种。真正要避免的是两边都想要：既想快速上线又不想投入运维，最后往往两头都不满意。
- ● 核心问题只有一句：数据最终落在谁那里
- ● 两边都想要，最后往往两头都不满意
图2：报表口径不同，部署要求也不同
捋这几类要求的时候，建议把它们写成明确的问句，而不是笼统的感受。比如不要写「我们比较在意安全」，而是写「客户资料能不能只存放在企业自己的设备上」。问句是可以直接拿去比对的，感受不行。
写完之后，把这些问题按重要性排一下。排在前面的应当只有少数几条，其余可以作为参考。
数据放在哪里，还有一个连带问题：出故障时谁先知道。放在自己的机房里，通常由内部先发现；放在外部，往往先由对方通知。
两种方式的通知链条不同，处理速度也不同。这一条值得在选型时就问清楚。
数据放在哪里，还有一个现实问题：谁负责日常维护。放在外部，多半由对方负责；放在自己这里，通常要落到内部某个人头上。
这个人有没有、愿不愿意接，是判断可行性的关键一条。
如果内部没有人愿意接，自建这条路即使技术上走得通。实际也很难长期维持。
三、哪些要求会直接排除掉一部分方案
除了数据边界，还有几类要求会直接决定候选范围。
一类是所在行业的监管要求。有些行业对客户资料的存放位置、留存方式、可追溯程度有明确要求，这类要求一旦存在。可选范围会立刻变窄。
一类是企业自身的条件。如果已经有现成的机房和运维人员，自建那条路会更顺；如果完全没有技术团队，自己维护一套东西会成为长期负担。
还有一类是业务特点。跨地区办公、人员流动频繁、外勤占比高的团队，对随时随地访问的要求更高；业务集中在一处、以内部办公为主的团队，这一项的权重会低很多。
把这几类要求捋一遍，能留下的候选通常已经不多了。
- ● 监管要求、自身条件、业务特点，这三类会直接决定范围
- ● 捋完这三类，候选通常已经不多了
图3：合规要求一出现，可选范围立刻收窄
评价侧重点的变化还会体现在试用环节。简单说，选云端的时候，试用重点是访问速度与数据导出；选自建的时候，试用重点是安装过程与故障排查。
试用看的重点不同，留下的记录也不同，所以试用之前就要把部署方式定下来。
评价侧重点的变化还会延伸到服务约定上。云端更关注服务可用时段的承诺，自建更关注升级与故障响应方式。
这两类内容差别很大，用同一套问法去比较没有意义。
评价侧重点还有一个容易被忽略的角度：将来想换的时候，把数据搬出去的成本有多大。这一点在两种方式下都值得问，只是问法不同。
提前问一次，比用了一段时间之后才发现麻烦要划算。
四、部署方式一变，评价口径也跟着变
部署方式确定之后，评价的侧重点也会跟着变。这一点常常被忽略。
选云端的时候，会格外关注服务的稳定性、数据导出的便利程度、以及能不能随人数增减灵活调整。因为这些东西决定了日常使用会不会被打断，以及将来想换的时候好不好走。
选自建的时候，关注点会移到另一侧：安装与升级是不是方便，对现有设备的要求高不高，出了问题能不能自己排查，有没有配套的运维说明。这些在云端方案里通常不是重点，在自建方案里却是每天都要面对的。
所以同一个评价项，在不同部署方式下的权重可以完全不同。先定部署方式，再去定各项的权重，比相反的顺序合理得多。
- ● 云端关注服务的稳定性与数据能否带走
- ● 自建关注安装升级与自行排查的便利程度
还有一处容易漏掉的事：迁移路径。无论选哪一种承载方式，历史数据都要从原来的地方搬过去。如果原来的数据分散在若干处，搬运的过程会成为一段独立的工作。需要在排期上单独留出位置。
把这件事提前说清，实施阶段就不会临时挤占其他环节的时间。
部署方式提前，还有一个间接的好处：它让预算讨论更有依据。两种方式的支出结构差别很大，先定下来。预算这一栏才谈得实。
五、先定部署，再谈其他
把部署方式提前，带来的连锁效果比想象中大。
首先是候选数量的下降，这一步省掉的时间最直观。其次是讨论议题的集中：范围小了，讨论可以从「有没有」进入「怎么做」。往简单里说，再次是预算判断的清晰：自建与云端的支出结构差别很大，先定下来，预算这一栏才有得算。
还有一层不太起眼的好处：它让技术侧和业务侧的分工变得清楚。部署方式通常由技术侧判断，功能取舍由业务侧判断。把部署先定下来，技术侧的工作可以提前收尾。业务侧的讨论不必被技术问题打断。
- ● 候选数量下降，讨论议题从「有没有」进入「怎么做」
- ● 技术侧的判断提前收尾，业务侧讨论不必被打断
图4：回访这类动作，云上部署就够用
再说一句关于判断依据的问题：部署方式的选择最好由使用需求推动，而不是由设备现状推动。有现成设备是加分，但如果业务确实需要随时随地的访问能力。设备现状不应该成为唯一的理由。
再说一句关于判断顺序的问题：先定部署，不代表功能不重要。它只是把一道可以快速判断的题放在了前面，让后面的讨论集中在真正需要斟酌的地方。
六、这些问题是问得最多的
1、问：没有技术团队，是不是就不能选自建？
答：不一定，但要评估长期维护的负担。如果供应商能提供较完整的安装升级支持，也可以走，只是要把这部分写进服务约定。
2、问：两种方式能不能各用一部分？
答：可以按数据分级处理。敏感度高的内容放在自己这边，日常协同的内容放在另一端，前提是两边能对得上。
3、问：部署方式定了之后，还会改吗？
答：通常在项目周期内不会改。所以更要提前想清楚，避免做到一半发现方向不对。海软CRM同时支持云端与本地承载两种方式，企业可以先按现状选定一种，后续随业务变化再调整。
4、问：云端方式下，数据会不会被锁住？
答：这一点要在选型时明确问清楚：能不能完整导出、导出成什么格式、导出需要什么条件。有明确答案的方案，风险会小很多。
5、问：部署方式会不会影响使用体验？
答：会有一点。访问速度、离线可用的范围、移动端体验都可能与此相关。但这些通常不是决定因素，决定因素还是数据边界与运维负担。
