百木园-与人分享,
就是让自己快乐。

快消数字化复盘:一个数字化产品在亚太区的应用始末

“为何每个国家使用的营销系统都不一样呢?”

这是一位跨国快消企业资深营销总多年前的一个感叹和无奈,他来自南美洲,来中国之前,在欧洲各国服务多年。这不只是他一人的感触,也是大部分数字化人的感触。

SAP无疑挑起了财务和供应链数字化的大旗,营销数字化却一直是一大难点和机会,主要是各地国家地区营销的多样化和个性化,特别是在文化底蕴极深的亚太地区及国家。

如何构建一个国际化产品来应对这样的挑战呢?

一、产品国际化中面临的挑战和机会

1. 不同的市场发展阶段

在亚太区有刚刚改革开放的北朝鲜,也有老牌发达国家澳洲日韩等,以及其他快速发展中的东南亚等国家。

除了国家的发展阶段不同,市场模式也有不同。有直销大卖场为主的澳新地区,消费者喜欢开车到大的卖场进行批量购买,家庭消费为主。 也有批发零售为主的日本、中国、越南这样等,大家可以选择在餐馆酒吧直接消费; 还有处于市场初期的印度,一些城市或省份是政府管控的,另外一些是市场化城市或省份。

1. 不同的文化和数字化环境

澳新与欧美接近,基本上可以实现欧美的无缝连接。数字化环境和工具,基本上与欧美无疑,他们日常使用Google、eBay、Amazon、Facebook、Twitter、Instagram、Telegram和whats App,完成自己的日常工作和生活。

作为东亚的发达地区,日韩除了使用国际先进的数字化工具外,他们更加喜欢使用本土的数字化工具,比如LINE,KaKao talk,fuyeor等等。东南亚地区可以使用欧美的数字化之外,也有自己的社交产品,比如越南的Zalo,印尼的BBM/黑莓信息等。

印度是一个神奇的国度,既有全球知名的宝莱坞和印度麻省理工/MIT称号的BIT,悠久的文化和历史,巨大的贫富分化和对旅行者极具挑战的饮食。落地在印度,打开手机Google、Uber可以使用,会让旅行者略安心。走在街头各种本土电子支付PayTM,Flipkart电商,和中国的一加手机。

中国是最为独特的,我们有日常的微信、淘宝、高德、抖音等等,各位都非常熟悉我就不再赘述了。

2. 不同的数字化阶段

回到我们企业内部的数字化,澳新是比较老的国际化产品Siebel营销数字化产品,有Pad版本。日韩独立自主研发的产品,基于手机使用。东南亚在使用中国之前版本的营销产品,印度也是自己研发的产品,只是完成一个业务需要配合的产品需要10多个。

二、数字化架构

一个可以落地的国际化产品涉及的内容很多,在这里想重点介绍如下几个方面,数字化架构、产品团队和组织、产品研发指导思路。

澳洲日本开始最早应用没有规划,每个国家开一个单独的应用,根据自己的国家需求进行相应的客户化,本地化和集成。当我们要在中国、越南开始应用时,还有其他几个国家地区要求上线时,我们就不得不开始考虑这个应用架构的问题。单独开不同的应用给各国,虽然保留了灵活性,但是也带重复建设的浪费,和维护的复杂性。

各国独立式应用还是亚太区集中式应用,引来了多方的关注,特别是全球总部数字化团队的关注。

经过1个多月多次的会议和沟通后,决定在上海搞一个workshop,请来各类专家,产品应用专家,企业架构专家,国家业务代表。为期一周的workshop结束之后,我们基本上讨论并制订了未来的架构设计,并制订了相应计划。

一个新的数字化架构,应对未来3-5年亚太区域需要,成为我们的第一步。我们的这个产品应用主要涉及到移动端应用、桌面应用和集成。数字化架构示意如下:

  • 建立亚太One Application,应对亚太地区的管理要求,各区域管理需求和用户需求等。
  • 应用中台主要包括通用产品能力,以及各地专有产品能力,倡导通用产品能力的建设。
  • 基于用户体验,本地化等考虑,各地持有独立应用端,实现与应用中台的无缝连接。
  • 基于Microservice 和Restful API的集成架构,实现与亚太区产品和各地本地应用的无缝整合,为用户提供完善的应用体验。

1. 应用中台

核心是我们Salesforce PaaS平台来搭建新一代的数字化营销产品,实现更好的逻辑和代码的高复用,如下梳理和规划的重点内容。

  • 数据对象及结构——定义通用数据和专有数据,数据规范等等等。核心数据对象的安全要求、变更流程等。
  • 用户及权限——各种层级用户的设置、数据及功能权限的定义和设置。针对几万多层次多角色用户的初始化,及日常管理等
  • 产品能力模型——区分通用产品能力,还是转悠产品能力。重点关注通用产品能力的建设。产品模型样例如下。

其次是周边应用,统一采用微服务方式进行传输和沟通,这里我们接入了核心的服务有路线优化服务、图像识别服务、大数据分析和展示服务等等。

2. 移动端应用

我们80%用户使用的移动端应用,我们需要兼顾成本、用户体验等。

因为需要跨不同手机平台,我们基本上已经放弃了Native。 重点考察了当时比较流行的跨平台移动框架——Xamarin、React-Native,、 Weex等。 我们当时选择了WeeX基于如下因素,3年前的Weex与目前Flutter的类似。虽然微信在国外有一些用户,目前也不是亚太地区的主流,更别提各国的政治因素了。

  • Write one, run anywhere. 写一遍,任何地方都可以运行。写一次代码,可以应用到web,Android和iOS。 开发技术非常成熟,开发效率也很高。
  • Weex还有一个比较方便的热部署,我觉得很有吸引力。服务器发布js文件后,客户端用户可无意识的更新,不需要开发者做大量的处理。
  • 更好的用户体验,增加一些缓存策略。

站在巨人的肩膀,帮助我们尽快完成自己的小事情,除掉移动框架搭建的时间,第一个移动端MVP一个月就上线了,1月切换了1000人来使用这个新产品,更快的界面反应,更友好的用户体验,以及用户无感的热更新,无疑是一个成功的产品。

3. 应用集成

建立统一的接口标准,所有接口通过API进行交互。定义通用API和专用API,便于性能调优。

建立API Gateway方便各相关产品的交互和应用,便于集中管理和监控接口运行情况,统一的权限管理等等。

三、组织, 产品研发

1. 产品组织

产品团队的建设不是一蹴而就的,团队的建设和成长离不开持续的努力和学习。团队经历了大致3个阶段。

1)外部顾问为主导的模式,内部团队做相应的管理和支持

在资源少任务重的情况下,我们也不得不采用外包的模式。在不清楚各供应商能力的情况下,我们不得已下发不同的需求给不同的供应商。

任务最重的时候,同时有4个不同供应商同时做不同的产品能力,给产品的管理带来了极大的挑战,从需求的分解,产品任务下发,代码合并,到代码review,产品测试,部署都面临着前所未有的挑战,非常大的管理难度。

经过几次迭代之后,基于交付质量,管理能力,配合度等关键指标的评估下,我们基本上确定下来我们的核心合作伙伴。

2)内部团队产品设计为主,外部团队交付为主

随着产品的不断推进,发现供应商人员的变动,会带走我们的核心能力,我们需要不断去做重复知识转移。

我们为何不把这些核心能力建立在内部呢? 我们首先把架构师资源建立了起来,UXD团队建立起来,通过内部团队的不断学习,有人成功的承担起了产品经理和产品负责人的职责。参与到日常产品研发和管理管理工作中。

第三方团队主要帮助我们完成产品交付的部分。各国家的推广和支持工作也逐渐由当地同事承担了下来。当然主要是指一线和部分二线支持,针对产品的支持还是会交给我们的产品团队来处理。

3)内部团队为主,外部团队为辅的模式

随着我们产品的进一步优化,在成本和反应速度的考量下,我们开始建立内部的交付团队,重点推进DevOps的搭建,自动化测试,自动化部署的建设。

2. 产品研发

最后我们建立了以内部资源为主,外包资源为辅的集中式产品管理团队,下面是一个示例图。

核心产品团队参与每周globa和各个国家的交流沟通会议。Scrum团队自己组织每天迭代会议,遇到的任何困难和问题可以在SoS会议中一起讨论和决策。

为了便于沟通和协作,我们定义了产品需求采集设计和交付的示例流程,各级别的业务需求可以直接联系我们我们集中产品团队,每周的SoS会议会review任何新的业务需求,之后会进行需求分析、产品设计,最后交付部署。

3. 最后小彩蛋

各地发展不一致,应用需求必然不一致。 我们重点讨论过我们的方法论,针对我们的产品建设,我们制定了如下几个原则:

  • 先通用产品能力,再专有产品能力。
  • 优先完成用户基数多,高频的产品能力。
  • 螺旋优化的迭代方式做通用产品能力。首先是如何统一通用产品能力,超过一个区域使用的能力,我就会定义成通用能力。其次如何建设通用能力,是寻访所有地区用户能力做大而全;还是面向主要用户,快速迭代。最后我们选择了,因为这是一个数字化营销应用,不是一个后端应用。
  • 四、阶段性小结

    经过两年的努力,这个营销数字化产品,实现覆盖全亚太全区域覆盖,一线用户超过4万人,助力企业数字化进程又向前迈出了一大步。

    这里分享的都是我们的超级干货,希望能与您产生一些共鸣,希望可以对您产生一些启发。

    给作者点赞,鼓励TA抓紧创作!


    来源:http://www.woshipm.com/pd/5395985.html
    本站部分图文来源于网络,如有侵权请联系删除。

    未经允许不得转载:百木园 » 快消数字化复盘:一个数字化产品在亚太区的应用始末

    相关推荐

    • 暂无文章