功能设计:映射
一旦你确定了需要迁移的数据类型和每种类型中的记录,下一步就是用文档记录数据将如何被映射。映射分为三级。
实体映射
实体映射是最高级的映射,其中每种类型的源应用程序数据都将根据实体的目的的和它所提供的功能被映射到对应的CRM业务实体上。这种映射通常简单直观,但是有些映射也需要多加考虑。例如,源系统中有一个名为“销售拜访”实体也可能会有一个标志来表明是亲自会面还是通过电话拜访,那么,这个信息就会被用于确定每个销售拜访记录是创建“会面”还是“电话拜访”。
字段映射
完成实体映射之后,你就可以开始着手进行字段级映射。这个过程需要确定从源应用程序迁移到每个实体中的每个要迁移的数据字段应该被插入哪个CRM字段中。理想的情况下,这些映射很简单;只需获取源应用程序中的字段ABC的值,并将其插入CRM应用程序中的咨询XYZ中。但是,随着源应用程序中的数据质量的下降,字段映射的复杂性就增加了。设想一下,如果一些用户在源应用程序中将一些数据输入到字段ABC中,而另一些用户将同样的数据输入字段DEF中。现在,你就不能进行简单的字段到字段的映射了,而是需要插入一些逻辑,如“先查看字段ABC;如果它为空,再查看字段DEF,得到最终信息并将它复制到CRM应用程序中的字段XYZ中”。如果源程序中的某个记录在字段ABC和字段DEF中都有数据,你应该怎么做呢?你可能开始觉得为什么数据迁移如此困难、不准确而且成本高昂。记录所有者的映射是数据迁移的另一个复杂因素。在旧的应用程序中属于先前员工的记录应该如何被指定到新的应用程序中?你是应该在新的应用程序中为先前员工创建用户记录以便这个记录历史,还是应该把它们作为迁移的一部分重新指定给一位当前员工?
值映射
最后一级的映射是值映射。在这种映射中,我们要为字段映射表格中每一行确定,所有源应用程序中的数据在被复制到CRM应用程序之前需要进行的任何转换。这种“转换”的一些例子如下所示。
选项列表的映射
当在CRM应用程序中映射选项列表字段时,几乎总是需要进行这种转换。
选项列表字段(也称为下拉列表框或列表框)是一种字段类型,用户可以从一个有限的选项集中选择一个值作为输入的信息。
需要进行转换的原因有很多。首先,被映射的字段的内容可能不包含完全相同的值。例如,考虑销售机会记录中用于跟踪销售机会的进展阶段的字段。在旧的源CRM应用程序中,可选项是“新的”、“进行中”、“签约中”、“成功”和“失败”。但是,新CRM应用程序则包含新的销售分类法,阶段分为“新的”、“合格的”、“开发解决方案中”、“谈判中”、“成功”和“失败”。为了将销售机会从源应用程序复制到新的CRM应用程序中,我们必须定义源应用程序中销售阶段的值应该如何被转换到CRM应用程序中。这个定义需要征求项目团队的意见,因为他们熟悉源应用程序及其中的数据,以及新的CRM应用程序设计。通过增加字段值。
即使一个给定字段的值在源应用程序和新CRM应用程序之间完美地匹配,也可能需要值映射。应用程序中通常不会存储我们在列表框中所见的实际文本,而是存储一些数字代码。举例来说,应用程序不会在数据库中存储“新的”一词来表示机会的销售阶段,而是在数据库中存储“3”,这个“3”就是与“新的”一词相关联的数字。但是,CRM应用程序中可能会用不同的数字代码来表示“新的”,可能是“8”。因此,即使选项列表的文本选项在两个应用程序中都是一样的,当我们将其从源应用程序中的销售阶段字段复制到CRM应用程序中的销售阶段字段时,我们也必须将“3”改为“8”。
数据查找
一些字段在从源应用程序映射到CRM中时需要数据查找。我们以销售机会的“销售代表”字段为例。这个字段中的值代表着拥有这个销售机会的销售人员。这个字段通常是指向源应用程序中独立用户表格中相应记录的一个链接。迁移过程必须获取源应用程序中销售机会表格的值,并利用这个值在用户表格中查找销售人员,然后在CRM中为这个人员找到相应的用户值,并将他们的值输入到相应的CRM字段中。
数据解析
不同的应用程序会以不同的方式来处理相同的信息;这就需要将数据解析添加到数据迁移过程中。例如,源应用程序将个人的姓名存储在一个名为“姓名”的单个字段中,而CRM应用程序则将姓名分成几个独立的字段(如“名”、“中间名”和“姓”)。数据迁移过程必须将源数据分解到各个单独的部分中,并将正确的部分传递给CRM中的正确字段。
数据迁移在这个例子中会变得复杂且不精确。虽然分解姓名的算法很好,但是并不完美,会产生错误。
4、数据迁移设计的签署
完成数据迁移设计的并用文档将其记录后,团队的正式签署通过是十分重要的。这是一种责任,团队应该明白他们是在确认自己审查并斟酌过的设计,而且明白它符合业务需求。数据迁移设计时一项注重细节的任务,并且要求足够的耐心。值得在这个环节上投入时间,因为一旦流程被创建后,再去更改设计就需要大量返工并花费巨大的资金。