JP4984846B2 - 業務フロー管理プログラム、業務フロー管理装置、および業務フロー管理方法 - Google Patents

Description

本発明は複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理するための業務フロー管理プログラム、業務フロー管理装置、および業務フロー管理方法に関し、特に各部署の業務内容を定義した業務定義と依頼内容とを比較することで依頼された業務を振り分ける業務フロー管理プログラム、業務フロー管理装置、および業務フロー管理方法に関する。

複数の部署を有する組織（企業、官庁・自治体など）では、各部署の活動内容が定義される。以下、活動内容の定義情報を業務定義と呼ぶ。各部署では、業務定義に対応する業務を遂行する。このような業務定義を予めコンピュータシステムに設定しておけば、業務の振り分けをコンピュータシステムによって自動化することができる。

業務定義に関する技術としては、業務情報を収集し、分析する技術がある（たとえば、特許文献１参照）。また、業務に関する問い合わせを、その問い合わせを分類するための分類条件と比較して、業務に関する意思決定プロセスを決定する技術もある（たとえば、特許文献２参照）。
特開２００２−２２２３０７号公報 特開２００３−７６６８６号公報

しかし、従来の技術では、業務定義の不整合を検出することができなかった。たとえば、各部署の業務定義が不明確な場合や、部署間での連係が不十分で情報が共有されていない場合に、業務定義の不整合が発生しやすい。この場合、組織内の部署間で互いに業務範囲を知らず、重複した業務を行っていたり、どの組織も責任を持たない業務が生じたりといった弊害が発生する。その結果、組織外（他の組織、顧客、市民など）から問い合わせがあっても、どの部署がそれに責任を持って対応すべきか不明なため、依頼がいわゆる「たらい回し」になることも珍しくない。

なお、各部署の業務範囲が正確に定義されている場合でも、その後の各部署の責任範囲の変更に合わせて業務定義が改版されないことが多い。その結果、時間が経つにつれて業務定義が実態に合わなくなってしまう。これは、業務定義の記述は現場もしくは管理部門に任されており、業務定義の改版を確実に実施する仕組みがないことに起因している。

また、業務定義そのものが通常は曖昧な表現であり、誤解釈を生みやすい。その結果、業務定義に応じた業務の振り分けに関する正確性が損なわれていた。
さらに、組織の活動内容が明示されていないことで、組織内の構成員の責任意識が希薄になり、組織活動の品質が低下する危険性もある。

本発明はこのような点に鑑みてなされたものであり、業務定義の不整合を検出することができる業務フロー管理プログラム、業務フロー管理装置、および業務フロー管理方法を提供することを目的とする。

本発明では上記課題を解決するために、図１に示すような複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理する業務フロー管理装置１が提供される。 業務定義記憶手段１ａは、部署毎に、部署で実施する業務の内容を定義した業務定義を記憶する。案件処理履歴記憶手段１ｂは、業務を依頼する依頼案件の担当部署として指定された部署において依頼案件に対して行った処理を示す案件処理履歴を記憶する。案件入力受付手段１ｃは、依頼内容を指定した依頼案件の入力を受け付ける。担当部署判断手段１ｄは、案件入力受付手段１ｃに入力された依頼案件と、業務定義記憶手段１ａに記憶された業務定義とを比較して、依頼案件に示される依頼内容を包含する業務定義が設定された部署を検出し、検出した部署を依頼案件の担当部署と判断する。案件出力手段１ｅは、担当部署判断手段１ｄで判断された担当部署の担当者が使用する端末装置３に対して、依頼案件を送信する。受理判断取得手段１ｆは、担当部署の担当者が使用する端末装置３から、送信した依頼案件を受理するか否かを示す受理情報を取得し、依頼案件の識別情報に受理情報を関連付けた案件処理履歴を案件処理履歴記憶手段１ｂに格納する。是正対象部署検出手段１ｇは、案件処理履歴記憶手段１ｂに記憶された案件処理履歴に基づいて、不受理の依頼案件の数を不適切処理案件数に換算し、不適切処理案件数が所定値以上となった部署を検出する。

このような業務フロー管理装置１によれば、案件入力受付手段１ｃにより依頼案件の入力が受け付けられる。すると、担当部署判断手段１ｄにより、依頼案件と、業務定義記憶手段１ａに記憶された業務定義とが比較され、依頼案件に示される依頼内容を包含する業務定義が設定された部署が検出され、検出された部署が依頼案件の担当部署と判断される。次に、案件出力手段１ｅにより、担当部署の担当者が使用する端末装置３に対して、依頼案件が送信される。その後、受理判断取得手段１ｆにより、端末装置３から、送信した依頼案件を受理するか否かを示す受理情報が取得され、依頼案件の識別情報に受理情報を関連付けた案件処理履歴が案件処理履歴記憶手段１ｂに格納される。そして、是正対象部署検出手段１ｇにより、不受理の依頼案件の数が不適切処理案件数に換算され、不適切処理案件数が所定値以上となった部署が検出される。

本発明では、担当部署が依頼案件を受理したか否かを示す受理情報を案件処理履歴として格納し、不受理となった案件を含む不適切処理案件数が所定値以上となった部署を検出するようにしたため、実際に各部署で行われている業務と業務定義との間の不整合を検出することができる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、発明の概要を示す図である。業務フロー管理装置１は、複数の端末装置２，３に接続されている。図１の例では、端末装置２は、業務の依頼に使用される。また、端末装置３は、業務を遂行する部署において業務を受理するか否かの判断結果入力に使用される。

業務フロー管理装置１は、業務定義記憶手段１ａ、案件処理履歴記憶手段１ｂ、案件入力受付手段１ｃ、担当部署判断手段１ｄ、案件出力手段１ｅ、受理判断取得手段１ｆ、および是正対象部署検出手段１ｇを有している。

業務定義記憶手段１ａは、部署毎に、部署で実施する業務の内容を定義した業務定義を記憶する。業務定義は、たとえば、サービスを提供する対象の物品を特定するサービス対象、提供するサービスの内容を示すサービス内容、およびサービスを提供する地域を示すサービス先によって業務の内容が定義されている。

案件処理履歴記憶手段１ｂは、業務を依頼する依頼案件の担当部署として指定された部署において依頼案件に対して行った処理を示す案件処理履歴を記憶する。案件処理履歴には、各部署を担当部署として依頼案件が、その部署で受理されたか否かを示す受理情報や、他の部署に回送されたときの回送先を示す回送情報が含まれる。

案件入力受付手段１ｃは、依頼内容を指定した依頼案件の入力を受け付ける。たとえば、依頼する業務に関する対象の物品、提供を受けるサービスの内容、およびサービスの提供を受ける地域が指定される。

担当部署判断手段１ｄは、案件入力受付手段１ｃに入力された依頼案件と、業務定義記憶手段１ａに記憶された業務定義とを比較して、依頼案件に示される依頼内容を包含する業務定義が設定された部署を検出し、検出した部署を依頼案件の担当部署と判断する。組織が木構造の場合、担当部署判断手段１ｄは、木構造を辿りながら、依頼内容を包含する業務定義が設定された部署を探索する。

案件出力手段１ｅは、担当部署判断手段１ｄで判断された担当部署の担当者が使用する端末装置３に対して、依頼案件を送信する。たとえば、案件出力手段１ｅは、端末装置３から依頼案件の参照要求を受けた際に、端末装置３を使用する担当者の所属部署が担当部署となっている依頼案件を、端末装置３に送信する。

受理判断取得手段１ｆは、担当部署の担当者が使用する端末装置３から、送信した依頼案件を受理するか否かを示す受理情報を取得し、依頼案件の識別情報に受理情報を関連付けた案件処理履歴を案件処理履歴記憶手段１ｂに格納する。なお、依頼案件を受理しない場合、回送先の部署が指定されることがある。その場合、受理判断取得手段１ｆは、回送先の部署を示す回送情報を案件処理履歴に含める。

是正対象部署検出手段１ｇは、案件処理履歴記憶手段１ｂに記憶された案件処理履歴に基づいて、不受理の依頼案件の数を不適切処理案件数に換算し、不適切処理案件数が所定値以上となった部署を検出する。なお、不適切処理案件数には、該当部署へ他の部署から回送された依頼案件の数を追加してもよい。

このような業務フロー管理装置１によれば、案件入力受付手段１ｃにより依頼案件の入力が受け付けられる。すると、担当部署判断手段１ｄにより、依頼案件と、業務定義記憶手段１ａに記憶された業務定義とが比較され、依頼案件に示される依頼内容を包含する業務定義が設定された部署が検出され、検出された部署が依頼案件の担当部署と判断される。次に、案件出力手段１ｅにより、担当部署の担当者が使用する端末装置３に対して、依頼案件が送信される。その後、受理判断取得手段１ｆにより、端末装置３から、送信した依頼案件を受理するか否かを示す受理情報が取得され、依頼案件の識別情報に受理情報を関連付けた案件処理履歴が案件処理履歴記憶手段１ｂに格納される。そして、是正対象部署検出手段１ｇにより、不受理の依頼案件の数が不適切処理案件数に換算され、不適切処理案件数が所定値以上となった部署が検出される。

すなわち、本発明によれば、入力された依頼案件データと各部署の業務定義が比較され、依頼案件の依頼内容を包含する業務定義を有する部署が担当部署とされる。ここで、業務定義が不正確であれば、依頼案件の依頼内容が、実際には担当部署と判断された部署の業務外の場合がある。その場合、担当部署において、依頼案件を受理しない旨の判断が行われる。受理するか否かの判断結果は案件処理履歴として記憶されるため、各部署における不受理の判断回数をカウントできる。このような不受理の案件（不適切処理案件）の件数が多い部署は、その部署の業務定義そのものが業務の実態に合わないと判断できる。

業務定義が業務の実態に合わない部署に対しては、たとえば、業務定義を是正するように促す（是正勧告）ことができる。このような是正勧告を行うことにより、是正勧告を受けた部署は受け付けた案件の履歴を元に、自部署の業務定義を修正できる。

その結果、案件処理を通じて業務定義をタイムリーに更新することができる。すなわち、業務の実態に合わない業務定義を直ぐに是正することができる。
また、本発明により、組織内の業務分担を明確に定義できる。すなわち、業務定義の不整合が迅速に修正されることで、業務定義の正確性が担保される。その結果、依頼案件の振り分けの間違いの回数（後に回送される回数）を低減することができる。これは、組織内外からの問い合わせに対して（たらい回しすることなく）迅速に処理できることでもある。

なお、依頼案件の受理情報に応じて、業務定義を自動で更新することもできる。たとえば、各部署で受理された依頼案件の依頼内容を、受理した部署の前記業務定義に追加することができる。また、各部署で受理しなかった依頼案件の依頼内容を、受理しなかった部署の業務定義から除外することができる。これにより、複雑な業務定義を直接入力する必要がなく、日常の業務で案件を処理してゆけば自動的に業務定義が更新され、各部署の担当者の作業負担が軽減される。

また、複数の動作モードを設けておくこともできる。動作モードとしては、初期記憶モードと通常モードとが用意される。
初期記憶モードでは、組織の中で処理すべき依頼案件を作成し、それを処理するにふさわしい最適な部署を探し、その見つけた部署で案件を処理する。その際、その案件の特徴（サービス対象、サービス内容、サービス先）をその処理部署の業務定義として記憶する。なお、依頼案件をどの部署で処理すべきなのかは、電話、口コミ、指示など組織内の多様な手段で検索・決定されるものとする。

このような複数の案件を処理し、各部署の業務定義を記憶し終わった後、業務定義に従って案件を処理する通常モードに切り替えられる。
通常モードでは、入力された依頼案件データと各部署の業務定義を比較し、依頼案件の依頼内容を包含する業務定義が検出されたときに、その業務定義に対応する部署で案件が処理される。案件と業務定義が一致したが、他の部署に回送した場合、あるいは他部署から案件を回送された場合は、次の修正記憶（再記憶）処理が実行される。

修正記憶処理では、他に回送した案件、あるいは他から回送された案件の要件を抽出し、その部署の業務定義にその案件の特徴を追加／削除する。
次に、本実施の形態の詳細を説明する。

［第１の実施の形態］
図２は、本実施の形態のシステム構成例を示す図である。本実施の形態では、業務フロー管理サーバ１００に対して、ネットワーク１０を介して複数のクライアント２１，２２，２３，・・・が接続されている。業務フロー管理サーバ１００は、予め登録された業務定義に基づいて、業務依頼の担当部署への振り分けを行う。また、業務フロー管理サーバ１００は、ユーザからの指示に応答して、振り分けられた業務依頼の他の部署への転送を管理する。そして、業務フロー管理サーバ１００は、業務依頼の転送状況を監視することで、業務依頼の不整合を検出し、業務定義の是正勧告を行う。

クライアント２１，２２，２３，・・・は、ユーザが使用するコンピュータである。ユーザは、クライアント２１，２２，２３，・・・を操作して、依頼された業務を処理する。また、ユーザは、クライアント２１，２２，２３，・・・を操作することで、業務フロー管理サーバ１００に対して業務依頼の転送指示を行うことができる。

図３は、本実施の形態に用いる業務フロー管理サーバのハードウェア構成例を示す図である。業務フロー管理サーバ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。

通信インタフェース１０６は、ネットワーク１０に接続されている。通信インタフェース１０６は、ネットワーク１０を介して、他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には業務フロー管理サーバ１００のハードウェア構成を示したが、クライアント２１，２２，２３，・・・も同様のハードウェアで実現できる。

図４は、業務フロー管理サーバの機能を示すブロック図である。業務フロー管理サーバ１００は、業務定義データベース（ＤＢ）１１０、案件ＤＢ１２０、案件処理履歴ＤＢ１３０、業務定義入力・確認部１４１、案件入力部１４２、案件・業務定義比較部１４３、案件受理部１４４、案件出力部１４５、および業務定義是正処理部１４６を有している。

業務定義ＤＢ１１０は、業務定義を記憶するデータベースである。たとえば、ＨＤＤ１０３の記憶領域の一部が、業務定義ＤＢ１１０として使用される。
案件ＤＢ１２０は、依頼案件を記憶するデータベースである。たとえば、ＨＤＤ１０３の記憶領域の一部が、案件ＤＢ１２０として使用される。

案件処理履歴ＤＢ１３０は、案件処理履歴を記憶するデータベースである。たとえば、ＨＤＤ１０３の記憶領域の一部が案件処理履歴ＤＢ１３０として使用される。
業務定義入力・確認部１４１は、クライアント２１，２２，２３，・・・から各部署の業務定義の入力を受け付け、入力された業務定義を業務定義ＤＢ１１０に格納する。また、業務定義入力・確認部１４１は、クライアント２１，２２，２３，・・・からの操作入力に応じて、業務定義ＤＢ１１０に格納された業務定義を修正する。

案件入力部１４２は、クライアント２１，２２，２３，・・・から、具体的な業務の依頼をするための操作入力を受け付ける。そして、案件入力部１４２は、入力内容に基づいて依頼案件情報を作成する。作成された依頼案件情報は、案件・業務定義比較部１４３に渡される。

案件・業務定義比較部１４３は、案件入力部１４２から依頼案件情報を取得し、取得した依頼案件情報と業務定義ＤＢ１１０内の各部署の業務定義とを比較する。そして、案件・業務定義比較部１４３は、依頼案件情報で示される業務を処理すべき部署を決定する。また、案件・業務定義比較部１４３は、依頼案件情報を案件受理部１４４に渡すとともに、決定した部署への回送指示を案件受理部１４４に通知する。

案件受理部１４４は、取得した依頼案件情報を案件ＤＢ１２０に格納する。また、案件受理部１４４は、ユーザからの依頼案件の受理通知または回送通知を受け付ける。案件受理部１４４は、回送通知が入力された場合、依頼案件情報の回送先を、回送通知で指定された部署に変更する。また、案件受理部１４４は、依頼案件の受理または回送の処理結果を、案件処理履歴として案件処理履歴ＤＢ１３０に格納する。

案件出力部１４５は、クライアント２１，２２，２３，・・・からの依頼案件取得要求に応じて、依頼案件情報を送信する。
業務定義是正処理部１４６は、案件処理履歴ＤＢ１３０に格納された業務情報をもとに、業務定義が実状に合っていない部署を特定し、その部署に対して業務定義の是正を勧告する。是正勧告は、たとえば、該当部署のユーザあてに是正勧告を示す電子メールを送信する。

このような構成の業務フロー管理サーバ１００によって、企業等の組織における各部署に対する業務依頼の振り分けが行われる。
図５は、組織の構成を示す図である。複数の部署３１〜３５によって組織が構成されている。図中、左にある部署ほど、上位の部署である。通常は上の部署は下部の部署の責任をまとめて負うことになる。

企業や団体など組織の部署間の関係は、ツリー型（ピラミッド型）で表現される。部署間には上下関係と横関係がある。上位の部署と線で接続された下位の部署との関係が、上下関係である。また、上位の部署を共有する複数の部署（たとえば、部署３１の下位の部署３２，３３）同士の関係が、横関係である。

各部署３１〜３５には、部署名が示されている。また、各部署３１〜３５には、その部署に設定された業務定義と案件処理履歴とが関連付けられる。実際には、業務定義は業務定義ＤＢ１１０に格納され、案件処理履歴は案件処理履歴ＤＢ１３０に格納される。

依頼案件でエントリ・アドレスとして示された部署（図５の例では部署３１）が、その依頼案件の最初の回送先となる。そして、エントリ・アドレスで指定された部署３１を基点として、依頼する業務に該当する業務定義を有する部署の探索が行われる。

このような組織に対する業務依頼を振り分ける場合、予め各部署の業務定義を業務定義ＤＢ１１０に格納しておく。
図６は、業務定義の例を示す図である。業務定義ＤＢ１１０には、部署毎の業務定義情報１１１，１１２，１１３，・・・が格納されている。

本実施の形態では、すべての業務を「対象（製品）」、「その対象に対する具体的なサービス内容」、「顧客」の３つの次元で表現する。それぞれを、Ｏ、Ｓ、Ｃで表現しておく。

業務定義情報１１１，１１２，１１３，・・・には、部署名と１以上の業務定義とが設定される。業務定義は、サービス対象、サービス内容、サービス先の三項目で表される。
たとえば、第二サービス部の業務定義情報１１１の１つめの業務定義として、サービス対象「製品Ｚ」、サービス内容「保守サービス」、サービス先「ＡＬＬ」が設定されている。これは、「第二サービス部は製品Ｚの保守サービスをすべての顧客に提供する」ということを表している。

また、第二サービス部の業務定義情報１１１の２つめの業務定義として、サービス対象「製品Ｗ」、サービス内容「保守サービス」、サービス先「東京地区顧客」、「横浜地区顧客」が設定されている。これは、「第二サービス部は、製品Ｗの保守サービスを東京地区と横浜地区の顧客に提供する」ということを表している。このように一つの部署に複数の業務定義を設定できる。

なお、業務定義が設定されると、設定された業務定義に基づいて業務定義一覧表が作成され、業務定義ＤＢ１１０に格納される。
図７は、業務定義一覧表のデータ構造例を示す図である。業務定義一覧表１１０ａは、全部署の業務定義を一つの表に纏めたものである。業務定義一覧表１１０ａには、部署名、部署アドレス、業務定義番号、サービス対象、サービス内容、およびサービス先の欄が設けられている。各欄の横方向に並べられた情報同士が関連付けられ、１つの業務定義を構成する。

部署名の欄には、業務定義に示される業務を行う部署の名称が設定される。部署アドレスの欄には、部署を一意に識別するためのアドレスが設定される。業務定義番号の欄には、同一業務定義情報内の個々の業務定義を識別するための識別番号が設定される。サービス対象の欄には、サービス対象とする製品名が設定される。サービス内容の欄には、提供されるサービスの内容が設定される。サービス先の欄には、サービスを提供する地域（地理的な範囲の指定）が設定される。

このように、各部署毎の業務定義が業務定義ＤＢ１１０に格納される。すると、部署間の連係が不十分な場合などに、業務内容の重複や、どの部署もサービスを提供しない業務（業務の空白）が発生する。この例では、第二サービス部の業務定義（業務定義番号「１」）と、顧客サービス本部の業務定義（業務定義番号「１」）との間で、製品Ｚの保守サービスにおいて、顧客が重なっている。業務定義は各部署が独立に記述するため、このような業務定義の重複は避けられない。

各部署の業務定義の設定が完了した後、業務依頼が行われ、依頼案件が生成される。依頼案件は、案件ＤＢ１２０に格納される。
図８は、依頼案件のデータ構造例を示す図である。依頼案件１２１，１２２，１２３，・・・には、案件番号、エントリ・アドレス、サービス対象、サービス内容、サービス先、案件詳細、および担当部署アドレスの各項目が設定されている。これらの項目に設定された情報により、業務を依頼するための基本的な帳票（伝票）が示される。

案件番号の項目には、依頼案件を一意に識別するための番号（案件番号）が設定される。案件番号は、案件入力部１４２によって採番された番号である。
エントリ・アドレスの項目には、業務の依頼者が組織構成の上で最初の依頼先として指定した部署のアドレスが設定される。もし特定の窓口部署が見当たらない場合は、ユーザはルート（組織の最上部）をエントリ・アドレスとする。

サービス対象の項目には、サービスを受ける製品の製品名が設定される。サービス内容の項目には、提供を希望するサービスの内容が設定される。サービス先の項目には、顧客の所在する地域の名称が設定される。図８の例では、サービス対象「製品Ｚ」、サービス内容「保守サービス」、サービス先「横浜地区顧客」である。これは、「横浜地区の顧客に対する製品Ｚの保守サービスについて依頼」する依頼案件であることを示している。

案件詳細の項目には、業務の依頼内容の詳細が設定される。たとえば、顧客の名称や、その顧客が顧客サービス本部によるサービス先の特定顧客に該当するか否かなどの情報を設定することができる。

担当部署アドレスの項目には、依頼案件が回送された部署の部署アドレス（担当部署アドレス）が設定される。担当部署アドレスは、依頼案件が入力された際に、案件・業務定義比較部１４３によって設定される。また、担当部署の担当者から回送の指示が出されると、案件受理部１４４によって回送先が判断され、依頼案件の担当部署アドレスの値が、回送先の部署の部署アドレスに更新される。

このような依頼案件が、依頼内容に対応する業務定義が設定された部署に回送される。そして、回送先の部署において、業務が処理されたか、あるいは他の部署に回送されたといった情報が、案件処理履歴として案件処理履歴ＤＢ１３０に格納される。

図９は、案件処理履歴のデータ構造例を示す図である。案件処理履歴ＤＢ１３０には、部署毎の案件処理履歴１３１，１３２，１３３，・・・が格納されている。案件処理履歴１３１，１３２，１３３，・・・には、大別すると、部署名、適切処理総案件数、および不適切処理総案件数も項目が設けられている。

部署名の項目には、案件処理履歴に対応する部署の名称が設定される。
適切処理総案件数の項目には、適切処理案件数と下部署適切処理案件数との項目が含まれている。また、適切処理案件数には、適切処理として判断された依頼案件の案件番号が関連付けられている。適切処理案件数の項目には、部署名で示される部署で処理した依頼案件の数が、適切処理案件数（ｐａ）として設定される。下部署適切処理案件数の項目には、部署名で示される部署の下位の部署で処理した依頼案件の数が、下部署適切処理案件数（ｐｂ）として設定される。適切処理総案件数の項目には、適切処理案件数と下部署適切処理案件数との合計値が、適切処理総案件数（ｐ）として設定される。

不適切処理総案件数の項目には、不適切処理案件数と下部署不適切処理案件数との項目が含まれている。また、不適切処理案件数には、回送処理案件数と被回送処理案件数との項目が設けられている。回送処理案件数の項目には、他の部署へ回送された依頼案件の案件番号が関連付けられている。同様に、被回送処理案件数の項目には、他の部署から回送されてきた依頼案件の案件番号が関連付けられている。

回送処理案件数の項目には、他の部署へ回送された依頼案件の数が、回送処理案件数（ｑ１）として設定される。被回送処理案件数の項目には、デフォルトの窓口から回送されてきた依頼案件の数が、被回送処理案件数（ｑ２）として設定される。不適切処理案件数の項目には、回送処理案件数と被回送処理案件数との合計値が、不適切処理案件数（ｑａ）として設定される。

下部署不適切処理案件数の項目には、部署名で示される部署の下位の部署に回送されたが不適切と判定された依頼案件の数が、下部署不適切処理案件数（ｑｂ）として設定される。

不適切処理総案件数の項目には、不適切処理案件数と下部署不適切処理案件数との合計値が、不適切処理総案件数（ｑ）として設定される。
このように、案件処理履歴１３１，１３２，１３３，・・・は、ある部署について、案件がどのように処理されたかを記録したものである。なお、本実施の形態では、一つの部署の適切処理総案件数として、該当部署の適切処理案件数と、その部署の下に位置する部署群の適切処理案件数との総数の和を設定している。これは、各部署は、その下位の部署の処理に責任をもつことを意味している。不適切処理の総案件数についても同様に、該当部署の不適切処理案件数と、その部署の下に位置する部署群の不適切処理案件数との総数の和を設定している。

なお、依頼案件が案件受理部１４４に渡されると、その依頼案件の案件処理履歴が生成され、案件処理履歴ＤＢ１３０の案件処理履歴一覧表内に設定される。
図１０は、案件処理履歴一覧表のデータ構造例を示す図である。案件処理履歴一覧表１３０ａは、全部署の案件処理履歴を一つの表に纏めたものである。案件処理履歴一覧表１３０ａには、案件番号、受付日／時刻、処理部署名、該当した業務定義番号、処理結果、および処理時刻の欄が設けられている。各欄の横方向に並べられた情報同士が関連付けられ、１つの案件処理履歴を構成する。

案件番号の欄には、依頼案件に設定された案件番号が設定される。受付日／時刻の欄には、依頼案件を受け付けた日時が設定される。処理部署名の欄には、依頼案件の担当部署として判断された部署の名称が設定される。該当した業務定義番号の欄には、処理部署名に示される部署を担当部署と判断する根拠となった業務定義の業務定義番号が設定される。処理結果の欄には、処理部署名で示される部署による処理結果が設定される。処理時刻の欄には、処理部署名で示される部署で依頼案件に関する処理を行った時刻が設定される。

たとえば、案件番号「１２３」の案件は、日時「XX:XX:XX」に第二サービス部で受け付けられた。ところが、第二サービス部では適切な処理ができないと判断されて、結局、時刻「YY:YY:YY」に顧客サービス本部に回送されている。この案件番号「１２３」は日時「ZZ:ZZ:ZZ」に顧客サービス本部で受け付けられ、日時「WW:WW:WW」にその内容に応じた業務が行われた。

案件番号「３２１」の案件は、いったん第一サービス部で受け付けられたが、適切な処理ができないと判断されて、Default窓口に回送されている。その後、デフォルト窓口で適切な処理部署を探し、第二サービス部に回送された。

図１１は、依頼案件の回送例を示す図である。図１１に示す依頼案件１２２は、製品Ｚの東京地区顧客に対する保守サービスに関するものである。エントリ・アドレスとして、製品本部が指定されている。そこで、案件・業務定義比較部１４３では、製品本部から依頼案件を担当する部署の探索を行う。

この例では、案件・業務定義比較部１４３は、製品本部の業務定義「ａ１」と、依頼案件の内容とを比較し、一致しないと判断している。そこで、案件・業務定義比較部１４３は、下層部署である製品サービス部門の業務定義に依頼案件１２２が参照される。

案件・業務定義比較部１４３は、製品サービス部門の業務定義「ａ１１」と依頼案件１２２の内容とを比較し、一致しないと判断している。そこで、さらに下層の部署に依頼案件１２２の業務定義が参照される。

案件・業務定義比較部１４３は、第一サービス部の業務定義「ａ１１１」と依頼案件１２２の内容とを比較し、一致しないと判断している。ここで、第一サービス部には下位の部署が存在しないため、横関係の部署である第二サービス部に依頼案件１２２の業務定義が参照される。

案件・業務定義比較部１４３は、第二サービス部の業務定義「ａ１１２」と依頼案件１２２の内容とを比較し、一致すると判断し、第二サービス部を受け付け部署としている。
第二サービス部の担当者は、依頼案件１２２の具体的な内容をクライアントを用いて参照する。この例では、担当者は、依頼案件１２２で求められている業務が第二サービス部の業務ではないと判断している。この場合、第二サービス部の担当者が、依頼案件１２２で依頼されている業務を遂行すべき部署を知っていたならば、その部署（この例では、顧客サービス本部）へこの依頼案件１２２の回送を指示する。この指示は、案件受理部１４４で受け取られ、依頼案件が顧客サービス本部に回送される。

第二サービス部の担当者がしかるべき部署を知らない場合（担当者からの回送先の指定が無い場合）は、案件受理部１４４はデフォルト窓口（未処理の案件を何でも受け付ける部署）へ依頼案件１２２を回送する。

デフォルト窓口の担当者は、クライアントで依頼案件の内容を参照し、組織の中でしかるべき部署を探し、そこへの回送指示を入力する。回送指示は、クライアントから案件受理部１４４に送られる。案件受理部１４４は、デフォルト窓口の担当者からの回送指示に応じて、指示された部署へ依頼案件を回送する。

なお、依頼案件１２２が入力された際に、案件・業務定義比較部１４３がすべての部署の業務定義を参照しても、依頼案件１２２を処理できる部署が見つからない場合は、案件・業務定義比較部１４３によってデフォルト窓口に依頼案件１２２が回送される。その後の回送先は、デフォルト窓口の担当者が判断する。

次に、上記のような依頼案件の回送処理と、案件処理履歴の生成処理手順を説明する。
図１２は、第１の実施の形態における処理手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。第１の実施の形態における処理は、前処理（ステップＳ１１，Ｓ１２）、メイン処理（ステップＳ１３〜Ｓ１６）、後処理（ステップＳ１７，Ｓ１８）に分かれる。前処理は、実行に必要な初期データを用意するものである。前処理としては、各部署の業務定義の入力受け付け、各部署の業務定義に基づく業務定義一覧表の作成が行われる。メイン処理では、具体的な依頼案件の作成、それを組織ツリー上での回送、各業務定義を比較して一致したときにその部署での受け付け確認、依頼案件の処理結果の案件処理履歴への反映が行われる。後処理では、案件が処理される度に処理履歴が参照され、業務定義を更新する必要がある部署の特定、その部署に対する更新勧告、業務定義の更新が行われる。

［ステップＳ１１］各部署の担当者は、クライアントを指定して業務フロー管理サーバ１００にアクセスし、自己の部署の業務範囲を示す情報の入力操作を行う。すると、業務フロー管理サーバ１００の業務定義入力・確認部１４１が入力内容に応じて業務定義を生成し、その業務定義を業務定義ＤＢ１１０に格納する。

［ステップＳ１２］業務定義入力・確認部１４１は、設定された業務定義の部署間の重複の有無を確認する。業務定義入力・確認部１４１は、業務定義の重複があれば、該当部署の担当者に是正勧告を行う。

［ステップＳ１３］営業などの担当者は、クライアントを用いて業務フロー管理サーバ１００にアクセスし、顧客からの業務の依頼内容の入力操作を行う。すると、業務フロー管理サーバ１００の案件入力部１４２は、入力された業務の依頼内容に応じた依頼案件を作成し、案件・業務定義比較部１４３に渡す。

［ステップＳ１４］案件・業務定義比較部１４３は、受け取った依頼案件の依頼内容と、業務定義ＤＢ１１０に登録された業務定義とを比較し、依頼内容に応じた業務定義を判断する。そして、案件・業務定義比較部１４３は、依頼内容に応じた業務定義に対応する部署を担当部署と設定する。依頼案件を案件受理部１４４に渡す。案件受理部１４４は、依頼案件を案件ＤＢ１２０に格納する。そして、案件出力部１４５が、担当部署からの依頼案件参照要求に応じて、依頼案件の内容を担当者の使用するクライアントに送信する。

［ステップＳ１５］案件受理部１４４は、担当部署の担当者から回送指示があれば、依頼案件を他の部署に回送する。また、案件受理部１４４は、担当部署、あるいは回送先の部署から案件受理の情報を受け取ると、その依頼案件の回送処理を終了する。

［ステップＳ１６］案件受理部１４４は、依頼案件を受け取ってから、いずれかの部署で受理判断されるまでの案件処理履歴に基づいて、案件処理履歴を更新する。
［ステップＳ１７］業務定義是正処理部１４６は、案件処理履歴ＤＢ１３０を参照し、担当部署として指定されながら、他の部署に回送した依頼案件数が所定数を超えている部署を検出する。該当部署が見つかった場合、業務定義是正処理部１４６は、該当部署の担当者宛に業務定義の是正勧告を行う。

［ステップＳ１８］業務定義入力・確認部１４１は、是正勧告を受けた担当者の使用するクライアントから業務定義の更新の操作入力を受け取ると、その操作入力に応じて業務定義の内容を更新する。

次に、図１２に示した各処理について詳細に説明する。
図１３は、業務定義の入力処理の手順を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。

［ステップＳ２１］業務定義入力・確認部１４１は、業務定義ＤＢ１１０の業務定義を初期化する。具体的には、業務定義入力・確認部１４１は、全部署の業務定義について、サービス対象、サービス内容、サービス先の欄を”Ａｌｌ”に設定する。これにより、各部署において、すべての業務が処理対象となる。

［ステップＳ２２］業務定義入力・確認部１４１は、クライアント２１，２２，２３，・・・を介して、各部署の担当者から、所属する部署が取り扱う業務のサービス対象、サービス内容、サービス先の入力を受け付ける。業務定義入力・確認部１４１は、入力内容に応じて、業務定義ＤＢ１１０内の各部署の業務定義の内容を更新する。

図１４は、業務定義の確認処理の手順を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳ３１］業務定義入力・確認部１４１は、各部署の業務定義を参照し、部署名、部署アドレス、業務定義番号、サービス対象、サービス内容、およびサービス先を、業務定義一覧に設定する。なお、業務定義入力・確認部１４１には、部署名と部署アドレスとの対応関係が予め登録されており、部署名に基づいて、その部署の部署アドレスを特定できる。

［ステップＳ３２］業務定義入力・確認部１４１は、サービス対象、サービス内容、サービス先をキーとして、業務定義一覧表に設定されている各業務定義をソートする。これにより、類似する業務定義が一覧表中で近くに設定される。その結果、業務定義一覧表を参照した際に、業務定義の重複や、業務の抜けなどを見つけやすくなる。

［ステップＳ３３］業務定義入力・確認部１４１は、サービス対象、サービス内容、サービス先のすべてが一致する複数の部署が存在するか否かを判断する。サービス対象、サービス内容、サービス先が同一の部署が複数ある場合、処理がステップＳ３４に進められる。サービス対象、サービス内容、サービス先が一致する複数の部署が存在しない場合、処理が終了する。

［ステップＳ３４］業務定義入力・確認部１４１は、ステップＳ３３で検出された複数の部署のうち、上下関係にある部署を除外する。これは、上層の部署の定義が配下の部署の定義を包含する場合には、業務定義の重複を許容するためである。

［ステップＳ３５］業務定義入力・確認部１４１は、ステップＳ３４で除外されなかった部署の担当者宛に、電子メールによって業務定義の更新勧告を送付する。なお、業務定義入力・確認部１４１には、各部署の担当者の電子メールアドレスは予め登録されている。その後、処理が終了する。

図１５は、依頼案件作成処理の手順を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
［ステップＳ４１］案件入力部１４２は、顧客から業務処理の依頼を受けた営業担当者の使用するクライアントに対して、依頼案件入力画面を表示する。

［ステップＳ４２］案件入力部１４２は、前回入力された依頼案件の案件番号をメモリ内に記憶している。そして、案件入力部１４２は、案件番号に１を加算して、新たに生成する依頼案件の案件番号とする。案件番号は、依頼案件の案件番号の項目に設定される。

［ステップＳ４３］案件入力部１４２は、クライアントから、最初に依頼案件を送付したい部署の選択入力を受け付ける。具体的には、案件入力部１４２は、業務定義ＤＢ１１０から業務定義一覧表１１０ａを取得し、クライアントの画面に表示させる。担当者は、クライアントの画面に表示された業務定義を閲覧し、依頼案件の送付先とすべき部署を選択する。案件入力部１４２は、選択された部署の部署アドレスを業務定義一覧表１１０ａから取得し、依頼案件のエントリ・アドレスに設定する。担当者から送付先の部署の指定が無い場合、案件入力部１４２は、組織のトップの部署のアドレスを、エントリ・アドレスに設定する。

［ステップＳ４４］案件入力部１４２は、クライアントから、依頼内容に関するサービス対象、サービス内容、サービス先の入力を受け付ける。たとえば、案件入力部１４２は、クライアントに表示した業務定義一覧表１１０ａ内の１つの業務定義が選択された場合、選択された業務定義のサービス対象、サービス内容、サービス先を、依頼内容と判断する。案件入力部１４２は、クライアントから指示された依頼内容を、依頼案件の依頼内容として設定する。

［ステップＳ４５］案件入力部１４２は、クライアントから依頼業務の詳細内容の入力を受け付ける。案件入力部１４２は、入力された詳細内容を、依頼案件の案件詳細の項目に設定する。

図１６は、案件の担当部署判定処理の手順を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
［ステップＳ５１］案件・業務定義比較部１４３は、依頼案件のエントリ・アドレスに送付する。具体的には、依頼案件の担当部署アドレスに、エントリ・アドレスを設定する。

［ステップＳ５２］案件・業務定義比較部１４３は、担当部署アドレスで示される担当部署の業務定義を業務定義ＤＢ１１０から取得し、参照する。
［ステップＳ５３］案件・業務定義比較部１４３は、担当部署の業務定義と、依頼案件の示す依頼内容とを比較する。具体的には、案件・業務定義比較部１４３は、業務定義と依頼案件との、サービス対象、サービス内容、およびサービス先を比較し、依頼内容を業務定義が包含するか否かを判断する。業務定義が一致すれば、処理がステップＳ５４に進められる。業務定義が一致しなければ、処理がステップＳ５５に進められる。

［ステップＳ５４］案件・業務定義比較部１４３は、現在の担当部署の設定を確定し、依頼案件を案件受理部１４４に渡す。その後、処理が終了する。
［ステップＳ５５］案件・業務定義比較部１４３は、下層の部署が存在するか否かを判断する。下層の部署が存在する場合、処理がステップＳ５６に進められる。下層の部署が存在しない場合、処理がステップＳ５７に進められる。

［ステップＳ５６］案件・業務定義比較部１４３は、現在の担当部署の下層の部署を１つ選択し、選択した部署を担当部署とし、担当部署の部署アドレスを依頼案件の担当部署アドレスに設定する。その後、処理がステップＳ５２に進められる。

［ステップＳ５７］案件・業務定義比較部１４３は、横組織が存在するか否かを判断する。具体的には、案件・業務定義比較部１４３は、最初に、現在の担当部署の横部署の有無を判断する。案件・業務定義比較部１４３は、現在の担当部署の横部署があれば、そのうちの１つの部署を選択する。案件・業務定義比較部１４３は、現在の担当部署の横部署がなければ、１つ上位の部署の横組織の有無を判断する。以後同様に、案件・業務定義比較部１４３は、横部署が見つかるまで組織の木構造を上位に辿っていく。横部署が見つかった場合、処理がステップＳ５８に進められる。横部署が見つからなかった場合、処理がステップＳ５９に進められる。

［ステップＳ５８］案件・業務定義比較部１４３は、ステップＳ５７で検出された横部署の１つを選択し、選択した部署を担当部署とし、担当部署の部署アドレスを依頼案件の担当部署アドレスに設定する。そして、案件・業務定義比較部１４３は、依頼案件を案件受理部１４４に渡す。その後、処理がステップＳ５２に進められる。

［ステップＳ５９］案件・業務定義比較部１４３は、デフォルト窓口を担当部署に設定する。すなわち、案件・業務定義比較部１４３は、デフォルト窓口に予め設定されたアドレスを担当部署アドレスに設定する。そして、案件・業務定義比較部１４３は、依頼案件を案件受理部１４４に渡す。その後、処理が終了する。

このようにして、依頼案件を処理すべき部署が、エントリ・アドレスの部署から順に探索される。探索は、各部署の業務定義と依頼案件を比較して、サービス対象、サービス内容、サービス先が一致するかによって判定される。依頼案件と一致する業務定義を持つ部署が見つかれば、その部署が担当部署に決定される。

もし依頼案件と業務定義が一致しない場合はさらに下層の部署が探索され、最下端に至れば横関係にある部署が探索される。もしすべての部署を探索しても業務定義と一致しない場合はデフォルト窓口が担当部署として設定される。

図１７は、案件の受理処理の手順を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
［ステップＳ６１］案件受理部１４４は、案件・業務定義比較部１４３から渡された依頼案件を受け付け、案件ＤＢ１２０に格納する。その際、案件受理部１４４は、案件処理履歴ＤＢ１３０の案件処理履歴一覧表１３０ａに対して、受け付けた依頼案件に対応する案件処理履歴のレコードを追加登録する。その際、案件番号の欄に依頼案件の案件番号を設定し、依頼案件を受け付けた日時を受付日／時刻の欄に設定し、処理部署名の欄に、担当部署アドレスに対応する部署名を設定する。また、案件受理部１４４は、案件・業務定義比較部１４３が依頼案件の担当部署を決定する原因となった業務定義の業務定義番号を案件・業務定義比較部１４３から取得し、該当した業務定義番号の欄に設定する。この時点では、処理結果の欄と処理時刻の欄は空欄である。

そして、案件出力部１４５が、各部署の担当者が使用するクライアントからの依頼案件参照要求に応じて、その依頼案件をクライアントに送信する。具体的には、案件出力部１４５は、依頼案件参照要求に含まれる部署名に基づいて、その部署の部署アドレスが担当部署アドレスに設定されている依頼案件を案件ＤＢ１２０から検索する。そして、案件出力部１４５は、検出された依頼案件をクライアントに送信する。

［ステップＳ６２］案件受理部１４４は、依頼案件参照要求に応じて送信された依頼案件に関し、デフォルト窓口からの回送案件か否かを判断する。デフォルト窓口からの回送案件の場合、処理をステップＳ６３に進める。デフォルト窓口からの回送案件でなければ、処理がステップＳ６５に進められる。

［ステップＳ６３］案件受理部１４４は、案件処理履歴ＤＢ１３０内の担当部署の案件処理履歴にアクセスし、被回送処理案件数（ｑ２）に１を加算する。
［ステップＳ６４］案件受理部１４４は、案件処理履歴ＤＢ１３０内の担当部署の案件処理履歴にアクセスし、被回送処理案件数（ｑ２）に関連付けて、受け付けた依頼案件の案件番号を登録する。

［ステップＳ６５］案件受理部１４４は、クライアントを介して担当部署の担当者から、依頼内容を受理することが妥当か否かを示す操作入力を受け付ける。すなわち、担当者は、クライアントに依頼案件の依頼内容を表示し、詳細内容に基づいてその依頼案件を自身の部署で受理すべきか否かを判断する。そして、担当者は、判断結果をクライアントに入力する。すると、クライアントから業務フロー管理サーバ１００に判断結果が送信される。

案件受理部１４４は、クライアントから送られた判断結果によって、依頼案件が受理されたか否かを認識する。依頼案件が受理された場合、処理がステップＳ６６に進められる。依頼案件が受理されなかった場合、処理がステップＳ６９に進められる。

［ステップＳ６６］案件受理部１４４は、現在の担当部署における案件の受理を確定する。たとえば、案件受理部１４４は、案件ＤＢ１２０に登録されている受理された依頼案件に対して、受理済みのフラグを設定する。

［ステップＳ６７］案件受理部１４４は、案件処理履歴ＤＢ１３０内の担当部署の案件処理履歴にアクセスし、適切処理案件数（ｐａ）に１を加算する。
［ステップＳ６８］案件受理部１４４は、案件処理履歴ＤＢ１３０内の担当部署の案件処理履歴にアクセスし、適切処理案件数（ｐａ）に関連付けて、受け付けた依頼案件の案件番号を登録する。その後、処理が終了する。

［ステップＳ６９］案件受理部１４４は、クライアントを介して担当部署の担当者から、回送先として妥当な部署が存在するか否かを示す操作入力を受け付ける。すなわち、担当者は、依頼案件を自身の部署で受理すべきでないと判断した場合、その依頼案件を処理すべき妥当な部署を知っていれば、その部署の部署名をクライアントに入力する。すると、クライアントから業務フロー管理サーバ１００に部署名が送信される。

案件受理部１４４は、クライアントから送られた部署名によって、回送先として妥当な部署を認識する。回送先として妥当な部署が指定された場合、処理がステップＳ７０に進められる。回送先として妥当な部署が指定されなかった場合、処理がステップＳ７３に進められる。

［ステップＳ７０］案件受理部１４４は、回送先として指定された部署に依頼案件を回送する。具体的には、案件受理部１４４は、依頼案件の担当部署アドレスの項目に、回送先の部署の部署アドレスを設定する。

［ステップＳ７１］案件受理部１４４は、案件処理履歴ＤＢ１３０内の回送前の担当部署の案件処理履歴にアクセスし、回送処理案件数（ｑ１）に１を加算する。
［ステップＳ７２］案件受理部１４４は、案件処理履歴ＤＢ１３０内の回送前の担当部署の案件処理履歴にアクセスし、回送処理案件数（ｑ１）に関連付けて、受け付けた依頼案件の案件番号を登録する。その後、処理が終了する。

［ステップＳ７３］案件受理部１４４は、デフォルト対応窓口に依頼案件を回送する。具体的には、案件受理部１４４は、依頼案件の担当部署アドレスの項目に、デフォルト対応窓口の部署アドレスを設定する。

［ステップＳ７４］案件受理部１４４は、案件処理履歴ＤＢ１３０内の回送前の担当部署の案件処理履歴にアクセスし、回送処理案件数（ｑ１）に１を加算する。
［ステップＳ７５］案件受理部１４４は、案件処理履歴ＤＢ１３０内の回送前の担当部署の案件処理履歴にアクセスし、回送処理案件数（ｑ１）に関連付けて、受け付けた依頼案件の案件番号を登録する。その後、処理が終了する。

このようにして、依頼案件の受理、または回送が行われる。すなわち、デフォルト窓口から回送されてきた案件ならば、自部署の被回送処理案件数がカウントアップされる。その依頼案件の詳細内容を担当者が解読し、自部署で処理できるか否かが判断される。もし受理したときは、自部署の適切処理案件数がカウントアップされる。受理しない場合であって、担当者が妥当な他部署を知っている場合はその部署に依頼案件が回送される。その際、自部署の回送処理案件数がカウントアップされる。また、担当者が妥当な他部署を知らない場合はデフォルト窓口に依頼案件が回送される。この場合にも、自部署の回送処理案件数がカウントアップされる。

図１８は、案件処理履歴の更新処理の手順を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。なお、この処理は、案件の処理（回送または受理）が行われる度に実行される。

［ステップＳ８１］案件受理部１４４は、組織の最下層の部署を探索し、その部署の案件処理履歴を参照する。
［ステップＳ８２］案件受理部１４４は、参照している案件処理履歴の変数「ｐｐ」と「ｑｑ」とに０を設定する。

［ステップＳ８３］案件受理部１４４は、下部署適切処理案件数（ｐｂ）にｐｐの値を代入する（ｐｂ←ｐｐ）。
［ステップＳ８４］案件受理部１４４は、下部署不適切処理案件数（ｑｂ）にｑｑを代入する（ｑｂ←ｑｑ）。

［ステップＳ８５］案件受理部１４４は、参照部署の適切処理案件数（ｐａ）と下部署適切処理案件数（ｐｂ）とを合計し、その合計値を適切処理案件数（ｐ）に代入する（ｐ←ｐａ＋ｐｂ）。

［ステップＳ８６］案件受理部１４４は、参照部署の不適切処理案件数（ｑａ）と下部署不適切処理案件数（ｑｂ）とを合計し、その合計値を不適切処理案件数（ｑ）に代入する（ｑ←ｑａ＋ｑｂ）。ただし、不適切処理案件数（ｑａ）は、回送処理案件数（ｑ１）と被回送処理案件数（ｑ２）とを加算した値である（ｑａ＝ｑ１＋ｑ２）。

［ステップＳ８７］案件受理部１４４は、現在の参照部署の未処理の横部署が存在するか否かを判断する。未処理の横部署が存在すれば、処理がステップＳ８８に進められる。未処理の横部署が存在しなければ、処理がステップＳ８９に進められる。

［ステップＳ８８］案件受理部１４４は、ステップＳ８７で検出された横部署の案件処理履歴を参照する。その後、処理がステップＳ８１に進められる。
［ステップＳ８９］案件受理部１４４は、上位の部署が存在するか否かを判断する。上位の部署が存在すれば、処理がステップＳ９０に進められる。上位の部署が存在しなければ、処理が終了する。

［ステップＳ９０］案件受理部１４４は、ステップＳ８９で検出された上位の部署の案件処理履歴を参照する。
［ステップＳ９１］案件受理部１４４は、参照している部署の下位の部署すべての適切処理案件数（ｐ）を取得し、それの合計値をｐｐに代入する。

［ステップＳ９２］案件受理部１４４は、参照している部署の下位の部署すべての不適切処理案件数（ｑ）を取得し、それの合計値をｑｑに代入する。その後、処理がステップＳ８３に進められる。

このようにして、すべての部署に関する案件処理履歴が更新される。すなわち、組織の最下層の部署が探索され、その部署の適切処理案件数と不適切処理案件数とが設定される。最下層の部署から順次、上位の部署が探索され、その部署の適切／不適切処理案件数と、下部組織分の適切／不適切処理案件数が加算される。したがって、ある部署の適切／不適切処理案件数は下部組織の処理案件数を含んでいる。これは、上位の部署が下位の部署の適切／不適切処理案件の責任を負うことを意味している。この処理が組織全体で繰り返される。

図１９は、業務定義の更新勧告処理の手順を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］業務定義是正処理部１４６は、現在の参照部署配下の最下層の部署を探索し、検出した部署（参照部署）の案件処理履歴を参照する。

［ステップＳ１０２］業務定義是正処理部１４６は、不適切処理総案件数（ｑ）が予め設定されている閾値（Ｔ１）より大きいか否かを判断する。不適切処理案件数が閾値より大きければ、処理がステップＳ１０３に進められる。不適切処理案件数が閾値以下であれば、処理がステップＳ１０４に進められる。

［ステップＳ１０３］業務定義是正処理部１４６は、参照部署に対して、業務定義の更新勧告を送付する。具体的には、業務定義是正処理部１４６は、参照部署の担当者あてに、業務定義の更新を促すメッセージを電子メールによって送信する。

［ステップＳ１０４］業務定義是正処理部１４６は、未処理の参照部署の横部署が存在するか否かを判断する。未処理の横部署が存在する場合には、処理がステップＳ１０５に進められる。未処理の横部署が存在しない場合には、処理がステップＳ１０６に進められる。

［ステップＳ１０５］業務定義是正処理部１４６は、横部署を参照部署とする。その後、処理がステップＳ１０１に進められる。
［ステップＳ１０６］業務定義是正処理部１４６は、上位の部署が存在するか否かを判断する。上位の部署が存在しなければ処理が終了する。上位の部署が存在すれば、処理がステップＳ１０７に進められる。

［ステップＳ１０７］業務定義是正処理部１４６は、上位の部署を参照部署とする。その後、処理がステップＳ１０２に進められる。
このようにして、案件処理履歴および案件処理履歴一覧表を参照して、不適切処理案件数がある閾値Ｔ１を超えた部署を検出できる。検出された部署は業務定義が適正に記述されていないと判断され、その部署の担当者に対して業務定義の更新を促す通知が自動送付される。この処理が組織全体にわたって実行される。

図２０は、業務定義の更新処理の手順を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。
［ステップＳ１１１］業務定義入力・確認部１４１は、各部署の担当者が使用するクライアントから、自部署（部署名によって指定）の案件処理履歴の参照要求を受け取ると、その案件処理履歴をクライアントに送信する。すると、クライアントで案件処理履歴が表示される。担当者は、表示された案件処理履歴を参照する。ここで、部署の担当者は、業務定義の更新に使用する依頼案件（回送処理案件または被回送処理案件）を指定し、業務定義の自動更新指示をクライアントに入力する。すると、クライアントから業務フロー管理サーバ１００に、依頼案件を指定した業務定義更新要求が送られ、以下の処理が実行される。

［ステップＳ１１２］業務定義入力・確認部１４１は、業務定義更新要求で指定された依頼案件が回送処理案件であれば、その案件番号ｎ（ｎは、案件番号を示す自然数）を取得する。次に、業務定義入力・確認部１４１は、案件処理履歴一覧表１３０ａから、取得した案件番号ｎに対応する案件処理履歴を参照する。そして、業務定義入力・確認部１４１は、案件番号ｎの案件処理履歴におけるサービス対象、サービス内容、サービス先を取得し、それぞれＳｎ、Ｏｎ、Ｃｎとする。

［ステップＳ１１３］業務定義入力・確認部１４１は、案件処理履歴一覧表１３０ａの案件番号ｎの案件処理履歴から該当した業務定義番号ｉ（ｉは、業務定義番号を示す自然数）を取得する。

［ステップＳ１１４］業務定義入力・確認部１４１は、業務定義ＤＢ１１０内の担当者の所属部署（ステップＳ１１１において指定された部署名によって判断）の業務定義情報を参照し、業務定義番号ｉの業務定義を取得する。次に、業務定義入力・確認部１４１は、取得した業務定義のサービス対象、サービス内容、サービス先を、それぞれＳｉ、Ｏｉ、Ｃｉとする。そして、業務定義入力・確認部１４１は、Ｓｉ、Ｏｉ、ＣｉのいずれもＡｌｌでない場合、自部署の業務定義番号ｉの業務定義を削除する。

［ステップＳ１１５］業務定義入力・確認部１４１は、Ｓｉ、Ｏｉ、Ｃｉのいずれか１つがＡｌｌの場合、自部署の業務定義番号ｉの業務定義に対してＳｎ、Ｏｎ、Ｃｎを除外する設定を行う。具体的には、業務定義入力・確認部１４１は、Ａｌｌと設定されたＳｉ、Ｏｉ、Ｃｉのいずれか１つに対して、新たなＳｉ＝”Ａｌｌ”−Ｓｎ、Ｏｉ＝”Ａｌｌ”−Ｏｎ、またはＣｉ＝”Ａｌｌ”−Ｃｎの設定を行う。

［ステップＳ１１６］業務定義入力・確認部１４１は、業務定義更新要求で指定された依頼案件が被回送処理案件であれば、その案件番号ｍ（ｍは、案件番号を示す自然数）を取得する。次に、業務定義入力・確認部１４１は、案件処理履歴一覧表１３０ａから、取得した案件番号ｍに対応する案件処理履歴を参照する。業務定義入力・確認部１４１は、参照した案件処理履歴におけるサービス対象、サービス内容、サービス先を取得し、それぞれＳｍ、Ｏｍ、Ｃｍとする。

［ステップＳ１１７］業務定義入力・確認部１４１は、業務定義ＤＢ１１０内の担当者の所属部署（ステップＳ１１１において指定された部署名によって判断）の業務定義情報、および業務定義一覧表１１０ａに対して、業務定義を追加する。そして、業務定義入力・確認部１４１は、追加した業務定義のサービス対象、サービス内容、サービス先として、それぞれＳｍ、Ｏｍ、Ｃｍを設定する。その後、処理が終了する。

このようにして、業務定義更新の勧告を受け取った部署では、自部署の業務定義を更新できる。すなわち、自部署から他部署に回送された案件に記入されたサービス対象、サービス内容、サービス先を含まないように、自部署の業務定義が書き直される。また、自部署に回送されてきた（被回送処理）案件に記入されたサービス対象、サービス内容、サービス先を含むように、自部署の業務定義が書き直される。

次に、業務定義の更新例を具体的に説明する。
図２１は、案件処理履歴の例を示す図である。図２１には、第二サービス部の案件処理履歴１３２の例が示されている。この例では、ある時点での適切処理数は１０５件であり、自部署で処理したもの５５件、下部組織で処理したもの５０件である。不適切な処理は３０件で、自部署で処理したもの２０件、下部組織で処理したもの１０件である。自部署での不適切処理は他部署に回送したもの１５件、他部署から回送されてきたもの５件である。回送処理案件の案件番号は「１２３」、「２３４」などである。被回送処理案件の案件番号は「３２１」などである。

このような案件処理履歴当家情報１３２を参照すれば、回送処理案件で指定された業務の内容を業務定義から除外し、被回送処理案件で指定された業務を業務定義に含めることで、不適切処理を減らすことができる。

図２２は、業務定義の更新例を示す図である。この例では、第二サービス部の案件処理履歴１３２の回送処理案件として登録された依頼案件４１は、サービス対象が「製品Ｚ」、サービス内容が「保守サービス」、サービス先が「東京地区特定顧客」である。すなわち、業務定義一覧表１１０ａでは、第二サービス部と顧客サービス本部との間で、処理業務の重複がある。そのため、製品Ｚに関する東京地区の特定顧客への保守サービスが、第二サービス部と顧客サービス本部との両方の業務定義に含まれてしまう。

ここで、実際の業務の振り分けとして、顧客サービス本部が製品Ｚに関する東京地区の特定顧客への保守サービスを行うことになっているものとする。その場合、製品Ｚに関する東京地区の特定顧客への保守サービスに関する依頼案件の担当部署として、第二サービス部が設定されると、その依頼案件は第二サービス部の担当者によって顧客サービス本部に回送される。すると、該当する依頼案件の案件番号が、第二サービス部の案件処理履歴当家情報１３２の回送処理案件に設定される。

この回送処理の結果、第二サービス部の不適切処理案件数が閾値を超えると、第二サービス部の担当者へ業務定義の是正勧告が送付される。そこで、第二サービス部の担当者の使用するクライアントから、回送案件の案件番号を指定して業務定義の更新要求が出されると、業務フロー管理サーバ１００において第二サービス部の業務定義が更新される。具体的には、案件番号に基づいて、案件処理履歴一覧表１３０ａを参照すると、該当した業務定義番号「１」が得られる。そこで、第二サービス部の業務定義情報１１１内の業務定義番号「１」の業務定義が参照される。

該当する業務定義は、サービス対象が「製品Ｚ」、サービス内容が「保守サービス」、サービス先が「Ａｌｌ」である。この業務定義から、依頼案件４１で示される依頼内容を除外するために、サービス先が「Ａｌｌ」から「Ａｌｌ−東京地区特定顧客」に変更される。

また、第二サービス部には他の部署から回送されてきた依頼案件４２がある。この依頼案件は、サービス対象「製品Ｘ」、サービス内容「設計サービス」、サービス先「横浜地区顧客」である。この被回送依頼案件を指定した更新要求がクライアントから業務フロー管理サーバ１００に出されると、業務フロー管理サーバ１００では、依頼案件４２に対応する新たな業務定義を。業務定義番号「４」として追加する。

図２３は、業務定義更新後の業務定義一覧表を示す図である。図２３の業務定義一覧表１１０ａを、図７に示す更新前と比較すると、第二サービス部のサービス先が「Ａｌｌ」から「東京地区の特定顧客を除くＡｌｌ」に変更されている。これにより、第二サービス部と顧客サービス本部との間の業務の重複が解消されている。

また、図２３では、第二サービス部の業務定義番号「４」の業務定義として、サービス対象「製品Ｘ」、サービス内容「設計サービス」、サービス先「横浜地区顧客」が追加されている。これにより、以後は、図２２に示した依頼案件４２と同じ内容の依頼案件に対して、第二サービス部が担当部署と判断される。

なお、顧客サービス本部では業務定義に沿って正しく案件を処理したので、特に業務定義の変更は行わない。
以上のように、依頼案件の回送状況を案件処理履歴として記録しておくことにより、各部署の担当者に対して業務定義の変更を指示することができる。また、案件処理履歴を用いることで、各部署の業務定義を容易に変更することが可能である。すなわち、他の部署への回送案件に基づいて、その依頼案件で示される業務を除外するように業務定義を変更できる。また、他の部署からの被回送案件に基づいて、その依頼案件で示される業務を業務定義に追加することができる。

ところで、上記の例では依頼案件で示される依頼内容を包含する業務定義が設定された部署を検出すると、まずその部署を担当部署として決定している。しかし、業務定義の重複がある場合、依頼案件の依頼内容を包含する業務定義が設定された部署が複数存在することがある。その場合、依頼案件で示される依頼内容とすべての部署の業務定義とを比較して、依頼内容を包含する部署を列挙するようにしてもよい。

図２４は、依頼案件を処理可能な部署のすべてを列挙する例を示す図である。この例では、エントリ・アドレスから下の部署すべてを検索し、依頼案件で示される依頼内容に一致する業務定義を有する部署を候補部署として一覧表に列挙する。組織全体を検索対象とするには、エントリ・アドレスとして、組織の頂点（ルート）の部署アドレスを指定すればよい。

図２４の例では、依頼案件１２２で指定された依頼内容に対応する業務定義が、第二サービス部と顧客サービス本部に設定されている。そのため、案件・業務定義比較部１４３が依頼案件の業務内容を包含する業務定義が設定された部署を、エントリ・アドレスから下の組織のすべてから探索する。そして、案件・業務定義比較部１４３は、該当する部署を候補部署の一覧表に列挙する。

案件・業務定義比較部１４３は、その列挙された部署内の適当な一部署を、担当部署として設定し、案件受理部１４４に依頼案件１２２を渡す。すると、案件出力部１４５によって担当部署の担当者へ依頼案件１２２が渡され、その担当者によって依頼案件１２２を受理するか否かが判断される。

最初に指定された担当部署が受理しない場合は、案件受理部１４４は、その部署の担当者の使用するクライアントに候補部署の一覧を表示する。そして、案件受理部１４４は、候補部署の中から次の回送先とする部署の選択入力を受け付け、選択された部署に依頼案件１２２を回送する。

図２４の例では、本来正しくない部署（第二サービス部）が担当部署として設定されたが、候補部署の一覧に基づいて、第二サービス部の担当者は、顧客サービス本部が適切な担当部署であると認識できる。そこで、第二サービス部の担当者からの操作入力に応じて、依頼案件１２２が、顧客サービス本部に回送される。

このように候補部署の一覧を表示させることで、正しい部署を早い段階で知ることができる。
また、処理方法によれば、業務定義の確認処理（図１２のステップＳ１２）を行わずにすむ。すなわち、この処理方法では、前処理段階では業務定義の重複を許容しているため、業務定義の確認処理で業務定義の更新勧告を行う必要なない。ただし、最終的には業務定義の重複をなくすことが必要であるため、後処理において業務定義の更新勧告が行われる。

［第２の実施の形態］
第２の実施の形態は、業務定義を記憶するモードを持つものである。すなわち、メイン処理と後処理において、初期記憶モードと通常モードとが用意されている。初期記憶モードでは、業務定義の学習が行われ、通常モードでは学習した業務定義の更新が行われる。

図２５は、第２の実施の形態の業務フロー管理サーバの機能を示すブロック図である。第２の実施の形態に係る業務フロー管理サーバ２００は、業務定義データベース（ＤＢ）２１０、案件ＤＢ２２０、案件処理履歴ＤＢ２３０、業務定義設定部２４１、案件入力部２４２、案件・業務定義比較部２４３、案件受理部２４４、および案件出力部２４５を有している。業務定義データベース（ＤＢ）２１０、案件ＤＢ２２０、案件処理履歴ＤＢ２３０、案件入力部２４２、案件・業務定義比較部２４３、案件受理部２４４、および案件出力部２４５の機能については、図４に示した第１の実施の形態に係る業務フロー管理サーバ１００の同名の要素とほぼ同じである。

業務定義設定部２４１は、依頼案件の処理状況に応じて業務定義を自動設定する。
以下、第１の実施の形態と異なる機能について説明する。
図２６は、第２の実施の形態における案件ＤＢのデータ構造例を示す図である。案件ＤＢ２２０には、案件番号、エントリ・アドレス、サービス対象、サービス内容、サービス先、案件詳細、および担当部署アドレスの欄が設けられている。これは、図８に示した依頼案件１２１，１２２，１２３，・・・の内容を表形式で表したものであり、実質的には同じものである。

図２７は、第２の実施の形態における処理手順を示すフローチャートである。以下図２７に示す処理をステップ番号に沿って説明する。この処理は、前処理（ステップＳ１２１）、メイン処理（ステップＳ１２２〜Ｓ１２７）、後処理（ステップＳ１２８〜Ｓ１３０）の３段階で行われる。

［ステップＳ１２１］業務定義設定部２４１は、各部署の業務定義、案件処理履歴をすべて初期化する。
［ステップＳ１２２］案件入力部２４２は、クライアントからの入力に応じて、依頼案件を作成する。作成された依頼案件は、案件・業務定義比較部２４３に入力される。

［ステップＳ１２３］案件・業務定義比較部２４３は、動作モードを判断する。動作モードには、初期記憶モードと通常モードとがある。現在の動作モードは、業務定義設定部２４１が管理するメモリに記憶されている。業務定義設定部２４１は、システムの運用開始時には、初期記憶モードで動作を開始する。そして、業務定義設定部２４１は、初期記憶モードの終了条件（たとえば、処理された依頼案件数が所定の閾値を超えたこと）を満たした場合に、動作モードを通常モードに変更する。案件・業務定義比較部２４３は、業務定義設定部２４１から動作モードを取得し、現在の動作モードを判断する。動作モードが初期記憶モードの場合、処理がステップＳ１２４に進められる。動作モードが通常モードの場合、処理がステップＳ１２５に進められる。

［ステップＳ１２４］初期記憶モードの場合、案件・業務定義比較部２４３は、入力された依頼案件を適切な部署に直接送付する。その後、処理がステップＳ１２６に進められる。

［ステップＳ１２５］通常モードの場合、案件・業務定義比較部２４３は、依頼案件で示される依頼内容を包含する業務定義が設定された部署を、組織ツリー上で部署を辿っていくことで探索する。そして、案件・業務定義比較部２４３は、該当する部署を担当部署と判定する。すなわち、案件・業務定義比較部２４３は、依頼案件で示される依頼内容を包含する業務定義を検出すると、その業務定義の部署アドレスの値を依頼案件の担当部署アドレスに設定する。この処理の詳細は、図１６に示した第１の実施の形態の処理と同様である。

［ステップＳ１２６］案件受理部２４４は、案件・業務定義比較部２４３から依頼案件を受け取り、案件ＤＢ２２０に格納する。その後、案件出力部２４５が、各部署の担当者が使用するクライアントからの要求に応じて、その担当者が所属する部署を担当部署とする依頼案件をクライアントに送信する。そして、案件受理部１４４は、担当部署の担当者から回送指示があれば、依頼案件を他の部署に回送する。また、案件受理部１４４は、担当部署、あるいは回送先の部署から案件受理の情報を受け取ると、その依頼案件の回送処理を終了する。この処理の詳細は、図１７に示した第１の実施の形態の処理と同様である。

［ステップＳ１２７］案件受理部２４４は、依頼案件を受け取ってから、いずれかの部署で受理判断されるまでの案件処理履歴に基づいて、案件処理履歴を更新する。
［ステップＳ１２８］業務定義設定部２４１は、動作モードを判定する。動作モードが初期記憶モードであれば、処理がステップＳ１２９に進められる。動作モードが通常モードであれば、処理がステップＳ１３０に進められる。

［ステップＳ１２９］動作モードが初期記憶モードの場合、業務定義設定部２４１は、案件が処理される度に案件処理履歴を参照し、処理された依頼案件で示される依頼内容を、その依頼案件を処理した部署の業務定義として、業務定義ＤＢ２１０に格納する。その後、処理が終了する。

［ステップＳ１３０］動作モードが通常モードの場合、業務定義設定部２４１は、案件が処理される度に案件処理履歴を参照し、他部署への案件の回送、あるいは他部署からの案件の回送を示す案件処理履歴に基づいて、該当部署の業務定義を更新する。その後、処理が終了する。

次に、第２の実施の形態における処理を詳細に説明する。
図２８は、業務定義の初期化処理の詳細を示すフローチャートである。
［ステップＳ１４１］業務定義設定部２４１は、すべての部署の業務定義のすべての項目を”空”に設定する。

図２９は、案件の直送処理の詳細を示すフローチャートである。
［ステップＳ１５１］案件・業務定義比較部２４３は、依頼案件をエントリ・アドレスに送付する。すなわち、案件・業務定義比較部２４３は、依頼案件のエントリ・アドレスを担当部署アドレスに設定することで、エントリ・アドレスで指定された部署を担当部署とする。

図３０は、業務定義の記憶処理の手順を示すフローチャートである。以下、図３０に示す処理をステップ番号に沿って説明する。
［ステップＳ１６１］業務定義設定部２４１は、すべての部署に対して、ステップＳ１６２〜Ｓ１６６の処理を実行する。

［ステップＳ１６２］業務定義設定部２４１は、各部署の案件処理履歴を参照する。
［ステップＳ１６３］業務定義設定部２４１は、適切処理案件として記録された案件番号から、それぞれの依頼案件の内容を参照する。

［ステップＳ１６４］業務定義設定部２４１は、それぞれの適切処理案件に示されたサービス対象、サービス内容、サービス先を自部署の業務定義に追加する。
［ステップＳ１６５］業務定義設定部２４１は、不適切処理案件として記録された案件番号から、それぞれの依頼案件の内容を参照する。

［ステップＳ１６６］業務定義設定部２４１は、それぞれの不適切処理案件に示されたサービス対象、サービス内容、サービス先を包含する自部署の業務定義がある場合、その業務定義から該当する依頼内容を除外する。

［ステップＳ１６７］業務定義設定部２４１は、すべての部署に対してステップＳ１６２〜Ｓ１６６の処理が完了した場合、処理を終了する。
このようにして、初期記憶モードにおいて、案件の受理とその履歴が記録された後、各部署の業務定義が記憶される。すなわち、正しく処理した案件（適切処理案件）に基づいて、それぞれの案件に記入されたサービス対象、サービス内容、サービス先が業務定義に追記される。また、案件を他の部署に回送したもの（不適切処理案件）に基づいて、それぞれの案件に記入されたサービス対象、サービス内容、サービス先を含まないように業務定義から除外される。

図３１は、業務定義の再記憶処理の手順を示すフローチャートである。以下、図３１に示す処理をステップ番号に沿って説明する。
［ステップＳ１７１］業務定義設定部２４１は、参照対象の部署の配下の最下層の部署を探索する。なお、処理の開始時点では、ルートの部署が参照対象であるものとする。業務定義設定部２４１は、最下層の部署の業務定義情報を参照する。

［ステップＳ１７２］業務定義設定部２４１は、不適切処理案件数（ｑ）が予め設定された閾値（Ｔ１）を超えているか否かを判断する。不適切処理案件数が閾値を超えていれば、処理がステップＳ１７３に進められる。不適切処理案件数が閾値以下であれば、処理がステップＳ１７４に進められる。

［ステップＳ１７３］業務定義設定部２４１は、参照している部署の業務定義を再記憶する。この処理の詳細は、図２０に示した第１の実施の形態の業務定義の更新処理と同様である。この場合、回送処理案件として設定されているすべての依頼案件の依頼内容を業務定義から除外する処理と、被回送処理案件として設定されているすべての依頼案件の依頼内容を業務定義に追加する処理とが行われる。

［ステップＳ１７４］業務定義設定部２４１は、参照している部署の未処理の横部署が存在するか否かを判断する。未処理の横部署が存在する場合、処理がステップＳ１７５に進められる。未処理の横部署が存在しない場合、処理がステップＳ１７６に進められる。

［ステップＳ１７５］業務定義設定部２４１は、未処理の横部署を参照対象の部署として、処理をステップＳ１７１に進める。
［ステップＳ１７６］業務定義設定部２４１は、参照している部署の上位の部署が存在するか否かを判断する。上位の部署が存在する場合、処理がステップＳ１７７に進められる。上位の部署が存在しない場合、処理が終了する。

［ステップＳ１７７］業務定義設定部２４１は、上位の部署を参照対象として、処理をステップＳ１７２に進める。
このようにして、業務定義の再記憶を行うことができる。たとえば、業務定義の重複が修正される。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、業務フロー管理サーバが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
以上説明した実施の形態の主な技術的特徴は、以下の付記の通りである。

（付記１） 複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理する業務フロー管理プログラムにおいて、
コンピュータを、
前記部署毎に、前記部署で実施する業務の内容を定義した業務定義を記憶する業務定義記憶手段、
業務を依頼する依頼案件の担当部署として指定された部署において前記依頼案件に対して行った処理を示す案件処理履歴を記憶する案件処理履歴記憶手段、
依頼内容を指定した前記依頼案件の入力を受け付ける案件入力受付手段、
前記案件入力受付手段に入力された前記依頼案件と、前記業務定義記憶手段に記憶された前記業務定義とを比較して、前記依頼案件に示される前記依頼内容を包含する前記業務定義が設定された前記部署を検出し、検出した前記部署を前記依頼案件の前記担当部署と判断する担当部署判断手段、
前記担当部署判断手段で判断された前記担当部署の担当者が使用する端末装置に対して、前記依頼案件を送信する案件出力手段、
前記担当部署の前記担当者が使用する前記端末装置から、送信した前記依頼案件を受理するか否かを示す受理情報を取得し、前記依頼案件の識別情報に前記受理情報を関連付けた前記案件処理履歴を前記案件処理履歴記憶手段に格納する受理判断取得手段、
前記案件処理履歴記憶手段に記憶された前記案件処理履歴に基づいて、不受理の前記依頼案件の数を不適切処理案件数に換算し、前記不適切処理案件数が所定値以上となった前記部署を検出する是正対象部署検出手段、
として機能させることを特徴とする業務フロー管理プログラム。

（付記２） 前記是正対象部署検出手段は、前記不適切処理案件数が所定値以上となった前記部署の担当者に対して業務定義の是正指示を送信することを特徴とする付記１記載の業務フロー管理プログラム。

（付記３） 前記コンピュータを、さらに、
前記是正対象部署検出手段からの前記是正指示を受け取った前記担当部署の前記担当者が使用する前記端末装置から不受理の前記依頼案件を指定した前記業務定義の訂正指示を受け取ると、前記業務定義記憶手段内の前記担当部署の前記業務定義に対して、指定された前記依頼案件に示される前記依頼内容を除外する修正を行う業務定義更新手段、
として機能させることを特徴とする付記２記載の業務フロー管理プログラム。

（付記４） 前記受理判断取得手段は、送信した前記依頼案件を前記担当部署の前記担当者が不受理と判断した場合、前記担当者が使用する前記端末装置から前記依頼案件の回送先とする前記部署の指定を取得し、前記依頼案件の識別情報に前記回送先を指定する回送情報を関連付けた前記案件処理履歴を前記案件処理履歴記憶手段に格納し、
前記是正対象部署検出手段は、不受理の前記依頼案件の数と他の部署から回送されてきた被回送処理案件の数との合計を前記不適切処理案件数として、前記不適切処理案件数が所定値以上となった前記部署を検出することを特徴とする付記１記載の業務フロー管理プログラム。

（付記５） 前記是正対象部署検出手段は、前記不適切処理案件数が所定値以上となった前記部署の担当者に対して業務定義の是正指示を送信し、
前記コンピュータを、さらに、
前記是正対象部署検出手段からの前記是正指示を受け取った前記担当部署の前記担当者が使用する前記端末装置から、他の部署から回送された前記被回送処理案件を指定した前記業務定義の訂正指示を受け取ると、前記業務定義記憶手段内の前記担当部署の前記業務定義に対して、指定された前記依頼案件に示される前記依頼内容を追加する修正を行う業務定義更新手段、
として機能させることを特徴とする付記４記載の業務フロー管理プログラム。

（付記６） 前記業務定義記憶手段に記憶された前記業務定義には、サービスを提供する対象の物品を特定するサービス対象、提供するサービスの内容を示すサービス内容、およびサービスを提供する地域を示すサービス先によって業務の内容が定義されていることを特徴とする付記１記載の業務フロー管理プログラム。

（付記７） 前記コンピュータを、さらに、
前記組織を構成する複数の前記部署が木構造で関連付けられており、前記木構造における下位の部署の前記不適切処理案件数を、上位の部署の前記不適切処理案件数に加算することで、前記案件処理履歴記憶手段内の前記部署の前記不適切処理案件数を算出する案件処理履歴更新手段、
として機能させることを特徴とする付記１記載に業務フロー管理プログラム。

（付記８） 前記コンピュータを、さらに、
初期記憶モードと通常モードとの２つの動作モードで動作し、前記初期記憶モードの際には、前記案件処理履歴記憶手段を参照し、各部署で受理された前記依頼案件の前記依頼内容を、受理した前記部署の前記業務定義に追加し、各部署で受理しなかった前記依頼案件の前記依頼内容を、受理しなかった前記部署の前記業務定義から除外する業務定義設定手段、
として機能させることを特徴とする付記１記載の業務フロー管理プログラム。

（付記９） 前記業務定義設定手段は、前記通常モードの際には、前記是正対象部署検出手段により前記不適切処理案件数が所定値以上となった前記部署が検出された場合に、検出された前記部署の前記業務依頼に関して、各部署で受理された前記依頼案件の前記依頼内容を、受理した前記部署の前記業務定義に追加し、各部署で受理しなかった前記依頼案件の前記依頼内容を、受理しなかった前記部署の前記業務定義から除外する、
ことを特徴とする付記８記載の業務フロー管理プログラム。

（付記１０） 複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理する業務フロー管理装置において、
前記部署毎に、前記部署で実施する業務の内容を定義した業務定義を記憶する業務定義記憶手段と、
業務を依頼する依頼案件の担当部署として指定された部署において前記依頼案件に対して行った処理を示す案件処理履歴を記憶する案件処理履歴記憶手段と、
依頼内容を指定した前記依頼案件の入力を受け付ける案件入力受付手段と、
前記案件入力受付手段に入力された前記依頼案件と、前記業務定義記憶手段に記憶された前記業務定義とを比較して、前記依頼案件に示される前記依頼内容を包含する前記業務定義が設定された前記部署を検出し、検出した前記部署を前記依頼案件の前記担当部署と判断する担当部署判断手段と、
前記担当部署判断手段で判断された前記担当部署の担当者が使用する端末装置に対して、前記依頼案件を送信する案件出力手段と、
前記担当部署の前記担当者が使用する前記端末装置から、送信した前記依頼案件を受理するか否かを示す受理情報を取得し、前記依頼案件の識別情報に前記受理情報を関連付けた前記案件処理履歴を前記案件処理履歴記憶手段に格納する受理判断取得手段と、
前記案件処理履歴記憶手段に記憶された前記案件処理履歴に基づいて、不受理の前記依頼案件の数を不適切処理案件数に換算し、前記不適切処理案件数が所定値以上となった前記部署を検出する是正対象部署検出手段と、
を有することを特徴とする業務フロー管理装置。

（付記１１） 複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理するための業務フロー管理方法において、
依頼内容を指定した依頼案件の入力を受け付ける案件入力受付手段と、
担当部署判断手段が、前記案件入力受付手段に入力された前記依頼案件と、前記部署で実施する業務の内容を定義した業務定義を前記部署毎に記憶する業務定義記憶手段に記憶された前記業務定義とを比較して、前記依頼案件に示される前記依頼内容を包含する前記業務定義が設定された前記部署を検出し、検出した前記部署を前記依頼案件の担当部署と判断し、
案件出力手段が、前記担当部署判断手段で判断された前記担当部署の担当者が使用する端末装置に対して、前記依頼案件を送信し、
受理判断取得手段が、前記担当部署の前記担当者が使用する前記端末装置から、送信した前記依頼案件を受理するか否かを示す受理情報を取得し、前記依頼案件の識別情報に前記受理情報を関連付けた案件処理履歴を案件処理履歴記憶手段に格納し、
是正対象部署検出手段が、前記案件処理履歴記憶手段に記憶された前記案件処理履歴に基づいて、不受理の前記依頼案件の数を不適切処理案件数に換算し、前記不適切処理案件数が所定値以上となった前記部署を検出する、
ことを特徴とする業務フロー管理方法。

発明の概要を示す図である。 本実施の形態のシステム構成例を示す図である。 本実施の形態に用いる業務フロー管理サーバのハードウェア構成例を示す図である。 業務フロー管理サーバの機能を示すブロック図である。 組織の構成を示す図である。 業務定義の例を示す図である。 業務定義一覧表のデータ構造例を示す図である。 依頼案件のデータ構造例を示す図である。 案件処理履歴のデータ構造例を示す図である。 案件処理履歴一覧表のデータ構造例を示す図である。 依頼案件の回送例を示す図である。 第１の実施の形態における処理手順を示すフローチャートである。 業務定義の入力処理の手順を示すフローチャートである。 業務定義の確認処理の手順を示すフローチャートである。 依頼案件作成処理の手順を示すフローチャートである。 案件の担当部署判定処理の手順を示すフローチャートである。 案件の受理処理の手順を示すフローチャートである。 案件処理履歴の更新処理の手順を示すフローチャートである。 業務定義の更新勧告処理の手順を示すフローチャートである。 業務定義の更新処理の手順を示すフローチャートである。 案件処理履歴の例を示す図である。 業務定義の更新例を示す図である。 業務定義更新後の業務定義一覧表を示す図である。 依頼案件を処理可能な部署のすべてを列挙する例を示す図である。 第２の実施の形態の業務フロー管理サーバの機能を示すブロック図である。 第２の実施の形態における案件ＤＢのデータ構造例を示す図である。 第２の実施の形態における処理手順を示すフローチャートである。 業務定義の初期化処理の詳細を示すフローチャートである。 案件の直送処理の詳細を示すフローチャートである。 業務定義の記憶処理の手順を示すフローチャートである。 業務定義の再記憶処理の手順を示すフローチャートである。

符号の説明

１ 業務フロー管理装置
１ａ 業務定義記憶手段
１ｂ 案件処理履歴記憶手段
１ｃ 案件入力受付手段
１ｄ 担当部署判断手段
１ｅ 案件出力手段
１ｆ 受理判断取得手段
１ｇ 是正対象部署検出手段
２，３ 端末装置

Claims (4)

1. 複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理する業務フロー管理プログラムにおいて、
   コンピュータを、
   前記複数の部署それぞれ対応付けて、各部署で実施する業務の内容を定義した業務定義を記憶する業務定義記憶手段、
   業務を依頼する依頼案件の担当部署として指定された部署において該依頼案件に対して行った処理を示す案件処理履歴を記憶する案件処理履歴記憶手段、
   依頼する業務の内容を指定した依頼案件の入力を受け付ける案件入力受付手段、
   入力された該依頼案件と、前記業務定義記憶手段に記憶された業務定義とを比較して、該依頼案件に示される業務の内容を包含する業務定義が対応付けられた部署を検出し、検出した該部署を該依頼案件の担当部署と判断する担当部署判断手段、
   該担当部署の担当者が使用する端末装置に対して、該依頼案件を送信する案件出力手段、
   該端末装置から、該端末装置に送信した該依頼案件を受理するか否かを示す受理情報を取得し、該依頼案件の識別情報に該受理情報を関連付けた案件処理履歴を前記案件処理履歴記憶手段に格納すると共に、該依頼案件が受理されなかった場合、該端末装置から該依頼案件の回送先とする部署の指定を取得し、該依頼案件の識別情報に該回送先を指定する回送情報を関連付けた案件処理履歴を前記案件処理履歴記憶手段に格納する受理判断取得手段、
   前記案件処理履歴記憶手段に記憶された案件処理履歴に基づいて、部署ごとの不受理の依頼案件の数と他の部署から回送されてきた被回送処理案件の数との合計を、各部署の不適切処理案件数とし、不適切処理案件数が所定値以上となった部署を検出し、該部署の担当者宛に業務定義の更新を促すメッセージを送信する是正対象部署検出手段、
   該部署の担当者が使用する端末装置からの、依頼案件を指定した更新指示に応じ、前記案件処理履歴記憶手段を参照し、該依頼案件が被回送処理案件である場合、該依頼案件に示される業務の内容を定義した業務定義を、該部署に対応付けて前記業務定義記憶手段に追加し、該依頼案件が不受理の案件である場合、該依頼案件に示される業務の内容を示す業務定義が、該部署に対応付けて前記業務定義記憶手段に登録されていれば、前記業務定義記憶手段から該業務定義を削除し、実施する業務の一部として該依頼案件に示される業務の内容を包含する業務定義が、該部署に対応付けて前記業務定義記憶手段に登録されていれば、該業務定義に示される業務の範囲から該依頼案件に示される業務の内容を除外するように、該業務定義を更新する業務定義設定手段、
   として機能させることを特徴とする業務フロー管理プログラム。
2. 前記担当部署判断手段は、前記案件入力受付手段に入力された依頼案件に示される業務の内容を包含する業務定義が対応付けられた部署として、複数の部署を検出した場合、該複数の部署のうちの１つの部署を依頼案件の担当部署と判断し、
   案件出力手段は、該担当部署の担当者が使用する端末装置に対して、該依頼案件を送信し、該端末装置から、該依頼案件の不受理を示す受理情報が送られた場合、該端末装置に、前記担当部署判断手段で検出された複数の部署の一覧を表示させ、該一覧から選択された部署の担当者が使用する端末装置に対して、該依頼案件を送信する、
   ことを特徴とする請求項１記載の業務フロー管理プログラム。
3. 複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理する業務フロー管理装置において、
   前記複数の部署それぞれ対応付けて、各部署で実施する業務の内容を定義した業務定義を記憶する業務定義記憶手段と、
   業務を依頼する依頼案件の担当部署として指定された部署において該依頼案件に対して行った処理を示す案件処理履歴を記憶する案件処理履歴記憶手段と、
   依頼する業務の内容を指定した依頼案件の入力を受け付ける案件入力受付手段と、
   入力された該依頼案件と、前記業務定義記憶手段に記憶された業務定義とを比較して、該依頼案件に示される業務の内容を包含する業務定義が対応付けられた部署を検出し、検出した該部署を該依頼案件の担当部署と判断する担当部署判断手段と、
   該担当部署の担当者が使用する端末装置に対して、該依頼案件を送信する案件出力手段と、
   該端末装置から、該端末装置に送信した該依頼案件を受理するか否かを示す受理情報を取得し、該依頼案件の識別情報に該受理情報を関連付けた案件処理履歴を前記案件処理履歴記憶手段に格納すると共に、該依頼案件が受理されなかった場合、該端末装置から該依頼案件の回送先とする部署の指定を取得し、該依頼案件の識別情報に該回送先を指定する回送情報を関連付けた案件処理履歴を前記案件処理履歴記憶手段に格納する受理判断取得手段と、
   前記案件処理履歴記憶手段に記憶された案件処理履歴に基づいて、部署ごとの不受理の依頼案件の数と他の部署から回送されてきた被回送処理案件の数との合計を、各部署の不適切処理案件数とし、不適切処理案件数が所定値以上となった部署を検出し、該部署の担当者宛に業務定義の更新を促すメッセージを送信する是正対象部署検出手段と、
   該部署の担当者が使用する端末装置からの、依頼案件を指定した更新指示に応じ、前記案件処理履歴記憶手段を参照し、該依頼案件が被回送処理案件である場合、該依頼案件に示される業務の内容を定義した業務定義を、該部署に対応付けて前記業務定義記憶手段に追加し、該依頼案件が不受理の案件である場合、該依頼案件に示される業務の内容を示す業務定義が、該部署に対応付けて前記業務定義記憶手段に登録されていれば、前記業務定義記憶手段から該業務定義を削除し、実施する業務の一部として該依頼案件に示される業務の内容を包含する業務定義が、該部署に対応付けて前記業務定義記憶手段に登録されていれば、該業務定義に示される業務の範囲から該依頼案件に示される業務の内容を除外するように、該業務定義を更新する業務定義設定手段と、
   を有する業務フロー管理装置。
4. 複数の部署で構成される組織に対する業務依頼の各部署への振り分けを管理するための業務フロー管理方法において、
   コンピュータが、
   依頼する業務の内容を指定した依頼案件の入力を受け付け、
   入力された該依頼案件と、業務定義記憶手段に記憶された、前記複数の部署それぞれ対応付けて、各部署で実施する業務の内容を定義した業務定義とを比較して、該依頼案件に示される業務の内容を包含する業務定義が対応付けられた部署を検出し、検出した該部署を該依頼案件の担当部署と判断し、
   該担当部署の担当者が使用する端末装置に対して、該依頼案件を送信し、
   該端末装置から、該端末装置に送信した該依頼案件を受理するか否かを示す受理情報を取得し、該依頼案件の識別情報に該受理情報を関連付けた案件処理履歴を案件処理履歴記憶手段に格納すると共に、該依頼案件が受理されなかった場合、該端末装置から該依頼案件の回送先とする部署の指定を取得し、該依頼案件の識別情報に該回送先を指定する回送情報を関連付けた案件処理履歴を前記案件処理履歴記憶手段に格納し、
   前記案件処理履歴記憶手段に記憶された案件処理履歴に基づいて、部署ごとの不受理の依頼案件の数と他の部署から回送されてきた被回送処理案件の数との合計を、各部署の不適切処理案件数とし、不適切処理案件数が所定値以上となった部署を検出し、該部署の担当者宛に業務定義の更新を促すメッセージを送信し、
   該部署の担当者が使用する端末装置からの、依頼案件を指定した更新指示に応じ、前記案件処理履歴記憶手段を参照し、該依頼案件が被回送処理案件である場合、該依頼案件に示される業務の内容を定義した業務定義を、該部署に対応付けて前記業務定義記憶手段に追加し、該依頼案件が不受理の案件である場合、該依頼案件に示される業務の内容を示す業務定義が、該部署に対応付けて前記業務定義記憶手段に登録されていれば、前記業務定義記憶手段から該業務定義を削除し、実施する業務の一部として該依頼案件に示される業務の内容を包含する業務定義が、該部署に対応付けて前記業務定義記憶手段に登録されていれば、該業務定義に示される業務の範囲から該依頼案件に示される業務の内容を除外するように、該業務定義を更新する、
   ことを特徴とする業務フロー管理方法。

Images