特許 7359544 作業自動指示システム、方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-10-02

(45)【発行日】2023-10-11

(54)【発明の名称】作業自動指示システム、方法及びプログラム

(51)【国際特許分類】

   G06Q 10/0633 20230101AFI20231003BHJP

   G06Q 10/10 20230101ALI20231003BHJP

【ＦＩ】

G06Q10/0633

G06Q10/10 310

【請求項の数】 7

(21)【出願番号】P 2018240510

(22)【出願日】2018-12-25

(65)【公開番号】P2020102064

(43)【公開日】2020-07-02

【審査請求日】2021-12-14

(73)【特許権者】

【識別番号】000233491

【氏名又は名称】株式会社日立システムズ

(74)【代理人】

【識別番号】110000062

【氏名又は名称】弁理士法人第一国際特許事務所

(72)【発明者】

【氏名】奥谷 行央

(72)【発明者】

【氏名】板子 有里佳

【審査官】松野 広一

(56)【参考文献】

【文献】特開２００４－３１０７４７（ＪＰ，Ａ）

【文献】特開２００３－０３６１６２（ＪＰ，Ａ）

【文献】特開２００８－１０２６０１（ＪＰ，Ａ）

【文献】特開２０１４－２３２４４１（ＪＰ，Ａ）

【文献】特開２０１１－１００２８３（ＪＰ，Ａ）

【文献】特開２００９－１０４５８８（ＪＰ，Ａ）

【文献】特開２０１０－０３９５５５（ＪＰ，Ａ）

【文献】特開２０１０－２８７１４５（ＪＰ，Ａ）

【文献】特開２００４－２８７５７５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１０／０２０５０３２（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

顧客からの作業に関する要求を登録するリクエスト登録システムと、
前記作業についての担当者のスキルに応じて、前記要求を前記担当者に割り当て、前記作業の順序が記載されたチケットを生成するチケットアクションシステムと、
前記チケットに基づきワークフローを実行するチケットワークフローシステムと、を備え、
前記チケットアクションシステムは、前記チケットワークフローシステムが実行する前記チケットのステータスを前記チケットに基づいて監視する監視部を有し、
前記チケットワークフローシステムは、
前記作業はリモート対応が可能であるかを少なくとも記載する作業リストデータベースと、
前記担当者が前記作業を実施するスキルを有するかを記載しているスキルデータベースと、
前記作業リストデータベース及び前記スキルデータベースを用いて、前記要求を分析する分析部と、
前記分析部による分析結果に基づいて、前記要求を前記担当者に割り当て、前記作業の順序が記載されたチケットを生成する生成部と、を有し、
前記チケットには、リモート対応が可能であるか、又は、作業場所に移動する必要があるかが記載されている作業自動指示システム。

【請求項2】

前記チケットワークフローシステムは、さらに、
前記作業間での優先順番を記載する作業順定義データベースを有し、
前記作業が複数ある場合、前記分析部は、前記作業順定義データベースを用いて、複数の前記作業間の優先順を分析し、前記監視部は、前記複数の作業の順序が記載されたチケットを生成する請求項１記載の作業自動指示システム。

【請求項3】

前記監視部は、前記チケットのステータスを前記複数の作業の順序を構成する前記作業毎に監視し、前記担当者に作業指示を送信する請求項２記載の作業自動指示システム。

【請求項4】

前記チケットが複数の担当者に割り当てられた場合、前記監視部は、前記複数の作業の順序に応じて、ある担当者が実施すべき作業が終了してから、他の担当者に作業指示を送信する請求項３記載の作業自動指示システム。

【請求項5】

前記分析部は、前記作業リストデータベースを用いて、前記要求が定例作業に関するものであるか否かを分析し、
前記チケットには、前記作業が定例作業であるか否かが記載されている請求項１記載の作業自動指示システム。

【請求項6】

顧客からの作業に関する要求に応じて作業を自動的に指示するシステムをコンピュータに実行させるための作業自動指示方法であって、
前記顧客からの作業単位で受け付けた要求を登録し、
前記作業についての担当者のスキルに応じて、前記作業を前記担当者に割り当て、前記作業の順序が記載されたチケットを生成し、
前記チケットに基づきワークフローを実行し、
前記担当者に割り当てられた前記チケットのステータスを前記チケットに記載された作業ごとに監視し、前記監視の結果に基づいて、前記担当者に作業指示を送信し、
前記作業はリモート対応が可能であるかを少なくとも記載するデータ及び前記担当者が前記作業を実施するスキルを有するかを記載するデータを用いて、前記要求を分析し、
前記分析の結果に基づいて、前記要求を前記担当者に割り当て、前記作業の順序が記載されたチケットを生成し、
前記チケットには、リモート対応が可能であるか、又は、作業場所に移動する必要があるかが記載されている作業自動指示方法。

【請求項7】

顧客からの作業に関する要求に応じて作業を自動的に指示するシステムをコンピュータに実行させるためのプログラムであって、
前記顧客からの作業単位で受け付けた要求を登録するステップと、
前記作業についての担当者のスキルに応じて、前記作業を前記担当者に割り当て、前記作業の順序が記載されたチケットを生成するステップと、
前記チケットに基づきワークフローを実行するステップと、
前記担当者に割り当てられた前記チケットのステータスを前記チケットに基づいて監視し、前記監視の結果に基づいて、前記担当者に作業指示を送信するステップと、を備え、
前記作業はリモート対応が可能であるかを少なくとも記載するデータ及び前記担当者が前記作業を実施するスキルを有するかを記載するデータを用いて、前記要求を分析するステップ、
前記分析するステップによる分析結果に基づいて、前記要求を前記担当者に割り当て、前記作業の順序が記載されたチケットを生成するステップと、を有し、
前記チケットには、リモート対応が可能であるか、又は、作業場所に移動する必要があるかが記載されている作業自動指示プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、構築したシステムが円滑に稼働するよう継続的に保守作業を行っていくための作業自動指示システム、方法及びプログラムに関する。

【背景技術】

【0002】

構築したシステムは、円滑に稼働するよう継続的に保守を行っていく必要がある。このような保守などを行うのが運用管理システムであり、おもにネットワーク、システム、業務運用の３つの管理を行う。

【0003】

ネットワークやシステムの管理には、ハードウェアやソフトウェアの障害を検出し遠隔操作などで復旧する障害対策、ハードウェアの配置や記録媒体の空き容量を管理する構成管理、ネットワーク上のトラフィックやプロセッサの使用率を管理する性能管理、パスワードやアクセス権を制御するセキュリティ管理がある。また、業務運用の管理では、スケジュールに従ったジョブの自動実行、バックアップ、帳票出力等を実行する。

【0004】

このような運用管理システムとしては、例えば、１つ又は複数の作業の順序であるワークフローをシステムとして運用及び管理するワークフローシステムがあり、例えば、製造現場でよく見られる工程管理システムに適用されている。

【0005】

また、特許文献１には、ソフトウェアの開発における、チケット駆動開発と呼ばれる開発手法が記載されている。近年、ソフトウェアの開発現場では、チケット駆動開発と呼ばれる開発手法が用いられている。チケット駆動開発とは、Ｗｅｂベースのチケット管理システムを用いて、プロジェクトの工程ごとに当該工程を示す「チケット」と呼ばれる情報を生成し、当該工程を終えたときに作業者が当該チケットに工程を終えたことを示す進捗状況を入力することによって、プロジェクトの工程を管理する手法である。このチケットに、工程の実行期限や作業者の作業時間を記載することによって、チケット管理システムは、工程の作業時間を管理することが可能になる。

【先行技術文献】

【特許文献】

【0006】

【文献】特開２０１４－１４２８８５号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかしながら、特許文献１のチケット管理システムでは、管理者が、作業者が行なう作業の順序を予めＷｅｂブラウザから登録している。このため、作業の種類毎に担当者が固定されてしまう。また、一つ又は複数の作業の順序に対し、一つ又は複数のチケットが関連付けられている。このため、作業の順序が複雑になると、作業者はチケットに関するメールを何度も受信することになり、運用管理システム全体として煩雑になる。

【0008】

本発明では、チケットのステータスを監視する作業自動指示システムを提供することを目的とする。

【課題を解決するための手段】

【0009】

上記課題を解決するために、代表的な本発明の作業自動指示システムの一つは、顧客からの作業に関する要求を登録するリクエスト登録システムと、前記作業についての担当者のスキルに応じて、前記要求を前記担当者に割り当て、前記作業の順序が記載されたチケットを生成するチケットアクションシステムと、前記チケットに基づきワークフローを実行するチケットワークフローシステムと、を備え、前記チケットアクションシステムは、前記チケットワークフローシステムが実行する前記チケットのステータスを前記チケットに基づいて監視する監視部を有する。

【発明の効果】

【0010】

本発明によれば、チケットアクションシステムが、顧客から依頼された作業に関するチケットに担当者を割り当て、さらに、チケットアクションシステムの監視部が、チケットワークフローシステムが実行するチケットの各段階でのステータスを監視することが可能となる。

【図面の簡単な説明】

【0011】

【図1】実施例１に係る作業自動指示システムの全体構成図。

【図2】実施例１に係るリクエスト登録システムの機能ブロック図。

【図3】実施例１に係るリクエストＤＢに格納するデータ構成図。

【図4】実施例１に係るチケットアクションシステムの機能ブロック図。

【図5】実施例１に係る顧客毎の作業リストＤＢに格納するデータ構成図。

【図6】実施例１に係る担当者のスキルＤＢに格納するデータ構成図。

【図7】実施例１に係る作業順定義ＤＢに格納するデータ構成図。

【図8】実施例１に係るチケットＤＢに格納するデータ構成図。

【図9】実施例１に係るチケットワークフローシステムのフローチャート及びチケットのステータス監視を説明するための図。

【図10】実施例２に係るリクエストＤＢに格納するデータ構成図。

【図11】実施例２に係る作業リストＤＢに格納するデータ構成図。

【図12】実施例２に係る担当者のスキルＤＢに格納するデータ構成図。

【図13】実施例２に係る作業順定義ＤＢに格納するデータ構成図。

【図14】実施例２に係るチケットＤＢに格納するデータ構成図。

【発明を実施するための形態】

【0012】

以下、図面を参照しながら本発明の実施の形態を説明する。

【実施例1】

【0013】

（構成）
図１は、実施例１に係る作業自動指示システムの全体構成図である。ここでは、構築したシステムを円滑に可動させるための運用管理システムが継続的に行う作業の例として保守作業を挙げ、この作業を自動指示するための作業自動指示システムについて説明する。

【0014】

作業自動指示システムは、顧客からの作業に関する要求であるリクエスト情報を登録するリクエスト登録システム１００と、作業に関するチケットを担当者に割り当て、かつ、チケットのステータスを監視するチケットアクションシステム３００と、チケットに基づいてワークフローを実行するチケットワークフローシステム４００を備える。

【0015】

各システム１００、３００、４００はコンピュータサーバ装置（以下、サーバという）で構成され、ネットワークを介して接続されている。また、各システムが利用するデータベース（以下、単にＤＢといい、リクエストＤＢ２１０、作業リストＤＢ２２０、スキルＤＢ２３０、作業順定義ＤＢ２４０及びチケットＤＢ２５０にわかれている）もサーバで構成され、ネットワークを介して接続されている。これらのシステム及びＤＢ内の各構成要素による処理を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、当該記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、作業自動指示システムに係る種々の処理を実行することが可能となる。

【0016】

図２は、実施例１に係るリクエスト登録システム１００の機能ブロック図である。リクエスト登録システム１００は、顧客からの作業に関するリクエスト情報を受信する受信部１１０と、受信したリクエスト情報を分類する分類部１２０とを備える。

【0017】

１又は複数の顧客は、Ｗｅｂブラウザ１０から作業に関するリクエスト情報を作業単位で入力する。

【0018】

受信部１１０は、Ｗｅｂブラウザ１０から作業単位で入力されたリクエスト情報を受け付ける。ここで、Ｗｅｂブラウザ１０は顧客の端末で表示及び動作し、リクエスト登録システム１００に含まれないことを前提とする。そのため、図２では、Ｗｅｂブラウザ１０、及び、Ｗｅｂブラウザ１０から受信部１１０への情報線を一点鎖線で表し、一方、リクエスト登録システム１００やリクエストＤＢ２１０は実線で表し、リクエスト登録システム１００がＷｅｂブラウザ１０を含まないことを明記している。

【0019】

分類部１２０は、作業単位で受け付けたリクエスト情報を顧客名及び作業期日に応じて分類し、分類したリクエスト情報をリクエストＤＢ２１０に格納する。また、分類部１２０は、過去に格納した情報をリクエストＤＢ２１０から読み出し、更新することが可能である。

【0020】

図３は、実施例１に係るリクエストＤＢに格納するデータ構成図である。リクエストＤＢ２１０は、テーブル形式のデータベースであり、複数のリクエストレコードで構成されている。図３の一点鎖線で囲んだリクエストレコード２１５は、リクエストＮｏ．「１」として、顧客名「顧客１」が作業名「Ｘ１、Ｙ１、Ｚ１」を期日（いつからいつまで）「２０１７年４月」にして欲しいと要求していることを表す。

【0021】

リクエストレコード２１５は、作業単位で受け付けたリクエスト情報を顧客名及び作業期日に応じてレコードに分類したものである。次に、リクエストレコード２１５がどのように更新登録されるかについて説明する。

【0022】

例えば、リクエスト登録システム１００が、顧客１から、２０１７年４月１日から２０１７年４月３０日までに作業名Ｘ１をして欲しいという第１のリクエスト情報を受け付けた場合、リクエストＤＢ２１０に、リクエストＮｏ．「１」、顧客名「顧客１」、作業名「Ｘ１」、期日「２０１７年４月」と登録する。

【0023】

次に、リクエスト登録システム１００が、顧客１から、２０１７年４月１日から２０１７年４月３０日までに作業名Ｙ１をして欲しいという第２のリクエスト情報を受け付けた場合、リクエストＤＢ２１０から、リクエストＮｏ．「１」、顧客名「顧客１」、作業名「Ｘ１」、期日「２０１７年４月」というリクエスト情報を読み出し、リクエストＮｏ．「１」顧客名「顧客１」、作業名「Ｘ１、Ｙ１」、期日「２０１７年４月」と更新登録する。

【0024】

最後に、リクエスト登録システム１００が、顧客１から、２０１７年４月１日から２０１７年４月３０日までに作業名Ｚ１をして欲しいという第３のリクエスト情報を受け付けた場合、リクエストＤＢ２１０から、リクエストＮｏ．「１」、顧客名「顧客１」、作業名「Ｘ１、Ｙ１」、期日「２０１７年４月」というリクエスト情報を読み出し、リクエストＮｏ．「１」、顧客名「顧客１」、作業名「Ｘ１、Ｙ１、Ｚ１」、期日「２０１７年４月」と更新登録する。図３の一点鎖線で囲んだリクエストレコード２１５は、この更新登録の状態を示す。

【0025】

なお、図３では説明の都合上、作業名「Ｘ、Ｙ、Ｚ」に、顧客名「顧客１、顧客２、顧客３」の数字を振り、「Ｘ１」などと表している。この「Ｘ１」は、顧客１がリクエストした作業Ｘを意味する。

【0026】

図４は、実施例１に係るチケットアクションシステムの機能ブロック図である。チケットアクションシステム３００は、リクエストレコードを取り込む取込部３１０と、リクエストレコードを分析する分析部３２０と、チケットを生成する生成部３３０と、チケットのステータスを監視する監視部３４０を備える。

【0027】

取込部３１０は、リクエストＤＢ２１０を定期的に読み出し、リクエストＤＢ２１０に格納されている新規なリクエストレコードを取り込む。定期的に読み出すタイミングとしては一日に一回などでよい。

【0028】

分析部３２０は、まず、作業リストＤＢ２２０を用いて、取り込んだ新規なリクエストレコードを分析する。

【0029】

図５は、実施例１に係る顧客毎の作業リストＤＢに格納するデータ構成図である。作業リストＤＢ２２０は、テーブル形式のデータベースであり、カラムとして左から「顧客名」、「作業名」、「作業内容」、「リモート対応」、「作業場所」、「種別」、「周期」及び「時間帯」が記載されている。ここで、「種別」が毎週や毎月の場合、その作業は定例作業である。すなわち、図５は定例作業に関する作業リストＤＢである。なお、作業リストＤＢには、非定例作業に関する作業リストが記載されていてもよい。

【0030】

分析部３２０は、作業リストＤＢ２２０を用いて、リクエストレコードの作業内容がリモート対応「可（可能）」または「不可（不可能）」を分析する。また、リモート対応「不可」の場合、作業場所も分析する。さらに、種別、周期、時間帯のカラムも分析する。

【0031】

次に、分析部３２０は、スキルＤＢ２３０を用いて、担当者が作業を担当することスキルを有するか否かを分析する。

【0032】

図６は、実施例１に係る担当者のスキルＤＢに格納するデータ構成図である。スキルＤＢ２３０はテーブル形式のデータベースであり、縦軸に作業名が記載され、横軸に担当者名が記載されている。例えば、作業「Ｙ（テープクリーニング）」は担当者「Ａ」及び「Ｂ」は「可」（すなわちスキル有り）であるが、担当者「Ｃ」は「不可」（すなわちスキル無し）であることが記載されている。

【0033】

さらに、分析部３２０は、作業順定義ＤＢ２４０を用いて、複数の作業間の優先順を分析する。

【0034】

図７は、実施例１に係る作業順定義ＤＢに格納するデータ構成図である。作業順定義ＤＢ２４０はテーブル形式のデータベースであり、複数の作業間での優先順番を記すために、カラムとして左から「順番」及び「作業名」が並んでいる。例えば、作業「Ｘ（サーバリブート）」、「Ｙ（テープクリーニング）」及び「Ｚ（機器巡回）」を行う場合、Ｘ、Ｙ、Ｚの順に作業を行う必要があることがわかる。

【0035】

このように、分析部３２０が、作業リストＤＢ２２０、スキルＤＢ２３０、作業順定義ＤＢ２４０を用いて、複数のリクエストレコードを分析する。

【0036】

生成部３３０は、分析部３２０が行なった複数のリクエストレコードの分析結果に基づいて、作業を担当者に割り当てるチケットを生成し、チケットＤＢ２５０へ出力する。

【0037】

図８は、実施例１に係るチケットＤＢに格納するデータ構成図である。チケットＤＢ２５０は、テーブル形式のデータベースであり、カラムとして左から「チケット番号」、「担当者」、「チケット名」、「作業順序」、「作業場所」、「種別」、「周期」及び「時間帯」が並んでいる。図８では、１つのチケットを１人の担当者に割り当てる場合を記載している。

【0038】

例えば、チケット番号「１」では、担当者「Ａ」は３つのサーバリブートに関する作業を「Ｘ１→Ｘ２→Ｘ３」の順に作業場所「本部オフィスの３階」にて毎週日曜日の１８：００～２０：００に行う旨が記載されている。この作業順序「Ｘ１→Ｘ２→Ｘ３」がワークフローに相当する。また、作業場所が「本部オフィスの３階」であるのは、図５の通り、リモート対応が可能だからである。リモート対応が不可能な場合、作業場所として例えば「Ａセンタ、１階南」と記載されている。この場合、担当者は作業場所「Ａセンタ、１階南」に移動し、物理作業（テープクリーニングなど）を実施することになる。

【0039】

なお、チケットには、必ずしも複数のリクエスト情報が割り当てられるわけではない。例えば、チケット番号「３」の場合、顧客１から受け取った１つのリクエスト情報（作業名はＺ１）のみが担当者Ｃに割り当てられる場合もある。つまり、ワークフローは１つの作業の順序「Ｚ１」を指す場合もある。

【0040】

監視部３４０は、チケットＤＢ２５０からチケットを読み出し、チケットワークフローシステム４００でのチケットのステータスを、読み出したチケットに基づいて監視する。

【0041】

（動作）
図９は、実施例１に係るチケットワークフローシステムのフローチャート及びチケットのステータス監視を説明するための図である。

【0042】

チケットワークフローシステム４００は、チケットＤＢ２５０からチケットを定期的に読み出し、チケットを担当者へ連絡する（Ｓ４１０）。定期的に読み出すタイミングとしては一日に一回などでよい。

【0043】

チケットワークフローシステム４００によるＳ４１０以降の処理は、チケットの準備段階、実施段階、及び、完了段階に分けること可能である。チケットアクションシステム３００の監視部３４０は、各段階でのチケットのステータス（状態）をチケットに基づいて監視する。ここで、チケットのステータスとしては、作業順序を構成する作業毎に、作業を実施する時期が近づいているか示すアラート（作業指示に関する警告）、各作業が完了したという終了などがある。そして、監視部３４０は、チケットに記載されている作業順序に基づいて担当者の携帯端末に作業指示を送信する。

【0044】

例えば、監視部３４０がチケットＤＢ２５０から図８のチケット番号「１」のチケットを読み出し、チケットワークフローシステム４００がチケット番号「１」のチケットを実行する場合について説明する。チケット番号「１」は毎週日曜日に実施する定例作業に関し、その作業順序「Ｘ１→Ｘ２→Ｘ３」であり、作業「Ｘ１」が終了した場合、チケット番号「１」のステータスは「Ｘ１は終了、Ｘ２は次に実施する必要があるので作業指示を送信する必要あり、Ｘ３はＸ２の終了後に作業指示を送信する予定」となる。

【0045】

このようにして担当者「Ａ」は、次に実施する必要がある作業（ここではＸ２）についてのみ作業指示を監視部３４０から受け取ることができ、複数の作業に関する（ここではＸ２だけでなくＸ３についても）メールを何度も（Ｘ２の作業指示と同時にＸ３の作業指示を）受信することが無くなる。

【0046】

また、チケットに毎週と記載されているため、その週についての作業指示だけを監視部３４０から受け取ることができ、翌週以降分の作業指示を受信する必要がなくなる。

【0047】

準備段階では、チケットワークフローシステム４００もスキルＤＢ２３０を利用し、担当者がチケットに割り当てられた作業を行うスキルを有しているかを審査する（Ｓ４２０）。そして、スキルを有している場合、担当者を承認する（Ｓ４３０）。

【0048】

実施段階では、チケットに記載された「種別」、「周期」及び「時間帯」（図８を参照）に応じて、担当者に実施を催促するフォローを実行する（Ｓ４４０）。そして、担当者が実施した結果をチケットに登録する（Ｓ４５０）。

【0049】

例えば、担当者「Ａ」が作業「Ｘ１」を行った結果が登録された段階（Ｓ４５０）で、担当者「Ａ」に次の作業「Ｘ２」を行うようフォローする（Ｓ４４０）必要がある。

【0050】

監視部３４０は、チケットＤＢ２５０に基づきチケットの各ステータスを監視しているため、次の作業（この場合、担当者「Ａ」による作業「Ｘ２」）を自動的に指示することができる。

【0051】

次に、チケットに記載された作業全体が終わった段階で、その実施結果を審査し、問題が無ければ、承認を行う（Ｓ４６０）。

【0052】

完了段階では、チケットに記載された作業が完了した旨を顧客に連絡を行う（Ｓ４７０）。

【0053】

（効果）
本実施例の作業自動指示システムによれば、チケットアクションシステム３００が、顧客から依頼された作業に関するチケットに担当者を割り当て、さらに、チケットアクションシステム３００の監視部３４０が、チケットワークフローシステム４００が実行するチケットの各段階でのステータスを監視することが可能となる。

【0054】

また、チケットアクションシステム３００は、作業リストＤＢ２２０、スキルＤＢ２３０及び作業順定義ＤＢ２４０を用いることによって、各担当者が行う作業順序を自動的にチケットとして生成することが可能になる。したがって、管理者が、作業者が行なう作業の順序を予め登録する必要は無くなる。

【0055】

さらに、一人の担当者が行う作業順序が複雑になっても、チケットアクションシステム３００が作業順序を構成する作業毎にチケットのステータスを監視しているため、作業者は複数の作業に関するメールを何度も受信することが無くなり、運用管理システム全体としての煩雑さを解消することが可能になる。特に、定例作業の場合に効果的である。

【実施例2】

【0056】

実施例２に係る作業自動指示システムでは、リクエスト登録システム１００、チケットアクションシステム３００及びチケットワークフローシステム４００は実施例１と同じ構成であるため、説明を省略する。実施例２の特徴は、各ＤＢのレコード数が多くなり、１つのチケットを複数の担当者に割り当てる点である。

【0057】

（構成）
図１０から図１４を用いて実施例２に係る各ＤＢを説明する。ここで、実施例２に係る各ＤＢは、図１のシステム全体構成図や、図２、図４及び図９のシステムの機能ブロック図における機能及び役割において実施例１で説明した各ＤＢと同じであり、同じ符号を用いる。ただし、実施例２に係る各ＤＢを具体的にテーブル形式で表した場合、実施例１のテーブル形式とは異なる。このため、説明の都合上、実施例２に係る各ＤＢをテーブル形式で表す図１０から図１４では実施例１と同じ符号の後ろに「－２（ハイフン２）」を付けて区別している。

【0058】

図１０は、実施例２に係るリクエストＤＢに格納するデータ構成図である。リクエストレコードの記載は図３と同じ要領である。例えば、図１０のリクエストＮｏ．「１」のリクエストレコードは、顧客名「顧客１」が作業名「サーバリブート」を期日（いつからいつまで）「２０１７年５月」にして欲しいと要求していることを表す。

【0059】

図１０が図３と異なる点は、図２の分類部が、作業単位で受け付けたリクエスト情報を作業期日に応じて分類し、分類したリクエスト情報をリクエストＤＢ２１０－２に格納する点である。このため、顧客名「顧客１」に対するリクエストＮｏ．は「１」から「３」となり、リクエストレコードの数が多くなる。

【0060】

図１１は、実施例２に係る作業リストＤＢに格納するデータ構成図である。作業リストＤＢのレコードの記載は基本的に図５と同じであり、さらに、作業リストＤＢ２２０－２には、カラム「顧客名」と「作業名」の間に「作業記号」が追加され、カラム「時間帯」の右側に「備考」が追加されている。

【0061】

カラム「作業記号」は英字と数字の組合せである。英字は作業名を表し、数字は顧客名を表す。例えば、作業記号が「ＷＡ１」の場合、英字「ＷＡ」が作業名「サーバリブート」を表し、数字「１」は顧客名「顧客１」を表す。

【0062】

なお、作業記号「ＷＧ３－１」及び「ＷＧ３－２」について、顧客名「顧客３」及び作業名「ＡＤサーバシステムバックアップ」である点で同じであるが、カラム「備考」は「毎月第２火曜」と「毎月第４火曜」が異なる。このため、「－（ハイフン）」と、その後に数字「１」または「２」を付け、識別できるようにしている。

【0063】

図１２は、実施例２に係る担当者のスキルＤＢに格納するデータ構成図である。図６と同様、縦軸に作業名が記載され、横軸に担当者名が記載されている。実施例２の場合、作業名が多くなるため、スキルＤＢ２３０－２には、作業名が多く記載されている。

【0064】

図１３は、実施例２に係る作業順定義ＤＢに格納するデータ構成図である。図７と同様、複数の作業間での優先順番が記載されている。実施例２の場合、作業名が多くなるため、作業順定義ＤＢ２４０－２には、作業名が多く記載されている。

【0065】

図１４は、実施例２に係るチケットＤＢに格納するデータ構成図である。チケットＤＢ２５０－２は、図８と異なり、カラムとして左から「チケット番号」、「チケット名」、「担当者」、「作業順序」、「作業場所」、「備考」が並んでいる。図１４では、１つのチケットを複数の担当者に割り当てる場合を記載している。

【0066】

例えば、チケット番号「１」では、チケット名「リモート対応」に二人の担当者「Ａ」及び「Ｂ」が割り当てられる。二人の担当者の作業場所は「○○オフィスの３Ｆ」である。

【0067】

担当者「Ａ」はリモート対応に関する作業を「ＷＡ１→ＷＣ１→ＷＧ３－１→ＷＧ３－２→ＷＪ４→ＷＫ４－３」の順に行う。また、担当者「Ｂ」はリモート対応に関する作業を「ＷＥ２→ＷＩ４→ＷＬ５」の順に行う。

【0068】

ここで、カラム「備考」には「担当者Ａ、Ｂは、作業順定義ＤＢ２４０－２に従って実行する」と記載されている。それゆえ、担当者は、相手がある作業を行ってから、自分が行うべき作業を実施する場合がある。

【0069】

例えば、担当者「Ａ」が作業「ＷＣ１」の次に「ＷＧ３－１」を行う場合を考える。「ＷＣ１」は図１１より「ＡＰ起動確認」であり、図１３より優先順番は「３」であることがわかる。「ＷＧ３－１」は図１１より「ＡＤサーバシステムバックアップ」であり、図１３より優先順番は「７」であることがわかる。

【0070】

一方、相手の担当者「Ｂ」は作業「ＷＥ２」を行う必要がある。「ＷＥ２」は図１１より「パスワード変更」であり、図１３より優先順番は「５」であることがわかる。

【0071】

このため、担当者「Ａ」が作業「ＷＣ１」の次に「ＷＧ３－１」を行う場合、担当者「Ａ」が作業「ＷＣ１」を終わった後に、担当者「Ｂ」が作業「ＷＥ２」を終え、それから、担当者「Ａ」は作業「ＷＧ３－１」を行う必要がある。

【0072】

このような場合に、図９で説明したフローチャート及びステータス監視によれば、まず、チケット番号「１」を担当者「Ａ」及び「Ｂ」へ連絡する（Ｓ４１０）。準備段階では、担当者「Ａ」及び「Ｂ」を審査し（Ｓ４２０）、担当者「Ａ」及び「Ｂ」の承認を行う。

【0073】

次に、実施段階では、担当者「Ａ」が作業「ＷＣ１」を終わった後に、担当者「Ｂ」に作業「ＷＥ２」を行うようフォローする（Ｓ４４０）。その作業結果を登録する（Ｓ４５０）。なお、Ｓ４６０の審査承認はチケット全体の作業が終わった段階で行われる。

【0074】

そこで、担当者「Ｂ」が作業「ＷＥ２」を行った結果が登録された段階（Ｓ４５０）で、担当者「Ａ」に作業「ＷＧ３－１」を行うようフォローする（Ｓ４４０）必要がある。

【0075】

監視部３４０は、チケットＤＢ２５０に基づきチケットの各ステータスを監視しているため、次の作業（この場合、担当者「Ａ」による作業「ＷＧ３－１」）を自動的に指示することができる。

【0076】

（効果）
本実施例の作業自動指示システムによれば、チケットアクションシステム３００が、顧客から依頼された作業に関するチケットに複数の担当者を割り当て、さらに、チケットワークフローシステム４００によるチケットの各段階でのステータスを監視することが可能となる。

【0077】

さらに、作業の順序に応じて、ある担当者が実施すべき作業が終了してから、他の担当者が他の作業を実施する必要がある場合でも、他方の担当者に送信する作業指示を適切なタイミングで行うことが可能となる。

【0078】

なお、本発明は上記した実施例に限定されるものではなく、保守作業以外の、構築したシステムが円滑に稼働するように行う運用管理に適用されうる様々な変形例が含まれる。例えば、運用管理作業の場合、運用管理するプロジェクトの各工程の実行期限や作業担当者の作業時間が記載されているチケットの準備、実施、完了の各段階について、ステータスを監視する場合も含まれ、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

【0079】

また、上記の各構成は、それらの一部又は全部が、例えば集積回路で設計する等によりハードウェアで構成されても、プロセッサでプログラムが実行されることにより実現されるように構成されてもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

【符号の説明】

【0080】

１００ リクエスト登録システム
２１０、２１０－２ リクエストＤＢ
２１５リクエストレコード
２２０、２２０－２ 作業リストＤＢ
２３０、２３０－２ スキルＤＢ
２４０、２４０－２ 作業順定義ＤＢ
２５０、２５０－２ チケットＤＢ
３００ チケットアクションシステム
３１０ 取込部
３２０ 分析部
３３０ 生成部
３４０ 監視部
４００ チケットワークフローシステム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】