JP2005092620A - 業務プロセス管理システム - Google Patents

Abstract

【課題】 業務プロセスを構成する業務を複数の担当者が受け持ち、それを並列実行する際に好適なワークフローの管理、構築することの可能な業務プロセス管理システムを提供する。
【解決手段】 業務データベースにおいては、各業務に関するデータが業務に固有の名前で管理される。また、当該業務に関わる担当者に数だけ、同じ業務に固有の名前の下に、異なる管理番号を有する配列として管理される。従って、所定の部署の所定の担当者に提示する作業内容を示した帳票は、当該業務に固有のデータや業務に共通のデータを埋め込むことによって生成でき、当該担当者が入力した作業結果などは、同じ帳票を用いて入力されるが、入力内容そのものは、異なる管理番号を用いて管理される。
【選択図】 図６

Description

本発明は、業務プロセスを管理するワークフローシステムに関して、特に業務プロセスを構成する業務を複数の担当者が受け持ち、それを並列実行する際に好適なワークフローの管理及び構築可能な業務プロセス管理システムに関する。

業務プロセスの実行を管理し、業務効率を向上させるシステムの一つとしてワークフローシステムがある。ワークフローシステムでは、一般に、事前に定義されたフロー定義情報に従って適切なタイミングで各担当者に実務実行を促す。フロー定義情報は、実行すべき業務の順序をグラフィカルなモデルなどで表現したものである。また、ワークフローシステム上で実行される各業務においては、パーソナルコンピュータ等の画面に表示される帳票フォームを用いてデータの入出力を行う場合が多い。

フロー定義情報や帳票フォーム定義情報は業務によって異なるものであり、ワークフローシステムを運用する前に、適切に構築する必要があるが、その構築に必要な工数がなるべく少ないワークフローシステムが望まれる。これらの定義情報構築を簡便化する手段の一つとして、複数の担当者が同種の業務を平行に実行するようナ業務プロセスの場合に、フロー定義情報中の該当業務の定義情報や、該当業務における帳票フォーム定義情報としては、一つだけを定義しておき、運用の時点で自動的に複数担当者に適用することが考えられる。このような技術に関し、特許文献１には、複数の担当者間で行う帳票処理業務において、フロー定義情報に帳票の複写配布・待合、条件分岐などの制御情報を新たに追加し、クライアントからのデータの受信を監視する通信監視部、解釈実行する業務フロー解釈実行部をサーバ上に設けていることにより、複雑な転送処理を含む業務実行支援システムの構築を可能にする方法が開示されている。また、特許文献２には、複数の担当者が書類や情報をやり取りしながら共同作業を行うような業務について、複数の業務を並列に実行する際に、リレーショナルデータベースの業務データまたは分散オブジェクトの参照を行うことにより、複数業務処理の動的な生成と並列実行を可能とするワークフローシステムが開示されている。
特願平６−２６００１２号明細書 特願平１０−２６４２８８号明細書

上記従来技術には、次のような課題がある。
すなわち、特許文献１では、帳票に入力されたデータの管理方法が考慮されておらず、ある帳票に入力されたデータを他の帳票に引き継いだり、入力されたデータの値によって転送を制御するなどの業務プロセスを構築するためには、別途そのための処理プログラムを作成する必要があった。特許文献２では、帳票フォーム定義情報の構築支援方法が考慮されておらず、帳票に入力されたデータをデータベースに格納する処理や、データベースのデータに応じた複数業務については個別に定義する方式となっている。このため、業務プロセスを構築する際には、これらの処理プログラムや処理スクリプトを別途作成する必要があった。

本発明の課題は、業務プロセスを構成する業務を複数の担当者が受け持ち、それを並列実行する際に好適なワークフローの管理、構築することの可能な業務プロセス管理システムを提供することである。

本発明の業務プロセス管理システムは、業務プロセスの流れを取得する手段と、該業務プロセスの流れ中の同一業務中で並列作業が生じる場合に、並列作業のそれぞれの作業を記述する、同一業務プロセスのデータ群内で異なる管理識別子によって管理されるレコードを生成するレコード生成手段と、該並列作業で帳票に入力された、それぞれの入力内容を、同一業務プロセスのデータ群内で固有の管理識別子を与えて管理する入力管理手段とを備え、１つの業務プロセスの流れの定義と１つの帳票フォーマットを用いて、並列作業を管理することを特徴とする。

本発明によれば、並列作業を行う担当者に提示する固有のデータ内容及び、該担当者が入力した固有の入力データ内容を、その作業が属する業務プロセスのデータ群内で異なる管理識別子を用いて管理し、１つの業務プロセスの流れの定義と、１つの帳票に、異なる管理識別子で管理されたデータ内容を適用する。

本発明によれば、フロー定義情報の要素であって業務プロセスを構成する業務を示す各アクティビティにおいて入力または出力されるデータの定義であるデータフロー情報を利用して作成された帳票フォーム定義情報を制御する際に、入出力するデータの管理を行うデータテーブルとしてデータブロー定義情報から生成する業務データ管理テーブルを使用し、更に、いずれかのアクティビティにおいて複数の担当者が平行して実施するなどの多重制御が必要である場合には、業務データ管理テーブルにおいて多重度数分の管理領域を自動的に用意して使用する処理を備えることにより、同一の帳票フォーム定義情報を用いて多重制御を行うことが可能となり、ワークフロー制御やデータ管理処理を個別に作成する必要が無く、業務システム構築の工数を低減する効果を有する。

図１は、本発明の実施形態に従った、帳票フォームの表示処理を説明する図である。
まず、クライアント１０からデータベースを管理するサーバ１１に帳票表示要求がクライアント１０から送られる。帳票表示においては、フォーム一覧表示制御機能が提供される。フォーム一覧表示制御機能においては、フォーム属性制御と業務データベースアクセス機能が提供される。帳票表示要求をサーバ１１が受け取るとデータベース１２にアクセスし、帳票をクライアント１０の画面に表示する。クライアント１０では、帳票に対し、必要な処理を行った後、帳票完了要求をサーバ１１に送信する。この場合、クライアント１０に表示される帳票表示には、帳票処理の完了機能と、帳票の一時保存機能が提供される。サーバ１１では、帳票処理の終わった時点での帳票をスナップショットとしてサーバ１１の画面に表示する。

図２は、フォーム属性制御機能を説明する図である。
クライアント１０には、ＴＯＤＯリストが表示される。ＴＯＤＯリストは、クライアント１０を利用するアクティビティ（担当業務）の担当者が実行すべき（to do）内容を表示するリストである。フォーム属性制御部２０は、担当者がＴＯＤＯリストから帳票を作成可能とするために、フォーム属性制御機能を提供する。フォーム属性制御機能は、業務データ管理テーブル２１、フォーム制御マスタ２２、帳票構成情報２３、業務データワークテーブル２４、マスクテーブル２５にアクセスして、これらのデータベースから得られたデータを連想配列機能を使って配列し、帳票表示機能によって、クライアント１０の画面に帳票を表示させる。すなわち、フォーム属性制御機能においては、フォーム部品に含まれる可変となる部分の値を取得する。取得された値は配列の中に格納され、配列はフォームレイアウト内に埋め込まれたフォーム部品より参照される。

図３は、業務データベースアクセス機能を説明する図である。
クライアント１０のＴＯＤＯリスト表示画面から、帳票表示処理の一部として、業務データベースにアクセスする。この場合には、データフローポイントマスタ３０、ワークフロー管理テーブル３１、業務名リスト３２、帳票構成情報３３、業務データワークテーブル２４、業務データ管理テーブル２１にアクセスして情報を取得する。得られた情報は、業務データワークテーブル２４に格納されると共に、クライアント１０の画面に帳票が表示される。帳票表示画面から帳票完了処理の一部として、業務データベースにアクセスする。アクセスするデータベースとしては、業務データテンプレートテーブル３６、業務データワークテーブル２４、フォーム制御マスタ３８、業務データ管理テーブル２１がある。各データベースにアクセスして得られた情報は、業務データ管理テーブル２１に格納される。

すなわち、業務データベースでは、データ一覧において、整理された業務データ名に対し、使用部署の観点からレコードを拡張して格納する。
使用部署で拡張された業務データ名（例えば、品質保証部＿検討結果）に対して、複数の担当者がデータを設定する場合、担当者の観点でのレコード拡張は、データ一覧で指定された個数に基づく配列として処理される。更に、差し戻しなどの動作により、同一フロー実行中に、複数回、同一アクティビティが実行されるケースにおいて、各々別のレコードを生成することでフロー実行の履歴をトレース可能とする。

図４は、業務データのトレースの仕組みを説明する図である。
同図（ａ）に示されているように、ａにおいて、検討依頼が承認され、ｂにおいて、検討部署が回答を作成し、ｃにおいて、検討部署の審査が行われ、ｄのように１回検討部署に再検討の指示が出され、ｅにおいて、再び検討部署の審査が行われ、、ｆにおいて、検討部署の承認がされ、ｇで依頼部署が検討部署の回答を検討するという業務の流れとなっているとする。

同図（ｂ）に示されるように、ｂの時点で、検討開始時には、帳票は白紙である。検討部署の回答が出来ると、ｂの時点の下の図のように、帳票に回答が書き込まれる。このとき、この回答のＩＤは、ｂとなる。ｃの時点において、１回目の回答が記述された帳票が検討部署の審査に付され、審査した結果の担当者上司のコメント（１回目）が帳票に書き込まれる。このとき、１回目の担当者上司のコメントのＩＤは、ｃとなる。次に、ｄの時点で、検討部署の担当者に１回目の回答と１回目の上司のコメントが記載された帳票が渡される。ここで、再検討され、検討部署の担当者の２回目の回答が生成され、１回目の回答に２回目の回答を上書きした帳票が作成される。２回目の回答のＩＤは、ｄである。ｅの時点では、２回目の回答が審査される。帳票には、２回目の回答が表示される。審査した結果の２回目の上司のコメントは、帳票においては、１回目の上司のコメントに上書きした形で表示される。このとき、上司の２回目のコメントは、ＩＤがｅとなる。そして、ｆの時点で、２回目の回答と、２回目の上司のコメントが表示された帳票が検討部署の承認に回され、管理者のコメントが付加される。管理者のコメントのＩＤは、ｆとなる。そして、ｇの時点で、依頼部署には、検討部署の２回目の回答と、２回目の上司のコメントと、管理者のコメントが表示された帳票が渡され、回答を検討することとなる。

すなわち、一プロセスで同一データ名のデータが複数レコード生成される。これらは異なるＩＤを持つ。また、各時点で表示に必要な情報のＩＤは、自己のＩＤとは異なる（別のアクティビティで格納された情報）ため、帳票の表示に際しては、ＩＤが最も大きいレコードを条件としてデータベースを検索することで最新情報を抽出する。

図５は、業務データベースアクセスからのワークテーブルの作成について説明する図である。
業務データベース（業務データ管理テーブル）へのアクセスは主に帳票の表示、帳票の完了・一時保存時に行われる。しかし、帳票内で常に業務データ管理データベースにアクセスするのではなく、多くのアクセスは業務データワークテーブルに対して行われる。業務データワークテーブルは、帳票の表示時に業務データ管理テーブルとデータフローポイントマスタから作成され、表示している帳票で必要なデータを保持する。業務データワークテーブルは、当該システムへのログインＩＤとプロセスＩＤをキーに管理され、帳票の完了時に対応するデータが削除される。

図６は、業務データベースとアクティビティの概念を説明する図である。
同図（ａ）は、業務データベースの概念である。業務データベースには、依頼部署である各担当部署の名前（Ａ部、Ｂ部）と、検討部署の回答の年月日からなる業務データが保管される。各業務データは、部ごとに設けられ、振り分け可能な担当者の数だけ配列として保持される。

同図（ｂ）は、アクティビティと帳票表示の説明である。Ａ部の担当１の回答のアクティビティに固定部品”部品＿Ａ部＿回答年月日＿００１．ｈｔｍｌ”があった場合には、業務データベースの”Ａ部＿回答年月日・配列１”のデータを参照・表示する。同アクティビティに部品＿共通＿回答年月日．ｈｔｍｌ”があった場合は、フォーム表示時に部署名を判断し、業務データベースの”Ａ部＿回答年月日・配列１”のデータを参照・表示する。

同じ部品（部品＿共通＿回答年月日．ｈｔｍｌ）が、Ｂ部の担当１の回答のアクティビティにあった場合はフォーム表示時に部署名を判断するので、業務データベースの”Ｂ部＿回答年月日・配列１”のデータを参照し、表示する。固定部品は、フォーム表示前に参照する業務データベース位置が決まっているが、共通部品はフォーム表示時にのみ参照する業務データベース位置が決定する。

図７及び図８は、作成するフォルダ及び業務データ毎の部品の配置を説明する図である。
図７において、部品データの作成時にフォーム配列フォルダと部品配置フォルダを作成する。フォーム配置フォルダとは、オペレータによるフォームレイアウト済みのフォームを格納するためのフォルダである。部品配置フォルダとは、業務データ毎の部品を配置するフォルダだ得る。フォルダの構成は、図７に示すとおりである。ここで、｛情報種別｝と｛部署名ｎ｝は可変の値となる。

図７においては、指定フォルダの下に、部品配置フォルダとフォーム配置フォルダとが設けられている。部品配置フォルダにおいては、情報種別、部署名を元にフォルダを作成する。フォルダ内のファイルは上書きする。フォーム配置フォルダにおいては、情報種別を元にフォルダを作成する。既に、同名のフォルダが存在した場合は、そのフォルダは作成しない。

図８は、図７において、｛情報種別｝が回答情報である各フォルダの構成を示す図である。
回答情報のフォルダには、部品＿共通＿回答年月日．ｈｔｍｌ、部品＿共通＿検討依頼項目．ｈｔｍｌ、部品＿共通＿検討結果．ｈｔｍｌが格納される。回答情報フォルダの下位のフォルダには、品質保証部のフォルダや、生産技術部のフォルダが設けられる。

品質保証部のフォルダには、品質保証部に対する回答年月日、検討依頼項目、検討結果のデータが保管される。同様に、生産技術部では、生産技術部に対する回答年月日、検討依頼項目、検討結果のデータが格納される。なお、フォーム配置フォルダの回答情報の内部には、情報種別のフォルダが生成される。

図９は、フォームエンジンの全体の処理を説明するフローチャートである。
なお、点線内は、フォーム属性制御機能の動作を示している。
まず、ステップＳ１０において、ユーザがＴＯＤＯリストから一つの案件Ｐの業務Ｗを選択する。ステップＳ１１において、帳票構成情報３３を参照して、案件Ｐ、業務Ｗに対応するフォーム定義ファイルの所在情報とフォーム内に存在するデータ項目名を取得する。ステップＳ１２において、フォーム制御マスタ３８を参照して、各データ項目名の属性定義を取得する。ステップＳ１３において、業務名リスト３２を参照して、案件Ｐ、業務Ｗの各データ項目について、それぞれの最新の管理番号を取得する。ステップＳ１４において、業務データテーブル（業務データ管理テーブル２１、あるいは、業務データワークテーブル２４）を参照して、案件Ｐ、業務Ｗの各データ項目の最新の管理番号におけるデータ値を取得し、連想配列に格納する。ステップＳ１５において、フォーム定義ファイル中の各データ項目から連想配列を参照して、属性定義とデータ値を取得する。ステップＳ１６において、画面に帳票を表示する。ステップＳ１７において、ユーザが画面からデータを入力する。ステップＳ１８において、入力されたデータ値を業務データテーブルに格納する。このとき、管理番号として新たな番号を付与する。

図１０〜図１３は、生成されるフォームの一例と並列作業の扱い方を説明する図である。
プロセスモデルとして図１０を仮定する。図１０において、長方形は、アクティビティ、ひし形は判断、楕円は結合を示すものとする。各ブロック内の「作業１」、「判断１」等は、ユーザが任意に入力した、各ブロックの名称である。矢印は、各ブロック（アクティビティ）間の接続を示し、矢印の根元側が遷移元、矢印の示す先が遷移先となる。

図１０のプロセスモデルは、まず、「作業１」を行い、次に「作業２」において、「作業１」の結果に対して承認／否認の判断を行い、否認であれば、「作業１」をやり直し、承認であれば、次に、「作業３」、「作業４」のどちらを行うかを判断して、「作業３」、「作業４」のいずれか一方を実行するという流れのプロセスモデルである。

ここで、「作業１」を２人の担当者が並行して実施するように設定されていたとする。このとき、本発明の実施形態における業務データ管理テーブルは、図１１に示すようになる。同じ「依頼処理」という業務名称、プロセス番号において、管理番号が２つ設けられており、それぞれについて、依頼番号、依頼内容分類、依頼内容詳細、承認コメント、検討結果、レベルが項目として設定されている。それぞれの管理番号は、異なる２人の担当者に対応する。一方の担当者は、依頼内容分類の値からわかるように、コスト見積もりを行い、他の担当者は、工作検討を行うことが記述されている。この依頼内容分類の値は、帳票が表示される場合に、担当者に示されるので、帳票のフォーマットが同じまま、異なる作業を依頼することが出来る。

この場合に生成されるフォームは、図１３に示すようになる。
フォーム作成者は、１種類のフォームのみを作成すればよく、「作業１」の担当者が２人であることに対応して２種類のフォームを作成する必要はない。「作業１」の担当者は、それぞれ違う内容のデータを入力することができる。すなわち、ここでは、それぞれの担当者は、コスト見積もりと、工作検討をすることになる。本例では、依頼内容分類がコスト見積もりであるか否かにより判断以降の進路が異なるが、そのような処理も図１２の条件式定義テーブルとして、一種類だけ定義しておけばよく、「作業１」の担当者が２人であることに対応して２種類の条件を定義する必要がない。

すなわち、２人の担当者が「作業１」という１つのアクティビティに割り当てられて、それぞれが異なる情報を帳票に書き込んだとしても、それぞれの作業内容や入力された情報は、同じ業務名称の下で、異なる管理番号で管理されるため、必要に応じて、必要な情報を管理番号を指定して呼び出すようにすればよい。従って、情報そのものは、関連付けられた異なる管理番号で管理される（同一名称の配列内で管理される）が、帳票のフォームや作業の流れを定義する条件式テーブルは、１つで良いことになり、並列作業が生じても業務プロセス管理システムを不要に複雑にする事がない。

また、異なるＩＤ、管理番号で管理する、あるいは、同一名称の配列内で並列作業を管理することは、すなわち、帳票への入力データ等を新たなメモリ領域を獲得して、データをそこに保管して管理することと同意である。

業務プロセスのフローは、並列作業の結果によって異なる場合があるが、これは、業務プロセスのフローの定義を並列作業の結果に適用することによって、並列作業のそれぞれの作業の業務プロセスの中での流れを決定する。

なお、上記の説明において、部品とは、帳票に埋め込む一つ一つの項目を示している。

本発明の実施形態に従った、帳票フォームの表示処理を説明する図である。 フォーム属性制御機能を説明する図である。 業務データベースアクセス機能を説明する図である。 業務データのトレースの仕組みを説明する図である。 業務データベースアクセスからのワークテーブルの作成について説明する図である。 業務データベースとアクティビティの概念を説明する図である。 作成するフォルダ及び業務データ毎の部品の配置を説明する図（その１）である。 作成するフォルダ及び業務データ毎の部品の配置を説明する図（その２）である。 フォームエンジンの全体の処理を説明するフローチャートである。 生成されるフォームの一例と並列作業の扱い方を説明する図（その１）である。 生成されるフォームの一例と並列作業の扱い方を説明する図（その２）である。 生成されるフォームの一例と並列作業の扱い方を説明する図（その３）である。 生成されるフォームの一例と並列作業の扱い方を説明する図（その４）である。

符号の説明

１０ クライアント
１１ サーバ
１２ データベース
２０ フォーム属性制御部
２１ 業務データ管理テーブル
２２ フォーム制御マスタ
２３ 帳票構成情報
２４ 業務データワークテーブル
２５ マスクテーブル
３０ データフローポイントマスタ
３１ ワークフロー管理テーブル
３２ 業務名リスト
３３ 帳票構成情報
３６ 業務データテンプレートテーブル
３８ フォーム制御マスタ

Claims (7)

1. 業務プロセスの流れを取得する手段と、
   該業務プロセスの流れ中の同一業務中で並列作業が生じる場合に、並列作業のそれぞれの作業を記述する、同一業務プロセスのデータ群内で異なる管理識別子によって管理されるレコードを生成するレコード生成手段と、
   該並列作業で帳票に入力された、それぞれの入力内容を、同一業務プロセスのデータ群内で固有の管理識別子を与えて管理する入力管理手段とを備え、
   １つの業務プロセスの流れの定義と１つの帳票フォーマットを用いて、並列作業を管理することを特徴とする業務プロセス管理システム。
2. 前記並列作業の結果生じる異なる業務プロセスの流れは、前記業務プロセスの流れの定義を、前記並列作業の結果に適用して決定されることを特徴とする請求項１に記載の業務プロセス管理システム。
3. 前記帳票は、該帳票のフォームに各項目を連想配列することによって得ることを特徴とする請求項１に記載の業務プロセス管理システム。
4. 前記業務プロセスの流れの中で、一人の担当者が複数回同様の作業をし、帳票に結果を入力する場合、それぞれの回の入力を異なる管理識別子を用いて管理することを特徴とする請求項１に記載の業務プロセス管理システム。
5. 前記業務プロセスの流れの中で行われた、帳票への複数回の入力の内、最新の入力内容を次のプロセスの担当者に提示することを特徴とする請求項４に記載の業務プロセス管理システム。
6. 業務プロセスの流れを取得するステップと、
   該業務プロセスの流れ中の同一業務中で並列作業が生じる場合に、並列作業のそれぞれの作業を記述する、同一業務プロセスのデータ群内で異なる管理識別子によって管理されるレコードを生成するレコード生成ステップと、
   該並列作業で帳票に入力された、それぞれの入力内容を、同一業務プロセスのデータ群内で固有の管理識別子を与えて管理する入力管理ステップとを備え、
   １つの業務プロセスの流れの定義と１つの帳票フォーマットを用いて、並列作業を管理することを特徴とする業務プロセス管理方法。
7. 業務プロセスの流れを取得するステップと、
   該業務プロセスの流れ中の同一業務中で並列作業が生じる場合に、並列作業のそれぞれの作業を記述する、同一業務プロセスのデータ群内で異なる管理識別子によって管理されるレコードを生成するレコード生成ステップと、
   該並列作業で帳票に入力された、それぞれの入力内容を、同一業務プロセスのデータ群内で固有の管理識別子を与えて管理する入力管理ステップとを備え、
   １つの業務プロセスの流れの定義と１つの帳票フォーマットを用いて、並列作業を管理することを特徴とする業務プロセス管理方法をコンピュータに実現させるプログラム。

Images