Adding Process Knowledge to the KM Mix
I’ve been thinking a lot about the (possibly) outdated concept of knowledge management as I do a bit of work with a client to help define a KM strategy. The twitterverse has given me some excellent resources on the debate about whether KM is dead, none better than a video unearthed by Helen Nicol. In it, KM gurus Larry Prusak and David Snowden debate whether KM is simply another management fad or, despite the trend towards social computing, it has a future. Rather than paraphrase the summary provided by Twitter pal Chris Jones or the video itself, I suggest you check it out on here.
My opinion: the core concepts of KM apply now as much as they ever did regardless of how they are applied in the enterprise. The term KM may be going out of style but the concepts are valid.
To that end I’ve been thinking about how knowledge embedded in business processes is perhaps the best way to realize the seemingly limitless promise of KM. To me, a successful “process knowledge” scenario might look something like this:
Organization X has a resonably well defined set of engineering standards but not everyone knows about them (and therefore not everyone follows them) nor is the process for providing feedback on the standards well understood. This has led to variations in engineering design processes which have impacted how quickly the organization is able to complete engineering projects. In this economy this is obviously a situation they would like to correct.
The organization agrees to undertake a project to surface these standards through their intranet linked back to their source location in their enterprise document management repository. The goal is to ensure that everyone in the company knows where to find the standards by either browsing or searching. Once in the intranet workspace, users find clear instructions about how to provide feedback on current standards, request updates or ask questions. The business owner of the standards (or her team) may either respond to questions on a threaded discussion and/or she might blog about ongoing updates and revisions to the standards.
Anyone new to the company can find the workspace on the intranet just by poking around but if they can’t (or choose not to) their colleagues will point them there because “that’s the way we do things around here”. The owner of the standards and her team will also hold regular face to face meetings with key stakeholders to discuss change requests and to communicate best practices. Meeting schedules, agendas and outcomes would be posted to the site for all to see, comment on and possibly even update (perhaps in a wiki). This community would be related to other communities that deal with other aspects of the engineering and operations function within the organization.
To this point, none of what I’ve talked about is particularly new or radical. It is the definition of a classic Community of Practice that many, if not most, KM initiatives will implement. The extension of the CoP is that the business process for creating, maintaining and distributing standards no longer relies on the knowledge with one person (or group) to succeed. When the owner of the engineering standard moves on the process not only survives, it thrives. When new people join the company they are brought up to speed quicker. When new ideas occur or when new requirements are identified the organization is able to respond quickly. And all of this capacity is embedded in the business process, not the person.
It is important to understand that implementing such a process will be an evolutionary change and that these projects will have successes and failures along the way. The tools choosen to enable the development and propagation of process knowledge are largely irrelevant but will guide what the organization is able to do and their areas of focus. If the application isn’t “ATM simple” people simply won’t use it.