Context-awareness is a common feature of contemporary knowledge management systems (KMS). The intended effect of context-awareness is to tailor appearance, functionality and behavior of KMS to the needs and individual preferences of knowledge workers and to contribute to flexibility in organizational KMS use by supporting the integration of knowledge use into work processes. The variability of organizational and individual tasks is essential for understanding context in organizations. Context modeling methods have been proposed which analyze this variability and identify context elements. This paper investigates whether there are recurring context elements across organizations and how these recurring elements could be used to improve context modeling methods and KMS configuration processes.
Context-awareness has emerged from a special feature of niche applications to a
characteristic of most knowledge management systems. The intended effect of
context-awareness is to tailor appearance, functionality and behavior of knowledge
management systems (KMS) to the needs of knowledge workers and to contribute to
flexibility in organizational KMS [
The focus of this paper is on the elements of ‘context’ and to understand whether there are recurring elements in context models for different organizations. Such recurring elements could indicate potential for improving both, functionality of KMS by extending and emphasizing functionality and content relevant for the recurring contexts, and context modeling approaches by adding aids or guidelines to early identify recurring context parts and thus making the modeling process more efficient. The work builds upon an earlier developed method for context modelling and on experiences from knowledge management projects in different kinds of organizations. From our perspective, the variability of organizational and individual tasks is essential for understanding context. We argue that making context elements explicit by capturing them in a context model eases the configuration and adaptation of generic knowledge management platforms to solutions for specific organizations more efficient.
The research questions investigated in the paper are What are recurring context elements of knowledge management systems relevant across single organizations? How can recurring context elements be applied for improving context modeling methods and implementation of context-aware knowledge management? Furthermore, the paper aims at motivating and demonstrating the modeling and analysis of context in knowledge management.
The paper is structured as follows: section 2 briefly describes the theoretical background for our work. Section 3 summarizes the research approach used. Section 4 presents cases of organizational knowledge management which were subject to context modeling and identification of recurring context elements. Section 5 presents selected context models and recurring context elements which were the result of context model analysis. Section 6 summarizes the work and draws conclusions. 2
This section summarizes the background for our work which includes characteristics of context-awareness (2.1), context-aware knowledge management (2.2) and methods for context modeling (2.3). 2.1
Context-Awareness
‘Context-awareness’ emerged from a special and innovative feature of niche
applications to a characteristic of many IT Systems in modern enterprises. Dey’s seminal
work defined context as information characterizing the situation of an entity [
However, design and development of context-awareness still require substantial
engineering work, i.e. there is no general development methodology for
contextaware systems. One reason for this probably is the variety of interpretations of the
term context in the area of engineering [
The field of KM attracts researchers from diverse disciplines with different perspectives, theories and interest in the field. At least two different perspectives on KMS have to be differentiated:
KMS from an organizational perspective: These systems describe how to establish
systematic KM in an organization in terms of activities and organizational structures
required. Well-known approaches sin this area are the ‘building block’ model
proposed by [
KMS from a technology perspective, i.e., IT-systems supporting organizational
KM. In this area, the architecture proposal for such systems of [
In both perspectives, it is acknowledged that context plays an important role, either
for the process of individual knowledge generation from information, the process of
understanding [
A systematic literature review (SLR) performed by Koç et al. [
Other related work has a focus on context-based systems and describes
requirements and ways of developing context models for specific application without
offering a general view on the method part (e.g. [
On previous work addresses context modeling in capability management and
proposes a component-oriented method for this purpose [
From a research methodology perspective, we performed an ex-post context analysis and context modelling in cases of organisational knowledge management which were completed 2010 to 2016. All analysis and modelling followed the same methodology (see section 5.1) and was done by the same researchers. The results of context modelling in the cases was analysed for recurring elements or partial models (see section 5.2). Furthermore, the context modelling showed the usefulness of explicitly capturing and modelling context.
Since our objective is to investigate recurring context elements in knowledge management our focus has to be on cases with data sources containing very detailed activity reports and rich case descriptions. As this type of report is quite sparse in scientific literature on context modelling methods (see section 2.3) we decided to base our analysis only on knowledge management projects performed in our own research groups. For these projects, the original project documentation and the personnel involved in the project are available. The projects analysed originated from two research contexts, (i) Rostock University (Germany), research group business information systems, and (ii) School of Engineering at Jönköping University (Sweden), research group information engineering who in some projects jointly worked on the tasks. Analysis of the projects included study of the documentation, discussions with the researchers involved and analysis of models or specifications, if available. Table 1 shows the list of projects analysed. These projects were chosen because of the availability of documentation and accessibility of the researchers involved. Medium-sized enterprise, IT industry German Ministry Public federal state Medium-sized enterprise, service provider domain experts Management of organisational knowledge Federal Knowledge of do
main experts authority, Process knowledge and customer services Management of organisational knowledge
Community of Practice, Wiki For brevity reasons, this section introduces only two of the organisational knowledge management cases listed in table 1 in more detail. The cases form the basis for the context modelling and context model analysis performed in section 5. When selecting these cases for presentation, the objective was to achieve a certain heterogeneity regarding the type of organization (distributed organization vs. centralized location), the application domain (industry vs. public sector) and the purpose of knowledge management project (knowledge sharing vs. knowledge mapping).
The first knowledge management case is taken from automotive industries and focuses on distributed product development in a networked organization with different suppliers. The main partner is the business area “seat comfort components” of a first tier automotive supplier with the main product development sites in Scandinavia. The seat comfort products mainly include seat heater, seat ventilation, climate control, lumber support and head restraint.
In this application case, analysis of requirements for knowledge management and collaborative engineering support, knowledge modelling and development of a knowledge management infrastructure and application of this infrastructure in everyday work was performed. The focus was on the advanced engineering unit, where product development tasks are concentrating on pre-development of new concepts and new materials. Development of products included elicitation of system requirements based on customer requirements, development of functional, design of logical and technical architecture, co-design of material, electrical and mechanical components, integration testing and production planning including production logistics, floor planning and product line planning.
The process was geographically distributed involving engineers and specialists at several locations of the automotive supplier and sub-supplier for specific tasks. A large percentage of seat comfort components can be considered as product families, i.e. various versions of the components exist and have to be maintained and further developed for different product models and different customers. In this context, flexible product development in networks with changing partners on customer and subsupplier side were of importance.
Modelling product development knowledge in the industrial case was performed
according to the active knowledge modelling [
The second case is a municipality administration from Germany with approx. 600 civil servants at one central location. The major challenge experienced by the municipality and motivating the knowledge management project were budget cuts and reduction in staff size. The municipality did not have a general knowledge management strategy but encouraged the different departments to address challenges in this field individually. Thus, the starting point for the case reported here was a “local” problem in one department (i.e. no general organizational initiative). The department under consideration experiences that citizens demand better and faster services from public administration and at the same time the number of civil servants in the department is continuously reduced (no replacement in case of retirements). The department has no established structures or processes for KM, but shared work procedures among the civil servants. For publishing and searching these work procedure, a MS-sharepoint infrastructure is provided.
As a central element towards introducing a knowledge management solution in the
department, it was decided to develop knowledge maps following the approach
proposed by Eppler [
The effects of the knowledge management project from an organizational perspective was that there is a much better overview to “who knows what” and that some of the shared work procedures now need less time. From an individual perspective of the civil servants, the knowledge maps are not completely developed as some individuals are hesitant to disclose their competence. The civil servants of the department can be divided into supporters of the approach (the majority) and opponents of the approach. 5
As indicated in section 3, we performed an ex-post context modeling and analysis of knowledge management cases. This section briefly presents the method for context modelling applied (5.1) and the results of the modeling. The results are presented in two parts: the first modeling phases relevant for identifying recurring context elements was done for all cases included in table 1 and is presented in 5.2. The actual context model development was performed only for the two cases introduced in section 4 and is presented in 5.3. 5.1
In order to identify the required context elements of the cases introduced in section
4, we applied the context modelling approach proposed in [
(1) Scenario modelling: The purpose of the first step is to identify user groups and how their ways of using the KM system differ from each other. The scenarios are captured with the processes supported by the system, the information input and output, possible connections to other systems and processes, and the integration of resources.
(2) Variability elicitation: The second step is probably the most important one. A context model has to include in what situations and on what inputs or events what kind of adaptations in the context-aware system should be made. Since the results of these adaptations can be considered as variations of the use of the system, the system’s behavior or even the system’s configuration, it is decisive to understand the cause and kind of the variation. In order to determine cause and kind of variation, the variation aspects (the cause of variation) and the variation points (where the variation occurs) are investigated.
(3) Context model development. The context model represents the variations aspects and variation points together with the required adaptations in a system-readable model that can be used to configure knowledge management systems. Such a context model consists of context elements connected to variation points/aspects, context sets for different user groups or usage scenarios, and optional adjustment algorithms specifying adaptations.
(4) Implementation of context-aware KM: the context model is used to configure the knowledge management system which is in use in the organization under consideration. This can be illustrated using Maier’s architecture of KMS (see section 2.2). Here, the context model would be used to extend what Maier refers to as knowledge structure and enterprise-specific vocabulary. This knowledge structure is represented and maintained in the integration layer, often represented as semantic net or ontology, for semantic integration of enterprise knowledge sources. Furthermore, it forms the basis for the knowledge services search and publication, e.g. by supporting navigation structures and filter functions in secondary search functions. With the elements of the context model integrated into the knowledge structure, these elements also become available as parameters on the personalization layer. 5.2
The first two steps of the context modeling method introduced in section 5.1 were performed for all cases listed in table 1, i.e. we developed scenario models based on the case documentations for every case, and we identified the variation aspects and variation points. With respect to scenario modeling, some cases already included the scenarios as part of the project work. An example is the automotive supplier case (cf. section 4.1) where the active knowledge models can be used as scenario models without making any changes, i.e. Figure 1 can be considered as an example for a scenario model. Role, individual competence, location of production, task, related external process, product variant, product family, material, supplier involvement, local regulation, compliance policy Study format, didactic model, individual portfolio, assignment type, subject area, collaboration type, group membership Position, procedure, document classification, regulation, case classification, applicable bylaw, individual competence, service policy, resource use policy Product line, role, related supplier process, platform, infrastructure version, campaign type, market segment International/national scope, position, procedure, document classification, service policy, resource use policy, regulation, case classification, applicable bylaw, individual competence Department, client group, service type, procedure, document classification, regulation, individual mandate, service policy, resource use policy Situation (time), location, local regulation, customer group, role, individual competence, service network membership, task, process
Variation Point Example (variation occurs …) when the material used for a product variant is dependent on local regulations when the study format leads to dynamic configuration of the meta-search when the information required for a permit depends on the regulation case when pricing depends on a subscription model and time when hierarchy and reporting depend on project or case when service priority depends on customer group when service execution depends on location
The most interesting aspect of the first two method steps for our research question is the identification of variation aspects and variation point, as these two aspects lead to the context elements. The identified variation aspects and variation points are shown in table 2.
Variation points proved to be too case specific and not suitable for an analysis of recurrence. In order to ease identification of recurring variation aspects, we sorted them into variation related to the individual knowledge worker, to the organizational context and to inter-organizational aspects (if appropriate for the case). The result of this classification step is summarized in table 3. The table also shows how many times each variation aspect and point occurred in the cases which is indicated by the numbers in brackets.
Variation Aspects
individual competence [
Table 3 shows that a number of variation aspects exist in the majority of cases. The organizational and inter-organizational variation aspects, which are of high interest for organizational knowledge management, can also be sorted into product, process, organization structure and resource-related aspects:
Product: product variant, product family, material, study format, service policy
[
Some of the recurring elements are not surprising as it is known in KM that adaptation of content and functionality to the knowledge workers’ organizational roles or the actual work processes are required. But some elements are more unexpected, for example the importance of location or time-related adaptations. 5.3
For the two cases presented in section 4, the context modeling process was continued by also developing a visual context model based on the analysis results. The purpose of this step was to investigate whether not only context elements recur but also structures among these context elements recur. Such recurring structures could be an indication that the development of context model patterns could be possible. Furthermore, the context models illustrate what kind of machine-readable models are the result of the context modeling method.
The context models were developed with a modelling tool which takes care of a
computable representation following a defined meta-model. We used the CDT tool
[
Figure 3 shows the context model for the automotive supplier case developed based on the analysis of the scenarios. The individual and organizational perspectives are represented as different context sets (see right hand side of the figure). “Context set 1” includes the context elements for organizational KM, which are product line, product variant and production location. In the context set, the context elements are represented with their ranges relevant for the set. “Context set 2” includes the elements relevant for the individual perspective. The context elements are made explicit in the center of the figure. Their attributes are shown in the property box at the lower part of the tool. Each context element is on its left-hand side linked to the variation aspect.
How to apply a context model in a KM systems can be illustrated by using Maier’s KMS architecture (see section 2). In Maier’s architecture, the context model would be used to extend what Maier refers to as knowledge structure and enterprise-specific vocabulary. This knowledge structure is represented and maintained in the integration layer, often represented as semantic net or ontology, for semantic integration of enterprise knowledge sources. Furthermore, it forms the basis for the knowledge services search and publication, e.g. by supporting navigation structures and filter functions in secondary search functions. With the elements of the context model integrated into the knowledge structure, these elements also become available as parameters on the personalization layer, i.e. the individual context elements can be used to tailor the KMS to the actual user.
The comparison of the two models showed structural patterns with recurring elements linked to the variation aspects. An example is the variation aspect regulation which in both modeled cases is connected to local regulation and case classification. 6
The focus of the previous sections was to investigate whether there are recurring elements in context models for different organizations. For this purpose we performed an ex-post context modeling and analysis exercise on a number of KM cases from previous work. Variations aspects and variation points were elicited for all cases and context models were developed for two selected cases. The work confirmed that it is important to understand the variability of organizational and individual tasks for understanding context. The context modeling method used proved – although developed for the area of portal configuration in e-learning – applicable and useful for knowledge management.
The research questions investigated in the paper were What are recurring context elements of knowledge management systems relevant across single organizations? The analysis of the cases showed that recurring elements of context models can be identified (see section 5.2). These recurring elements concern variation aspects, such as process, product structures and locations.
How can recurring context elements be applied for improving context modeling methods and implementation of context-aware knowledge management? These findings have implications for the context modeling methods and for KMS. Context modeling methods should be complemented with aids or best practices that inform the modeler about typical context elements recurring in a certain field of analysis, for example provided as a guideline. Such guidelines could help to reduce the time for context modeling. Recurring elements or future “context model patterns” could indicate potential for improving both, functionality of KMS by extending and emphasizing functionality and content relevant for the recurring contexts (see section 5.3).
The biggest limitation of our work is the small number of cases investigated. Future work has to address this shortcoming by using the context modeling perspective on more knowledge management cases in order to confirm the findings of this paper. Furthermore, future work needs to address
Identification of recurring context elements for application areas and domains. We expect that the sets of recurring elements will depend on application or industrial domain Development of patterns for context models including tool support
Investigation how to adapt the functionality of KMS
The work presented in this paper was supported within the project KOSMOS-2 (Konstruktion und Organisation eines Studiums in Offenen Systemen) funded by the BMBF (Federal Ministry of Education and Research, Germany) and the European Social Funds of the European Union.