编辑导语：面对不一样的市场环境和用户群体，企业要如何做好营销数字化工作？这其中便蕴含着一个机会，即构建一款国际化的数字化营销产品。本篇文章里，作者便结合实际案例，总结了一款数字化营销产品的搭建过程，一起来看一下吧。

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

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

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. 最后小彩蛋

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

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

四、阶段性小结

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

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

本文由 @鹿鸣 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。