Judging from the number of articles, white papers and press releases concerning portal return on investment (ROI), we could easily fall into the trap of believing that once funding for a portal is secured, success is just a matter of time. However, portals do not work out of the box with any long-term ability to tackle real business problems. To succeed, enterprise information portals (EIPs) must be crafted to the particular processes of an organization. This means focusing on the issues that demand the time and attention of the end user. The first step in shifting the focus to a grass-roots-oriented development model is to recognize that one of the chief reasons EIPs fail to deliver is the lack of a compelling reason to use the portal.
We've all seen screen shots of portals with the latest news, corporate messages, calendars and a host of portlet utilities for tracking flight information and converting currencies. While these components are helpful, they do not drive users to the portal. They're welcome additions from a user's perspective because they offer information or services they occasionally need and can access from one place that place being where they go for core IT services. One type of gravity well that draws users to an EIP is an anchor application, such as business intelligence reporting, enterprise search, collaboration tools or document repositories. Siemens' widely publicized ShareNet portal provides professionals around the world with access to sales proposals and has been responsible for incremental sales in the hundreds of millions of dollars. That is compelling.
What constitutes an anchor application? Anchor applications support core business processes selling telecommunications equipment, researching market information, designing a new product, etc. Second, they provide a service not easily available elsewhere. Collaborating through a threaded discussion can be done asynchronously and without regard to geography, plus it has the added benefit of creating a record of the dialog that can be referenced at a later time. Project teams can share files through file systems, but Web access and better meta data support are key advantages to using a portal framework. Third, and perhaps most importantly, these applications aid users in their recurring tasks whether it is processing insurance claims, developing sales proposals or tracking production metrics.
To create an anchor application, designers need to observe and understand not only what users do, but how they do it. When Etienne Wenger observed insurance claims processors in his research on communities of practice, he discovered an elaborate system of processes and artifacts that enabled staff members to get their jobs done. We do not need to become anthropologists to design decent applications, but we need to understand what information people use in their work and how they interact with others. This can come from detailed observations over an extended period of time, which is impractical in most cases, or by following a grass-roots, bottom-up design methodology.
Portals, by their nature, require a standardized infrastructure; and that is best defined from a centralized, top-down perspective. Let IT decide on a portal vendor, search/categorization tools and collaboration systems; but let business drivers and staff needs determine the shape of the applications within the portal. CARE Canada, a non-governmental relief agency, took this approach and created a knowledge management portal that has delivered on expectations.
CARE Canada had to solve two problems. First, they needed to rapidly respond to natural disasters around the world using a range of repeatable processes. Manuals, procedures and other documentation had to be readily available to relief workers. In addition, much of the organization's expertise was in the form of tacit knowledge of experienced staff. Capturing that knowledge before the staff left was the second problem CARE Canada addressed. After selecting a portal that provided an easily navigated content repository and rich support for collaboration, and seeding the portal with basic content, the IT developers stepped back and let early adopters drive the evolution of the portal. The result was a strong sense of ownership by users and a viral adoption cycle that spread among relief workers who were finding the information and expertise they needed.
We can learn a couple of important lessons from well-adopted EIPs. Deploy to the true believers first. Keep it focused on staff that understand the potential for the portal and have pressing business needs. Find a business situation that is untenable: for example, the staff needs to follow procedures for a particular process but can't find documentation. In another case, a department might have accumulated too many custom reports over the years; and now some are unused, some are forgotten and/or many don't know they exist. Replace these with an ad hoc query tool.
Weave the tool into everyday work. A process that requires creating a document in Word, logging into a portal and then proceeding through a three-step wizard to add the document is too tedious a process to be widely adopted. Consider the mechanical process and watch for users saying, "There has to be a better way."
"Build it and they will come" is not a sound design strategy. A "let them build it" strategy is more likely to succeed.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access