JPH1027203A - 業務支援システムおよび業務支援方法 - Google Patents

Abstract

(57)【要約】 【課題】ワークフローの自動生成および文書差し戻しな
どの例外処理に伴うフローの動的変更に対応可能な業務
支援システムを実現する。 【解決手段】個々のタスクと文書との関係が文書−タス
ク関係モデルデータベース５で記憶および管理されてお
り、その関係を利用することによりワークフロー自動生
成、修正フローのチェック、文書差し戻し時の例外処
理、およびタスク削除処理が、ワークフロー自動生成部
６、修正フローチェック部７、例外処理部８，９によっ
てそれぞれ実行される。ワークフローの生成では、同一
文書であってもタスクによってその意味が異なり、例え
ば申請書などの文書は申請者による起票タスクでは「作
成」文書、上長などによる承認タスクでは「参照」
（「承認」）文書となることに着目し、各文書は「作
成」、「参照」という順番でタスクの順序関係が決定さ
れ、ワークフローが生成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は業務支援システムお
よび業務支援方法に関し、特にワークフロー管理システ
ムやフォームルーティングシステムのようにコンピュー
タを利用した情報の伝達により業務遂行を支援する業務
支援システムおよび業務支援方法に関する。

【０００２】

【従来の技術】昨今、ホワイトカラーの生産性向上等を
目的とした業務改革が行われつつあるが、組織改正等に
対して業務の変更が追い付いていないのが現状である。
たとえば、帳票は旧組織に基づいて設計されたものなの
で、使われない承認欄が残っていたり、旧組織で行って
いた業務を誰が遂行するのか不明確で混乱したりしてい
る。

【０００３】このような状況は、現在、業務改革の推進
の有効なツールとして注目を集めているワークフロー管
理システムを利用した場合でも、改善されていないのが
実状である。ここで、ワークフローとは、業務遂行方法
のうち、とくに仕事の担当者間で受け渡される情報の流
れをコンピュータネットワークを利用して自動化し、オ
フィス業務を効率化する仕組みと言うことができる。ワ
ークフロー管理システムの主な機能は、 （１）受け渡す情報（成果物）の管理 （２）情報の流れ（ワークフロー）の定義 （３）情報の流れ（ワークフロー）の管理 である。

【０００４】（１）は、受け渡す情報の中身を定義し、
各担当者が割り当てられた処理をその上で施せる環境を
提供することである。（２）は、ワークフローとして、
情報がどの担当者の間を流れていき、各担当者がどのよ
うな作業を行うのか定義するためのインタフェースを提
供することである。（３）は、ワークフロー上で仕事の
滞留しているところなどの管理情報を取得し、担当者の
変更やフローの修正、変更などの処理の参考にするため
のものである。

【０００５】ワークフロー管理システムの機能の中核と
なるのが上記の（２）である。現在のワークフロー管理
システムでは、そのためのビジュアルインタフェースが
備えられている。ワークフローの定義では、業務を構成
する作業の洗い出し、作業と担当者、成果物の対応関
係、情報の流れの分岐条件など様々な要素を定義する必
要がある。このような複雑な作業を少しでも改善するた
めにグラフィカルなネットワーク表現でそれらの定義を
できるようなインタフェースが用意されている。

【０００６】ワークフロー管理システムに類似するもの
として、フォームルーティングシステムがある。フォー
ムルーティングシステムは文書回覧を目的にしたシステ
ムで、上記のワークフロー管理システムのうち、（１）
と（２）の機能だけをもっている。ただし、（２）につ
いては、特別なスクリプト言語やマクロを用いて定義し
なくてはならない。このことから、フォームルーティン
グシステムはワークフロー管理システムを簡易化したも
のと言うことができる。

【０００７】

【発明が解決しようとする課題】上記のように、業務改
革のツールとして、ワークフロー管理システムやフォー
ムルーティングシステムなどの業務支援システムは複数
の人間の間で情報を流す業務を支援する機能をもってい
る。ただし、現状のものには次の問題点がある。

【０００８】（１）業務を詳細に分析、定義しなくて
は、そのワークフローをシステムに入力して運用するこ
とはできない。

【０００９】（２）各担当者は与えられた手順にしたが
って仕事をすることを強制され、自分のやりやすいよう
に業務遂行方法を修正することができない。

【００１０】（３）業務のやり方や組織等が変更された
とき、業務遂行方法を逐一、再定義しなくてはならない
（すなわち、影響のある手順を人間が判断し、それを業
務のやり方や組織の変更に合わせて修正しなくてはなら
ない）。

【００１１】本発明はこのような点に鑑みてなされたも
のであり、文書などの受け渡し情報の作成・参照を伴う
業務の遂行を支援する場合には、その受け渡し情報と業
務手順との関係から業務遂行方法（手順）が導き出せる
ことに着目し、この関係を利用することによって、業務
の詳細な分析および定義をすること無く、業務遂行方法
（手順）の生成、動的な業務遂行方法修正などを容易に
行うことができる業務支援システムおよび業務支援方法
を提供することを目的とする。

【００１２】また、本発明は、文書などの受け渡し情報
だけでなく、組織、担当者、作業等の業務に係わる事物
間の相互関係にも着目し、それら関係を用いて必要最低
限守らなくてはならない業務に関する条件（制約）を規
定し、その制約から初期の業務遂行方法（手順）を提示
でき、また必要に応じて業務遂行方法の再生成を容易に
行うことができる業務支援システムおよび業務支援方法
を提供することを目的とする。

【００１３】

【課題を解決するための手段】本発明は、コンピュータ
を利用して、業務遂行に必要な各担当者の作業およびそ
れら作業間における情報の受け渡しを支援する業務支援
システムにおいて、支援対象業務を構成する個々の作業
とその作業で扱う受け渡し情報との関係を記述した受け
渡し情報−作業関係モデル情報を保持する手段と、前記
受け渡し情報−作業関係モデル情報を参照して各作業と
そこで扱う受け渡し情報との関係から作業間の順序関係
を調べ、前記支援対象業務の遂行手順を生成する手段と
を具備することを特徴とする。

【００１４】この業務支援システムにおいては、支援対
象業務の構成単位となる個々の作業とその作業で作成・
参照される文書などの受け渡し情報との間の関係に着目
し、その関係を定義した受け渡し情報−作業関係モデル
情報からワークフローなどの業務遂行手順が自動生成さ
れる。通常、業務では、同一の文書であっても作業に依
存してその持つ意味は異なっており、例えば、申請書な
どの文書は申請者による起票作業では「作成」文書、上
長などによる承認作業では「参照」（「承認」）文書と
なる。この場合、各文書は「作成」、「参照」という順
番で処理される。このような各作業における文書の扱い
方の違いから作業間の順序関係が調べられて、ワークフ
ロー、つまり支援対象業務の遂行手順が生成される。そ
して、その遂行手順に従ってコンピュータ上の各担当者
の作業および文書情報などの受け渡しが管理される。こ
のように受け渡し文書と作業との関係を利用し、その関
係から業務遂行手順を導き出す構成を採用することによ
り、業務の詳細な分析および定義を行うこと無く、業務
遂行手順を容易に生成することが可能となる。

【００１５】受け渡し情報−作業関係モデル情報として
は、例えば、各作業で扱う受け渡し情報毎にその情報が
作成情報と参照情報のどちらの種類に属しているかを示
す属性情報を定義したものを利用することができる。こ
の場合、業務の遂行手順となるワークフローは、作業間
で扱われる同一の受け渡し情報毎にその情報を作成する
作業とその情報を参照する作業を調べ、受け渡し文書を
作成する作業の後方にその受け渡し情報を参照する作業
を順序付けることによって生成することができる。

【００１６】また、文書などの受け渡し文書毎にその情
報が作成情報と参照情報のどちらの種類に属しているか
を定義する代わりに、作業間で扱われる受け渡し情報間
の参照関係を示す情報を受け渡し情報−作業関係モデル
情報として用いることもできる。この場合には、業務遂
行手順となるワークフローは、他の受け渡し情報から参
照される受け渡し情報を扱う作業と、他の受け渡し情報
を参照する受け渡し情報を扱う作業とを受け渡し情報毎
に調べ、他の受け渡し情報から参照される受け渡し情報
を扱う作業の後方に他の受け渡し情報を参照する受け渡
し情報を扱う作業を順序付けることによって生成するこ
とができる。

【００１７】また、受け渡し情報−作業関係モデル情報
を用いることにより、文書などの受け渡し情報の差し戻
しや、作業削除といった業務遂行手順の動的変更にも容
易に対応することが可能となる。

【００１８】差し戻しとは、ワークフロー運用時に上流
行程で作成された受け渡し情報に不具合が発見された場
合には、その情報に関わる作業をもう一度やり直す処理
のことである。

【００１９】この発明においては、このような情報の差
し戻しに対応するために、伝達された受け渡し情報の参
照を行う作業で差し戻しが指定されたとき、前記受け渡
し情報−作業関係モデル情報を参照して、前記業務遂行
手順を修正する第１の例外処理手段を具備しており、こ
の第１の例外処理手段は、前記受け渡し情報−作業関係
モデル情報を参照して、差し戻しが指定された情報を作
成した作業を検索する手段と、前記差し戻しを指定した
作業と前記指定された情報を作成した作業との間の作業
を検索してコピーし、それを前記差し戻しを指定した作
業に後続させて前記業務遂行手順に挿入する手段とを含
むことを特徴とする。これにより、差し戻し発生時の複
雑なフロー変更処理がシステム内で自動的に行われるよ
うになり、一般ユーザであっても動的な例外処理を容易
に扱うことが可能となる。

【００２０】また、発明においては、テンプレートなど
として作成されたワークフローから不要な作業を削除す
るといったタスク削除にも対応するために、不要作業が
指定されたときは、その不要な作業を前記業務遂行手順
から削除して前記業務遂行手順を修正する第２の例外処
理手段を具備し、この第２の例外処理手段は、前記受け
渡し情報−作業関係モデル情報を参照して、前記削除さ
れる作業が作成し且つ他の作業から参照のみされている
受け渡し情報を検索し、その情報を前記業務遂行手順か
ら削除する手段とを含むことを特徴とする。これによ
り、削除する作業で作成され、他の作業では参照のみが
なされる受け渡し情報がある場合、システム内でその情
報も自動的に不要であると判断されて、ワークフロー内
からその情報の削除が行われる。

【００２１】また、この発明は、業務遂行手順がユーザ
などによって修正されたとき、受け渡し情報−作業関係
モデル情報を参照して、その修正された遂行手順におけ
る作業の順序関係の正当性を調べる手段を具備すること
を特徴とする。これにより、修正された遂行手順と受け
渡し情報−作業関係との間の整合性が管理できるように
なり、ワークフローのカスタマイズを容易に行うことが
可能となる。

【００２２】また、この発明は、業務制約を格納する業
務制約記憶手段と、業務制約から業務遂行方法を生成す
る業務遂行方法生成手段と、生成された業務遂行方法を
格納する業務遂行方法記憶手段と、業務制約と業務遂行
方法記憶手段中の業務遂行方法の整合性を検査する整合
性検査手段と、業務遂行方法を修正するためのインタフ
ェースを提供する業務遂行方法修正手段と、修正履歴を
記憶するための修正履歴記憶手段を具備することを特徴
とする。この構成によれば、業務制約記憶手段により、
必要最低限守らなくてはならない制約を保持し、業務遂
行方法生成部により、業務制約から、それだけでは決め
られない手順などを補うことにより業務遂行方法を生成
し、業務遂行方法記憶手段により、生成された業務遂行
方法を保持し、整合性検査手段により、業務制約記憶手
段中の制約と業務遂行方法記憶手段中の業務遂行方法と
の整合性を検査し、業務遂行方法修正手段により、業務
遂行方法記憶手段中の業務遂行方法を担当者が修正で
き、修正履歴記憶手段により、個人単位で修正の履歴を
保持し、それに基づいて業務遂行方法を生成できるよう
になる。

【００２３】このように、文書などの受け渡し情報だけ
でなく、組織、担当者、作業等の業務に係わる事物間の
相互関係にも着目し、それら関係を用いて必要最低限守
らなくてはならない業務に関する条件（制約）を抽出す
ることで、その制約から、初期の業務遂行方法（手順）
の提示、また必要に応じて業務遂行方法の再生成などを
容易に行うことが可能となる。

【００２４】

【発明の実施の形態】以下、図面を参照してこの発明の
実施形態を説明する。

【００２５】図１には、この発明の第１の実施形態に係
る業務支援システムの機能構成が示されている。この業
務支援システムは、ワークフロー管理システムやフォー
ムルーティングシステムなどのようにコンピュータネッ
トワークを用いて、業務遂行に必要な各担当者の作業お
よびそれら作業間における文書などの情報の受け渡しを
支援する。この業務支援システムを例えば複数のクライ
アントコンピュータとサーバコンピュータとがＬＡＮを
介して接続されたコンピュータネットワークシステムに
おいて運用する場合には、この業務支援システムは、各
クライアントコンピュータの動作を制御するためにサー
バコンピュータ上で実行されるプログラムとして実現さ
れる。

【００２６】この業務支援システムは、ワークフローで
定義された業務進行手順に従って各担当者のクライアン
トコンピュータに対してその作業に必要な画面やプログ
ラム実行の制御、文書情報などを提供し、その進捗状況
などを管理する。このシステムでは、ある担当者による
作業が終了すると、その作業で作成されたテキスト、図
形、イメージなどの文書や数値データなどの情報が、そ
れを参照することが必要な作業を行う次の担当者のクラ
イアントコンピュータに自動的に伝達される。そして、
そのクライアントコンピュータ上には、伝達された文書
等の情報の参照・承認を伴う作業を引き継ぐために必要
な画面やプログラムが再び提供される。

【００２７】この業務支援システムでは、このような文
書などの受け渡し情報の作成・参照を伴う業務の遂行を
効率よく支援するために、業務で作成・参照される文書
情報等と業務手順との関係に着目し、これを従来のワー
クフロー管理システムに組み込む形式を採用している。

【００２８】すなわち、図１に示されているように、こ
の業務支援システムにおいては、受け渡し文書管理部
１、ワークフロー定義部２、およびワークフロー管理部
３からなる従来のＩＰＯ（Ｉｎｐｕｔ Ｐｒｏｃｅｓｓ
Ｏｕｔｐｕｔ）型のワークフローモデルに対応した構
成に加え、文書−タスク関係モデル情報データベース
５、ワークフロー自動生成部６、修正フローチェック部
７、第１の例外処理（差し戻し処理）部８、第２の例外
処理（タスク削除処理）部９が設けられている。

【００２９】受け渡し文書管理部１は、受け渡す情報、
つまり共有文書を管理し、各担当者が割り当てられた処
理をコンピュータ上で実行できるようにするための作業
画面、プログラム、文書などを含む環境を各クライアン
トコンピュータに提供する。ワークフロー定義部２は、
ワークフローとして、文書がどの担当者の間を流れてい
き、各担当者がどのような処理を行うのか定義するため
のインタフェースを提供する。ワークフロー管理部３
は、ワークフロー上で仕事の滞留しているところなどの
管理情報を取得し、進捗状況や、担当者の変更やフロー
の修正などを行う。

【００３０】ワークフロー定義部２に組み込まれたワー
クフロー自動生成部６および修正フローチェック部７
は、それぞれ文書−タスク関係モデル情報データベース
５を利用して、ワークフローの自動生成、および生成さ
れたフローが修正された場合における修正フローの整合
性チェックを行う。

【００３１】一般に、多くの業務では、個々のタスク
（ワークフローの構成単位となる作業）は、ある文書を
受け取り、それを参照しながら新しい文書を作成して次
の担当者に渡すといった文書の流れに従って作成され
る。このことから、このシステムでは、個々のタスクと
文書との関係を文書−タスク関係モデルデータベース５
で記憶および管理する事により、その関係を利用したワ
ークフロー自動生成と修正フローのチェックをサポート
している。

【００３２】すなわち、通常、業務では、同一の文書で
あってもタスクに依存してその持つ意味は異なってお
り、例えば、申請書などの文書は申請者による起票タス
クでは「作成」文書、上長などによる承認タスクでは
「参照」（「承認」）文書となる。この場合、各文書は
「作成」、「参照」という順番で処理される。このよう
な文書の性質からタスクの順序関係が調べられて、ワー
クフロー、つまり支援対象業務の遂行手順が、ワークフ
ロー自動生成部６によって生成される。

【００３３】ワークフロー自動生成部６によって作成さ
れたワークフローは、テンプレートとして利用すること
ができ、各ユーザが必要に応じて修正することができ
る。ワークフローが修正されたとき、修正フローチェッ
ク部７は、文書−タスク関係モデルデータベース５を参
照して、文書−タスク関係と修正フローとの整合性を調
べ、修正フローの正当性を判断する。

【００３４】文書−タスク関係モデルデータベース５に
は、支援対象業務を構成する個々のタスクとそのタスク
で扱う文書との関係を示す文書−タスク関係モデル情報
として、図示のように、各タスク（タスク１，２）とそ
のタスクで扱う文書毎にその文書が作成文書と参照文書
のどちらの種類に属しているかを示す文書属性情報５ａ
を構築することが好ましい。この場合、ワークフロー
は、タスク間で扱われる同一文書毎にその文書を作成す
るタスクとその文書を参照するタスクを調べ、文書を作
成するタスクの後方にその文書を参照するタスクを順序
付けることによって容易に生成することができる。

【００３５】また、文書毎にその文書が作成文書と参照
文書のどちらの種類に属しているかを定義した情報５ａ
の代わりに、タスク毎に使用する文書を定義し、且つタ
スク間で扱われる文書がどの文書から参照されているか
という文書間の参照関係を定義した情報５ｂを用いても
よい。この場合には、ワークフローは、他の文書から参
照される文書を扱うタスクと、他の文書を参照する文書
を扱うタスクとを文書毎に調べ、他の文書から参照され
る文書を扱うタスクの後方に他の文書を参照する文書を
扱うタスクを順序付けることによって生成することがで
きる。

【００３６】ワークフロー自動生成および修正フローチ
ェック処理の詳細については、図５以降で詳述する。

【００３７】ワークフロー管理部３に組み込まれた第１
および第２の例外処理部８，９は、それぞれ文書−タス
ク関係モデルデータベース５を参照して、文書の差し戻
しやタスク削除といった例外処理時にワークフローを動
的に変更するためのものであり、以下、この例外処理の
ための方法について説明する。

【００３８】（１）例外処理１：差し戻し 差し戻しとは、ワークフロー運用時に上流行程で作成さ
れた文書に不具合が発見された場合に、その文書に関わ
るタスクをもう一度やり直す処理のことである。このよ
うな差し戻し処理はフロー中のどのタスクでも発生する
可能性があるため、従来のシステムでは、これら全ての
場合に応じて分岐条件を定義してフローを生成する必要
があった。しかし、この実施形態のシステムでは、文書
−タスク関係モデルデータベース５を利用することによ
って差し戻し処理に伴うフロー変更が自動的に行われる
ため、複雑な変更手順の定義などが不要となる。

【００３９】図２および図３には、例外処理部８によっ
て実行される差し戻し処理の具体例が示されている。

【００４０】ここでは、図２（ａ）のワークフロー中に
定義されているタスク「文書ａの承認」にて、その作業
を行う担当者によって文書ａの差し戻しが指定された場
合を考える。この場合、例外処理部８は、図３のフロー
チャートに従ってフロー変更処理を行い、図２（ｂ）に
示されているようにワークフローを修正する。

【００４１】すなわち、例外処理部８は、タスク「文書
ａの承認」にて差し戻し文書が指定されると（ステップ
Ｓ１０１）、まず、文書−タスク関係モデルデータベー
ス５を参照して、指定された文書「文書ａ」を作成した
タスクを検索する（ステップＳ１０２）。この検索処理
により、図２（ａ）のタスク「文書ａの作成」が該当す
るタスクという選択される。この後、例外処理部８は、
文書−タスク関係モデルデータベース５を参照して、差
し戻しを指定したタスク「文書ａの承認」とタスク「文
書ａの作成」との間の全てのタスクを検索し（ステップ
Ｓ１０３）、それをコピーして、差し戻しを指定したタ
スク「文書ａの承認」に後続させてフロー中に挿入する
（ステップＳ１０４）。これにより、図２（ａ）のフロ
ー中の「文書ａ作成」、「タスクＢ」、「タスクＣ」、
「タスクＤ」がコピーされて、それらタスクが図２
（ｂ）に示されているように、「文書ａ修正」タスク、
「タスクＢ’」、「タスクＣ’」、「タスクＤ’」とし
て、「文書ａの承認」と「タスクＥ」との間に挿入され
る。

【００４２】（２）例外処理２：タスク削除 タスク削除とは、テンプレートとして作成されたワーク
フローのうち、案件により不要となったタスクをフロー
内から削除する処理のことである。この場合、タスクの
削除に伴って、不要になった文書の削除も例外処理部９
によって自動的に行われる。タスク削除処理は、図４の
フローチャートに従って実行される。

【００４３】すなわち、例外処理部９は、タスクの削除
が利用者によって指定されると（ステップＳ１１１）、
まず、文書−タスク関係モデルデータベース５を参照し
て、その削除対象のタスクで作成された文書を検索し、
作成文書があるか否かを調べる（ステップＳ１１２，Ｓ
１１３）。削除対象のタスクで作成された文書がある場
合には、例外処理部９は、今度は、それら作成文書の中
で、他のタスクから参照のみされている文書を文書−タ
スク関係モデルデータベース５を参照して検索し、該当
する文書、つまり削除されるタスクが作成し且つ他のタ
スクから参照のみされている文書、が存在するか否かを
調べる（ステップＳ１１４，Ｓ１１５）。

【００４４】削除されるタスクが作成し且つ他のタスク
から参照のみされている文書が存在する場合には、例外
処理部９は、削除対象のタスクを削除すると共に、その
文書についてもフロー中から削除する（ステップＳ１１
６）。

【００４５】以上のように、図１の業務支援システムで
は、例外発生時の複雑なフロー変更はそのシステム内で
自動的に処理されるため、システム管理者以外の一般ユ
ーザであっても動的な例外処理を扱うことが可能とな
る。このため、システム管理者（設計時）、業務管理者
（運用開始時）、担当者（運用時）のそれぞれに対する
業務支援が可能となる。また、大規模エンジニアリング
業務に適用した場合には、設計、運用開始、運用のそれ
ぞれの局面において、次のような利益を提供することが
できる。

【００４６】（１）設計支援 例外発生場面の想定が不要：仕様の変更が頻繁に起こる
エンジニアリング業務の場合、フロー中のどのタスクで
も文書の変更や差し戻しが発生する可能性がある。従来
のシステムではこれら全ての場合に応じて条件分岐など
を予め定義する必要があるが、本システムでは、設計者
は文書−タスク間の関係のみを定義するだけでよい。

【００４７】フロー変更手順の設定が不要：上長による
承認／差し戻しのように、フローの変更や分岐が発生す
ることが予め想定できるような場合でも、どのタスクま
でフローを戻すか、どのタスクをやり直さなければなら
ないかといったフロー変更手順を分析する必要がない。

【００４８】（２）運用開始支援 フローのカスタマイズが容易：例えばプラントのような
大規模な見積もり業務では、案件毎に受注品目が異なる
ことが多く、テンプレートとなるワークフローをその場
合の数だけ用意することは現実的でない。そこで、テン
プレートして受注品目が最も多い場合のワークフローを
用意しておき、運用時に不要なタスクを削除（カスタマ
イズ）してからワークフローの運用を開始することが要
求される。本システムでは、タスクの削除の際に不要文
書も一緒に整理できるため、運用開始時のカスタマイズ
が容易となる。

【００４９】（３）運用支援 例外処理の最適化：本システムでは、前述したように業
務のあらゆる場面で例外を処理することができる。ま
た、例外処理のためのフロー変更は、文書−タスク関係
モデルに従って論理的に正しく、且つ最適化されている
ため、従来業務をトレースして人為的に設計したフロー
と比べ、いっそうの業務効率化を期待できる。

【００５０】次に、図１のシステムの具体的な実現形態
について説明する。なお、以下では、実際の業務の形態
を考慮し、文書だけでなく、組織、担当者、作業等の業
務に係わる事物間の相互関係にも着目し、それら関係を
文書−タスク関係モデルとして利用する場合について想
定する。

【００５１】図５には、図１のワークフロー自動生成部
６および修正フローチェック部７とその間の結合関係が
模式的に示されている。

【００５２】図５において、業務制約記憶部１１は、図
１の文書−タスク関係モデルデータベース５に相当する
ものであり、業務、サブ業務（作業）、役割、成果物
（文書）の一覧と、制約として守らなくてはならないそ
れらの間の相互関係、すなわち、業務制約を定義してい
る。業務遂行方法生成部１２は、図１のワークフロー自
動生成部６に相当するものであり、業務制約記憶部１１
中の制約に基づき業務遂行方法を生成し、業務遂行方法
記憶部１３へ結果を格納する。整合性検査部１４は、図
１の修正フローチェック部７に相当するものであり、業
務遂行方法記憶部１３の中の業務遂行方法が修正された
とき、または、業務遂行方法生成部１２以外の他の手段
により業務遂行方法が格納されたときに、それらの業務
遂行方法と業務制約記憶部１１中の制約との間の整合性
を検査する。同様に、整合性検査部１４は、業務制約記
憶部１１中の制約が変更されたときにも、変更された制
約と業務遂行方法記憶部１３中の業務遂行方法との整合
性を検査する。このとき、整合性のとれていない業務遂
行方法について、整合性検査部１４は、業務遂行方法生
成部１２に対して業務遂行方法の再生成を依頼する。以
下、具体例に基づいて本実施形態の動作を説明する。

【００５３】図７に業務制約記憶部１１中の制約の例を
示す。図７では学会参加準備という業務に関する制約を
定義している。業務名の宣言の次には業務生成のために
必要な業務パラメータ、業務で使用する文書、業務を遂
行する役割、業務を構成するサブ業務、業務をサブ業務
で構成する際の条件、という順番で定義している。

【００５４】サブ業務の定義では、その中で作成する文
書（作成文書）と添付する文書（添付文書）、文書を作
成する役割（作成者）と文書を承認する役割（承認
者）、その前にやっておかなくてはならないサブ業務
（必要業務）を定義している。承認者や添付文書、必要
業務の項目でｉｆ ｘ ＝ｙ ｔｈｅｎ ｚとなってい
るのは、業務パラメータｘの値がｙならば、その項目の
値としてｚを含めることを表している。

【００５５】例えば、サブ業務「学会参加申請」では学
会参加申請書を本人が作成し、それに発表原稿を添付し
て課長の承認と、さらに海外の学会参加では部長の承認
も必要なことを定義している。また、図７の構成条件で
は、開催場所が近距離でないときにはサブ業務「出張申
請」が必要なことを定義している。サブ業務の各項目
は、必要なものだけを定義する。

【００５６】構成条件のところで条件を指定されていな
いサブ業務は、無条件で業務遂行方法に必要と解釈す
る。ただし、入力された業務パラメータとサブ業務間の
相互関係により、業務遂行方法から削除されるサブ業務
もある。この場合の例は後述する。

【００５７】図６に本実施形態における業務遂行方法生
成部１２の構成を示す。業務遂行方法生成部１２は、業
務遂行方法生成実行部１２１と、業務パラメータ入力部
１２２とから構成される。業務遂行方法生成実行部１２
１は業務制約記憶部１１中の制約と業務パラメータ入力
部１２２を介してユーザから入力される業務パラメータ
の値により業務遂行方法を生成する。

【００５８】図８に業務遂行方法生成実行部１２１の処
理の流れを示す。最初にステップ４１で業務パラメータ
入力部１２２を通して業務パラメータを入手する。図７
の定義では、開催場所と参加種別の二つの業務パラメー
タの値を入手する。この業務パラメータの値は、ＧＵＩ
を通してユーザから入力されるものである。

【００５９】次にステップ４２で業務パラメータの値と
業務制約に規定された構成条件とに基づいて、業務を構
成するサブ業務を絞り込む。図７の定義では、開催場所
が近距離なら出張申請というサブ業務は不要と判断さ
れ、それ以外のサブ業務で構成される。開催場所が近距
離でなければ、すべてのサブ業務が必要と判断される。

【００６０】ステップ４３では、サブ業務間の相互関係
と業務パラメータの値とに基づいて、不要なサブ業務を
検出する。図７の定義では、サブ業務「発表原稿作成」
が作成した文書である発表原稿を、業務パラメータの参
加種別が発表のときだけサブ業務「学会参加申請」とサ
ブ業務「学会参加申込」で添付文書として利用してい
る。この関係から、参加種別が発表以外のときには、
「発表原稿作成」の作成した文書は他のサブ業務で利用
されないことがわかる。このように、他のサブ業務で作
成した文書を添付書類として利用せず、かつ、作成した
文書が他のサブ業務で添付書類として利用されない孤立
したサブ業務は業務遂行方法生成の処理の対象外とす
る。

【００６１】ステップ４４では、業務を構成する各サブ
業務について、入力された業務パラメータに基づいて、
文書作成と文書承認のタスク単位に分解する。ここでの
タスクとは、これ以上分解できない単位業務（作業）の
ことである。

【００６２】図７の定義に対して、参加種別が発表で開
催場所が海外のとき、各サブ業務から次のタスクを生成
する。

【００６３】発表原稿作成 → 発表原稿作成タスク 学会参加申請 → 学会参加申請作成タスク、学会参加
申請課長承認タスク、学会参加申請部長承認タスク 学会参加申込 → 学会参加申込タスク、 出張申請 → 出張申請作成タスク、出張申請課長
承認タスク、出張申請部長承認タスク 図９に上記のタスクの定義を示す。タスクの定義は、図
７のサブ業務の定義と類似した形をしている。異なる点
は次の通り。

【００６４】・元のサブ業務で作成者が文書を作成する
タスクは作成、承認するタスクは承認というタスク種別
をもつ ・承認のタスクでは元のサブ業務での作成文書が承認文
書になる ・作成者と承認者の代わりに担当者ができ、作成のタス
クでは作成者が担当者に、承認のタスクでは承認者が担
当者になる。

【００６５】次に、ステップ４５では、作成と承認、お
よび、作成文書と添付文書、必要業務の関係から、タス
ク間の順序付けを行う。まず、同一の文書に対する承認
は作成の後でなくてはならない。また、同一の文書を添
付するタスクはそれを作成するタスクの後でなくてはな
らない。これらのことから、図１０の順序関係が生成さ
れる。さらに、元のサブ業務で必要業務を指定している
タスクは、その必要業務として指定されたサブ業務から
生成されたタスクより後でなくてはならない。なお、順
序関係を設定する際、冗長な順序関係を削除する。これ
は、例えば、タスクＡ、Ｂ、Ｃについて、Ａ→Ｃと、Ａ
→Ｂ、Ｂ→Ｃの順序関係があったときに、Ａ→Ｃの順序
関係は、他のタスクを迂回した順序関係があることから
冗長なので、削除する。図１０では、冗長な順序関係は
ないので、削除される順序関係はない。

【００６６】次に、ステップ４６では、同じ文書の承認
を行う課長と部長の承認の順序付けを行う。本実施形態
では、課長の承認の後に部長の承認を行うように、タス
ク間の順序関係を追加する。その結果は図１１（ａ）の
ようになる。このとき、ステップ４５と同様に、冗長な
順序関係を削除する。図１１（ａ）では、次の四つが冗
長な順序関係になっている。

【００６７】 学会参加申請タスク → 学会参加申請部長承認タスク 出張申請作成タスク → 出張申請部長承認タスク 学会参加申請課長承認タスク → 学会参加申込タスク 出張申請課長承認タスク → 学会参加申込タスク これらが削除されて図１１（ｂ）の順序関係が設定され
る。

【００６８】次に、ステップ４７で承認者が同じタスク
のマージを行う。タスクのマージは次の二つの条件で行
う。

【００６９】・同じ役割（担当者）が承認するタスク
で、並行して実行できる（図１１のような順序グラフで
経路が存在しない）タスク ・同じ役割（担当者）が承認するタスクで、連続して実
行されるタスク 図１０のグラフでは学会参加申請課長承認タスクと出張
申請課長承認タスク、および、学会参加申請部長承認タ
スクと出張申請部長承認タスクが並行して実行できるの
で、これらをマージして、学会参加申請課長承認＆出張
申請課長承認タスクと、学会参加申請部長承認＆出張申
請部長承認タスクの二つのタスクを生成する。その結果
を図１２に示す。ここでもステップ４５の冗長な順序関
係削除の処理を行うが、図１２では冗長な順序関係がな
い。以上により、業務遂行方法が生成される。

【００７０】業務パラメータ入力部１２２は業務制約記
憶部１１中の制約で指定された業務パラメータとそのデ
ータタイプに応じて、業務パラメータ入力画面を生成
し、その画面を通してユーザに業務パラメータの値を指
定してもらう。業務パラメータのデータタイプとして
は、列挙型、文字列型、数値型の三種類がある。図２の
開催場所と参加種別は列挙型の業務パラメータである。
開催場所は近距離、遠距離、海外の三つの値のいずれか
をとる。また、参加種別は発表と参加の二つの値のいず
れかをとる。文字列型と数値型の業務パラメータは次の
ように宣言する。

【００７１】業務パラメータ１： ｓｔｒｉｎｇ 業務パラメータ２： ｎｕｍｂｅｒ 業務パラメータ入力部１２２は列挙型の業務パラメータ
についてはラジオボタンで、文字列型と数値型の業務パ
ラメータについてはテキストフィールドで入力する画面
（ＧＵＩ）を生成する。図７の業務制約に対して生成さ
れる画面を図１３に示す。

【００７２】業務遂行方法生成部１２は、生成した業務
遂行方法を業務遂行方法記憶部１３に格納する。業務遂
行方法記憶部１３は図１５（ａ）の形式で業務遂行方法
を記憶する。図１５（ａ）は図１２の業務遂行方法を格
納した例である。対応サブ業務のところには、そのタス
クの生成の元となったサブ業務の名前を格納する。ま
た、種類のところには、そのタスクが文書作成タスクな
のか文書承認タスクなのかのタスク種類を格納する。次
タスクには、次に実行すべきタスクＩＤを格納する。

【００７３】次に、図１５（ａ）の業務遂行方法が図１
５（ｂ）のように修正されたときを例にとり、整合性検
査部１４の動作を説明する。整合性検査部１４は、順序
関係のある二つのタスク単位で、それらが業務制約記憶
部１１中の制約と整合性があるかを図１４の処理の流れ
にしたがって検査する。図１５（ｂ）については、次の
順序関係について検査することになる。

【００７４】学会参加申請作成（ｔ２）→学会参加申請
課長承認＆出張申請課長承認（ｔ４）、出張申請作成
（ｔ３）→学会参加申請課長承認＆出張申請課長承認
（ｔ４）、学会参加申請課長承認＆出張申請課長承認
（ｔ４）→学会参加申請部長承認＆出張申請部長承認
（ｔ５）、学会参加申請部長承認＆出張申請部長承認
（ｔ５）→発表原稿作成（ｔ１）、発表原稿作成（ｔ
１）→学会参加申込み（ｔ６） まず、図１４のステップ１２１にて、二つのタスクが同
じサブ業務から生成されたものか否かを調べ、同じサブ
業務から生成されたものであれば、ステップ１２２で、
タスクの種類が文書作成→文書承認の順番になっている
ことを確認する。その順番に違反するものがあればステ
ップ１２３でエラーメッセージを出力する。図１５
（ｂ）の順序関係には該当するものはない。

【００７５】次に、二つのタスクが異なるサブ業務から
生成されたときには、ステップ１２４で、それらのサブ
業務で添付文書と作成文書が同じで、添付文書のサブ業
務の後に作成文書のサブ業務がくるようにタスクが順序
付けられていないかを検査する。その検査に該当するも
のがあればステップ１２５でエラーメッセージを出力す
る。上記の例では、 学会参加申請部長承認＆出張申請部長承認（ｔ５）→発
表原稿作成（ｔ１） の関係が該当する。学会参加申請部長承認＆出張申請部
長承認タスクのサブ業務は学会参加申請と出張申請の二
つであるが、学会参加申請の添付文書は発表原稿になっ
ている。また、発表原稿作成のサブ業務は発表原稿作成
であるが、その作成文書が発表原稿になっているため上
記の検査に該当する。

【００７６】整合性検査部１４は業務遂行方法が変更さ
れたときだけでなく、業務制約記憶部１１中の業務制約
が変更されたときも、制約と業務遂行方法の整合性を検
査する。例えば、図７の業務制約が変更されたときに
は、図１５（ａ）や図１５（ｂ）の業務名が学会参加準
備となっているタスクを無効にし、学会参加準備の業務
遂行方法の再生成を業務遂行方法生成部１２に依頼す
る。

【００７７】業務制約記憶部１１や業務遂行方法記憶部
１３の中身の変更は、整合性検査部１４が定期的に調べ
る。業務制約や業務遂行方法毎に独立のファイルに格納
すれば、各ファイルの作成日時と更新日時の比較によ
り、その業務制約、あるいは、業務遂行方法が更新され
たか判断することができる。

【００７８】また、業務遂行方法生成実行部１２１の処
理手順は、業務遂行方法生成ルールに基づいて制御する
こともできる。図１６にこの場合の業務遂行方法生成部
１２の構成を示す。図８の処理の中では、ステップ４６
にて課長の承認の後に部長の承認を実行するように順序
付けているが、図１６ではこのような役割間の暗黙の順
序関係が業務遂行方法生成ルールとして登録できるよう
にしたものである。図７の業務制約に対しては、 本人→課長→部長 という暗黙の順序関係を業務遂行方法生成ルール１２３
に登録しておくことにより、同様の結果を得ることがで
きる。

【００７９】また、本実施形態のシステムでは、複数の
業務遂行方法を連動して生成することができる。例え
ば、見積り業務と購入業務があったとし、購入業務は見
積り金額によって手順が代わるとする。このような場
合、最初に見積りの業務遂行方法を生成し、かつ、その
業務を実行してから購入の業務遂行方法を生成、実行す
ることが望ましい。これは、図１７に示すように、業務
遂行部１５と業務関係記憶部１６とを追加することによ
って実現できる。業務関係記憶部１６には、見積りと購
入の二つの業務の場合、 見積り → 購入 という順序関係を登録しておく。業務遂行部１５は一種
のワークフロー管理ツールで、業務関係記憶部１６を参
照し、業務遂行方法を生成、実行する順番を決定する。
上記の例では、業務遂行部１５は、最初に見積りの業務
遂行方法を業務遂行方法生成部１２に生成してもらい、
その手順に基づいた業務の実行を管理する。そして見積
り業務が終了したら、購入の業務遂行方法を見積り金額
を業務パラメータとして入力してもらうことにより行
う。購入のワークフローを生成したら、見積りのときと
同様に、それを実行する。

【００８０】次に、図１８乃至図４０を参照して、図１
のシステムの他の具体的な実現形態をこの発明の第２実
施形態として説明する。

【００８１】図１８は第２実施形態における業務支援シ
ステムの構成を示している。１５１は、業務とその構成
タスク、担当者、利用文書の相互関係に関するユーザー
の入力から、業務遂行方法生成に必要な制約を抽出する
組織規則入力部である。１５５は、文書の因果関係から
業務遂行方法を求める厳密なルールと組織など利用者の
環境に応じたルールからなる業務遂行方法生成ルール１
５３と、ユーザーの業務遂行方法修正履歴を格納した業
務遂行方法修正履歴記憶部１５４とを参照して、前記組
織規則入力部により抽出された業務制約１５２から、業
務遂行方法を生成する業務遂行方法生成部である。１５
７は、前記業務遂行方法生成部によって生成された業務
遂行方法を格納する業務遂行方法記憶部１５６の内容
を、ユーザーからの入力により修正し、修正内容を抽出
して前記業務遂行方法修正履歴記憶部へ格納する業務遂
行方法修正部である。

【００８２】図１９および図２０は、業務制約の例であ
る。業務制約には、タスクに関する制約（図１９（ａ）
の１６１）、業務に関する制約（図１９（ｂ）の１６
２）、文書に関する制約（図２０（ａ）の１６３）、担
当者に関する制約（図２０（ｂ）の１６４）がある。

【００８３】業務の構成タスクに関する制約１６１に
は、タスク種別、パラメータ、担当者、締切日、作成／
参考文書、直前／前方／直後／後方タスクの情報を記述
するための属性が定義されている。業務に関する制約１
６２には、属性として、業務種別、パラメータ、担当
者、構成タスクが定義されている。業務中の文書に関す
る制約１６３には、作成者、編集／参照が許可される利
用者、参考文書に関する情報を記述する属性が定義され
ている。また、業務／タスク中の担当者についての制約
１６４には、担当者種別、上位／下位担当者についての
属性が定義されている。

【００８４】例えば、業務の構成タスクに関する制約１
６１には、見積り依頼書送付というタスクの担当者は、
資材課でなくてはならず、参考文書として見積り依頼書
が必要である、という制約が記述されている。業務に関
する制約である１６２には、見積り業務が、資材課によ
って担当され、見積り依頼書送付と見積書受け取りとい
う二つのタスクを含んで構成されなければならない、と
記述されている。各制約の属性には、必要に応じて、パ
ラメータを利用した条件式を記述することができる。ま
た、各制約の属性に、他の制約を記述し、その属性値を
局所的に再定義して利用することもできる。

【００８５】次に、組織規則入力／制約抽出部１５１の
制約抽出処理について説明する。ここでは、図１９およ
び図２０の制約は既に用意されていて、この制約を利用
して、更に新しい業務のワークフローを生成する場合を
考える。

【００８６】図２１乃至図２３は、タスクと文書間の関
係をユーザに入力させるためのＧＵＩの動作例である。

【００８７】図２１（ａ）に示されているように、ま
ず、初期画面１７１（１７１）がユーザに提示され、こ
の画面上で、これから生成する業務の業務種別名として
例えば「購入」がユーザによって入力される（１７
２）。次に、その画面１７２上の「業務取り込み」ボタ
ンをクリックすると、図２１（ｂ）に示されているよう
に、購入業務の構成業務として取り込むべき業務名を指
定する画面が表示される（１７３）。この画面上で図１
９および図２０に制約が定義されている「見積り」業務
を指定すると、見積り業務に関しては、既にタスクと文
書間の関係が定義されているので、ＧＵＩには１７４の
形式でこれが表示される。

【００８８】この画面上で「タスク追加」、「文書追
加」ボタンをクリックすると、図２２（ａ）に示すよう
に、購入業務に必要な構成タスクおよび文書の追加設定
が可能となる。図２２（ａ）の１７５においては、購入
業務に必要な構成タスクとして、「見積り依頼書作
成」、「見積り依頼承認」、「手配依頼書作成」が追加
され、また文書として、新たに、「手配依頼書」が追加
されている。また、この画面上の「パラメータ追加」ボ
タンをクリックすると、制約の条件判断に必要なパラメ
ータを追加設定するための画面が図２２（ｂ）の１７６
のように表示され、そこで、図示のように数値パラメー
タである「金額」などのパラメータ名が入力される（１
７６）。

【００８９】次に、図２３に示されているように、図２
２（ａ）の画面１７５の中に、「作成」、「参考」と入
力することで、タスクと文書間の関係を指定することが
できる。同様にして、購入業務に必要な、全ての構成タ
スクと文書間の関係を入力したものが、図２４である。

【００９０】図２５は、業務に必要な文書相互の関係を
入力するＧＵＩの動作例である。

【００９１】既に、図２０において見積り依頼書と見積
書の間の参照関係は定義されているので、図２５（ａ）
に示されているように、初期画面（１９１）には、これ
が表示されている。更に、図２５（ｂ）に示されている
ように、「手配依頼書」は「見積書」を参照する、とい
う制約を画面上に入力すると（１９２）、逆参照関係に
関しては、組織規則入力／制約抽出部１５１が自動的に
補完し、その関係を図２５（ｃ）に示されているように
呈示する（１９３）。同様にして、購入業務に必要な全
ての文書間の関係を入力した結果が図２６である。

【００９２】図２７は、タスクと担当者の関係を入力す
るＧＵＩの動作例である。見積り業務と担当者である資
材課の関係は、図１９および図２０の制約に既に定義さ
れているので、図２７（ａ）に示されているように、初
期画面（２１１）にこれが提示される。ここで、担当者
として、「本人」は、全ての業務の場合に、既定値とし
て示される。購入業務には、担当者として更に「課
長」、「予算担当」が必要であることを図２７（ｂ）に
示されているように入力し（２１２）、さらに、図２７
（ｃ）に示されているように担当者とタスクとの関係を
入力する（２１３）。画面２１３で、入力値「以上」
は、そのタスクが、その担当者の、上位属性項目を辿っ
た集合に含まれる担当者によって処理されなければなら
ない、という制約を意味している。また、「金額＜２０
０，０００」は、指定された数値パラメータの金額の値
が２００，０００より小さい場合に、その担当者に処理
されてもよい、という制約を表している。同様にして、
購入業務に必要な、全てのタスクと担当者の関係を入力
したのが図２８である。図２８で、「ｅｌｓｅ」とは、
同じ行に含まれる条件式「金額＞１００，０００」が満
たされない時に、その担当者が処理するという制約を表
している。

【００９３】図２９は、担当者間の関係を入力するＧＵ
Ｉの動作例である。

【００９４】既に図２０で定義されている制約に関して
は、図２９（ａ）に示されているように、その初期画面
（２３１）に提示される。更に関係の指定が必要な場合
には、図２９（ｂ）に示されているように、新たに入力
することができる（２３２）。

【００９５】次に、このような組織規則入力／制約抽出
部１５１への入力から、業務制約を抽出する方法を図３
０のフローチャートを参照して説明する。

【００９６】ここでは、例として、前述の購入業務を考
える。まず、ステップ２４１により、入力された業務、
タスクなどが既に定義されたものかが判断される。例え
ば、見積り依頼書作成タスクは、新規に入力されたタス
クであるから、ステップ２４２により、新規定義され
る。この時、必要な属性値は、組織規則入力／制約抽出
部１５１への入力から定義される。検収タスクは図１９
に既に定義されているので、新規定義はされない。

【００９７】次に、ステップ２４３により、購入業務の
制約内に、必要な属性、あるいはタスク／文書種別名な
どがコピーされる。ただし、購入業務自身はコピーされ
ない。さらに、ステップ２４４では、既に存在していた
定義が、組織規則入力／制約抽出部１５１への入力によ
り変更を加えられているか判断され、変更がある場合に
は、ステップ２４３でコピーされた内容を、ステップ２
４５で再定義する。例えば、検収タスクは、担当者属性
が変更されているため、購入業務の制約内で再定義が行
われてる。組織規則入力／制約抽出部１５１により抽出
され、新規定義された購入業務の制約の例を、図３２に
示す。既に定義された制約（図１９および図２０）とあ
わせて購入業務の業務制約となる。

【００９８】図３２（ｂ）の２５２で定義されている担
当者属性の形式は、金額パラメータが１００，０００よ
り大きければ課長、それ以外なら本人が属性値となるこ
とを示している。再定義の形式としては、再定義する属
性値の始めに＋記号を用いることで、従来の定義への追
加を表したり、属性名のみを記述することで、制約の解
除を表したりすることもできる。

【００９９】一度抽出された業務制約は、後述の業務遂
行方法が生成されたり、同じく後述する業務遂行方法修
正部により業務遂行方法が修正された後でも、前記組織
規則入力部１５１によって適宜修正することが出来る。
修正は、制約の入力と同様の方法でも、また、図１９、
図２０、図３２のような制約を直接編集することでも行
える。修正により、新たな制約が生成されたときには、
この制約を含む業務について、後述する業務遂行方法生
成および業務遂行方法修正の手続きを繰り返すことで、
正しい業務遂行方法を自動的に生成する。また、業務遂
行中や業務修正後の制約の修正により、業務遂行方法や
後述する業務遂行方法修正履歴に矛盾が生じた場合に
は、制約の修正を取り消すか、業務を始めからやり直す
か、業務遂行方法の修正を取り消すか、といった方策
を、利用者への問い合わせにより決定することが出来
る。また、制約の修正により矛盾が生じるか否かは、修
正が行われる際に、この制約を含む業務について、図１
４と同様の手順で検査することで判断することができ
る。

【０１００】次に、図３３を参照して、業務制約から業
務遂行方法を生成する業務遂行方法生成部１５５の動作
について、前記購入業務を例に説明する。

【０１０１】まず、ステップ２６１で、購入業務の制約
に含まれる全てのタスクの参考文書属性が調べられ、あ
る文書を参考文書とするタスクは、該文書を作成するタ
スクよりも後方である、というルールによって、各タス
クの前方／後方タスク属性が記述される。例えば、見積
り依頼承認タスクは、見積り依頼書を参考文書とするの
で、見積り依頼書を作成する見積り依頼書作成タスクよ
りも後方である。

【０１０２】次に、ステップ２６２によって、文書の制
約の参考文書属性と、タスクの制約の参考文書属性が調
べられ、ある文書を参考文書とする文書を作成するタス
クは、該参考文書を作成するタスクよりも後方である、
というルールに従って、各タスクの前方／後方タスク属
性が記述される。例えば、手配依頼書は見積書を参考文
書とするので、手配依頼書を作成する手配依頼書作成タ
スクは、見積書を作成する見積書受取タスクよりも後方
である。ここでの、前方／後方属性の変更は、属性の再
定義ということになるので、購入業務の制約内での再定
義が行われ、この結果が図３４である。実業務において
利用されるためには、さらに、金額パラメータの値が入
力される必要があり、例えば、金額の値が「１２０，０
００」と入力された場合には、実際のワークフローは図
３５の様になる。これは、前記業務遂行方法記憶部に格
納される。

【０１０３】図３３のステップ２６１および２６２によ
る判断規則は、業務遂行方法生成ルール１５３に格納さ
れていたものであり、たとえば、他の属性を利用したル
ールを業務遂行方法生成ルール１５３に記述しておけ
ば、ステップ２６３で、利用者の職場環境に応じた業務
遂行方法を生成することができる。また、ステップ２６
４で、業務遂行方法修正履歴記憶部１５４を参照して、
利用者毎の業務遂行方法を生成することもできる。次
に、これらを実現する業務遂行方法修正部について説明
する。

【０１０４】例えば、「佐藤」という利用者が、見積り
依頼書を作成する際に、既に存在する「見積り依頼書書
式ガイド」なる文書を、参考にしたい場合を考える。こ
の時、ＧＵＩとしては、組織規則入力／制約抽出部１５
１と同様のものを利用することができる。図３６（ｂ）
が、修正の例である、この修正の結果は、図３７の３０
１と３０２のいずれかの形式で、業務遂行方法修正履歴
記憶部１５４に格納される。この結果を、業務遂行方法
生成部１５５で利用する方法が図３８に示されている。

【０１０５】まず、ステップ３１１によって、業務遂行
方法記憶部１５６と業務遂行方法修正履歴記憶部１５４
それぞれに格納されたデータで、業務／タスクなどの種
別が一致するものがあるか調べられ、一致する場合に
は、ステップ３１２により、変更すべき項目以外の属性
が一致するか調べられる。これも一致した場合には、ス
テップ３１３により、業務遂行方法記憶部１５６の内容
が変更される。３０１の形式の場合、担当者である佐藤
が、見積り依頼書を利用する際には、必ず、見積り依頼
書書式ガイドが参考文書となることを表している。つま
り、一度修正を加えれば、全く別の業務内でも、見積り
依頼書と、見積り依頼書書式ガイドを関連付けて利用す
る事が出来る。また、３０２の形式の場合は、担当者佐
藤が、購入業務を処理する時のみ、修正が有効になる。
図３７のいずれの形式で格納するかは、利用者の問い合
わせによって決定することが出来る。

【０１０６】また、図３７の担当者属性を指定しないこ
とも出来る。この時、修正は全ての利用者に対して有効
となり、業務遂行方法生成ルール１５３として格納され
る。また、タスクの前後関係を修正する場合のＧＵＩ例
を図３９に示す。

【０１０７】図３９のフロー３２１は図３５に示された
タスクの前後関係を流れ図にしたものであり、この流れ
図に直接矢印を追加、削除することで、フロー３２２の
ようにタスクの前後関係を修正する事が出来る。この修
正の内容は、図３７と同様に、業務遂行方法修正履歴記
憶部１５４あるいは業務遂行方法生成ルール１５３に格
納され、業務遂行方法生成部１５５により参照される。
利用者による修正は、図１４の手順で整合性検査部によ
り、業務制約と矛盾しないか、検査することが出来る。

【０１０８】また、タスクの順序の修正を、文書の差戻
しなど、運用時に例外的に発生するイベントから自動的
に処理することができる。図３９のフロー３２３は、フ
ロー３２２における「見積り依頼書送付」タスクで「見
積り依頼書」に変更が生じ、差戻しが発生した場合のタ
スク順序の修正例を示している。このとき、本業務支援
システムはタスクと文書間の関係（図２４）を参照し
て、差し戻された「見積り依頼書」を作成したタスクを
調べ、それ以降のタスクをやり直すよう、自動的にタス
クの多重化および順序の修正を行なう。すなわち、図３
９の例においては、図２４の制約を検索することによ
り、「見積り依頼書」を作成したタスクとして「見積り
依頼書作成」タスクが検出され、その「見積り依頼書作
成」タスクと「見積り依頼書送付」タスクとの間のタス
クが全てコピーされて、それらが差し戻しを指定した
「見積り依頼書送付」タスクに後続するようにフロー内
部に挿入される。

【０１０９】この時、もし「見積り依頼書」の変更によ
る影響が小さい場合には、利用者は「見積り依頼書」の
変更を関係者に通知するだけでタスクのやり直しは行わ
ないように指定することもできる。この時、フロー３２
２は図４０のフロー３２４のように変更される。

【０１１０】次に、図４２乃至図４７を参照して、図１
のシステムの別の具体的な実現形態をこの発明の第３実
施形態として説明する。

【０１１１】図４１は、本実施形態における業務支援シ
ステムの構成を示している。組織規則入力部４０１は、
組織構成、担当者の役割、文書の関係等、組織で決めら
れた規則を入力するためのものである。業務制約生成部
４０２は、組織規則入力部４０１から入力された各種規
則を組合せ業務手順等の制約を生成する。ここで生成さ
れた業務制約は、業務制約蓄積部４０３に蓄積される。
業務遂行方法生成部４０４は、業務制約蓄積部４０３に
蓄積された業務制約を参照して、業務手順等の業務遂行
方法を生成する。業務遂行方法入力部４０５は、業務手
順等の具体的な業務遂行方法を入力するためのものであ
る。整合性検査部４０６は、業務遂行方法入力部４０５
から入力された業務遂行方法と業務制約との整合性を検
査する。

【０１１２】業務組織規則入力部４０１では、図２１〜
図２９で説明したようなインタフェースを用いて、役割
関係、書類の依存関係、書類と役割の関係などの組織規
則を入力する。ここで入力された組織規則から変換され
た業務制約を図４２に示す。図４２では、「客先提案書
作成」５０１、「客先提案書検査」５０２、「客先提案
書承認」５０３の３つの業務についての制約が記述され
ている。「客先提案書検査」５０２に記述されている重
要度とは、業務の重要度を３段階で分類したもので、３
は最重要を示す数字である。「客先提案書検査」は最重
要業務であり、多重チェックが必要であることを示して
いる。

【０１１３】ここでは、組織改正に伴う現状業務の変更
の支援方法について説明する。

【０１１４】たとえば組織のフラット化を狙った組織改
正が行われ、週間組織である課がなくなった場合を例に
とる。

【０１１５】図４３は組織規則入力部４０１の表示画面
の一例で、役割の構成を階層的に表現したものである。
表示画面は、役割あるいは組織を示すオブジェクト５０
１と役割間の関係をしめす関係５０２とから構成され
る。図４３（ａ）は従来の組織を表示した画面であり、
技術部の下位組織には××課と△△課があり、××課に
はメンバーとしてＡ社担当、Ｂ社担当が、△△課にはメ
ンバーとしてＣ社担当、Ｄ社担当がいることを示してい
る。

【０１１６】図４１の業務制約生成部４０２は、（１）
各役割には業務を遂行する担当者がいる、（２）組織間
の上位下位関係は役割の上位下位関係に継承される、と
いう規則を適用し、技術部には部長が、××課と△△課
には課長が、Ａ社担当、Ｂ社担当、Ｃ社担当、Ｄ社担当
には各々担当者がおり、各々の間に上位下位関係が存在
することを推論し、業務制約を生成する。この結果を記
述したものが、図４２（ｂ）の５０４、５０５、５０６
のような本人、課長、部長間の制約である。

【０１１７】図４３（ｂ）は組織改正後、システム管理
者が新組織の規則を編集した結果を示す図である。××
課、△△課がなくなり、技術部が直接Ａ社担当、Ｂ社担
当、Ｃ社担当、Ｄ社担当を管理することになったことを
示している。この改正に従い、課長という役職が存在し
なくなった。図４４は組織改正後の新組織規則から生成
された業務制約を示す図である。業務制約中から課長と
いう役職がなくなり、図４２の５０２で担当者が「課長
以上」であったのは、課長と部長の上位下位関係から図
４４の６０２では「部長以上」に変更されている。

【０１１８】図４５は業務遂行方法入力部４０５の表示
画面の一例で、業務遂行手順をフロー的に表示したもの
である。図４５（ａ）は従来の組織に基づく業務手順を
表示した画面であり、図４５（ｂ）は今回の組織改正に
伴い、システム管理者がこの業務手順を編集した結果を
示す図である。

【０１１９】図４５（ａ）では客先提案書検査を課長と
部長が行なっていたが、課長という役職が存在しなくな
ったことから、（ｂ）ではフロー上から課長が担当者で
ある客先提案書検査の業務が削除されている。次に、こ
こで入力された組織規則から生成された業務制約と、業
務遂行方法の整合性を整合性検査部４０６で検査する。
図４６はその処理の流れを示した図である。

【０１２０】整合性検査部４０６はいくつかの検査項目
と検査ルールを持ち、それに従い、検査を行なう。ここ
では、３つのルールを適用している例を示す。まず、業
務と担当者の制約を、業務制約中の業務種別と担当者の
項目を参照して検査する（ステップＳ７０１）。図４５
の例の場合は、各々業務種別と担当者の制約を満たして
いる。ここで整合性が取れていないことが発見されれ
ば、業務遂行方法生成手順にジャンプする（ステップＳ
７０２）。次に文書の参照関係から業務の順序に関する
制約を検査する（ステップＳ７０３）。具体的には、前
述の実施形態でも述べたような、ある文書を参考文書と
するタスクは、該文書を作成するタスクよりも後方であ
る、というルールが適用される。図４４において、客先
提案書検査と客先提案書承認では各々客先提案書を参考
文書とするため、これらのタスクは、客先提案書を作成
するタスクである客先提案書作成より後方でなければな
らず、図４５の例では、これらの制約を満たしている。
ここで整合性が取れていないことが発見されれば、業務
遂行方法生成手順にジャンプする（ステップＳ７０
４）。次に重要度対策が成されているか検査する（ステ
ップＳ７０５）。

【０１２１】図４４の６０２において、客先提案書検査
は重要度が３であり、重要性の高い業務であることを示
している。この場合、重要度が３の業務の場合は、同じ
処理を二度繰り返し行わなければならない、というルー
ルが適用される。図４５（ｂ）では、新組織改正にした
がい、業務フローを簡略化したため、従来業務で二度繰
り返されていた客先提案書検査が省略されてしまった。
したがって、ここでは制約が満たされていないことがわ
かる。ここで、整合が取れていない場合は、業務遂行方
法生成手順にジャンプする（ステップＳ７０６）。

【０１２２】業務遂行方法生成部４０４は、図８で示し
たワークフロー生成処理手順と同様の手順で、業務制約
を参照し、業務遂行方法を生成する。図４７は、その結
果生成された業務遂行方法を提示した表示画面の一例で
ある。重要度が３である客先提案書検査は二度繰り返す
ことが望ましいことを示している。ここで、図４７にお
いて担当者がブランクになっているのは（８０１）、図
４４の業務制約６０２からは担当者が部長以上であるこ
としかわからず、アサインする役割をシステムが決めら
れなかったことを示している。システム管理者は、ここ
で提示された業務遂行方法のうち欠如している情報を補
うなどして、最終的な業務遂行方法を決定する。

【０１２３】

【発明の効果】以上説明したように、この発明によれ
ば、文書と業務手順との関係を利用することによって、
業務の詳細な分析および定義をすること無く、業務遂行
方法（手順）の自動生成や、文書の差し戻しや不要作業
の削除といった動的変更を伴う業務遂行方法の修正など
を容易に行うことが可能となる。また、組織、担当者、
作業等の業務に係わる事物間の相互関係から必要最低限
守らなくてはならない業務に関する条件（制約）を生成
しているため、文書同士や人同士の関係などある側面で
見た事物の相互関係だけを入力することだけで、複雑な
業務手順や適切な関連書類等を提示することが出来るよ
うになり、業務遂行方法の設計が容易となり、組織や業
務のやり方の変更にも柔軟に対応できる。

【０１２４】また、修正履歴により個人の流儀で業務遂
行方法のカスタマイズも可能であるので、決められた方
法にしばられることがなく、個人の生産性も向上する。
さらに、事物間の最低限の制約から提示される業務遂行
方法は冗長さを含まないため、整合性検査により、現状
業務に、矛盾や無駄が存在しないか、といった分析や業
務改善提案を行うことが出来、業務改革に有用である。

【図面の簡単な説明】

【図１】この発明の第１実施形態に係る業務支援システ
ムの機能構成を示すブロック図。

【図２】図１のシステムに設けられた例外処理部によっ
て実行される文書差し戻し時のワークフロー変更処理の
様子を示す図。

【図３】図１のシステムに設けられた例外処理部によっ
て実行される文書差し戻し時のワークフロー変更処理の
手順を示すフローチャート。

【図４】図１のシステムに設けられた例外処理部によっ
て実行される不要タスク削除処理の手順を示すフローチ
ャート。

【図５】図１のシステムの具体的な実現形態を示すブロ
ック図。

【図６】図５のシステムに設けられた業務遂行方法生成
部の構成を示すブロック図。

【図７】図５のシステムに設けられた業務制約記憶部中
の業務制約の記述例を示す図。

【図８】図６の業務遂行方法生成部によって実行される
業務遂行方法生成処理の手順を示すフローチャート。

【図９】図７の業務制約から生成されたタスク定義を示
した図。

【図１０】図７の業務制約で規定された文書間の関係か
らタスクの順序付けを行った結果を示す図。

【図１１】図７の業務制約で規定された役割間の関係か
らタスクの順序付けを行った結果を示す図。

【図１２】図１１のタスク順序付けに対してタスクのマ
ージ処理を施した結果を示す図。

【図１３】図６の業務遂行方法生成部に設けられた業務
パラメータ入力部によって生成される画面例を示す図。

【図１４】図５のシステムに設けられた整合性検査部に
よって実行される整合性検査処理の手順を示すフローチ
ャート。

【図１５】図６の業務遂行方法生成部によって生成され
た業務遂行方法の記述例を示す図。

【図１６】図５のシステムに設けられた業務遂行方法生
成部の他の構成例を示すブロック図。

【図１７】図５のシステムの変形例を示すブロック図。

【図１８】この発明の第２実施形態に係る業務支援シス
テムの構成を示すブロック図。

【図１９】図１８のシステムで使用される業務制約の記
述例を示す図。

【図２０】図１８のシステムで使用される業務制約の記
述例を示す図。

【図２１】図１８のシステムに設けられた組織規則入力
部でタスクと文書間の関係を入力するために使用される
画面例を示す図。

【図２２】図１８のシステムに設けられた組織規則入力
部でタスクと文書間の関係を入力するために使用される
画面例を示す図。

【図２３】図１８のシステムに設けられた組織規則入力
部でタスクと文書間の関係を入力するために使用される
画面例を示す図。

【図２４】図１８のシステムに設けられた組織規則入力
部でタスクと文書間の関係を入力するために使用される
画面例を示す図。

【図２５】図１８のシステムに設けられた組織規則入力
部で文書相互の関係を入力するために使用される画面例
を示す図。

【図２６】図１８のシステムに設けられた組織規則入力
部で文書相互の関係を入力するために使用される画面例
を示す図。

【図２７】図１８のシステムに設けられた組織規則入力
部でタスクと担当者の関係を入力するために使用される
画面例を示す図。

【図２８】図１８のシステムに設けられた組織規則入力
部でタスクと担当者の関係を入力するために使用される
画面例を示す図。

【図２９】図１８のシステムに設けられた組織規則入力
部で担当者間の関係を入力するために使用される画面例
を示す図。

【図３０】図１８のシステムに設けられた組織規則入力
部によって実行される業務制約抽出処理の手順を示すフ
ローチャート。

【図３１】図１８のシステムに設けられた組織規則入力
部によって抽出された業務制約の一例を示す図。

【図３２】図１８のシステムに設けられた組織規則入力
部によって抽出された業務制約の一例を示す図。

【図３３】図１８のシステムに設けられた業務遂行方法
生成部により実行される業務遂行方法生成処理の手順を
示すフローチャート。

【図３４】図１８のシステムに設けられた業務遂行方法
生成部により生成された業務遂行方法の例を示す図。

【図３５】図１８のシステムの業務遂行方法記憶部中に
格納された業務遂行方法の記述例を示す図。

【図３６】図１８のシステムの業務遂行方法修正部によ
って実行される業務遂行方法修正処理に使用される画面
例を示す図。

【図３７】図１８のシステムの業務遂行方法修正履歴記
憶部中の修正履歴の記述例を示す図。

【図３８】図１８のシステムの業務遂行方法生成部が業
務遂行方法修正履歴記憶部を参照する処理の流れを示す
フローチャート。

【図３９】図１８のシステムの業務遂行方法修正部によ
るタスクの前後関係の修正画面例を示す図。

【図４０】図１８のシステムの業務遂行方法修正部によ
るタスクの前後関係の修正画面例を示す図。

【図４１】この発明の第３実施形態に係る業務支援シス
テムの構成を示すブロック図。

【図４２】図４１のシステムで使用される業務制約の記
述例を示す図。

【図４３】図４１のシステムに設けられた組織規則入力
部の画面例を示す図。

【図４４】図４１のシステムにおいて組織改正後の新組
織規則から生成された業務制約の例を示す図。

【図４５】図４１のシステムで生成された業務遂行方法
をフロー的に表示した業務遂行方法入力部の画面例を示
す図。

【図４６】図４１のシステムにおける整合性検査処理の
手順を示すフローチャート。

【図４７】図４１のシステムにおける業務遂行方法を提
示した画面例を示す図。

【符号の説明】

１…受け渡し文書管理部、２…ワークフロー定義部、３
…ワークフロー管理部、５…文書−タスク関係モデルデ
ータベース、６…ワークフロー自動生成部、７…修正フ
ローチェック部、８，９…例外処理部、１１…業務制約
記憶部、１２…業務遂行方法生成部、１３…業務遂行方
法記憶部、１４…整合性検査部、１５…業務遂行実行
部、１６…業務関係記憶部、１２１…業務遂行方法生成
実行部、１２２…業務パラメータ入力部、１２３…業務
遂行方法生成ルール、１５１…組織規則入力／制約抽出
部、１５２…業務制約、１５３…業務遂行方法生成ルー
ル、１５４…業務遂行方法修正履歴記憶部、１５５…業
務遂行方法生成部、１５６…業務遂行方法記憶部、１５
７…業務遂行方法修正部、４０１…組織規則入力部、４
０２…業務制約生成部、４０３…組織規則蓄積部、４０
４…業務遂行方法生成部、４０５…業務遂行方法入力
部、４０６…整合性検査部、４０７…業務遂行方法提示
部。

フロントページの続き (72)発明者 後藤 和之 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内

Claims (13)

【特許請求の範囲】
1. 【請求項１】 コンピュータを利用して、業務遂行に必
   要な各担当者の作業およびそれら作業間における情報の
   受け渡しを支援する業務支援システムにおいて、 支援対象業務を構成する個々の作業とその作業で扱う受
   け渡し情報との関係を記述した受け渡し情報−作業関係
   モデル情報を保持する手段と、 前記受け渡し情報−作業関係モデル情報を参照して各作
   業とそこで扱う受け渡し情報との関係から作業間の順序
   関係を調べ、前記支援対象業務の遂行手順を生成する手
   段とを具備することを特徴とする業務支援システム。
2. 【請求項２】 前記受け渡し情報−作業関係モデル情報
   には、各作業で扱う文書などの受け渡し情報毎にその受
   け渡し情報は作成すべき情報であるのか、参照すべき情
   報であるのかを示す属性情報が定義されており、 前記支援対象業務の遂行手順を生成する手段は、 作業間で扱われる同一受け渡し情報毎にその情報を作成
   する作業とその情報を参照する作業を調べ、受け渡し情
   報を作成する作業の後方にその受け渡し情報を参照する
   作業を順序付けることを特徴とする請求項１記載の業務
   支援システム。
3. 【請求項３】 前記受け渡し情報−作業関係モデル情報
   には、作業間で扱われる受け渡し情報間の参照関係を示
   す参照関係情報が定義されており、 前記支援対象業務の遂行手順を生成する手段は、 他の受け渡し情報から参照される受け渡し情報を扱う作
   業と、他の受け渡し情報を参照する受け渡し情報を扱う
   作業とを受け渡し情報毎に調べ、他の受け渡し情報から
   参照される受け渡し情報を扱う作業の後方に他の受け渡
   し情報を参照する受け渡し情報を扱う作業を順序付ける
   ことを特徴とする請求項１記載の業務支援システム。
4. 【請求項４】 コンピュータを利用して、業務遂行に必
   要な各担当者の作業およびそれら作業間における情報の
   受け渡しを支援する業務支援システムにおいて、 支援対象業務を構成する個々の作業とその作業で扱う情
   報との関係を記述した受け渡し情報−作業関係モデル情
   報を保持する手段と、 前記受け渡し情報−作業関係モデル情報から前記支援対
   象業務を支援するために必要な業務遂行手順を生成する
   手段と、 他の作業から受け渡しされた情報の参照を行う作業でそ
   の受け渡し情報の差し戻しが指定されたとき、前記受け
   渡し情報−作業関係モデル情報を参照して、前記業務遂
   行手順を修正する第１の例外処理手段とを具備し、 この第１の例外処理手段は、 前記受け渡し情報−作業関係モデル情報を参照して、前
   記指定された受け渡し情報を作成した作業を検索する手
   段と、 前記差し戻しを指定した作業と前記指定された受け渡し
   情報を作成した作業との間の作業を検索してコピーし、
   それを前記差し戻しを指定した作業に後続させて前記業
   務遂行手順に挿入する手段とを含むことを特徴とする業
   務支援システム。
5. 【請求項５】 コンピュータを利用して、業務遂行に必
   要な各担当者の作業およびそれら作業間における情報の
   受け渡しを支援する業務支援システムにおいて、 支援対象業務を構成する個々の作業とその作業で扱う受
   け渡し情報との関係を記述した受け渡し情報−作業関係
   モデル情報を保持する手段と、 前記受け渡し情報−作業関係モデル情報を参照して、作
   業間順序関係により定義された前記支援対象業務の業務
   遂行手順を生成する手段と、 前記生成された遂行手順から不要作業が指定されたと
   き、その不要な作業を前記業務遂行手順から削除して前
   記業務遂行手順を修正する第２の例外処理手段とを具備
   し、 この第２の例外処理手段は、 前記受け渡し情報−作業関係モデル情報を参照して、前
   記削除される作業が作成し且つ他の作業から参照のみさ
   れている受け渡し情報を検索し、その受け渡し情報を前
   記業務遂行手順から削除する手段とを含むことを特徴と
   する業務支援システム。
6. 【請求項６】 コンピュータを利用して、業務遂行に必
   要な各担当者の作業およびそれら作業間における情報の
   受け渡しを支援する業務支援システムにおいて、 支援対象業務を構成する個々の作業とその作業で扱う受
   け渡し情報との関係を記述した受け渡し情報−作業関係
   モデル情報を保持する手段と、 前記受け渡し情報−作業関係モデル情報を参照して、作
   業間順序関係により定義された前記支援対象業務の業務
   遂行手順を生成する手段と、 前記生成された業務遂行手順が修正されたとき、前記受
   け渡し情報−作業関係モデル情報を参照して、その修正
   された遂行手順における作業の順序関係の正当性を調べ
   る手段とを具備することを特徴とする業務支援システ
   ム。
7. 【請求項７】 コンピュータを利用して、業務遂行に必
   要な各担当者の作業およびそれら作業間における情報の
   受け渡しを支援する業務支援方法において、 支援対象業務を構成する個々の作業とその作業で扱う受
   け渡し情報との関係を示す受け渡し情報−作業関係モデ
   ル情報を参照して各作業とそこで扱う受け渡し情報との
   関係から作業間の順序関係を調べて、前記支援対象業務
   の遂行手順を生成し、 前記生成された遂行手順に従って、前記支援対象業務の
   業務遂行に必要な各担当者の作業およびそれら作業間に
   おける情報の受け渡しを支援することを特徴とする業務
   支援方法。
8. 【請求項８】 コンピュータを利用して、業務遂行に必
   要な各担当者の作業およびそれら作業間における情報の
   受け渡しを支援する業務支援方法において、 支援対象業務を構成する個々の作業の順序関係によって
   定義された業務遂行手順に従って、前記支援対象業務の
   遂行に必要な各担当者の作業およびそれら作業間におけ
   る情報の受け渡しを管理し、 他の作業から受け渡しされた情報の参照を行う作業でそ
   の受け渡し情報の差し戻しが指定されたとき、前記支援
   対象業務を構成する個々の作業とその作業で扱う受け渡
   し情報との関係を示す受け渡し情報−作業関係モデル情
   報を参照して、前記指定された受け渡し情報を作成した
   作業を検索し、 前記差し戻しを指定した作業と前記指定された受け渡し
   情報を作成した作業との間の作業を検索してコピーし、
   それを前記差し戻しを指定した作業に後続させて前記業
   務遂行手順に挿入することにより前記業務遂行手順を修
   正することを特徴とする業務支援方法。
9. 【請求項９】 コンピュータを利用して、業務遂行に必
   要な各担当者の作業およびそれら作業間における情報の
   受け渡しを支援する業務支援方法において、 支援対象業務を構成する個々の作業の順序関係によって
   定義された業務遂行手順のなかから不要作業を削除する
   とき、前記支援対象業務を構成する個々の作業とその作
   業で扱う受け渡し情報との関係を示す受け渡し情報−作
   業関係モデル情報を参照して、削除される作業が作成し
   且つ他の作業から参照のみされている受け渡し情報を検
   索し、 その受け渡し情報を前記業務遂行手順から削除すること
   により前記業務遂行手順を修正することを特徴とする業
   務支援方法。
10. 【請求項１０】 コンピュータを利用して、業務遂行に
    必要な各担当者の作業およびそれら作業間における情報
    の受け渡しを支援する業務支援方法において、 支援対象業務を構成する個々の作業とその作業で扱う受
    け渡し情報との関係を記述した受け渡し情報−作業関係
    モデル情報を参照して、前記支援対象業務の業務遂行手
    順を生成し、 前記生成された業務遂行手順が修正されたとき、前記受
    け渡し情報−作業関係モデル情報を参照して、その修正
    された遂行手順における作業の順序関係の正当性を調べ
    ることを特徴とする業務支援方法。
11. 【請求項１１】 コンピュータを利用して、業務遂行に
    必要な各担当者の作業およびそれら作業間における情報
    の受け渡しを支援する業務支援システムにおいて、 組織、担当者、作業、文書等の業務に係わる事物間の相
    互関係を記述する入力手段と、 前記組織、担当者、作業、文書等の業務に係わる事物間
    の相互関係から、業務の手順、担当、作成文書等の業務
    に係わる制約を抽出する手段と、 この制約を参照して業務遂行方法を提示する手段とを具
    備することを特徴とする業務支援システム。
12. 【請求項１２】 提示された業務遂行方法を修正する業
    務遂行方法修正手段と、 各業務遂行方法の修正履歴を記憶する修正履歴記憶手段
    とをさらに具備し、 前記修正履歴と業務に係わる制約を組み合わせて業務遂
    行方法を提示することを特徴とする請求項１１記載の業
    務支援システム。
13. 【請求項１３】 修正された業務遂行方法、あるいは新
    規に入力された業務遂行方法と、業務の手順、担当、作
    成文書等の業務に係わる制約との整合性を検査し、修正
    または入力された業務遂行方法の不具合を提示する手段
    をさらに具備することを特徴とする請求項１１記載の業
    務支援システム。