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 [2] use by easing the implementation of knowledgeintensive work processes. The importance of context-awareness in KM is largely undisputed. Context-awareness basically aims at understanding all relevant information required for knowledge use of an organization or an actor (the context) and applying this understanding in organizational and technical KM solutions and systems (cf. section 2 for a more detailed discussion).
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.
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).
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 [1] and paved the way for context-aware assistive systems. Nowadays, groupware systems, knowledge portals and other information systems used to support KM provide mechanisms to adapt to the users' situation on demand. 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 [3,5]. An essential part of developing context based systems is to analyze and conceptualize the elements of the specific context required for the application under development, including their dependencies and mechanism of use. The context is also required during runtime of a context-aware system, i.e. the context model is not only a conceptualization but has to be reflected in appropriate information structures and instantiated in the actual system.
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 [7] and the SECI model [6].
KMS from a technology perspective, i.e., IT-systems supporting organizational KM. In this area, the architecture proposal for such systems of [4] and the differentiation between various knowledge services as components of this architecture is often applied. Maier distinguishes several layers in a KMS architecture (access, personalization, knowledge service, integration, and infrastructure layer) and four basic services (publication, search, collaboration and learning) in the architecture's knowledge service layer.
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 [6] or the creation of new knowledge [8]. IT-systems supporting KM often explicitly include components for 'contextualization' (knowledge portals) or contain personalization or individualization features which aim at adapting to a certain user and the actual context of use [4].
A systematic literature review (SLR) performed by Koç et al. [3] on the state of the art of context modelling methods in IS research showed that the term context is widely used in computer science, but the method support for developing context models is scarce. The term "method" is used synonymously with "development steps" or "modelling approaches" and Model Driven Development (MDD) techniques are frequently applied when eliciting context models. Hoyos et al. [9] present a domain specific language (DSL) and show steps on how to model context quality. Hussein et al. [10] introduce a model based approach to develop context-aware adaptive software systems. Serral et al. [11] propose steps to develop context-aware systems applying MDD methods. Kapitsaki and Venieris [12] describe how to develop context-aware web applications using MDD techniques in six steps.
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. [13,14]). This works primarily focus on the conceptualisation of context, i.e. what elements typically are part of context, how to identify and represent them in models. Also the field of requirement engineering (RE) has made valuable contributions. Lapouchnian and Mylopoulos [16] propose a process to explore contextual variability and analyze effects on goal models. Ali et al. [15] introduce a goal-based RE modelling and reasoning framework for systems oper-ating in various contexts. Both proposals are helpful for identifying and formalising the contextual factors.
On previous work addresses context modeling in capability management and proposes a component-oriented method for this purpose [18]. Furthermore, there is work on identifying context elements for applications in e-learning [17]. None of the proposed methods or approaches has a specific focus on knowledge management or KMS.
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.
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 [20]. The work included two cycles. The first cycle focused on capturing organizational knowledge and best practices for networked manufacturing enterprises with task patterns. The second cycle focused on integration of product knowledge. Figure 1 shows an example for a knowledge model developed in the project. Following the active knowledge modelling philosophy, the developed knowledge models were also made executable in the KM infrastructure (see, e.g. [21]).
Figure 1: Active knowledge model from automotive supplier case Figure 1 visualizes best practice knowledge for the task "establish material specification". The process flow with the steps "1. Prepare draft", "2. Material Testing", "3. Process Trial" and "4. Release Material Specification" is shown; for "2. Material Testing" even the refinement is included in the middle area of the figure. Above the process flow, objectives and documents which are input are included. The arrows indicate relationships between processes, roles, systems and documents or objectives. On the lower part, the roles involved in the process are included (grouped at the left hand side) and the IT systems and tools are shown.
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 WM1017 -9te Konferenz Professionelles Wissensmanagement 5.-7. April 2017 in Karlsruhe, Deutschland 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 [19]. Figure 1 shows the knowledge application map as an example illustrating the results of the project.
The aims of the knowledge management project was to make competences explicit which are required for the work procedures, share expertise between different civil servants for the different services offered to citizens.
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.
WM1017 -9te Konferenz Professionelles Wissensmanagement 5.-7. April 2017 in Karlsruhe, Deutschland
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.
In order to identify the required context elements of the cases introduced in section 4, we applied the context modelling approach proposed in [17] which consists of four steps:
(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.
WM1017 -9te Konferenz Professionelles Wissensmanagement 5.-7. April 2017 in Karlsruhe, Deutschland
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. 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. [2], compliance policy, study format, didactic model, assignment type, subject area, collaboration type, position [2], procedure [3], document classification [2], regulation [2], case classification [2], applicable bylaw [2], service policy [2], resource use policy [2], product line, platform, infrastructure version, campaign type, market segment, international/national scope, service policy, department [2], client group, service type, situation (time), customer group, Inter-organizational variation service network membership, related external process, related supplier process, supplier involvement 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 [2], resource use policy [2], product line, Process: task, collaboration type, procedure [3], service type, related external process, related supplier process Organization structure: role [4], compliance policy, position [2], regulation [2], applicable bylaw [2], market segment, international/national scope, department [2], client group, customer group, service network membership, supplier involvement Resource: document classification [2], resource use policy [2], platform, infrastructure version. 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 WM1017 -9te Konferenz Professionelles Wissensmanagement 5.-7. April 2017 in Karlsruhe, Deutschland actual work processes are required. But some elements are more unexpected, for example the importance of location or time-related adaptations.
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 [22] which stores the model in an XML-based representation. CDT also allows for visual representation of variation points in process models. 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.
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.
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).
WM1017 -9te Konferenz Professionelles Wissensmanagement 5.-7. April 2017 in Karlsruhe, Deutschland