JP6189660B2 - イベント支援装置及びイベント支援方法 - Google Patents

Description

本発明は、イベントの実行を支援するためのイベント支援装置及びイベント支援方法に関する。

法人活動において的確な統制管理のために、承認ワークフローに基づいて承認作業を行なう。このような承認ワークフローに基づいて承認が必要な起案文書の回付を支援するための申請管理システムが検討されている（例えば、特許文献１参照）。この文献に記載された申請管理システムにおいては、ファイルサーバに、各部署の部署単位フォルダを設け、この中に申請中フォルダ、回付中フォルダ、最終承認フォルダを設ける。申請管理サーバの制御部は、これらのフォルダを用いて、ワークフローを管理する。

また、スケジュールと連携したワークフロー作業を実現するワークフロー管理システムも検討されている（例えば、特許文献２参照）。この文献に記載されたワークフロー管理システムは、ワークフローサーバと、スケジュールサーバとを有する。このワークフローサーバは、ワークフローを担当可能な担当者の情報であるワークフロー経路テーブルを有しており、スケジュールサーバは担当者のスケジュールに関する情報であるスケジュール管理テーブルを有している。ワークフローサーバは、スケジュール管理テーブルから、担当者情報に格納されている担当者のうち、最も早い日時に空き時間を有する担当者を選定することによって、最短のワークフロー経路である最短ワークフロー経路を算出する。

特開２０１２−１６８７２１号公報（第１頁、図１） 特開２０１１−１９１９６４号公報（第１頁、図１）

上述のように、法人活動において、状況に応じて適切な承認ワークフローによる承認作業を行なう必要がある。しかしながら、法人活動は多種多様なイベントから構成されており、一つのイベントを実施する場合にも、多くの手続やリソース（施設や情報等）が関係するため、各手続やリソースに応じた的確な承認ワークフローを適用する必要がある。

また、法人内において、各種リソースは多様なサービス管理システムにより管理されている。例えば、法人の施設への入退館や入退室は、施設管理のためのシステムによって管理される。また、法人において利用される情報（例えば、社外秘等の重要情報）については、情報管理のためのシステムによって管理される。また、役職員が、イベントのための移動に要した交通費は、交通費を精算するためのシステムによって管理される。その他、ＰＣ等の法人の資産を持ち出す場合には、資産管理システムによって管理される。このように、一つのイベントに対して、複数のサービス管理システムが関与している場合に、個々のサービス管理システムにおいて手続していたのでは、作業負担がかかるとともに、手続忘れ等による適切な管理を実現できない可能性がある。

また、イベントの内容や参加者が変更されることもある。このような場合においても、各サービス管理システムにおいて、統制上、的確な変更対応が望まれる。
本発明は、上記問題点を解決するためになされたものであり、効率的かつ的確にイベントを管理するためのイベント支援システム及びイベント支援方法を提供することにある。

・上記課題を解決するためのイベント支援装置は、イベントのスケジュール情報が記録されるスケジュール管理システムと、管理対象イベントに対応した各種処理を実行する複数のサービス管理システムとに接続された制御部を備える。そして、前記制御部が、前記スケジュール管理システムに記録されたスケジュール情報におけるイベントの参加者に基づいて、管理すべき管理対象イベントを特定し、前記管理対象イベントに対応した各種処理を実行させるために、前記各サービス管理システムに対して、前記管理対象イベントに基づいた通知を行ない、前記各サービス管理システムから、前記イベントの参加者に関する管理対象イベントに係る状況変化情報を取得し、前記状況変化情報に応じて、前記イベントの参加者の状態を特定し、前記状況変化情報に基づいて判断した前記管理対象イベントのステータス及び前記参加者の状態に応じて、前記状況変化情報を取得した管理対象イベントに後続する管理対象イベントに対応した各種処理を実行させる。これにより、スケジュール情報に基づいて、イベント支援装置と各サービス管理システムとが連携して、イベントを実施するための各種処理を行なうことができる。

・上記イベント支援装置においては、前記制御部が、前記管理対象イベントのステータスの変更を検知した場合、前記各サービス管理システムに対して、前記管理対象イベントの変更についての通知を行なうことが好ましい。これにより、イベントの状況変化に対しても、的確に対応することができる。

・上記イベント支援装置においては、前記制御部が、前記各サービス管理システムから、前記管理対象イベントに係る状況変化情報を取得し、前記状況変化情報に基づいて、前記管理対象イベントのステータスを判断する。これにより、各サービス管理システムから状況変化を取得し、この変化に応じた対応を行なうことができる。

・上記イベント支援装置においては、前記制御部が、前記管理対象イベントのイベント属性を特定し、前記イベント属性に基づいて、前記各サービス管理システムへの通知の要否を判断することが好ましい。これにより、イベント属性に応じて、適切な通知を行なうことができる。

・上記課題を解決するためのイベント支援装置は、イベントのスケジュール情報が記録されるスケジュール管理システムと、前記スケジュール管理システムに接続された制御部、承認に係る権限者を特定するための権限者特定部を備える。更に、イベント属性に応じて承認経路を決定する承認経路管理部を備える。そして、前記制御部が、前記スケジュール情報において新たに登録された管理対象イベントを検知した場合、前記管理対象イベントのイベント属性に基づいて、前記承認経路管理部から承認経路を取得し、前記特定した複数の承認経路において、前記権限者特定部を用いて、前記イベント属性に応じた承認に係る権限者を特定し、共通した実行権限者を特定し、承認ルールに反しておらず、共通した実行権限者を設定可能な場合には、実行権限者を統合した承認経路を生成する。これにより、イベント種別等のイベント属性に応じて、このイベントを承認するための承認ワークフローを決定することができる。
上記イベント支援装置においては、前記制御部が、前記管理対象イベントの参加者の属性に基づいて承認に係る権限者を特定することが好ましい。

・上記イベント支援装置においては、前記統制管理部は、統制が必要な統制事象について、個別統制を記録した統制記憶部を更に備え、前記制御部が、前記イベント属性に応じて、統制が必要な統制事象を特定し、前記統制管理部において、前記統制事象についての個別統制に応じた承認経路を決定することが好ましい。これにより、イベント実施において、統制上、必要な承認を行なうことができる。

・上記イベント支援装置においては、承認に係る権限者を特定するための権限者特定部を更に備え、前記制御部が、前記権限者特定部において、前記イベント属性に応じた承認に係る権限者を特定する。これにより、承認に係る権限者を特定することができる。

・上記イベント支援装置においては、前記制御部が、前記管理対象イベントの参加者の属性に基づいて承認に係る権限者を特定する。これにより、参加者の属性に応じた承認ワークフローを決定することができる。

・上記イベント支援装置においては、前記統制記憶部には、個別統制について順序関係が記録されており、前記制御部が、前記イベント属性に応じた複数の個別統制について、各個別統制の順序関係を特定し、前記順序関係に基づいて承認経路を生成することが好ましい。これにより、複数の手続による承認が必要な場合にも、統合された無駄のない承認ワークフローを生成することができる。

・上記イベント支援装置においては、前記統制記憶部には、前記承認経路上の承認に係る権限者について、前記権限者が担うべき個別統制を記録することが好ましい。これにより、統制記憶部を参照して、承認に係る作業を的確に行なうことができる。

・上記イベント支援装置においては、前記管理対象イベントについて、事前承認の有無を確認し、既に事前承認が登録されている場合には、前記個別統制について承認済みとして対応することが好ましい。これにより、事前承認による効率的な承認作業を行なうことができる。

・上記イベント支援装置においては、前記制御部が、前記承認経路における承認に係る権限者に対して承認依頼を行ない、前記権限者における承認状況を管理することが好ましい。これにより、承認ワークフローを実行することができる。

・上記イベント支援装置においては、前記制御部は、ワークフロー管理システムに更に接続され、前記制御部が、前記ワークフロー管理システムとの間で、承認経路及び承認状況を共有することが好ましい。これにより、ワークフロー管理システムにおいて、承認ワークフローを実行することができる。

・上記イベント支援装置においては、前記制御部が、前記管理対象イベントにおける推奨参加者を特定し、前記管理対象イベントにおいて推奨参加者が登録されていない場合には注意喚起を出力することが好ましい。これにより、適切な参加者の参加を促すことができる。

本発明によれば、効率的かつ的確にイベントを管理することができる。

本実施形態のイベント支援システムの説明図。 本実施形態において用いるデータの説明図であって、（ａ）はパーティ管理システム、（ｂ）は業務記憶部、（ｃ）はイベント記憶部、（ｄ）は役務割当表記憶部に記録されるデータの説明図。 本実施形態において用いるデータの説明図であって、（ａ）は手続ＤＢに記録されるデータ、（ｂ）は統制表の説明図。 本実施形態の処理の概要の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の状態遷移の説明図。 本実施形態の統制表の説明図。 本実施形態の統制表の説明図。 本実施形態の統制表の説明図。 本実施形態の統制表の説明図。 本実施形態で用いるデータの説明図であって、（ａ）は業務管理レコード、（ｂ）は役務割当管理レコード、（ｃ）はイベント、（ｄ）は人ベース個別統制リスト、（ｅ）は役務ベース承認ＷＦの説明図。 本実施形態で用いるデータの説明図であって、（ａ）は人ベース承認ＷＦ（役務→人置換え版）、（ｂ）は人ベース承認ＷＦ（最適化版）、（ｃ）は人ベース承認ＷＦ（現実解版）の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。

以下、本発明を具体化したイベント支援装置の一実施形態を図１〜図１９に従って説明する。本実施形態では、法人における役職員が、イベントの登録時、実施許諾時、実施時、実施後の処理を行なう場合を想定する。この場合、このイベントの実施に必要な承認処理や管理処理の実行を支援する。

本実施形態では、図１に示すように、ネットワーク（図示せず）を介して接続されている複数のサービス管理システム１０、イベント支援システム２０、パーティ管理システム２２、業務記憶部２３、イベント記憶部２４、手続ＤＢ３０、スケジュール管理システム５０、ＷＦシステム５５を用いる。なお、本実施形態では、スケジュール管理システム５０において申請されたイベント（申請イベント）は、ＷＦシステム５５において承認ワークフローにより承認されて、有効化されて承認イベントとなる。イベント支援システム２０において、この申請イベント、承認イベントを、管理対象イベントとして取り扱う。

サービス管理システム１０は、各役職員に対するサービスを管理するコンピュータシステムである。本実施形態では、サービス管理システム１０として、法人の建物や部屋への入出を管理する施設管理システム１０ａ、会議等で用いられる資料等を管理する情報管理システム１０ｂ、役職員の移動に要した交通費の精算を管理する交通費管理システム１０ｃ等を用いる。

スケジュール管理システム５０は、役職員が申請したイベント（申請イベント）や、役職員毎のＴｏＤｏを管理するコンピュータシステムである。
申請イベントは、新たなイベントを登録した場合に記録される。申請イベントとして、イベントコード、イベント名、申請者、日時、場所、イベント種別、業務、資料、参加者に関するデータが記録される。

イベントコードデータ領域には、各申請イベントを特定するための識別子に関するデータが記録される。
イベント名データ領域には、このイベントの名称に関するデータが記録される。
申請者データ領域には、この申請イベントを申請した役職員を特定するための識別子（役職員コード）に関するデータが記録される。

日時データ領域、場所データ領域には、それぞれ、この申請イベントが行なわれる年月日及び時刻、申請イベントが実施される場所を特定するための識別子（場所コード）に関するデータが記録される。

イベント種別データ領域には、この申請イベントの種別を特定するための識別子に関するデータが記録される。
業務データ領域には、この申請イベントが属する業務を特定するための識別子に関するデータが記録される。

資料データ領域には、この申請イベントにおいて用いられる資料に関するデータが記録される。
参加者データ領域には、この申請イベントに参加する参加者を特定するための識別子に関するデータが記録される。このデータ領域には、パーティ情報の役職員コードが記録される。

また、ＴｏＤｏには、役職員毎に、各役職員が行なわなければならない作業が記録される。

スケジュール管理システム５０は、役職員端末に格納されたスケジューラ（スケジュール管理アプリケーション）に接続される。
この役職員端末は、役職員が、イベントの申請や、このイベントの承認に係る統制、イベントの参加に利用するコンピュータ端末である。役職員端末は、表示部（ディスプレイ等）や入力部（キーボードやポインティングデバイス等）を備えている。本実施形態では、イベントを申請する役職員は、この役職員端末のスケジューラを利用して、スケジュール管理システム５０にアクセスし、申請イベントを登録する。また、管理者は、役職員端末を利用して、ＷＦシステム５５にアクセスし、申請イベントの承認に係る確認等を行なう。

ＷＦシステム５５は、承認ワークフローに基づいて、承認に係る権限者の役職員端末に対して、各種申請を回付する処理を行なうコンピュータシステムである。

イベント支援システム２０は、以下のシステム等との連携を管理するコンピュータシステムである。
・申請イベントを介しスケジュール管理システム５０との連携
・申請イベントの実施に係る承認統制を担う承認ワークフローを介しＷＦシステム５５との連携
・承認ワークフローにより承認されたイベント（承認イベント）の状態を介しサービス管理システム１０との連携

イベント支援システム２０は、制御部２１を備えている。制御部２１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（状態通知や状態変更に関するサービス連携段階、関連統制抽出、承認ＷＦ合成、承認ＷＦ実行に関する関連統制抽出段階等の各処理等）を行なう。そのためのイベント支援プログラムを実行することにより、制御部２１は、図１に示すように、サービス連携部２１Ａ、ＷＦ連携部２１Ｂとして機能する。サービス連携部２１Ａは、サービス管理システム１０と連携する処理を実行する。ＷＦ連携部２１Ｂは、スケジュール管理システム５０及びＷＦシステム５５と連携する処理を実行する。

サービス連携部２１Ａは、状態通知部２１１、状態変更部２１２を備える。
状態通知部２１１は、承認イベントの状態（承認や変更）に対応して、各サービス管理システム１０に対する通知処理（ブロードキャスト）を実行する。

状態変更部２１２は、各サービス管理システム１０から取得した状況変化についての通知に基づいて、各承認イベントの状態を変更する処理を実行する。この変更処理は、状態変更部２１２が保持する状態変更辞書を用いて行なわれる。この状態変更辞書には、各サービス管理システム１０から通知された状況変化に応じて、承認イベントの状態変更の要否、状態変更を行なう場合にはイベント支援システム２０が実行すべき対応が記録されている。

ＷＦ連携部２１Ｂは、関連統制抽出部２１３、承認ＷＦ合成部２１４、承認ＷＦ実行部２１５を備える。
関連統制抽出部２１３は、承認イベントの申請や内容の変更を検知して、この承認イベントに関連する管理事象やサービス管理システム１０に係る統制事象を抽出する処理を実行する。

承認ＷＦ合成部２１４は、統制管理部、権限者特定部として機能し、先の統制事象に基づいて、イベント内容（イベント属性）に応じ必要な手続群に係る承認ワークフロー（承認ＷＦ）の合成処理を実行する。このために、承認ＷＦ合成部２１４は、先の承認ワークフロー上の手続に係る役務名やライン上の役職名を具体的に役職員に展開する処理も実行する。更に、承認ＷＦ合成部２１４は、承認ワークフローを決定するための承認ルールを保持している。この承認ルールにおいては、自分の申請を自分で承認する自己決裁の禁止等、承認に係る権限者を決定するためのルールが定められている。

承認ＷＦ実行部２１５は、ＷＦシステム５５を介して、申請イベントの登録や承認イベントの変更に係る承認ワークフロー処理を実行する。

イベント支援システム２０は、組織情報記憶部としてのパーティ管理システム２２、業務記憶部２３、イベント記憶部２４に接続されている。
図２（ａ）に示すように、パーティ管理システム２２は、人事システムや取引会社管理システムにより実現される。このパーティ管理システム２２の人事システムには、法人の組織構造や各ラインに属する役職員に関するパーティ情報２２０が記録されている。このパーティ情報２２０には、役職員コード、氏名、勤務先、所属、役職に関するデータが記録される。

役職員コードデータ領域には、各役職員を特定するための識別子に関するデータが記録される。
氏名データ領域には、この役職員や部外者の氏名に関するデータが記録される。
勤務先データ領域には、この役職員や部外者の勤務場所を特定するためのデータが記録される。

所属データ領域には、この役職員や部外者が属する組織（部署）を特定するための識別子に関するデータが記録される。
役職データ領域には、この役職員や部外者の役職を特定するための識別子に関するデータが記録される。

なお、パーティ管理システム２２における取引会社管理システムにおいては、イベントに関連する他法人（外部）の役職員（部外者）の情報が管理される。この取引会社管理システムのパーティ情報２２０には、法人を特定するための情報（法人コード）が追加されて記録される。

図２（ｂ）に示すように、業務記憶部２３には、業務の関係者に関する業務管理レコード２３０が記録される。この業務管理レコード２３０は、各役職員によって行なわれる業務が登録された場合に記録される。業務管理レコード２３０には、業務コード、管理者、担当者、協業先、関係者に関するデータが記録される。

業務コードデータ領域には、各業務を特定するための識別子に関するデータが記録される。
管理者データ領域には、この業務を管理する役職員を特定するための識別子（役職員コード）に関するデータが記録される。

担当者データ領域には、この業務を担当する役職員を特定するための識別子（役職員コード）に関するデータが記録される。
協業先データ領域には、この業務に協力する他法人や、この他法人の役職員を特定するための識別子（取引会社管理システム上の法人コードや役職員コード）に関するデータが記録される。
関係者データ領域には、この業務の関係する他部署や、この他部署の役職員を特定するための識別子（部署コードや役職員コード）に関するデータが記録される。

図２（ｃ）に示すように、イベント記憶部２４には、スケジュール管理システム５０から取得した申請イベントを管理対象イベントとして管理するためのイベント管理レコード２４０が記録される。このイベント管理レコード２４０は、役職員によって登録されたスケジュールについてのイベント情報を取得した場合に記録される。イベント管理レコード２４０には、イベントコード、ステータスに関するデータが記録される。

イベントコードデータ領域には、スケジュール管理システム５０において登録された各申請イベントを特定するための識別子に関するデータが記録される。
ステータスデータ領域には、管理対象イベントのステータス（状態）に関するデータが記録される。ここでは、管理対象イベント及び各参加者の状態に関するデータが記録される。

また、図１に示すように、イベント支援システム２０は、統制記憶部としての手続ＤＢ３０に接続されている。この手続ＤＢ３０は、役務割当表記憶部３２及びポリシー記憶部３３を備えている。

図２（ｄ）に示すように、役務割当表記憶部３２には、各手続において規定された役務を担う役職員を登録するための役務割当管理レコード３２０が記録される。この役務割当管理レコード３２０には、役務、組織、担当者に関するデータが記録される。

役務データ領域には、各役務を特定するための識別子に関するデータが記録される。
組織データ領域には、この役務担当者が責任を負う組織を特定するための識別子に関するデータが記録される。
担当者データ領域には、この役務を担当する役職員を特定するための識別子に関するデータが記録される。

図３（ａ）に示すように、ポリシー記憶部３３には、業務や管理対象を表す「統制事象」、「統制事象」の統制を担う「役務」者、「統制事象」の統制内容を記載した「統制表ＣＴ」が登録される。

本実施形態では、「統制事象」として、イベント種別毎の業務統制と、様々な管理手続毎の管理統制が記録される。「統制事象」にはイベント内容に応じた当該統制事象の必要性を判定するための情報が含まれる。
この「役務」者は、適任者を個別に任命する場合や、役職や業務上の役割によって規定される場合がある。

図３（ｂ）に示すように、この「統制表ＣＴ」は、統制すべき局面（統制局面）として、イベント実施の承認可否を判定する「実施許諾」、イベント実施中に係る「実施」、イベントの実施後に係る「実施結果」の３段階で管理される。更に、各々の「統制局面」では、網羅性、実在性、正当性、正確性、権限性、時限性の６つの「統制項目」について、具体的「個別統制」が規定される。各「役務」は、その役割に応じ、「個別統制」を担う（実行する）。

網羅性は、イベントが漏れなく、かつ重複なく記録されていることを意味し、実行されるイベントの登録により担保する。本実施形態では、イベントが関連するサービス管理システム１０をコントロールする仕組みであり、イベントの存在を条件としてサービス管理システム１０を利用できる。これにより、必然的に網羅性は担保される。

実在性は、特定の日付においてイベントが実在していることを意味し、実施したことの証拠（エビデンス）により担保する。
正当性は、イベントの実施や内容が妥当であることを意味し、業務管理者の確認ないし指示により担保する。

正確性は、情報が正確に記録され、提供されていることを意味し、再鑑ないし証拠（エビデンス）により担保する。
権限性は、情報が正当な権限者以外に利用されないように保護されていることを意味し、主にシステムの機能（例えば、ＩＴアプリ統制（ＩＴＡＰ））により担保する。

時限性は、予め有効期間や終了期間などが決められていることを意味し、実施の証拠（エビデンス）により担保する。
更に、「個別統制」には、各項目について、内容欄と実行欄が設けられている。
内容欄には、統制の具体的内容が記録される。
実行欄には、当該「個別統制」を担う実行者が記録される。例えば、ＩＴアプリケーションを用いての統制（ＩＴＡＰ）や「役務」者による統制（再鑑や確認や承認等）が記録される。

（イベント支援システム２０の機能）
次に、図４を用いて、イベント支援システム２０やサービス管理システム１０における処理全体の概要を説明する。

まず、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において登録されたイベント申請を検知する（Ｆ１１）。この処理は、ＷＦ連携部２１Ｂの関連統制抽出部２１３により実現される。

次に、イベント支援システム２０の制御部２１は、承認ＷＦを合成する（Ｆ１２）。この処理は、ＷＦ連携部２１Ｂの承認ＷＦ合成部２１４により実現される。
次に、イベント支援システム２０の制御部２１は、承認ＷＦを稼働する（Ｆ１３）。この処理は、ＷＦ連携部２１Ｂの承認ＷＦ実行部２１５により実現される。

そして、承認ワークフローにおいて承認された場合には、イベント支援システム２０の制御部２１は、各サービス管理システム１０に対して、承認を通知する（Ｆ１４）。この処理は、サービス連携部２１Ａの状態通知部２１１により実現される。ここでは、各参加者において、出席表明者に関する通知を行なう。また、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、承認済みイベントに係る各参加者が出席表明を検知した場合にも、出席表明を通知する。
この場合、各サービス管理システム１０は、必要に応じて通知に応じた対応を行なう（Ｆ２１）。

また、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、イベントについて内容変更（イベントの削除を含む）を検知する（Ｆ１５）。

この場合、イベント支援システム２０の制御部２１は、統制変更の有無を確認する（Ｆ１６）。ここで、統制変更があると判定した場合（Ｆ１７において「統制変更有」の場合）、イベント支援システム２０の制御部２１は、上述のように、承認ＷＦの合成（Ｆ１２）以降の処理を行なう。

一方、統制変更がないと判定した場合（Ｆ１７において「統制変更無」の場合）、イベント支援システム２０の制御部２１は、各サービス管理システム１０に対して、変更を通知する（Ｆ１８）。

イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、イベントや参加者についての状態変化を検知する（Ｆ３１）。そして、イベント支援システム２０の制御部２１は、各サービス管理システム１０に対して、状態変化を通知する（Ｆ３２）。この処理は、サービス連携部２１Ａの状態変更部２１２により実現される。
この場合、各サービス管理システム１０は、必要に応じて通知に応じた対応を行なう（Ｆ４１）。

また、各サービス管理システム１０は、状態変化を察知した場合、イベント支援システム２０に状況変化を通知する（Ｆ４２）。

この場合、イベント支援システム２０の制御部２１は、通知に応じた対応を行なう（Ｆ３３）。これに応じて、イベント支援システム２０の制御部２１は、状態変化の発生を検知する（Ｆ３１）。

（イベントの登録又は内容変更が行なわれた場合の処理）
次に、図５を用いて、イベントの登録又は内容変更が行なわれた場合の処理の概要における処理を詳述する。

まず、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、イベント登録を検知する。このイベント登録には、イベントコード、申請者、日時、場所、イベント種別、業務、資料、参加者に関するデータを含んでいる。

この場合、イベント支援システム２０の制御部２１は、イベント申請処理を実行する（ステップＳ１−１）。具体的には、制御部２１の関連統制抽出部２１３は、イベント管理レコード２４０を生成し、イベント記憶部２４に登録する。このイベント管理レコード２４０には、イベントコード、ステータスに関するデータを含める。ここで、イベント管理レコード２４０のステータスデータ領域には、申請中を記録する。

次に、イベント支援システム２０の制御部２１は、承認ＷＦの合成処理を実行する（ステップＳ１−２）。具体的には、制御部２１の関連統制抽出部２１３は、手続ＤＢ３０のポリシー記憶部３３から、当該申請イベントに関連する「個別統制」項目を抽出する。そして、承認ＷＦ合成部２１４が、抽出された「個別統制」に基づいて承認ワークフローの生成処理を実行する。この処理については、図７、図８を用いて後述する。

次に、イベント支援システム２０の制御部２１は、承認ＷＦ稼働処理を実行する（ステップＳ１−３）。具体的には、制御部２１の承認ＷＦ合成部２１４は、承認ＷＦ実行部２１５に承認ワークフローの実行を指示する。この場合、承認ＷＦ実行部２１５は、ＷＦシステム５５において、承認ワークフローを回付する。そして、ＷＦシステム５５で、承認ワークフローにおいて承認された場合には、イベント記憶部２４のイベント管理レコード２４０のステータスデータ領域に、承認結果を記録する。

そして、承認ワークフローにおいて承認された場合には、イベント支援システム２０の制御部２１は、承認の通知処理を実行する（ステップＳ１−４）。具体的には、制御部２１の状態通知部２１１は、サービス管理システム１０に対して、イベントの承認を通知する。この通知には、イベント内容に関するデータを含める。

この場合、各サービス管理システム１０は、必要に応じて通知に応じた対応処理を実行する（ステップＳ１−５）。ここでは、後述するように、各サービス管理システム１０は、イベント支援システム２０から取得した通知に対応した処理を実行する。

更に、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、承認済みイベントに係る各参加者の参加表明（出席表明、欠席表明）を検知した場合、イベント支援システム２０の制御部２１は、イベント登録処理を実行する（ステップＳ２−１）。具体的には、制御部２１の関連統制抽出部２１３は、イベント記憶部２４に登録されているイベント管理レコード２４０の参加者データ領域において、参加者を追加したり削除したりする。そして、イベント管理レコード２４０のステータスデータ領域には、各参加者の参加表明を記録する。

次に、イベント支援システム２０の制御部２１は、参加表明の通知処理を実行する（ステップＳ２−２）。具体的には、制御部２１の状態通知部２１１は、各サービス管理システム１０に対して、この承認イベントへの参加者の参加表明を通知する。この通知にも、イベント内容に関するデータを含める。この場合も、各サービス管理システム１０は、必要に応じて通知に応じた対応処理を実行する（ステップＳ２−３）。

また、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、イベントについて内容変更（承認イベントの削除を含む）を検知した場合、イベント支援システム２０の制御部２１は、内容変更登録処理を実行する（ステップＳ３−１）。具体的には、制御部２１の関連統制抽出部２１３は、イベント記憶部２４に登録されているイベント管理レコード２４０の内容を修正する。

次に、イベント支援システム２０の制御部２１は、統制変更の有無の確認処理を実行する（ステップＳ３−２）。具体的には、制御部２１の関連統制抽出部２１３は、手続ＤＢ３０のポリシー記憶部３３から、当該承認イベントに関連する「個別統制」を抽出する。そして、関連統制抽出部２１３は、内容変更により「個別統制」に違いが生じる場合には統制変更があると判定する。

ここで、統制変更があると判定した場合（ステップＳ３−３において「ＹＥＳ」の場合）、イベント支援システム２０の制御部２１は、上述のように、ステップＳ１−２〜Ｓ１−４と同様に、承認ＷＦの合成処理（ステップＳ３−４）、承認ＷＦ稼働処理（ステップＳ３−５）、承認の通知処理（ステップＳ３−６）を実行する。この場合も、各サービス管理システム１０は、必要に応じて通知に応じた対応処理を実行する（ステップＳ３−７）。

一方、統制変更がないと判定した場合（ステップＳ３−３において「ＮＯ」の場合）、イベント支援システム２０の制御部２１は、変更の通知処理を実行する（ステップＳ３−８）。具体的には、制御部２１の状態通知部２１１は、サービス管理システム１０に対して、承認イベントについて内容変更があったことを通知する。この通知にも、イベント内容に関するデータを含める。この場合も、各サービス管理システム１０は、必要に応じて通知に応じた対応処理を実行する（ステップＳ３−９）。

（イベントや参加者についての状態変化の発生を検知した場合の処理）
次に、図６を用いて、イベント支援システム２０において、イベントや参加者について、状態変化の発生を検知した場合の処理を説明する。

この場合には、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、状態変化の発生の検知処理を実行する（ステップＳ４−１）。具体的には、制御部２１の状態変更部２１２は、イベント記憶部２４のイベント管理レコード２４０に記録されたステータスを、状態変化の内容に応じて変更する。

この場合、イベント支援システム２０の制御部２１は、状態変化の通知処理を実行する（ステップＳ４−２）。具体的には、制御部２１の状態通知部２１１は、サービス管理システム１０に対して、状態変化が発生したことを通知する。この通知にも、イベント内容に関するデータを含める。この場合、各サービス管理システム１０は、必要に応じて通知に応じた対応処理を実行する（ステップＳ４−３）。

また、各サービス管理システム１０が、状態変化を察知した場合、状況変化の通知処理を実行する（ステップＳ５−１）。具体的には、サービス管理システム１０は、承認イベントに関連して提供しているサービスについての状況変化を検知する。そして、イベントコードに関連づけられたサービスの状況変化を検知した場合、サービス管理システム１０は、イベント支援システム２０に対して、状態変化が発生したことを通知する。この通知には、イベントコードに関するデータを含める。

この場合、イベント支援システム２０の制御部２１は、必要に応じて状態の変更処理を実行する（ステップＳ５−２）。具体的には、制御部２１の状態変更部２１２は、サービス管理システム１０から通知を取得する。そして、状態変更部２１２は、状態変更辞書を用いて、承認イベントの状態変更の要否を判定する。状態変更を行なう場合には、状態変更部２１２は、通知に含まれるイベントコードが記録されたイベント管理レコード２４０を、イベント記憶部２４から抽出する。そして、状態変更部２１２は、このイベント管理レコード２４０に記録されたステータスを、状態変化の内容に応じて変更する。この場合、イベント支援システム２０は、サービス管理システム１０に対して、状態変化の通知処理を実行する（ステップＳ５−３）。この場合も、各サービス管理システム１０は、必要に応じて通知に応じた対応処理を実行する（ステップＳ５−４）。

（関連統制表の作成処理）
次に、図７を用いて、関連統制表の作成処理について説明する。
ここでは、イベント支援システム２０の制御部２１は、業務統制の抽出処理を実行する（ステップＳ６−１）。具体的には、制御部２１の関連統制抽出部２１３は、スケジュール管理システム５０から取得したイベント情報においてイベント種別を特定する。そして、関連統制抽出部２１３は、ポリシー記憶部３３において、このイベント種別に対応した統制事象に関連付けられた統制表ＣＴ（業務統制の統制表ＣＴ）を特定する。次に、関連統制抽出部２１３は、この業務統制の統制表ＣＴにおいて、「実施許諾」に記録されている項目を業務個別統制として特定する。

次に、イベント支援システム２０の制御部２１は、管理統制の抽出処理を実行する（ステップＳ６−２）。具体的には、制御部２１の関連統制抽出部２１３は、スケジュール管理システム５０から取得したイベント情報においてイベント内容を特定する。次に、関連統制抽出部２１３は、ポリシー記憶部３３において、このイベント内容に含まれる管理種別に対応した統制事象に関連付けられた統制表ＣＴ（管理統制の統制表ＣＴ）を特定する。具体的には、関連統制抽出部２１３は、統制局面「実施許諾」の統制項目「網羅性」の条件が、イベント内容を満たす統制表ＣＴを特定する。ただし、「網羅性」以外が空欄の場合は除外する。

（承認ワークフローの生成処理）
次に、図８を用いて、この関連統制表を用いての承認ワークフローの生成処理を説明する。

ここでは、まず、イベント支援システム２０の制御部２１は、人手で行なうべき個別統制の抽出処理を実行する（ステップＳ７−１）。具体的には、制御部２１の承認ＷＦ合成部２１４は、関連統制抽出部２１３が特定した統制表ＣＴ（業務統制及び管理統制の統制表ＣＴ）の統制局面が「実施許諾」であって、個別統制の実行が役務である個別統制を抽出する。

次に、イベント支援システム２０の制御部２１は、抽出された個別統制の順序関係設定処理を実行する（ステップＳ７−２）。具体的には、制御部２１の承認ＷＦ合成部２１４は、抽出された個別統制を持つ統制表ＣＴの順序関係を、統制項目が「網羅性」の内容領域に記録されている条件に基づき特定する。同様に、承認ＷＦ合成部２１４は、同じ統制表ＣＴに属する個別統制の内容領域に記録されている条件に基づき、統制表ＣＴの中での個別統制の順序関係を特定する。

次に、イベント支援システム２０の制御部２１は、同一順序にある個別統制のマージ処理を実行する（ステップＳ７−３）。具体的には、制御部２１の承認ＷＦ合成部２１４は、同じ順位にある実行領域が同じ役務である個別統制を統合して役務ベース承認ワークフローを作成する。

次に、イベント支援システム２０の制御部２１は、組織や業務に基づいて役務から人への展開処理を実行する（ステップＳ７−４）。具体的には、制御部２１の承認ＷＦ合成部２１４は、パーティ管理システム２２、業務記憶部２３、役務割当表記憶部３２に記録された各レコードを参照して、役務ベース承認ワークフローの各個別統制の内容を実行する実行権限者（個別統制について可否・良否判断を担う権限者）を特定する。ここで、複数の役職員が実行権限を有する場合には、すべての役職員を実行権限者として特定する。

次に、イベント支援システム２０の制御部２１は、承認ＷＦの最適化処理を実行する（ステップＳ７−５）。具体的には、制御部２１の承認ＷＦ合成部２１４は、各個別統制において、上位、下位の順序関係を含めて、共通した実行権限者を特定する。そして、承認ルールに反しておらず、共通した実行権限者を設定可能な場合には、承認ＷＦ合成部２１４は、承認ワークフローを統合する。これにより、役務ベース承認ワークフローにおける実行権限者を統合して人ベース承認ワークフローを作成する。

（状態遷移の具体例）
まず、図９を用いて、イベントの申請や実施、承認イベントの参加者についての状態遷移を説明する。

スケジュール管理システム５０に新規イベントが登録されたことを検知した場合、イベント支援システム２０の制御部２１は当該イベントを申請イベントとして認識、申請状態（ＳＴ１１）とする。そして、当該申請イベントの承認ワークフローを生成・実行する。申請状態中に申請イベントの内容を変更した場合、申請状態のままとなる。承認ワークフローが起動され、権限者により申請が申請者に差し戻された場合も同様に、申請状態のままとなる。

また、申請状態において、申請が取り消された場合には、申請はキャンセル状態（ＳＴ１２）となる。
申請が承認された場合には、承認状態（ＳＴ１３）となる。この承認状態において承認イベント内容に変更が生じた場合、統制対象の変更の有無によって異なる状態に遷移する。統制に変更が生じない場合には、承認状態（ＳＴ１３）を維持することになる。一方、統制対象に変更が生じた場合には、申請状態（ＳＴ１１）に戻り、変更の承認を求める承認ワークフローが生成・実行される。なお、既に承認された承認イベントを取り消すことも可能である。この場合には、申請状態での取下げと同様にキャンセル状態となる。

そして、承認イベントが開始された場合には、実施状態（ＳＴ１４）となる。更に、承認イベントが終了した場合には、終了状態（ＳＴ１５）となる。
また、承認イベントに対しての参加者が設定されている場合には、各参加者は参加依頼状態（ＳＴ２１）となる。ここで、各参加者において参加表明を行なった場合、その内容に応じて、欠席表明又は出席表明の状態（ＳＴ２２）となる。そして、出席表明に対して、実際の参加状況として、欠席と出席との二つの状態（ＳＴ２３）がある。なお、当初より出席を予定している参加者の場合には、参加依頼状態（ＳＴ２１）から参加状況状態（ＳＴ２３）となる。参加表明の有無、参加表明の内容にかかわらず、実際に出席した場合には、実際の参加状況は出席となる。

更に、各参加者は、出席表明状態（ＳＴ２２）と並行して、参加形態（ＡＴ１）の属性を持つ。具体的には、参加者が役職員の場合又は部外者の場合、参加者の勤務場所に応じて移動がある場合又はない場合がある。なお、本実施形態では、入館管理について、入館・入室権限がある場合とない場合とがある。ここでは、参加者の勤務場所に応じて移動がある場合には、入室権限がなく、新たな入館・入室設定が必要である。一方、移動がない場合には、入室権限があり、新たな入館・入室設定は不要とする。

そして、参加表明状態（ＳＴ２２）において出席表明であり、参加状況（ＳＴ２３）において出席した、すべての参加者が退席した場合には、承認イベントの終了と判定する。承認イベントの終了時点で参加状況（ＳＴ２３）が「出席」でなかった参加設定者については、参加依頼状態、参加表明状態等は問わず、参加状況（ＳＴ２３）は「欠席」となる。

〔会議を行なう場合の具体例〕
次に、図１０〜図１９を用いて、会議を行なう場合の具体例を説明する。
（統制表の具体例）
次に、図１０〜図１３を用いて、上述した状態遷移が生じる会議の管理において用いる統制表の具体例を説明する。

図１０は、「業務統制：会議（社内会議、訪問、来訪）」についての統制表ＣＴ１を示している。ここで、「ＩＴＡＰ」は「ＩＴアプリケーション統制」を意味している。
図１１は、「管理統制：情報（イベント資料の利用、持出し）」についての統制表ＣＴ２を示している。

図１２は、「管理統制：施設（入館・入室）」についての統制表ＣＴ３を示している。
図１３は、「管理統制：移動（交通費精算）」についての統制表ＣＴ４を示している。この統制表ＣＴ４においては、イベントの実施後における個別統制が登録されている。

（イベント管理の具体例）
次に、図７、図８、図１４〜図１９を用いて、上述した会議を行なう場合のイベント管理処理について説明する。

ここでは、図１４（ａ）に示すように、業務記憶部２３には、プロジェクトＹの関係者（役職員Ａ、Ｂ、Ｃ…）が登録された業務管理レコード２３１が記録されている場合を想定する。

また、図１４（ｂ）に示すように、役務割当表記憶部３２において、関係部の情報管理者（役職員Ａ、Ｚ…）が登録された役務割当管理レコード３２１が記録されている場合を想定する。
そして、図１４（ｃ）に示すように、会議についてイベント５００が登録された場合を想定する。

まず、図７に示したように、イベント支援システム２０の制御部２１は、関連統制表の作成処理を実行する。

ここでは、イベント支援システム２０の制御部２１は、業務統制の抽出処理を実行する（ステップＳ６−１）。具体的には、制御部２１の関連統制抽出部２１３は、手続ＤＢ３０のポリシー記憶部３３において、統制事象として、イベント５００のイベント種別（社内会議）が記録されている統制表ＣＴ（業務統制の統制表ＣＴ）を特定する。ここでは、図１０に示す「会議」についての統制表ＣＴ１が特定される。

次に、イベント支援システム２０の制御部２１は、管理統制の抽出処理を実行する（ステップＳ６−２）。具体的には、制御部２１の関連統制抽出部２１３は、統制事象として、イベント５００のイベント内容に合致する統制表ＣＴ（管理統制の統制表ＣＴ）を特定する。ここでは、図１１に示す「情報」についての統制表ＣＴ２が特定される。

次に、図８に示したように、イベント支援システム２０の制御部２１は、承認ワークフローの生成処理を実行する。
まず、イベント支援システム２０の制御部２１は、人手で行なうべき個別統制の抽出処理を実行する（ステップＳ７−１）。具体的には、制御部２１の承認ＷＦ合成部２１４は、関連統制表において、管理者や役務者による確認が必要な個別統制を特定する。

この処理により、図１４（ｄ）に示す人手で行うべき個別統制の人ベース個別統制リスト５１０が生成される。ここでは、業務管理者による申請イベント（会議）の正当性（業務上の是非）、権限性（業務上の権限）についての確認が必要であることを示している。また、申請イベント（会議）の正当性、権限性が確認された場合には、情報管理者による情報管理上の正当性についての確認が必要であることを示している。

更に、イベント支援システム２０の制御部２１は、抽出された個別統制の順序関係設定処理を実行する（ステップＳ７−２）。そして、イベント支援システム２０の制御部２１は、同一順序にある個別統制のマージ処理を実行する（ステップＳ７−３）。

この処理により、図１４（ｅ）に示す役務ベース承認ワークフロー５２０が生成される。すなわち、まず業務管理者が「会議の正当性」及び「会議の権限性」の確認処理５２１を行ない、それに続き情報管理者が「情報（管理上）の正当性」の確認処理５２２を行なう。

次に、イベント支援システム２０の制御部２１は、組織や業務に基づいて役務から人への展開処理を実行する（ステップＳ７−４）。具体的には、制御部２１の承認ＷＦ合成部２１４は、業務管理者として、図１４（ｃ）のイベント情報において、対象のプロジェクトＹを特定し、図１４（ａ）の業務管理レコード２３１においてプロジェクトＹのリーダである役職員Ａを特定する。また、情報管理者として、図１４（ｂ）の役務割当管理レコード３２１において、１部情報管理者として、役職員（Ａ，Ｚ）を特定する。

この処理により、図１５（ａ）に示す人ベース承認ワークフロー５３０が生成される。ここでは、役職員Ａが「会議の正当性」及び「会議の権限性」を確認する。また、役職員Ａ又は役職員Ｚが、「情報の正当性」を確認する。これにより、役務を人に置き換えた承認ワークフローが生成される。

次に、イベント支援システム２０の制御部２１は、承認ＷＦの最適化処理を実行する（ステップＳ７−５）。具体的には、制御部２１の承認ＷＦ合成部２１４は、各個別統制において、共通した実行権限者を特定する。ここでは、承認ワークフローを割り当てられた各実行権限者について、個別統制を統合する。ここでは、役職員Ａは、「会議の正当性」、「会議の権限性」及び「情報の正当性」についての確認権限を有する。

この場合、図１５（ｂ）に示す最適化版の承認ワークフロー５４０（人ベース承認ＷＦ（最適化版））のように、役職員Ａが「会議の正当性」、「会議の権限性」及び「情報の正当性」すべての確認を一度に行なってもよい。或いは、役職員Ａが「会議の正当性」、「会議の権限性」の確認を行ない、役職員Ｚが「情報の正当性」について確認を行なってもよい。

更に、実際のＷＦシステム上で確認操作を行なう場合、論理的に順序が同じ権限者を統合する方が現実的である。具体的には、図１５（ｃ）に示す現実解版の承認ワークフロー５５０（人ベース承認ＷＦ（現実解版））のように、まず、役職員Ａに確認操作が要求されるが、そこでは「会議の正当性」、「会議の権限性」は必須、「情報の正当性」は任意（option）となる。役職員Ａが、すべての確認を行なった場合には、承認ワークフローは終了し、申請イベントは承認されたことになる。一方、役職員Ａが「情報の正当性」について確認していない場合には、役職員Ｚによる「情報の正当性」の確認操作が必須となる。

（各サービス管理システムとの連携）
次に、図１６を用いて、イベント支援システム２０とサービス管理システム１０との連携について説明する。ここでは、上述した会議における連携を説明する。本実施形態では、イベント支援システム２０と、施設管理システム１０ａ、情報管理システム１０ｂ、交通費管理システム１０ｃの各サービス管理システム１０との連携を想定する。なお、施設管理システム１０ａにおける処理は図１７、情報管理システム１０ｂにおける処理は図１８、交通費管理システム１０ｃにおける処理は図１９を用いて後述する。

まず、イベントの申請があった場合（ステップＳ８−１）には、イベントは承認前であり、イベント支援システム２０とサービス管理システム１０との連携はなされない。
申請イベントが承認され実際に実施されるまでには、以下のように、イベント内容に係る操作が行われる。
・イベント承認（ステップＳ８−２）
・参加者についての出席表明（ステップＳ８−３）
・参加者についての欠席表明（ステップＳ８−４）
・承認イベントについての資料変更（ステップＳ８−５）
・承認イベントについての場所変更（ステップＳ８−６）
・承認イベントについての取消（ステップＳ８−７）

これらのイベント内容に係る操作（ステップＳ８−２からＳ８−７）については、イベント支援システム２０のサービス連携部２１Ａからサービス管理システム１０に通知がなされ（図４の通知Ｆ１４、Ｆ１８）、サービス管理システム１０では通知に応じた対応がなされる。

承認イベントの実施に係る動きは、サービス管理システム１０が検知した状況変化として、イベント支援システム２０に通知される（ステップＳ９−１からＳ９−４）。
例えば、施設管理システム１０ａが、参加者の入館を検知した場合、図４の通知Ｆ４２に対応して、イベント支援システム２０に対して参加者の入館通知を行なう（ステップＳ９−１）。

また、情報管理システム１０ｂが参加者の出席を検知した場合、情報管理システム１０ｂは、図４の通知Ｆ４２に対応して、イベント支援システム２０に対して参加者の出席通知を行なう（ステップＳ９−２）。

この場合、イベント支援システム２０の制御部２１は、ステップＳ５−２（図６）に対応して、イベント開始を認識（ステップＳ８−８）し、イベントを実施状態に遷移させる（図９のＳＴ１４）。イベント支援システム２０の制御部２１は、イベントが実施状態に遷移したことを、サービス管理システム１０に通知する（図４の通知Ｆ３２）。

情報管理システム１０ｂがイベント終了を検知した場合、情報管理システム１０ｂは、図４の通知Ｆ４２に対応して、イベント支援システム２０に対してイベントの終了通知を行なう（ステップＳ９−３）。

この場合、イベント支援システム２０の制御部２１は、ステップＳ５−２（図６）に対応して、イベント終了を認識（ステップＳ８−９）し、イベントを終了状態に遷移させる（図９のＳＴ１５）。イベント支援システム２０の制御部２１は、イベントが終了状態に遷移したことを、サービス管理システム１０に通知する（図４の通知Ｆ３２）。

施設管理システム１０ａが参加者の退館を検知した場合、図４の通知Ｆ４２に対応して、イベント支援システム２０に対して参加者の退館通知を行なう（ステップＳ９−４）。
イベント終了通知を受信した場合、交通費管理システム１０ｃは、イベント出席者の交通費精算の処理（生成、申請、承認）を行なう（ステップＳ９−５〜Ｓ９−７）。

（各サービス管理システムにおける処理）
次に、図１７〜図１９を用いて、上述した具体例の会議を実施する場合に、各サービス管理システム１０において実行される処理を説明する。

（入館・入室の管理処理）
次に、図１７を用いて、入館・入室の管理処理を説明する。この処理は、図１６（図４）に示したイベント支援システム２０からの通知に基づいて行なわれる。ここで、「ループする矢印」記号は、繰り返しを意味する。また、「菱形」記号は、判断を意味する。施設管理システム１０ａは、入館・入室を管理するための入館・入室設定ＤＢを備えている。この入館・入室設定ＤＢの入館・入室設定レコードには、来訪者コード、拠点、時間、イベントに関するデータが記録される。

来訪者コードデータ領域は、来訪者を特定するために、パーティ管理システム２２に記録されている役職員コードが記録される。
拠点データ領域は、来訪者が訪問する拠点を特定するための識別子に関するデータが記録される。

時間データ領域は、イベント開催時間に対応して、来訪者が訪問する年月日及び時刻に関するデータが記録される。
イベントデータ領域は、来訪目的である承認イベントを特定するための識別子（イベントコード）に関するデータが記録される。

以下、施設管理システム１０ａにおいて実行される情報処理を説明する。
イベント支援システム２０の制御部２１より、イベントの承認通知がもたらされた場合（図１６のステップＳ８−２）、施設管理システム１０ａは、このイベント（会議）の出席表明者に対し、入館・入室判定処理を実行する（ステップＳ１０−１）。具体的には、施設管理システム１０ａは、出席表明者毎に、出席表明者がイベント（会議）開催場所の入館・入室権限を有しているかどうかをチェックする。ここで、施設管理システム１０ａは、その結果に基づき、各参加表明者の参加形態の入館・入室権限有無（ＡＴ１）を判定する。

当該出席表明者がイベント（会議）開催場所の入館・入室権限を持たない場合（以降、「来訪者」と称する）には、施設管理システム１０ａは、入館・入室設定追加処理を実行する（ステップＳ１０−２）。具体的には、施設管理システム１０ａは、当該出席表明者について、来訪者コード、拠点、時間、イベントに関するデータを含めた入館・入室設定レコードを生成し、入館・入室設定ＤＢに記録する。なお、施設管理システム１０ａは、部外者に対しては、イベントコード、来訪者の法人名・氏名を記録した２次元コードを生成する。そして、施設管理システム１０ａは、この２次元コードを部外者の携帯端末に送信する。

また、イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（出席表明）通知がもたらされた場合（図１６のステップＳ８−３）にも、施設管理システム１０ａは、新たに出席表明した参加者について、入館・入室設定要否判定処理（ステップＳ１０−１）、必要に応じ入館・入室設定追加（ステップＳ１０−２）を実行する。

一方、イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（欠席表明）通知がもたらされた場合（図１６のステップＳ８−４）、施設管理システム１０ａは、当該欠席表明者が来訪者の場合には、入館・入室設定削除処理を実行する（ステップＳ１０−３）。具体的には、入館・入室設定ＤＢから、当該来訪者の当該イベントの入館・入室設定レコードを削除する。

また、イベント支援システム２０の制御部２１より、承認イベントの取消通知がもたらされた場合（図１６のステップＳ８−７）も、施設管理システム１０ａは、来訪者の入館・入室設定削除（ステップＳ１０−３）を実行する。

一方、イベント支援システム２０の制御部２１より、承認イベントの変更通知がもたらされた場合、施設管理システム１０ａは、まず施設変更かどうかについて判定する。施設変更の場合（図１６のステップＳ８−６）、施設管理システム１０ａは、来訪者の入館・入室設定削除処理を行なう（ステップＳ１０−３）。

更に、施設管理システム１０ａは、各出席表明者に対し、変更後施設における入館・入室設定要否判定処理（ステップＳ１０−１）、必要に応じ入館・入室設定追加処理（ステップＳ１０−２）を実行する。

なお、施設の変更がない場合には、施設管理システム１０ａは、来訪者について、設定変更処理を実行する（ステップＳ１０−４）。例えば、承認イベントの時間変更等については、入館・入室設定ＤＢに記録されている入館・入室設定レコードの時間を変更する。

来訪者が役職員の場合、入館・入室設定ＤＢの入館・入室設定レコード情報に基づき、入館・入室設定ＤＢに記録された時間（イベント開催時間）近傍であれば社員証（ＩＤカード）で入館・入室が可能である。実際の入館・入室にあたっては、所管のゲート開閉カードリーダにＩＤカードをかざして入館・入室を行なう。

来訪者が他法人の部外者の場合、社員証（ＩＤカード）を持たないため、窓口で外部来訪者用ＩＤカードを貸与する。具体的には、送付された２次元コードを施設受付の２次元コードリーダで読み込み、イベントと来訪者を特定する。引続き、貸与する外部来訪者用ＩＤカードをカードリーダに読み込ませ、イベントと来訪者とをリンクさせることで、当該外部来訪者用ＩＤカードを、入館・入室設定ＤＢの入館・入室設定レコード情報に紐付ける。これにより、役職員と同様に、イベント開催時間近傍であれば当該外部来訪者用ＩＤカードで入館・入室が可能となる。

来訪者の入館を検知すると、施設管理システム１０ａは、来訪者入館処理を実行する（ステップＳ１０−５）。この場合、施設管理システム１０ａは、イベント支援システム２０に対して、来訪者の入館通知を行なう（図１６のステップＳ９−１）。

また、施設管理システム１０ａは、役職員来訪者の場合は社員証（ＩＣカード）による施設退館操作により、また部外者の場合は外部来訪者用ＩＤカードの受付返却操作によって、施設からの退館を検知する。退館を検知した場合、施設管理システム１０ａは、来訪者退館処理を実行する（ステップＳ１０−６）。この場合、施設管理システム１０ａは、イベント支援システム２０に対して、来訪者についての退館通知を行なう（図１６のステップＳ９−４）。

（情報管理処理）
次に、図１８を用いて、情報管理処理を説明する。この情報管理システム１０ｂは、参加者に対して情報を配付するためのイベント資料ＤＢを備えている。このイベント資料ＤＢには、イベントコードに関連付けられて、イベントの申請者によって登録された配付資料（イベント資料）が記録される。更に、この配付資料には、［一般、重要、機密］等の情報の重要度が付加されている。また、情報管理システム１０ｂには、ネットワークを介して、スマート端末に接続される。このスマート端末は、イベントのために情報を閲覧するためのコンピュータ端末である。

以下、情報管理システム１０ｂにおいて実行される情報処理を説明する。
イベント支援システム２０の制御部２１より、イベントの承認通知がもたらされた場合（図１６のステップＳ８−２）、情報管理システム１０ｂは、事前閲覧可能な配付資料を出席表明者所管のスマート端末にプッシュする（ステップＳ１１−１）。具体的には、情報管理システム１０ｂは、出席表明者の所属・役職や配付資料の重要度等に基づいて、イベント資料のアクセス権限に従って、出席表明者毎に事前閲覧可能な配付資料を判定する。そして、情報管理システム１０ｂは、各出席表明者に対し、事前閲覧可能と判定された配付資料を、出席表明者所管のスマート端末に配信（プッシュ）する。

イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（出席表明）通知がもたらされた場合（図１６のステップＳ８−３）も、上述のとおり、情報管理システム１０ｂは、事前閲覧可能な配付資料を、新規出席表明者所管のスマート端末にプッシュする（ステップＳ１１−１）。

また、イベント支援システム２０の制御部２１より、承認イベントの変更（配付資料）通知がもたらされた場合（図１６のステップＳ８−５）、上述のとおり、情報管理システム１０ｂは、追加資料について、事前閲覧可能な配付資料を出席表明者所管のスマート端末にプッシュする（ステップＳ１１−１）。

一方、削除資料がある場合、情報管理システム１０ｂは、参加表明者所管のスマート端末から削除資料をデリートする（ステップＳ１１−２）。具体的には、情報管理システム１０ｂは、出席表明者所管のスマート端末に削除資料の削除を指示する。スマート端末は、削除指示された資料が存在すれば、これを削除する。

イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（欠席表明）通知がもたらされた場合（図１６のステップＳ８−４）、情報管理システム１０ｂは、欠席表明者所管のスマート端末から削除資料をデリートする（ステップＳ１１−２）。

イベント支援システム２０の制御部２１より、承認イベントの取消がもたらされた場合（図１６のステップＳ８−７）、情報管理システム１０ｂは、すべての出席表明者所管のスマート端末から当該イベント資料をデリートする（ステップＳ１１−２）。

情報管理システム１０ｂは、参加者のスマート端末が社外にあることを検知した場合、イベント資料へのアクセス権限（Ｒ／Ｗ機能）をオフにする（ステップＳ１１−３）。
一方、参加者の承認イベントへの出席を検知した場合（イベント開催時刻に開催場所にいることを検知した場合）、イベント資料へのアクセス権限（Ｒ／Ｗ機能）をオンする（ステップＳ１１−４）。そして、イベント支援システム２０に対して、当該参加者の出席通知を行なう。この参加者出席通知には、イベント、参加者を特定するための情報を含める。

また、情報管理システム１０ｂは、承認イベントの終了を検知した場合（イベント開催時刻超過や開催場所からの離脱等を検知した場合）、イベント資料をデリートする（ステップＳ１１−５）。

そして、情報管理システム１０ｂにおいて、全参加者の終了を検知した場合、イベント支援システム２０に対して、イベントの終了通知を送信する。このイベント終了通知には、イベントを特定するための情報を含める。

（交通費精算の管理処理）
次に、図１９を用いて、交通費精算の管理処理を説明する。交通費管理システム１０ｃは、移動ＤＢ、交通費精算ＤＢに接続されている。移動ＤＢには、交通費細目レコードが記録される。この交通費細目レコードには、交通費細目コード、日付、行先（イベント場所）、目的（イベント種別）、イベント、経路、金額、精算日、役職員に関するデータが記録される。

交通費細目コードデータ領域には、各交通費細目レコードを特定するための識別子に関するデータが記録される。
日付データ領域には、イベント開催日に関するデータが記録される。
行先データ領域には、イベント場所を特定するためのデータが記録される。
目的データ領域には、イベント種別を特定するためのデータが記録される。
イベントデータ領域には、参加した承認イベントを特定するための識別子（イベントコード）に関するデータが記録される。

経路データ領域には、移動した経路に関するデータが記録される。
金額データ領域には、移動に要した交通費の金額に関するデータが記録される。
精算日データ領域には、精算申請した年月日が記録される。
役職員データ領域には、承認イベントのために移動した役職員を特定するための識別子（役職員コード）に関するデータが記録される。

交通費精算ＤＢには、交通費精算管理レコードが記録される。この交通費精算管理レコードには、役職員、期間、金額、交通費細目コード、精算状況に関するデータが記録される。

役職員データ領域には、交通費の精算対象の役職員を特定するための識別子（役職員コード）に関するデータが記録される。
期間データ領域には、交通費の精算対象の期間に関するデータが記録される。本実施形態では、交通費精算の締日によって定められる期間（例えば、２０１３年４月期）毎に設定される。

金額データ領域には、この役職員における精算対象の金額に関するデータが記録される。
交通費細目コードデータ領域には、交通費精算対象の交通費細目レコードを特定するための識別子に関するデータが記録される。

精算状況データ領域には、この役職員の精算状況を特定するためのフラグが記録される。
なお、交通費精算ＤＢの交通費精算管理レコードは、期間（精算対象期間）中の移動ＤＢ中の交通費細目レコードを要素として保持する。

以下、交通費管理システム１０ｃにおいて実行される情報処理を説明する。
イベント支援システム２０の制御部２１より、イベントの終了通知がもたらされた場合（図１６のステップＳ８−９）、交通費管理システム１０ｃは、出席者移動判定処理を実行する（ステップＳ１２−１）。具体的には、交通費管理システム１０ｃは、出席者において、イベント出席のために移動した役職員（移動参加者）を特定する。具体的には、役職員の勤務先と、イベント（会議）の場所とを比較することにより判定する。

そして、交通費管理システム１０ｃは、移動参加者毎に、移動情報の生成処理を実行する（ステップＳ１２−２）。具体的には、交通費管理システム１０ｃは、移動参加者毎に、移動が発生したイベント情報に基づいて、以下の交通費細目レコードを生成、移動ＤＢに記録する。
交通費細目レコードの日付＝イベント日付
交通費細目レコードの行先＝イベント場所
交通費細目レコードの目的＝イベント種別
交通費細目レコードのイベント＝イベントＩＤ
交通費細目レコードの役職員＝移動参加者の役職員コード

なお、イベントの行先が自社拠点やプロジェクト等に係る顧客先である場合、承認経路として、経路及び金額には、予め規定された値を設定するようにしてもよい。この場合には、交通費管理システム１０ｃに、自社拠点や顧客先に対応して経路及び金額のデフォルト値を保持させておく。

交通費精算ＤＢに、移動参加者に係るイベント日付が属する精算対象期間の未精算の交通費精算管理レコードが存在しない場合、移動参加者に係るイベント日付が属する精算対象期間の交通費精算管理レコードを生成する。この交通費精算管理レコードには、先に生成した交通費細目レコードの交通費細目コードを記録することにより、両レコードを関連付けておく。

そして、交通費管理システム１０ｃは、イベント支援システム２０に対して、交通費精算についてのＴｏＤｏ通知を送信する（図１６のステップＳ９−５）。この通知を受け、イベント支援システム２０は、スケジュール管理システム５０の当該移動参加者のＴｏＤｏとして、交通費精算を登録する（図１６のステップＳ８−１０）。

なお、交通費精算ＤＢに移動参加者に係るイベント日付が属する精算対象期間の未精算の交通費精算管理レコードが存在する場合は、この交通費精算管理レコードに先の交通費細目レコードを保持させる。

交通費精算締日が到来した場合、交通費管理システム１０ｃは、未精算交通費精算の確認処理を実行する（ステップＳ１２−３）。具体的には、交通費管理システム１０ｃは、交通費精算ＤＢの中から未精算である交通費精算管理レコードを抽出する。

次に、交通費管理システム１０ｃは、未精算である交通費精算管理レコードに記録された役職員に対し、交通費精算喚起処理を実行する（ステップＳ１２−４）。具体的には、交通費管理システム１０ｃは、交通費未精算の役職員に対して、未精算の交通費があることを示した注意喚起のためのメールを送信する。

役職員がスケジュール管理システム５０に登録された交通費精算ＴｏＤｏを選択すると、交通費管理システム１０ｃの交通費精算の申請機能が起動される。役職員は、この機能を使って交通費の精算申請を行なう。具体的には、承認経路外の交通費精算明細については、経路を設定する。この場合、交通費管理システム１０ｃは、経路に応じて金額を自動計算する。承認経路の交通費精算明細については、経路及び金額として、予め規定された値が設定されている。ここで、必要に応じ修正を行なうことができるが、修正を行なった場合には承認経路外となる。

そして、すべての交通費精算明細を確認・設定し、申請を行なう（ステップＳ１２−５）。
交通費精算の申請を行なうと、交通費管理システム１０ｃは、イベント支援システム２０に対して、交通費精算についてのＴｏＤｏ申請を通知する（図１６のステップＳ９−６）。この通知を受け、イベント支援システム２０は、スケジュール管理システム５０の当該移動参加者の交通費精算ＴｏＤｏを申請状態とする（図１６のステップＳ８−１１）。

次に、交通費管理システム１０ｃは、交通費精算承認処理を実行する（ステップＳ１２−６）。具体的には、図１３の統制表ＣＴ４における「管理統制：移動（交通費精算）」に則り、交通費管理システム１０ｃは、承認経路外である交通費精算明細については、経路の正当性について経理担当に確認を求める。経理担当により確認された場合、交通費精算は承認される。

交通費精算が承認されると、交通費管理システム１０ｃは、イベント支援システム２０に対して、交通費精算についてのＴｏＤｏ承認を通知する（図１６のステップＳ９−７）。この通知を受け、イベント支援システム２０は、スケジュール管理システム５０の当該移動参加者の交通費精算ＴｏＤｏを承認状態とする（図１６のステップＳ８−１２）。

交通費精算の申請について承認された場合、交通費管理システム１０ｃは、交通費精算処理を実行する（ステップＳ１２−７）。具体的には、交通費管理システム１０ｃは、各役職員に対して、承認された交通費の支払処理を行なう。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）上記実施形態では、申請イベントの登録を検知した場合、イベント支援システム２０の制御部２１は、承認ＷＦの合成処理を実行する（ステップＳ１−２）。ここでは、イベント支援システム２０の制御部２１は、業務統制の抽出処理を実行する（ステップＳ６−１）。更に、イベント支援システム２０の制御部２１は、管理統制の抽出処理を実行する（ステップＳ６−２）。これにより、イベントに応じて、各個別統制を管理するための関連統制表を作成することができる。

更に、イベント支援システム２０の制御部２１は、人手で行なうべき個別統制の抽出処理を実行する（ステップＳ７−１）。そして、イベント支援システム２０の制御部２１は、抽出された個別統制の順序関係設定処理を実行する（ステップＳ７−２）。これにより、一つのイベントに対して複数の承認が必要な場合にも、前提条件を考慮して、的確な承認作業を行なうことができる。

また、イベント支援システム２０の制御部２１は、同一順序にある個別統制のマージ処理を実行する（ステップＳ７−３）。これにより、一つのイベントに対して複数の承認が必要な場合にも、まとめて承認作業を行なうことができる。

また、イベント支援システム２０の制御部２１は、組織や業務に基づいて役務から人への展開処理を実行する（ステップＳ７−４）。そして、イベント支援システム２０の制御部２１は、承認ＷＦの最適化処理を実行する（ステップＳ７−５）。これにより、一つのイベントに対して複数の承認が必要な場合にも、まとめて承認作業を行なうことができる。

（２）上記実施形態では、イベント支援システム２０の制御部２１より、イベントの承認通知がもたらされた場合、施設管理システム１０ａは、このイベント（会議）の出席表明者に対し、入館・入室設定要否判定処理を実行する（ステップＳ１０−１）。当該出席表明者がイベント（会議）開催場所の入館・入室権限を持たない場合、施設管理システム１０ａは、入館・入室設定追加処理を実行する（ステップＳ１０−２）。これにより、イベントの承認に基づいて、イベントの実施に必要な入館や入室のための手続を行なうことができる。

また、イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（出席表明）通知がもたらされた場合、施設管理システム１０ａは、新たに出席表明した参加者について、入館・入室設定要否判定処理を実行する（ステップＳ１０−１）。これにより、状況変化に応じて、入館や入室のための手続を行なうことができる。

また、イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（欠席表明）通知がもたらされた場合、施設管理システム１０ａは、当該欠席表明者が来訪者の場合には、入館・入室設定削除処理を実行する（ステップＳ１０−３）。これにより、状況変化に応じて、入館や入室が不要になった関係者に対する手続を行なうことができる。

また、施設の変更がない場合には、施設管理システム１０ａは、来訪者について、設定変更処理を実行する（ステップＳ１０−４）。これにより、状況変化に応じて、入館や入室のための手続を変更することができる。

また、カードリーダの読取により、来訪者の入館を検知した場合、施設管理システム１０ａは、来訪者入館処理を実行する（ステップＳ１０−５）。この場合、施設管理システム１０ａは、イベント支援システム２０に対して、参加者について入館通知を行なう。これにより、イベント支援システム２０は、イベントの参加者の参加状況を把握することができる。

また、カードリーダの読取により、来訪者の退館を検知した場合、施設管理システム１０ａは、来訪者退館処理を実行する（ステップＳ１０−６）。この場合、施設管理システム１０ａは、イベント支援システム２０に対して、参加者の退館通知を行なう。これにより、イベント支援システム２０は、イベントの進行状況を把握することができる。

（３）上記実施形態では、イベント支援システム２０の制御部２１より、イベントの承認通知がもたらされた場合、情報管理システム１０ｂは、事前閲覧可能な配付資料を出席表明者所管のスマート端末にプッシュする（ステップＳ１１−１）。これにより、イベントで用いる資料を的確に配付することができる。

また、イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（出席表明）通知がもたらされた場合、情報管理システム１０ｂは、事前閲覧可能な配付資料を、新規出席表明者所管のスマート端末にプッシュする（ステップＳ１１−１）。これにより、参加者が変更になった場合にも、的確に資料を配付することができる。

また、イベント支援システム２０の制御部２１より、承認イベントの変更（配付資料）通知がもたらされた場合、情報管理システム１０ｂは、追加資料について、事前閲覧可能な配付資料を出席表明者所管のスマート端末にプッシュする（ステップＳ１１−１）。これにより、資料が変更された場合にも、的確に資料を配付することができる。

また、イベント支援システム２０の制御部２１より、承認イベントの参加者の変更（欠席表明）通知がもたらされた場合、情報管理システム１０ｂは、欠席表明者所管のスマート端末から削除資料をデリートする（ステップＳ１１−２）。これにより、イベントに参加できなくなった場合、配付した資料を削除することができる。

また、イベント支援システム２０の制御部２１より、承認イベントの取消がもたらされた場合、情報管理システム１０ｂは、すべての出席表明者所管のスマート端末から当該イベント資料をデリートする（ステップＳ１１−２）。これにより、イベントが中止になった場合にも、配付した資料を削除することができる。

また、参加者の承認イベントへの出席を検知した場合、イベント資料へのアクセス権限（Ｒ／Ｗ機能）をオンする（ステップＳ１１−４）。この場合、スマート端末は、イベント支援システム２０に対して、参加者出席通知を行なう。これにより、イベント支援システム２０は、イベント参加者の出席状況を把握することができる。

また、情報管理システム１０ｂにおいて、承認イベントの終了を検知した場合、イベント支援システム２０に対して、イベント終了通知を送信する。これにより、イベント支援システム２０は、イベントの進捗状況を把握することができる。

（４）上記実施形態では、イベント支援システム２０の制御部２１より、イベントの終了通知がもたらされた場合、交通費管理システム１０ｃは、出席者移動判定処理を実行する（ステップＳ１２−１）。これにより、交通費管理システム１０ｃにおいて、交通費が必要な役職員を特定し、交通費の精算を行なうことができる。

なお、上記実施形態は、以下の態様に変更してもよい。
・上記実施形態では、イベント支援システム２０の状態通知部２１１は、サービス管理システム１０に対し、状態変化をブロードキャストする。これに代えて、状態通知部２１１に状態通知辞書を保持し、状態通知辞書に従って通知処理を行なうようにしてもよい。この場合、状態通知辞書には、承認イベントの状態変更の内容に応じた各サービス管理システム１０への通知の条件、及び条件に応じた対応を記録しておく。なお、状態通知辞書はルールやプログラムとして実装することも可能である。

・上記実施形態では、イベント支援システム２０の状態変更部２１２の状態変更は、状態変更部２１２が保持する状態変更辞書を用いて行なわれる。これに代えて、状態変更辞書を、各サービス管理システム１０に保持させるようにしてもよい。なお、状態変更辞書はルールやプログラムとして実装してもよい。

・ 上記実施形態では、イベント支援システム２０は、ネットワークを介して、組織情報記憶部としてのパーティ管理システム２２、業務記憶部２３、イベント記憶部２４に接続されている。パーティ管理システム２２、業務記憶部２３、イベント記憶部２４のハードウェア構成は、これに限定されるものではなく、イベント支援システム２０内に設ける等の構成によって実現することができる。

・ 上記実施形態では、ネットワークを介して、イベント支援システム２０とスケジュール管理システム５０とが接続される。これに代えて、イベント支援システム２０とスケジュール管理システム５０を一つのシステムとして構築するようにしてもよい。この場合には、スケジュール管理レコードにおいて、承認イベントのステータスを管理する。

・ 上記実施形態では、イベント記憶部２４には、スケジュール管理システム５０から取得した申請イベントに関するイベント管理レコード２４０が記録される。このイベント管理レコード２４０には、イベントコード、ステータスに関するデータが記録される。これに代えて、スケジュール管理システム５０において、ステータスを管理させるようにしてもよい。ここでは、イベント支援システム２０において、イベント状態の変更を検知した場合、スケジュール管理システム５０においてステータスを更新する。

・ 上記実施形態では、イベント記憶部２４には、スケジュール管理システム５０から取得した申請イベントに関するイベント管理レコード２４０が記録される。このイベント管理レコード２４０には、イベントコード、ステータスに関するデータが記録される。ここで、イベント管理レコード２４０に、イベントコード、イベント名、申請者、日時、場所、イベント種別、業務、資料、参加者に関するデータを記録するようにしてもよい。

・ 上記実施形態では、状態通知部２１１は、承認等により決定されたイベントの登録や変更に対応して、各サービス管理システム１０に対する通知処理を実行する。この通知処理は、状態通知部２１１が保持する辞書を用いて行なわれる。ここで、状態通知部２１１が、すべてのサービス管理システム１０に対して、通知をブロードキャストするようにしてもよい。この場合には、各サービス管理システム１０は、イベント支援システム２０から取得した通知に基づいて、対応の要否を判定する。このため、各サービス管理システム１０に、イベント支援システム２０から取得した通知に応じた対応を行なうための情報（例えば、「対応をすべき通知の判定条件」と「この判定条件下での対応すべき処理内容」とを関連付けた辞書）を保持させておく。そして、各サービス管理システム１０は、イベント支援システム２０から取得した通知が、提供しているサービスに関連するかどうかを、通知の内容に基づいて判定する。サービス管理システム１０は、提供しているサービスに関連する内容である場合には、この通知に対応した処理を実行する。

・ 上記実施形態では、各参加者は、出席表明状態（ＳＴ２２）と並行して、参加形態（ＡＴ１）の属性を持つ。入館管理について、参加者の勤務場所に応じて移動がある場合には、新たな入館・入室設定が必要であり、移動がない場合には、新たな入館・入室設定は不要とする。これに代えて、役職員毎に、入館・入室可能な施設に基づいて、入館・入室設定を行なうようにしてもよい。この場合には、パーティ管理システム２２において、役職員毎に、入館・入室可能な施設を記録しておく。そして、承認イベントの場所が、入館・入室可能な施設として登録されていない場合には、新たな入館・入室設定を行なう。

・ 上記実施形態では、イベント支援システム２０の制御部２１は、承認ＷＦ稼働処理を実行する（ステップＳ１−３）。ここで、申請イベントの推奨参加者や、イベント参加者のバランスをチェックする参加者管理処理を行なうようにしてもよい。この場合には、統制表ＣＴに、イベント種別に応じて、参加が望まれる推奨参加者を登録しておく。また、イベント参加者に応じて、他の推奨参加者を登録しておくようにしてもよい。そして、イベント支援システム２０の制御部２１は、イベントの申請時に参加者管理処理を行なう。

図２０を用いて、この参加者管理処理を説明する。
まず、イベント支援システム２０の制御部２１は、イベント登録処理を実行する（ステップＳ１３−１）。具体的には、イベント支援システム２０の制御部２１は、スケジュール管理システム５０において、イベント登録を検知する。

次に、イベント支援システム２０の制御部２１は、イベント関係者の特定処理を実行する（ステップＳ１３−２）。具体的には、制御部２１の関連統制抽出部２１３は、登録されたイベント管理レコード２４０の参加者データ領域に記録された参加者をイベント関係者として特定する。

次に、イベント支援システム２０の制御部２１は、関係者に漏れがあるかどうかについての判定処理を実行する（ステップＳ１３−３）。具体的には、制御部２１の関連統制抽出部２１３は、イベント管理レコード２４０のイベント種別や対象に基づいて、統制表ＣＴにおいて推奨参加者を特定する。推奨参加者がイベント関係者として登録されている場合には、関係者に漏れがないと判定する。一方、イベント関係者に含まれない推奨参加者を検知した場合には、関係者に漏れがあると判定する。

関係者に漏れがあると判定した場合（ステップＳ１３−３において「ＹＥＳ」の場合）、イベント支援システム２０の制御部２１は、アラート処理を実行する（ステップＳ１３−４）。具体的には、制御部２１の関連統制抽出部２１３は、申請者の役職員端末に対してアラーム画面を出力する。このアラーム画面には、ＯＫボタンとともに、参加者の変更入力欄が設けられている。

次に、イベント支援システム２０の制御部２１は、変更があるかどうかについての判定処理を実行する（ステップＳ１３−５）。具体的には、制御部２１の関連統制抽出部２１３は、参加者の変更入力欄への入力の有無や、参加者が追加により、変更の有無を判定する。

参加者の変更入力欄に入力があり、変更があると判定した場合（ステップＳ１３−５において「ＹＥＳ」の場合）、イベント支援システム２０の制御部２１は、変更処理を実行する（ステップＳ１３−６）。具体的には、制御部２１の関連統制抽出部２１３は、イベント記憶部２４のイベント管理レコード２４０の参加者データ領域に記録された役職員コードを変更する。そして、ステップＳ１３−３以降の処理を繰り返す。

一方、参加者の変更入力欄に入力がなく、変更がないと判定した場合（ステップＳ１３−５において「ＮＯ」の場合）、イベント支援システム２０の制御部２１は、承認ワークフローにて注意喚起処理を実行する（ステップＳ１３−７）。具体的には、制御部２１の関連統制抽出部２１３は、承認ワークフローにおいて、問題がないことを示すメッセージを含める。

そして、イベント支援システム２０の制御部２１は、ステップＳ１−２と同様に、承認ＷＦ稼働処理を実行する（ステップＳ１３−８）。なお、関係者に漏れがないと判定した場合（ステップＳ１３−３において「ＮＯ」の場合）にも、イベント支援システム２０の制御部２１は、承認ＷＦ稼働処理を実行する（ステップＳ１３−８）。

・ 上記実施形態では、参加者の参加表明（出席表明又は欠席表明）を検知した場合、イベント支援システム２０の制御部２１は、参加者変更通知処理を実行する（ステップＳ８−３、Ｓ８−４）。ここで、代理参加を許容するようにしてもよい。この場合には、イベント支援システム２０は、代理の参加者情報を含めた参加者変更通知を各サービス管理システム１０に送信する。この場合、各サービス管理システム１０は、当初の参加者の権限に基づいて、代理の参加者の対応を行なう。

・ 上記実施形態では、情報管理システム１０ｂにおいて、イベント参加者の情報利用状況に応じて、承認イベントの終了を判定する。承認イベントの終了判定は、情報の利用状況によるものだけに限定されるものではない。例えば、情報管理システム１０ｂにおいて、終了検知できない場合には、承認イベントが設定された時間帯に基づいて、承認イベントの終了を判定するようにしてもよい。この場合には、イベント日時から所定時間が経過したときに、イベント終了と判定する。

・ 上記実施形態では、申請イベントの登録を検知した場合、イベント支援システム２０の制御部２１は、承認ＷＦの合成処理を実行する（ステップＳ１−２）。これに代えて、申請イベントにおける個別統制について事前承認が行なわれている場合には、この個別統制についての承認ワークフローを省略するようにしてもよい。この場合には、イベント支援システム２０に、イベント種別や日時、場所、対象に対して、事前承認情報を記録した承認情報記憶部を設ける。そして、イベント支援システム２０の制御部２１は、申請イベントの登録を検知した場合に、イベント内容に基づいて、承認情報記憶部において、事前承認の有無を確認する。そして、既に事前承認が登録されている場合には、この個別統制については承認済みとして承認ワークフローを省略する。これにより、事前承認により、効率的にイベント内容についての承認を行なうことができる。

・ 上記実施形態では、イベント支援システム２０の制御部２１は、業務統制の抽出処理（ステップＳ６−１）、管理統制の抽出処理（ステップＳ６−２）を実行することにより、関連統制表を生成する。そして、この関連統制表に基づいて、承認ワークフローを生成する。この場合、申請イベントの属性に応じて、承認ワークフローを生成するようにしてもよい。例えば、申請イベントの申請者や日時、場所、参加者の属性に応じて、必要な承認ワークフローを決定する。

・ 上記実施形態では、イベント支援システム２０の制御部２１は、承認結果や承認イベントに関する各種通知をすべてのサービス管理システム１０に送信する。これに代えて、承認イベントの属性に応じて、通知を送信するサービス管理システム１０を選択するようにしてもよい。この場合には、イベント支援システム２０において、個別統制に応じて、通知を送信するサービス管理システム１０を指定した通知先情報記憶部を設ける。

・ 上記実施形態では、交通費管理システム１０ｃは、移動参加者毎に、移動情報の生成処理（ステップＳ１２−２）、未精算交通費精算の確認処理（ステップＳ１２−３）、交通費精算喚起処理（ステップＳ１２−４）を実行する。ここで、交通費管理システム１０ｃが、即時に交通費精算の申請〜承認処理を実行するようにしてもよい。

・ 上記実施形態では、手続ＤＢを、イベント支援システム２０のＷＦ連携部２１Ｂにて承認ワークフローを作成するときに用いる。ここで、連携対象のサービス管理システム１０の特定や、連携先での処理の論理チェックに用いるようにしてもよい。例えば、図１３の統制表ＣＴ４において、「管理統制：移動（交通費精算）」は、統制局面として実施結果を持つ。実施結果の「網羅性」には、イベントの終了時（「実施結果」）に参加者が来訪者であることが定義されている。ここから、交通費精算システムのステップ（ステップＳ１２−１、Ｓ１２−２）を導くことができる。同様に「正当性」、「正確性」から（ステップＳ１２−６）を導くことができる。また、「時限制」から（ステップＳ１２−３）を導くことができる。

・ 上記実施形態では、施設管理システム１０ａは、部外者に対しては、２次元コードを生成し、この部外者の携帯端末に送信する。部外者が来訪した場合、送付された２次元コードを施設受付の２次元コードリーダで読み込み、イベントと来訪者を特定する。引続き、貸与する外部来訪者用ＩＤカードをカードリーダに読み込ませて、外部来訪者用ＩＤカードを、入館・入室設定ＤＢの入館・入室設定レコード情報に紐付ける。２次元コードやＩＤカードに代えて、近距離無線通信技術（ＮＦＣ：Near field communication）を用いることも可能である。この場合には、ＮＦＣ搭載デバイスをＩＤカードとして用いる。また、外部来訪者が所有するＮＦＣ搭載デバイスの識別コードを事前に把握できている場合には、この識別コードにより、入館・入室設定を行なうことも可能である。

・ 上記実施形態では、施設管理システム１０ａは、入館・入室設定追加処理を実行する（ステップＳ１０−２）。ここで、複数のイベントに参加する場合、まとめて入館・入室設定を登録するようにしてもよい。例えば、社内の役職員の場合には、複数のイベントの最早時刻〜最遅時刻までを、入館・入室設定ＤＢに登録する。また、部外者の場合には、一枚の外部来訪者用ＩＤカードに集約する。この場合、イベント毎に、外部来訪者用ＩＤカードに紐付けた入館・入室設定レコードを、入館・入室設定ＤＢに登録する。

・ 上記実施形態では、削除資料がある場合、情報管理システム１０ｂは、参加表明者所管のスマート端末からイベント資料をデリートする（ステップＳ１１−２）。ここで、誰からも参照されていない場合に削除するようにしてもよい（ガーベージコレクション方式）。これにより、複数のイベントで同じファイルが使用される場合にも対応することができる。

・ 上記実施形態では、イベント支援システム２０の制御部２１のＷＦ連携部２１Ｂは、スケジュール管理システム５０において登録されたイベント申請を検知する（Ｆ１１）。ここで、ＷＦ連携部２１Ｂが行なうスケジュール管理システム５０とＷＦシステム５５との連携については、登録（申請）時の他に、承認ワークフロー実行時にも連携させてもよい。

また、申請イベントを、スケジュール管理システム５０でなく、ＷＦシステム５５に登録するようにしてもよい。すなわち、イベント支援システム２０のＷＦ連携部２１Ｂが、ＷＦシステム５５に登録された申請イベントを検知した場合、その情報をイベント記憶部２４に登録する。更に、ＷＦ連携部２１Ｂは、スケジュール管理システム５０にイベントの登録情報を配信する。そして、これ以降は、前述のように、申請イベントの内容に応じた承認ワークフローの合成、実行を行なう。

・ 上記実施形態では、ＷＦシステム５５は、承認ワークフローに基づいて、承認に係る権限者の役職員端末に対して、各種申請を回付する処理を行なう。ここで、承認ワークフロー実行時に、スケジュール管理システム５０のＴｏＤｏを用いて、次に確認等の統制を行なう権限者への通知を行なうようにしてもよい。この場合には、イベント支援システム２０のＷＦ連携部２１Ｂ（承認ＷＦ実行部２１５）が、承認ワークフローに則り、次に確認等の統制を行なうべき権限者のＴｏＤｏに通知する。このＴｏＤｏには、ＷＦシステム５５の当該確認画面へのリンクを設定しておく。そして、ＷＦシステム５５の当該確認画面にて確認作業を行なうことができる。また、ＴｏＤｏからＷＦシステム５５の当該確認画面にリンクすることなく、ＴｏＤｏ画面にて直接当該確認を行なえるようにしてもよい。

・ 上記実施形態では、スケジュール管理システム５０は、役職員が申請したイベント（申請イベント）や、役職員毎のＴｏＤｏを管理する。ここで、イベント支援システム２０の制御部２１のサービス連携部２１Ａが、イベントの状態変化を、逐次、スケジュール管理システム５０に通知するようにしてもよい。また、制御部２１のＷＦ連携部２１Ｂが、承認ワークフローの確認状況を、逐次、スケジュール管理システム５０に通知するようにしてもよい。この場合、スケジュール管理システム５０は、イベントの状態を登録する。これにより、スケジュール管理システム５０のスケジューラを用いて、イベントの状態を確認することができる。

１０…サービス管理システム、１０ａ…施設管理システム、１０ｂ…情報管理システム、１０ｃ…交通費管理システム、２０…イベント支援システム、２１…制御部、２１１…統制抽出部、２１２…ＷＦ生成部、２１３…ＷＦ実行部、２１５…状態通知部、２１６…状態変更部、２２…パーティ記憶部、２３…業務記憶部、２４…イベント記憶部、３０…手続ＤＢ、３２…役務割当表記憶部。

Claims (14)

1. イベントのスケジュール情報が記録されるスケジュール管理システムと、管理対象イベントに対応した各種処理を実行する複数のサービス管理システムとに接続された制御部を備えたイベント支援装置であって、
   前記制御部が、
   前記スケジュール管理システムに記録されたスケジュール情報におけるイベントの参加者に基づいて、管理すべき管理対象イベントを特定し、前記管理対象イベントに対応した各種処理を実行させるために、前記各サービス管理システムに対して、前記管理対象イベントに基づいた通知を行ない、
   前記各サービス管理システムから、前記イベントの参加者に関する管理対象イベントに係る状況変化情報を取得し、
   前記状況変化情報に応じて、前記イベントの参加者の状態を特定し、前記状況変化情報に基づいて判断した前記管理対象イベントのステータス及び前記参加者の状態に応じて、前記状況変化情報を取得した管理対象イベントに後続する管理対象イベントに対応した各種処理を実行させることを特徴とするイベント支援装置。
2. 前記制御部が、前記管理対象イベントのステータスの変更を検知した場合、前記各サービス管理システムに対して、前記管理対象イベントの変更についての通知を行なうことを特徴とする請求項１に記載のイベント支援装置。
3. 前記制御部が、前記管理対象イベントのイベント属性を特定し、
   前記イベント属性に基づいて、前記各サービス管理システムへの通知の要否を判断することを特徴とする請求項１又は２に記載のイベント支援装置。
4. イベントのスケジュール情報が記録されるスケジュール管理システムと、前記スケジュール管理システムに接続された制御部、承認に係る権限者を特定するための権限者特定部を備えたイベント支援装置であって、
   前記制御部が、イベント属性に応じて承認経路を決定する承認経路管理部を更に備え、
   前記制御部が、前記スケジュール情報において新たに登録された管理対象イベントのイベント属性に基づいて、前記承認経路管理部から承認経路を取得し、
   前記特定した複数の承認経路において、前記権限者特定部を用いて、前記イベント属性に応じた承認に係る権限者を特定し、共通した実行権限者を特定し、承認ルールに反しておらず、共通した実行権限者を設定可能な場合には、実行権限者を統合した承認経路を生成することを特徴とするイベント支援装置。
5. 前記制御部が、前記管理対象イベントの参加者の属性に基づいて承認に係る権限者を特定することを特徴とする請求項４に記載のイベント支援装置。
6. 前記承認経路管理部は、統制が必要な統制事象について、個別統制を記録した統制記憶部を更に備え、
   前記制御部が、
   前記イベント属性に応じて、統制が必要な統制事象を特定し、前記承認経路管理部において、前記統制事象についての個別統制に応じた承認経路を決定することを特徴とする請求項４又は５に記載のイベント支援装置。
7. 前記統制記憶部には、個別統制についての順序関係に関する情報が記録されており、
   前記制御部が、
   前記イベント属性に応じて特定された複数の個別統制について、各個別統制の順序関係を特定し、
   前記順序関係に基づいて承認経路を決定することを特徴とする請求項６に記載のイベント支援装置。
8. 前記統制記憶部には、前記承認経路上の承認に係る権限者について、前記権限者が担うべき個別統制を記録したことを特徴とする請求項６又は７に記載のイベント支援装置。
9. 前記制御部が、
   前記管理対象イベントについて、事前承認の有無を確認し、
   既に事前承認が登録されている場合には、前記個別統制について承認済みとして対応することを特徴とする請求項６〜８のいずれか一つに記載のイベント支援装置。
10. 前記制御部が、前記承認経路における承認に係る権限者に対して承認依頼を行ない、前記権限者における承認状況を管理することを特徴とする請求項４〜９のいずれか一つに記載のイベント支援装置。
11. 前記制御部は、ワークフロー管理システムに更に接続され、
    前記制御部が、前記ワークフロー管理システムとの間で、承認経路及び承認状況を共有することを特徴とする請求項４〜１０のいずれか一つに記載のイベント支援装置。
12. 前記制御部が、
    前記管理対象イベントにおける推奨参加者を特定し、
    前記管理対象イベントにおいて推奨参加者が登録されていない場合には、注意喚起を出力することを特徴とする請求項１〜１１のいずれか一つに記載のイベント支援装置。
13. イベントのスケジュール情報が記録されるスケジュール管理システムと、管理対象イベントに対応した各種処理を実行する複数のサービス管理システムとに接続された制御部を備えたイベント支援装置を用いて、イベント支援を行なう方法であって、
    前記制御部が、
    前記スケジュール管理システムに記録されたスケジュール情報におけるイベントの参加者に基づいて、管理すべき管理対象イベントを特定し、前記管理対象イベントに対応した各種処理を実行させるために、前記各サービス管理システムに対して、前記管理対象イベ
    ントに基づいた通知を行ない、
    前記各サービス管理システムから、前記イベントの参加者に関する管理対象イベントに係る状況変化情報を取得し、
    前記状況変化情報に応じて、前記イベントの参加者の状態を特定し、前記状況変化情報に基づいて判断した前記管理対象イベントのステータス及び前記参加者の状態に応じて、前記状況変化情報を取得した管理対象イベントに後続する管理対象イベントに対応した各種処理を実行させることを特徴とするイベント支援方法。
14. イベントのスケジュール情報が記録されるスケジュール管理システムと、前記スケジュール管理システムに接続された制御部、承認に係る権限者を特定するための権限者特定部を備えたイベント支援装置を用いて、イベント支援を行なう方法であって、
    前記制御部が、イベント属性に応じて承認経路を決定する承認経路管理部を更に備え、
    前記制御部が、前記スケジュール情報において新たに登録された管理対象イベントのイベント属性に基づいて、前記承認経路管理部から承認経路を取得し、
    前記特定した複数の承認経路において、前記権限者特定部を用いて、前記イベント属性に応じた承認に係る権限者を特定し、共通した実行権限者を特定し、承認ルールに反しておらず、共通した実行権限者を設定可能な場合には、実行権限者を統合した承認経路を生成することを特徴とするイベント支援方法。

Images