Most organisations will organise their knowledge library either through a Wikis or through a portal, whether this is a corporate Internet portal, or a team-based portal such as a SharePoint site.
A web portal is a web page or web site that functions as a point of access to information and knowledge on an Intranet or the World Wide Web. Corporate intranets became more popular as organisations started to realise that they could provide a simple route, via a web browser, to a library of company information and explicit knowledge. As the demand for the provision of portals grew, so too did the tools that the IT department could use to create and management content. Today it is not unusual for company employees to be able to publish direct to the company portal and portals are becoming more and more customised to the needs of individual users. Portals have also been seen as the way of integrating legacy applications in organisations, a situation which frequently occurs when one organisation is acquired by another.
Portals provide a simple route, via a web browser, to a variety of company information and explicit knowledge, and a consistent look and feel for users while providing them with access to the online resources they need. Portals can be set up at Community of Practice level as well, using tools like SharePoint. Some of the advantages of portals include
One problem with portals is that it can often be very difficult to add content to them. For well-established and mature processes, this is not a problem, as content will be only rarely be added or updated. However, for process knowledge that is dynamically evolving, it can be extremely useful to allow readers to comment on the documentation, or even to edit it, as new lessons are learned and new knowledge becomes available. This is where Wikis can add huge value.
When you are building your store of explicit knowledge for the organisation, you need to make it clear how much validity your documentation has. Knowledge comes in different levels of trust, and you need to make it clear to the reader what level applies to all documentation. There are three main levels;
1. Mandatory, or Must Do . This is the level of company standards, and everybody reading this particular process documentation needs to be very clear that they need to follow exactly what s written. If there is a major problem, they need to get in touch with the process owner and discuss it with them, but that the default should be to follow this documentation exactly.
2. Advisory, or Should Do . This is the level of best practices, and everybody reading this particular process documentation needs to be clear that this is the best way to approach this particular process, based on current company knowledge. However there is always the possibility to improve on best practice, and if somebody can find an even better way, then that s great. So Advisory process is advised, but not compulsory. However if people ignore advisory knowledge and things go wrong, some awkward questions may be asked.
3. Suggested, or Could Do . This is the level of good ideas or good practices that others in the organisation have used, which the reader should feel free to reuse or re-adapt to his or her own context. These good ideas can still save the reader a lot of time and effort, but there is no real requirement to copy them.
Contact us for more information
