Enterprise Portal - How, How Much, and Why?
- Dr. Moria Levy

- Mar 1, 2003
- 2 min read

For over two years now, in Israel, the portal topic has been one of the hottest subjects in knowledge management, specifically, and information systems in general. People talk, build, engage, and even argue about who's responsible. Yet, the number of successes is not impressive. There are several portals in production, but few that serve as examples and models. ROI - don't even mention it.
Recently, with the increasingly strong coupling between knowledge management and business processes in organizations and the execution of knowledge management-focused projects, the portal question has emerged.
Portal for what?
After all, a portal is a tool whose main purpose is to aggregate data, information, and knowledge from other systems. Usually, it's not responsible for producing and managing new content that wasn't managed in other systems. The question of need and viability intensifies in light of all the promises that the portal is the "miracle" of knowledge management. The solution is simple. Information systems (operational, managerial, and document systems) are not lacking. Moreover, organization employees don't make sufficient use of them. It's precisely the portal that can promote their usage.
And how?
Through context-dependent integration of parts from different systems (usually at the window and screen level). The user, who is hesitant or sometimes lacks time (and perhaps even knowledge and patience) to open each system separately, can have a relevant status picture before their eyes that combines information from different systems according to their needs. However, for the context to be relevant, it must be smart. You can't just randomly aggregate screens, documents, and window parts. A process analysis must be performed that traces the business processes of the knowledge worker and analyzes their data, information, and knowledge needs within each of these processes. For them, and only for them, should portal screens be established.
And how much?
The collection of business processes of different knowledge workers is (almost) infinite. That's why it's so difficult to start. That's why they always fled to the common denominator. But there's no need to provide a solution for all processes at once. Even Rome wasn't built in a day. Implementation can be carried out gradually.
Here's a proposal for a possible implementation approach:
Choose several main knowledge groups for which you want to provide an initial solution.
Select from them a group where reducing data, information, and knowledge gaps is a central factor for improving the achievement of business/organizational goals.
Analyze their main business/organizational processes and diagnose the data, information, and knowledge that assist them in performing their activities.
Define the systems that support the management of the aforementioned data, information, and knowledge.
Examine the feasibility of integrating these systems (at least most of them) in the portal. Remember that technology doesn't always allow for this to be done with reasonable effort.
Characterize the windows that will be integrated and support the business processes.
Develop the links and adaptations in the portal.
Implement and reap success.
So good luck!




Comments