(57)【要約】【課題】工程管理が複雑な住宅建築やリフォーム等の工事案件において、工程遅延や案件の放置による商機損失が散見される。【解決手段】工程管理システムに、登録された各案件の各工程の進捗状況を管理し、ユーザからのアクセスに各工程の進捗状況を可視化して提示すると共に、各工程の遅延を警告する案件処理部と、進捗管理データベースの情報に基づき工程パターン・工程ＩＤ毎の月単位の実績情報を集計して実績集計データベースに格納する実績集計処理部と、実績集計データベースに格納する過去の実績情報に基づき、翌月の工程パターン・工程ＩＤ毎の案件数と、所要日数の予測値を算出して作業予測データベースへ格納する作業予測処理部とを備えて構成する。【選択図】  図１
2020201834.tif 000002
【特許請求の範囲】
【請求項１】
工事を伴う案件の各工程の進捗状況を管理する工程管理システムであって、
進捗管理データベースと、実績集計データベースと、作業予測データベースとを有するデータベースサーバと、
演算処理を行うアプリケーションサーバと、
を備え、
進捗管理データベースは、各案件の各工程の進捗状況、実績日を保持し、
実績集計データベースは、各案件の各工程を処理した月単位の実績を案件数と平均所要日数で集計した情報を保持し、
作業予測データベースは、翌月の工程パターン・工程ＩＤ毎の案件数と、各工程に要する日数の予測値を保持し、
アプリケーションサーバは、
登録された各案件の各工程の進捗状況を管理し、ユーザからのアクセスに各工程の進捗状況を可視化して提示すると共に、各工程の遅延を警告する案件処理部と、
進捗管理データベースの情報に基づき工程パターン・工程ＩＤ毎の月単位の実績情報を集計して実績集計データベースに格納する実績集計処理部と、
実績集計データベースに格納する過去の実績情報に基づき、翌月の工程パターン・工程ＩＤ毎の案件数と、所要日数の予測値を算出して作業予測データベースへ格納する作業予測処理部と、
を備えることを特徴とする工程管理システム。
【請求項２】
アプリケーションサーバの前記作業予測処理部は、
実績集計データベースに格納する過去の実績情報に基づき、工程パターン・工程ＩＤ毎に案件数と所要日数の線型回帰モデルを計算し、および直近の月の案件数と前年同月の案件数との比較より案件数の増加率を計算し、前記線型回帰モデル、および案件数の増加率に従って翌月の工程パターン・工程ＩＤ毎の案件数と、所要日数の予測値を算出して作業予測データベースへ格納することを特徴とする請求項１に記載の工程管理システム。
【請求項３】
データベースサーバは更に、工事に対応する工程パターン・工程ＩＤ毎に警告開始相対日数のデータを保持する工程定義マスタを有し、
前記作業予測処理部は、翌月の工程パターン・工程ＩＤ毎の案件数と、所要日数の予測値を算出した際に、工程パターン・工程ＩＤ毎の所要日数により、工程定義マスタの該当工程の警告開始相対日数を更新することを特徴とする請求項１に記載の工程管理システム。
【請求項４】
前記案件処理部は、各案件の各工程の進捗状況を管理して、前工程の実績日より前記工程定義マスタの警告開始相対日数が経過後に未処理の状態である工程がある場合には、ユーザ端末へ遅延警告を表示することを特徴とする請求項３に記載の工程管理システム。
【請求項５】
前記作業予測処理部が実績集計データベースに格納する過去の実績情報に基づき、直近の月の案件数と前年同月の案件数との比較より案件数の増加率を計算する処理は、処理実行月を含めて直近３カ月（処理実行月、１カ月前、２カ月前）の各工程・工程ＩＤ毎の案件数と、前年同月の各工程パターン・工程ＩＤ毎の案件数をそれぞれ比較して、各月毎の前年からの案件数の増加率を算出して、直近３カ月の案件数の増加率の平均を各工程パターン・工程ＩＤ毎の案件数の前年からの増加率とする処理であることを特徴とする請求項２に記載の工程管理システム。
【請求項６】
アプリケーションサーバの前記実績集計処理部は、
進捗管理データベースの各案件の各工程の進捗情報に基づき、集計期間内に処理した案件数を工程パターン・工程ＩＤ毎に集計し、および前工程ＩＤと当該工程ＩＤの実績日の差分を算出し、集計期間内において、当該工程パターン・工程ＩＤにおいて要した日数の平均値を算出し、実績集計データベースの月単位の工程パターン・工程ＩＤ毎の案件数と所要日数に格納することを特徴とする請求項１に記載の工程管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、工事を伴う工程管理システムに関する。
【背景技術】
【０００２】
住宅の工事の工程管理を容易に行うための「物件規模や諸条件を考慮した適切な工期を設定し、かつ工期の補正や修正、他邸との調整も容易な工程管理システム」について、特開２００５−２６７４８８号公報（特許文献１）に記載がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２６７４８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
住宅建築やリフォームビジネス等の工事では、取り扱う商材毎に工程や工数が異なり、工程管理が複雑な工事案件において、工程遅延や案件の放置による商機損失が散見される。
【０００５】
取り扱う商材が増えるほど、より工程管理が複雑になる為、案件毎の進捗状況を可視化した上で、適切なタイミングで各工程を進め、確実に商機獲得することが必要不可欠である。特許文献１では物件規模や諸条件を考慮した適切な工期を設定する点について記載されているが、人の判断で工期を設定することになり、設定した工期の妥当性という点は考慮されていない。また、工事に至るまでの打合せや契約に関する工程が考慮されていない。
【０００６】
そこで本発明では、案件登録から工完に至るすべての工程において、過去の実績から各工程の適切な処理タイミングを工事毎に算出し、進捗遅れが直観的に分かるように表現することで管理者から担当者へのフォローが手厚くできるようにして、工程遅延や機会損失の削減を目的とする。
【課題を解決するための手段】
【０００７】
本発明の工程管理システムの好ましい例では、工事を伴う案件の各工程の進捗状況を管理する工程管理システムであって、進捗管理データベースと、実績集計データベースと、作業予測データベースとを有するデータベースサーバと、演算処理を行うアプリケーションサーバとを備え、進捗管理データベースは、各案件の各工程の進捗状況、実績日を保持し、実績集計データベースは、各案件の各工程を処理した月単位の実績を案件数と平均所要日数で集計した情報を保持し、作業予測データベースは、翌月の工程パターン・工程ＩＤ毎の案件数と、各工程に要する日数の予測値を保持し、アプリケーションサーバは、登録された各案件の各工程の進捗状況を管理し、ユーザからのアクセスに各工程の進捗状況を可視化して提示すると共に、各工程の遅延を警告する案件処理部と、進捗管理データベースの情報に基づき工程パターン・工程ＩＤ毎の月単位の実績情報を集計して実績集計データベースに格納する実績集計処理部と、実績集計データベースに格納する過去の実績情報に基づき、翌月の工程パターン・工程ＩＤ毎の案件数と、所要日数の予測値を算出して作業予測データベースへ格納する作業予測処理部とを備えて構成する。
【０００８】
また、本発明の他の特徴として、前記工程管理システムにおいて、アプリケーションサーバの前記作業予測処理部は、実績集計データベースに格納する過去の実績情報に基づき、工程パターン・工程ＩＤ毎に案件数と所要日数の線型回帰モデルを計算し、および直近の月の案件数と前年同月の案件数との比較より案件数の増加率を計算し、前記線型回帰モデル、および案件数の増加率に従って翌月の工程パターン・工程ＩＤ毎の案件数と、所要日数の予測値を算出して作業予測データベースへ格納することを特徴とする。
【発明の効果】
【０００９】
過去の実績を基に各工程の処理タイミングを工事毎に定めることで、適切な処理タイミングを把握でき、管理者から担当者へのフォローがより容易になり、計画的に案件を遂行することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態における工程管理システムの全体構成例を示す図である。
【図２Ａ】工事マスタのデータ構造例を示す図である。
【図２Ｂ】工程定義マスタのデータ構造例を示す図である。
【図２Ｃ】進捗管理ＤＢのデータ構造例を示す図である。
【図２Ｄ】実績集計ＤＢのデータ構造例を示す図である。
【図２Ｅ】作業予測ＤＢのデータ構造例を示す図である。
【図３】実績集計処理部、および作業予測処理部の処理フローである。
【図４】案件毎の進捗状況を一覧化した場合のイメージ図である。
【図５】実績集計ＤＢに格納する過去の実績情報に基づき、工程パターン・工程ＩＤ毎に案件数と所要日数の線型回帰モデルを計算する処理を説明する図である。
【図６】各種サーバ、ユーザ端末の物理的な構成の例を示す図である。
【発明を実施するための形態】
【００１１】
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態における工程管理システム１００の全体構成例を示す図である。
【００１２】
図１に示すように本実施形態における工程管理システム１００は、各種データを格納しているデータベースサーバ１０１と、演算処理を行うアプリケーションサーバ１０２と、各工程の進捗状態の入力、工程管理の処理結果の表示等を行うユーザインタフェースを提供するユーザ端末１０３と、スケジューリングされたジョブを実行するバッチサーバ１０４とがネットワーク１０５を介して通信可能に接続されている。
【００１３】
アプリケーションサーバ１０２は、演算処理部３０１で格納されたプログラムが実行されて、案件処理部４０１、実績集計処理部４０２、作業予測処理部４０３の各機能が実現される。
案件処理部４０１は、ユーザ端末１０３からのアクセスによって起動され、登録された各案件の各工程データを進捗管理ＤＢ２０３上で更新、管理して、ユーザの要求に応じて各案件の各工程の進捗状況をユーザインタフェース上に報告する。
実績集計処理部４０２は、月次処理として起動され、案件の進捗状況を実績として保持している進捗管理ＤＢ２０３を検索して、処理実行月に実績のある工程パターン・工程ＩＤ別案件数を実績集計ＤＢ２０４に格納する。
作業予測処理部４０３は、実績集計ＤＢ２０４に記録されている過去の実績情報より工程パターン・工程ＩＤ毎に処理した案件数と各工程の所要日数の相関関係を求め、翌月の案件数と所要日数を予測して、案件処理部４０１がユーザに対して工程の遅延を警告する警告開始相対日数を更新する。
【００１４】
ユーザ端末１０３は、工程管理者、各工程の実施者が使用する端末であり、ユーザ操作により、案件登録をはじめとする案件を進める為の各種処理、各工程の進捗状態の入力、工程管理の処理結果の表示等を行う。ユーザ端末１０３は例えば、会社や工場内の、または個人のパーソナルコンピュータやサーバであり、複数台存在する。あるいはユーザ端末１０３は、スマートフォンやタブレット端末などの、通信機能を有する通信デバイスであってもよい。
【００１５】
ネットワーク１０５は、通信キャリアなどによって提供される無線ネットワークまたは有線ネットワークである。ネットワーク１０５は、個別の会社などが所有するネットワークを、ネットワーク１０５の一部に含んでもよく、複数種類のプロトコルを通過させるネットワークであってもよい。
【００１６】
図２Ａ乃至図２Ｅは、データベースサーバ１０１で保持する各データベースのデータ構造例を示す。
【００１７】
図２Ａにデータ構造例を示す工事マスタ２０１は、予め定義してデータベースに登録しておき、工事を分類分けした工事分類を主キーとし、工事の基本情報として、工事を識別する為の工事分類、工事分類に対応する名称として工事名、工事分類と図２Ｂに示す工程パターンを紐付けるために工程パターンを保持している。図２Ａに示す例では、フローリングはＡという工事分類で識別され、フローリング工事を進めるにあたって必要となる工程は、工程定義マスタで工程パターン１０として定義されている工程である。
【００１８】
図２Ｂにデータ構造例を示す工程定義マスタ２０２は、各工事案件を進める上で必要となる工程を定義しており、工程有無をパターン化することで工程パターンとして定義する。各工程を識別する為の工程ＩＤ、工程ＩＤに対応する名称として工程名を保持し、工程パターン・工程ＩＤ毎に対象外フラグ、警告要否フラグ、警告開始相対日数を定義する。
【００１９】
対象外フラグは工程パターン・工程ＩＤに対応して処理対象の工程であるかを定義し、“０”であれば処理対象であり、“１”であれば処理対象外の工程を意味する。また、警告要否フラグで、該当する工程パターン・工程ＩＤの工程において、警告表示をするかしないかを定義する。警告要否フラグが“０”であれば進捗遅れは管理せず、警告表示しないことになり、“１”にすることで対象の工程は警告表示対象となる。警告表示するにあたり、警告表示する為の基準値を警告開始相対日数として定義する。警告開始相対日数は、対象の工程で許容する所要日数を意味し、前工程の実績日から当日までの日数と比較することで警告表示する。
【００２０】
図２Ａ、Ｂに示す例では、フローリング工事の作業工程は工程パターン１０で定義される。現場確認依頼や現場確認は対象外フラグが“０”である為、処理対象として定義されていることになる。ただし、現場確認依頼は警告要否フラグが“０”である為、進捗遅れは管理しないが、現場確認は警告要否フラグが“１”である為、進捗が遅れていれば、警告表示することになる。警告表示するタイミングとしては、警告開始相対日数が“１”である為、前工程である現場確認依頼の実績日(終了日)の１日後に未処理の状態であれば、例えば点滅として遅延警告を行う。
【００２１】
図２Ｃにデータ構造例を示す進捗管理ＤＢ２０３は、ユーザがユーザ端末１０３から新たな工事を含む新規案件を登録する操作に従い、案件処理部４０１が、工事マスタ２０１と工程定義マスタ２０２の定義情報を基に、対象案件に必要となる工程情報を取得して新たなデータレコードを作成する。その後、該当案件のデータレコードには、案件処理部４０１が、ユーザ端末１０３からの報告などにより、実行した各工程の処理状態や実績日を保持する。
【００２２】
進捗管理ＤＢ２０３には、案件を識別する為の案件番号があり、案件番号に紐付く工事(１件の案件に複数の工事が含まれる場合がある。)の順番を連番として保持する。また、連番における具体的な工事を工事分類として保持し、工事分類に紐付く工程パターンを工程定義マスタ２０２から取得し、工程パターンとして保持する。
更に、各工程の進捗状況を保持するとともに、警告表示する為の基準日を管理日付(該当工程を管理開始する日付として前工程の実績日が入れられる。)として保持し、警告開始日付へ管理日付に工程定義マスタの警告開始相対日数を足し算した日付を保持する。
進捗管理ＤＢ２０３の予定日には、案件処理部４０１で必要に応じて入力した処理予定日を保持し(予定日はユーザが例えば顧客の希望日などをユーザ端末１０３から入力した日付などを登録して、ユーザへの提示画面に表示されるが、案件処理部４０１の処理では参照されない。)、実績日には案件処理部４０１にて該当工程ＩＤに対応する処理を確定させた日付を保持する。
【００２３】
図２Ｃに示す例では、案件番号“０００１”には工事が２つあり、１つ目がフローリング、２つ目がカーポートとなる。フローリングの工程パターンは“１０”であり、工程ＩＤ“０１０１０”である案件登録は、２０１８年０１月０１日に処理されたことを意味する。なお案件登録は最初の工程となる為、管理日付、警告開始日付、予定日には実績日と同じ値が入ることになる。
【００２４】
工程管理システム１００は、工事を伴う案件の各工程の進捗状況を見える化したシステムである。ユーザ端末１０３から指示を受けてアプリケーションサーバ１０２の案件処理部４０１を実行する。各案件に対するユーザからの指示に応じた処理を案件処理部４０１で実行し、処理結果をユーザ端末１０３に表示すると共に、その処理実績を進捗管理ＤＢ２０３へ格納する。進捗管理ＤＢ２０３へは処理実績として、処理日付および各工程の状態が保持される。
【００２５】
各工程の状態として、「処理対象外」、「未処理」、「処理中」、「処理済」がある。「処理対象外」とは、処理する必要がない工程を意味し、図２Ｂに示す工程定義マスタにて定義する。「未処理」は、前工程が完了し、次に処理すべき工程の状態である。「処理中」は、処理対象データの一部が処理済もしくは、一時保存された状態である。「処理済」は、処理すべき対象データがすべて処理済となった状態を示す。
【００２６】
このように、進捗管理ＤＢ２０３へ格納されたデータは、ユーザ端末１０３からアプリケーションサーバ１０２へ出力指示が送られた結果、アプリケーションサーバ１０２を介して対象案件のデータを取得し、ユーザ端末へ返される。ユーザ端末１０３はアプリケーションサーバ１０２から受信したデータを編集し、対象案件の工程管理表として表示する。
【００２７】
図４に工程管理表の表示例を示す。図４に示す工程管理表の表示例では、進捗管理ＤＢ２０３で保持している各工程の進捗状況と実績日を用いて進捗状況を可視化しており、案件に紐付く工事毎に進捗状況を示す。各工程の進捗状況を四角のマーク及び実績日で表現しており、△（日付無）は「未処理」、△（日付有）は「処理中」、完（日付有）は「処理済」、「−」（ハイフン）は「処理対象外」、空白は未到達工程を意味する。
【００２８】
図４に示す表示例におけるフローリングであれば、案件登録は完了しており、現場確認や現場確認依頼は作業対象外である為、次に実施すべき処理は見積書作成となる。また、進捗管理ＤＢ２０３の各工程における進捗状況が処理済以外であり、現在の運用日付が進捗管理ＤＢ２０３の警告開始日付を過ぎている場合は、対象となる工程が予定より遅れていると判断し、遅れている工程を例えば点滅で表現する。
【００２９】
このように工程管理システム１００は各工程の進捗状況に遅れが生じた際に、遅れている工程に対して警告表示をする機能を備える。本実施例では、警告表示機能において、警告表示する為の基準となる図２Ｂに示す工程定義マスタの警告開始相対日数を過去実績を基に算出することが特徴である。このような処理を行う工程管理システム１００により、複数の部署を跨って推進する各案件の進捗状況を共有することが可能となり、各部署で各工程の処理状況を把握することができ、互いにフォローし合うことで着実に案件を推進することができる。
【００３０】
図２Ｄにデータ構造例を示す実績集計ＤＢ２０４は、進捗管理ＤＢ２０３を基に実績集計処理部４０２で単位月あたりに各工程で処理した案件数及び所要日数の平均値を算出し、集計した情報を保持する。
図２Ｄに示す例では、２０１６年０１月と、２０１６年０２月に全工程における処理した案件数及び所要日数の平均値を算出して、各工程ごとに集計した情報を記録している。例えば、２０１６年０１月の工程パターン“１０”の工程ＩＤ“０２０１０”（現場確認）を集計処理した案件数は１６０件であり、平均して現場確認依頼してから５日間要したことを意味している。
また、図２Ｄに示す例では、工程パターン“１０”の各工程ＩＤの案件数が順次減っていくのは、案件登録はしたけれど、顧客の意向、その他の理由で、打合せまで行く前の工程で打ち切られた案件が発生するため、または前月からの繰り越しなども存在するためである。
【００３１】
図２Ｅにデータ構造例を示す作業予測ＤＢ２０５は、実績集計ＤＢ２０４に保持する実績情報を基に作業予測処理部４０３で算出する翌月の各工程で処理する案件数及び所要日数の予測値を保持する。
図２Ｅに示す例では、年月“００００００”で示す工程パターン“１０”の工程ＩＤ“０２０１０”（現場確認）のデータは、実績集計ＤＢ２０４に保持する過去の実績情報を基に算出した結果、処理案件数が１００件の場合は所要日数が４日であるが、処理する案件数が１５０件になった場合は所要日数が５日、処理する案件数が２００件になった場合は所要日数が７日かかることを意味する。そのような相関関係の結果を踏まえ、２０１６年０２月における工程パターン“１０”の工程ＩＤ“０２０１０”（現場確認）は２０６件の案件を処理することが予測され、それらの所要日数は平均で７日かかることを予測していることを示す。
【００３２】
図３に本実施例の特徴である作業予測ＤＢ２０５のデータを生成するプロセスである実績集計処理部４０２および案件作業予測処理部４０３の処理フローを示す。
【００３３】
ステップＳ１０１において、作業予測ＤＢ２０５に翌月の各工程で処理する案件数及び所要日数の予測値を生成する為に、実績集計処理部４０２が月次処理(処理実行月の月末最終日の夜に当月の実績情報の集計を行う)としてバッチサーバ１０４へ処理指示を発して、進捗管理ＤＢ２０３の情報を基に実績集計ＤＢ２０４に当月の実績情報を生成する。
【００３４】
実績集計処理Ｓ１０１では、案件の進捗状況を実績として保持している進捗管理ＤＢ２０３の実績日を基に集計期間内に処理した案件数を工程パターン・工程ＩＤ毎に集計し、実績集計ＤＢ２０４の案件数に集計結果の工程パターン・工程ＩＤ別案件数を格納する。また、前工程ＩＤと当該工程ＩＤの実績日の差分を算出し、集計期間内において、当該工程パターン・工程ＩＤにおいて要した日数の平均値を算出し、実績集計ＤＢ２０４の該当工程パターン・工程ＩＤの所要日数に算出した平均所要日数を格納する。
【００３５】
生成された実績集計ＤＢ２０４の当月の実績情報、および記録されている過去の実績情報を基に、作業予測処理部４０３において、以下のステップの処理により、翌月の各工程パターン・工程ＩＤごとの案件数、および所要日数を予測して、作業予測ＤＢ２０５に格納する。
【００３６】
ステップＳ２０１において、作業予測処理部４０３が実績集計ＤＢ２０４に記録されている実績情報の過去データより適当なデータを選択して集計し、工程パターン・工程ＩＤ毎に処理した案件数と各工程の所要日数の相関関係を算出する。
【００３７】
例えば、ある工程パターン・工程ＩＤの業務、作業を実施する担当者は、当然、他の工程パターン・工程ＩＤの業務、作業も兼務していることになるが、各種の案件が混在して受注する住宅建築やリフォームビジネス等の工事案件において、担当者の総数に大きな変更が無ければ、概略、ある工程パターン・工程ＩＤの業務、作業に振り分けられる担当者の最大工数は均一になると予測できる。
【００３８】
そのような条件において、図５(Ａ)に示すのは、実績集計ＤＢ２０４に記録されている過去の実績情報の中で、例えば担当者の総数がほぼ同じで、工程パターンが１０、工程ＩＤが０２０１０(現場確認)の工程に振り分けられる担当者の最大工数が均一と見なせる２０１６年１月から２０１７年１２月までの実績情報の例である。これらのデータを見ると、案件数が多くなると、１件の案件を処理する所要日数が増えることが分かる。これは、処理すべき案件数が多いと、着手が遅れ、待ち時間が増えることに因ります。
【００３９】
図５(Ｂ)に、図５(Ａ)に示す実績集計ＤＢ２０４の実績情報の案件数と所要日数をプロットした散布図を示す。案件数と所要日数は正の相関関係が見られる。案件数ｘｉと所要日数ｙｉの間の相関係数ｒｘｙは数式(１)で求められる。
【００４０】
【数１】
2020201834.tif 000003
【００４１】
案件数ｘｉと所要日数ｙｉの間の相関係数ｒｘｙは0.933となり、強い直線関係が見られるので、所要日数ｙｉが案件数ｘｉの回帰関数ｙ＝ａｘ＋ｂで近似される線型モデルを考える。
【００４２】
ここで、回帰係数ａ、切片ｂは、それぞれ数式(２)、数式(３)で求められる。
【００４３】
【数２】
2020201834.tif 000004
【００４４】
【数３】
2020201834.tif 000005
【００４５】
図５(Ｃ)に示すように、実績集計ＤＢ２０４に記録されている過去の実績情報より、工程パターン・工程ＩＤ毎に案件数ｘｉと所要日数ｙｉの線型回帰モデルを計算する。
【００４６】
算出した線型回帰モデルに従って、図５(Ｄ)に示すように、作業予測ＤＢ２０５へ、年月を「000000」として、工程パターン・工程ＩＤ毎に案件数を５０件単位に増分させた案件数と工程の所要時間の相関関係の予測値を格納する。
【００４７】
ステップＳ２０２において、作業予測処理部４０３が実績集計ＤＢ２０４に記録されている実績情報を読み出し、処理実行月(当月)を含めて直近３カ月（処理実行月、１カ月前、２カ月前）の各工程パターン・工程ＩＤ毎の案件数と、前年同月の各工程パターン・工程ＩＤ毎の案件数をそれぞれ比較して、各月毎の前年からの案件数の増加率を算出して、直近３カ月の案件数の増加率の平均を各工程パターン・工程ＩＤ毎の案件数の前年からの増加率とする前年比算出処理を実行する。
【００４８】
ステップＳ２０３において、作業予測処理部４０３がＳ２０２で算出した前年からの増加率を利用し、処理実行月(当月)の翌月の前年同月における工程パターン・工程ＩＤ毎の案件数に算出した増加率を掛算することで、直近の案件数推移を基に処理実行月の翌月の工程パターン・工程ＩＤ毎の予測案件数を算出する。
【００４９】
ステップＳ２０４において、作業予測処理部４０３がＳ２０３で算出した翌月の工程パターン・工程ＩＤ毎の予測案件数を用いて、作業予測ＤＢ２０５に格納されている年月が「000000」で、同一工程パターン・同一工程ＩＤの案件数が５０ごとに増加するデータと比較して、前記予測案件数と一致する、または前記予測案件数を間に挟む両案件数を持つデータレコードの所要日数を読み出して、前記予測案件数を間に挟む両案件数との比例配分に応じて、処理実行月の翌月の該当工程パターン・工程ＩＤの予測所要日数を算出する。  例えば、図２Ｅの作業予測ＤＢ２０５において、年月“２０１６０１”、工程パターン“１０”、工程ＩＤ“０２０１０”（現場確認）の予測案件数が“１９４”とＳ２０３で算出されたとすれば、Ｓ２０４において、年月“００００００”、工程パターン“１０”、工程ＩＤ“０２０１０”、案件数“１５０”、所要日数“５”のデータレコードと、年月“００００００”、工程パターン“１０”、工程ＩＤ“０２０１０”、案件数“２００”、所要日数“７”のデータレコードが参照されて、予測案件数“１９４”が、案件数“１５０”と案件数“２００”の間に挟まれた比例配分に応じて、処理実行月の翌月の該当工程パターン・工程ＩＤの予測所要日数を“７”と算出する。
【００５０】
以上のように、翌月案件数予測処理Ｓ２０３及び所要日数算出処理Ｓ２０４により算出した予測値である処理実行月(当月)の翌月における工程パターン・工程ＩＤ毎の案件数及び所要日数を作業予測ＤＢ２０５へ翌月分のデータとして格納する。
【００５１】
ステップＳ２０５において、作業予測処理部４０３が、作業予測ＤＢ２０５へ格納した処理実行月の翌月の工程パターン・工程ＩＤ毎における所要日数を工程定義マスタ２０２の該当工程パターン・工程ＩＤに対応した警告開始相対日数の欄へ格納する。
【００５２】
翌月において、案件処理部４０１は、各案件の各工程の進捗遅れの管理を、更新された工程定義マスタ２０２の警告開始相対日数の値に基づいて実行する。
【００５３】
以上、本実施形態について具体的に説明したが、本実施形態によれば、過去の実績から案件数や工事に応じた所要日数を予測することで、各工事における各工程の適切な処理タイミングを把握することが可能となり、管理者から担当者へのフォローが容易となる。また、予測値があることで関係部署および顧客との調整もスムーズに行え、工程遅延や案件の放置による商機損失を削減することができると考える。
【００５４】
最後に、図６は、図１で示したデータベースサーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３、バッチサーバ１０４の物理的な構成を示す図である。本実施例ではこれらのサーバ（またはユーザ端末）には、プロセッサ（ＣＰＵ）６０１、メモリ６０２、補助記憶装置６０３、及び通信インターフェース（通信Ｉ／Ｆ）６０４を有する計算機６００が用いられる。この計算機は一例として、パーソナルコンピュータ（ＰＣ）等の汎用的な計算機でよい。計算機６００はまた、入力インターフェース（入力Ｉ／Ｆ）６０５及び出力インターフェース（出力Ｉ／Ｆ）６０８を有してもよい。入力インターフェース６０５は、キーボード６０６やマウス６０７などが接続され、オペレータからの入力を受けるインターフェースである。出力インターフェース６０８は、ディスプレイ装置６０９やプリンタなどが接続され、プログラムの実行結果をオペレータが視認可能な形式で出力するインターフェースである。
【００５５】
本実施例では、これらのサーバがそれぞれ物理的に異なる計算機である例を説明する。ただし必ずしもこれらのサーバが、異なる計算機である必要はなく、上で述べたいくつかのサーバが有する機能部が、単一の計算機上に実装されていてもよい。
【符号の説明】
【００５６】
１００・・・工程管理システム、１０１・・・データベースサーバ、１０２・・・アプリケーションサーバ、１０３・・・ユーザ端末、１０４・・・バッチサーバ、１０５・・・ネットワーク、２０１・・・工事マスタ、２０２・・・工程定義マスタ、２０３・・・進捗管理ＤＢ、２０４・・・実績集計ＤＢ、２０５・・・作業予測ＤＢ、３０１・・・演算処理部、４０１・・・案件処理部、４０２・・・実績集計処理部、４０３・・・作業予測処理部、６００・・・計算機、６０１・・・プロセッサ（ＣＰＵ）、６０２・・・メモリ、６０３・・・補助記憶装置、６０４・・・通信インターフェース（通信Ｉ／Ｆ）、６０５・・・入力インターフェース（入力Ｉ／Ｆ）、６０６・・・キーボード、６０７・・・マウス、６０８・・・出力インターフェース（出力Ｉ／Ｆ）、６０９・・・ディスプレイ装置。
【図１】
2020201834.tif 000006
【図２Ａ】
2020201834.tif 000007
【図２Ｂ】
2020201834.tif 000008
【図２Ｃ】
2020201834.tif 000009
【図２Ｄ】
2020201834.tif 000010
【図２Ｅ】
2020201834.tif 000011
【図３】
2020201834.tif 000012
【図４】
2020201834.tif 000013
【図５】
2020201834.tif 000014
【図６】
2020201834.tif 000015