Process for Role Creation ( New ) / Change

[Former Member]

What is the PROCESS YOU think is need to create / change a role. This question because the process together with controls plays a very vital role in securing any corporation. "Roles" being integral to our field of practice, Wanted to know thoughts from

various folks.

ideally we could bullet points to answers or numbered !

Thanks

PS; 1.I understand that it varies from corporation to corporation.

2. I am not talkiing about designng of the role.

Edited by: george G on Jan 14, 2008 7:10 PM

[jurjen_heeck]

Well, since the original authorization concept on your system is (or should be) an integral part of the implementation's design I suggest you treat rolechanges exactly the way software development and/or customizing is handled.....

[Former Member]

Agree with Jurjen.

It should be treated like a normal change request which will require approval by mgmnt.

[Former Member]

Hey Come on Guys !! I know you can suggest more than that !! Dont ask me to be an advocate of 'status quo' !! let me hear more innovative suggestions !! way to improvement , way to raising the bar !

thx

[Former Member]

Sorry George but I am not a liberal! LOL!

[jurjen_heeck]

>

> let me hear more innovative suggestions !! way to improvement , way to raising the bar !

Okay, so you want to improve. Pls tell us where your 'bar' is now, otherwise noone will know wether their advice will raise it or not.

Apart from that my standpoint remains that the changeprocedures for software development and customizing generally suffice for authorization management.

Jurjen

[Former Member]

Jurjen

Agree, and to give help to George here are some bulltpoints te shoot to management:

1 all roles MUST be based upon a process description made by the functional consultant(s) together with business expert(s). Which means that new roles or changed roles can not exist before the change in the process description has been approved (and that is at hoighest level management).

2 the aforementioned precess descrition MUST als describe the risks teh experts see in the processess and the way they think that should be solved. Meaning they do a proposition at this stage and it is up to the security team to try to build roles the way the resctictions are requested.

3 Only by testing (by functional consultants and/or business experts) the requested restrictions can be proved

4 In any good organised company the whole process as described above, is writen down in an auditable system (f.e. Solution manager) and all steps MUST have the OK of the right manager before the one is allowed to start on the next step.

The whole of the above is a mandatory process.

benefits:

Auditable

Manageble

possible to track for all involved

Can be used to manage resources

Should be used to evaluate money spend

Can be used to assign KPI's to all support departments in order to establish the efficiency of the support process.

Should be used in change management procedures to inform Business end users of process changes including planning of change courses when needed.

All together it is NOT much different from the orginal implementation process other than the procedures in communication.

Is this what you need George. If not clear make me an offer and i come to your site and will explain in person.

Edited by: Auke Visser on Jan 15, 2008 12:53 PM

[Former Member]

Auke,

Yes this is what I was looking for !! I am sure some time later few others ( Read atleast Juluis,Alex! !) Will chip in their experience.

Is this what you need George. If not clear make me an offer and i come to your site and will explain in person.

Auke, How I wish I could make an offer ! For time being my offer remains a cup of tea at the tiffanys and a broadway show ? ready ?

Thanks Auke, greatly appreciate !

[Former Member]

Hi george,

Without copy and pasting a sample doc I can't really add to what Auke's has put down.

There are plenty of ways to skin a cat and as long as you keep the fundamental controls in there then it'll usually work out OK.

As a it of extra ammo, you may want to have a look at the ITIL framework which stipulates a set of procedures covering change management.

Overview here: http://en.wikipedia.org/wiki/Change_Management_(ITIL)

[Former Member]

If 2 cents more can still be squeezed out, then [this thread|; might interest you.

Which ever process there is, it should strive to support a consistent authorization concept (and changes going forward) together with a consistent development approach (and changes), and system development liefcycle etc. Even if both (or all) are in "the bad books", that is still better than both (or all) being different.

Or is that too high-level and fluffy for you?

Cheers,

Julius

[Former Member]

Juluis, Sorry for the delay,in reply..i aam taken ill.

You rpost is a good CEO talk !! i want grass roots ..what to do ( Likewhat Auke said) how to do . what to expect ..etc

Thanks

[Former Member]

>

> Juluis, Sorry for the delay,in reply..i aam taken ill.

>

> You rpost is a good CEO talk !! i want grass roots ..what to do ( Likewhat Auke said) how to do . what to expect ..etc

>

> Thanks

1. absorb all the info in this post

2. create a process that reflects the points that have been raised and is based on common sense

3. ask colleagues for their comments on it.

I'm sure there are plenty on here who will look over it for you. I don't think anyone is going to post up a detailed one.

[Former Member]

Hi,

1. Roles must be created or changed based on the Requirements of the Organisation.

2. It must be checked as to how many users exist in the organisation for various application areas. If the number of users are less, then they have more responsibility area .So this may result in SoD conflicts. The roles must be designed in such a fashion where the SoD conflicts are minimal.

3. There should be a clear demarkation between critical and non critical activities.

4. Business and IT has to come together to decided what are the General requirements and how they should be mapped to SAP.

5.After all this the Roles are implemented in SAP.