TOCの概要(質問をしよう)

ＴＯＣで変革したら情報システムがボトルネックになる？

日付:2004/09/13

=============================================================
☆質問に答えよう

「ＴＯＣで変革したら情報システムがボトルネックになる？」
=============================================================
大阪の山中さんからのご質問です。

疑問に思うこと、それは、TOC実践の現場にて情報システムは、どうや
って追随していくのだろうか？ということです。

今日、生産管理にしても何にしても管理と名のつくものには、少なか
らず情報システムが関わっているといっても過言ではないと思います。
しかし、TOCはそのシンプルかつパワフルなソリューションを実践する
ために非常に短期間に劇的に考え方そのものを変革するわけですから、
その改革のスピードについていけないものがボトルネックになりかね
ないと思います。

一方、情報システムは、もちろんその規模にもよるのですが、そんな
に急には変革についていけません。ゴールを読んだ時もそうですし、
村上さんの本を読ませていただいた時も、情報システムそのものがど
うやれば変革の足枷にならないのだろか？という疑問が頭から離れま
せん。

実際のところ、情報システムはTOCを実践するにあたってどうあれば良
いのでしょうか？

=============================================================
今回の話題は現在ＧＳＣのメーリングリストでも熱い議論が続いてい
ますが、私なりの経験から意見を申し上げたいと思います。

我々がこのテーマについて議論するためには、情報システムというも
のを定義するところから始めなくてはいけないと思います。

単純にサプライチェーン上の様々な機能を、コンピュータ処理をする
という機能の総称を「情報システム」と呼んでも良いのですが、話を
分かりやすくするために、

?生産計画や資材計画など様々な事前計画に関わる部分を「計画系」
?実際に生産指示や購入業務などのオペレーションをつかさどる部分を
　「統制系」と定義
?その情報を吸い上げ、在庫管理や決算処理などを行う部分を「実績系」

と区分しましょう。

上記の区分は私が勝手に区分しているだけで、モノの本や様々なシス
テムのカタログとは若干違うかもしれません・・・。

要するに、会社の全ての業務は「計画」→「統制」→「実績」という
P(Plan)→D(Do)→S(See)のサイクルで廻っていると考えた方が分かり
やすいと思います。

実際、購買業務は実績系の在庫データと計画系の基準生産計画のデータ
からデータを受け取って購買すべき品目や時期を計算します。
要するに数少ない「鍵となる業務（独立変数）」以外は、ＴＯＣで言
うところの従属業務（従属変数）として、計算されるという事です。

さて、こう考えると従来のＥＲＰなどに採用されている「モジュール」
という考え方はどう捉えたらよいのでしょうか。
「モジュール」は購買や生産計画など個々の業務を切り分けして、そ
れぞれ業種や規模などに応じた、最適なワークフローを提供しようと
いう考え方です。
無論それぞれのモジュール中身は「ＰＤＳ」のサイクルが廻っている
事は言うまでもありません。

私自身感じる、情報システムが「ボトルネック」になるケースはこの
「計画、統制、実績」のサイクルが切れている時です。
これはＥＲＰが導入されていようが、いまいが共通項として挙げられ
ると思います。
ただＥＲＰが導入されている際にやっかいなのは、ＥＲＰのデータシ
ームレスを保証するために、何らかのカスタマイズが行われ「パッチ」
が当てられている場合が多いという事です。

それでは、これを改善するために、コンサルタントとして何をするか
少しお話ししましょう。

まず、導入当初の「計画、統制、実績」の破綻度合いですが、ほとん
どのケースで、実績が実態と乖離しています。
実績管理とは「作業実績」「在庫データ」などのデータ、要するにイ
ンとアウトがタイムリーに記録され、残数が実態と合っているという
事です。
この実績管理がいい加減だと、どんな情報システムを導入しても「絵
に描いた美味しそうな餅」となってしまいますから、注意が必要です。

もしもどうしても在庫精度が上がらないなら、情報システムを空回り
させ、足で稼いだ「実測データ」を当面使用する場合もあります。

次に、ＤＢＲという仕組みを使って、ローカルな統制を行います。
このフェーズでは計画の精度（何を・いくつ・何時までに）はあまり
問題にしません。
なぜならば在庫精度が上がらない状態で、正確な計画が作れるはずが
ないからです。

ここでまた情報システムの「空回り」をさせます。
ここでの空回りは「生産計画」や「調達計画」を自分たちで作るとい
う事です。

ここまで読んで、
「そんな事をしたら、データの精度が益々悪くなり、情報システム
以前の状態に戻ってしまう」
と感じられる方がいるかもしれませんね。

そうではないのです。

「生産計画」や「調達計画」を自分たち作るためにはなにが必要でし
ょうか？

正確な「在庫実績データ」と何を・いくつ・何時までに作るという
「基準生産計画」があれば計画は出来るのです。
不確実なデータを組み合わせて作る計画から、まず実績データを切
り口にして、正しいデータを一つでも入れ込む作業を行うのです。
それでも「基準生産計画」は正しいとは言えませんから、出来上が
った生産計画はまだ不確実性を残しています。
しかしこうやって一つずつデータの精度を上げる取組を積み重ねて
ゆく事は非常に重要です。

さて、ポイントはそこから先です。

こうして作られた、ローカルな管理の仕組みは、消して全体最適を
保証するモノではあありません。
あくまでローカルな最適システムと捉えて良いと思います。

どうやって、ここから全体の最適化を行うのでしょうか？

思い出して下さい、

ＤＢＲの考え方の中で、不確実なモノ同士繋いでゆく時に使うのは
バッファーでした。バッファーとは時間の概念です。
機能間のゆらぎを、バッファー概念で時間余裕を上手入れ込んでコ
ントロールするのです。

たとえば上記の例で言えば、正確な在庫情報×不確実な基準生産計
画＝不確実な生産計画なのですが、その不確実性をバッファーで吸
収してやるのです。その上でバッファー管理を行い、情報の精度を
上げる改善を行い、ゆらぎを吸収してゆきます。

このゆらぎが少なくなれば、機能間の情報はつなぎ目なく（シーム
レス）に流れ始めバッファー管理も不要になります。

これを、次々に繋いでゆけば情報システムは非常にシンプルかつ精
度の高いものになります。

逆に情報システムにどんな素晴らしいコンセプトや高い処理能力が
あっても大元となるデータの精度が低くては宝の持ち腐れとなって
しまいます。
アメリカではＴＯＣを上手にインプリメントした企業では、業務そ
のものが非常にシンプルになり、既存のＥＲＰをほとんどカスタマ
イズすることなく活用出来るという報告があります。

私自身の経験からも、ＴＯＣの適用で業務が非常にシンプルになる
のは間違いがないですし、この報告は納得のいくものです。
そもそもＥＲＰは様々な管理形態からベストなものを提案している
はずです。
従って、ＥＲＰをそのままカスタマイズする事無しに活用出来れば
その効果を最大限享受できることになるのです。


さてそろそろ結論に行きましょう。
ＴＯＣの適用にあたっては、評価の仕方やＤＢＲの適用といった、
あらかじめ変えるべき部分は明らかにしておく必要があります。
しかしそれ以外は、順番にボトルネックになっているデータフロー
を改善する。改善の方向は情報のゆらぎを吸収するバッファ管理を
行う。
いくつかの機能の固まりが出来て「サイクル」が回り出したら、大
きなデータフローをもう一度検討し、デザインする。

こういう方向で改善してゆけば、情報システムがボトルネックにな
る事は無いと思います。

これ以上の情報は、拙著、「在庫ゼロ、ＬＴ短縮、ＴＯＣプロジェ
クト：中経出版」の中のセイコーエプソンの稿をご参照下さい。