As many of you were referring to what the "Big Six" are doing, I though
I'd chime in and tell what I have been working on in my role as Senior
Methodologist at Andersen Consulting. (By the way, Andersen Consulting is
an SBU of Arthur Andersen & Co., S.C., which has another SBU, which is the
accounting and tax part called "Arthur Andersen". So technically, we are
not part of the "Big Six". People from Arthur Andersen are also doing
quite a bit about knowledge databases, but they can speak for themselves.
Anyway, with the obligatory legal disclaimer out of the way, back to the
topic at hand ...)
As my father was fond of saying: "All of you are right". For me (being
involved in several world-wide efforts relating to methodology (as a key
knowledge asset of Andersen Consulting) and other learning organization
initiatives), the key is to distinguish the different kinds of knowledge
(awkward phrase, but still ...), the different kinds of roles people play
in which they (might) need the various kinds of knowledge and how they
want to "access" that knowledge.
First, the different kinds of knowledge. We have come up with a "taxonomy
of knowledge" (ranging from "individual knowledge 'residing' in
individuals" to very explicit knowledge such as methodology 'residing' in
binders and knowledge bases and encompassing processes, training and
productivity tools). Different kinds of knowledge 'reside' in different
places (some does not reside anywhere, it emerges from bringing different
people together working on a project), they need to represented
differently, they need to be communicated differently, they may require
more or less support in terms of training and/or tools. In my view, any
corporate/organization-wide/large/... knowledge database support must take
into account and support (in very different ways) these different kinds of
knowledge.
But, it gets more complicated. I'll restrict my comments to explicit
knowledge here, because I have actually done work on it. I am currently
slowly easing into more tacit kinds of knowledge. It turns out, which
aspects of knowledge people want, and in which level of detail, and the
like, depends on the task(s) that people are actually trying to
accomplish. Along, these lines I have distinguished different subtypes of
(explicit) methodology knowledge to cater to different kinds of "users."
This is a first, at least with regard to methodology knowledge.
Heretofore, nobody had thought of methodology information as having
different aspects, views and levels of detail, dependent on what a "user"
is trying to do, whereas that kind of information is very much common
practice in the traditional information systems development practice.
(Maybe a cobbler's children problem here ...)
Third, it turns out that the "non-functional" aspects of knowledge are
equally important to its actual "use." For example, how fast can people
"access" it, on what medium, how easy is it to search/find stuff, how
readable is it once you find it, where can they go if they have questions
(which they invariably do), etc.? This is, again, of course, not new
relative to any kind of system building, but it needs to be done, and is
quite possibly even more important than ever (more and more information to
choose from, 20-second attention span, expectations of using software
successfully immediately, it has to be fun, ...). I have done Quality
Function Deployment-like things in Requirements Analysis to try to get
these things as clear as possible early on.
I presented a paper on the second and third point at the Workshop on
Information Technology and Systems of the International Conference on
Information Systems in Vancouver December 1994. We are still working on
the taxonomy (and, more importantly, its implications).
-- Gezinus J. Hidding, Ph.D. Senior Methodologist Andersen Consulting ghidding@andersen.com