JP6712934B2 - データ分析装置及びデータ分析方法 - Google Patents

Description

本発明は、各工程についてシミュレーションを行い、事象発生を検知したタイミングで適切な対処をした場合の効果を試算するための技術に関する。

製造業において、短納期で製品を納入することの顧客ニーズが高まっている。また、仕掛品の保管場所を削減したり、キャッシュフローを改善したりという目的からも、納期が短いことは好ましい。このため、特許文献１に示すように、顧客注文（オーダー）に要する工程およびその順序、各工程に要する設備および作業時間（標準時間）などを元に計画を立て、最適化された生産を行う技術に基づき、生産を行うことが各社で試みられている。

特開２０１５−１７６１８９号公報

図１５は、作成されたスケジュールの通りに各工程作業が行われた場合の例を示す図である。この例では、二つのオーダーに応じた複数の工程作業が行われる。具体的には、実線で示すように、１つ目のオーダーに従って、９：００から９：３０まで設備１を使用した工程作業が行われ、次に１０：００から１０：３０まで設備３を使用した工程作業が行われ、最後に１１：００から１２：００まで設備４を使用した工程作業が行われる。さらに、２つ目のオーダーに従って、９：００から１０：００まで設備２を使用した工程作業が行われ、次に１１：００から１２：００まで設備３を使用した工程作業が行われ、最後に１２：３０から１４：００まで設備４を使用した工程作業が行われる。

品種が多い場合やカスタマイズ要求が多い種類の製品、個別設計に近い製品を製造する工場においては、計画の通りに生産が進むとは限らない。工程作業時間の予定外の増加、生産機械のチョコ停、仕掛品の場所の調査、調達品の到着の遅延、ロット廃棄の発生、突発需要の発生などの事象により、当初の計画と実績としての生産の間には乖離が常に一定の確率で生じている。

図１６は、工程作業時間が予定外に増加した場合の例を示す図である。この例では、１つ目のオーダーの、設備３を使用する２つ目の工程作業時間が０．５から１に増加している。単一の設備で複数の工程作業を同時に実行することはできないため、２つ目のオーダーの工程作業のうち、一つ目のオーダーの設備３を使用する工程作業の後で同じ設備３を使用する工程作業のスケジュールにも影響が波及している。

図１７は、生産機械の短時間の停止（いわゆるチョコ停）又は仕掛品の場所の調査等が発生した場合の例を示す図である。この例では、１つ目のオーダーの、２つ目と３つ目の工程作業の間の時間が増加している。このため、１つ目のオーダーの設備４を使用する３つ目の工程作業の開始時刻及び終了時刻が遅延し、その結果、図１６の場合と同様に、２つ目のオーダーの設備４を使用するスケジュールにも影響が波及している。

図１８は、調達品の到着の遅延が発生した場合の例を示す図である。この例では、１つ目のオーダーの、設備１を使用する１つ目の工程作業の着手日時が９から９．５に遅延している。その結果、１つ目のオーダーの２つ目及び３つ目の工程作業に要する時間は増加していないが、それぞれの終了時間が遅延し、その影響が、図１６および図１７の場合と同様に、２つ目のオーダーの設備３及び設備４を使用する工程作業のスケジュールにも波及している。

図１９は、ロット廃棄の発生の例を示す図である。１つ目のオーダーが２つ目の工程作業で止まり、１つ目の工程作業からやり直している。その結果、１つ目のオーダーの２つ目及び３つ目の工程作業の終了時間が遅延し、その影響が、図１６、図１７および図１８の場合と同様に、２つ目のオーダーの設備３及び設備４を使用する工程作業のスケジュールにも波及している。

図２０は、突発需要の発生の例を示す図である。１つ目のオーダーが２回行われている。その結果、１つ目のオーダーの２つ目及び３つ目の工程作業の終了時間が遅延し、その影響が、図１６、図１７、図１８および図１９の場合と同様に、２つ目のオーダーの設備３及び設備４を使用する工程作業のスケジュールにも波及している。

これらの事象は、現場の実績収集の仕組みが、紙の帳票への記入などデジタル化されていなかったり、複数のシステムにまたがって管理されていたりすることで、リアルタイムにスケジュール管理システムに検知されない場合がある。このため、本来は事象発生直後に再スケジュールを行えば設備の稼働効率を上げて遅れを回復できる場合でも、事象発生情報の検知が遅れたために再スケジュールのタイミングも遅れ、いたずらに遅延を拡大させている可能性がある。

しかし、実際に、事象発生の検知が遅れたため、再スケジュールタイミングが遅れたことが原因で遅延を拡大されたか否かは、事象発生を検知したタイミングでの作業時間を見積もることができなければ、判断できない。つまり、事象発生を検知したタイミングで再スケジュールした場合に工程作業をいつ終えることができるか、定量的・正確な見積もりを行うことができなければ、上記のような事象の発生による影響を見積もることができず、適切なタイミングでの再スケジューリングによる波及影響の抑制効果について見積もることができない。さらには、リアルタイムな実績収集の仕組みの効果も判断することができない。

上記の課題を解決するために、本発明のデータ分析装置は、所定の事象が発生する工程を含む作業に対するシミュレーションにおいて、前記事象を発生させるよう設定する事象発生設定部と、事象発生から当該事象発生検知までの時間を示す事象発生検知タイミングを記憶部に記録する事象発生検知タイミング設定部と、前記シミュレーションを実行するシミュレーション実行処理部であって、前記シミュレーションにおいて、前記事象発生を検知した場合には、前記記録した事象発生検知タイミングに従って、当該事象に対する対応を行った場合の前記工程に対する影響を反映させてシミュレーションを実行するシミュレーション実行処理部と、前記シミュレーション実行処理部で実行されたシミュレーションの結果に基づいて、前記工程についての前記事象発生検知タイミングに対するＫＰＩを算出するＫＰＩ算出部と、を備え、前記事象発生検知タイミング設定部は、複数の事象発生検知タイミングを設定し、前記シミュレーション実行処理部は、前記事象が発生した場合、当該事象についていずれの事象発生検知タイミングに従って、前記影響を反映させたシミュレーションを実行させるか特定し、前記特定された事象発生検知タイミングから、前記影響を反映させてシミュレーションを実行する候補日時を示す再スケジュール候補日時を算出し、前記事象が複数発生した場合、第１の事象の第１の再スケジュール候補日時が、前記第１の事象より後に発生する第２の事象の第２の再スケジュール候補日時より後である場合、前記第２の再スケジュール候補日時が示す日時で、前記影響を反映させてシミュレーションを実行することを特徴とする。

本発明の一態様によれば、シミュレーションを行うことによって、実績収集の仕組みの導入の効果を定量的に見積もることができる。上記した以外の課題、構成、及び効果は、以下の実施形態の説明によって明らかにされる。

本発明の実施例に係るデータ分析装置の構成を示すブロック図である。 本発明の実施例の事象パラメタの構成及びデータ例を示す図である。 本発明の実施例の事象データの構成及びデータ例を示す図である。 本発明の実施例の交換可能設備データの構成及びデータ例を示す図である。 本発明の実施例のスケジュールデータの構成及びデータ例を示す図である。 本発明の実施例の工程定義データの構成及びデータ例を示す図である。 本発明の実施例の迅速対象データの構成及びデータ例を示す図である。 本発明の実施例の製造実績データの構成及びデータ例を示す図である。 本発明の実施例のデータ分析装置の処理概要を示すフローチャートである。 本発明の実施例のデータ分析装置が実行する事象発生処理を示すフローチャートである。 本発明の実施例のデータ分析装置が実行するシミュレーション処理を示すフローチャートである。 本発明の実施例のデータ分析装置が実行する再スケジュール予定日時の更新処理の詳細を示すフローチャートである。 本発明の実施例のデータ分析装置が実行する工程作業を着手・完了する処理の詳細を示すフローチャートである。 本発明の実施例のデータ分析装置が出力する情報を説明する図である。 作成されたスケジュールの通りに各工程作業が行われた場合の例を示す図である。 工程作業時間が予定外に増加した場合の例を示す図である。 生産機械の短時間の停止又は仕掛品の場所の調査等が発生した場合の例を示す図である。 調達品の到着の遅延が発生した場合の例を示す図である。 ロット廃棄の発生の例を示す図である。 突発需要の発生の例を示す図である。

以下、添付図面を参照しながら、本発明に係るデータ分析装置の形態例を説明する。後述する形態例及びその説明は一例であり、本発明には様々な変形例が考えられる。

＜システム構成＞
図１〜図２０は、以下で説明する形態例を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表し、基本的な構成及び動作は同様であるものとする。

図１は、本発明の実施例に係るデータ分析装置の構成を示すブロック図である。

データ分析装置は、事象発生を検知したタイミングで未完了の工程について再スケジュールを行った上で工程を実行した場合の、リードタイム等の効果を試算する装置である。データ分析装置は、中央処理装置０１０、データメモリ０２０、プログラムメモリ０３１、製造実績ＤＢ（データベース）０４０、交換可能設備ＤＢ０５０、表示装置０６０、キーボード０７０、及びポインティングデバイス０８０を有する。中央処理装置０１０は、データメモリ０２０、プログラムメモリ０３１、製造実績ＤＢ０４０、交換可能設備ＤＢ０５０、表示装置０６０、キーボード０７０、及びポインティングデバイス０８０と相互接続されている。

中央処理装置０１０は、事象発生処理部０１１、シミュレーション処理部０１２、及び表示処理部０１３を有する。事象発生処理部０１１は、作業時間の増加等の工程進捗に影響を及ぼす事象が、どのオーダーまたはどのオーダーにおけるどの工程で発生するかを決定するものである。シミュレーション処理部０１２は、スケジュール管理システム（例えば、本発明のデータ分析装置がシミュレートする対象の工場等において実際にスケジュールを管理しているシステム）が事象発生を検知したタイミング毎に未完了の工程を再スケジュールして実行した場合の工程完了日時等を見積もるものである。表示処理部０１３は、各々のタイミングで再スケジュールをして各工程を着手完了した場合のリードタイムや納期順守率等を算出し表示するものである。

データメモリ０２０は、中央処理装置０１０の各処理部が、事象を発生させ、シミュレーションを行い、その結果を表示するために用いる各種パラメタおよびデータを格納する。データメモリ０２０は、事象パラメタ０２１、事象データ０２２、スケジュールデータ０２３、工程定義データ０２４、製造実績データ０２５、シミュレーション実績データ０２６、通常事象発生検知タイミング０２７、迅速事象発生検知タイミング０２８、迅速対象データ０２９、及び交換可能設備データ０３０を格納する。

なお、事象発生処理部０１１、シミュレーション処理部０１２及び表示処理部０１３の機能は、中央処理装置０１０がプログラムメモリ０３１に格納されたプログラム（図示省略）を実行することによって実現される。したがって、以下の説明において上記の処理部が実行する処理は、実際には、中央処理装置０１０がプログラムに記述された命令に従って実行する。また、プログラムメモリ０３１及びデータメモリ０２０は、同一の記憶装置であってもよい。また、製造実績ＤＢ０４０及び交換可能設備ＤＢ０５０は、それぞれ、例えばハードディスクドライブ等の記憶装置であってもよいし、同一の記憶装置であってもよい。また、製造実績ＤＢ０４０及び交換可能設備ＤＢ０５０に含まれるデータの少なくとも一部が必要に応じてデータメモリ０２０にコピーされてもよい。

図２は、本発明の実施例の事象パラメタ０２１の構成及びデータ例を示す図である。

事象パラメタ０２１は、シミュレーションで用いられる事象が、どの程度の確率で発生するかを事象の種類毎に定義するとともに、その事象が発生した場合の影響度合いを定義するデータテーブルである。

事象パラメタ０２１はデータフィールドとして、種類２０１、発生確率２０２、影響度合い２０３を有する。

種類２０１は、どのような種類の事象が発生するかを示すフィールドであり、値として“工程作業時間の増加”、“工程着手時間の遅延”、“オーダー着手の遅延”、“オーダーを途中から再実行”、及び“オーダーを最初から再実行”のいずれかを有する。

発生確率２０２は、あるオーダーに対し、その種類の事象が、どの程度の確率で発生するかを定義したフィールドである。なお、各オーダーにおいてどの工程で事象が発生するかはランダムに決定される。

影響度合い２０３は、事象が発生した場合に、その工程及び同一オーダーの他の工程に与える影響を示すフィールドであり、事象の種類ごとに定義される。事象の種類２０１が“工程作業時間の増加”である場合、その事象が発生した場合の工程作業時間が、事象が発生しなかった場合の何倍になるかが定義される。事象の種類２０１が“工程着手時間の遅延”である場合、その事象が発生した場合の前工程の完了と後工程の着手の時間差が、事象が発生しなかった場合の何倍になるかが定義される。事象の種類２０１が“オーダー着手時間の遅延”である場合、その事象が発生した場合のオーダーの最初の工程の着手日時が何時間または何日遅延するかが定義される。事象の種類２０１が“オーダーを途中から再実行”である場合、および“オーダーを最初から再実行”である場合は、そのオーダーにおける他の工程への影響はなく、影響度合いは定義しない。影響度合いは、シミュレーション処理フローのＳ１１０６のステップで工程定義データを更新する際に利用される。本実施形態における事象パラメタの要素数は５である。

なお、上記の“工程作業時間の増加”、“工程着手時間の遅延”、“オーダー着手の遅延”、“オーダーを途中から再実行”、及び“オーダーを最初から再実行”は、それぞれ、図１６から図２０に示した例に対応する。“オーダーを途中から再実行”とは、図１９に示したように、全工程作業が終了していないオーダーの作業を中止して、最初の工程作業から再実行する事象である。“オーダーを最初から再実行”は、全工程作業が終了したオーダーを最初の工程作業から再実行する事象である。

図３は、本発明の実施例の事象データ０２２の構成及びデータ例を示す図である。

事象データ０２２は、シミュレーション対象として用いることを決定した事象がどのような種類であるか、及び他の工程にどのような影響があるかを示すデータテーブルである。

事象データ０２２はデータフィールドとして、種類３０１、オーダー３０２、工程順序３０３、及び影響度合い３０４を有する。

種類３０１は、シミュレーション対象として用いることを決定した事象がどのような種類のものであるかを示す。オーダー３０２は、シミュレーションにおいて事象が発生すると決定した工程作業が、どのオーダー（注文）に対応する作業であるかを示す。工程順序３０３は、当該工程作業が当該オーダーにおいて何番目の工程作業であるかを示す。影響度合い３０４は、その事象が同一オーダーの他の工程に、どの程度の影響を与えるかを示す。

シミュレーション処理部０１２は、製造実績データ０２５から取得した各オーダーの各工程に対して、読み込んだ事象パラメタ０２１の発生確率２０２がシステムによりランダムに発生させた変数と比較して大きいか否かを判断する。発生確率２０２がランダムに発生させた変数より大きい場合、シミュレーション処理部０１２は、その読み込んだ事象が発生すると想定し、事象データ０２２を生成する。事象データ０２２の要素数は、シミュレーションにおいて発生すると想定した事象の数である。

シミュレーション処理部０１２は、生成した事象データ０２２に基づき、シミュレーションを行う。事象データ０２２に基づくシミュレーションの詳細は後述する。

図４は、本発明の実施例の交換可能設備データ０３０の構成及びデータ例を示す図である。

交換可能設備データ０３０は、設備の故障が発生した場合等、その工程を行うために代替して使用可能な設備を示すデータを格納したデータテーブルである。交換可能設備データ０３０は、データフィールドとして、設備４０１を有する。

本データは、シミュレーション処理フローのＳ１１１１ステップ（図１１参照）で、設備の空きを待つために工程進捗が遅れることを防止し最適な再スケジュールを行うために、スケジューラによって参照される。

図４の例は、設備０２と設備０５が交換可能であること、すなわちそれらのいずれを使用しても同じ工程作業を実行できることを示している。

図５は、本発明の実施例のスケジュールデータ０２３の構成及びデータ例を示す図である。

スケジュールデータ０２３は、シミュレーション処理において、その工程で事象が発生するか否かに関わらず、各工程の着手日時及び使用する設備を決定するために用いられるテーブルである。

スケジュールデータ０２３は、データフィールドとして、オーダー５０１、工程順序５０２、予定着手日時５０３、及び予定設備ＩＤ５０４を有する。

オーダー５０１は、シミュレーションが行われる工程作業が、どのオーダーに対応する作業であるかを示す。工程順序５０２は、当該工程作業が当該オーダーにおいて何番目の工程作業であるかを示す。予定着手日時５０３は、シミュレーションにおいて当該工程作業が着手される日時を示す。予定設備ＩＤ５０４は、シミュレーションにおいて当該工程作業を行うこと予定している設備を示す。

その工程において、“工程着手時間の遅延”又は“オーダー着手の遅延”が生じた場合、スケジュールデータ０２３の予定着手日時５０３が更新される。この他、予定着手日時５０３及び予定設備ＩＤ５０４は、シミュレーション処理フローのＳ１１１１ステップで、他のオーダーの各工程との関係を考慮し、より効率的な再スケジュールを行うため、スケジューラによって更新される場合もある。

図６は、本発明の実施例の工程定義データ０２４の構成及びデータ例を示す図である。

工程定義データ０２４は、シミュレーション処理において、各工程の完了日時を算出したり、最適なスケジュールを計算したりするために用いられるテーブルである。

工程定義データ０２４は、データフィールドとして、オーダー６０１、工程順序６０２、作業時間６０３、最早着手時間６０４、及び使用可能設備６０５を有する。

オーダー６０１は、シミュレーションが行われる工程作業が、どのオーダーに対応する作業であるかを示す。工程順序６０２は、当該工程作業が当該オーダーにおいて何番目の作業であるかを示す。作業時間６０３は、当該工程作業を行うのに必要な時間を示す。最早着手時間６０４は、材料の到達時間等に基づき最も早く当該工程作業に着手できる時間は何時であるかを示す。使用可能設備６０５は、当該工程作業を行うために使用可能な設備を示す。使用可能設備６０５に複数の設備が含まれる場合、それらの設備は代替可能である。

工程定義データ０２４は、製造実績データ０２５に基づき、その工程で事象が発生するか否かに関わらず、各々の製造実績データ毎に生成される。工程定義データ０２４は、製造実績の要素数と同数生成されることになる。

図７は、本発明の実施例の迅速対象データ０２９の構成及びデータ例を示す図である。

迅速対象データ０２９は、実績収集の仕組み導入によって事象が発生したことを事象発生直後に検知するケースを判断するための条件を示す。すべての工程についてスケジュール管理システムが事象発生直後に事象発生を検知すべく、すべての工程に実績収集の仕組みを導入することは困難な場合がある。そのため、後の工程に甚大な影響を与える特定の工程又は設備についてのみ実績収集の仕組み導入する場合がある。その場合、その工程についてのみ事象が発生した事実を事象発生直後にスケジュール管理システムが検知することとなる。迅速対象データ０２９は、そのような迅速に事象発生の事実を検知する対象を特定するための条件を示す。

迅速対象データ０２９は、データフィールドとして、オーダー条件７０１、設備条件７０２、及び時刻条件７０３を有する。

オーダー条件７０１は、迅速な検知をすべき対象となるオーダーを示す。設備条件７０２は、迅速な検知の対象となる設備を列挙したものである。時刻条件７０３は、その時間帯で事象発生した場合に検知する対象であることを示す。

図８は、本発明の実施例の製造実績データ０２５の構成及びデータ例を示す図である。

製造実績データ０２５は、ＰＯＰ（Point of Production）システムによって現場で収集された着手日時及び作業時間を、各オーダーにおける工程毎にまとめたテーブルである。

製造実績データ０２５は、データフィールドとして、オーダー８０１、工程順序８０２、標準時間８０３、設備ＩＤ８０４、着手日時８０５、及び完了日時８０６を有する。

オーダー８０１は、実行された工程作業が、どのオーダーに対応する作業であるかを示す。工程順序８０２は、その工程作業がそのオーダーにおいて何番目の作業であるかを示す。標準時間８０３は、その工程作業を行うのに標準的に必要な時間を示す。設備ＩＤ８０４は、実際にその工程作業を行った設備を示す。着手日時８０５は、実際にその工程作業に着手した日時を示す。完了日時８０６は、実際にその工程作業を完了した日時を示す。

製造実績データ０２５は、シミュレーションを行う際に用いられる各工程のスケジュールデータ０２３及び工程定義データ０２４の初期作成において用いられる。

＜システム動作について＞
図９は、本発明の実施例のデータ分析装置の処理概要を示すフローチャートである。

本実施例のデータ分析装置の処理は、作業時間の増加等の工程進捗に影響を及ぼす事象が発生した場合、スケジュール管理システムがその事象の発生を事象発生直後に検知しないケースがあることを考慮し、スケジュール管理システムが事象発生を検知したタイミングで未完了の工程を再スケジュールする等の適切な対応をし、各工程を着手完了した場合のＫＰＩ（Key Performance Indicator、重要業績評価指標）を算出するものである。

データ分析装置の処理概要のフローチャートについて説明する。

まず、製造実績データ０２５が読み込まれる（Ｓ９０１）。後に製造実績のある工程すべてについてシミュレーション処理を行うため、事象発生処理部０１１は、製造実績データ０２５に格納されたすべてのデータを読み込む。

次に、事象発生処理部０１１は、事象パラメタ０２１について、５種類のパラメタすべてを読み込む（Ｓ９０２）。

次に、事象発生処理部０１１は、シミュレーションにおいて、読み込んだ製造実績データ０２５から取得した各オーダーの各工程について、作業時間増加又は着手時間の遅延等の事象が発生するか否かを決定する（Ｓ９０３）。この処理の詳細は図１０を参照して後述する。

次に、シミュレーション処理部０１２が、その決定した事象が発生してから、その事象が発生したことをスケジュール管理システムが検知するまでの経過時間を示す通常事象発生検知タイミングを設定する（Ｓ９０４）。

次に、シミュレーション処理部０１２は、事象発生について実績収集の仕組みを導入した場合の事象発生から事象発生を検知するまでの経過時間を示す迅速事象発生検知タイミングを設定する（Ｓ９０５）。例えば、実績収集の仕組み導入の投資を抑えつつ事象発生による影響を最小限に抑えようとするため、新たに導入した設備についてのみ実績収集の仕組みを導入する場合がある。そのような実績収集の仕組みが導入された工程は、事象発生の事実を迅速にスケジュール管理システムが検知しすぐに再スケジュールすることができるが、それ以外の工程について事象が発生した場合、迅速な検知はされず、例えば事象発生から数時間経過後に事象発生を認識し再スケジュールすることとなる。迅速事象発生検知タイミングを設定することで、実績収集の仕組みを部分的に導入した場合の効果を見積もることができる。このため、迅速事象発生検知タイミングは、通常事象発生検知タイミングと比較して、事象が発生してからそれが検知されるまでの経過時間が短くなるように設定される。

次に、シミュレーション処理部０１２は、シミュレーション処理を行う（Ｓ９０６）。シミュレーション処理は、スケジュール管理システムが事象発生を検知し、検知タイミングに基づき再スケジュールすることを想定する日時毎に行う。その工程が事象発生により影響を受ける工程である場合、事象発生による作業時間の遅延等を加味してシミュレーションを行う。また、事象発生による影響を受けない工程は、当初のスケジュールに基づく工程着手日時や作業時間でシミュレーションを行う。事象発生を検知し再スケジュールする日時経過後は、その時点で未完了の工程について、最適にスケジュールし直した上で（後述する再スケジュール）、スケジュールデータ０２３を設定し、そのスケジュールデータ０２３に基づき、各工程が着手され完了するまでをシミュレーションする。この処理の詳細は図１１〜図１３を参照して後述する。

さらに、シミュレーション処理部０１２は、異なる通常事象発生検知タイミング及び迅速事象発生検知タイミングを設定し、Ｓ９０６のシミュレーション処理を行ってもよい。

次に、表示処理部０１３は、実績収集の仕組みの導入のパターンごとに、例えばリードタイム及び納期順守率等のＫＰＩを算出する（Ｓ９０７）。この処理の詳細は図１４を参照して後述する。

図１０は、本発明の実施例のデータ分析装置が実行する事象発生処理を示すフローチャートである。

事象発生処理は、シミュレーションにおいて実行される各オーダー又は各オーダーにおける各工程について、作業時間の増加又は着手日時の遅延等の事象が発生すると想定できるか否かを判断するものである。判断の結果、事象が発生すると想定したオーダーまたはオーダーにおける工程については、事象の種類３０１、オーダー３０２、及びそのオーダーにおける工程順序３０３毎に、その事象発生による影響度合い３０４を示す事象データ０２２が生成される。

事象発生処理のフローチャートの各処理を説明する。

まず、事象発生処理部０１１は、事象パラメタ０２１を参照し、ある種類の事象パラメタについて、種類２０１、その発生確率２０２、及び影響度合い２０３を読み込む（Ｓ１００１、Ｓ１００２）。

次に、事象発生処理部０１１は、処理の対象のオーダーを設定する（Ｓ１００３）。例えば、初期値として、１つ目のオーダーを示す値“１”が設定される。

次に、Ｓ１００１及びＳ１００２において取得した事象パラメタ０２１の発生確率２０２が、例えばメルセンヌ・ツイスターなどの乱数生成アルゴリズムによってランダムに発生させた０以上１未満の変数以上か否かを判断する（Ｓ１００４）。この処理は、Ｓ１００１及びＳ１００２で読み込んだ事象の発生確率２０２に基づき、シミュレーションにおいて、そのオーダーに対してその事象が発生すると想定できるか否かを判断するものである。すなわち、読み込んだ事象の発生確率２０２と、ランダムに発生させた０以上１未満のランダム変数を比較し、発生確率２０２の方が大きければ、シミュレーションにおいて事象が発生すると判断する。これによって、事象発生処理部０１１は、事象が発生するものと想定されたオーダーまたはそのオーダーにおける工程については、事象データを作成し、後にシミュレーション処理部０１２がこの事象データを用いてシミュレーションを行う。この事象発生処理によって、現実（実態）に近い状況で事象発生を想定することができる。

次に、Ｓ１００４で事象が発生すると判断した場合、事象発生処理部０１１は、読み込んだ事象パラメタの種類が、“工程作業時間の増加”又は“工程着手日時の遅延”であるか否かを判断する（ステップ９０５）。種類２０１が、“工程作業時間の増加”又は“工程着手日時の遅延”である場合、事象発生処理部０１１は、対象オーダー８０１について、製造実績データ０２５から、工程順序をランダムに抽出する（Ｓ１００６）。そのオーダーにおけるどの工程で事象が発生するかを決定するためである。

次に、事象発生処理部０１１は、Ｓ１００２で読み込んだ事象が、Ｓ１００６で決定された工程において発生した場合の影響度合いを事象パラメタ０２１から取得する（Ｓ１００７）。この影響度合いは後のシミュレーションの処理フローにおいて、Ｓ１００６ステップでの工程定義データの更新（例えば作業時間６０３が増加したり、最早着手時間６０４が遅延したりするような事象など）に用いられる。

最後に、事象発生処理部０１１は、シミュレーションにおいて事象が発生すると判断したオーダーについて、発生すると判断した事象の種類、対象オーダー、対象工程及び影響度合いを、事象データ０２２の種類３０１、オーダー３０２、工程順序３０３及び影響度合い３０４に登録する。

事象発生処理部０１１は、１つの種類の事象について、製造実績データ０２５に格納されたオーダーの上限値に達するまでＳ１００４〜Ｓ１００７の処理を繰り返し、オーダーの上限値に達したら、別の事象の種類を設定し、上記と同様の処理を実行する。全てのオーダーと５種類の事象すべてとの全組合せについて上記の処理が終了したら、図１０の処理が終了する。

上記のように、本実施例では、Ｓ９０１で読み込まれた製造実績データ０２５と、Ｓ９０２で読み込まれた事象パラメタ０２１と、に基づいて事象を発生する処理が行われる。これは、製造実績データ０２５がスケジュールデータ０２３の初期値として使用されるためである（後述するＳ１１０２参照）。すなわち、Ｓ９０１は、製造実績データに基づいてスケジュールデータ０２３の初期値を作成する処理であり、Ｓ９０３の処理は、そのようにして作成されたスケジュールデータ０２３の初期値と、事象パラメタ０２１と、に基づいて事象を発生させる処理であると言える。後述するように、製造実績データ０２５によらずにスケジュールデータ０２３の初期値を生成することも可能であり、その場合は、Ｓ９０１において製造実績データ０２５を読み込む代わりにスケジュールデータ０２３の初期値を作成するか、又は既に作成されている初期値を読み込んでもよい。

図１１は、本発明の実施例のデータ分析装置が実行するシミュレーション処理を示すフローチャートである。

本シミュレーション処理は、各オーダー又は、各オーダーにおける各工程で、作業時間の増加等の事象が所定の確率でランダムに発生すると想定し、その事象が発生したことをスケジュール管理システムが検知したタイミングで、未完了の工程について再スケジュールをして、各工程がいつ着手され完了するのかをシミュレーションする処理である。シミュレーションは、再スケジュール前の工程を含め、製造実績のある工程すべてについて行われる。

シミュレーション処理のフローチャートについて説明する。

まず、シミュレーション処理部０１２は、再スケジュール予定日時を初期化する（Ｓ１１０１）。再スケジュール予定日時は、事象が発生したという事実を、スケジュール管理システムが検知し、その検知に基づき、再スケジュールが行われる日時を示す。初期値としては、”９９９９”など無限将来の値を設定する。

次に、シミュレーション処理部０１２は、スケジュールデータ０２３を初期化する（Ｓ１１０２）。スケジュールデータ０２３は、事象が発生すると想定する工程だけでなく、製造実績データとして登録されたデータすべてに対して作成する。作成したスケジュールデータ０２３の値に基づいて、各工程についてシミュレーションが行われる。また、再スケジュールを行う際にもスケジュールデータ０２３の各値が用いられる。スケジュールデータ０２３の初期値は、そのデータフィールドであるオーダー５０１、工程順序５０２、予定着手日時５０３及び予定設備ＩＤ５０４に、製造実績データ０２５のデータフィールド値であるオーダー８０１、工程順序８０２、着手日時８０５及び設備ＩＤ８０４を転記することによって作成される。

上記のように製造実績データ０２５を利用することによって、実際に実行可能なスケジュールデータ０２３の初期値を作成することができる。ただし、上記の作成方法は一例であり、既に説明したように、スケジュールデータ０２３の初期値は、製造実績データ０２５からの転記以外の方法によって作成されてもよい。その場合、Ｓ１１０２では、そのようにして作成された初期値が読み込まれる。また、上記は本発明を工場等の製造業の現場に適用した例であるが、本発明は製造業以外の事業に適用することも可能であり、その場合は、当該事業の作業の実績データに基づいてスケジュールデータ０２３の初期値を作成することもできる。

次に、シミュレーション処理部０１２は、工程定義データ０２４を作成する（Ｓ１１０３）。工程定義データ０２４は、事象が発生すると想定する工程だけでなく、製造実績データとして登録された各々のデータすべてに対して作成される。スケジュールデータ０２３とともに、工程定義データ０２４の各値に基づいて、シミュレーションが行われる。また、最適な再スケジュールを行う際にも工程定義データ０２４の各値が用いられる。工程定義データ０２４のデータフィールドであるオーダー６０１、工程順序６０２及び最早着手時間６０４には、製造実績データ０２５のデータフィールド値であるオーダー８０１、工程順序８０２及び着手日時８０５が転記される。工程定義データ０２４のデータフィールド値である作業時間６０３には、製造実績データ０２５のデータフィールド値である完了日時８０６と着手日時８０５との差が登録される。発明が解決しようとする課題の中で述べた、標準時間が未整備である問題のため、製造実績データ０２５の標準時間ではなく、より信頼性が高いと考えられる完了日時８０６と着手日時８０５との差を用いる。工程定義データ０２４の使用可能設備６０５には、製造実績データ０２５の設備ＩＤ８０４の値に基づき、交換可能設備データ０３０を参照して対応する設備４０１のＩＤが登録される。

次に、シミュレーション処理部０１２は、実績収集仕組みの導入パターンを抽出する（Ｓ１１０４）。これは、実績収集仕組みを導入するための投資を抑えつつ事象発生による影響を最小限に抑えようとするため、事象発生を迅速に認識するため対策（すなわち実績収集の仕組み）を部分的に導入することを想定したものである。実績収集仕組みを部分的に導入するパターンの例として、新しく導入した設備に対してのみ実績収集仕組みを導入する、大口顧客のオーダーに対応する仕掛品に関する工程に事象が発生した場合のみタグ等によって管理する、又は、定期的に所定の時間帯に発生した事象を報告する運用をする、といったパターンが挙げられる。実績収集仕組みをどの程度（すなわちどの部分に）導入することで効果を発揮するかを定量的に確認できるようにするため、シミュレーション処理部０１２は、Ｓ１１０５〜Ｓ１１１３のシミュレーション処理を、複数の実績収集の仕組み導入のパターンのそれぞれについて行う。実績収集仕組みの導入パターンは、迅速対象データ０２９から抽出される。

次に、シミュレーション処理部０１２は、変数Ｄａｔｅを初期化する。（Ｓ１１０５）。変数Ｄａｔｅは、シミュレーションにおける現在時刻（シミュレーション現在時刻）に相当する。Ｄａｔｅ（シミュレーション現在時刻）は、その時刻において、その工程が完了しているか否か、その時刻は工程着手時間であるか、その時刻はスケジュール管理システムが事象発生を検知し再スケジュールを行う時刻であるか、を判断するために用いられる。シミュレーション処理部０１２は、初期値としてＤａｔｅ＝０を登録する。シミュレーション処理部０１２は、あるＤａｔｅ（シミュレーション現在時刻）に対して、Ｓ１１０２で取得済みのすべてのスケジュールデータについて以降の処理（Ｓ１１０６〜Ｓ１１１３）である事象発生によるスケジュールデータ０２３及び工程定義データ０２４の更新、再スケジュール、及び各工程の着手完了を実施し、その後、Ｄａｔｅ（シミュレーション現在時刻）をインクリメントし、同様にＳ１１０２で取得済みの残りすべてのスケジュールデータについて以降の処理を行うことを繰り返す。

次に、シミュレーション処理部０１２は、あるＤａｔｅ（シミュレーション現在時刻）において、各スケジュールデータ０２３に対して、その時刻に図９で決定した想定事象が発生するか否かを判断する（Ｓ１１０６）。Ｄａｔｅ（シミュレーション現在時刻）が、その事象が発生すると想定する工程の予定着手日時５０３に到達していれば、その時刻に事象が発生すると判断される。すなわち、シミュレーション処理部０１２は、事象データ０２２から、事象が発生すると想定する工程のオーダー３０２及び工程順序３０３を取得し、スケジュールデータ０２３を参照し、取得したオーダー３０２及び工程順序３０３と一致するオーダー５０１及び工程順序５０２を有するスケジュールデータ０２３を抽出する。

発生を想定する事象の種類３０１が“工程作業時間の増加”または“工程着手日時の遅延”または“オーダー着手の遅延”である場合、抽出したスケジュールデータ０２３の予定着手日時５０３がＤａｔｅ（シミュレーション現在時刻）と等しければ、その時刻にその想定事象（工程が遅延する事象）が発生すると判断される。発生を想定する事象の種類３０１がそれ以外である場合、すなわち“オーダーを途中から再実行”又は“オーダーを最初から再実行”である場合、スケジュールデータ０２３の予定着手日時５０３と工程定義データ０２４の作業時間６０３との和がＤａｔｅ（シミュレーション現在時刻）と等しければ、その時刻に、その想定事象（オーダーを再実行する必要性を引き起こす事象）が発生すると判断される。“オーダーを途中から再実行”又は“オーダーを最初から再実行”が発生する例としては、作業途中の物品を完全に破損してしまい作り直しになったり、作業途中の物品と同じ種類の物品が緊急に他用途でも必要となり追加で製造する必要が生じたりするなどがある。

次に、シミュレーション処理部０１２は、工程定義データ０２４を更新する（Ｓ１１０７）。工程定義データ０２４の更新は、事象発生によって生じた作業時間の増加及び最も早く工程に着手できる日時の変更を反映させるものである。したがって、そのＤａｔｅ（シミュレーション現在時刻）において、事象が発生すると判断した工程について、その工程に対応する工程定義データ０２４のみ、事象の種類に応じた更新処理が行われる。すなわち、シミュレーション処理部０１２は、発生する事象の種類３０１が“工程作業時間の増加”だった場合、作業時間を増加する。種類３０１が“工程着手日時の遅延”だった場合、最早着手時間６０４を遅らせる。種類３０１が“オーダー着手の遅延”だった場合、そのオーダーの最初の工程順序における最早着手時間６０４を遅らせる。種類３０１が“オーダーを途中から再実行”だった場合、新しいオーダーの工程定義データを工程ごとに作り、オーダーの値を含め元のオーダーのデータを新しい工程定義データに転記し、元のオーダーの実行済みの工程以降の工程順序のデータを削除する。種類３０１が“オーダーを最初から再実行”だった場合、新しいオーダーの工程定義データを工程ごとに作り、オーダーの値も含め元のオーダーのデータを新しい工程定義データに転記する。

次に、シミュレーション処理部０１２は、スケジュールデータ０２３を更新する（Ｓ１１０８）。スケジュールデータ０２３の更新は、事象発生によって生じた“工程着手時間の遅延”、“オーダー着手時間の遅延”又は“予定設備の変更”を反映させるものである。したがって、そのＤａｔｅ（シミュレーション現在時刻）において、事象が発生すると判断した工程に対応するスケジュールデータ０２３についてのみ事象の種類に応じた更新処理が行われる。すなわち、シミュレーション処理部０１２は、発生する事象の種類３０１が“工程着手日時の遅延”だった場合、予定着手日時５０３を遅らせる。“種類３０１が“オーダー着手の遅延”だった場合、そのオーダーの最初の工程順序における予定着手日時５０３を遅らせる。種類３０１が“オーダーを途中から再実行”だった場合、Ｓ１１０６で新たに作成した工程定義データに対応するスケジュールデータ０２３を新たに追加する。

すなわち、シミュレーション処理部０１２は、現在着手している工程作業の完了日時の直後に、工程順序１の工程作業に着手し、その後の工程作業にも順次着手するようにスケジュールデータ０２３に要素を追加し、また追加要素の予定着手日時を設定する。シミュレーション処理部０１２は、種類３０１が“オーダーを最初から再実行”だった場合、Ｓ１００６で新たに作成した工程定義データに対応するスケジュールデータ０２３を追加する。すなわち、シミュレーション処理部０１２は、現在着手しているオーダーの最後の工程順序の完了日時の直後に、工程順序１の工程作業に着手し、その後の工程作業にも順次着手するようにスケジュールデータ０２３に要素を追加し、また追加要素の予定着手日時を設定する。

以後のシミュレーションは、Ｓ１１０７で更新された工程定義データ０２４及びＳ１１０８で更新されたスケジュールデータ０２３を参照して実行される。これによって、発生した事象の影響が以後のシミュレーションに反映される。

次に、シミュレーション処理部０１２は、再スケジュール予定日時を更新する（Ｓ１１０９）。

再スケジュール予定日時は、事象が発生したという事実を、スケジュール管理システムが検知し、その検知に基づき再スケジュールする日時を想定したものである。再スケジュール予定日時更新処理については、図１２のフローチャートを用いて詳細に説明する。

次に、シミュレーション処理部０１２は、再スケジュールするか否かを判断し（Ｓ１１１０）、再スケジュールをすると判断した場合、再スケジュールを行う（Ｓ１１１１）。再スケジュールを行うとは、そのＤａｔｅ（シミュレーション現在時刻）において、未完了のスケジュールデータ０２３について、予定着手日時５０３と予定設備５０４を最適な値に更新することを意味する。すなわち、シミュレーション処理部０１２は、あるＤａｔｅ（シミュレーション現在時刻）が再スケジュール予定日時と一致するか否かを判断する。一致する場合に、そのＤａｔｅ（シミュレーション現在時刻）はスケジュール管理システムが事象発生を検知するに至ったタイミングであるとして、シミュレーション処理部０１２は、そのＤａｔｅ（シミュレーション現在時刻）において未完了のすべてのスケジュールデータ０２３について、予定着手日時５０３及び予定設備ＩＤ５０４を最適な値に更新する。予定着手日時５０３、予定設備ＩＤ５０４の最適な値への更新は、他のスケジュールデータ０２３及び工程定義データ０２４基づき、予定設備及び代替設備の有無、並びに、オーダー及び工程の入れ替えを考慮して行う。なお、シミュレーション処理部０１２は、既存のスケジューラ（例えば、本実施例のデータ分析装置がシミュレートする対象の工場等において使用されているスケジューラ等）にスケジュールの更新処理を実行させてもよい。

次に、シミュレーション処理部０１２は、工程作業を着手し、完了する（Ｓ１１１２）。工程作業着手・完了処理は、Ｄａｔｅ（シミュレーション現在時刻）が、スケジュールデータ０２３の予定着手日時に到達している場合、その工程作業の着手から完了までのシミュレーションを行う処理である。工程作業を着手・完了する処理については、図１３のフローチャートを用いて詳細に説明する。

シミュレーション処理部０１２は、Ｄａｔｅ（シミュレーション現在時刻）をインクリメントして（Ｓ１１１３）、Ｓ１１０６以降の処理を実行する。例えば、シミュレーション処理部０１２は、Ｄａｔｅ（シミュレーション現在時刻）に対応するスケジュールデータが存在する限り、Ｓ１１０６〜Ｓ１１１３を繰り返し実行してもよい。

さらに、シミュレーション処理部０１２は、Ｓ１１０２〜Ｓ１１１３の処理を、実績収集の仕組みの導入パターンごとに行う。

図１２は、本発明の実施例のデータ分析装置がＳ１１０８において実行する再スケジュール予定日時の更新処理の詳細を示すフローチャートである。

再スケジュール予定日時は、スケジュール管理システムが事象が発生したことを検知し、その検知に基づき再スケジュールを行う日時である。

本実施例においては、事象が発生したという事実を検知し再スケジュールを行うタイミングについて、Ｓ９０４において通常事象発生検知タイミングと迅速事象発生検知タイミングが設定される。その設定した通常事象発生検知タイミングまたは迅速事象発生検知タイミングに基づき、再スケジュール予定日時が更新される。通常事象発生検知タイミングは、実績収集の仕組みを導入しない場合のリードタイム等のＫＰＩを見積もるために用いられる。たとえば、事象発生から５時間後にスケジュール管理システムが事象発生を検知し再スケジュールを行う場合、事象発生から５時間後の日時、すなわち、Ｄａｔｅ（シミュレーション現在時刻）に５時間を加算した日時が、更新後の再スケジュール予定日時となる。なお、再スケジュール予定日時は、Ｓ１１０５で、Ｄａｔｅ（シミュレーション現在時刻）において想定事象が発生すると判断した場合のみ更新される。事象が発生しなければ、シミュレーション処理部０１２は、再スケジュールする必要がないため更新は行わず、現状のスケジュールデータ０２３を用いてシミュレーションを行う。

また、実績収集の仕組みを部分的に導入した場合の効果を見積もるため、シミュレーション処理部０１２は、通常事象発生検知タイミングと迅速事象発生検知タイミングのいずれかを用いて再スケジュール予定日時を更新する。たとえば、実績収集仕組みの導入の投資を抑えつつ事象発生による影響を最小限に抑えようとするため、新しく導入した設備のみ実績収集仕組みを導入する、大口顧客のオーダーに対応する仕掛品に関する工程に事象が発生した場合のみタグ等により管理する、又は、定期的に所定の時間帯に発生した事象を報告する、といった仕組みを導入する場合がある。そのような部分的な実績収集仕組みを導入する場合は、特定の事象については事象発生の事実を迅速にスケジュール管理システムが検知しすぐに再スケジュールすることができるが、それ以外の事象が発生した場合、迅速な検知はされず、事象発生から数時間経過後に事象発生を検知し再スケジュールすることとなる。通常事象発生検知タイミングと、迅速事象発生検知タイミングの２種類のタイミングを用いることで、部分的に実績収集仕組みを導入した場合であっても適切なシミュレーションを行うことができる。

再スケジュール予定日時の更新処理のフローチャートについて説明する。

まず、シミュレーション処理部０１２は、Ｓ１１０６における、事象データのオーダーと工程順序とを用いて、スケジュールデータから該当行を探す処理によって得られたスケジュールデータ０２３の、オーダー５０１及び予定設備ＩＤ５０４を取得する（Ｓ１２０１）。

次に、シミュレーション処理部０１２は、事象が発生した工程について、迅速対象データ０２９を参照し、迅速対象か否かを判断する（Ｓ１２０２）。たとえば、シミュレーション処理部０１２は、Ｄａｔｅ（シミュレーション現在時刻）が、迅速対象データ０２９の時刻条件７０３の条件を満たすか否かを判断してもよい。これは、リアルタイムな実績収集仕組みの導入が困難な場合に、バッチ収集システムの導入及び運用によって、特定の時間帯に定期的に事象発生の事実を検知する場合を想定したものである。あるいは、シミュレーション処理部０１２は、予定設備ＩＤ５０４が迅速対象データ０２９における設備条件７０２に含まれるか否かを判断してもよい。すべての設備に実績収集の仕組みを導入するコスト負担から、新しい設備等一部の設備に対してのみ、実績収集の仕組みを導入する場合を想定したものである。あるいは、シミュレーション処理部０１２は、取得したオーダー５０１が迅速対象データ０２９におけるオーダー条件７０１に含まれるか否か判断してもよい。これは、大口顧客又は納期期限に厳しい顧客等、特定の顧客のオーダーに対応する仕掛品に関する事象発生のみ迅速検知する場合を想定したものである。

次に、事象が発生した工程が迅速な検知対象となる条件に含まれる場合（Ｓ１２０２：Ｙｅｓ）、すなわち、発生した事象の時刻条件、設備条件及びオーダー条件が、迅速対象データ０２９に含まれるいずれかの条件を満たした場合、シミュレーション処理部０１２は、事象発生検知タイミングに、迅速事象発生検知タイミングを設定する（Ｓ１２０３）。

一方、事象が発生した工程が迅速な検知対象となる条件に含まれない場合（Ｓ１２０２：Ｎｏ）、シミュレーション処理部０１２は、事象発生検知タイミングに、通常事象発生検知タイミングを設定する（Ｓ１２０４）。

なお、すべての工程を対象として実績収集の仕組みを導入した場合は、事象発生検知タイミングとして、迅速事象発生検知タイミングのみ用いる。

次に、シミュレーション処理部０１２は、現在設定されている再スケジュール予定日時が、Ｄａｔｅ（シミュレーション現在時刻）に事象発生検知タイミングを加えた値より将来であるか否かを判断する（Ｓ１２０５）。現在設定されている再スケジュール予定日時が、Ｄａｔｅ（シミュレーション現在時刻）に事象発生検知タイミングを加えた値より将来である場合、シミュレーション処理部０１２は、再スケジュール予定日時を、Ｄａｔｅ（シミュレーション現在時刻）に事象発生検知タイミングを加えた値で更新する。（Ｓ１２０６）。

例えば、２つの事象が発生することが想定されるシミュレーションにおいて、先に発生した１つ目の事象が迅速対象でなく、その再スケジュール予定日時が「午後３時に事象発生に気付き、再スケジュールを行う」となっており、Ｄａｔｅ（シミュレーション現在時刻）が午後２時で、２つ目の事象が迅速対象であり再スケジュールタイミング使用値が０（事象発生直後）であった場合、「午後２時に事象発生に気付き、再スケジュールを行う」という予定が新しく追加されたということを意味する。この場合、午後２時にスケジュール管理システムが事象発生を検知し再スケジュールを行えば、既に発生している１つ目の事象も考慮した際スケジュールが行われるため、午後３時にスケジュール管理システムが事象発生を検知して再スケジュールを行うという想定は必要ない。このため、シミュレーション処理部０１２は、再スケジュールの予定を、「午後２時に事象発生に気付き再スケジュールを行う」という予定に更新する。

結局、ある事象（第１の事象）が発生してからそれが検知されるまでの間に、別の事象（第２の事象）が発生した場合、それらのいずれかが先に検知された時点で再スケジュールが行われ、もう一方が検知された時点では再スケジュールが行われない。例えば、第２の事象が先に検知された場合、その時点で再スケジュールが行われ、第１の事象が検知された時点での再スケジュールは行われない。これによって、不要な再スケジュールの実行が省略される。

図１３は、本発明の実施例のデータ分析装置がＳ１１１１において実行する工程作業を着手・完了する処理の詳細を示すフローチャートである。

工程作業を着手・完了する処理は、事象発生の対象工程、事象発生によって影響を受ける工程、及び、事象が発生しても影響を受けない工程のすべてについて行われる。事象発生の対象工程及び事象発生によって影響を受ける工程の場合、その影響を勘案して各工程を着手し完了するまでのシミュレーションが行われる。また、再スケジュールする以前及び再スケジュールした後ともにシミュレーションが行われる。ただし、再スケジュール後は、Ｓ１１１０において、最適に再スケジュールした後、シミュレーションが行われる。

工程作業の着手・完了のフローチャートについて説明する。

シミュレーション処理部０１２は、未完了の各スケジュールデータ０２３について、Ｄａｔｅ（シミュレーション現在時刻）が予定着手日時５０３に至っているか否か、つまり、Ｄａｔｅ（シミュレーション現在時刻）が予定着手日時５０３と等しいか否かを判断する（Ｓ１３０１）。Ｄａｔｅ（シミュレーション現在時刻）が予定着手日時５０３と等しければ、次に、シミュレーション処理部０１２は、予定設備ＩＤ５０４が利用可能か否かを判断する（Ｓ１３０２）。利用可能か否かの判断は、予定設備が前工程で現在使用中であるか否かに基づいて判断する。具体的には、スケジュールデータ０２３において、予定設備ＩＤ５０４が一致するデータの中に、予定着手日時がＤａｔｅ（シミュレーション現在時刻）以前のものがなければその設備は利用可能と判断される。Ｓ１３０７で説明するように、既に完了した工程のスケジュールデータは削除されるため、この処理方法によって設備の利用可否を判断することができる。予定設備５０４が利用可能であると判断した場合、次に、シミュレーション処理部０１２は、そのオーダーにおける前の工程が完了しているか否かを判断する。具体的には、オーダーが同じで工程作業順序が一つ前のスケジュールデータ０２３が存在していなければ、前の工程は完了していると判断できる。

次に、シミュレーション処理部０１２は、Ｓ１３０１〜Ｓ１３０３において、Ｄａｔｅ（シミュレーション現在時刻）が予定着手日時５０３に至っており（Ｓ１３０１）、予定設備が利用可能であり（Ｓ１３０２）、前の工程が完了している（Ｓ１３０３）場合、工程定義データ０２４において、該当するオーダー６０１における工程順序６０２のデータから作業時間６０３を取得する（Ｓ１３０５）。

Ｓ１３０２において予定設備が利用可能でないと判断されたか、または、Ｓ１３０３において前の工程が完了していないと判断された場合、その工程は着手できず、前の工程が完了するまで、その工程は待ち状態となる。すなわち、シミュレーション処理部０１２は、その工程についてのスケジュールデータ０２３の予定着手日時５０３をインクリメントする（Ｓ１３０４）。インクリメントは、現在の予定着手日時５０３に所定の時間（例えば３０分）加算することによって行われる。

次に、シミュレーション処理部０１２は、予定着手日時と作業時間の和がＤａｔｅ（シミュレーション現在時刻）と等しいか否かを判断する（Ｓ１３０６）。予定着手日時と作業時間の和がＤａｔｅ（シミュレーション現在時刻）と等しい場合、その工程が、Ｄａｔｅ（シミュレーション現在時刻）において、完了していると判断できる。

工程が完了していると判断できる場合、シミュレーション処理部０１２は、スケジュールデータ０２３及び工程定義データ０２４から該当する工程に関するデータを削除する（Ｓ１３０７）。

削除完了後、シミュレーション処理部０１２は、シミュレーション実績データ０２６に必要な情報を記入する（Ｓ１３０８）。シミュレーション実績データ０２６は、リードタイムなどのＫＰＩを算出するために用いる。具体的には、シミュレーション実績データ０２６は、製造実績データ０２５のオーダー８０１、工程順序８０２、設備ＩＤ８０４、着手日時８０５及び完了日時８０６と同様の項目を有し、それぞれに、シミュレーション上で終了した工程が属するオーダー、その工程の順序、その工程に使用された設備、その工程のシミュレーション上の着手日時及び完了日時等の情報が登録される。

次に、図９のＳ９０７で実行される処理の詳細を説明する。

表示処理部０１３は、すべてのシミュレーション実績データ０２６に基づき、リードタイムを算出する。同様に、表示処理部０１３は、すべてのすべてのシミュレーション実績データ０２６に基づき、加重平均法を用いて棚卸資産を算出する。さらに、表示処理部０１３は、すべてのシミュレーション実績データ０２６に基づき、納入順守率を算出する。これらはＫＰＩの一例であり、他のＫＰＩが算出されてもよい。これらのＫＰＩの算出は公知の方法を含めた任意の方法によって実現できるため、詳細な説明を省略する。表示処理部０１３は、これらの算出結果を、実績収集の仕組みの導入パターン（迅速対象データの条件）ごとにまとめる。

図１４は、本発明の実施例のデータ分析装置が出力する情報を説明する図である。

例えば、表示処理部０１３は、表示装置０６０を使用して、実績収集の仕組みの導入パターンごとにまとめたＫＰＩを表形式で表示する（Ｓ９０７）。図１４の例では、シミュレーションの条件として使用した各種類の事象の発生確率と、事象発生直後に再スケジュールが行われた場合のＫＰＩと、事象発生直後にその事象の発生が検知されない（例えば事象発生から５時間後に検知され、再スケジュールが行われた）場合のＫＰＩと、が表示される。この例では、ＫＰＩとしてリードタイム、棚卸資産及び納期順守率が表示されている。これによって、リアルタイムな実績収集の仕組みの費用効果を参照可能となる。また、部分的に、実績収集装置を導入した場合の費用対効果も参照可能となる。

本明細書では表形式での表示を行ったが、事象の発生確率を大きくしながら、再スケジュールタイミングを折れ線グラフで示して表示してもよい。

以上のように、本発明の実施例によれば、シミュレーションを行うことによって、実績収集の仕組みの導入の効果を定量的に見積もることができる。また、実績収集の仕組みを部分的に導入する場合の効果も見積もることができる。したがって、最も費用対効果が高いと見込まれる部分から実績収集の仕組みの導入を開始することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

０１０ 中央処理装置
０１１ 事象発生処理部
０１２ シミュレーション処理部
０１３ 表示処理部
０２０ データメモリ
０２１ 事象パラメタ
０２２ 事象データ
０２３ スケジュールデータ
０２４ 工程定義データ
０２５ 製造実績データ
０２６ シミュレーション実績データ
０２７ 通常事象発生検知タイミング
０２８ 迅速事象発生検知タイミング
０２９ 迅速対象データ
０３０ 交換可能設備データ
０３１ プログラムメモリ
０４０ 製造実績ＤＢ
０５０ 交換可能設備ＤＢ
０６０ 表示装置
０７０ キーボード
０８０ ポインティングデバイス

Claims (2)

1. 所定の事象が発生する工程を含む作業に対するシミュレーションにおいて、前記事象を発生させるよう設定する事象発生設定部と、
   事象発生から当該事象発生検知までの時間を示す事象発生検知タイミングを記憶部に記録する事象発生検知タイミング設定部と、
   前記シミュレーションを実行するシミュレーション実行処理部であって、
   前記シミュレーションにおいて、
   前記事象発生を検知した場合には、前記記録した事象発生検知タイミングに従って、当該事象に対する対応を行った場合の前記工程に対する影響を反映させてシミュレーションを実行するシミュレーション実行処理部と、
   前記シミュレーション実行処理部で実行されたシミュレーションの結果に基づいて、前記工程についての前記事象発生検知タイミングに対するＫＰＩを算出するＫＰＩ算出部と、
   を備えるデータ分析装置であって、
   前記事象発生検知タイミング設定部は、複数の事象発生検知タイミングを設定し、
   前記シミュレーション実行処理部は、
   前記事象が発生した場合、当該事象についていずれの事象発生検知タイミングに従って、前記影響を反映させたシミュレーションを実行させるか特定し、
   前記特定された事象発生検知タイミングから、前記影響を反映させてシミュレーションを実行する候補日時を示す再スケジュール候補日時を算出し、
   前記事象が複数発生した場合、第１の事象の第１の再スケジュール候補日時が、前記第１の事象より後に発生する第２の事象の第２の再スケジュール候補日時より後である場合、前記第２の再スケジュール候補日時が示す日時で、前記影響を反映させてシミュレーションを実行することを特徴とするデータ分析装置。
2. 中央処理装置と、メモリと、を有するデータ分析装置が実行するデータ分析方法であって、
   前記中央処理装置が、所定の事象が発生する工程を含む作業に対するシミュレーションにおいて、前記事象を発生させるよう設定する事象発生設定ステップと、
   前記中央処理装置が、事象発生から当該事象発生検知までの時間を示す事象発生検知タイミングを記憶部に記録する事象発生検知タイミング設定ステップと、
   前記中央処理装置が、前記シミュレーションを実行するシミュレーション実行処理ステップであって、
   前記シミュレーションにおいて、
   前記中央処理装置が、前記事象発生を検知した場合には、前記記録した事象発生検知タイミングに従って、当該事象に対する対応を行った場合の前記工程に対する影響を反映させてシミュレーションを実行するシミュレーション実行処理ステップと、
   前記中央処理装置が、前記シミュレーション実行処理ステップで実行されたシミュレーションの結果に基づいて、前記工程についての前記事象発生検知タイミングに対するＫＰＩを算出するＫＰＩ算出ステップと、
   を含み、
   前記事象発生検知タイミング設定ステップは、前記中央処理装置が、複数の事象発生検知タイミングを設定するステップを含み、
   前記シミュレーション実行処理ステップは、
   前記中央処理装置が、前記事象が発生した場合、当該事象についていずれの事象発生検知タイミングに従って、前記影響を反映させたシミュレーションを実行させるか特定するステップと、
   前記中央処理装置が、前記特定された事象発生検知タイミングから、前記影響を反映させてシミュレーションを実行する候補日時を示す再スケジュール候補日時を算出するステップと、
   前記中央処理装置が、前記事象が複数発生した場合、第１の事象の第１の再スケジュール候補日時が、前記第１の事象より後に発生する第２の事象の第２の再スケジュール候補日時より後である場合、前記第２の再スケジュール候補日時が示す日時で、前記影響を反映させてシミュレーションを実行するステップと、を含むことを特徴とするデータ分析方法。

Images