简体中文
未来五年，企业软件领域将发生一场巨大的变化。Oracle 将客户推送到Oracle 云，SAP迁移到 S/4HANA ，其他ERP云，如Netsuit和Workday也会迅速增长。在2030年之前，大多数公司都将在云上运行其 ERP。这个变化为ERP公司和许多系统集成商带来了机会，他们正在积极准备ERP的云迁移项目。随着越来越多的中国企业走向海外和业务的国际化，其中许多ERP云迁移项目将是全球性的，需要应对全球银行整合的复杂性。
我们反复地从一些已经开始迁移过程的不同用户那里听到同样的声音，“我们不知道项目会如此复杂或耗时。” 事实上，许多与我们合作的系统集成商一直告诉我们，银行集成是他们项目中风险最大的组成部分之一。
当今的企业 IT 团队在构建办公室系统之间的接口方面经验丰富，但这些接口通常是停滞的接口，不需要额外资源。在处理银行接口时，IT 团队通常需要多个团队来与银行进行协调。这些可能包括 IT、司库、AP、连接团队、SWIFT 服务局和银行的技术团队。一旦开发了规范，它们很少能第一次通过测试，开发团队经常必须重新进行重建和重新测试;然后他们必须再次通过协调努力。我们见过这样一些情况，让测试格式得到银行的批准，可能需要两到五倍的努力。
一旦银行批准了格式，IT 部门需要通过内部程序将产品发布到生产中，包括开发> 测试 > QA > 非生产 > 产品。事实上，单一付款格式通常需要 6个月以上才能完成开发、测试并发布到生产中，供企业所有者使用。
我们看到的一个常见错误是：假设每家银行通过SWIFT传送的报文格式都是统一的标准格式。尽管SWIFT 正在从 MT 迁移到 XML，但也不能否定一个事实，即每家银行在如何接受传入文件方面都会有自己独特的差异。由于每家银行都有自己独特的报文格式，而且大多数客户需要多种的银行报文格式，如当日到账、隔日到账、支票等，许多公司将需要开发和测试数百种格式。我们经常看到 IT 公司需要两年多时间才能完成所有银行连接和付款格式测试。
一旦格式进入生产阶段IT基础结构团队必须管理这些格式。大多数公司需要额外的资源来管理连接以解决银行问题，根据银行的要求编辑格式，以及按需实施新银行。根据公司的银行业务不同，平均需要2-5个员工。
另外一个公司必须面临的新问题是 – 2020 年强制要求的新 SWIFT 要求。
由于 2016 年孟加拉国一家银行的在使用SWIFT时受到欺诈攻击而损失了8100 万美元，SWIFT 不仅提高了其基础设施周围的安全性，还提高了对控制自身 BIC 的公司的授权要求。许多希望管理自己 SWIFT 连接的公司都希望采用联盟 Lite2 （AL2）。但是，根据2020年的新要求，内部 IT 支持团队将需要通过多达12次测试的年度认证和测试，以保持 SWIFT 的认证。这会给许多内部 IT 团队带来巨大的风险和额外费用，因为他们现在必须拥有内部 SWIFT 领域专业知识，并且需要每年重新认证。存在的一个风险是，许多公司将不会有超过一个或两个资源认证。如果此人力资源离开公司，会发生什么？有备用人员吗？重新训练新资源的成本和时间是多少？
为了降低这些关键人为风险，加快 ERP 迁移并简化全球银行连接，许多组织都希望Kyriba 为其实现连接。凭借20年的经验和根嵌入式连接，我们可以提供帮助。我们已经与 全球700多个银行网络实现直连，可与大多数主流ERP 实现对接，从而消除开发和测试的艰巨任务，通过将银行集成工作削减 80% 以上，缩短了ERP的价值实现时间。这种整套交付服务（white-glove service）还将消除内部 IT 支持银行集成的所需的资源或SWIFT 领域专业知识。
