Robert Andrei Buchmann
email: robert.buchmann@econ.ubbcluj.ro

Dimitris Karagiannis

Agile Modelling Method Engineering: Lessons Learned in the ComVantage Research Project

Keywords: Agile modelling method engineering, enterprise modelling, metamodelling, modelling requirements

The paper reports on experiences accumulated during a EU research project where challenges pertaining to requirements-driven metamodelling agility have been analysed. Traditionally, modelling languages are perceived as stable artefacts -that is, if they address a sufficiently large community with fixed modelling requirements on a fixed layer of abstraction. However, the enterprise modelling community must also consider the case where evolving requirements emerge in a narrow domain, or even in a single enterprise, therefore reusability across domains will be sacrificed to the benefit of on-demand adaptation, specialization or integration. Under such conditions, an agile metamodelling approach was applied in the ComVantage project and this, in turn, raised specific requirements for conceptual and technological enablers, allowing us to derive conclusions that are generalized here beyond the project scope. The paper's concluding SWOT analysis highlights the need to stimulate the emergence of an agile metamodelling paradigm based on community-driven enablers.

Introduction

Diagrammatic conceptual modelling has been concerned with standardization even from its earliest days, when the first draft of "process chart" symbols [START_REF] Gilbreth | Process Charts[END_REF] was presented to the American Society of Mechanical Engineers (ASME), with a subtitle suggesting optimality: "Process Charts -First Steps in Finding the One Best Way to Do Work". According to the authors, the process charts were "a device for visualizing a process as means for improving it" and, for this purpose, an initial set of quite arbitrarily chosen symbols was proposed. The set of symbols was further developed by ASME in a new set of flowcharting symbols whose key quality was that they could be drawn by engineers using crayon and "template rulers". Later, Von Neumann adopted these to describe the first programs in a control flow visualization style. Many years later, standards like UML and BPMN still inherit the rhombus shape for decision concepts (and other such "legacy symbols") as part of standardized notations. Howev-er, computer-aided diagrammatic modelling can now benefit from enriching notation with a variety of features, such as: interactivity (symbols acting as hyperlinks), dynamics (symbols changing based on some machine-readable properties or semantics), visual semantics (information communicated through ornamental aspects, or even animation). None of these had been possible in the days of crayon and template rulers, and the variety of available options in this respect is nowadays subject to modelling requirements, together with other customization needs of the targeted users (modellers) pertaining to (i) model-driven functionality, (ii) semantic coverage of models or (iii) the depth of domain-specificity.

As software engineering recognized the unstable nature of requirements and the competitive value of flexible response to evolving requirements, the Agile Manifesto [START_REF]Manifesto for Agile Software Development[END_REF] and community emerged to challenge the traditional rigid ways of building software. Similar challenges can be met with respect to modelling requirements in the practice of modelling method engineering, particularly in its application for enterprise modelling. Consequently, an Agile Modelling Method Engineering (AMME) approach and its enablers must be consolidated from experience reports such as the one to be provided in the work at hand.

The goal of this paper is to share metamodelling experiences from our research on modelling virtual enterprises in the ComVantage research project [START_REF]ComVantage public deliverables[END_REF], consequently highlighting characteristics of AMME as a key methodological necessity. In order to establish the motivation, we will introduce the improvised term "ComVantage enterprise" and compile its characteristics and challenges that must be tackled with an AMME approach. A modelling method and prototype was developed for the mentioned project within the environment provided by the Open Model Initiative Laboratory [START_REF]Open Model Initiative Laboratory, ComVantage modelling prototype and resources[END_REF], and the paper reflects back on this development experience.

The remainder of the paper is structured as follows: Section 2 provides a brief project overview and, as a generalized motivation, compiles the enterprise characteristics that require an AMME approach. Section 3 provides an overview on the emerging AMME approach and its key enablers. Section 4 reports on experiences with AMME in relation to examples extracted from the ComVantage modelling method. Section 5 positions the paper in the context of related works. The final section generalizes conclusions beyond the project scope.

Motivational Characteristics of a "ComVantage Enterprise"

In this section we will compile characteristics for a "ComVantage enterprise" from the project experience, as well as by instantiating features identified in research roadmaps provided by European research clusters where the project took part -e.g., FInES [START_REF]Future Internet Enterprise Systems cluster, The FInES Research Roadmap[END_REF].

The ComVantage research project aimed to support collaborative business processes in virtual enterprises with adaptive mobile technology driven by models designed with the domain-specific "ComVantage modelling method". The modelling method had to be developed iteratively, as requirements evolved and the development of run-time systems also imposed an incremental iterative approach. Details on different snapshots of the evolving modelling method are available in deliverables [START_REF]ComVantage public deliverables[END_REF] (de-liverables D311, D312) and previous publications [START_REF] Buchmann | Conceptual modeling for mobile maintenance: the ComVantage case[END_REF][START_REF] Buchmann | Modelling Mobile App Requirements for Semantic Traceability[END_REF]. In this paper we will only provide insight for a few modelling elements in order to derive key characteristics for AMME. In the following, we highlight the enterprise characteristics that must be tackled by the AMME approach:

A. Modelling is employed as knowledge representation. Historically, model-driven software engineering employed models in different ways, as highlighted by Table 1. The "modelling is programming" paradigm [START_REF] Aquino | Conceptual modelling of interaction[END_REF] uses models for generation of executable code. This vision was later complemented by a "modelling is configuration" approach, having run-time systems parameterized with model information and models acting as "control panels" to influence run-time behaviour -e.g., in the context of process-aware information systems [START_REF] Van Der Aalst | Process-aware informations systems: lessons to be learned from process mining[END_REF], with the help of XML model serializations such as BPEL [START_REF] Van Der Aalst | BPEL -the official website[END_REF]). As enterprise modelling expanded beyond the goals of business process management in order to build a holistic representation of the enterprise, diagrammatic models became means of capturing the knowledge of stakeholders on different enterprise aspects (e.g. processes, goals, capabilities). Relevance to AMME: AMME is called to ensure that the necessary semantics is captured, in relation to modelling needs that may evolve as users become accustomed to modelling. On the side of stakeholders, inexperienced modellers will gradually raise requirements for deeper specialization of modelling concepts (deepening domain-specificity), while the modelling method engineer can be confronted with gradual understanding of the application domain. B. Semantics-awareness is required for run-time enterprise systems. The functionality of enterprise systems can be, at execution time, sensitive to machinereadable semantics captured in various forms. Typically such semantic representations are nowadays available in a new type of semantic networks (the Linked Enterprise Data paradigm [START_REF]Linking Enterprise Data[END_REF]), possibly enriched by ontologies and rules to enable reasoning over the Web of Data. Alternatively, information systems may also be sensitive to the semantics captured in diagrammatic form by enterprise models (with the modelling language alphabet acting as a "terminological box") -that is, if relevant granularity is ensured, and a machine-readable model repository is provided.

Relevance to AMME: AMME is called to ensure that changes in requirements for the run-time enterprise system propagate accordingly to modelling requirements so that the necessary properties are assimilated in the modelling language (to become accessible at run-time).

C. Scenario-driven requirements for run-time systems means that run-time requirements should be built around work processes and work capabilities rather than around disparate use cases. While traditional requirements elicitation practices used to advocate atomization of user stories, the increasing experience of stakeholders with business process management may be leveraged in order to capture requirements in control flow representations mapped on resource/capability requirements. Agile software engineering already recognized this by aggregating requirements in narrative units such as stories and epics. Relevance to AMME: As [START_REF] Kaindl | On confusion between requirements and their representations[END_REF] emphasizes, requirements elicitation does not produce requirements per se, but requirements representations, whose descriptions may involve domain-specific concepts and properties relative to the business context. AMME is called to provide agile modelling means for collecting enterprise system requirements that include domain-specific aspects, thus bridging the gap between stakeholders and system developers [START_REF] Buchmann | Modelling Mobile App Requirements for Semantic Traceability[END_REF].

D. Complexity management challenges.

Although modelling typically means abstraction and simplification, in enterprise modelling even the model is too complex to be comprehensive in a single diagrammatic representation. Enterprise models are partitioned in different facets/layers across different abstraction layers or viewpoints (see Archimate [START_REF]The Open Group, ArchiMate® 2.1 Specification[END_REF], Zachman [START_REF] Zachman | A framework for information systems architecture[END_REF]). Since diagrammatic enterprise models are subjected to human interpretation, an inherent decomposition requirement must ensure model understandability and should be satisfied both on the meta level (e.g., by partitioning a metamodel in multiple model types) and on the model level (e.g., decomposing a business process model in subprocesses). Relevance to AMME: AMME is called to identify building blocks of manageable granularity for both modellers (to help with model comprehension) and metamodellers (to help defining backlog units). Such building blocks will make it possible to isolate evolving modelling requirements so that an agile response to changes does not affect the entire method and change propagations become traceable.

E. Domain-specific modelling requirements.

Enterprise models can be specialized and contextual, and it is plausible to have an enterprise modelling method adopted in a narrow community, or even for a single case/project, where the enterprise is interested in employing models for internal purposes (e.g., as input for a custom modelaware run-time system), with no desire for sharing and reusing them in the external environment. Relevance to AMME: In domain-specific modelling, the level of concept specialization is not necessarily fixed, as new properties and subtyping may be gradually required to achieve new capabilities and the proverbial "competitive advantage" of agile development. AMME is called to ensure that such evolving specialization is assimilated in the method in a timely manner.

3

The AMME Framework

Framework Overview

Without going point by point through the Agile Manifesto [START_REF]Manifesto for Agile Software Development[END_REF], we highlight the key characteristics of Agile development as compiled by [START_REF]Agile Alliance[END_REF]:

• Iterative: repeat activities and potentially revisit same work products;

• Incremental: each successive version is usable and builds upon previous versions;

• Version control: enable for other agile practices;

• Team control: small group of people assigned to the same project building block with shared accountability.

In order to achieve agility in Modelling Method Engineering, such principles must be grafted on the fundamentals of modelling method design, considering the building blocks defined in [START_REF] Karagiannis | Metamodeling Platforms[END_REF], described as follows:

(1) The modelling language describes the set of modelling constructs (their notation, grammar and semantics. To achieve manageable granularity and model comprehensibility, the modelling language can be partitioned in model types addressing different facets or abstraction layers of the system under study. The partitioning can be perceived as a usability feature (a top-down decomposition approach to avoid visual cluttering) or a consequence of hybridization (a bottom-up strategy employed to interconnect modelling language fragments).

(2) The modelling procedure defines the steps that must be taken by modellers towards some goal (in the simplest case, it advises on the precedence in creating different types of models).

(3) The mechanisms and algorithms cover functionality that process model information for various purposes (visualization, transformation, evaluation etc.).

Agility relies on iterative incremental cycles integrated in a high level framework such as the one depicted in Fig. 1.

In the centre, the modelling method evolves in a Produce-Use metamodelling cycle (by analogy with the Code-Test cycle): (i) in the top phase, the modelling language is derived from so called "Models of Concepts" that capture the domain knowledge and structure it in modelling constructs (the language alphabet); (ii) in the lower phase, each iteration of the modelling method is implemented in a modelling tool that allows the creation and evaluation of enterprise models ("Models that Use Concepts") by instantiating the concepts designed in the previous phase/ For this cycle, the Application Environment raises modelling requirements and provides domain knowledge, while in the backend a Knowledge and Resource Repository accumulates reusable resources and lessons learned. In our case the Knowledge and Resource Repository is accumulated through the Open Model Initiative Laboratory, a physical and virtual research environment that also hosts an implementation of the ComVantage modelling prototype [START_REF]Open Model Initiative Laboratory, ComVantage modelling prototype and resources[END_REF] (which still evolves in follow-up projects).

Conceptual Enablers

During the Produce phase of the cycle depicted in Fig. 1, a knowledge acquisition effort will produce a "Model of Concepts" to describe the enterprise ontologically. A practical requirement for decomposition naturally emerges in order to ensure model comprehensibility and a usable separation of concerns. The solutions that fulfil the decomposition requirement are also the basis of establishing a manageable backlog granularity during AMME, beyond the building blocks suggested in Section 3.1. A generic classification scheme for different kinds of units (content containers) is provided in Fig. 2.

On the top layer: Asemantic containers provide a grouping of modelling constructs without assigning explicit machine-readable semantics to this grouping, unlike the semantic containers which have to their content a richer relation than the generic mereological one ("part-of"/"contains"). Depending on how containers are perceived, we may have visual containers (visual partitions sectioning the modelling canvas according to some criteria, e.g. business process swimlanes) or functional containers (an entire model). With respect to how the contents of a container are related to the exterior of that container, we may have related content (through machine-readable relations) or isolated content.

On the lower layer, the container types are further subsumed to more specialized building blocks: for example swimlanes/pools in business process models are typically unspecified visual containers (their meaning can be left to human interpretation). However, depending on the freedom of interpretation to be allowed, the relation of a swimlane to its contents may also be prescribed at metamodel level, by imposing semantics on this containment (e.g., a machine-readable link to an organisational unit). A more complex type of container is the model type, used when the enterprise modelling language has the alphabet split into problem-specific subsets. These are semantic containers in the sense that they have a clear meta-level specification of what concepts are allowed in each type of model, as well as constrained relations (links) to other models. If such a specification does not exist, we are talking about unprescribed canvas (e.g. Powerpoint-style free sketches). Each concept in a model type becomes a semantic unit, and its properties must be traced to detect propagation of changing requirements, as will be shown in Section 4. Further (implementationspecific) specialization is suggested in Fig. 2, however it will not be detailed here since it depends on the intended depth of domain-specificity on a case by case basis.

Fig. 2. A taxonomy of modelling units to tackle the decomposition requirement

Technological Enablers

Rapid prototyping is a key necessity for producing iterative prototypes that meet gradually refined requirements, even "throwaway prototypes" aimed to (i) familiarize inexperienced modellers with what they can expect from the final implementation and to (ii) stimulate their ability to formulate modelling requirements. The practice of metamodelling has answered such necessities and nowadays we see an increasing popularity of platforms that provide built-in functionality for productive development of modelling tools according to some existing conceptualisation (e.g., ADOxx [START_REF]ADOxx tool page[END_REF], MetaEdit+ [START_REF] Metacase | MetaEdit+ tool page[END_REF]). Each available metamodelling platforms relies on a meta 2 model providing primitive built-in constructs (e.g., concept, connector) to create "Models of Concepts". As a complement to the available metamodelling platforms, specifically aimed to support rapid cross-platform prototyping, we have proposed in [START_REF] Visic | A domain-specific language for modelling method definition: from requirements to grammar[END_REF] an additional abstraction layer where a modelling method can be described in a declarative language (MM-DSL, Fig. 3) built on a common subset of primitives of the popular meta 2 models. A draft of the language grammar is openly available at [START_REF]The MM-DSL grammar specification[END_REF]. Rapid prototyping is enabled by compilers that translate MM-DSL code to a platform-specific format for the metamodelling platform of choice in order to produce modelling prototypes in a highly automated way (a proof-of-concept compiler is currently available only for ADOxx deployment, with additional compilers expected to emerge from the OMILab community).

AMME: The ComVantage Case

Enterprise modelling methods typically show a recurring frame of facets/layers/viewpoints and this was also adopted in the ComVantage modelling method, as its metamodel is split in various enterprise facets -the business model, business processes, app and data requirements (due to the project's technological specificity), models of domain-specific resources. Semantic relations are present in the form of hyperlinks that allow navigability across models and at the same time characterize the semantics of how the different facets (typically covered by different model types) are related one to another. We will not discuss here the entire metamodel layering (details available in public deliverables [3, D312]), only some fragments that illustrate the modelling requirements evolution and its propagation in the method building blocks. Since decomposition is a key enabler for agility, the modelling method building blocks must be mapped on backlog tasks and sprint responsibilities. Metamodellers Requirements for (semantics-aware) run-time systems will propagate in requirements for semantics available in models; 2. Requirements on mechanisms and algorithms typically propagate in requirements for new properties or concepts in the language (to provide additional input to functionality); 3. Requirements on notation change quite often, as most users perceive modelling primarily on a visual level. Change requests on notation level typically propagate in the other building blocks, e.g.: (i) dynamic or interactive notations will depend on the presence of some property in the concept semantics; (ii) excessive visual cluttering will be solved by splitting a model type in multiple model types, also raising new integration needs (hyperlinks between models); 4. Requirements on a model type typically propagate in other related model types, as concepts are transferred among model types to reduce the linking effort, or new concepts are introduced; 5. The modelling procedure typically takes the form of modelling guidelines, therefore usually there are no direct requirements on the modelling procedure. However, users may impose requirements in the form of constraints, which are quite volatile in nature (e.g., "I don't want to have more than 5 model types"). More importantly, such constraints refer to usability and the automation of some procedure steps (e.g., "I don't want to create models of type X. Instead, they should be generated automatically") and this typically propagates towards additional functionality; 6. Any changes in the modelling language and functionality propagate in the modelling procedure guidelines.

A core concept of the method is the App requirement concept aiming to capture, at business process level, what kinds of mobile apps are required to support specific business activities. As an app-centred run-time architecture was being developed in the project, the modelling requirements on how the "required apps" should be described evolved. Table 2 illustrates this evolution along 5 phases, while the subsequent figures reflect how the concept evolved on a diagrammatic level.

Phase2

The mobile app requirement should be symbolised by its own concept with domain-specific properties to describe the required app.

All semantics pertaining to the app requirements are isolated in a new app concept. Apps are visually connected to activities to indicate where a mobile app is required. Each app symbol is further described by its own property sheet capturing various non-functional requirements (e.g., device type, operating system).

The concept of Activity loses some properties. The App concept is added to the language alphabet (i.e., to the business process model type), with new editable properties. The modelling procedure guidelines must reflect the new way of connecting app requirements to activities.

Phase3

To avoid visual cluttering, the mobile app symbols should be linked outside the business process modelling canvas and collected in a pool of reusable app requirements.

A new model type is created to collect the app symbols in a single catalogue of "required apps". The notation in the business process activity provides a hyperlink to easily navigate to the app description linked to each activity. This is visible in Fig. 6 as an app icon in the top left corner of the appsupported activities.

The business process model type is split, so that a new model type will include only the app symbols. The connector between activities and apps is replaced by a hyperlink between the two model types (on the Activity notation). The modelling procedure guidelines must be updated with the new way of linking app requirements, as well as with the prerequisite of having an app element available before a hyperlink is created for it.

Phase4

Each required mobile app should be further described by its features in the form of abstract user interaction elements of different types (e.g., buttons, labels etc.). This requirement aims to provide a basis for early mockup designs for the required app, thus making the elicitation of app requirements "bleed into" the app design phase.

A new model type is added to describe an abstract user interface (similar to the "abstract UI" concept in the Cameleon framework [START_REF] Calvary | A unifying reference framework for multi-target user interfaces[END_REF]). This expresses the key app features that must be available for user interaction in each required app.

The metamodel is extended with a new model type, describing an app user interface in terms of some abstract types of UI controls (a taxonomy of such controls must be devised). A hyperlink is enabled between app symbols and such UI models. The modelling procedure guidelines must include explanations on the proposed taxonomy of UI controls and how the new type of model should be linked.

Phase5

An external app orchestration system will automatically deploy and execute mobile apps that are chained according to the workflow dictated by the business process model. The orchestration engine should be modelaware in the sense that the precedence of app chaining must be dictated by the precedence of the apps modelled for the business process (details in [START_REF] Ziegler | Beyond app-chaining -mobile app orchestration for efficient model driven software generation[END_REF]).

(a) A new model type depicts the app precedence; (b) Functionality for automated derivation of the app precedence from existing business process models; (c) Functionality for exporting the resulted diagrams in a serialization format that can be queried by the app orchestration engine responsible with app deployment (RDF [START_REF]RDF 1.1 Concepts and Abstract Syntax[END_REF] was the format of choice).

The metamodel is extended with a new model type (the "orchestration", describing the precedence of app usage for a business process. A mechanism is needed to derive such models from business process models, in order to ensure their consistency. Another mechanism is created to serialize the contents of models in some query-able format, to facilitate the extraction of semantics from the model information). Modelling procedure guidelines must be updated to (a) instruct the user in using these mechanisms; (b) instruct the run-time system developer on the RDF vocabulary that must be used to build model queries.

Fig. 5 shows how the app requirement description evolved between Phases 1 and 2, from an editable property of a process activity to a modelling symbol with its own domain-specific editable properties (the blue boxes are mock-ups of the property sheets). 6 shows the additional model types that emerged from Phases 3 and 4 (the pool of required apps isolated from the business process model, and the abstract UI model for each app), as well as the types of links that can be created between models (see the legend). Fig. 7 shows the orchestration model type emerging in Phase 5 as a necessity for exposing the app usage precedence to the run-time system (run-time orchestrated apps [START_REF] Ziegler | Beyond app-chaining -mobile app orchestration for efficient model driven software generation[END_REF]). The sample model in Fig. 7 is generated automatically via a graph rewriting rule set applied on the business process model example in Fig. 6 (details on the transformation are out of this paper's scope, being available in [START_REF] Buchmann | Modelling Mobile App Requirements for Semantic Traceability[END_REF]).

Related Works

To the best of our knowledge, the framework of Agile Modelling Method Engineering was initially outlined on a generic level in some of our previous work -the published keynote [START_REF] Karagiannis | Agile Modelling Method Engineering[END_REF] and the works of the NEMO (Next Generation Enterprise Modelling) Summer School [START_REF]NEMO 2015 Summer School materials[END_REF], with some characteristics being suggested (in the context of fast prototyping) in [START_REF] Visic | A domain-specific language for modelling method definition: from requirements to grammar[END_REF]. This paper is distinguished from the mentioned works by (a) reporting on experiences from an application case of the generic AMME framework, with respect to challenges identified in the ComVantage research project (the case discussed in Section 4); (b) refining the characteristics of a "Next Generation Enterprise" by anchoring them in characteristics of enterprises involved in the discussed project (Section 2); and (c) providing details on the conceptual and technological enablers (Sections 3.2 and 3.3).

However, the AMME framework builds on agility challenges identified in other related works, since it emerged from a multi-disciplinary convergence of concerns previously discussed in the fields of Metamodelling and Enterprise Modelling:

Agility challenges, as well as model complexity challenges, have been discussed in the field of Metamodelling with respect to improving productivity for multiperspective modelling [START_REF] Frank | Multi-Perspective Enterprise Modeling: Conceptual Framework and Modeling Languages[END_REF], domain-specific multi-level modelling [START_REF] Frank | Multilevel Modeling: Toward a New Paradigm of Conceptual Modeling and Information Systems Design[END_REF], as well as in a metamodelling interpretation on Language-oriented Programming [START_REF] Clark | Applied metamodelling: a foundation for language driven development[END_REF]. Metamodelling itself, as a discipline, emerged from the need to enable flexibility in modelling language design through a multi-layered abstraction architecture (e.g., the "powertype" approach [START_REF] Gonzalez-Perez | Metamodelling for software engineering[END_REF], the MetaEdit+ approach [START_REF] Kelly | MetaEdit+ a Fully Configurable Multi-user and Multitool CASE and CAME Environment[END_REF]). This, however, has not been complemented yet by a fully-fledged methodological agile approach that mirrors the agility principles and challenges from software development. Project-based experiences are necessary to bring forth the kind of reflections that fuelled the agile movement in software engineering, since the Agile Manifesto mainly evolved from pragmatic needs of practitioners who questioned the obstacles and pitfalls of rigid management approaches (e.g., the waterfall approach).

The discipline of Enterprise Modelling recognizes a need for semantic as well as notational diversity, since a multitude of enterprise architectures and frameworks have been established and are widely adopted (e.g., EKD [START_REF] Loucopoulos | Enterprise Knowledge Management and Conceptual Modelling[END_REF], ArchiMate [START_REF]The Open Group, ArchiMate® 2.1 Specification[END_REF], Zachman [START_REF] Zachman | A framework for information systems architecture[END_REF], more recently capability-driven approaches [START_REF] Zdravkovic | Requirements Engineering for Capability Driven Development[END_REF]). However, the paradigm of Enterprise Modelling traditionally obscures the notion of evolving modelling requirements which is central to AMME, as it requires dedicated management strategies. This is perhaps due to ambitions for standardization, which is in line with the original goal of ASME process charts on enabling "the best way to do work". The work at hand aims to stimulate the assimilation of "unstable" domain-specificity (or even case-specificity) that must extend high-level enterprise architecture models in response to changing requirements.

Concluding SWOT Analysis

Just like the Agile Manifesto for software development, the notion of AMME is consolidated not only from theoretical analysis, but also from reflecting back on obstacles and experiences with metamodelling projects. Experiences with the ComVantage research project show a practical AMME instantiation and have been synthesized in the work at hand. Consequently, AMME is hereby analysed qualitatively as a foundational notion with an early-stage maturity level on which future work is called to further establish enablers. By paralleling the principles of Agile software development, methodological or technological enablers are expected to emerge from communitydriven efforts and shared experiences: management support tools, rapid prototyping enablers, validation methodologies, reports on agile best practices or agility pitfalls. Since we are not dealing yet with a wide adoption of AMME, it is too early to assess comparative experience reports. A SWOT analysis is hereby provided to evaluate the success of AMME for the instance experience:

Strengths: AMME was a necessity for enabling the evolution of Enterprise Modelling requirements and for dealing with their multi-faceted nature, as multiple types of stakeholders have been involved, from design-time decision makers (aiming for model analysis) to run-time system users (relying on machine-readable model semantics). Conceptual and technological enablers supported the agile approach and brought forward the need for a mature agile approach to metamodeling.

Weaknesses: The experience with applying AMME is still limited to OMILab projects. Its application to ComVantage emerged as a necessity driven by unstable requirements. The main identified pitfalls are (a) that synchronicity with the development of the run-time systems relying on model information is difficult to maintain if not planned from the very beginning; and (b) an evaluation methodology for user acceptance involves a training phase that can create bottlenecks, as stakeholders are called to frequently re-learn the modelling language. In addition, aspects pertaining to the management of human resources in agile teams have not been tackled in this paper. Future works must consider strategies to tackle such challenges.

Opportunities: The evolution of the Agile software development practices and tool support was fundamentally community-driven. Future work may be layered on the conceptual foundation established by the work at hand in order to enrich AMME as a community-driven framework, to raise its maturity level, to enrich tool support and to enable longitudinal studies for further refinement.

Threats: Standards typically defuse the problems raised in the work at hand by bringing all potential users on the same level of abstraction and encouraging universal adoption for the benefit of reusability across domains. Therefore, the generalized relevance of the work at hand depends on the desired trade-off between reusability and domain specialization, as well as on the uptake of semantics-aware information systems whose evolving requirements are an inherent cause for propagating modelling requirements.

Fig. 1 .

 1 Fig. 1. The AMME Framework (adapted from [17])

Fig. 3 .

 3 Fig. 3. The blocks of modelling method definition with MM-DSL (details on code snippets and grammar available in [20-21])

Fig. 4 .

 4 Fig. 4. Propagation of modelling requirements across method building blocks 1. Requirements for (semantics-aware) run-time systems will propagate in requirements for semantics available in models; 2. Requirements on mechanisms and algorithms typically propagate in requirements for new properties or concepts in the language (to provide additional input to functionality); 3. Requirements on notation change quite often, as most users perceive modelling primarily on a visual level. Change requests on notation level typically propagate in the other building blocks, e.g.: (i) dynamic or interactive notations will depend on the presence of some property in the concept semantics; (ii) excessive visual cluttering will be solved by splitting a model type in multiple model types, also raising new integration needs (hyperlinks between models); 4. Requirements on a model type typically propagate in other related model types, as concepts are transferred among model types to reduce the linking effort, or new concepts are introduced; 5. The modelling procedure typically takes the form of modelling guidelines, therefore usually there are no direct requirements on the modelling procedure. However, users may impose requirements in the form of constraints, which are quite volatile

Fig. 5 .

 5 Fig. 5. Descriptive property evolves into modelling concept (Phase 1-2 requirements) Fig.6shows the additional model types that emerged from Phases 3 and 4 (the pool of required apps isolated from the business process model, and the abstract UI model for each app), as well as the types of links that can be created between models (see the

Fig. 6 .Fig. 7 .

 67 Fig. 6. Modelling concept evolves into linked model type (Phase 3-4 requirements)

Table 1 .

 1 The different stages of model-

driven software engineering How models are employed Relation to run-time Systems Pre-condition

	Modelling is	Run-time code is generated from	All information necessary in the
	Programming	model	final code is available, explicitly or
			implicitly, in models
	Modelling is	Run-time system is parameterized	Model information can be serialized
	Configuration	and its execution driven by model	in some interoperable format, typi-
		information	cally XML
	Modelling is	Run-time system functionality is	Model information can be converted
	Knowledge representation	influenced by properties, concepts	to	some	machine-readable
		and reasoning based on the seman-	knowledge base (that supports
		tics captured in models	querying and reasoning)

Table 2 .

 2 Evolving "required App" concept in relation to modelling requirements

	Modelling Requirement	Solution	Propagations to backlog
			items
	Phase1 The business process activities	The concept of business process	The concept of Activity in the
	should indicate when an activity	Activity gets some editable proper-	business process model type is
	must be supported by a mobile	ties where the modeller (e.g, app	extended with new properties. The
	app.	requirements elicitator) captures	modelling procedure guidelines
		descriptions of the app capabilities	must indicate how the app require-
		required to support that activity.	ments are expressed (see a mockup
			in Fig. 5)

Acknowledgment

The research leading to these results was funded by the European Community's Seventh Framework Programme under grant agreement no. FP7-284928 ComVantage.


Anne Persson
email: anne.persson@his.se

Anniken Karlsen

Kristens Gudfinnsson
email: kristens.gudfinnsson@his.se

Towards A Generic Goal Model to Support Continuous Improvement in SME Construction Companies

Keywords: Goal model, enterprise modeling, continuous improvement, SME construction companies

Small and medium sized (SME) construction companies are often good at bricks, mortar and carpentry but not at management. However, it is often bad management that hinders companies to become financially sustainable over time and to grow. This paper presents a generic goal model aiming to support SME construction companies to systematically work with continuous improvement towards the overarching goal of becoming thriving businesses. The goal model has been developed based on the principles of lean, balanced scorecards and the business canvas, as well as on a management consultant's experiences from working with this kind of companies for many years.

Introduction

Small and medium sized (SME) enterprises are a key driver for economic growth in Europe [START_REF]Small and medium-sized enterprises[END_REF]. In order to stay competitive and profitable, SMEs, like larger organizations, must meet the requirements and demands of a rapidly changing market. SME construction companies are no different. For many years, construction companies have had a poor reputation for coping with the adverse effects of change with many projects unable to meet deadlines, cost and quality targets [START_REF] Smith | Managing risk in construction projects[END_REF]. Even more serious is the fact that many companies, particularly small ones, are going bankrupt in an industry that has a great influence on nations' gross domestic product [START_REF] Love | An exploratory study of information technology evaluation and benefits management practices of SMEs in the construction sector[END_REF].

Due to this, top-level concerns for both business executives and national authorities are how to turn construction companies into profitable and well-run businesses and to keep them that way over time. Particularly the SME construction companies, struggle with low profits and many are going bankrupt, adding people to the unemployment lines. In many cases this is due to lack of control systems and proper information for decision-making.

In the work leading up to this paper we have noticed that for a small construction company one or two problematic projects can actually tip the scale towards severe financial crisis. Practitioners have reported to us that many SME construction companies are good at "bricks, mortar and carpentry", but not at management. This becomes devastating in a situation where companies not only have to manage each project individually, but must also be able to handle project portfolios with complex dependencies between projects. Hence, the potential for improving the management aspect of construction companies is great. Such improvement should, however, be done orderly and with a long-term perspective, which implies setting up orderly schemes for continuous improvement.

In this paper we propose a generic goal model that is aimed to somewhat alleviate this problematic situation in SME construction companies by providing a framework for continuous improvement. The model is the backbone of a method for continuous improvement to be used in SME construction companies, the SmallBuild+ method. The method has been developed within a EUREKA Eurostars project.

The remainder of the paper is organized as follows. Section 2 provides the theoretical background of the work. In section 3 the approach to developing the proposed goal model is described. The generic goal model is presented in section 4, together with some suggestions on how to use it, also in relation to tool support. Finally, some aspects of further evaluation and future outlook are discussed in section 5.

Theoretical Background

In this section we describe the background to the work presented in this paper. We describe the situation of SME construction companies and some challenges they face in their continuous improvement efforts. The approach proposed in the paper is based on a generic goal model. The use of such models to support continuous improvement is also discussed.

Challenges of SME Construction Companies

The building and property industry is a large, fragmented and complex industry. It is also an important policy area affecting all sectors of the society. The wealth creation of society is among others dependent on the construction industry delivering wellfunctioning buildings and infrastructure to businesses, industry, public entities, private individuals and society [START_REF]The Bygg21 strategy report[END_REF]. As an example, in 2014 the construction of 25,404 homes was initiated in Norway alone.

Continuing with Norway as an example, the following list indicates some major challenges facing the industry [START_REF]The Bygg21 strategy report[END_REF]. We believe that it is fair to assume that the situation is similar in other countries. 1. Productivity growth seems to be too weak. 2. Building and construction processes are characterized by many quality deviations, errors and omissions.

3. The industry is characterized by fragmented purchasing and low procurement expertise leading to a non-holistic overall cost focus, contributing to short-term investments. 4. The industry has a too low rate of innovation. There is broad consensus in the industry that the industry must get better at taking innovations in use. 5. Parts of the industry are characterized by too many unethical practices. 6. Production processes are characterized by weak interaction. Widespread use of detailed contracts, selecting suppliers based on the lowest price, combined with split purchasing, provides many changes, additions and conflicts that generate distrust and weakened interactions. 7. The construction process is hampered by too many delayed and costly regulations and rules and different interpretations of these. In addition to this, a sector study by e-Business W@tch [START_REF]Business W@tch[END_REF] identified the issues of improving ICT skills, increasing the awareness of ICT benefits and potentials, and facilitating interoperability are identified as relevant construction sector policy initiatives. Although the study is 10 years old, our experience shows that this is still the case.

Olawale and Sun [START_REF] Olawale | Cost and time control of construction projects: Inhibiting factors and mitigating measures in practice[END_REF] conducted a survey of 250 construction project organizations in the UK, which was followed by face-to-face interviews with experienced practitioners from fifteen of these organizations. They found that the top five factors inhibiting effective project cost and time control, are all project internal elements and that quite often programs are drawn upon gut feeling. This is in contrast to previous studies where many external aspects are cited as the most important factors, such as inflation, material shortage, unforeseen ground conditions, inclement climate, etc. [START_REF] Olawale | Cost and time control of construction projects: Inhibiting factors and mitigating measures in practice[END_REF].

For many years construction companies have had a poor reputation for coping with the adverse effects of change with several projects unable to meet deadlines, cost and quality targets [START_REF] Smith | Managing risk in construction projects[END_REF]. Even more serious is the matter that many are going bankrupt within an industry that possibly influences an economy's gross domestic product more than any other [START_REF] Love | An exploratory study of information technology evaluationand benefits management practices of SMEs in the construction sector[END_REF]. This is particularly the case with small and medium sized companies (SME). Due to this, top-level concerns for both business executives and others are how to turnaround the construction companies to profitable and well-run businesses and keep them that way.

Morris and Pinto [START_REF] Morris | The Wiley Guide to managing projects[END_REF] investigated data on project overruns from 3600 projects and concluded that project managers also need to look into the organizational business contexts within which projects are managed. This aspect is highlighted by Aarseth [START_REF] Aarseth | Project Management -A New Mindset for Success[END_REF] who presents findings from interviews conducted with hundreds of project managers and project team members suggesting that the task perspective, time schedule and scope, is not sufficient when the context of the project is complex. Just as important are focus on business relationship management, cooperation between the project, the people and companies in the project and the external environment, organizations and context [START_REF] Aarseth | Project Management -A New Mindset for Success[END_REF].

Obviously, construction projects seldom can be handled one by one along a timeline. Instead they are usually parts of project portfolios where a number of projects continually must be analyzed, invested in and developed in concert [START_REF] Hernández | A Portfolio Inspired Metric for Project Selection in Construction Management, Organization, technology and management in construction -An international[END_REF]. Within these portfolios each project are likely to be subject to uncertainty and risk as regards cost, time and quality [START_REF] Smith | Managing risk in construction projects[END_REF]. Therefore, managers must know which projects the company is involved in, which stage each project has reached, who is involved in each project, capital-binding in each project, and how each project is related to and dependent on other project schedules. As regards the highest ranked factor inhibiting both cost and time control it is obvious that there is a need for controlling and restricting the influence of this factor.

In summary, SME construction companies face big challenges, not only in Norway, which means that the potential for improving the management aspect of construction companies is great. Such improvement should, however, be done orderly and with a long-term perspective, which implies setting up orderly schemes for continuous improvement.

Challenges to Continuous Improvement in SME enterprises

SME enterprises are a key driver for economic growth in Europe [START_REF]Small and medium-sized enterprises[END_REF]. In order to stay competitive and profitable, SMEs, like larger organizations, must meet the requirements and demands of a rapidly changing market. One strategy to achieve this is to implement different continuous improvement initiatives, such as, e.g., Lean. However, despite the well-known theories, only a few SMEs succeed in their continuous improvement initiatives [START_REF] Bhasin | An appropriate change strategy for lean success[END_REF].

Ogunbiyi, Oladapo and Goulding [START_REF] Ogunbiyi | An empirical study of the impact of leanconstruction techniques on sustainable construction in the UK[END_REF] have done an empirical study of the impact of lean construction techniques on sustainable construction in the UK. Results from their study indicate that there are many benefits associated with implementation of lean construction and sustainable construction such as improved corporate image and sustainable competitive advantage, improved productivity and process flow, improvement in environmental quality and increased compliance with customer's expectations. The study also identifies several areas of linkage between lean and sustainability such as waste reduction, value maximization, environmental management and health and safety improvement among others.

SMEs are generally defined by their number of employees, but there are other variables than size that influence leadership, strategic planning and culture in companies [START_REF] Ghobadian | Total quality management in SMEs[END_REF]. A majority of SMEs are privately held and family-owned. Research has shown that this affects how the company is managed and operated. Family firms are run by reasons other than financial and rational and reflect a different view of ownership, based on the owner's values and beliefs [START_REF] Brundin | The Family Ownership Logic: Core Characteristics of Family-Controlled Businesses[END_REF]. This implies that noneconomic (family) goals may take precedence over economic goals in family firms [START_REF] Kraus | Family firm research: sketching a research field[END_REF]. These circumstances have implications both on the design of business support services and SMEs' willingness to participate in continuous improvement as well as their objectives to do so [START_REF] Bill | The Incubus Paradox: Attempts at Foundational Rethinking of the "SME Support Genre[END_REF].

There are several factors that have shown to be critical for a successful implementation of different continuous improvement initiatives. The most common are management and leadership [START_REF] Achanga | Critical success factors for lean implementation within SMEs[END_REF], but also performance evaluation [START_REF] Alaskari | Critical Successful Factors (CSFs) for Successful implementation of Lean tools and ERP systems[END_REF] and supporting information systems have shown to play an important roll particularly now with the growing use of business intelligence [START_REF] Davenport | The new industrial engineering: Information technology and business process redesign[END_REF].

Performance Measurement Systems (PMS) support performance management by communicating and transforming different performance measurements between different organizational levels and employees. Ukko et al. [START_REF] Ukko | How to communicate target information in SMEs?[END_REF] conclude that association between goals on the strategic level and on the operational level is important in order to achieve the strategic goals, and that performance measurement should be enabled on the operational level. They also state that since many companies today apply performance measurement on the operational level, one of the major challenges for managers is to achieve understandable and accessible communication about the goal of the organization. There is also a need to better understand challenges in transforming performance measurement on the operational level to usable information on the strategic level. It is critical that managers on different levels have relevant decision support of good quality.

Using Generic Goal Models to Support Continuous Improvement

Goals have been important to businesses for a long time. In 1954 Peter Drucker published the book The Practice of Management, being recognized as the first book to write about objectives, to define key result areas, to outline how to set objectives, and to describe how to use them to direct and steer a business and to measure its performance while looking at management as a whole [START_REF] Drucker | The Practice of Management, Harper Business[END_REF]. The time dimension is essential in management because management is concerned with decisions for action, and action is always aimed at results in the future [START_REF] Drucker | The Practice of Management, Harper Business[END_REF]. This clearly points to the need to take a continuous improvement perspective when working towards goal achievements.

A goal model is a structure of interrelated goals that describe the strategic direction of an enterprise towards a desired state of the enterprise. Goals models provide an analytical instrument for a number of purposes, e.g. decision-making and planning in order to achieve consistence, coherence and increased understanding among [START_REF] Overbeek | A language for multi-perspective goal modeling: Challenges, requirements and solutions[END_REF].

Goal models are often considered to be a part of the enterprise modeling process, where a number of integrated models capturing and representing different aspects (focal areas) of an enterprise, for example business processes, business rules, concepts, information, data, vision, goals and actors [START_REF] Sandkuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method (The Enterprise Engineering Series) Kindle Edition[END_REF]. The systematic use of process models for various purposes is a quite common practice in all types of organizations. We have observed, however, that the systematic use of goal models in practice is less common even though goals are needed as a driver in all kinds of organizational development work.

A number of goal modeling techniques are described in the literature. Some examples can be found in [START_REF] Sandkuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method (The Enterprise Engineering Series) Kindle Edition[END_REF][START_REF] Dardenne | Goal-Directed Requirements Acquisition[END_REF][START_REF] Yu | Towards Modelling and Reasoning Support for Early-Phase Requirement Engineering[END_REF][START_REF] Rolland | Capturing System Intentionality with Maps[END_REF]. They are reported to have a number of weaknesses, e.g. being complex to understand, requiring a huge amount of time to implement and as such being unable to support business analysts in a rapidly changing business environment [START_REF] Ullah | Modeling business goal for business/IT alignment using requirements engineering[END_REF] Nevertheless, since goals are essential for business development, there is a need to find fairly simple and practical approaches that support businesses in working with goals.

One of the more critical aspects in goal modeling is the creative process of formulating the goals, negotiating them between the stakeholders involved, defining relationships between goals, and documenting the model. It takes quite a bit of competence to manage this process [START_REF] Stirna | Purpose Driven Competency Planning for Enterprise Modeling Projects[END_REF]. Using reference goal models or generic goal models can be a useful starting-point to alleviate some of the risk in such situations.

The aim of reference models typically is to unify and integrate the body of knowledge or best practice in a certain area. In the work reported in this paper, this approach was considered relevant, since the level of management maturity in SME construction companies is relatively low. A reference goal model in this case then provides learning and insight into which elements make up an enterprise and which areas must be in focus to ensure long-term survival and company growth.

Approach to Develop the Proposed Generic Goal Model

In a pilot study carried out in a Norwegian SME construction company [START_REF] Karlsen | Enterprise Modeling Practice in a Turnaround Project[END_REF] enterprise modeling was used in a turnaround operation together with business management methods in an effort to change the way of working in the company. The company was at the time at severe risk to go bankrupt. The combination of these approaches yielded some very encouraging results Fig. 1). Fig. 1. Profit margin in industry in Norway compared to that in the SME construction company [START_REF] Karlsen | Enterprise Modeling Practice in a Turnaround Project[END_REF] These results motivated an initiative to develop a process surveillance and control method that combines enterprise modeling and business management methods, the SmallBuild+ method. The aim of the method is to support companies in their continuous improvement towards sustainability and economic growth. It has been developed in collaboration between practitioners and researchers in a project funded by the EUREKA Eurostars programme 1 .

The Norwegian SME construction company previously mentioned has been involved as a case study setting for developing and testing the method. During the project, the company needed to carry out a second turnaround project to save the company from going bankrupt, again. This shows that awareness of the status of a company and related risks needs to be part of day-to-day business.

During that work, the need for defining relevant goals related to various business areas became a central theme to ensure survival and growth after a period where most of the energy had been put into handling urgent issues and putting out fires, due to the danger of bankruptcy. Motivated by the writings of [START_REF] Hernández | A Portfolio Inspired Metric for Project Selection in Construction Management, Organization, technology and management in construction -An international[END_REF] and the work by [START_REF] Olawale | Cost and time control of construction projects: Inhibiting factors and mitigating measures in practice[END_REF], relevant goals for ensuring long-term sustainability were formulated. The goals were documented in the form of a simple hierarchical goal model. The goal model was developed in close cooperation between practitioners and researchers in the SmallBuild+ project. The manager of the company experienced great value in putting the goals and objectives into an orderly "system". He stated that it helped him to get an overview of the situation: "When everything is burning around you, it is difficult to raise your head and look at the situation from a bird's eye perspective."

This specific goal model was generalized to be applicable to other SME construction companies and then became the backbone of the SmallBuild+ method for continuous improvement (Fig. 2).

Fig. 2. Goal oriented continuous improvement in the SmallBuild+ method

The development of the goal model was built on the following three approaches: 1) Lean [START_REF] Liker | The Toyota Way in Services: The Case of Lean product Development[END_REF], 2) Balanced Scorecard [START_REF] Schneiderman | Analog Devices: 1986-1992, The First Balanced Scorecard[END_REF], and 3) the Business Model Canvas [START_REF] Osterwalder | The Business Model Ontology -A Proposition In A Design Science Approach[END_REF]. It also builds on a management consultant's experiences from working with this kind of companies for many years. The consultant participated in the project.

The Generic Goal Model and its Use

In this section the developed generic goal model is presented. Since the model targets improving the effectiveness of the organization as a whole, including various focus areas, its subcomponents are many and varied, corresponding to the common target components addressed in change literature [START_REF] Cawsey | Organizational Change -An Action-Oriented Toolkit[END_REF] and targeted by consultants with years of experience as change facilitators. To address this complexity in an orderly fashion and to increase readability of the model, we chose to present each focus area in separate sub-models.

In the top-level model (Fig. 3), the main goals are presented that need to be achieved in order to ensure sustainable SME construction companies. Each of them represents an essential focus area. Each of these top goals are decomposed in a separate sub-model (Fig. 456789), except for the goal focusing on health and safety, which are covered in national regulatory documents. When assessing the status of a specific SME construction company, the goals of each focus area assessed one by one. The status is set to red, yellow or green. Red means that the goal needs urgent attention. Yellow means that the status of the goal is partially satisfactory and needs attention but not urgently. Green means that the status of the goal is satisfactory. For each of the goals needing attention Fig. 10 provides an example of defined criteria for setting the status of a goal, in this case a goal concerning the liquidity of the company. This supports the user of the model in estimating the status of the company in question. Similar criteria are developed for the other focus areas. Goals specific the company in question can be added to model. After the assessment of each of the goals, the model becomes a specific goal model relevant for the company in question. In order to ensure that goals were followed by relevant improvement initiatives, a paper-based scheme was developed in the project where each goal was listed, categorized due to the status of goal achievement, linked to an improvement initiative with a start and end-date and motivated by strategy and other formal company decisions. After having used the paper-based scheme in the field for some time, it became evident to the manager of the company that it was useful to ensure follow-ups of a variety of business areas, but it proved difficult and cumbersome to keep the paper-based scheme up to date, due to status changes, schedule changes etc. Evidently there are huge dynamics related to goal achievements in business so this problem needed a solution. Hence, a computer-based tool was developed to help keeping track of this dynamicity. The tool is presented in [START_REF] Karlsen | Towards a Tool to Support Goal Oriented Continuous Improvement in SME Construction Companies[END_REF]. In the tool, each goal and related improvement initiatives can be documented, reviewed and refined, which is illustrated in Fig. 11. In the tool, the columns to the right are colored red (serious condition), yellow (weak condition), green (good condition) and blue (not applicable), starting from the left. An overview of the company status can also be generated (Fig. 12), where the wheel on the right hand side illustrates the portion of red, yellow and green goals. In this case the portion of red goals is about half and the portion of red goals is the smallest.

Note that Fig. 11 and Fig. 12 are only meant to illustrate how the status of goals are presented to the user. The SmallBuild+ project is soon to be finished. The SmallBuild+ method and tool has been tested, with positive results, in the SME construction company involved in the project. The positive results have in turn encouraged a consultancy company that is also involved in the project to start preparing for commercialization of both the method and the tool. In fact, they have founded another company aimed to support SME construction companies with capital and other support for making them sustainable over time. The SmallBuild+ method and related tool will be an important part of the services offered.

The generic goal model has not only been tested in the SME construction company involved in the project. It has also been tested by the consultancy company in a turnaround operation involving another SME construction company, with positive results.

Although there are positive indications of the usefulness of the goal model and related tool, we foresee that further testing and consequent adjustments will be needed before they can be put into more widespread use.

One example of remaining work is that in the current version of the generic goal model, there is no weighting of the goals. During the use of the tool it has become evident that this needs to be done because not every goal can realistically be equally important. However, this is something that will require some research in order for such a weighting to be reliable. E.g. in initial discussions, it has turned out that the goal of having good financial management is a critical goal for SME construction companies. In any case, the complex relationships between goals in the model need to be the basis for such a weighting.

In terms of applicability of the goal model beyond the construction industry, we speculate that, since most of the goals are quite generic, it should be useful to other types of companies as well. One could also imagine that the goal model could be complemented with advice how to adapt it to other types of companies. This would hugely improve on the usefulness of the model, which is why we see it as a natural step to move forward, after further improvement and validation of the current model in the construction industry.

An additional improvement could be to extend the model with guidelines on how to integrate the model with a company's existing management practices concerning Lean, the Business Canvas and the Business Scorecard.

Fig. 3 .Fig. 4 .

 34 Fig. 3. Top-level goal model

Fig. 5 :Fig. 6 .

 56 Fig. 5: Sub-model on having good HR and personnel management

Fig. 7 .Fig. 8 .Fig. 9 .

 789 Fig. 7. Sub-model on having effective accounting and financial management

Fig. 10 .

 10 Fig. 10. Example of criteria to support setting the status of a goal

Fig. 11 .

 11 Fig. 11. Managing the goals of a specific company

Fig. 12 .

 12 Fig. 12. Overview of goal status for a company

https://www.eurostars-eureka.eu