Re: Identification of Potential Business Value #value

Douglas Weidner

What you have described is essentially something I designed for the US DoD in 1994.
It was to house their Business Process Re-engineering methodology, which a team of us BPR consultants had documented.

The question was how to publish it for wide distribution.

In 1994, a hard copy manual would have been the traditional solution.
But, to save trees and many other reasons such as frequent updates, and to start leveraging DoDs IT network, I suggested an approach we ultimately called a Knowledge Base. 
It was housed in a KBase Tool (Microsoft Access and Visual Basic 3.0 for those who know such s/ware). In those days, a KBase was definitely not a repository.

A methodology is analogous to a process, typically with a work breakdown structure (WBS).
Each WBS activity had a description and any number of attached (associated) objects.

These three components are essential and remain the main ingredients of today's granular, process-oriented KBases.

In 1995, DoD funded the development of a KM methodology, which was housed on the same tool (VB 5.0 by then).
That early KM Methodology was the core for the eventual KM Institute's KM Methodology.

As a KM Consultant, I later recommended the KBase use to the UN. 
But I recommended integration of CoPs, for which I coined an expression "Connect & Collect", where 'Collect' referenced the KBase content and 'Connect' referenced the CoP when the KBase content was inadequate or some K nugget (object) needed clarification.

The above history and the evolution of KBases is described more fully in a chapter in the book, 
Knowledge Management Matters - Words of Wisdom from Leading Practitioners, 2018
Where is KM going?  One Long-Term Knowledge Manager’s Perspectives on KM’s Roots by Chronological Stages 

If anyone would like a copy of my chapter, just ping me at: douglas.weidner@...

On Fri, Aug 23, 2019 at 10:49 AM tman9999@... [sikmleaders] <sikmleaders@...> wrote:

“My kingdom for a nail....”

Yes, context is everything when it comes to valuing knowledge assets and artifacts. Back in the early JIT days (Just In Time) a common shorthand for one its core concepts was “I want what I want when I want it.” KM thought-leader Larry Prusak quoted a modified version of this: “I know what I know when I know it.” Both are relevant here.

A knowledge worker may not even be aware of the value of a given artifact even when they are in the midst of doing something that ultimately requires or would benefit them in completing it. Only upon hitting the sticking point does the worker recognize the gap between the requirements of the task and their ability to execute it. “I want what I want when I want it.”

This points to an easy way of inventorying artifacts: figure out a way to map them to specific processes or tasks and activities within existing processes.

Example: Electrical utility workers are trained in the classroom and then in the field via a union guild model. Due to the evolution of electrical network equipment that naturally occurs over decades, it is impossible to train for a given procedure on every variation of the equipment that that procedure could be performed on. So the classroom training on changing an overload fuse on a 600KVA panel focuses on the current version of those panels. But in the field a worker may come across a decades old panel that appears roughly the same as the one they saw in the classroom, except for the fact that following the sequence of steps for working on a new panel will result in a catastrophic failure if that sequence is applied when working on an old panel.

One possible solution: your idea of smartphone video comes into play here. Simply have an experienced worker video the correct procedure and upload it to a repository that houses a collection of said field videos.

Of course this leads to two important challenges:
1. How to tag these mini-tutorials so they are easily surfaced when searched for (I want what I want when I want it).
2. How to alert the worker that a) a procedure modification is needed here; and b) there is an artifact available to help them.

I used the example of the electric utility field workers because about 12 years ago I was on a ride-along with one of them and witnessed this scenario first-hand. Fortunately the field worker I was with was a veteran lineman who knew all about the need for a different procedure on the old panel. As I watched over his shoulder while he was working on it he explained to me how it required a different set of steps and what would happen if someone tried to complete the task using the “normal” approach (it involved a big “boom”). Even thought smartphones were still just emerging, the notion of videoing the procedure for this odd-ball panel seemed like a no-brainer - if we could come up with solutions to the above two questions.

Based on the above story, I hope it gives you some ideas about how you might approach your challenge. Start by cherry-picking the easy-to-value artifacts and developing a way to address the above two questions as related to known, existing processes. Your challenge is to come up with a way of putting knowledge assets and artifacts “in the way of” the knowledge worker who is executing against a given known workflow or process. Solve this and you’ll be well on your way toward gaining insight and understanding as to the value of a given artifact or asset, as well as laying down the infrastructure that will be usable for artifacts that may not be so easily mapped to a given process or task.

Join to automatically receive all group messages.