(57)【要約】      【課題】本発明は、承認期間を短縮し、承認の作業負荷を軽減し、情報セキュリティを強化する。      【解決手段】本発明は、ワークフローのフォームフィールド操作権限の設定方法を公開し、前記ワークフローは開始ノード及び承認ノードを含み、前記開始ノードと承認ノードのフォームフィールド操作権限の設定方式は異なる。外に、本発明は、承認ノードのフォームフィールドの操作権限の設定方法を公開し、前記承認ノードに１つ以上のプロセス承認者を含み、承認ノードの各承認者のフォームフィールド操作権限をカスタマイズ設定する。具体的に、承認ノードから承認者を選択する、承認者を選択した後フォームフィールド操作権限のデフォルト設定を表示する、選択した承認者のワークフローにある承認事項により、フォームフィールドの操作権限のデフォルト設定を変更することを含む。      【選択図】図４
2020521224.tif 000002
【特許請求の範囲】
【請求項１】
ワークフローのフォームフィールド操作権限の設定方法であって、前記ワークフローは開始ノード及び承認ノードを含み、前記開始ノードと承認ノードのフォームフィールド操作権限の設定方式は異なる設定方法。
【請求項２】
前記開始ノードのフォームフィールド操作権限の設定方式は、前記開始ノードに１つ以上のプロセス発起者を含む、前記プロセス発起者のシステム内にあるフォーム操作権限を開始ノード内にそのプロセス発起者のフォームフィールド操作権限として取得する、前記フォームフィールド操作権限は、プロセス内ではなくシステム内の権限である、各プロセス発起者のフォームフィールド操作権限は独立していることである、請求項１に記載の設定方法。
【請求項３】
前記承認ノードのフォームフィールド操作権限の設定方式は、前記承認ノードに１つ以上のプロセス承認者を含む、承認ノードに各承認者のフォームフィールド操作権限をカスタマイズ設定する、前記フォームフィールド操作権限は、プロセス内ではなくシステム内の権限である、各プロセス承認者のフォームフィールド操作権限は独立していることである、請求項１に記載の設定方法。
【請求項４】
前記承認ノードのフォームフィールドの操作権限の設定方法であって、前記承認ノードに１つ以上のプロセス承認者を含み、承認ノードの各承認者のフォームフィールド操作権限をカスタマイズ設定する設定方法。
【請求項５】
承認者のフォームフィールド操作権限に対するカスタマイズ設定は、承認ノードから承認者を選択する、承認者を選択した後フォームフィールド操作権限のデフォルト設定を表示する、選択した承認者のワークフローにある承認事項により、フォームフィールドの操作権限のデフォルト設定を変更することを含む、請求項４に記載の設定方法。
【請求項６】
前記デフォルトのフォームフィールド操作権限は、フォームフィールドの全部の検分権限を有する、且つフォームフィールドの変更権限を有しない、或いはフォームフィールドの全部の検分権限と全部の変更権限を有する、或いはフォームフィールドのいかなる検分権限と変更権限を有しないことである、請求項５に記載の設定方法。
【請求項７】
前記承認者はロールであり、前記ロールの設定方式は二種類を含み、１つはロールを直接選択して承認権限を授与し、もう１つは部門レベルによりロールを決定して承認権限を授与し、前記ロールは、グループ／クラスではなく、独立した個人であり、一つのロールは唯一のユーザーを同時期に関連付けることができ、一つのユーザーは１つ以上のロールに関連付けられることができる、請求項４に記載の設定方法。
【請求項８】
前記ロールは部門に属し、そのロールの名称は部門内で唯一であり、そのロールの番号はシステム内で唯一である、請求項７に記載の設定方法。
【請求項９】
前記ユーザーが部門間を移動する時、ユーザーと元の部門のロールの関連を取り消し、ユーザーを新しい部門内のロールに関連付けさせる、請求項８に記載の設定方法。
【請求項１０】
フォームフィールドが秘密フィールドと通常フィールドを含む時、秘密フィールドと通常フィールドを区別して表示する、請求項４に記載の設定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＲＰなどの管理ソフトウェアシステムのワークフローに権限を設定する方法に関し、特に、ワークフローとその承認ノードのフォームフィールド操作権限の設定方法に関する。
【背景技術】
【０００２】
ロールベースのアクセス制御（ＲＢＡＣ）は、近年最も研究され成熟したデータベース権限管理メカニズムの１つであり、従来の強制アクセス制御（ＭＡＣ）および自律アクセス制御（ＤＡＣ）に代わる理想的な候補と考えられる。従来の自律型アクセス制御は高い融通性を備えるが、セキュリティは低い。強制アクセス制御は高いセキュリティを備えるが、制限が強すぎる。ロールベースのアクセス制御は、両方の長所を兼ね備え，管理が簡単であるだけでなく、複雑さ、コスト、エラーの可能性を減らすこともできるため、近年大幅に成長している。ロールベースのアクセス制御（ＲＢＡＣ）の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化することで、ユーザーは、異なるロールを割り当てられることにより、データベースリソースに間接的にアクセスする。
【０００３】
大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限の許可を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、ＳＱＬ言語を使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されたら、大量の複雑かつ面倒な認証変更を実行するために、予期しない認証エラーによって引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。
【０００４】
ロールベースの権限制御メカニズムにより、システムのアクセス権を簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。
【０００５】
ただし、従来のロールベースのユーザー権限管理及びワークフロー制御方法は、「ロール対ユーザー、１対多」の関連付けメカニズムを採用し、「ロール」はグループ／クラスの性質を有する。つまり、１つのロールが複数のユーザーに同時に対応／関連付けできる。ロールは、役職／職務／職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の３つの形式に分けられる。１．図１に示すように、ユーザーが直接承認されるが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒である。承認プロセスには承認ノードの承認操作主体がユーザーであり、ワークフロー承認ノードには従業員／ユーザーを承認主体として直接選択する。従業員の変更（異動、辞任など）が発生した場合、従業員に関係するすべてのプロセスを適宜調整する必要がある。特に会社の経営陣にとっては、関与する承認プロセスの数が多く、プロセス調整の作業負荷が大きく複雑であり、ミスや脱落を起こしやすく、会社の正常な運転に影響を及ぼし、予測不可能な損失さえ引き起こす。
【０００６】
従業員の承認権限のみが変更された場合でも、従業員に関係するプロセスを調整する必要があり、上記と同様の問題もある。
【０００７】
２．図２に示すように、ロール（クラス／グループ／役職／職種）は承認され（１つのロールを複数のユーザーに関連付けさせることができる）、ユーザーはロールを介して権限を取得し、承認操作の主体はグループ／クラスというロールである。３．図３に示すように、上記の２つの方法が組み合わされている。
【０００８】
上記の説明では、２と３の両方がクラス／グループの性質のロールを承認する必要があり、クラス／グループ／役職／職種のロールを介する承認およびワークフロー制御の方法には次の欠点がある。１．ユーザーのアクセス権限を変更する場合、難しく操作する。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限の変更を処理する場合、ロールに関連付けられる従業員の権限を変更するが、ロールは権限の変更されない他の従業員にも関連付けられることで、個々の従業員の権限の変更により、ロール全体の権限を変更することができない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【０００９】
従業員／ユーザーの承認権限を変更する場合、従業員／ユーザーをロールから離脱するか、ワークフロー承認ノードには承認主体として従業員／ユーザーを直接選択するか、承認プロセスの要件を満たすために新しいロールを追加する。１番目の方式では、従業員の変更（異動、辞任など）が発生した場合、従業員に関係するすべてのプロセスを、特に企業の管理担当者に対して調整する必要がある。関与する承認プロセスの数が多く、プロセス調整の作業負荷が大きく複雑であり、ミスや脱落を起こしやすく、会社の正常な運転に影響を及ぼし、予測不可能な損失さえ引き起こす。従業員の承認権限のみが変更された場合でも、従業員に関係するプロセスを調整する必要があり、上記と同様の問題もある。２番目の方式では、新しいロールはロールの設立や関連付けや承認に関与する。特に、多数のロールと、ロールに関連付けられた多数のユーザーの場合、どのユーザーがロールに具体的に関連付けられているかを覚えるのは困難である。
【００１０】
２．ロールに含まれる特定の権限を長期的に覚えることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えることは困難になり、権限の類似したロール間の権限差別を覚えるのがより難しくなり、ロールの類似した権限も混同し易い。新しいユーザーを関連付けると、どうやって関連付けるか正確に判断することはできない。
【００１１】
３．ユーザーの権限が変更されるため、ロールをますます設立するのをもたらす（新しいロールを設立しない場合、ユーザーを直接承認するのが大幅に増加する）。各ロール間の特定の差別を区別することはより困難である。
【００１２】
４．役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーに関連付けられるためにそれぞれロールを設立する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーをよりやすく発生する。
【００１３】
通常、既存のプロセスノードには２種類の承認があり、１番目はすべてのノードがシステム内の権限を使用することであり、２番目はすべてのノードに同じ権限を設定することである。
【００１４】
すべてのノードがシステムの権限を採用する時に、承認者の部分はフォームの関連フィールドを検分または変更できないため、正常な承認プロセスを完成できない。承認ノードでフィールドを変更できない場合、それらを変更する必要があれば、発起者に棄却するだけ、従って承認周期を延長する。例１：清算フォームを承認する時に、最後の承認者は、承認を行う時に払い戻し金額を変更する必要があると見なす。この時に、払い戻しフォームを発起者に棄却し、発起者は変更した後新しいプロセスを再発起し、また、関連する承認者が再承認する必要があるため、関連する承認者の作業負荷が増加し、承認周期が大幅に延長される。これは、特に多数の承認者がいるプロセスに当てはまる。例２：成都支店の担当者が上海支店の販売契約を承認することが必要であるが、成都支店の承認者は、システムで上海支店の販売契約を検分する権限を持たない。（成都支店の従業員には、システムの認証にビジネス管理のニーズに応じて成都支店の販売契約を検分する権限を授与するが、上海支店の販売契約を検分する権限を授与しないという原因がある。ただし、上海支店の販売契約を承認するための承認ノードを設定する時、成都支店にある人物が強い能力を持つことを考慮して、成都支店のその人物は承認ノードに設定してその承認ノードに承認者となる。その承認者がその承認ノードで上海支店の販売契約を承認する時、従来の承認プロセスの承認ノードには独立した権限設定を実行しない代わりに、承認プロセスの承認ノードは、システム内の承認者の承認プロセスに対応するフォームの権限を採用／踏襲することで、その場合、承認ノードの承認者の権限は、システムで販売契約フォームを採用／踏襲する権限になる。システムの承認者の権限は成都支店の販売契約を検分することだけであり、上海支店の販売契約を検分する権限はないという原因もある）。この時、成都支店の承認者は販売契約の関連内容を検分できず、正常なの承認プロセスを完成しないことにつながる。
【００１５】
契約署名前の承認などの様に、すべてのノードに同じ権限を設定している場合、承認者の部分は承認の必要としない機密情報を検分できることで、そのような情報の広がりにつながり、情報漏洩を引き起こしやすく、情報セキュリティを脅かす。財務承認者は、契約を確認するときに主に契約は財務の観点から署名するべきかどうかをチェックし、顧客の連絡先などの情報を知る必要はあらない。財務承認者が顧客の連絡先などの情報を検分する権限を設定する場合、顧客の連絡先等の情報漏洩につながる可能性がある。さらに、契約承認プロセスでは、承認者Ａは３番目と５番目の承認ノードにあり、３番目の承認ノードには契約の製品技術要件を承認するため、技術関連情報のみを表示する必要がある。５番目の承認ノードには契約の輸送方法を承認するため、関連する輸送情報のみを表示できる。従来、承認者Ａに対してすべての承認ノードに同じ権限を設定し、様々な承認ノードの異なる承認要件に対する同じでない権限の設定を満たすことはできない。
【発明の概要】
【発明が解決しようとする課題】
【００１６】
本発明の目的は、現行技術の欠陥を克服し、ワークフローとその承認ノードのフォームフィールド操作権限の設定方法を提供し、承認周期を短縮し、承認作業量を減らし、情報セキュリティを強化する。
【課題を解決するための手段】
【００１７】
本発明の目的は、以下の技術的手段により達成される。ワークフローのフォームフィールド操作権限の設定方法であって、前記ワークフローは開始ノード及び承認ノードを含み、前記開始ノードと承認ノードのフォームフィールド操作権限の設定方式は異なる。
【００１８】
優先的に、前記開始ノードのフォームフィールド操作権限の設定方式は、前記開始ノードに１つ以上のプロセス発起者を含む、前記プロセス発起者のシステム内にあるフォーム操作権限を開始ノード内にそのプロセス発起者のフォームフィールド操作権限として取得する、そのフォームフィールド操作権限は、プロセス内ではなくシステム内の権限である、各プロセス発起者のフォームフィールド操作権限は独立していることである。
【００１９】
優先的に、前記承認ノードのフォームフィールド操作権限の設定方式は、前記承認ノードに１つ以上のプロセス承認者を含む、承認ノードに各承認者のフォームフィールド操作権限をカスタマイズ設定する、そのフォームフィールド操作権限は、プロセス内ではなくシステム内の権限である、各プロセス承認者のフォームフィールド操作権限は独立していることである。
【００２０】
承認ノードのフォームフィールドの操作権限の設定方法であって、前記承認ノードに１つ以上のプロセス承認者を含み、承認ノードの各承認者のフォームフィールド操作権限をカスタマイズ設定する。
【００２１】
優先的に、承認者のフォームフィールド操作権限に対するカスタマイズ設定は、承認ノードから承認者を選択する、承認者を選択した後フォームフィールド操作権限のデフォルト設定を表示する、選択した承認者のワークフローにある承認事項により、フォームフィールドの操作権限のデフォルト設定を変更することを含む。
【００２２】
優先的に、前記デフォルトのフォームフィールド操作権限は、フォームフィールドの全部の検分権限を有する、且つフォームフィールドの変更権限を有しない、或いはフォームフィールドの全部の検分権限と全部の変更権限を有する、或いはフォームフィールドのいかなる検分権限と変更権限を有しないことである。
【００２３】
優先的に、前記承認者はロールであり、前記ロールの設定方式は二種類を含み、１つはロールを直接選択して承認権限を授与し、もう１つは部門レベルによりロールを決定して承認権限を授与し、前記ロールは、グループ／クラスではなく、独立した個人であり、一つのロールは唯一のユーザーを同時期に関連付けることができ、一つのユーザーは１つ以上のロールに関連付けられることができる。
【００２４】
優先的に、前記ロールは部門に属し、そのロールの名称は部門内で唯一であり、そのロールの番号はシステム内で唯一である。
【００２５】
優先的に、前記ユーザーが部門間を移動する時、ユーザーと元の部門のロールの関連を取り消し、ユーザーを新しい部門内のロールに関連付けさせる。
【００２６】
優先的に、フォームフィールドが秘密フィールドと通常フィールドを含む時、秘密フィールドと通常フィールドを区別して表示する。
【発明の効果】
【００２７】
本発明の有益な効果は次のとおりである。（１）本発明では、フィールドの部分を承認者の承認項目により承認者に対応するように設定し、承認者はフィールドを修正する必要がある場合にフィールドを直接修正できる。フォームを棄却してプロセスを再開する代わりに、承認周期を短縮し、前置にある承認者の作業負荷を軽減する。
【００２８】
開始ノードと承認ノードの権限設定は異なり、開始ノードのプロセスの発起者／申請者／提出者は、承認プロセスの対応するフォームのシステム内のフォームフィールド権限を取得する（提出者の日常の仕事内容により授与されたシステム内のフォーム権限）。従って、承認ノードの承認者は、プロセス承認ノードに対し独立して設定された「承認プロセスの対応するフォームのフォームフィールド権限」を取得する。開始ノードと承認ノードの権限設定は異なる場合、開始ノードのプロセス発起者／申請者／提出者と承認ノードの承認者が取得するフォームフィールド権限の方式は異なるが、プロセス発起者／申請者／提出者はシステム内のフォームフィールド権限を取得する。従って、承認ノードの承認者は、承認ノードの承認者の為に独立して設定されたその承認ノードのフォームフィールド権限を取得する（システムのフォームフィールド権限ではない）。開始ノードと承認ノードの権限設定が異なると、フォームフィールドに対しプロセス発起者／申請者／提出者と承認ノードの承認者の異なる権限要件を満たす。
【００２９】
たとえば、上海支店の営業担当者Ａは承認のために上海の販売契約を提出し、承認プロセスには６つの承認ノードがある。承認ノード２は成都支店の担当者Ｂをその承認ノードの承認者（契約の製品技術要件を承認する）として設定し、承認ノード５も成都支店の担当者Ｂをその承認ノードの承認者（契約の輸送モードを承認する）として設定する。従って、成都支店の人員Ｂは、システムで上海の販売契約を検分／変更するためのフィールド権限を持っていない（成都支店の人員は上海市場で販売業務に責任を負わないが、成都市場で販売業務に責任を負う）。ただし、本申請の方法では、承認ノード２において認定人員Ｂは契約の製品技術要件に関連するフィールドを検分／変更でき、承認ノード５において認定人員Ｂは契約の輸送関連フィールドを検分／変更できない。従って、営業担当者Ａは、システム内の販売契約フォーム権限を直接使用する（営業担当者Ａは上海支店であるため、営業担当者の日常業務によると、営業担当者Ａが上海での販売契約を検分表示／変更する権限を授与している）。つまり、フォームフィールド権限に対する開始ノードと承認ノードの異なる要件が満たされ、様々な承認ノードの異なる承認要件に対する同じでないフォームフィールド権限設定も満たされる。
【００３０】
たとえば、払い戻しフォームの承認プロセスには６つの承認者がいる（つまり、６つの承認ノードがあり、各承認ノードに１つの承認ノードがある）。前方にいる５つの承認者は承認を完成して終わり、最後の承認者は払い戻し額を修正する必要があると考えている。この時、最後の承認者は、払い戻しフォームを取り消して承認プロセスを再度発起する代わりに、直接変更することができる。これにより、承認プロセスを再発起する時に前方にいる５つの承認者の承認ワークロードを削減し、承認プロセスを再発起する時に前方にいる５つの承認者が必要とする承認時間を短縮する。
【００３１】
（２）本発明では、承認担当者の承認項目により、フィールドの部分が承認者に対応して検分できると設定するために、承認者は承認に必要な情報が検分でき、同時に他の情報が検分できず、情報のセキュリティを確保する。
【００３２】
例：販売承認、技術承認、財務承認を含む契約前の承認プロセスでは、次の設定を行うことができる。販売員は契約に調印するため、販売承認者はフォームに全部のフィールドを検分でき、全部のフィールドを変更できるように設定する。契約の技術要件の実行可能を技術上に承認する必要があるため、技術承認者が技術上のフォームフィールド（製品の技術要件など）が検分でき、変更できるだけのように設定する。財務の観点から契約を財務的に承認する必要があるため、財務承認者は、財務上のフォームフィールド（製品モデル、単価、数量、領収書種類など）が検分できるだけ、変更できないように設定する。顧客の担当や連絡先などの情報は、関係のない担当者（財務承認者など）が検分できないため、関連情報の漏洩を防ぎ、情報セキュリティを確保する。
【００３３】
（３）ワークフローにおける承認操作のロールは、従来のグループ／クラスのロールではなく、独立した個人であり、従業員／ユーザーの変更（異動、辞任など）が発生した場合、または従業員の承認権限が変更された場合でも、  従業員を新しいロールに再関連付けさせ、そのロールの承認権限を適切に調整してもよい。プロセスを再設定／調整する必要はあらない。簡単に設定し、間違いや脱落がないため、企業の正常な運用に影響を与えず、ワークフローの信頼性が大幅に向上する。職務番号の性質を有するロールは、承認リンクノードに承認権限主体となる。ユーザーは、ロールを介してどの承認タスクを持つかを決定し、ロールの権限を関連付けることで承認操作をしてもよい。理解は明確かつ単純であり、役職番号／職務番号の性質を有する各ロールは作業主体の最小単位であり、この発明は、様々な各ロールの承認要件に対して十分に満たすことができる。
【００３４】
（４）ロールは、ユーザーとの１対１の関係にある。一つのロールは、唯一のユーザーを同時期に関連付けることができる。これの利点は、ユーザーに関連付けられてもよく、ユーザーを設立するたびに権限を割り当てる必要がなくなることであり、しかもロールの権限の変更は、従来のメカニズムにあるロールの権限の変更よりもはるかに小さくなる。独立した個体の性質（役職番号／職務番号の性質）のロールの数は少ない。従業員の異動は大きいが、役職番号／職務番号の変化は小さい（一定期間に変化さえない、つまりロールは変わらない）。これにより、ユーザーの権限管理を大幅に簡易化し、システムの掛かりを削減する。
【００３５】
（５）動的管理、入職と異動などの操作は、簡単且つ便利であり、効率と信頼性が高い。入職／離職／異動の適用は承認プロセスで簡単である。ワークフローの発起と承認の主体はロールであるため、従業員／ユーザーを変更する場合、承認プロセスを再設定する必要はない（ユーザーはロールを取り消し、ロールを関連付けてもよい）。役職番号／職務番号のロールを失ったユーザーは、ロールの関連付けを取り消し、役職番号／職務番号のロールを引き継ぐユーザーは、その役職番号のロールを関連付ける。承認ワークフローを再設定したり、ワークフロー内のロールを再承認したりする必要はあらない。これにより、プロセス設定の効率やセキュリティや信頼性を大幅に向上させる。
【００３６】
（６）ロールが部門に属している場合、ロールは部門を変更できず、ロールが部門を変更できないのはなぜか？理由１：本発明のロールの性質は役職番号／職務番号と同等であるため、様々な役職番号／職務番号の作業内容／権限は異なる。例えば、販売部門の販売員１のロールと技術部門の開発者１のロールは、２つの役職番号／職務番号がまったく異なり、権限が違う。理由２：販売員１のロールの部門（販売部門）が技術部門に置き換えられる場合、販売員１のロールを変更しないと、技術部門には販売部門の権限を持つロールがある。これは、管理の混乱とセキュリティの脆弱性につながる可能性がある。
【図面の簡単な説明】
【００３７】
【図１】図１は、背景技術においてシステムがユーザを直接承認する方法の概略図である。
【図２】図２は、背景技術においてシステムがグループ／クラスの性質を有するロールを承認する方法の概略図である。
【図３】図３は、背景技術においてシステムがユーザーを直接承認する方法とグループ／クラスの性質を有するロールを承認する方法を組み合わせる方法の概略図である。
【図４】図４は、本発明において承認ノードのフォームフィールドの操作権限を設定するフローチャートである。
【図５】図５は、本発明においてフォームフィールド操作権限のデフォルトを設定する第１状態の概略図である。
【図６】図６は、本発明においてフォームフィールド操作権限のデフォルトを設定する第２状態の概略図である。
【図７】図７は、本発明においてフォームフィールド操作権限のデフォルトを設定する第３状態の概略図である。
【図８】図８は、実施形態において承認プロセスの概略図である。
【図９】図９は、図８に前記承認プロセスにフォームフィールド操作権限のデフォルトを設定する概略図である。
【発明を実施するための形態】
【００３８】
添付の図面を参照して本発明の技術的手段を以下でさらに詳細に説明するが、本発明の保護範囲は以下に限定されない。
【実施例１】
【００３９】
ワークフローのフォームフィールド操作権限の設定方法は、開始ノード及び承認ノードを含み、前記開始ノードと承認ノードのフォームフィールド操作権限の設定方式は異なる（一つの承認プロセスは、一つの開始ノード、少なくとも１つの承認ノード、一つの終了ノードを含む）。一つの実施形態では、操作権限は検分権限及び修正権限を含む。
【００４０】
前記開始ノードのフォームフィールド操作権限の設定方式は、前記開始ノードに１つ以上のプロセス発起者を含む、前記プロセス発起者のシステム内にあるフォーム操作権限を開始ノード内にそのプロセス発起者のフォームフィールド操作権限として取得する、そのフォームフィールド操作権限は、プロセス内ではなくシステム内の権限である、各プロセス発起者のフォームフィールド操作権限は独立していることである。前記プロセス開始者は、ワークフローの発起／申請／提出に使用される。
【００４１】
前記承認ノードのフォームフィールド操作権限の設定方式は、前記承認ノードに１つ以上のプロセス承認者を含む、承認ノードに各承認者のフォームフィールド操作権限をカスタマイズ設定する、そのフォームフィールド操作権限は、プロセス内ではなくシステム内の権限である、各プロセス承認者のフォームフィールド操作権限は独立していることである。
【００４２】
例：販売員Ａは、販売契約に署名できるかどうかを判断するように販売契約に調印する前に承認を開始する。フォームフィールドは、顧客名、製品モデル、数量、単価、技術要件、納期、配送場所を含む。承認者は販売主管Ｂ、財務スタッフＣ、技術者Ｄ、生産者Ｅ、経理を含む。販売員Ａはシステム内に顧客名、製品モデル、数量、単価、技術要件、納期を検分／変更する権限を持つ場合、開始ノードで顧客名、製品モデル、数量、単価、技術要件、納期を検分／変更する権限も持つ。販売主管Ｂは販売契約の全面的な審査を実施する必要があるため、販売主管Ｂの権限は、顧客名、製品モデル、数量、単価、技術的要件、納期、配送場所を検分／変更するように設定される。財務スタッフＣは財務関連情報を承認するだけでよいため、財務スタッフＣの権限は製品モデル、数量、単価を検分／変更するように設定される。技術者Ｄは技術関連情報を承認するだけでよいため、技術者Ｄの権限は技術要件を検分／変更するように設定される。生産者Ｅは生産関連情報を承認するだけでよいため、生産者Ｅの権限は納期を検分／変更するように設定される。経理Ｆは販売契約の全面的な審査を実施する必要があるため、経理Ｆの権限は、顧客名、製品モデル、数量、単価、技術的要件、納期、配送場所を検分／変更するように設定される。
【００４３】
図４に示すように、承認ノードのフォームフィールドの操作権限の設定方法であって、前記承認ノードに１つ以上のプロセス承認者を含み、承認ノードの各承認者のフォームフィールド操作権限をカスタマイズ設定し、各承認者のフォームフィールド操作権限は独立している。
【００４４】
承認者のフォームフィールド操作権限に対するカスタマイズ設定は、承認ノードから承認者を選択する、承認者を選択した後フォームフィールド操作権限のデフォルト設定を表示する、選択した承認者のワークフローにある承認事項により、フォームフィールドの操作権限のデフォルト設定を変更することを含む。
【００４５】
一つの実施形態では、操作権限は検分権限及び変更権限を含み、承認者が特定のフィールドに対し検分権限を持たない場合、そのフィールドは「＊」記号で承認者に表示される（技術を担当する承認者が契約承認プロセスの承認ノードで契約金額フィールドを検分できない場合、契約金額フィールドは具体的な値で表示されないに代わり、具体的な値は「＊」などで表示される。このフィールドのフィールド値は、他の記号に置き換えることもできる。承認者が契約金額フィールドを検分及び変更する権限を持っている場合、承認者は契約金額フィールドのフィールド値を検分し、契約金額フィールドのフィールド値も変更できる）。
【００４６】
たとえば、承認ノードには承認者Ａ、承認者Ｂ、承認者Ｃが含まれる。承認者Ａは技術承認を実行し、承認者Ｂは財務承認を実行し、承認者Ｃは本番承認を実行する。具体的な承認操作は次のとおりである。承認者Ａを選択し、デフォルトのフォーム操作権限に基づいて技術要件を表示／変更するように承認者Ａの権限を修正する。承認者Ｂを選択し、デフォルトのフォーム操作権限に基づいて製品モデル、単価、および数量を表示／変更するように承認者Ｂの権限を修正する。承認者Ｃを選択し、デフォルトのフォーム操作権限に基づいて、製品モデルと数量を表示する、配達日を変更するように承認者Ｃの権限を修正する。
【００４７】
前記デフォルトのフォームフィールド操作権限は、フォームフィールドのすべての表示権限を備え、フォームフィールドの変更権限を備えない。図５に示すように、顧客名、製品モデル、単価、数量、および納期に対応する検分オプションを全部で選定し、変更オプションを全く選定しなく、または、フォームフィールドに全部の検分権限と全部の変更権限を備える。図６に示すように、顧客名、製品モデル、単価、数量、および納期に対応する検分オプションと変更オプションを全部で選定し、または、フォームフィールドに検分権限と変更権限をまったく備えない。図７に示すように、顧客名、製品モデル、単価、数量、および納期に対応する検分オプションと変更オプションをまったく選定しない。
【００４８】
前記承認者はロールであり、前記ロールの設定方式は二種類を含み、１つはロールを直接選択して承認権限を授与し、もう１つは部門レベルによりロールを決定して承認権限を授与し、前記ロールは、グループ／クラスではなく、独立した個人であり、一つのロールは唯一のユーザーを同時期に関連付けることができ、一つのユーザーは１つ以上のロールに関連付けられることができる。
【００４９】
前記等級を部門間の階層関係により決定し、等級に応じて決定される承認ロールは、プロセスを提出するロールの自体である場合も、等級に対応する部門の部門主管ロールである場合もある。
【００５０】
ロールの定義：ロールは、グループ／クラス／カテゴリ／役職／職務／職種の性質を有しないが、非集合の性質を有する。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である（役職番号はここで役職ではなく、一つの役職に同時に複数の従業員がいるが、１つの役職番号は同時に一つの従業員にしか対応できない）。
【００５１】
たとえば、会社のシステムは次のロールを設立できる。総経理、副総経理１、副総経理２、北京販売部Ｉの経理、北京販売部ＩＩの経理、北京販売部ＩＩＩの経理、上海販売エンジニア１、上海販売エンジニア２、上海販売エンジニア３、上海販売エンジニア４、上海販売エンジニア５等。従来のロールの概念は、グループ／クラス／役職／職務／職種の性質であり、１つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号／職務番号と同等であり、映画やテレビドラマのロールに似ている。一つの俳優は一つのロールを同時に（幼年、少年、中年．．．）演じることができ、一つの俳優は複数のロールを演じることができる。ユーザーとロールの関係：その会社の従業員である張三さんは、会社の副総経理２を務め、同時に北京販売部Ｉの経理を務める場合、張三さんは総経理２及び北京販売部Ｉの経理というロールを関連付ける必要がある。張三さんは両方のロールに対する権限を持っている。
【００５２】
ユーザーは、ロールとの関連付けにより権限を決定する。ユーザーの権限を変更する場合、ロールが所有する権限を調整することにより、ロールを関連付けたユーザーの権限を変更する目的を達成する。ユーザーがロールを関連付けると、そのユーザーはそのロールの全部の操作権限を持つ。
【００５３】
ロールは、ユーザーとの１対１の関係にある（そのロールは、ユーザーに関連付けられる場合、他のユーザーはそのロールを関連付けることができなくなります;そのロールは、ユーザーに関連付けられていない場合、他のユーザーが選択して関連付けることができる）。ユーザーは、ロールとの１対多の関係にある（一つのユーザーは同時に複数のロールに関連付けられることができる）。
【００５４】
前記ロールは部門に属し、そのロールの名称は部門内で唯一であり、そのロールの番号はシステム内で唯一である。
【００５５】
前記ユーザーが部門間を移動する時、ユーザーと元の部門のロールの関連を取り消し、ユーザーを新しい部門内のロールに関連付けさせる。
【００５６】
ロールを設立した後、ユーザーの設立プロセスでロールを関連付けることができ、または、ユーザーの設立後いつでもロールを関連付けることができる。ユーザーがロールを関連付けた後、ロールとの関係はいつでも解除でき、他のロールとの関係はいつでも確立できる。
【００５７】
フォームフィールドが秘密フィールドと通常フィールドを含む時、フィールド承認権限を授与する時にを操作者を警告するために、秘密フィールドと通常フィールドを区別して表示する。たとえば、通常フィールドを宋字体とフォント４で表示し、機密フィールドを太字とフォント４で表示する。
【実施例２】
【００５８】
以下に、承認ノードのフォームフィールド操作権限のカスタム設定について具体例を挙げて説明する。
【００５９】
図８は、販売契約に署名する前の承認プロセスを示しており、開始ノード、承認ノード（図８には５つの承認ノードがある）、および終了ノードを含む。前記開始ノードには、販売契約の承認プロセスを発起／申請／提出する開始者を含む。前記承認ノードは販売主管Ａ、財務スタッフＢ、技術主管Ｃ、生産主管Ｄ、経理Ｅを含む。販売主管Ａは販売契約の全部の情報を承認する責任を持ち、財務スタッフＢは販売契約の財務を承認する責任を持ち、技術主管Ｃは販売契約の技術を承認する責任を持ち、生産主管Ｄは販売契約の生産を承認する責任を持ち、経理Ｅは顧客情報を除く販売契約の全部の情報を承認する責任を持つ（すなわち、５つの承認ノードのそれぞれの承認者ごとにフォームフィールド操作権限をカスタマイズする）。
【００６０】
販売契約のフォームフィールド操作権限は、図９に示すように、フォームフィールドを有しないいかなる検分権限と変更権限となるようにデフォルト設定する。顧客名と連絡先情報は機密フィールドであり、太字で表示される。
【００６１】
具体的な承認者の権限設定プロセスは次のとおりである。販売主管Ａの権限設定：承認ノードから販売主管Ａを選択し、販売契約のフォームフィールド操作権限のデフォルト設定を表示してから、顧客名、連絡先情報、製品モデル、技術要件、単価、数量、納期の後面にある［検分］列と［変更］列の対応するボックスをオンにする。
【００６２】
財務スタッフＢの権限設定：承認ノードから財務スタッフＢを選択し、販売契約のフォームフィールド操作権限のデフォルト設定を表示してから、製品モデル、単価、数量の後面にある［検分］列の対応するボックスをオンにする。
【００６３】
技術主管Ｃの権限設定：承認ノードから技術主管Ｃを選択し、販売契約のフォームフィールド操作権限のデフォルト設定を表示してから、製品モデル、技術要件の後面にある［検分］列と［変更］列の対応するボックスをオンにする。
【００６４】
生産主管Ｄの権限設定：承認ノードから生産主管Ｄを選択し、販売契約のフォームフィールド操作権限のデフォルト設定を表示してから製品モデル、数量、納期の後面にある［検分］列の対応するボックスをオンにする。
【００６５】
経理Ｅの権限設定：承認ノードから経理Ｅを選択し、販売契約のフォームフィールド操作権限のデフォルト設定を表示してから、製品モデル、技術要件、単価、数量、納期の後面にある［検分］列と［変更］列の対応するボックスをオンにする。
【００６６】
上記は本発明の優先的な実施形態だけである。本発明は、本明細書に開示された形態に限定されないと理解され、他の実施形態を除くとみなされなく、却って様々な他の組み合わせや修正や環境に利用でき、本明細書のコンセプトの範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全部と本発明に添付される請求項の範囲内にあるべきである。
【図１】
2020521224.tif 000003
【図２】
2020521224.tif 000004
2020521224.tif 000005
【図３】
2020521224.tif 000006
【図４】
2020521224.tif 000007
【図５】
2020521224.tif 000008
【図６】
2020521224.tif 000009
【図７】
2020521224.tif 000010
【図８】
2020521224.tif 000011
【図９】
2020521224.tif 000012
【国際調査報告】
2020521224.tif 000013
2020521224.tif 000014
2020521224.tif 000015
2020521224.tif 000016
2020521224.tif 000017