Enterprise KM

[Richard Veryard]

Picked up a tweet from John Hovell @klowey22

VPEC-T mindmap (values, policies, events, content, trust)...wondering
how we might apply to enterprise #km

---

My first thought was that a lot of enterprise knowledge management
focuses on Content.

> What knowledge do we have?

We then have to think about Events and Policies

> How does the knowledge get in? How does it get out again?
> How do we know which bits of knowledge are valid and relevant to a particular context?

But why doesn't this always work as well as it should? To answer this,
we have to consider how knowledge reflects different values and
beliefs across the enterprise, and above all how trust (and mistrust)
affects the willingness to share knowledge with co-workers. There is
an abstract topology of the organization, onto which we can map
different value systems and trust gradients. Understanding this will
help produce a more situated platform for knowledge management.

[Seabird]

I think KM is a very fertile ground for KM because it has so many
constituencies with quite divergent needs. So (as I usually do), I
shall start with a story.

I joined a new company in May this year. This company has an enormous
amount of documentation, discussion threads, program specs, iteration
definitions,... A whole pile of really interesting stuff. Since many
people create into this pile, they are automatically conditioned to
use it. So they are in there a lot.

Enter naive Chief Architect. I want to find stuff and find it quickly.
The trouble is I don't even know the language/vocabulary with which to
search it. I really needed the items tagged, "This would be really
handy for Chris when he joins..." so I could find them quickly. Of
course no one knows what that is, so there isn't a hope in hell.

So I am left to wade through the stuff. No classificaton scheme is
going to work - except maybe a tagging scheme, so I can tag stuff for
myself. However for the folks working in the products, they have what
they need. So it seems to work as a series of siloes, but trying to
manage across the siloes turns out to be as hard as managing anything
across the siloes. Of course I digress a bit! So coming back to the
VPEC-T question around KM, we do have some important questions to ask.

Starting with V:
What is the set of values the KM system is supposed to enable? Is it
for the developers to record the documentation? Is it to help a newbie
get up to speed? Is it to help 2nd level support in the middle of the
night? Is it to be the repository of policy? Is it to be, "Oh we had
better have one of these for compliance?" In other words what value is
the company expecting from its investment in KM?

Policy - I don't have a lot to say about Policy in the light of KM.
Doesn't seem to me to be very different from specifying Policy for
other kinds of systems. Maybe policies around information
representation, retention, access, etc.Does it need to be central,
comtrolled? Impacts of legislation. So for example a requirement might
be "Yes we have a Policy about informatuion retention."

Now the Events. In some ways the easy part - especially if we sort out
the V. But that's always the case. We can distinguish between the
Events that create content, and those that are used by subscribers for
some reason. In most KM systems, I would argue that it is very
important for subscribers to be able to register for Events to
themselves either when something changes or on some time frame. It is
therefore wiorth looking at the events that people use to put stuff
into the KM system itself (well that's not a terribly good way to look
at it - really look at the events which cause change in interesting
content) and the placement of those events on the appropriate queues
(input queues of various subscribers including the KM environment
itself.).

Content - That's the stuff you want people to know about. KM systems
typically habe too much Content and not enough organziation. So be
careful with what you decide to stiore. It must be manageable.

Trust - Again multi-sided. Trust of the information itself. Trust of
the author, trust in the process of auditing/vetting. Again many
facets to the issue. Trust that it won'r be abused. So proper setting
of Trust boundaries matters.

Anyhow, there's some grist to the mill.....

C

[Richard Veryard]

Chris has talked about the VPEC-T of the KM system. I think it's worth
relating this to the knowledge itself.

VALUES. What is (could be) the value of knowledge to the organization,
and to the people inside and outside the organization.

POLICIES. What are the policies for the creation, sharing and use of
knowledge? In what way should business decisions about the future be
driven by knowledge of the past and present? Does knowledge have an
expiry date, so that the organization is not trapped by its past?

EVENTS. Some knowledge comes from the processing (e.g. interpretation
and analysis) of information. Some knowledge comes from active
experimentation (trial and error). For example, a marketing department
sends out a mailshot with two explicit objectives: firstly to create
business, and secondly to create extra knowledge about customer
behaviour. (Perhaps the mailshots are produced in different colours,
in order to find out which colours are most effective in generating a
positive response.) Therefore the behaviour of the marketing
department is an important event in the creation of new knowledge.

CONTENT. As Chris points out, we need not only flat content but also
structure (tagging or metacontent).

TRUST. There are many reasons why an expert might hesitate before
putting her knowledge into a knowledge management system.

1. Concern that the organization might not continue need her expertise
in future
2. Concern that people might use the knowledge in inappropriate
contexts.
3. Concern that the knowledge might not work.

Thus we can use VPEC-T to think about the relationship between the
knowledge itself and the knowledge management system.

R

[j4ngis]

One might also consider VPEC-T from two different perspectives;
Producing & Consuming.
Walking through the VPEC-T system (as Richard did above) you can do
it from Producing Knowledge perspective and Consuming/using knowledge
perspective. And why not also from Knowledge Managers/Maintainer
perspective...

For example:
CONTENT:
Producing: How do we store/structure/knowledge making it retrievable?
How much should we store? In what formats?
Consuming: How do I find Knowledge? Where do i find knowledge? How
much is there? What is there?
Maintain: How do we re-refresh content? How do we weed out old? What
format to use? How to access content?

EVENTS:
Producing: When should we store knowledge? What triggers what to
store, when?
Consuming: What triggers to look for/retrieve K?
Maintain: When do we weed out? How do we trigger a refresh?

Possibly adding other "roles" involved....

[Richard Veryard]

j4ngis wants to look at this from the Knowledge Managers/Maintainer
perspective...

One of the questions here is whether the knowledge manager is actually
interested in the knowledge content per se, or focuses on oiling the
wheels. Like a librarian who never actually reads the books in the
library herself, merely organizes the catalogue and chases the overdue
books. Would we trust a librarian who didn't read books?

The knowledge manager or librarian acts as the custodian of the
knowledge-base or library. We TRUST the contents of the library, and
we TRUST the librarian to care (VALUES) about this - for example, if
an incorrect formula is discovered (EVENT) in a chemistry book, we
expect (POLICY) the librarian to glue the correction slip firmly over
the relevant page. And if a chemistry book is riddled with errors, we
expect the book to be withdrawn from the stacks.

[John Hovell]

first, thank you so much to the VPECT community for starting up this
dialog so quickly - that alone says alot to me. Second, as I respond
here, let me be the first to admit that I have zero experience in
VPECT so I am coming from the enterprise KM perspective here (and i
hope thats helpful). i'm picking up on the notion that VPECT seems to
be a method of framing 'problems' to better prepare 'solutions'... it
sounds like it will have a lot in common with km itself as well as
enterprise architecture and systems thinking/engineering...one might
even find similarities with applied strategic thinking... so, i
understand that i could walk through VPEC-T to frame the enterprise KM
problem, but honestly, i feel like we have a number of ways to
brainstorm and frame the km problem (knowledge audits, basic
situational analysis/awareness, etc.)...
like richard mentioned above, i think some kmers are interested in
'oiling the whels' as opposed to the content itself - which is what we
tend to call 'optimizing the flow of knowledge'.

so, allow me to take my first stab at walking through vpec-t with
regard to enterprise km

v - as with all of these elements, the value of km depends on the
situation of the organization. typically, i think you'll hear that km
is part of 'optimizing business performance' - i'm sure you've heard
this quote, but we reference it quite a bit in km, peter senge said
'the only sustainable competitive advantage is an organizations
ability to learn faster than its competition'. km and learning
(formal and especially informal) tend to work hand in hand to support
the vision/growth/success of the business

p - this is a very interesting element to me. i agree w seabird here,
i haven't seen a lot of km-related policies. the closest policies
tend to be IT Use agreements or communications policies, but they
aren't that close... i wonder if policy can (or needs to) be written
around how people create, transfer and retain their knowledge?

e - i think this is where all of the fun takes place. the obvious
events in enterprise km are mentoring, process mapping/improvement,
etc... when we say 'events' are we also allowed to consider
organizational events (such as new leadership or acquisitions) or
'outside' events (such as new legislation or industry changes)?

c - i happen to come from a web development background where we always
heard 'content is king', so this is another interesting element to
me. from my perspective, 'content' would be the knowledge itself and
this is an area that tends to cause a lot of confusion. this is
probably the most helpful quote i know in this area 'we know more than
we say, and we say more than we write/type'. so i guess content (i.e.
knowledge itself) is king here too :) the question for me at this
point here is 'what is the optimal balance (and amount of structure)
for connecting the right/best knowledge to the right/critical need(s)
at the right/optimal time'

t - well, trust is the magic sauce as we say, right? in km we talk
about trust all the time because it plays into enterprise communities
of practice, organizational network analysis, organizational
storytelling, social media, frankly, just about everything we try to
do. there are so many great books/posts/etc on 'trust' out there, so
i'm not exactly sure where to start the 'trust and km' conversation in
this post...

i feel like i have a lot more to add here, but i also feel like i've
gone past a reasonable post length :) i like the concept of applying
vpec-t to enterprise km and i'd love to see a list of other ways to
think through the 'problem definition' pieces of km. does vpec-t (or
any other method) intend to result in a pragmatic way to execute
continuous improvement? (which then reminds me of the quote 'if i had
60 minutes to solve a problem, i'd define the problem for 59 minutes
and execute for 1' that was einstein, right?)

so thats my first complete newbie attempt, please help me learn :)