システム移行に伴って、どのような点について気を使われましたか。

EDIの切替だけでなく、自社の基幹システムとスマクラ（流通BMS）とのシステム連携に対する投資コストがどれ位かかるのか、かけるコストに対して効果はどのようなもの想定されるのか、限られたリソースの中で短期導入を実現するにはどうすべきか、といった点について腐心しました。

導入前の接続テストはどのように行いましたか。

スマクラ（データセンター）とお取引先様の間のテストについては、基幹システムへの影響が懸念されたため、本番データをテストに使用することはしませんでした。そのため、本部の負荷が大きいのですが、代替手段として、様々なパターンを想定し、これに対応するダミーデータを本部で作成し、これをもってテストに臨むこととしました。本番直前になって想定外の事態が発生し、この対応に追われる一幕もありましたが、このような事態においても、各ベンダーの協力・各社の連携によって乗り切ることができ、スタートにまでこぎつけることができました。
なお、実際に想定外の事態が発生した場合には、対応策として仕様の一部見直しも発生しました。仕様の見直しはタイムラグなしに関係者が必ず情報共有をしなければなりませんが、これを行うためには本部に大きな負荷がかかります。そこで、テストに関わる資料についてはスマクラポータルを利用して、資料の配布を郵送ではなく、Web画面からのダウンロード形式にして本部業務の負荷軽減を行いました。

稼働前夜までに、どのようなことをされましたか。

生鮮部門の稼働で、どのようなことが変わりましたか。

生鮮センターの扱う対象は主に鮮魚で、鮮魚は日によって価格の変動があるなどEDI化が難しい部門ですが、流通BMS導入に取り組みました。 まず、センター業務では、これまで弊社では採用していなかった、出荷案内ベースでのセンター検収に変更しました。これまでは、発注データを使っていましたので、特に不定貫などは毎回入荷の度、発注データをお取引先様側で一旦取消して、手書き伝票に切り替えていましたので、折角のEOSデータが途中で途切れると言った非効率な運用をおこなっていました。流通BMSの出荷メッセージ（事前出荷案内）を使用することで、検収の精度をあげること、手書き伝票を大幅に削減することなど、お取引先様、及びセンター側を含めた弊社共に運用面での効率化を図ることが出来ました。その他、欠品やなどの把握もより精度の正しい情報を得ることができるようになってきました。

スケジュール通りに導入ができたポイントは何だったと思いますか。

一言で言うと、EDIではスマクラ（SCSK）をはじめとして、基幹システムや、ＩＴベンダー各社がそれぞれサポートしてくれたことだと思います。
業務での対応には、様々な与件があります。対応に迷った際には、スマクラが想定する業務を前提に出来るだけシンプルな形で合わせように腐心したことだと思います。また、基幹システムの入れ替え検討とは分離したことも大きかったと思います。ただし、後者においては、その弊害といいますか、不安要素、不確定要素を残すことになり、結果として、流通BMSで目指すべき、支払メッセージまでの連携に至らず、受領メッセージまでの導入に留まることになってしまいました。

具体的には、どのような取り組みとなったのでしょうか。

生鮮センターのオペレーションをシンプルにしたことは先に述べたとおりですが、流通BMS導入に際しては、お取引先様の協力が不可欠です。そのため、何よりも先にお取引先様に対して、運用・問題把握・業務の切り分けといった事柄それぞれに対し、これまで行っていた運用よりも効率的になるようにしましょう、という姿勢で取り組みました。 まず、世の中に流通業取引の標準と呼べるものは、流通BMSしか存在しないので、これをベースに検討しましょうという方針決定を行いました。流通BMS導入については、正直、お取引先様においても導入のハードルが高いことは承知した上で、各お取引先様にお願いしました。
流通BMSに対するご理解の状況は、お取引先様毎に様々でした。不安要件を抱えるお取引先様には、ひざ詰めしてご説明し、必要と判断した場合には、弊社側の運用でカバーするといった対策を取ることもありました。この対話の中から、業務の流れの形を作って行きました。
流通システム開発センターをはじめとして、流通BMS導入に至るあるべき論が語られた資料は数多くありますが、正直実感が湧かないものでした。実際に自ら導入・運用して初めて、その効果の実感が湧くようになり、効率化がなされたと体感出来るようになった次第です。
当初立てたスケジュール通りに導入出来た、その取り組みのポイントは、特別な運用をなくしたことです。従来行っていた業務、システム化が出来なかった業務をすべて、これを機にシステム化に取り組むといったことも必要ですが、流通BMSとはそもそも大手小売業のノウハウそのものです。流通BMSで検討して、従来行っていた業務がシステム化に沿わないのであるなら、それは無理をしてシステム化すべき業務ではないと認識すべきとしました。言い換えると対象業務すべてを無理にシステム化することでかえって業務が増えてしまうような場合には思い切ってシステム化の対象外としてしまいました。

例えば、どのような業務を対象外としたのでしょうか。

出荷メッセージ（出荷確定データ）をお取引先様から生鮮センターへ送信するようにしましたが、一部の商品に関して所定の締時間までに間に合わないことが判明しました。 具体的には、大半は地元の卸売市場から仕入れますが、品揃えの都合上どうしても一部は築地市場で仕入れることになります。この一部の仕入れで間に合わないものがあることが判明しました。事前に取り決めたお取引先様・生鮮センター・小売りそれぞれで無理がないとする運用ルールは、4:00までに出荷確定を行い、生鮮センターへ5:00までに納品するというものですが、築地からの搬送時間を考慮すると4:00までに出荷確定を行うのは事実上無理です。 そこで実際にその件数は何件であるのかを調査しました。その結果、日に数十件程度しか発生しないことが判明しました。発生件数が極めて少ないことが判明したため、これについては生鮮センター内の業務として対応（当日中にデータ化）することにしました。 もし、この調査を行わずに業務フロー上の変更で対応したとすると、出荷メッセージの締時間、生鮮センターや店舗への納品時間の変更、およびそれぞれの業務対応時間の短縮といった、製・配・販のどこかに無理を強いるようなことになっていたと思われます。標準の業務と例外の業務を明確に区別することで、結果として無理のない運用、これまで行っていた運用よりも効率的な運用が実現されました。

その他に対象外とした業務はありますか。

基幹システムの入れ替え検討と分離したのはなぜでしょうか。

流通BMS導入のきっかけとして、基幹システムの入れ替えを機にという話もよく聞きますが、弊社では敢えて基幹システムには原則として、大きな改修せずに実施しました。
①大きな投資コストをかけずに、流通BMS導入に踏み切る、②出来るだけ現行店舗オペレーションに修正を加えずに導入する、という2大方針を元に、今回のプロジェクトは遂行されています。
弊社が、基幹システムの入れ替えと切り離した形でスマクラ（流通BMS）の導入に踏み切ったのは、最悪の事態を避けるためでした。大手であれば、豊富な人材を背景に大規模なシステム改変と業務オペレーションの変更を同時に行えるでしょう。しかし、弊社のように導入サポートを行える人材が限られている中で、基幹システムの変更に伴う店舗オペレーションの変更と同時に、品揃えに直結するEDIの変更を行うことは、店舗の混乱を招くだけでしかありません。また、流通BMSを一部導入することによって、その効果が肌身を以て実感していない状態で基幹システムを入れ替えるのは危険であるという思いもありました。実際、他社では、基幹システムの入れ替えに手間取り、これに引きずられる形で、流通BMSの稼働スケジュールが伸び伸びになってしまっているというお話も聞いていたため、なおさらでした。基幹システムの入れ替えは、それだけ全社に与える影響が大きいものと認識しています。

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

おかげさまで、当初立てた予定通りに導入できたと言えます。出荷データ化により、当初想定した通り、伝票入力周りのヒューマンエラーが減少したのは明らかです。ただ、問題がなかったかと言えばそうでもありません。最初のうちは、ちょっとしたヒューマンエラーは多発しました。
まず、「商品マスタ」です。マスターから取り込む商品名称の桁数を15桁と当初定めたのですが、（最近の商品は商品名称の長いものもあり）、商品名称の最後に、「糠（ぬか）の●●漬け」の味種が表記されず、センターでの商品仕分けの際、どの味種の商品をどの店に仕分けて良いのか判断できなかったということがありました。商品は3つ届いているけれど、味種が異なっていて、どの店にどれを届ければ良いかわからず、仕分け作業がもたついてしまった、ということがありました。これについては、システム上の対応、すなわち、商品マスタの桁数の設定変更をすぐに行うことで対応しました。
最もヒューマンエラーらしい、ヒューマンエラーとしては、「Web-EDIの画面操作」です。取引先側としては、2画面操作して操作完了となるところを、最初の1画面だけ操作した時点で操作終了したと勘違いしてしまった一方で、センター側では、いくら待っても出荷データ（ASNデータ）が届かないため焦ってしまう、といったことが当初多発しました。これについては、当運用を開始するに先立ち、お取引先様の各出荷部門担当者様の連絡先を把握していたため事なきを得ましたが、改めてお取引先様のご担当者には操作手順を再度周知を行い、以降同じような操作ミスを防ぐようにしました。
次に、「出荷始まりの対応」です。出荷データを受け取るところから始まる取り組みとしては初めてであったため、何らかの問題が発生すると想定し、欠品情報について、システム導入前と後での比較を行いました。しかしながら、以前からお取引先様より検品状況のリストの提示を受けていたこともあり、稼動前と稼動後の比較結果として特に増減は見られませんでした。ただ、検品時のシステム操作上の課題が出てきました。ほぼ欠品がゼロであることが分かっている商品においては承認操作が煩雑であるため、これが検討課題として挙げられます。鮮魚部門といってもすべてが市場取引によるものではなく、刺身のツマのように惣菜に近い加工品においてはそもそも欠品はない前提で考えて良い商品だと思いますが、これらの商品を画面上で１画面１画面確定するのは煩わしく、一括確定処理ができるような機能があると便利である旨をスマクラ側に伝えた次第です。

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

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

これから流通BMSを導入することを検討していて、ゼロから始めようと考えている企業であれば、次のようなスケジュール感が望ましいと思います。

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

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

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