JP2009129166A - 業務処理システム - Google Patents

Abstract

【課題】直列的な流れのみでは完結しない業務フローおよび各業務の進捗状況を一括して管理することのできる業務処理システムを提供する。
【解決手段】データベースは、直列的に連続する複数の業務からなる業務フローを定義した業務フロー定義情報と、業務フローの組合せおよび処理順を定義した業務フロー組合せ情報と、を保持する領域を有し、サーバ１００は、業務処理の進捗状況または業務フロー組合せ情報をデータベースに格納し、クライアント端末２００は、業務処理の新たな進捗状況の入力を受け付ける際に、サーバ１００より、進捗状況、業務フロー定義情報、および業務フロー組合せ情報を取得し、業務フローの組合せおよび処理順、各業務フローを構成する業務およびその順序、並びに各業務の進捗状況を画面表示する。
【選択図】図４

Description

本発明は、複数の業務から構成される業務フローについて、各業務処理の進捗状況を管理するシステムに関するものであり、特に、管理対象とする業務フローの定義を柔軟に行うことができるようにする技術に関する。

近年、業務が複数の作業工程の一連の流れで構成され、業務に必要な情報が作業工程間で適宜伝達されることで遂行されることが多くなっている。
また、複数の担当者がネットワークを経由して業務をする際に、担当業務を円滑に進めるため、担当者間で受け渡すドキュメントや情報の流れを管理し、自動化するワークフローシステムが知られている（例えば、非特許文献１〜３参照）。

また、業務処理システムに関し、『複数の作業工程のシーケンスから構成される業務処理の流れにおいて、工程から工程へと通常の伝票を単位とするデータの伝達方法を改善し、作業効率を向上させる。』ことを目的とした技術として、『掲示板データベース１１は、一連の業務プロセスに関連するすべてのデータ項目の内容を集約して格納し、関連するすべての作業担当者がクライアント２を介して掲示板の形式で共有する。状態遷移ルール１２は、作業工程の各々についてデータ入力を完了すべきデータ項目を設定する。状態監視部３は、掲示板データベース１１及び状態遷移ルール１２を参照して現在作業中の工程が規定のデータ入力を完了したとき、次の作業工程に遷移させ、関連するクライアントに状態遷移を通知し、また各作業工程のデータ入力完了期限を設定する状態遷移期限ルール１３を参照して処理期限が迫ったとき、関連するクライアント２に通知する。』というものが提案されている（特許文献１）。

特開平１０−２１４１１３号公報（要約） 速水治夫、「ここまできたワークフロー管理システム（１）」情報処理学会誌、Ｖｏｌ．３９、ＮＯ．１１、ｐ１１６０−ｐ１１６５（１９９８） 速水治夫、阪口俊昭、渋谷亮一、「ここまできたワークフロー管理システム（２）」情報処理学会誌、Ｖｏｌ．３９、ＮＯ．１２、ｐ１２５８−ｐ１２６３（１９９８） 速水治夫、渋谷亮一、鈴木登雄、生駒順一、寺下陽介、植野直樹、金子聡、林潔、「ここまできたワークフロー管理システム（３）」情報処理学会誌 Ｖｏｌ．４０、ＮＯ．５、ｐ５０７−ｐ５１３（１９９９）

上記非特許文献１〜３では、ワークフローの基本技術は開示されているが、これらの文献には、ワークフローを構成する業務が直列的に接続されている場合の技術しか記載されていない。
しかし、企業等における各種業務では、業務の開始から終了までのフローが、直列的な流れのみでは完結しない場合が多くある。

例えば、ある業務処理は直列的なワークフローで行われるが、その後に続く業務処理へ連続的につながっていない場合や、連続してつながっている場合でも、前の処理が複数回処理されてから次の処理につながる場合など、様々なケースが存在する。
さらには、ワークフローの処理過程で分岐箇所を設け、ある条件では行うが、異なる条件では行わずに更に次の処理を行う、といった条件付で行われる業務もある。

また、上記特許文献１では、掲示板データベースで作業に関わる情報を共有し、利用することは述べられているが、上述のように様々な条件の下で複雑に連携した業務フローを取り扱う際の具体的な構成や利用の仕方については述べられていない。

そのため、上記非特許文献１〜３や特許文献１に記載の技術では、取り扱うことのできる業務フローの構成が一定範囲に制限され、企業等における任意の業務フローを必ずしも管理することができない場合があるという課題があった。

本発明は、上記のような課題を解決するためになされたものであり、直列的な流れのみでは完結しない業務フローおよび各業務の進捗状況を一括して管理することのできる業務処理システムを提供することを目的とする。

本発明に係る業務処理システムは、業務処理の進捗状況を管理するシステムであって、業務処理の進捗状況の入力を受け付けるクライアント端末と、前記進捗状況を保持するデータベースを格納した記憶手段を備えるサーバと、を有し、前記データベースは、直列的に連続する複数の業務からなる業務フローを定義した業務フロー定義情報と、前記業務フローの組合せおよび処理順を定義した業務フロー組合せ情報と、を保持する領域を有し、前記クライアント端末は、前記進捗状況または前記業務フロー組合せ情報の入力を受け付けてこれらの情報を前記サーバに送信し、前記サーバは、その進捗状況または業務フロー組合せ情報を前記データベースに格納し、前記クライアント端末は、業務処理の新たな進捗状況の入力を受け付ける際に、前記サーバより、前記進捗状況、前記業務フロー定義情報、および前記業務フロー組合せ情報を取得し、前記業務フローの組合せおよび処理順、各前記業務フローを構成する業務およびその順序、並びに各業務の進捗状況を画面表示するものである。

本発明に係る業務処理システムによれば、業務フロー定義情報で直列的な業務フローを定義するとともに、業務フロー組合せ情報で業務フローの組み合わせおよび処理順を定義するので、直列的な流れのみでは完結しない業務フローと各業務の進捗状況を定義および管理することができる。

実施の形態１．
図１は、本発明の実施の形態１に係る業務処理システムの構成図である。
図１において、１００はサーバ、２００ａと２００ｂはクライアント端末であり、これらはネットワーク３００を介して接続されている。
サーバ１００は、ネットワークインターフェースを備えた比較的高性能なコンピュータで構成され、クライアント端末２００ａと２００ｂから入力される各種情報の蓄積や提供を行うものである。
クライアント端末２００ａと２００ｂは、ネットワークインターフェースを備えたＰＣなどの比較的小型のコンピュータで構成され、ユーザが後述の各種情報の入力や閲覧を行うためのものである。以下、クライアント端末２００ａと２００ｂを総称するときは、クライアント端末２００とする。

なお、図１ではクライアント端末２００は２台のみであるが、台数は任意でよい。
同様に、サーバ１００の構成や台数も任意でよい。

サーバ１００は、記憶手段１１０を備える。記憶手段１１０には、後述の図２〜図８で説明する業務フローの一覧と、各業務の進捗状況とを格納する業務フロー管理データベースが格納される。
記憶手段１１０は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）のような書き込み可能な記憶装置で構成される。

業務フロー管理データベースは、データベースに格納するデータを保持するデータファイルを記憶手段１１０に格納し、必要に応じてＤＢＭＳ（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）などのソフトウェアをサーバ１００に導入することで、構成することができる。

次に、本実施の形態１に係る業務処理システムの管理対象となる業務フローと、各業務フローの非連続性について説明する。
以下の説明では、情報システムの受託開発プロジェクトにおける業務フローを例に説明するが、本発明の適用対象はこれに限られるものではなく、任意の業務フローを対象とすることができることを付言しておく。

図２は、本実施の形態１に係る業務処理システムで管理する業務フローの一覧である。
図２において、（１）引き合い業務フロー〜（７）プロジェクト完了業務フローは、それぞれが完結した業務フローである。各業務フローは、複数の業務で構成される。

情報システムの受託開発プロジェクトでは、図２に示すように、概ね（１）引き合い業務フロー〜（７）プロジェクト完了業務フローの順で、業務フローが進行する。また、（１）〜（７）の各業務フロー内では、当該業務フローを構成する業務が、直列的な流れで進行する。
以下、各業務フローと構成業務の内容について、簡単に説明する。

（１）引き合い業務フロー
情報システムの受託開発の引き合いがあった時点で、プロジェクトの件名などの基本情報の登録を行う業務フローであり、構成業務はない。

（２）最適化検討業務フロー
プロジェクトの最適化検討が行われる時に発生する業務フローであり、最適化検討を主管する部署（以下主管部署）と最適化検討を受ける部署（以下受審部署）が対象となる。
（２．１）結果登録：主管部署が実施結果を登録する。
（２．２）結果承認：受審部署が登録内容を確認し承認する。

最適化検討業務フロー内では、（２．１）−＞（２．２）の順で業務が行われる。
プロジェクトの最適化検討は、プロジェクトの進行中の任意の時点で行われる場合があり、したがって最適化検討業務フローは、任意の時点で複数回実施される場合がある。

（３）見積時審査業務フロー
プロジェクトの見積時審査が行われる時に発生する業務フローであり、審査を受ける部署（以下受審部署）と審査を主管する部署（以下主管部署）が対象となる。
（３．１）部内レビュー結果登録：受審部署が部署内での見積資料のレビュー結果を登録する。
（３．２）審査結果登録：主管部署が登録内容を確認し、見積時審査結果を登録する。
（３．３）結果承認：受審部署が登録内容を確認し承認する。

見積時審査業務フロー内では、（３．１）−＞（３．２）−＞（３．３）の順で業務が行われる。
情報システムの受託開発プロジェクトにおいて、見積もりはプロジェクトの進行中の任意の時点で複数回行われる場合があり、したがって見積時審査業務フローは、任意の時点で複数回実施される場合がある。

（４）プロジェクト計画時審査業務フロー
プロジェクト計画時審査が行われる時に発生する業務フローであり、審査を受ける部署（以下受審部署）と審査を主管する部署（以下主管部署）が対象となる。
（４．１）部内レビュー結果登録：受審部署が部署内でのプロジェクト計画書のレビュー結果を登録する。
（４．２）審査結果登録：主管部署が登録内容を確認し、プロジェクト計画時審査結果を登録する。
（４．３）結果承認：受審部署が登録内容を確認し承認する。

プロジェクト計画時審査業務フロー内では、（４．１）−＞（４．２）−＞（４．３）の順で業務が行われる。
情報システムの受託開発プロジェクトにおいて、例えば仕様変更の発生など、プロジェクト計画を再度立案する必要が生じる場合があり、したがってプロジェクト計画時審査業務フローは、任意の時点で複数回実施される場合がある。

（５）リスク審査業務フロー
リスク審査が行われる時に発生する業務フローであり、審査を受ける部署（以下受審部署）と審査を主管する部署（以下主管部署）が対象となる。
（５．１）部内レビュー結果登録：受審部署が部署内での見積資料のレビュー結果を登録する。
（５．２）審査結果登録：主管部署が登録内容を確認し、プロジェクト計画時審査結果を登録する。
（５．３）結果承認：受審部署が登録内容を確認し承認する。

リスク審査業務フロー内では、（５．１）−＞（５．２）−＞（５．３）の順で業務が行われる。
リスク審査は、プロジェクトの進行中の任意の時点で行われる場合があり、したがってリスク審査業務フローは、任意の時点で複数回実施される場合がある。

（６）月次報告業務フロー
プロジェクトの進捗確認のために実施される報告会で、毎月定例で発生する業務フローであり、プロジェクトの実行部署（以下実行部署）、実行部署を管理する部署（以下実行管理部署）、プロジェクトの管理部署（以下管理部署）が対象となる。
（６．１）実績登録：実行部署が該当月のプロジェクト実績資料を登録する。
（６．２）結果承認：実行管理部署が登録内容を確認し承認する。
（６．３）結果承認：管理部署が登録内容を確認し承認する。
（６．４）結果承認：実行管理部署が登録内容を確認し承認する。

月次報告業務フロー内では、（６．１）−＞（６．２）−＞（６．３）−＞（６．４）の順で業務が行われる。
月次報告会は、毎月定例で発生するので、月次報告業務フローは、プロジェクトの進行中に複数回発生する。

（７）プロジェクト完了業務フロー
プロジェクトが完了したと判断された時に発生する業務フローであり、プロジェクトの実行部署（以下実行部署）とプロジェクトの管理部署（以下管理部署）が対象となる。
（７．１）完了登録：実行部署がプロジェクトが完了したことを登録する。
（７．２）結果承認：管理部署が登録内容を確認し承認する。

月次報告業務フロー内では、（７．１）−＞（７．２）の順で業務が行われる。
プロジェクト完了はプロジェクトの進行の上で原則１回であり、したがってプロジェクト完了業務フローは、プロジェクトの最後に１回のみ発生する。

以上、図２に示す各業務フローと構成業務の内容について、簡単に説明した。

図２に示す各業務フロー内では、結果非承認による差し戻しのようなケースを除けば、構成する業務が直列的に進行し、各業務フローが完結される。
しかし、業務フロー間の流れについては、必ずしも（１）引き合い業務フロー〜（７）プロジェクト完了業務フローの順で業務フローが進行するとは限らず、途中の過程などにおいて、同一の業務フローが複数回実行されたり、所定の条件により業務フローのスキップが生じたり、といったことが発生し得る。
そのため、従来の業務処理システムでは、このような非定型かつ非連続な業務フローをあらかじめ定義して管理することが困難であった。

そこで、本実施の形態１に係る業務処理システムでは、図２に示す直列的に進行する完結した業務フローを１管理単位とし、この完結した業務フローを任意に組み合わせることにより、管理対象の業務フローを任意に定義することができるようにする。

次に、本実施の形態１に係る業務処理システムの詳細説明を行う前に、同システムの使用手順について、以下にステップを追って簡単に説明する。使用手順の詳細については、後述の図３〜図８で、画面イメージと併せて改めて説明する。

（１）記憶手段１１０が格納している業務フロー管理データベースには、後述の図３〜図８で説明する、あらかじめ定義された業務フローの雛形が複数格納されている。

（２）ユーザは、クライアント端末２００を使用して、上記（１）の複数の業務フローの雛形を参照し、この雛形を任意に選択して組み合わせ、非連続に組み合わされた新たな業務フローを任意に定義する。本ステップは、業務フローの分岐時や繰り返し時など、任意の時点で実行できる。

（３）ユーザは、クライアント端末２００を使用して、ステップ（２）で定義した業務フローの各業務の進捗状況を入力し、サーバ１００に送信する。進捗状況は、業務フロー管理データベースに格納される。

以上、本実施の形態１に係る業務処理システムの使用手順について簡単に説明した。
ユーザは、本実施の形態１に係る業務処理システムを使用することで、非定期かつ非連続に発生する業務フローを任意の時点で組み合わせて新たな業務フローを定義することができるので、従来の技術では困難であった、直列的な流れのみでは完結しない業務フローの管理を行うことが可能となるのである。

次に、上述の業務処理システムの使用手順を、クライアント端末２００の画面イメージと併せて説明する。

図３は、クライアント端末２００からサーバ１００にアクセスした際の画面イメージである。サーバ１００は、クライアント端末２００からのアクセスを受け付け、図３のような画面を返信する。
図３において、画面右側には、図２で説明した各業務フローを表す画面部品がラベル状に表示されている。また、画面左側には、プロジェクトの基本情報や進捗状況を表示する画面が表示されている。初期状態では、画面左側には何の情報も表示されていない。

図４は、情報システムの受託開発の引き合いがあった時点で、ユーザが行う画面操作イメージである。以下、ユーザが行う操作手順を説明する。

（１）引き合いがあると、ユーザは画面右側の「引き合い業務フロー」ラベルを、画面左側の「基本情報」欄に貼り付ける。
ここでいう貼り付け操作は、ラベル画面部品をドラッグ＆ドロップするようなものでもよいし、「選択」ボタンを押下して指定するようなものでもよい。以下の操作における貼り付けも、同様である。

（２）「引き合い業務フロー」ラベルを貼り付けると、画面左側の「基本情報」欄に入力欄が現れる。
（３）ユーザは、画面左側の「基本情報」欄に表示される入力欄に、当該プロジェクトの名称などの基本情報を入力する。

図５は、プロジェクトの最適化検討を行う時点で、ユーザが行う画面操作イメージである。ここでは、引き合い業務フローに続いて最適化検討業務フローを行うものと仮定する。以下、ユーザが行う操作手順を説明する。

（１）ユーザは、プロジェクトの最適化検討を開始する時点で、画面右側の「最適化検討業務フロー」ラベルを、画面左側の「進捗情報」欄に貼り付ける。
（２）「最適化検討業務フロー」ラベルを貼り付けると、画面左側の「進捗情報」欄に同業務フローラベルが現れる。

（３）同業務フローラベル上では、現在の最適化検討業務フローの進捗状態が「（２．１）結果登録」であることを示すように、同業務が色付きで表示される。
（４）ユーザは、最適化検討業務フローの進捗状況を、別途設ける業務進捗の入力画面（図示せず）上で入力する。入力に応じて、最適化検討業務フローの進捗状態が、「（２．１）結果登録」から「（２．２）結果承認」へと進行する。

図６は、プロジェクトの見積時審査を行う時点で、ユーザが行う画面操作イメージである。ここでは、最適化検討業務フローに続いて見積時審査業務フローを行うものと仮定する。以下、ユーザが行う操作手順を説明する。

（１）ユーザは、プロジェクトの見積時審査を開始する時点で、画面右側の「見積時審査業務フロー」ラベルを、画面左側の「進捗情報」欄に貼り付ける。
（２）「見積時審査業務フロー」ラベルを貼り付けると、画面左側の「最適化検討業務フロー」ラベルの下に「見積時審査業務フロー」ラベルが現れる。

（３）「見積時審査業務フロー」ラベル上では、現在の見積時審査業務フローの進捗状態が「（３．１）部内レビュー結果登録」であることを示すように、同業務が色付きで表示される。
（４）ユーザは、見積時審査業務フローの進捗状況を、別途設ける業務進捗の入力画面（図示せず）上で入力する。入力に応じて、見積時審査業務フローの進捗状態が、「（３．１）部内レビュー結果登録」から「（３．３）結果承認」へ向かって進行する。

図７は、１回目の見積時審査に続いて、再度の見積時審査を行う場合の、ユーザが行う画面操作イメージである。
見積時審査は、先に説明したように任意のタイミングで複数回行われる場合がある。ここでは、見積時審査業務フローを２回連続して行う場合を想定し、以下、ユーザが行う操作手順を説明する。

（１）ユーザは、２回目の見積時審査を開始する時点で、画面右側の「見積時審査業務フロー」ラベルを、画面左側の「進捗情報」欄に貼り付ける。
（２）「見積時審査業務フロー」ラベルを貼り付けると、画面左側の１つ目の「見積時審査業務フロー」ラベルの下に、２つ目の「見積時審査業務フロー」ラベルが現れる。
（３）ユーザは、１つ目の見積時審査業務フローと同様に、各業務の進捗状況を、別途設ける業務進捗の入力画面（図示せず）上で入力する。

図８は、プロジェクトの計画時審査を行う時点で、ユーザが行う画面操作イメージである。ここでは、２回目の見積時審査業務フローに続いてプロジェクト計画時審査業務フローを行うものと仮定する。以下、ユーザが行う操作手順を説明する。

（１）ユーザは、プロジェクトの計画時審査を開始する時点で、画面右側の「プロジェクト計画時審査業務フロー」ラベルを、画面左側の「進捗情報」欄に貼り付ける。
（２）「プロジェクト計画時審査業務フロー」ラベルを貼り付けると、画面左側の２つ目の「見積時審査業務フロー」ラベルの下に「プロジェクト計画時審査業務フロー」ラベルが現れる。

（３）「プロジェクト計画時審査業務フロー」ラベル上では、現在のプロジェクト計画時審査業務フローの進捗状態が「（４．１）部内レビュー結果登録」であることを示すように、同業務が色付きで表示される。
（４）ユーザは、プロジェクト計画時審査業務フローの進捗状況を、別途設ける業務進捗の入力画面（図示せず）上で入力する。入力に応じて、プロジェクト計画時審査業務フローの進捗状態が、「（４．１）部内レビュー結果登録」から「（４．３）結果承認」へ向かって進行する。

以後、ユーザは、プロジェクトの進捗に応じて、各業務フローが発生した時点で、その業務フローラベルをクライアント端末２００の画面上で順次貼り付けて追加していく。
他のユーザは、画面左側の「進捗情報」欄を閲覧することで、当該プロジェクトにおいて過去に発生した業務フローの発生時点や順序、現時点での業務の進捗状況を即座に把握することができる。

以上の説明において、各業務の進捗状況を色付き表示で画面表示することを説明したが、これは１例であり、開始日や終了日などの数値、その他の文字列など、任意の表示形式を用いることができる。

また、以上の説明において、業務フローの発生時点で各業務フローラベルを画面左側に順次貼り付けて業務フローを追加していくことを説明したが、業務フローの追加に限ることなく、変更や削除、検索といった機能を設けてもよい。

なお、図３〜図８で説明したような画面は、クライアント端末２００にインストールされたクライアントアプリケーションの画面として構成することもできるし、Ｗｅｂブラウザ上に表示されるＷｅｂアプリケーションの画面として構成することもできる。
図３〜図８で説明したような画面をＷｅｂアプリケーションとして構成する場合は、これらの画面をＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルやＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）、Ｗｅｂブラウザ上で実行されるスクリプトファイルなどで構成することができる。
その他、Ｊａｖａ（登録商標）アプレットなど、Ｗｅｂブラウザ上で実行されるアプリケーションとして構成することもできる。

以上、本実施の形態１では、業務処理システムの構成と動作を、主にクライアント端末２００上の画面構成の観点から説明した。

なお、図４〜図８で説明した画面イメージは１例であり、これと同様の内容を表すその他の画面構成を採用することもできることを付言しておく。

以上のように、本実施の形態１に係る業務処理システムによれば、ユーザは、各業務フローが発生した時点で、クライアント端末２００の画面右側に表示されている業務フローラベルを画面左側に貼り付ることにより、非定期かつ非連続で発生する業務フローを、発生時点で任意に組み合わせることができる。
これにより、必ずしも直列的な流れのみでは完結しない業務フローを任意に組み合わせて新たな業務フローを構築し、管理することができるので、従来のワークフロー管理システムでは実現することができなかった、非定型な業務フローの進捗管理を行うことができる。

また、本実施の形態１に係る業務処理システムでは、非定型な業務フローの中にも、直列的な流れのみで完結する定型的な部分業務フローが存在することに着目し、これを業務フローラベルとして画面部品化し、ユーザがこのラベルを任意に組み合わせることで、非定型な業務フローの進捗管理を行うことができるようにした。
これにより、個々の部分業務フローを発生の都度定義する必要がなく、非定型な業務フローを画面上で構築するに際して、ユーザの負担を最小限に抑えることができる。

また、本実施の形態１に係る業務処理システムでは、各業務フローを構成する個々の業務の進捗状況を、色付きの表示で画面表示するようにしたので、任意の組み合わせで構成した非定型な業務フローの進捗状況を、容易に把握することができる。

また、本実施の形態１に係る業務処理システムでは、各業務フローの組合せおよび処理順を、各業務フローをラベル状に表示した掲示板形式で画面表示するので、ユーザにとって親しみやすい表示形式で、非定型な業務フローの進捗状況を容易に把握することに資する。

実施の形態２．
実施の形態１では、本発明に係る業務処理システムの構成と動作を、主にクライアント端末２００上の画面構成の観点から説明した。
本実施の形態２では、サーバ１００の記憶手段１１０が格納している業務フロー管理データベースの構成、およびサーバ１００とクライアント端末２００の間の通信について、詳細を説明する。

図９は、記憶手段１１０が格納している業務フロー管理データベースの構造とデータ例を示すものである。
図９（ａ）は、業務フロー管理データベースが保持している業務フロー定義テーブルの構成とデータ例、図９（ｂ）は、同データベースが保持している業務フロー組合せテーブルの構成とデータ例である。

図９（ａ）に示す業務フロー定義テーブルは、本発明に係る業務処理システムの管理者などのユーザがあらかじめ業務フローの既定データを格納しておくものである。
図９（ｂ）に示す業務フロー組合せテーブルは、ユーザが実施の形態１で説明した図３〜図８の操作を行う度に、データが追加、変更または削除されていくものである。

図９（ａ）に示す業務フロー定義テーブルは、「業務フローＩＤ」列、「業務フロー名」列、「構成業務」列を有する。
「業務フローＩＤ」列には、図２で説明した各業務フローの識別ＩＤが格納される。
「業務フロー名」列には、図２で説明した各業務フローの名称が格納される。
「構成業務」列には、「業務フローＩＤ」列の値で特定される業務フローを構成する各業務と、その流れを示す情報とが格納される。

図９（ａ）では、図２で説明した各業務フローに即したデータ例を示した。
例えば、図９（ａ）の２行目のデータは、図２の「（２）最適化検討」業務フローの内容を表している。
同業務フローは、「（２．１）結果登録」−＞「（２．２）結果承認」の順で業務が流れるため、「構成業務」列の値では、その旨を表すデータを格納している。

図９（ｂ）に示す業務フロー組合せテーブルは、「プロジェクトＩＤ」列、「業務フローＩＤ」列、「業務フロー順序」列を有する。
「プロジェクトＩＤ」列には、管理対象とするプロジェクトの識別ＩＤが格納される。
「業務フローＩＤ」列には、「プロジェクトＩＤ」列の値で特定されるプロジェクトを構成する業務フローの識別ＩＤが格納される。本列は、業務フロー定義テーブルの「業務フローＩＤ」列に外部参照している。
「業務フロー順序」列には、「プロジェクトＩＤ」列の値で特定されるプロジェクトにおいて、「業務フローＩＤ」列の値で特定される業務フローが、何番目に位置するかを示す番号が格納される。

図９（ｂ）では、図８で説明した画面イメージに即したデータ例を示した。
図８の画面イメージでは、「見積時審査」業務フローが２回連続しており、図９（ｂ）の３行目と４行目のデータでこれを表現している。
即ち、「業務フローＩＤ＝１０３」の業務フローは、図９（ａ）を参照すると「見積時審査」業務フローであることが分かり、したがって「見積時審査」業務フローは、３番目と４番目で連続して行われることが分かる。

本実施の形態２における「業務フロー定義情報」は、業務フロー定義テーブルに格納されるデータがこれに相当する。
また、「業務フロー組合せ情報」は、業務フロー組合せテーブルに格納されるデータがこれに相当する。
また、「既定の業務フロー定義情報」は、業務フロー定義テーブルにあらかじめ登録された図９（ａ）のようなデータがこれに相当する。

以上、業務フロー管理データベースの構成とデータ例について、実施の形態１の図２〜図８に即して説明した。
次に、サーバ１００とクライアント端末２００の間の通信について、業務フロー管理データベースのデータ更新、および図３〜図８の各画面イメージとの関係と併せて、ステップを追って詳細を説明する。

（１）業務フロー定義テーブルのデータ登録
ユーザは、クライアント端末２００を用いて、図２で説明した各業務フローの内容を入力し、サーバ１００に送信する。入力画面（図示せず）は別途設ける。
サーバ１００は、入力内容を受信し、その内容を業務フロー定義テーブルに登録する。ここでは図９（ａ）と同内容のデータが登録されたものとする。

（２）プロジェクト情報掲示板のリクエスト
ユーザは、プロジェクトが開始されると、クライアント端末２００を用いてサーバ１００にアクセスし、図３の画面をサーバ１００にリクエストする。
サーバ１００は、業務フロー定義テーブルより図９（ａ）に示すデータを取得し、これを用いて図３の画面を生成して、クライアント端末２００に送信する。
クライアント端末２００は、受信した図３の画面を画面表示する。
なお、サーバ１００は図９（ａ）に示すデータのみをクライアント端末２００に送信し、クライアント端末２００にて図３の画面を生成して表示するようにしてもよい。その他の画面についても同様である。

（３）発生した業務フローの登録
ユーザは、各業務フローが発生する毎に、クライアント端末２００を用いて、図４〜図８で説明した画面イメージのような操作を行う。ユーザがクライアント端末２００上で各業務フローラベルの貼り付けを行う毎に、業務フロー組合せテーブルにデータが１行追加される。
例えば、ユーザが図４の画面操作を行った場合、クライアント端末２００は、当該プロジェクトの１番目の業務フローとして「引き合い業務フロー」が選択された旨を、サーバ１００に送信する。
サーバ１００は、クライアント端末２００より上記の旨を受信し、図９（ｂ）の１行目のデータを、業務フロー組合せテーブルに登録する。
以後同様に、ユーザがクライアント端末２００上で図５〜図８の画面操作を行う毎に、図９（ｂ）の各行のデータが、業務フロー組合せテーブルに登録される。

以後、クライアント端末２００がサーバ１００に図４〜図８の画面をリクエストすると
、サーバ１００は業務フロー組合せテーブルより図９（ｂ）に示すデータを取得し、これを用いて図４〜図８の画面を生成して、クライアント端末２００に送信する。
クライアント端末２００は、受信した図４〜図８の画面を画面表示する。
即ち、以後のリクエストでは、業務フローが発生順に組み合わされた状態で、クライアント端末２００上の画面表示がなされる。

（４）業務の進捗状況の入力
ユーザは、各業務フローを構成する業務の進捗状況を、クライアント端末２００を用いて、別途設ける入力画面（図示せず）上で入力する。
クライアント端末２００は、各業務の進捗状況を、サーバ１００に送信する。
サーバ１００は、受信した各業務の進捗状況を、業務フロー管理データベース上の適当な領域に格納する。

以後、クライアント端末２００がサーバ１００に図４〜図８の画面をリクエストすると
、サーバ１００は業務フロー管理データベースより各業務の進捗状況を取得し、これを用いて現在の進捗状況を色付きで表示した図４〜図８の画面を生成して、クライアント端末２００に送信する。
クライアント端末２００は、受信した図４〜図８の画面を画面表示する。
即ち、以後のリクエストでは、各業務の進捗が色付き表示された状態で、クライアント端末２００上の画面表示がなされる。

以上、本実施の形態２では、業務処理システムの構成と動作を、主にサーバ１００の記憶手段１１０が格納している業務フロー管理データベースの構成、およびサーバ１００とクライアント端末２００の間の通信の観点から説明した。

なお、図９で説明した業務フロー管理データベースの構成は１例であり、これ以外の構成で業務フロー管理データベースを構成することもできることを付言しておく。

以上のように、本実施の形態２に係る業務処理システムでは、業務フロー管理データベースに図９（ａ）（ｂ）の各テーブルを設けるとともに、各業務の進捗状況を格納する領域を設け、サーバ１００は、クライアント端末２００から図４〜図８の画面操作入力を受けてその内容を各テーブルに格納する。
そのため、本実施の形態２に係る業務処理システムは、クライアント／サーバ型のシステムや、Ｗｅｂシステムなどの形態で実装することができ、したがってユーザは、ネットワーク３００を介して任意の場所から、プロジェクトの進捗状況や、業務フローの組合せおよび処理順を参照することができる。

実施の形態３．
実施の形態２では、図９（ａ）（ｂ）を用いて、業務フロー管理データベースの構成とデータ例を説明した。また、同データベースのデータ更新、およびサーバ１００とクライアント端末２００の間の通信の詳細について説明した。
本発明の実施の形態３では、業務フロー管理データベースの別の構成とデータ例を示す。同構成により、各業務フローを構成する業務を柔軟に定義可能とすることを図る。

図１０は、本実施の形態３における業務フロー管理データベースの構造とデータ例を示すものである。
本実施の形態３における業務フロー管理データベースでは、図９（ａ）に示した業務フロー定義テーブルを細分し、図１０（ａ）（ｃ）（ｄ）の３テーブルで構成した。
図１０（ａ）は新たな業務フロー定義テーブル、図１０（ｃ）は業務定義テーブル、図１０（ｄ）は業務フロー構成定義テーブルの構成とデータ例である。なお、業務フロー組合せテーブルは、図９（ｂ）に示したものと同様であるため、記載を省略した。

図１０（ａ）に示す新たな業務フロー定義テーブルは、図９（ａ）に示すものと同様の役割を果たすものである。
図１０（ｃ）に示す業務定義テーブルは、本発明に係る業務処理システムの管理者などのユーザがあらかじめ各業務の既定データを格納しておくものである。
図１０（ｄ）に示す業務フロー構成定義テーブルは、業務フローと各業務の関連付け定義を、本発明に係る業務処理システムの管理者などのユーザがあらかじめ格納しておくものである。

図１０（ａ）に示す新たな業務フロー定義テーブルは、「業務フローＩＤ」列、「業務フロー名」列を有する。
図９（ａ）に示した構成と比較すると、「構成業務」列が他のテーブルに移動されているが、その他の列の構成は、図９（ａ）と同様である。なお、データ例は、図９（ａ）と同じものを用いた。

図１０（ｃ）に示す業務定義テーブルは、「業務ＩＤ」列、「業務名」列を有する。
「業務ＩＤ」列には、各業務フローを構成する業務の識別ＩＤが格納される。
「業務名」列には、「業務ＩＤ」列の値で特定される業務の名称が格納される。

図１０（ｃ）では、図９（ａ）で説明した「構成業務」列に即したデータ例を示した。
例えば、図１０（ｃ）の１〜２行目のデータは、図９（ａ）の２行目の「構成業務」列の内容を表している。
業務フロー定義テーブルと、業務定義テーブルとの関連付けは、次に説明する業務フロー構成定義テーブルで定義される。

図１０（ｄ）に示す業務フロー構成定義テーブルは、「業務フローＩＤ」列、「業務ＩＤ」列、「業務フロー内順序」列を有する。
「業務フローＩＤ」列は、業務フロー定義テーブルの「業務フローＩＤ」列に外部参照している。
「業務ＩＤ」列は、業務定義テーブルの「業務ＩＤ」列に外部参照している。
「業務フロー内順序」列には、「業務フローＩＤ」列の値で特定される業務フロー内において、「業務ＩＤ」列の値で特定される業務が位置する順序が、数値で格納される。

「業務フローＩＤ」列と「業務ＩＤ」列の組合せにより、各業務フローを構成する業務が定義される。また、「業務フロー内順序」列の値により、各業務フロー内における各業務の処理順が定義される。

本実施の形態３における「業務定義情報」は、業務定義テーブルに格納されるデータがこれに相当する。
また、「業務フロー構成定義情報」は、業務フロー構成定義テーブルに格納されるデータがこれに相当する。

図１１は、図１０（ａ）（ｃ）（ｄ）の各テーブルより、業務フローと構成業務の関連付けを抽出する処理を説明するものである。ここでは、図１０（ｄ）の下半分のデータを例に取って説明することとし、以下にサーバ１００およびクライアント端末２００の処理を、ステップ毎に説明する。

（１）サーバ１００は、クライアント端末２００より、図３〜図８のいずれかの画面に対するリクエストを受けると、業務フロー管理データベースより、図１０（ｄ）に示す業務フロー構成定義テーブルを参照する。

（２）サーバ１００は、業務フロー構成定義テーブルの「業務フローＩＤ」列より取得した値をキーにして業務フロー定義テーブルを参照し、当該業務フローＩＤに相当する業務フロー名を得る。
ここでは、「業務フローＩＤ＝１０３」をキーにして業務フロー定義テーブルを参照し、「業務フロー名＝見積時審査」を得る。

（３）サーバ１００は、業務フロー構成定義テーブルの「業務ＩＤ」列より取得した値をキーにして業務定義テーブルを参照し、当該業務ＩＤに相当する全ての業務名を得る。
ここでは、「業務ＩＤ＝２０２」〜「業務ＩＤ＝２０４」をキーにして業務定義テーブルを参照し、「業務名＝結果承認」、「業務名＝部内レビュー結果登録」、「業務名＝審査結果登録」を得る。

（４）サーバ１００は、上記ステップ（３）で取得した業務名を、業務フロー構成定義テーブルの「業務フロー内順序」列より取得した順番に並び替える。
ここでは、（１）「部内レビュー結果登録」、（２）「審査結果登録」、（３）「結果承認」の順番に並び替えられる。

（５）サーバ１００は、以上のステップで取得および並び替えしたデータに基づき、「（３）見積時審査」業務フローラベルを構築し、クライアント端末２００に返信する。
ここでは、図１１下図に示すような業務フローラベルを構築し、クライアント端末２００に返信する。

（６）クライアント端末は、サーバ１００が送信した「（３）見積時審査」業務フローラベルを、図３〜図８で示すような画面の右側に表示する。
なお、ステップ（１）〜（５）でサーバ１００が取得および並び替えしたデータのみをクライアント端末２００に送信し、クライアント端末２００にて、「（３）見積時審査」業務フローラベルを構築してもよい。

サーバ１００は、以上のような処理手順により、図９（ａ）に示した業務フロー定義テーブルと同様のデータを、図１０（ａ）（ｃ）（ｄ）の各テーブルより取得したデータを用いて生成することができる。
実施の形態２で説明した図９の構成と比較すると、業務フロー定義と業務定義を個別に登録し、両者の関係を表す情報がこれらの定義と切り離されているので、各業務フローおよびその構成業務を、柔軟に定義することができる。

なお、図１０〜図１１で説明した業務フロー管理データベースの構成は１例であり、実施の形態２と同様に、これ以外の構成で業務フロー管理データベースを構成することもできることを付言しておく。

また、図１０〜図１１では、同名の業務は同一のものとして取り扱ったが、対象部署の違いに応じて、それぞれを別個の業務として取り扱うこととしてもよい。
例えば、「業務名＝結果承認」は、複数の業務フロー内で用いられる業務であるが、その実行部署によって内容が異なる。そのため、以下の（１）〜（４）のように、実行部署に応じて別個の業務として定義してもよい。

（１）業務名＝結果承認（実行部署）
（２）業務名＝結果承認（実行管理部署）
（３）業務名＝結果承認（管理部署）
（４）業務名＝結果承認（受審部署）

以上のように、本実施の形態３によれば、業務フローと各構成業務の関連付けを柔軟に定義することができるので、管理対象とすることのできる業務フローの構成が広がり、より多様な業務フローの進捗状況を管理することが可能となる。

実施の形態１に係る業務処理システムの構成図である。 実施の形態１に係る業務処理システムで管理する業務フローの一覧である。 クライアント端末２００からサーバ１００にアクセスした際の画面イメージである。 情報システムの受託開発の引き合いがあった時点で、ユーザが行う画面操作イメージである。 プロジェクトの最適化検討を行う時点で、ユーザが行う画面操作イメージである。 プロジェクトの見積時審査を行う時点で、ユーザが行う画面操作イメージである。 １回目の見積時審査に続いて、再度の見積時審査を行う場合の、ユーザが行う画面操作イメージである。 プロジェクトの計画時審査を行う時点で、ユーザが行う画面操作イメージである。 記憶手段１１０が格納している業務フロー管理データベースの構造とデータ例を示すものである。 実施の形態３における業務フロー管理データベースの構造とデータ例を示すものである。 図１０（ａ）（ｃ）（ｄ）の各テーブルより、業務フローと構成業務の関連付けを抽出する処理を説明するものである。

符号の説明

１００ サーバ、２００ａ〜２００ｂ クライアント端末、３００ ネットワーク。

Claims (4)

1. 業務処理の進捗状況を管理するシステムであって、
   業務処理の進捗状況の入力を受け付けるクライアント端末と、
   前記進捗状況を保持するデータベースを格納した記憶手段を備えるサーバと、
   を有し、
   前記データベースは、
   直列的に連続する複数の業務からなる業務フローを定義した業務フロー定義情報と、
   前記業務フローの組合せおよび処理順を定義した業務フロー組合せ情報と、
   を保持する領域を有し、
   前記クライアント端末は、
   前記進捗状況または前記業務フロー組合せ情報の入力を受け付けてこれらの情報を前記サーバに送信し、
   前記サーバは、
   その進捗状況または業務フロー組合せ情報を前記データベースに格納し、
   前記クライアント端末は、
   業務処理の新たな進捗状況の入力を受け付ける際に、
   前記サーバより、前記進捗状況、前記業務フロー定義情報、および前記業務フロー組合せ情報を取得し、
   前記業務フローの組合せおよび処理順、各前記業務フローを構成する業務およびその順序、並びに各業務の進捗状況を画面表示する
   ことを特徴とする業務処理システム。
2. 前記データベースは、
   前記業務フローを構成する各業務を定義した業務定義情報と、
   前記業務フローと各業務の関連付けを定義した業務フロー構成定義情報と、
   を保持する領域を有し、
   前記クライアント端末は、
   前記業務定義情報または前記業務フロー構成定義情報の入力を受け付けてこれらの情報を前記サーバに送信し、
   前記サーバは、
   その業務定義情報または業務フロー構成定義情報を前記データベースに格納することにより、
   各業務フローを構成する業務を前記クライアント端末から任意に定義可能とした
   ことを特徴とする請求項１に記載の業務処理システム。
3. 前記クライアント端末は、
   前記業務フローの組合せおよび処理順を、
   各業務フローをラベル状に表示した掲示板形式で画面表示する
   ことを特徴とする請求項１または請求項２に記載の業務処理システム。
4. 前記データベースは、
   既定の前記業務フロー定義情報をあらかじめ格納しており、
   前記クライアント端末は、
   前記規定の業務フロー定義情報を前記サーバより取得し、
   業務フローの組合せ順の入力のみを受け付けて前記サーバに送信する
   ことを特徴とする請求項１ないし請求項３のいずれかに記載の業務処理システム。

Images