Best practice for using adding menus to roles |
 |
EXPERT RESPONSE FROM: Steven Fullbright
|
|
|
|
| > |
QUESTION POSED ON: 17 June 2003
What is the best practice for using adding menus to roles while keeping
ongoing maintenance to a minimum? For example, our sales user base
consists of 15 - 20 distinct roles, most of whom will want to see the exact
same user menu. Do we create an empty role containing the menu and include
it in all the roles? Do we maintain the menu in each of the roles?
Did SAP intend for each user to have exactly one role? Or, was it expected
to have a combination of roles such as "Sales update + Finance display + MM
display"?
I'm a developer and functional person and I'm not very strong on the security
side. We are upgrading from 3.1 to 4.7 and have been shown very little
with regard to how have some standard menu paths for our custom Z
transactions across various user groups. Any suggestions would be greatly appreciated.
|
|
| > |
This is really a great question and I appreciate you asking it. I like to
think of myself somewhat of an menu-navigation evangelist when it comes to
these issues. Here our my abridged thoughts (I could go on for hours on
this)... first thing first: are you going to use SAP's Enterprise portal
products? This could alter your design and approach. Lets assume not and I will save that lengthy discussion for another day (it is somewhat of
an enigma). I believe that your organization's employee size and user base
will ultimately dicate what role approach you use for security.
If you are a small organization (I am assuming you are since you're a
developer doing security) with consistent job structures and fewer than
3,000 users (and unlikely to grow significantly), you should consider using
a "JOB-ROLE" approach. In the "JOB-ROLE" approach you would identify all
of the appropriate transactions and reports for a specific job function
(functionally, we'll worry about organization later), you would then work
through the tireless and glory-less process of documenting authorizations,
updating USOBT correctly (I don't care what SAP says, this is the right
thing to do), and working with the process teams to ensure the role
accomplishes all of the users job functions. From a menu perspective, you
will want to specifically nail down a common and consistent structure of
menu nodes that flows in a user-centric fashion. This structure (in my
opinion) should relate to the business process that the user is trying to
work through; it should also be as simple as possible (I never try to bury
more than four nodes in any one node); don't try to make the menu extremely
deep or complicated. If that is your intention, you should just use the SAP
standard menus.
You will want to start your top node with something like "Finance" or
"Accounting", make sure that these top nodes over a business process are
always the same despite the JOB-ROLE they may be in. (Quick-Tip: You can
control the way the menus behave through the SSM_CUST table. There are a
number of OSS notes on it) The rational for this statement, is if you
should ever assign two job roles to the same user or two derived roles
from the same JOB-ROLE to the same users (assuming you have the correct
parameters in the SSM_CUST table), SAP will dynamically consolidate the
menus and minimize duplicate nodes. After this laborous process you should
make derived roles off of your all encompassing JOB-ROLES and only maintain
the menu at the Model - JOB-ROLE level.
I personally would not create an empty role with only a menu since that
would create dual maintenance and authorization inconsistencies for you.
Similarly, the "TASK-ROLE" approach which is commonly used for larger
organizations with many diverse job functions would prescribe to the same
menu approach. The "Task-Role" typically incorporates the transactions and
reports necessary to perform the tasks within a business process, ie..
Close the GL Books, or Process Payroll.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
