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

卸売業の情報システム − 開発体制と手順編

第30回「開発体制と手順(その1)」

消費財卸売業のシステム開発は、平成時代に大きく変わったと考えられます。加工食品や化粧品・日用品の卸売業においては、それらの多くが昭和時代後半の15年間に情報システム開発に着手してきました。その頃の情報システム化の勢いは強く、現在の礎が出来上がった時代といえましょう。少し周辺業界になると、まだ着手できずに部分的なシステム化を行ったに過ぎない企業や急速に普及したパソコンによって割と簡易なシステム化をはかった企業が多くありました。平成に入るとバブルの崩壊がすぐにあり、そこですべての卸売業のシステム化の勢いは弱くなりました。そこから不況に陥り、システムの現状維持や老朽化対応で15年から30年ほど耐え忍ぶ企業がほとんどになりました。しかし卸売業は変化対応こそが真骨頂なので、システム化の進展がのぞまれるようになり、どうにかしてシステムや取引先に対するサービスを進化させようと工夫するように変化してきたのです。
やるべきシステム・サービスをひとつひとつテーマに挙げそれを作ることがしばらくの間、卸売業システムの開発方法の主流になりました。その後中堅・大手の卸売業に基幹システムを再構築する流れも現れて現在に至ります。
卸売業のシステム開発は王道の基幹システム構築と取引環境課題に応じたテーマ別のシステム構築に分類されます。この分類を考慮しつつシステム開発手順と、それに必要とされる開発体制についてカストプラス流にアレンジしてご紹介します。

(1)研究・勉強について
@事例研究
事例を研究することは、大変重要だとわかっていながらも近年では難しいことになってしまいました。それは数十年前と大きく変わって、「他社には見せない!」、「真似されると困る!」という気持ちだけが優先的に継承され、先進事例を持っていると思われる企業を筆頭に見学を申し込んでも断られます。他方で「恥ずかしくて到底他人様にお見せできるものではない!」という理由も断られる理由になっています。
ある業界(カテゴリ単位卸売業)の例では、お互いがよほど親交がある場合を除き、他社の見学申し込みを断り続けてきたので、他社の事例を研究しないことが、当たり前になってしまい進化・進歩の風を感じる経験が消失している企業ばかりになっています。「どうせ見せてはもらえないのだから、申し込むだけ迷惑をかける。」というような感覚になっているのです。そうして20年が経過し、業界全体を見渡してみると、システムやサービスがその場しのぎの対症療法中心に形成されており、進歩ではなくむしろ退歩しているように見えます。特に見かけでよく分かる物流サービスは生産性が低いばかりではなく、精度も危うくコストも多めになっているのです。しかしその企業では先進他社事例を研究せず(もちろん業界紙などで先進的な取り組みを行っている他社の記事を見てはいますが)自社にあてはめて考える習慣を失っているために、危機感や羨望という感情が湧いては来ません。あきらめているようにも見えます。
事例研究は大変重要です。その前に自社のシステムの改善ポイントを明確にしておくことも大切です。改善ポイントをターゲットと定めて、同業他社事例・異業種他社事例・海外企業事例等の中から研究対象を探します。話を聞いたり実際に見せもらうことがかなわないかもしれませんので、業界に通ずる人物と交流するなりしてなんとか意図が伝わるようにします。何度もポイントを伝えつつアプローチしているうちに見せもらえることもあります。業界の真の発展を望んでいる企業であれば、熱心な企業に耳を傾けるはずです。
見学・視察が許されたならば、ターゲットとするポイントをしっかりと見て、帰ってからも十分レビューを行い、その事例を活かせることができるのかどうかを検討していただきたい。その後、更に許されるのであればもう一度先方に伺い、最もシステムを把握されている方にお会いできないかアポイントメントをお願いするということも考えます。
事例研究は、たいしたことがないと思われるかもしれませんが、最も大事な我が社の新システム構築のスタート地点を見つける手段といえるのです。そして見せてもらった直後が肝要なのです。そこで得られた内容をどのように応用するかを連動して検討すべきです。

A応用システムの研究
事例研究や聞いた情報、思いついたアイディアなどを実際の業務に応用してシステム化するためにはどのようなことが必要なのでしょうか?事例から学んだ直後からすべき応用システムの研究について考えてみます。
よくある話として「たくさん見たが、どれが我が社に合うのかさっぱりわからない。」という意見です。過ぎたるは及ばざるがごとく、見すぎてしまって自社でどのように活かしていけばよいかがわからなくなる状態です。よく陥る問題はレビューができていないことかもしれません。見学直後にレビューすべきです。特徴をよくまとめておき、さらに自社での応用の可否についても記録しておきましょう。
また、見たけれども「何がどうなっているのかさっぱりわからなかった。」ということもよくある話です。ポイントは絞っていたのですが、該当企業の仕組みそのものまでには至らなかったというようなことがあります。「結局秘密については何も教えてはくれなかった。」ということかもしれません。その際に解決方法として、再度アポイントをとり「うちの仕組みはこうなっていて、ファイルの項目や処理の仕方、特殊な仕掛けなどをご教授願いたい。」と、今度は自社の情報を出して教えてもらう作戦が考えられます。レベルの違いはあれども、情報交換という形を取るのです。そして、もっと踏み込んで「こういうコンセプトの仕組み・システムを構築したいが、どこをどうすればよいか思案中です。」と伝え、見学先企業の問題点や今後の解決案等までもいただいて、自社の案をブラッシュアップする作戦もあります。
肝心な応用についてですが、方式を見てきた事例企業と同じにすることはありません。機能要素に分類して自社で作るべき/変えるべき要素を見極めます。その結果として想定される直前・直後の業務や周辺・関連業務への影響を精査します。そして得られるメリットやデメリットについてまとめます。



つづく(次回は「開発体制と手順(その2)」です)

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

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

All rights reserved,Copyright2019Custplus Inc.