INDEX
Web-EDIとは、企業間電子商取引を実現するための一つの方式です。WebブラウザやWebサーバなどWeb技術を用い、インターネットを介して人がそのプロセスに関与しながら電子商取引を行います。具体的な実現形態としては、伝票表示型(ブラウザ型)とファイル転送型という2つのタイプがあります。
伝票表示型(ブラウザ型)とは、注文書など紙の伝票イメージをそのまま画面に持ち込んだような形態で、たとえば、受注企業なら注文一覧から注文内容を確認し、納期回答や出荷情報の入力を伝票イメージを確認しながら画面操作によって行うものを指します。
一方、ファイル転送型とは、その名のとおりファイル形式でビジネス文書のデータをやりとりします。発注企業がサーバへアップロードした注文書ファイルを、受注企業がアクセスしてダウンロードするといった具合です。派生形として、アップロード・ダウンロードのプロセスを自動化するソフトウェアを利用するケースもあります。
実は、Web-EDIという言葉には少し矛盾があります。そもそもEDIとは、「異なる企業間で、商取引のためのデータを、通信回線を介して標準的な規約(可能な限り広く合意された各種規約)を用いて、コンピュータ(端末を含む)間で交換すること」です。つまり、人が介在することなくコンピュータ間で自動的にやり取りするのが本来のEDIです。そのため、Web-EDIは人が操作するのでEDIとはいえないということになります。そして、アップロード・ダウンロードのプロセスを自動化するソフトウェアを利用するケースも人は介在しませんが、ファイルの形式や受け渡しのプロトコルが標準的な規約を用いていないことが一般的ですので、これもEDIとはいえません。
それなら、なぜWeb-EDIは誕生したのでしょうか。EDIを行うにはコンピュータ(一般的にはサーバ)、通信設備、業務システムが必要で、相応の投資を伴います。しかし、商取引を行うすべての企業に投資の余裕があるとは限りません。たとえば、ある製造業の取引先には家族経営で部品を製造する企業の場合もあります。企業規模からEDIへの投資は難しい。かといってビジネス文書を郵送やFAXでやりとりしていては効率が上がりません。その点、Web-EDIであれば1台の一般的なPCとインターネット回線さえあれば取引が可能になるため、小規模な企業も気軽に参加できます。多様な取引先とビジネスを行う企業としても、それほど効率を落とさずに企業間取引の電子化を進められるというわけです。
ちなみに、インターネットEDIという言葉もありますが、これはWeb-EDIとは別ものです。こちらは、JX手順やebXML MS、EDIINT AS2などといった標準的な規約に則ったインターネット対応の通信プロトコルを用いたEDIのことを意味します。
Web-EDIはどのように構築すべきでしょうか。業界によっては、Web-EDIガイドラインというものが、すでに策定されています。
たとえば、下記のようなガイドラインです。
このようなガイドラインに則ったEDI標準をベースにWeb-EDIを構築することがベストです。なぜなら、それによって受け渡す情報(メッセージ)やデータ項目、コード体系、帳票、ファイル形式といったものが統一されるとともに、画面操作や運用も一元化しやすいからです。
また、ガイドラインではセキュリティ対策や運用方針なども示しています。個別要素を極力排除し、こうした指針にしっかりしたがってWeb-EDIを構築すれば、取引先や業界から理解や評価が得やすくなり、利用してもらいやすくなります。業界の中には、企業の構築したWeb-EDIシステムやWeb-EDI製品・サービスが、その業界のガイドラインに準拠していることを認定するところもあります。
それでは、「業界にガイドラインが存在しない」という場合はどうしたらよいでしょうか。業界によっては、ガイドラインは策定されていないものの、多くの企業が利用するEDIサービスが存在したり、業界のリーディングカンパニーが仕様を提案していることもあります。一度業界団体に尋ねてみてください。それらも見当たらないという場合は、タイプの似た業界のガイドラインを参考にすることをお勧めします。
Web-EDIでは、セキュアなHTTP通信であるHTTPSを利用し、すべてのデータは暗号化されます。業界のガイドラインにもセキュリティに関する考慮事項は掲載されているので、ぜひ参考にしてください。
基本的な方針としては、セキュリティポリシーを具体的に定め、それにしたがって実装・運用することが重要です。たとえば、ログインIDやパスワードは桁数や複雑さを指定するとともに、有効期間や世代管理も設定します。また、定期的なパスワード変更依頼、攻撃を想定したログインの連続失敗への対処、同一アカウントでの同時ログイン制御、パスワード忘れやパスワード変更への対応なども、あらかじめ決めておきましょう。
アカウントごとの権限やロール設定も忘れてはいけません。当該アカウントで行える業務範囲やITリソースへのアクセス権を厳格にガバナンスします。
証跡管理も肝要です。誰がいつどのような操作をしたかを記録しておき、万が一の場合の行動追跡や監査対応に備えます。
加えて、Web-EDI構築時には脆弱性を考慮した設計や開発が不可欠です。システムを公開する際には第三者による客観的な脆弱性診断を事前に行うことが望ましく、セキュリティパッチをこまめに適用するなど継続的な脆弱性対応も求められます。
企業間商取引でWeb-EDIを利用することで様々な課題を解決できる大きなメリットがありますが、残念ながら課題も多く残されていることを認識しておく必要があります。
このように、Web-EDIにはメリットも多いですがデメリットも少なくありません。その意味では、これはあくまで本流のEDIを補完するもので、Web-EDIだけで多様な企業との電子商取引を実現するのは難しいと考えるのがよいでしょう。
それでも、Web-EDIで業務効率化が進むのもまた事実。構築する際には、できるかぎり業界のガイドラインに則りながら、取引企業の企業規模や取引量を考慮し伝票表示型とファイル転送型(自動送受信のソフトウェアも配布)の双方を用意し手作業を最少化することをめざしましょう。また、Web-EDIのメリット・デメリットに関して説明会開催などで取引先と共有し、理解を得ながら推進することが重要です。
各業界でのガイドラインでは、Web-EDIの仕組みを構築するうえで考慮するべき点をいくつか挙げています。
まず、Web-EDIは、EDIを補完するものとして位置付けており、EDIも同時に行える仕組みにすることを推奨しています。そして情報種や取引量、さらには企業のバックエンドシステムとの連携性なども考慮して伝票表示型とファイル転送型の双方の仕組みを用意することも推奨しています。このように様々な形態で取引が可能な仕組みを構築することで、Web-EDIのメリットを最大化し取引先の企業規模や取引量で差をなくすることで、公平で効率的な企業間電子商取引を実現することができます。(図1)
次に、Web-EDIで交換されるデータの重要性を考慮し、最低限のセキュリティレベルを担保するためにHTTPS、ログインID、パスワードを利用することとしています。それ以上のセキュリティの確保は、各社でのセキュリティポリシーに委ねられていますが、昨今の情報セキュリティの強化の観点からセキュリティポリシーを策定し、オープンなインターネットをベースにしたWeb-EDIの信頼性や安全性、品質を担保する必要があります。
そして、最も重要なことは、各業界が定めるEDIメッセージやデータ項目に準拠してWeb-EDIの仕組みを構築し、業務や運用を考慮した操作性を提供することです。
データ・アプリケーションのACMS WebFramerは、取引業務を容易にIT化できるWeb-EDI構築のためのシステム基盤です。商取引に求められるすべての業務プロセス機能を、発注企業、受注企業の双方に対して提供します。それだけではなく、社内情報共有など企業内外のさまざまな業務に適用でき、全社規模のWebシステムの基盤としても活用していただけます。
ACMS WebFramerは、管理機能と構築支援ツールからなり、構築支援ツールによりノーコードでWeb-EDIを構築でき、基幹EDIシステムとしてデファクトスタンダードであるACMS B2BやACMS Apexと同じ運用体系の中でWeb-EDIを統合管理することができます。さらに、アプリケーションサンプル、テンプレート提供により、迅速な取引業務の立ち上げを支援。各業界でのWeb-EDIガイドラインに則ったシステムを構築するための機能を提供しおり、主要な業界からも認定を受けており、ACMS WebFramerは取引企業に幅広く利用される Web-EDI構築を実現します。
取引業務を容易にIT化できるWeb-EDIシステム構築のための新しいシステム基盤。
EIAJ-EDI標準(2001年版)をベースにしたWeb-EDIテンプレート。
流通BMSの主要6メッセージに対応した小売向けWeb-EDIテンプレート。
Webベースでのデータ交換システム構築を容易に実現。
以下のページでは、インターネットEDIの特長と利用される6大通信プロトコルを解説しています。
また、各業界で決まったインターネットEDIについても解説しています。併せてご覧ください。