Difference between revisions of "Role"
({{class}}) |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | {{ | + | {{glossary}}{{cleanup}} |
| + | This is a template document to be used in creating role descriptions. ideally this would be available as a form for setting up new roles, with each the sections being fields. | ||
| + | |||
| + | == Summary == | ||
| + | The summary provides an overview of the role, their purpose within the organisation, resources they need access to, other roles within and outside the organisation they need to interact with, as well as the personality type best suited to the role. If desired this can be matched with various personality type assessments available. | ||
| + | |||
| + | == Skills == | ||
| + | An overview of skills required for the person filling the role, if necessary along with proficiency levels required, which could be assessed via a range of tests. | ||
| + | |||
| + | == Responsibilities == | ||
| + | What is expected of the person filling the role. This may be a description of various areas the role is responsible for and which standards are to be expected. If applicable, this is where KPIs ([[W:Key Performance Indicators|Key Performance Indicators]]) are introduced for that role. Regarding procedures, it is important to understand that while it is important to document everything clearly, people are not expected to follow procedures in a "robot-like" way. Once people know how to fill a role, they will only need to refer to the procedures to update them, or to train others who are new in that role. Responsibilities are generally broken down further as follows: | ||
| + | |||
| + | === Workflow === | ||
| + | Every role will have specific "inboxes" of tasks that need dealing with, we call these workflows. The person filling the role will be notified in the event of a new task, which could be in the form of an email appearing in their email application or an item within the wiki moving into a workflow state that requires attention from their role. The procedures will specify how to deal with any tasks that are part of a workflow. | ||
| + | |||
| + | === Procedures === | ||
| + | Every role portal provides access to a range of procedures listed, which are normally mapped one-to-one with roles, which means any procedure is clearly to be performed by a specific role, not several roles. The procedures provide clear step-by-step instructions on how to perform tasks, and people filling roles within wiki organisation are asked to actively document procedures whenever they have to think about how to do something or notice they are doing something that has not been documented anywhere. | ||
| + | |||
| + | === Best Practices === | ||
| + | The best practices for each role form the established convention of how tasks should be performed, they form the context for performing procedures. While procedures document clearly '''what''' needs to be done, step-by-step, best practices inform the person filling the role '''how''' the work is to be done. | ||
| + | |||
| + | === Events === | ||
| + | This aspect details which events the role is to be expected to respond to. There may be recurring events which are part of that role's schedule or events that can happen spontaneously, such as the phone ringing, a parcel being delivered or a customer walking in the door. These events would in most cases be linked to procedures. | ||
| + | |||
| + | == Rights == | ||
| + | In the IT world, rights are often associated with roles. The role filled determines the level of access a person has. This is true of every organisation, for every role there is a clear definition of rights. This will include the accounts and passwords the role needs access to, any keys required for physical facilities or cars and the level of access the role has within the IT systems of the organisation, as well as access to any other resources required for the role. In wiki organisation, roles will comprise groups in the security layer of the wiki, although most wiki organisations may wish to grant members equal access to information in the interest of openness. | ||
| + | |||
| + | == See also == | ||
| + | *[[Workflow]] | ||
| + | *[[File:Roles and Classes in OO.pdf|Roles and Classes in OO.pdf]] | ||
Latest revision as of 05:09, 26 January 2011
|
|
This is a template document to be used in creating role descriptions. ideally this would be available as a form for setting up new roles, with each the sections being fields.
Contents
Summary
The summary provides an overview of the role, their purpose within the organisation, resources they need access to, other roles within and outside the organisation they need to interact with, as well as the personality type best suited to the role. If desired this can be matched with various personality type assessments available.
Skills
An overview of skills required for the person filling the role, if necessary along with proficiency levels required, which could be assessed via a range of tests.
Responsibilities
What is expected of the person filling the role. This may be a description of various areas the role is responsible for and which standards are to be expected. If applicable, this is where KPIs (Key Performance Indicators) are introduced for that role. Regarding procedures, it is important to understand that while it is important to document everything clearly, people are not expected to follow procedures in a "robot-like" way. Once people know how to fill a role, they will only need to refer to the procedures to update them, or to train others who are new in that role. Responsibilities are generally broken down further as follows:
Workflow
Every role will have specific "inboxes" of tasks that need dealing with, we call these workflows. The person filling the role will be notified in the event of a new task, which could be in the form of an email appearing in their email application or an item within the wiki moving into a workflow state that requires attention from their role. The procedures will specify how to deal with any tasks that are part of a workflow.
Procedures
Every role portal provides access to a range of procedures listed, which are normally mapped one-to-one with roles, which means any procedure is clearly to be performed by a specific role, not several roles. The procedures provide clear step-by-step instructions on how to perform tasks, and people filling roles within wiki organisation are asked to actively document procedures whenever they have to think about how to do something or notice they are doing something that has not been documented anywhere.
Best Practices
The best practices for each role form the established convention of how tasks should be performed, they form the context for performing procedures. While procedures document clearly what needs to be done, step-by-step, best practices inform the person filling the role how the work is to be done.
Events
This aspect details which events the role is to be expected to respond to. There may be recurring events which are part of that role's schedule or events that can happen spontaneously, such as the phone ringing, a parcel being delivered or a customer walking in the door. These events would in most cases be linked to procedures.
Rights
In the IT world, rights are often associated with roles. The role filled determines the level of access a person has. This is true of every organisation, for every role there is a clear definition of rights. This will include the accounts and passwords the role needs access to, any keys required for physical facilities or cars and the level of access the role has within the IT systems of the organisation, as well as access to any other resources required for the role. In wiki organisation, roles will comprise groups in the security layer of the wiki, although most wiki organisations may wish to grant members equal access to information in the interest of openness.
