So, how can you ensure that your investment on knowlegde (including intellectual property) is managed properly?
Change the way your organization considers knowledge production (with some practical help in the next few pages, of course).
It is a simple statement, but can it be done? Knowledge management in most organization is associated with endless projects and programmes, complex software- and sprawling budgets.
How do you convert this concept into something practical, without first dropping seemingly endless amounts of money into "knowledge management"?
Management vs. retention
Knowledge Management is quite often confused with its tools and methodologies.
Anyway, almost any system or organization works according to the "Garbage In-Garbage Out" (GIGO) principle.
GIGO? Usually, any transformation process does not improve the quality of its inputs- at best, it can keep the additional "background noise" introduced by the transformation process low.
Any tool that tries to build a general description of activities across the functional divide is based on a specific idea of how the organization should be structured- the "embedded company".
The typical tool assumes a specific reference set of accepted processes, results, and way to manage changes: we will define this set of assumptions the "Embedded Corporate Identity" (eCI).
ERP, CRM, and Knowledge Management tools share the same pitfall: unless you know already where you are, you risk that the tools will insert into your organization their own "Embedded Corporate Identity".
We suggest that Knowledge Management is introduced once you have already a working policy for collecting, structuring, distributing, maintaining knowledge: what we call "Knowledge Retention" (KR) policy.
Introducing knowledge retention: where are you now?
First, identify what is the current behaviour across your organization when it comes to knowledge retention: do not be surprised to find wide differences between organizational units, or inside organizational units.
"Scientific management" was originally based on sound knowledge of management practice.
The concept? Ease the training of managers without the need to start from the shop floor and rise up into management, as training was supposed to replace the experience.
With personal computers, the widespread use of computers tools like spreadsheets allowed to replace the transfer of "fuzzy" knowledge (people skills, etc) with a more structured and quantitative approach.
In reality, the 90s saw the sharp rise of spreadsheet-toting consultants, focused on quantifying everything, quite often discarding the unquantifiable as irrelevant.
Quantitative knowledge is fast and easy to replicate and communicate: successive generations of quantitative-focused managers and consultants increasingly drifted away from the business common sense.
Second, identify a set of qualitative parameters and some levels of compliance used to benchmark each organizational unit.
Third, using these parameters, a simple "radar" chart will become the basis for a brainstorming on possible initiatives to improve the status of each organizational unit, complementing the quantitative approach.
ISO9000 and knowledge
Another interesting trend in the 90s was to introduce ISO9000 certification, to a point where certification became a cost of staying in the business- as having a telephone or a fax line.
In late 90s, customers practically merged ISO9000 and Knowledge Management, for the sake of efficiency- but being ISO9000 reporting requirements a structured approach, this supposed efficiency had some unexpected side-effect on the actual collection and re-use of knowledge.
ISO9000 originally simply stated that you were going to be assessed vs. what you stated that would be your quality level- not vs. some "common" or “standard” quality level.
Often the knowledge producers became the “bottleneck”, as they were required to produce the same set of information for different destinations and formats- ISO9000, Knowledge Management, Methodology, etc.
Knowledge Management cannot work without Knowledge Retention, and is greatly enhanced by the use of tools to manage the processing of knowledge.
Knowledge Retention can be done without necessarily using any tool or setting up a Knowledge Management unit inside each part of your organization, provided that you identify the right target, or "public"..
Our approach is to identify for each customer how to better restructure knowledge at the production point, so that each item can be reused to be "published" for different publics.
Publishing: yet another concept that is quite often discussed along with Knowledge Management, and quite often distorted into a simple format conversion for each public.
Public and knowledge production
A knowledge production process has actually at least the following four steps:- First, produce
- Second, collect
- Third, distribute
- Fourth, update or prune
If you try to introduce a similar approach across the organization
While a technical approach to knowledge management sometimes could benefit from a "big bang", this usually produces just a technological implementation.
But who will maintain the processed knowledge stored inside the knowledge management system?
Certainly not the knowledge producer, as it will be completely different from the source.
Each document has (or should have) a destination public, i.e. an intended audience.
If you cannot define the audience, chances are that your document will not achieve the intended results.
But do you really need to write time and again the same item? The risk is that your knowledge producers will spend seven hours reporting in slightly different formats what they spent one hour doing.
Knowledge snippets and traceability
Two simple actions could simplify both the interaction with the "thesaurisation and compliance organizations" (e.g. methodology, quality assurance, knowledge management) and the knowledge production: writing "knowledge snippets" along with each item, and defining "building maps" for the basic documents to be generated by the knowledge producers.
Traceability is a simple concept, and it is more a matter of common sense than a complete new concept.
Simply, partition your document into "atomic" (i.e. not further divisible) items, and whenever producing an update, take note of which existing item you are updating.
As described in the "Methodology" section, the management of traceability is slightly more complex, but is built around this basic rule.
Not everyone is keen on documenting in a traceable way, or interested in restructuring the documents according to different sets of requirements.
The knowledge producers should retain control of the knowledge they originated, as they are the only ones able to update it in a meaningful way.
Obviously, this implies that the knowledge producers opearate according to your own rules- and this applies both to your own staff and any external suppliers.
As it will be discussed in a later issue, you can outsource/delegate the execution, but not the responsibility.
If you define clear "roadmaps" to assemble and store knowledge items, then the thesaurisation is just a by-product of your normal activities.
Then, the knowledge producers can delegate the actual collection and formalization to resources focused on those task, usually belonging to the "thesaurisation and compliance organizations".
Knowledge producers usually need to get through some trial-and-error before they can identify the proper size of the "knowledge snippets" for their processes, but there is a low-cost option.
Ask them to define "knowledge snippets" so that they can enforce traceability.
They should start by looking at their own business processes, and check what is the minimal traceable "knowledge snippet": probably the actual size and configuration of a meaningful knowledge snippet is different across the organization.
The knowledge side of downsizing
A common problem in any organization is that through downsizing, BPR, re-organization, outsourcing, probably you organization removed as much organizational redundancy as it was previously available, and therefore you have scarce if any cross-functional expertise left in-house.
This implies that quite often "knowledge configuration" (KC), where existing in-house knowledge components are re-used across the organization, is increasingly difficult, or it is delegated to external resources- who happen to be the only ones still working across the functional divide.
Using "knowledge snippets" along with traceability reduces the cost of knowledge production and retention (including its maintenance).
Also, this allows your organization to introduce "knowledge configuration management" (KCM), ensuring consistency of behaviour across the organization, also if you use delegate processes and activities to external resources.
KCM is linked to another concept: "versioning" of knowledge. The basic concept is that any item of knowledge depends from one or more other items, produced in the same or other organizational units.
Management + Costing
Once "Knowledge Configuration Management" is in place, quantitative analysis becomes again possible.
Obviously, the parameters need to be tailored to the specific categorisation of "knowledge snippets" that will have been negotiated with the knowledge producers.
Why introducing again the quantitative analysis?
Consider this as possible side effect, not a mandatory element of a “knowledge retention” policy.
Introducing quantitative analysis after adopting the new approach could be useful to actually share the costs of producing and maintaining a specific "knowledge snippet".
And it is not only useful for "Internal Transfer Pricing", but also when spinning out a unit or negotiating a joint venture.
Obviously, also if the demonstrated value or cost of an item is X, corporate policy realities could result in a lower transfer price, considering the balance as an additional element of overhead, paid by the organisation as a whole.
Management and participation
If you introduce Knowledge Management after Knowledge Retention and Traceability, the actual knowledge producers will be more active partners in the setting up and negotiation of the separation of roles and the organization of the infrastructure.
This increased participation will result in a greater control on the knowledge contents, as the knowledge management organizational unit will not be the only organizational structure in charge of all the knowledge management tasks.
If the Knowledge Management organization is in place before the rest of the organization is able to provide usable knowledge, the net result is usually an "ivory tower" approach.
Should this be the case, the Knowledge Management organization, for lack of contact with sources that understand its "lingo", starts generating knowledge and assumptions, instead of structuring knowledge produced by the actual Knowledge Providers.
In turn, this will give less incentive to the other organizational units to become part of a process that adds overhead but whose value (i.e. knowledge that can be extracted to be reused) is questionable.
Interestingly, some organizations that misused Knowledge Management tools and methodologies found themselves with an increase of the use of external consultancies, used by some organizational units as a way to circumvent rules that were applied only to internal knowledge production.
Knowledge Management based on Knowledge Retention also simplified the identification of "core" knowledge items, whose understanding should be kept inside your organization.
These "core" items are those relevant to ensure that any "outsourcing" activities do not reduce your own organization business continuity capabilities.
Knowledge and embedded security
Once the knowledge production is structured, it becomes easier to define a control/security policy, by assigning different level of access and responsibility to different organizational units.
A positive side effect of this definition is that identifying the "knowledge boundaries" for each organisational unit reduces the need of cross-functional meetings to those where the subject is new or clearly spans across "knowledge boundaries".
As each item becomes classified at its definition, it is possible to delegate without losing control: as will be discussed in a future issue, this will reduce the number of resources needed to cope with a larger number of projects, using external resources only when and for how long is really needed, and without any loss of knowledge.
As described above, adopting a sound Knowledge Management policy based on Knowledge
Retention makes investment on knowledge and knowledge costing possible.
Why the title of this issue links "knowledge retention" to "embedded security"?
Knowing which items of your knowledge base are "core" and should be maintained inside your organization ensures that you can improve your business continuity capabilities, also when delegating to third parties one or more processes.
What is "embedded security"?
Security is quite often considered an additional set of processes, almost an afterthought.
But this externalisation of security implies that you try to build up walls
(virtual or real), without actually involving who produces the knowledge and therefore should know its sensitivity.
Security (both physical and logical) does not come cheaply, and 100% security is unachievable.
Our concept of "embedded security" is quite simple: instead of adding security after your processes, try to focus on identifying who is responsible for a specific knowledge subset, and have them define the related security profile with your security experts.
Maybe, you will discover that some of the security can be "embedded" in the actual processes involved in producing the knowledge.
Some additional layers of security will just (expensively) increase the perceived security, while impeding the knowledge distribution that is needed to actually generate value.
Guidelines for action
All the basic items now clarified, how long would it take to achieve these results?
It depends on your expectations- and how you manage them.
As noted above, a "big bang" approach is possible if you focus on technology, but then maintaining the knowledge will be more expensive, as the producers will need constant help both to trace back and update the "thesaurised" knowledge.
In any change management activity, you need to change the behaviour of the knowledge producers.
A simple presentation is not enough to produce the change: you also need to reinforce the message with consistent actions.
We suggest a staged approach, using the results from the parameter-definition activities shown above to build up a schedule of intervention that could produce the first results in few months.
Lowering the expectations (better, managing them) implies identifying which organizational units could produce results faster.
Then, a "viral" model could be used to both improve your knowledge retention policy and spread the activity to other organizational units.
The "viral" model is used whenever you want to "evangelise" on a new process or technology:
identify a first structure with a high chance of success; once successful, this structure should "spread" to others, reinforcing the message: usually, the growth is not simply linear.
How do you operate?
Realistically, identify a homogeneous area to tune your approach on, and identify the actual "stakeholders" involved in the knowledge processes: production, collection, distribution, and maintenance.
This approach allows finding if there are any further organizational units that should be involved and to negotiate a process and the roles- e.g. organizational units that have already been assigned similar tasks, or that defined their own knowledge retention policies.
Finally, no knowledge retention policy should allow "loopholes", like using external resources to bypass standards.
The message to both internal and external resources is quite simple: you can delegate the execution of activities, not responsibility, and therefore any organizational unit using external resources should "price" the cost of converting the externally-generated knowledge in order to make it comply with
the internal rules.
Quite often, these additional costs will reduce or remove the economic viability of externalisation, at least for recurring activities.
Timeframe for delivery
A first project could usually take one-two months to assess the parameters and give an overview, using brainstorming sessions to identify the targets and the first organizational units to apply the process to.
The collection and first structuring, with the building of a reference catalogue, would probably take another four months.
Unless you have already a knowledge retention policy in place, the culture change management usually would require another six months, with oversight from either the first organizational unit carrying out all the activities, a new structure, external resources, or a team comprising a mix of resources from the three.
Thereafter, a "viral spreading" approach (like the one used in Business Intelligence and similar activities) is suggested to deploy the process across the organization.
As for the project team size, the initial team should be as small as possible, while a single resource should be in charge of the first catalogue building, to ensure consistency.
Once the first phase and second phase of the first project are carried out, and the working rules have been defined, the team could be expanded to activate parallel projects.
Closing
In conclusion, knowledge retention is not rocket science, and the benefits it can deliver are quite sensible.
Moreover, you can do it yourself. If you decide to use the information contained in this issue of BusinessFitnessMagazine, please let us know your results.
With different level of detail, this approach has been applied time and again, both internally and for customers across Europe.
As usual, use the information at your own risk and adapting anything you read to your own environment.
While we had consistent success in applying this approach, we cannot guarantee that it will work for your organization.
Good work!
|
Current issue