EDIコラム「現行システムのバージョンアップで大丈夫？EDI刷新の正しいあり方を考える」（2024/3/8更新）
仕入先や得意先などとの取引業務を支えるEDIのシステムは、停止の許されないミッションクリティカルな仕組みであり、製造や流通の事業運営を効率化するうえでは欠かせないシステムです。ただし、EDIのシステムは、保守・運用に相当の工数や特殊な知識が必要とされ、それがIT部門の悩みの種になっています。
ここでは、EDIの保守・運用を巡る問題をどのようにして解決するかという観点から、EDI刷新のあるべき方向性についてご紹介します。
デジタル社会の発展に伴い、いかにしてIT（デジタル技術）やデータを有効に活用するか、あるいはデジタルトランスフォーメーション（DX）の取り組みを前進させるかが、企業にとって経営課題の1つになっています。その重要課題に取り組むうえでのカギといえるのが、社内システムに対する保守・運用の業務負担を可能な限り減らすことです。
というのも、DXの取り組みにはIT部門による支えが必要であり、そのための人的リソースを十分に確保するには、社内システムの保守・運用の業務負担を低減させることが必須だからです。また、そうだからこそ、近年では基幹システムのインフラをクラウド化し、その保守・運用の手間を大幅に低減しようとする動きが活発化してきたといえます。
上記の観点から、保守・運用の手間を大きく低減させるべきシステムの1つといえるのが、EDIです。
EDIは、取引先（仕入先や得意先）との受発注や出荷、請求、支払などのデータをやり取りするために使用される仕組みです。その活用によって取引データの送受信や販売管理システムといった他の基幹システムとのEDIとの連携を自動化することが可能となります。ゆえに、企業対企業（B2B）の取引が日常的に数多く行われる製造業や流通業（卸売業、小売業）にとって事業運営の効率化に欠かせない仕組みとして普及してきました。
ただし、EDIは、企業のIT部門にとってシステムの開発や保守・運用に相当の手間がかかる仕組みです。
例えば、EDIは自社と取引先の双方が使用してはじめて機能します。そのため、新規のEDI導入、ないしはEDIのシステム刷新を図る際には、現行の取引業務プロセスやシステムに相応の変更があることを取引先に伝え、先方の納得のもとでEDIを導入してもらう必要があります。加えていえば、EDIの新規導入や刷新時には、取引先ごとに、どの通信手順（通信プロトコル）でつなげるのが適切か、あるいは、取引先のフォーマット変換に対する要件はどのようなものかをしっかりと確認したうえで、その設定、システム開発を図らなければなりません。また、EDIシステムの本番運用前には、取引先による通信テストの実施を支援したり、導入プロジェクトの進捗状況を把握したり、各種の問い合わせへの対応なども行う必要があります。さらに、EDIのシステム導入後には、取引先と自社とのデータの送受信の状況も適宜確認しなければならず、そこに問題が発生した際には、その原因の究明と対応を行う必要があります。
そしてこれらの作業は、EDIの接続対象が増えるたびに発生する、あるいは増えていく可能性があるのです。
このほか、EDIのシステムについては、例えば、近年における「EDIの2024年問題」や「インボイス制度の施行」、さらには「電子帳簿保存法の改正」など、社会的な環境の変化にもしっかりと対応していく必要もあります。
「EDIの2024年問題」とは？ 「EDIの2024問題」とは、NTT東日本・西日本のISDN回線サービス「INSネット」の「ディジタル通信モード」が2024年１月をもって終了となり、同サービスを使用していた多数の「レガシーEDI」（＝JCA手順、全銀手順、全銀TCP/IPなどの通信プロトコルをベースとする旧式のEDI）を「流通BMS」や「JX手順」「EDIINT AS2」「ebXML MS」、さらにはファームバンキング用のファイル転送サービス「AnserDATAPORT」などに対応したインターネットEDIやWeb-EDIに移行させる必要が生じた問題を指す。
もう1つ、EDIのシステム開発・保守・運用を巡る問題として挙げられるのが、属人化のリスクです。
実際、EDIのシステムは、IT部門内の特定の人員が長年にわたって保守・運用を担当し、取引先のフォーマット変換の要件などを適宜確認しながら、コツコツと作り上げてきた仕組みであることが多くあります。このようなEDIのシステムは、IT部門内でシステムを作り上げ、保守・運用を担ってきた担当者以外は中身がわからず、接続先の追加やEDIと基幹システムとの連携などが行えないといった “属人化” の状況に陥ります。
結果として、当該のEDI担当者が高齢化によって退職してしまった場合、EDIの保守・運用、ないしはトラブルへの対応がままならなくなります。
当然のことながら、こうしたリスクは、IT部門の若手の人員にEDIのシステム開発や保守・運用を担ってきたベテランのスキル、知識を習得させることで回避できます。
ただし、内製によって独自に維持してきたEDIのシステムは、DXの担い手となりうる若いIT人材に継承させるべき仕組みなのでしょうか。おそらく、そのように問われれば、EDIを使う大多数の企業のIT部門が「そうではない」と答えるはずです。
EDIに関する上述したような問題は、EDIの導入や保守・運用のあり方を抜本的に変革しなければ解決することはできないといえます。
逆に、例えば「EDIの2024年問題」の解決に向けて、オンプレミス環境で使用してきた既存のEDIシステムを単純にバージョンアップしてしまうとすればどうでしょうか。
これは、EDIのシステムを、インフラを含めて自社内で継続的に保守・運用していくことを前提に、使用する回線のインフラをINSネット（のディジタル通信モード）から、インターネット回線に切り替えるだけのことといえます。したがって、上述したようなシステム刷新に関連した手間はそのままとなりますし、保守・運用の業務負担も低減されないことになるでしょう。
また、EDIのシステム刷新後も、内製でのシステム開発の体制をそのまま維持しようとするならば、上で触れた属人化の問題も解決されないことになります。
したがってまずは、EDIのシステム基盤をオンプレミス型から、クラウド型へとシフトさせることを検討すべきといえます。これによってIT部門は、少なくともEDI業務を支えるシステムインフラの整備や保守・運用から解放されることになります。と同時に、EDIというミッションクリティカルな仕組みの可用性や24時間365日の安定稼働を手間をかけずに確保できる可能性が大きくなります。
とはいえ、単純にインフラをクラウド化しただけで、EDIのシステム開発・保守・運用を巡る問題が一挙に解決されるわけではありません。
実際、Web-EDIは、クラウドサービスとして提供される仕組みですが、これを採用するに当たっては、取引先企業に対して事前に通信プロトコルやEDIの仕様、ルールを確認して利用可能なWeb-EDI製品を選定することが必要となります。また、取引先と自社との間でデータの送受が正しく行われるかどうかのテストを入念に行わなければならないほか、運用開始後も、データ送受信の状況確認を継続して行う必要があり、かつ、トラブル発生時の対応にも相応の労力が必要とされるはずです。
以上のように考えていくと、EDIのシステム刷新をどのようにして行うべきかの答えが見えてきます。それは、システム基盤のクラウド化を図るのと同時に、開発から保守・運用に至るほぼすべての作業を、信頼の置ける外部の専門事業者に委託（アウトソース）してしまうことです。
このソリューションによって、社内IT部門の要員にかかるEDIのシステム開発・保守・運用の業務負担をドラスティックに引き下げることが可能になります。また同時に、重要な取引先からの受注や仕入など、自社における事業の継続性に大きくかかわるミッションクリティカルなEDIのシステムを安心・安全に稼働させ続けることができるようになります。結果として企業のIT部門は、より多くの人的リソースを、より戦略的で働き手のモチベーションが高いレベルで維持できるIT業務に割り振ることが可能になります。
ちなみに、インターネットEDIやWeb-EDI、流通BMS、FAX配信など、幅広いEDIニーズに柔軟に対応し、各種多様なプロトコル変換やマッピングに対応可能なSCSKのクラウド型EDIサービス「スマクラ」は、EDIにおけるシステムの開発から構築、保守・運用に至るまでのサービスが包括的に提供されるソリューションです。
本ソリューションにおいては、EDIに関する豊富な運用実績とノウハウを有し、製造や流通の商習慣にも精通する専任チームが、システム移行や保守・運用、ヘルプデスクなどの業務にあたります。そのため、お客様は、EDIのシステム開発と保守・運用に要する手間を大幅に低減できます。そんなスマクラへの評価は高く、2024年3月時点で本部契約300社以上の実績を積み上げ、年間数10兆円を超える商取引情報がスマクラ上でやり取りされています。
