株式会社与野フードセンター様 第5回 (最終回)

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

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

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


連載第5回
営業企画部 部長 : 橋口一成様
第1回目「キックオフ」、第2回目「要件定義」、第3回目「取引先説明会」、第4回目「導入編(前編)」について解説してきました。
第5回目は、連載最終回の「導入編(後編)」です。
営業企画部 部長・橋口一成様に、導入後の状況についてと、これから流通BMS導入を検討される企業様へ向けてのメッセージをいただきました。
第4回をみる

稼動日以降の問題・課題としてどのようなものが挙げられるでしょうか。

おかげさまで、当初立てた予定通りに導入できたと言えます。
出荷データ化により、当初想定した通り、伝票入力周りのヒューマンエラーが減少したのは明らかです。ただ、問題がなかったかと言えばそうでもありません。最初のうちは、ちょっとしたヒューマンエラーは多発しました。

まず、「商品マスタ」です。
マスターから取り込む商品名称の桁数を15桁と当初定めたのですが、(最近の商品は商品名称の長いものもあり)、商品名称の最後に、「糠(ぬか)の●●漬け」の味種が表記されず、センターでの商品仕分けの際、どの味種の商品をどの店に仕分けて良いのか判断できなかったということがありました。商品は3つ届いているけれど、味種が異なっていて、どの店にどれを届ければ良いかわからず、仕分け作業がもたついてしまった、ということがありました。
これについては、システム上の対応、すなわち、商品マスタの桁数の設定変更をすぐに行うことで対応しました。

最もヒューマンエラーらしい、ヒューマンエラーとしては、「Web-EDIの画面操作」です。
取引先側としては、2画面操作して操作完了となるところを、最初の1画面だけ操作した時点で操作終了したと勘違いしてしまった一方で、センター側では、いくら待っても出荷データ(ASNデータ)が届かないため焦ってしまう、といったことが当初多発しました。
これについては、当運用を開始するに先立ち、お取引先様の各出荷部門担当者様の連絡先を把握していたため事なきを得ましたが、改めてお取引先様のご担当者には操作手順を再度周知を行い、以降同じような操作ミスを防ぐようにしました。

次に、「出荷始まりの対応」です。
出荷データを受け取るところから始まる取り組みとしては初めてであったため、何らかの問題が発生すると想定し、欠品情報について、システム導入前と後での比較を行いました。しかしながら、以前からお取引先様より検品状況のリストの提示を受けていたこともあり、稼動前と稼動後の比較結果として特に増減は見られませんでした。ただ、検品時のシステム操作上の課題が出てきました。ほぼ欠品がゼロであることが分かっている商品においては承認操作が煩雑であるため、これが検討課題として挙げられます。
鮮魚部門といってもすべてが市場取引によるものではなく、刺身のツマのように惣菜に近い加工品においてはそもそも欠品はない前提で考えて良い商品だと思いますが、これらの商品を画面上で1画面1画面確定するのは煩わしく、一括確定処理ができるような機能があると便利である旨をスマクラ側に伝えた次第です。

流通BMSの適用範囲の拡大に向けての今後の取り組みについてお聞かせください。

現在、与野フードセンターとしてグロサリーや他の生鮮部門への導入を行っている最中です。
これまでの導入過程の中で、様々なお取引先様の状況が少しずつ分かるようになってきました。つまり、流通BMSが進んでいるお取引先様と、そうでないお取引先様があるということです。
流通BMSの取り組みは、全体の仕組みとして考えていく必要があります。大手のお取引先様は問題ありませんが、中小のお取引先様は、簡単に対応してくれるかというと、そういう訳にはいかない場合があります。
今後、地元により密着した店舗作りを考える上では、幅広いお取引先様のご協力が不可欠であり、より多くのお取引先様に、流通BMSでのお取引をお願いしていくことが今後の課題でもあります。

これから流通BMSの導入を検討されている企業様に向けてのメッセージをいただけますか。

流通BMSへの取り組み方について

流通BMS導入は時代の流れなので、この流れに乗るということはまず必要と考えました。
一方で、基幹システム、取引のやり方、社内のルール(特に伝票のルール)、物流センターとの運用の取り決め、お取引先様への導入、等々が必要になってきます。
それに加えて、システムにかかわる投資、システムベンダー様の協力、等も必要になってきます。
そのうえで、流通BMSをどう活用していくのかという、会社としての方向性やビジョンが不可欠となるのは申し上げるまでもございません。
私たちは、そのような負荷を押してなお、流通BMSを導入するメリットがあると思っています。
流通BMSは、大手小売業のノウハウの塊です。メッセージと業務が紐付られ、定義されています。
流通BMSを導入する上での前提として、多少時間がかかっても流通BMSのメリット・全体ビジョンを理解した上で、世の中でどのように使われていくかを把握してから、自社の現状業務と流通BMSで定義されている業務と利用されているメッセージを検証して、流通BMSを導入することが望ましいと思います。


生鮮部門に流通BMSを導入する場合に考えるべきこと

グロサリー部門から手堅く導入するケースが一般的ですが、弊社では、生鮮の鮮魚から流通BMSの導入を開始しました。これは、先に述べた通り、新生鮮センターを立ち上げるタイミングがEDIの切替検討時期に重なったためです。正直申し上げますと、物流センターの立ち上げということがなければ、生鮮部門の流通BMS化については、恐らく後回しにしていたと思います。
特に苦慮したのは、市場品であるために、入荷直前まで産地が確定しない、品質によって価格がばらつく、といった生鮮ならではの要件をシステムにどう反映させるか、ということでした。
結論から言えば、出来ないことは出来ないということで、複雑なシステム構造にしない、ということで動き始めました。結果、原価・量目の修正による修正をフロー化することにとどめたシステムに落ち着きました。

生鮮の流通BMSのルールの詳細は、現在、関係者の皆様がその策定をされている最中ですから、当社として、その内容を受けてからの改修で良いと考えています。 導入において問題がある部分は、むしろシンプルにしておいて、当面、運用でカバーします。
現実的な方法論を模索することが肝要かと思います。


流通BMSの要件定義を行う際の心構えについて

今回、流通BMS導入に際しては、生鮮特有の課題に関する調整を、SCSK様主導で行っていただき大変助かりました。特に物流要件がそうです。
また、流通BMSを理解しているSCSK様には当たり前のことだったかも知れませんが、弊社では認識していなかったこと、例えば、JCAではできたことが流通BMSではできないという項目は検討・対応が必要です。
弊社の場合、レガシーEDI行っており、同じVANサービスの移行だったために、これまでの運用はそのまま引き継がれるものとの思い込みがありました。後から仕様の認識の違いとして発覚することになったのですが、流通BMSの要件定義では、1つずつ地道に確認していく姿勢が大切です。

小売側において、事前に洗い出しが必要と分かっていることがあるいなら行っておくべきです。特に、基幹システムとのシステム連携部分は念入りに行うべきです。弊社のようにパッケージとして導入している場合、その仕様の変更には極めて困難を伴います。その検討結果、すなわち要件定義に関わってくるところが全体の導入コストに大きく関わってくるので、最初の段階でなるべく精緻に行うことが重要になるかと思います。後から追加稟議を書くのは辛いことですから。


流通BMSの導入に要する期間の考え方

具体的には、2012年の9月にプロジェクトを立ち上げて、2013年の3月までの実質半年間で、生鮮センター(鮮魚・惣菜)のお取引先様向けの導入は一応完了しました。導入を終えて感じることは準備期間が短すぎたということです。
何とか当初計画したスケジュール通りに稼動へとこぎつけたものの、手書き伝票運用を廃止して出荷データに変更するなどの業務改革を伴う導入であり、ゼロから検討する項目も多く発生していたことを鑑みると、社内業務調整などのことも含め、1年かけて行うべき作業内容量であったと思います。
これから流通BMSを導入することを検討していて、ゼロから始めようと考えている企業であれば、次のようなスケジュール感が望ましいと思います。

  • 全体を概ね1年間程度として、そのスケジュールを明確化する
  • 最初の半年間は、仕組みの検証に充てる
  • 仕組み一つ一つに当たってから、はじめて流通BMSの要件定義に取り掛かる
  • 要件の段階では、仕組み毎に担当者に検証の振り分けを行う
  • 専任の担当者に振り分けて確認作業を行う(流通BMSはやっつけではできません)
  • 次に残りの半年ですが、この期間は実作業の検証に充てる
  • スケジュールの進捗確認は、できるだけ細かく行う(当社は週間単位で関係者と打合せを行いました)

流通BMSを導入することで、自社ではどのような業務改革を行うのか、どのように現状業務が変更されるのか、ベンダーではどのように現状業務が変更されるのか、自社としてどう変更して欲しいのか、事前に対象業務を抽出し、新しい業務での運用に支障が起きないかどうかなどの検証作業の期間が必要になります。


流通BMS導入のタイミングの考え方

弊社では、先に述べた通り、新生鮮センターの立ち上げタイミングに合わせてEDIの切替を行ったため、基幹システムに手を加えないことを前提に進めました。
また、短納期の導入スケジュールに対応するため、小さくはじめて徐々に拡大していく方法(ステップ分けを行った上での部分対応)を採用しました。
目標とするスケジュール通りに導入できたのは、社内だけでなく、お取引先様に多大なご協力を頂いた結果であり、心から感謝しています。
基幹システムの変更を行わなかったために、流通BMSの基本メッセージの全てには対応ず、今後の課題として残っています。(支払メッセージには対応していません。)
基幹システムの導入と一緒に、流通BMSを導入できるのが一番良いタイミングです。当然、物流センターを他社に委託している場合は、そこのシステム変更のタイミングというように、システム面の変更・導入のタイミングに合わせるのが、良いタイミングなのだと思います。
出来ないことは無理にやらない、無理をして全体が動かなくなってしまっては元も子もないので、全体最適を考えた上で、導入タイミングを決めることが望ましいと思います。

第4回をみる