情報技術の世界では、その表現に含まれる単語の重要性を考えもせずに、新しい言葉が生み出されています。
これは、「マルチバンク接続」という言葉にも当てはまります。この場合、「マルチ」という部分が焦点にあてられます。
複数の銀行：正確には多くの銀行を効果的に管理する機能は、欠かせません。次の4つの要素を、考慮する必要があります。
- 銀行は外部機関であり、通常のIT統合機能を備えた社内組織ではない
- 銀行は、コンプライアンス要件とセキュリティ要件から、非常にプロセス志向の組織である
- 国際銀行は様々な時間帯で営業されており、自社の拠点と最大12時間の時差がある場合もある
銀行によっては、担当者が英語またはあなたの母語を話せない可能性もあり、技術的な作業が困難になるでしょう。
1.マルチバンク接続には、いくつの銀行が含まれるのか？
「マルチバンク」という場合、単に2～3行にとどまりません。50や100に届かないにせよ、時には10行、20行を管理している企業もあります。
2.マルチバンク接続がIT部門に与える影響
IT部門主導の自社製銀行接続プロジェクトを立ち上げる際、 SAPへの連続的な銀行追加の難しさは、一般に最も軽視されているプロジェクト領域のひとつです。 確かにSAPはいくつかの標準フォーマットを提供していますが、様々なタスクの範囲の幅広さと複雑さのせいで、銀行接続は大きく誤解され、軽んじられがちな領域です。
3.銀行との連動に必要な作業
グローバルなペイメントファクトリーの配備を目指す企業は、一般に、社内IT部門に対し、取引銀行に合わせた支払フォーマットと支払フローを構築し検証するよう求めます。
支払フォーマットには多くの要素が含まれるため、数百のカスタマイズを通じてそれぞれの環境で修正と検証を行う必要があります。その後、銀行とのテストが始まりますが、最初はほとんど上手くいきません。
フォーマットのカスタマイズには、以下が含まれます。
- 銀行
- 申請元の支店
- 送金先の支店
- 支払種別
- 為替換算の有無
- 緊急の支払かどうか
- 通貨
構築と検証が必要なフォーマットとシナリオの規模が、あまりに膨大で圧倒されることもあります。ＩＴ部門が行うアプリケーション統合のほとんどが、あるアプリケーションを別のアプリケーションと接続するものであるため、なおさらその傾向がみられます。 S/4HANAなどの大規模プロジェクトに着手している場合、IT部門は既にパンク寸前で、必要な支払フォーマット全てを構築し検証する時間など、ほとんどありません。
4.支払シナリオとその多様性
銀行によってプロトコル、ファイルフォーマット、セキュリティに違いがあるせいで、多くの場合、銀行別に支払のたびに単発で連動することになります。
例えば、A銀行 – 申請元フランクフルト支店 – 送金先マドリード支店- SEPA 支払-緊急性なし- 為替換算なし- ユーロといった支払シナリオもあるかもしれません。
エラーになれば支払処理は失敗するため、支払シナリオを銀行と一緒にテストする必要があります。支払を完了するには、全ての点で、各銀行が義務づける要件をきっちり満たさねばならないからです。けれど、そうなるとIT部門は、銀行間の違いを把握しなければなりません。
銀行接続を稼働させるには、一般に3、5、あるいは10種類のフォーマットが必要です。けれど、国際的な銀行接続プロジェクトには約500ものバリエーションがあります。
銀行接続を実現するには、一般に次のような手順を踏みます。
- 仕様書の作成: SAP ERPでは、銀行から情報をもらった後で、データ仕様書の作成を行います。
- 抽出、変換: 次のステップとしてコードの抽出、変換を行い、SAP IDocsから適切なデータを抽出します。あるいは、支払ファイルを設定するための統合のワークベンチとして、SAPのマルチバンク接続アプリを使用している場合、SAPと各銀行間で個別にアプリケーションを移動させねばなりません。いずれにせよIT部門は大量の作業を抱えており、私たちの分析によると、マルチバンク接続は、標準開発言語を用いた接続よりも作業量を増やします（SAPへのデータのインポート、エクスポートには、ABAPのみを使用）。
- テスト: 次に、相手銀行とともに少額でテストを行います。接続を初めてつなげたときは、ほぼ全てのケースで上手くいきません。
- インターフェイスのバグやエラーの解決 連動が失敗した理由を、相手銀行が説明してくれます。けれど、銀行側は、IT部門になじみのない独自の用語や専門知識を使用するため、SAP顧客企業のIT部門は説明を理解できません。それぞれのシナリオで、送信が必要なデータもしばしば変更されます。例えば、ドイツからポーランドに支払データを送るシナリオは、ドイツからドバイに送る場合には変更が必要です。支払種別が変わると、これがさらに変更されます。緊急性の有無によって、必要なデータがさらに変わります。シナリオごとに送信すべきデータが変わり、ひとつでもフィールドに漏れがあったり、フォーマットが間違っていると、そのテストは失敗します。
こうした複雑さから、新規銀行をひとつ追加するのに半年から1年かかることも多く、80行と言わずとも、範囲が5行、10行となると、S/4HANA移行の成功が阻まれかねません。
ERPクラウド移行時に支払を最適化する方法について、詳しくは キリバの最新のEブック（英語）をダウンロードしてください。
日本語
