Assessing, Creating and Sustaining Knowledge Culture in Organisations
Peter Troxler and Kristina Lauche
This chapter is based on five examples from our research and consultancy experience in knowledge intensive organisations, both from the public and the private sector. We use these examples to illustrate a framework of Knowledge Management and Knowledge Culture. The framework is based on the theory of socio-technical systems. We applied this framework in the five examples to assess the problems related to Knowledge Management. For each example we discuss how the results of these analyses helped to develop and maintain a Knowledge Culture. We highlight the similarities and differences of the five examples. The chapter concludes with some thoughts on how organisations can assess, create and sustain a Knowledge Culture based on this socio-technical framework.
What Is the Problem, Where Does It Hurt?
A manufacturer of specialist, high precision milling machines had just acquired another milling machine manufacturer to extend their product range into less specialist markets. The brief they gave us when we started to work with them was immediately related to knowledge management: they wanted us to suggest a way how they could best integrate the engineering documentation of both product lines into one document management system. But the initial interviews already revealed, that this was not really the problem. In fact some of the designers already had a pretty obvious solution in mind. But not everybody agreed with this it. We wondered what the reason could be.
A service department of a local government were about to implement "New Public Management", an approach to manage departments by giving them a defined amount of money and holding them accountable for service quality rather by allocating detailed resource budgets and controlling resource spend. Our job was to help them define appropriate performance indicators for service quality. To do so we needed to understand the type of their services and how the department actually worked. We learnt that they offered a wide range of personal services, from very general to highly personalised ones. But to our and their surprise they had just one single way to deliver these services: one-to-one consultancy meetings.
The optimisation department of a large service provider had implemented an extensive, database driven system to describe their own processes, to capture, store and retrieve lessons learnt from past projects, and to relate these lessons to the process description. The department was relatively small and apart from a small, centralized support team its members were dispersed worldwide. After a couple of years they wanted to know how they were doing and how they could improve their system. We carried out a number of analyses. One important result was that despite the considerable investment that went into building the system, people used it only sparsely and complained about a number of issues.
Employees in a department of a healthcare organisation were looking at ways how they could improve their quality of care. They found that they could learn a lot from mishaps. So they set up a system so that people could voluntarily report mishaps anonymously. Periodically the head of the department would read through all the reports and select outstanding ones to analyse with the group and discuss ways to prevent the same issue to happen again. After several months of convincing people to contribute this system was working very well. The head of department, however, felt that there must be a way to gain more insight from these reports, and we were asked to analyse their system.
One branch of an engineering company lost an international engineering project to another company. The alarming surprise was that the competitor bid for half the price, without selling their performance under value. So this branch decided, after many years of implementing information and document management systems, to follow other subsidiaries of the company and to create Communities of Practice. The number of communities rose quickly to over twenty, with topics ranging from electrical engineering to human resources, from performance management to "new graduates". After six months we carried out a review of their efforts as part of one of our research programs. We evaluated how the employees and the champions who were in charge of the communities felt about the initiative and what their attitude was towards Knowledge Management.
Analysis of the Problem -- A Framework
These five examples differ in many aspects. Yet they do have a couple of things in common. All the examples are knowledge-intensive businesses. In all the examples organisational culture played a major role. Thus, in all five examples, we were able to use the same theoretical framework to support our analysis of knowledge management and how culture influences its success. The framework builds on the theory of socio-technical systems, see e.g. (Coakes, Willis, & Clarke, 2002; Emery, 1959; Emery & Trist, 1960, 1965, 1973; Miller & Rice, 1967; Rice, 1958, 1963; Trist, 1981; Trist & Bamforth, 1951; Troxler, 1999; Troxler & Lauche, 2003).
The theory of socio-technical systems conceptualises organisations as structurally composed of two distinct subsystems: the technical subsystem and the social subsystem. These two subsystems are built around the primary process (or task) of the organisation. The social subsystem comprises all human elements -- i.e. the people, their attitudes, values, norms, histories, competencies and behaviours. The technical subsystem is made up of human artefacts such as physical structures, buildings and other pieces of technology. For our purposes, we add a third structural element to the description of a socio-technical system: the management subsystem (Troxler, 1999; Ulich, 1997, 1998). It consists of the formal and informal policies, strategies and procedures, traditions and institutions, i.e. the formal and informal organisation of the system.
A socio-technical system is structurally composed of distinct subsystems: the social subsystem, the technical subsystem, and the management subsystem. They interact to fulfil the purpose of the system through the primary process and the support processes. The social and technical subsystems are also connected by the roles of people and the functions the technical subsystem provides.
The technical and the social subsystems are in multiple interactions:
1. They interact to fulfil the purpose the system is built for -- they make the primary process of the system happen.
2. They are directly interrelated through functions and roles. The members of the social subsystem fill different roles, whereas the technical subsystem provides the necessary functions. This, in fact, is the most important and probably the most complex distinction between the social and the technical subsystem.
3. The two subsystems rely on support processes that make sure the primary process can take place.
4. They are subject to a management process that steers the whole system to ensure it achieves its goals.
5. The technical and social subsystems are linked by the formal and informal organisation of the system.
The theory of socio-technical systems is a useful framework to analyse and design various aspects of an organisation. E.g. it helps to understand how organisations manage their knowledge and particularly what role the culture within an organisation plays to foster or hinder knowledge management.
In a knowledge-based organisation, the application of knowledge will play an important part in the primary process. In fact, the primary process will rely heavily on "knowing" (Polanyi, 1958): knowing about the technology and use of milling machines, knowing about the services and their delivery in the local government department, knowing about the optimisation of services and the critical issues involved, knowing about the practical provision of healthcare to patients, or knowing about the various aspects of international engineering projects. Knowledge management has to address this process of knowing.
Knowledge can also be seen as a product rather than a process. Knowledge management in this sense comprises activities like knowledge acquisition, knowledge modelling, knowledge use and reuse, knowledge retrieval, knowledge publishing and knowledge maintenance. In terms of the socio-technical framework these activities form a set of support processes.
Knowledge exchange happens within the social subsystem, between the social and the technical subsystem, and within the technical subsystem. Traditionally knowledge is seen as explicit or as tacit (Polanyi, 1958); tacit knowledge typically resides in humans whereas explicit knowledge can be stored in the technical subsystem. Knowledge exchange is related to the transition of knowledge between these states (Nonaka & Takeuchi, 1995). An exchange within the social subsystem, socialisation of knowledge, corresponds typically to a transition from tacit to tacit knowledge by seeing and doing. A transition from the social to the technical subsystem requires to externalise tacit knowledge into an explicit format, e.g. through knowledge elicitation. Training and learning is the inverse process, internalisation of knowledge, transforming it from explicit to tacit. The exchange of explicit knowledge within the technical subsystem is known as knowledge combination or integration.
In a knowledge-based organisation, the primary process will rely heavily on "knowing", i.e. the application of knowledge. Knowledge management is managing this process. Activities like knowledge acquisition etc. form the supporting processes. Knowledge exchange takes place between and within the social and technical subsystems.
Successful knowledge management will build on a basic principle of socio-technical systems design: the joint optimisation of the social and the technical subsystems. Recently, many popular knowledge management publications focus almost entirely on the people-to-people relations; and even some theorists (Eijnatten, 1993; Sitter, Dankbaar, & Hertog, 1994; Zwaan, 1975) ignore the idea of joint optimisation and consequently reduce socio-technical systems design to a mere workforce participation exercise.
The culture in an organisation is seen as "A pattern of shared basic assumptions that the group learned as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way you perceive, think, and feel in relation to those problems" (Schein, 1985). Culture has become a popular concept to explain the intangible and soft issues in organisations. Theories of organisational and Knowledge Culture include many aspects of culture, some of them invisible, like attitudes and beliefs that rely on behavioural norms, basic assumptions and values; some of them visible, like systems and institutions, artefacts and products, and rituals and behaviours (CEN European Committee for Standardization, 2004; Hall, 1963, 1976; Hofstede, 1991; Schein, 1985; Schwartz, 1994; Spencer-Oatey, 2000).
The three visible aspects of Knowledge Culture correspond to the (structural) building blocks of a socio-technical system:
Artefacts and products relate to the technical subsystem: The design of physical space and buildings can be read as symbols for role modelling.
Rituals and behaviours relate to the social subsystem: Stories and legends about people or events can be symbols for the allocation of formal and informal status.
Systems and institutions relate to the management subsystem: They act as symbols for values and basic assumptions.
At the centre of Knowledge Culture are values and basic assumptions that influence the beliefs, attitudes and conventions in an organisation. These elements of culture are invisible. The visible aspects of Knowledge Culture correspond to the (structural) building blocks of a socio-technical system: Systems and institutions relate to the management subsystem, rituals and behaviours relate to the social subsystem, and artefacts and products relate to the technical subsystem.
These aspects are easy to observe, but difficult to decipher. The structure of an organisation can be read as a symbol for what the organisation thinks is important. As symbols they are ambiguous, and there is no single, straightforward way to establish the essence of the culture of an organisation from looking at its visible aspects. And, most importantly, the visible aspects of Knowledge Culture are not its most determining elements. This is often referred to as the iceberg model of culture. The behavioural norms, attitudes and beliefs at the foundation of the Knowledge Culture of an organisation have a strong impact on the process of knowing itself, on how this process is managed, and on how the organisation deals with knowledge as a product.
In the milling machines manufacturer example we encountered the classical cultural problems of acquisitions where two different cultures clash. This was certainly a reason why the document management system had not already been implemented. And we found another problem: technical enquiries tended to take extremely long to get answered. The design team leaders seemed to be the bottleneck. Was there a belief that team leaders were supposed to know best?
In the local government department we observed, that all services were delivered in one-to-one consultancy meetings, regardless of the type of service. Asked why the employees pointed out that the facilities of the department did not allow for other settings. But we suspected that assumptions about service and the "right way" of service delivery were the real cause.
The culture in the optimisation department was certainly in favour of technical solutions, and we even suspected that some of the people would rather consult a database than ask a colleague. But in the survey, people complained that the support team did not react to requests fast enough.
The healthcare department had developed an effective way of analysing mistakes and mishaps. Especially they managed to establish a local culture of sharing, trust and open discussion, based on the belief that it is important to learn from mishaps. This is rarely the case in healthcare organisations where a blame and shame culture used to be prevalent.
The engineering company tried to establish such a culture of sharing. Their Communities of Practice combined both, technical and social elements. However, perceptions among staff whether this cultural change would last differed: members of Communities were significantly more positive towards the integration of Communities into the culture of the company than non-members.
Analyses, Solutions and Outcomes
In the case of the milling machines manufacturer we analysed the design department in terms of the socio-technical system. In an initial report to the company we made them aware of the situation: There were issues relating to the IT tools the engineers used, particularly the design package and the scheduling package. But these problems were already being addressed. It was not technical problems that blocked the integration of the two product families, as they had suspected. But they needed to look more closely at the people relations in the engineering department. Recently, the company had appointed a new head of the design department. He had just finished his PhD in Engineering and this was his first job back in the industry. This may have contributed to the leaders of the engineering teams not trusting him.
To continue the project we proposed to take the head of the engineering department and the team leaders on an away day. There we first discussed the aims of the engineering department within the company, again in terms of the socio-technical framework. Together with the team we defined the primary and secondary processes, identified technical and social subsystems, and discussed the findings of our initial report. Then we addressed the people relations, particularly the roles of the head of department and of the team leaders. In a lengthy discussion we finally established that the role the head of department saw as his own corresponded to what the team leaders expected of him. And what they presented as their current roles was exactly what he thought their role should be.
This established a basis to address the real issues that the engineering department had to face: They needed simpler data structures and they had to improve the archiving and tracking of design changes. Throughout the organisation they could eliminate a lot of rumours about product changes by informing other departments proactively about design decisions. And the team leaders estimated to save 25-30 % of their time if requests for information would not have to be processed by themselves but could go directly to the engineers who were responsible for the products. The participants of the workshop quickly identified a number of ways to develop solutions for these problems. The issue of archiving and tracking e.g. could be resolved as part of the imminent recertification of the company's quality management system. The other issues were addressed in separate projects.
Three months later the projects were well under way. After only nine months the company confirmed that "part of the points highlighted by the project are now resolved. This is in particular the case for the flow of information, the response time of the engineering department, the simplification of the data structures, and the archiving."
Service Department in Local Government
Again we used the theory of socio-technical systems to analyse the department and its services. For the staff in the department it was a new approach to think of services as processes. They were used to see their services responses to individual cases; they treated every case as a new, unique problem. Although they had regular meetings to share experiences time allowed only for discussion of the most problematic cases. Thus services were delivered inconsistently. Some clients noticed these inequalities and were able to gain personal benefits. Under the new management structure where the department were to be held accountable for service quality this certainly would have become an obstacle.
In a workshop with all the staff we discussed what was expected of the department, both in terms of the key performance indicators and in the personal opinion of the employees. The main conclusion of this discussion was, that the department needed a change in attitude. Many services could be standardised and delivered in a much less personalised way. This freed up personnel, time and resources to deal with the minority of cases where individual, one-to-one consultancy sessions were essential to guarantee the service quality that was expected by the local government.
The department took the responsibility to implement this conclusion. At the centre of developing this "new service culture" were changes to the facilities: two rooms that formerly had been designated consultancy offices were converted into a central service area. At the service desk all the necessary information became available to deliver the standard services correctly and efficiently. This eased the way for establish and documenting standard procedures and standardised ways of delivering services. Two consultancy offices remained for the cases that need individual consultancy. The aim was to solve almost any problem of a client in just one session. The staff rota scheme made more time available for one-to-one sessions and for sharing knowledge and experiences, particularly related to the key performance indicators.
After two years the local government reviewed the performance of the department in comparison to similar departments in other local governments. The results were extraordinary. On average a similar department was able to solve the problems of their clients in 80 percent of the cases. The success rate of this department was a stunning 96 percent. The manager attributed this to two reasons: the strong focus on building up a knowledge base related to the performance indicators and the successful implementation of cultural change.
This department had implemented a multifaceted, technology-driven Knowledge Management approach -- an online collection of performance guidelines, a repository of lessons learnt, and an online training system. These systems were designed to provide all employees with easy access to the most valuable knowledge, and to establish a link between service-related knowledge and other experiences from the projects in which it was created. The systems were database applications that could be accessed through a conventional web browser interface from any place in the world.
The performance guidelines were some kind of electronic manual describing the primary process. They were highly structured and provided detailed technical reference on every task required in all the phases of a project and described over fifty standard problems and best operating practices how to solve these problems or how to them from occurring. The lessons learnt held structured descriptions of whole projects, the respective environment, the technical problems encountered, and the way the project teams solved them. The online training system included a guided tour to the other applications, references to example projects, and some test exercises. All the databases were searchable using different search criteria.
All frontline staff were the target users of the systems. They used the performance guidelines and the lessons learnt particularly in the planning phase of a project. After a project was completed they described it according the structure of the database and added the lessons learnt. They also related these lessons learned to the standard problems of the performance guidelines; and they acted as tutors for the online training system.
Domain experts acted as reviewers on the lessons learnt. They made sure the lessons learned were correct with respect their own business knowledge. They improved problem headings or descriptions if necessary, and occasionally they modified entries in the performance guidelines or add new ones.
Knowledge engineers were responsible for the maintenance, improvement and development of the knowledge systems, e.g. by new elements to the project descriptions etc., and they introduced new employees to the different knowledge systems and their basic use. They also performed knowledge acquisition campaigns to incorporate the more extensive project experience from certain employees or on certain topics.
In a case study we investigated the use of these knowledge-based systems. The investigation showed that the systems failed to unfold their full potential. Performance guidelines were seen as most helpful, but they were seldom used. The users reported easy access to and successful re-use of lessons learnt across geographical areas. Also, the introductory training did not enable users to report new cases without central support that was not available due to lacking resources. Further, learners hoping for (human) feedback on their assignments from the online training system were disappointed by the slow response of the tutors.
The case study showed that, for successful implementation, the whole socio-technical system should have been considered at the time designing the software solution, for both phases, implementation and use. Learning did only take place slowly because sufficient resources were not allocated. However, the company realised bottom-line benefits from sharing knowledge through the use of this system.
When we started to work with the healthcare organisation, they had been looking more closely at mishaps or Critical Incidents for about ten months. Critical Incidents are events that could lead to harm to the patient if allowed to progress. Critical Incidents can be a great source for learning, provided the organisation has adopted an open culture. Traditionally healthcare organisations were more likely to look for who was to blame than to analyse how to prevent the same incident happening again. This particular organisation had already started the transition to a learning culture. We were asked to look for ways how their reporting system could be improved, particularly through the application of IT.
Our initial task was to understand how their existing system worked. On a voluntary basis employees contributed to the critical incidents system by reporting their incidents completely anonymously, i.e. the author of the report could never be identified. They had to describe the incident on a paper form in their own words and how it could have been prevented. Further they had to characterise the incident, based on a set of categories that had been suggested by one of the medical professional bodies. They also had to assess the underlying cause of the incident as human error, equipment failure, or system failure. Every two or three months the group met to analyse selected incidents and to discuss how these could be prevented in the future.
We were interested how consistently the employees would assess the underlying causes. We worked with a set of cases that an expert randomly selected for us from the whole database with several hundred cases. In individual sessions, she and two other experts looked at the cases in some more detail and assessed the underlying causes again. We collated the results and found, that the three experts came to the same conclusion only in thirty percent of the cases. For all the other cases, i.e. seventy percent, their views diverged in some way. In a facilitated discussion the experts were able to resolve these differences and to arrive at an agreed assessment.
This experience lead us to two conclusions: Firstly, we suggested to support the assessment of incidents with a tailored IT system, that would help the reporting individuals to more clearly understand the development of the incident, e.g. by asking questions similar to the ones from the facilitated discussion (and in fact similar to the ones that they would ask in their regular meetings). Such a system would clearly build on the existing culture and not merely collect additional data. Secondly, we suggested implementing a way in which the authors of incident reports could voluntarily disclose their identities, because this would make it possible to have follow-up discussion about what happened and to clarify ambiguities. This suggestion would only be viable in a learning culture where individuals would not risk getting the blame for incidents. We believed the right culture was in place in this particular organisation. In fact the department implemented our second suggestion successfully.
The engineering contractor company focused on the implementation of Communities of Practices that embrace 'people to solutions' as well as 'people to people' paradigms. The central piece of communication technology was a conventional a web portal, which included a skill-finder database, a tool for threaded discussions, and any documents and tools or gadgets the communities choose to have on their portal. The intention was to replace peer-to-peer email habits with one central communication hub for a range of tasks.
Each community had a champion who promoted it and facilitated the internal discussion. Champions received a half-day training course, which provided background understanding of Communities of Practice and the stages of their development, an update of the technological features of the web portal and a brief introduction to facilitation skills. Employees were encouraged to join communities as they wished; all were open to anyone with access to the company's intranet. Individuals also determined the content of their skill profile and updated it themselves.
We carried out semi-structured interviews with eleven of the 23 champions and issued a web-based questionnaire to hundred members (89 returned) and hundred non-members of communities (26 returned). The results can be seen as typical for the early stage of developing a culture based on Communities of Practice. In the interviews, the champions reported a healthy mixture of users but a slow take-up of the idea of communities, and a number of usability issues of the web portal. Also, some voiced concerns over the long-term management support such as "other initiatives have fallen due to funding being withdrawn" or problems of "getting my boss interested". The most active communities were firstly those that already existed as professional groups with established social structures and regular meetings, and secondly company-wide initiatives that utilised the portal as a new communication channel. To our surprise, most interviewees perceived the rationale for Communities of Practice and the current benefits as being mainly local. The training and the experience of using the portal only began to raise awareness for the benefit of breaking down geographical boundaries to develop communities in a global context.
The questionnaire data showed that 83.2 % of the respondents saw Knowledge Management as a priority and the majority was reasonably satisfied with how problems of knowledge transfer were addressed. However, 39.3 % felt it could be improved. The portal technology was evaluated as fit for use but employees felt there was too much focus on virtual meetings and not a strong enough vision of the future. Most participants showed an acceptable understanding of Knowledge Management, mainly centred on sharing of knowledge; there was no statistical difference between members and non-members. We did find statistically significant differences for the expected duration and the integration of Communities of Practice into the culture of the company: Members were more positive towards the integration into the culture, and expected Communities of Practice to last for five to ten years.
We used the theory of socio-technical systems in each case as a backdrop to carry out our analyses. In the milling machines example, we were initially called in to give advice on the technical subsystem. Our analysis revealed that the main problems were questions of socio-technical fit between the requirements of the business and the prevailing culture. In the example of a local government department, and even to a greater extent in the healthcare case, the social and the technical subsystem were quite equally developed; and they initially had supported the primary process and the organisational culture well. The optimisation department showed a similar situation to the milling machines manufacturer. A lot had been done to implement a highly sophisticated technical subsystem, but the concurrent development of the social subsystem was neglected. The engineering contractor finally had adopted a more balanced approach when creating Communities of Practice, and hence they were probably more successful in motivating their people for this new way of collaboration.
We could not ascertain whether everybody in the engineering company had fully subscribed to the new culture of working, though. Their Communities of Practice approach certainly worked where it found a good fit with the existing Knowledge Culture, i.e. in communities that already existed and in organisation-wide initiatives that were reliant on the new communication infrastructure. In the healthcare example, the evolution of organisational culture challenged the initial fit of the visible elements of culture and the underlying beliefs and values. Thus we suggested adjusting the socio-technical system to gain a closer fit again. The culture in the optimisation department took longer to develop in the desired way. Bottom-line benefits from sharing knowledge were not enough to enthuse people into fully using the technical systems. A lack of consideration for the social subsystem did not reinforce these benefits enough. In the local government example, changes in the environment questioned clearly some underlying attitudes of the employees. Recognising this was a first step to changing these attitudes. Respective changes to the visible elements of culture, i.e. in the socio-technical system, reinforced these changes. The milling machines example not only showed a traditional technical approach to organisation but we also discovered an attitude that lead people to assume that it is the boss who knows best. To challenge this attitude an give them, the bosses, a key role in overcoming it might have been an important step to influence this culture.
So: What Is the Answer?
All our five examples are different, and they show certain similarities and certain patterns. But as always, there is not simple answer to a problem as complex as assessing, creating and sustaining Knowledge Culture in an organisation.
We believe that it is key to assess a problem, in this case Knowledge Culture, to have an appropriate framework for the assessment. The socio-technical framework of Knowledge Management and Knowledge Culture is based theoretical models. It provides an understanding of the basic elements that constitute an organisation, of their interaction, and of their relationship to the highly complex phenomenon of culture. As a framework it provides a general guideline how to assess Knowledge Culture, and the five examples illustrate the use and application of this framework.
Creating a Knowledge Culture inevitably has to address the invisible elements of culture -- behavioural norms, attitudes and belief. They are as important as they are hard to get at. In the examples where we addressed cultural change we usually did this through a form of making some of these invisible elements explicit, e.g. in discussions. It is tempting to change some of the visible elements of culture, like products, rituals or systems. While this can have an influence on culture, it is hard to control this influence to change culture in the desired way.
The visible elements of culture play an important role in sustaining Knowledge Culture. Appropriate institutions, behaviours and artefacts, an appropriate design of the socio-technical system, will make the invisible elements of culture stronger. Changing Knowledge Culture has to address the invisible elements, adjusting the visible elements will help to strengthen and sustain Knowledge Culture.
We would like to extend a warm thank you to the project partici-pants in the five organisations as well as to our consultancy part-ners and research students in Zurich, Switzerland, and Aberdeen, Scotland, who all contributed to the success of the five projects.
CEN European Committee for Standardization; European Guide to Good Practice in Knowledge Management. Part 2: Organizational Culture; ftp://cenftp1.cenorm.be/PUBLIC/CWAs/e-Europe/KM/CWA14924-02-2004-Mar.pdf; 29 May, 2004.
Coakes, E., Willis, D., & Clarke, S. (Eds.). 2002. Knowledge management in the SocioTechnical world. The graffiti continues. London: Springer.
Eijnatten, F. M. v. 1993. The paradigm that changed the work place. Assen: Van Gorcum.
Emery, F. E. 1959. Characteristics of Socio-Technical Systems. London: Tavistock Institute.
Emery, F. E. & Trist, E. L. 1960. Socio-Technical Systems. In C. W. Churchman & M. Verhulst (Eds.), Management Science, Models and Techniques: 83-97. Oxford: Pergamon.
Emery, F. E. & Trist, E. L. 1965. The Casual Texture of Organizational Environments. Human Relations(18): 21-32.
Emery, F. E. & Trist, E. L. 1973. Towards a Social Ecology. London: Plenum Press.
Hall, E. T. 1963. The silent language. Greenwich, Conn.: Fawcett.
Hall, E. T. 1976. Beyond Culture. Garden City, NY: Anchor Press.
Hofstede, G. H. 1991. Cultures and organizations : software of the mind. London ; New York: McGraw-Hill.
Miller, E. J. & Rice, A. K. 1967. Systems of Organization. London: Tavistock Institute of Human Relations.
Nonaka, I. & Takeuchi, H. 1995. The knowledge-creating company : how Japanese companies create the dynamics of innovation. New York: Oxford University Press.
Polanyi, M. 1958. Personal knowledge; towards a post-critical philosophy. Chicago,: University of Chicago Press.
Rice, A. K. 1958. Productivity an Social Organization. The Ahmedabad Experiment. London: Tavistock Institute of Human Relations.
Rice, A. K. 1963. The Enterprise and its Environment. London: Tavistock Institute of Human Relations.
Schein, E. H. 1985. Organizational culture and leadership (1st ed.). San Franciso: Jossey-Bass Publishers.
Schwartz, S. H. 1994. Beyond Individualism/Collectivism: New Dimensions of Values. In U. Kim & H. C. Triandis & C. Kagitçibasi & S. C. Choi & G. Yoon (Eds.), Individualism and Collectivism: Theory Application and Methods. Newbuty Park, CA: Sage.
Sitter, L. U. d., Dankbaar, B., & Hertog, J. F. d.; Designing simple organisations and complex jobs; http://www.merit.unimaas.nl/publications/rmpdf/1994/rm94_012.pdf; 13. Jan., 2003.
Spencer-Oatey, H. 2000. Culturally Speaking: managing Rapport through Talk accross Cultures. London: Continuum.
Trist, E. L. & Bamforth, K. W. 1951. Some Social and Psychological Consequences of the Longwall Method of Coal Getting. Human Relations(4): 3-38.
Trist, E. L. 1981. The Evolution of Sociotechnical Systems.
Troxler, P. 1999. Wirkungsbeurteilung strategischer Gestaltungsprojekte in der industriellen Produktion. Ein Beitrag zur nachhaltigen, arbeitsorientierten, prospektiven Gestaltung soziotechnischer Systeme. ETH, Zurich.
Troxler, P. & Lauche, K. 2003. Knowledge Management and Learning Culture in Distributed Engineering. Paper presented at the Research for Practice. Innovation in Products, Processes and Organisations, ICED03, Stockholm.
Ulich, E. 1997. Mensch-Technik-Organisation. Ein europäisches Produktionskonzept. In O. Strohm & E. Ulich (Eds.), Unternehmen arbeitspsychologisch bewerten. Ein Mehrebenenansatz unter besonderer Berücksichtigung von Mensch, Technik, Organisation. Zürich: vdf Hochschulverlag an der ETH.
Ulich, E. 1998. Arbeitspsychologie (4 ed.). Zürich; Stuttgart: vdf Hochschulverlag an der ETH; Schäffer-Poeschel.
Zwaan, A. H. v. d. 1975. The socio-technical systems approach: A critical evaluation. International Journal of Production Research, 13: 149-163.
About the Authors
Peter Troxler is based in Rotterdam and works as a Knowledge Management expert with management consultancies in Europe. He supports organisations in the private and public sector to building management systems for the knowledge economy. Recently he has helped to establish the Research Centre in Knowledge Technologies at the University of Aberdeen. The centre exploits cutting edge research in semantic knowledge technologies and transfers the results to industry, especially in the energy sector, to healthcare and to other public sector institutions.
Peter has worked for six years as a researcher at ETH Zurich at the interface of industrial psychology and management science; research topics were factory automation and human factors, object-oriented, modular production systems, technology assessment, and the development of integrated management systems. For six years he worked as a management consultant in the area of strategy development and implementation, and integrated management systems with a variety of customers from industry, non-profit organisations, charities and the public sector.
Peter Troxler holds a Dr. sc. techn. in Industrial Management and a degree in Operations Management (Dipl. Ing.) from ETH Zurich, Switzerland. He is a member of many professional organisations, notably the Swiss Associoation of Industrial Psychologists, (SGAOP), the International Council of Systems Engineering (INCOSE), the German Association of Engineers (VDI). He is an Owning Member of the Chaordic Commons, a funding member of Knowledge Angels and a member and regular contributor to KnowledgeBoard, the online community of the European KM Forum.
Kristina Lauche is an Assistant Professor at the Technical University of Delft, NL. Her research focuses on the Interaction of People and Teams in Complex Situations. Research topics include manufacturing and engineering teams, innovation projects in SMEs, the concept of Communities of Practices, and collective work regulation in teams.
Kristina holds a Dr. phil. in Psychology from the University of Potsdam, Germany and a Dipl. Psych. from the Freie Universtät Berlin, Germany. In her research career she has worked at the University of Munich (Germany), ETH Zurich (Switzerland), and the University of Helsinki (Finland). She is a member of the Society for Industrial and Organizational Psychology Inc. (SIOP), German Association of Psychologists (DGPs), the Swiss Association of Industrial Psychologists (SGAOP), the European Association of Work Psychologists (EAWOP) and the International Design Society.
Address of the authors
Dr Peter Troxler
[ k n w l d g ]
Beukelsdijk 74 B, 3022 DJ Rotterdam, The Netherlands
Dr Kristina Lauche
Technical University of Delft, Industrieel Ontwerpen
Landbergstraat 15, 2628 CE Delft, The Netherlands
10 Steps for KM Practitioners to Assess, Create and Sustain Knowledge Culture in Organisations
1. Start the assessment of Knowledge Culture by analysing and describing the actual, observable work environment, e.g. in terms of a socio-technical system, which consists of five elements:
a. Identify the purpose, or goal, of the system.
b. Identify the primary and secondary processes or chains of activities.
c. Describe the technical sub-system and the functions it provides (systems in use, strengths and weaknesses).
d. Describe the social sub-system and the roles its members fulfil, their attitudes, history, shared views and potential conflicts.
e. Describe the management sub-system and the specific goals it pursues.
2. Establish in what way Knowledge plays an important part in the organisation:
a. Knowledge as a process: Where does 'knowing' i.e. creating knowledge play an important part in a process or activity to achieve its goal?
b. Knowledge as a product: Where does a process or an activity rely heavily on existing knowledge or experience?
3. Establish where crucial tacit knowledge and explicit knowledge resides. Who are key carriers of tacit knowledge or experience? What are the key repositories of explicit knowledge and sources of information?
4. Describe the visible elements of the Knowledge Culture in the organisation:
a. Artefacts and products, in fact any tangible objects that are part of the organisations or are produced by the organisation (they relate to the technical subsystem).
b. Rituals and behaviours that form part of to the social subsystem.
c. Systems and institutions of the management subsystem.
5. Create a discussion about the visible, observable results of you assessment so far. Test the accuracy of your observations with the people who work in the organisation. Establish a common picture of the obvious, observable. This will later enable you to distinguish between what all agree has been observed, and people's opinions and interpretations.
6. Create a discussion about the underlying elements of culture in the organisation, i.e. the attitudes and beliefs that rely on behavioural norms, basic assumptions and values. In what way are the observable elements of culture expressions of these underlying elements? In how far do people agree on these interpretations?
a. How can the design of physical space, the buildings and other material manifestations be read as symbols, e.g. for role modelling?
b. How can stories and legends about people or events be seen as symbols for the allocation of formal and informal status?
c. How can systems and institutions be explained as symbols for values and basic assumptions?
7. Create a discussion about the visible and invisible elements of the Knowledge Culture: Are they consistent? Are they what the organisation wants? Do they to the correspond views that individuals have about the organisation? In what way should the elements of culture be changed? How could peoples' views about the organisation be challenged? This might lead in to a three step cultural change programme of unfreeze, change, and refreeze (see steps 8 to 10 below).
8. Unfreeze -- develop an awareness of the change needed, the methods planned to achieve the change, the needs of those affected, and the ways that progress will be planned and monitored. Establish how the visible elements of culture, artefacts and products, rituals and behaviours, systems and institutions, support, express and sustain the invisible elements of the desired culture and the views of people.
9. Change -- define the problems, identify the solutions and implement them. Establish how the visible elements of culture translate into the elements of the socio-technical system. Particularly design the division of labour between the technical, social and management subsystem so that sustains the attitudes and beliefs, the behavioural norms, the basic assumptions and values.
10. Refreeze -- Stabilise the situation, build or rebuild relationships and consolidate the systems. Continue the dialogue about Knowledge Culture as described in the 9 steps above on a regular basis. Take into account that culture changes slowly -- an annual (or even bi- or tri-annual) reassessment is probably more appropriate than a monthly report on culture.