Previously in this series of Knowledge Retention versus People Retention I’ve talked about Enabling the employees to become knowledge sources, How to find out where the knowledge is, Encouraging the employees to share their knowledge, Giving the employees the tools to share their knowledge, and Promoting the Knowledge Exchange.
Next up is the penultimate article in the series, Delivering the Knowledge to the employees. The organisation has spent the effort mapping, gathering and storing the knowledge, but how do we actually get this back to the employees, back to the learners in the organisation who need the knowledge? Strapping on a search engine to the Intranet is all very well, but that only works with specific searches, and the employees have to go to the knowledge that they already know they need.
Let’s talk about giving them the tools to pull knowledge to themselves, and knowledge that they might not even realise they need, and in the process the knowledge will be spread across the employees in the organisation instead of sitting with at key failure points.
Delivering the information…Email is a place where information gets lost, not delivered…
It’s not all about capturing and retaining the information though, the information flow also has to be enabled and channels created for the delivery of that knowledge to and from employees, not just to a storage system. There are many ways to look at this area but the first and most important one is to ensure that email is not used.
Employees are already deluged with information, lengthy emails sent with huge attachments, email conversations exploding into large groups resulting in numerous people being copied into email chains that are unimportant and carry their name through some historical requirement. Email is a place where information gets lost, not delivered.
Some more useful tools that can help that delivery of information are Instant Messaging, Feeds and Feed Aggregators.
Instant Messaging, or Team Messaging…
Instant Messaging is a term that scares organisations and should be used with care. The idea that any employees can contact any other employee and engage in an online chat is not the issue in itself, it’s the idea that all employees will be doing it at the same time, swamp the intranet and no work will get done. It’s a short sighted and quite ignorant viewpoint, but it has some validity in the early beginnings of an Instant Messaging implementation.
Like all these other collaborative systems they have to be left to the employees to develop and grow themselves, and sometimes the better thing to do is step back and let them grow at their own pace.
However this isn’t the view of many technology departments within large organisations, and the idea of Team Messaging appeals much more. This is where employees are restricted to viewing those who are within the teams they are working with, for example the projects they are currently assigned to. It would also allow employees to see the presence icons of those experts mentioned previously, and engage in a direct chat with them, should they allow it.
Suddenly the system becomes more manageable, more formal and less open to abuse in the eyes of the technology teams. Instant Messaging can work in the organisation after all.
The addition of an Instant, or Team, Messaging system allows for the instantaneous flow of information or knowledge from one employee to another, or a group of others. Using a tool like this ensures that information spreads throughout the organisation rather than simply moves from one point to another. Knowledge movement becomes much more informal and timely, and less stagnant and privately held.
Feeds are a vital form of knowledge movement. Simply creating a store of information and hoping that employees will return time and time again to keep themselves updated is not enough, they need to be told of updates and new information in a timely and targetted manner.
Feeds are commonplace on the Internet and a site without a feed is actually now deemed as a negative and a distinct disadvantage in their marketplace. The ability to send content direct to the readers or subscribers of the site is vital, not just sending all content either, but new and relevant to what they want to read. This should be exactly the same for any knowledge system.
A feed allows for all of this to happen. In it’s simplest form it is text listing of the latest information from your site which readers subscribe to. When new information is posted on the site the feed is updated, this passes directly to the reader, and they can read the update in their feed reader without visiting the site.
Of course the feed can contain any type of information from the site, for example latest news stories or the latest comments made, and they can include a snippet of the information to tease the reader to the site, or the full information to make it convenient for them to read.
Feeds push your content to the readers as and when the content goes live on the site, and so applying them to an organisation allows for your Intranet to be much more accessible. Instead of having stores of information and knowledge throughout the Intranet that sit there and stagnate, they can become information broadcast channels and employees can subscribe to watch them.
Here’s a very practical example. I read over two hundred sites a day, a mixture of information and knowledge on anything from weather to formula 1, from films to e-learning. To do this normally I’d have to visit each site, find the new content, and then read it before moving to the next site. With feeds I am immediately shown the content from only the new content on all these sites and it’s shown in one place, a feed aggregator.
There’s another use for the feeds, instead of pushing information from a knowledge store to employees, they can be used to push information from a knowledge store to an application, in a more technical way, this is a portal. The feed pushes the content to an application front end and displays it for the reader, therefore a simple web page could display various feeds from various different knowledge stores. This is a feed aggregator.
Feeds on their own are not very user friendly, and employees would find it hard to read them, so a feed aggregator makes the feeds readable and gathers them under one application in a single style and format. It can allow a reader to group them together under their own headings, sort them in different ways, and add and remove feeds as they desire.
In an organisation this could mean the removal of a complex maze of Intranet pages and the addition of a single employee home page. This would in essence be a feed reader which pulls in feeds from the knowledge stores, Internet sites applications that they subscribe to.
For example, you would expect two or three standard organisation news feeds to be there, along with feeds for any project blogs and wikis they are connected with, perhaps a feed or two from their common searches in the organisations LMS for keywords of learning interest, feeds from blogs or discussion groups that belong to experts whose knowledge they are interested in, etc.
Now the knowledge is flowing from the knowledge stores that have been created to retain the employees knowledge, to the employees themselves.
If the Social Network map was to be revisited now, the information flows would be much more focussed to the knowledge retention systems on the organisations Intranet rather than certain individuals, and the removal of knowledge experts from that map would have much less of an effect than before.
Knowledge is now being captured, retained and shared, and it flows through the organisation easily. A side affect of this is that the organisations Intranet would look very different.
Next up, for the final article in the series, I’ll talk about how this has the side affect of remodelling the organisation’s Intranet, from a bundle of websites without any real operational knowledge, to a project based, knowledge store in A new Intranet model