Feature
posted 1 May 2000 in Volume 3 Issue 8
Mapping organisational
knowledge
Effective knowledge management constitutes more than simply providing
channels of communication to unstructured information. Marcus Blosch describes
the approach taken at DHL in developing a model-based knowledge resource, and
presents some practical ideas on how other organisations can adapt this
methodology.
Modern organisations realise that knowledge is their most important
asset, but one which, because it is generally intangible, is locked up in the
contents of the various documents of the organisation, its intranet and in the
experiences of individuals spread across the organisation. It is therefore
important that these organisations manage this asset in order to make the best
possible use of it. The biggest problem is in developing a clear methodology to
allow knowledge to be brought together and integrated into a coherent whole.
More is not
necessarily better
To date there has been a great deal of work done in developing
approaches to knowledge management that are essentially based on providing more
communication channels to individuals and existing information. So, for example,
the organisation may develop an electronic library that stores all the companies
documentation, formal, informal, project related and so on, and makes this
available over the Internet, with advanced search facilities, and via group
emails and chat rooms.
There is no doubt that these solutions are technically sophisticated and
eye-catching, and while they can be an important component in a knowledge
management approach, they do not constitute knowledge management per se.
Essentially, there are three problems with this approach. The first is that
managers at present complain of information overload, and this form of
initiative has a tendency to increase the overall time required for
communication, and the possibility of information overload increases. While
access to information is important, access to the right information is doubly
so.
In many
instances, information available via, for example, a portal is structured in a
library system, but only loosely in terms of the relationships between the
information contained. That is, although multiple items are available, their
context varies, and as a result it is not possible to fully understand or relate
individual elements. For instance, items may contain a considerable amount of
political ‘spin’ which is indiscernible to a reader unfamiliar with the area or
project in question. Using a piece of information without knowing this may cause
any number of problems.
Leading on from this point, individuals and groups within an
organisation often have very different world-views, or models of reality. The
classic example of this is the differences between the users and developers of a
system; users complain that developers never listen, while developers complain
that users never make a clear statement of their requirements. Research shows
that this is due to their different models of reality. Providing a portal or
access to information will not in any way resolve this issue.
What is required is the
ability to access the right information easily; information that is structured
in a coherent and consistent way so that the underlying model for it is common
across all items in the knowledge base. It is exactly these requirements that
the modelling approach to knowledge management aims to achieve.
A pragmatic
definition of knowledge
Within many fields there has been a
resurgence of pragmatism, particularly in the writings of Richard Rorty, Hilary
Putnam and Donald Davidson. Pragmatism is a philosophy of action that relates
truth and meaning to ‘purposeful action’ in the real world. Knowledge is located
in language, which contains our ‘model’ of reality. This model allows us to
explain the real world, predict outcomes and take action to achieve specific
outcomes. Pragmatism does not, however, recreate the split between the mind, on
one hand, and the real world, on the other. Rather, the real world and knowledge
about it arise mutually, rather like the foreground and background required to
recognise any object.
The models of reality contained in language are contingent and
evolutionary; as an individual learns and gains experience, the models become
more sophisticated and more accurate in their ability to explain reality and
achieve specific outcomes. These models are also to some extent socially
negotiated between groups of individuals, whether that constitutes an
organisation or a group within an organisation.
It is naturally possible to make the
distinction between tacit and explicit knowledge. Tacit knowledge is the largely
unconscious knowledge of experience, which an individual has but would not find
easy to explain. Explicit knowledge, or ‘recipe’ knowledge, relates to the ‘how
to’ knowledge that an individual has and can use to explain how specific
outcomes are achieved. On this basis a model-based approach to knowledge
management often focuses on models of the organisations explicit
knowledge.
A
framework for knowledge management
In order to manage a complex business
that has many different activities, the organisation needs to understand the
business processes being carried out, the timing and events that trigger and
drive these processes, the data and systems that underpin the processes, the
goals and reasons for carrying out the processes, the network of the processes,
and, finally, the people involved. DHL has chosen the Zachman framework as its
model to represent these aspects, which was defined by John Zachman, formally of
IBM, and was an attempt to capture all the important knowledge surrounding large
projects. (For more detailed information, see www.zifa.com). Essentially, this framework sets
out a number of related models that represent the organisation as a
whole.
In
essence, the framework leads to a set of models that are highly interconnected;
the benefit of the framework stems from both the models themselves and from
their relationships. The framework allows navigation between cells. So, for
example, it is possible to break a particular process down into great detail, to
look at the data and systems that support a particular task, the goals that the
task aims to fulfil, its associate business rules and so on.
The framework affords
individuals in the organisation the opportunity to take different ‘views’,
depending on which area they are interested in. As such, systems designers may
be interested in process and data requirements, while human resource managers
will be interested to see the competencies attached to procedures in order to
define training needs.
Unfortunately, John Zachman had little to say on the subject of what
should be modelled first, how it should be modelled, how relationships are
specified and what modelling techniques should be used. DHL spent a considerable
amount of time defining these models and their relationships. Few organisations
have the luxury of being able to undertake modelling projects purely for the
sake of generating models.
Generating the knowledge
base
Important documents, in terms of setting the context of any modelling
work undertaken, are at row one in the framework, ‘scope’. For DHL, this
primarily consisted of statements of business and IT strategy as found in the
organisation’s five-year plan. These statements should also contain particular
performance targets, which form the row one level of the goal column. The link
between the process column and the goal column reveals which processes realise
which goals.
The
main driver for model development has been the use of process models in change
and re-engineering projects. Typically, the company’s strategy has called for
change in certain areas, which has led to projects being run to perform the
analysis, design and implement the change. These projects have not, as is
typical with pure re-engineering projects, been driven from senior management,
except in providing the support and scope for the project.
The projects have been run with the
experts in a particular area, typically supervisors, working in conjunction with
the project team. This has an obvious advantage, in that these individuals know
the process in greater detail, and bring their knowledge and experience to bear
on the problem at hand – they incorporate their tacit knowledge. A second
benefit of such an approach is that the change is defined largely by those who
will eventually be responsible for implementing and working with the
developments in their local setting, thus involving and committing them to the
project.
There
are a number of distinct advantages in using process maps. Firstly, they are a
diagrammatic representation of what is happening in an organisation; they
attempt to show an abstraction of what actually is going on. Secondly, they
capture knowledge from a wide range of individuals across the organisation in a
consistent and coherent way, and thirdly, process maps form the basis of
innovation. A key part of innovation is knowing what is done now, and then being
able to improve it. For example, if the key aspect of a process is time, then
the process maps can be used to see which activities take the most time and
whether a ‘critical path’ exists. The process map may then be used to
re-organise the process to reduce the time taken.
The project manager would organise a
series of workshops with nominated individuals to develop the process models.
The process modelling approach used within DHL utilised a small set of symbols
in developing the process maps, in order to ensure that the focus remained on
the task at hand rather than on the intricacies of the model. Essentially the
models are built up from two symbols, one representing an activity box (that
what is done), the other a decision box (yes or no).
Using these two symbols, it is
possible to show quite complex business processes (the decision boxes define
breaks in the flow and any logic for the decision is contained in the activity
box that precedes it). More complex modelling approaches can be employed, such
as IDEF (see www.idef.com), but as mentioned above, this tends to distract from
the modelling process.
A map attempting to show the whole business process in detail, from end
to end, would be extremely large. In order to make it more manageable, it is
levelled:
There is no doubt that levelling is to some extent subjective, but the
main thing is to ensure that it is meaningful and consistent with other models.
Another important aspect of process maps is the ‘swim lanes’, or ‘roles’. It is
possible to use organisational units to represent roles, if these are common and
stable across the organisation (such as finance, marketing and the like).
However, in the case of DHL these vary from country to country, due to diverse
local requirements, and as a result, generic roles are used.
For each procedure, at
the very least a description, scope, and business rules are defined. For each
task and step, a description, inputs (such as information read from a computer
screen or a report) and outputs (such as reports generated, data entered into
systems) are recorded. From these models it is possible to make linkages to show
which data elements, systems used, and goals being realised, link to other
processes.
Another important type of model to the organisation is the data model.
Logically, the corporate data model represents all the data contained within DHL
as a whole. This is mapped to various physical models and a current systems
model that shows which systems utilise which data elements. The techniques and
approaches of data modelling are to a large part standard within the IT
industry, and have been followed within DHL.
As projects run, new models are added
to the knowledge base and are linked with existing models. Currently, DHL’s
inventory of models covers the majority of functional areas. These models cannot
be seen as static, one-off developments. Rather, they are constantly being
updated as different projects run. New information is constantly being
integrated into the model resource. These are some example of the uses for the
integrated business model.
- Systems development. The main contention of this model-based approach to
knowledge management is that the business architecture should drive the
technical architecture. No doubt there needs to be a marriage of the two,
particularly in terms of taking advantage of the opportunities offered by
information technology.
- It is possible for system designers to use the model to understand the
business processes of interest at a low level, in particular the data usage
and the business rules that guide the process. From this, the functional and
non-functional requirements of the system can be generated, for example by
using the UML notation and generating ‘use cases’ from tasks and steps (see
also www.omg.org). Any changes to the
existing data models, systems models, networks or business processes can be
fed back into the overall model.
- Impact analysis. The knowledge base represents a set of inter-related
models. This allows any changes to be traced through the organisation as a
whole. For example, it may be required as a result of customer service
research to change the business rules surrounding a particular service offered
by the organisation. It is possible to see which business processes across the
organisation, and by implication which data and systems, will be affected by
such a change. On this basis it will be possible to make a full evaluation of
the impact of the development.
- Process costing. It is possible at the task level to identify various cost drivers, such as manpower, materials and so on, and assign costs to these. Over the business process and its related areas, it is then possible to sum the costs incurred by that business process. It is also possible to use the processes as a basis for activity-based costing. This allows processes to be costed, which is of particular interest when evaluating change.
These are just some of the ways in which the knowledge base may be used,
and in most cases the way it is used will depend upon the particular interest of
the person accessing it. The most important thing is that the models are easily
accessible to those wishing to use them, and that new models and any changes are
fed back into the inventory of the existing models.
The models in the knowledge base add
value to the organisation when they are utilised, and as such, providing access
is of great importance; to do so is to provide a window into the organisation.
Naturally, at the moment the most important way of presenting the models to the
organisation is by putting them on the intranet and making them accessible to
everyone. This must be done in a way that easily facilitates the linkage of the
various models in a user-friendly way, so that the user has a clear a point of
entry and can navigate as required.
Finally, in order to extract the
greatest value from the models, individuals need to be made aware of their
existence and be encouraged to use them. In this sense, even though a model may
be ‘owned’ by a specific area, which has responsibility for maintaining the
model, each model is made accessible to all the individuals across the
organisation.
Conclusion
The process-based approach to KM has provided our organisation with a
consistent and coherent approach to knowledge management. It also offers
individuals key information in their understanding of the organisation and
allows them to take purposive action to bring about and communicate change.
The development
of such a resource does involve a considerable effort, but it may be done as
part of each new project so that the models are built up over time. The initial
analysis and development of a model resource may be done at a high level,
allowing subsequent work to be slotted in underneath. It is important to
remember that any models developed are not static, rather they are dynamic and
can, and indeed should, change over time as the business develops.
Providing access and
encouraging use are of great importance. The development of the corporate portal
and the provision of access via the intranet are crucial mechanisms in the
delivery of the models to the organisation as a whole. This may be done in
conjunction with other sources of information, such as document archives. It is
important that the models be used as a common mechanism of communication and
management, and that the business is managed through them; ultimately, they
become a huge asset to the organisation.
Marcus Blosch is a business
modeller at DHL. He can be contacted at:mblosch@lhr-sys.dhl.com
denotes premium content | Jun 18 2013 



