WMSの設計と導入のポイント[デジロジ]：ロジスティクス・ビジネス[LOGI-BIZ]バックナンバー

2001年10号

デジロジ
WMSの設計と導入のポイント

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

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