コラム・特集

8.6 方法

IEハンドブック
第11部 計画と管理

第8章 ディストリビューションとロジステックス

8.6 方法

デストリビューション・システムを作成するとき,よく見逃される段階はその実施である。分析した者が,次の基本的質問の1つにも答えを出させ得なかったことにより,多くデストリビューション・システムのデザインを実施に移すことは,不可能でないとしてもむずかしいことだ。

1.デストリビューション・システム・モデルの実施に品質と量を含めた必要条件を十分に考慮したか。

2.計算機システムと関連したモデルは十分な対応性が有るか?(というのは,適切な考えを受け入れられる時間内に出すことができるか?)こ の第2間は計画中は重要視されないが,運営上は大変重要である。

3.結果は使用者に理解され信じられるか? 彼または彼女は十分な情報を持っているか,ただし過多ではない。最後にデザインの合理性は確かめられているか? そうして実施のために十分に文章化されているか。

これらの論点について簡単にふれてみる。

必要なデータとその発生源
ディストリビューション・システム・デザインに際して, 1つの忠告をするとすれば ,「データとして必要なことを忘れるな!」ということである。多くの必要なデータの性質,量,品質に対してあまり十分な考慮がなされないために,多くのすばらしいモデルや設計が,採用されず捨てられている。

そこで「必要なデータは手に入るか ? そうならどこにあるか?」 等を考えてみよう。あるディストリビューション・システムのモデルは,ただ費用の資料を出すだけのために多数の経理士を必要としている。モデル・デザインに深入りする前に,資料の源を検査することも必要である。もしいま資料が無いのなら,それを入手するためにどれだけの努力(時間と金)が必要か? モデル・デザインよりも資料集めにもっと費用がかかることもあり得る。

また,モデルにデータを入れなければならないことも, 忘れてはならない。もしも,モデルがコンピュータを使うモデルならば,データはキーパンチされねばならない。もし,もうすでにデータがコンピュータに入っているならば,現在のモデルに利用できるようにしなければならない。ここではデザイナーが望んだ形の資料が入手できなかったり,資料の量があまりにも 多過ぎるからといって,モ デルの中で考慮すべきことを無視せよといっているのではない。またある別なデータソースが取って代われる場合もある 。たとえば1,000人の客に配送するデイストリビューション・システムがデザインされつつあるとする。配送費用の組み合わせとしては(1,000)2=1,000,000 entriesになる。これらの費用の資料は全部どこで集められるか,そうして誰がコンピュータにインプットするのか? この場合,運賃料金の表が手にはいれば,それを代用できる。また,幸運にも,すでにコンピュータのテープに入っていれば,それを代用できる。これは費用の一部分であるかも知れない。

また,この同じコスト・マトリックス問題への解決方法としては,単純に,経費は直線(Euclidean)距離に比例しているのだと仮定することもできる。この場合 x, y,座標で位置を示すので1,000個所を表わすのに2,000のデータを入れればよいことになる。あるポイントをとって,試しに回帰分析を応用してこの関係を求めることもできうる。いつでも,モデル結果に大した影響をあたえない程度に,必要なデータの量を減らすよう,努力することだ。

最後に,必要なデータの品質に注意をはらわねばならない。データはどの程度に正確でなければならないか, という質問には返答しがたいが,しかし,要求される資料品質については,モデル設計過程があまり進行しないうちに,いくらか決定していなければならない。物流システムのデザインを,数段階のデザイン の過程に取りかかってみて,必要な資料に対する品質が得られる。第1段階ではデザイナーまたは分析者は,物流システムのマクロ的モデルの開発をしようとする。それから次の努力の段階はどこであるかを求めるために,このモデルの弾力性と柔軟性の分析をする。

ある大きなコンピュータ会社のスペア・パーツの配送の検討中,社の車の1マ イル当たりの実費はいくらになるかという質問があがったが,答えが得られず,反対にできた物流システムはマイル当たりの率の変化に対して, 敏感に対応できないシステムであったことを判明させる結果になった。

計算能力とコンピュータ資源
モデルの実施に関しては,デザイナーまたは分析者は,コンピュータが利用できるか,または他の計算方法を使用するかを,考えねばならない。使用する手段(機械) に係わりなく,計算努力に深い注意を払わなければならない。計算しやすければ,物流モデルの実行に当たって費やす努力が少なくてすむ。もし大した努力が不要ならば,コ ンピュータを使わずに手計算で十分かも知れない。

もしコンピュータが無いならば,ディストリビューション・モデルは手計算を前提にしてデザインされねばならない。ディストリビューションは,ときには客の位置として地図上のポイント(客の位置)を選ぶので,人間の空間的把握が得意なことを利用することにより(特にモデルの過程を進める前),ある程度の人手による計算は可能である。地図上で境界上の影響を考えること以外は , 人間は,サービス地区における割り当て,たとえば地図の上で複数の客を個々のサービス地区に割り当てる等は 得意である。い ったんこの割り当てが完成されたならば、小さな物流問題は,個々のサービス地区で解決すればよいことになる。

コンピュータ利用できる場合でも,われわれはそのコンピュータを使ってモデルを実施するのに,必要な時間 を認識しておかねばならない。ある東北部の市は,コンピュータ・モデルによる電話による(dial― a― ride) 輸送システムの実行に8時間かかるため,それを諦めた。このダイヤル・システムは日々の発送,計画,そして即時発送の必要な場合には実用的でなかった。

問題の大きさと解決の方法とは深い関係にある。ある大きさの問題を解くのに良い解法でも,他のサイズの間 題解法には効果が無い場合がある。ある大きな鉄道会社のために作られた相互作用発送システム開発には,切替えとdelayの最適解を求めるサブシステムを採用した。1つの方法は最短距離算定のために路線計画法を使った。ミニコン(鉄道システムのような分野では)モデルを実行するのに時間がかかりすぎた。そこでリニア・プログ ラミングは,ついに列挙法 (enumeration)に変えられた。このモデルは,予期された特殊サイズの発送問題の解法には,LP手法よりはるかにすぐれていた。問題が2倍も大きかったなら,最初のモデルのほうが明白に優れていた。この例は,われわれがいつも問題の規模に注意しなければならないことを示している。 コンピュータが用いられているときでさえも,規模を考えることが解決への近道になることがある。

モデル結果のディスプレーとプレゼンテーション
すべてのモデリングと分析の努力は,それが使用者に理解され役に立たなければ無駄である。幹部役員はたびたびコンピュータからのアウトプットに圧倒される。特殊な例ではあるが,ある会社の重役は彼のシステムを動かした結果,毎月コンピュータからの出る資料はおおよそ一寸の厚さになった。あまりにも 多くの情報がアウトプットされるため,彼が意思決定に必要な情報を見つけることができないと思い,そのアウトットはくず籠に捨てられる結果となった。

ディストリビューション・モデルのデイスプレーと紹介の方法は,直接使用者のためにデザインされていなければならない。意思決定者が最終決定をする際に,自ら量的に測れない制約や目標を考慮に入れられるように, 代替案の分析をして,その結果できた案を推薦すべきである。どの意思決定者にとっても,最も役立つ情報はシステムの対応性に関する分析の結果を紹介することである。パラメータ・モデルの多くの値に対して色々試してみる。そこで意思決断者は推薦されたシステムに,道理にかなった範囲内でのパラメータ値の変更ができる,弾力性のあることがわかれば,最終の結果に安心できるであろう。このようにシステムの対応性分析は,またクリ ティカル・システム・パラメータを明確にさせることにも役立つことがわかった。この発見は,すでに数回のレポートが出されていた後であったので,そのエンジニアリング会社は,結果が急に変わった理由を説明するという気まづい仕事をしなければならなかった。

デザイナーがモデル確認にもっと時間をかけるべきである。これには数種の方法がある。

第1.モデルを歴史的情報と照らし合わすこと。どんな食い違いでも,十分な説明がされなければその先の試験とか,実施はすべきでない。

第2.色々な常識的なことと照らし合せる。たとえば, 各品目当たりの平均物流費は道理にかなっているか等。

第3.どのデザインの結果も独立な検査で立証されたか ? これは,そのモデルが使えるであろうと思われるある量の大まかな予測をして,それをモデルに適用してみることによリチェックする。

たいていの会社では,ディストリビューション・システムのデザインが終わった時点で,モ デルと結果が文書化される。人びとは1つのデザインに何力月も何年も働いていると疲れ,推薦されたシステム以外の物は何も文 書化したくなくなる。しかし,この推薦を誰かの机の上にもう1年ほうっておき,それから意思決定者に大事な質問を持ち出させるか,条件の変更をさせてみよう。また,もしもそのシステムの分析者が会社をやめていたならば,情報を取り戻す望みはないであろう。もし分析者がまた在籍していても,彼は多分モデルが何をするか,またどうやってするかのほとんどを忘れているだろう。

われわれの経験から,モデル文書化のたった1つの方法は,しばしばリポートを要求し,こ のリポートの紹介をしてもらい,それを注意深く編集することである。“ ドラフト”と札をつけ,誰かが他のことを思い出したときには,たやすく変更することができるようにする。良い文書化の努力は後にそれだけの価値がある。

 本コラムは絶版となっている「IEハンドブック(サルベンティ編・日本能率協会訳・1986)」をアーカイブとして掲載するものです。このハンドブックの各章は多くの事例と理論を通して生産性向上に対するアイデアを提供するべく専門家によって執筆されています。基盤をなしているIEの考え方・原則はインダストリアル・エンジニアリングにかかわるすべてのひとに有用でしょう。

関連記事一覧

2019ものづくり公開セミナーガイド

B2Bデジタルマーケティングセミナー

ものづくり人材育成ソリューション

マーケティング分野オンラインセミナー