JP2018088128A - サーバ、その処理方法及びプログラム - Google Patents

Abstract

【課題】 ワークフローの承認者として会議を選択可能にする仕組みを提供する。【解決手段】 組織におけるワークフローを管理するサーバであって、ワークフローの識別情報と対応付けて、当該ワークフローを承認する承認者の情報を管理し、組織において開催される会議の情報を取得する。取得された会議の情報を用いて当該会議の選択を受け付け、ワークフローを承認する承認者として設定するための画面の画面情報を生成する。ワークフローを承認する承認者の情報として、画面を介して選択された会議の情報を管理することを特徴とするサーバ。【選択図】 図５

Description

本発明は、ワークフローを管理するサーバと、その処理方法及びプログラムに関する。

従来、ワークフローでは、申請者が申請した文書について、その文書に係る業務の種類に応じた承認者が順に承認することにより承認処理を完了させる。

一方、複数の承認者に対して同時に承認依頼をし、そのうちの１人、所定の割合以上または全員が承認すると次の承認アクティビティへ進む、“合議”というアクティビティが存在する。その場合、合議アクティビティの承認者として、複数のユーザ（例：Ａ取締役、Ｂ取締役およびＣ取締役）または複数のユーザで構成されたグループ（例：取締役会などの会議体）を選択し、設定する必要がある。
特許文献１では、承認ルートでの最終承認を経た後に、役員会の会議資料を管理する事務局コンピュータに対して、ワークフロー案件の情報を送信する技術が記載されている。

特開２００２−３６６７１９号公報

しかし、特許文献１のシステム構成では、最終承認を終えたワークフローの情報を用いて、会議の資料を作成するのみであって、ワークフローの承認者として会議を選択できないという課題がある。つまり、特許文献１のシステム構成では、会議における話し合いによって決定された、案件の承認・否認をワークフローシステムに反映できないという問題が生じてしまう。

そこで、本発明の目的は、ワークフローの承認者として会議を選択可能にする仕組みを提供することである。

組織におけるワークフローを管理するサーバであって、前記ワークフローの識別情報と対応付けて、当該ワークフローを承認する承認者の情報を管理する承認者情報管理手段と、前記組織において開催される会議の情報を取得する会議情報取得手段と、前記会議情報取得手段により取得された会議の情報を用いて当該会議の選択を受け付け、前記ワークフローを承認する承認者として設定するための画面の画面情報を生成する承認者設定画面情報生成手段とを備え、前記承認者情報管理手段は、前記ワークフローを承認する承認者の情報として、前記画面を介して選択された会議の情報を管理することを特徴とするサーバ。

本発明によれば、ワークフローの承認者として会議を選択可能にする仕組みを提供することができる。

本発明のワークフローシステム１００の構成の一例を示す図 本発明のワークフローサーバ１０２のハードウエア構成の一例を示す図 本発明のワークフローサーバ１０２の機能構成の一例を示すブロック図 本発明の会議体への承認依頼処理の一例を示すフローチャート 本発明の情報処理装置１０１により表示されるワークフロー承認画面の一例を示す図 本発明の情報処理装置１０１により表示される承認者として会議を選択・登録する画面の一例を示す図 本発明の会議体による承認処理の一例を示すフローチャート 本発明の情報処理装置１０１により表示される会議の議題一覧画面の一例を示す図 本発明の情報処理装置１０１により表示されるワークフロー承認画面の一例を示す図 本発明のバッチ処理の一例を示すフローチャート 本発明の会議終了後自動承認処理の一例を示すフローチャート 本発明のサーバ１０２で管理するテーブルのデータの一例を示す図

以下、図面を参照して、本発明の実施形態を詳細に説明する。
図１は、本発明の一実施形態を示すワークフローシステムの一例を示すシステム構成図である。

図１に示すように、本実施形態のワークフローシステム１００は、複数のクライアント（以下、情報処理装置１０１と記載する）、ワークフローサーバ１０２および予定管理サーバ１０３がネットワーク１０４を介して接続されている。なお、本実施形態においては、ワークフローサーバ１０２と予定管理サーバ１０３は別の装置としたが、これに限定するものではなく、同一筐体の装置であってもよい。

ネットワーク１０４の構成は公知であるため詳細な説明は省略するが、ネットワーク１０４としてローカルエリアネットワーク（ＬＡＮ）・ワイドエリアネットワーク（ＷＡＮ）・イントラネット・インターネットなどを利用することができる。

このようなワークフローシステム１００において、ユーザは、例えばウェブブラウザやクライアントソフトウェア等を利用して、情報処理装置１０１から、ワークフローサーバ１０２に対して、ワークフロー進行の要求等を行う。
ワークフローサーバ１０２は、情報処理装置１０１から要求に応じた処理や管理を行い、情報処理装置１０１に対して結果等を送信する。

予定管理サーバ１０３は、会議等の予定を管理するサーバであって、情報処理装置１０１またはワークフローサーバ１０２からの要求に応じて、予定（スケジュール）を取得、登録し、要求を送信した情報処理装置１０１またはワークフローサーバ１０２に対して結果等を返信する。

情報処理装置１０１、ワークフローサーバ１０２および予定管理サーバ１０３間の通信は、ＨＴＴＰのリクエスト・レスポンスでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエスト・レスポンスなどであってもよい。

なお、情報処理装置１０１は、デスクトップＰＣのほか、携帯電話、スマートフォン、タブレット端末、ノートＰＣ、およびＰＤＡ端末などの持ち運び可能な端末であってもよい。
以上で、図１の説明を終了する。

図２は、図１に示したワークフローサーバ１０２のハードウエア構成の一例を示すブロック図である。
図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。
出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、外部メモリコントローラ２０７には、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。

この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０４を介して外部機器との通信制御処理を実行する。

なお、外部メモリ２１１には、本発明を実現するためのプログラム２１２が記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
以上で、図２の説明を終了する。

図３は、本発明のワークフローサーバ１０２の機能構成の一例を示すブロック図である。
承認者情報管理部３０１は、ワークフローの識別情報と対応付けて、当該ワークフローを承認する承認者の情報を管理する機能部である。
会議情報取得部３０２は、組織において開催される会議の情報を取得する機能部である。
承認者設定画面情報生成部３０３は、会議情報取得部３０２により取得された会議の情報を用いて当該会議の選択を受け付け、ワークフローを承認する承認者として設定するための画面の画面情報を生成する機能部である。
承認者情報管理部３０１は、ワークフローを承認する承認者の情報として、画面を介して選択された会議の情報を管理する機能部である。

承認者設定画面情報生成部３０３は、会議情報取得部３０２により取得された会議以外の会議の情報の入力を受け付け、ワークフローを承認する承認者として設定するための画面の画面情報を生成する機能部である。

一覧画面情報生成部３０４は、承認者情報管理部３０１から、会議の識別情報を用いて当該会議が承認者として対応付けられているワークフローの情報を取得し、当該ワークフローの一覧を表示する画面の画面情報を生成する機能部である。
会議終了判定部３０５は、会議が終了したか否かを判定する機能部である。

承認否認部３０６は、会議終了判定部３０５により終了したと判定された会議が承認者として対応付けられているワークフローの承認処理または否認処理を自動で行う機能部である。
以上で、図３の説明を終了する。

図１２は、ワークフローサーバ１０２または予定管理サーバ１０３で管理するテーブルの一例を示す図である。なお、本実施形態においては、予定管理サーバ１０３においてスケジュールテーブル１２１０を管理し、ワークフローサーバ１０２において会議テーブル１２２０、議題テーブル１２３０およびワークフローテーブル１２４０を管理するとしたが、この管理方法に限定するものではなく、異なる管理方法であってもよい。
スケジュールテーブル１２１０は、「会議ＩＤ」「開始日時」「終了日時」「会議名」「会議室」のカラムを含み、会議の情報を管理するテーブルである。

会議テーブル１２２０は、「会議ＩＤ」「終了フラグ」「配送ステータス」のカラムを含み、会議の終了および配送ステータスを管理するテーブルである。
議題テーブル１２３０は、「会議ＩＤ」「案件ＩＤ」「ステータス」「ソート順」のカラムを含み、会議において議題とする案件を管理するテーブルである。

ワークフローテーブル１２４０は、「案件ＩＤ」「案件名」「業務ＩＤ」「業務名」「申請者」「承認者１」「承認者２」「承認者３」「現在」「ステータス」「案件情報」のカラムを含み、ワークフローの個々の案件を管理するテーブルである。なお、

なお、「承認者１」「承認者２」「承認者３」には、承認者の「ユーザＩＤ」または「会議ＩＤ」を設定する。また、承認者１〜３のカラムしか記載していないが、「承認者４」「承認者５」・・・「承認者ｎ」のように、より多くの承認者カラムを持つとしてもよい。

また、「現在」には、“申請者”、“承認者１”、“承認者２”、“承認者３”、“ＮＵＬＬ”のいずれかの文字列を設定することにより、現在誰がこの案件を担当しているか（＝誰の承認待ちか）がわかるようになっている。例えば、レコード１２４１のように、「承認者２」＝“２０１６＿２３５（会議ＩＤ）”、「現在」＝“承認者２”の場合は、「承認者２」カラムに設定されている会議“２０１６＿２３５”での承認待ちという状態である。

また、「業務ＩＤ」毎に、「案件情報」に含まれる項目やデフォルトの承認ルート（「承認者１」「承認者２」「承認者３」・・・）が異なる。なお、承認ルートは、「申請者」の所属部門やロール等に従って決定されるが、承認画面５００などを介して、申請者や承認者の操作または「案件情報」に含まれる項目の値に従って、承認ルートを変更することができる。つまり、「業務ＩＤ」によっては、デフォルトの承認ルートに「会議ＩＤ」が設定されていることもあるし、デフォルトの承認ルートとして「会議ＩＤ」が設定されていない場合であっても、承認画面５００などを介して、「承認者ｎ」に「会議ＩＤ」を設定することによって、承認者として会議を設定することができる。

すなわち、ワークフローテーブル１２４０は、ワークフローの識別情報と対応付けて、当該ワークフローを承認する承認者の情報を管理する手段の一例を示す機能部である。また、ワークフローテーブル１２４０は、ワークフローを承認する承認者の情報として、画面を介して選択された会議の情報を管理する手段の一例を示す機能部である。

なお、本実施形態においては、テーブルの構成を上記のようにするとしたが、これに限定するものではなく、異なるテーブル、異なるカラムによる構成であってもよい。
以上で、図１２の説明を終了する。

図４は、本発明の会議体への承認依頼処理の一例を示すフローチャートである。図５は、本発明の情報処理装置１０１により表示されるワークフロー承認画面の一例を示す図である。図６は、本発明の情報処理装置１０１により表示される承認者として会議を選択・登録する画面の一例を示す図である。図４〜図６を用いて、本発明の会議体への承認依頼処理について説明する。

ステップＳ４０１において、情報処理装置１０１は、承認依頼メールを受信する。ここでは、ユーザ＝“承認者００１”が、「案件ＩＤ」＝“０１０１”の（ワークフローの）案件についての承認依頼メールを受信したとする。

ステップＳ４０２において、情報処理装置１０１は、受信した承認依頼メールに含まれている承認画面を表示するためのリンク（不図示）のユーザによる選択を受け付ける。

ステップＳ４０３において、情報処理装置１０１は、ワークフローサーバ１０２に対して、承認画面の表示要求を送信する。なお、表示要求には、ステップＳ４０２にて指示を受け付けた案件の「案件ＩＤ」を含む。
ステップＳ４０４において、ワークフローサーバ１０２は、情報処理装置１０１から送信された承認画面の表示要求を受信する。

ステップＳ４０５において、ワークフローサーバ１０２は、表示要求を受信した案件情報を取得する。具体的には、ステップＳ４０４にて受信した「案件ＩＤ」を検索キーにして、ワークフローテーブル１２４０を検索し、検索結果を取得する。ここでは、ワークフローテーブル１２４０のレコード１２４１を取得したとする。

ステップＳ４０６において、ワークフローサーバ１０２は、ステップＳ４０５で取得した案件情報を用いて、その案件を承認するための承認画面情報を生成する。すなわち、ステップＳ４０６は、取得された会議の情報を用いて当該会議の選択を受け付け、ワークフローを承認する承認者として設定するための画面の画面情報を生成する処理の一例を示すステップである。また、ステップＳ４０６は、取得された会議以外の会議の情報の入力を受け付け、ワークフローを承認する承認者として設定するための画面の画面情報を生成する処理の一例を示すステップである。
ステップＳ４０７において、ワークフローサーバ１０２は、情報処理装置１０１に対して、ステップＳ４０６にて生成した承認画面情報を送信する。
ステップＳ４０８において、情報処理装置１０１は、承認画面情報を受信する。

ステップＳ４０９において、情報処理装置１０１は、ステップＳ４０８にて受信した承認画面情報を用いて、承認画面５００（図５）を出力部２１０に表示する。ここでは、現在操作しているユーザ＝“承認者００１”であるため、図５の５０５部分を識別して表示する。また、承認画面５００では、現在画面操作を行っている承認者が、次の承認者を設定することができるとする。

ステップＳ４１０において、情報処理装置１０１は、次承認者の選択を受け付ける。承認者選択ボタン５０１（図５）が押下された場合は、承認者選択画面（不図示）を表示し、システムに登録されているユーザの中から、次の承認者を選択する。なお、この承認者選択処理については、既知の技術であるため、説明は省略する。また、会議選択ボタン５０２（図５）が押下された場合は、ステップＳ４１１に進む。

ステップＳ４１１において、情報処理装置１０１は、カレンダー選択画面６１０（図６）を表示し、この案件の承認を行う会議の開催日の選択を受け付け、予定管理サーバ１０３に対して、会議予定の要求を送信する。ここでは、１０月２５日（図６の６１１）の選択を受け付けたとする。

ステップＳ４１２において、予定管理サーバ１０３は、情報処理装置１０１から会議予定の要求を受信する。なお、会議予定の要求には、選択を受け付けた会議の開催日を含む。

ステップＳ４１３において、予定管理サーバ１０３は、会議予定情報を検索する。具体的には、受信した会議開催日（例：１０月２５日）を用いて、スケジュールテーブル１２１０を検索し、会議予定情報を取得する。ここでは、１２１１〜１２１３の３件の会議予定情報が取得できたとする。なお、会議予定情報には、開始時刻、終了時刻、会議名、参加者等の情報が含まれている。
ステップＳ４１４において、予定管理サーバ１０３は、情報処理装置１０１に対して、ステップＳ４１３にて取得した会議予定情報を送信する。

ステップＳ４１５において、情報処理装置１０１は、予定管理サーバ１０３から会議予定情報を受信する。すなわち、ステップＳ４１５は、組織において開催される会議の情報を取得する処理の一例を示すステップである。

ステップＳ４１６において、情報処理装置１０１は、受信した会議予定情報を用いて、会議予定一覧画面６２０（図６）を出力部２１０に表示する。ステップＳ４１１にて選択した日付に会議予定が存在した場合は、会議予定一覧画面６２０には取得した会議予定を表示する。なお、ステップＳ４１１にて選択した日付に会議予定が存在しなかった場合は、会議予定一覧画面６２０には会議予定を表示しない。

ここで、会議予定一覧画面６２０について説明しておく。表示された会議予定の右には、その会議を案件の承認者として設定するための選択ボタン６２１を表示する。また、表示された会議予定の右下には、スケジュールテーブル１２１０に登録されていない新規の会議を登録し、その会議を承認者として設定するための登録ボタン６２２を表示する。

ステップＳ４１６では、会議の選択ボタン６２１または登録ボタン６２２の押下を受け付け、選択ボタン６２１の押下を受け付けた場合は、会議確定画面６４０に選択された会議の情報を表示し、登録ボタン６２２の押下を受け付けた場合は、会議室選択画面６３０にて会議室の選択（図６の６３１）を受け付けた後、会議確定画面６４０にて新規に登録する会議の情報（開始時刻、終了時刻、会議名、参加者等）の入力を受け付ける。これにより、ワークフローの承認者として会議を選択可能にすることができる。

なお、会議確定画面６４０に表示される議題６４１には、その会議に今回対応付ける案件および既に対応付けられている案件の「案件ＩＤ」「案件名」を表示する。つまり、新規の会議を登録する場合には、既に対応付けられている案件は無いため、議題６４１には今回対応付ける案件の「案件ＩＤ」「案件名」のみを表示する。

また、確定ボタン６４２の押下を受け付けると、案件に承認者として対応付ける会議の情報を外部メモリ２１１に記憶し、カレンダー選択画面６１０、会議予定一覧画面６２０、会議室選択画面６３０および会議確定画面６４０を閉じる。

ステップＳ４１７において、情報処理装置１０１は、承認画面５００の承認ボタン５０３または否認ボタン５０４の押下を受け付ける。ここでは、承認ボタン５０３の押下を受け付けたとする。

ステップＳ４１８において、情報処理装置１０１は、ステップＳ４１６にて外部メモリ２１１に記憶した会議の情報が新規登録の会議か否かを判定する。新規登録の会議の場合はステップＳ４１９に進み、既存の会議の場合はステップＳ４２０に進む。
ステップＳ４１９において、情報処理装置１０１は、予定管理サーバ１０３に対して、会議登録要求および登録する会議情報を送信する。
ステップＳ４２０において、予定管理サーバ１０３は、情報処理装置１０１から会議登録要求および登録する会議情報を受信する。

ステップＳ４２１において、予定管理サーバ１０３は、ステップＳ４２０にて受信した会議情報を用いて、スケジュールテーブル１２１０に会議のスケジュールを登録し、登録に伴い採番された「会議ＩＤ」を情報処理装置１０１に送信する。ここでは、スケジュールテーブル１２１０にスケジュールレコード１２１３を登録し、採番された「会議ＩＤ」＝“２０１６＿２３５”を情報処理装置１０１に送信したとする。

ステップＳ４２２において、情報処理装置１０１は、ワークフローサーバ１０２に対して、会議・議題の登録要求を送信する。なお、登録要求には、（ステップＳ４１６にて選択を受け付けたまたはステップＳ４２１の後に受信した）「会議ＩＤ」、議題６４１（＝「案件ＩＤ」＋「案件名」）および会議情報を含む。
ステップＳ４２３において、ワークフローサーバ１０２は、情報処理装置１０１から会議・議題の登録要求を受信する。

ステップＳ４２４において、ワークフローサーバ１０２は、ステップＳ４２３にて受信した「会議ＩＤ」および議題６４１を用いて、会議テーブル１２２０および議題テーブル１２３０にレコードを登録する。

会議テーブル１２２０には、ステップＳ４２３にて受信した「会議ＩＤ」が存在しない場合は、「会議ＩＤ」を用いて、新規の会議レコードを登録する。ステップＳ４２３にて受信した「会議ＩＤ」が存在する場合は、新規の会議レコードは登録しない。ここでは、会議テーブル１２２０にレコード１２２１を登録し、「終了フラグ」＝“ＦＡＬＳＥ”、「配送ステータス」＝“未実施”を設定したとする。

議題テーブル１２３０には、ステップＳ４２３にて受信した「会議ＩＤ」および「案件ＩＤ」を用いて、新規の議題レコードを登録する。ここでは、レコード１２３１を登録したとする。

ステップＳ４２５において、ワークフローサーバ１０２は、承認者ＩＤに会議ＩＤを設定し、会議情報に含まれている会議の参加者に対して、承認依頼メールを送信する。具体的には、ステップＳ４２３にて受信した「案件ＩＤ」をキーとしてワークフローテーブル１２４０を検索し、該当レコードの「承認ｎ」の値にステップＳ４２３にて受信した「会議ＩＤ」を設定する。また、「現在」の値には、「会議ＩＤ」を設定したカラムである“承認ｎ”を設定する。また、「現在」の承認者が会議となるため、「ステータス」＝“会議承認待ち”を設定する。

ここでは、ワークフローテーブル１２４０のレコード１２４１について、「承認者２」＝“２０１６＿２３５”および「現在」＝“承認者２”を設定する。また、「現在」の承認者が会議であるため、「ステータス」＝“会議承認待ち”を設定する。
ステップＳ４２６において、情報処理装置１０１は、承認完了画面（不図示）を出力部２１０に表示する。
以上で、図４の説明を終了する。

図７は、本発明の会議体による承認処理の一例を示すフローチャートを示す図である。図８は、本発明の情報処理装置１０１により表示される会議の議題一覧画面の一例を示す図である。図９は、本発明の情報処理装置１０１により表示されるワークフロー承認画面の一例を示す図である。図７〜図９を用いて、本発明の会議体による承認処理について説明する。
ステップＳ７０１において、会議室にある情報処理装置１０１は、ワークフローサーバ１０２に対して、会議一覧要求を送信する。
ステップＳ７０２において、ワークフローサーバ１０２は、情報処理装置１０１から会議一覧要求を受信する。
ステップＳ７０３において、ワークフローサーバ１０２は、会議テーブル１２２０から会議一覧を取得する。
ステップＳ７０４において、ワークフローサーバ１０２は、情報処理装置１０１に対して、取得した会議一覧を送信する。
ステップＳ７０５において、情報処理装置１０１は、ワークフローサーバ１０２から会議一覧を受信する。

ステップＳ７０６において、情報処理装置１０１は、ステップＳ７０５にて受信した会議一覧を出力部２１０に表示し（不図示）、これから開始する会議の選択を受け付ける。ここでは、「会議ＩＤ」＝“２０１６＿２３５”の会議の選択を受け付けたとする。

ステップＳ７０７において、情報処理装置１０１は、ワークフローサーバ１０２に対して、会議画面の表示要求を送信する。なお、表示要求には、ステップＳ７０６にて指示を受け付けた「会議ＩＤ」を含む。
ステップＳ７０８において、ワークフローサーバ１０２は、情報処理装置１０１から会議画面表示要求を受信する。

ステップＳ７０９において、ワークフローサーバ１０２は、ステップＳ７０８にて受信した「会議ＩＤ」を検索キーとして、議題テーブル１２３０から議題一覧を取得する。ここでは、「会議ＩＤ」＝“２０１６＿２３５”を検索キーとして、議題テーブル１２３０からレコード１２３１〜１２３５を取得したとする。

ステップＳ７１０において、ワークフローサーバ１０２は、ステップＳ７０９で取得した議題一覧を用いて、会議画面の画面情報を生成する。すなわち、ステップＳ７１０は、会議の識別情報を用いて当該会議が承認者として対応付けられているワークフローの情報を取得し、当該ワークフローの一覧を表示する画面の画面情報を生成する処理の一例を示すステップである。
ステップＳ７１１において、ワークフローサーバ１０２は、情報処理装置１０１に対し、生成した会議画面の画面情報を送信する。
ステップＳ７１２において、情報処理装置１０１は、ワークフローサーバ１０２から会議画面の画面情報を受信する。

ステップＳ７１３において、情報処理装置１０１は、ステップＳ７１２で受信した画面情報を用いて、会議画面８００（図８）を出力部２１０に表示する。これにより、会議における議題が一覧化されているため、各議題について承認・否認を決定することで、当会議によって決定しなければならない議題について漏れなく話し合うことができる。

また、会議画面８００では、各議題をドラッグ＆ドロップ等の操作することで、議題の順番を変更することができる。この順番の変更に従って、議題テーブル１２３０の「ソート」の値を変更する。これにより、重要な議題や短時間で結論が出そうな議題から取り組むことができるため、会議の効率化を図ることができる。
ステップＳ７１４において、情報処理装置１０１は、議題を選択する開くボタン８０１の押下を受け付ける。

ステップＳ７１５において、情報処理装置１０１は、ワークフローサーバ１０２に対して、議題情報要求を送信する。議題情報要求には、押下を受け付けた「案件ＩＤ」を含む。
ステップＳ７１６において、ワークフローサーバ１０２は、情報処理装置１０１から議題情報要求を受信する。

ステップＳ７１７において、ワークフローサーバ１０２は、ステップＳ７１６にて取得した「案件ＩＤ」をキーとして、ワークフローテーブル１２４０から案件情報を取得する。ここでは、「案件ＩＤ」＝“０１０１”を検索キーとして、ワークフローテーブル１２４０からレコード１２４１を取得したとする。これにより、会議の場において、議題の内容および添付資料などを漏れなく順番に閲覧できるため、会議のために資料やアジェンダを整理・作成する必要がなくなり、会議および案件の承認・否認のための準備を効率化することができる。
ステップＳ７１８において、ワークフローサーバ１０２は、ステップＳ７１７で取得した案件情報を用いて、案件承認画面の画面情報を生成する。
ステップＳ７１９において、ワークフローサーバ１０２は、情報処理装置１０１に対して、案件承認画面の画面情報を送信する。
ステップＳ７２０において、情報処理装置１０１は、ワークフローサーバ１０２より、案件承認画面の画面情報を受信する。

ステップＳ７２１において、情報処理装置１０１は、ステップＳ７２０にて受信した案件承認画面情報を用いて、案件承認画面（図９）を出力部２１０に表示する。

ステップＳ７２２において、情報処理装置１０１は、会議による話し合いの結果として、案件承認画面の「承認ボタン９０１」「否認ボタン９０２」または「差戻しボタン９０３」の押下を受け付ける。ここでは、「承認ボタン９０１」が押下されたものとする。

ステップＳ７２３において、情報処理装置１０１は、ステップＳ７２２にて選択された承認、否認または差戻しを、議題（案件）毎に外部メモリ２１１に記憶する。

ステップＳ７２４において、情報処理装置１０１は、ステップＳ７１２で取得した全議題（案件）の判断が完了したか否かを判定する。全ての議題についての判断が完了していない場合は、ステップＳ７１３に戻る。全ての議題についての判断が完了した場合は、ステップＳ７２５に進む。
ここでは、議題毎の判断は、以下の通りだったとする。
議題Ｎｏ．１（図１２のレコード１２３１）：承認
議題Ｎｏ．２（図１２のレコード１２３２）：否認
議題Ｎｏ．３（図１２のレコード１２３３）：承認
議題Ｎｏ．４（図１２のレコード１２３４）：差戻し
議題Ｎｏ．５（図１２のレコード１２３５）：承認

ステップＳ７２５において、情報処理装置１０１は、全ての議題についての判断が完了したことを通知し、会議を終了するか否かの確認、メッセージ（不図示）を出力部２１０に表示する。

ステップＳ７２６において、情報処理装置１０１は、「終了しない」の選択を受け付けた場合はステップＳ７１３に戻り、「終了する」の選択を受け付けた場合は、ステップＳ７２７に進む。

ステップＳ７２７において、情報処理装置１０１は、ワークフローサーバ１０２に対して、会議終了通知を送信する。また、会議終了通知には、ステップＳ７２３にて外部メモリ２１１に記憶した全議題の判断結果を含む。
ステップＳ７２８において、ワークフローサーバ１０２は、情報処理装置１０１から会議終了通知を受信する。
ステップＳ７２９において、ワークフローサーバ１０２は、ステップＳ７２８で受信した議題の数だけ、ステップＳ７３０を繰り返し実行する。

ステップＳ７３０において、ワークフローサーバ１０２は、ステップＳ７２８で受信した議題毎の判断結果を用いて、議題テーブル１２３０の「ステータス」の値を更新する。ここでは、議題テーブル１２３０のレコード１２３１〜１２３５の「ステータス」の値を（“承認”、“否認”、“承認”、“差戻し”、“承認”に）それぞれ更新したとする。

これにより、会議における話し合いによって決定された、ワークフロー案件の承認・否認をワークフローシステムに反映することができる。つまり、会議による決定をもって、案件の承認・否認に反映することができるため、会議体のメンバーであるユーザがそれぞれ承認・否認をする必要がなくなり、ワークフローの承認・否認処理を効率化することができる。

ステップＳ７３１において、ワークフローサーバ１０２は、会議ＩＤをキーとして、会議テーブル１２２０の「終了フラグ」を更新する。ここでは、「会議ＩＤ」＝“２０１６＿２３５”をキーとして、会議テーブル１２２０のレコード１２２１の「終了フラグ」＝“ＴＲＵＥ”、「配送ステータス」＝“未実施”に更新する。
以上で、図７の説明を終了する。

図１０は、本発明のバッチ処理の一例を示すフローチャートである。
ステップＳ１００１において、ワークフローサーバ１０２は、バッチ処理等によって、ステップＳ１００２〜ステップＳ１００３の処理を定期的に繰り返し実行する。

ステップＳ１００２において、ワークフローサーバ１０２は、会議テーブル１２２０に「終了フラグ」＝“ＴＲＵＥ”＆「配送ステータス」＝“未実施”のレコードが存在するかを判定する。存在する場合はステップＳ１００３に進み、存在しない場合はステップＳ１００４に進む。すなわち、ステップＳ１００２は、会議が終了したか否かを判定する処理の一例を示すステップである。

ステップＳ１００３において、会議テーブル１２２０からステップＳ１００２にて存在すると判定された会議レコードを取得し、会議終了後自動承認処理（図１１）を実行する。ここでは、「会議ＩＤ」＝“２０１６＿２３５”のレコード１２２１を取得したとする。

なお、本実施形態においては、ステップＳ１００２によって、終了した会議について承認・否認の配送処理を行うとしたが、これに限定するものではなく、例えば、終了時刻を過ぎた会議について承認・否認の配送処理を行うとしてもよい。これにより、ステップＳ７２６にて「終了する」の選択を受け付けないまま終了してしまった会議（例えば、すべての議題について結論が出る前に終了してしまった会議）についても、結論が出た議題についてのみ承認・否認の配送処理を行い、結論が出なかった議題については、差戻しの配送処理を行うといった対処ができるようになる。
以上で、図１０の説明を終了する。

図１１は、本発明の会議終了後自動承認処理の一例を示すフローチャートである。
ステップＳ１１０１において、ワークフローサーバ１０２は、ステップＳ１００３にて取得した「会議ＩＤ」を検索キーとして、議題テーブル１２３０を検索し、該当する議題レコードを全て取得する。ここでは、「会議ＩＤ」＝“２０１６＿２３５”を検索キーとして、議題テーブル１２３０からレコード１２３１〜レコード１２３５を取得したとする。

ステップＳ１１０２において、ステップＳ１１０１にて取得したレコードを１件ずつ、ステップＳ１１０３〜ステップＳ１１０６の処理を繰り返す。ここでは、取得した議題レコードは、レコード１２３１〜レコード１２３５の５件であるため、ステップＳ１１０３〜ステップＳ１１０６の処理を５回繰り返す。

ステップＳ１１０３において、取得した議題レコードに含まれる「ステータス」を確認し、「ステータス」＝“承認”の場合はステップＳ１１０４へ、「ステータス」＝“否認”の場合はステップＳ１１０５へ、「ステータス」＝“差戻し”の場合はステップＳ１１０６へそれぞれ進む。

ステップＳ１１０４において、取得した議題レコードの「案件ＩＤ」を検索キーにしてワークフローテーブル１２４０を検索し、該当した案件について承認処理を実行し、次の承認者に承認依頼を行う。なお、次の承認者が存在しない場合は、承認完了処理を行う。なお、この承認処理および承認完了処理については、通常のワークフローと同様の処理であるため、説明は省略する。

ステップＳ１１０５において、取得した議題レコードの「案件ＩＤ」を検索キーにしてワークフローテーブル１２４０を検索し、該当した案件について否認処理を実行し、申請者に否認されたことを通知する。なお、この否認処理については、通常のワークフローと同様の処理であるため、説明は省略する。すなわち、ステップＳ１１０４およびステップＳ１１０５は、終了したと判定された会議が承認者として対応付けられているワークフローの承認処理または否認処理を自動で行う処理の一例を示すステップである。

ステップＳ１１０６において、取得した議題レコードの「案件ＩＤ」を検索キーにしてワークフローテーブル１２４０を検索し、該当した案件について差戻し処理を実行し、申請者に差戻しされたことを通知する。なお、この差戻し処理については、通常のワークフローと同様の処理であるため、説明は省略する。

ステップＳ１１０７において、会議テーブル１２２０の処理中レコードの「配送ステータス」を更新する。ステップＳ１１０６またはステップＳ１１０７により全ての案件の配送（承認、否認、差戻し等）が成功した場合、「配送ステータス」＝“配送成功”に更新する。ステップＳ１１０６またはステップＳ１１０７により何れかの案件の配送が失敗した場合、「配送ステータス」＝“配送失敗”に更新する。
以上で、図１１の説明を終了する。
以上により、ワークフローの承認者として会議を選択可能にする仕組みを提供することができる。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ ワークフローシステム
１０１ 情報処理装置
１０２ ワークフローサーバ
１０３ 予定管理サーバ
１０４ ネットワーク

Claims (6)

1. 組織におけるワークフローを管理するサーバであって、
   前記ワークフローの識別情報と対応付けて、当該ワークフローを承認する承認者の情報を管理する承認者情報管理手段と、
   前記組織において開催される会議の情報を取得する会議情報取得手段と、
   前記会議情報取得手段により取得された会議の情報を用いて当該会議の選択を受け付け、前記ワークフローを承認する承認者として設定するための画面の画面情報を生成する承認者設定画面情報生成手段と
   を備え、
   前記承認者情報管理手段は、
   前記ワークフローを承認する承認者の情報として、前記画面を介して選択された会議の情報を管理すること
   を特徴とするサーバ。
2. 前記承認者設定画面情報生成手段は、
   前記会議情報取得手段により取得された会議以外の会議の情報の入力を受け付け、前記ワークフローを承認する承認者として設定するための画面の画面情報を生成すること
   を特徴とする請求項１に記載のサーバ。
3. 前記承認者情報管理手段から、前記会議の識別情報を用いて当該会議が承認者として対応付けられているワークフローの情報を取得し、当該ワークフローの一覧を表示する画面の画面情報を生成する一覧画面情報生成手段
   を更に備えることを特徴とする請求項１または２に記載のサーバ。
4. 前記会議が終了したか否かを判定する会議終了判定手段と、
   前記会議終了判定手段により終了したと判定された会議が承認者として対応付けられているワークフローの承認処理または否認処理を自動で行う承認否認手段と
   を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載のサーバ。
5. 組織におけるワークフローを管理するサーバにおける処理方法であって、
   前記サーバが、
   前記ワークフローの識別情報と対応付けて、当該ワークフローを承認する承認者の情報を管理する承認者情報管理ステップと、
   前記組織において開催される会議の情報を取得する会議情報取得ステップと、
   前記会議情報取得ステップにより取得された会議の情報を用いて当該会議の選択を受け付け、前記ワークフローを承認する承認者として設定するための画面の画面情報を生成する承認者設定画面情報生成ステップと
   を実行し、
   前記承認者情報管理ステップは、
   前記ワークフローを承認する承認者の情報として、前記画面を介して選択された会議の情報を管理すること
   を特徴とする処理方法。
6. 組織におけるワークフローを管理するサーバで実行可能なプログラムであって、
   前記サーバを、
   前記ワークフローの識別情報と対応付けて、当該ワークフローを承認する承認者の情報を管理する承認者情報管理手段と、
   前記組織において開催される会議の情報を取得する会議情報取得手段と、
   前記会議情報取得手段により取得された会議の情報を用いて当該会議の選択を受け付け、前記ワークフローを承認する承認者として設定するための画面の画面情報を生成する承認者設定画面情報生成手段
   として機能させ、
   前記承認者情報管理手段は、
   前記ワークフローを承認する承認者の情報として、前記画面を介して選択された会議の情報を管理すること
   を特徴とするプログラム。
   

Images