Roles vs Position

This is what I also do in my projects and highly recommended. It allows you to run reports and see who has to be trained and saves you touching dozens or hundreds of models if the org structure changes.

Hi, you can look to this:

http://www.ariscommunity.com/users/hannawij/2010-08-11-position-object-vs-person-type-object

daer Roland and Alexander,

Thank you for your replies.

My concerns centralized around the way followed by the consultant to identify the roles. Ha has proposed to us very generic and common roles which confused everyone in our organization, for example, he has proposed the following roles to be assigned to Strategic Planning Division:

• Strategic Planning Team Leader.
• Strategic Planning Team member.

In the current situation we have approximately 25 positions who responsible and accountable to execute the strategic planning processes. I have discussed and argued with the consultant to use positions while he designing the processes but always he refers back to the Best practices.

Just wanted to know is that “best practice” if yes, I would appreciate if anyone could send me any standard, rules or document which describes how to identify the roles.

Thank you all,

Hi,

Roles should be common, because role describes some pull of functions assigned to it. From one site it is difficult something to say about your roles labeling approach without understanding of your modeling conventions and goals. From other site, it’s really could be that one role assigned to many positions, e.g. you can get some common roles like ‘Enterprise employee’ for every position at the company (role is used e.g. at HR processes) or role ‘Department manager’ for all managers.

Of course, labeling of the roles should be described in Modeling Conventions. And there are no any common approaches because every project is unique. But there are some (our) rules of roles determining. First of all your roles should be absolutely clear to process executers – if process executer can read model without any explanations then your approach is right. So there is a conclusion that your roles labeling should be very similar to positions, but not equal. Next, labeling of the roles shouldn’t be too common or too detailed – it is another extreme when every role named similar to function.

Modeling with roles is considered best practice by many process modelers. This is due to the fact that in large organizations positions an responsibilities (described by roles in ARIS) tend to vary based on different criteria. For instance, in a large company there might many manufacturing sites of varying sizes. At a large site there may be a different position for each role, at the small site there may one or two positions that are responsible for all of the roles. Both use the same process but different positions are reponsible for doing the work. Using roles instead of positions allows the same process to be used in both places making it easier to standardize your processes. You should then map the roles to the various positions on the organization chart. Some organizations are even using this to build their positions descriptions. Also, roles are less likely to change than the org chart (at most companies at least).

Each consultant and/or consulting organization has a set of their own best practices, also some standards, training, and certification groups maintain a set of best practices. I don't know af any authoritative set of set of best practices that I could point you to. Best is to have the consultant explain why it is a best practice, they should be able to justify it.

Dear Alexander and Rick,

Thank you for your advices and I really appreciate your help.

Best regards.

I have found roles vs positions a major challenge and some reasons include
- lack of ownership for roles
- lack of resource to maintain the role position link
- lack of interaction between the business and HR to ensure the roles match job descriptions behind the positions
- lack of definition and governance around roles and the link to positions.

However it can work with commitment and collaboration.

In my experience businesses often fall back on to positions as it is the most concrete and visible to all...

There is a fundamental difference between Roles and Positions,

Positions are used in a hierarchical organization tree for planning purposes.  Not all positions are allways occupied.  Position to persons is a one-to-one relationship.

Roles on the other hand are functional descriptions of a particular job function, such as Purchasing Agent, Director, Finance Clerk, CIO, etc...  Roles MUST have a "roleOccupant" to be active.  Roles can be delegated. Roles have privileges.  All Roles (i.e. Director) have the same privileges, but are restricted to the Organizational Unit.  This makes the management of Privileges much easier.

Persons can hold more than one role to perform their day to day activities, and will inherit the privileges assigned to the specific Role. 

And then there are Groups,  Groups are not roles, a group is a grouping of persons requiring access to a resource, example group A has access to Printer Y.

There are many references avaliable with regards to this subject that I can provide.

Dear Mr Secretain

 i  prepare my phd thesis  modeling the new product development process usig aris Business architect. since i want to model the organization chart of an enterprise i'd like to send me the references concernig this subject (position ,position type and roles) .

Thank you in advance for your assistance

Hi guys,

This is a very interesting topic. I'd like some assistance with this problem.

We're in a systems implementation project. The processes being developed have very system oriented roles, viz. master data maintainer, purchase order processor, work order requestor etc.

From a systems perspective, these roles are effective as they can be linked back to the relevant system objects and helps in defining system authorisations.

However from a process perspective, the end users cannot always relate to such specific and granular role. In my opinion, process roles should describe the function the person is performing. E.g. A position of a Process Analyst, may perform the following process roles - process modeller, process workshop facilitator, repository administrator, project manager etc.

So have you guys had any experience in defining process roles that are easily relateable by the business and also serves the purpose of systems security design?

Cheers

Ganesh