exact  any/all
  The original knowledge-management publication
denotes premium content | May 23 2013 

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:

  • The process map represents a part of the business process.
  • The process map is made up of procedures, which relate to the logical grouping of tasks. For instance, ‘check in clearance paperwork’.
  • A task is the basic unit of activity, and is logically complete. In other words, it is it is done by one person, at one time, in one place. For ‘check in paperwork’, an individual task may be ‘sort paperwork’.
  • The task itself is often made up of smaller steps. So for sort paperwork, these may be 1) identify the split code, 2) place paperwork in the correct tray, and so on.


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


Follow us on:


Copyright ©2013 Wilmington Publishing & Information Ltd 2010, a division of the Wilmington Group PLC. Wilmington Publishing & Information Ltd is a company registered in England & Wales with company number 03368442 GB. Registered office: 19 - 21 Christopher Street, London EC2A 2BS. VAT NO.GB 899 3725 51