Portal success is always highly subjective. It is driven by how easy it is for someone to find and complete the task he or she wants to do within the portal and measured by gut reaction and level of adoption among users. A good user-centric design makes a compelling portal application.
| This tested and proven advice will help you to organize and manage your SAP Enterprise Portal content. |
Unfortunately, in my experience too many portals fail to meet their business objectives. With SAP Enterprise Portal (SAPEP) implementations, the most common problem is a lack of understanding of how to organize and manage portal content. This is often the most true at longtime SAP shops. The key to organizing and managing portal content is the SAP portal role.
I've used the following 16 best practices for planning and implementing portal roles with good results on many SAP EP implementations, and they apply to both SAP EP 5.0 and SAP EP 6.0. By following these best practices, you can realize the full business value of your portal and deliver a business solution your end users will truly welcome rather than fear.
- The number of portal roles and their definition should mirror the long-term scope of your portal. Failing to address how your portal content is organized in the end state will generate significant rework and lower the adoption rate when multiple phases of deployment are planned. The tendency is always to meet immediate needs rather than long-term objectives. Taking an existing portal and significantly changing its functional scope rarely works. Don't expect to design a portal that deals only with, for example, employee benefits and be able in the future to turn it into a single internally facing portal for your organization.
- Recognize how much attention you need to give to portal roles. If you intend to use SAP EP only to create point solutions, similar to simple standalone Web sites, the organization of portal content is designed once, and the amount of portal content remains relatively static. In this scenario, there is little need to focus on how to grow and manage your defined portal roles.
- As the volume of content available to a group of users gets very large, the desirability for a business user to simply search for what they are looking for, rather than navigate via the portal roles to it, dramatically increases (as does the cost of maintaining the portal roles). For large-scale portals, consider supplementing the use of portal roles with the SAP Knowledge Management (SAP KM) tools, especially the search tool TREX.
- The key success criterion for a portal role is driven by the business user's perception of what the role should contain and what content is actually embedded within the portal role.
- Portal roles provide the starting point for navigating portal content. For the end state scope of your portal, plan to assign no more than eight to 10 portal roles to a group of users. More than 10 roles typically force the user to scroll across the two portal navigation bars to find portal roles, a major irritant.
- With a Web site, the Web developer typically has full control over the semantics of how users navigate to content and the content itself (e.g., clicking on "Display customer quotation" delivers a similarly titled Web page). Portals aggregate and organize existing content (e.g., SAP R/3 transactions). It's important that the descriptions of the portal content within the portal role are consistent with each other rather than with the title of any actual content if this cannot be changed. Getting the user to the right content is your key consideration.
- The effort to develop portal roles should be 70 percent design and 30 percent building the portal roles. It's cheaper to get it right on the whiteboard! Use mock-ups and prototyping to test representative portal roles with real users before building the portal roles. Don't design a portal role with too many sublevels. Once a portal role structure goes beyond five levels deep, it becomes harder and harder for users to find what they want. Similarly, you should not typically have more than eight to 10 items at each sublevel of your portal role.
- Plan and design for growth and change. At a high level, you should know the number of portal roles needed in the final stage of your portal. Design each portal role only when you need to build and deploy it. Keep in mind that, as much as possible, the content structured in a particular portal role should be unique and not duplicated in other portal roles.
- Keep the overall number of portal roles as small as possible to keep the total cost of ownership low. For example, avoid creating business unit-specific roles.
- When designing a specific portal role, consider using, for example, lists within iViews, favorites-style iViews, and portal eventing functionality to help simplify portal role structures. The bigger or more "bushy" (the number of menu items available) a portal role becomes, the less likely that it is easy and intuitive for a user to find a specific item.
- You have several basic approaches to organizing the content within your portal roles. The most common is to use a functionality-driven structure - e.g., to create a contract within a sales role, you would click on "Sales," then "Order Management," and finally "Contracts" to find the item. This is intuitive, mirroring many business applications. Process-centric approaches - e.g., create requisition, approve requisition, or create purchase order - provide the preferred approach for users, but it can be difficult to implement processes with more than 12 key steps. For a large-scale internal SAP portal, it is often politically astute to use an organizationally driven model - e.g., business unit, finance department, accounts payable team - as the first two or three levels of your portal roles. At the lowest level of a portal role, sequencing content in a descending alphabetical order works well in single-language portals.
- Ensure that within each portal role the most frequently used items are the most quickly seen and accessible. The order of portal content must represent its relevance to the users who have access to the portal role. Making it quicker to display a credit memo than a sales order in your portal will generate a poor perception of your portal as a business tool.
- For a portal that uses content from SAP R/3, determine what relationship, if any, you want to establish with SAP R/3 authorization (security) roles. Remember that portal roles guide navigation only for the user. You can import SAP R/3 security information into SAP EP to provide some baseline structures for your portal roles. However, this does not negate the portal role design effort required unless you are using SAP EP as simply an expensive alternative to SAPGUI.
- Keep it simple. The technology for building portal roles is highly flexible and can be implemented in many ways. How you build your portal roles should ultimately be driven by the cost of maintaining them. Avoid embedding portal roles inside other portal roles, and limit your use of the delta link capabilities.
- In designing portal roles, the design effort should reflect the heterogeneous nature of the users to be assigned the portal role. For a highly targeted role - for example, accounts payable - it is reasonable to assume a common level of comfort with IT systems, a common understanding of relevant business terminology, and a relatively small volume of portal role content. This makes designing a portal role reasonably simple. For an organization-wide role such as benefits enrollment, expect to spend significant design and usability testing time to ensure acceptance from the boardroom to the shop floor.
- The biggest cost associated with portal roles is not in initial design and building of them, but with how they are managed long-term. The more portal roles you create, the bigger the maintenance overhead. The definition of each portal role should be clear and as much as possible enable each item of portal content to be found in only one portal role. Having the same content duplicated in multiple portal roles significantly increases the maintenance cost.
One final thought: I've dealt with considerations and best practice for organizing content within a single portal. Organizations may choose to deploy multiple portals to serve internal business users and customers and business partners. In all scenarios, it is imperative for long-term success to plan how you will organize content within your portals and have the governance put in place to deliver on this plan. Steve Dunne is a senior manager at Capgemini and leads its SAP NetWeaver practice on the west coast. Steve has been delivering SAP projects for the last 12 years and has been focused on portal projects for the last five years.
Read more...
Posts
