JP7351465B2 - 管理システムにおける事務処理の管理方法 - Google Patents

Description

本発明は、ＥＲＰ、ＣＲＭ等の管理システムにおける事務処理の管理方法に関する。

現在の企業管理システムにおいける、意見／提案、訴え等の事務に対する処理は、通常は会社から配属する者に手配して指定し、配属する者は事務の具体的な内容により処理するのに被配属者を指定する。この様な従来の処理方式は事務提供者の事務機密性に対する要件を満たすことができない。例えば、訴え事務に対して、会社が配属する者を手配する場合に、被訴え者或は被訴え者の部下に手配して処理する可能性があると、被訴え者は被訴え情報を取得する可能性が高い。これは訴え事務の公平処理に影響を直接及ぼす可能性が高くなり、訴え提供者に対してさえも不利の影響を及ぼす。この様な状況は、従業員が会社にある色々な問題を反映することを抑圧し、会社の発展に不利である。

又は、従来の企業管理システムにおいて事務配属を行う人は、全て特定の某従業員／ユーザーであり、配属する者が離職し、移動する時、その配属する者に関わる全体的な事務を相応に引き継がなければならない。作業量が大きくなり、エラーまたは欠落が発生しやすい。配属する者を適切に設置しないと、事務配属を遅くする問題をもたらす可能性が高い。一方では、緊急事務の処理時効に影響を及ぼし（作業場に存在する隠れた安全危険を解決する意見／提案）、予測できない損失を引き起こす可能性があり、他方では、従業員の提供した事務に遅れて対応することは、従業員の意見／提案、訴え等の事務を提供する積極性に否定的影響を及ぼす。

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

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

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

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

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

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

従業員／ユーザーの承認権限を変更する場合、従業員／ユーザーをロールから離脱するか、承認プロセスの要件を満たすために新しいロールを追加する。１番目の方式は、欠陥が上記の「ユーザーを直接承認する」方法と同じである。２番目の方式は、新しいロールがロールの設立や関連付けや承認に関わる。特に、ロールが多数あり、ロールの関連付けたユーザーも多数ある場合、どのユーザーがロールと具体的に関連付るかを覚えるのは困難である。

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

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

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

本発明の目的は、現行技術の欠陥を克服し、管理システムにおける事務処理の管理方法を提供し、事務提供者に某ユーザー／従業員を指定する機能を提供し、提供者の提供した事務の機密が漏れないのを確保し、事務の公正な処理を保証する。

本発明の目的は、以下の技術的手段により達成される。管理システムにおける事務処理の管理方法は、以下のステップを含む。事務提供者が事務処理請求を提供し、その事務を処理するのに某ユーザー／従業員を指定しようとする場合に、事務提供者が事務処理請求を提供する時に指定しようとするユーザー／従業員を指定し、前記事務処理請求を指定された前記ユーザー／従業員に指定する。そうでない場合、事務提供者が事務処理請求を提供する時に、前記事務処理請求が、事前に設定した一人或は複数の配属する者に指定され、配属する者は、事務提供者の提供する事務処理請求の内容により、処理するのに被配属ユーザー／従業員を指定する。

事務提供者が其れの指定しようとするユーザー／従業員を指定し、その事務処理請求をその被配属ユーザー／従業員に指定した後、その被配属ユーザー／従業員は任意の他のユーザー／従業員にその事務を転送することができない。

前記配属する者は、従業員、ユーザー、組／類の性質を有するロール、独立個体特性ロールのうちの一種或は複数種の組合せを含む。

前記配属する者は独立個体特性ロールであり、独立個体特性ロールは組／類の性質を有するロールと異なり、同時期に一つの独立個体特性ロールは唯一のユーザーを関連付け、一つのユーザーは一つ或は複数の独立個体特性ロールを関連付ける。

ロールを作成した時或は後にそのロールのために一つの部門を選定すると、そのロールがその部門に属し、ロールの作業内容によりロールを承認し（ユーザーはロールと関連付け後、ユーザーは関連付けたロールの権限を取得する）、且つそのロールの名称がその部門に唯一であり、そのロールの番号がシステムに唯一である。前記ユーザーが部門間に異動する時、ユーザーと元の部門のロールの関連を取り消し、ユーザーを新しい部門のロールに関連付ける。

配属する者は被配属ユーザー／従業員を指定する時、配属付記に記入するステップを更に含む。

管理システムにおける事務処理の管理方法は、被配属ユーザー／従業員が配属する者の指定した事務を受けるかどうかを選択するステップを更に含む。受ける場合、次の三種の方式のうちの一つで此の回の配属を終える。（１）一部の完了：事務提供者が提供した事務を処理し終えないで、後続の処理を必要とし、被配属ユーザー／従業員が一部の完了を確認した後、その事務提供者が提供した事務が配属する者に戻り、配属する者が再度指定するのを待つ。
（２）転送：事務提供者が提供した事務を処理し終えないで、後続の処理を必要とし、被配属ユーザー／従業員が転送を確認し且つ被転送ユーザー／従業員を指定した後、その被転送ユーザー／従業員が後続の処理を行う。（３）完了：事務提供者が提供した事務を全部と処理し終える／処理しきる。

管理システムにおける事務処理の管理方法は、一人或は複数の監督者を設置するステップを更に含む。事務提供者が提供した事務を処理し終えた後、監督者は事務提供者が提供した事務を評価する。

管理システムにおける事務処理の管理方法は、一人或は複数の監督者を設置するステップを更に含む。事務提供者が提供した事務を処理し終えた後、監督者は配属する者及び／或は事務処理に参加した各ユーザー／従業員を評価する。

事務提供者が提供した事務を処理し終えた後、事務提供者が事務処理結果を評価するステップを更に含む。

本発明の有益な効果は次のとおりである。（１）本発明は、管理システムにおける事務処理の管理方法を提供し、事務提供者のために某ユーザー／従業員を指定する機能を提供し、且つ処理するのにその事務を他人に転送することができなく、提供者の提供した事務の機密を漏らさないのを確保し、事務の公正な処理を保証する。

例えば、張三という某従業員は常務副総経理を訴えようとして、処理するために総経理を指定することができ、総経理は、処理するためにその事務を任意の他人に転送することができない。その原因は、総経理は誰に転送しても、その訴え情報が常務副総経理に伝わる可能性があり、転送することができないので、訴える人と総経理しかわからず、他の第三者がわからない。その訴えを受けた後、総経理が事情を了解するのに常務副総経理を問いかけても、総経理が訴える人の機密を保護することも考えて巧みに間接的に了解するが、訴えの問題を常務副総経理に直接的に公開しない。

（２）独立個体特性ロールを採用して配属する者とし、配属する者が離職し異動する時に、新任の配属する者を配属ロールのみに関連付けて現在の全体的な事務を自動的に取得し、事務を引き継ぐ作業量を低減し、シームレスな接合を達成することができ、事務配属が延期し或は漏れることが現れなく、緊急事務を適切に処理することを確保し、従業員の提供した事務に遅れて対応せずにすむので従業員の積極性に否定的影響を及ぼすのを回避する。

例えば、張三という元の配属する者が離職し或は異動する時、配属する者を担当しなく、従来の方式は張三に関わる全体的な事務を新任の配属する者（李四）に全て転送する必要があり、作業量が大きくなり、エラー或は脱漏が発生しやすい。適切に作業の引き継ぎを終えないと、事務配属の遅延をもたらす。本発明は、配属する者が配属ロールであり、全体的な事務を配属ロールに割り当てる。張三が離職し異動する時、システム管理者（或は相応の管理者）が張三に対応するユーザーと配属ロールの関連付けを直接的に取り消し、更に新任の李四に対応するユーザーを配属ロールに関連付けると、李四は配属ロールの現在の全体的な事務を自動的に取得する。ロールの関連により、配属する者の手中に事務を引き継ぐことを付随して実現し、作業量が小さくなり、使用が便利である。

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

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

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

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

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

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

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

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

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

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

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

管理システムにおける事務処理の管理方法であって、前記事務は、意見、提案、訴え、作業任務のうちの一種或は複数種であり、以下のステップを含む。事務提供者は事務処理請求を提供する。（１）事務提供者が事務処理請求を提供し、その事務を処理するのに某ユーザー／従業員を指定しようとする場合に、事務提供者が事務処理請求を提供する時に其れの指定しようとするユーザー／従業員を指定し、その事務処理請求を指定されたそのユーザー／従業員に指定する。この方式では、被配属ユーザー／従業員はその事務を拒否／返還することができなく（納受／領収することしかできない）、且つ「完了」の方式で事務提供者の此の回提供した指定を終えることしかできない。処理しなくても、原因の説明を書き込むことを必要とし、その事務の処理を完了する（即ち、「完了」を選択し或は確定する）。事務提供者に指定されたユーザー／従業員は、転送することができないが、その事務を自分で処理できないことを感じる（処理するのに他人を問いかける可能性があるのを感じる）と、某人を問いかけた後（これも処理結果の一種である）、その事務処理の完了を確定すると回復することができる。提供者の提供した事務処理請求が完了した後、事務提供者はこの事務の処理結果が採点される。事務提供者は、状況により事務処理請求を再度提供し、処理するために他のユーザー／従業員を指定し、或は方式（２）で後続の処理を行うことができる。

更に、事務提供者に指定されたユーザー／従業員は事務提供者が提供した事務を拒否／
返還し或は処理しないことができる（例えば、社長は多くの情報／事務を受信し、その情報／事務には、一部が妨害情報であり、もう一部は社長が原因等を了解する必要はあるが、更に処理することは必要としない）。

更に、事務提供者に指定されたユーザー／従業員の何れかは事務提供者が提供した事務を拒否／返還し或は処理しないことができるように設定することができると、此の回承認されたユーザー／従業員が提供者の提供した事務を拒否／返還し或は処理しないことができる（例えば、社長がその権限を有するように設定する）。

更に、事務提供者／被配属者／事務処理に参加した従業員／人或は従業員の提供した事務／配属する者／被配属ユーザー或は従業員のうちのどちらかが評価されないように設定することができる（例えば、被配属ユーザー／従業員「社長：張三」を評価しないように設定することができる）。

（２）事務提供者は誰がその事務を処理したのを知らなく或は事務処理者を指定したがらないと、事務提供者が事務処理請求を提供する時、その事務処理請求は、事前に設定した一人或は複数の配属する者に指定し、配属する者は、事務提供者の提供した事務処理請求の内容により、処理するのに被配属ユーザー／従業員を指定する。配属する者は被配属ユーザー／従業員を選定する時、指定付記に記入することができ、事務に関する相関説明をする。

被配属ユーザー／従業員は、配属する者の指定した事務（拒否／返還、納受／領収）を受けるかどうかを選択することができる。受ける場合（配属する者の指定したユーザー／従業員は、指定される時に配属する者の指定した事務を受けるかどうかを選択することができ、被転送ユーザー／従業員は転送される時に転送ユーザー／従業員の転送した事務を選定するかどうかを選定することもできるが、事務提供者が事務処理請求を提供する時に指定するユーザー／従業員は納受／領収することしかできなく、拒否／返還することができない）、次の三種の方式のうちの一つで此の回指定を終える。（１）一部の完了：事務提供者の提供した事務を処理し終えないで、後続の処理を必要とし、被配属ユーザー／従業員が一部の完了を確認した後、その事務提供者が提供した事務が配属する者に戻り、配属する者の再度指定するのを待つ。

（２）転送：事務提供者が提供した事務を処理し終えないで、後続の処理を必要とし、被配属ユーザー／従業員が転送を確認し且つ被転送ユーザー／従業員を指定した後、その被転送ユーザー／従業員が後続の処理を行う。被転送ユーザー／従業員が再度転送することができる（被転送ユーザー／従業員は、「一部の完了、転送、完了」という三種のうちの一種でその転送を終えることもできる。その三種の方式は、「１、一部の完了：事務提供者が提供した事務を処理し終えないで、後続の処理を必要とし、被転送ユーザー／従業員が一部の完了を確認した後、その事務提供者が提供した事務が元の配属する者に戻り、元の配属する者が再度指定するのを待つ。２、転送：事務提供者が提供した事務を処理し終えないで、後続の処理を必要とし、被転送ユーザー／従業員が転送を確認し且つ他の被転送ユーザー／従業員を指定した後、その他の被転送ユーザー／従業員が後続の処理を行う。（３）完了：事務提供者が提供した事務を全部と処理し終える／処理しきり、被転送ユーザー／従業員が完了を確認すると、その事務処理がここで完了し、後続の処理を行わない）。

（３）完了：事務提供者が提供した事務を全部と処理し終える／処理しきる。完了したとはその事務を既に解決しており、その事務を処理しないと完了を確定することができる。つまり、その事務の処理或はその事務の完了はここまでで終わり、被配属ユーザー／従業員が完了を確定した後、その事務の処理がここまでで終わり、後続の処理を行わない（事務提供者が事務処理請求を提供する時に指定するユーザー／従業員は「完了」の方式で事務提供者が提供した指定を終えることしかできなく、事務提供者が事務処理請求を提供
する時に指定するユーザー／従業員は、「完了」を確認した場合に、事務提供者が提供した事務を全部と処理し終える／処理しきる。完了したとはその事務を既に解決しており、その事務を処理しないと完了を確定することができる。つまり、その事務の処理或はその事務の完了はここまで終わり、被配属ユーザー／従業員が完了を確定した後、その事務の処理がここまで終わる）。

更に、配属する者はその権限内に検分できる並びにその提供した事務に関係する他の事務／情報／データ等を選択してその提供した事務と関連付け、その提供した事務の処理人員がその提供した事務を処理する時に相関情報を検分することができるのに都合がよく、提供した事務を処理するのに役立つ。ある事務を処理し終え後、事務提供者が満足しないので（その原因は、その事務を処理しなく或は処理結果に満足しない可能性がある）、元の事務提供者は事務を再度、配属する者に提供すると、配属する者はこの人の以前提供した事務を選択して此の回提供した事務と関連付ける。これは、後続の処理人員がその事務を提供した前或は後に相関状況を了解することができるので都合がよい。

被配属ユーザー／従業員或は被転送ユーザー／従業員或は被配属ユーザー／従業員は、事務を処理している過程中に（配属／転送／指定を受けた後、被配属ユーザー／従業員或は被転送ユーザー／従業員は上記の三種の方式のうちの一種を選定してその配属或は転送を終える前、被配属ユーザー／従業員は「完了」を選定してその指定を終える前）、相関人員が事務処理の進度と委細を了解するために、事務処理情報と相関情報を記入して保存することができる。

さらに、前記配属する者の受けた事務処理進度は、以下の状況を含む。（１）未処理は、既に指定したが処理しないという状況と指定しないという状況を含む。（２）既に処理したが完了しない、（３）完了は、事務提供者が提供した事務を処理し終える。事務処理進度にマークを付ける方式で提供した事務を処理する状況を表示することもできる。提供した事務を処理する状況を早急に了解するのに都合がよい。特にある事務を処理しないが完了を選択することを了解／監督する。

事務提供者は従業員、ユーザー、組／類の性質を有するロール、独立個体特性ロール等である。事務提供者は、自分で提供した全体的な事務並びに事務ごとの処理過程及び詳しい処理記録を見ることができる（事務を処理する過程で、事務処理進度を事務提供者に随時反映する必要があり、しかも処理段階で処理記録等の情報を記入することができる）。更に、事務提供者が必要な処理進度情報のみが見えるが機密な記録が見えないように設定することもできる。配属する者は、自分の配属を経る事務内容や処理過程や相関処理情報を見ることができ、自分で指定した以外の事務が見えない。更に、配属する者が必要な処理進度情報のみが見えるが機密な記録が見えないように設定することもできる。事務を処理し終えた後、配属する者は自分で指定した事務に対して何でも見えるか（事務内容、処理過程及び相関処理情報）、又は何も見えない（事務内容、処理過程及び相関処理情報）。又は、配属する者は指定した事務内容が見えるが、処理過程及び相関処理情報が見えない。

本実施例は、事務提供者のために某ユーザー／従業員を指定する機能を提供し、且つ事務提供者が指定しようとするユーザー／従業員を指定し、その事務処理請求をその被指定ユーザー／従業員に指定した後、その被指定ユーザー／従業員はその事務を任意の他のユーザー／従業員を転送することができない。提供者の提供した事務の機密を漏らさないことを確保し、事務の公正処理を保証する。

例えば、張三という某従業員は常務副総経理を訴えようとするのに、処理するのを総経理を指定することができ、総経理は、処理するためにその事務を任意の他人に転送することができない。その原因は、総経理は誰に転送しても、その訴え情報が常務副総経理に伝
わる可能性があり、転送することができないので、訴える人と総経理しかわからず、他の第三者がわからない。その訴えを受けた後、総経理が事情を了解するのに常務副総経理に問いかけても、総経理が訴える人の機密を保護することも考えて巧みに間接的に了解するが、訴え問題を常務副総経理に直接的に公開しない。

一つの監督者を設定し、事務提供者が提供した全部の事務を処理し終えた後、監督者は事務提供者が提供した事務を評価し、監督者は配属する者及び／或は事務処理に参加した各従業員／ユーザーを評価することもできる。評価方式は採点や満足や不満の評価等のうちの一種或は複数種を含む。評価の観点は、態度や処理効率や結果や過程等のうちの一種或は複数種を含む。

監督者は採点を行い、幾つかの事務は会社に対して積極的な作用が備わる主に考えられる。事務を処理し終えた後、採点しなければならない。その理由は、最初に事務が価値があるように見えるが、処理者により処理し終えた後その事務が実に何も価値がないように見えるという可能性があるからである。事務に対する採点はゼロ及びゼロ以上の分数のみであり、負数ではない。事務処理に参加した従業員／ユーザーに対する採点は負数である可能性がある。

事務提供者が提供した全体的な事務を処理し終えた後、事務提供者は事務処理結果を評価することもでき、事務処理の効率や結果満足度等を評価する。

評価は機密の漏洩をもたらす可能性があるため、監督者は事務提供者の直接指定したユーザー／従業員及び処理過程を評価することができなく、その事務を評価することもできないようにも設定する。勿論、監督者は事務提供者の直接指定したユーザー／従業員（監督者が何方かの配属する者／何方かの事務処理者／何方かの事務処理ロールの関連付けたユーザー／何方かの事務処理ロールの関連付けたユーザーに対応する従業員に対するのを設置するようにも設定する）及び承認過程を評価することができ、その事務（対応の事務）を評価することもできるようにも需要に応じて設定する。

前記配属する者は従業員、ユーザー、組／類の性質を有するロール、独立個体特性ロール等を含む。

本実施例は、前記配属する者は独立個体特性ロールであり、独立個体特性ロールは組／類の性質を有するロールと異なり、図４に示すように、同時期に一つの独立個体特性ロールは唯一のユーザーを関連付け、一つのユーザーは一つ或は複数の独立個体特性ロールを関連付ける。一つのユーザーが一つの従業員に対応し、一つの従業員が一つのユーザーに対応し、従業員は其れに対応するユーザーの関連付けたロール（独立個体特性ロール）により権限を決定（取得）する。従業員とユーザーはお互いに１対１の関係であり且つ一生結びつき、ユーザーが従業員に対応した後、そのユーザーはその従業員に属し、ユーザーは他の従業員を関連付けることができない。その従業員が離職する場合に、そのユーザーは他の従業員に対応することもできなく、従業員は再度入職した後、その従業員が依然として元のユーザーを利用している。

ロールを作成した時或は後にそのロールのために一つの部門を選定すると、そのロールがその部門に属し、ロールの作業内容によりロールを承認し、且つそのロールの名称がその部門に唯一であり、そのロールの番号がシステムに唯一である。前記ユーザーが部門間に異動する時、ユーザーと元の部門のロールの関連を取り消し、ユーザーを新しい部門のロールに関連付ける。

事務提供者は誰がその事務を処理するのかを明らかにする場合に、その事務の処理に指定したのは、ユーザー／従業員であり、ロールではない。その原因は、指定したのはロールである場合に、企業長期運営に従業員の変動に関わる過程では、一つのロールが依然として複数のユーザー／従業員に関わる可能性があり、その事務の機密を確保することができないので、このような事務を処理するのに確定的なユーザー／従業員を指定する。

独立個体特性ロールを採用して配属する者とし、配属する者が離職し異動する時に、新任の配属する者（配属する者に対応するユーザー）を配属ロールのみに関連付けて現在の全体的な事務を自動的に取得し、事務を引き継ぐ作業量を低減する。しかも、シームレスな接合を達成することができ、事務配属が延期し或は漏れることが生じなく、緊急事務を適切に処理することを確保し、従業員の提供した事務に遅れて対応しないので従業員の積極性に否定的影響を及ぼすのを回避する。

例えば、張三という元の配属する者が離職し或は異動する時、配属する者を担当しなくなり、従来の方式は張三に関わる全体的な事務を新任の配属する者（李四）に全て転送する必要があり、作業量が大きくなり、エラー或は脱漏が発生しやすい。適切に作業の引き継ぎを終えないと、事務配属の延時をもたらす。本発明は、配属する者が配属ロールであり、全体的な事務を配属ロールに割り当てる。張三が離職し異動する時、システム管理者（或は相応の管理者）が張三に対応するユーザーと配属ロールの関連付けを直接的に取り消し、更に新任の李四に対応するユーザーを配属ロールに関連付けると、李四は配属ロールの現在の全体的な事務を自動的に取得する。ロールの関連により、配属する者の手中に事務を引き継ぐことを付随して実現する。

以下は、独立した個体の性質を有するロールによりユーザーを承認する方法の備わる利点を分析する。ユーザーはそれとロールの関連により権限を決定（取得）し、ユーザーの権限を修正すると、ロールの所有する権限を調整することによりそのロールを関連付けたユーザーの権限を改変する目的を達成する。一旦ユーザーがロールを関連付けたと、そのユーザーはそのロールの所有する操作権限を有する。

ロールとユーザーの関係は１対１である（そのロールが一つのユーザーと関連付ける時、他のユーザーがそのロールを再度関連付けることができない。そのロールがユーザーに関連付けされたと、他のユーザーに選定されて関連付けることができる。つまり、一つのロールはでき且つ一つのユーザーのみに関連付けられる）。ユーザーとロールの関係は１対多である（一つのユーザーが同時に複数のロールを関連付ける）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (6)

1. 管理システムにおける事務処理の管理方法であって、
   事務提供者が事務処理請求を提供し、事務提供者が事務を処理するのにユーザー／従業員を指定する場合、前記管理システムの制御手段は、前記事務提供者による事務処理請求の提供を受け付けると共に、ユーザー／従業員の指定を受け付け、指定された前記ユーザー／従業員による他のユーザー／従業員への事務の転送を受け付けないように制御し、
   そうでない場合、前記制御手段は、前記事務提供者による事務処理請求の提供を受け付け、提供された事務処理請求を、事前に設定を受け付けた一人或は複数の配属する者に指定し、指定された前記配属する者が前記事務提供者の提供する事務処理請求の内容に応じて処理するための被配属ユーザー／従業員の指定を受け付けるように制御すること、を含み、
   前記配属する者は独立個体特性ロールであり、独立個体特性ロールは組／類の性質を有するロールと異なり、同時期に一つの独立個体特性ロールは唯一のユーザーを関連付け、一つのユーザーは一つ或は複数の独立個体特性ロールを関連付けるように前記制御手段で関連付けを受け付けて、ユーザーに関連付けられたロールの権限を該ユーザーに取得させる、管理システムにおける事務処理の管理方法。
2. 前記制御手段が、ロールの作成を受け付けた時或は後に前記ロールのために一つの部門の選定を受け付けると、前記ロールが前記部門に属し、前記ロールの作業内容によりロールを承認し、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一であり、前記ユーザーが部門間を異動する時、前記制御手段が、前記ユーザーと元の部門のロールの関連の取り消しを受け付け、前記ユーザーと新しい部門のロールの関連付けを受け付ける請求項１に記載の管理システムにおける事務処理の管理方法。
3. 前記制御手段が、被配属ユーザー／従業員が指定された事務を受けるかどうかの選択を受け付けるステップを更に含み、受ける場合に、
   （１）一部の完了：事務提供者が提供した事務を処理し終えないで、後続の処理を必要とし、被配属ユーザー／従業員が一部の完了を確認した後、前記事務提供者が提供した事務が指定された前記配属する者に戻り、指定された前記配属する者が再度指定するのを待つこと、
   （２）転送：事務提供者が提供した事務を処理し終えないで、後続の処理を必要とし被配属ユーザー／従業員が転送を確認し且つ被転送ユーザー／従業員を指定した後、被転送ユーザー／従業員が後続の処理を行うこと、
   （３）完了：事務提供者が提供した事務の全部を処理し終える／処理しきること、
   三種の方式のうちの一つが行われる請求項１に記載の管理システムにおける事務処理の管理方法。
4. 前記制御手段が、一人或は複数の監督者の設置を受け付けるステップを更に含み、前記事務提供者が提供した事務を処理し終えた後、前記制御手段によって、前記監督者は前記事務提供者が提供した事務を評価できるようにする請求項１に記載の管理システムにおける事務処理の管理方法。
5. 前記制御手段が、一人或は複数の監督者の設置を受け付けるステップを更に含み、事務提供者が提供した事務を処理し終えた後、前記制御手段によって、前記監督者は指定された前記配属する者及び／或は事務処理に参加した各ユーザー／従業員を評価できるようにする請求項１に記載の管理システムにおける事務処理の管理方法。
6. 前記事務提供者が提供した事務を処理し終えた後、前記制御手段によって、前記事務提供者が事務処理結果を評価できるようにする請求項１に記載の管理システムにおける事務処理の管理方法。