以下、本発明の実施の形態について、図を用いて説明する。各図中、同一または相当する部分には、同一符号を付している。実施の形態の説明において、同一または相当する部分については、説明を適宜省略または簡略化する。なお、本発明は、以下に説明する実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。例えば、以下に説明する実施の形態は、部分的に実施されても構わない。
実施の形態1.
本実施の形態について、図1から図16を用いて説明する。
***構成の説明***
図1を参照して、本実施の形態に係るスケジュール管理システム100の構成を説明する。
スケジュール管理システム100は、任意のスケジュールを管理するシステムでよいが、本実施の形態では製造工場の生産スケジュールを管理するシステムである。スケジュール管理システム100は、1つの案件につき、1つのスケジュールを作成して管理する。個々のスケジュールは、1つ以上の工程からなる。
スケジュール管理システム100は、図示していないLANまたはインターネット等のネットワークを介して複数のユーザ端末200と通信を行う。「LAN」は、Local Area Networkの略語である。それぞれのユーザ端末200は、生産スケジュールの管理者によって利用されるPC、タブレットまたはスマートフォン等の端末である。「PC」は、Personal Computerの略語である。
スケジュール管理システム100は、図示していないLANまたはインターネット等のネットワークを介して複数の連携システム300とも通信を行う。これら複数の連携システム300は、互いに異なる種類の資源の空き状況または供給状況を記録するシステムである。資源とは、設備、人員および部品在庫等、生産に必要なもののことである。本実施の形態では、連携システム300として、設備管理システム301、勤怠管理システム302、在庫管理システム303、受注管理システム304および進捗管理システム305等がある。
スケジュール管理システム100は、設定部110と、作成部120と、登録部130と、更新部140と、消去部150と、判定部160と、インタフェース部170と、共通データベース180とを備える。
スケジュール管理システム100は、インタフェース部170経由で各連携システム300から抽出したデータを共通データベース180で一元管理する。共通データベース180を参照することで、各連携システム300が個別に保持している、工程検討に必要な情報を一元的に参照できる。各連携システム300でデータ変更が実施された場合は、変更をトリガとしたデータ送信が可能な連携システム300からは変更タイミングで、可能でないものからは設定周期ごとに共通データベース180へ最新データをアップすることで、共通データベース180内の情報を最新に保つことができる。
スケジュール管理システム100は、共通データベース180に保存された情報より演算処理で自動的に工程案を作成することができる。工程案としては、単純に設備の空き状況、人員の空き状況、および、在庫状況等から生成されるもののみでなく、優先度による既存工程の組み換えおよびクラッシングによる短縮案等も生成可能とする。
連携システム300の情報が更新され、工程に影響のあるイベントまたは工程遅延が発生した場合、スケジュール管理システム100は、発報と代替案提示とを行うことができる。
各連携システム300が共通データベース180を参照可能とすれば、連携システム300ごとでの重複した情報入力を省略することができる。
スケジュール管理システム100は、ローカルサーバまたはクラウドサーバ等のコンピュータである。スケジュール管理システム100は、プロセッサ101を備えるとともに、メモリ102、補助記憶装置103、入力機器104、ディスプレイ105および通信装置106といった他のハードウェアを備える。プロセッサ101は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の機能は、ソフトウェアにより実現される。共通データベース180は、メモリ102に構築されてもよいが、本実施の形態では補助記憶装置103に構築される。
プロセッサ101は、スケジュール管理プログラムを実行する装置である。スケジュール管理プログラムは、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の機能を実現するプログラムである。プロセッサ101は、例えば、CPUである。「CPU」は、Central Processing Unitの略語である。
メモリ102および補助記憶装置103は、スケジュール管理プログラムを記憶する装置である。メモリ102は、例えば、フラッシュメモリまたはRAMである。「RAM」は、Random Access Memoryの略語である。補助記憶装置103は、例えば、フラッシュメモリまたはHDDである。「HDD」は、Hard Disk Driveの略語である。
入力機器104は、スケジュール管理プログラムへのデータの入力のために操作される機器である。入力機器104は、例えば、マウス、キーボードまたはタッチパネルである。
ディスプレイ105は、スケジュール管理プログラムから出力されるデータを画面に表示する機器である。ディスプレイ105は、例えば、LCDである。「LCD」は、Liquid Crystal Displayの略語である。
通信装置106は、スケジュール管理プログラムに入力されるデータを受信するレシーバと、スケジュール管理プログラムから出力されるデータを送信するトランスミッタとを含む。通信装置106は、例えば、通信チップまたはNICである。「NIC」は、Network Interface Cardの略語である。レシーバは、各ユーザ端末200および各連携システム300からデータを受信するために利用される。トランスミッタは、各ユーザ端末200および各連携システム300にデータを送信するために利用される。
スケジュール管理プログラムは、補助記憶装置103からメモリ102にロードされ、プロセッサ101に読み込まれ、プロセッサ101によって実行される。補助記憶装置103には、スケジュール管理プログラムだけでなく、OSも記憶されている。「OS」は、Operating Systemの略語である。プロセッサ101は、OSを実行しながら、スケジュール管理プログラムを実行する。
なお、スケジュール管理プログラムの一部または全部がOSに組み込まれていてもよい。
スケジュール管理システム100は、プロセッサ101を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、スケジュール管理プログラムの実行を分担する。それぞれのプロセッサは、例えば、CPUである。
スケジュール管理プログラムにより利用、処理または出力されるデータ、情報、信号値および変数値は、メモリ102、補助記憶装置103、または、プロセッサ101内のレジスタまたはキャッシュメモリに記憶される。
スケジュール管理プログラムは、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170により行われる処理をそれぞれ設定処理、作成処理、登録処理、更新処理、消去処理、判定処理およびインタフェース処理としてコンピュータに実行させるプログラムである。スケジュール管理プログラムは、コンピュータ読取可能な媒体に記録されて提供されてもよいし、記録媒体に格納されて提供されてもよいし、プログラムプロダクトとして提供されてもよい。
スケジュール管理システム100は、1台のコンピュータで構成されていてもよいし、複数台のコンピュータで構成されていてもよい。スケジュール管理システム100が複数台のコンピュータで構成されている場合は、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の機能が、各コンピュータに分散されて実現されてもよい。
共通データベース180は、スケジュール検討に必要であり、他の連携システム300と共通で扱う案件ごとに更新されるような情報と、プル型の情報取得が必要な連携システム300に対するデータ取得の周期を示す情報とを持つ。具体的には、共通データベース180は、案件情報181、資源予約情報182、進捗情報183およびデータ取り込み周期情報184を持つ。
図2に案件情報181の例を示す。
案件情報181としては、案件番号、登録者、商談確度、スケジュール承認状態、優先度、機種、数量、商談規模、納期および納期調整可能範囲等が記録される。登録者は、案件を登録した、その案件のスケジュールの管理者のことである。機種は、複数指定可能である。数量および納期は、機種ごとに設定可能である。
案件番号とは、案件ごとに割り当てられるユニークな番号のことである。変更管理用に副番を持つ場合もある。商談確度とは、受注済であるか、未受注であるか、また未受注であれば、受注の確度のことである。機種とは、製品の種別のことである。納期調整可能範囲とは、設定中の納期から後ろ倒し可能と想定される期間のことである。納期と発注元の運用開始日との間に差があり、調整余地がある場合、あるいは、量産品で在庫品の融通にて調整可能な場合等は、納期調整可能範囲が0日よりも大きい値に設定される。
図3に資源予約情報182の例を示す。
資源予約情報182には、設備情報191、人員情報192および在庫情報193等が含まれる。設備情報191、人員情報192および在庫情報193等、検討されたスケジュールに応じて予定を押さえる必要がある情報については、公式に承認された予約状況が承認済スケジュールとして登録され、案件番号に紐付く未承認の仮予約情報が検討中案件として登録される。
承認済スケジュールとは、スケジュール管理システム100上で公式に承認されたスケジュールのことである。検討中案件とは、登録中案件のうち、スケジュールが承認されていない案件のことであり、商談確度が受注済であるか、未受注であるかは関係しない。登録中案件とは、共通データベース180に登録されている全案件のことであり、商談確度およびスケジュール承認状態を問わず、すべての案件を指す。検討中案件のスケジュールが承認されると、その検討中案件は承認済案件となり、承認済スケジュールに組み込まれる。承認済案件については、検討中案件と同様に、商談確度が受注済であるか、未受注であるかは関係しない。
設備情報191としては、設備名および予約状況等が記録される。予約状況としては、開始日、終了日および予約理由等が記録される。予約理由としては、案件での使用であればその案件番号、メンテナンスまたは故障等であればその旨が記録される。
人員情報192としては、人員名および予約状況等が記録される。予約状況としては、開始日、終了日および予約理由等が記録される。予約理由としては、案件への対応であればその案件番号、休暇または出張等であればその旨が記録される。
在庫情報193としては、部品名、在庫数量、予約状況および入着状況等が記録される。予約状況としては、案件番号、数量および使用タイミングが記録される。入着状況としては、案件番号、数量および入着タイミングが記録される。
設備情報191には、承認済スケジュールおよび検討中案件の情報とは別に、設備管理システム301からの入力情報が含まれる。人員情報192にも、承認済スケジュールおよび検討中案件の情報とは別に、勤怠管理システム302からの入力情報が含まれる。在庫情報193にも、承認済スケジュールおよび検討中案件の情報とは別に、在庫管理システム303からの入力情報が含まれる。これらの連携システム300からの入力情報は、予約理由によって変更不可の予定として承認済スケジュールおよび検討中案件に反映される。
検討中案件の情報には、後述する変更通知情報194および消去通知情報195のいずれかまたは両方が含まれる場合がある。
資源予約情報182に含まれる、各連携システム300からの入力情報は、資源の空き状況または供給状況を示す第1情報196に相当する。具体的には、設備情報191に含まれる、設備管理システム301からの入力情報は、設備の空き状況を示す第1情報196に相当する。人員情報192に含まれる、勤怠管理システム302からの入力情報は、人員の空き状況を示す第1情報196に相当する。在庫情報193に含まれる、在庫管理システム303からの入力情報は、部品の供給状況を示す第1情報196に相当する。
資源予約情報182に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する資源の割り当て状況を示す第2情報197に相当する。具体的には、設備情報191に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する設備の割り当て状況を示す第2情報197に相当する。人員情報192に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する人員の割り当て状況を示す第2情報197に相当する。在庫情報193に含まれる、承認済スケジュールの情報は、個別の承認済案件に対する部品の割り当て状況を示す第2情報197に相当する。
このように、本実施の形態では、資源予約情報182に、複数種類の資源の空き状況または供給状況を示す情報が第1情報196として含まれ、個別の承認済案件に対する複数種類の資源の割り当て状況を示す情報が第2情報197として含まれている。なお、変形例として、資源予約情報182に、1種類のみの資源の空き状況または供給状況を示す情報が第1情報196として含まれ、個別の承認済案件に対する1種類のみの資源の割り当て状況を示す情報が第2情報197として含まれていてもよい。
資源予約情報182に含まれる、検討中案件の情報は、新たな未承認案件に対する資源の割り当て結果を示す第3情報198に相当する。具体的には、設備情報191に含まれる、検討中案件の情報は、新たな未承認案件に対する設備の割り当て結果を示す第3情報198に相当する。人員情報192に含まれる、検討中案件の情報は、新たな未承認案件に対する人員の割り当て結果を示す第3情報198に相当する。在庫情報193に含まれる、検討中案件の情報は、新たな未承認案件に対する部品の割り当て結果を示す第3情報198に相当する。
このように、本実施の形態では、新たな未承認案件に資源が割り当てられた場合に、当該新たな未承認案件に対する資源の割り当て結果を示す第3情報198が、資源予約情報182の一部として共通データベース180に記録される。
後述するように、資源予約情報182は、新たな未承認案件に資源が割り当てられる際に参照される。資源予約情報182に含まれる第2情報197は、新たな未承認案件が承認された場合に、当該新たな未承認案件に対する資源の割り当て結果に応じて更新される。また、第2情報197は、資源の割り当て状況に変化が生じた承認済案件がある場合に、生じた変化に合わせて更新される。
図4に進捗情報183の例を示す。
進捗情報183としては、案件番号、工程名および進捗状況が記録される。
図5にデータ取り込み周期情報184の例を示す。
データ取り込み周期情報184としては、連携システム300の名称であるシステム名、および、周期が記録される。
以上の情報のほかに、スケジュール検討に必要だが、案件ごとに更新される可能性が低く、必要に応じて更新し、ライブラリ情報として参照すればよいような情報もある。具体例としては、機種ごとに、使用部材および製造工程等を示す情報がある。製造工程としては、使用設備およびその使用期間、使用人員およびその使用期間、および、工程間の順序が記録される。設備ごとに、処理能力、および、生産機種切り替え時の所要時間等を示す情報もある。生産機種切り替え時の所要時間が一律でない場合は各パターンが網羅される。人員ごとに、各工程を担当した場合の処理能力等を示す情報もある。部品ごとに、リードタイム等を示す情報もある。注意値および警告値等の進捗遅延警告に関する情報もある。工程名および○日前等の工程順序変更可能期間に関する情報もある。こういった情報は、共通データベース180に保持されてもよいし、補助記憶装置103の他の領域に保持されてもよい。
***動作の説明***
図1から図5のほかに、図6から図16を参照して、本実施の形態に係るスケジュール管理システム100の動作を説明する。スケジュール管理システム100の動作は、本実施の形態に係るスケジュール管理方法に相当する。
図6にスケジュールを作成する際のフローを示す。
図6のフローが開始されるトリガとして、新たな未承認案件である第1案件についての案件情報181が第1案件の登録者のユーザ端末200から入力されたとする。
ステップS11において、設定部110は、第1案件のスケジュールを、共通データベース180に登録された個別の承認済案件のスケジュールを変更することを前提に作成してよいかどうかの設定を検討条件の設定として受ける。
本実施の形態では、設定部110は、第1案件のスケジュールを、共通データベース180に登録された個別の未承認案件のスケジュールとの競合を避けることを前提に作成すべきかどうかの設定をさらに検討条件の設定として受ける。
本実施の形態では、設定部110は、第1案件のスケジュールが、共通データベース180に登録された未承認案件である第3案件のスケジュールとの競合を避けることを前提に作成される場合に、共通データベース180に登録された未承認案件の中から第3案件として扱う未承認案件を選択するための選択条件の設定も受ける。
本実施の形態では、設定部110は、第1案件のスケジュールを、共通データベース180に登録された個別の未承認案件のスケジュールを変更することを前提に作成してよいかどうかの設定をさらに検討条件の設定として受ける。
具体的には、設定部110は、図7から図10に示す検討条件および選択条件の入力を第1案件の登録者のユーザ端末200から受ける。図7から図10において、大項目は独立して取り扱い、参照条件は各大項目の組み合わせで決定するものとする。
図7に示すように、承認済スケジュールの取り扱いについては、
・承認済スケジュールの変更を許可するかどうか
・承認済スケジュールの変更を許可する場合、納期超過を許容するかどうか
・納期超過を許容する場合、納期調整範囲を超えた納期超過を許容するかどうか
が設定される。
図8および図9に示すように、検討中スケジュールの取り扱いについては、
・検討中案件を考慮に入れるかどうか
・検討中案件を考慮に入れる場合の基準、すなわち、選択条件
・検討中案件を考慮に入れる場合、検討中案件のスケジュール変更を許可するかどうか
・検討中案件のスケジュールの変更を許可する場合、納期超過を許容するかどうか
・納期超過を許容する場合、納期調整範囲を超えた納期超過を許容するかどうか
が設定される。
図10に示すように、クラッシングの取り扱いについては、
・クラッシングによる期間短縮を行うかどうか
・クラッシングを行う場合、対象は入力案件のみかどうか
・クラッシングを行う場合、どの工程にどの程度までリソース追加可能か
が設定される。
ステップS12において、作成部120は、共通データベース180を参照して、個別の承認済案件のスケジュールと競合せず、かつ、設定部110に設定された検討条件を満たすスケジュールを第1案件のスケジュールとして作成する。
具体的には、作成部120は、共通データベース180に記録され、複数種類の資源の空き状況または供給状況と個別の承認済案件に対する複数種類の資源の割り当て状況とを示す資源予約情報182を参照して、第1案件に複数種類の資源を割り当てることで、第1案件のスケジュールを作成する。
より具体的には、作成部120は、資源予約情報182に含まれる情報を加工して既存の工程自動作成ツールに与えて工程自動作成ツールを実行することで、資源予約情報182に含まれる承認済スケジュールと競合せず、かつ、ステップS11で入力された検討条件を満たすスケジュールを第1案件のスケジュールとして作成する。工程自動作成ツールには、スケジュールの自動作成および自動調整の基本的な機能が備わっていればよい。
例として、図11に示すような登録中案件があった場合に、新規案件Fについて作成されるスケジュールが検討条件によってどのように変わるかを図12に示す。簡略化のため、1種類の資源のみを想定する。検討条件としては、様々なものが考えられるが、本例では以下の4つを想定する。
・条件C1:承認済スケジュールの変更を許可しない。検討中案件を考慮しない。入力案件のクラッシングを行わない。
・条件C2:承認済スケジュールの変更を許可しない。検討中案件を考慮しない。入力案件のクラッシングを行う。工程および追加人数は制限する。
・条件C3:承認済スケジュールおよび検討中案件の変更を許可する。優先度「低」以下の案件の納期調整範囲を超えての遅延を許可する。優先度「高」以上の検討中案件を考慮に入れる。
・条件C4:承認済スケジュールの変更を許可しない。入力案件のクラッシングを行う。工程および追加人数は制限する。商談確度「中」以上の検討中案件を考慮に入れる。検討中案件のスケジュール変更を許可する。低優先度案件の納期遅延を許可する。
ステップS13において、作成部120は、ステップS12で作成した第1案件のスケジュールが納期内に完了するようになっているかを判定する。納期内に完了するようになっていなければ、ステップS14の処理が行われる。納期内に完了するようになっていれば、ステップS16の処理が行われる。
ステップS14において、作成部120は、ステップS12で作成した第1案件のスケジュールが納期を超過する要因と、その超過日数とを第1案件の登録者のユーザ端末200に出力する。
ステップS15において、第1案件についての案件情報181が変更され、変更後の案件情報181が第1案件の登録者のユーザ端末200から入力されれば、ステップS11の処理が再び行われる。そのような案件情報181が入力されなければ、ステップS16の処理が行われる。
ステップS16において、ステップS12で作成された第1案件のスケジュールを共通データベース180に登録することを指示する操作が第1案件の登録者のユーザ端末200で行われれば、ステップS17の処理が行われる。そのような操作が行われなければ、フローが終了する。
ステップS17において、登録部130は、作成部120により作成された第1案件のスケジュールを共通データベース180に登録する。
具体的には、登録部130は、作成部120による第1案件に対する複数種類の資源の割り当て結果を共通データベース180に記録することで、第1案件のスケジュールを共通データベース180に登録する。
登録部130は、登録した第1案件のスケジュールが、共通データベース180に登録された承認済案件である第2案件のスケジュールを変更することを前提に作成されていれば、第1案件が承認された場合に第2案件のスケジュールの変更を第2案件の管理者に通知するための変更通知情報194を共通データベース180に記録する。
登録部130は、登録した第1案件のスケジュールが、共通データベース180に登録された未承認案件である第3案件のスケジュールとの競合を避けることを前提に作成されていれば、第3案件がキャンセルされた場合に第3案件のスケジュールの消去を第1案件の管理者に通知するための消去通知情報195を共通データベース180に記録する。
登録部130は、登録した第1案件のスケジュールが共通データベース180に登録された未承認案件である第3案件のスケジュールを変更することを前提に作成されていれば、第1案件が承認された場合に第3案件のスケジュールの変更を第3案件の管理者に通知するための情報をさらに変更通知情報194として共通データベース180に記録する。
より具体的には、登録部130は、第1案件に案件番号を付与し、その案件番号とともに、ステップS12で作成された第1案件に対する設備、人員および部品在庫の割り当て結果を、それぞれ共通データベース180の設備情報191、人員情報192および在庫情報193に追加する。
図11および図12に示した例では、案件Fが第1案件、案件A、案件Bおよび案件Cが第2案件、案件Dおよび案件Eが第3案件に相当する。
設定部110に設定された検討条件が条件C1であるとする。その場合、作成部120は、新規案件である案件Fのスケジュールを、承認済案件である案件A、案件Bおよび案件Cのスケジュールとの競合を避けることを前提に作成する。案件A、案件Bおよび案件Cのスケジュールを変更することは前提になっていない。検討中案件である案件Dおよび案件Eのスケジュールとの競合を避けることも前提になっていない。結果として、案件Fのスケジュールには遅延が生じており、また、案件Fのスケジュールは案件Dおよび案件Eのスケジュールと重複しているが、登録部130は、案件Fのスケジュールを未承認案件のスケジュールとしてそのまま共通データベース180に登録する。なお、変更通知情報194および消去通知情報195は記録されない。
設定部110に設定された検討条件が条件C2である場合は、案件Fのクラッシングが許可されているため、遅延が解消するという点を除けば、検討条件が条件C1である場合と同じである。
設定部110に設定された検討条件が条件C3であるとする。その場合、作成部120は、新規案件である案件Fのスケジュールを、承認済案件である案件A、案件Bおよび案件Cのスケジュールとの競合を避けること、低優先度案件である案件Bのスケジュールを変更すること、および、高優先度の検討中案件である案件Dのスケジュールを変更することを前提に作成する。高優先度案件である案件A、および、中優先度案件である案件Cのスケジュールを変更することは前提になっていない。低優先度の検討中案件である案件Eのスケジュールとの競合を避けることも前提になっていない。結果として、案件Fのスケジュールは案件Bに遅延を生じさせることになり、また、案件Fのスケジュールは案件Eのスケジュールと重複しているが、登録部130は、案件Fのスケジュールを未承認案件のスケジュールとしてそのまま共通データベース180に登録する。案件Bのスケジュールは案件Fが承認された場合に変更されることになるため、登録部130は、案件Bの案件番号を示す変更通知情報194を案件Fの案件番号またはスケジュールに紐付けて共通データベース180に記録する。案件Dがスケジュール変更なしで承認されると仮定すると、案件Dのスケジュールも案件Fが承認された場合に変更されることになるため、登録部130により記録される変更通知情報194には、案件Bの案件番号だけでなく、案件Fの案件番号も示されている。案件Fのスケジュールは案件Dがキャンセルされた場合に案件Dを考慮する必要がなくなるため、登録部130は、案件Fの案件番号を示す消去通知情報195を案件Dの案件番号またはスケジュールに紐付けて共通データベース180に記録する。なお、案件Fのスケジュールに遅延が生じていない場合、あるいは、案件Fのスケジュールに遅延が生じているが、案件Dがキャンセルされても遅延が解消しない場合は、消去通知情報195が記録されなくてもよい。
設定部110に設定された検討条件が条件C4であるとする。その場合、作成部120は、新規案件である案件Fのスケジュールを、承認済案件である案件A、案件Bおよび案件Cのスケジュールとの競合を避けること、および、高確度または中確度で受注可能な案件である案件Dおよび案件Eのスケジュールを変更することを前提に作成する。案件A、案件Bおよび案件Cのスケジュールを変更することは前提になっていない。案件Fのクラッシングは許可されている。結果として、案件Fのスケジュールは案件Eに遅延を生じさせることになるが、登録部130は、案件Fのスケジュールを未承認案件のスケジュールとしてそのまま共通データベース180に登録する。案件Dおよび案件Eがスケジュール変更なしで承認されると仮定すると、案件Dおよび案件Eのスケジュールは案件Fが承認された場合に変更されることになるため、登録部130は、案件Dおよび案件Eの案件番号を示す変更通知情報194を案件Fの案件番号またはスケジュールに紐付けて共通データベース180に記録する。案件Fのスケジュールは案件Dまたは案件Eがキャンセルされた場合に案件Dまたは案件Eを考慮する必要がなくなるため、登録部130は、案件Fの案件番号を示す消去通知情報195を案件Dおよび案件Eの案件番号またはスケジュールに紐付けて共通データベース180に記録する。なお、案件Fのスケジュールに遅延が生じていない場合、あるいは、案件Fのスケジュールに遅延が生じているが、案件Dおよび案件Eのいずれがキャンセルされても遅延が解消しない場合は、消去通知情報195が記録されなくてもよい。
図13に検討中案件のスケジュールを承認済スケジュールに更新する際のフローを示す。
図13のフローが開始されるトリガとして、第1案件を承認する操作が第1案件の承認権限者のユーザ端末200で行われたとする。
ステップS21およびステップS22において、更新部140は、第1案件を承認する操作を受けて、第1案件のスケジュールを新たな承認済案件のスケジュールとして共通データベース180に登録し直す。
具体的には、更新部140は、第1案件を承認する操作を受けて、登録部130により記録された第1案件に対する複数種類の資源の割り当て結果に応じて資源予約情報182を更新することで、第1案件のスケジュールを新たな承認済案件のスケジュールとして共通データベース180に登録し直す。
より具体的には、更新部140は、承認された第1案件のスケジュールを新たな承認済スケジュールとして共通データベース180の資源予約情報182に追加するとともに、承認された第1案件のスケジュールを共通データベース180の資源予約情報182の検討中案件から削除する。
ステップS23において、更新部140は、承認された第1案件の案件番号またはスケジュールに紐付く変更通知情報194が共通データベース180に記録されているかどうかを判定する。変更通知情報194が記録されていれば、ステップS24の処理が行われる。変更通知情報194が記録されていなければ、ステップS25の処理が行われる。
ステップS24において、更新部140は、変更通知情報194に従い、第2案件のスケジュールの変更を第2案件の管理者に通知する。
具体的には、更新部140は、変更通知情報194に示されている案件番号から、該当する案件の管理者のメールアドレスまたはその他の連絡先を特定して、その管理者にメール等で連絡する。
図11および図12に示した例において、案件Bの案件番号を示す変更通知情報194が案件Fの案件番号またはスケジュールに紐付けて共通データベース180に記録されていれば、更新部140は、案件Bの管理者にメール等で案件Bのスケジュールの変更を通知する。案件Dは承認済案件ではないが、案件Dの案件番号を示す変更通知情報194が案件Fの案件番号またはスケジュールに紐付けて共通データベース180に記録されていれば、更新部140は、案件Dの管理者にメール等で案件Dのスケジュールの変更を通知する。案件Eも承認済案件ではないが、案件Eの案件番号を示す変更通知情報194が案件Fの案件番号またはスケジュールに紐付けて共通データベース180に記録されていれば、更新部140は、案件Eの管理者にメール等で案件Dのスケジュールの変更を通知する。
ステップS25において、更新部140は、登録中案件に含まれる検討中案件すべての管理者にメール等で新たな承認済スケジュールの追加を通知する。すなわち、本実施の形態において、更新部140は、第1案件のスケジュールを新たな承認済案件のスケジュールとして共通データベース180に登録し直す際に、共通データベース180に他の未承認案件のスケジュールが登録されていれば、第1案件のスケジュールの登録を他の未承認案件の管理者に通知する。
ステップS24またはステップS25で通知を受けた管理者は、必要に応じて図6のフローにより対象案件のスケジュールを調整することができる。
図14にスケジュールを消去する際のフローを示す。
図14のフローが開始されるトリガとして、案件をキャンセルする操作が当該案件の管理者のユーザ端末200で行われたとする。
ステップS31において、消去部150は、共通データベース180の資源予約情報182を参照して、キャンセルされた案件が承認済案件であるかどうかを判定する。すなわち、消去部150は、キャンセルされた案件が第2案件であるか、それとも第3案件であるかを判定する。第2案件であれば、ステップS32の処理が行われる。第3案件であれば、ステップS36の処理が行われる。
ステップS32において、消去部150は、第2案件をキャンセルする操作を受けて、第2案件のスケジュールを共通データベース180から消去する。
具体的には、消去部150は、キャンセルされた第2案件のスケジュールを共通データベース180の資源予約情報182の承認済スケジュールから削除する。
ステップS33において、承認済スケジュールの最適化を自動的に実施することを指示する操作がユーザ端末200で行われれば、ステップS34の処理が行われる。そのような操作が行われなければ、ステップS35の処理が行われる。
ステップS34において、作成部120は、共通データベース180の資源予約情報182に残っている承認済スケジュールの情報を加工して工程自動作成ツールに与えて工程自動作成ツールを実行することで、承認済スケジュールの最適化を実施する。登録部130は、作成部120による最適化の実施結果に合わせて共通データベース180の資源予約情報182を更新する。
ステップS35において、消去部150は、登録中案件すべての管理者にメール等で共通データベース180の資源予約情報182の更新を通知する。その後、フローが終了する。
ステップS36において、消去部150は、第3案件をキャンセルする操作を受けて、第3案件のスケジュールを共通データベース180から消去する。
具体的には、消去部150は、キャンセルされた第3案件のスケジュールを共通データベース180の資源予約情報182の検討中案件から削除する。
ステップS37において、消去部150は、キャンセルされた第3案件の案件番号またはスケジュールに紐付く消去通知情報195が共通データベース180に記録されているかどうかを判定する。消去通知情報195が記録されていれば、ステップS38の処理が行われる。消去通知情報195が記録されていなければ、フローが終了する。
ステップS38において、消去部150は、消去通知情報195に従い、第3案件のスケジュールの消去を第1案件の管理者に通知する。
具体的には、消去部150は、消去通知情報195に示されている案件番号から、該当する案件の管理者のメールアドレスまたはその他の連絡先を特定して、その管理者にメール等で連絡する。
図11および図12に示した例において、キャンセルされた案件が案件Dであり、案件Fの案件番号を示す消去通知情報195が案件Dの案件番号またはスケジュールに紐付けて共通データベース180に記録されていれば、消去部150は、案件Dの管理者にメール等で案件Fのスケジュールの消去を通知する。同様に、キャンセルされた案件が案件Eであり、案件Fの案件番号を示す消去通知情報195が案件Eの案件番号またはスケジュールに紐付けて共通データベース180に記録されていれば、消去部150は、案件Eの管理者にメール等で案件Fのスケジュールの消去を通知する。
ステップS35またはステップS38で通知を受けた管理者は、必要に応じて図6のフローにより対象案件のスケジュールを調整することができる。
図15に連携システム300への情報入力により共通データベース180を更新する際のフローを示す。
図15のフローが開始されるトリガとして、登録中案件のスケジュールに影響を及ぼすような情報が、複数の連携システム300のうちいずれかの連携システム300へ入力されたとする。そのような情報の入力の例としては、
・設備管理システム301へのメンテナンス予定または故障情報の入力
・勤怠管理システム302への出張予定または休暇取得の入力
・在庫管理システム303への部品の手配情報または入着情報の入力
・受注管理システム304への受注または失注の入力
がある。
ステップS41において、情報の入力先の連携システム300が、情報の入力をトリガとして外部へ情報を出力可能なシステムであれば、ステップS42の処理が行われる。そのようなシステムでなければ、ステップS45の処理が行われる。
ステップS42において、情報の入力先の連携システム300からインタフェース部170に情報が出力される。インタフェース部170は、その連携システム300から、出力された情報、すなわち、該当する種類の資源の空き状況または供給状況の変化の通知を受ける。連携システム300が設備管理システム301であれば、インタフェース部170は、設備の空き状況の変化の通知を受ける。連携システム300が勤怠管理システム302であれば、インタフェース部170は、人員の空き状況の変化の通知を受ける。連携システム300が在庫管理システム303であれば、インタフェース部170は、部品の供給状況の変化の通知を受ける。
ステップS43において、インタフェース部170は、ステップS42で連携システム300から受け取った情報を共通データベース180の資源予約情報182の形式に合うように加工する。
ステップS44において、インタフェース部170は、ステップS43で加工した情報を共通データベース180に出力する。その後、ステップS47の処理が行われる。
ステップS45において、共通データベース180のデータ取り込み周期情報184に定義されたタイミングが到来すると、ステップS46の処理が行われる。
ステップS46において、共通データベース180は、インタフェース部170を介して連携システム300から情報を取り出す。
ステップS47において、共通データベース180は、インタフェース部170を介して取得した情報で資源予約情報182を更新する。すなわち、インタフェース部170は、連携システム300から通知された変化に合わせて共通データベース180の資源予約情報182を更新する。連携システム300が設備管理システム301であれば、インタフェース部170は、設備情報191を更新する。連携システム300が勤怠管理システム302であれば、インタフェース部170は、人員情報192を更新する。連携システム300が在庫管理システム303であれば、インタフェース部170は、在庫情報193を更新する。
ステップS48において、判定部160は、インタフェース部170による資源予約情報182の更新内容に応じて、共通データベース180に登録された承認済案件ごとに、該当する種類の資源の割り当てを変更するかどうかを判定する。本実施の形態では、判定部160は、さらに、インタフェース部170による資源予約情報182の更新内容に応じて、共通データベース180に登録された未承認案件ごとに、該当する種類の資源の割り当てを変更するかどうかを判定する。なお、判定部160は、該当する種類以外の種類の資源の割り当てを変更するかどうかも判定することが望ましい。
具体的には、判定部160は、ステップS47における資源予約情報182の更新の影響によりスケジュールの変更が必要となる案件を抽出する。
ステップS49において、判定部160は、ステップS48の判定結果を、少なくとも該当する種類の資源の割り当てを変更すると判定した承認済案件の管理者に通知する。本実施の形態では、判定部160は、ステップS48の判定結果を、該当する種類の資源の割り当てを変更すると判定した未承認案件の管理者にも通知する。
具体的には、判定部160は、ステップS48で資源予約情報182の更新の影響によりスケジュールの変更が必要となる案件を抽出していれば、抽出した案件の管理者にメール等で連絡する。
このように、本実施の形態では、インタフェース部170は、複数の連携システム300のうちいずれかの連携システム300から、該当する種類の資源の空き状況または供給状況の変化の通知を受けた場合に、通知された変化に合わせて共通データベース180の第1情報196を更新する。なお、資源の種類が1種類のみ、連携システム300の数が1つのみでも本実施の形態を適用することができる。つまり、インタフェース部170は、1つの連携システム300のみから、その1種類の資源の空き状況または供給状況の変化の通知を受け、通知された変化に合わせて共通データベース180の第1情報196を更新してもよい。
図16に共通データベース180から連携システム300へのフィードバックを行う際のフローを示す。
図16のフローが開始されるトリガとして、共通データベース180が更新されたとする。
このフローでは、既存の承認済案件に変更のない新規案件が承認された場合は、設備管理システム301に新規案件の設備使用スケジュールが出力され、勤怠管理システム302に新規案件の作業スケジュールが出力され、在庫管理システム303に新規案件の部品手配および使用予定が出力されることになる。
設備トラブルにより作業工程の一部に順番変更があった場合は、設備管理システム301に設備使用スケジュールの変更が出力され、勤怠管理システム302に作業スケジュールの変更が出力される。部品の手配タイミングに影響がなければ、在庫管理システム303に出力される変更はない。
遅延解消のため二交代制にすることで期間短縮を図る更新があった場合は、勤怠管理システム302に作業スケジュールの変更が出力される。設備使用期間に影響がなければ、設備管理システム301に出力される変更はない。
ステップS51において、判定部160は、共通データベース180の更新対象が承認済スケジュールであるかどうかを判定する。承認済スケジュールでなければ、ステップS52によって、ステップS53以降の処理では、重複する複数スケジュール案を持てない連携システム300が情報出力の対象外となる。
ステップS53において、判定部160は、連携システム300ごとに、該当する種類の資源の割り当てに変更があったかどうかを判定する。設備情報191が更新されたのであれば、インタフェース部170は、設備管理システム301の登録情報に影響があると判定する。人員情報192が更新されたのであれば、インタフェース部170は、勤怠管理システム302の登録情報に影響があると判定する。在庫情報193が更新されたのであれば、インタフェース部170は、在庫管理システム303の登録情報に影響があると判定する。影響を受ける連携システム300がなければ、フローが終了する。
ステップS54において、共通データベース180は、影響を受ける連携システム300に送信する情報をインタフェース部170に出力する。
ステップS55において、インタフェース部170は、ステップS54で共通データベース180から出力された情報を送信先の連携システム300の登録情報の形式に合うように加工する。
ステップS56において、インタフェース部170は、ステップS55で加工した情報を、該当する連携システム300に出力する。
このように、インタフェース部170は、資源予約情報182が更新された場合に、資源予約情報182の更新内容を複数の連携システム300に通知する。
登録部130により第1案件のスケジュールが共通データベース180に登録された場合には、インタフェース部170は、登録部130により記録された第1案件に対する複数種類の資源の割り当て結果を複数の連携システム300に通知する。すなわち、インタフェース部170は、新たな未承認案件に対する複数種類の資源の割り当て結果が共通データベース180に記録された場合に、記録された割り当て結果を複数の連携システム300に通知する。つまり、インタフェース部170は、第3情報198が共通データベース180に記録された場合に、第3情報198を連携システム300に通知して資源の空き状況または供給状況とは別に記録させる。ただし、重複する複数スケジュール案を持てない連携システム300は、通知対象から除外される。
更新部140により第1案件のスケジュールが新たな承認済案件のスケジュールとして共通データベース180に登録し直された場合には、インタフェース部170は、更新部140による資源予約情報182の更新内容を複数の連携システム300に通知する。つまり、インタフェース部170は、新たな未承認案件が承認され、当該新たな未承認案件に対する資源の割り当て結果に応じて共通データベース180の第2情報197が更新された場合に、第2情報197の更新内容を連携システム300に通知して連携システム300の記録内容を更新させる。また、インタフェース部170は、資源の割り当て状況に変化が生じた承認済案件があり、生じた変化に合わせて共通データベース180の第2情報197が更新された場合にも、第2情報197の更新内容を連携システム300に通知して連携システム300の記録内容を更新させる。
本実施の形態では、インタフェース部170は、複数種類の資源のうち少なくとも1種類の資源について共通データベース180の第2情報197が更新された場合に、第2情報197の更新内容を、互いに異なる種類の資源の空き状況または供給状況を記録する複数の連携システム300のうち該当する連携システム300に通知して当該連携システム300の記録内容を更新させる。なお、資源の種類が1種類のみ、連携システム300の数が1つのみでも本実施の形態を適用することができる。つまり、インタフェース部170は、共通データベース180の第2情報197が更新された場合に、第2情報197の更新内容を、その1種類の資源の空き状況または供給状況を記録する連携システム300に通知して当該連携システム300の記録内容を更新させてもよい。
共通データベース180の第2情報197が更新される場合に、共通データベース180の第1情報196は、第2情報197の更新と同時に更新されてもよいし、連携システム300から通知があったときに更新されてもよい。前者の場合は、単に第2情報197の更新内容に合わせて第1情報196が更新される。後者の場合は、インタフェース部170が第2情報197の更新内容を連携システム300に通知して連携システム300の記録内容を更新させた後、その更新に伴ってインタフェース部170が連携システム300から資源の空き状況または供給状況の変化の通知を受けたときに、通知された変化に合わせて第1情報196が更新される。
***実施の形態の効果の説明***
本実施の形態では、新たな案件のスケジュールを、他の案件のスケジュールを変更することを前提に作成できるようにしつつ、実際に変更が適用される場合に対象案件の管理者が通知を受けられるようにしている。そのため、新たな案件のスケジュールを、他の案件のスケジュールとの競合を避けつつ、迅速に作成することができる。
従来は、業務にサイロ化している複数のシステムを導入している場合、システム間の情報連携をユーザが行う必要がある。システム化されていない複数システム間の情報連携は、ユーザの負荷となり、常に全システムで最新の情報を共有することが難しく、チェック漏れ等のヒューマンエラーを誘発しやすい。本実施の形態では、スケジュール管理システム100が、システム間連携を行うインタフェース部170と、共通データベース180とを持ち、インタフェース部170経由で各システムから抽出したデータを共通データベース180で一元管理する。共通データベース180を参照することで、各システムが個別に保持していた工程検討に必要な情報を一元的に参照できる。各システムで実施されたデータ変更は、変更をトリガとしたデータ送信が可能なシステムは変更タイミングで、可能でないものは設定周期ごとに共通データベース180へ最新データをアップすることで、工程に影響のあるイベントまたは工程遅延が発生した際、発報と代替案提示とを行うことができる。
本実施の形態では、生産スケジュールを検討する際に、設備管理システム301で設備の空き状況、在庫管理システム303で部品の在庫状況、勤怠管理システム302で作業者の空き状況を調べて検討するといったことは必要なくなる。よって、顧客から新たな案件の依頼を受けた場合に、納期の回答をすぐに出すことができる。
本実施の形態では、新たな案件が承認された場合に、その案件に対する資源の割り当て結果に応じたデータベースの更新内容が、該当する資源の空き状況または供給状況を記録する連携システムに通知されて連携システムの記録内容が更新されるようにしている。そのため、新たな案件が承認された場合に、その案件に必要な資源を確保するための情報共有を迅速に行うことができる。
***他の構成***
本実施の形態では、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の機能がソフトウェアにより実現されるが、変形例として、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。すなわち、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の機能の一部が専用のハードウェアにより実現され、残りがソフトウェアにより実現されてもよい。
専用のハードウェアは、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックIC、GA、FPGAまたはASICである。「IC」は、Integrated Circuitの略語である。「GA」は、Gate Arrayの略語である。「FPGA」は、Field−Programmable Gate Arrayの略語である。「ASIC」は、Application Specific Integrated Circuitの略語である。
プロセッサ101および専用のハードウェアは、いずれも処理回路である。すなわち、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の機能がソフトウェアにより実現されるか、ソフトウェアとハードウェアとの組み合わせにより実現されるかに関わらず、設定部110、作成部120、登録部130、更新部140、消去部150、判定部160およびインタフェース部170の動作は、処理回路により行われる。