JP2020528601A - 基準フィールドにより承認プロセスを設置する方法 - Google Patents

Abstract

【課題】本発明の方法は、簡単で明確であり、操作が簡単であり、フォームの基準フィールドが変更でき、実際の管理にさまざまな承認要件を満たすことができる。【解決手段】本発明は、準フィールドにより承認プロセスを設置する方法を公開し、承認プロセスを作成するステップは、Ｓ１：前記承認プロセスに対応する一つのフォームを選択すること、Ｓ２：前記承認プロセスのために一つの基準フィールドを選択し、１つ或は複数の承認プロセスに一つの基準フィールドが選択できること、Ｓ３：前記承認プロセスに選択された基準フィールドのフィールド値セットを設定し、各フィールド値が前記基準フィールドの下の承認プロセスのフィールド値セットのみに存在できることを含む。承認プロセスを関連付ける時、前記承認フォームの基準フィールドのフィールド値に従って、それがどの承認プロセスに対応する基準フィールドのフィールド値セットに属するかを判断する。本発明は、フォームを提出して承認プロセスを承認する時、承認フォームの基準フィールドにより承認プロセスを自動的に関連付けることができ、承認フォームの基準フィールドの内容によりプロセスを決定する。【選択図】図５

Description

本発明は、ＥＲＰなどの管理ソフトウェアシステムにプロセス設置担当者が承認プロセスを設置する方法に関し、特に、基準フィールドにより承認プロセスを設置する方法に関する。。

ロールベースのアクセス制御（ＲＢＡＣ）は、近年最も多く研究され、最も成熟したデータベース権限管理メカニズムの１つであり、従来の強制アクセス制御（ＭＡＣ）および自律アクセス制御（ＤＡＣ）に代わる理想的な候補と考えられる。従来の自律型アクセス制御は高い融通性を備えるが、セキュリティは低い。強制アクセス制御は高いセキュリティを備えるが、制限が強すぎる。ロールベースのアクセス制御は、両方の長所を兼ね備え、管理が簡単であるだけでなく、複雑さ、コスト、エラーの可能性を減らすこともできるため、近年大幅に成長している。ロールベースのアクセス制御（ＲＢＡＣ）の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化するに従って、ユーザーは、異なるロールを割り当てられることにより、データベースリソースに間接的にアクセスする。

大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限承認を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、ＳＱＬ言語を使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されたら、大量の複雑かつ面倒な承認変更を実行するために、予期しない承認エラーに引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。

ロールベースの権限制御メカニズムにより、システムのアクセス権をが簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。

ただし、従来のロールベースのユーザー権限管理及びワークフロー制御方法は、「ロール対ユーザー、１対多」の関連付けメカニズムを採用し、「ロール」はグループ／クラスの性質を有する。つまり、１つのロールが複数のユーザー同時をに対応／関連付けできる。ロールは、役職／職務／職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の３つの形式に分けられる。１、図１に示すように、ユーザーを直接承認されるが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒である。承認プロセスには承認ノードの承認操作主体がユーザーであり、ワークフロー承認ノードには従業員／ユーザーを承認主体として直接選択する。従業員の変更（異動、辞任など）が発生した場合、従業員に関するすべてのプロセスを適宜調整する必要がある。特に会社の経営陣にとっては、関する承認プロセスの数が多く、プロセス調整の作業負荷が大きく複雑であり、ミスや脱落を起こしやすく、会社の正常な運転に影響を及ぼし、予測不可能な損失さえ引き起こす。

従業員の承認権限のみが変更された場合でも、従業員に関するプロセスを調整する必要があり、上記と同様の問題もある。

２、図２に示すように、ロール（クラス／グループ／役職／職種）は承認され（１つのロールを複数のユーザーに関連付けることができる）、ユーザーはロールを介して権限を取得し、承認操作の主体はグループ／クラスというロールである。３、図３に示すように、上記の２つの方法が組み合わされている。

上記の説明では、２と３の両方がクラス／グループの性質を有するロールを承認する必要があり、クラス／グループ／役職／職種のロールを介する承認およびワークフロー制御の方法には次の欠点がある。１、ユーザーのアクセス権限を変更する場合、難しく操作する。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限の変更を処理する場合、ロールを関連付けられる従業員の権限を変更するが、ロールは権限の変更されない他の従業員にも関連付けられることで、個々の従業員の権限の変更により、ロール全体の権限を変更することができない。そのため、この状況に対応して、権限の変更された従業員に適用するために新しいロールを設立するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。

従業員／ユーザーの承認権限を変更する場合、従業員／ユーザーをロールから離脱するか、ワークフロー承認ノードには承認主体として従業員／ユーザーを直接選択するか、承認プロセスの要件を満たすために新しいロールを追加する。１番目の方式では、従業員の変更（異動、辞任など）が発生した場合、従業員に関するすべてのプロセスを、特に企業の管理担当者に対して調整する必要がある。関連する承認プロセスの数が多く、プロセス調整の作業負荷が大きく複雑であり、ミスや脱落を起こしやすく、会社の正常な運転に影響を及ぼし、予測不可能な損失さえ引き起こす。従業員の承認権限のみが変更された場合でも、従業員に関するプロセスを調整する必要があり、上記と同様の問題もある。２番目の方式では、新しいロールはロールの設立や関連付けや承認に関する。特に、多数のロールと、ロールを関連付けられた多数のユーザーの場合、どのユーザーがロールを具体的に関連付けられているかを覚えるのは困難である。

２、ロールに含まれる特定の権限を長期的に覚えることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えることは困難になり、権限の類似したロール間の権限差別を覚えるのがより難しくなり、ロールの類似した権限も混同し易い。新しいユーザーを関連付けると、どうやって関連付けるかを正確に判断することはできない。

３、ユーザーの権限が変更されるため、ロールをますます設立するのをもたらす（新しいロールを設立しない場合、ユーザーを直接承認するのが大幅に増加する）。各ロール間の特定の差別を区別することはより困難である。

４、役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーを関連付けてロールをそれぞれ作成する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーがより簡単に発生する。

さらに、従来の承認プロセスの設定方法では、１つのフォームに対して１つの承認プロセスしか作成できず（同時期に１つの承認プロセスしか使用できない）、このフォームがこのプロセスに沿って全て提出される必要がある。プロセスの転送条件をプロセスに設定して、プロセス承認のさまざまな承認ラインをガイドする可能性があるが、複雑な承認要件に直面する時、プロセスの転送条件は非常に複雑に設定され、承認ラインの走向も非常に多くなる。管理要件を完全に満たすプロセスの設定には特定の困難があり、設定操作は複雑であり、エラーが発生しやすく、修正が面倒である。修正する時、プロセスの関係者の正常な使用にも影響を与える可能性がある。

本発明の目的は、現行技術の欠陥を克服し、基準フィールドにより承認プロセスを設置する方法を提供することであり、フォーム（フォームデータ）を提出して承認プロセスを承認する時、承認フォーム（フォームデータの対応するフォーム）の基準フィールドにより承認プロセスを自動的に関連付けることができ、承認フォーム（フォームデータ）の基準フィールドの内容によりどのプロセスを承認するかを決定する。この方法は、簡単で明確であり、理解しやすく、操作が簡単であり、フォームの基準フィールドが変更でき、実際の管理におけるさまざまな承認要件を満たすことができる。

本発明の目的は、以下の技術的手段により達成される。基準フィールドにより承認プロセスを設置する方法は、承認フォームのために基準フィールドを決定するステップ、承認プロセスを作成するステップ、及びユーザーに提出された承認フォームにより承認プロセスを自動的に関連付けるステップを含む。承認フォームのために基準フィールドを決定するステップは、ワークフローの承認を必要とする各フォームのために一つの基準フィールドを決定し、或いは基準フィールドによりワークフローの承認を行う各フォームのために一つの基準フィールドを決定し、一つの承認フォームが同時期に基本フィールドを決定でき、且つ一つしか決定しない。承認プロセスを作成するステップは、Ｓ１：前記承認プロセスに対応する一つのフォームを選択（或は設定）し、１つのフォームが一つ或は複数の承認プロセスに対応すること、Ｓ２：前記承認プロセスのために一つの基準フィールドを選択し、１つ或は複数の承認プロセスに一つの基準フィールドが選択でき、基準フィールドが提出ロール、或はフォームに対応するロール属性フィールド、或はフォームに対応する部門属性フィールドであること、および、Ｓ３：前記承認プロセスのステップＳ２に選択された基準フィールドのフィールド値セットを設定し、各フィールド値（基準フィールドの各フィールド値）が、前記基準フィールドの下の承認プロセスのフィールド値セットのみに存在できることを含む。「承認フォームのために基準フィールドを決定するステップ」と「承認プロセスを作成するステップ」という二つのステップには前後順序はない。

ユーザーに提出された承認フォームにより承認プロセスを自動的に関連付けるステップは、ＳＳ１：ユーザーに提出された承認フォーム（フォームデータ）により、システムが前記承認フォーム（そのフォームデータに対応する承認フォーム）に決定された基準フィールドを見つけること、ＳＳ２：ステップＳＳ１で決定された基準フィールドに従って、前記承認フォームの基準フィールドにより対応の承認プロセスを見つけない場合、「対応の承認プロセスなし」を表示し（「対応の承認プロセスなし」を指摘する）、見つかる場合に、前記基準フィールドに対応するすべての承認プロセスを見つけてステップＳＳ３に移動し、或は見つかる場合に、ステップＳＳ３に直接移動すること、および、ＳＳ３：前記承認フォーム（フォームデータ）の基準フィールドのフィールド値に従って、それがどの承認プロセスに対応する基準フィールドのフィールド値セットに属するかを判断すると、前記承認フォーム（フォームデータ）がこの承認プロセスを使って承認して承認フォーム（フォームデータ）と承認プロセスの関連付けを完成することを含む。

選択された基準フィールドが提出ロール、或は対応するフォーム中のロール属性フィールドである場合、フィールド値セットのフィールド値が全てロールであり、選択された基準フィールドが対応するフォーム中の部門属性フィールドである場合、フィールド値セットのフィールド値が全てロールである。

前記フィールド値セットには、ヌル値である一つのフィールド値を含み、承認プロセスを設定するとき、選択された基準フィールドのフィールド値がヌル値であるフォームに対応する一つの承認プロセスを設定し、ユーザーに提出された承認フォーム（フォームデータ）に基準フィールドの内容がヌル値である場合、この承認プロセスを使って承認する。

選択された基準フィールドが唯一の承認プロセスのみに対応する場合、前記承認プロセスに選択された基準フィールドのフィールド値セットには「すべて」という一つのフィールド値選択項が選択でき、「すべて」を選択し、ユーザーに提出された承認フォーム（フォームデータに対応する承認フォーム）により決定された基準フィールドは、前記承認プロセスに選択された基準フィールドと同じになると、ユーザーに提出された承認フォーム（フォームデータ）に基準フィールドのフィールド値が何値であるかに関わらず、その提出された承認フォーム（フォームデータ）は、前記承認プロセスを使って承認を行い、且つ新しく追加された基準フィールドのフィールド値も承認プロセスを使って承認を行う（つまり、新しく追加された前記基準フィールドのフィールド値に関われたプロセスはすべて前記承認プロセスである）。

フォームのロール属性フィールド、フォームの部門属性フィールドはすべてラジオ且つ記入必須項目である。（たとえば、契約フォームの「契約署名部門」フィールドの内容は、記入必須項目／選択必須項目でなければならないと、そのフィールドが基準フィールドとなる）

前記ロールは、グループ／クラスではなく、独立した個体であり、一つのロールは唯一のユーザーを同時期に関連付けることができ、一つのユーザーは一つ或は複数のロールを関連付けることができる。

前記ロールは部門に属し、そのロールはその部門内で唯一であり、ロールの作業内容によりロールを承認し、ユーザーはロールを関連付けるにより権限を取得する。

ユーザーが部門間を移動する時、先ずユーザーと元の部門のロールの関連を取り消し、次にユーザーを新しい部門内のロールに関連付ける。

前記承認プロセスは、ユーザー−ロール−権限の３層構造モデルに基づいて、その中、ロール層には、ワークフローのプロセス承認の操作主体はロールであり、各ロールは独立した個体であり、グループ／クラスではなく、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或は複数のロールを関連付け、権限層には、ワークフローの実行中に使用する必要がある権限で構成され、ロールに権限を直接授与し、ユーザー層には、ユーザーがロールを関連付けることによりワークフローの承認タスクを決定し、ロールを関連付ける権限で承認操作を実行する。

前記承認プロセスには、一つの開始ノード、少なくとも１つの承認ノード、一つの終了ノードを含み、開始ノードには承認プロセスを開始し、承認ノードには承認ロールを選択し、承認ロールに権限を与え、終了ノードには承認プロセスが終了する。

本発明の有益な効果は次のとおりである。１、フォーム（フォームデータ）を提出して承認プロセスを承認する時、承認フォーム（フォームデータの対応するフォーム）の基準フィールドにより承認プロセスを自動的に関連付けることができ、承認フォーム（フォームデータ）の基準フィールドの内容によりどのプロセスを承認するかを決定する。この方法は、簡単で明確となり、理解しやすく、操作が簡単であり、フォームの基準フィールドが変更でき、実際の管理においてさまざまな承認要件を満たすことができる。

例えば、プロセス設計者がプロセスを設計しているとき、契約フォームの目下の基準フィールドを「契約署名ロール」に設定し、その契約フォームの下の各承認プロセスを設定し、各承認プロセスの基準フィールドとその基準フィールドのフィールド値セットを決定する。

ロール５という提出ロールは、契約フォーム（契約／フォームデータ）を提出し、契約フォーム（この契約）には次のフィールドを含む。契約署名ロールはロール１（契約署名ロールがフィールドであり、ロール１がこのフィールドの内容／値である）であり、契約責任ロールはロール２であり、契約署名部門は部門１であり、契約責任部門は部門２であり、ユーザーに提出されたのは契約フォーム（この契約）であり、システムは自動的に目下の契約フォーム（この契約に対応する契約フォーム）に対応する（設定する）基準フィールド（目下の基準フィールド）が「契約署名ロール」であることを見つけることができ、従って、「契約署名ロール」に対応する複数の承認プロセスを見つける。最後に、契約フォーム（この契約）の「契約署名ロール」フィールドのフィールド値「ロール１」により、「契約署名ロール」基準フィールドのフィールドセットに「ロール１」を含む唯一の承認プロセスを決定する。

２、本発明には、１つのフォームは一つ或は複数の承認プロセスが作成できる。１つのプロセスのみを作成する場合、基準フィールドのフィールド値が「すべて」に設定できる。ユーザーに提出された承認フォーム（フォームデータ）により決定された基準フィールドは、その承認プロセスに選択された基準フィールドと同じになると、その基準フィールドのフィールド値が何値であるかに関わらず、その提出された承認フォームは、その承認プロセスを使って承認を行い、且つ新しく追加された基準フィールドのフィールド値もその承認プロセスを使って承認を行う。これは、簡単、便利である。複雑な応用の場合には、たとえば、システムに３つの事業部門があり、各事業部門が異なる製品を販売する。従来の方法では、販売契約フォームは１つの承認プロセスのみを作成する可能性があり、作成時に複雑なプロセス条件と承認経路を設定する必要がある。これは、複雑であり、エラーが発生しやすいだけでなく、管理ニーズを完全に満たす承認プロセスを設定することも困難である。本発明には、３つの事業部門の販売契約の承認要件を満たすために、販売契約フォームに対して３つの承認プロセスを作成する可能性があり、同時に、システムユーザーは、契約の承認（承認プロセス）を行う（選択／決定）ために、「契約署名部門」、「提出ロール」等のフィールドの中にどちらをを使用するかどうかも自分が決定する可能性があり、ユーザーのニーズをより正確に満たすことができる。使用プロセスでは、プロセスユーザーはそれを明確かつ簡単に理解し、明確かつ簡単に修正し、修正プロセス中に他のプロセスの使用に影響しない。

ユーザーは、ニーズに応じて異なるフォームを使ってさまざまな基準フィールドが選択でき、且つ基準フィールドも置き換えることができるため、異なるフォームのさまざまな管理ニーズに大いに対応できる。たとえば、一部のシステムユーザーは、契約の承認中に「契約署名のロール」で承認プロセスを実行したがる（つまり、「契約署名ロール」が契約フォームの目下の基準フィールドとして使われて承認のために契約を提出する場合、契約フォームの「契約署名ロール」フィールドに対応する承認プロセスが関連する承認実行を行う。）が、一部のユーザーは「契約署名部門」で承認プロセスを実行したがり、一部のユーザーも「提出者」で承認プロセスを決定したがる場合、システムユーザーはニーズに応じてフォームの基準フィールドを自由に変更して問題を解決する可能性がある（フォームの基準フィールドを変更した後、提出されたフォームデータは、対応するフォームの目下の基準フィールドに対応する承認プロセスで承認を実行する。たとえば、目下の契約フィールド「契約署名ロール」が「契約署名部門」に置き換えられた場合、「契約署名部門」が目下の基準フィールドになる。たとえば、契約が承認のために提出された後、契約フォームの目下の基準契約フィールド「契約署名部門」に対応する承認プロセスが承認されるが、「契約署名ロール」に対応する承認プロセスが承認されない。つまり、提出されたフォームデータは、対応するフォームの目下の基準フィールドに対応する承認プロセスで関連する承認を実行する）。

３、異なるフォームには、どちらプロセスを行うかを決定するために異なるフィールドが必要である。たとえば、生産注文は提出者であり、払い戻し承認は払い戻し者であり、契約承認は契約署名者であり、全てフォーム提出者により承認プロセスを決定するとは限らない。誰が提出するかに関わらず、プロセスは、基準フィールド（目下の基準フィールド）に対応するロール或は部門により決定される。この設定方法は操作がより便利であり、さまざまなフォームの承認に適切に適用する可能性があり、企業の実際の運用と管理ニーズがよりよく満足することができる。

４、ワークフローに承認操作の主体はロールであり、しかもこのロールは従来のグループ／クラスの性質を有するロールではなく独立した個体である。従業員／ユーザーの変更（異動、辞任など）が発生した場合、または従業員の承認権限が変更された場合でも、従業員を新しいロールに再度関連付けるか、それに応じてロールの承認権限を調整してもよい。プロセスを再設定／調整する必要はなく、設定が便利であり、ミスや脱落は発生せず、企業の正常な運用には影響せず、ワークフローの信頼性を大幅に向上させる。役職番号の性質を有するロールは、承認リンクノードに承認権限主体となり、ユーザーは、ロールによりどの承認タスクがあるかを決定し、ユーザーは、ロールを関連付ける権限により承認操作を行ってもよい。理解は明確かつ簡単であり、役職番号／職務番号の性質を有する各ロールは最小作業単位であり、各ロールの承認に対する多様な要求に応じて本発明は十分に満たすことができる。

５、本発明は、ロールがユーザーとの１対１の関係にあり、一つのロールが唯一のユーザーを同時期に関連付けることができる。これの利点は、ユーザーを関連付けてもよく、ユーザーを設立するたびに権限を割り当てる必要がなくなることであり、しかもロールの権限の変更は、従来のメカニズムにあるロールの権限の変更よりもはるかに小さくなる。独立した個体の性質（役職番号／職務番号の性質）のロールの数は少ない。従業員の異動は大きいが、役職番号／職務番号の変化は小さい（一定期間に変化さえない、つまりロールは変わらない）。これにより、ユーザーの権限管理を大幅に簡易化し、システムの掛かりを削減する。

６、動的な管理、入職や異動等の操作が簡単と便利となり、効率と信頼性が高くある。入職／離職／異動の適用は承認プロセスで簡単である。ワークフローの発起と承認の主体はロールであるため、従業員／ユーザーを変更する場合、承認プロセスを再設定する必要はない（ユーザーはロールを取り消し、ロールを関連付けてもよい）。役職番号／職務番号のロールを失ったユーザーは、ロールの関連付けを取り消し、役職番号／職務番号のロールを引き継ぐユーザーは、その役職番号のロールを関連付ける。承認ワークフローを再設定したり、ワークフロー内のロールを再承認したりする必要はない。これにより、プロセス設定の効率やセキュリティや信頼性を大幅に向上させる。

たとえば、張三というユーザーが辞任または異動する原因で、張三は「バイヤー３」というロールとして働かなく、張三はロールとの関連付けを取り消す。ほかに、李四は、「バイヤー３」というロールとする仕事を引き継ぎ、李四はこのロールを関連付けると、李四は承認プロセス中の「バイヤー３」というロールの承認タスクと承認権限を自動的に取得する。

７、従来の権利管理メカニズムでは、ロールをグループ、職種、クラスなどに定義し、ロールがユーザーとの１対多の関係にあり。実際にシステムを使用するプロセスでは、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限変更を処理する場合、ロールを関連付ける従業員の権限が変更され、このロールは権限を変更しない他の従業員に関連付けるので、個々の従業員の権限を変更したため、全体のロールの権限を変更できない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。

しかし、本発明の方法では、ロールが独立した個体であるため、ロール権限を変更して目標を達成することができる。本発明の方法は、システムの初期化時にワークロードを増加させるように見えるが、ロールの作成或は権限授与の効率は、コピーなどの方法によってグループの性質を有する従来のロールより高くさせる。ユーザーに関連つける時にグループの性質を有するロールの共通性を考慮しないため、本発明の技術的手段は、承認設定を明確にさせる。特に、システムが一定期間使用された後（ユーザー／ロールの権限動的に変化している）、本発明の技術的手段は、システム使用時のシステム管理の効率を大幅に向上させ、動的認証をより簡単、便利、明確にさせ、権限設定の効率と信頼性を向上させる。

８、従来のグループの性質を有するロールの承認方法はエラーが発生しやすく、本発明の方法では、従来の方法でこのグループの性質を有するロールを関連付ける複数のユーザーにどのような共通性があるかを考慮することなく、ロールを独立した個体として考慮するだけでよいため、本発明の方法は権限エラーの確率を大幅に低減させる。承認エラーが発生した場合でも、ロールを関連付けるその一つのユーザーのみに影響するが、従来のグループの性質を有するロールはそのロールを関連付ける全部のユーザーに影響する。承認エラーが発生した場合でも、本発明の修正方法は簡単であり、時間が短く、従来のグループの性質を有するロールはエラーを修正する時にそのロールを関連付ける全部のユーザーの共通性を考えなければならない。機能ポイントが多い場合、変更が面倒且つ複雑であるだけでなく、非常にエラーが発生しやすく、且つ多くの場合、新しいロールを作成するだけで解決できる。

９、従来のグループの性質を有するロールの承認方法では、ロールの権限機能ポイントが多くある場合、時間が長くなると、ロールの具体的な権限を覚えにくく、権限の近付くロールの間の区別を覚えるのはより困難である。本発明の方法のロール自身は、役職番号／職務番号の性質を有しており、選択は明らかである。

１０、異動するときに、異動されたユーザーの多くの権限を他のユーザーに割り当てる場合、処理する時に異動されたユーザーのこれ等の権限を区別して、他のユーザーを関連付けるためにロールをそれぞれ作成する必要がある。このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすくなる。

本発明の方法は次のとおりである。異動されたユーザーは複数のロールを関連付け、異動する場合、まずユーザーと元の部門のロールの関連付けを取り消し（これ等の取り消されたロールは他のユーザーに再度関連付けることができる）、ユーザーは新しい部門のロールを関連付けてもよい。操作は簡単であり、エラーが現れない。

図１は、従来技術においてシステムがユーザを直接承認する方法の概略図である。 図２は、従来技術においてグループ／クラスの性質を有するロールを承認する方法の概略図である。 図３は、従来技術においてシステムがユーザーを直接承認し、グループ／クラスの性質を有するロールを承認して組み合わせる方法の概略図である。 図４は、本発明のシステムが独立した個体の性質を有するロールによりユーザーを承認する方法の概略図である。 図５は、本発明によるワークフロー承認プロセスの概略図である。

本発明の技術的手段は、添付の図面を参照して以下でさらに詳細に説明されるが、本発明の保護範囲は以下に限定されない。

基準フィールドにより承認プロセスを設置する方法は、承認フォームのために基準フィールドを決定するステップ、承認プロセスを作成するステップ、及びユーザーに提出された承認フォームにより承認プロセスを自動的に関連付けるステップを含む。承認フォームのために基準フィールドを決定するステップは、ワークフローの承認を必要とする各フォームのために一つの基準フィールドを決定し、或いは基準フィールドによりワークフローの承認を行う各フォームのために一つの基準フィールドを決定し、一つの承認フォームが同時期に基本フィールドを決定でき、且つ一つしか決定しない。承認プロセスを作成するステップは、Ｓ１：その承認プロセスに対応する一つのフォームを選択（或は設定）し、１つのフォームが一つ或は複数の承認プロセスに対応すること、Ｓ２：その承認プロセスのために一つの基準フィールドを選択し、１つ或は複数の承認プロセスに一つの基準フィールドが選択でき、基準フィールドが提出ロール、或はフォームに対応するロール属性フィールドの一つ、或はフォームに対応する部門属性フィールドの一つであること、Ｓ３：その承認プロセスのステップＳ２に選択された基準フィールドのフィールド値セットを設定し、各フィールド値（基準フィールドの各フィールド値）が、その基準フィールドの下の承認プロセスのフィールド値セットのみに存在できることを含む。「承認フォームのために基準フィールドを決定するステップ」と「承認プロセスを作成するステップ」という二つのステップには前後順序がない。選択された基準フィールドが提出ロール、或はフォームに対応するロール属性フィールドである場合、フィールド値セットのフィールド値が全てロールであり、選択された基準フィールドがフォームに対応する部門属性フィールドである場合、フィールド値セットのフィールド値が全てロールである。ユーザーに提出された承認フォームにより承認プロセスを自動的に関連付けるステップは、ＳＳ１：ユーザーに提出された承認フォーム（フォームデータ）により、システムはがその承認フォーム（そのフォームデータに対応する承認フォーム）に決定された基準フィールドを見つけること、ＳＳ２：ステップＳＳ１で決定された基準フィールドに従って、その承認フォームの基準フィールドにより対応の承認プロセスを見つけない場合（承認プロセスにそのフォームの基準フィールドをその基準フィールドとするのもがない）、「対応の承認プロセスなし」を表示し（「対応の承認プロセスなし」を指摘する）、見つかる場合に、その基準フィールドに対応するすべての承認プロセスを見つけてステップＳＳ３に移動し、或は見つかる場合に、ステップＳＳ３に直接移動すること、ＳＳ３：その承認フォーム（フォームデータ）の基準フィールドのフィールド値に従って、それがどの承認プロセスに対応する基準フィールドのフィールド値セットに属するかを判断すると、その承認フォーム（フォームデータ）がこの承認プロセスを使って承認して承認フォーム（フォームデータ）と承認プロセスの関連付けを完成することを含む。

承認プロセスは、フォーム内の基準フィールドのフィールド内容により決定する可能性があり、複数の承認プロセスを一つの承認フォームに割り当てる。フォーム内の基準フィールド（目下の基準フィールド）のフィールド内容によりプロセスを決定するのは、簡単、明確となり、理解しやすい。

例えば、契約フォームは、そのフォームの「契約署名部門」が基準フィールド（目下の基準フィールド）であることを決定し、これらの３つの承認プロセスも契約フォームの「契約署名部門」を基本フィールドとして選択し、これらの３つの承認プロセスはプロセスＡ、Ｂ、Ｃである。承認プロセスＡの契約署名部門のフィールド値セットには「販売一部、販売二部、販売三部など」を含み、承認プロセスＢの契約署名部門のフィールド値セットには「販売四部、販売五部、販売六部など」を含み、承認プロセスＣの契約署名部門のフィールド値セットには「販売七部、販売八部、販売九部」を含む。これで、ユーザーは承認のために一つの契約フォーム（契約）を提出し、そのフォーム（契約）の「契約署名部門」が販売九部であり、その提出された契約フォーム（この契約）は承認プロセスＣで承認される。そのフォーム（契約）の「契約署名部門」が販売五部である場合、提出された契約フォームは承認プロセスＢで承認される。

特別な説明は、販売一部が承認プロセスＡの基準フィールド「販売署名部門」のフィールドセットのみに含まれ、承認プロセスＢ或は承認プロセスＣの基準フィールド「販売署名部門」のフィールドセットに同時に存在することはできない。

本実施例には、フォームの基準フィールドを置き換えることができる。例えば、契約フォームの基準フィールドを置き換えると、基準フィールドが「契約署名部門」から「契約署名ロール」に変更される（つまり、目下の基準フィールドが「契約署名部門」から「契約署名ロール」に変更され、「契約署名ロール」が目下の基準フィールドになる）。現在、ユーザーが承認のために契約フォーム（契約）を提出すると、「契約署名ロール」（目下の基準フィールド）の承認プロセスが、関連するルールに従って、提出された契約フォーム／契約データを承認する（契約署名部門の承認プロセスとは関係ない）。

複雑な応用の場合には、たとえば、システムに３つの事業部門があり、各事業部門が異なる製品を販売する。従来の方法では、販売契約フォームは１つの承認プロセスのみを作成する可能性があり、作成時に複雑なプロセス条件と承認経路を設定する必要がある。これは、複雑であり、エラーが発生しやすいだけでなく、管理ニーズを完全に満たす承認プロセスを設定することも困難である。本発明には、３つの事業部門の販売契約の承認要件を満たすために、販売契約フォームに対して３つの承認プロセスを作成する可能性があり、同時に、システムユーザーは、契約の承認（承認プロセス）を行う（選択／決定）ために、「契約署名部門」、「提出ロール」等のフィールドの中にどちらをを使用するかどうかも自分が決定する可能性があり、ユーザーのニーズをより正確に満たすことができる。使用プロセスでは、プロセスユーザーはそれを明確かつ簡単に理解し、明確かつ簡単に修正し、修正プロセス中に他のプロセスの使用に影響しない。

ユーザーは、ニーズに応じて異なるフォームを使ってさまざまな基本フィールドが選択でき、且つ基準フィールドも置き換えることができるため、異なるフォームのさまざまな管理ニーズに大いに対応できる。たとえば、一部のシステムユーザーは、契約の承認中に「契約署名のロール」で承認プロセスを実行したがるが、一部のユーザーは「契約署名部門」で承認プロセスを実行したがり、一部のユーザーも「提出者」で承認プロセスを決定したがる場合、システムユーザーはニーズに応じてフォームの基準フィールドを自由に変更して問題を解決する可能性がある（フォームの基準フィールドを変更した後、提出されたフォームデータは、対応するフォームの目下の基準フィールドに対応する承認プロセスで承認を実行する。たとえば、目下の契約フィールド「契約署名ロール」が「契約署名部門」に置き換えられた場合、「契約署名部門」が目下の契約フィールドになる。たとえば、契約が承認のために提出された後、契約フォームの目下の基準契約フィールド「契約署名部門」に対応する承認プロセスが承認されるが、「契約署名ロール」に対応する承認プロセスが承認されない。つまり、提出されたフォームデータは、対応するフォームの目下の基準フィールドに対応する承認プロセスで関連する承認を実行する）。

そのフィールド値セットには、ヌル値である一つのフィールド値を含み、承認プロセスを設定するとき、選択された基準フィールドのフィールド値がヌル値であるフォームに対応する一つの承認プロセスを設定し、ユーザーに提出された承認フォーム（フォームデータ）に基準フィールドの内容がヌル値である場合、この承認プロセスを使って承認する。

例えば、承認のために契約を提出するときに、契約フォーム（フォームデータ）の契約署名部門のフィールドにヌル値であると（この契約フォームの契約署名部門は記入必須項目ではないため）、その提出された契約フォームは、「契約フォームに決定された基準フィールド（契約署名部門が目下の基準フィールドである）の契約署名部門フィールド値セットにヌル値を含む承認プロセス」により承認される。

選択された基準フィールドが唯一の承認プロセスのみに対応する場合、前記承認プロセスに選択された基準フィールドのフィールド値セットには「すべて」という一つのフィールド値選択項が選択でき、「すべて」を選択し、ユーザーに提出された承認フォーム（フォームデータに対応する承認フォーム）により決定された基準フィールドは、その承認プロセスに選択された基準フィールドと同じになると、ユーザーに提出された承認フォーム（フォームデータ）に基準フィールドのフィールド値が何値であるかに関わらず、その提出された承認フォーム（フォームデータ）は、その承認プロセスを使って承認を行い、且つ新しく追加された基準フィールドのフィールド値も承認プロセスを使って承認を行う（つまり、新しく追加されたその基準フィールドのフィールド値に関われたプロセスはすべてその承認プロセスである）。

例えば、契約フォームは、そのフォームの「契約署名部門」が基準フィールド（目下の基準フィールド）であることを確認し、且つ一つの承認プロセスのみが「契約署名部門」を選択して基準フィールドとする。そのプロセスの契約署名部門のフィールド値セットには「全て」を含む（「全て」は説明方式に一種だけであり、「全部」等と説明する可能性もある）と、承認するために提出された契約フォーム（フォームデータ）の契約署名部門のフィールド値が何でもあれば（ヌル値であるフィールド値、後で追加されたフィールド値を含む）、その承認プロセスにより全て承認される。

本実施例には、フォームのロール属性フィールド、フォームの部門属性フィールドはすべてラジオ且つ記入必須項目である。この場合、実施例２におけるフィールド値がヌル値である状況が存在しない。（たとえば、契約フォームの「契約署名部門」フィールドの内容は、記入必須項目／選択必須項目でなければならないと、そのフィールドが基準フィールドとなる）

本実施例には、図４に示すように、前記ロールは、グループ／クラスではなく、独立した個体であり、一つのロールは唯一のユーザーを同時期に関連付けることができ、一つのユーザーは一つ或は複数のロールに関連付けることができる。

前記承認プロセスはユーザー−ロール−権限の３層構造モデルに基づく。その中、ロール層には、ワークフローのプロセス承認の操作主体はロールであり、各ロールは独立した個体であり、グループ／クラスではなく、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或は複数のロールを関連付ける。前記ロールの構成は、職名+職務番号である。権限層には、ワークフローの実行中に使用する必要がある権限で構成され、ロールに権限を直接授与しする。ユーザー層には、ユーザーがロールを関連付けることによりワークフローの承認タスクを決定し、ロールを関連付ける権限で承認操作を実行する。

前記ユーザー−ロール−権限の３層構造モデルを構築するのは、以下のステップを含む。ロールを作成し、各ロールは独立した個体であり、グループ／クラスではない。作成されたロールに権限をそれぞれ承認する。ユーザーをロールに関連付け、その中、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或は複数のロールを関連付ける。作成されたロールを先にそれぞれ承認する可能性があり、ユーザーをロールに先に関連付ける可能性もある。

図５に示すように、前記承認プロセスには、一つの開始ノード、少なくとも１つの承認ノード、一つの終了ノードを含む。開始ノードには、ワークフローを発起／申請／提出し、さらに、提出ロールがワークフローを発起／申請／提出して開始ノードをとし、或は一番目の承認ノードを開始ノードととする。承認ノードには、承認ロールを選定し、承認ロールを承認する。システムは、提出ロールに提出されるフォームにより承認プロセスを決定し、ワークフローがある必要のフォームに対して一つ或は複数の承認プロセスを設計するが、一つロールはフォームに１つの承認プロセスのみを選択できる（同じロールは、同じフォーム中の一つのプロセスのみに存在できる）。例えば、２つのプロセスが購入契約フォームにあり、それぞれＰ１プロセスとＰ２プロセスである。Ｐ１プロセスの開始ノードでロールＡを選択されば、Ｐ２プロセスの開始ノードでロールＡを選択できない。この時、ロールＡは、購入契約の承認を追加し、承認を提出するときにＰ１プロセスに自動的に入れる。

終了ノードには、承認プロセスがこのノードに移動した後、その承認プロセスが終了し、その終了ノードが承認操作を行わない。又は、最後の承認ノードを終了ノードとし、その終了ノードが承認操作を行うことが必要とする。

以下は、独立した個体の性質とするロールを介してユーザーを承認する方法の利点を分析している。ユーザーは、それとロールの関連により権限を（取得）決定する。ユーザーの権限を修正しようとしている場合、ロールの所有する権限を調整するによりそのロールを関連付けるユーザーの権限が代わる目的を達成する。ユーザーがロールを関連付けると、そのユーザーはそのロールの全ての操作権限を持っている。

ロールのユーザーに対する関係は１対１である（そのロールが一つのユーザーを関連付ける時に、他のユーザーはそのロールを関連付けることができない。そのロールがユーザーを関連付けない場合、他のユーザーに選定されて関連付けることができる）。ユーザーのロールに対する関係は１対多である（一つのユーザーが同時に複数のロールを関連付けることができる）。

ロールの定義：ロールは、グループ／クラス／カテゴリ／役職／職務／職種の性質を有しないが、非集合の性質を有する。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である（役職番号はここで役職ではなく、一つの役職に同時に複数の従業員がいるが、１つの役職番号は同時に一つの従業員にしか対応できない）。

たとえば、会社のシステムは次のロールが設立できる:総経理、副総経理１、副総経理２、北京販売部Ｉの経理、北京販売部ＩＩの経理、北京販売部ＩＩＩの経理、上海販売エンジニア１、上海販売エンジニア２、上海販売エンジニア３、上海販売エンジニア４、上海販売エンジニア５等。ユーザーとロールの関連関係：その会社の従業員である張三は、会社の副総経理２を務め、同時に北京販売部Ｉの経理を務める場合、張三は副総経理２及び北京販売部Ｉの経理というロールを関連付ける必要がある。張三は両方のロールに対する権限を持っている。

従来のロールの概念は、グループ／クラス／役職／職務／職種の性質であり、１つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号／職務番号と同等であり、映画やテレビドラマのロールに似ている。一つのロールは一つの俳優のみに同時に（幼年、少年、中年...）演じられ、一つの俳優は複数のロールを演じることができる。

ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。

前記ロールの構成は、職名+職務番号である。例えば、作業場生産労働者１、作業場生産労働者２、作業場生産労働者３等様なロールは、独立した個体であり、これは役職番号／職務番号と同等であり、従来の権限管理システムのロールとは異なる。従来のシステムのロールの概念は、役職／職務／職種等のグループ／クラスの性質である。

次の例は、張三という従業員が入社した後、従業員やユーザーやロールの関係を示していった。１.新入職：従業員は新しく雇用され、そのユーザー（従業員）の対応する役職番号／職務番号のロールを直接関連付けてもよい。例えば、張三は会社に加わった（会社は張三に張三というユーザーを割り当てた）。仕事内容は営業部Ｉにあり、北京地区の冷蔵庫製品の販売を担当した（対応するロールは販売部Ｉの「販売エンジニア５」というロールである）。 次に、張三というユーザーが「販売エンジニア５」というロールを直接選択してもよい。

２.職務の追加：一定期間勤務した後、張三は北京で地域テレビ製品の販売を担当するようになり（対応するロールは販売部Ｉの「販売エンジニア８」というロールである）、同時に販売後部門の主管を兼務した（販売後部門の主管というロールに対応する）。 次に、張三というユーザーは、販売部Ｉの「販売エンジニア８」と販売後部門の「販売後主管」という二つのロールを増やして関連付けった。この時に、張三という従業員には、三つのロールを関連付け、これ等は、ぞれぞれ販売部Ｉの「販売エンジニア５」、「販売エンジニア８」、及び販売後部門の「販売後主管」であり、張三というユーザーは、これら３つのロールに対する権限を持った。

３.職務の減少：しばらくして、会社は張三を販売後部門の経理（販売後部門の「販売後経理」というロールに対応する）として任命し、他の仕事を兼務しないようにすることを決めった。 次に、張三というユーザーは、販売後部門の「販売後経理」というロールに関連付けられ、以前に関連付けられていた３つのロールを取り消した（販売部Ｉの「販売エンジニア５」、「販売エンジニア８」、及び販売後部門の「販売後主管」）。この時に、張三というユーザーは販売後部門の「販売後経理」というロールの権限のみを持っていった。

４.ロールの権限の調整（ロールの自身所有する権限に対して調整する）：会社が販売後経理の権限を増やすことを決定した場合、販売後経理というロールの権限を増やすだけでよく、張三というユーザーは販売後経理というロールの権限が増加するため、張三というユーザーの権限も増加した。

５.辞任：１年後、張三は辞任した。張三というユーザーと販売後部門の「販売後主管」というロールの関連を取り消してもよい。

例えば、会社は動的な経営中、従業員の入社と退社が頻繁に継続的に発生するが、役職番号／職務番号の修正は非常にわずかである（特定の期間で変化しない）。

従来の承認方法：システム機能ポイントが多くある場合、従来のグループ／クラスとするロールを介して承認する。これは、承認に大量の複雑な作業負荷があるだけでなく、エラーが発生しやすい。エラーが発生した場合でも、短時間で容易に見つけなく、システムのユーザーに損失を与えやすい。

本発明の承認方法：本発明は、役職番号／職務番号の性質とするロールに対して承認し、ユーザーがロールを関連付けて権限を決定（取得）すると、ユーザーの権限を制御するのは、単純なユーザーとロールの関連付けにより実現される。これにより、権限の制御を簡単、便利、明確にして、権限承認の効率と信頼性を大幅に向上させる。

上記は本発明の優先的な実施形態だけである。本発明は、本明細書に開示された形態に限定されないと理解され、他の実施形態を除くとみなされなく、却って様々な他の組み合わせや修正や環境に利用でき、本明細書のコンセプトの範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全部と本発明に添付される請求項の範囲内にあるべきである。

Claims (10)

1. 基準フィールドにより承認プロセスを設置する方法であって、承認フォームのために前記基準フィールドを決定するステップ、前記承認プロセスを作成するステップ、及びユーザーに提出された前記承認フォームにより前記承認プロセスを自動的に関連付けるステップを含み、
   前記承認フォームのために基準フィールドを決定するステップは、ワークフローの承認を必要とする各フォームのために一つの基準フィールドを決定し、或いは前記基準フィールドによりワークフローの承認を行う各フォームのために一つの基準フィールドを決定し、一つの前記承認フォームが同時期に基本フィールドを決定でき、且つ一つしか決定しなく、
   承認プロセスを作成するステップは、
   Ｓ１：前記承認プロセスに対応する一つのフォームを選択し、１つのフォームが一つ或は複数の承認プロセスに対応すること、
   Ｓ２：前記承認プロセスのために一つの基準フィールドを選択し、１つ或は複数の承認プロセスに一つの基準フィールドが選択でき、前記基準フィールドが提出ロール、或はフォームに対応するロール属性フィールド、或はフォームに対応する部門属性フィールドであること、 および、
   Ｓ３：前記承認プロセスのステップＳ２で選択された基準フィールドのフィールド値セットを設定し、各フィールド値が、前記基準フィールドの下の承認プロセスのフィールド値セットのみに存在できること、を含み、
   ユーザーに提出された承認フォームにより承認プロセスを自動的に関連付けるステップは、
   ＳＳ１：ユーザーに提出された承認フォームにより、システムはが前記承認フォームに決定された基準フィールドを見つけること、
   ＳＳ２：ステップＳＳ１で決定された基準フィールドに従って、前記承認フォームの基準フィールドにより対応の承認プロセスを見つけない場合、「対応の承認プロセスなし」を表示し、見つかる場合に、前記基準フィールドに対応するすべての承認プロセスを見つけてステップＳＳ３に移動し、或は見つかる場合に、ステップＳＳ３に直接移動すること、および、
   ＳＳ３：前記承認フォームの基準フィールドのフィールド値に従って、それがどの承認プロセスに対応する基準フィールドのフィールド値セットに属するかを判断すると、前記承認フォームがこの承認プロセスを使って承認して承認フォームと承認プロセスの関連付けを完成すること、を含む方法。
2. 選択された基準フィールドが提出ロール、或はフォームに対応するロール属性フィールドである場合、フィールド値セットのフィールド値が全てロールであり、選択された基準フィールドがフォームに対応する部門属性フィールドである場合、フィールド値セットのフィールド値が全てロールである請求項１に記載の方法。
3. 前記フィールド値セットには、ヌル値である一つのフィールド値を含み、承認プロセスを設定するとき、選択された基準フィールドのフィールド値がヌル値であるフォームに対応する一つの承認プロセスを設定し、ユーザーに提出された承認フォームに基準フィールドの内容がヌル値である場合、この承認プロセスを使って承認する請求項１に記載の方法。
4. 選択された基準フィールドが唯一の承認プロセスのみに対応する場合、前記承認プロセスに選択された基準フィールドのフィールド値セットには「すべて」という一つのフィールド値選択項が選択でき、「すべて」を選択し、ユーザーに提出された承認フォームにより決定された基準フィールドは、前記承認プロセスに選択された基準フィールドと同じとなると、ユーザーに提出された承認フォームに基準フィールドのフィールド値が何値であるかに関わらず、提出された前記承認フォームは、前記承認プロセスを使って承認を行い、且つ新しく追加された基準フィールドのフィールド値も承認プロセスを使って承認を行う請求項１又は３に記載の方法。
5. フォームのロール属性フィールド、フォームの部門属性フィールドはすべてラジオ且つ記入必須項目である請求項１に記載の方法。
6. 前記ロールは、グループ／クラスではなく、独立した個体であり、一つのロールは唯一のユーザーに同時期に関連付けることができ、一つのユーザーは一つ或は複数のロールに関連付けることができる請求項１に記載の方法。
7. 前記ロールは部門に属し、前記ロールは前記部門内で唯一であり、ロールの作業内容によりロールを承認し、ユーザーはロールを関連付けるにより権限を取得する請求項６に記載の方法。
8. ユーザーが部門間を移動する時、先ずユーザーと元の部門のロールの関連を取り消し、次に前記ユーザーを新しい部門内のロールに関連付ける請求項７に記載の方法。
9. 前記承認プロセスは、ユーザー−ロール−権限の３層構造モデルに基づいて、その中、ロール層には、ワークフローのプロセス承認の操作主体はロールであり、各ロールは独立した個体であり、グループ／クラスではなく、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或は複数のロールを関連付け、権限層には、ワークフローの実行中に使用する必要がある権限で構成され、ロールに権限を直接授与し、ユーザー層には、ユーザーがロールを関連付けることによりワークフローの承認タスクを決定し、ロールを関連付ける権限で承認操作を実行する請求項６に記載の方法。
10. 前記承認プロセスには、一つの開始ノード、少なくとも１つの承認ノード、一つの終了ノードを含み、開始ノードには承認プロセスを開始し、承認ノードには承認ロールを選択し、承認ロールに権限を与え、終了ノードには承認プロセスが終了する請求項１に記載の方法。