JP2003242326A

JP2003242326A - 突発事象対応支援システム

Info

Publication number: JP2003242326A
Application number: JP2002043463A
Authority: JP
Inventors: Zenji Sekiya; 善治関谷; Takahiro Chikushima; 隆尋築島; Yogo Koda; 洋吾更田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-02-20
Filing date: 2002-02-20
Publication date: 2003-08-29

Abstract

(57)【要約】【課題】非定常的な事象や突発的な事象へ迅速に対応
し、一時的に破綻した需給バランスを速やかに回復させ
る。【解決手段】突発的に部品の入庫状況や受注情報の変更
が起きた場合、当該変更情報に基づくＭＰＳを複数の緊
急度に対して各々用意し、ＭＰＳ毎にＭＲＰ計算を行
う。各々の部品受払結果を出力し、それらを比較するこ
とにより問題の内容とその緊急度を判定する。また、仮
の対策による救済効果を確認できるよう受払のシミュレ
ーションにより、実際の対策を立案することが可能とな
る。また、設計変更しなければならない状況が発生した
場合、ＰＤＭ等の入力装置から部品表を仮に編集して設
計変更案を作成し、設計変更情報をＳＣＭシステムに渡
して変更を適用した状態でＭＲＰ計算し、出力結果を入
力装置に戻すことにより、事前に設計変更の影響を確認
することが可能とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は生産活動において、
非定常的な事象や事前に予測し得ない突発事象の発生に
対して、迅速かつ低間接工数で適切な対策を打つことを
支援する技術に関する。

【０００２】

【従来の技術】突発事象に対応する業務は通常の業務フ
ローには表現されない業務である。部品メーカーからの
分納や納期延伸依頼があり、かつ、その部材を用いる調
達計画への影響が大きい場合には、請期枠補正が行われ
る。しかし、これはあくまで緊急避難的な第一段階の対
応に過ぎず、最終的な対応に人手が必要となっていた。

【０００３】例えば、特開平１１−２９６５９１には発
生した問題の原因を特定する技術が開示されているが、
その問題による影響度を算出することは不可能であっ
た。

【０００４】また、非定常的な事象の例として設計変更
があげられるが、設計変更による製造や調達への影響を
事前に算出するシステムは存在しなかった。

【０００５】

【発明が解決しようとする課題】突発事象への対応は、
ケース・バイ・ケースの判断が必要であり、業務を定式
化しにくいという特徴を持つ。それゆえ、システムによ
る支援が困難であった。

【０００６】突発事象の原因として、顧客や営業など需
要側から生じるもの、製造現場や取引先など供給側から
生じるものがある。需要側から生じるものとして、・営業からの新規飛び込み受注依頼・既受注案件の注文内容の変更供給側から生じるものとして、・部品の着荷不足、検収後の不良発生・部品メーカーからの分納、納期延伸・設計変更などが考えられる。

【０００７】これらの突発事象は、需要と供給のバラン
スの一時的破綻をもたらす。問題の影響度を人手で算出
するのに、大きな問題が２つあった。１）工数が大きいこと出荷確定数や、既受注数、部品在庫量や、部品の発注残
など必要なデータを各種のシステムからデータを落と
し、受払表を作る。期末など部品在庫を絞ったり、機種
のライフサイクルを迎えると、複数の突発事象が起きや
すくなる上、そもそも日々、受注が入ってきて状況も変
動するため、この表作成工数も大きなものとなる。２）正確な値の算出が困難であることある時点で、受注管理システムや出荷ＤＢなど関連シス
テムからデータを落としてきても、それらシステムのデ
ータ更新タイミングが異なる場合があり、実はデータと
しては異なる時点のものを集めてきていることになり得
るので、それらを使って受払を行っても、まさに１、２
個レベルで足りるか否かが確証を持てない。つまり、ど
れくらい緊急度を要するかは判らない。

【０００８】設計変更の理由としては、不良対策、原価
低減などがある。不良対策の場合はどのみちやらなけれ
ばならないのだが、対策にかかる費用が正確に把握でき
ない、また、原価低減のために設計変更したつもりが、
変更により使われなくなって余った部品の金額が原価低
減により削減した費用を上回り、却って損失を増大させ
てしまうというようなことも無いとは言えない状況であ
った。

【０００９】本発明の目的は、電子商取引によるリアル
タイム化が進展する中で今後増加することが予想される
突発事象へ迅速に対応し、一時的に破綻した需給バラン
スを速やかに回復させることで受注の拡大と経営効率の
向上を図る、あるいは前述したような非定常業務でのミ
スオペレーションによる損失を防ぐことにあり、しか
も、これを低い間接工数で実現することにある。

【００１０】

【課題を解決するための手段】突発的に部品の入庫状況
や受注情報などの変更が起きた場合、それらの変更情報
を反映したＭＰＳ（Master Production Schedule）を複
数の緊急度に対してそれぞれ用意し、各ＭＰＳ毎にＭＲ
Ｐ（Manufacturing Resource Planning）計算を行う。
それぞれの部品受払結果を出力し、それらを比較するこ
とにより問題の内容とその緊急度を判定することが可能
となる。また、仮の対策を打ったとしてどこまで救済で
きるかを直ちに確認できるよう受払のシミュレーション
が行え、対策立案の意思決定を支援する。

【００１１】また、設計変更しなければならない状況が
発生した場合、ＰＤＭ（Product Data Management）シ
ステムなどの入力装置から部品表を仮に編集して設計変
更案を作成し、設計変更情報をＳＣＭ（Supply Chain M
anagement）システムに渡して変更を適用した状態でＭ
ＲＰ計算し、出力結果を入力装置に戻すことにより、事
前に設計変更の影響を確認することを可能にする。

【００１２】

【発明の実施の形態】以下、本発明による突発事象対応
支援システムの実施形態を図面により詳細に説明する。
図１は本発明の一実施形態による突発事象対応支援シス
テムのシステム構成を示す図である。図１の「外部シス
テム」、「外部データベース」の「外部」というのは外
部のシステムであって構わないということであり、必ず
しも外部になければならないということではなく、統合
されたシステムも考えられる。図２は本システムのデー
タ構成の一例を示す図、図１５は本システムを利用する
関係者（部門）の一例である。

【００１３】図３に本発明のシステムを利用した突発事
象対応業務の処理フローを示す。まず、受注管理や調達
などの業務システムから受注情報や部品の入庫情報など
の入力がある（Ｓ３１）。それらの入力を監視し突発事
象発生を検知する（Ｓ３２）。検知した突発事象によっ
て引き起こされる問題の影響度を算出する（Ｓ３３）。
突発事象発生を関係者へ連絡する（Ｓ３４）。その事象
に対する対策の検討材料となる情報を基に対策を立案
し、その対策を実行したとして他に問題が無いかを検証
する（Ｓ３５）。対策が決定したらその対策を実行する
（Ｓ３６）。という流れで進む。

【００１４】図４にＳ３２の突発事象検知の処理フロー
を示す。突発事象の発生は、顧客や営業など需要サイド
から生じるもの、製造現場や取引先など供給サイドから
生じるものがある。これらの情報の第１報が入りうるＤ
Ｂを定期的に監視し、何らかの事象が発生していないか
を自動的に検知する。例えば、部品の着荷不足や検収後
の不良発覚などは、入庫ＤＢへ入力する。発注数量より
も入庫数量が少ない、あるいは不良数量が正の値を取っ
ている、などのデータの入力を定期的に監視することに
より自動的に検知できる。取引先からの納期回答、分納
などの情報は、調達システムより入力される。このよう
な入力の有無をジャーナル（ＪＮＬ）として記録する。
そこで、定期的にこのジャーナルをチェックし、取引先
からの入力がなかったかを監視することにより事象の発
生を自動検知できる（Ｓ４１）。検知した事象は、事象
マスタを検索し内容を特定する（Ｓ４２）。そして、発
生事象ＤＢに事象ＮＯ、事象内容、発生日時を登録す
る。ここまで終了するとＳ３３の問題影響度算出に処理
が移る。

【００１５】図５にＳ３３の問題影響度算出の処理フロ
ーを示す。まず、発生事象ＤＢを検索し、未対策の事象
データが存在しないかどうか調べる（Ｓ５１）。存在し
なければ処理を終了する。

【００１６】需要側の突発事象により、供給側のどの部
品がいつからどれだけ不足するか、逆に供給側の突発事
象により、需要側として、どの計画がいつからどれだけ
不可能になるか、を算出する。

【００１７】需要側で何らかの突発事象が発生した場合
は、新しいＭＰＳやＢＯＭを作り、ＭＲＰの正展開を行
うことで、部品不足の発生の有無、仮に不足が発生する
としてそれがいつかを計算する。不足発生時期が、確定
注文分か予約注文分か見込分かにより、緊急度が異な
る。

【００１８】一方、供給側で何らかの突発事象が発生し
た場合、どれくらい緊急度が高いかを３段階に分けて把
握する。図１６〜１９に示したように、製造台数として
は出荷確定分＜既受注分＜調達計画分である。また、一般的に、直近のものほど出荷日が確定
していて、将来のものほど受注が固まっていない傾向に
ある。図１６では、出荷確定分と既受注分と調達計画分
の３つを重ねて示している。出荷確定分に起きる非定常
事象が最も緊急度が高いものとして扱い、また調達計画
分は、まだ特定の顧客が定まっていない生産予定分であ
るので、非定常事象に対して優先順位を最も低く扱うこ
ととしている。ここで、調達計画分は、当初の計画分で
あり、図１７に示すような全体領域である。また、既受
注分は、受注を受けて当該製品の顧客が定まっている数
量であり図１８に示すような領域である。また、調達計
画分は、既受注分のうち、更に特定顧客に対する出荷日
が確定している生産分であり、図１９に示すような領域
である。これらの３つの領域を重ねて表示すると図１６
のようなグラフになる。

【００１９】最も緊急度が高いのは、出荷確定分だけで
部品を使っても不足する場合である。これは顧客に納期
を約束しているものであり、何とか部品を集められなけ
れば、納期延伸を依頼しなければならない。顧客への納
期延伸依頼は最終手段である。

【００２０】次に緊急度が高いのは、既受注分だけで部
品を使っても不足が発生する場合である。部品が直近で
不足する場合は、まさに１、２個レベルで足りる足りな
いの攻防になる。そこで、ぎりぎりの必要数を算出する
には、出荷確定分と既受注分を区別する必要がある。両
者の間で必要数が異なるのは、受注したものの出荷日が
確定していないという受注案件が存在することによる。

【００２１】最も緊急度が低いのが、調達計画で必要と
した数が不足する場合である。但し、これも前２者と比
べて相対的に緊急度が低いということである。

【００２２】これらの３段階の緊急度に対応して、ＭＰ
Ｓを３種類用意する。そして各ＭＰＳ毎にＭＲＰ計算を
行い、部品受払結果を３種類出力する。一定のタイムテ
ーブルに従って、ＭＲＰ計算用の「入庫予定データ」を
生成し（Ｓ５２）、３種類のＭＰＳに基づくＭＲＰ計算
が一度に３回実行され、その結果として各ＭＰＳに対応
した部品過不足ファイルが出力される（Ｓ５３）。その
ファイルの内容は、問題状況ＤＢに登録される（Ｓ５
４）。どの段階で不足が発生したかを判定することによ
り緊急度を判定し、発生事象ＤＢに登録する（Ｓ５
５）。３種類のＭＰＳは、受注管理システムや出荷ＤＢ
にアクセスして最新の受注／出荷情報に基づいて作成す
る。但し、その場合には、「入庫予定データ」作成時
に、部品在庫情報を同じタイミングのものである必要が
ある。

【００２３】ＭＲＰ計算には、ＭＲＰシステムの”簡
易”版を用いてもよい。この”簡易”の意味は、必要最
小限の部分（変更のあった部分）についてのみ出力する
ということである。ＭＲＰ計算では、数万品目について
数ヶ月分の所要量を出力するところで処理時間の多くを
費やしている。今回、ＭＲＰを同時に３回計算するが、
出力内容を絞ることで全体の処理時間の短縮を図れ、迅
速な対応に寄与できる。

【００２４】事象発生毎にリアルタイムで起動してもよ
いが、部材着荷不足のように、同時の数百の事象が発生
するケースが存在する場合があり、このような場合に
は、複数の事象をあわせて同時にＭＲＰ計算した方が早
い。

【００２５】ここまで終了するとＳ３４の事象発生通知
に処理が移る。

【００２６】図６にＳ３４の突発事象を関係者に連絡す
るフローを示す。発生事象ＤＢから影響度が入力済かつ
未対策の案件を検索する（Ｓ６１）。事象マスタには
「どのケースは誰に連絡すれば良いか」を予め登録して
おく。これを検索し該当する担当者を検索する（Ｓ６
２）。担当者マスタから担当者のメールアドレスを検索
する（Ｓ６３）。検索されたメールアドレスにメールを
送信する（Ｓ６４）。特に緊急度が高い場合は、単に担
当だけでなく、かなり上位のマネージャも含む関係者に
一斉に速報を流すことができる。

【００２７】図７にＳ３５以降の対策立案、決定、実行
フローを示す。関係者が突発事象発生の通知メールを受
信したら、本システムを起動する。問題影響度算出装置
が出力した結果を表示し、発生した事象、影響度を確認
する。Ｓ１５の対策決定支援装置は、最終的な判断は人
が行うが、その判断の基となる情報を提供する。まず、
その時点での最新の品目毎の受払表を関係者が共有す
る。データの内容は、先の簡易版ＭＲＰシステムの計算
結果である。過去の同様な事象の履歴も表示させること
ができる。それらを基に、仮の対策を打ったとして、ど
こまで救済できるかを直ちに確認できるよう、受払のシ
ミュレーションを行う。この場合も簡易版ＭＲＰシステ
ムを用いて処理時間の短縮を図る方法もある。また、時
々刻々と対策が打たれ、状況が変わっていく中で、コミ
ニュケーションを容易にするため、各部署のコメントを
入力できる。対策案が決定したらＳ３６の対策実行支援
装置がＳ１８の制御装置を呼び出して関係するシステム
に対策を反映させる。ここで対策した内容とその日時は
発生事象ＤＢに登録され、今後に生かされる。

【００２８】図２０は算出された緊急度とそれに応じた
対策の例である。

【００２９】以下に、突発事象対応支援システムの画面
例を図面を用いて示す。

【００３０】まず、ログイン画面後、メインメニューが
表示される。Ｗｅｂでシステムを構築する場合はフレー
ム分けしてメニューを常に表示しておくことも考えられ
る。このメインメニューから、「発生事象一覧」、「問
題品目一覧」、「品目受払表」などの画面に遷移するこ
とができる。図２１は画面繊維の例である。

【００３１】図８に「発生事象一覧」の画面例を示す。
「発生事象一覧」とは、現在、どんな突発事象が生じて
いるかの一覧である。既に述べたように、突発事象はシ
ステムが自動的に検知する。まだ対策していない突発事
象を全てここに表示する。本画面は、必要であれば、ロ
グイン時のIDに対応して、発生している突発事象（発生
事象）を選択して表示することもできる。供給側の突発
事象であるので、案件毎に品目コードが一意に決まる。
この品目コードをクリックすると、「品目受払表」画面
へ遷移する。

【００３２】調達部門であれば、取引先コードを入れる
ことで、自分の担当品目に限定して表示することができ
る。品目コードを入力して、表示内容を限定することも
できる。期間での検索も可能。また、出荷確定分の必要
数に対し部材不足が発生している事象のみ、既受注分に
対する不足発生の事象のみ、調達計画に対して不足が発
生している事象のみ等、プルダウンメニューで選択し、
緊急度に応じて表示内容を限定できる。

【００３３】表示される表は、大きく「発生事象状況」
「問題状況」「対策状況」の３つの部分からなる。１）発生事象状況発生した突発事象の事象ＮＯが自動的に採番される。発
生日時、状態（公開／未処理）、品目コード、事象種類
（着荷不足、検収不良など）が表示される。状態とは、
調達部門の初期対応が終わっているか否かである。「未
処理」であれば、そこをクリックすることで、「資材担
当初期見解」画面へ移る。２）問題状況品名コード、問題の種類（どの種類の必要数で部材不足
が発生したか）、発生日（最初に不足した日）、数量
（最初に不足した日の不足量）、累積（最大いくつ不足
するか）、を表示する。出荷確定分の必要数で不足する
場合には、他の必要数でも必ず不足するが、最も緊急度
の高いケースを表示する。品名コードをクリックするこ
とで、「品目受払表」画面へ移る。この「問題状況」の
欄は、事象ではなく、品目としての情報である。従っ
て、異なる事象であっても、同じ品目であれば、後述の
「対策状況」の欄も含め、同じ内容である。３）対策状況その事象の品目に対する最新のコメントを表示する。

【００３４】図９に発生事象が着荷不足、検収不良等の
場合の「資材担当初期見解」の画面例を示す。調達部門
で処理する場合にはその対策案を選び、他部署との協働
作業に入る場合にはコメントを添えることができる。

【００３５】図１０に「問題品目一覧」の画面例を示
す。「発生事象一覧」画面は、事象単位の表示である。
従って一つの品目に対し、取引先の納期回答があり、着
荷不足もあり、検収不良もあれば、３件の突発事象が表
示されることになる。「問題品目一覧」画面は、一品目
一行として、突発事象が１件以上生じている品目を一覧
表示したものである。これも各行毎に品目コードが一意
に決まるので、この品目コードをクリックすることで、
「品目受払表」画面へ遷移する。

【００３６】問題種類や品目コードで選択内容を限定で
きる。表示される表は、「問題状況」「対策状況」であ
る。これは、「発生事象一覧」画面の表のサブセットで
ある。「問題状況」の中の品名コードをクリックするこ
とで、「品目受払表」画面へ移る。

【００３７】図１１に「品目受払表」の画面例を示す。
「発生事象一覧」画面や「問題部品一覧」画面やメイン
メニューからこの画面に移る。「品目受払表」画面は、
現時点でのその品目に対する需要と供給の受払を表示し
たものである。需給バランスが崩れているとは、どこか
の時点で在庫がマイナスになっている状態である。需要
としての必要数は、出荷確定分、既受注分、調達計画分
の３種類を切り換えて、それぞれの場合の受払結果を表
示する。

【００３８】品目コードを直接入力することで表示内容
を切り替えられる。右上の表は、各種類の必要数におけ
る部材不足の概要を表示してある。受払のもととなる消
費種類は、出荷確定分（日別６週間分）、受注残分（日
別６週間分）、受注残分（週別６ヶ月分）、調達計画分
（週別６ヶ月分）、の４種類をプルダウンメニューで選
択できる。これにより、画面下部の受払表の内容が変わ
る。図５の画面には表示されていないが、この受払表の
下に消費予定の内訳を形名毎に分けた表がある。

【００３９】さらに、この「品目受払表」画面には「注
残リスト」、「シミュレーション」、「コメント」、
「事象履歴」の４つのボタンがあり、各ボタンを押せば
それぞれに対応した画面を呼び出すことができる。

【００４０】図１２に「注残リスト」画面例を示す。品
目受払表では、各日もしくは各週の部材必要数の合計が
書いてあり、その下にその部材を使う製品の形名毎の内
訳がある。それらの形名の受注を一覧として見ることが
できる。最悪何件かを納期延伸せざるを得ないときに候
補を探す場合などに使うことが考えられる。図１１の
「品目受払表」で消費種類が「出荷確定分」が選択され
ていると、出荷確定分のリストが表示される。「受注残
分」が選択されていると、既受注分のリストが表示され
る。

【００４１】「受払シミュレーション」では、不足して
いる部材が仮にいつ、いくつ入ると、部材不足の状況が
どう変化するか、シミュレーションを画面上で実行でき
る。確定注文、予約注文、見込のそれぞれに、シミュレ
ーションしたい仮定の数字を入力する。この仮定の数字
通りに部材が入ってきたとして、受払がどう変わるかを
表示できる。

【００４２】図１３に「コメント入力画面」を示す。図
１１の「品目受払表」を見た関係各部門のコメントを入
力する。例えば、受払シミュレーションを使って、生産
計画立案部門や営業部門が、調達部門に対し最低、いつ
までに何個を確保してほしいという要求を書くことがで
きる。

【００４３】「品目受払表」からボタンを押されてこの
ウィンドウが開く。品目コードの欄は、デフォルトで
「品目受払表」の品目が入る。入力部門を選択し、コメ
ント種類として「要望」なのか、「状況報告」なのかを
選択し、コメントを書く。

【００４４】図１４に「事象・コメント来歴」画面を示
す。一つの品目に対し次々と突発事象が発生したら、各
時点で各部門がコメントを加えていく。その来歴を見る
ことができる。

【００４５】図１１の「品目受払表」からボタンを押さ
れてこのウィンドウが開く。品目コードの欄は、デフォ
ルトで「品目受払表」の品目が入る。この品目について
の来歴が時系列で表示される。

【００４６】図１４の例では、以下のことが起きたと想
像される。まず、3/22時点で着荷不足（３０個）という
突発事象が発生し、続けて、3/25には検収不良が発生し
た。その時点では不足数は１０個に減っていた。必要数
が減ったか、とりあえず着荷不足分が届いたと想像され
る。翌3/26には、調達部門から不足分についての納期回
答を3/28にもらう予定とのコメントがあった。同日、生
産計画立案部門から、請期に問題あるので早く対策して
欲しいとの要望がよせられている。翌3/27に取引先から
納期回答があったが、不足数は１２０に増大した。かな
り後倒しの納期回答が返って来た結果、既受注分の必要
数まで不足したと想像される。翌日調達部門から、次回
の部品納入が４月上旬になるという見通しが報告され
た。それを受け、営業部門が大口案件の分納を検討し始
めている。現時点での状況は、右上の表に概要があり、
出荷確定分だけに部材を引き当てても4/10には12個不足
する見込みである。

【００４７】図１３の「コメント入力」を積極的に使う
と、このようにチャット的に関連部門間の協働作業の経
過が残る。上位のマネージャは、どうして現在に至った
かを容易に把握できる。また、このような協働作業は、
各部門のプロフェッショナルが出てきて行なうと想定さ
れるが、まだ経験年数の浅い担当でもこのような記録を
見ることで、いろいろなケースを仮想的に体験すること
が可能である。これは、ある意味で、突発事象への対応
という非定常的計画業務のナレッジということもでき
る。

【００４８】次に、設計変更の影響をシミュレーション
する機能について図面を用いて説明する。図２２は本シ
ステムを利用する関係者（部門）の一例である。設計変
更による影響といっても担当（部署）により知りたい情
報は異なる。本機能では、各部門が協調して設計変更の
適用を検討することに主眼を置き、各部門に合わせた情
報を提供する。

【００４９】図２３は本機能を用いた業務フローの一例
である。設計担当が設計変更情報を入力する。設計者と
しては、いつから設計変更を適用可能か、その日に変更
を適用すると原価はどれだけ下がり、使用しなくなる部
品はどれだけ余ってしまうかを把握したら、生産計画担
当に設計変更情報を送る。生産計画担当は、設計変更が
生産計画に与える影響を確認する。作番（製造番号）ご
とに完了遅れは発生しないか、発生したとすればどの部
品が原因かを確認し、遅れの調整を試みる。より詳細な
設計変更の適用情報を入力してシミュレーションし直す
ことも可能。問題を解決できなければ設計に変更案を戻
し、問題がなければ購買担当に設計変更情報を送る。購
買担当は、設計変更が調達に与える影響を確認する。部
品ごとに追加発注、注残取消の必要が無いかを確認す
る。追加発注、注残取消が間に合わない場合は生産計画
部門に戻して計画の再立案させることも可能であり、間
に合えばそれらを実行し、設計変更案を正式に部品表に
登録し、生産計画は調整後のものに更新する。

【００５０】図２４は設計変更情報を入力する画面の一
例である。製品の構成を示す部品表は部品の親子関係を
ツリー構造で表現する。まず、どの製品に対して設計変
更を適用するか選択する。単純に部品を追加する場合
は、新たに追加する部品（新品目コード）と、その部品
はどの親（親品目コード）に対して何個付随するか（員
数）という情報を入力する。単純に部品を削除する場合
は、削除する部品（旧品目コード）を入力する。部品を
変更する場合は、変更前の部品（旧品目コード）、変更
後の部品（新品目コード）と数量（員数）を入力する。
設計担当はこの程度の入力でよい。親品目コードと旧品
目コードについては、ツリーから選択すると直感的に選
びやすい。１つの設計変更に部品の追加、削除、変更が
同時に複数発生した場合でも、１つずつ入力して追加ボ
タンを押すことにより画面下のリストに入り、リストに
溜まった全ての変更情報を加味したシミュレーションを
実行することができる。生産計画部門は設計が入力した
情報に加えて、有効期間指定なのかランニングチェンジ
なのかといった設計変更の種別、ランニングチェンジな
らば在庫がなくなった時点で適用するのか注残まで考慮
するのかといった方式、有効期間指定ならばその開始日
と終了日を入力して、詳細なシミュレーションが可能。

【００５１】図２５は設計部門向けのシミュレーション
結果画面の一例である。左に設計変更を加味した製品構
成ツリー（ツリーの中でどの部品が追加、変更、削除さ
れたかを色分けして明示することにより視覚的に分かり
やすく表現）、右にその変更を適用することにより旧部
品の余剰額推移グラフと新部品の使用可能日を表す縦線
を示している。この画面から、旧部品が専用部品か共用
部品かを判定する画面（共用部品であれば、他の製品で
も使われるので余っても問題無いが、専用部品であれば
他の製品では使われないので余ってしまうと損失が発生
するので、変更を適用することによる損益を考慮する必
要がある）、部品毎の余剰額や使用可能日をグラフでは
なく表にした画面、作番毎の影響を確認する画面、承認
依頼画面に遷移できる。

【００５２】図２６は生産計画部門向けのシミュレーシ
ョン結果画面の一例である。設計変更により、遅れが発
生した作番の一覧を表示する。もともとの完了予定日と
設計変更を適用すると完了する日を表示する。行を選択
し詳細ボタンを押すと、欠品している部品とその欠品数
の日ごとの推移を確認できる。

【００５３】図２７は購買部門向けのシミュレーション
結果画面の一例である。設計変更により、追加発注や注
残取消の候補となる部品の一覧を表示する。

【００５４】図２８は本機能の処理フローの一例を表し
ている。

【００５５】

【発明の効果】本発明によれば、突発事象へ迅速に対応
し、一時的に破綻した需給バランスを速やかに回復させ
ることで、受注の拡大と経営効率の向上を図れ、また、
ミスオペレーションによる損失を防げ、しかも、これら
を低い間接工数で実現できる。

【図面の簡単な説明】

【図１】システム構成図

【図２】データベース構成図

【図３】システム全体の処理フロー図

【図４】事象検知の処理フロー図

【図５】問題影響度算出のフロー図

【図６】自動通知の処理フロー図

【図７】対策検討、実行の処理フロー図

【図８】発生事象一覧の画面例

【図９】資材担当初期見解の画面例

【図１０】問題品目一覧の画面例

【図１１】品目受払表の画面例

【図１２】注残リストの画面例

【図１３】コメント入力の画面例

【図１４】事象・コメント来歴の画面例

【図１５】プレーヤー構成図（突発事象）

【図１６】生産計画の例

【図１７】調達計画分の生産計画の例

【図１８】既受注分の生産計画の例

【図１９】出荷計画分の生産計画の例

【図２０】緊急度と各部門の対応の例

【図２１】画面遷移例（Web対応版）

【図２２】プレーヤー構成図（設計変更）

【図２３】業務フロー例

【図２４】設計変更情報入力画面例

【図２５】設計部門用評価画面例

【図２６】生産計画部門用評価画面例

【図２７】購買部門用評価画面例

【図２８】処理フロー例

【符号の説明】

Ｓ１１突発事象検知装置Ｓ１２問題影響度算出装置Ｓ１３事象発生通報装置Ｓ１４対策決定支援装置Ｓ１５対策実行支援装置Ｓ１６事象履歴管理装置Ｓ１７データベースＳ１８制御装置

フロントページの続き (72)発明者更田洋吾神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウェア事業部内Ｆターム(参考） 3C100 AA29 BB04 BB05 BB36 BB38 BB39

Claims

【特許請求の範囲】

【請求項１】突発的な、あるいは非定常的な事象によっ
て引き起こされる問題の影響度を算出することを特徴と
するシステムおよびその算出方法。
【請求項２】請求項１に記載されたシステムであって、
突発的な、あるいは非定常的な事象の発生を検知するこ
とを特徴とするシステム。
【請求項３】請求項２に記載されたシステムであって、
検知した事象、算出された問題の影響度を関係者に通知
することを特徴とするシステム。
【請求項４】請求項３に記載されたシステムであって、
対策の立案を支援する情報を提示することを特徴とする
システム。
【請求項５】請求項４に記載されたシステムであって、
立案した対策を仮に実行したとしてシミュレーション
し、実際の対策案を決定する際の意思決定を支援するこ
とを特徴とするシステム。
【請求項６】請求項５に記載されたシステムであって、
決定した対策を実行する手段を有することを特徴とする
システム。
【請求項７】非定常的な事象によって引き起こされる調
達・製造への影響を事前に算出し、各関連部門が協調し
て設計変更の適用時期、方法、その後の対策を決定する
ことを支援することを特徴とするシステム。