非洲银行面临的普遍挑战：银行的移动银行与钱包应用程序之间的区别

正文：

近期在一次展会上，一家非洲银行的代表向嘉宾提出了一个问题：

“银行的移动银行和钱包应用程序之间有什么不同？”

这个问题可以更具挑战性地提出，“为何银行的应用程序总是难以做到优质？”

或者更深入地探讨，“为何一些银行需要开发两个不同的应用程序？”

我曾与非洲银行探讨过此话题。

从本质上看，传统银行的商业逻辑与互联网应用的运营模式截然不同，同时在技术支持上也存在差异。

传统银行的运营模式是通过在各个城镇设立网点来服务客户，客户在有需求时前来排队办理业务，而在没有需求时则不会主动前往银行，形成了“无事不登三宝殿”的现象。

基于这种商业逻辑，银行的移动银行应用同样遵循了将线下业务转移到应用上的思路，其业务逻辑和流程依旧延续着传统模式，转账可能需要遵循银行的工作时间，早期甚至不敢保证全天候服务，所有业务流程都是对传统模式的线上延伸。

因此，银行应用的功能通常仅需几个基本选项，这也引发了一个反向思考：银行未必必须依赖于自己的应用程序。用户习惯使用何种平台，就可以在其上实现这些功能。比如，中国的银行利用微信入口，让客户直接在微信小程序中享受银行服务，而印度和非洲的一些银行则通过WhatsApp提供银行接口，用户在WhatsApp中即可使用基本银行服务，此外还有USSD和短信银行业务，这些都是传统业务逻辑下的自然延伸。

然而，互联网原生的金融应用则截然不同。作为互联网原生的产品，它们深知如何吸引用户，增强活跃度，获取流量，而不是等待客户上门。

其目标在于让客户在无所事事时主动前来，查看是否有新功能、新业务、优惠或是其他吸引人的内容。

因此，互联网原生应用的核心考核指标是月活跃用户（MAU）、日活跃用户（DAU）及衍生的各种指标。从流量获取的角度来看，银行的移动银行应用无法与原生支付应用竞争。

这引出了第二个原因，即技术投入的差异。

传统银行通常依靠采购第三方技术，而互联网公司则倾向于组建自有团队来开发技术。结果是，当需要规划新营销活动并开发新功能时，传统银行需经过调研、招标和评标等繁琐流程，耗时半年之久。为了降低责任，团队通常会提前描述大范围需求，导致供应商报价偏高，从而需要更多高层决策，增加了复杂度。

反观互联网公司，仅需组建一个小团队就可以快速推出最简可行产品（MVP），通常一个月内便可完成。这种时间上的差距使互联网公司总是处于领先地位。

为了应对这一挑战，中国的银行普遍选择了人力资源外包技术团队，形成了一个随时可裁撤的技术团队，以便在有需求时迅速行动，减轻流程带来的阻力。

当然，这种外包团队主要进行前端业务的开发，而在底层或后台仍会使用大公司提供的稳定系统。

银行还会招聘一些自有核心运营和产品设计人员，负责制定营销策略、分析需求，并与外包技术团队协同工作，实现快速交付。自有员工的经验至关重要，他们需具备运营、产品设计以及团队管理的背景，以确保项目进度，并有效指挥外包团队，避免成为甩手掌柜，仅仅抛出一句需求描述，这样外包团队将难以把握项目方向，最终可能导致双方之间的责任推诿。总体而言，技术团队可以通过外包来一定程度上弥补不足。

这引出了第三个问题，即后台系统的稳定性与开放性之间的矛盾。系统越开放，其稳定性往往越差；若要实现稳定，则需减少开放接口的数量。

为了保持稳定性，传统银行的核心系统往往趋向于封闭，功能设计简单，但显然这与互联网时代的竞争需求不符。

1. 新的开放银行核心与银行应用组合，这类银行通过用更具开放性的核心系统替代旧系统，直接提供更多接口以适应互联网。

2. 在旧核心之外建立轻量化的核心或钱包及应用，例如南非的FNB、缅甸的KBZ和摩洛哥的Wafa等。这是因为旧核心系统的改造难度过大（不仅是技术问题，还涉及到组织变动等复杂因素），不如直接重新搭建。

因此，回答之前的问题其实很清晰：要想在竞争中胜出，银行必须在对应用程序的理解、市场营销及技术层面进行全面的改造与变革。

来源：移动支付网