Management Brain Institute

　随分前になるが、あるコンピュータ関連の企業にアドバイザリー契約で行っていた時のことである。
　ちょうど私がいる時に、現在商談を進めている取引先が打ち合わせに来るという。よく聞けば、以前私が商品部を指導していた企業でバイヤーをやっていた人が情報システムの部署に移り、その人が来るという。
　久しぶりの対面でいろいろと話したが、システムの話になると｢とにかくたくさんの画面と帳票が欲しい｣｢何でもいいからたくさん出せて安いのを要望してこいと言われて来た｣という。
　小売業に限らないのかも知れないが、情報システムについての本当の理解がないと、画面も帳票もたくさんあることがよいという、まるで一山いくらで商品の価格交渉をしているような感覚で情報システムを考えているケースがある。
　その裏返しがシステムをつくる側のSEということになるのだろう。Excelのピボットテーブルのように、自由にいろいろな組み合わせができるテーブルを提案する。とにかく、いろいろな手法を調べてきて、それらをメニューに加えようとする。
　結局、｢何でもできる｣というシステムがまともに使えたことがないから、難しいシステムを高いコストをかけてつくり、しかも複雑だから後々メンテナンスも大変なシステムをつくり上げてしまう。
　目的的に考えれば、このような価値観、考えのおかしさがよく分かる。
　情報システムは、どんな形でアウトプットを出したとしても、要するに｢業務で使う｣ことが目的である。
　｢業務の精度を上げる｣｢業務の手間を省く｣というのが主な目的であると考えれば、ベースにあるのは本部であろうが、店であろうが、そこで日常的に行われている｢業務｣に役に立たなければ意味がない。
　本部や店で日常的に行われているルーチン業務、そこで行われる意思決定は、そんなに複雑ではない。
　要するに計画に対してより多く売れたのか、それとも売れてないかのどちらかであるから、至って単純である。
　売れ過ぎれば、予定よりも在庫が少なくなり売り逃しが発生する可能性があるから商品を追加する。追加するにはどの商品をどのくらい追加すればよいかということが分かればよい。
　逆に予定よりも売れなかった場合には、予定よりも在庫が多く残るからどこかで仕入れを減らすなり、値下げをして販売数量を伸ばすことで在庫の調整をする。
　いずれの場合も程度問題で、修正行動が必要な場合ととりあえずは様子を見るという場合に分かれる。
　したがって、とりあえず必要なことは売上、在庫、仕入のバランスを見ることである。仕入のバランスが値入率を決めるし、仕入と売上のバランスが悪ければ在庫のバランスが崩れ、値下を含めて粗利が下がる。
　業務の入口で必要となるのは売上、在庫、仕入、値入、粗利、客数、客単価、買上単価、買上点数であるから、これらが52週間という時系列でどのように進捗しているかが分かれば、とりあえずのことは事足りる。
　全社/全部門、商品部としての全社/部門/ライン/クラス、店長/店部門/店ライン/店クラスなどは同じ帳票の単位違いだから、一つの帳票をドリルダウン、ドリルアップするだけで済む。
　どの単位でも数値の異常を探すには下の単位を見ればよいから、異常値の原因は下の単位の構成比、あるいは前述の売上以下9つの数値のバランスを見れば済む。
　あと必要になるのは商品構成を見るマトリックス(クラシフィケーション・マトリックス;商品特性×商品特性、商品特性×価格　Excelのピボットテーブルでできる)、商品部が見る取引先構成、取引先別値入率、発注/未納率、販売部が見る全社の店別散布図(売上/経常利益)などであるが、これらは定期的に確認する程度で高頻度で見る必要はない。
　要するにたくさんいろいろな帳票が出たとしても、そんなものを見ているだけの時間をとれる部署は少ないし、仮に多くの画面があったとすれば、よほどインターフェイス、操作性をよくしない限り、画面操作に時間ばかり取られて業務効率は著しく低下する。
　業務量分析をしてみれば分かるが、POS導入以降、実に多くのムダなオペレーション(価値を生まない作業時間)が生まれ、本来業務のクオリティを低下させている。
　日常的な業務目的、開発コスト、メンテナンス/更新のコスト・容易性、...など、あらゆることを考えればシステムは単純で扱いやすく、分かりやすいのが一番である。
　
　総合スーパー、食品スーパー、ホームセンター、コンビニエンスストア、ドラッグストア、....等々、様々な業態があるが、要するに商品を仕入れて売っているだけだし、全てのデータの基は仕入伝票に記載されているデータ(取引先名・コード、商品コード・JAN・商品名、売価、原価、数量)がベースだから、標準的なシステムを一つつくりさえすれば、あとはそれらのアレンジで済むはずである。違いがあるのは、生鮮食品の原価法と売価還元という粗利計算間違い、その他商品サイクルやアイテム数くらいである。
　このような筆者の問いかけに対し、長年、大手企業のシステムを支えてきたあるシステムのプロはこのように応えてくれた。
　要求事項さえ、キチンとできていれば標準的なシステムを一つつくれば済むが、各社各様にいろいろな注文を出してくるから、どうしてもそれに合せてカスタマイズをせざるを得ない。第一、標準的なシステム一つで済んでしまったら、これだけの規模の業界、これだけの人数がいるSE、プログラマーを養っていけない。
　まさに、その通りではあるが、そのために様々なロスが生じていると思うと非常に複雑な思いである。
　いっそのこと、標準的なシステムを一つつくり、それに合わせて業務の仕組みも変えてしまえば、非常にローコストで効率的な業務システムができると思うのだが....。