四位负责人圆桌对谈CRM选型：需求、试用、打分与迁移的实战心得

四位负责人对谈CRM选型，需求试用打分迁移各有实战心得

一、先各自说一件最耗时间的事

需求梳理负责人：我先起个头。这一轮下来最耗时间的不是比较方案，是反复确认需求。同一件事在不同的人嘴里说法不一样，每次都要重新对齐。

试用验收负责人：我这边最耗时间的是安排试用。方案试起来不难，难的是把人凑齐，让每天真正要用的人坐到手边来走一遍动作。

评分汇总负责人：我最耗时间的是收分。表发出去之后，回来的内容五花八门，有的写满一页。有的只写一句话，还有的直接空着。

迁移准备负责人：那我说我的。最耗时间的是整理历史数据。原以为只是导出再导入，实际做起来，光是判断哪些内容算重复就花了不少工夫。

需求梳理负责人：你们说的其实是同一个问题的四个侧面：口径不清，后面每一环都要多花时间。

• ● 口径不清，四个环节都会各自付一遍代价
• ● 反复对齐，是需求没落纸的典型症状

图1：长尾客户要不要一起管，先想清楚

评分汇总负责人：我补一句。不绕弯子，口径不清还有一种表现：同一条需求，上午问和下午问得到的答案不一样。

需求梳理负责人：对，这时候不要急着往下走，先把这一条定住。

迁移准备负责人：定不住的时候，先按最保守的那种理解写下，并标注待确认。

• ● 同一条需求答案反复变化时，先定住再往下走

试用验收负责人：我先说一句，试用之前我们都会先想好要验证什么，不然试完只剩下一个感觉。

• ● 试用之前先想好要验证什么

二、需求文档到底该由谁写

试用验收负责人：那需求文档应该由谁来写？我们这边是推动的人写的，写完业务同事说不对。

需求梳理负责人：我现在的做法是：业务同事先说，我负责整理成条目，整理完再拿回去给他确认一遍。这样他说的和他看到的就对上了。

评分汇总负责人：确认这一遍很关键。我们之前跳过确认，结果打分的时候争议特别多，因为每个人理解的条目含义都不一样。

迁移准备负责人：我从数据的角度补一句。整理条目的时候最好顺带写清一件事：这条需求涉及哪些数据。写清楚了，后面整理历史数据的时候就有边界。

需求梳理负责人：对，条目和数据要说清对应关系，否则迁移阶段又要重新问一遍。

• ● 业务先说，再由推动的人整理，整理完必须回确认
• ● 每条需求顺带写清涉及哪些数据

图2：资质这类材料，谁看谁改要有规矩

评分汇总负责人：那如果试用的时候问题不少，是不是就该直接排除？

试用验收负责人：不一定。要看问题属于哪一类。属于配置能调整的，说明只是还没配好；属于设计上就没有这类考虑的，就要认真掂量。

需求梳理负责人：对，我一般会分两栏写：能改的和改不了的。改不了的那一栏更值得看。

• ● 试用问题要分能改与改不了两栏
• ● 改不了的那一栏，参考价值更大

评分汇总负责人：那我再问一句，条目写多少条比较合适？

需求梳理负责人：能覆盖每天都要做的动作就够，不必把能想到的都写进去。

试用验收负责人：对，条目越少，试的时候越跑得完。

• ● 条目覆盖每天的动作就够，不必求全

迁移准备负责人：我还有一个担心，试用会不会试出很多其实不重要的问题？

• ● 试用要按影响程度筛一遍

三、试用阶段最该看什么

评分汇总负责人：试用的时候，你们重点看什么？

试用验收负责人：看三样：动作走了几步、中间有没有停顿、一线愿不愿意再走第二遍。第三样最直观，愿意再来一遍说明基本可用。

需求梳理负责人：我还会看数据进去之后的样子。有些方案演示时很顺，把自己的数据导进去之后，字段对不上的地方一下就露出来了。

迁移准备负责人：我看的是数据的出口。一句话，能不能完整导出、导出之后格式变不变，这个在试用阶段就要试一次，不要等用了一阵才发现带不走。

评分汇总负责人：这一条我以前没想过，记下来。

试用验收负责人：还有一点：试用不要给太多指导，让他们自己走，卡在哪儿最有价值。

• ● 动作步数、停顿位置、愿不愿意再走一遍
• ● 试用阶段就试一次数据导出，确认带得走

图3：能不能本地化承载，是一道前置问题

迁移准备负责人：我问一个实际的问题：试用的数据要不要用真的？

试用验收负责人：要用真的。可以脱敏，但结构要真实，否则字段对不上的问题根本试不出来。

评分汇总负责人：而且要挑有问题的数据试，干干净净的数据试什么都顺。

• ● 试用数据要真实结构，最好挑有问题的数据

需求梳理负责人：试用不只是试系统，也是试我们自己的流程。有时候走不下去，是我们自己没想清楚。

迁移准备负责人：这种情况我遇到过，最后改的是流程，不是系统。

• ● 试用也试自己的流程，不只是试系统

试用验收负责人：我再补一句，记录一定要当天写，隔天补的会漏掉一半。

• ● 试用记录要当天写

四、打分怎么打才不会变成吵架

评分汇总负责人：说说打分吧，我们上一次打分差点吵起来。

需求梳理负责人：吵起来通常是因为权重没提前定。两个人都投了反对，但反对的权重不同，最后就被当成同一个反对。

评分汇总负责人：我们后来改成先定权重再打分，情况好多了。

试用验收负责人：我还建议写「部分满足」这个档。只有满足和不满足两档，很多人会在中间反复纠结，最后随便填一个。

迁移准备负责人：另外，打分的时候要写一句理由。理由比分数有用得多，后面回顾的时候。看理由就能想起当时的判断依据。

评分汇总负责人：对，理由写清楚，后面就不需要重新开一次会解释。

需求梳理负责人：总结一句：权重先定、档位留中间、理由必须写。

• ● 权重先定，档位留出中间一档，理由必须写
• ● 理由比分数更有延续价值

评分汇总负责人：我再补一句，别把打分表当终点。它只是把讨论结果固定下来的一种方式，真正决定成败的是后面有没有人真的把它用起来。

• ● 打分表是固定结论的方式，不是终点

需求梳理负责人：我再说一句，这件事随时可以开始，不必等准备得多完整。

• ● 不必等准备完整，随时可以开始

评分汇总负责人：还有一个建议：打分表用完之后别丢，下一轮比较别的方案还能接着用。

• ● 打分表可以留着，下一轮接着用

五、给还在准备阶段的人几句提醒

需求梳理负责人：最后一人说一句，给还在准备阶段的同行。

试用验收负责人：别急着看方案。先把要解决的那几个动作写清楚，你会发现可选范围一下子小了很多。

评分汇总负责人：打分这件事，宁可条目少一点、写得实一点，也不要弄一张很长的表。表越长，回来的质量越差。

迁移准备负责人：历史数据早点看。越早看，越有时间为那些对不上的内容做安排。像海软CRM这类系统在推进时，也会先把历史数据的种类与归属捋一遍，再规划怎么搬。

需求梳理负责人：我的提醒是别嫌麻烦。需求这一步花的力气，后面每一环都会省回来。

• ● 先写清要解决的动作，再看方案
• ● 条目少而实，比一张长表更有用

图4：项目信息要不要并进来，早讨论早省事

试用验收负责人：最后说一句，这件事没有一次就做对的，多把中间的结果写下来，下一轮就会顺很多。

• ● 把中间结果写下来，下一轮会顺很多

评分汇总负责人：还有一点，四个人里如果有人中途换人，前面写下来的东西就是最好的一份交接材料。

需求梳理负责人：对，这也是我坚持每轮都写下来的原因。

• ● 写下来的东西，就是最好的一份交接材料

需求梳理负责人：说得差不多了，下次接着聊。

• ● 把结论记下来，下次接着聊

六、大家问得最多的几个问题

1、问：需求文档写完之后还要更新吗？

答：要。业务变化、方案比较、试用发现的问题，都会带来调整。每次调整都回到文档上改一遍。

2、问：试用阶段最容易被忽略的是什么？

答：数据的出口。能不能完整导出、导出之后格式是否可用，这两件事常在试用时被跳过。

3、问：打分表里的条目多少合适？

答：以能覆盖必须有的那一档为准，不必穷尽。条目越多，填写质量越差。

4、问：四个角色里，谁的意见最有决定权？

答：没有哪一个角色天然占优。业务侧判断顺不顺，技术侧判断可行不可行，用的人是否有意愿用由试用说话。最后的取舍由对系统负责的人来定。

5、问：这套做法在多大团队里适用？

答：人数的多少不影响做法，只影响分工。人少的时候同一个人可以兼几个角色，但四个角度仍要分别过一遍。