(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0016】
以下、添付図面を参照しながら、本発明に係るデータ分析装置の形態例を説明する。後述する形態例及びその説明は一例であり、本発明には様々な変形例が考えられる。
【0017】
<システム構成>
図1〜
図20は、以下で説明する形態例を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表し、基本的な構成及び動作は同様であるものとする。
【0018】
図1は、本発明の実施例に係るデータ分析装置の構成を示すブロック図である。
【0019】
データ分析装置は、事象発生を検知したタイミングで未完了の工程について再スケジュールを行った上で工程を実行した場合の、リードタイム等の効果を試算する装置である。データ分析装置は、中央処理装置010、データメモリ020、プログラムメモリ031、製造実績DB(データベース)040、交換可能設備DB050、表示装置060、キーボード070、及びポインティングデバイス080を有する。中央処理装置010は、データメモリ020、プログラムメモリ031、製造実績DB040、交換可能設備DB050、表示装置060、キーボード070、及びポインティングデバイス080と相互接続されている。
【0020】
中央処理装置010は、事象発生処理部011、シミュレーション処理部012、及び表示処理部013を有する。事象発生処理部011は、作業時間の増加等の工程進捗に影響を及ぼす事象が、どのオーダーまたはどのオーダーにおけるどの工程で発生するかを決定するものである。シミュレーション処理部012は、スケジュール管理システム(例えば、本発明のデータ分析装置がシミュレートする対象の工場等において実際にスケジュールを管理しているシステム)が事象発生を検知したタイミング毎に未完了の工程を再スケジュールして実行した場合の工程完了日時等を見積もるものである。表示処理部013は、各々のタイミングで再スケジュールをして各工程を着手完了した場合のリードタイムや納期順守率等を算出し表示するものである。
【0021】
データメモリ020は、中央処理装置010の各処理部が、事象を発生させ、シミュレーションを行い、その結果を表示するために用いる各種パラメタおよびデータを格納する。データメモリ020は、事象パラメタ021、事象データ022、スケジュールデータ023、工程定義データ024、製造実績データ025、シミュレーション実績データ026、通常事象発生検知タイミング027、迅速事象発生検知タイミング028、迅速対象データ029、及び交換可能設備データ030を格納する。
【0022】
なお、事象発生処理部011、シミュレーション処理部012及び表示処理部013の機能は、中央処理装置010がプログラムメモリ031に格納されたプログラム(図示省略)を実行することによって実現される。したがって、以下の説明において上記の処理部が実行する処理は、実際には、中央処理装置010がプログラムに記述された命令に従って実行する。また、プログラムメモリ031及びデータメモリ020は、同一の記憶装置であってもよい。また、製造実績DB040及び交換可能設備DB050は、それぞれ、例えばハードディスクドライブ等の記憶装置であってもよいし、同一の記憶装置であってもよい。また、製造実績DB040及び交換可能設備DB050に含まれるデータの少なくとも一部が必要に応じてデータメモリ020にコピーされてもよい。
【0023】
図2は、本発明の実施例の事象パラメタ021の構成及びデータ例を示す図である。
【0024】
事象パラメタ021は、シミュレーションで用いられる事象が、どの程度の確
率で発生するかを事象の種類毎に定義するとともに、その事象が発生した場合の影響度合いを定義するデータテーブルである。
【0025】
事象パラメタ021はデータフィールドとして、種類201、発生確率202、影響度合い203を有する。
【0026】
種類201は、どのような種類の事象が発生するかを示すフィールドであり、値として“工程作業時間の増加”、“工程着手時間の遅延”、“オーダー着手の遅延”、“オーダーを途中から再実行”、及び“オーダーを最初から再実行”のいずれかを有する。
【0027】
発生確率202は、あるオーダーに対し、その種類の事象が、どの程度の確率で発生するかを定義したフィールドである。なお、各オーダーにおいてどの工程で事象が発生するかはランダムに決定される。
【0028】
影響度合い203は、事象が発生した場合に、その工程及び同一オーダーの他の工程に与える影響を示すフィールドであり、事象の種類ごとに定義される。事象の種類201が“工程作業時間の増加”である場合、その事象が発生した場合の工程作業時間が、事象が発生しなかった場合の何倍になるかが定義される。事象の種類201が“工程着手時間の遅延”である場合、その事象が発生した場合の前工程の完了と後工程の着手の時間差が、事象が発生しなかった場合の何倍になるかが定義される。事象の種類201が“オーダー着手時間の遅延”である場合、その事象が発生した場合のオーダーの最初の工程の着手日時が何時間または何日遅延するかが定義される。事象の種類201が“オーダーを途中から再実行”である場合、および“オーダーを最初から再実行”である場合は、そのオーダーにおける他の工程への影響はなく、影響度合いは定義しない。影響度合いは、シミュレーション処理フローのS1106のステップで工程定義データを更新する際に利用される。本実施形態における事象パラメタの要素数は5である。
【0029】
なお、上記の“工程作業時間の増加”、“工程着手時間の遅延”、“オーダー着手の遅延”、“オーダーを途中から再実行”、及び“オーダーを最初から再実行”は、それぞれ、
図16から
図20に示した例に対応する。“オーダーを途中から再実行”とは、
図19に示したように、全工程作業が終了していないオーダーの作業を中止して、最初の工程作業から再実行する事象である。“オーダーを最初から再実行”は、全工程作業が終了したオーダーを最初の工程作業から再実行する事象である。
【0030】
図3は、本発明の実施例の事象データ022の構成及びデータ例を示す図である。
【0031】
事象データ022は、シミュレーション対象として用いることを決定した事象がどのような種類であるか、及び他の工程にどのような影響があるかを示すデータテーブルである。
【0032】
事象データ022はデータフィールドとして、種類301、オーダー302、工程順序303、及び影響度合い304を有する。
【0033】
種類301は、シミュレーション対象として用いることを決定した事象がどのような種類のものであるかを示す。オーダー302は、シミュレーションにおいて事象が発生すると決定した工程作業が、どのオーダー(注文)に対応する作業であるかを示す。工程順序303は、当該工程作業が当該オーダーにおいて何番目の工程作業であるかを示す。影響度合い304は、その事象が同一オーダーの他の工程に、どの程度の影響を与えるかを示す。
【0034】
シミュレーション処理部012は、製造実績データ025から取得した各オーダーの各工程に対して、読み込んだ事象パラメタ021の発生確率202がシステムによりランダムに発生させた変数と比較して大きいか否かを判断する。発生確率202がランダムに発生させた変数より大きい場合、シミュレーション処理部012は、その読み込んだ事象が発生すると想定し、事象データ022を生成する。事象データ022の要素数は、シミュレーションにおいて発生すると想定した事象の数である。
【0035】
シミュレーション処理部012は、生成した事象データ022に基づき、シミュレーションを行う。事象データ022に基づくシミュレーションの詳細は後述する。
【0036】
図4は、本発明の実施例の交換可能設備データ030の構成及びデータ例を示す図である。
【0037】
交換可能設備データ030は、設備の故障が発生した場合等、その工程を行うために代替して使用可能な設備を示すデータを格納したデータテーブルである。交換可能設備データ030は、データフィールドとして、設備401を有する。
【0038】
本データは、シミュレーション処理フローのS1111ステップ(
図11参照)で、設備の空きを待つために工程進捗が遅れることを防止し最適な再スケジュールを行うために、スケジューラによって参照される。
【0039】
図4の例は、設備02と設備05が交換可能であること、すなわちそれらのいずれを使用しても同じ工程作業を実行できることを示している。
【0040】
図5は、本発明の実施例のスケジュールデータ023の構成及びデータ例を示す図である。
【0041】
スケジュールデータ023は、シミュレーション処理において、その工程で事象が発生するか否かに関わらず、各工程の着手日時及び使用する設備を決定するために用いられるテーブルである。
【0042】
スケジュールデータ023は、データフィールドとして、オーダー501、工程順序502、予定着手日時503、及び予定設備ID504を有する。
【0043】
オーダー501は、シミュレーションが行われる工程作業が、どのオーダーに対応する作業であるかを示す。工程順序502は、当該工程作業が当該オーダーにおいて何番目の工程作業であるかを示す。予定着手日時503は、シミュレーションにおいて当該工程作業が着手される日時を示す。予定設備ID504は、シミュレーションにおいて当該工程作業を行うこと予定している設備を示す。
【0044】
その工程において、“工程着手時間の遅延”又は“オーダー着手の遅延”が生じた場合、スケジュールデータ023の予定着手日時503が更新される。この他、予定着手日時503及び予定設備ID504は、シミュレーション処理フローのS1111ステップで、他のオーダーの各工程との関係を考慮し、より効率的な再スケジュールを行うため、スケジューラによって更新される場合もある。
【0045】
図6は、本発明の実施例の工程定義データ024の構成及びデータ例を示す図である。
【0046】
工程定義データ024は、シミュレーション処理において、各工程の完了日時を算出したり、最適なスケジュールを計算したりするために用いられるテーブルである。
【0047】
工程定義データ024は、データフィールドとして、オーダー601、工程順序602、作業時間603、最早着手時間604、及び使用可能設備605を有する。
【0048】
オーダー601は、シミュレーションが行われる工程作業が、どのオーダーに対応する作業であるかを示す。工程順序602は、当該工程作業が当該オーダーにおいて何番目の作業であるかを示す。作業時間603は、当該工程作業を行うのに必要な時間を示す。最早着手時間604は、材料の到達時間等に基づき最も早く当該工程作業に着手できる時間は何時であるかを示す。使用可能設備605は、当該工程作業を行うために使用可能な設備を示す。使用可能設備605に複数の設備が含まれる場合、それらの設備は代替可能である。
【0049】
工程定義データ024は、製造実績データ025に基づき、その工程で事象が発生するか否かに関わらず、各々の製造実績データ毎に生成される。工程定義データ024は、製造実績の要素数と同数生成されることになる。
【0050】
図7は、本発明の実施例の迅速対象データ029の構成及びデータ例を示す図である。
【0051】
迅速対象データ029は、実績収集の仕組み導入によって事象が発生したことを事象発生直後に検知するケースを判断するための条件を示す。すべての工程についてスケジュール管理システムが事象発生直後に事象発生を検知すべく、すべての工程に実績収集の仕組みを導入することは困難な場合がある。そのため、後の工程に甚大な影響を与える特定の工程又は設備についてのみ実績収集の仕組み導入する場合がある。その場合、その工程についてのみ事象が発生した事実を事象発生直後にスケジュール管理システムが検知することとなる。迅速対象データ029は、そのような迅速に事象発生の事実を検知する対象を特定するための条件を示す。
【0052】
迅速対象データ029は、データフィールドとして、オーダー条件701、設備条件702、及び時刻条件703を有する。
【0053】
オーダー条件701は、迅速な検知をすべき対象となるオーダーを示す。設備条件702は、迅速な検知の対象となる設備を列挙したものである。時刻条件703は、その時間帯で事象発生した場合に検知する対象であることを示す。
【0054】
図8は、本発明の実施例の製造実績データ025の構成及びデータ例を示す図である。
【0055】
製造実績データ025は、POP(Point of Production)システムによって現場で収集された着手日時及び作業時間を、各オーダーにおける工程毎にまとめたテーブルである。
【0056】
製造実績データ025は、データフィールドとして、オーダー801、工程順序802、標準時間803、設備ID804、着手日時805、及び完了日時806を有する。
【0057】
オーダー801は、実行された工程作業が、どのオーダーに対応する作業であるかを示す。工程順序802は、その工程作業がそのオーダーにおいて何番目の作業であるかを示す。標準時間803は、その工程作業を行うのに標準的に必要な時間を示す。設備ID804は、実際にその工程作業を行った設備を示す。着手日時805は、実際にその工程作業に着手した日時を示す。完了日時806は、実際にその工程作業を完了した日時を示す。
【0058】
製造実績データ025は、シミュレーションを行う際に用いられる各工程のスケジュールデータ023及び工程定義データ024の初期作成において用いられる。
【0059】
<システム動作について>
図9は、本発明の実施例のデータ分析装置の処理概要を示すフローチャートである。
【0060】
本実施例のデータ分析装置の処理は、作業時間の増加等の工程進捗に影響を及ぼす事象が発生した場合、スケジュール管理システムがその事象の発生を事象発生直後に検知しないケースがあることを考慮し、スケジュール管理システムが事象発生を検知したタイミングで未完了の工程を再スケジュールする等の適切な対応をし、各工程を着手完了した場合のKPI(Key Performance Indicator、重要業績評価指標)を算出するものである。
【0061】
データ分析装置の処理概要のフローチャートについて説明する。
【0062】
まず、製造実績データ025が読み込まれる(S901)。後に製造実績のある工程すべてについてシミュレーション処理を行うため、事象発生処理部011は、製造実績データ025に格納されたすべてのデータを読み込む。
【0063】
次に、事象発生処理部011は、事象パラメタ021について、5種類のパラメタすべてを読み込む(S902)。
【0064】
次に、事象発生処理部011は、シミュレーションにおいて、読み込んだ製造実績データ025から取得した各オーダーの各工程について、作業時間増加又は着手時間の遅延等の事象が発生するか否かを決定する(S903)。この処理の詳細は
図10を参照して後述する。
【0065】
次に、シミュレーション処理部012が、その決定した事象が発生してから、その事象が発生したことをスケジュール管理システムが検知するまでの経過時間を示す通常事象発生検知タイミングを設定する(S904)。
【0066】
次に、シミュレーション処理部012は、事象発生について実績収集の仕組みを導入した場合の事象発生から事象発生を検知するまでの経過時間を示す迅速事象発生検知タイミングを設定する(S905)。例えば、実績収集の仕組み導入の投資を抑えつつ事象発生による影響を最小限に抑えようとするため、新たに導入した設備についてのみ実績収集の仕組みを導入する場合がある。そのような実績収集の仕組みが導入された工程は、事象発生の事実を迅速にスケジュール管理システムが検知しすぐに再スケジュールすることができるが、それ以外の工程について事象が発生した場合、迅速な検知はされず、例えば事象発生から数時間経過後に事象発生を認識し再スケジュールすることとなる。迅速事象発生検知タイミングを設定することで、実績収集の仕組みを部分的に導入した場合の効果を見積もることができる。このため、迅速事象発生検知タイミングは、通常事象発生検知タイミングと比較して、事象が発生してからそれが検知されるまでの経過時間が短くなるように設定される。
【0067】
次に、シミュレーション処理部012は、シミュレーション処理を行う(S906)。シミュレーション処理は、スケジュール管理システムが事象発生を検知し、検知タイミングに基づき再スケジュールすることを想定する日時毎に行う。その工程が事象発生により影響を受ける工程である場合、事象発生による作業時間の遅延等を加味してシミュレーションを行う。また、事象発生による影響を受けない工程は、当初のスケジュールに基づく工程着手日時や作業時間でシミュレーションを行う。事象発生を検知し再スケジュールする日時経過後は、その時点で未完了の工程について、最適にスケジュールし直した上で(後述する再スケジュール)、スケジュールデータ023を設定し、そのスケジュールデータ023に基づき、各工程が着手され完了するまでをシミュレーションする。この処理の詳細は
図11〜
図13を参照して後述する。
【0068】
さらに、シミュレーション処理部012は、異なる通常事象発生検知タイミング及び迅速事象発生検知タイミングを設定し、S906のシミュレーション処理を行ってもよい。
【0069】
次に、表示処理部013は、実績収集の仕組みの導入のパターンごとに、例えばリードタイム及び納期順守率等のKPIを算出する(S907)。この処理の詳細は
図14を参照して後述する。
【0070】
図10は、本発明の実施例のデータ分析装置が実行する事象発生処理を示すフローチャートである。
【0071】
事象発生処理は、シミュレーションにおいて実行される各オーダー又は各オーダーにおける各工程について、作業時間の増加又は着手日時の遅延等の事象が発生すると想定できるか否かを判断するものである。判断の結果、事象が発生すると想定したオーダーまたはオーダーにおける工程については、事象の種類301、オーダー302、及びそのオーダーにおける工程順序303毎に、その事象発生による影響度合い304を示す事象データ022が生成される。
【0072】
事象発生処理のフローチャートの各処理を説明する。
【0073】
まず、事象発生処理部011は、事象パラメタ021を参照し、ある種類の事象パラメタについて、種類201、その発生確率202、及び影響度合い203を読み込む(S1001、S1002)。
【0074】
次に、事象発生処理部011は、処理の対象のオーダーを設定する(S1003)。例えば、初期値として、1つ目のオーダーを示す値“1”が設定される。
【0075】
次に、S1001及びS1002において取得した事象パラメタ021の発生確率202が、例えばメルセンヌ・ツイスターなどの乱数生成アルゴリズムによってランダムに発生させた0以上1未満の変数以上か否かを判断する(S1004)。この処理は、S1001及びS1002で読み込んだ事象の発生確率202に基づき、シミュレーションにおいて、そのオーダーに対してその事象が発生すると想定できるか否かを判断するものである。すなわち、読み込んだ事象の発生確率202と、ランダムに発生させた0以上1未満のランダム変数を比較し、発生確率202の方が大きければ、シミュレーションにおいて事象が発生すると判断する。これによって、事象発生処理部011は、事象が発生するものと想定されたオーダーまたはそのオーダーにおける工程については、事象データを作成し、後にシミュレーション処理部012がこの事象データを用いてシミュレーションを行う。この事象発生処理によって、現実(実態)に近い状況で事象発生を想定することができる。
【0076】
次に、S1004で事象が発生すると判断した場合、事象発生処理部011は、読み込んだ事象パラメタの種類が、“工程作業時間の増加”又は“工程着手日時の遅延”であるか否かを判断する(ステップ905)。種類201が、“工程作業時間の増加”又は“工程着手日時の遅延”である場合、事象発生処理部011は、対象オーダー801について、製造実績データ025から、工程順序をランダムに抽出する(S1006)。そのオーダーにおけるどの工程で事象が発生するかを決定するためである。
【0077】
次に、事象発生処理部011は、S1002で読み込んだ事象が、S1006で決定された工程において発生した場合の影響度合いを事象パラメタ021から取得する(S1007)。この影響度合いは後のシミュレーションの処理フローにおいて、S1006ステップでの工程定義データの更新(例えば作業時間603が増加したり、最早着手時間604が遅延したりするような事象など)に用いられる。
【0078】
最後に、事象発生処理部011は、シミュレーションにおいて事象が発生すると判断したオーダーについて、発生すると判断した事象の種類、対象オーダー、対象工程及び影響度合いを、事象データ022の種類301、オーダー302、工程順序303及び影響度合い304に登録する。
【0079】
事象発生処理部011は、1つの種類の事象について、製造実績データ025に格納されたオーダーの上限値に達するまでS1004〜S1007の処理を繰り返し、オーダーの上限値に達したら、別の事象の種類を設定し、上記と同様の処理を実行する。全てのオーダーと5種類の事象すべてとの全組合せについて上記の処理が終了したら、
図10の処理が終了する。
【0080】
上記のように、本実施例では、S901で読み込まれた製造実績データ025と、S902で読み込まれた事象パラメタ021と、に基づいて事象を発生する処理が行われる。これは、製造実績データ025がスケジュールデータ023の初期値として使用されるためである(後述するS1102参照)。すなわち、S901は、製造実績データに基づいてスケジュールデータ023の初期値を作成する処理であり、S903の処理は、そのようにして作成されたスケジュールデータ023の初期値と、事象パラメタ021と、に基づいて事象を発生させる処理であると言える。後述するように、製造実績データ025によらずにスケジュールデータ023の初期値を生成することも可能であり、その場合は、S901において製造実績データ025を読み込む代わりにスケジュールデータ023の初期値を作成するか、又は既に作成されている初期値を読み込んでもよい。
【0081】
図11は、本発明の実施例のデータ分析装置が実行するシミュレーション処理を示すフローチャートである。
【0082】
本シミュレーション処理は、各オーダー又は、各オーダーにおける各工程で、作業時間の増加等の事象が所定の確率でランダムに発生すると想定し、その事象が発生したことをスケジュール管理システムが検知したタイミングで、未完了の工程について再スケジュールをして、各工程がいつ着手され完了するのかをシミュレーションする処理である。シミュレーションは、再スケジュール前の工程を含め、製造実績のある工程すべてについて行われる。
【0083】
シミュレーション処理のフローチャートについて説明する。
【0084】
まず、シミュレーション処理部012は、再スケジュール予定日時を初期化する(S1101)。再スケジュール予定日時は、事象が発生したという事実を、スケジュール管理システムが検知し、その検知に基づき、再スケジュールが行われる日時を示す。初期値としては、”9999”など無限将来の値を設定する。
【0085】
次に、シミュレーション処理部012は、スケジュールデータ023を初期化する(S1102)。スケジュールデータ023は、事象が発生すると想定する工程だけでなく、製造実績データとして登録されたデータすべてに対して作成する。作成したスケジュールデータ023の値に基づいて、各工程についてシミュレーションが行われる。また、再スケジュールを行う際にもスケジュールデータ023の各値が用いられる。スケジュールデータ023の初期値は、そのデータフィールドであるオーダー501、工程順序502、予定着手日時503及び予定設備ID504に、製造実績データ025のデータフィールド値であるオーダー801、工程順序802、着手日時805及び設備ID804を転記することによって作成される。
【0086】
上記のように製造実績データ025を利用することによって、実際に実行可能なスケジュールデータ023の初期値を作成することができる。ただし、上記の作成方法は一例であり、既に説明したように、スケジュールデータ023の初期値は、製造実績データ025からの転記以外の方法によって作成されてもよい。その場合、S1102では、そのようにして作成された初期値が読み込まれる。また、上記は本発明を工場等の製造業の現場に適用した例であるが、本発明は製造業以外の事業に適用することも可能であり、その場合は、当該事業の作業の実績データに基づいてスケジュールデータ023の初期値を作成することもできる。
【0087】
次に、シミュレーション処理部012は、工程定義データ024を作成する(S1103)。工程定義データ024は、事象が発生すると想定する工程だけでなく、製造実績データとして登録された各々のデータすべてに対して作成される。スケジュールデータ023とともに、工程定義データ024の各値に基づいて、シミュレーションが行われる。また、最適な再スケジュールを行う際にも工程定義データ024の各値が用いられる。工程定義データ024のデータフィールドであるオーダー601、工程順序602及び最早着手時間604には、製造実績データ025のデータフィールド値であるオーダー801、工程順序802及び着手日時805が転記される。工程定義データ024のデータフィールド値である作業時間603には、製造実績データ025のデータフィールド値である完了日時806と着手日時805との差が登録される。発明が解決しようとする課題の中で述べた、標準時間が未整備である問題のため、製造実績データ025の標準時間ではなく、より信頼性が高いと考えられる完了日時806と着手日時805との差を用いる。工程定義データ024の使用可能設備605には、製造実績データ025の設備ID804の値に基づき、交換可能設備データ030を参照して対応する設備
401のIDが登録される。
【0088】
次に、シミュレーション処理部012は、実績収集仕組みの導入パターンを抽出する(S1104)。これは、実績収集仕組みを導入するための投資を抑えつつ事象発生による影響を最小限に抑えようとするため、事象発生を迅速に認識するため対策(すなわち実績収集の仕組み)を部分的に導入することを想定したものである。実績収集仕組みを部分的に導入するパターンの例として、新しく導入した設備に対してのみ実績収集仕組みを導入する、大口顧客のオーダーに対応する仕掛品に関する工程に事象が発生した場合のみタグ等によって管理する、又は、定期的に所定の時間帯に発生した事象を報告する運用をする、といったパターンが挙げられる。実績収集仕組みをどの程度(すなわちどの部分に)導入することで効果を発揮するかを定量的に確認できるようにするため、シミュレーション処理部012は、S1105〜S1113のシミュレーション処理を、複数の実績収集の仕組み導入のパターンのそれぞれについて行う。実績収集仕組みの導入パターンは、迅速対象データ029から抽出される。
【0089】
次に、シミュレーション処理部012は、変数Dateを初期化する。(S1105)。変数Dateは、シミュレーションにおける現在時刻(シミュレーション現在時刻)に相当する。Date(シミュレーション現在時刻)は、その時刻において、その工程が完了しているか否か、その時刻は工程着手時間であるか、その時刻はスケジュール管理システムが事象発生を検知し再スケジュールを行う時刻であるか、を判断するために用いられる。シミュレーション処理部012は、初期値としてDate=0を登録する。シミュレーション処理部012は、あるDate(シミュレーション現在時刻)に対して、S1102で取得済みのすべてのスケジュールデータについて以降の処理(S1106〜S1113)である事象発生によるスケジュールデータ023及び工程定義データ024の更新、再スケジュール、及び各工程の着手完了を実施し、その後、Date(シミュレーション現在時刻)をインクリメントし、同様にS1102で取得済みの残りすべてのスケジュールデータについて以降の処理を行うことを繰り返す。
【0090】
次に、シミュレーション処理部012は、あるDate(シミュレーション現在時刻)において、各スケジュールデータ023に対して、その時刻に
図9で決定した想定事象が発生するか否かを判断する(S1106)。Date(シミュレーション現在時刻)が、その事象が発生すると想定する工程の予定着手日時503に到達していれば、その時刻に事象が発生すると判断される。すなわち、シミュレーション処理部012は、事象データ022から、事象が発生すると想定する工程のオーダー302及び工程順序303を取得し、スケジュールデータ023を参照し、取得したオーダー302及び工程順序303と一致するオーダー501及び工程順序502を有するスケジュールデータ023を抽出する。
【0091】
発生を想定する事象の種類301が“工程作業時間の増加”または“工程着手日時の遅延”または“オーダー着手の遅延”である場合、抽出したスケジュールデータ023の予定着手日時503がDate(シミュレーション現在時刻)と等しければ、その時刻にその想定事象(工程が遅延する事象)が発生すると判断される。発生を想定する事象の種類301がそれ以外である場合、すなわち“オーダーを途中から再実行”又は“オーダーを最初から再実行”である場合、スケジュールデータ023の予定着手日時503と工程定義データ024の作業時間603との和がDate(シミュレーション現在時刻)と等しければ、その時刻に、その想定事象(オーダーを再実行する必要性を引き起こす事象)が発生すると判断される。“オーダーを途中から再実行”又は“オーダーを最初から再実行”が発生する例としては、作業途中の物品を完全に破損してしまい作り直しになったり、作業途中の物品と同じ種類の物品が緊急に他用途でも必要となり追加で製造する必要が生じたりするなどがある。
【0092】
次に、シミュレーション処理部012は、工程定義データ024を更新する(S1107)。工程定義データ024の更新は、事象発生によって生じた作業時間の増加及び最も早く工程に着手できる日時の変更を反映させるものである。したがって、そのDate(シミュレーション現在時刻)において、事象が発生すると判断した工程について、その工程に対応する工程定義データ024のみ、事象の種類に応じた更新処理が行われる。すなわち、シミュレーション処理部012は、発生する事象の種類301が“工程作業時間の増加”だった場合、作業時間を増加する。種類301が“工程着手日時の遅延”だった場合、最早着手時間604を遅らせる。種類301が“オーダー着手の遅延”だった場合、そのオーダーの最初の工程順序における最早着手時間604を遅らせる。種類301が“オーダーを途中から再実行”だった場合、新しいオーダーの工程定義データを工程ごとに作り、オーダーの値を含め元のオーダーのデータを新しい工程定義データに転記し、元のオーダーの実行済みの工程以降の工程順序のデータを削除する。種類301が“オーダーを最初から再実行”だった場合、新しいオーダーの工程定義データを工程ごとに作り、オーダーの値も含め元のオーダーのデータを新しい工程定義データに転記する。
【0093】
次に、シミュレーション処理部012は、スケジュールデータ023を更新する(S1108)。スケジュールデータ023の更新は、事象発生によって生じた“工程着手時間の遅延”、“オーダー着手時間の遅延”又は“予定設備の変更”を反映させるものである。したがって、そのDate(シミュレーション現在時刻)において、事象が発生すると判断した工程に対応するスケジュールデータ023についてのみ事象の種類に応じた更新処理が行われる。すなわち、シミュレーション処理部012は、発生する事象の種類301が“工程着手日時の遅延”だった場合、予定着手日時503を遅らせる。“種類301が“オーダー着手の遅延”だった場合、そのオーダーの最初の工程順序における予定着手日時503を遅らせる。種類301が“オーダーを途中から再実行”だった場合、S1106で新たに作成した工程定義データに対応するスケジュールデータ023を新たに追加する。
【0094】
すなわち、シミュレーション処理部012は、現在着手している工程作業の完了日時の直後に、工程順序1の工程作業に着手し、その後の工程作業にも順次着手するようにスケジュールデータ023に要素を追加し、また追加要素の予定着手日時を設定する。シミュレーション処理部012は、種類301が“オーダーを最初から再実行”だった場合、S1006で新たに作成した工程定義データに対応するスケジュールデータ023を追加する。すなわち、シミュレーション処理部012は、現在着手しているオーダーの最後の工程順序の完了日時の直後に、工程順序1の工程作業に着手し、その後の工程作業にも順次着手するようにスケジュールデータ023に要素を追加し、また追加要素の予定着手日時を設定する。
【0095】
以後のシミュレーションは、S1107で更新された工程定義データ024及びS1108で更新されたスケジュールデータ023を参照して実行される。これによって、発生した事象の影響が以後のシミュレーションに反映される。
【0096】
次に、シミュレーション処理部012は、再スケジュール予定日時を更新する(S1109)。
【0097】
再スケジュール予定日時は、事象が発生したという事実を、スケジュール管理システムが検知し、その検知に基づき再スケジュールする日時を想定したものである。再スケジュール予定日時更新処理については、
図12のフローチャートを用いて詳細に説明する。
【0098】
次に、シミュレーション処理部012は、再スケジュールするか否かを判断し(S1110)、再スケジュールをすると判断した場合、再スケジュールを行う(S1111)。再スケジュールを行うとは、そのDate(シミュレーション現在時刻)において、未完了のスケジュールデータ023について、予定着手日時503と予定設備504を最適な値に更新することを意味する。すなわち、シミュレーション処理部012は、あるDate(シミュレーション現在時刻)が再スケジュール予定日時と一致するか否かを判断する。一致する場合に、そのDate(シミュレーション現在時刻)はスケジュール管理システムが事象発生を検知するに至ったタイミングであるとして、シミュレーション処理部012は、そのDate(シミュレーション現在時刻)において未完了のすべてのスケジュールデータ023について、予定着手日時503及び予定設備ID504を最適な値に更新する。予定着手日時503、予定設備ID504の最適な値への更新は、他のスケジュールデータ023及び工程定義データ024基づき、予定設備及び代替設備の有無、並びに、オーダー及び工程の入れ替えを考慮して行う。なお、シミュレーション処理部012は、既存のスケジューラ(例えば、本実施例のデータ分析装置がシミュレートする対象の工場等において使用されているスケジューラ等)にスケジュールの更新処理を実行させてもよい。
【0099】
次に、シミュレーション処理部012は、工程作業を着手し、完了する(S1112)。工程作業着手・完了処理は、Date(シミュレーション現在時刻)が、スケジュールデータ023の予定着手日時に到達している場合、その工程作業の着手から完了までのシミュレーションを行う処理である。工程作業を着手・完了する処理については、
図13のフローチャートを用いて詳細に説明する。
【0100】
シミュレーション処理部012は、Date(シミュレーション現在時刻)をインクリメントして(S1113)、S1106以降の処理を実行する。例えば、シミュレーション処理部012は、Date(シミュレーション現在時刻)に対応するスケジュールデータが存在する限り、S1106〜S1113を繰り返し実行してもよい。
【0101】
さらに、シミュレーション処理部012は、S1102〜S1113の処理を、実績収集の仕組みの導入パターンごとに行う。
【0102】
図12は、本発明の実施例のデータ分析装置がS1108において実行する再スケジュール予定日時の更新処理の詳細を示すフローチャートである。
【0103】
再スケジュール予定日時は、スケジュール管理システムが事象が発生したことを検知し、その検知に基づき再スケジュールを行う日時である。
【0104】
本実施例においては、事象が発生したという事実を検知し再スケジュールを行うタイミングについて、S904において通常事象発生検知タイミングと迅速事象発生検知タイミングが設定される。その設定した通常事象発生検知タイミングまたは迅速事象発生検知タイミングに基づき、再スケジュール予定日時が更新される。通常事象発生検知タイミングは、実績収集の仕組みを導入しない場合のリードタイム等のKPIを見積もるために用いられる。たとえば、事象発生から5時間後にスケジュール管理システムが事象発生を検知し再スケジュールを行う場合、事象発生から5時間後の日時、すなわち、Date(シミュレーション現在時刻)に5時間を加算した日時が、更新後の再スケジュール予定日時となる。なお、再スケジュール予定日時は、S1105で、Date(シミュレーション現在時刻)において想定事象が発生すると判断した場合のみ更新される。事象が発生しなければ、シミュレーション処理部012は、再スケジュールする必要がないため更新は行わず、現状のスケジュールデータ023を用いてシミュレーションを行う。
【0105】
また、実績収集の仕組みを部分的に導入した場合の効果を見積もるため、シミュレーション処理部012は、通常事象発生検知タイミングと迅速事象発生検知タイミングのいずれかを用いて再スケジュール予定日時を更新する。たとえば、実績収集仕組みの導入の投資を抑えつつ事象発生による影響を最小限に抑えようとするため、新しく導入した設備のみ実績収集仕組みを導入する、大口顧客のオーダーに対応する仕掛品に関する工程に事象が発生した場合のみタグ等により管理する、又は、定期的に所定の時間帯に発生した事象を報告する、といった仕組みを導入する場合がある。そのような部分的な実績収集仕組みを導入する場合は、特定の事象については事象発生の事実を迅速にスケジュール管理システムが検知しすぐに再スケジュールすることができるが、それ以外の事象が発生した場合、迅速な検知はされず、事象発生から数時間経過後に事象発生を検知し再スケジュールすることとなる。通常事象発生検知タイミングと、迅速事象発生検知タイミングの2種類のタイミングを用いることで、部分的に実績収集仕組みを導入した場合であっても適切なシミュレーションを行うことができる。
【0106】
再スケジュール予定日時の更新処理のフローチャートについて説明する。
【0107】
まず、シミュレーション処理部012は、S1106における、事象データのオーダーと工程順序とを用いて、スケジュールデータから該当行を探す処理によって得られたスケジュールデータ023の、オーダー501及び予定設備ID504を取得する(S1201)。
【0108】
次に、シミュレーション処理部012は、事象が発生した工程について、迅速対象データ029を参照し、迅速対象か否かを判断する(S1202)。たとえば、シミュレーション処理部012は、Date(シミュレーション現在時刻)が、迅速対象データ029の時刻条件703の条件を満たすか否かを判断してもよい。これは、リアルタイムな実績収集仕組みの導入が困難な場合に、バッチ収集システムの導入及び運用によって、特定の時間帯に定期的に事象発生の事実を検知する場合を想定したものである。あるいは、シミュレーション処理部012は、予定設備ID504が迅速対象データ029における設備条件702に含まれるか否かを判断してもよい。すべての設備に実績収集の仕組みを導入するコスト負担から、新しい設備等一部の設備に対してのみ、実績収集の仕組みを導入する場合を想定したものである。あるいは、シミュレーション処理部012は、取得したオーダー501が迅速対象データ029におけるオーダー条件701に含まれるか否か判断してもよい。これは、大口顧客又は納期期限に厳しい顧客等、特定の顧客のオーダーに対応する仕掛品に関する事象発生のみ迅速検知する場合を想定したものである。
【0109】
次に、事象が発生した工程が迅速な検知対象となる条件に含まれる場合(S1202:Yes)、すなわち、発生した事象の時刻条件、設備条件及びオーダー条件が、迅速対象データ029に含まれるいずれかの条件を満たした場合、シミュレーション処理部012は、事象発生検知タイミングに、迅速事象発生検知タイミングを設定する(S1203)。
【0110】
一方、事象が発生した工程が迅速な検知対象となる条件に含まれない場合(S1202:No)、シミュレーション処理部012は、事象発生検知タイミングに、通常事象発生検知タイミングを設定する(S1204)。
【0111】
なお、すべての工程を対象として実績収集の仕組みを導入した場合は、事象発生検知タイミングとして、迅速事象発生検知タイミングのみ用いる。
【0112】
次に、シミュレーション処理部012は、現在設定されている再スケジュール予定日時が、Date(シミュレーション現在時刻)に事象発生検知タイミングを加えた値より将来であるか否かを判断する(S1205)。現在設定されている再スケジュール予定日時が、Date(シミュレーション現在時刻)に事象発生検知タイミングを加えた値より将来である場合、シミュレーション処理部012は、再スケジュール予定日時を、Date(シミュレーション現在時刻)に事象発生検知タイミングを加えた値で更新する。(S1206)。
【0113】
例えば、2つの事象が発生することが想定されるシミュレーションにおいて、先に発生した1つ目の事象が迅速対象でなく、その再スケジュール予定日時が「午後3時に事象発生に気付き、再スケジュールを行う」となっており、Date(シミュレーション現在時刻)が午後2時で、2つ目の事象が迅速対象であり再スケジュールタイミング使用値が0(事象発生直後)であった場合、「午後2時に事象発生に気付き、再スケジュールを行う」という予定が新しく追加されたということを意味する。この場合、午後2時にスケジュール管理システムが事象発生を検知し再スケジュールを行えば、既に発生している1つ目の事象も考慮した際スケジュールが行われるため、午後3時にスケジュール管理システムが事象発生を検知して再スケジュールを行うという想定は必要ない。このため、シミュレーション処理部012は、再スケジュールの予定を、「午後2時に事象発生に気付き再スケジュールを行う」という予定に更新する。
【0114】
結局、ある事象(第1の事象)が発生してからそれが検知されるまでの間に、別の事象(第2の事象)が発生した場合、それらのいずれかが先に検知された時点で再スケジュールが行われ、もう一方が検知された時点では再スケジュールが行われない。例えば、第2の事象が先に検知された場合、その時点で再スケジュールが行われ、第1の事象が検知された時点での再スケジュールは行われない。これによって、不要な再スケジュールの実行が省略される。
【0115】
図13は、本発明の実施例のデータ分析装置がS1111において実行する工程作業を着手・完了する処理の詳細を示すフローチャートである。
【0116】
工程作業を着手・完了する処理は、事象発生の対象工程、事象発生によって影響を受ける工程、及び、事象が発生しても影響を受けない工程のすべてについて行われる。事象発生の対象工程及び事象発生によって影響を受ける工程の場合、その影響を勘案して各工程を着手し完了するまでのシミュレーションが行われる。また、再スケジュールする以前及び再スケジュールした後ともにシミュレーションが行われる。ただし、再スケジュール後は、S1110において、最適に再スケジュールした後、シミュレーションが行われる。
【0117】
工程作業の着手・完了のフローチャートについて説明する。
【0118】
シミュレーション処理部012は、未完了の各スケジュールデータ023について、Date(シミュレーション現在時刻)が予定着手日時503に至っているか否か、つまり、Date(シミュレーション現在時刻)が予定着手日時503と等しいか否かを判断する(S1301)。Date(シミュレーション現在時刻)が予定着手日時503と等しければ、次に、シミュレーション処理部012は、予定設備ID504が利用可能か否かを判断する(S1302)。利用可能か否かの判断は、予定設備が前工程で現在使用中であるか否かに基づいて判断する。具体的には、スケジュールデータ023において、予定設備ID504が一致するデータの中に、予定着手日時がDate(シミュレーション現在時刻)以前のものがなければその設備は利用可能と判断される。S1307で説明するように、既に完了した工程のスケジュールデータは削除されるため、この処理方法によって設備の利用可否を判断することができる。予定設備504が利用可能であると判断した場合、次に、シミュレーション処理部012は、そのオーダーにおける前の工程が完了しているか否かを判断する。具体的には、オーダーが同じで工程作業順序が一つ前のスケジュールデータ023が存在していなければ、前の工程は完了していると判断できる。
【0119】
次に、シミュレーション処理部012は、S1301〜S1303において、Date(シミュレーション現在時刻)が予定着手日時503に至っており(S1301)、予定設備が利用可能であり(S1302)、前の工程が完了している(S1303)場合、工程定義データ024において、該当するオーダー601における工程順序602のデータから作業時間603を取得する(S1305)。
【0120】
S1302において予定設備が利用可能でないと判断されたか、または、S1303において前の工程が完了していないと判断された場合、その工程は着手できず、前の工程が完了するまで、その工程は待ち状態となる。すなわち、シミュレーション処理部012は、その工程についてのスケジュールデータ023の予定着手日時503をインクリメントする(S1304)。インクリメントは、現在の予定着手日時503に所定の時間(例えば30分)加算することによって行われる。
【0121】
次に、シミュレーション処理部012は、予定着手日時と作業時間の和がDate(シミュレーション現在時刻)と等しいか否かを判断する(S1306)。予定着手日時と作業時間の和がDate(シミュレーション現在時刻)と等しい場合、その工程が、Date(シミュレーション現在時刻)において、完了していると判断できる。
【0122】
工程が完了していると判断できる場合、シミュレーション処理部012は、スケジュールデータ023及び工程定義データ024から該当する工程に関するデータを削除する(S1307)。
【0123】
削除完了後、シミュレーション処理部012は、シミュレーション実績データ026に必要な情報を記入する(S1308)。シミュレーション実績データ026は、リードタイムなどのKPIを算出するために用いる。具体的には、シミュレーション実績データ026は、製造実績データ025のオーダー801、工程順序802、設備ID804、着手日時805及び完了日時806と同様の項目を有し、それぞれに、シミュレーション上で終了した工程が属するオーダー、その工程の順序、その工程に使用された設備、その工程のシミュレーション上の着手日時及び完了日時等の情報が登録される。
【0124】
次に、
図9のS907で実行される処理の詳細を説明する。
【0125】
表示処理部013は、すべてのシミュレーション実績データ026に基づき、リードタイムを算出する。同様に、表示処理部013は、すべてのすべてのシミュレーション実績データ026に基づき、加重平均法を用いて棚卸資産を算出する。さらに、表示処理部013は、すべてのシミュレーション実績データ026に基づき、納入順守率を算出する。これらはKPIの一例であり、他のKPIが算出されてもよい。これらのKPIの算出は公知の方法を含めた任意の方法によって実現できるため、詳細な説明を省略する。表示処理部013は、これらの算出結果を、実績収集の仕組みの導入パターン(迅速対象データの条件)ごとにまとめる。
【0126】
図14は、本発明の実施例のデータ分析装置が出力する情報を説明する図である。
【0127】
例えば、表示処理部013は、表示装置060を使用して、実績収集の仕組みの導入パターンごとにまとめたKPIを表形式で表示する(S907)。
図14の例では、シミュレーションの条件として使用した各種類の事象の発生確率と、事象発生直後に再スケジュールが行われた場合のKPIと、事象発生直後にその事象の発生が検知されない(例えば事象発生から5時間後に検知され、再スケジュールが行われた)場合のKPIと、が表示される。この例では、KPIとしてリードタイム、棚卸資産及び納期順守率が表示されている。これによって、リアルタイムな実績収集の仕組みの費用効果を参照可能となる。また、部分的に、実績収集装置を導入した場合の費用対効果も参照可能となる。
【0128】
本明細書では表形式での表示を行ったが、事象の発生確率を大きくしながら、再スケジュールタイミングを折れ線グラフで示して表示してもよい。
【0129】
以上のように、本発明の実施例によれば、シミュレーションを行うことによって、実績収集の仕組みの導入の効果を定量的に見積もることができる。また、実績収集の仕組みを部分的に導入する場合の効果も見積もることができる。したがって、最も費用対効果が高いと見込まれる部分から実績収集の仕組みの導入を開始することができる。
【0130】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。
【0131】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、SSD(Solid State Drive)等の記憶デバイス、または、ICカード、SDカード、DVD等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
【0132】
また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。