We discuss how an Enterprise Modelling approach, namely C3S3P, has been applied in an automotive supplier company. The paper concentrates on the phases of the C3S3P development process such as Concept Study, Scaffolding, Scoping, and Requirements Modelling. We have also presented the concept of task pattern which has been used in the MAPPER project for capturing, documenting and sharing best practices concerning business processes in organisation. Within this application context we have analysed our experiences concerning stakeholder participation and task pattern development.
Every information system (IS) engineering project needs to have a clear vision and
purpose, and to know what kind of properties the developed product should possess.
This usually is the focus of requirements engineering (RE) activities that are being
performed in project’s early stages. The main objective of this process is not only to
put forward a number of features that the product should have, but also to connect
them to the business needs of the customer organization in such a way that each
product requirement is traceable to some business objective of the organization. This
explicit connection between IS requirements and business goals helps avoiding
unnecessary rework and increases the business value of the product. Moreover, in the
process of eliciting and linking the business needs and IS requirements, the
development team and the stakeholders usually have to tackle a number of “wicked”
or “ill-structured” problems [
Enterprise Modeling (EM) seeks to solve organizational design problems in, for
instance, business process reengineering, strategy planning, enterprise integration, and
information systems development [
The participative approach to EM contributes to the quality of the requirement
specification as well as increases the acceptance of decisions in the organizations, and
is thus recommended by several EM approaches (c.f. for instance [
The objective of this paper is to report how a specific EM approach, namely C3S3P1, was applied in an automotive supplier company in order to elicit requirements for a reconfigurable IS to support collaborative engineering and flexible manufacturing processes. More specifically, we will address the following questions: • How were the stages of C3S3P followed to develop requirements and what where the experiences and lessons learned in each of them? (See section 3.1). • What kinds of model elements were used in the project and how were they supported by the METIS2 tool? (See sections 3.2 and 3.3) • What are the experiences concerning stakeholder participation? • What are the experiences concerning the creation of task patterns?
The remainder of the paper is organized as follows. Section 2 presents the application case at Kongsberg Automotive. Section 3 presents the RE and EM process. Section 4 captures experiences concerning stakeholder participation and creation of task patterns. Conclusions and issues for future work are discussed in section 5.
The application case is taken from the EU FP6 project MAPPER, which aims at
enabling fast and flexible manufacturing by providing methodology, infrastructure
and reusable services for participative engineering in networked manufacturing
enterprises. A core element of the MAPPER approach is reconfigurable enterprise
models including an executable environment for these models, which are considered
active knowledge models. See [
The application case focuses on distributed product development with multi project lifecycles in a networked organization from automotive supplier industry. Main partner is Kongsberg Automotive’s (KA) business area seat comfort. KA’s main 1 C3S3P is used in ATHENA (http://www.athena-ip.org) and MAPPER projects (http://mapper.troux.com), see also [St07]. 2 See http://www.troux.com products are seat comfort components (seat heater, seat ventilation, lumber support and head restraint), gear shifts and commercial vehicle components.
The case is focused on the department Advanced Engineering within the Business Area Seat Comfort. Development of products includes identification of system requirements based on customer requirements, functional specification, development of logical and technical architecture, co-design of electrical and mechanical components, integration testing, and production planning including production logistics, floor planning and product line planning. This process is geographically distributed involving engineers and specialists at several KA locations and suppliers from the region. A high percentage of seat comfort components are product families, i.e. various versions of the components exist and are maintained and further developed for different product models and different customers. KA needs fast and flexible product development in concurrently performed forward-development processes. Hence, general requirements regarding infrastructure and methodology are: − To support geographical distribution and flexible integration of changing partners − To enable flexible engineering processes reflecting the dynamics of changing customer requirements and ad-hoc process changes, and at the same time welldefined processes for coordinated product development − To coordinate a large number of parallel product development activities competing for the same resources − To allow richness of variants while supporting product reuse and generalization.
The purpose of the requirements modelling activity is to further specify and elicit these general requirements. Regarding the service and infrastructure, the requirements will address the collaboration infrastructure, which has to support networked manufacturing between different locations of KA and KA’s suppliers. Furthermore, services for performance and coordination of work, management of projects or tasks, or workplaces are subject of requirements analysis. Regarding the methodology, KA has to express and qualify the desired methodology support for sustainable collaboration, multi-project portfolio management, organisational learning and EM.
Requirements elicitation and specification in the MAPPER project and in the application case at KA was not performed in the traditional way of producing documents with text and illustrations. The requirements are captured in a (partial) enterprise model, which at the same time, to a large extent, can be used as executable solution model during the later phases of the project. This way of heavily using networked manufacturing EM reflects the MAPPER philosophy of model-adapted product and process engineering: the current requirements model will be adapted to support real-world projects in the application case by configuring the solution for the projects in question.
The rest of this section presents the requirement model development process (3.1), elements of the requirements model (3.2) and an illustrative example of the actual model (3.3).
Development of the requirements model included a number of phases and iterations.
The development process of the requirements model can to a large extent be
considered as enterprise knowledge modelling process, which was inspired by the
POPS* [
The above phases will be discussed in the following sections.
At the beginning of this phase, a number of preparation steps had to be taken, which were contributing to a joint understanding of visual knowledge modelling – a prerequisite for the later phases. After having identified all team members, they were offered an introduction and basic training in Metis. We started with scaffolding workshops with all team members. The following roles were involved: − Manager – the owner of the application case who is responsible for establishing it at KA, assigning the right personnel resources, arranging meetings, etc. − Planner – responsible the way of working and for establishing a consensus between all partners, coordinating the different tasks, moderating the meetings, etc. − Modelling expert – provides expert knowledge about the method and the tool, − Facilitator – experienced in using the selected modelling process and tool and facilitates model construction and capturing of knowledge in the models − Coach – supports the modelling process by coaching the modellers. − Modeller – develops the enterprise models in Metis during the modelling process. − Domain expert – provides knowledge about the problem domain.
After the preparations, an iterative process started, which at the end resulted in 3 major versions of the scaffolding model. The first modelling step in the first iteration was to clearly define the purpose of the model to be developed. Within the scaffolding phase, the purpose was to model the current situation in the problem area as seen by the different stakeholders from KA, such as R&D manager, engineers with different specialisations, purchaser, customer responsible, etc. Starting from the POPS* approach, relevant perspectives were identified. During this step he initial POPS* perspectives Process, Organisation, Product and Systems were supplemented with other perspectives like Objectives, Technical Approaches or Skills. Definition of additional perspectives was not performed just once, but had to be repeated in every iteration. Between the workshops, the facilitator and the modelling experts checked the jointly developed models and added details such as textual descriptions.
Focus in the scoping phase was on developing initial versions of solution models that specified the intended future way of working in the application case, i.e. the future Process of Innovation (POI) in Advanced Engineering of KA’s business area seat comfort. The resulting solution models should be executable in the MAPPER infrastructure, which required all modelling perspectives to be defined on such a level of detail that they contained all model elements required for execution. In comparison to the scaffolding model, the solution model had to fulfil higher demands with respect to completeness and consistency, e.g. the complete process flow had to be modelled and not just the essential tasks illustrating the way of working.
Due to the needed level of completeness and detail, the way of modelling had to be revised. Instead of only using joint modelling workshops, we first created textual scenario descriptions for all relevant task patterns, which included information about the intended way of working, involved roles, and tools or documents used. They also contained statements explicitly identifying requirements. Based on each scenario description, the facilitator and modelling coach developed a model, which was then refined together with the stakeholders from KA.
The work during the scoping phase was structured by dividing POI into 9 main task patterns and grouping these task patterns into 3 pilot installations.
The requirements modelling and scoping ran partly in parallel. The purpose of the requirements modelling phase was to make requirements to the MAPPER infrastructure and methodology explicit. This phase started with identification of the types of requirements to be captured and with agreeing on how the requirements should be represented in the models. We decided to distinguish between platform, methodology, approach, and solution requirements and to represent them in the model. More details about requirement types and representation are in section 3.2.
Requirements identification was performed in joint workshops with stakeholders from KA and in two ways: (1) analyse the textual scenario descriptions, extract the requirements described there, and add them to the model; (2) review the solution model for each task pattern and check all tasks on all refinement levels for presence of requirements. The resulting requirements were presented to all team members in joint modelling workshops.
Like in scoping, the sequence and structure of requirements modelling was governed by the division into task patterns and pilots.
The requirements consisted of two main elements: textual scenario descriptions and a requirement model. Both are available for the overall POI and for all main tasks contributing to the POI. Regarding these tasks, the intention was not to just divide the POI into sub-tasks, but to produce adaptable models capturing best practices for the task under consideration. The term “task pattern” was then introduced to indicate that these adaptable models are not only valid and applicable in POI, but that they are also relevant for other KA units and processes, and even for the other MAPPER partners or enterprises outside the project. Thus, task pattern is defined as a self-contained model template with well-defined connectors to application environments capturing knowledge about best practices for a clearly defined task, where − “Self-contained” means that a task pattern includes all perspectives, model elements and relationships between the modelled elements required for capturing the knowledge reflecting a best practice. − “Model template” means that the task pattern has to be expressed in a defined modelling language and that no instances are contained in the task patterns. − “Connectors” are model elements that facilitate the adaptation of the task pattern to target application environments. − “Application environments” currently are limited to enterprise models.
Examples for task patterns are “establish material specification”, “develop new test method”, “prototype build” or “establish product specification”. The task patterns and the POI model include four different types of requirements: − Approach requirements are relevant in case different principal approaches for an activity in the application case exist. E.g. line vs. matrix organisation of projects, and room-based vs. message-based support of asynchronous cooperation. − Methodology requirements express any requirement related to methodology use and design, e.g. planned application of (parts of) the MAPPER baseline methodology or required extensions or refinements of the baseline methodology. − Platform requirements include requirements with respect to the MAPPER infrastructure. This part of the model will typically capture which task or activity needs support by what MAPPER service, IT tool or template. − Solution requirements for implementation properties of the solution for a specific project. E.g. which service to use for a project if several equivalent services exist? All requirements from the scenario descriptions are reflected in the requirements model, but not necessarily vice versa. I.e. the requirements model contains additional requirements because the additional requirements emerged in the model development process, which were not clear or visible during the stage of scenario development.
This section presents an overview of the requirements model of the POI (see Figure 1) and introduces the model structure, used for the task pattern models: − The top part shows a container with the requirements that are subdivided into solution, approach, methodology and platform requirements (as introduced in 3.2). − The middle part consists of a container with the actual process model for POI that consists of the tasks: Idea Analysis Phase, Visualisation Phase and Report Phase. At the edges of each process different aspects are represented – control information (top edge), input information (left edge), output of the process (right edge), the roles involved and the resources used (bottom edge). Examples of resources are MAPPER services, other IT-systems or information sources. − The bottom part shows the infrastructure model, which is a sub-model common for all task patterns and POI. The organisation part (to the left) includes the organisational structure of KA, the specific roles required for POI and the task patterns, as well as the skills and competences required for these roles. The infrastructure part (to the right) includes all services and client applications of the MAPPER infrastructure, and the information resources available at KA.
Some of the requirements and the process “Report Phase” are enlarged for this paper. Relations between model objects and requirements (relations from middle part to top part) illustrate the cause for these requirements. Relations between model objects and infrastructure objects (relations from middle part to bottom part) illustrate the use of the infrastructure objects, and are necessary for execution of the models. This section analyses our experiences concerning stakeholder participation in the C3S3P development process and task pattern development. 4.1
Participation of stakeholders from different departments of KA and from different MAPPER partners was considered a key success factor for creating adaptable knowledge models suitable for use in everyday practice. We noted that different participation levels were adequate for the different modelling phases (see section 3.1).
In the initial phase, scaffolding, nearly all stakeholders participated all the time during the model development process. This included presentations from and discussions with KA about the modelling domain, discussions and joint decisions about perspectives to be included in the model, meta-modelling, joint creation, editing and describing of the models with METIS. The produced models were not very large, but in terms of sharing knowledge and creating a joint understanding about the domain and the nature and the EM process, the modelling sessions with all stakeholders were highly valuable. They created a joint ownership of the result. Between the modelling sessions the facilitators refined the model and the meta-model. The subsequent modelling sessions always started by reviewing the model which contributed to a shared understanding and improving the quality of the model.
During the second phase, scoping, the way of working was changed and the level of participation reduced – before developing METIS models, we developed textual scenario descriptions for the task under consideration. The scenario descriptions were developed participatory, but the development of models based on the scenario description was done by the modelling facilitator alone. The reason for this change was the level of detail of the models required by the need to provide executable models. These models included lot of detailed and technical information. Joint editing of such models was perceived too time consuming and did not really concern the stakeholders. The models produced by the facilitator were presented to the other stakeholders for validation and to strengthen the joint ownership of the results.
In the third phase, requirements modelling, the participation level increased again, as all requirements had to be qualified and described. Although most requirement model refinements were done in smaller working groups of 3-4 people, the participation from different stakeholders was of high importance.
We consider this participatory modelling not only positive for the quality of the modelling results itself, but also with regards to the modelling process and the internal dissemination at the use case partner. The way of modelling provided valuable input for the methodology development by confirming the importance of stakeholder participation, scoping, iterative refinement etc. Furthermore, the way of expressing requirements in four different perspectives on both detail levels (task patterns) and in an aggregated way on use case level (requirements matrix) emerged as new practice during the requirements modelling process. We consider this an important experience in requirement structuring and visualization. The involvement of many stakeholders from KA during the complete modelling process also helped to promote MAPPER internally. With a solid understanding of the potential and work practices of model adapted product and process development the KA stakeholders were able to disseminate MAPPER ideas in the organisations, thus contributing to an increased management attention and further internal developments. 4.2
Even though the idea behind task patterns is to identify and capture reusable and generic practices, they are deeply rooted in the individual enterprise processes. Hence, for an external modeller to extract and model the relevant task patterns, an access to the experience and knowledge of KA’s domain experts is an absolute requirement.
The existing scenario descriptions provided a good starting point in facilitating a top-down modelling approach. For each task pattern the outline was built initially. The modelling was not always performed strictly top-down. Sometimes defining the content of a task led to changes at a higher level, e.g. in some cases the headings from the outline were changed upon defining the scenario content. In other cases when revising the content a more suitable heading could be found. The order in the resulting outlines can be characterized by a generic sequence – prepare, conduct and report.
. The textual descriptions originally focused mainly on task breakdown structure and were less expressive about task sequence, resources, inputs and outputs. While modelling task patterns, new ideas and questions emerged leading to refinements of the textual descriptions. This shifting of focus took several iterations.
The number of requirements for the execution environment where not multiplied by the number of task patterns because they shared certain requirements.
We have analysed how the C3S3P EM approach has been applied in an automotive supplier company and presented the phases of the C3S3P development process such as Concept Study, Scaffolding, Scoping, and Requirements Modelling. In the MAPPER project we have also introduced the concept of a task pattern for capturing, documenting and sharing best practices concerning business processes in organisation. On the basis of this application case we have analysed our experiences concerning stakeholder participation and task pattern development.
We will further develop the requirements model during the planned pilots in terms of requirement change management and tracking of the requirements document.
Future work in the application case will focus on the C3S3P modelling process and on task patterns. When starting the development of task patterns, we had in mind to capture knowledge about best practices in handy, flexible models that can be put in a library and used on-demand by selecting, instantiating and executing them. This basic idea has resulted in 9 task patterns. In order to transfer them to other organisations, adaptation mechanisms will have to be defined. Furthermore, we will have to investigate, from a methodological point of view how adaptation to substantial changes in the infrastructure should be best facilitated, how patterns can be combined and integrated, as well as how to support pattern evolution.