受発注システム選びの勘所【第2回】流通BMS対応の受発注システム導入、初めの一歩

基幹システムとの連携が容易にできなければ、流通BMS本来のメリットを引き出したシステムとは呼べない。場当たり的な導入は結果として自らの首を絞めかねないのだ。

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

　前回「流通BMSの先行事例から見えてきた受発注システムの課題」では、流通業界のお荷物的な存在だった受発注システムが、流通BMSと呼ばれる標準によって生まれ変わりつつあることを説明した。しかし、先行事例を見る限り導入に当たっての課題は多い。システム担当者にとっては頭の痛い問題であり、“触らぬ神にたたりなし”、できることなら先延ばしにしたいというのが本音ではないだろうか。とはいうものの、20数年にわたり使い続けられてきた旧来のJCA手順はもはや限界で待ったなし。遅かれ早かれ検討を始めなければならない状況である。本稿では、そんな悩めるシステム担当者が流通BMS対応の受発注システムを導入する際、事前に考慮すべき点についてアドバイスしていきたい。

導入に当たってまずは既存システム・業務の課題を洗い出そう

　あらためて整理してみると、流通BMSを導入するに当たって流通業界のシステム担当者は以下の課題を抱えている。流通業が抱える共通の課題を自社に置き換えて考えることは、導入方法を検討する上で非常に有効だ。

受発注システムの課題

　EDI（Electronic Data Interchange）に関しては、混在する既存の種々の仕組み（JCA手順、全銀手順、Web EDI）を持っているのに加えて、新たに流通BMSへの対応を迫られている。既存の仕組みが一気に流通BMSに置き換わる状態ではないため、既存の環境を残しつつ、流通BMSにどう対応するかが課題である。

　小売業のシステム担当者にしてみると、大小の規模を合わせた何千という取引先に対して一度に流通BMS化への依頼をすることは到底できないと考えている。一方で、卸売業やメーカーのシステム担当者は、得意先である小売からの依頼だからといっても、1社からの依頼で流通BMS化に充てられる費用は限られている。たとえ今後ほかの取引先から同様の依頼があると予想できても、あらかじめそれを見越した上で予算も含めたシステム化の検討を行える企業は少ないだろう。

　われわれがコンサルタントとしてお話しさせていただくと、小売側にしても、卸・メーカー側にしても、このような課題を抱えている担当者をよく目にする。特に小売よりも卸やメーカー担当者は、得意先である小売各社が今後（段階的ではあるにしても）流通BMSに対応していくことは分かっていながら、全体を見据えた流通BMS化の予算を取ることができないようだ。結果として、1社ごとに対応するたびに工数や費用を掛けてしまっている企業が多い。

業務面での課題

　既存システムが日次や月次の業務の締め処理に合わせて構築されているため、各業務の締め時間にシステム負荷が集中してしまう。そのため、月末や年度末の負荷に耐えられるシステムリソースの増強を常に考える必要がある。しかし、締め処理の時間以外はシステムリソースに十分余裕があるにもかかわらず、「システム側の都合で業務や締め処理の時間を変更できない」と考えてしまうシステム担当者は少なくない。結果として、業務的な改善を提案できずに、単に最大負荷に耐えられるだけのシステムリソースを追加するしか処置がないのだ。

業務的な改善を提案できず、ピーク時の処理量に合わせてシステムを構築するしかなく、平均するとほとんど使われていない無駄の多いシステムになってしまう

　その原因には、一般にシステム担当者が「業務をうまく回るようにするのが大前提で、自分たちは裏方に徹するのが本分だ」と考えている背景がある。そのため、ハードやソフトの保守が切れたことをきっかけに業務システムを入れ替えたとしても、システム担当者が常日ごろから業務課題を取り除くようにはかかわっていないため、以前と比べて何ら導入効果が感じられないシステムが出来上がってしまっていることも多い。

　例えば、マスターデータなどは、先にシステム登録されていなければ入出荷はおろか発注・受注すらできない。しかし、マスターデータの更新がリアルタイムにできるシステムを備えていないため、システムの対応ができるまで新商品を販売できなかったり、システムが対応する前に販売してしまった場合には、後日手作業でデータを修正したりしている。マスターデータのシステムを更改したとしても、商品アイテムの増加によるHDD容量の拡充と性能を含めた操作性の向上だけに着目してしまうと、業務として抱えている課題であるマスターデータのリアルタイム更新は未解決のままとなる。

　このように、業務課題を解決するためにシステムを導入したはずが、結局は業務課題を棚上げしてしまっている例はいくらでもある。

システムロードマップの課題

　多くの企業がそうであるように、必要に迫られつつシステムを整備してきた結果、いざEDIとして流通BMSを導入しようとしたとしても、その効果が実現できるはずの、物流・トレーサビリティ・会計をはじめとする基幹系の仕組みとの連携が容易でなくなっている。具体的には、各システム内で利用しているマスターデータやけた数、項目の属性などがシステムごとにバラバラで統一されていない仕組みをよく見かけるのだ。

　流通BMSを基幹システムと連携させるには、各システムの経年劣化に合わせて更改計画をあらかじめ作成し、伝票レス、トレーサビリティ、在庫管理、RFID、自動発注などの今後取り組むべき機能と併せて、既存基幹システムの効果を引き出せる要件を明確に定めた上で、段階的に連携を図る必要がある。そのためには、システム担当者は企業内のシステムをふかんした上で、必要に応じて適切な要件を既存基幹システムに追加しながら流通BMSの導入を進めるのがよい。

　われわれがコンサルタントとしてよく直面するのが、自社のシステムをふかんできずにいるシステム担当者である。「システムをふかんする」ということは、単にある業務システムのI/Oを明確にするだけではなく、企業の業務全体の業務フローを把握した上で、ロールとミッションがどのように結び付き、いつシステムを利用（参照・更新）しているのかを把握することである。その結果、おのずと業務とシステムのズレや課題が見えてくるのである。

　流通業のシステム担当者は、大小の差はあるにしても上記のような課題を抱えて既存のEDIを運用しながら、流通BMSの導入を検討している。システム担当者として考えていただきたいのは、流通BMSの導入はシングルポイントでは解決できないということだ。前述の課題が示すように、既存EDIのメンテナンス工数に加えて、さらに場当たり的に追加する形で流通BMSを導入するのであれば、一向にメンテナンス工数が減ることはないのだ。ここはぜひ腰を据えて取り組む必要があると理解していただき、それが結果として担当しているシステムをより良い仕組みに変えていく近道となり、システムを変えることで業務が改善し、全社がより良くなるととらえていただきたい。

　次回は本稿で挙げた課題を踏まえ、流通BMS対応製品の種類や製品選びのポイントを解説していく。

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

筆者紹介

宮田泰宏

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

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

関連ホワイトペーパー

流通業 | EDI | 基幹システム | 在庫管理 | ハードディスク | RFID | ワークフロー