I've spent a week with the new user interface: the NetWeaver Business Client.
NWBC Menus
One of the largest end-user gains from moving to the NWBC is the role-based menu. It provides all users with consistent access to applications in SAP. I can imagine this UI being very beneficial in turn-over scenarios for training new users. This is also a useful tool for users who are dissatisfied with remembering SAP transaction codes. And also a performance boost for general navigation, user to user.
Recommendation
Please read "Reasons to Use SAPgui" below. I advise editing role menus in-place as opposed to generating new roles for NWBC menus. I suggest using Design D: Department-first Application-quick Work Centers.
Technical Details of Role Menus
SAP menus are provided to a user via granted roles. Each role may or may not have a menu. Any menu that exists is shared between the SAPgui Easy Access "User" menu and the NWBC "Navigation" menu. An option exists that allow the role's entire menu structure to be hidden from one or both clients. Additionally, a role may be designated as a Home Role. When so chosen, this role becomes planted as the first item in the menu.
In the NWBC, the first level of the menu is called the Work Center and will appear in the top navigation tabs. First-level folders from all roles will appear in this Work Center row. For example, as a result of the combination of DISPLAY-GENERAL and CONFIG-MGR roles, the NWBC menu below is generated.
Folders at the same level in different SAP roles are merged into one menu. When two roles contain the same folder name, the menu is merged and child elements are displayed under a single menu item. Note: this merging feature does not happen in the SAPgui Easy Access menu, which is why it may be important to separate NWBC menu roles from Easy Access menu roles.
Options for Using NWBC
Approach #1: Big Bang
The approach that would result in the least amount of mid-term maintenance is to set a date for all users to begin using NWBC. A dedicated, focused effort on the part of IT would be required to reconfigure all existing role menus to fit into the NWBC menu design.
Approach #2: Role By Role
Alternatively, we could take a role-by-role approach to converting to NWBC. In this way, the role from which a user gains most of their access could be edited in-place. Some roles are shared. As such, supplementary NWBC menu roles will be necessary until all users of the shared role begin using the NWBC. A one-to-one shared role to NWBC role will be necessary in order to properly relate the menu to the new NWBC menu design.
NWBC Menu Designs
Design A: Department-first Work Centers
Level 1: Department
Level 2: Role
Level 3: Applications
This is a natural first step at putting order to list of menus and commands available to a user through granted roles. The problem is that this design still throws too much at the user at once. Our “General Display” role provides the user with transactions from many different functional areas. With so many work centers available at the top level, it is still too easy to get lost.
Design B: Role-first Work Centers
Level 1: Role
Level 2: All departments used by role
Level 3: Applications
This design essentially swaps the first and second level folders. For many users, this will greatly reduce the number of work centers. However for users who may have only the General Display and one or two supplementary roles, no "home" work center is available. The few tools they do need are then lost in the Tools work center.
Design C: Department-first Role-focused Work Centers
Level 1: Department, with general display role in a single Tools work center
Level 2: Role
Level 3: Applications
This design is similar to A, but here the user's role plays higher importance. In essence, the entire General Display role has been taken out of the Work Center level and placed beneath a work center titled Tools. This helps to remove the clutter of unnecessary applications from the user's main focus and job.
Design D: Department-first Application-quick Work Centers
Level 1: Department, with general display role in a single Tools work center
Level 2: Applications
This design came by way of advice from SAP that we should strive to keep our role menus no more than two levels deep (although it supports up to five levels). The design helps users get quickly to their most important applications.
Note: in both designs C and D, the Tools work center (general display role) is subdivided by Department (level 2) and then Applications (level 3). This is an acceptable compromise because the users most often accessed applications should be available from the explicitly assigned roles.
Reasons to Use SAPgui
(a.k.a. Reasons to Not Use NWBC)
With this change to the user interface comes a few items that some users may not like or may need time to get used to. Consider these differences when choosing how to proceed.
Screen real estate
The available program space is greatly diminished by the use of NetWeaver Business Client. With the menus displayed on the top and left of the shell, you're left with about 70% of the window space when compared with standard SAPgui. Some options are offered to help compensate for this.
- You may collapse the Navigation Panel (left-hand menu tree) when not needed or turn it off completely from the View menu. (Proposal: make the panel auto-hide after choosing an item.)
- You may turn off the Navigation Tabs (large buttons at the top). In this case, the user may use the bread-crumb menu that is always visible at the top of the screen.
The SAPgui Application Menu [More…] Button
Another change was made to help improve screen real estate that deserves its own heading. The SAPgui application menu has been reduced to a [More…] button. Upon click, a pop-up menu is displayed for navigation to application-specific commands. Were it me, I would have placed the entire NWBC menu under one menu item and moved the SAPgui menu to the top of the shell. These commands are too important to hide behind a cumbersome [More…] menu.
Menu Merge Sorting
A really nice feature of the NWBC menus is that when two roles or more roles are assigned to a user, common folder names at the same level are merged so that all children of the folder from both roles appear as one menu. The implementation of this folder merge is poor. I've seen a merged folder be thrown to the front of the list when I expected it at the end. I've seen it at the back of the list when I expected it at the beginning. And I've also seen it land somewhere in the middle. This sort cannot be influenced by the menu designer or modified by the end user.
Merging Menus of Home vs. non-Home Role
The home role checkbox may be chosen for any number of roles assigned to a user. When a single role is provided to a user containing a single top-level folder, the results are very nice. The home role stays planted at the left offering quick access to applications. If a secondary non-home role contains the same top-level folder name, but is not designated as a home role, then this "choice" may take precedence over the home role of the menu with which it is being merged.
Here you can see the DEVELOPER role is identified as the Home Role with a top-level folder 'IT'. When merged with two additional roles assigned to the same userid, the 'IT' work center lands at the end of the list, even though no other role anywhere is assigned as a Home Role for this user.
Window Snapping is Not Available
It doesn't "snap" to the window edge in Windows 7, as do (almost) all other Windows applications.