株式会社与野フードセンター様 第2回

事例でわかる流通BMS導入プロジェクトの詳しい進め方
「流通BMSは導入したいが、プロジェクトの進め方がわからないので不安」という声が多くのスーパーマーケットから寄せられています。確かに不安は多いと思いますが、実際は想像以上に難しくありません。そこで今回は、スマクラを採用して流通BMSの導入を進めている株式会社与野フードセンター(以下、与野フード)様の事例を通して、具体的な手順を解説していきます。

株式会社与野フードセンター

与野フードセンターは1960年に埼玉県与野市(現さいたま市)で創業した食品スーパーマーケットです。「よい物を安価に」をモットーに、地域密着で18店舗を展開しています。


連載第2回 第2回目は、現状のデータ項目を整理する「要件定義」について説明します。既存のデータ項目と、流通BMSの標準データ項目のどこが違うのかを明らかにすることが要件定義の目的です。ここを疎かにすると、後の工程に大きな影響を及ぼしますので、第一のハードルと考えて真剣に取り組みましょう。
第1回をみる
第3回をみる

要件定義ではどのような作業をするのですか。

中心になるのは、データ項目のマッピング作業です。簡単にいえば、今のデータを整理するということ。現状のデータの中身を調べて、新しい流通BMSの形に合わせていきます。実際の作業は、スマクラチーム(SCSK)が行いますので、流通BMS導入企業や基幹システムの担当ベンダーは「この項目は何ですか?」といったスマクラチームからの質問に答えていただくだけです。

要件定義には誰が出席すればいいのでしょう。

導入企業の担当者、基幹システムのベンダー担当者、スマクラチーム(SCSK)のSEの3者で行います。関係者全員が出席する必要はありません。

要件定義のミーティングは何回程度行う必要がありますか。

4、5回が一般的です。ミーティングで出た宿題を導入企業、基幹システムのベンダー、スマクラチームがそれぞれ持ち帰り、次回のミーティングで確認する作業を重ねていきます。1週間おきまたは隔週で開催するケースが多く、4回実施で1、2カ月はかかる計算です。

与野フード様ではスピードを優先して毎週開催し、1カ月で要件定義フェーズを終えました。

要件定義には1回でどれくらいの時間がかかるのですか。

1回で3、4時間です。データの細かい確認作業になるので、それなりの時間はかかります。採用するデータ項目数によっても時間は変わってくるでしょう。

要件定義で行う作業には何がありますか。

「①現行データ項目の確認」「②マッピングシートの作成」「③スマクラforWebの画面・帳票の確認」の3つです。

「①現行データ項目の確認」では何をするのでしょう。

現在やり取りしているデータの中身がどうなっているかを細かく確認していきます。一般的に、データ項目は導入企業ごとに異なるため、現状を把握することから始める必要があります。

まず、基幹システムの担当ベンダーから、現行のデータ種、データ項目、データレイアウト(データの桁数、具体的な利用方法)を仕様書ベースで、スマクラチーム(SCSK)が説明を受けます。基幹システムのベンダーは、IT寄りのデータ構造には深い知識があるものの、スーパーの業務には詳しくない事があります。そこで、導入企業には業務側の視点でサポートしていただきます。後工程のマッピング作業に支障をきたさないように、仕様書だけでなく、サンプルデータも使ってダブルチェックします。

データは基幹システムのベンダーが用意するのですか。

ケースバイケースです。データに関しては、構造を最も理解している基幹システムのベンダーが理想的といえます。自社で基幹システムを構築している場合は、担当者がデータを用意しています。

与野フード様では、基幹システムの一部プログラム変更を要した為、担当ベンダーの全面的な協力が必要となりました。

サンプルデータは必要ですか。

必要です。なぜなら、紙の仕様書に書かれているデータ構造と、実際のデータ構造が異なる場合があるから。例えば、紙の仕様書には10桁のデータとあるのに、実際は6桁しかないといったケースが過去にありました。この段階で狂ってしまうと、後工程に大きな影響を及ぼしかねないため、仕様書とサンプルデータの2段構えでチェックしていきます。

「②マッピングシートの作成」とは何でしょう。

①で整理したデータ項目が、流通BMSの標準形式では「どの項目に相当するか」を紐付けていく作業です。具体的には以下の3ステップで実施します。

Step1:現行データ項目をマッピング
流通BMSは、従来のJCA手順と比べてデータの項目数がはるかに多いため、現行データ項目に対して不要な項目も出てきます。そこで選別作業が発生します。

Step2:必須項目への対応
流通BMSでは、必ず入れなければならない必須項目があります。そのため、現行データで不足している必須項目を洗い出し、どう対処するかを決定します。しばらく使わない項目は一時的に「0」と入れるといった便宜的な対応を行う程度で十分です。

Step3:任意項目への対応
Step1とStep2で漏れた項目について対応方法を決定します。

●要件定義(マッピングイメージ)

与野フード様においても、Step1からStep3へと、順序を追って進めました。初めて導入するスーパーさんの立場からすると、流通BMSの専門用語は理解できないことも多く、戸惑うケースも少なくありません。また、基幹システムのデータ構造についても、担当者レベルで深い知識を持つことは稀です。そうした場合でも、流通BMSと、基幹システムの両方に詳しいスマクラチームが間に入ることで、コミュニケーションがスムーズに進みます。

現行データ項目が、流通BMSのデータ項目にあてはまらない特殊なケースではどうすればよいのでしょうか。

特殊ケースは避けることが望ましいといえます。しかし、どうしても対応が必要な場合はルール違反にならないように、回避策を模索します。スマクラチームは、過去に何十社もの導入を手がけ、特殊なケースにも対応してきた実績があるため、代替手段を提案することが可能です。どうしても難しいというケースの場合、スマクラチームから業界団体を介して流通BMS協議会にチェンジリクエストを申請します。

与野フード様のケースでは、流通BMSにない「伝票タイプ」(紙伝票の種類)がありましたが、「商品分類(中)」の項目に割り振ることで対応しました。それ以外については、標準に近いデータ構造で構成されていたため、ほとんど苦労なく終わっています。

「③スマクラWebの画面・帳票の確認」とは何ですか。

与野フード様のケースでは、「スマクラforBMS」に先行して「スマクラforWeb」を利用するため、手書き伝票の取引先の利用を想定したデモを実施し、受注・出荷の画面・帳票を確認しています。特に、手書きで登録した情報は、与野フード様の基幹システムに取り込む必要があることから、現行業務に適合しているかどうかを確認していただきました。以上の工程で要件定義はすべて終了です。

要件定義の次工程ではどんな作業をするのでしょう。

パイロット取引先を選定し、接続テストを行います。並行して全取引先に対する説明会の準備を進める作業が待っています。

第1回をみる
第3回をみる