卸売業情報システム第44回

卸売業向けインストラクションコース　　【コンテンツ】

卸売業の情報システム　－　先進情報システム運営の前提条件編

第４４回「メンテナンスについて（その１）」

卸売業にとってのメンテナンスというと設備や備品などの保守維持から商品マスタファイルなどのデータや業務用のプログラムの保守維持、場合によっては機能改善・向上などがあります。
そしてメンテナンス体制というとそれを管理・実行する方々を指します。ここでは自動で動くシステム的なメンテナンスも含めます。
機器・設備のメンテナンスについては我が国の卸売業の場合には、総務や庶務のような部署が事務所の機器と同列でメンテナンスすることが多いようです。規模が大きいと物流機器に関しては物流センター長かそれに近しい担当者が物流機器メーカーなどに保守維持作業を依頼してあとはおまかせという感じです。メンテナンスリースの場合にはリース月額にメンテナンス費用が含まれていますので、機器の販売会社が保守維持のための必要作業の告知と作業の日程調整を推し進めてくれるので、忘れずにメンテナンスすることができます。また機器により法定の保守サイクル・保守内容が定められていますので、しっかり遵守することが大事です。

３．メンテナンスについて

（１）メンテナンス体制
データ管理としてのメンテナンスはコードが付けられて変更等に応じてメンテナンスされます。
社員やその所属に関しては社員コード、部門コード、事業コード、本支店コード、地区コード、国コードなどがあります。
商品に関しては商品コード、商品分類コードなどがあります。
物流センターについては格納ロケーションコード、通路コード、庫内エリアコード、在庫区分コードなどがあります。
作業の区別に関しては処理方式区分コード、指示方式区分コードなどがあります。
お金の移動に関しては取引区分コード、入金種別コード、支払種別コードなどがあります。
勤怠に関しては早出区分コード、日勤区分コード、夜勤区分コード、休憩区分コード、休日出勤区分コードなどがあります。
伝票に関しては売上データ区分コード、仕入データ区分コード、曜日コードなどがあります。
取引先関係では得意先コード、店舗コード、納品センターコード、仕入先コード、工場コード、納品車両区分コードなどがあり、各種コードは数多く設定されます。ここからは商品情報について述べます。

①商品マスタデータ交換について
ⅰ使う瞬間に手元にないと業務を妨げる
商品マスタ情報は業務中いつも使うわけではありませんが、例えばコード化が必要なときまたはコードから商品のことを調べるときに使います。つまり使うときは台帳的な感じではなく自動的に魔法のように結果が現れることを期待します。ところが「使うとき」はかなり広範囲であり、マスタ情報が手元にないと大変な支障をきたすことになります。ですから商品情報の項目は業務全般を把握した上で用意しなければなりません。そして商品の製造元がすべてを理解して情報項目を設定しなければなりませんが、考慮すべきは卸売業や小売業、そして近年では購買者も使うようになってきていることです。作成者（多くの場合はメーカー）から利用者（小売業、卸売業など）、さらに購買者の情報として使われるということです。購買者には特にアレルゲン情報（小麦、蕎麦など）や化学物質情報（RoHS 指令、REACH 規則など）が知りたいと思ったときに正確にわかりやすくする必要性がいわれるようになりました。またIT化が進んできたこともありリアルタイムにそれぞれの企業と同期されることが望まれます。
ここまでは商品ごとの共通情報（関わる全員が共通して活用できる情報）の説明です。次項に共通情報／個別情報について述べます。

ⅱマスタ情報は共通情報と個別情報がある
業務の中には取引価格を示す商品情報もあります。これは売手と買手の組み合わせで相対に定義される個別情報ということになります。これについてはその処理方法によってはマスタデータなのかトランザクションデータなのかが個別に定義されていますので、どちらか一つに決めつけることはできません。しかしここでは便宜的にマスタ情報として分類させていただきました。
この個別情報は共通情報と異なり必要なタイミングを考えなければなりません。共通情報の必要なタイミングとして考えられることは、メーカーが設定する最初のタイミングは商品の発売が決まったときかもしれませんしもっと前の商品開発が決まったときかもしれません。また価格やロジスティクス的な情報はもっとずっと後に決まるのかもしれません。このように徐々に情報が揃って（途中変更もありえます）いくようなリアルタイム同期が望まれるようになるのかもしれませんね。また先程アレルゲンの話に触れましたが、特に化学物質などの規則は半年単位程度で更改されますので追加変更が頻繁に起きるのかもしれません。商品の仕様は無限といっても過言ではないでしょう。一方個別情報の必要なタイミングで考えられることは、相対で決まる情報であっても都度変更されるもの（高頻度の場合もあります）と固定的なものがあるということです。相場変動が激しい商品は単価が後日決まる形が主流ですが、激しく変更されることがあります。どこまでルアルタイムに情報共有できるかがこれからの課題でしょう。
商品情報の別の分類として他にいくつか考えられます。まずpush情報とpull情報という分類があります。作成側と利用側の立場の違いと売りたい方が強いのか買いたい方が強いのかで情報提供の仕方が逆になり得ます。pushとは送り込んだり提案したりする提供の仕方です。逆にpullは問い合わせて取得したり検索して取り込んだりすることです。また全業態共通で使用する項目といった分類もできますし、メーカー・卸売業間の発注・物流だけで使う項目であったり卸売業・小売業間の受注・物流だけで使う項目であったりするのでこれも分類することができるでしょう。

ⅲ日本の習慣がマスタ同期を妨げている
商品情報の課題についても触れておきます。
昨今ではネット販売を中心としたナショナルブランド商品を取り扱う企業が急増しました。しかし正しい商品情報をしっかりと揃えて最終顧客に提供する用意がない企業も参入することもありえます。これはリアル店舗の小売業で商品取り扱いの幅を拡大した場合も同様です。そこに販売力が伴うことになると、しっかりとしたロジスティクスが必要になります。しかし残念ながら商品情報をしっかりと用意することができていないために発注でトラブル含み、ロジスティクスでは納品のたびにトラブルが起き、代金の精算時にはもはや何が正しいのかわからないほどの手間がかかる結果になったりします。しかし提供側がものすごく親切なのでそれを補っているので生産性が悪くで仕方がありません。IT化が進めばなくなっていくと期待します。
また力関係で根拠のない価格設定がオンラインで送られてきて手間がかかるなど先進諸外国では考えられないことが起きるという不思議な状況があります。取引先が未承認の安売りや過剰な値引き競争の結果が給料不足に仮面を被せた人手不足ですね。
こうした課題を都合よく採用するケースもあり、習慣化しマスタ情報の同期を妨げていることもあります。

ⅳバッチ転送だから運用を制限していないか？
バッチ転送は便利なのでしょうか？定番商品とか常時在庫商品は自社のシステムで素早く処理できるようにしたいものです。しかしそうでない商品は情報を使うときが限られています。その情報は多少時間がかかっても業務に支障がないように入手されれば良いのです。IT化が進めば商品情報のうち定番商品や常時在庫商品は自社DBに取り込んでおいてその他はクラウド上のDBを読み込んでほぼリアルタイムに処理ができるようになるでしょう。もっと進めば業界？共通のDBで同期するという考え方になるかもしれません。いまメールが飛び交って成立している、本来企業間ワークフローに仕上げなければならない業務がかなりたくさん残されています。リアルタイムに同期できる範囲が広がってくればとても良い結果になると予想されます。しかしリアルタイムになったら本当に制約がなくなるものなのか？という疑問は残ります。
リアルタイム化により制約が解決しそうなこともあります。その例を挙げます。
最近では商品の若干の仕様変更であれば、すぐ（数週間）に新商品を製造してしまうことが増加しています（急いては事を仕損じるではありませんが）が、肝心の商品情報の同期ができずに工場が出荷を待たされることもあります。『なんのために急いで作ったのだろうか？』といわれます。リアルタイムな同期の仕組みができるようになれば解決するかもしれません。
もう一方では『商品情報をまだ出したくない』タイミングというものがあります。そうはいっても商談は発売の何ヶ月も前から行われます。『できればその季節の当社の目玉商品として電撃発表して販売開始したい！』などと考えますが、リアルタイムに同期する仕組みに載せなければ販売ができません。棚割にも昔ながらの匿名品として載せるしかありません。この課題は後述します。
　兎にも角にもバッチ伝送の制限からは脱却したいものです。

つづく（次回は第２部　３．メンテナンスについて（１）メンテナンス体制 ②商品マスタのメンテナンス　です）