JP6570604B2 - スケジュール管理システムおよびスケジュール管理プログラム - Google Patents

Description

本発明は、スケジュール管理システムおよびスケジュール管理プログラムに関するものである。

特許文献１から特許文献４には、共通的な業務を１つのデータベースで統合したＥＲＰパッケージを用いて生産管理を行う技術が記載されている。「ＥＲＰ」は、Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｎｇの略語である。

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

製造業のＩＴ化が進み、生産現場にも各種業務支援システムが導入されているが、各システムが個別最適化されている場合が少なくない。「ＩＴ」は、Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙの略語である。

システム間で連携している場合も、パッケージを構成するシステム同士の連携に限られる。そのため、システム間またはパッケージ内外を跨ぐ情報共有および検討はユーザが行わなくてはならない。例えば、生産スケジュールを検討する際は、設備管理システムで設備の空き状況、在庫管理システムで部品の在庫状況、勤怠管理システムで作業者の空き状況を調べて検討する必要がある。よって、顧客から新たな案件の依頼を受けた場合に、納期の回答をすぐに出すことが難しい。また、新たな案件が社内で承認された場合に、その案件に必要な設備、部品および作業者を確保するための情報共有が遅れるおそれがある。

本発明は、新たな案件のスケジュールを、他の案件のスケジュールとの競合を避けつつ、迅速に作成することを目的とする。

本発明の一態様に係るスケジュール管理システムは、
新たな未承認案件である第１案件のスケジュールを、データベースに登録された個別の承認済案件のスケジュールを変更することを前提に作成してよいかどうかの設定を検討条件の設定として受ける設定部と、
前記データベースを参照して、前記個別の承認済案件のスケジュールと競合せず、かつ、前記設定部に設定された検討条件を満たすスケジュールを前記第１案件のスケジュールとして作成する作成部と、
前記作成部により作成された前記第１案件のスケジュールを前記データベースに登録するとともに、前記第１案件のスケジュールが、前記データベースに登録された承認済案件である第２案件のスケジュールを変更することを前提に作成されていれば、前記第１案件が承認された場合に前記第２案件のスケジュールの変更を前記第２案件の管理者に通知するための変更通知情報を前記データベースに記録する登録部と
を備える。

本発明では、新たな案件のスケジュールを、他の案件のスケジュールを変更することを前提に作成できるようにしつつ、実際に変更が適用される場合に対象案件の管理者が通知を受けられるようにしている。そのため、新たな案件のスケジュールを、他の案件のスケジュールとの競合を避けつつ、迅速に作成することができる。

実施の形態１に係るスケジュール管理システムの構成を示すブロック図。 実施の形態１に係る案件情報の例を示す表。 実施の形態１に係る資源予約情報の例を示す表。 実施の形態１に係る進捗情報の例を示す表。 実施の形態１に係るデータ取り込み周期情報の例を示す表。 実施の形態１に係るスケジュール管理システムの動作を示すフローチャート。 実施の形態１に係るスケジュール管理システムに対して設定される検討条件と共通データベース参照先との例を示す表。 実施の形態１に係るスケジュール管理システムに対して設定される検討条件と共通データベース参照先との例を示す表。 実施の形態１に係るスケジュール管理システムに対して設定される検討条件と共通データベース参照先との例を示す表。 実施の形態１に係るスケジュール管理システムに対して設定される検討条件と共通データベース参照先との例を示す表。 案件の例を示す表。 実施の形態１に係るスケジュール管理システムにより作成されるスケジュールの例を示す表。 実施の形態１に係るスケジュール管理システムの動作を示すフローチャート。 実施の形態１に係るスケジュール管理システムの動作を示すフローチャート。 実施の形態１に係るスケジュール管理システムの動作を示すフローチャート。 実施の形態１に係るスケジュール管理システムの動作を示すフローチャート。

以下、本発明の実施の形態について、図を用いて説明する。各図中、同一または相当する部分には、同一符号を付している。実施の形態の説明において、同一または相当する部分については、説明を適宜省略または簡略化する。なお、本発明は、以下に説明する実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。例えば、以下に説明する実施の形態は、部分的に実施されても構わない。

実施の形態１．
本実施の形態について、図１から図１６を用いて説明する。

＊＊＊構成の説明＊＊＊
図１を参照して、本実施の形態に係るスケジュール管理システム１００の構成を説明する。

スケジュール管理システム１００は、任意のスケジュールを管理するシステムでよいが、本実施の形態では製造工場の生産スケジュールを管理するシステムである。スケジュール管理システム１００は、１つの案件につき、１つのスケジュールを作成して管理する。個々のスケジュールは、１つ以上の工程からなる。

スケジュール管理システム１００は、図示していないＬＡＮまたはインターネット等のネットワークを介して複数のユーザ端末２００と通信を行う。「ＬＡＮ」は、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋの略語である。それぞれのユーザ端末２００は、生産スケジュールの管理者によって利用されるＰＣ、タブレットまたはスマートフォン等の端末である。「ＰＣ」は、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒの略語である。

スケジュール管理システム１００は、図示していないＬＡＮまたはインターネット等のネットワークを介して複数の連携システム３００とも通信を行う。これら複数の連携システム３００は、互いに異なる種類の資源の空き状況または供給状況を記録するシステムである。資源とは、設備、人員および部品在庫等、生産に必要なもののことである。本実施の形態では、連携システム３００として、設備管理システム３０１、勤怠管理システム３０２、在庫管理システム３０３、受注管理システム３０４および進捗管理システム３０５等がある。

スケジュール管理システム１００は、設定部１１０と、作成部１２０と、登録部１３０と、更新部１４０と、消去部１５０と、判定部１６０と、インタフェース部１７０と、共通データベース１８０とを備える。

スケジュール管理システム１００は、インタフェース部１７０経由で各連携システム３００から抽出したデータを共通データベース１８０で一元管理する。共通データベース１８０を参照することで、各連携システム３００が個別に保持している、工程検討に必要な情報を一元的に参照できる。各連携システム３００でデータ変更が実施された場合は、変更をトリガとしたデータ送信が可能な連携システム３００からは変更タイミングで、可能でないものからは設定周期ごとに共通データベース１８０へ最新データをアップすることで、共通データベース１８０内の情報を最新に保つことができる。

スケジュール管理システム１００は、共通データベース１８０に保存された情報より演算処理で自動的に工程案を作成することができる。工程案としては、単純に設備の空き状況、人員の空き状況、および、在庫状況等から生成されるもののみでなく、優先度による既存工程の組み換えおよびクラッシングによる短縮案等も生成可能とする。

連携システム３００の情報が更新され、工程に影響のあるイベントまたは工程遅延が発生した場合、スケジュール管理システム１００は、発報と代替案提示とを行うことができる。

各連携システム３００が共通データベース１８０を参照可能とすれば、連携システム３００ごとでの重複した情報入力を省略することができる。

スケジュール管理システム１００は、ローカルサーバまたはクラウドサーバ等のコンピュータである。スケジュール管理システム１００は、プロセッサ１０１を備えるとともに、メモリ１０２、補助記憶装置１０３、入力機器１０４、ディスプレイ１０５および通信装置１０６といった他のハードウェアを備える。プロセッサ１０１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の機能は、ソフトウェアにより実現される。共通データベース１８０は、メモリ１０２に構築されてもよいが、本実施の形態では補助記憶装置１０３に構築される。

プロセッサ１０１は、スケジュール管理プログラムを実行する装置である。スケジュール管理プログラムは、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の機能を実現するプログラムである。プロセッサ１０１は、例えば、ＣＰＵである。「ＣＰＵ」は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略語である。

メモリ１０２および補助記憶装置１０３は、スケジュール管理プログラムを記憶する装置である。メモリ１０２は、例えば、フラッシュメモリまたはＲＡＭである。「ＲＡＭ」は、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略語である。補助記憶装置１０３は、例えば、フラッシュメモリまたはＨＤＤである。「ＨＤＤ」は、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略語である。

入力機器１０４は、スケジュール管理プログラムへのデータの入力のために操作される機器である。入力機器１０４は、例えば、マウス、キーボードまたはタッチパネルである。

ディスプレイ１０５は、スケジュール管理プログラムから出力されるデータを画面に表示する機器である。ディスプレイ１０５は、例えば、ＬＣＤである。「ＬＣＤ」は、Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙの略語である。

通信装置１０６は、スケジュール管理プログラムに入力されるデータを受信するレシーバと、スケジュール管理プログラムから出力されるデータを送信するトランスミッタとを含む。通信装置１０６は、例えば、通信チップまたはＮＩＣである。「ＮＩＣ」は、Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄの略語である。レシーバは、各ユーザ端末２００および各連携システム３００からデータを受信するために利用される。トランスミッタは、各ユーザ端末２００および各連携システム３００にデータを送信するために利用される。

スケジュール管理プログラムは、補助記憶装置１０３からメモリ１０２にロードされ、プロセッサ１０１に読み込まれ、プロセッサ１０１によって実行される。補助記憶装置１０３には、スケジュール管理プログラムだけでなく、ＯＳも記憶されている。「ＯＳ」は、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍの略語である。プロセッサ１０１は、ＯＳを実行しながら、スケジュール管理プログラムを実行する。

なお、スケジュール管理プログラムの一部または全部がＯＳに組み込まれていてもよい。

スケジュール管理システム１００は、プロセッサ１０１を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、スケジュール管理プログラムの実行を分担する。それぞれのプロセッサは、例えば、ＣＰＵである。

スケジュール管理プログラムにより利用、処理または出力されるデータ、情報、信号値および変数値は、メモリ１０２、補助記憶装置１０３、または、プロセッサ１０１内のレジスタまたはキャッシュメモリに記憶される。

スケジュール管理プログラムは、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０により行われる処理をそれぞれ設定処理、作成処理、登録処理、更新処理、消去処理、判定処理およびインタフェース処理としてコンピュータに実行させるプログラムである。スケジュール管理プログラムは、コンピュータ読取可能な媒体に記録されて提供されてもよいし、記録媒体に格納されて提供されてもよいし、プログラムプロダクトとして提供されてもよい。

スケジュール管理システム１００は、１台のコンピュータで構成されていてもよいし、複数台のコンピュータで構成されていてもよい。スケジュール管理システム１００が複数台のコンピュータで構成されている場合は、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の機能が、各コンピュータに分散されて実現されてもよい。

共通データベース１８０は、スケジュール検討に必要であり、他の連携システム３００と共通で扱う案件ごとに更新されるような情報と、プル型の情報取得が必要な連携システム３００に対するデータ取得の周期を示す情報とを持つ。具体的には、共通データベース１８０は、案件情報１８１、資源予約情報１８２、進捗情報１８３およびデータ取り込み周期情報１８４を持つ。

図２に案件情報１８１の例を示す。

案件情報１８１としては、案件番号、登録者、商談確度、スケジュール承認状態、優先度、機種、数量、商談規模、納期および納期調整可能範囲等が記録される。登録者は、案件を登録した、その案件のスケジュールの管理者のことである。機種は、複数指定可能である。数量および納期は、機種ごとに設定可能である。

案件番号とは、案件ごとに割り当てられるユニークな番号のことである。変更管理用に副番を持つ場合もある。商談確度とは、受注済であるか、未受注であるか、また未受注であれば、受注の確度のことである。機種とは、製品の種別のことである。納期調整可能範囲とは、設定中の納期から後ろ倒し可能と想定される期間のことである。納期と発注元の運用開始日との間に差があり、調整余地がある場合、あるいは、量産品で在庫品の融通にて調整可能な場合等は、納期調整可能範囲が０日よりも大きい値に設定される。

図３に資源予約情報１８２の例を示す。

資源予約情報１８２には、設備情報１９１、人員情報１９２および在庫情報１９３等が含まれる。設備情報１９１、人員情報１９２および在庫情報１９３等、検討されたスケジュールに応じて予定を押さえる必要がある情報については、公式に承認された予約状況が承認済スケジュールとして登録され、案件番号に紐付く未承認の仮予約情報が検討中案件として登録される。

承認済スケジュールとは、スケジュール管理システム１００上で公式に承認されたスケジュールのことである。検討中案件とは、登録中案件のうち、スケジュールが承認されていない案件のことであり、商談確度が受注済であるか、未受注であるかは関係しない。登録中案件とは、共通データベース１８０に登録されている全案件のことであり、商談確度およびスケジュール承認状態を問わず、すべての案件を指す。検討中案件のスケジュールが承認されると、その検討中案件は承認済案件となり、承認済スケジュールに組み込まれる。承認済案件については、検討中案件と同様に、商談確度が受注済であるか、未受注であるかは関係しない。

設備情報１９１としては、設備名および予約状況等が記録される。予約状況としては、開始日、終了日および予約理由等が記録される。予約理由としては、案件での使用であればその案件番号、メンテナンスまたは故障等であればその旨が記録される。

人員情報１９２としては、人員名および予約状況等が記録される。予約状況としては、開始日、終了日および予約理由等が記録される。予約理由としては、案件への対応であればその案件番号、休暇または出張等であればその旨が記録される。

在庫情報１９３としては、部品名、在庫数量、予約状況および入着状況等が記録される。予約状況としては、案件番号、数量および使用タイミングが記録される。入着状況としては、案件番号、数量および入着タイミングが記録される。

設備情報１９１には、承認済スケジュールおよび検討中案件の情報とは別に、設備管理システム３０１からの入力情報が含まれる。人員情報１９２にも、承認済スケジュールおよび検討中案件の情報とは別に、勤怠管理システム３０２からの入力情報が含まれる。在庫情報１９３にも、承認済スケジュールおよび検討中案件の情報とは別に、在庫管理システム３０３からの入力情報が含まれる。これらの連携システム３００からの入力情報は、予約理由によって変更不可の予定として承認済スケジュールおよび検討中案件に反映される。

検討中案件の情報には、後述する変更通知情報１９４および消去通知情報１９５のいずれかまたは両方が含まれる場合がある。

資源予約情報１８２に含まれる、各連携システム３００からの入力情報は、資源の空き状況または供給状況を示す第１情報１９６に相当する。具体的には、設備情報１９１に含まれる、設備管理システム３０１からの入力情報は、設備の空き状況を示す第１情報１９６に相当する。人員情報１９２に含まれる、勤怠管理システム３０２からの入力情報は、人員の空き状況を示す第１情報１９６に相当する。在庫情報１９３に含まれる、在庫管理システム３０３からの入力情報は、部品の供給状況を示す第１情報１９６に相当する。

資源予約情報１８２に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する資源の割り当て状況を示す第２情報１９７に相当する。具体的には、設備情報１９１に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する設備の割り当て状況を示す第２情報１９７に相当する。人員情報１９２に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する人員の割り当て状況を示す第２情報１９７に相当する。在庫情報１９３に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する部品の割り当て状況を示す第２情報１９７に相当する。

このように、本実施の形態では、資源予約情報１８２に、複数種類の資源の空き状況または供給状況を示す情報が第１情報１９６として含まれ、個別の承認済案件に対する複数種類の資源の割り当て状況を示す情報が第２情報１９７として含まれている。なお、変形例として、資源予約情報１８２に、１種類のみの資源の空き状況または供給状況を示す情報が第１情報１９６として含まれ、個別の承認済案件に対する１種類のみの資源の割り当て状況を示す情報が第２情報１９７として含まれていてもよい。

資源予約情報１８２に含まれる、検討中案件の情報は、新たな未承認案件に対する資源の割り当て結果を示す第３情報１９８に相当する。具体的には、設備情報１９１に含まれる、検討中案件の情報は、新たな未承認案件に対する設備の割り当て結果を示す第３情報１９８に相当する。人員情報１９２に含まれる、検討中案件の情報は、新たな未承認案件に対する人員の割り当て結果を示す第３情報１９８に相当する。在庫情報１９３に含まれる、検討中案件の情報は、新たな未承認案件に対する部品の割り当て結果を示す第３情報１９８に相当する。

このように、本実施の形態では、新たな未承認案件に資源が割り当てられた場合に、当該新たな未承認案件に対する資源の割り当て結果を示す第３情報１９８が、資源予約情報１８２の一部として共通データベース１８０に記録される。

後述するように、資源予約情報１８２は、新たな未承認案件に資源が割り当てられる際に参照される。資源予約情報１８２に含まれる第２情報１９７は、新たな未承認案件が承認された場合に、当該新たな未承認案件に対する資源の割り当て結果に応じて更新される。また、第２情報１９７は、資源の割り当て状況に変化が生じた承認済案件がある場合に、生じた変化に合わせて更新される。

図４に進捗情報１８３の例を示す。

進捗情報１８３としては、案件番号、工程名および進捗状況が記録される。

図５にデータ取り込み周期情報１８４の例を示す。

データ取り込み周期情報１８４としては、連携システム３００の名称であるシステム名、および、周期が記録される。

以上の情報のほかに、スケジュール検討に必要だが、案件ごとに更新される可能性が低く、必要に応じて更新し、ライブラリ情報として参照すればよいような情報もある。具体例としては、機種ごとに、使用部材および製造工程等を示す情報がある。製造工程としては、使用設備およびその使用期間、使用人員およびその使用期間、および、工程間の順序が記録される。設備ごとに、処理能力、および、生産機種切り替え時の所要時間等を示す情報もある。生産機種切り替え時の所要時間が一律でない場合は各パターンが網羅される。人員ごとに、各工程を担当した場合の処理能力等を示す情報もある。部品ごとに、リードタイム等を示す情報もある。注意値および警告値等の進捗遅延警告に関する情報もある。工程名および○日前等の工程順序変更可能期間に関する情報もある。こういった情報は、共通データベース１８０に保持されてもよいし、補助記憶装置１０３の他の領域に保持されてもよい。

＊＊＊動作の説明＊＊＊
図１から図５のほかに、図６から図１６を参照して、本実施の形態に係るスケジュール管理システム１００の動作を説明する。スケジュール管理システム１００の動作は、本実施の形態に係るスケジュール管理方法に相当する。

図６にスケジュールを作成する際のフローを示す。

図６のフローが開始されるトリガとして、新たな未承認案件である第１案件についての案件情報１８１が第１案件の登録者のユーザ端末２００から入力されたとする。

ステップＳ１１において、設定部１１０は、第１案件のスケジュールを、共通データベース１８０に登録された個別の承認済案件のスケジュールを変更することを前提に作成してよいかどうかの設定を検討条件の設定として受ける。

本実施の形態では、設定部１１０は、第１案件のスケジュールを、共通データベース１８０に登録された個別の未承認案件のスケジュールとの競合を避けることを前提に作成すべきかどうかの設定をさらに検討条件の設定として受ける。

本実施の形態では、設定部１１０は、第１案件のスケジュールが、共通データベース１８０に登録された未承認案件である第３案件のスケジュールとの競合を避けることを前提に作成される場合に、共通データベース１８０に登録された未承認案件の中から第３案件として扱う未承認案件を選択するための選択条件の設定も受ける。

本実施の形態では、設定部１１０は、第１案件のスケジュールを、共通データベース１８０に登録された個別の未承認案件のスケジュールを変更することを前提に作成してよいかどうかの設定をさらに検討条件の設定として受ける。

具体的には、設定部１１０は、図７から図１０に示す検討条件および選択条件の入力を第１案件の登録者のユーザ端末２００から受ける。図７から図１０において、大項目は独立して取り扱い、参照条件は各大項目の組み合わせで決定するものとする。

図７に示すように、承認済スケジュールの取り扱いについては、
・承認済スケジュールの変更を許可するかどうか
・承認済スケジュールの変更を許可する場合、納期超過を許容するかどうか
・納期超過を許容する場合、納期調整範囲を超えた納期超過を許容するかどうか
が設定される。

図８および図９に示すように、検討中スケジュールの取り扱いについては、
・検討中案件を考慮に入れるかどうか
・検討中案件を考慮に入れる場合の基準、すなわち、選択条件
・検討中案件を考慮に入れる場合、検討中案件のスケジュール変更を許可するかどうか
・検討中案件のスケジュールの変更を許可する場合、納期超過を許容するかどうか
・納期超過を許容する場合、納期調整範囲を超えた納期超過を許容するかどうか
が設定される。

図１０に示すように、クラッシングの取り扱いについては、
・クラッシングによる期間短縮を行うかどうか
・クラッシングを行う場合、対象は入力案件のみかどうか
・クラッシングを行う場合、どの工程にどの程度までリソース追加可能か
が設定される。

ステップＳ１２において、作成部１２０は、共通データベース１８０を参照して、個別の承認済案件のスケジュールと競合せず、かつ、設定部１１０に設定された検討条件を満たすスケジュールを第１案件のスケジュールとして作成する。

具体的には、作成部１２０は、共通データベース１８０に記録され、複数種類の資源の空き状況または供給状況と個別の承認済案件に対する複数種類の資源の割り当て状況とを示す資源予約情報１８２を参照して、第１案件に複数種類の資源を割り当てることで、第１案件のスケジュールを作成する。

より具体的には、作成部１２０は、資源予約情報１８２に含まれる情報を加工して既存の工程自動作成ツールに与えて工程自動作成ツールを実行することで、資源予約情報１８２に含まれる承認済スケジュールと競合せず、かつ、ステップＳ１１で入力された検討条件を満たすスケジュールを第１案件のスケジュールとして作成する。工程自動作成ツールには、スケジュールの自動作成および自動調整の基本的な機能が備わっていればよい。

例として、図１１に示すような登録中案件があった場合に、新規案件Ｆについて作成されるスケジュールが検討条件によってどのように変わるかを図１２に示す。簡略化のため、１種類の資源のみを想定する。検討条件としては、様々なものが考えられるが、本例では以下の４つを想定する。
・条件Ｃ１：承認済スケジュールの変更を許可しない。検討中案件を考慮しない。入力案件のクラッシングを行わない。
・条件Ｃ２：承認済スケジュールの変更を許可しない。検討中案件を考慮しない。入力案件のクラッシングを行う。工程および追加人数は制限する。
・条件Ｃ３：承認済スケジュールおよび検討中案件の変更を許可する。優先度「低」以下の案件の納期調整範囲を超えての遅延を許可する。優先度「高」以上の検討中案件を考慮に入れる。
・条件Ｃ４：承認済スケジュールの変更を許可しない。入力案件のクラッシングを行う。工程および追加人数は制限する。商談確度「中」以上の検討中案件を考慮に入れる。検討中案件のスケジュール変更を許可する。低優先度案件の納期遅延を許可する。

ステップＳ１３において、作成部１２０は、ステップＳ１２で作成した第１案件のスケジュールが納期内に完了するようになっているかを判定する。納期内に完了するようになっていなければ、ステップＳ１４の処理が行われる。納期内に完了するようになっていれば、ステップＳ１６の処理が行われる。

ステップＳ１４において、作成部１２０は、ステップＳ１２で作成した第１案件のスケジュールが納期を超過する要因と、その超過日数とを第１案件の登録者のユーザ端末２００に出力する。

ステップＳ１５において、第１案件についての案件情報１８１が変更され、変更後の案件情報１８１が第１案件の登録者のユーザ端末２００から入力されれば、ステップＳ１１の処理が再び行われる。そのような案件情報１８１が入力されなければ、ステップＳ１６の処理が行われる。

ステップＳ１６において、ステップＳ１２で作成された第１案件のスケジュールを共通データベース１８０に登録することを指示する操作が第１案件の登録者のユーザ端末２００で行われれば、ステップＳ１７の処理が行われる。そのような操作が行われなければ、フローが終了する。

ステップＳ１７において、登録部１３０は、作成部１２０により作成された第１案件のスケジュールを共通データベース１８０に登録する。

具体的には、登録部１３０は、作成部１２０による第１案件に対する複数種類の資源の割り当て結果を共通データベース１８０に記録することで、第１案件のスケジュールを共通データベース１８０に登録する。

登録部１３０は、登録した第１案件のスケジュールが、共通データベース１８０に登録された承認済案件である第２案件のスケジュールを変更することを前提に作成されていれば、第１案件が承認された場合に第２案件のスケジュールの変更を第２案件の管理者に通知するための変更通知情報１９４を共通データベース１８０に記録する。

登録部１３０は、登録した第１案件のスケジュールが、共通データベース１８０に登録された未承認案件である第３案件のスケジュールとの競合を避けることを前提に作成されていれば、第３案件がキャンセルされた場合に第３案件のスケジュールの消去を第１案件の管理者に通知するための消去通知情報１９５を共通データベース１８０に記録する。

登録部１３０は、登録した第１案件のスケジュールが共通データベース１８０に登録された未承認案件である第３案件のスケジュールを変更することを前提に作成されていれば、第１案件が承認された場合に第３案件のスケジュールの変更を第３案件の管理者に通知するための情報をさらに変更通知情報１９４として共通データベース１８０に記録する。

より具体的には、登録部１３０は、第１案件に案件番号を付与し、その案件番号とともに、ステップＳ１２で作成された第１案件に対する設備、人員および部品在庫の割り当て結果を、それぞれ共通データベース１８０の設備情報１９１、人員情報１９２および在庫情報１９３に追加する。

図１１および図１２に示した例では、案件Ｆが第１案件、案件Ａ、案件Ｂおよび案件Ｃが第２案件、案件Ｄおよび案件Ｅが第３案件に相当する。

設定部１１０に設定された検討条件が条件Ｃ１であるとする。その場合、作成部１２０は、新規案件である案件Ｆのスケジュールを、承認済案件である案件Ａ、案件Ｂおよび案件Ｃのスケジュールとの競合を避けることを前提に作成する。案件Ａ、案件Ｂおよび案件Ｃのスケジュールを変更することは前提になっていない。検討中案件である案件Ｄおよび案件Ｅのスケジュールとの競合を避けることも前提になっていない。結果として、案件Ｆのスケジュールには遅延が生じており、また、案件Ｆのスケジュールは案件Ｄおよび案件Ｅのスケジュールと重複しているが、登録部１３０は、案件Ｆのスケジュールを未承認案件のスケジュールとしてそのまま共通データベース１８０に登録する。なお、変更通知情報１９４および消去通知情報１９５は記録されない。

設定部１１０に設定された検討条件が条件Ｃ２である場合は、案件Ｆのクラッシングが許可されているため、遅延が解消するという点を除けば、検討条件が条件Ｃ１である場合と同じである。

設定部１１０に設定された検討条件が条件Ｃ３であるとする。その場合、作成部１２０は、新規案件である案件Ｆのスケジュールを、承認済案件である案件Ａ、案件Ｂおよび案件Ｃのスケジュールとの競合を避けること、低優先度案件である案件Ｂのスケジュールを変更すること、および、高優先度の検討中案件である案件Ｄのスケジュールを変更することを前提に作成する。高優先度案件である案件Ａ、および、中優先度案件である案件Ｃのスケジュールを変更することは前提になっていない。低優先度の検討中案件である案件Ｅのスケジュールとの競合を避けることも前提になっていない。結果として、案件Ｆのスケジュールは案件Ｂに遅延を生じさせることになり、また、案件Ｆのスケジュールは案件Ｅのスケジュールと重複しているが、登録部１３０は、案件Ｆのスケジュールを未承認案件のスケジュールとしてそのまま共通データベース１８０に登録する。案件Ｂのスケジュールは案件Ｆが承認された場合に変更されることになるため、登録部１３０は、案件Ｂの案件番号を示す変更通知情報１９４を案件Ｆの案件番号またはスケジュールに紐付けて共通データベース１８０に記録する。案件Ｄがスケジュール変更なしで承認されると仮定すると、案件Ｄのスケジュールも案件Ｆが承認された場合に変更されることになるため、登録部１３０により記録される変更通知情報１９４には、案件Ｂの案件番号だけでなく、案件Ｆの案件番号も示されている。案件Ｆのスケジュールは案件Ｄがキャンセルされた場合に案件Ｄを考慮する必要がなくなるため、登録部１３０は、案件Ｆの案件番号を示す消去通知情報１９５を案件Ｄの案件番号またはスケジュールに紐付けて共通データベース１８０に記録する。なお、案件Ｆのスケジュールに遅延が生じていない場合、あるいは、案件Ｆのスケジュールに遅延が生じているが、案件Ｄがキャンセルされても遅延が解消しない場合は、消去通知情報１９５が記録されなくてもよい。

設定部１１０に設定された検討条件が条件Ｃ４であるとする。その場合、作成部１２０は、新規案件である案件Ｆのスケジュールを、承認済案件である案件Ａ、案件Ｂおよび案件Ｃのスケジュールとの競合を避けること、および、高確度または中確度で受注可能な案件である案件Ｄおよび案件Ｅのスケジュールを変更することを前提に作成する。案件Ａ、案件Ｂおよび案件Ｃのスケジュールを変更することは前提になっていない。案件Ｆのクラッシングは許可されている。結果として、案件Ｆのスケジュールは案件Ｅに遅延を生じさせることになるが、登録部１３０は、案件Ｆのスケジュールを未承認案件のスケジュールとしてそのまま共通データベース１８０に登録する。案件Ｄおよび案件Ｅがスケジュール変更なしで承認されると仮定すると、案件Ｄおよび案件Ｅのスケジュールは案件Ｆが承認された場合に変更されることになるため、登録部１３０は、案件Ｄおよび案件Ｅの案件番号を示す変更通知情報１９４を案件Ｆの案件番号またはスケジュールに紐付けて共通データベース１８０に記録する。案件Ｆのスケジュールは案件Ｄまたは案件Ｅがキャンセルされた場合に案件Ｄまたは案件Ｅを考慮する必要がなくなるため、登録部１３０は、案件Ｆの案件番号を示す消去通知情報１９５を案件Ｄおよび案件Ｅの案件番号またはスケジュールに紐付けて共通データベース１８０に記録する。なお、案件Ｆのスケジュールに遅延が生じていない場合、あるいは、案件Ｆのスケジュールに遅延が生じているが、案件Ｄおよび案件Ｅのいずれがキャンセルされても遅延が解消しない場合は、消去通知情報１９５が記録されなくてもよい。

図１３に検討中案件のスケジュールを承認済スケジュールに更新する際のフローを示す。

図１３のフローが開始されるトリガとして、第１案件を承認する操作が第１案件の承認権限者のユーザ端末２００で行われたとする。

ステップＳ２１およびステップＳ２２において、更新部１４０は、第１案件を承認する操作を受けて、第１案件のスケジュールを新たな承認済案件のスケジュールとして共通データベース１８０に登録し直す。

具体的には、更新部１４０は、第１案件を承認する操作を受けて、登録部１３０により記録された第１案件に対する複数種類の資源の割り当て結果に応じて資源予約情報１８２を更新することで、第１案件のスケジュールを新たな承認済案件のスケジュールとして共通データベース１８０に登録し直す。

より具体的には、更新部１４０は、承認された第１案件のスケジュールを新たな承認済スケジュールとして共通データベース１８０の資源予約情報１８２に追加するとともに、承認された第１案件のスケジュールを共通データベース１８０の資源予約情報１８２の検討中案件から削除する。

ステップＳ２３において、更新部１４０は、承認された第１案件の案件番号またはスケジュールに紐付く変更通知情報１９４が共通データベース１８０に記録されているかどうかを判定する。変更通知情報１９４が記録されていれば、ステップＳ２４の処理が行われる。変更通知情報１９４が記録されていなければ、ステップＳ２５の処理が行われる。

ステップＳ２４において、更新部１４０は、変更通知情報１９４に従い、第２案件のスケジュールの変更を第２案件の管理者に通知する。

具体的には、更新部１４０は、変更通知情報１９４に示されている案件番号から、該当する案件の管理者のメールアドレスまたはその他の連絡先を特定して、その管理者にメール等で連絡する。

図１１および図１２に示した例において、案件Ｂの案件番号を示す変更通知情報１９４が案件Ｆの案件番号またはスケジュールに紐付けて共通データベース１８０に記録されていれば、更新部１４０は、案件Ｂの管理者にメール等で案件Ｂのスケジュールの変更を通知する。案件Ｄは承認済案件ではないが、案件Ｄの案件番号を示す変更通知情報１９４が案件Ｆの案件番号またはスケジュールに紐付けて共通データベース１８０に記録されていれば、更新部１４０は、案件Ｄの管理者にメール等で案件Ｄのスケジュールの変更を通知する。案件Ｅも承認済案件ではないが、案件Ｅの案件番号を示す変更通知情報１９４が案件Ｆの案件番号またはスケジュールに紐付けて共通データベース１８０に記録されていれば、更新部１４０は、案件Ｅの管理者にメール等で案件Ｄのスケジュールの変更を通知する。

ステップＳ２５において、更新部１４０は、登録中案件に含まれる検討中案件すべての管理者にメール等で新たな承認済スケジュールの追加を通知する。すなわち、本実施の形態において、更新部１４０は、第１案件のスケジュールを新たな承認済案件のスケジュールとして共通データベース１８０に登録し直す際に、共通データベース１８０に他の未承認案件のスケジュールが登録されていれば、第１案件のスケジュールの登録を他の未承認案件の管理者に通知する。

ステップＳ２４またはステップＳ２５で通知を受けた管理者は、必要に応じて図６のフローにより対象案件のスケジュールを調整することができる。

図１４にスケジュールを消去する際のフローを示す。

図１４のフローが開始されるトリガとして、案件をキャンセルする操作が当該案件の管理者のユーザ端末２００で行われたとする。

ステップＳ３１において、消去部１５０は、共通データベース１８０の資源予約情報１８２を参照して、キャンセルされた案件が承認済案件であるかどうかを判定する。すなわち、消去部１５０は、キャンセルされた案件が第２案件であるか、それとも第３案件であるかを判定する。第２案件であれば、ステップＳ３２の処理が行われる。第３案件であれば、ステップＳ３６の処理が行われる。

ステップＳ３２において、消去部１５０は、第２案件をキャンセルする操作を受けて、第２案件のスケジュールを共通データベース１８０から消去する。

具体的には、消去部１５０は、キャンセルされた第２案件のスケジュールを共通データベース１８０の資源予約情報１８２の承認済スケジュールから削除する。

ステップＳ３３において、承認済スケジュールの最適化を自動的に実施することを指示する操作がユーザ端末２００で行われれば、ステップＳ３４の処理が行われる。そのような操作が行われなければ、ステップＳ３５の処理が行われる。

ステップＳ３４において、作成部１２０は、共通データベース１８０の資源予約情報１８２に残っている承認済スケジュールの情報を加工して工程自動作成ツールに与えて工程自動作成ツールを実行することで、承認済スケジュールの最適化を実施する。登録部１３０は、作成部１２０による最適化の実施結果に合わせて共通データベース１８０の資源予約情報１８２を更新する。

ステップＳ３５において、消去部１５０は、登録中案件すべての管理者にメール等で共通データベース１８０の資源予約情報１８２の更新を通知する。その後、フローが終了する。

ステップＳ３６において、消去部１５０は、第３案件をキャンセルする操作を受けて、第３案件のスケジュールを共通データベース１８０から消去する。

具体的には、消去部１５０は、キャンセルされた第３案件のスケジュールを共通データベース１８０の資源予約情報１８２の検討中案件から削除する。

ステップＳ３７において、消去部１５０は、キャンセルされた第３案件の案件番号またはスケジュールに紐付く消去通知情報１９５が共通データベース１８０に記録されているかどうかを判定する。消去通知情報１９５が記録されていれば、ステップＳ３８の処理が行われる。消去通知情報１９５が記録されていなければ、フローが終了する。

ステップＳ３８において、消去部１５０は、消去通知情報１９５に従い、第３案件のスケジュールの消去を第１案件の管理者に通知する。

具体的には、消去部１５０は、消去通知情報１９５に示されている案件番号から、該当する案件の管理者のメールアドレスまたはその他の連絡先を特定して、その管理者にメール等で連絡する。

図１１および図１２に示した例において、キャンセルされた案件が案件Ｄであり、案件Ｆの案件番号を示す消去通知情報１９５が案件Ｄの案件番号またはスケジュールに紐付けて共通データベース１８０に記録されていれば、消去部１５０は、案件Ｄの管理者にメール等で案件Ｆのスケジュールの消去を通知する。同様に、キャンセルされた案件が案件Ｅであり、案件Ｆの案件番号を示す消去通知情報１９５が案件Ｅの案件番号またはスケジュールに紐付けて共通データベース１８０に記録されていれば、消去部１５０は、案件Ｅの管理者にメール等で案件Ｆのスケジュールの消去を通知する。

ステップＳ３５またはステップＳ３８で通知を受けた管理者は、必要に応じて図６のフローにより対象案件のスケジュールを調整することができる。

図１５に連携システム３００への情報入力により共通データベース１８０を更新する際のフローを示す。

図１５のフローが開始されるトリガとして、登録中案件のスケジュールに影響を及ぼすような情報が、複数の連携システム３００のうちいずれかの連携システム３００へ入力されたとする。そのような情報の入力の例としては、
・設備管理システム３０１へのメンテナンス予定または故障情報の入力
・勤怠管理システム３０２への出張予定または休暇取得の入力
・在庫管理システム３０３への部品の手配情報または入着情報の入力
・受注管理システム３０４への受注または失注の入力
がある。

ステップＳ４１において、情報の入力先の連携システム３００が、情報の入力をトリガとして外部へ情報を出力可能なシステムであれば、ステップＳ４２の処理が行われる。そのようなシステムでなければ、ステップＳ４５の処理が行われる。

ステップＳ４２において、情報の入力先の連携システム３００からインタフェース部１７０に情報が出力される。インタフェース部１７０は、その連携システム３００から、出力された情報、すなわち、該当する種類の資源の空き状況または供給状況の変化の通知を受ける。連携システム３００が設備管理システム３０１であれば、インタフェース部１７０は、設備の空き状況の変化の通知を受ける。連携システム３００が勤怠管理システム３０２であれば、インタフェース部１７０は、人員の空き状況の変化の通知を受ける。連携システム３００が在庫管理システム３０３であれば、インタフェース部１７０は、部品の供給状況の変化の通知を受ける。

ステップＳ４３において、インタフェース部１７０は、ステップＳ４２で連携システム３００から受け取った情報を共通データベース１８０の資源予約情報１８２の形式に合うように加工する。

ステップＳ４４において、インタフェース部１７０は、ステップＳ４３で加工した情報を共通データベース１８０に出力する。その後、ステップＳ４７の処理が行われる。

ステップＳ４５において、共通データベース１８０のデータ取り込み周期情報１８４に定義されたタイミングが到来すると、ステップＳ４６の処理が行われる。

ステップＳ４６において、共通データベース１８０は、インタフェース部１７０を介して連携システム３００から情報を取り出す。

ステップＳ４７において、共通データベース１８０は、インタフェース部１７０を介して取得した情報で資源予約情報１８２を更新する。すなわち、インタフェース部１７０は、連携システム３００から通知された変化に合わせて共通データベース１８０の資源予約情報１８２を更新する。連携システム３００が設備管理システム３０１であれば、インタフェース部１７０は、設備情報１９１を更新する。連携システム３００が勤怠管理システム３０２であれば、インタフェース部１７０は、人員情報１９２を更新する。連携システム３００が在庫管理システム３０３であれば、インタフェース部１７０は、在庫情報１９３を更新する。

ステップＳ４８において、判定部１６０は、インタフェース部１７０による資源予約情報１８２の更新内容に応じて、共通データベース１８０に登録された承認済案件ごとに、該当する種類の資源の割り当てを変更するかどうかを判定する。本実施の形態では、判定部１６０は、さらに、インタフェース部１７０による資源予約情報１８２の更新内容に応じて、共通データベース１８０に登録された未承認案件ごとに、該当する種類の資源の割り当てを変更するかどうかを判定する。なお、判定部１６０は、該当する種類以外の種類の資源の割り当てを変更するかどうかも判定することが望ましい。

具体的には、判定部１６０は、ステップＳ４７における資源予約情報１８２の更新の影響によりスケジュールの変更が必要となる案件を抽出する。

ステップＳ４９において、判定部１６０は、ステップＳ４８の判定結果を、少なくとも該当する種類の資源の割り当てを変更すると判定した承認済案件の管理者に通知する。本実施の形態では、判定部１６０は、ステップＳ４８の判定結果を、該当する種類の資源の割り当てを変更すると判定した未承認案件の管理者にも通知する。

具体的には、判定部１６０は、ステップＳ４８で資源予約情報１８２の更新の影響によりスケジュールの変更が必要となる案件を抽出していれば、抽出した案件の管理者にメール等で連絡する。

このように、本実施の形態では、インタフェース部１７０は、複数の連携システム３００のうちいずれかの連携システム３００から、該当する種類の資源の空き状況または供給状況の変化の通知を受けた場合に、通知された変化に合わせて共通データベース１８０の第１情報１９６を更新する。なお、資源の種類が１種類のみ、連携システム３００の数が１つのみでも本実施の形態を適用することができる。つまり、インタフェース部１７０は、１つの連携システム３００のみから、その１種類の資源の空き状況または供給状況の変化の通知を受け、通知された変化に合わせて共通データベース１８０の第１情報１９６を更新してもよい。

図１６に共通データベース１８０から連携システム３００へのフィードバックを行う際のフローを示す。

図１６のフローが開始されるトリガとして、共通データベース１８０が更新されたとする。

このフローでは、既存の承認済案件に変更のない新規案件が承認された場合は、設備管理システム３０１に新規案件の設備使用スケジュールが出力され、勤怠管理システム３０２に新規案件の作業スケジュールが出力され、在庫管理システム３０３に新規案件の部品手配および使用予定が出力されることになる。

設備トラブルにより作業工程の一部に順番変更があった場合は、設備管理システム３０１に設備使用スケジュールの変更が出力され、勤怠管理システム３０２に作業スケジュールの変更が出力される。部品の手配タイミングに影響がなければ、在庫管理システム３０３に出力される変更はない。

遅延解消のため二交代制にすることで期間短縮を図る更新があった場合は、勤怠管理システム３０２に作業スケジュールの変更が出力される。設備使用期間に影響がなければ、設備管理システム３０１に出力される変更はない。

ステップＳ５１において、判定部１６０は、共通データベース１８０の更新対象が承認済スケジュールであるかどうかを判定する。承認済スケジュールでなければ、ステップＳ５２によって、ステップＳ５３以降の処理では、重複する複数スケジュール案を持てない連携システム３００が情報出力の対象外となる。

ステップＳ５３において、判定部１６０は、連携システム３００ごとに、該当する種類の資源の割り当てに変更があったかどうかを判定する。設備情報１９１が更新されたのであれば、インタフェース部１７０は、設備管理システム３０１の登録情報に影響があると判定する。人員情報１９２が更新されたのであれば、インタフェース部１７０は、勤怠管理システム３０２の登録情報に影響があると判定する。在庫情報１９３が更新されたのであれば、インタフェース部１７０は、在庫管理システム３０３の登録情報に影響があると判定する。影響を受ける連携システム３００がなければ、フローが終了する。

ステップＳ５４において、共通データベース１８０は、影響を受ける連携システム３００に送信する情報をインタフェース部１７０に出力する。

ステップＳ５５において、インタフェース部１７０は、ステップＳ５４で共通データベース１８０から出力された情報を送信先の連携システム３００の登録情報の形式に合うように加工する。

ステップＳ５６において、インタフェース部１７０は、ステップＳ５５で加工した情報を、該当する連携システム３００に出力する。

このように、インタフェース部１７０は、資源予約情報１８２が更新された場合に、資源予約情報１８２の更新内容を複数の連携システム３００に通知する。

登録部１３０により第１案件のスケジュールが共通データベース１８０に登録された場合には、インタフェース部１７０は、登録部１３０により記録された第１案件に対する複数種類の資源の割り当て結果を複数の連携システム３００に通知する。すなわち、インタフェース部１７０は、新たな未承認案件に対する複数種類の資源の割り当て結果が共通データベース１８０に記録された場合に、記録された割り当て結果を複数の連携システム３００に通知する。つまり、インタフェース部１７０は、第３情報１９８が共通データベース１８０に記録された場合に、第３情報１９８を連携システム３００に通知して資源の空き状況または供給状況とは別に記録させる。ただし、重複する複数スケジュール案を持てない連携システム３００は、通知対象から除外される。

更新部１４０により第１案件のスケジュールが新たな承認済案件のスケジュールとして共通データベース１８０に登録し直された場合には、インタフェース部１７０は、更新部１４０による資源予約情報１８２の更新内容を複数の連携システム３００に通知する。つまり、インタフェース部１７０は、新たな未承認案件が承認され、当該新たな未承認案件に対する資源の割り当て結果に応じて共通データベース１８０の第２情報１９７が更新された場合に、第２情報１９７の更新内容を連携システム３００に通知して連携システム３００の記録内容を更新させる。また、インタフェース部１７０は、資源の割り当て状況に変化が生じた承認済案件があり、生じた変化に合わせて共通データベース１８０の第２情報１９７が更新された場合にも、第２情報１９７の更新内容を連携システム３００に通知して連携システム３００の記録内容を更新させる。

本実施の形態では、インタフェース部１７０は、複数種類の資源のうち少なくとも１種類の資源について共通データベース１８０の第２情報１９７が更新された場合に、第２情報１９７の更新内容を、互いに異なる種類の資源の空き状況または供給状況を記録する複数の連携システム３００のうち該当する連携システム３００に通知して当該連携システム３００の記録内容を更新させる。なお、資源の種類が１種類のみ、連携システム３００の数が１つのみでも本実施の形態を適用することができる。つまり、インタフェース部１７０は、共通データベース１８０の第２情報１９７が更新された場合に、第２情報１９７の更新内容を、その１種類の資源の空き状況または供給状況を記録する連携システム３００に通知して当該連携システム３００の記録内容を更新させてもよい。

共通データベース１８０の第２情報１９７が更新される場合に、共通データベース１８０の第１情報１９６は、第２情報１９７の更新と同時に更新されてもよいし、連携システム３００から通知があったときに更新されてもよい。前者の場合は、単に第２情報１９７の更新内容に合わせて第１情報１９６が更新される。後者の場合は、インタフェース部１７０が第２情報１９７の更新内容を連携システム３００に通知して連携システム３００の記録内容を更新させた後、その更新に伴ってインタフェース部１７０が連携システム３００から資源の空き状況または供給状況の変化の通知を受けたときに、通知された変化に合わせて第１情報１９６が更新される。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態では、新たな案件のスケジュールを、他の案件のスケジュールを変更することを前提に作成できるようにしつつ、実際に変更が適用される場合に対象案件の管理者が通知を受けられるようにしている。そのため、新たな案件のスケジュールを、他の案件のスケジュールとの競合を避けつつ、迅速に作成することができる。

従来は、業務にサイロ化している複数のシステムを導入している場合、システム間の情報連携をユーザが行う必要がある。システム化されていない複数システム間の情報連携は、ユーザの負荷となり、常に全システムで最新の情報を共有することが難しく、チェック漏れ等のヒューマンエラーを誘発しやすい。本実施の形態では、スケジュール管理システム１００が、システム間連携を行うインタフェース部１７０と、共通データベース１８０とを持ち、インタフェース部１７０経由で各システムから抽出したデータを共通データベース１８０で一元管理する。共通データベース１８０を参照することで、各システムが個別に保持していた工程検討に必要な情報を一元的に参照できる。各システムで実施されたデータ変更は、変更をトリガとしたデータ送信が可能なシステムは変更タイミングで、可能でないものは設定周期ごとに共通データベース１８０へ最新データをアップすることで、工程に影響のあるイベントまたは工程遅延が発生した際、発報と代替案提示とを行うことができる。

本実施の形態では、生産スケジュールを検討する際に、設備管理システム３０１で設備の空き状況、在庫管理システム３０３で部品の在庫状況、勤怠管理システム３０２で作業者の空き状況を調べて検討するといったことは必要なくなる。よって、顧客から新たな案件の依頼を受けた場合に、納期の回答をすぐに出すことができる。

本実施の形態では、新たな案件が承認された場合に、その案件に対する資源の割り当て結果に応じたデータベースの更新内容が、該当する資源の空き状況または供給状況を記録する連携システムに通知されて連携システムの記録内容が更新されるようにしている。そのため、新たな案件が承認された場合に、その案件に必要な資源を確保するための情報共有を迅速に行うことができる。

＊＊＊他の構成＊＊＊
本実施の形態では、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の機能がソフトウェアにより実現されるが、変形例として、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。すなわち、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の機能の一部が専用のハードウェアにより実現され、残りがソフトウェアにより実現されてもよい。

専用のハードウェアは、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ、ＦＰＧＡまたはＡＳＩＣである。「ＩＣ」は、Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。「ＧＡ」は、Ｇａｔｅ Ａｒｒａｙの略語である。「ＦＰＧＡ」は、Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略語である。「ＡＳＩＣ」は、Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。

プロセッサ１０１および専用のハードウェアは、いずれも処理回路である。すなわち、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の機能がソフトウェアにより実現されるか、ソフトウェアとハードウェアとの組み合わせにより実現されるかに関わらず、設定部１１０、作成部１２０、登録部１３０、更新部１４０、消去部１５０、判定部１６０およびインタフェース部１７０の動作は、処理回路により行われる。

１００ スケジュール管理システム、１０１ プロセッサ、１０２ メモリ、１０３ 補助記憶装置、１０４ 入力機器、１０５ ディスプレイ、１０６ 通信装置、１１０ 設定部、１２０ 作成部、１３０ 登録部、１４０ 更新部、１５０ 消去部、１６０ 判定部、１７０ インタフェース部、１８０ 共通データベース、１８１ 案件情報、１８２ 資源予約情報、１８３ 進捗情報、１８４ データ取り込み周期情報、１９１ 設備情報、１９２ 人員情報、１９３ 在庫情報、１９４ 変更通知情報、１９５ 消去通知情報、１９６ 第１情報、１９７ 第２情報、１９８ 第３情報、２００ ユーザ端末、３００ 連携システム、３０１ 設備管理システム、３０２ 勤怠管理システム、３０３ 在庫管理システム、３０４ 受注管理システム、３０５ 進捗管理システム。

Claims (13)

1. 新たな未承認案件である第１案件のスケジュールを、データベースに登録された個別の承認済案件のスケジュールを変更することを前提に作成してよいかどうかの設定を検討条件の設定として受ける設定部と、
   前記データベースを参照して、
   前記設定部が受けた前記検討条件の設定が前記個別の承認済案件のスケジュールを変更することを前提にしている場合に、前記個別の承認済案件のうち前記検討条件に設定されたスケジュール変更を許可する条件に一致した承認済案件のスケジュールを変更することを前提として前記第１案件のスケジュールを作成し、
   前記設定部が受けた前記検討条件の設定が前記個別の承認済案件のスケジュールを変更することを前提にしていない場合に、前記個別の承認済案件のスケジュールを変更しないことを前提として前記第１案件のスケジュールを作成する作成部と、
   前記作成部により作成された前記第１案件のスケジュールを前記データベースに登録するとともに、前記第１案件のスケジュールが、前記データベースに登録された承認済案件である第２案件のスケジュールを変更することを前提に作成されていれば、前記第１案件が承認された場合に前記第２案件のスケジュールの変更を前記第２案件の管理者に通知するための変更通知情報を前記データベースに記録する登録部と
   を備えるスケジュール管理システム。
2. 前記第１案件を承認する操作を受けて、前記第１案件のスケジュールを新たな承認済案件のスケジュールとして前記データベースに登録し直すとともに、前記データベースに前記変更通知情報が記録されていれば、前記変更通知情報に従い、前記第２案件のスケジュールの変更を前記第２案件の管理者に通知する更新部をさらに備える請求項１に記載のスケジュール管理システム。
3. 前記更新部は、前記第１案件のスケジュールを新たな承認済案件のスケジュールとして前記データベースに登録し直す際に、前記データベースに他の未承認案件のスケジュールが登録されていれば、前記第１案件のスケジュールの登録を前記他の未承認案件の管理者に通知する請求項２に記載のスケジュール管理システム。
4. 前記設定部は、前記第１案件のスケジュールを、前記データベースに登録された個別の未承認案件のスケジュールとの競合を避けることを前提に作成すべきかどうかの設定をさらに前記検討条件の設定として受け、
   前記登録部は、前記第１案件のスケジュールが、前記データベースに登録された未承認案件である第３案件のスケジュールとの競合を避けることを前提に作成されていれば、前記第３案件がキャンセルされた場合に前記第３案件のスケジュールの消去を前記第１案件の管理者に通知するための消去通知情報を前記データベースに記録する請求項１から３のいずれか１項に記載のスケジュール管理システム。
5. 前記第３案件をキャンセルする操作を受けて、前記第３案件のスケジュールを前記データベースから消去するとともに、前記データベースに前記消去通知情報が記録されていれば、前記消去通知情報に従い、前記第３案件のスケジュールの消去を前記第１案件の管理者に通知する消去部をさらに備える請求項４に記載のスケジュール管理システム。
6. 前記設定部は、前記データベースに登録された未承認案件の中から前記第３案件として扱う未承認案件を選択するための選択条件の設定を受ける請求項４または５に記載のスケジュール管理システム。
7. 前記設定部は、前記第１案件のスケジュールを、前記データベースに登録された個別の未承認案件のスケジュールを変更することを前提に作成してよいかどうかの設定をさらに前記検討条件の設定として受け、
   前記登録部は、前記第１案件のスケジュールが、前記データベースに登録された未承認案件である第３案件のスケジュールを変更することを前提に作成されていれば、前記第１案件が承認された場合に前記第３案件のスケジュールの変更を前記第３案件の管理者に通知するための情報をさらに前記変更通知情報として前記データベースに記録する請求項１から３のいずれか１項に記載のスケジュール管理システム。
8. 前記作成部は、前記データベースに記録され、複数種類の資源の空き状況または供給状況と前記個別の承認済案件に対する前記複数種類の資源の割り当て状況とを示す資源予約情報を参照して、前記第１案件に前記複数種類の資源を割り当てることで、前記第１案件のスケジュールを作成し、
   前記登録部は、前記作成部による前記第１案件に対する前記複数種類の資源の割り当て結果を前記データベースに記録することで、前記第１案件のスケジュールを前記データベースに登録する請求項１に記載のスケジュール管理システム。
9. 前記登録部により記録された前記第１案件に対する前記複数種類の資源の割り当て結果を、互いに異なる種類の資源の空き状況または供給状況を記録する複数の連携システムに通知するインタフェース部をさらに備える請求項８に記載のスケジュール管理システム。
10. 前記第１案件を承認する操作を受けて、前記登録部により記録された前記第１案件に対する前記複数種類の資源の割り当て結果に応じて前記資源予約情報を更新することで、前記第１案件のスケジュールを新たな承認済案件のスケジュールとして前記データベースに登録し直す更新部をさらに備える請求項８に記載のスケジュール管理システム。
11. 前記更新部による前記資源予約情報の更新内容を、互いに異なる種類の資源の空き状況または供給状況を記録する複数の連携システムに通知するインタフェース部をさらに備える請求項１０に記載のスケジュール管理システム。
12. 互いに異なる種類の資源の空き状況または供給状況を記録する複数の連携システムのうちいずれかの連携システムから、該当する種類の資源の空き状況または供給状況の変化の通知を受け、通知された変化に合わせて前記資源予約情報を更新するインタフェース部と、
    前記インタフェース部による前記資源予約情報の更新内容に応じて、前記データベースに登録された承認済案件ごとに、前記該当する種類の資源の割り当てを変更するかどうかを判定し、判定結果を少なくとも前記該当する種類の資源の割り当てを変更すると判定した承認済案件の管理者に通知する判定部と
    をさらに備える請求項８または１０に記載のスケジュール管理システム。
13. コンピュータに、
    新たな未承認案件である第１案件のスケジュールを、データベースに登録された個別の承認済案件のスケジュールを変更することを前提に作成してよいかどうかの設定を検討条件の設定として受ける設定処理と、
    前記データベースを参照して、
    前記設定処理により受けた前記検討条件の設定が前記個別の承認済案件のスケジュールを変更することを前提にしている場合に、前記個別の承認済案件のうち前記検討条件に設定されたスケジュール変更を許可する条件に一致した承認済案件のスケジュールを変更することを前提として前記第１案件のスケジュールを作成し、
    前記設定処理により受けた前記検討条件の設定が前記個別の承認済案件のスケジュールを変更することを前提にしていない場合に、前記個別の承認済案件のスケジュールを変更しないことを前提として前記第１案件のスケジュールを作成する作成処理と、
    前記作成処理により作成された前記第１案件のスケジュールを前記データベースに登録するとともに、前記第１案件のスケジュールが、前記データベースに登録された承認済案件である第２案件のスケジュールを変更することを前提に作成されていれば、前記第１案件が承認された場合に前記第２案件のスケジュールの変更を前記第２案件の管理者に通知するための変更通知情報を前記データベースに記録する登録処理と
    を実行させるスケジュール管理プログラム。

Images