Note: groups.io will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
toggle quoted messageShow quoted text
My suggestion is much more complex, but has the benefit of being more organic in identifying SMEs within an overall KM system. I led the implementation of this at GE Healthcare during our KMS redevelopment.
I called the approach "pollen", because knowledge sticks. The idea is that a KM portal should return search results at three levels:
1. Appropriate people based on search terms
2. Appropriate projects
3. Source data / reports, etc
The idea being that most people would rather talk to another human being first, then find a project doing the thing of interest, before only as a last resort turning to the source material to figure it out themselves. The way you organically derive this is as follows:
- Search history within your KM portal sticks to a user; i.e. the terms/metadata of what they regularly search for and download builds up;
- If there are projects, i.e. if your KM system supports aggregation of information and primary research into a project, then the project derives metadata from the information associated with it, and users associated with a project build up metadata terms derived from that project.
Essentially, this means that no user needs to manage their own knowledge profile, and it can be assumed that the metadata is self-reinforcing. It also means that, as people and projects change over time, the metadata can change as well (deliberately deprioritising / prioritising metadata based on date/age).
This has to be built into the knowledge management system. It is not particularly complex from a software perspective, but it does require buy-in of the entire organisation, and - obviously - a budget to implement it.
If anyone is interested, I'm happy to discuss further how this is done and how you apply it to your specific software stack.