Role Naming convention

[Former Member]

Good Morning All..!

I have a brand new sand box SCM, I am creating new roles on the system..

The roles should meet the Global naming standards, team want to go with location, system and org. unit in the naming convention..

I came up with

Eg:

ZM_US_SCM_0101AB_XXXX_ALL (Business role)

Description of above example:

M= Role type..like configure/x, composite/c......

US= location

SCM=system

0101AB=company and dep code

xxxx= role description

I wonder how to customize the naming convention for Basis, Helpdesk, security, abap and configuration

Am I complicating the role name?

Team want location code in the naming, so please suggest how should I go about it......?

Thanks in advance..!

[Former Member]

Hey guys please help me with your thoughts..I am stuck with this..

[Former Member]

Hi Anil,

I'm sure it is important to you, but please don't forget that a good number of posters on this board are based in Europe and the time you posted is end of working day for those on the mainland.

There are always many ways to do naming conventions and there is no right answer.

First of all, you talk about "global naming convention" - are there other non-SRM implementations that have roles created? If so, what is their naming convention? It may be worth using whatever they are using so as to retain consistency across environments.

What you want from your naming convention is the ability to search easily and to identify the purpose of roles.

Your naming convention contains a load of useful data but depending on how you use it, you may want to move some of the elements around

First of all, they don't have to start with Z. Avoid S but the rest is fair game, though Z is very safe.

Role Type: Stick to the technical type of the role here, don't mix composite and config for example. Composite, derived, parent etc make sense if you need the info.

Location: Is this more important that the system? if you search on US roles then maybe not, your call.

System: as above

Company and dep code: Usually I prefer this later on. This is because I typically search on type of role, func area, variant/description and then company or org unit. Again it is your call and nothing wrong with your suggestion.

Role description: Personally I prefer to use a numerical system here. The reason for this is that role descriptions change and transactions in a role change. By sticking to numbers then I find that when these things are changed, you don't have to worry so much about the role no longer matching the description.

depending on the build requirements, I find something like the following is reasonably flexible

ZS_R3_UK_<process area>_<role number>_<org unit>

where <process area> could be fi, ap, security, basis etc

<role number> is an arbitrary number e.g. 00001 - 99999

<org unit> plant/comp code etc - whatever the role is derived to etc

hope that helps

[Former Member]

Hey Alex!

I was bit tensed so could not resist.

Your explanation was very informative and thanks a tonne for giving me your thoughts.

"Just to check my understanding is Org. unit used only when we derive a role from a master role?"

I know I am bugging you alot, however when my turn comes I would do like you.

Thanks Again So Much for a detail explanation.

[Former Member]

Hi Anil,

You can use org unit whenever appropriate. It may be that you don't use master & derived role principle and maintain a single role which is associated with an org unit. It's certainly not mandatory to include it!

[Former Member]

Thanks Again Alex..!