Difference between revisions of "Role"

From Organic Design wiki
m (Responsibilities)
(move unfinished bits out to talk)
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.
+
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.
 
 
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 ==
 
== 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.
 
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.

Revision as of 00:33, 13 February 2009

Info.svg This article is a class which is similar to a category except that it has a number of associated articles of different namespaces:
  • Role - the concepts of Foo
  • Portal:Roles - the primary entry point for all things Foo, does section zero query of members
  • Template:Role - articles transclude this template to designate it as a member of the Foo class
  • Category:Roles - the template will automatically categorise the instances into here, but the portal is the primary entry point
  • Create:Role - default content which should be preloaded into newly created Foo instances
  • Form:Role - if a forms solutions is in use, then this will be the form for creating or editing Foo parameters

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 (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.