JP2022189877A

JP2022189877A - Ｒｐａ保守支援装置

Info

Publication number: JP2022189877A
Application number: JP2022166728A
Authority: JP
Inventors: 秀夫中村; Hideo Nakamura
Original assignee: Japan Research Institute Ltd
Current assignee: Japan Research Institute Ltd
Priority date: 2018-03-09
Filing date: 2022-10-18
Publication date: 2022-12-22
Anticipated expiration: 2038-03-09
Also published as: JP2019159556A; JP7402957B2

Abstract

【課題】ロボティック・プロセス・オートメーションに基づくソフトウェアが稼働した後、比較的長い期間経過した段階で、当該ソフトウェアを再生させる又は取捨選択していくことを容易化する。
【解決手段】ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアの処理結果に基づいて、ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備える、ＲＰＡ保守支援装置が開示される。この場合、ソフトウェアの処理は、規定された情報源から情報を取得する処理を含み、出力部は、情報源を構築するアプリケーションの変更を、メンテナンス情報として出力してよい。
【選択図】図２

Description

本開示は、ＲＰＡ保守支援装置に関する。

保守管理対象のサーバにおけるハードウェア又はソフトウェアの情報を保守管理する保守管理サーバを備えた保守情報管理システムが知られている。

特開２００８－０２７１４９号公報

しかしながら、上記のような従来技術では、ＲＰＡ（ロボティック・プロセス・オートメーション）に基づくソフトウェアが稼働した後、比較的長い期間経過した段階で、当該ソフトウェアを再生させる又は取捨選択していくことが難しい。

そこで、１つの側面では、本発明は、ロボティック・プロセス・オートメーションに基づくソフトウェアが稼働した後、比較的長い期間経過した段階で、当該ソフトウェアを再生させる又は取捨選択していくことを容易化することを目的とする。

１つの側面では、ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアの処理結果に基づいて、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備え、
前記ソフトウェアの処理は、規定された情報源から情報を取得する処理を含み、
前記出力部は、前記情報源を構築するアプリケーションの変更を、前記メンテナンス情報として出力する、ＲＰＡ保守支援装置が提供される。

１つの側面では、本発明によれば、ロボティック・プロセス・オートメーションに基づくソフトウェアが稼働した後、比較的長い期間経過した段階で、当該ソフトウェアを再生させる又は取捨選択していくことを容易化できる。

ＲＰＡに係る各フェーズを示す概略図である。運用フェーズのイメージ図である。メンテナンス情報の出力例を示す図である。一実施例によるＲＰＡ保守支援システムの全体を示す概略図である。クライアントコンピュータのハードウェア構成の一例を示す図である。ＲＰＡ保守支援サーバと情報源サーバとクライアントコンピュータの機能を説明する図である。メンテナンス情報出力部により実行される処理の一例を示す概略フローチャートである。メンテナンス情報出力部により実行される処理の他の一例を示す概略フローチャートである。メンテナンス情報出力部により実行される処理の他の一例を示す概略フローチャートである。メンテナンス情報出力部により実行される処理の他の一例を示す概略フローチャートである。メンテナンス情報出力部により実行される処理の他の一例を示す概略フローチャートである。

以下、添付図面を参照しながら各実施例について詳細に説明する。
図１Ａは、ＲＰＡ（ロボティック・プロセス・オートメーション）に係る各フェーズを示す概略図である。図１Ａに示すように、ＲＰＡは、ＲＰＡに基づくソフトウェア（以下、「ＲＰＡソフトウェア」と称する）の構築フェーズと、構築フェーズで構築されたＲＰＡソフトウェアの運用フェーズとがある。以下で説明するＲＰＡ保守支援システムは、運用フェーズにおけるメンテナンス用に構成される。なお、構築フェーズでの構築方法は、任意であり、任意のＲＰＡツールが使用されてもよい。

図１Ｂは、運用フェーズのイメージ図である。図１Ｂでは、３つのＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３が模式的に示される。なお、ＲＰＡソフトウェアの数は任意である。

図１Ｂでは、ＲＰＡソフトウェアＰＲ１は、一例として、リリース承認会議ロボプロセスという名称であり、以下のようなＳ１からＳ５の処理要素を含む。
Ｓ１：表計算ソフトウェアで記入内容作成
Ｓ２：広報用部門の電子掲示板作成
Ｓ３：期限管理データベース作成
Ｓ４：依頼メール作成
Ｓ５：依頼メール発信
また、ＲＰＡソフトウェアＰＲ２は、一例として、大型案件取り纏めロボプロセスという名称であり、以下のようなＳ１０からＳ１５の処理要素を含む。
Ｓ１０：広報用部門の電子掲示板作成
Ｓ１１：表計算ソフトウェアでスケジュール作成
Ｓ１２：依頼メール作成
Ｓ１３：依頼メール発信
Ｓ１４：修正依頼受信
Ｓ１５：表計算ソフトウェア上のスケジュール更新
また、ＲＰＡソフトウェアＰＲ３は、一例として、特許月次モニタリングロボプロセスという名称であり、以下のようなＳ２０からＳ２７の処理要素を含む。
Ｓ２０：モニタリング依頼受信
Ｓ２１：広報用部門の電子掲示板作成
Ｓ２２：確認依頼メール作成
Ｓ２３：確認依頼メール発信
Ｓ２４：確認済メール受信
Ｓ２５：広報用部門の電子掲示板修正
Ｓ２６：モニタリング依頼メール作成
Ｓ２７：モニタリング依頼発信

ＲＰＡソフトウェアＰＲ１からＰＲ３は、ユーザから所定の入力が与えられると、入力に基づいて動作し、それぞれ、全ての処理要素を実行する。例えば、ＲＰＡソフトウェアＰＲ３では、所定の入力は、Ｓ２０に係る検索条件や、Ｓ２３に係る発信先のメールアドレス、Ｓ２６に係る発信先のメールアドレス等を含む。Ｓ２５では、確認済メールの内容に基づいて、広報用部門の電子掲示板が修正される。

以下では、特に言及しない限り、一例として、３つのＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３に関する説明を行う。

ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の実行に伴うログ情報（実行ログやアクセスログ等）は、ＤＢ１に蓄積される（実行ログ・アクセスログ蓄積）。
図１Ｃは、メンテナンス情報の出力例を示す図である。
図１Ｃでは、表形式で、ＰＲＡ業務名、最終更新日、定例稼働日、直近稼働可否、最終稼働日、変更必須項目Ｎｏ．１、Ｎｏ．２、及び、必要により修正する項目Ｎｏ．１、Ｎｏ．２の欄が設けられている。図１Ｃでは、ＰＲＡ業務名は、リリース承認会議記入依頼と、大型案件取り纏めと、特許月次モニタリングと、業界別・企業別分析資料取り纏めを含む。なお、リリース承認会議記入依頼、大型案件取り纏め、及び特許月次モニタリングは、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３にそれぞれ対応する。

また、図１Ｃでは、最終更新日が所定基準を満たす場合に、その欄が赤等で着色されることで（図１Ｃではハッチングで表現）、注意喚起される（メンテナンス情報の出力態様の一例）。所定基準は、任意であるが、例えば半年以上や１年以上経過している場合に満たされてよい。例えば、図１Ｃでは、特許月次モニタリングについて、最終更新日が所定基準を満たすため、赤等で着色されている。なお、最終更新日が古い場合に、段階的に複数の色で着色されてもよい。

また、図１Ｃでは、リリース承認会議記入依頼については、変更必須項目Ｎｏ．１の欄に、“新規・追加変更”との文字が表示されている（メンテナンス情報の出力態様の一例）。

その他、メンテナンス情報は、処理を実行している途中でアラームを出す（エラーを読み上げることや、画面にポップアップを表示する等）態様で出力されてもよい。メンテナンス情報は、他システムのファイル（参照先のファイル）を再指定できる画面を表示させる態様で出力されてもよい。あるいは、メンテナンス情報は、前回処理との差分を通知した上で、ＲＰＡソフトウェアのどこをどう直せばよいかをアドバイスする態様で出力されてもよい。例えば、ＲＰＡソフトウェアが、複数の命令が実行順に定義されている場合、エラーが発生すると、システム管理者は、命令ごとにその処理を確認でき、再修正登録できるといった具合である。このように、メンテナンス情報は、システム管理者に対して修正を支援するレベルの出力態様であってもよい。あるいは、処理スタート時に保持しているパラメータと、処理結果を対比し、かつ処理を重ねるごとにその情報を蓄積していくことで、システム管理者の人手で変更している当初パラメータの設定自体も何をセットすべきか学習してもよい。この場合、メンテナンス情報は、学習結果に基づくパラメータを仮セットする態様で出力されてもよい。

また、メンテナンス情報の出力態様は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の個別処理以外に、あるグループに属するＲＰＡソフトウェアのエラー発生情報を、掲示板的にまとめて表示する態様であってもよい。この場合、グループに属するＲＰＡソフトウェアのエラー発生情報は、自動的に収集されてもよい。

このようにして、メンテナンス情報は多様な態様で出力されてよい。なお、メンテナンス情報の出力条件（どのようなときにメンテナンス情報を出力するか）の更なる例については後述する。

図２は、一実施例によるＲＰＡ保守支援システム１の全体を示す概略図である。ＲＰＡ保守支援システム１は、ＲＰＡソフトウェアを保守・管理するためのシステムである。

ＲＰＡ保守支援システム１は、ＲＰＡ保守支援サーバ１０（ＲＰＡ保守支援装置の一例）と、情報源サーバ１１と、クライアントコンピュータ群２１とを含む。ＲＰＡ保守支援サーバ１０と情報源サーバ１１とクライアントコンピュータ群２１とは、ネットワーク４を介して接続される。ネットワーク４は、インターネット、ＷｏｒｌｄＷｉｄｅＷｅｂ、ＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）、無線通信網、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでもよい。

ＲＰＡ保守支援サーバ１０は、単一のサーバであってもよいし、複数の種類のサーバの組み合わせにより実現されてもよい。また、ＲＰＡ保守支援サーバ１０は、複数のコンピュータによる組み合わせにより実現されてもよい。

ＲＰＡ保守支援サーバ１０は、後述するように、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の処理結果に基づいて、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３のメンテナンスに関するメンテナンス情報を出力する機能（以下、「第１メンテナンス情報出力機能」と称する）を有する。第１メンテナンス情報出力機能の詳細は後述する。

また、ＲＰＡ保守支援サーバ１０は、後述するように、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の処理結果に基づくことなく、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３のメンテナンスに関するメンテナンス情報を出力する機能（以下、「第２メンテナンス情報出力機能」と称する）を有する。

第１メンテナンス情報出力機能により出力されるメンテナンス情報は、第２メンテナンス情報出力機能により出力されるメンテナンス情報とは属性が異なってもよい。例えば、第１メンテナンス情報出力機能により出力されるメンテナンス情報は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の処理結果に関するものであるのに対して、第２メンテナンス情報出力機能により出力されるメンテナンス情報は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の処理結果とは無関係な情報、例えば人とのつながりを促進できる情報（例えば何の業務に関するＲＰＡソフトウェアであるかを、新しいユーザに説明するようなメッセージ）であってもよい。このメッセージは、自然言語によるメッセージであってよく、メッセージの出力形態は、例えば音声や、文字、画像（動画、静止画）、点字、手話（動画、静止画の組合せ）等であってよい。

例えば、第２メンテナンス情報出力機能に関して、ＲＰＡ保守支援サーバ１０は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３のそれぞれの業務に関する内容を、メンテナンス情報として出力してもよい。この場合、出力タイミングは、任意であり、定期的なタイミングであってもよいし、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３が起動されたタイミングであってもよい。例えば、ＲＰＡ保守支援サーバ１０は、ＲＰＡソフトウェアＰＲ１が起動された際、ＲＰＡソフトウェアＰＲ１に係る業務が特許月次モニタリングロボプロセスである点を出力するとともに、特許月次モニタリングロボプロセスがどのような処理要素（Ｓ２０～Ｓ２７参照）を含むかについてのメッセージを出力してもよい。この場合、メンテナンス情報の出力先は、任意であり、例えば、ＲＰＡソフトウェアＰＲ１が起動された端末等である。あるいは、ＲＰＡ保守支援サーバ１０は、ＲＰＡソフトウェアＰＲ１の実行が終了した際、ＲＰＡソフトウェアＰＲ１に係る業務が特許月次モニタリングロボプロセスである点を出力するとともに、特許月次モニタリングロボプロセスがどのような処理要素（Ｓ２０～Ｓ２７参照）を含むかについてのメッセージを出力してもよい。このような場合、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３と人とのつながりを促進できる。すなわち、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３が、人にとって身近な存在となるように促進できる。
これらの場合、上記のメッセージは、自然言語によるメッセージであってよく、メッセージの出力形態は、例えば音声や、文字、画像（動画、静止画）、点字、手話（動画、静止画の組合せ）等であってよい。

あるいは、第２メンテナンス情報出力機能に関して、ＲＰＡ保守支援サーバ１０は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３のメンテナンスが所定期間以上なされていない場合に、その旨を表すメンテナンス情報を出力してよい。この場合、所定期間は、ＲＰＡソフトウェアＰＲ１の属性（例えばＲＰＡソフトウェアＰＲ１に係る業務の属性）に応じて決定されてよい。この場合のメンテナンス情報は、人とのつながりを促進できる情報ではなく、第１メンテナンス情報出力機能により出力されるメンテナンス情報と同様の機能を有する。

なお、本実施例では、第１メンテナンス情報出力機能及び第２メンテナンス情報出力機能が実現されるが、変形例では、第１メンテナンス情報出力機能及び第２メンテナンス情報出力機能のうちのいずれか一方のみが実現されてもよい。

情報源サーバ１１は、単一のサーバであってもよいし、複数の種類のサーバの組み合わせにより実現されてもよい。

情報源サーバ１１は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の実行の際にアクセスされる情報源（以下、「アクセス対象情報源」と称する）を保有する。アクセス対象情報源は、アプリケーション（表計算ソフトウェアや文書作成ソフトウェア等）を介して生成されたファイル（以下、「アプリケーションファイル」とも称する）、データベース、又はＷｅｂサイト等の形態であってよい。また、情報源サーバ１１の機能の一部又は全部は、ＲＰＡ保守支援サーバ１０に組み込まれてもよい。

クライアントコンピュータ群２１は、複数のクライアントコンピュータ２０を含む。なお、本明細書において、特に言及しない限り、ユーザとは、クライアントコンピュータ２０のユーザを指す。

クライアントコンピュータ２０は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３を実行する。クライアントコンピュータ２０は、記憶装置（例えば後述の補助記憶部１０３）に記憶されたＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３を実行する。なお、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３は、ＲＰＡ保守支援サーバ１０から毎回ダウンロードされてもよいし、初回や更新時のみダウンロードされてもよい。
図３は、クライアントコンピュータ２０のハードウェア構成の一例を示す図である。なお、ＲＰＡ保守支援サーバ１０や情報源サーバ１１のハードウェア構成についても、規模や性能が異なりうる点、及び、表示装置１０８等が省略されてよい点以外は、同様であってよい。
図３に示す例では、クライアントコンピュータ２０は、制御部１０１、主記憶部１０２、補助記憶部１０３、ドライブ装置１０４、ネットワークＩ／Ｆ部１０６、入力部１０７、及び表示装置１０８を含む。

制御部１０１は、主記憶部１０２や補助記憶部１０３に記憶されたプログラムを実行する演算装置であり、入力部１０７や記憶装置からデータを受け取り、演算、加工した上で、記憶装置などに出力する。

主記憶部１０２は、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）やＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）などである。主記憶部１０２は、制御部１０１が実行する基本ソフトウェアであるＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）やアプリケーションなどのプログラムやデータを記憶又は一時保存する記憶装置である。

補助記憶部１０３は、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）やＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）などであり、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３や、各種アプリケーションなどに関連するデータを記憶する記憶装置である。

ドライブ装置１０４は、記録媒体１０５、例えばフレキシブルディスクからプログラムを読み出し、記憶装置にインストールする。

記録媒体１０５は、所定のプログラムを格納する。この記録媒体１０５に格納されたプログラムは、ドライブ装置１０４を介してクライアントコンピュータ２０にインストールされる。インストールされた所定のプログラムは、クライアントコンピュータ２０により実行可能となる。

ネットワークＩ／Ｆ部１０６は、有線及び／又は無線回線などのデータ伝送路により構築されたネットワークを介して接続された通信機能を有する周辺機器やＲＰＡ保守支援サーバ１０とクライアントコンピュータ２０とのインターフェースである。

入力部１０７は、カーソルキー、数字入力及び各種機能キー等を備えたキーボード、マウスやタッチパッド等を有する。なお、入力部１０７は、ネットワークＩ／Ｆ部１０６を介して接続される周辺機器により実現されてもよい。

表示装置１０８は、液晶ディスプレイ等であってよい。なお、表示装置１０８は、ネットワークＩ／Ｆ部１０６を介して接続される周辺機器により実現されてもよい。

なお、図３に示す例において、以下で説明する各種処理等は、プログラムをクライアントコンピュータ２０に実行させることで実現することができる。また、プログラムを記録媒体１０５に記録し、このプログラムが記録された記録媒体１０５をクライアントコンピュータ２０に読み取らせて、以下で説明する各種処理等を実現させることも可能である。なお、記録媒体１０５は、様々なタイプの記録媒体を用いることができる。例えば、記録媒体１０５は、ＣＤ（ＣｏｍｐａｃｔＤｉｓｃ）－ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的あるいは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等のように情報を電気的に記録する半導体メモリ等であってよい。

図４は、ＲＰＡ保守支援サーバ１０と情報源サーバ１１とクライアントコンピュータ２０の機能を説明する図である。図４では、代表として、１つのクライアントコンピュータ２０について説明するが、他のクライアントコンピュータ２０も同様であってよい。

ＲＰＡ保守支援サーバ１０は、メンテナンス情報出力部１３０（出力部の一例）と、ログデータ記憶処理部１３２と、ログデータベース１３４とを含む。メンテナンス情報出力部１３０及びログデータ記憶処理部１３２は、制御部１０１のような制御部が主記憶部１０２や補助記憶部１０３のような記憶装置に記憶されるプログラムを実行することで実現できる。また、ログデータベース１３４は、補助記憶部１０３のような記憶装置により実現できる。
メンテナンス情報出力部１３０は、ログデータベース１３４内のデータ（ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の処理結果の一例）に基づいて、第１メンテナンス情報出力機能を実現する。第１メンテナンス情報出力機能の詳細は後述する。

また、メンテナンス情報出力部１３０は、ログデータベース１３４内のデータに基づくことなく、第２メンテナンス情報出力機能を実現する。第２メンテナンス情報出力機能の例は上述の通りである。

ログデータ記憶処理部１３２は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の実行に伴うログ情報を、クライアントコンピュータ２０から受信すると、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の実行に伴うログ情報を、ログデータベース１３４に記憶する。以下、ログデータベース１３４内に記憶されるログ情報を、「ログデータ」とも称する。ログデータは、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３ごとにかつ実行イベントごとに抽出可能な態様で、記憶されてよい。

情報源サーバ１１は、情報源管理部１４０と、情報源データベース１４２とを含む。情報源管理部１４０は、制御部１０１のような制御部が主記憶部１０２や補助記憶部１０３のような記憶装置に記憶されるプログラムを実行することで実現できる。情報源データベース１４２は、補助記憶部１０３のような記憶装置により実現できる。
情報源管理部１４０は、情報源データベース１４２内のアクセス対象情報源を管理する。例えば、情報源管理部１４０は、アクセス対象情報源を適宜更新し、削除、追加等を行う。

クライアントコンピュータ２０は、ＲＰＡソフトウェア実行部２１０と、ログ送信部２１２と、パラメータ管理部２１４を含む。ＲＰＡソフトウェア実行部２１０及びログ送信部２１２は、制御部１０１のような制御部が主記憶部１０２や補助記憶部１０３のような記憶装置に記憶されるプログラムを実行することで実現できる。また、パラメータ管理部２１４は、補助記憶部１０３のような記憶装置により実現できる。

ＲＰＡソフトウェア実行部２１０は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３を実行する。ＲＰＡソフトウェア実行部２１０は、定期的にＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３を実行してもよいし、ユーザからの指令に応じてＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３を実行してもよいし、予め規定されたルール（例えばパラメータ管理部２１４で設定されるスケジュールに係るパラメータ）にしたがってＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３を実行してもよい。

ログ送信部２１２は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の実行に伴うログ情報を、ＲＰＡ保守支援サーバ１０に送信する。

パラメータ管理部２１４は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３をコントロールするパラメータを管理する。各種パラメータは、各種業務に係るＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の上位層に設定される態様であってよい。なお、定例的に行う業務の一覧や、各種パラメータのうちの、変更すべきパラメータ等は、基本的に日付・その関連情報を設定しておくことで自動的に取得されてもよい。また、パラメータ管理部２１４は、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３の実行命令や、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３が終了した際に業務終了の情報等も、例えばユーザがシート上で確認できる態様で、管理してもよい。

ところで、ＲＰＡにより作成された業務プロセス（ＲＰＡソフトウェア）は、従来、人が行っていた作業を代替し効率化することが可能となる反面、人が作業していた時に気づく場合があった本質的な業務プロセスの問題点、例えば、より効率化できるようなプロセスの組み換え、等の気付きができないというデメリットもある。また、定例的に行う業務をＲＰＡで効率化する発想はあるが、業務プロセスは基本的に一緒であるものの年月日を都度変更セットする必要があったり、月によっては管理対象先を変更する必要があったり等、いくつかのパラメータ変更が必要となる業務が多い。また、将来的には大量のＲＰＡソフトウェアが生成され、稼働していくことになると予測されるが、陳腐化したＲＰＡソフトウェアを再生させる又は取捨選択していくことが求められる時期が来ると考えられる。
この点、本実施例によれば、上述のように、第１メンテナンス情報出力機能や第２メンテナンス情報出力機能によりメンテナンス情報が出力されるので、ＲＰＡソフトウェアを再生させる又は取捨選択していくことを容易化できる。すなわち、ＲＰＡソフトウェアが稼働した後、比較的長い期間経過した段階で、当該ソフトウェアを再生させる又は取捨選択していくことを容易化できる。
例えば、一定期間稼働ロジックに変更の無いＲＰＡソフトウェアを起動しようとすると、メッセージ（メンテナンス情報）がポップアップ等して、当該ＲＰＡソフトウェアの確認・改修を促すことができる。また、ＲＰＡソフトウェアが参照（アクセス）するアクセス対象情報源を表すログ情報をログデータベース１３４に蓄積しておき、アクセス対象情報源ごとにアクセス実績が分析できる。この場合、例えば、ログデータを統計的に処理して、アクセスの多いアクセス対象情報源をピックアップすることで独立した別システム構築の候補として採り上げることも可能となる。このように、本実施例によるメンテナンス情報出力機能は、ＲＰＡソフトウェアの機能を補充することで人の気付き的な代替手段となることができる。

次に、図５から図９を参照して、第１メンテナンス情報出力機能の具体例について、フローチャートを参照して説明する。以下では、一例として、ＲＰＡソフトウェアＰＲ１、ＰＲ２、ＰＲ３のうちの、ＲＰＡソフトウェアＰＲ１に関する処理について説明する。

図５は、メンテナンス情報出力部１３０により実行される処理の一例を示す概略フローチャートである。

図５では、前提として、ＲＰＡソフトウェアＰＲ１は、情報源サーバ１１から情報源データベース１４２内のアクセス対象情報源に係る情報（例えばアプリケーションファイル内の情報）を取得する処理を含むものとする。

ステップＳ５００では、メンテナンス情報出力部１３０は、モニタリング条件が成立したか否を判定する。モニタリング条件は、任意であり、例えば定期的に成立してもよいし、ユーザからのモニタリング指令が入力された場合に成立してもよい。判定結果が“ＹＥＳ”の場合は、ステップＳ５０２に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ５０２では、メンテナンス情報出力部１３０は、ログデータ記憶処理部１３２内のＲＰＡソフトウェアＰＲ１に関するログデータを取得する。

ステップＳ５０４では、メンテナンス情報出力部１３０は、ステップＳ５０２で取得したログデータに基づいて、アクセス対象情報源の不在、又は、アクセス対象情報源を構築するアプリケーションの変更があったか否かを判定する。アクセス対象情報源の不在は、アクセス対象情報源に係る情報が情報源サーバ１１から得られないことを表す。例えば所定のフォルダ内にアクセス対象情報源が存在しない場合が該当する。また、アクセス対象情報源を構築するアプリケーションの変更とは、アクセス対象情報源に係る情報が情報源サーバ１１から得られたが、アクセス対象情報源を構築するアプリケーションが変更されていること（例えば表計算ソフトウェアベースであったものが、他の形式のソフトウェアベース、例えばデータベース管理型のソフトウェアベースに変更されていること）を表す。判定結果が“ＹＥＳ”の場合は、ステップＳ５０６に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ５０６では、メンテナンス情報出力部１３０は、アクセス対象情報源の不在、又は、アクセス対象情報源を構築するアプリケーションの変更を表すメンテナンス情報を出力する。出力先は、クライアントコンピュータ群２１のうちの、登録されたシステム管理者に係るクライアントコンピュータ２０（以下、単に「システム管理者に係るクライアントコンピュータ２０」とも称する）であってもよいし、所定のサーバ（図示せず）であってもよいし、ＲＰＡ保守支援サーバ１０内のデータベース（図示せず）であってもよい。
例えば、メンテナンス情報出力部１３０は、アクセス対象情報源の不在があった場合は、その旨を表すメンテナンス情報を出力し、アクセス対象情報源を構築するアプリケーションの変更があった場合は、その旨を表すメンテナンス情報を出力する。メンテナンス情報の出力態様は、任意であり、例えば図１Ｃを参照して上述した態様であってよい。あるいは、メンテナンス情報出力部１３０は、アクセス対象情報源の不在があった場合は、エラーを読み上げる指令を、システム管理者に係るクライアントコンピュータ２０に送信してもよい。なお、システム管理者に係るクライアントコンピュータ２０では、エラーが発生した場合、ＲＰＡソフトウェアＰＲ１のロジック修正画面が自動起動し、新たな作業（例えば新しいアクセス対象情報源）を、例えばシステム管理者がすぐに登録できるように構成されてもよい。

図５に示す処理によれば、アクセス対象情報源の不在、又は、アクセス対象情報源を構築するアプリケーションの変更があった場合に、その旨を表すメンテナンス情報を出力できる。これにより、例えば、アクセス対象情報源を構築するアプリケーションの変更等に起因してＲＰＡソフトウェアＰＲ１の処理結果が、所期の結果と異なる場合に、例えばシステム管理者は、当該状況に容易に気付くことができ、必要な修正等を行うことができる。

なお、図５では、アクセス対象情報源の不在、又は、アクセス対象情報源を構築するアプリケーションの変更があった場合に、メンテナンス情報が出力されるが、これに限られない。例えば、アクセス対象情報源の不在、又は、アクセス対象情報源を構築するアプリケーションの変更のうちの、いずれか一方が生じた場合のみ、メンテナンス情報が出力されてもよい。また、表計算ソフトウェア等で作成されたアプリケーションファイルの変更（アプリケーションファイルの中身の情報の変更）があった場合に、その旨を表すメンテナンス情報を出力することとしてもよい。

図６は、メンテナンス情報出力部１３０により実行される処理の他の一例を示す概略フローチャートである。

図６では、前提として、ＲＰＡソフトウェアＰＲ１は、情報源サーバ１１から情報源データベース１４２内のアクセス対象情報源に係る情報を取得する処理を含むものとする。

ステップＳ６００では、メンテナンス情報出力部１３０は、モニタリング条件が成立したか否を判定する。モニタリング条件は、図５を参照して上述した通りであってよい。判定結果が“ＹＥＳ”の場合は、ステップＳ６０２に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ６０２では、メンテナンス情報出力部１３０は、ログデータ記憶処理部１３２内のＲＰＡソフトウェアＰＲ１に関するログデータを取得する。

ステップＳ６０４では、メンテナンス情報出力部１３０は、ステップＳ６０２で取得したログデータに基づいて、アクセス対象情報源に係る情報の新鮮さの低下、又は、アクセス対象情報源のバージョンの変化があったか否かを判定する。アクセス対象情報源に係る情報の新鮮さの低下は、例えばアクセス対象情報源の属性に応じて基準が異なってもよい。例えば、アクセス対象情報源に係る情報が、本来更新されるべきタイミングで更新されていない場合は、アクセス対象情報源に係る情報の新鮮さの低下があると判定されてもよい。また、アクセス対象情報源のバージョンの変化とは、例えばアクセス対象情報源に係るアプリケーション（例えば表計算ソフトウェア）のバージョンアップ等である。判定結果が“ＹＥＳ”の場合は、ステップＳ６０６に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ６０６では、メンテナンス情報出力部１３０は、アクセス対象情報源に係る情報の新鮮さの低下、又は、アクセス対象情報源のバージョンの変化を表すメンテナンス情報を出力する。出力先は、図５を参照して上述した通りであってよい。

図６に示す処理によれば、アクセス対象情報源に係る情報の新鮮さの低下、又は、アクセス対象情報源のバージョンの変化があった場合に、その旨を表すメンテナンス情報を出力できる。これにより、例えば、アクセス対象情報源に係るアプリケーションのバージョンアップ等に起因してＲＰＡソフトウェアＰＲ１の処理結果が、所期の結果と異なる場合に、例えばシステム管理者は、当該状況に容易に気付くことができ、必要な修正等を行うことができる。

なお、図６では、アクセス対象情報源に係る情報の新鮮さの低下、又は、アクセス対象情報源のバージョンの変化があった場合に、メンテナンス情報が出力されるが、これに限られない。例えば、アクセス対象情報源に係る情報の新鮮さの低下、及び、アクセス対象情報源のバージョンの変化のうちの、いずれか一方が生じた場合のみ、メンテナンス情報が出力されてもよい。また、図５との組み合わせで、アクセス対象情報源の不在、アクセス対象情報源を構築するアプリケーションの変更、アクセス対象情報源に係る情報の新鮮さの低下、及びアクセス対象情報源のバージョンの変化のうちの、少なくともいずれか１つが生じた場合に、メンテナンス情報が出力されてもよい。

図７は、メンテナンス情報出力部１３０により実行される処理の他の一例を示す概略フローチャートである。

図７では、前提として、ＲＰＡソフトウェアＰＲ１は、前処理と、本処理とを含み、本処理は、規定された情報源（アクセス対象情報源）から情報を取得することを含み、前処理は、当該アクセス対象情報源の存在を確認する処理を含む。ログ送信部２１２は、ＲＰＡソフトウェア実行部２１０による前処理の結果（ログ情報の一部）を、情報源サーバ１１に送信する。

ステップＳ７００では、メンテナンス情報出力部１３０は、モニタリング条件が成立したか否を判定する。モニタリング条件は、図５を参照して上述した通りであってよい。判定結果が“ＹＥＳ”の場合は、ステップＳ７０２に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ７０２では、メンテナンス情報出力部１３０は、ログデータ記憶処理部１３２内のＲＰＡソフトウェアＰＲ１に関するログデータを取得する。

ステップＳ７０４では、メンテナンス情報出力部１３０は、ステップＳ７０２で取得したログデータのうちの、ＲＰＡソフトウェア実行部２１０による前処理の結果に係るログデータに基づいて、アクセス対象情報源の不在があったか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ７０６に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ７０６では、メンテナンス情報出力部１３０は、アクセス対象情報源の不在を表すメンテナンス情報を出力する。出力先は、図５を参照して上述した通りであってよい。

図７に示す処理によれば、ＲＰＡソフトウェア実行部２１０による前処理の結果に係るログデータを利用することで、アクセス対象情報源の不在があった場合に、その旨を表すメンテナンス情報を出力できる。
なお、図７に示す処理では、ＲＰＡ保守支援サーバ１０がＲＰＡソフトウェア実行部２１０による前処理の結果に基づいてメンテナンス情報を出力しているが、クライアントコンピュータ２０側で直接的に前処理の結果に基づいてメンテナンス情報を出力してもよい。

図８は、メンテナンス情報出力部１３０により実行される処理の他の一例を示す概略フローチャートである。
ステップＳ８００では、メンテナンス情報出力部１３０は、モニタリング条件が成立したか否を判定する。モニタリング条件は、図５を参照して上述した通りであってよい。判定結果が“ＹＥＳ”の場合は、ステップＳ８０２に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ８０２では、メンテナンス情報出力部１３０は、ログデータ記憶処理部１３２内のＲＰＡソフトウェアＰＲ１に関するログデータを取得する。

ステップＳ８０４では、メンテナンス情報出力部１３０は、ステップＳ８０２で取得したログデータに基づいて、所定条件が満たされたか否かを判定する。
図８では、一例として、所定条件は、以下の条件（１）～（３）のうちの、少なくともいずれか１つが満たされた場合に、満たされる。
条件（１）：動作環境に有意な変化があったこと。
条件（２）：ＲＰＡソフトウェアＰＲ１の実行の際の通信量に有意な変化があったこと。
条件（３）：ＲＰＡソフトウェアＰＲ１の処理時間に有意な変化があったこと。
例えば、ＯＳなどが変更された場合に、条件（１）が満たされてよい。また、条件（２）は、ＲＰＡソフトウェアＰＲ１の実行の際の通信量が、通常的な通信量（例えば一定期間内の平均値）に対して乖離した場合に、満たされてよい。また、条件（３）は、ＲＰＡソフトウェアＰＲ１の処理時間が、通常的な処理時間（例えば一定期間内の平均値）に対して乖離した場合に、満たされてよい。
ステップＳ８０４において、判定結果が“ＹＥＳ”の場合は、ステップＳ８０６に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ８０６では、メンテナンス情報出力部１３０は、条件（１）～（３）のうちの満たされた１つ以上の条件に係る内容を表すメンテナンス情報を出力する。出力先は、図５を参照して上述した通りであってよい。

図８に示す処理によれば、条件（１）～（３）のうちの、少なくともいずれか１つが満たされた場合に、その旨を表すメンテナンス情報を出力できる。これにより、例えば、動作環境の変化に起因してＲＰＡソフトウェアＰＲ１の処理結果が、所期の結果と異なる場合に、例えばシステム管理者は、当該状況に容易に気付くことができ、必要な修正等を行うことができる。

なお、図８に示す処理は、一のＲＰＡソフトウェアＰＲ１に関するものであるが、これに限られない。例えば、図８に示す処理は、複数のＲＰＡソフトウェアを連携させる場合にも適用できる。具体的には、複数のＲＰＡソフトウェアが例えばジョブネットワークを形成し、複数のＲＰＡソフトウェアのそれぞれに係る業務が連携される場合がありうる。この場合、複数のＲＰＡソフトウェア全体としての処理に関して、条件（２）や条件（３）が満たされた場合に、メンテナンス情報が出力されてもよい。例えば、ＲＰＡソフトウェアＡ１に対して、２つの並列した前処理に係るＲＰＡソフトウェアＢ１、Ｂ２がある場合を想定する。この場合、通常的にはＲＰＡソフトウェアＢ１が先に完了するところを、ＲＰＡソフトウェアＢ１に係る要処理データが急増したため、処理時間が長引きＲＰＡソフトウェアＢ２の方が早く完了する場合がありうる。かかる場合に、メンテナンス情報が出力されることで、システム管理者は、当該状況に容易に気付くことができ、必要な修正等を行うことができる。

図９は、メンテナンス情報出力部１３０により実行される処理の他の一例を示す概略フローチャートである。

図９では、前提として、ＲＰＡソフトウェアＰＲ１は、所定の処理順序にしたがって行われるべき複数の処理要素を含む。例えば、ＲＰＡソフトウェアＰＲ１は、複数の命令が実行順に定義されている。すなわち、ＲＰＡソフトウェアＰＲ１の複数の処理要素は、所定の処理順で処理する設定にしたがって、処理される。当該設定は、ＲＰＡツールが出力したものであってもよいし、ユーザが編集したものであってもよいし、人工知能で学習させて得られたものであってもよい。また、当該設定に関する情報は、設定が変更されるごとに、ＲＰＡ保守支援サーバ１０において登録されてよい。

ステップＳ９００では、メンテナンス情報出力部１３０は、モニタリング条件が成立したか否を判定する。モニタリング条件は、図５を参照して上述した通りであってよい。判定結果が“ＹＥＳ”の場合は、ステップＳ９０２に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ９０２では、メンテナンス情報出力部１３０は、ログデータ記憶処理部１３２内のＲＰＡソフトウェアＰＲ１に関するログデータを取得する。

ステップＳ９０４では、メンテナンス情報出力部１３０は、ステップＳ９０２で取得したログデータに基づいて、所定の処理順序からの逸脱（すなわち、所定の処理順で処理する設定に基づいてＲＰＡソフトウェアＰＲ１の複数の処理要素が処理されなかった事象）があったか否かを判定する。例えば、本来は、処理要素Ａ１～Ａ１０までがこの順序で行われるのに対して、処理要素Ａ１～Ａ１０までが異なる順序（例えば処理要素Ａ９よりも先に処理要素Ａ１０が実行される場合や、処理要素Ａ９が実行されずに処理要素Ａ１０が実行される場合等）、所定の処理順序からの逸脱があったと判定される。判定結果が“ＹＥＳ”の場合は、ステップＳ９０６に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ９０６では、メンテナンス情報出力部１３０は、所定の処理順序からの逸脱を表すメンテナンス情報を出力する。出力先は、図５を参照して上述した通りであってよい。

図９に示す処理によれば、所定の処理順序からの逸脱があった場合に、その旨を表すメンテナンス情報を出力できる。これにより、例えば、所定の処理順序からの逸脱に起因してＲＰＡソフトウェアＰＲ１の処理結果が、所期の結果と異なる場合に、例えばシステム管理者は、当該状況に容易に気付くことができ、必要な修正等を行うことができる。

なお、図９に示す処理では、複数の処理要素は、ＲＰＡソフトウェアＰＲ１を形成する処理要素であるが、これに限られない。例えば、複数の処理要素は、複数のＲＰＡソフトウェアであってもよい。具体的には、複数のＲＰＡソフトウェアが例えばジョブネットワークを形成し、複数のＲＰＡソフトウェアのそれぞれに係る業務が連携される場合がありうる。この場合、複数のＲＰＡソフトウェアの連携態様の変化（すなわち所定の処理順で処理する設定に基づいて複数のＲＰＡソフトウェアが処理されなかった事象）に基づいて、メンテナンス情報が出力されてもよい。

以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせることも可能である。

上述した実施例に関して、更に以下の付記を開示する。
［付記１］
ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアの処理結果に基づいて、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備える、ＲＰＡ保守支援装置。
［付記２］
前記ソフトウェアは、規定された情報源から情報を取得する処理を含み、
前記出力部は、前記情報源の不在、前記情報源を構築するアプリケーションの変更、アプリケーションで作成されたアプリケーションファイルの変更、前記情報の新鮮さの低下、及び、前記情報源のバージョンの変化のうちの少なくともいずれか１つを、前記メンテナンス情報として出力する、付記１に記載のＲＰＡ保守支援装置。
［付記３］
前記ソフトウェアは、前処理と、本処理とを含み、
前記本処理は、規定された情報源から情報を取得することを含み、
前記前処理は、前記情報源の存在を確認する処理を含み、
前記出力部は、前記前処理の結果が前記情報源の不在を表す場合に、その旨の情報を、前記メンテナンス情報として出力する、付記１に記載のＲＰＡ保守支援装置。
［付記４］
前記出力部は、動作環境の変化、又は、前記ソフトウェアの処理時間の変化を、前記メンテナンス情報として出力する、付記１に記載のＲＰＡ保守支援装置。
［付記５］
前記ソフトウェアは、所定の処理順序で処理されるように設定された複数の処理要素を含み、
前記出力部は、前記所定の処理順で処理する設定に基づいて前記複数の処理要素が処理されなかった場合に、前記メンテナンス情報として出力する、付記１に記載のＲＰＡ保守支援装置。
［付記６］
ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアのメンテナンスが所定期間以上なされていない場合に、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備える、ＲＰＡ保守支援装置。
［付記７］
ロボットプロセスオートメーションに基づくソフトウェアの処理結果に基づいて、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する、
処理をコンピュータに実行させる、ＲＰＡ保守支援プログラム。

１ＲＰＡ保守支援システム
４ネットワーク
１０保守支援サーバ
１１情報源サーバ
２０クライアントコンピュータ
２１クライアントコンピュータ群
１０１制御部
１０２主記憶部
１０３補助記憶部
１０４ドライブ装置
１０５記録媒体
１０６ネットワークＩ／Ｆ部
１０７入力部
１０８表示装置
１３０メンテナンス情報出力部
１３２ログデータ記憶処理部
１３４ログデータベース
１４０情報源管理部
１４２情報源データベース
２１０ＲＰＡソフトウェア実行部
２１２ログ送信部
２１４パラメータ管理部
ＰＲ１ＲＰＡソフトウェア
ＰＲ２ＲＰＡソフトウェア
ＰＲ３ＲＰＡソフトウェア

Claims

ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアの処理結果に基づいて、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備え、
前記ソフトウェアの処理は、規定された情報源から情報を取得する処理を含み、
前記出力部は、前記情報源を構築するアプリケーションの変更を、前記メンテナンス情報として出力する、ＲＰＡ保守支援装置。
ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアの処理結果に基づいて、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備え、
前記ソフトウェアの処理は、規定された情報源から情報を取得する処理を含み、
前記出力部は、アプリケーションで作成されたアプリケーションファイルの変更を、前記メンテナンス情報として出力する、ＲＰＡ保守支援装置。
ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアの処理結果に基づいて、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備え、
前記ソフトウェアの処理は、規定された情報源から情報を取得する処理を含み、
前記出力部は、前記情報の新鮮さの低下を、前記メンテナンス情報として出力する、ＲＰＡ保守支援装置。
ロボティック・プロセス・オートメーション（ＲＰＡ）に基づくソフトウェアの処理結果に基づいて、前記ソフトウェアのメンテナンスに関するメンテナンス情報を出力する出力部を備え、
前記ソフトウェアの処理は、規定された情報源から情報を取得する処理を含み、
前記出力部は、前記情報源のバージョンの変化を、前記メンテナンス情報として出力する、ＲＰＡ保守支援装置。