JP2013246529A - 業務課題分析支援システム - Google Patents

Abstract

【課題】
本発明の課題は、業務システムの稼働状況を示すデータを分析し、システム利用者が現場で行っている業務に潜む暗黙的な課題を見つけ出すことを支援するシステムを提供することにある。特に、エズノグラファのような専門家でなくとも課題を見出すことを支援することを課題とする。
【解決手段】
観察やインタビューなどのユーザ分析から見つかった現場の業務課題に対して、その業務課題がコンピュータを利用したときにどのような事象として稼動データに表れるのかを分類した事象例と、その事象を見つけ出すための分析メニューと解析機能、可視化手段を有するシステムを提供する。
【選択図】 図１

Description

本発明は、業務課題を分析するシステムおよび業務課題分析を支援する技術に関し、特にコンピュータシステムの稼動情報に基づいて業務を分析し、業務を行っている現場に潜む業務課題を見つけ出すための分析を支援するシステムおよび支援方法に関し、特に、エラー情報の分析に関する。

コンピュータシステムが高価な時代には、業務効率向上がシステム化の第一の目的であり、その効果が高い業務から順にシステムが導入された。コンピュータシステムが普及した現在では、業務の大部分がシステム化されているが、業務によっては導入時期の異なる複数のシステムを組合せて行う必要があり、一度入力したデータをメモ帳にコピーして別のシステムに入れ直すケースや、ペーパーレスを目的に新しいシステムが導入されても、紙での運用がなくならないケースが見受けられる。業務を行っている現場では、こうした作業を当たり前に行っているため、作業者自身は問題として気付いていないことも多いが、エスノグラフィー等のユーザ分析の手法で見つけられている。
また、現場での業務実態を把握する別の方法として、コンピュータの稼動情報を利用して業務を可視化する試みも数多く報告されている。

特許文献１では、コンピュータシステムのデータの更新情報を用いて、時間の経過に伴う業務フロー（コンピュータシステムを利用した業務の流れ）の変化を分析し、変化内容を容易に把握することができる技術を提供している。

特開２００８−２２５８１４号公報

近年、業務の情報化が浸透し、業務効率よりも、業務の中で行われている人の創造活動を支援することで、新たな付加価値を生み出すシステム提案が求められている。そのためには、まず、現場の業務に潜んでいる「創造活動を妨げている要因・活発にする要因」を洗い出すことが必要である。

しかしながら、特許文献１に記載の技術では、コンピュータシステムの稼動状況から業務の流れの変化を把握することはできるが、現場に潜む問題を見つけることは難しいという課題がある。

本発明は以上の課題を鑑みてなされたものであり、コンピュータシステムの稼働状況を示すデータを分析することによって、システム利用者が現場で行っている業務に潜む問題を見つけ出すことができる技術を提供することを目的とする。

上記の課題を解決するために、本発明では、対象業務に関し、当該業務に関わる情報の分析において、複数の情報について、それらの属性を特定し、そのそれぞれの関連性、組合せを考慮して、その問題点となる要因の候補を特定するものである。

例えば、観察やインタビューから見つかった現場の業務課題に対して、その業務課題がコンピュータを利用したときにどのような事象として稼動データに表れるのかを分類した事象例と、その事象を見つけ出すための分析メニューと解析機能、可視化手段、データ収集手段を有するシステムを提供する。具体的には、分析対象として、「人」「業務」「時間」を示す情報を抽出し、これらの属性として、各情報に対応付けられたもしくは含まれるその「人」の経験年数や勤務地、その「業務」で利用する画面や作業所要時間、特定の日付や曜日などの「時間」特性を収集して分析する機能を備える。例えば、エラーを解析する場合、従来のエラー解析では、月ごとや日ごとのエラー件数やエラー種別を集計していたが、本発明では、どの業務をしていたときに発生したエラーなのか、そのときに並行して、または、同時に行っていた業務は何か、忙しさとエラーの発生との間に関係はあるのか、などについて、上述の属性を組合せて集計する手段を提供する。

本発明によれば、コンピュータシステムの稼動データから現場の業務課題の候補を見つけ出すことができるようになるため、その課題が適切かどうかをシステム利用企業に確認することや、エスノグラファーのような専門家が現場を調査する際に、適切な現場や時期を選んだりすることができるようになり、効率的な現場調査ができるようになり、更には、人の創造活動を支援し、新たな付加価値を生み出すシステム提案へとつなげることができるようになる。

本実施形態のシステム構成図である。 業務実態情報管理テーブルとユーザ管理テーブルの構成を示した図である。 経験年数管理テーブルと拠点管理テーブルと業務階層管理テーブルの構成を示した図である。 業務情報生成プログラムの処理の流れを示した図である。 作業所要時間情報テーブルの構成を示した図である 同時表示画面情報テーブルの作成手順と構成を示した図である。 画面表示情報生成プログラムの処理の流れを示した図である。 業務エラー情報管理テーブルの構成を示した図である。 業務エラー情報生成プログラムの処理の流れを示した図である。 業務課題の事象例を示した図である。 分析メニューと解析事例を示した図である。 解析機能の例を示した図である。 業務情報解析プログラムの処理の流れを示した図である。 解析結果可視化プログラムの処理の流れを示した図である。 分析の画面例を示した図である。 業務エラー要素管理テーブルと業務エラー分析情報テーブルの構成を示した図である。 エラー分析プログラムの処理の流れを示した図である。

以下、本発明の一実施形態を、コンピュータのシステム稼動データから、「人」「業務」「時間」に関する情報を収集してエラーを引き起こした要因を分析し、業務課題候補を見つけ出す例を、図面を用いて説明する。ここで、エラーとは、(a)システムが業務内容をチェックして業務上のエラーを判断する場合と、(b)業務上のエラーとしては想定されていない、システム動作上のエラーと、(c)システムではエラーと判断されないが、人が判断する業務上のエラーの３種類が想定できるが、ここではどの種別のエラーかは特定しない。

図１は、本実施形態のシステム構成図である。システム稼動データ１００は、業務の作業者が業務システムを利用した際のシステムログであり、例えば、利用者端末からアプリケーションサーバへのリクエストや、リクエストに対するサーバのレスポンスなどの情報である。こうしたシステムログは、通常はサーバが出力しているため、分析したい期間のシステムログをシステム稼動データ１００に格納しておく。ここではシステム稼動データとしてシステムログを想定しているが、分析に必要な情報を、サーバ・クライアント間のパケット情報から取り出すようにしても良い。業務情報２００は業務情報解析に使用する情報群であり、システム稼動データ１００に格納された情報を業務情報生成部５００が整形し、必要な情報を生成して業務情報２００に格納する。業務課題分析ノウハウ４００は「分析メニューと解析事例」、観察・インタビューなどの現場調査から得られた業務課題の事例と、データ分析により見える事象とを対応付けた「業務課題の事象例」、解析を行うための「分析軸」で構成されており、分析者は解析事例や課題候補の事象例を参考にして分析を行う。業務解析情報３００には、解析対象のデータを業務情報２００から読み出し、図１２に示す解析機能６０００を使用して解析を行った解析結果が格納されている。解析結果可視化部７００は業務解析情報３００に格納されている解析結果を、業務フロー上に重ねる形式や表形式など、ユーザが指定した形態で表示する。

図２は業務情報２００に格納されている業務実態情報管理テーブル２０１とユーザ管理テーブル２０２と、業務階層管理テーブル２０５の構成を示した図である。業務実態情報管理テーブル２０１は、人、業務、時間に分類されている。業務実態情報管理テーブル２０１のユーザＩＤは、システム利用者のユーザ毎に割り当てられたＩＤであり、ユーザ管理テーブル２０２に格納されているユーザＩＤと同じものである。作業ＩＤは、業務の設計時に、業務を構成する作業を定義するために付けられるが、定義されていない場合も多い。作業ＩＤがログに出力されていない場合は、画面ＩＤやＷＥＢ画面のＵＲＬなどを作業ＩＤとしても良い。作業開始／終了時刻が出力されていない場合は、画面のリクエスト／レスポンスタイムを作業開始時刻とし、作業終了時刻は次の作業の開始時刻と同じとする。作業の区切りとなる画面があり、その画面から遷移するボタンをクリックした、などの情報が得られる場合は、クリックを行った時刻を作業終了時刻とする。案件ＩＤが出力されていない場合は、空白とする。ユーザ管理テーブル２０２の所属組織や役職を、システム稼動データから取得することは難しいため、別システムで管理されている場合はその情報を利用するか、手作業で入力するものとし、データが得られない場合は空白とする。拠点情報も同様に、別システムの情報を利用するか手作業で入力してもよいが、ＩＰアドレスが端末の設置場所に応じて割り振られることを利用して、図３の２０４拠点管理テーブルに示すようにＩＰアドレスと拠点とを対応付けて管理し、システム稼動データに含まれる端末のＩＰアドレス情報から拠点情報を取得し、ユーザＩＤと対応付けてユーザ管理テーブル２０２に記録するようにしてもよい。拠点情報と同様に、ユーザ管理テーブル２０２の経験年数は、２０３経験年数管理テーブルの経験年数とリンクしている。業務階層管理テーブル２０５は業務を構成する作業の階層を管理するテーブルである。設計時などに業務機能階層図として作成されることもあるが、資料がない場合は現場の作業者へのインタビューや業務マニュアルから情報を得てテーブルを作成したり、業務フローから推測して作成したりする。また、プロセスマイニングの技術を用いて、作業間の関係を分析し、グループ化された作業を業務として位置づけるなどして自動的に生成しても良い。

図３は、業務情報２００に格納されている経験年数管理テーブル２０３と、拠点管理テーブル２０４の構成を示した図である。経験年数管理テーブル２０３には、ユーザＩＤとそのユーザのシステム利用開始日、システム最新利用日、利用年数が管理されている。経験年数管理テーブル２０３はシステムの利用年数を、その業務の経験年数と読み替えて、業務の経験年数による分析を行えるようにするためのテーブルであり、あるユーザＩＤの経験年数が更新されると、図２に示したユーザ管理テーブル２０２の経験年数も更新する。拠点管理テーブル２０４は、ＩＰアドレスと拠点とを対応付けて管理しているテーブルであり、この対応テーブルは、別システムで管理されている場合はその情報を利用するか、手作業で入力するものとし、データが得られない場合は空白とする。運用年数管理テーブル２０６は、システムの運用年数を管理するテーブルである。システム運用年数による変化や、システムが改定された直後からのデータの変動を分析する場合に使用する。月毎、曜日毎、などの時系列の分析は、カレンダ情報と作業開始／終了時刻を用いて分析を行う。

図４は、業務情報生成部５００内で動作する業務情報生成プログラム５０１の処理の流れを示した図である。起動すると、ステップ５１０においてシステム稼動データ１００から、業務実態情報管理テーブル２０１の項目に対応するデータ部分を抜き出し、ステップ５２０において、抜き出したデータをユーザＩＤ別に分類し、日付順に並び替え、実データＩＤを付与して、業務情報２００に実データとして格納する。

次に、ステップ５３０に進み、ユーザＩＤ毎に経験年数データを作成/更新する。まず、経験年数管理テーブル２０３にアクセスし、作成/更新の対象とするユーザＩＤの利用開始日が登録されているかどうかを確認する。利用開始日が登録されていない場合は、そのユーザＩＤのデータの中で一番古い作業開始時刻の日付を利用開始日として登録する。次に、一番新しい作業開始時刻の日付を最新利用日として更新する。最後に、最新利用日と利用開始日の差分を年単位で計算して、経験年数を更新する。ステップ５１０で抜き出したデータについて、すべてのユーザ分の経験年数を確認して、次のステップ５４０に進む。
ステップ５４０では、実データから、業務実態情報管理テーブル２０１の項目に対応するデータを抜き出す。項目に該当するデータが実データに含まれていない場合は、空白としてテーブルを作成し、業務情報２００に格納する。データ項目と一致するデータがない場合であっても、上述したように、画面を作業と解釈してデータを作成してもよい。

図５は、作業所要時間情報テーブル２００１の構成を示した図である。作業所要時間情報テーブル２００１はユーザ別、案件別、作業別に作業開始時刻と終了時刻、作業終了時刻と作業開始時刻の差分から算出した作業所要時間を管理している。
図６は、個々のユーザがそれぞれ複数の画面を使用して作業を行なっている状況を分析するためのデータを生成する手順と、この手順により生成される同時表示画面情報テーブルの構成を示した図である。なお、「同時」表示画面との用語を用いたが、表示や使用は必ずしも同時でなくともよい。画面表示状況２２０に示すように、あるユーザがa1の画面を時刻t1からt4まで表示し、a2の画面を時刻t2からt3まで表示し、a3の画面を時刻t3からt5まで表示していた場合を例に、図７の画面表示情報生成プログラム２２０１によって同時表示画面情報を生成する手順を説明する。まず、ステップ２２１０において、業務実態情報テーブル２０１から分析対象期間のデータを抜き出し、各画面の表示時刻と、そのときに表示した画面ＩＤを同時表示画面テーブル２２４に仮の情報として登録する。このときの仮の同時表示画面テーブル２２４を２２１とする。次に、ステップ２２２０において、仮の同時表示画面テーブル２２１に作業終了時刻を時刻順に挿入し、開始時刻より遅く、終了時刻のより早い部分に表示画面ＩＤを追加する。例えば、画面a1の終了時刻はt4のため、t4をt3の後ろに挿入し、t1とt4の間にあるt2とt3に表示画面ID a1を追加する。画面a2と画面a3についても同様にして行い、同時表示画面情報テーブル２２４を生成する。

図８は、業務エラー情報管理テーブル２１０の構成を示した図である。業務エラー情報管理テーブル２１０は業務実態情報管理テーブル２０１とほぼ同様の構成であるが、システム稼動データ１００からエラーに関連する情報を取り出したものであり、エラーが発生したときに表示されていた画面ＩＤ、同時表示画面ＩＤ、同時表示画面数とエラーが発生した時刻が格納されている。

図９は、業務エラー情報管理テーブル２１０を生成するエラー情報生成プログラム５５１の処理の流れを示した図である。起動すると、ステップ５６０において、システム稼動データ１００から業務エラー情報管理テーブル２１０の項目に対応するデータ部分を抜き出し、ステップ５７０において抜き出したデータをユーザID別に分類し、日付順に並び替え、実データIDを付与して、業務情報２００に実データとして格納する。次に、ステップ５８０において、同時表示画面情報テーブル２２４の時刻を参照して、エラー発生時刻以前の一番近い時刻での表示画面ＩＤと画面数を読み出し、ステップ５９０において、実データから、業務エラー情報管理テーブル２１０の項目に対応するデータを抜き出し、該当するデータが含まれていない場合は空白とし、ステップ２１１０で読み出した表示画面ＩＤと画面数を追加して業務エラー情報管理テーブル２１０に格納する。

図１０は、業務課題分析ノウハウ４００に格納されている業務課題の事象例４０２を示した図である。例えば、データ分析によって「複数の画面を同時に使用している」という事象が見つかった場合、その事象は「割り込みやかけもちが多い」という業務課題候補の事象として捉えることができ、更にその課題は、「現場による割り込み作業が頻繁に発生する」または「別の紙資料を見ながら入力している」などの観察でみつかる事象がおきている可能性があると捉えることができる。ある作業をしているときに電話による割り込みが入り、元の画面を開いたまま、別の画面を開いて電話での案件の作業を行い、その後、元の画面に戻る、という事象が実際に起きていた場合などである。データ分析で見つかる事象と、観察・インタビューで見つかる事象とは、１対１で対応しているわけではないため、実際には複数の事象を総合的に判断して課題候補をみつけていく必要があるが、課題候補がどういう事象として現れる可能性があるかが分かるため、データ分析を行う際の参考とすることができる。データ分析や観察・インタビューによるユーザ分析を行い、新しい課題候補と事象例が見つかった場合には、業務課題の事象例４０２を拡張していく。

図１１は、業務課題分析ノウハウ４００に格納されている分析メニューと解析事例４０３の例を示した図である。分析メニュー４０４の分析メニューを使用して現場の業務課題候補を見つけるため、図５に示した業務課題の事象例４０２の現場の業務課題候補に対応している。解析事例４０５には、課題候補を見つけるためにどのような解析を行ったらよいかの観点と解析方法が示されている。例えば、「割り込み作業・かけもち作業をみつける」という分析メニューには、「（業務フロー解析）で、流れの向きや流れの量が、マニュアル等に記載されている業務フローと異なる部分を見つける」「（エラー解析）でエラーが起こっている部分を見つける」という解析事例がある。分析者が選択した分析メニューに対応する解析事例を示すことにより、経験のない分析者のデータ分析を支援することができる。分析を行っていき、新しい課題候補と解析事例が見つかった場合には分析メニュー４０４と解析事例４０５を拡張していく。

図１２は業務情報解析部６００にて行うデータ解析の機能の例を示した図である。解析を行う際には、ここに示したすべての入力情報を用意する必要はないが、先頭に○印のある入力情報は必要である。例えば、業務フロー解析機能では、概要データとして、「日付」、「時刻」、「案件ＩＤ」、「業務ＩＤまたは作業ＩＤと次の作業ＩＤ」が組となったデータ群を入力とし、案件毎の業務または作業の順番を流れとし、案件として流れた件数を流量として出力する。ここで業務ＩＤまたは作業ＩＤとしているのは、一つの業務や作業は複数のステップから構成されており、夫々のステップをどこまで細かく記述するかによって、業務や作業の粒度が変わってしまうからである。作業レベルとその記述のしかたの標準を規定し、それに従うことで粒度を均一化することができるが、ここでは粒度は規定せず、業務は複数の作業から構成されているという階層のみを規定する。一般的なＷｅｂシステムでは、端末からサーバへの画面リクエスト（ＨＴＴＰリクエストのログ）、またはサーバからのレスポンス情報（アプリケーションサーバのインフォメーションログなど）がシステム稼動データ１００に入っている場合が多いため、画面を作業と解釈して、解析を行ってもよい。その場合、出力は画面遷移の経路と画面が表示された回数となるが、これを作業の流れと流量として解析を行う。「次の作業ＩＤ」が取得できている場合は、「作業ＩＤ」から「次の作業ＩＤ」に向かって作業が流れたことが分かるが、「次の作業ＩＤ」が取得できていない場合は、「案件ＩＤ」が同じ作業を時刻順に並べることで、作業の流れを解析する。ＨＴＴＰリクエストのように参照元の画面が分かる場合には、参照元の画面（ＵＲＬ）を「作業ＩＤ」とし、リクエストされた画面（ＵＲＬ）を「次の画面ＩＤ」として、作業の流れを解析する。

解析は一度で終わるものではなく、分析軸を用いてドリルダウンをしていく。ドリルダウンとは、多次元データベースのデータ分析を行なう際に、概要データから詳細データへと対象を絞り込んでいく分析手法である。業務フロー解析の場合は「日付」、「時刻」、「案件ＩＤ」、「業務ＩＤまたは作業ＩＤと次の作業ＩＤ」を概要データとして、業務や作業の流れや流量の全体像を可視化し、流れや流量の中で気になる部分があれば、その部分をドリルダウンして詳細な分析を行う。例えば、設計時の業務フローにはない流れが表示されており、その流れの詳細を分析したい場合、概要分析で用いた入力データを用いると、「年月日、曜日」別、「時分秒」別、「案件」別の流れや流量を見ることができるが、それに加えて、「経験年数」別、「拠点」別、「ユーザ」別の流れや流量をみることができる。これらの入力情報や分析軸を詳細分析に加えているのは、経験年数によって業務効率や質に差が出たり、拠点によって作業ルールが異なったりなど、業務経験の違いが出やすい傾向があるからである。

図１３は、業務情報解析部６００で動作する業務情報解析プログラム６０１の処理の流れを示した図である。ステップ６１０で、図６に示した分析メニュー４０４を画面に表示する。ユーザがプルダウン方式で分析メニューを選択する場合の画面例を図１１の分析メニューと解析事例から解析機能を選択する画面例８１０に示す。ユーザが分析メニューを選択すると、ステップ６２０において、そのメニューに対応する解析事例４０５を表示する。例えば、図１１の分析メニューと解析事例から解析機能を選択する画面例８１０において、ユーザは「割り込み作業・かけもち作業をみつける」という分析メニューを選択し、次に、その分析メニューの解析事例から「（所要時間解析）で流れが滞っている業務や作業をみつける」を選択する。ここでは、所要時間解析を行うため、ステップ６３０において、所要時間解析を起動し、その結果をステップ６４０において業務情報解析情報３００に格納する。

ステップ６３０にて起動する解析プログラムについては、データ分析を行うための様々な手法が公開されており、それらの解析プログラムを利用することを前提としているため、ここでは詳細な説明は省略する。解析プログラムの例を図１７のエラー分析プログラム６３０１に示す。

図１４は、解析結果可視化部７００で動作する解析結果可視化プログラム７０１の処理の流れを示した図である。ステップ７１０において業務解析情報３００から解析結果を読み出し、ステップ７２０において、解析結果を業務フロー解析の場合はフロー図で、その他の解析の場合は分析軸を表の項目とする表形式で、表示し、ステップ７３０に進む。ステップ７３０では、グラフ形式などの別の可視化表現用のデータを作成し、ステップ７４０においてステップ７３０で作成しておいた可視化可能な表示形式と分析軸の選択肢を表示し、ユーザが表示形式と分析軸を選択すると、ステップ７５０において選択された分析軸で解析結果を絞り込み、選択された表示形式で表示する。その後、ステップ７４０とステップ７５０を繰り返して、ユーザが表示形式や分析軸の選択を行うたびに、選択された表示形式と分析軸で解析した結果を表示することを繰り返す。

図１５は、分析の画面例を示した図である。これらの図を用いて、分析手順の概要を説明する。システム稼動データ１００から業務情報が生成され、業務情報２００に格納されているとする。分析者は、分析メニューを選択し、表示された結果を見ながら詳細分析を行っていく。まず、分析者が、図１５に示す分析メニューと解析事例から解析機能を選択する画面例８１０のように分析メニューからを「割り込み作業・かけもち作業をみつける」を選択すると、その分析メニューに必要な解析事例が表示され、解析事例から「（エラー解析）でエラーが発生している部分をみつける」を選択すると、解析機能が起動してエラー分析６３０１を行い、その結果を分析結果の表示例８２０のように表示する。分析結果の表示例８２０では、画面Ａを表示していて、かつ画面Ａと他の表示画面と合わせて３画面を同時に表示しているというケースが分析期間中に128件発生しており、そのうちの12件で、エラーＡという種類のエラーが発生したことを表している。発生率と共に件数も表示することにより、よく利用される業務の中で起きたのか、まれなケースなのかを判断することができる。

図１６に、エラー解析の考え方を示す。エラーを引き起こす要因はさまざまであり、要因が独立している場合もあれば、要因間の相関により確率が高まる場合もある。要因に相関があるかどうかを分析することは、分析者が考えた何通りかの組合せについて、エラーが発生している確率を計算するという方法で可能であるが、すべての要因の組み合わせについて分析者が試すことは、時間と労力がかかり、現実的ではない。しかし、分析者が考えなかったところに相関関係が発生している場合もあるため、要因同士の組合せによるエラー発生確率をコンピュータが計算し、計算結果を示すことにより、この分析を支援することが可能である。本発明では、エラー分析の要因として、作業者がある作業を行っている場合に、別の何かの作業の割り込みが入り、元の作業に復帰したときにエラーが起こりやすいというような、人の作業状況に関係するエラー発生率を提示することを目的としている。エラーの要因として、「複数の作業を行っているか」、「割り込まれた作業も含めると、その作業にどのくらいの時間をかけていたか」というような、従来のエラー分析では着目されていない要因の分析を支援する。

業務エラー要因管理テーブル３１０は、人の作業に着目した場合のエラーの要因の構成例を示している。エラーが起きたときの、ユーザＩＤ、画面ＩＤだけでなく、そのときに並行して表示していた別画面のＩＤ、並行して表示していた画面数、エラーを引き起こした画面の表示時間、なども要因の一つである。これらの要因に対し、実際にエラーが発生したときのユーザＩＤや画面ＩＤを要素とする。業務エラー要因Ａ１の要素管理テーブル３１１は要因Ａ１の各要素値の例を、業務エラー要因Ａ２の要素管理テーブル３１２は要因Ａ２の各要素値の例である。同様に、Ｂ１、Ｂ２などの要素番号に対応した要素管理テーブルがある。エラーが発生した場合、業務エラー分析情報テーブル３２０に示すように、同じ要素で構成された業務が発生していた回数と、同じ要素で構成された業務でエラーが発生した回数を数え、その発生件数と発生率を計算し、計算結果を表示する。ただし、同時表示画面数については、エラー要素値以上の数の画面を開いていた回数をカウントすることとする。分析者は、その発生率をみて、どの要素の組合せが重要なのかを判断し、エラー要因を推測することが可能となる。

図１７は、エラー分析プログラム６３０１の処理の流れを示した図である。起動すると、ステップ６３１０において、業務エラー情報管理テーブル２１０から業務エラー情報を読み込み、エラーが起きていたときの要素値を取り出し、業務エラー分析情報テーブル３２０に合致する要素があれば、その回数に１を加え、ない場合は新たな要素をその要因の管理テーブルに登録し、業務エラー分析情報テーブル３２０に回数を１として登録する。次に、ステップ６３２０において、業務実態管理情報２０１などの業務情報を読み込み、ステップ６３１０で取り出したエラー要素に合致するデータを取り出し、正常回数をカウントして業務エラー分析情報テーブル３２０に格納する。次に、ステップ６３３０において、エラー要素の正常回数とエラー回数から、エラー発生率を算出し、業務エラー分析情報テーブル３２０に格納する。すべての要素の組合せについて、ステップ63１0から6330を繰り返し、終了する。
このようにして、エラー要因として設定した要因の全ての要素の組合せについて、エラー発生件数と正常件数をカウントし、エラー発生率を算出する。

例えば、複数画面を開いている場合にエラー発生率が高いという分析結果が得られた場合、作業者が複数の作業を同時にこなしているために、別の案件の処理と入れ替えて処理してしまったり、別の作業から戻った際に、記憶していた内容を忘れてしまい、作業をやり直したために作業に時間がかかったり、ということが発生している可能性が考えられる。複数画面を開いている場合にエラー発生率が高いという事象が、割り込みやかけもちが多いという課題から発生している事象であるかどうかは確定できないが、時系列での案件数の推移や、複数画面を同時に利用しているのかなどの別のデータ分析を組み合わせることで確度を向上させることができる。

また、業務課題の事象例４０２を参照すると、観察でみつかる事象からは、電話による割り込みが頻繁に発生する、別の紙資料を見ながら入力している、などの事象が発生している可能性があることが分かる。例えば、コンタクトセンタの受付業務において、電話で受け付けた用件をデータ入力している最中に別の顧客から電話が入り、データ入力作業を中断して電話で応対した場合、聞き取った内容をメモしておき、あとでまとめてデータ入力作業を行う、というような流れになっている可能性も考えられる。このような可能性については、現場を観察したり、担当者へのインタビューを行わないと確認することができないが、システム利用者へのインタビューの材料としたり、専門家が調査を行う際の補助材料として活用することができる。

このようにして、分析者は分析メニューから分析を開始し、必要に応じて分析対象を絞り込み、データに表れる事象を確認するという作業を繰り返す。業務課題と事象は１対１で対応づけられるものではないため、分析者は複数の事象を総合的に判断して業務課題を発見していく必要がある。分析メニュー４０４と、業務課題の事象例４０２は対応しているため、業務課題の事象例４０２は、分析メニュー４０４を使用してどのような事象が見えそうか、また、分析メニュー４０４で分析した結果、見えた事象がどのような課題に結びつきそうかという参考情報とすることができる。

本実施形態により、システム利用者の潜在的な業務課題の候補をシステム稼動データから発見することが可能となり、システム利用者の視点での的確なシステム改善提案活動を行うことができるようになる。また、エスノグラフィーによるユーザ分析を行う前に、本実施形態を利用して現場調査を行うことにより、どこをいつ調査すればよいのかを知ることができるようになるため、効果的な調査活動ができるようになるという効果がある。

１００ システム稼動データ
２００ 業務情報
３００ 業務解析情報
４００ 業務課題分析ノウハウ
５００ 業務情報生成部
６００ 業務情報解析部
７００ 解析結果可視化部

Claims (6)

1. 業務遂行に当り当該業務の遂行状況を示す複数の情報を収集する手段と、
   収集された前記複数の情報のそれぞれを、当該情報の属性と対応付けて記憶する手段と、
   前記情報のうち、前記業務遂行上の問題となる情報および属性を特定する手段と、
   特定された属性について、当該属性と関連性を有する他の属性を特定して関連付けることで、前記問題の要因候補を特定する手段とを有することを特徴とする業務課題分析支援システム。
2. 請求項１に記載の業務課題分析支援システムにおいて、
   前記要因候補を表示する手段をさらに有し、
   前記表示する手段は、前記要因候補毎を選択的に表示可能であることを特徴とする業務課題分析支援システム。
3. 請求項２に記載の業務課題分析支援システムにおいて、
   前記複数の情報は、前記業務を実行する人、実行された時間および前記業務であり、
   前記属性は、前記人の経験年数および勤務地、前記時間における日付および曜日、前記業務で利用する画面および作業所要時間であることを特徴とする業務課題分析支援システム。
4. 業務遂行に当り当該業務の遂行状況を示す複数の情報を収集するステップと、
   収集された前記複数の情報のそれぞれを、当該情報の属性と対応付けて記憶するステップと、
   前記情報のうち、前記業務遂行上の問題となる情報および属性を特定するステップと、 特定された属性について、当該属性と関連性を有する他の属性を特定して関連付けることで、前記問題の要因候補を特定するステップとからなることを特徴とする業務課題分析支援方法。
5. 請求項４に記載の業務課題分析支援方法において、
   前記要因候補を表示するステップをさらに有し、
   前記表示するステップは、前記要因候補毎を選択的に表示可能であることを特徴とする業務課題分析支援方法。
6. 請求項５に記載の業務課題分析支援方法において、
   前記複数の情報は、前記業務を実行する人、実行された時間および前記業務であり、
   前記属性は、前記人の経験年数および勤務地、前記時間における日付および曜日、前記業務で利用する画面および作業所要時間であることを特徴とする業務課題分析支援方法。

Images