Difference between revisions of "Role"
({{class}}) |
(some notes on role) |
||
| Line 1: | Line 1: | ||
{{class}} | {{class}} | ||
| + | A role is an essential component of any organisation, is it a specific entry point for people to perform a range of tasks within the organisation. People who fill roles perform a range of procedures which are linked to from their role [[workspace]] and are expected to do so according to established convention for that role, the [[best practices]]. This is over and above their general commitment to the [[charter]] of the organisation they work for, motivated by the shared vision they have with the other members. | ||
| + | |||
| + | It is important to distinguish people from the roles they fill within an organisation. This is often overlooked, as many people identify with their (paid-for) roles so much they refer to themselves as "being that role", as in: Person 1: "Who are you?" Person 2: "I'm the janitor". In reality the person responding only fills the role of the janitor for a certain amount of time. Most people fill a number of roles, and to reduce them to the role they fill to "earn a living" reduces them to much less than they are, it also breeds discrimination and prejudice. From the perspective of the organisation and knowledge management, keeping roles and people separate is important to ensure that know-how remains within the organisation and new members can easily be trained up to fill a role, or multiple roles, or move between roles. Having a clear structure of roles ensures accountability and allows everyone to focus on their specific area. When people identify strongly with their roles this often a result of poor training and documentation and results in members leaving the organisation with a lot of role specific knowledge, which is lost to the organisation due to never being documented. | ||
| + | |||
| + | Within wiki organisation, role portals can be accessed through the ontology, they form one of the top level branches. | ||
| + | *Managing files and imap folders, home folder, login from multiple workstations, could be part of od-workstation pckg | ||
| + | *Groupware setup when setting up person in role - examples (Milan) | ||
| + | *Emailtowiki, Category watching, Config:Role | ||
| + | *Should allow conversion of posted form to wiki article | ||
| + | *Unique IDs? Done? | ||
| + | *Emailtowiki config, allow in article config:role | ||
| + | |||
| + | == 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: | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
Revision as of 23:28, 5 January 2009
|
A role is an essential component of any organisation, is it a specific entry point for people to perform a range of tasks within the organisation. People who fill roles perform a range of procedures which are linked to from their role workspace and are expected to do so according to established convention for that role, the best practices. This is over and above their general commitment to the charter of the organisation they work for, motivated by the shared vision they have with the other members.
It is important to distinguish people from the roles they fill within an organisation. This is often overlooked, as many people identify with their (paid-for) roles so much they refer to themselves as "being that role", as in: Person 1: "Who are you?" Person 2: "I'm the janitor". In reality the person responding only fills the role of the janitor for a certain amount of time. Most people fill a number of roles, and to reduce them to the role they fill to "earn a living" reduces them to much less than they are, it also breeds discrimination and prejudice. From the perspective of the organisation and knowledge management, keeping roles and people separate is important to ensure that know-how remains within the organisation and new members can easily be trained up to fill a role, or multiple roles, or move between roles. Having a clear structure of roles ensures accountability and allows everyone to focus on their specific area. When people identify strongly with their roles this often a result of poor training and documentation and results in members leaving the organisation with a lot of role specific knowledge, which is lost to the organisation due to never being documented.
Within wiki organisation, role portals can be accessed through the ontology, they form one of the top level branches.
- Managing files and imap folders, home folder, login from multiple workstations, could be part of od-workstation pckg
- Groupware setup when setting up person in role - examples (Milan)
- Emailtowiki, Category watching, Config:Role
- Should allow conversion of posted form to wiki article
- Unique IDs? Done?
- Emailtowiki config, allow in article config:role
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:
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.
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.
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.
