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

为什么每个国家都使用不同的营销系统?

多年前,这是一家跨国快速消费品企业高级营销公司的叹息和无助。他来自南美洲,在来到中国之前已经在欧洲国家服务了很多年。这不仅是他的感受,也是大多数数字人的感受。

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基于以下因素,三年前Weex与目前Flutter类似的。虽然微信在国外有一些用户,但它不是亚太地区的主流,更不用说各国的政治因素了。

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

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

3. 应用集成

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

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

三、组织、产品研发

1. 产品组织

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

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

在资源少、任务重的情况下,我们还必须采用外包模式。当我们不知道每个供应商的能力时,我们必须向不同的供应商发布不同的需求。

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

经过几次迭代,基于交付质量、管理能力、合作等关键指标的评价,我们基本确定了我们的核心合作伙伴。

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

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

为什么不在内部建立这些核心能力呢? 我们首先建立了架构师资源,UXD通过内部团队的不断学习,一些团队成功地承担了产品经理和产品负责人的责任。参与日常产品研发和管理。

第三方团队主要帮助我们完成产品交付的部分。当地同事逐渐承担了各国的推广和支持工作。当然,主要是指一线和部分二线支持,产品支持仍将交给我们的产品团队进行处理。

3)内部团队为主,外部团队为辅

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

2. 产品研发

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

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

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

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

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

3. 最后一个小彩蛋

各地发展不一致,应用需要

我们重点讨论了我们的方法论,并制定了以下原则:

  1. 先通用产品能力,再专有产品能力。
  2. 优先考虑用户基数多、产品能力高的问题。
  3. 螺旋优化的迭代方法是使一般产品的能力。首先是如何统一一般产品的能力,超过一个区域的使用能力,我将被定义为一般的能力。其次,如何建立一般能力是寻找所有区域的用户能力;或者为主要用户,快速迭代。最后,我们选择了它,因为它是一个数字营销应用程序,而不是一个后端应用程序。

四、阶段性总结

经过两年的努力,该营销数字产品覆盖了亚太地区,一线用户超过4万人,为企业数字化进程迈出了一大步。

这里分享的是我们的超级干货,希望能和你产生一些共鸣,希望能给你一些启发。

相关新闻

联系我们

联系我们

888-888-8888

在线咨询:点击这里给我发消息

邮件:admin@example.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信
关注微信
分享本页
返回顶部