ロジビズ :月刊ロジスティックビジネス
ロジスティクス・ビジネスはロジスティクス業界の専門雑誌です。
2001年10号
デジロジ
WMSの設計と導入のポイント

*下記はPDFよりテキストを抽出したデータです。閲覧はPDFをご覧下さい。

OCTOBER 2001 60 従来、物流システムにおい ては運輸管理システムと在庫管理システムが東西横綱のよ うな存在であった。
ところが、 ERP(企業の基幹系システ ム)やサプライチェーンマネ ジメントの考え方が浸透して くるとともに、これらのシス テムに「計画」と「実行」、 とりわけ「マネジメント」の 考え方が重要な概念として組 み込まれるようになってきた。
サプライチェーン・マネジ メント・システムを考える上 で重要な要素技術をやや乱暴 に取りまとめてみるとSCP (サプライ・チェーン・プラン ニング:計画系)とSCE (サプライ・チェーン・エクゼ キューション:実行系)に大 別できる。
このうち前者のS CPは一般に需要予測が代 表と思われているようだが、 実際には資材調達・生産・物流・配送等の 全体スケジュールの計画と制御の最適化が 目的で、需要予測はひとつの要素に過ぎな い。
この計画系については他に譲るとして、今 回は後者。
サプライチェーンにおける物流実 務の実践的なシステムのコアとなるWMSを 取り上げ、基本的な考え方と開発・導入の 田中純夫フレームワークス(旧エクゼ) 社長 WMSの設計と導入のポイント 第7回  既存の作業手順をそのままプログラム化したような旧態依然と した在庫管理・運輸管理システムは、次第に「お呼びでない」状 況になりつつある。
欧米では既にERP導入企業の80%以上が物 流管理にWMSを導入している。
WMSがSCMの必須ツールとな っているのだ。
その導入ノウハウを解説する。
ポイントについて考えてみよう。
WMSの 10 の機能 近年のシステム技術の発展には著しいも のがあり、物流管理においても従来のように 作業の手順をそのままプログラム化したよう な旧態依然とした在庫管理・運輸管理シス テムは、次第に「お呼びでない」状況になり © 61 OCTOBER 2001 のならば7〜 10 が必須になる。
工数のかかるカスタマイズについては、「7 既存システムとの連携プレー」がポイントに なる。
様々な業務を想定して設計されたシ ステムであれば、業務要求に対する適合度 は高いので、本来はカスタム化のための工数 もそれほどかからない。
ところが、そこに既存システムとの接続の 問題が出てくる。
既存システムには企業の歴 史・資産(レガシーと言う。
資産というより は遺産・過去の遺物。
本当はバカにして言 っているのだが‥‥)が反映されているので、 各社各様、ケース・バイ・ケースの対応を 取らざるを得ない。
電気的な接続や信号のやりとり、データ 列びの組み替えなどはもちろんのこと、異な るシステム間のデータ連携では、矛盾のないロジックやフロー設計や追跡がポイントにな る。
これを「インテグリティ(一貫性、正規 性など)」という。
インテグリティへの対応 はエンジニアリングの能力を評価する尺度の ひとつであり、ベンダーやエンジニアを選定 する際の重要な指標にもなる。
パッケージを前提としたWMS導入では、 機能や価格比較よりも、むしろこの部分が コストやスケジュール、後々のメンテナンス に多大な影響を及ぼす。
インターフェースの 設計があやふやであるにもかかわらず、コス トやスケジュールが異常にかさむ場合は要注 意。
もちろん、それ以前に導入側の業務要 求仕様をキッチリしておくことは言うまでも は基本機能の汎用化、マネジメント機能の 充実、および拡張性を考慮した設計となっ ているのが特徴だ。
ちなみに、マテハン機器の制御に比重を置いたものを、特にWCS ( Warehouse Control System )と呼んでい る。
■WMSの主要機能■ 1 正確な在庫管理(は当たり前)と キモを押さえた標準機能 2 複数拠点、複数業務に同時対応 3 ビジネスモデルやワークフローへの柔軟 な対応 4 施設運用・マテハン機器等の制御 5 人的資源のスケジューリング 6 
辧殖董別祇機器)等を活用した作業 進捗のモニタリング機能 7 既存システムとの連携プレー 8 他システムとの柔軟なインターフェース 9 
絅沺璽吋奪函■絅灰沺璽垢悗梁弍 10 モバイルコンピューティング(主にWe b)への対応 「インテグリティ」に注目 これら一〇の機能うち1〜6は、WMS と名乗るのであれば、もはや常識である。
完 成度が高いものであれば、1〜6は「Fi t & Gap(システムと業務の適合性)」 を問題なくカバーするはずだ。
ここに設計上 の問題や機能の欠落があるとすれば、論外 である。
さらにサプライチェーン対応とする つつある。
近年注目を集めているのは、一筆書きで 描くが如く効率の良いルートを組むことので きる配車計画システム、そしてOR(オペレ ーション・リサーチ)や数理計画を活用して 拠点立地問題やネットワークの最適化など を行う全体計画のシステムである。
また、正確な在庫管理はもとより、施設・ 機械・人間などのリソース、そして既存シス テムを効率よく活用するための統合物流管 理システムが注目されている。
これがWMS ( Warehouse Management System )とい われるシステムだ。
欧米ではERP導入企業の八〇%以上が 物流管理にWMSを併用し、WMSのパッ ケージ導入がなかば常識化している。
これに 対して、我が国では未だに自社開発あるい はインテグレーターに作成させた独自システ ムを利用している企業が多い。
その理由として、かつては「我が社は他と 違う」、あるいは「ノウハウを他に公開した くない」などといわれていた。
しかし、最近 では我が国でもグローバル化、オープン化に よる意識改革が進んでいる。
物流システムは ゼロから作るのではなく、購入したほうが良 いし、システムそのものよりも、活用するノ ウハウ(使う技術)がより重要なのだとの認 識が定着しつつある。
WMSの主要機能を以下に列記してみた。
今までのシステムが特定拠点、特定業務や 目的のために開発されたのに対し、WMS OCTOBER 2001 62 反面、モジュールの中身 が見えないため、簡単なものをつくるのにも、あれや これやとモジュールを組み 合わせなければならないし、 チューニングが困難という デメリットもある。
それでも、システムが複 雑化すればするほど、抽 象化による構造の描きや すさ、わかりやすさや、既 存モジュールの可用性な ど、オブジェクト指向には 有り余る利点がある。
効 率の悪さはCPUのパワ ーで補えるので、「ま、い いか」の範囲である。
現 在ではオブジェクト指向ぬ きにシステムを語ることは できなくなっている(図2、 3)。
話を戻そう。
システムの 開発で最初にすべきこと は対象のフレームワーク (全体像の枠組み)を描くことである。
対象 業種、業務、基本機能、オプションの切り分 けなど、ラフなデザイン、というよりはスケ ッチを行う。
留意点としては十分に余裕を持 った、メンテナンスのし易い設計にすること だ。
顧客の要望を取り入れる際には、相反す ない。
オブジェクト指向 余談になるが、学生の頃、マイクロコンピ ュータ(マイコン)が世の中に登場して以来、 学業・趣味・仕事の良き相棒としてコンピュ ータとは二五年以上の付き合いになる。
過去、 幸運なことにほとんどのメーカーのあらゆる システムに触れる機会があった。
現在のようにWindows 一辺倒になる以前 は、メーカーごとにO/Sや開発言語、デー タベース等が特化しており汎用化が面倒であ った。
しかしながら、これらの環境下で受託 開発や専用パッケージ開発などの経験を積み 重ねたことが、最新環境での開発に役立って いる。
はじめて「オブジェクト指向」に触れたの は九〇年頃だった。
当時手にした本が「Tao Of Object (オブジェクト道)」という、武道 書か哲学書のようなものだった。
「オブジェクト指向」は一種のパラダイムシ フトだった。
頭で理解するより、体感してし まえばなんと言うことはないのであるが、汎 用コンピュータや初期のパソコンでCOBOL や FORTRAN 、 BASIC から入った人たちに とっては概念の理解に相当の苦労があったと 思う。
ソフトウェア開発が職人の手による一 品モノからモダンな工業製品に変貌をとげる 過程での話である。
このオブジェクト指向の普及によりシステ ムの全体像は格段に描きやすくなった。
その る要求仕様を盛りこまなければならない。
設 計は意志決定の連続である。
「あれを入れ、 これを切る」も一手だが、切ったものが後か ら復活することもある。
全体を見渡したベス トバランス設計が設計者の腕の見せ所とな る。
この時、導入側としてはIT以前の問題と 63 OCTOBER 2001 して、しっかりしたビジネスモデルと設計・ 導入コンセプト、そして明確な意志をもつこ とが成功の秘訣である。
設計者側では、その 時は理解されなくとも、将来を見越した設計 思想を取り込んだ開発を行うことが大切だ。
設計仕様の解釈には様々な代替案がある。
通 常は性能がそこそこであればコスト・ミニマ ムが求められる。
しかし、開発者のなかにはエンジニアの意 地と言うのか、職人気質が頭をもたげ、他に 真意を理解されぬまま、自らの時間を費やし て「その先」を見据えたものを作り上げてしまうことがある。
これをプログラマーの「良 心」と言うのだそうな。
開発時にはトラブルが続出したが何とか稼 働にこぎ着けた。
その後三年ほどたってから、 「今になって設計真意がわかった。
今見ても 他と遜色がない、むしろすごいシステムだっ たんだね」との評価。
設計者 は我意を得たり、とばかりに ほくそ笑む。
実話である。
「余裕」の必要性とエンジニ アの顔が見える開発が大切、 という例だ。
ところで、一般にシステム 仕様の決定や評価の際には、 機能を羅列し、○×をつけた り、優先順位をつけたりする のだが、数値化が難しく判断 の困難なものが少なくない。
チームで選定するにも、みん な自分の価値基準で判断しよ うとする。
判断基準は複数あ り、互いに利害が反するため、 決定は混迷を増していく。
結 果、時間を掛けたにもかかわ らず、発言権の強い人物の意 見に引っ張られてしまうこと になる。
このような局面で役に立つ 手 法 に 「 A H P ( Analytic Hierarchy Process: 段層分析法)」がある。
階層的構造 による分析手法であり、計量化が難しいもの を評価する際やグループでの意志決定に有効 だ。
これについては章をあらためWMSの選 定を例として解説してみたい。
ビジネスは意 志決定の連続である。
感覚的なものを科学的 に、あいまいなものを明確に、複数の要素・ 価値基準をバランス良く取り込んだ意志決定 を行うための手法として、AHPには学ぶ価 値がある。
導入の勘どころ さて、グランドデザインといえるものがで きあがると、次にプラットフォーム(O/S) や、データベース、開発言語の選定に入る。
データベースは航空機でいうとエンジンに相当する重要な要素だ。
航空機はエンジンの性 能ですべてが制約されるように、システムも データベースがそのシステムの将来を左右す るといって過言ではない。
詳しく言うと、ここでいうデータベースと はプログラムのことではなく、業務実現のた めのデータ構造の定義体のことを指す。
プロ グラムとしてのデータベースは定評のあるも のを購入すれば良い。
どんなデータベースを 使用しているかよりも、業務に適切な構造設 計かどうかのほうが重要なのである。
ちょっとした機能拡張でも毎回データベー ス本体に手を入れなければならないシステム、 あるいは安定した動作が得られないシステム OCTOBER 2001 64 は、基本構造に致命的な問題を抱えていると 考えて良い。
「手練れ」による設計は、この あたりに十分な配慮がなされている。
これも 重要な評価ポイントだ。
納得のいくまで設計 を重ねる、もしくはベンダーからの説明を受 けよう。
業務のフローをプログラム化するロジック や、どの様な言語を使用するか、画面の表現 などは、多少の巧拙はあれ、あまり問題では ない。
実績と市場性のあるものを選択すれば よい。
もともと業務とは日々変化するものな ので、システムもまた不変で有り続けること はできない。
したがって、問題になるのは導 入後のメンテナンスのほうだ。
機能の拡張や 強化、他システムとの連携がいつでもどこで も簡単にできる「しくみ」が重要だ。
新規開発にせよ、他からの購入品にせよ、 初期費用に大差はない。
導入後のビジネス環 境変化へ、迅速かつローコストに対応できる かどうかのほうが、コスト的にも大きな意味 を持つ。
実際、あるシステムを導入したが、 インターフェースや帳票追加などに、数百万 から数千万円かかると言われ、頭を抱えてい るなど、最近はパッケージ導入に伴うメンテ ナンスが重大な問題としてクローズアップさ れている。
ここでは、データベースとともにロジック や画面を構成する「フレームワーク」が重要 になる。
このフレームワークを利用してWM S以外の開発ができるほど洗練された「しく み」を持っているのが良いシステムの条件だ。
必然的に拡張性、柔軟性、接続性、メンテナ ンス性に優れ るということ になる。
設計コンセ プトや開発手 法が重要なこ とはもちろん であるが、物 流の現場は常 に臨戦態勢下 である。
高度 なシステムだ から、難しい、 遅 い 、 高 い 、 問題が出やす い、という言 い訳は通用し ない。
確実で 安定した動作 による高い信 頼性があって こそ、実践的 なSCM構築が実現できるのである。
開発時はもとより、稼働後の性能や品質を 維持するためには、品質管理の考え方が問わ れることになる。
現在、設計開発ツールとと もに品質管理のための良いツールが多数リリ ースされている。
これからは本体システムの 善し悪しの評価だけでなく、各種ツールなど の情報収集と導入、整備、人材教育など、周 辺環境の整備の評価に比重を置くことが肝要 である(図4)。
一九八三年、埼玉大学工学部卒。
物流企業系シス テムハウスを経て、九一年に独立。
エクゼを設立 し、社長に就任。
製造・販売・物流を統合するサ プライチェーンシステムのインテグレーターとし て活動。
九七年には物流管理ソフト「Nexus 」を 開発し、現在は「Nexus ?」にバージョンアップし てシリーズ展開している。
日本企業の物流事情に精通 したシステムインテグレー ターとして評価が高い。
今 年一〇月に社名変更。
田中純夫(たなか・すみお) Profile

購読案内広告案内