profile naming - how would you do it?

[Former Member]

Hi,

I am involved in a large implementation of a number of SAP products. We need to come up with a naming convention that works across multiple products and makes sense in order to be able to decipher it, as well as following any naming conventions/rules of the various systems.

Here are the products we will be installing:

ECC

SRM

CRM

SCM

BI

Portal

PI

ADS

Sol. Manager

TRex

Are there any "rules" for naming? (I.E. - no underscores in the second position, can't be longer than X characters, etc.) We'd like the names to match or be similar for the roles in ECC and the Portal.

Here's an idea we are bouncing around:

1_234_<desc>_##

position 1 is either a Z (composite role) or Y (single role)

position 2 is a single character denoting an internal user or external user (so "I" or "E")

position 3 is a character denoting the application (SRM, CRM, ECC, XI, etc. - we have a list made up, so

X represents XI for instance)

position 4 is a character denoting the server role (Dev, Test, QA, PRD)

<desc> is a short description -- "Manager - Disp. only", "Manager - Change", etc.

"##" are a couple of characters to denote versions if necessary

Please shoot holes in this and give us a solid working idea. Can we name profiles so they are the same or close enough to each other between ECC and the Portal so we can know they are related?

Thanks,

KC

[Former Member]

Hi Keith,

Your idea is looks good.

for profiles....do one thing, use the same role name for profiles too.

while generating the profiles mention the rolename as profile name ...manually.

[jurjen_heeck]

>

> while generating the profiles mention the rolename as profile name ...manually.

Why would you do that? It restricts your rolename to 12 characters instead of 30 and the relation between the role and the profile is already in the table AGR_PROF. There's no need at all to change the generated profile name on a system newer than 4.5, except if you want to restrict maintenance authorizations based on the profile name.

[Former Member]

Jurjen

as the change documents only show the profile name a lot of companies like the profiles to have the same name as the role. I do not see a problem in having only 10 positions available.

As in the naming convention a few tips:

1 let there be a position to disciminate between the systems like let BI roles start with B: R/3 roles start with R: etc.

2 make sure that you use exactly the same position in the name for the same thing, this makes analyses easier later.

3 aviod trying to build meaning full names as in that case people will force you to use addtional positions, best pratice create roles per area with a sequece number like HR001, HR002, FI001, FI002 and CO0001, CO002. If you work across multiple system it might be handy to use teh same role name for the same thing everywhere.

4 use special characters in role name between different parts of the role name: example R:HR001_all is a R/3 HR role without restictions (all ORG values set to *) if you happen to go bejond 10 positions because of that then you can leave the special characters out of the profile name.

5 Be sure to have all Or Level varianst weel inventorised before making a final decission on the naming convention, and make sure that all these variants are possible.

[jurjen_heeck]

>

> as the change documents only show the profile name a lot of companies like the profiles to have the same name as the role.

I've heard that one more often but still disagree. The databaselink between profile and role is technically guaranteed, a manually typed profile name can contain errors and cause mismatches in reports. I prefer an additional query on the outcome of profile reports to combine them with the role names rather than trusting the profile names.

Anyway, this definately is one of my pet peeves

Edited by: Jurjen Heeck on Mar 4, 2008 1:04 PM

[Former Member]

Jurjen

as we probably both know how to create our own reports that translate profilenames in role names etc. we do not see the need.

But there is a mayority of people out there (like controllers) that do not know their way around in SAP as we do. for these poepel it can be of help. and i would rather help them this way then have them turn away of using SAP themselves.

I recently had a few auditors in a class i was teaching that told me they had never logged on to SAP nor would they ever do. We could try to get these people on board by doing this like the one we discuss now!

[Former Member]

I would tend to agree with Jurjen.

In the majority of cases it should be possible to explain to a controller / role owner that they use the name of the role which they know, and when they see T-XXXXXXX things then it is technical stuff underlying the role, and only concentrate on the values then. They should from the outset (selection) be aware of which role they are looking at.

If you name the roles / profiles / authorizations the same (or very similar, only) then you will confuse them and mixed up terminology does not help anybody (a bit like the Tower of Babylon).

Regards,

Julius

[Former Member]

Julius

although you are right about the possible mix up i know that it is done this way more often then leave the default profile name. and for experienced people there will not be a mix up. teh peopel we do this for do not even know of a difference between rol and profile, so why bother?

The only advantage i know for leaving the default name is that one can identify the system in which the role has been created

[Former Member]

As a point for clarity, the <desc> portion of what I am proposing is not limited to 4 characters. This can be as long as necessary, as in my example of "Manager - Disp. Only". This example is 20 characters.

One of my questions is, what are the character limits for naming in both ECC and Portal? I'm guessing by your posts that the limit is 30 characters in ECC, but what about the Portal? This implementation is actually going to be 99.99999% web-based and we would like the ECC and Portal names to match. Are there limits on the Portal as far as length, special characters that can't be used, etc.?

Thanks for all the feedback thusfar.

- KC

[Former Member]

> Keith Cooley wrote:

> As a point for clarity, the <desc> portion of what I am proposing is not limited to 4 characters. This can be as long as necessary, as in my example of "Manager - Disp. Only". This example is 20 characters.

So, we are talking about a naming convention for the role names, not the profile names! Right?

Thanks for clarifying between Internal and External. That will be an important feature which the business partners can also assign themselves. Have you thought about moving "I" / "E" right upfront in the name to seperate them without any doubt?

Cheers,

Julius

[Former Member]

Hello Auke,

I dont want to change your mind if your way works for you and your customers (I assume that you stick around for long enough that if it did not work, then you would get to hear about it from them and would have changed your mind), so that is fine.

I did find one thing amusing though:

> and for experienced people there will not be a mix up. teh peopel we do this for do not even know of a difference between rol and profile, so why bother?

What you see as a solution to the people problem, is exactly that which I think is the cause of the problem.

If someone turned up in my office and tried to persuade me that roles, profiles and authorizations should all have the same name so that I don't get confused by them, then I would become rather sceptical...

... a sceptic example added:

Changing the name of the profile to that of the role would limit the name spaces for the profiles and the authorizations when they are generated. You might even get it right to have collisions... or human error when maintaining the profile names could occur (perhaps providing more access than intended).

Certainly, for such a large implementation where Keith has indicated that 99% will be web based UI, however they want to restrict the backend authorizations (which is a good security practice in my books), there will most likely be more than one client used in QAS and without much doubt in the DEV systems (not to mention several of each of them). So a client specific indicator would be needed for the profile names... in addition to the SID...?

Some recommended reading: [SAP note 571276|https://service.sap.com/sap/support/notes/571276]

Cheers,

Julius

Edited by: Julius Bussche on Mar 4, 2008 8:31 PM

[Former Member]

Some "off the top of my hat comments:

> Keith Cooley wrote:

> Here are the products we will be installing:

>

> ECC

> SRM

> CRM

> SCM

> BI

> Portal

> PI

> ADS

> Sol. Manager

> TRex

I was thinking of suggesting including the SID (system ID) of the origin of the role, but if you let the generated profiles generate their names, then that is taken care of for technical information purposes.

> 1_234_<desc>_##

>

> position 1 is either a Z (composite role) or Y (single role)

You might want to give folks authority to maintain Composites from a certain range of names, but not Singles. Consider moving the Z/Y indicator further back in the naming convention.

> position 2 is a single character denoting an internal user or external user (so "I" or "E")

I assume you mean Employee / Contractor. You might have temporary externals in to take care of work for employees taken ill unexpectedly, or, an employee might gather sufficient skills to fullfill the role of an external consultant brought in for customzing. Consider dropping this, and rather use user groups of the users to distinguish between internals and externals.

> position 3 is a character denoting the application (SRM, CRM, ECC, XI, etc. - we have a list made up, so

> X represents XI for instance)

What happens if the same role is required in the ECC and the XI and the SolMan?

> position 4 is a character denoting the server role (Dev, Test, QA, PRD)

I like this one. An indicator for how far the role should be transported. The less developer roles in production, the better

> <desc> is a short description -- "Manager - Disp. only", "Manager - Change", etc.

How many roles will there be and do you need to create the same roles (or used derived roles) for different company codes, plants, purchasing orgs, etc? You might want to include an Organization indicator.

> "##" are a couple of characters to denote versions if necessary

99 versions of a role. Should be okay until the year 9999... (just joking)

> Please shoot holes in this and give us a solid working idea.

Tried my best.

Cheers,

Julius

[Former Member]

Hi Julius,

A few more points for clarification. This system is primarily a SCM system, where buyers/sellers/logistics people/etc. are able to log in and do what they need to do. When I say Internal vs. External, I mean company employees (or contractors working for the company) vs. suppliers, buyers, etc. for the company. The external users will use the system to provide their goods or to request goods and the external user community is going to be much larger than the internal community.

Another point is that the end users (external users) will have a designated person for each organization that can approve user id requests in the system. That approver will also have the ability to grant rights to the new user out of a subset of the profiles they are allowed to access.

With these things in mind, and keeping in mind the various components and any special requirements of each (ECC vs. Portal and their naming "rules") (EX. - I read somewhere you shouldn't use a "_" in the second position of a name. Is this true?), are there any other things we will run in to?

Thank you for all your input thusfar.

KC