受発注システム選びの勘所【第3回】流通BMS対応の受発注システムの種類と製品選定方法

流通BMS対応製品はどのような種類があって、どう選べばいいのか。本稿では流通BMS対応製品の種類と機能を解説するとともに、製品を評価して選定する方法の一例を示す。

[宮田泰宏，ウルシステムズ]

　前回「流通BMS対応の受発注システム導入、初めの一歩」では、システム担当者が流通BMS対応の受発注システムを導入する際に、既存システム・業務の課題を洗い出す必要性を解説した。システム担当者の課題は一朝一夕に解決することはできないが、流通BMSの導入を行う際のポイントを押さえることで解決方法を考えやすくなる。本稿では実際に自社システムとして流通BMSを取り入れる際の、製品選びのポイントを解説する。まずは先述した流通BMSの導入を行う際のポイントを整理しよう。

流通BMS導入3つのポイント

ポイント1：メンテナンスコストの削減に注目する

　これまでのEDI（Electronic Data Interchange）の仕組みは、Web EDIであれJCA手順であれ、各社各様の仕様（電文フォーマット）を各社異なる伝送方法で送付していた。そのため、そのシステムのメンテナンス、例えば小売業側で「ある項目のけた数を増やしたい」「商品属性の情報を追加したい」などといったシステムへの要求があった場合、取引先となる卸売業やメーカーは都度その対応をする必要があった。小売業の担当者にしてみれば、数年に一度程度の仕様変更なら、卸売業やメーカーの対応が大変だとは考えないかもしれない。しかし、何千という得意先を抱えている卸売業やメーカーのシステム担当者にしてみれば、常にどこかの得意先の要求に合わせたシステムの改修が必要になる。流通BMSの仕様に関しては、電文フォーマットが統一されているだけでなく、伝送方法も決められているため、メンテナンス工数は格段に減らすことができる。特に、卸売業やメーカー側にしてみると、これまで小売業ごとに対応していたメンテナンス工数を削減する効果が大きい。

ポイント2：他システムとの柔軟な連携を図る

　これまでの受発注システムはバッチ処理が基本であり、当日の夕方一斉に注文から受注処理が動くことが多かった。大手の場合、JCA手順で卸が小売からの注文を受けるのに、1時間以上の時間を要している例はまれではない。そのため、ホストコンピュータにEDIの仕組みを入れることで、信頼性の確保と続いている業務との連携（ホストコンピュータ上のバッチ処理で連携）をうまく実現しているケースが多く見られる。流通BMSはリアルタイム処理をベースにしているため、受発注は随時可能であり、ホストコンピュータのような大掛かりな仕組みも必要ない。そのため、既存のEDIをホストコンピュータから切り離し、WindowsやLinuxのサーバで処理をすることでホストコンピュータの負荷を減らすことが可能である。また、既存のJCA手順がアナログ回線だったのに比べて、流通BMSはインターネットを利用するため伝送速度も速く、信頼性が高いため、基幹システムとしてホストコンピュータをそのまま利用し続けたとしても、サーバ側で既存の仕組みに合わせたデータ変換やバッチ処理の呼び出しが可能である。このように、流通BMSを利用することで、既存システムを大掛かりに入れ替えるのではなく、一部を切り離して柔軟に適用していくことが可能である。

ポイント3：EOS化率の向上を図れるようにする

　多くの企業の受発注の仕組みの中には、いまだに電話とFAXによるシステムが多く残っている。Web EDIを利用するにしても、小売ごとに様式が異なる仕組みでは、取引先となる卸やメーカーが各小売専用の仕組みを用意しているのと同じで、小売にとっては一見都合が良さそうでも、結果としてそのコスト負担は小売に跳ね返ってきている。流通BMSに対応した製品は、これまでのサーバ型やクライアント型といった機能を直接利用する製品だけではなく、あらかじめ業務と連携した製品も出てきている。例えば、物流ラベルやマスターデータと連携した製品などである。このような製品以外にも、ハンディースキャナーや自動検品の仕組みと連携するような製品もある。サーバ型やクライアント型では、導入するのにシステムインテグレーションが必要であったりする場合が多く、すぐに利用するのは難しかった。その点、業務と連携した製品であれば、導入時の時間とコストを削減でき、これまではシステム化が難しく、電話やFAXでしか対応できなかった取引先とも流通BMSを利用することでEOS（Electronic Ordering System：オンライン発注）化率向上を図ることが可能となってきている。

　EOS化率を上げることで一次的効果として紙を削減できるだけでなく、締め処理における違算チェック作業を減らし、人件費の削減につなげることが可能である。さらに電子化されたデータをその前後の処理でそのまま扱うことで、業務フローを簡略化し処理時間の削減にもつなげることができる。

　流通BMSは単なるEDIの追加作業ではなく、自社の業務システムを見直す際にこれらのポイントを都度意識しながら取り入れていくことがシステム担当者の課題を解決する近道である。それでは、具体的に流通BMSに対応した製品を分類してみよう。

流通BMS対応の製品

　流通BMS対応の受発注システムを導入するに当たっては、スクラッチからシステムを構築するのではなく、何らかのパッケージ製品を選んで導入することが望ましい。なぜなら、標準化されたプロトコルやフォーマットを前提にしたシステムであるため、既に多数の安価で安定したパッケージ製品が提供されているからである。それでは、どのように製品を選べばよいのだろうか。流通システム標準普及推進協議会（※）では、流通BMSに準拠した製品を「みんなつながる流通BMS」というロゴマークにより準拠製品として認定している。ここでは、どのような製品があるのか機能ごとに分類してみたい。

※流通システム標準普及推進協議会：流通システム標準化事業で策定された流通BMSなどの標準仕様を維持管理し、普及推進するための民間企業主体の組織。2009年4月、財団法人流通システム開発センター内に設立された。

　流通BMS対応のパッケージ製品にはシステム形態から分類してサーバ型製品とクライアント型製品の2つに分類される。前回触れたように、流通BMSの機能に加えて物流やマスターデータとの連携を容易にすることを機能として盛り込んだ製品なども、サーバ型もしくはクライアント型の機能を備えている。また、従来同様にVAN事業者やASP事業者からも流通BMSのサービスは提供されているが、最近ではクラウドコンピューティングやSaaS（Software as a Service）型のサービスとしても提供されている。

サーバ型製品

　サーバ型製品は、リアルタイムでの通信を可能にしたプッシュ型のシステム形態を取る。サーバ型製品同士はもちろん、クライアント型製品とも通信できる。他拠点との同時接続が可能で、基幹システムなどと密に連携できるため、大企業向けの製品である。オールマイティーな製品であり、小売業や大手卸売業・メーカーに向いているといえるだろう。

クライアント型製品

　クライアント型製品は、必要なときにサーバ型製品にアクセスするプル型のシステム形態を取る（JCA手順のシステム形態と同じである）ため、通信量の少ない中小企業向け製品といえる。ここで注意すべきことは、クライアント製品同士では通信することができないということだ。つまり、送受信する企業のどちらかがサーバ型でないと通信できないのである。実際は、発注側の企業はサーバ型を導入することが多く、受注側の企業はサーバ型とクライアント型のどちらかを選択することが多い。機能限定型であるが、中小規模の取引先向きである。

VAN／ASP事業者が提供するサービス

　従来のEDI（JCA手順や全銀手順など）においては、地域に根ざしたVAN／ASP事業者が中小企業向けにネットワークとデータ交換サービスを丸ごと提供するサービスを展開してきた。現在では、インターネットが当たり前になるにつれてネットワークを提供するということ自体の意味は薄れてきているものの、データ交換サービスとしては健在である。VAN／ASP事業者は、今までのEDIと同様に流通BMSにおいても、利用者がプロトコルを意識せずに、例えば従来の画面と同様のインタフェースを用いることで、業務に必要なデータ交換をサービスとして提供しようとしている。VAN／ASP事業を利用するメリットは、何といっても流通BMSのシステムを意識せず、従来通りのシステムと合わせて運用をすべて任せることができることだ。また、自社システムとの連携を容易にするためのカスタマイズに対応しやすいことが多い。デメリットは、従来のEDIと同様に従量課金でのサービスであり、流通BMSを利用することで直接的にはコスト削減にはつながらない場合がある。従来の運用を変えずに利用する場合に向いているサービスといえるだろう。

クラウド、SaaSとして提供される利用型サービス

　パッケージ製品ではないが、利用型のサービスも注目されている。利用型のサービスはさまざまなシステム形態があり一様ではないが、クラウド、SaaSの利点を生かして特色のあるサービスが提供されている。利用型サービスは、課金の方法はさまざまで、初期導入費用は比較的少ない場合が多い。導入までの期間は短く、申し込んだ翌日には利用可能となるサービスなどもある。そのため、利用の仕方によっては自社導入と比べて大幅なコスト削減を図ることが可能である。利用型サービスで気を付けなければならないのは、個別のカスタマイズが難しい点で、例えばインタフェースや運用画面はほとんどの場合が固定であったりする。そのため、自社システムとの連携においては、あらかじめ必要な機能が備わっているかどうかを見極める必要がある。また、極端に低価格の場合には、SLA（Service Level Agreement）があまり高くない場合もあり、注意が必要だ。コストを掛けずに新規導入する場合に向いているといえるだろう。

製品の選定

　製品を選定するに当たり、われわれがお勧めするのが、選定に当たっての評価項目を挙げ、それぞれの評価項目がどのくらい必要であるかを優先順位に従って点数を付けて評価するという方法である。

　評価項目とはシステムの要件に当たるもので、システムに何を求めるかという項目である。ここで参考までに、流通BMSに対応した製品を選定する際の評価項目と、実際に製品評価をした例を下記に示す。この例では、あらかじめ製品の分類に従って絞り込みをした結果、最終的に3つの製品が候補となった。ここでは、評価項目として、「機能充足度」「操作性」「処理能力」「運用保守」「サポート・体制」「費用」の6項目を挙げた。評価をする場合に注意してほしいのは、どうしても費用を重要視してしまいがちなことだ。だが、流通BMSの導入はシングルポイントですべてのEDIを置き換えることはできないため、中長期の利用を自社システムロードマップに計り、自社に合う評価項目を吟味した上で総合的に判断してほしい。

製品選定の評価項目

評価項目			評価のポイント
機能充足度	1	スケジューラ機能	送受信の予定を管理する機能
	2	メール通知機能	送受信した結果をメールで通知する機能
	3	フォーマット変換機能	ファイルの形式を変換する機能
	4	BMSスキーマへの対応	各バージョンのBMSに変換する機能
	5	暗号化機能	送受信データを暗号化・復号する機能
	6	再送機能	送受信データを再送する機能
	7	監視機能	異常時に通知する機能
	8	アップロード／ダウンロード機能	手動でデータを送受信するための機能
	9	外部システム連携機能	既存システムなどと連携する機能
	10	帳票出力機能	帳票として印刷する機能
	11	検索機能	送受信したデータを参照する機能
	12	トレーサビリティ機能	取引の内容の変化を追跡する機能
	13	商品マスター管理機能	商品マスターを管理する機能
操作性	1	利用しやすさ	業務の流れに合わせた操作のしやすさ
	2	入力のしやすさ	画面の操作性、インタフェースの分かりやすさ
	3	デザイン	デザインの一貫性やフォントの見やすさ
	4	マニュアル	マニュアルの充実度。量ではなく質で評価
	5	カスタマイズ	利用者が必要に応じてカスタマイズができるかどうか
処理能力	1	性能要件	想定するピーク時のトランザクション（時間当たりの明細処理件数など）処理の要件を満たすか
	2	信頼性要件	システムのサービスレベル（稼働時間、耐障害性）を確保できるか
	3	データ保全要件	バックアップなどでデータの保全要件を満たすか
	4	障害時の処理継続性	エラーが発生した処理を修正後継続することが可能か
	5	拡張性要件	将来の増設時にサービス停止を可能な限り低減させるシステム構成であるか
	6	トラフィック制限	大量の送受信が集中した場合に設定したしきい値を超えないようにすることが可能か
運用保守	1	運用保守要件	システムを常に良好な運転状態に保つために必要な保守の要件を満たすか
	2	障害監視要件	障害時の障害部位、範囲、サービス影響などの情報把握が可能か
	3	障害等への対応	システムの改修のしやすさ
	4	データ移行	現行システムからのデータの移行のしやすさ。並行稼働の必要性
	5	セキュリティ対策	セキュリティ対策がなされているか
	6	ログ出力	必要なデータのログが十分に出力されるか
	7	メンテナンスの容易性	日常的な運用のしやすさ
サポート・体制	1	開発条件	OS、データベース、ミドルウェア、開発言語などの要件を満たすか
	2	開発スケジュール	スケジュールが要件を満たすか
	3	開発体制	体制が具体化されているか。体制に問題がないか
	4	障害対応体制	障害時のオンサイトでの対応体制
	5	システム導入実績	同様のシステムの導入実績
	6	導入支援体制（現場教育）	現場への導入に当たっての教育訓練の支援体制
	7	サポート体制（ヘルプデスク）	ヘルプデスクなどのオフサイトの窓口のサービスの充実度
	8	現状理解度	自社の過去の導入実績などから現状システムの理解が容易か
費用	1	初期導入費用（ハードウェア）	システムの導入に伴うハードウェアの費用
	2	初期導入費用（ソフトウェア）	システムの導入に伴うソフトウェアの費用
	3	初期導入費用（関連）	システムの導入に伴い、既存システムへの改修が発生する場合の費用
	4	保守費用（ハードウェア）	導入するシステムに必要となるハードウェアの保守契約費用
	5	保守費用（ソフトウェア）	導入するシステムに必要なソフトウェアの保守費用
	6	運用費用（3年間）	自社で運用する場合の人件費を算出
	7	ハウジング費用（3年間）	導入するシステムを外部に運用委託した場合の費用
	8	拡張費用（想定）	現状の構成から拡張を想定した場合に掛かる費用
	9	瑕疵（かし）担保期間	瑕疵担保の期間。瑕疵担保期間に無償で対応される範囲
	10	検収方法	検収の方法についての特殊要件に対応できるか

3つの製品の評価結果をレーダーチャートで表現してみる《クリックで拡大》

　レーダーチャートを見ると、A社の製品は費用が他社に比べてかなり安いが、特に機能やサポートが劣っていることが分かる。B社の製品は若干費用が掛かるが、ほかの評価項目は平均的に高得点でバランスが良いことが分かる。また、C社の製品は機能やサポートは良いが、運用保守性、操作性に劣ることが分かり、短期的なつなぎの製品としては良いかもしれない。このように、流通BMSに対応している製品でも特徴が異なり、つなぎとしての一時的な利用に向いている製品もあれば、初期導入費用は高くても中長期的に考えると結果として割安な製品もある。

　今回は流通BMS対応製品の分類と機能、製品を評価して選定する方法の一例を示した。受発注システムは単にデータ交換というだけではなく、SCM（Supply Chain Management）の土台となる最重要のデータを扱うシステムである。受発注なくして業務は始まらない。製品を正しく評価し自社に合うシステムを導入していただきたい。

※「流通BMS」は、財団法人流通システム開発センターの登録商標です。

筆者紹介

宮田泰宏

ウルシステムズ株式会社　ソリューション事業部

Java言語を中心とするオープンシステムの、10年以上の開発経験を持つ。現在はITコンサルタントとして、さまざまな業種のIT企画、ベンダー管理、PMO、技術の標準化などにかかわる。流通業においては、流通BMSを利用したEDIの導入を支援するコンサルティングを展開中。

関連ホワイトペーパー

流通業 | サーバ | EDI | ASP | SaaS | 暗号化 | 基幹システム | セキュリティ対策 | バックアップ | クラウドコンピューティング | データベース | SCM | ワークフロー