COLUMNコラム

  • HOME
  • コラム
  • 御社製品の競合先は何ですか?

御社製品の競合先は何ですか?

  • トレジャリーマネジメント

2016.06.07

「御社製品の競合先は何ですか?」
お客様先に行くとよく尋ねられる質問です。これに対する答えはシンプルなものなのですが、少し意外に思われる内容かもしれません。

「特定の会社や製品ではなく、お客様自身が我々の製品ソリューションの有用性に確信が持てないこと”です」

つまり、企業財務担当がトレジャリー業務に特化した製品ソリューションが役にたつかどうか、単純に確信をなかなか持てないのです。
そこで、現在の状況を変えて新しいチャレンジへ立ち向かう際によく障害として語られる10つのことを整理してみました。
皆様も変化を恐れてしまう「思考の罠」に陥っていませんか?

皆様の現状を改善するための一歩を踏み出す勇気の後押しになれば幸いです。

1:現状のエクセルで業務がうまく回っている。何か問題があるのでしょうか?
必要性が顕在化していない所にはニーズは発生しません。トレジャリーシステムを利用することで享受できる数々の利点を認識したとしても認識の変化は起こらないでしょうか?
大量のリストデータを集計するにはエクセルの使い勝手や処理能力はとても素晴らしいのですが、トレジャリー業務を行う際に大量のリストデータを操作して行うことがベストな方法だと考えている方は少ないでしょう。
トレジャリーシステムであれば、各種データと承認情報・意思決定内容とその責任者についての情報がシステム上に保持されるためトレース可能になり、システム利用者間で共有して確認することが可能になります。
具体的には、通常は支払処理やトレジャリー関連の取引についてメールや紙ベースなどで記録されており十分にトレースできるような状況にありません。
エクセルそのものに満足するかもしれませんが、エクセルはトレジャリー業務を適切に整理し維持運用するためのツールにはなりえません。

2:ERPシステムですべて対応できるのでトレジャリーシステムは不要ではないでしょうか。
ERPシステムの財務用モジュールはそもそもトレジャリー業務向けに作成されたものではなく、会計業務視点で会計業務のために作成されているものです。
トレジャリー業務は会計業務と似て非なるものです。つまり、会計は既に発生した過去情報について詳細な資料を基に各種業務を遂行するのに対して、トレジャリー業務は企業内外の情報や推測した内容を元に意思決定のための予測情報を作成して業務を遂行します。
これはそれぞれの業務のワークフローがことなるため必然的に利用すべきシステムも異なるものとならざるを得ません。
つまり、会計システムをトレジャリー業務で利用しようとすることは、トレジャリーシステムを会計業務で利用しようとすることと同じで無理があります。
また、トレジャリー業務で行われた意思決定内容を即座に会計システムに反映して会計業務を行う必要はなく、それぞれの業務に最適な別々のシステムを使いつつ必要に応じて両者がサポートしあうことでそれぞれの業務は通常十分円滑に実行可能なのです。

3:これ以上統合されていないシステムはもう持ちたくない。
トレジャリー業務は他の業務と孤立しているわけではないので、使うシステムも独立したものであってはならないという意見が時々ありますがそんなことはありません。
会計システムは会社規模や各地域の習慣等によりグループ全体で統合利用されていることは本当に稀で、むしろ現代のウェブベースのトレジャリープラットフォームは、グループ全体の関係者に利用されている数少ないシステムです。
確かにトレジャリーシステムはシステム的に統合されているものではないのですが、グループ全体のファイナンス業務を統合しており、すべてのグループ会社と親会社が統合されたときその真価が発揮されます。

4:外部システムとのインターフェイスが煩雑になるのではないでしょうか。
一般的にシステム間のインターフェイスは複雑で煩わしいものですが、トレジャリー業務は例外です。
このような疑問に対しては、どのインターフェイスが本当に必要なものなのかをまず確認することをお勧めします。
今までの経験によるとおおよそ以下の2種類のインターフェイスに集約されます。

・銀行からのアカウントステートメントデータ
・銀行への支払情報データ

幸いなことに、これら2つについては標準化されているためトレジャリー業務側と会計業務側とでの調整はほとんど必要ありません。
銀行アカウントステートメントデータの標準フォーマットはSWIFTのMT940や米国のBAIになりますが、それらをERPへ連携する場合は、トレジャリーマネジメントシステム上で事前に処理がなされます。
銀行への支払情報データについても同様で、ERPシステム上で作成された支払情報データをトレジャリーマネジメントシステム上へ連携し、資金予測への利用や支払の承認処理の実行を行ったうえで各銀行へ送られます。
上記以外のケースについてはインターフェイスが不要なことがほとんどなのですが、通常は非常に簡単に対応することが可能です。

5:余裕がないので今は対応が難しい。
「余裕がない」というのは、具体的には何に対する余裕になるでしょうか?
人的リソースの余裕がないのでしょうか、それとも何か他の別のものでしょうか?
トレジャリーシステムを利用すれば、将来的には日々の業務負荷を低減させ、人的リソースの余力を創出することが可能になり、さらにその浮いた時間を将来の投資的な活動や本来やるべき活動へシフトすることでより業務を高度化することが可能になります。
トレジャリーシステムの導入時の一次的な作業負荷に対しては外部リソースの活用も可能ですし、トータルとして費用対効果があるのであればそのような投資も会社にとっては有用なものになります。
費用対効果のある投資に対して、「余裕がない」ということで投資を実行しないのは、継続的に企業を発展させるという企業の使命および経済合理性の観点からは不可解なことです。

6:コストがかかりすぎる。
15年ほど前まではトレジャリーシステムはとても高価なものでした。ごく限られた一握りの玄人にしか利用が難しいようなシステムしかなく、複雑怪奇かつ選択肢自体もとても限られていた状況でした。
しかし最近では、価格も下がりソリューションの幅も広がってきており、財務部にとって利用することが当たり前のツールとなってきています。
加えてライセンス買取型ではなく、月額課金型のモデルが主流になってきているので、投資金額自体も財務部での権限で承認可能なレンジになってきています。

7:システム部が対応する時間を取れない。
最近のITテクノロジーの進化の恩恵を受けて、トレジャリーシステムもSaaS形式で提供されることがほとんどです。
つまり、社内のシステム部門の担当が初期導入や障害保守対応などの運用業務をすることなく、TMSベンダーがそれを担うことになるので、社内のシステム部に負荷がかからず利用が可能な環境が整っています。

8:子会社へ無理を強いることになる。
これは親会社側の決定により、単一のシステムをグループ全体に統一して利用させようとすると、子会社の自主性を制限する側面があるため、必ず議論に上がるとてもポピュラーな論点です。
そのため優れたトレジャリーソフトウェアは既にこの論点を踏まえ、すべてのグループ会社の日々の業務にとても役に立つように考慮の上設計開発されています。
具体的には、支払業務のプロセスをシンプルなものにしたり、レポーティング業務が柔軟にできるようになっています。
さらに、もし必要な場合は、各社固有の業務処理のために必要なソフトウェアがある場合は、それを各社に残すことも可能です。
データを一元的にトレジャリーシステムに集約して管理することにより収集業務の効率化のみならず、各種費用の削減効果も期待できるため、子会社にとってもメリットが享受できるため無理を強いるということにはならないのです。

9:銀行口座の完全網羅は不可能。
今現在の状況でいえば、支払データ送信や銀行口座情報の取得に関して、銀行独自のフォーマットしか対応していないためにTMS側にデータを連携できない銀行や、TMS側にデータ連携をしたがらない銀行が存在しています。
最近の貿易金融関連の銀行サービスのトレンドを見ても、すべての銀行が同じようなソリューションを提供しているわけでもありません。
しかしこれはトレジャリーシステム側の問題というよりは、銀行側の問題であり、銀行独自規格のサービスから市場共通規格のサービスへの移行を銀行側に働きかけるには、トレジャリーシステムを利用することしか方法はないと考えています。

10:他にプロジェクトを抱えている。
どの会社でも慢性的な人手不足の中業務を行っていることがほとんどですが、そんな中でも将来の業務負荷の低減や業務の高度化を目標に掲げ新しいプロジェクトに取り組まれている会社が多くあります。
ERP導入の完了を待って、トレジャリーシステムの導入開始するというのは、単なる時間とお金の無駄遣いでしかありません。
ROIとして問題なく、人的リソースの問題でプロジェクトを開始していない場合は、投資の効果を得る機会をみすみす逃していることになるので、いち早く開始するべきです。

いかがでしたでしょうか?

次回のコラムは

子会社に負荷をかけずにトレジャリーマネジメントシステム導入する方法

を予定しています。

コンサルタント・深山

タグをクリックすると、そのジャンルに属するコラムの一覧をご覧いただけます。