卸売業向けインストラクションコース

卸売業の情報システム − パートナーの選択編

第26回「環境の変化(その2)」

卸売業の情報システム創りに際して、どのようなパートナーと組むべきかをカストプラス流にアレンジしてご紹介いたします。

(1)環境の変化
近年のコンピュータシステムはオープンシステム化され、十分な期間を経ています。それに伴ってパートナー選びが従来と変わってきています。いままではコンピュータメーカーに直接担当してもらうか、大手コンピュータ販売会社や地元のコンピュータ販売会社またはソフトウエア開発会社に担当してもらうことでシステムの開発ができましたが、これからどうなるか?考えてみたいと思います。

Bマイグレーションの罪悪
よくあるコンピュータのグレードアップ手法に「単純コンバージョン」または「マイグレーション」というものがあります。十数年前まで平成時代初期から長く続いた単純コンバージョンという手法は、機種の違いにかかわらず、いままで動いていたソフトを次の機械でもそっくりそのまま動かすという置き換え方法です。いままでの“従来機=レガシーマシン”同士であればそういったことも成り立つでしょうが、オープン系のコンピュータに置き換えるとなるとそうはいかなくなることが多いのです。マイグレーションは今ではプログラムやデータだけではなくOSやプラットフォームも含めて、従来の環境を次の新システム(主にハードウエアを指します)でも使おうとする考え方になっています。
単純コンバージョンとマイグレーションのどちらも以前のシステムをできるだけそのまま使って新しい機械に移し替えようとするものです。この開発手法を選ぶ理由はいくつかありますが、当初の多くは新規に開発すべき重要コンテンツも見当たらないし、それに費用がかかりすぎるというものでした。そうこうしている間に20年ほど経って、いよいよ新要件(新しいコンテンツ)がバックログとして積もりに積もってきたので、新規開発しようという機運になりました。しかしそれを支えるシステム技術者が20年もの間、商売にもならないノウハウの蓄積とその維持向上を怠らずに(しかもほぼ無料で)やってくれたかというと、それはありませんでした。
実に残念なことに必要と思ったときには、その役割の人はいなくなってしまったのです。当然といえば当然です。レガシーは悪いものではなく知識ベースの蓄積のもとであったのですが、この国では悪いもの/良いものを区別するのが好きなので、古いものは悪いもの、新しいものは良いものという概念が先に出てしまいがちです。本来作られてしかるべきその知識ベースも作られずにノウハウはほとんど消えてしまったのです。かくして今は40年以上前のSE不足よりも深刻なほど、ノウハウのない状態に陥ってしまいました。
最近ではかつての共同配送的な研究テーマがまことしやかに展開されて同じように失敗したり、物流運用の話題で当時盛り上がったことを、若い新人コンサルタントが自分が編み出したかのように(おそらく昔のことを知らずに)提案していたりして、化石の著者としてはゾッとすることがよくあります。
これを何とかするためには長期にわたる改善案しかないのですが、システム規模が小さくても新コンテンツのアプリケーションを開発し続けることだと思います。そして、業界横断的なシステム関連者同士のコミュニケーションを取ることだと思います(それも不況で出張禁止/経費節減/人員削減等の理由で難しくなっていますが努力は大事です)。
卸売業のシステム化は企業規模などによりその方法が大きく異なってきています。それも情報共有しにくい要因かもしれません。下図を参照ください。



C基幹システムの再構築でおこなうべきこと
卸売業は変化対応業であるといわれてきました。変化に対応するというと聞こえは良いのですが、最近の10年以上の間に要望に応えるという感じから、流れに押される対応に変質してしまったような感じになってしまいました。得意先小売業から、どう考えても効率化につながらない合理性のない要望が多く出てくるようになり、システムを少しずつ変更しながら対応してきました。
例えば、発注単位を無視した発注、季節の棚替えに伴う商品の入れ替え多発、得意先企画【専用】商品の限度を超える受け入れ要請、時間ギリギリのASN送信、センター納品遅延【→全店配送】の無協力、リードタイムの先方都合の短縮、専用オリコン・専用カゴ車の増加、ほかがあります。
どれもお互いの効率を追求して決めたことを破った、しかも先方の事実誤認による変更要求であるといえます。発注単位は1個単位になったとしても、それは3の倍数とか5の倍数に縛られると棚割の自由がきかないとする正論の一方、効率を何も考えずに1個売れたら1個発注する(セイルバイワンバイなどといいますが)習慣になってしまいます。毎日1個か2個発注される商品は2日に一度、3日に一度の発注・納品で十分な場合がほとんどです。しかし発注単位ルールを破ってしまったあとはお構いなしになります。最近ではまともな話し合いにも応じないことがあり、無法地帯です。季節の棚替えについても我が国の大問題・課題である、ロスを無くす観点から、自然切り替えに近い変更を目指したいのですが、パッと変えたほうがインパクトがあって売れ行きが良くなるという半分正論を盾にほぼ全品返品して新しい棚割に従って納品する。しかもいっぺんに作業できないから一部は少しずつ変えるという矛盾まであるようです。新商品もJANコードが変わるなら、旧品は全品返品だとする考えが支配的です。そのコストは巡り巡って消費者に回ってきます。一時の作業の省略目的で行われますが、流通全体では損をしています。
この類の話は枚挙に暇がありません。話をもとに戻すと、基幹システムの再構築をおこなう際に我々が抱えてきた過去の受けるべきでなかったサービスが現在ではなくなっていることがよく確認されます。先限とか繰延請求などといっていた処理も、すっかりなくなった卸売業企業では新システムにおいて、その機能をカットしています。
ここで述べたいことは、過去の受けるべきでなかったサービスを総括し、新基幹システム構築の際に機能カットをおこなうべきということです。帳票でも無駄な習慣になっており、実際は活用されていないものを挙げて9割以上発行を止めた卸売業が存在し、のちに業務上何の問題も起きなかった例が多数あります。
古くて、いまではなくなったサービス機能は売掛管理・買掛管理に多く残されています。次に物流の個別対応機能です。受注管理や発注管理、マスタ管理などでも古くて使いもしない機能が沢山残されています。近年では、業界の中での話し合いや情報交換といったものがなくなってきましたので、なくなったことにも気づかず後生大事に残されているのです。それもそのはずで、情報システムの担当者は他社の人とも会うことがないために本当になくなったのかどうかを確認できないからです。またそれを伝道師のように伝える人もほぼ絶滅したのです。
以上が次項以降で解説する「パートナーの選択」が大変重要な鍵になってきたといえる所以です。


つづく(次回は「(2)パートナーの選択と対処方法(その1)」です)

元のページにもどる
トップページにもどる

カストプラスへメールを送ります

All rights reserved,Copyright2019Custplus Inc.