JP6843405B2 - フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法 - Google Patents

Description

本発明は、ＥＲＰなどの管理ソフトウェアシステムのワークフローに承認ノードの承認権限を設定する方法に関し、特にフォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法に関する。

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

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

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

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

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

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

３、図３に示すように、上記の２つの方法が組み合わされている。

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

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

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

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

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

従来のシステムのワークフロー承認メカニズムには、次の欠陥がある。

（１）プロセス発起者は、承認ノードで承認者としてプロセス発起者自身を選択できず、承認プロセスが完了する前に、承認プロセスの発起者は、提出された申請の承認結果を照合し確認できない。たとえば、発起者は１０，０００元の払い戻し承認申請を提出して、発起者から提出された内容が異なる又はその他の理由がある場合、承認プロセスは終了する。複数の等級に承認された後、確認された払い戻し額は５００元に修正され、最終承認結果は５００元しか許さず、承認プロセスは完了して終わる。承認結果を受け取った後、発起者が異議を唱えた場合、以前の承認プロセスの結果を無効にする必要があり、その後、承認申請が再提出される。これにより、システムの内部消費が増加し、承認の効率が低下する。

（２）複雑な組織構造を持つ州間及び多国籍のグループ会社に対しては、関与する承認プロセスの数は非常に多く、承認プロセスの流通条件と流通路線も非常に複雑である。システムプロセスの設定担当者にとっては、作業負荷が非常に大きく、承認プロセスの設定を間違いやすいため、システムの使用は非常に不便であり、システムの信頼性は高くならない。

（３）等級に応じて承認が設定されている場合、最上級の部門主管が提出した承認要求に対してシステムは承認を実行することができない。通常、最上級の部門主管に対して専門的な承認ロールを個別に割り当てる必要があり、システムワークフローを設定する担当者の作業負荷が増加する。

（４）承認プロセスに提出されたロールのみ、部門等級を判断するための判断基準として提出でき、部門等級を判断するための基準とするようにフォームに含まれる他のロールあるいは部門をカスタマイズすることはできず、特定の使用制限がある。

例えば、契約承認プロセスに対して契約の署名ロールが休暇中のため、彼の同僚は彼に代わって契約承認を発起し、システムは彼の同僚がプロセスの提出ロールであると判断する。等級で判断する時に等級の判断は同僚に基づいて行われ、契約の署名ロールの所属する部門と役職を客観的に反映することはできない。たとえば、契約の署名ロールは販売部門の販売員１であり、その同僚ロールはＲ＆Ｄ部門の開発者１であり、その契約は、署名ロールの所属する部門の部門主管―販売主管に前もって承認される必要がある。承認ノードの承認等級を１に設定する時、システムは開発者１の所属する部門の主管―販売主管が承認するように分配し、承認プロセスに分配エラーと使用の不便が現れる。

本発明の目的は、従来技術の欠陥を克服し、フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法を提供し、部門等級を判断する基準とするように需要によりフォームに関与するロール属性フィールド、部門属性フィールドまたは提出ロールをカスタマイズする。このようにして、承認ロールを決定し、使用がより柔軟、便利になる。

本発明の目的は、以下の技術的手段により達成される。

フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法は、システムの組織構造を設定するステップと、部門等級により承認ロールを設定するステップを含む。

前記システムの組織構造を設定するステップは、
ＳＳ１）システムの組織構造に含まれる部門とロールを設立すること、
ＳＳ２）部門間の階層関係を設置し、各部門の部門主管ロールを設定することを含む。

前記部門等級により承認ロールを設定するステップは、
ＳＳＳ１）等級方式により承認を行うロールの設定を選択すること；
ＳＳＳ２）承認プロセスの対応するフォームにロール属性フィールド、部門属性フィールドあるいはその承認プロセスの提出ロールを選択し、等級主体とすること；
ＳＳＳ３）特定の等級値ｎを入力し、ｎは０以上の正整数であり、
（１）承認プロセスの対応するフォームのロール属性フィールドを選択して等級主体とし、そのフィールドの対応するロールを判断基準として等級を判断し、
[１]ｎ＝０では、そのフィールドの対応するロールはその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、そのフィールドの対応するロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、フィールドに対応するロールがそれの所属する部門の部門主管ロールである場合、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、そのフィールドの対応するロールの所属する二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、そのフィールドの対応するロールの所属する三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
（２）承認プロセスの対応するフォームの部門属性フィールドを選択して等級主体とし、そのフィールドの対応する部門を判断基準として等級を判断し、
[１]ｎ＝０では、そのフィールドの対応する部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、そのフィールドの対応する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、そのフィールドの対応する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、そのフィールドの対応する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[５]その他もろもろ、枚挙にいとまがない；
[６]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
（３）承認プロセスの提出ロールを選択して等級主体とし、その提出ロールを判断基準として等級を判断し、
[１]ｎ＝０では、ワークフロー承認プロセスの提出ロールはその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、ワークフロー承認プロセスの提出ロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、提出ロールがそれの所属する部門の部門主管ロールである場合、その提出ロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、ワークフロー承認プロセスの提出ロールの所属する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、ワークフロー承認プロセスの提出ロールの所属する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、ワークフロー承認プロセスの提出ロールの所属する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当することを含む。

承認ノードを選択するのは等級承認である時、等級の対応する承認ロールに対して承認権限の授与を行うと、この等級の対応する承認ロールの承認権限は全て同じになる。

前記フォームのロール属性フィールドと部門属性フィールドは、記入用のラジオボタンである。

前記ワークフローの制御方法は、
Ｓ１）ユーザー−ロール−権限の３層構造モデルを構築し、その中で、ロール層では、ワークフローのプロセス承認の本体はロールであり、各ロールは独立した個体であり、グループ／クラスではあらず、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付け；権限層は、ワークフローの実行中に使用する必要がある権限で構成され、ロールに権限を直接授与する；ユーザー層：ユーザーは、ロールを関連付けることによりワークフローの承認タスクを決定し、ロールを関連付ける権限で承認操作を実行すること；
Ｓ２）３層構造モデルによりワークフローを制御し、１つの承認プロセスには、１つの開始ノード、少なくとも１つの承認ノード、１つの終了ノードを含み、開始ノードは、ワークフローを発起／申請／提出し、さらに提出ロールはワークフローを発起／申請／提出すると、ワークフローを発起する権限を持つロールは、提出ロールとしてワークフローを発起／申請／提出し、システムは、提出ロールに提出されるフォームにより承認プロセスを決定し、ワークフローが必要なフォームに対して1つ以上の承認プロセスを設計するが、一つのロールはフォームに1つの承認プロセスのみを選択でき、承認ノードは、承認する部門の等級を設定し、等級内の対応する承認ロールの承認権限を承認し、終了ノードは：プロセスがこのノードに移動した後、承認プロセスの承認が終了したことを示すこと；
Ｓ３）ユーザーは、関連付けられるロールにより処理する必要のある承認タスクを決定し、関連付けられるロールの権限により承認操作を行うことを含む。

承認ノードで1つ以上の承認ロールを選択し、１つの承認ロールは同じ承認プロセスで異なる承認ノードに存在でき、フォームフィールドに対して異なる承認ノードにその承認ノードが異なる可能性がある。

承認ノードで1つ以上の承認ロールを選択し、承認ノードで承認ロールを設定し、各承認ノードの承認ロールごとに対して独立した権限設定を行うことが可能になる。

前記ステップＳ１には、（１）各ロールがグループ／クラスではなく独立した個体であるロールを作成すること、（２）ステップ（１）で作成されたロールをそれぞれ承認すること、（３）ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付けることを含む。

ステップ（１）が先行するが、ステップ（２）とステップ（３）は連続順序関係にない。

前記ロールは部門に属し、ロール名称は部門内で唯一であり、ロール番号はシステム内で唯一であり、ユーザーの部門間管理は、（１）ユーザーと元の部門のロールの関連を取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む。

前記ユーザーはロールとの関連付けにより権限を決定し、１つのユーザーが１つのユーザーアカウントに対応し、１つのユーザーアカウントが１つのユーザーに対応する。

前記ロールは職名＋職務番号で構成される。

フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法は、システムの組織構造を設定するステップと、部門等級により承認ロールを設定するステップを含む。

前記システムの組織構造を設定するステップは、
ＳＳ１）システムの組織構造に含まれる部門とロールを設立すること、
ＳＳ２）部門間の階層関係を設置し、各部門の部門主管ロールを設定することを含む。

前記部門等級により承認ロールを設定するステップは
ＳＳＳ１）等級方式により承認を行うロールの設定を選択すること；
ＳＳＳ２）承認プロセスの対応するフォームにロール属性フィールド、部門属性フィールドあるいはその承認プロセスの提出ロールを選択し、等級主体とすること；
ＳＳＳ３）特定の等級値ｎを入力し、ｎは０以上の正整数であり、
（１）承認プロセスの対応するフォームのロール属性フィールドを選択して等級主体とし、そのフィールドの対応するロールを判断基準として等級を判断し、
[１]ｎ＝０では、そのフィールドの対応するロールはその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、そのフィールドの対応するロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、フィールドに対応するロールがそれの所属する部門の部門主管ロールである場合、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、そのフィールドの対応するロールの所属する二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、そのフィールドの対応するロールの所属する三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[８]ｎ＞１では、「そのフィールドの対応するロールは、それの所属する部門の部門主管であり、しかもその部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要がある；
（２）承認プロセスの対応するフォームの部門属性フィールドを選択して等級主体とし、そのフィールドの対応する部門を判断基準として等級を判断し、
[１]ｎ＝０では、そのフィールドの対応する部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、そのフィールドの対応する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝３では、そのフィールドの対応する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、そのフィールドの対応する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[５]その他もろもろ、枚挙にいとまがない；
[６]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[７]ｎ＞１では、「そのフィールドの対応する部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要がある；
（３）承認プロセスの提出ロールを選択して等級主体とし、その提出ロールを判断基準として等級を判断し、
[１]ｎ＝０では、ワークフロー承認プロセスの提出ロールはその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、ワークフロー承認プロセスの提出ロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、提出ロールがそれの所属する部門の部門主管ロールである場合、その提出ロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、ワークフロー承認プロセスの提出ロールの所属する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、ワークフロー承認プロセスの提出ロールの所属する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、ワークフロー承認プロセスの提出ロールの所属する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[８]ｎ＞１では、「そのフィールドの対応するロールは、それの所属する部門の部門主管であり、しかもその部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要があることを含む。前記指定グループの承認は、（１）１つ以上の承認ロールが指定グループを構成する場合；（２）指定グループは部門等級により決定され、等級本体を選択する場合、その承認ノードにより選択された等級本体のみを踏襲し、等級値ｎは０のみに設定できる場合；（３）指定グループは部門等級により決定され、等級本体が自主的に選択し、指定グループには、１つ以上の指定ノードを含み、指定ノードの等級値ｎが０以外である場合、下級の指定ノードを設定する必要があり、指定ノードの等級値ｎが０であるまで、承認ノードの指定グループを設定して終わる場合から１つを含む。

本発明の有益な効果は次のとおりである：（１）従来の等級承認方法は、部門等級を判断するように判断基準としてロールが承認プロセスで提出できるだけ、部門等級を判断する基準とするようにフォームに関与する他のロールまたは部門をカスタマイズすることはできず、使用には特定の制限がある。

例えば、契約承認プロセスに対して契約の署名ロールが休暇中のため、彼の同僚は彼に代わって契約承認を発起し、システムは彼の同僚がプロセスの提出ロールであると判断する。等級で判断する時に等級の判断は同僚に基づいて行われ、契約の署名ロールの所属する部門と役職を客観的に反映することはできない。たとえば、契約の署名ロールは販売部門の販売員１であり、その同僚ロールはＲ＆Ｄ部門の開発者１であり、その契約は、署名ロールの所属する部門の部門主管―販売主管に前もって承認される必要がある。承認ノードの承認等級を１に設定する時、システムは開発者１の所属する部門の主管―販売主管が承認するように分配し、承認プロセスに分配エラーと使用上の不便さが現れる。

本発明は、部門等級を判断する基準とするようにフォームに関与するロール属性フィールド、部門属性フィールド、または提出ロールを需要によりカスタマイズできる。たとえば、承認ノードを設定する場合、契約フォームの署名ロールを等級主体として選択でき、部門等級を判断するために署名ロール（提出ロールを純粋にデフォルトにしない）が基準として使用され、このようにして、承認ロールは販売部門の主管ロールであると判断され、使用はより柔軟で便利であり、汎用性が高い。

（２）システムは最高等級の部門主管の承認メカニズムを提供し、最高等級の部門主管が等級承認により承認プロセスを完成できないという問題を回避する。

例えば、会社の最高等級指導者の会長が承認要求を提出する時、等級承認には会長の上級部門はないが、議長から提出された承認請求を承認する指定グループを設定する。

指定グループは、[１]指定グループは1つ以上の承認ロールで構成され、たとえば、複数の監督委員会成員が指定グループを構成し、会長の承認請求を監督委員会成員が承認する場合；[２]指定グループは、部門等級により決定され、等級主体を選択する時に承認ノードにより選択された等級主体を踏襲し、且つ等級値ｎを０のみに設定でき、企業の組織構造の変更に対応するためにこの状況を適用し、たとえば、会社の元の最高等級主管は総経理であり、組織構造を変更した後、取締役会を追加し、最高等級主管が会長になり、承認ノードの等級値が０になると、承認ロールは総経理に固定されるのではなく、自動的に議長に変わり、承認ロールが組織の変更に適応できないという問題を回避する場合；[３]指定グループは、部門等級により決定され、等級主体を自主的に選択でき、選択する時に承認ノードにより選択された等級主体を踏襲し，指定グループには１つ以上の指定ノードを含み、指定ノードの等級値ｎが０以外である場合、下級の指定ノードを設定する必要があり、指定ノードの等級値ｎが０であるまで、承認ノードの指定グループを設定して終わり、一般部門のロール承認に最高等級の部門主管から提出される承認申請を適用し、たとえば、財務部門の財務主管は、会長が提出した契約承認請求に関連する支払い情報を承認でき、それには最終的に会長が確認する必要がある場合からの一つを含む。

（３）承認ノードが承認ロールを設定する時に部門等級ｎを０に設定でき、つまり、提出ロール自身が承認ノードの承認ロールとして選択される。承認プロセスを完成する前に、提出ロール自身が承認して確認でき、不同意を選択すれば、再承認に戻り、同意を選択すれば、次のステップに入り、提出ロールの照合手順を追加し、承認結果が間違っているか、承認結果が提出ロールの予想と一致しないため新しい（再提出）承認プロセスが必要であるという問題を回避し、システムの内部消耗を削減し、承認プロセスの効率と信頼性を向上させる。

たとえば、提出ロールが１０，０００元の払戻承認申請を提出したが、提出ロールに提出された内容が間違っているか、その他の理由がある場合、複数等級により承認した後、承認された払戻額は５００元に修正される。承認プロセスを完成する前に、承認ロールとする提出ロールにより照合することにより問題が発見でき、不同意を選択すれば、再承認に戻り、次のステップに入り、承認プロセスを作成（再提出）する必要はない。

（４）部門等級で承認ロールを設定する方式により、システムワークフローの設定担当者は、承認ロールを設定するときに等級本体を選択し、等級値を入力するだけで済む。複数の承認プロセスを1つの承認プロセスに有効的に統合して、流布条件と流布線路を有効的に削減でき、システムワークフローの設定担当者の作業負荷を軽減し、システムの信頼性を向上させる。たとえば、経費払戻承認プロセスでは、承認ノードで等級承認を設定し、部門等級を１に設定すると、その承認ノードで提出ロールの所属する部門の部門主管が全ての経費払戻を自動的に承認する。

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

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

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

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

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

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

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

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

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

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

（１２）ロールが部門に属している場合、ロールは部門を変更できず、ロールが部門を変更できないのはなぜか？理由１：本発明のロールの性質は役職番号／職務番号と同等であるため、様々な役職番号／職務番号の作業内容／権限は異なる。たとえば、販売部門の販売員１のロールと技術部門の開発者１のロールは、２つの役職番号／職務番号がまったく異なり、権限が異なる。理由２：販売員１のロール部門（販売部門）が技術部門に置き換えられる場合、販売員１のロールを変更しない限り、技術部門には販売部門の権限を持つロールがある。これは、管理の混乱とセキュリティの脆弱性につながる可能性がある。

（１３）１つのロールは、同じ承認プロセスに異なる承認ノードが存在でき、各承認ノードの承認ロールに対して独立した権限設定を行うことができ、その承認ロールは、異なる承認ノードでフォームフィールドに対する検分権限、変更権限が異なる可能性がある。優先的な例えとして、あるロールは成都販売経理３であり、契約承認ワークフローでは、それが成都販売契約承認と上海販売契約承認の２つの承認ノードに存在する。成都販売契約の承認ノードに対して、そのロールは、承認をする時に顧客名、連絡先、連絡先情報、製品数量、製品単価、契約金額等の全てのフィールドを表示でき、製品単価と契約金額を変更できる。ただし、上海の販売契約の承認ノードは、顧客名、連絡先、連絡先情報などの機密フィールドの内容を検分できず、さらにいかなる変更を加えることもできない。このようにして、承認プロセスでロールの権限をカスタマイズできる。

背景技術においてシステムがユーザを直接承認する方法の概略図である。 背景技術においてシステムがグループ／クラスを性質とするロールを承認する方法の概略図である。 背景技術においてシステムがユーザーを直接承認し、グループ／クラスを性質とするロールを承認して組み合わせる方法の概略図である。 実施例におけるシステム組織構造のツリー図である。 本発明によるワークフロー制御方法のフローチャートである。 本発明のシステムが独立した個体を性質とするロールによりユーザーを承認する方法の概略図である。 本発明によるワークフロー承認プロセスの概略図である。 本発明によるユーザーロール承認方法のフローチャートである。

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

フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法は、システムの組織構造を設定するステップと、部門等級により承認ロールを設定するステップを含む。

前記システムの組織構造を設定するステップは、以下のサブステップを含む。

ＳＳ１）システムの組織構造に含まれる部門とロールを設立する。

ＳＳ２）部門間の階層関係を設定し、図４に示すように、部門Ａは部門Ｂより一段階高く、部門Ａは部門Ｃより二段階高く...各部門の部門主管ロールを設定する。

前記部門等級により承認ロールを設定するステップは、以下のサブステップを含む。

ＳＳＳ１）等級方式により承認を行うロールの設定を選択する。

ＳＳＳ２）承認プロセスの対応するフォームにロール属性フィールド、部門属性フィールドあるいはその承認プロセスの提出ロールを選択し、等級主体とし、等級主体を選択する場合、１つのみを選択でき、フォームには複数のロールと部門を性質とするフィールド（署名ロール、担当ロール、署名部門、担当部門など）を含むことができるが、１つのプロセスにプロセスを提供するロールの数は１つのみである。

ＳＳＳ３）特定の等級値ｎを入力し、ｎは０以上の正整数である（ｎの値は、ａ、ｂ、ｃ、ｄなどの他の記号に置き換えることもできる。ｂはａより一段階大きく、ｃはaより二段階大きく、dはaより三段階大きく、その他もろもろ、枚挙にいとまがない）。
（１）承認プロセスの対応するフォームのロール属性フィールドを選択して等級主体とし、そのフィールドの対応するロールを判断基準として等級を判断する。たとえば、プロセスの提出ロールはｄ２であるが、選択されたフォームのロール属性フィールドは署名ロールである。この署名ロールはロールｄ３である。
[１]ｎ＝０では、選定されたロールｄ３はその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、選定されたロールｄ３の所属する部門Ｄの部門主管ロールｄ１はその承認ノードの承認ロールを担当し、フィールドに対応するロールがそれの所属する部門の部門主管ロールである場合、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、選定されたロールｄ３の所属する部門Ｄの上級部門Ｃの部門主管ロールｃ１はその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、選定されたロールｄ３の所属する部門Ｄの二重上級Ｂの部門主管ロールｂ１はその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、選定されたロールｄ３の所属する部門Ｄの三重上級Ａの部門主管ロールａ１はその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する。たとえば、ロールｄ３に対して、部門等級は最大４である必要があり、部門等級が６に設定されると、最高等級部門Ａの部門主管ロールａ１が承認ノードの承認ロールを担当する。

（２）承認プロセスの対応するフォームの部門属性フィールドを選択して等級主体とし、そのフィールドの対応する部門を判断基準として等級を判断し、たとえば、フォーム中の部門属性フィールドを選択して署名部門とする。この署名部門は部門Ｄである。
[１]ｎ＝０では、選定された部門Ｄの部門主管ロールｄ１はその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、選定された部門Ｄの上級部門Ｃの部門主管ロールｃ１はその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、選定された部門Ｄの二重上級Ｂの部門主管ロールｂ１はその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、選定された部門Ｄの三重上級Ａの部門主管ロールａ１はその承認ノードの承認ロールを担当する；
[５]その他もろもろ、枚挙にいとまがない；
[６]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する。たとえば、部門Ｄに対して、部門等級は最大３である必要があり、部門等級が６に設定されている場合、最高等級部門Ａの部門主管ロールａ１が承認ノードの承認ロールを担当する。

（３）承認プロセスの提出ロールを選択して等級主体とし、その提出ロールを判断基準として等級を判断し、たとえば、提出ロールはロールｄ２である。
[１]ｎ＝０では、ワークフロー承認プロセスの提出ロールｄ２はその承認ノードの承認ロールを担当する。承認ノードが承認ロールを設定する時に部門等級ｎを０に設定でき、つまり、提出ロールｄ２は自身が承認ノードの承認ロールとして選択される。承認プロセスを完成する前に、提出ロールｄ２は自身が承認して確認でき、不同意を選択すれば、再承認に戻り、同意を選択すれば、次のステップに入り、提出ロールの照合手順を追加し、承認結果が間違っているか、承認結果が提出ロールの予想と一致しないため、新しい（再提出）承認プロセスが必要であるという問題を回避し、システムの内部消耗を削減し、承認プロセスの効率と信頼性を向上させる。

たとえば、提出ロールｄ２が１０，０００元の払戻承認申請を提出したが、提出ロールに提出された内容が間違っているか、その他の理由がある場合、複数等級により承認した後、承認された払戻額は５００元に修正される。承認プロセスを完成する前に、承認ロールとする提出ロールにより照合すると問題を発見することができ、不同意を選択すれば、再承認に戻り、次のステップに入り、承認プロセスを作成する必要はない。

[２]ｎ＝１では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの部門主管ロールｄ１はその承認ノードの承認ロールを担当する（提出ロールがｄ１である場合、それが所属する部門Ｄの部門主管ロールであると、提出ロールの所属する部門Ｄの上級部門Ｃの部門主管ロールｃ１は、承認ノードの承認ロールを担当する）。[３]ｎ＝２では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの上級部門Ｃの部門主管ロールｃ２はその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの二重上級Ｂの部門主管ロールｂ２はその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの三重上級Ａの部門主管ロールａ１はその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する。たとえば、ロールｄ２に対して、部門等級は最大４である必要があり、部門等級が６に設定されている場合、最高等級部門Ａの部門主管ロールａ１が承認ノードの承認ロールを担当する。

本発明の技術的手段には、提出ロールの等級承認方式による利点に基づいて、別の利点がある。契約署名ロール、契約新規ロール、契約担当ロールなど、さまざまなロールを選択でき、その承認ノードは、等級を提出ロールで判断できず、等級を契約署名ロールで判断できる。たとえば、提出ロールの上級は、払戻フォームに一番目の承認ノードを承認し、他の承認ノードに対しては払戻ロールの上級が承認する（払戻ロールと提出ロールは異なるロールになる場合がある）。

従来の等級承認方法は、部門等級を判断するように判断基準としてロールが承認プロセスで提出できるだけ、部門等級を判断する基準とするようにフォームに関与する他のロールまたは部門をカスタマイズすることはできず、使用には特定の制限がある。

例えば、契約承認プロセスに対して契約の署名ロールが休暇中のため、彼の同僚は彼に代わって契約承認を発起し、システムは彼の同僚がプロセスの提出ロールであると判断する。等級で判断する時に等級の判断は同僚に基づいて行われ、契約の署名ロールの所属する部門と役職を客観的に反映することはできない。たとえば、契約の署名ロールは販売部門の販売員１であり、その同僚ロールはＲ＆Ｄ部門の開発者１であり、その契約は、署名ロールの所属する部門の部門主管―販売主管に前もって承認される必要がある。承認ノードの承認等級を１に設定する時、システムは開発者１の所属する部門の主管―販売主管が承認するように分配し、承認プロセスに分配エラーと使用上の不便さが現れる。

本発明は、承認ノードを設定する場合、契約フォームの署名ロールを等級主体として選択でき、部門等級を判断するために署名ロール（提出ロールを純粋にデフォルトにしない）が基準として使用され、このようにして、承認ロールは販売部門の主管ロールであると判断され、使用はより柔軟、便利であり、汎用性が高い。

フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法は、システムの組織構造を設定するステップと、部門等級により承認ロールを設定するステップを含む。前記システムの組織構造を設定するステップは、以下のサブステップを含む。
ＳＳ１）システムの組織構造に含まれる部門とロールを設立する。
ＳＳ２）部門間の階層関係を設定し、図４に示すように、部門Ａは部門Ｂより一段階高く、部門Ａは部門Ｃより二段階高く...各部門の部門主管ロールを設定する。

前記部門等級により承認ロールを設定するステップは、以下のサブステップを含む。
ＳＳＳ１）等級方式により承認を行うロールの設定を選択する。
ＳＳＳ２）承認プロセスの対応するフォームにロール属性フィールド、部門属性フィールドあるいはその承認プロセスの提出ロールを選択し、等級主体とする。
ＳＳＳ３）特定の等級値ｎを入力し、ｎは０以上の正整数である（ｎの値は、ａ、ｂ、ｃ、ｄなどの他の記号に置き換えることもできる。ｂはａより一段階大きく、ｃはａより二段階大きく、ｄはａより三段階大きく、その他もろもろ、枚挙にいとまがない）。
（１）承認プロセスの対応するフォームのロール属性フィールドを選択して等級主体とし、そのフィールドの対応するロールを判断基準として等級を判断する。たとえば、プロセスの提出ロールはｄ２であるが、選択されたフォームのロール属性フィールドは署名ロールである。この署名ロールはロールｄ３である。
[１]ｎ＝０では、選定されたロールｄ３はその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、選定されたロールｄ３の所属する部門Ｄの部門主管ロールｄ１はその承認ノードの承認ロールを担当し、フィールドに対応するロールがそれの所属する部門の部門主管ロールである場合、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、選定されたロールｄ３の所属する部門Ｄの上級部門Ｃの部門主管ロールｃ１はその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、選定されたロールｄ３の所属する部門Ｄの二重上級Ｂの部門主管ロールｂ１はその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、選定されたロールｄ３の所属する部門Ｄの三重上級Ａの部門主管ロールａ１はその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する。たとえば、ロールｄ３に対して、部門等級は最大４である必要があり、部門等級が６に設定されると、最高等級部門Ａの部門主管ロールａ１が承認ノードの承認ロールを担当する。

[８]ｎ＞１では、「選定されたロールは、それの所属する部門の部門主管であり、またその部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要がある。

（２）承認プロセスの対応するフォームの部門属性フィールドを選択して等級主体とし、そのフィールドの対応する部門を判断基準として等級を判断し、たとえば、フォーム中の部門属性フィールドを選択して署名部門とする。この署名部門は部門Ｄである。
[１]ｎ＝０では、選定された部門Ｄの部門主管ロールｄ１はその承認ノードの承認ロールを担当する；
[２]ｎ＝１では、選定された部門Ｄの上級部門Ｃの部門主管ロールｃ１はその承認ノードの承認ロールを担当する；
[３]ｎ＝２では、選定された部門Ｄの二重上級Ｂの部門主管ロールｂ１はその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、選定された部門Ｄの三重上級Ａの部門主管ロールａ１はその承認ノードの承認ロールを担当する；
[５]その他もろもろ、枚挙にいとまがない；
[６]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する。たとえば、部門Ｄに対して、部門等級は最大３である必要があり、部門等級が６に設定されている場合、最高等級部門Ａの部門主管ロールａ１が承認ノードの承認ロールを担当する。

[７]ｎ＞１では、「選定された部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要がある。

（３）承認プロセスの提出ロールを選択して等級主体とし、その提出ロールを判断基準として等級を判断し、たとえば、提出ロールがロールｄ２である。
[１]ｎ＝０では、ワークフロー承認プロセスの提出ロールｄ２はその承認ノードの承認ロールを担当する。承認ノードが承認ロールを設定する時に部門等級ｎを０に設定でき、つまり、提出ロールｄ２は自身が承認ノードの承認ロールとして選択される。承認プロセスを完成する前に、提出ロールｄ２は自身が承認して確認でき、不同意を選択すれば、再承認に戻り、同意を選択すれば、次のステップに入り、提出ロールの照合手順を追加し、承認結果が間違っているか、承認結果が提出ロールの予想と一致しないため新しい（再提出）承認プロセスが必要であるという問題を回避し、システムの内部消耗を削減し、承認プロセスの効率と信頼性を向上させる。

たとえば、提出ロールｄ２が１０，０００元の払戻承認申請を提出したが、提出ロールに提出された内容が間違っているか、その他の理由がある場合、複数等級により承認した後、承認された払戻額は５００元に修正される。承認プロセスを完成する前に、承認ロールとする提出ロールにより照合すると問題を発見することができ、不同意を選択すれば、再承認に戻り、次のステップに入り、承認プロセスを作成する必要はない。

[２]ｎ＝１では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの部門主管ロールｄ１はその承認ノードの承認ロールを担当する（提出ロールがｄ１である場合、それが所属する部門Ｄの部門主管ロールであると、提出ロールの所属する部門Ｄの上級部門Ｃの部門主管ロールｃ１は、承認ノードの承認ロールを担当する）。[３]ｎ＝２では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの上級部門Ｃの部門主管ロールｃ２はその承認ノードの承認ロールを担当する；
[４]ｎ＝３では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの二重上級Ｂの部門主管ロールｂ２はその承認ノードの承認ロールを担当する；
[５]ｎ＝４では、ワークフロー承認プロセスの提出ロールｄ２の所属する部門Ｄの三重上級Ａの部門主管ロールａ１はその承認ノードの承認ロールを担当する；
[６]その他もろもろ、枚挙にいとまがない；
[７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する。たとえば、ロールｄ２に対して、部門等級は最大４である必要があり、部門等級が６に設定されている場合、最高等級部門Ａの部門主管ロールａ１が承認ノードの承認ロールを担当する。

[８]ｎ＞１では、「そのフィールドの対応するロールは、それの所属する部門の部門主管であり、しかもその部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要がある；
前記指定グループの承認は、（１）１つ以上の承認ロールが指定グループを構成する場合；（２）指定グループは部門等級により決定され、等級本体を選択する場合、その承認ノードにより選択された等級本体のみを踏襲し、等級値ｎは０のみに設定できる場合；（３）指定グループは部門等級により決定され、等級本体が自主的に選択し、指定グループには、１つ以上の指定ノードを含み、指定ノードの等級値ｎが０以外である場合、下級の指定ノードを設定する必要があり、指定ノードの等級値ｎが０であるまで、承認ノードの指定グループを設定して終わる場合から一つを含む。

システムは最高等級の部門主管の承認メカニズムを提供し、最高等級の部門主管が等級承認により承認プロセスを完成できないという問題を回避する。

例えば、会社の最高等級指導者の会長が承認要求を提出する時、等級承認には会長の上級部門が存在しないが、議長から提出された承認請求を承認する指定グループを設定する。

指定グループは
[１]指定グループは１つ以上の承認ロールで構成され、たとえば、複数の監督委員会成員が指定グループを構成し、会長の承認請求を監督委員会成員が承認する場合；
[２]指定グループは、部門等級により決定され、等級主体を選択する時に承認ノードにより選択された等級主体を踏襲し、かつ等級値ｎを０のみに設定でき、企業の組織構造の変更に対応するためにこの場合を適用し、たとえば、会社の元の最高等級主管は総経理であり、組織構造を変更した後、取締役会を追加し、最高等級主管が会長になり、承認ノードの等級値が０になると、承認ロールは総経理に固定されるのではなく、自動的に議長に変わり、承認ロールが組織の変更に適応できないという問題を回避する場合；
[３]指定グループは、部門等級により決定され、等級主体を自主的に選択でき、その時に承認ノードにより選択された等級主体を踏襲し，指定グループには１つ以上の指定ノードを含み、指定ノードの等級値ｎが０以外である場合、下級の指定ノードを設定する必要があり、指定ノードの等級値ｎが０であるまで、承認ノードの指定グループを設定して終わり、一般部門のロール承認に最高等級の部門主管から提出される承認申請を適用し、たとえば、財務部門の財務主管は、会長が提出した契約承認請求に関連する支払い情報を承認でき、最終的に会長が確認する必要がある場合からの１つを含む。

承認ノードの選択を行うのが等級承認である時、等級の対応する承認ロールに対して承認権限の授与を行うと、この等級の対応する承認ロールの承認権限は全て同じになる。

たとえば、ｎ＝１では、ａ３、ｂ３、ｃ３、およびｄ３がそれぞれ承認プロセスを提出する場合、対応する承認主管はそれぞれａ１、ｂ１、ｃ１、ｄ１であり、ａ１、ｂ１、ｃ１、ｄ１の承認権限は同じである。

図５に示されるように、ワークフローの制御方法は以下のステップを含む。Ｓ１）ユーザー−ロール−権限の３層構造モデルを構築し、その中で、ロール層では、ワークフローのプロセス承認の本体はロールであり、各ロールは独立した個体であり、グループ／クラスではあらず、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付け；権限層は、ワークフローの実行中に使用する必要がある権限で構成され、ロールに権限を直接授与する；ユーザー層：ユーザーは、ロールを関連付けることによりワークフローの承認タスクを決定し、ロールを関連付ける権限で承認操作を実行する。Ｓ２）図７に示されるように、３層構造モデルによりワークフローを制御し、１つの承認プロセスには、一つの開始ノード、少なくとも１つの承認ノード、１つの終了ノードを含み、開始ノードには、ワークフローを発起／申請／提出し、さらに提出ロールはワークフローを発起／申請／提出すると、ワークフローを発起する権限を持つロールは、提出ロールとしてワークフローを発起／申請／提出し、システムは、提出ロールに提出されるフォームにより承認プロセスを決定し、ワークフローが存在する必要のあるフォームに対して１つ以上の承認プロセスを設計するが、１つのロールはフォームに１つの承認プロセスのみを選択できる（同じロールは、同じフォーム中の１つのプロセスのみに存在できる）。例えば、２つのプロセスが購入契約フォームにあり、それぞれＰ１プロセスとＰ２プロセスである。Ｐ１プロセスの開始ノードでロールＡを選択すれば、Ｐ２プロセスの開始ノードでロールＡを選択できない。この時、ロールＡは、購入契約の承認を追加し、承認を提出するときにＰ１プロセスに自動的に入れる。

承認ノードでは、承認する部門の等級を設定し、等級内の対応する承認ロールの承認権限を承認し、終了ノードでは：プロセスがこのノードに移動した後、承認プロセスの承認が終了したことを示す。
Ｓ３）ユーザーは、関連付けられるロールにより処理する必要のある承認タスクを決定し、関連付けられるロールの権限により承認操作を行うことを含む。

承認ノードで１つ以上の承認ロールを選択し、１つのロールは、同じ承認プロセスで異なる承認ノードに存在でき、その承認ロールは、フォームフィールドに対する検分と変更権限が異なる。優先的な例えとして、あるロールは成都販売経理３であり、契約承認ワークフローでは、それが成都販売契約承認と上海販売契約承認の２つの承認ノードに存在する。成都販売契約の承認ノードに対して、そのロールは、承認をする時に顧客名、連絡先、連絡先情報、製品数量、製品単価、契約金額等の全てのフィールドを表示でき、製品単価と契約金額を変更できる。ただし、上海の販売契約の承認ノードは、顧客名、連絡先、連絡先情報などの機密フィールドの内容を検分できず、さらにいかなる変更も加えることはできない（ただし、検分権限を持つように設定できるが、変更権限はない）。

承認ノードで１つ以上の承認ロールを選択し、承認ノードで承認ロールを設定し、各承認ノードの承認ロールごとに対して独立した権限設定を行うことが可能になる。たとえば、ある契約フォームの承認プロセスには、それぞれロールＡとロールＢという２つの承認ロールを設定する承認ノードがある。その契約フォームの契約金額フィールドとそのフィールド値を検分するようにロールＡを設定できる。契約フォームの契約金額フィールドを検分できない、または契約金額フィールドを検分できるが、フィールド値を検分できないようにロールＢを設定できる。値を検分しない場合は、「*」などの他の記号を使用できる。ロールＢは、契約フォームの顧客住所フィールドとそのフィールド値を検分できる。

図６および図８に示されるように、前記ステップＳ１は以下の順位のサブステップを含む。Ｓ１０１：各ロールがグループ／クラスではなく独立した個体であるロールを作成する。Ｓ１０２：ステップ（１）で作成されたロールをそれぞれ承認する。Ｓ１０３：ユーザーをロールに関連付けさせる。１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付ける。ユーザーは、ロールとの関連付けにより権限を決定する。ユーザーの権限を変更する場合、ロールの所有する権限を調整することにより、そのロールを関連付けるユーザーの権限を変更する目的を達成する。ユーザーがロールを関連付けると、そのユーザーはそのロールの全ての操作権限を持つ。

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

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

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

ロールに対する承認：システムのロールに対する承認は、フォームに対する承認、メニューに対する承認、または機能に対する承認を含むが、これらに限定されない。フォームに対する操作承認には、追加や削除や変更や検分の権限を含むが、これらに限定されない。

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

ロールに対する承認は、フォームに対する承認、メニューに対する承認、または機能に対する承認を含むが、これらに限定されない。

ロールは部門に属し、ロール名は部門で単一であり、ロール番号はシステム内で単一であり、ロールの作業内容によりロールを承認する。

ユーザーが部門を変更したい場合、部門間の異動に関与し、その具体的な操作過程は、（１）ユーザーと元の部門のロールの関連付けを取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む。

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

前記ステップＳ１は以下の順位のサブステップを含む。Ｓ１０１：ロールを作成し、各ロールはグループ／クラスではなく、独立した個体である。Ｓ１０２：ユーザーをロールに関連付け、一つのロールは単一のユーザーのみを関連付け、１つのユーザーは１つ以上のロールを関連付ける。Ｓ１０３：Ｓ１０１に作成されたロールをそれぞれ承認する。

ロールは部門に属し、ロール名は部門内で単一であり、ロール番号はシステム内で単一である。

ワークフロー制御方法は、更にユーザーの部門間で異動する管理スタンプを含む。その具体的な操作過程は、（１）ユーザーと元の部門のロールの関連付けを取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む。

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

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

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

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

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

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

例えば、会社の動的な運用では、スタッフの入退場が頻繁に行われるが、役職番号／職務番号の変更は非常にわずかである（一定期間内でも変更はない）。

従来の承認方法：システム機能が多くある場合、従来のグループ／クラスの性質でロールを承認すると、承認ワークロードが大きく複雑であるだけでなく、ミスをおかしやすく、間違っていても短時間で見つけるのは容易ではないため、システムユーザーに損害を与えやすい。

本発明の承認方法：本発明は、役職番号／職務番号という性質を有するロールを承認し、ユーザーはロールを関連付けて権限を決定する。次に、ユーザー権限の制御を簡単にユーザーとロールの関連関係を通じて達成する。これにより、権限制御が簡単で操作しやすく、明確になり、承認の効率と承認の信頼性が大幅に向上する。

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

Claims (11)

1. フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法であって、システムの組織構造を設定するステップと、部門等級により承認ロールを設定するステップを含み、
   前記システムの組織構造を設定するステップは、
   ＳＳ１）システムの組織構造に含まれる部門とロールを設立すること、
   ＳＳ２）部門間の階層関係を設定し、各部門の部門主管ロールを設定することを含み、
   前記部門等級により承認ロールを設定するステップは、
   ＳＳＳ１）等級方式により承認を行うロールの設定を選択すること；
   ＳＳＳ２）承認プロセスの対応するフォームにロール属性フィールド、部門属性フィールドあるいはその承認プロセスの提出ロールを選択し、等級主体とすること；
   ＳＳＳ３）特定の等級値ｎを入力し、ｎは０以上の正整数であり、
   （１）承認プロセスの対応するフォームのロール属性フィールドを選択して等級主体とし、そのフィールドの対応するロールを判断基準として等級を判断し、
   [１]ｎ＝０では、そのフィールドの対応するロールはその承認ノードの承認ロールを担当する；
   [２]ｎ＝１では、そのフィールドの対応するロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、フィールドに対応するロールがそれの所属する部門の部門主管ロールである場合、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   [３]ｎ＝２では、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   [４]ｎ＝３では、そのフィールドの対応するロールの所属する二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
   [５]ｎ＝４では、そのフィールドの対応するロールの所属する三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
   [６]その他もろもろ、枚挙にいとまがない；
   [７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   （２）承認プロセスの対応するフォームの部門属性フィールドを選択して等級主体とし、そのフィールドの対応する部門を判断基準として等級を判断し、
   [１]ｎ＝０では、そのフィールドの対応する部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   [２]ｎ＝１では、そのフィールドの対応する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   [３]ｎ＝２では、そのフィールドの対応する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
   [４]ｎ＝３では、そのフィールドの対応する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
   [５]その他もろもろ、枚挙にいとまがない；
   [６]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   （３）承認プロセスの提出ロールを選択して等級主体とし、その提出ロールを判断基準として等級を判断し、
   [１]ｎ＝０では、ワークフロー承認プロセスの提出ロールはその承認ノードの承認ロールを担当する；
   [２]ｎ＝１では、ワークフロー承認プロセスの提出ロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、提出ロールがそれの所属する部門の部門主管ロールである場合、その提出ロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   [３]ｎ＝２では、ワークフロー承認プロセスの提出ロールの所属する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
   [４]ｎ＝３では、ワークフロー承認プロセスの提出ロールの所属する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
   [５]ｎ＝４では、ワークフロー承認プロセスの提出ロールの所属する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
   [６]その他もろもろ、枚挙にいとまがない；
   [７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する、ことを含む設定方法。
2. 承認ノードを選択するのが等級承認である時、等級の対応する承認ロールに対して承認権限の授与を行うと、この等級の対応する承認ロールの承認権限は全て同じになる請求項１に記載の設定方法。
3. 前記フォームのロール属性フィールドと部門属性フィールドは、記入用のラジオボタンである請求項１に記載の設定方法。
4. 前記ワークフローの制御方法は、
   Ｓ１）ユーザー−ロール−権限の３層構造モデルを構築し、その中で、ロール層では、ワークフローのプロセス承認の本体はロールであり、各ロールは独立した個体であり、グループ／クラスではあらず、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付け；権限層は、ワークフローの実行中に使用する必要がある権限で構成され、ロールに権限を直接授与する；ユーザー層：ユーザーは、ロールを関連付けることによりワークフローの承認タスクを決定し、ロールを関連付ける権限で承認操作を実行すること；
   Ｓ２）３層構造モデルによりワークフローを制御し、１つの承認プロセスには、１つの開始ノード、少なくとも１つの承認ノード、１つの終了ノードを含み、開始ノードには、ワークフローを発起／申請／提出し、さらに提出ロールがワークフローを発起／申請／提出すると、ワークフローを発起する権限を持つロールは、提出ロールとしてワークフローを発起／申請／提出し、システムは、提出ロールに提出されるフォームにより承認プロセスを決定し、ワークフローが存在する必要のあるフォームに対して１つ以上の承認プロセスを設計するが、１つのロールはフォームに１つの承認プロセスのみを選択でき、承認ノードは、承認する部門の等級を設定し、等級内の対応する承認ロールの承認権限を承認し、終了ノードは：プロセスがこのノードに移動した後、承認プロセスの承認が終了したことを示すこと；
   Ｓ３）ユーザーは、関連付けられるロールにより処理する必要のある承認タスクを決定し、関連付けられるロールの権限により承認操作を行うことを含む請求項１に記載の設定方法。
5. 承認ノードで１つ以上の承認ロールを選択し、１つの承認ロールは同じ承認プロセスで異なる承認ノードに存在でき、フォームフィールドに対して異なる承認ノードに対してその承認ノードが異なる可能性がある請求項４に記載の設定方法。
6. 承認ノードで１つ以上の承認ロールを選択し、承認ノードで承認ロールを設定し、各承認ノードの承認ロールごとに対して、独立した権限設定を行うことが可能になる請求項４に記載の設定方法。
7. 前記ステップＳ１には、（１）各ロールがグループ／クラスではなく独立した個体であるロールを作成すること、（２）ステップ（１）で作成されたロールをそれぞれ承認すること、（３）ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付けることを含み、
   ステップ（１）が先行するが、ステップ（２）とステップ（３）は連続順序関係にない請求項４に記載の設定方法。
8. 前記ロールは部門に属し、ロール名称は部門内で唯一であり、ロール番号はシステム内で唯一であり、ユーザーの部門間管理は、（１）ユーザーと元の部門のロールの関連を取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む請求項１あるいは４に記載の設定方法。
9. 前記ユーザーはロールとの関連付けにより権限を決定し、１つのユーザーが１つのユーザーアカウントに対応し、１つのユーザーアカウントが１つのユーザーに対応する請求項１に記載の設定方法。
10. 前記ロールは職名＋職務番号により構成される請求項１に記載の設定方法。
11. フォームフィールドに基づいてワークフロー承認ノードに承認ロールを設定する方法であって、システムの組織構造を設定するステップと、部門等級により承認ロールを設定するステップを含み、
    前記システムの組織構造を設定するステップは、
    ＳＳ１）システムの組織構造に含まれる部門とロールを設立すること、
    ＳＳ２）部門間の階層関係を設置し、各部門の部門主管ロールを設定することを含み、
    前記部門等級により承認ロールを設定するステップは
    ＳＳＳ１）等級方式により承認を行うロールの設定を選択すること；
    ＳＳＳ２）承認プロセスの対応するフォームにロール属性フィールド、部門属性フィールドあるいはその承認プロセスの提出ロールを選択し、等級主体とすること；
    ＳＳＳ３）特定の等級値ｎを入力し、ｎは０以上の正整数であり、
    （１）承認プロセスの対応するフォームのロール属性フィールドを選択して等級主体とし、そのフィールドの対応するロールを判断基準として等級を判断し、
    [１]ｎ＝０では、そのフィールドの対応するロールはその承認ノードの承認ロールを担当する；
    [２]ｎ＝１では、そのフィールドの対応するロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、フィールドに対応するロールがそれの所属する部門の部門主管ロールである場合、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [３]ｎ＝２では、そのフィールドの対応するロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [４]ｎ＝３では、そのフィールドの対応するロールの所属する二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
    [５]ｎ＝４では、そのフィールドの対応するロールの所属する三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
    [６]その他もろもろ、枚挙にいとまがない；
    [７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [８]ｎ＞１では、「そのフィールドの対応するロールは、それの所属する部門の部門主管であり、しかもその部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要がある；
    （２）承認プロセスの対応するフォームの部門属性フィールドを選択して等級主体とし、そのフィールドの対応する部門を判断基準として等級を判断し、
    [１]ｎ＝０では、そのフィールドの対応する部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [２]ｎ＝１では、そのフィールドの対応する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [３]ｎ＝２では、そのフィールドの対応する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
    [４]ｎ＝３では、そのフィールドの対応する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
    [５]その他もろもろ、枚挙にいとまがない；
    [６]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [７]ｎ＞１では、「そのフィールドの対応する部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要がある；
    （３）承認プロセスの提出ロールを選択して等級主体とし、その提出ロールを判断基準として等級を判断し、
    [１]ｎ＝０では、ワークフロー承認プロセスの提出ロールはその承認ノードの承認ロールを担当する；
    [２]ｎ＝１では、ワークフロー承認プロセスの提出ロールの所属する部門の部門主管ロールはその承認ノードの承認ロールを担当し、提出ロールがそれの所属する部門の部門主管ロールである場合、その提出ロールの所属する上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [３]ｎ＝２では、ワークフロー承認プロセスの提出ロールの所属する部門の上級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [４]ｎ＝３では、ワークフロー承認プロセスの提出ロールの所属する部門の二重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
    [５]ｎ＝４では、ワークフロー承認プロセスの提出ロールの所属する部門の三重上級の部門主管ロールはその承認ノードの承認ロールを担当する；
    [６]その他もろもろ、枚挙にいとまがない；
    [７]部門等級の設定がシステム組織構造内の最高等級部門を超える場合、最高等級部門の部門主管ロールはその承認ノードの承認ロールを担当する；
    [８]ｎ＞１では、「そのフィールドの対応するロールは、それの所属する部門の部門主管であり、しかもその部門には上級部門がない場合」指定グループにより承認ノードを承認するように設定する必要があることを含み、
    前記指定グループの承認は、（１）１つ以上の承認ロールが指定グループを構成する場合；（２）指定グループは部門等級により決定され、等級本体を選択する場合、その承認ノードにより選択された等級本体のみを踏襲し、等級値ｎは０のみに設定できる場合；（３）指定グループは部門等級により決定され、等級本体が自主的に選択し、指定グループには、１つ以上の指定ノードを含み、指定ノードの等級値ｎが０以外である場合、下級の指定ノードを設定する必要があり、指定ノードの等級値ｎが０であるまで、承認ノードの指定グループを設定して終わる場合から１つを含む設定方法。