用友的销售数据搬进CRM，先过四道关
用友用了五六年，客户、订单、往来账都在里面。要换一套销售侧的 CRM，第一个问题就是：这些数据能不能搬过去，搬过去还能不能用。
答案是能搬，但麻烦不在搬，在搬之前要做的判断。
第一处：哪些数据该搬，哪些该留在原地
"把客户全部迁过来"是最常见的想法，也是最容易后悔的做法。用友里的客户主数据往往包含大量只做过一次交易、甚至只开过票的对象。这些记录迁到 CRM 里，会变成几千条无人跟进的死客户，把线索池和客户台账全稀释掉。
比较稳的筛法是按活跃度切：近两年有订单的客户迁，两年内只有开票记录的留在财务系统，从没用过的直接归档。这样迁过来的量通常是原来的三到五成，但都是活的。
判断活跃度需要导出一张订单明细表，按客户汇总订单数和最后成交日期。这个动作在用友那边做一次，导成 Excel 即可。
第二处：字段对不上，是最耗时间的部分
用友的客户档案字段是为财务和开票设计的：纳税人识别号、开户行、账号、信用额度、结算方式。CRM 的客户字段是为销售设计的：客户名称、手机号、联系人、地域、详细地址、公司网站、注册资本、员工人数、备注。
两边重叠的只有名称和地址。剩下的要么丢，要么找地方放。
处理办法有三条：能用自定义字段装的就装（客户字段支持自定义），销售不需要的就舍弃，必须保留但系统里没有位置的，写进备注。备注这个字段不要小看，它是最后的安全垫，但也不能什么都往里塞，塞满了等于没有。
字段映射建议写成一张表：左边用友的字段名，右边 CRM 的字段名，中间一列写转换规则。"客户名称"直接映射，"客户简称"对不上就并入备注，"信用额度"对不上就标不迁。这张表一页纸，后面所有争论都对着它说，比口头讨论省事。表做完之后让财务和销售各看一遍，两个部门对同一个字段的理解往往不一样，这个差异越早暴露越好。
还有一个细节：客户类型要分清楚。系统里新建客户要先选公司或个人，两类客户的表单字段不一样。用友里没有这个区分，迁的时候要按"有统一社会信用代码的算公司"这类规则先分好，否则导入会卡住。
第三处：联系人是一对多，别拍平
用友的客户档案里，联系人常常是几个字段：联系人、电话、手机。一个客户只能记一个人。
CRM 里一个客户可以加多位联系人，每位联系人单独一条记录。迁的时候如果只把主联系人带过去，等于丢掉了一半信息。
做法是把用友里的联系人字段拆成多条记录，一条一个联系人。如果原来只有一个人，就建一条。联系人字段不支持自定义，所以别想着加"职务""决策角色"这类字段，写在联系人姓名的备注里更实际。
第四处：历史订单，迁不迁要算账
订单是另一回事。CRM 的订单结构是围绕销售过程设计的：订单名称、编号、客户、开始结束时间、产品明细、收款阶段。用友的销售订单围绕发货和开票设计。
硬迁的代价是把两套逻辑拧在一起，最后谁都不顺。多数团队的选择是只迁近一年的订单，更早的留在用友里查。
迁订单要先迁产品。产品库里的产品名称、编号、单价、计量单位四项必须有值，否则订单明细建不出来。用友的存货档案导出来，字段映射一遍，能对上七八成，剩下的手工补。
迁移真正的风险，是并行期的信任问题
数据迁完不算完。上线后一个月，两边数据会出现差异：这边改了一个客户，那边没改；那边开了一张票，这边没记。差异一出现，团队就开始不信新系统。
避免的办法是明确切换日：切换日之前的以用友为准，之后的一律在 CRM 里录，不再回填。这条规矩要老板签字，否则一定会有人偷偷回去改。
迁移这件事，工具能解决导入，解决不了口径。哪张表是准的、哪个字段代表什么、谁有权改，这些定不下来，迁十次也一样乱。项目型销售CRM里对数据迁移的顺序讲得更细，客户和订单怎么对应，可以对着千营CRM的客户模块看。
