WO2017068803A1 - イベント管理システム - Google Patents

Abstract

管理対象外の機器等についても監視対象とすることができ、ビジネス・イベントを能動的に検知して対応するアクションを提示するイベント管理システムである。イベント・コンテクストＤＢと、アクション・パターンＤＢと、監視対象からデータを取得し、取得したデータとイベント・コンテクストにおける検知基準とに基づいて第１のイベントの発生を検知して出力するイベント検知部と、イベント検知部により出力されたイベントに対応するアクション・パターンをアクション・パターンＤＢから取得して出力するアクション提供部とを有する。イベント検知部は、アクション提供部において第１のイベントに対応するアクション・パターンを取得できなかった場合に、第１のイベントに係るイベント・コンテクストの情報に基づいて、類似する第２のイベントを特定して出力する。

Description

イベント管理システム

　本発明は、イベントに対応するアクションを管理する技術に関し、特に、ビジネス・イベントも含む多様なイベントを管理するイベント管理システムに適用して有効な技術に関するものである。

　各種のビジネスにおいて、監視対象に生じる様々な業務上の事象（イベント）に対して、その内容に応じた適切な対応（アクション）をとることが行われている。その際、例えば、業務に習熟していない担当者も含めて統一的かつ迅速な対応を可能とするため、生じ得ると想定されるイベントに対してとるべきアクションを予め定義しておき、生じたイベントに対応するアクションを速やかに担当者に提示する、もしくは可能な場合は自動実行することが行われている。

　イベントには、例えば、監視対象の機器に発生した障害や、各種センサにより測定した値の閾値超過等の物理的・客観的な事象に加えて、顧客からのクレームや引き合い、売上げの減少等の業務的・主観的な事象も広く含まれ得る（以下では、このような業務上何らかの対応することが必要なイベントを「ビジネス・イベント」と記載する場合がある）。イベントの発生は、機械的・電気的に検知して通知される場合もあれば、発生を検知したオペレータ等が業務担当者等に電話や電子メール等で連絡するような場合もある。イベントの発生を検知・把握すると、対象のイベントに対応するものとして予め設定されているアクションを自動／手動により実行する。もしくは、監視対象に発生したイベントを解析して、適切な対応を判断して実行する。

　イベントを検知して対応するアクションを実行することに関する技術として、例えば、特開２０００－１４８５３８号公報（特許文献１）には、「コンピュータ障害に対して当該コンピュータに自律的な復旧処理を実行させるためのジョブを障害別に保持しておき、例えば公衆通信回線を通じて、所定のコンピュータから障害通知を受信したときに当該障害の種別を判定して該当するジョブを抽出し、抽出したジョブを当該コンピュータへ送出する」旨が記載されている。

特開２０００－１４８５３８号公報

　特許文献１に記載されている技術では、障害が生じた監視対象を障害の内容に応じて自律的に復旧させることができる。しかし、障害通知を受信することでイベントの発生を受動的に検知しているにすぎないため、監視対象から障害が通知されなければ監視対象に発生したイベントを検知することはない。したがって、イベントが発生した場合にこれを所定のプロトコル等によって授受することが予め想定されているような閉じた環境（監視対象が管理されている環境）では有効である。

　しかし、例えば、開いた環境における管理対象外の機器等において生じたイベントを能動的に監視して検知することは想定されていない。近年のＩｏＴ（Internet of Things）技術の進展により、このような管理対象外の機器等は急速に増える状況にあり、これらを監視対象としたいというニーズもある。そして、このような管理対象外の機器等から検知し得るイベントは、新規のイベントである場合が多いことが想定され、予め対応するアクションを定義・設定しておくことが困難である。

　そこで本発明の目的は、管理対象外の機器等についても監視対象とすることができ、業務上対応が必要なビジネス・イベントを能動的に検知して対応するアクションを提示することを可能とするイベント管理システムを提供することにある。

　本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

　本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

　本発明の代表的な実施の形態によるイベント管理システムは、監視対象におけるイベントの発生を検知し、検知したイベントに対応する、一連のアクションからなるアクション・パターンに係る情報を出力するイベント管理システムであって、イベントの検知基準の情報を含むイベント・コンテクストを保持するイベント・コンテクスト記録部と、前記アクション・パターンに係る情報を保持するアクション・パターン記録部と、を有する。

　また、監視対象からデータを取得し、取得したデータと、前記イベント・コンテクストにおける前記検知基準とに基づいて、第１のイベントの発生を検知して出力するイベント検知部と、前記イベント検知部により出力されたイベントに対応する１つ以上の前記アクション・パターンを前記アクション・パターン記録部から取得して出力するアクション提供部と、を有する。そして、前記イベント検知部は、前記アクション提供部において前記第１のイベントに対応する前記アクション・パターンを取得できなかった場合に、前記第１のイベントに係る前記イベント・コンテクストの情報に基づいて、前記第１のイベントに類似する第２のイベントを特定して出力するものである。

　本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

　すなわち、本発明の代表的な実施の形態によれば、管理対象外の機器等についても監視対象とすることができ、業務上対応が必要なビジネス・イベントを能動的に検知して対応するアクションを提示することを可能となる。

本発明の一実施の形態であるイベント管理システムの構成例について概要を示した図である。 本発明の一実施の形態におけるイベント・コンテクストの例について概要を示した図である。 本発明の一実施の形態におけるアクション・パターンの例について概要を示した図である。 本発明の一実施の形態におけるアクション・パターンの他の例について概要を示した図である。 本発明の一実施の形態におけるアクション・パターンに評価情報を対応付けた例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態におけるユーザ端末のディスプレイに表示される画面例について概要を示す図である。 本発明の一実施の形態におけるイベントの検知からアクション・パターンの提示、実行に係る一連の処理の流れの例について概要を示した図である。

　以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

　＜システム構成＞
　図１は、本発明の一実施の形態であるイベント管理システムの構成例について概要を示した図である。イベント管理システム１は、後述する監視対象２０において発生したイベントを検知し、対応するアクションをユーザ端末４０に対して提示する、もしくは可能な場合には自動実行するというイベント管理サービスを実現する情報処理システムである。イベント管理システム１は、例えば、イベント管理装置１０、およびこれとネットワークを介して接続可能な監視対象２０、データ蓄積サーバ３０、およびユーザ端末４０を有する。

　監視対象２０は、イベント管理装置１０がイベントの発生の有無を監視する対象の機器等である。これらの機器等は、イベントの発生を判断することができるデータを自ら生成もしくは出力することができるものである。例えば、情報処理システムを構成する各サーバやネットワーク機器、工場内に設置された各種設備や機器、各種の電気・電子機器等が該当する。このような直接にイベントの検知対象となる機器に限らず、例えば、コールセンターに設置された端末や、工場内に設置された機器の状態を定期的にチェックする端末等、ビジネスの遂行状況やビジネス上の事象を監視・管理しており、間接的にビジネス・イベントの発生を検知するための対象となる機器等も含まれ得る。

　監視対象２０には、イベント管理システム１によって監視するものとして把握されている機器等である管理対象２１と、把握されていない（すなわち新規の）機器等である管理対象外２２とが含まれる。管理対象外２２の機器等には、例えば、ＩｏＴ技術を利用することでネットワークに接続可能とされた各種の機器や裝置等も含まれ得る。本実施の形態のイベント管理システム１は、管理対象外２２の機器等についても、能動的にデータを取得・収集してイベントの発生を検知することが可能である。

　また、監視対象２０には、機器に限らず、例えば、販売管理システムや営業管理ステム、在庫管理システム等、業務の遂行に用いられる外部の情報処理システム等からなる外部システム２３も含まれ得る。これらの外部システム２３は、それ自身において図示しない各種の業務データを保持している。業務データには、例えば、担当者毎の営業成績等を示す営業データや、商品毎の在庫数等を示す在庫データ、ソーシャルメディアにおいて参加者が書き込むコメント等のソーシャルメディアデータ、ＥＣ（Electronic Commerce）サイトやブログ等において蓄積される購入履歴等のウェブサイトデータ等、各種のデータが広く含まれ得る。

　また、ＧＰＳ（Global Positioning System）やＩＣカード、ＲＦＩＤ（Radio Frequency IDentifier）等によって検知される位置情報や乗車履歴、温度や加速度等の各種のセンサデータ、販売管理等の業務システムにおいて生成されるＰＯＳ（Point Of Sale）データや取引明細データ等のオペレーションデータ等も含まれ得る。また、ウェブサーバにおいて自動的に生成されるアクセスログやエラーログ等のログデータや、ＣＲＭ（Customer Relationship Management）システムにおいて管理されるダイレクトメール等の販促データや会員カードデータ等のカスタマデータ等も含まれ得る。

　データ蓄積サーバ３０は、外部システム２３において記録されている上記のような各種の業務データを取得し、取得したデータをデータ蓄積部３１に一元的に記録する。外部システム２３から取得したデータに加えて、もしくはこれに代えて、データ蓄積サーバ３０が自ら検出したデータや、自らが入力を受け付けたデータをデータ蓄積部３１に記録してもよい。これにより、イベント管理装置１０は、各外部システム２３から個別にデータを取得・収集するのに代えて、データ蓄積サーバ３０から一括してデータを取得することができる。なお、図１の例では、データ蓄積サーバ３０は、イベント管理装置１０とは別の独立した裝置として記載されているが、イベント管理装置１０と同一の裝置として構成されていてもよい。

　イベント管理装置１０は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ、もしくはＰＣ（Personal Computer）等の情報処理裝置により構成される。そして、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェア上で稼働するソフトウェアとして実装されたイベント検知部１１、アクション提供部１２、およびデータ更新部１３等の各部を有する。また、データベース等として実装されたデータ収集条件ＤＢ１４、イベント・コンテクストＤＢ１５、およびアクション・パターンＤＢ１６等の各データストアを有する。

　データ収集条件ＤＢ１４には、イベント管理裝置１０のイベント検知部１１がどのようなデータを取得・収集するのかの判断基準を定義するデータ収集条件が記録されている。さらに、データ蓄積サーバ３０がどのようなデータを取得・収集するのかの判断基準が含まれていてもよい。データ収集条件には、例えば、データの取得先である監視対象２０の各機器や外部システム２３、データ蓄積サーバ３０等を識別するためのＩＤや番号等の識別情報や、取得するデータを特定もしくは検索するための検索キー等の情報が含まれ得る。識別情報は、監視対象２０の各機器や外部システム２３、データ蓄積サーバ３０毎に割り振られた情報であればよく、例えば、ＭＡＣアドレスやＩＰアドレスであってもよい。

　イベント検知部１１は、データ収集条件ＤＢ１４に定義されているデータ収集条件に基づいてデータを取得・収集し、その内容に基づいて業務上対応することが必要なイベントの発生を検知して出力する機能を有する。ここで検知するイベントはビジネス・イベントであり、例えば、監視対象２０の機器に発生した障害や、各種センサにより測定した値の閾値超過等の物理的・客観的な事象に加えて、顧客からのクレームや引き合い、売上げの減少等の業務的・主観的な事象も広く含まれ得る。

　すなわち、検知するイベントには、例えば、顧客からの引き合い等のビジネスチャンスに関する積極的なもの、および顧客からのクレームや監視対象２０にて発生した障害等に関する消極的なものが含まれる。また、例えば、コールセンターへの問合せ等、可及的に速やかに検知して対応する必要があるヒューマンイベントや、工場の生産ラインのロボットやこれを監視する機器、駐輪場の清算機等の監視対象２０の機器から定期的に送信される情報に基づいて自動的に検知する機器イベント等が含まれる。ヒューマンイベントは、例えば、クレームや問合せの内容について、監視対象２０の一例であるコールセンターの端末が入力を受け付けた文字情報により特定することができる。上述したように、監視対象２０の各機器が自ら機器イベントを送信してもよい。

　本実施の形態では、上記のような各種のビジネス・イベントの発生を自動的に検知可能とするため、ビジネス遂行上発生したデータをどのような視点からどのように解釈するかという「ビュー」を設定し、これをイベントに関連付けた「イベント・コンテクスト」を定義する。各イベント・コンテクストは、検知すべき各イベントに対応した検知基準や検知条件の内容を保持する。複数のイベント・コンテクストを１つのイベントに関連付けることも可能である。定義されたイベント・コンテクストおよびイベントの情報は、イベント・コンテクストＤＢ１５に記録される。イベント・コンテクストの詳細な内容については後述する。

　アクション提供部１２は、イベント検知部１１により検知されて出力されたイベントに対応するアクション・パターンをアクション・パターンＤＢ１６から取得し、ユーザ端末４０に送信してユーザに提示する機能を有する。アクション・パターンとは、イベントに対応するための１つ以上の特定のアクションの種類・内容やその実行順を指す。例えば、同一の顧客から同日に複数回のクレームがあったことを示すヒューマンイベントが検知された場合、アクション提供部１２は、顧客からのクレームを上司にエスカレーションさせるための１つ以上のアクション・パターンをアクション・パターンＤＢ１６から取得する。取得したアクション・パターンは、取るべき一連のアクションの候補として、ユーザ端末４０に送信されてユーザに提示され、ユーザはその内容に従ってアクションを実行する。アクション・パターンの詳細な内容についても後述する。

　アクション・パターンについての複数の候補をユーザ端末４０へ提示する際、アクション提供部１２は、過去に対象の各アクション・パターンが実行された際の結果に基づいて各アクション・パターンをソートして、一覧表示させる画面データを生成するようにしてもよい。例えば、過去に対象のアクション・パターンが実行された際にユーザにより入力された評価点や、アクション・パターンの実行に要した時間、コスト等の項目のうち１つ以上の項目に基づいてアクション・パターンを優先順位付けすることができる。なお、アクション・パターンの各アクションはユーザにより実行されるが、可能な場合にはイベント管理装置１０自身や他のシステム、機器等が自動的にアクション・パターンの全部もしくは一部のアクションを実行してもよい。

　アクション・パターンＤＢ１６には、検知し得る各イベント毎に、後述するような複数のアクションの組み合わせにより構成されるアクション・パターンが予め記録されている。各アクション・パターンは、例えば、ユーザ端末４０等を介して、イベント管理装置１０がアクションの種類・内容や実行順等の情報の入力を受け付けることで生成される。

　一方で、イベント検知部１１で検知されたイベントが新規のイベントである場合には、アクション・パターンＤＢ１６に対応するアクション・パターンが登録されていないという状況が生じ得る。例えば、管理対象外２２の機器等におけるイベントや、管理対象２１に新たに導入された機器等におけるイベントは、新規のイベントとなる場合がある。このような場合、従来技術では、対応するアクション・パターンが登録されていない以上、アクション・パターンを提示することはできない。

　これに対し、本実施の形態のイベント管理システム１では、検知した新規のイベントに対して、これと近似・類似する既存のイベントを特定し、この既存のイベントに対応するアクション・パターンを提示することでアクション・パターンをリコメンデーションする。すなわち、イベント・コンテクストＤＢ１５に新規のイベントの検知条件（例えば、対象において想定される一般的・抽象的なイベント）についても登録しておき、当該イベントが発生した際に、その検知内容と既存の具体的なイベントの検知条件とをパターンマッチングすることで、類似する既存のイベントを特定する。

　例えば、イベント検知部１１は、検知した新規のイベントに対して、イベントの発生元や、イベントの種別（ビジネスチャンスに関するものや、障害に関するもの、ヒューマンイベント、機器イベント等）、発生回数、値の上昇率等の項目のいずれか１つ以上が一致または類似する既存のイベントを、類似するイベントとして特定する。なお、パターンマッチングの手法は特に限定されず、公知の手法も含む適当な手法を適宜採用することができる。

　そして、アクション提供部１２は、特定された既存のイベントの検知条件等の情報をイベント・コンテクストＤＢ１５から抽出し、また、対応するアクション・パターンに係る内容や評価点、実行時間、コスト（例えば、金額に換算したもの）等の情報をアクション・パターンＤＢ１６から抽出する。そして、これらの情報をユーザ端末４０等に送信して提示する。これにより、新規のイベントに類似している既存のイベントの内容、およびこれに対応するアクション・パターンの情報をユーザに提示して、ユーザが何らかのアクションを実行可能とすることができる。また、ユーザが新規のイベントに対するアクション・パターンを作成・定義するのに有用な補助情報を提供することができる。

　データ更新部１３は、イベント管理装置１０において記録・保持するデータの更新に係る機能を有する。例えば、アクション・パターンが実行された結果としてユーザにより入力された評点である評価点と、アクション・パターンを実行するのに要した時間、およびコスト等の項目のいずれか一つ以上（以下では「評価情報」と記載する場合がある）と、実行されたアクション・パターンとを対応付けて、アクション・パターンＤＢ１６に記録する。ユーザにより入力された評価情報の値に代えて、イベント管理裝置１０やユーザ端末４０が所定の基準等に基づいて算出した値をアクション・パターンＤＢ１６に記録するようにしてもよい。

　データ更新部１３は、さらに、後述するユーザ端末４０を介してユーザにより入力・設定された、イベントの検知条件等のイベント・コンテクストに係る情報や、アクション・パターンの設定・定義に係る情報をユーザ端末４０から受信し、イベント・コンテクストＤＢ１５やアクション・パターンＤＢ１６に記録する機能も有する。

　ユーザ端末４０は、イベントを管理するユーザ、すなわち、発生したイベントに対応してアクションを実行するユーザが使用するＰＣ（Personal Computer）等の情報処理端末である。具体的には、例えば、駐輪場を管理する管理会社に設置されている管理用の端末等が該当する。

　ユーザは、イベント管理裝置１０から送信されたアクション・パターン（もしくは送信されたアクション・パターンの候補からユーザが選択したもの）に含まれる各アクションを、アクション・パターンに設定された順序に従って実行する。ユーザは、ユーザ端末４０を使用してアクションを実行してもよいし、イベント管理システム１の外部にて手動で実行し、結果に係る情報のみ入力するようにしてもよい。可能な場合には、イベントの検知をトリガーとしてイベント管理装置１０もしくは他のシステム等に自動的にアクションを実行させ、その結果をユーザ端末４０を介して把握する構成としてもよい。

　ユーザ端末４０は、ユーザ等がアクション・パターンを実行した後に、ユーザからアクション・パターンに対する評価情報の入力を受け付ける。そして、実行したアクション・パターンと、入力を受け付けた評価情報とを対応付けて、イベント管理裝置１０へ送信する。アクション・パターン毎ではなくその中の個別のアクション毎に評価情報の入力を受け付けるようにすることも可能である。また、ユーザ端末４０は、上述したように、イベント・コンテクストやアクション・パターンの設定・定義に係る情報の入力を受け付けて、これらをイベント管理装置１０へ送信する。

　＜イベント・コンテクスト＞
　図２は、イベント・コンテクストの例について概要を示した図である。「ビュー」の項目はデータの解釈の視点を示しており、「データ・タイプ」の項目は、解釈の際に取り扱うデータのタイプを示している。また、「検知基準」の項目は、イベントの発生を検知する基準を示している。図中では説明の便宜上概念的な文言で示しているが、実際には数値や数式等、システム的に判定可能な基準により定義される。閾値との比較等、簡単なイベント・コンテクストもあれば、データ・パターンや統計値との比較等、複雑な検知基準となるものもある。「イベント」の項目には検知するビジネス・イベントの例を示している。図示するように、あるビューによって検知するイベントは複数あり得る一方、上述したように、１つのイベントに複数のイベント・コンテクスト（ビュー）が関連付けられる場合もある。

　イベント検知部１１は、例えば、受動的なデータの取得手法として、外部のイベントリソースである監視対象２０の機器から送信されるデータを受信する。もしくは、能動的なデータの取得手法として、例えば、監視対象２０の機器（特に管理対象外２２の機器）や外部システム２３、データ蓄積サーバ３０等に対して、定期・不定期にアクセスしてデータを取得・収集する。

　そして、取得したデータについてイベント・コンテクストＤＢ１５に記録されている各イベントの検知基準を参照し、検知基準を満たしているか否かを判定することで、イベントの発生を検知する。具体的には、例えば、監視対象２０の機器であるロボットが故障したことを示すアラートがイベント管理裝置１０に送信された場合、イベント検知部１１は、これを受信して、ロボットが故障した旨のイベントを受動的に検知する。電流値や電圧値が送信された場合には、これらが所定の閾値を超えた（もしくは下回った）場合に故障したと能動的に判定することも可能である。

　取得したデータ１つ１つに基づく検知に限らず、取得した複数個のデータに基づいてイベントの発生を検知するようにしてもよい。複数個のデータは、１回の取得で収集した同種の複数個のデータであってもよいし、時系列上の複数回の取得で収集したデータであってもよい。例えば、イベント検知部１１は、監視対象２０等から取得した複数個のデータの遷移の傾向（増加や減少、変化率等）や統計的な特徴（平均値や標準偏差等）等に基づいてイベントの発生を検知する。

　具体的には、例えば、顧客からクレームがあったことを示すヒューマンイベントが、コールセンターから１日に所定の回数以上送信された場合に、製品のリコールが発生したこと（もしくはリコールすべきこと）を示すイベントを検知する。また、例えば、データ（センサ等による測定値）が３回連続で所定の閾値を超えている場合に、機器に障害が発生したことを示すイベントを検知する。また、月間の利益率が３ヶ月連続で下落している場合に、財務状況が悪化していることを示すイベントを検知する。また、１０個中３個以上の商品のデータが不良品であることを示す閾値を超えている場合は、商品の品質管理体制が悪化していることを示すイベントを検知する。

　＜アクション・パターン＞
　アクションは、ビジネス活動そのものを表現するものであり、様々な内容を定義することができる。イベントへの対応としてアクションは必須の要素であり、適切なアクションを設定することが望ましい。一方で、例えば、管理対象外２２の機器等におけるイベントや、管理対象２１に新たに導入された機器等におけるイベントは、過去にアクションの実行の経験がない新規のイベントとなる場合がある。この場合、イベントとしては予め定義できるものの、どのようなアクションが最適であるかを予め定義しておくことは困難な場合がある。

　そこで本実施の形態では、ビジネスの遂行の過程で、アクションを適宜追加・変更・削除して、イベントに対応するアクションを漸次最適化していくことを可能とする。そのための仕組みとして「アクション・パターン」を用いる。

　図３は、アクション・パターンの例について概要を示した図である。図３では、「定期検査」および「修理」という各イベントにおけるアクション・パターンの例を示している。アクション・パターンは、例えば、「作業」、「対象」、「値」、「割当」、「期限」、「完了日時」、「状況」、「参照」、および「成果物」等の項目を有し、これらの内容はアクション・パターンＤＢ１６に記録される。

　「作業」の項目は、各アクションで行う行為の内容を特定する名称やコード値等を保持する。例えば、「入力」、「調査」、「測定」、「作成」、「送付」、「起動」等、ユーザがビジネス活動として行う行為や作業が含まれ得る。「対象」の項目は、各アクションが対象とする事物を示す名称等を保持する。例えば、「データ」、「機器」、「設備」、「長さ」、「報告」、「メール」、「システム」等の各種のものが含まれ得る。アクションの「対象」の多くは、イベントが対象とする事物の一部であったり、その属性であったりする。「値」の項目は、対象のアクションの結果として生じた、もしくは取得した何らかの値を保持する。この値は、「作業」や「対象」の項目の内容に応じて数値やテキスト、名称、状態等の属性の値により表現される。

　「割当」の項目は、対象のアクションの実行が割り当てられた人や組織、役割等を特定する名称やＩＤ等の識別情報、コード値等を保持する。「期限」および「完了日時」の各項目は、それぞれ、対象のアクションの実施期限および実際の完了の日時の情報を保持する。「状況」の項目は、アクションの実行結果を示すテキストやコード値等の情報を保持する。通常は「ＯＫ」もしくは「ＮＧ」により示されるが、「実施中」や「完了」のように進捗状況を表すようにしてもよい。進捗自体がアクションにとって重要な意味を持つ場合には、アクション・パターンに別途「進捗」という項目を設けるようにしてもよい。

　「参照」の項目は、対象のアクションを実行する上で必要となるデータやドキュメント等の参照情報を特定する情報を保持する。例えば、「検査マニュアル」や「操作マニュアル」、「設計図」等のデータやドキュメントが含まれ得る。先行するアクションにおける報告等（例えば、後述の「成果物」）もこれに該当する場合がある。また、ユーザ等による何らかの入力情報もこれに該当する場合がある。

　「成果物」の項目は、対象のアクションの実行結果として作成されたデータやドキュメント等の成果物を特定する情報を保持する。例えば、「検査報告」、「調査報告」、「要対応顧客リスト」等のデータやドキュメントが含まれ得る。上記の「値」の項目のデータも、アクションの実行結果として作成されるものであるが、この「値」の項目は数値やテキストとして集約化、代表化されているのに対し、「成果物」の項目は各種のドキュメントや報告書等、アクションの結果の詳細内容を示すものとして、「値」の項目と併せて用いられる。

　図３の例では、「定期検査」イベントは、例えば、「オイルレベル」の「検査」、「回転数」の「測定」、「電圧」の「測定」、「電流」の「測定」、「イベント」の「導出」という一連のアクションにより構成されることを示している。そして、現時点では最後の「イベント」の「導出」のアクションまで全て完了していることを示している。また、「電流」の「測定」のアクションにおいて測定された「値」が適切ではなかった（「状況」が「ＮＧ」である）ために、「イベント」の「導出」のアクションにより、後続の「修理」イベントが新たに導出されたことを示している。

　この「修理」イベントは、例えば、「部品表」の「作成」、「部品」の「発注」、「出荷日」の「応答」、「部品」の「出荷」、「部品」の「受領」、「修理作業」の「手配」、「修理作業」の「作業」という一連のアクションにより構成されることを示している。そして、現時点で「部品」の「出荷」のアクションまで完了しており、「部品」の「受領」のアクションの実行中（すなわち修理のための部品の納入待ち）であることを示している。

　同様に、図４は、アクション・パターンの他の例について概要を示した図である。図４では、「クレーム増加」および「製品リコール」という各イベントにおけるアクション・パターンの例を示している。「クレーム増加」イベントは、例えば、「クレーム」の「調査」、「イベント」の「導出」という一連のアクションにより構成され、現時点では最後の「イベント」の「導出」のアクションまで全て完了していることを示している。そして、クレームの内容から製品に欠陥があることが明らかになったために、「イベント」の「導出」のアクションにより、後続の「製品リコール」イベントが新たに導出されたことを示している。

　この「製品リコール」イベントは、例えば、「対象製品リスト」の「作成」、「対象顧客リスト」の「作成」、「製品リコール」の「通知」、「製品」の「リコール実施」、「回収状況」の「報告」という一連のアクションにより構成されることを示している。そして、現時点で「対象製品リスト」の「作成」のアクションまで完了しており、「対象顧客リスト」の「作成」のアクションの実行中であることを示している。

　図３や図４に示したアクション・パターンの例は、含まれる一連のアクションを順に実行していくという単純なものである。しかし、実際にはビジネスの状況に応じてアクションの実行方法には様々なものがある。そこでこれらの実行方法を管理するため、各アクションに対して実行条件を定義できるようにしてもよい。実行条件には、例えば、対象のアクションの実行が必須かオプションか、対象のアクションを順序通り実行する必要があるか否か、対象のアクションを実行するための前提条件の有無、対象のアクションの実行が他のアクションの実行結果に依存するか否か等の内容が含まれる。これらの実行条件を組み合わせることで、ビジネス・ニーズに合致するように一連のアクション（ワークフロー）の実行方法を定義・管理することができる。

　＜アクション・リコメンデーション＞
　図３や図４に示したアクション・パターンの例は、基本的にイベントの定義時に予めアクションの内容も固定的に定義しておくことができるものである。しかし、現実のビジネスでは、イベントに対するアクション・パターンの候補が複数存在し、いずれを選択するかを容易には決定できない場合も多く生じ得る。特に、新規のイベントを定義する場合には、いずれのアクション・パターンが最適かその時点では不明であるため、複数のアクション・パターンが候補となるよう定義されることになる。また、内容によっては、アクション・パターン自体が、イベントの起きた日時や場所、対象物等に合わせて柔軟に対応できるものであることが必要となる場合もある。

　このような観点から、アクション・パターンは、「事前定義」アクション・パターンと、「動的」アクション・パターンの２つに分類される。「事前定義」アクション・パターンとは、実行すべきアクションとその実行順序を予め固定的に決めておくことができるものであり、例えば、上述の図３、図４等の例に示したようなものが含まれる。

　一方、「動的」アクション・パターンとは、イベントの状況に合わせてユーザが適切なアクションを適宜選択することができるものである。ここでは、例えば、上記の「事前定義」アクション・パターンの場合と同様に、デフォルト設定として予め定められたアクションとその実行順序をそのまま用いることもできる。

　さらに、これに加えて、ユーザが当該アクション・パターンを継続的に用いる過程で、アクションの追加・削除・変更等により最適なアクション・パターンを漸次形成していき、最終的に「事前定義」アクション・パターンとして定着したアクション・パターンとすることもできる。すなわち、「動的」アクション・パターンは、繰り返し実行される過程で学習により最適なアクション・パターンを迅速に形成することができるものである。アクション・パターンの最適化は、ユーザが行うことも可能である一方、アクションの実行結果について蓄積されたデータ等を利用して、ディープラーニング等の公知の機械学習の手法を用いてシステム的に行うことも可能である。

　特定のイベントの内容に対して最適なアクション・パターンを形成していくのに加えて、例えば、イベントの発生日時や発生場所、対象の事物等のイベントの内容・特性に応じて、それぞれ異なる最適なアクション・パターンを形成していくことも可能である。これは、対応するアクション・パターンが予め定義されていない新規のイベントであっても、その内容や特性が類似するイベントを判定し、これに対応するアクション・パターンを候補として提示（リコメンデーション）することができることを意味する。すなわち、新規のイベントであっても、類似するイベントを介して間接的にアクション・パターンを提示することが可能である。

　イベントは上述したように、データを取得・収集してイベントの発生の有無を検知するイベント・コンテクストによって特徴づけられる。したがって、あるイベントは、イベント・コンテクストという観点で他のイベントと類似している場合があり得る。すなわち、新規のイベントについても、当該イベントのイベント・コンテクストと同様もしくは類似するイベント・コンテクストを有するイベントは類似したイベントであるということができる。類似するイベント同士は、当然ながら類似したアクション・パターンを有する（もしくは類似したアクション・パターンが好適である）ことが想定される。したがって、新規のイベントに対しても、これと類似する既存のイベントに基づいてアクション・パターンを提示することができることになる。これは、多数の種類のイベントを取り扱うことになる場合には特に時間的・経済的コストを大幅に削減することを可能とするものである。

　上述したように、イベント（イベント・コンテクスト）が類似しているか否かの判定には、例えば、イベント・コンテクスト同士のパターンマッチングを行うが、類似しているか否かの判定の手法は特に限定されない。例えば、図２に示したイベント・コンテクストの例において、「ビュー」、「データ・タイプ」、「検知基準」が同じである複数のイベントは、類似しているとして取り扱ってもよい。また、さらに検知基準の詳細な内容や値が類似・近似しているか否かを考慮要素に加えるようにしてもよい。

　また、上述したように、本実施の形態では、アクション・パターンがユーザ等により実行された結果として、ユーザから評価点や実行に要した時間、コスト等の評価情報の入力を受け付けて、これをアクション・パターンに対応付けてアクション・パターンＤＢ１６に記録する。この評価情報は、イベントに対して複数のアクション・パターンが候補として抽出され、これらをユーザに提示（リコメンデーション）する際に、アクション・パターン間の優先順位を設定するために用いることができる。

　図５は、アクション・パターンに評価情報を対応付けた例について概要を示した図である。基本的な内容は図３に示したアクション・パターンの内容と同様であるが、ここでは、イベントに対する一連のアクションからなる各アクション・パターンを特定するための「識別番号」の項目と、個別の各アクションの「実行順序」を示す項目とを有している例を示している。また、各アクション・パターンに対して、「評価点」、「時間」、「コスト」の各評価情報の値をそれぞれ保持する項目を有している。これらの評価情報の値に基づいて、各アクション・パターンの優先順位を設定することができる。なお、図５の例では、アクション・パターン毎に評価情報の値を設定する例を示しているが、上述したように、個別のアクション毎に評価情報を設定できるようにしてもよい。

　＜画面例＞
　図６は、ユーザ端末４０のディスプレイに表示される画面例について概要を示す図である。図３（ａ）は、検知したイベントに対してユーザにアクション・パターンの候補を提示する一覧表示画面の例を示している。図３（ａ）の例では、各アクション・パターンの候補について、それぞれ、アクション・パターン名と識別番号に加えて、評価点、時間、コストの各評価情報の値が対応付けて一覧表示されている。また、評価点ボタン４１、時間ボタン４２、コストボタン４３の各ボタンが表示されている。

　ユーザが評価点ボタン４１を押下すると、評価点の降順でアクション・パターンの候補がソートされて一覧表示される。同様に、ユーザが時間ボタン４２を押下すると、時間の降順でソートされて一覧表示される。また、ユーザがコストボタン４３を押下すると、コストの降順でソートされて一覧表示される。ユーザが特定のアクション・パターンの行やセルを選択・押下すると、図３（ｂ）に示すようなアクション確認画面が表示される。図３（ｂ）の例では、対象のアクション・パターンについて、各アクションの名称や内容、対象等の情報が、アクションの実行される順序に従って降順に一覧表示されている。ユーザは、この内容を確認して、イベントに対するアクションを実行することができる。

　これらの画面に加えて、例えば、実行中のアクション・パターンの状況管理を可能とするため、図３や図４の例に示したようなアクション・パターンの内容を適宜参照できる画面を有していてもよい。

　＜処理の流れ＞
　図７は、イベントの検知からアクション・パターンの提示、実行に係る一連の処理の流れの例について概要を示した図である。処理を開始すると、まず、イベント管理装置１０は、イベント検知部１１によってデータ収集条件ＤＢ１４からデータ収集条件の情報を取得する（Ｓ０１）。データ収集条件は、上述したように、イベント検知部１１がどのようなデータを取得・収集するのかの判断基準を定義したものである。データ収集条件には、例えば、データの取得先を識別するための識別情報や、取得するデータを特定もしくは検索するための検索キー等の情報が含まれ得る。取得したデータ収集条件の情報は、監視対象２０の各機器やデータ蓄積サーバ３０がその内容に基づいて自らデータを取得してイベント管理装置１０に応答することができる場合には、これらの機器に送信される。

　その後、監視対象２０の各機器やデータ蓄積サーバ３０では、イベント管理装置１０から送信されたデータ収集条件の情報に基づいて、自らが保持するデータを検索し、対応するデータを取得して、イベント管理装置１０に送信する（Ｓ０２）。各機器がデータを保持し、これを取得する手法はそれぞれ異なり得る。例えば、データ蓄積サーバ３０は、自らが外部システム２３等から取得・収集したデータをデータ蓄積部３１に記憶しておき、ここからデータ収集条件に合致するデータを取得することができる。

　データの取得・収集のタイミングは、上記のように、データ収集条件のデータを監視対象２０やデータ蓄積サーバ３０が受信したタイミングに同期して行うものに限らない。例えば、データ収集条件が監視対象２０の機器等に予め送信・記録されており、これに基づいて各機器が個別に定期的に検索を行い、合致するデータが存在した時点でそれをイベント管理装置１０に非同期で送信するようにしてもよい。また、上記のようにデータ収集条件の情報を各機器等に送信し、その内容に基づいて各機器等がデータを取得するものに限らず、イベント管理装置１０（イベント検知部１１）が、管理対象外２２のものも含む各機器等のデータ入出力インタフェースにアクセスしてデータを直接取得・収集するような構成とすることも可能である。

　その後、監視対象２０やデータ蓄積サーバ３０からデータを取得・収集したイベント管理装置１０では、イベント検知部１１が、イベント・コンテクストＤＢ１５から、対応するイベント・コンテクストにおけるイベントの検知基準の情報を取得する（Ｓ０３）。例えば、ステップＳ０１で取得したデータ収集条件に割り当てられた識別番号等をキーとして、対応するイベント・コンテクストを特定する。

　次に、イベント検知部１１は、ステップＳ０２において取得されたデータと、ステップＳ０３にて取得したイベント・コンテクスト（イベントの検知基準）とに基づいて、イベント発生の有無を判定する（Ｓ０４）。イベントが発生していないと判定された場合（Ｓ０４－Ｎｏ）は、一連の処理を終了する。

　一方、ステップＳ０４でイベントが発生していると判定された場合（Ｓ０４－Ｙｅｓ）は、イベント管理装置１０のアクション提供部１２が、発生したイベントに対応するアクション・パターンをアクション・パターンＤＢ１６から取得する（Ｓ０５）。ここでは、例えば、発生したイベントの名称等をキーとして、アクション・パターンＤＢ１６を検索し、対応するもの全てをアクション・パターンの候補として取得する。そして、アクション・パターンを取得できたか否かを判定し（Ｓ０６）、取得できたと判定された場合（Ｓ０６－Ｙｅｓ）は、後述のステップＳ０８へ進む。

　一方、ステップＳ０６でアクション・パターンが取得できなかったと判定された場合（Ｓ０６－Ｎｏ）は、イベント検知部１１により、イベント・コンテクストのパターンマッチング等により、ステップＳ０４で検知したイベントと類似するイベントを１つ以上取得する（Ｓ０７）。そして、ステップＳ０５に戻って、再度アクション提供部１２によるアクション・パターンの取得の処理を繰り返す。

　その後、イベント管理装置１０のアクション提供部１２は、ステップＳ０４で検知したイベント、もしくはステップＳ０７で取得した類似イベントに対応するものとして取得したアクション・パターンの候補を、図６（ａ）に示すような一覧表示としてユーザ端末４０に提示するための画面データを生成し（Ｓ０８）、ユーザ端末４０上にアクション・パターンの候補の一覧を表示させる（Ｓ０９）。

　その後、ユーザ等によりアクション・パターンに設定された各アクションの実行が行われると（Ｓ１０）、ユーザ端末４０は、各アクションの実行状況や、アクション・パターンに対する評価点、実行するのに要した時間およびコスト等の評価情報の入力を受け付ける（Ｓ１１）。これらの評価情報の全部もしくは一部について、ユーザからの入力の受け付けに代えて、ユーザ端末４０自身がその内容を所定の基準により評価・算出するようにしてもよい。ユーザにより実行されたアクション・パターン、各アクションの実行状況、アクション・パターンに対する評価情報等は、イベント管理装置１０に送信される。

　イベント管理装置１０では、データ更新部１３により、ユーザ端末４０から取得した情報について、実行されたアクション・パターンに対して、各アクションの実行状況や、アクション・パターンに対する評価情報を対応付けて、アクション・パターンＤＢ１６に記録する（Ｓ１２）。

　以上のようなイベントの検知と対応するアクション・パターンの実行に加えて、図示しないアクション・パターンの最適化のステップを有していてもよい。このステップは、定期的に行われてもよいし、評価情報の値が所定の閾値を超えた場合等、所定の条件に合致した場合に行われるようにしてもよい。アクション・パターンの最適化は、上述したように、ユーザが手動で行ってもよいし、ディープラーニング等の機械学習の技術を利用してイベント管理装置１０が自動的に行うようにしてもよい。

　＜本実施の形態の効果＞
　以上に説明した本発明の一実施の形態であるイベント管理システム１によれば、管理対象２１や管理対象外２２の機器を含む様々な監視対象２０、およびデータ蓄積サーバ３０等からデータを取得・収集して、イベントを検知するとともに、対応するアクション・パターンのレコメンデーション、およびアクション・パターンの実行結果の記録・蓄積を行うことができる。そして、記録・蓄積された内容に基づいて、手動・自動によりアクション・パターンの内容を漸次最適化していくことで、ビジネスの効率的・効果的な遂行を支援することができる。

　すなわち、監視対象２０の各機器等から取得したデータと、イベント・コンテクストＤＢ１５に設定されているイベントの検知基準の情報とに基づいて、イベント管理裝置１０のイベント検知部１１がビジネス・イベントの発生を検知する。このように、各機器等において発生が検知されたイベントの通知を受ける受動的なものに限らず、イベント管理装置１０が能動的に管理対象外２２も含む各機器等におけるイベントの発生を検知することができる。

　また、イベント管理装置１０のイベント検知部１１では、複数回に渡って取得した各データと、イベント・コンテクストとに基づいて、ビジネス・イベントの発生を検知することができ、データの傾向等に基づいてより適切にイベントの発生を検知することができる。

　また、イベント管理装置１０のアクション提供部１２では、イベント検知部１１により検知されたイベントに対応するアクション・パターンをアクション・パターンＤＢ１６から取得してユーザ端末４０へ提示することで、ユーザに対して自動でアクション・パターンを提示することができる。その際、新規のイベントであっても、これに類似するイベントを判定し、判定されたイベントに対応するアクション・パターンを候補として提示（レコメンデーション）することができる。

　また、イベント管理装置１０のデータ更新部１３では、アクション・パターンが実行された結果として入力される評価点や、アクション・パターンを実行するのに要した時間およびコストの情報の少なくとも一つ以上と、実行されたアクション・パターンとを対応付けて、アクション・パターンＤＢ１６に記録する。これらの情報は、イベント管理裝置１０におけるアクション・パターンの内容の最適化に活用することができる。

　以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

　本発明は、ビジネス・イベントも含む多様なイベントを管理するイベント管理システムに利用可能である。

１…イベント管理システム、
１０…イベント管理装置、１１…イベント検知部、１２…アクション提供部、１３…データ更新部、１４…データ収集条件ＤＢ、１５…イベント・コンテクストＤＢ、１６…アクション・パターンＤＢ、
２０…監視対象、２１…管理対象、２２…管理対象外、２３…外部システム、
３０…データ蓄積サーバ、３１…データ蓄積部、
４１…評価点ボタン、４２…時間ボタン、４３…コストボタン

Claims (4)

1. 　監視対象におけるイベントの発生を検知し、検知したイベントに対応する、一連のアクションからなるアクション・パターンに係る情報を出力するイベント管理システムであって、
   　イベントの検知基準の情報を含むイベント・コンテクストを保持するイベント・コンテクスト記録部と、
   　前記アクション・パターンに係る情報を保持するアクション・パターン記録部と、
   　監視対象からデータを取得し、取得したデータと、前記イベント・コンテクストにおける前記検知基準とに基づいて、第１のイベントの発生を検知して出力するイベント検知部と、
   　前記イベント検知部により出力されたイベントに対応する１つ以上の前記アクション・パターンを前記アクション・パターン記録部から取得して出力するアクション提供部と、を有し、
   　前記イベント検知部は、前記アクション提供部において前記第１のイベントに対応する前記アクション・パターンを取得できなかった場合に、前記第１のイベントに係る前記イベント・コンテクストの情報に基づいて、前記第１のイベントに類似する第２のイベントを特定して出力する、イベント管理システム。
2. 　請求項１に記載のイベント管理システムにおいて、
   　前記イベント検知部は、前記第１のイベントの前記イベント・コンテクストの各項目と、前記イベント・コンテクスト記録部に記録された各イベントにおける前記イベント・コンテクストの各項目とのパターンマッチングにより、前記第１のイベントに類似する前記第２のイベントを特定する、イベント管理システム。
3. 　請求項１に記載のイベント管理システムにおいて、
   　前記アクション・パターンに係る各アクションの実行結果に係る情報およびユーザによる評価情報に基づいて、前記アクション・パターンの内容を変更することが可能である、イベント管理システム。
4. 　請求項１に記載のイベント管理システムにおいて、
   　前記アクション提供部は、前記アクション・パターンに係る各アクションの実行結果に係る情報およびユーザによる評価情報に基づいて、前記アクション・パターン記録部から取得した複数の前記アクション・パターンを優先順位付けして出力する、イベント管理システム。

Images