礼品卡平台无中断迁移:余额、数据与连续性

礼品与忠诚度计划可以在客户毫无察觉的情况下更换平台——前提是在任何数据搬迁动作之前,先把余额、卡片库存与数据格式映射清楚。

迁移首先是一项数据映射工作

Ogloba 已为零售商建立一站式的迁移路径,可将既有的礼品与忠诚度计划、有效卡片余额与卡片库存,从原有平台整体迁移过来。工作的起点是把旧系统的数据映射到 Ogloba 的数据结构(schema),由此产出提取与加载的设计——也就是把旧有格式与新系统的要求逐一对应。程序化的迁移可能分成许多阶段,但最基本的形式就是从旧系统读出、写入新系统。实际中的制约很少来自技术。能否延续,取决于原供应商是否配合,或零售商自己的 IT 团队是否有能力把数据导出。

当转换不是答案

并不是每一个计划都需要转换。当地法规若要求第三方处理商必须继续存在,那么要改变的是对接方式,而不是数据。2013 年为一家中国大型零售连锁交付的移动礼品卡计划就是这样运作:以专用 API 将 Wincor 结账系统连到 Ogloba,余额查询与交易查询则由 China Union Pay 的 Web 服务处理。在收银台,收银机把卡号 PAN 与持卡人的手机号码传给 Ogloba,由 Ogloba 把卡片送到手机上——必要时则以短信发送应用商店链接。

迁移风险大多是数据映射的问题。及早解决,客户就不会察觉这次更换。

FAQ

迁移任何余额之前,必须先完成哪些映射?

每一种旧有数据格式都要先与 Ogloba 的数据结构对应。这份映射正是提取与加载设计的来源,涵盖有效余额、卡片库存,以及附带其上的计划规则。

平台迁移最常被什么拖延?

通常不是技术。常见的制约是把数据从原有系统取出——要么原供应商愿意配合,要么由零售商自己的 IT 团队执行导出。

什么情况下转换数据是错误的做法?

当地法规要求第三方处理商必须继续留在架构中的时候。此时计划改变的是对接方式而非数据,既有的处理商仍在底层持续运行。

后端平台更换时,结账流程如何保持不变?

靠收银机与平台之间的专用 API。在一个中国零售的落地案例中,收银台把卡号 PAN 与持卡人手机号码传给 Ogloba,由 Ogloba 将卡片送到手机,结账流程完全无需改动。