CRM选型第一步不是比方案，先把客户管理需求落在纸面再开会
CRM选型第一步不是比方案，把客户管理需求落在纸面再开会
一、选型真正难的，不是挑软件
很多人以为选型最难的一步是在几个候选之间做决断。实际做过一轮的人多半会有相反的感受：最难的是在还没有任何候选的时候，把「我们要什么」先写清楚。
软件本身是相对确定的。界面长什么样、有哪些模块、能不能对接，对方讲得清楚。演示也看得见。不确定的是自己这一边：哪些事必须由系统承接、哪些事可以继续用现有方式、什么条件下算验收通过。这些问题在写清楚之前，任何比较都缺一个共同起点。
于是常见的一幕是：会议开了好几次，每次都在比功能，每次结束都没有结论。不是大家不认真，而是没有一个可以对照的东西。
- ● 难的不是做决断，是把「我们要什么」先写下来
- ● 没有共同起点，比较就永远停在比功能上
图1：需求先写下来，比较才有共同起点
还有一个容易混淆的地方：需求文档和方案介绍不是一回事。方案介绍是对方写的，讲的是他能做什么；需求文档是自己写的，讲的是我们需要什么。两者都对，但作用完全不同，混在一起看很容易被带偏。
把两份东西分开放在桌上，讨论会清楚得多。
还有一点：需求文档不必一次写完。第一遍把确定的部分写下来，剩下的留出空白，标注待确认。空白本身就是有用的信息，它告诉后来的人哪些地方还没定。
反过来，把不确定的地方也写得满满当当，反而会让人误以为已经定下来了。
二、需求写不清，会议会一直重开
需求没写清的代价，最先体现在会议效率上，而不是体现在软件上。
同一场讨论会被反复重开，因为每次参与的人不同、记得的内容不同。对「重点是什么」的判断也不同。有人关心跟进记录会不会丢，有人关心报表口径。有人只想知道报价能不能多人协作。说穿了，这些诉求都没错，但它们没有被写在同一张纸上，于是每次都要重新对齐一遍。
更隐蔽的代价出现在实施阶段。签约之后，原本模糊的地方会变成具体问题：这个字段要不要、那条审批走几级、历史数据怎么处理。这些问题本可以在选型前一次性讨论完，现在只能边实施边补，而每一次补都要占用双方的沟通成本。
- ● 同一场讨论反复重开，是需求没落纸的直接表现
- ● 模糊之处不会消失，只会在实施阶段变成具体问题
图2：需求说不清，定制每一步都会返工
还有一种常见情况：需求被写成了功能名。比如写「需要报表」，但没写清报表要看什么、按什么切、给谁看。这样的条目在比较方案时无法使用，因为它不能回答「满足还是不满足」。
所以整理的功夫要花在把功能名还原成动作上。写「需要报表」的时候，再补一句「每天早上打开就能看清前一段时间各区域新增客户数」。这一句补上去，条目立刻变得可用。
需求写不清还有一种更隐蔽的代价：它会让人误以为分歧已经被解决了。会上有人提了一条，有人应了一声「可以」，看起来达成了共识，其实两个人的理解并不一样。
这种假共识在实施阶段一定会以问题的形式回来。
还有一处值得留意：需求文档里最好标明每一条是谁提的。这个信息在后面被质疑时很有用，因为可以直接找到提出的人确认。
另外，条目的语言尽量用业务自己的说法，不要提前翻译成技术名词。翻译过的表达容易在传递中丢掉原意。
三、第一份该写下来的东西：数据类型
需求文档不必写得漂亮，但第一页应该有内容：把企业实际在用的客户相关数据列全。
列的时候按来源走一遍，比按想象写要准得多。客户档案在一处，联系人在另一个文件里，跟进记录散在聊天工具和笔记本上，报价与订单在财务那边。售后记录又在服务同事手里。走一遍下来，通常会发现自己原以为集中管理的内容，其实分了好几摊。
这一步做完，后面的判断会变得具体。数据种类决定了需要哪些字段，字段决定了模块边界。模块边界又决定了迁移的工作量。很多团队是在实施阶段才发现历史数据无处安放。根源就在这一步没有做。
- ● 按来源走一遍，比凭印象列准确得多
- ● 数据种类决定字段，字段决定迁移的工作量
图3：分级这类规矩，属于必须先说清的需求
整理数据类型的时候，建议顺手标一个量级：是小批量还是大批量，集中在少数几个地方还是散在很多个文件里。实话讲，量级不改变结论，但它决定准备的工作量。
量级还有一个用处：它能帮你判断某一条需求值不值得为它单独设计。数据很少的部分，用最简单的方式处理就好。
数据列完之后建议做一次交叉检查：把列出来的数据种类，与当前实际在用的每份文件对照一遍，看有没有遗漏。
对照时最容易被漏掉的，是那些「不算正式」的内容，比如聊天记录里的一句口头确认。
优先级最好由业务侧先给出一份初稿，再由推进的人整理。完全交给推进的人定，容易出现与实际使用脱节的情况。
四、第二份：三档优先级
数据列完之后，第二份要写的是优先级。写法上最有效的做法是只分三档，不要更多。
三档的好处是它逼人做取舍。分成五档、七档的时候，大量条目会落在中间，讨论到最后谁都说不清哪一条更该先做。只分三档，每一档的边界就很硬：必须有的那一档里，缺任何一项系统都不算可用；最好有的那一档里，可以有，晚一点也行；暂时不需要的那一档里，写下来是为了挡住推销。
第三档最容易被跳过，但它其实最有用。把明确不需要的内容写出来交给对方。后续沟通会省掉很多来回。
表1：三档优先级的写法与用途
| 档次 | 典型内容 | 写下来之后有什么用 |
|---|---|---|
| 必须有 | 客户档案与跟进记录 | 缺一项就不能上线 |
| 最好有 | 移动端与审批流 | 有则更好，可后补 |
| 暂时不需要 | 复杂营销自动化 | 明确写出来挡住推销 |
- ● 只分三档，中间地带越少，取舍越清楚
- ● 第三档写出来，是为了挡住不必要的推荐
图4：权限需求常被漏掉，事后补很贵
还有一个延续的效果：三档文档可以当成新同事的入门材料。一个刚接手推进的人，看完三档就知道当前重点在哪里，不必把前面几轮会议的记录全部读完。
这也是把讨论写下来最实际的一处回报。它替人节省了重复解释的时间。
文档写完之后，建议安排一次集中确认。把参与讨论的人凑在一起，逐条读过去，有异议当场改。这一遍花的时间不多，却能挡掉后面很多反复。
五、三档写完，讨论才有了落点
三档写完的第一个变化是讨论的形状。原来大家谈的是「希望有什么」，现在谈的是「这一条属于哪一档」。往简单里说，前一种说法无法收敛，后一种说法可以逐条落地。
第二个变化是候选范围的收敛。把必须有的一档拿给候选方，能同时满足的往往不多。比较的范围会自然缩小。这时候再去比界面、比价格，效率会高得多。
第三个变化出现在签约之后。三档文档可以直接作为验收时的参照：必须有的逐条确认，最好有的排进后续计划，暂时不需要的从沟通里去掉。它让交付有了可以对照的纸面依据，而不是靠印象判断做没做到。
- ● 讨论从「希望有什么」变成「这一条属于哪一档」
- ● 必须有的一档可以直接当验收参照
还有一点要说明：需求写清楚不等于需求写得漂亮。样式、措辞、排版都不重要，重要的是每一条都能被检验。检验不了的条目，写多少都不起作用。
还有一句话值得说给推进这件事的人：需求阶段真正的成果不是一份文档，而是所有人对同一件事形成了同一套理解。文档只是这套理解的载体。
六、常见问题解答
1、问：需求文档要写多正式？
答：不必正式，一页纸也行。关键是写下来并且让参与的人看过，形式不重要。
2、问：需求由谁来写？
答：由每天用这套东西的人先说，再由负责推进的人整理。只有管理者参与，容易写成愿望清单。
3、问：写到一半发现需求变多了怎么办？
答：把新增的部分先放进最好有那一档，不要立刻改写必须有。必须有一档越稳定，后面越省事。
4、问：历史数据要不要在需求里写清楚？
答：要。至少写清有哪些种类、大概在哪里、由谁负责整理，具体数量可以到实施阶段再对。
5、问：需求文档和最后的验收有什么关系？
答：关系很直接。把必须有一档作为验收清单，把最好有一档作为后续计划，交付就有了能对照的依据。海软CRM这类方案在实施之前，通常也会先与客户一起把需求过一遍，把这层对齐做在前面。
