Collaborative Manufacturing Network for Competitive Advantage · 2017-04-21 · Project title...

284928

Collaborative Manufacturing Network

for Competitive Advantage

D3.1.1 – Specification of Modelling Method Including Conceptualization Outline

(public)


WP3 – Secure Information Model

© ComVantage Consortium – 2012 2

Grant Agreement No. 284928

Project acronym ComVantage

Project title Collaborative Manufacturing Network for Competitive Advantage

Deliverable number D3.1.1

Deliverable name Specification of Modelling Method Including Conceptualization Outline

Version V 1.0

Work package WP 3 – Secure Information Model

Lead beneficiary UNIVIE

Authors Dimitris Karagiannis (UNIVIE), Robert Buchmann (UNIVIE), Patrik Burzynski (UNIVIE), Jasmin Brakmic (UNIVIE)

Reviewers David Orensanz (BOC-IB), Leon Urbas (TUD)

Nature R – Report

Dissemination level PU – Public

Delivery date 29/06/2012 (M10)




Executive Summary

This report presents the conceptualization process and results for the development of the ComVantage modelling method. It is the first iteration of two and it is the support document for the implementation phase to be developed in task 3.4, thus it outlines a first set of method concepts and constructs, to be implemented by the first version of the modelling tool prototype. In the current iteration, the method addresses generically the global frame of supply chain management integrated with aspects of mobile interaction and Linked Data support. Furthermore, the method will be adapted to requirements of the specific ComVantage application areas as part of the adaption tasks 6.2, 7.2 and 8.2. The document presents both the methodology for method development and the results derived by applying it to the ComVantage context, resulting in a conceptualization of the modelling method.




Table of Contents

1 OVERVIEW .......................................................................................................................................... 8

1.1 INTRODUCTION ............................................................................................................................................ 8

1.2 SCOPE OF THIS DOCUMENT............................................................................................................................ 8

1.3 RELATED DOCUMENTS ................................................................................................................................ 10

1.4 TERMS AND ACRONYMS USED IN THIS DOCUMENT .......................................................................................... 11

2 THE METHOD SPECIFICATION METHODOLOGY ................................................................................... 12

2.1 PRESENTATION OF THE EMPLOYED FRAMEWORK ............................................................................................. 12

2.2 THE METHOD DEVELOPMENT LIFECYCLE ........................................................................................................ 13

3 OVERVIEW OF SUPPLY CHAIN AND PROCESS MANAGEMENT FRAMEWORKS ...................................... 15

3.1 PROCESS CONTROL: SIXSIGMA AND LEAN ...................................................................................................... 15

3.2 PROCESS STRUCTURING: SCOR AND VRM .................................................................................................... 18

4 THE COMVANTAGE MODELLING METHOD SPECIFICATION .................................................................. 23

4.1 THE MODELLING PROCEDURE ...................................................................................................................... 23

4.2 THE MODELLING STACK .............................................................................................................................. 24

4.3 THE MODEL TYPES ..................................................................................................................................... 26

4.3.1 The Product Structure Model Type ............................................................................................... 26

4.3.2 The "Voice of the Customer" Model Type ..................................................................................... 26

4.3.3 The e3 Business Model Type ......................................................................................................... 27

4.3.4 The Scope Model Type ................................................................................................................... 29

4.3.5 The Thread Model Type ................................................................................................................. 30

4.3.6 The Process Model Type ................................................................................................................ 30

4.3.7 The Mobile Mockup Model Type ................................................................................................... 31

4.3.8 The Mobile Orchestration Model Type.......................................................................................... 32

4.3.9 The Organizational Structure Model Type ..................................................................................... 33

4.3.10 The Causality Model Type ............................................................................................................ 33

4.3.11 Adaptation Prospects................................................................................................................... 34

4.4 DESCRIPTION OF THE MODELLING LANGUAGE, MECHANISMS AND ALGORITHMS .................................................. 35

4.4.1 The Product Structure Model Type ............................................................................................... 35

4.4.2 The “Voice of the Customer” Model Type ..................................................................................... 38

4.4.3 The e3 Business Model Type ......................................................................................................... 40

4.4.4 The Scope Model Type ................................................................................................................... 44

4.4.5 The Thread Model Type ................................................................................................................. 46

4.4.6 The Process Model Type ................................................................................................................ 56

4.4.7 The Mobile Orchestration Model Type.......................................................................................... 66

4.4.8 The Organizational Structure Model Type ..................................................................................... 68

4.4.9 The Mobile Mockup Model Type ................................................................................................... 70

4.4.10 The Causality Model Type ............................................................................................................ 74

4.5 MODEL TYPE-INDEPENDENT REQUIREMENTS .................................................................................................. 75




4.5.1 General Classes and Attributes ...................................................................................................... 75

4.5.2 Generic Requirements ................................................................................................................... 76

4.5.3 The Exposure of Models as Linked Data ........................................................................................ 78

4.5.4 Six Sigma Functionality Requirements ........................................................................................... 87

5 CONCLUSIONS AND OUTLOOK ........................................................................................................... 89

5.1 CONCLUSIONS ........................................................................................................................................... 89

5.2 OUTLOOK AND OPEN ISSUES ........................................................................................................................ 89

6 REFERENCES ...................................................................................................................................... 90

7 APPENDIX – PROCESS TO MOBILE ORCHESTRATION TRANSFORMATION RULES .................................. 91




List of Figures

Figure 1: Overview of the Plant commissioning challenges .............................................................................. 9

Figure 2: The collaborative production space envisioned for the Customer-oriented production .................. 9

Figure 3: The landscape for the Mobile maintenance application area .......................................................... 10

Figure 4: Positioning of the current document in the ComVantage task flow ................................................ 11

Figure 5: The DKE metamodelling framework (Karagiannis and Kühn, 2002) ................................................ 12

Figure 6: The Modelling product development cycle ...................................................................................... 13

Figure 7: The requirements acquisition strategy for the current specification .............................................. 14

Figure 8: The Six Sigma ranking ....................................................................................................................... 15

Figure 9: Orchestration of SixSigma, Lean and process classification frameworks ......................................... 16

Figure 10: Deviation-driven process output control with SixSigma ................................................................ 16

Figure 11: Improving process in Six Sigma ...................................................................................................... 17

Figure 12: Degrading SixSigma process ........................................................................................................... 17

Figure 13: The SCOR process landscape .......................................................................................................... 19

Figure 14: The VRM approximation of the supply chain landscape ................................................................ 22

Figure 15: The inputs and outputs of the ComVantage modelling method (v 1.0) ........................................ 24

Figure 16: The ComVantage modelling stack (v1.0) ........................................................................................ 25

Figure 17: Overview of the model types from ComVantage modelling method (v 1.0) ................................. 25

Figure 18: Mockups for the product and market structure model types ....................................................... 27

Figure 19: Example showcasing an AND in a Business Model depicting the creation of a Shirt. .................... 28

Figure 20: Example showcasing an OR in a Business Model depicting Train rides and Food provision. ........ 28

Figure 21: Example with Occurrences (O) and Fraction (F) for AND and OR. ................................................. 29

Figure 22: Mockup of the scope model type ................................................................................................... 29

Figure 23: Mockup for a thread model expressing a process landscape compliant to SCOR ......................... 30

Figure 24: Mockup for a process model extended with mobile interaction support ..................................... 31

Figure 25: Mockup of a mobile mockup model ............................................................................................... 32

Figure 26: Derivation by graph transformation of the mobile orchestration model ...................................... 32

Figure 27: Mockup of the organizational structure model ............................................................................. 33

Figure 28: Mockup of the causality diagram ................................................................................................... 34

Figure 29: Mockup of the funnel model type .................................................................................................. 34

Figure 30: Mockup of value stream mapping .................................................................................................. 34

Figure 31: Mockup for incident escalation ...................................................................................................... 35

Figure 32: Mockup for a skill model ................................................................................................................ 35

Figure 33: Generated maps from Google ........................................................................................................ 46

Figure 34: Example for input and output restrictions from SCOR. .................................................................. 55

Figure 35: Example for the reduced view of a Process model ........................................................................ 64

Figure 36: Process stepper encounters an Activity. ......................................................................................... 65

Figure 37: Process stepper encounters a Decision .......................................................................................... 66

Figure 38: Linked data constructs for describing the models ......................................................................... 80

Figure 39: Exemplary models to be exposed as Linked Data .......................................................................... 81




Figure 40: Querying directions for the exemplary SPARQL queries ................................................................ 87

Figure 41: Functionality for loading and visualizing data from the process execution time .......................... 88

Figure 42: Transformation rules for deriving mobile orchestration models ................................................... 92

Figure 43: Process model-to-mobile orchestration model transformation steps ........................................... 94

List of Tables

Table 1: Predefined Linked Data constructs to be provided as reference classes by the modelling tool ....... 79

Table 2: Modelling concepts mapped on the Linked Data constructs ............................................................ 80




1 OVERVIEW

1.1 Introduction

This is the first iteration (of two) of a deliverable whose goal is to describe the purpose and specification of the envisioned ComVantage modelling method, a method for supply chain design and management augmented with mobile and Linked Data support. The document also presents the metamodelling framework on which the specification is based upon and the modelling requirements acquisition strategy that is being employed in order to define the input of the modelling method. The application domain is supply chain management, thus the method is of a generic nature with respect to the specifics of the three application areas covered by the project. Adaptation efforts for these application areas are subject to future deliverables.

The document is organized as follows: this introduction is followed by a scope statement correlated with the description of work, a positioning of the document in the context of related deliverables and a list of terms and acronyms used in the document. Chapter 2 describes on a generic level our metamodelling framework and method specification methodology. Chapter 3 briefly describes the application domain of supply chain management and some popular frameworks. Chapter 4 is the core content of the document. It starts with the definition of the modelling steps and an overview of how the proposed model types are interrelated in the modelling stack. This also gives emphasis to the criteria on which each model type was selected as relevant in the context of ComVantage modelling goals. It continues with mockup descriptions of the model types and their specific purpose, followed by some suggestions of further development in the adaptation tasks (6.2,7.2,8.2) with the goal of setting a bridge towards future deliverables (section 4.3.11). The main part of the chapter is the concrete specification of the method's first version (section 4.4). This is presented in the form of classes of concepts and relations, suggested notations, attributes and functionality. The last part of the specification is model type independent (section 4.5) and it also provides specific guidelines related to the model-to-Linked Data integration. The document ends with conclusions and an outlook to future developments envisioned for the second iteration.

1.2 Scope of this Document According to (ComVantage, 2011), "this task aims to design the business process modelling method for ComVantage and conceptualisation as a basis for the development on a meta-modelling platform. This includes the design of a hybrid, process-based method for dynamic collaboration processes between different user roles and regarding different types of information". The business process modelling paradigm is placed in the wider context of process management in a supply chain environment, for companies and technological partners joining the envisioned ComVantage system, where activities rely on two key types of resources: mobile interaction support and Linked Data. In order to accomplish this and to understand the modelling requirements for such a modelling method, literature input has been taken from methodologies such as:

Six Sigma (Tennant, 2001) and Lean (Womack et al., 2007) for process control;

SCOR1 and VRM2 for process and metric categorization;

The e3 value modelling language3 for business model design;

Kano (Kano et al., 1984) for product structuring;

DMAIC and SCOR implementation guidelines (Bolstorff and Rosenbaum, 2007) for defining a modelling lifecycle and procedure.

1 http://supply-chain.org/, last accessed on 26.06.2012

2 http://www.value-chain.org/en/cms/?1960, last accessed on 26.06.2012

3 http://e3value.few.vu.nl/, last accessed on 26.06.2012




Application partners and requirements/scenario specification deliverables have provided domain-specific input that will drive the adaptation of the modelling method according to their application areas:

Plant commissioning and engineering – the application area is represented by COMAU, a company that has extensive experience with designing and assembling production lines. According to the current requirements set collected within task 2.1, their main concerns are process control and monitoring, incident and task management (Figure 1);

Figure 1: Overview of the Plant commissioning challenges

Customer-oriented production – the application area is represented by DC21 and ISN, companies that collaborate in providing an innovating line of t-shirts to certain customer groups. Their high level requirement is to involve the customer in the production process and to provide a higher degree of customization (Figure 2);

Figure 2: The collaborative production space envisioned for the Customer-oriented production




Mobile maintenance – the application area is represented by K&A and RST, companies that collaborate in providing maintenance services for machines augmented with embedded sensors capable of projecting process variables and of supporting the goal of remote maintenance (Figure 3).

Figure 3: The landscape for the Mobile maintenance application area

Before the adaptation tasks will be developed for specific needs, the current document encompasses all three application areas under a common view, covered by the supply chain paradigm (which also gives the framework for evaluation within WP9). Thus, specificities for the three application areas will be only superficially suggested in the current document.

1.3 Related Documents

The current document's position in the project context and with respect to related deliverables and tasks is presented in Figure 4. The relations expressed in the figure are as follows:

Application areas' refined scenarios and functional requirements provide concepts for the modelling requirements;

The modelling method, as it is presented in the current task, is generic and it will be further specialized in the adaption deliverables from WP6, 7 and 8;

The modelling method aims to also support technological work packages by specifying exports and model analysis functionality for access control design, Linked Data coupling and mobile app orchestration design;

The modelling method will be implemented in a modelling tool within task 3.4. Further justification on how the elements of the modelling method are determined by requirements of the specific application work packages are provided in the overview on the modelling stack (sections 4.1-4.3).




Figure 4: Positioning of the current document in the ComVantage task flow

1.4 Terms and Acronyms Used in this Document ADOlog – modelling tool for supply chains

ADONIS – modelling tool for business process modelling

DKE – Department of Knowledge Engineering

DMAIC – Define, Measure, Analyse, Improve, Control

e3 value – modelling language for designing value chains

Kano's model – classification of product attributes and features in relation with customer satisfaction and dissatisfaction

Lean – process control strategy aimed to minimize waste

Linked Data – a way of expressing and publishing data using the RDF data model

ML – Modelling Language

MM – Modelling Method

Modelling procedure – a set of modelling steps driven by modelling goals in specific scenarios

SCOR – Supply Chain Operations Reference

Six Sigma – statistical process control strategy aimed to minimize process output variance

SPARQL – the standard language for querying Linked Data expressed as RDF

TriG – syntax for RDF named graphs

VRM – Value Reference Model

WP – Work package




2 THE METHOD SPECIFICATION METHODOLOGY

2.1 Presentation of the Employed Framework

The method is developed on the framework developed within University of Vienna, the DKE Metamodelling Framework, summarized in Figure 5. According to it, a modelling method is composed by a modelling technique and a set of mechanisms / algorithms.

Figure 5: The DKE metamodelling framework (Karagiannis and Kühn, 2002)

The modelling technique relies on a modelling language, complemented by procedures describing how the modelling should be done in order to achieve some level of validity (acceptance) with respect to the modelling objectives:

The modelling language is defined by syntax (labelled abstract constructs), notation (graphical constructs assigned to the abstract ones in order to be used the diagrammatic representations) and semantics mapped on the application domain (the meaning of the constructs). These can be specified by a metamodel extended with rule enforcing and notational design capabilities;

The modelling procedure describes how the user should use the method in order to reach his goals. This is strongly dependant on modelling scenarios, their specific requirements and conventions. The same modelling language can be used for expressing models that are aligned or not to conventions imposed by certain goals. A model whose target audience is human public has different goals and acceptance levels than a model meant to be executable automatically or simulated upon. Thus, we can consider a modelling procedure as being a set of steps driven by the goals of a modelling scenario.

The mechanisms and algorithms are functionality employed by the modelling procedure. They are lower-level procedures to be implemented in a modelling tool in order to solve tasks that are generic, domain-specific or hybrid. The modelling procedure is determined by the user goals, while the mechanisms and algorithms are functions that relate certain output to certain input. Common functionality includes:

Model querying, in order to extract model parts that fit certain criteria (a subproblem of this would be model evaluation);

Model transformation, in order to export models in various formats (from one language to another) for interoperability purposes;

Model comparison, in order to detect deviations or compliance of models.




Simulations, in order to compute certain characteristics over a range of possible (deterministic or stochastic) inputs.

The generic mechanisms and algorithms only rely on the well-formedness of models, regardless of their meaning. The specific ones rely on semantics, on the construct attributes and domain-specific rules. The hybrid ones take as an input both structure and semantics – in this category would fall algorithms for mapping models or converting them from one language to another. First, elements to be mapped/converted must be structurally identified, then their semantics must be queried to achieve consistent meaning in the result. UML can be employed to describe the core metamodel, but it lacks capabilities regarding rules and notation, and it's strictly object oriented, meaning that approaches that are not fully aligned to the object-oriented paradigm are not very intuitively or completely expressed. Also, specific mechanisms and algorithms that rely on domain-specific ontologies are not well suited to the rather restriction-oriented approach of UML.

2.2 The Method Development Lifecycle

According to the mentioned approach, a modelling product is the output of a production cycle consisting in the following phases:

The cognitive phase, a knowledge acquisition phase which relies on a modelling requirements definition framework;

The conceptualization phase, in which the captured knowledge is refined and structured according to a metamodelling framework supported by a theoretical formalism, which further drives the implementation;

The implementation phase, in which the modelling method is implemented in a tool;

The deployment phase, in which the tool becomes an actual product, enhanced with documentation, customer support services or various by-products.

With the task represented by this deliverable, we are positioned in the first two phases which will result in a method specification, while task 3.4 will cover the realization of the concrete tool.

Figure 6: The Modelling product development cycle

Due to the agile approach employed by ComVantage on all development areas, this cycle suffers two adjustments:

the conceptualization and implementation phases have two subphases, one focused on generic concepts and one focused on adaptations to the application areas;

it spirals in multiple iterations growing in complexity. Thus, workshops on requirements and analysis of scenarios defined in previous tasks are of essence, by providing domain specific concepts and processes and allowing for the integration under the common umbrella of the generic modelling method. Then, existing theoretical research (frameworks) and pragmatic development (modelling products) suggests approaches and functionality. Finally, the metamodelling




framework on which our approach is based imposes a certain structural approach, which needs to be aligned with the development platform in later stages. The metamodelling approach is also founded on theoretical formalism which makes the object of the theoretical research goals for the leading partner of this task. The requirements acquisition strategy which supports the current specification is described by Figure 7.

Figure 7: The requirements acquisition strategy for the current specification

Notice also that the metamodelling framework, the domain specifics and the existing theoretical and practical approaches constrain each other in order to achieve a convergence, to define common ground, rather than being simply aggregated under a "common multiple" view. In this respect, an integration model is also subject to our current research. The main drivers of the modelling method requirements are the market, which suggests features and the necessary modelling stack, the literature which provides standard methodology application recommendations and the application partners whose support help to define the modelling requirements adapted to their business use cases. As mentioned, for the process management-related goals of ComVantage the literature indicated frameworks such as SCOR, VRM, Six Sigma, Lean and existing modelling methods/implementations such as ADOlog4 or e3. Our approach relies on the following working terms (definitions reduced to the scope of ComVantage):

A model is externalized semi-structured knowledge that can be easily grasped by actors from the business environment and processed to some extent by modelling tools that support process complexity management;

Targeted usage scenarios are the following: o Communication of knowledge in a visual way, in collaborative context; o Documentation of knowledge management; o Structuring knowledge in order to support its process and querying; o Evaluation of phenomena described by the structured knowledge, as decision support.

The approach is subordinated to conceptual modelling of business-IT alignment; it does not address CAD-type design, software development or machine learning-driven knowledge discovery, although it can interface with such areas via import/export mechanisms. For the purposes of ComVantage, an RDF-format exposure of models will be specified in the current document.

Thus, the modelling method aims to serve process design and improvement decisions for the ComVantage business models rather than model-driven engineering or technical solutions design. This is consistent with objectives for the companies joining a ComVantage system, in a context of standard process categorizations such as SCOR and VRM.

4 http://www.boc-group.com/at/produkte/adolog/, last accessed on 26.06.2012




3 OVERVIEW OF SUPPLY CHAIN AND PROCESS MANAGEMENT FRAMEWORKS

3.1 Process Control: SixSigma and Lean

Considering the application domain of ComVantage, we identified that the problem is subordinated to the global tableau of supply chain management supported by technological innovations coming from the fields of mobile technology and Semantic Web. These function as enablers or support for business processes which, ultimately, fall under the paradigm of supply chain management. Several frameworks have come under our scrutiny during the literature and state-of-the art review efforts, which will be briefly described in this section. SixSigma and Lean are two quality assurance methodologies that can complement the mentioned process classification standards, and have converging goals:

SixSigma aims to place process outputs within 6 standard deviations (or 4.5 according to some practices, with respect to long term process monitoring (Tennant, 2001)) from the mean of a normal output distribution;

Lean is focused on waste minimization and relies on modelling techniques such as value stream mapping to compare value-adding time to total lead/cycle time (Womack et al., 2007) (Rother and Shook, 1999).

According to SixSigma, strict process control must be employed to restrict the number of standard deviations between the mean process output and its closest specification limit. According to how many standard deviations are between the mean and the limit, companies can be diagnosed along the SixSigma ranking:

Figure 8: The Six Sigma ranking

Error rates represent the rate of normal process outputs/indicators that fall outside the specification limits. For example, a 1Sigma company has one standard deviation from mean to the closest limit, leaving one third of output outside the specification. SixSigma and Lean goals can be orchestrated with standard categorizations offered by frameworks such as SCOR and VRM. These frameworks define activity and process types to be executed along a supply chain/value chain and semantically define target indicators to be tracked. The orchestration of the mentioned approaches is described in Figure 9:




Figure 9: Orchestration of SixSigma, Lean and process classification frameworks

SixSigma is a process control strategy developed by Motorola. A SixSigma process has its output within specification limits that are distanced by 6 times the standard deviation from the normal output mean:

Figure 10: Deviation-driven process output control with SixSigma

The ideal case is when all output is aligned to the mean and the number of standard deviations between mean and specification limits tends towards infinite:




Figure 11: Improving process in Six Sigma

Figure 12: Degrading SixSigma process

The opposite case is when a company gets demoted to 5Sigma, 4Sigma and so on, because the variance in process output is too strong, the mean is shifted towards one specification limits or specification limits become more restrictive. In each of these cases, the number of standard deviations from mean to the closest specification limit falls under 6, demoting the process quality (and thus the company) in the SixSigma ranking. Obviously, this leads to higher error rate (output outside of the specification limit). This is a signal that the company needs to employ statistical process control, to gather execution data as time series and to identify strong variations in process attributes, then try to identify root causes for such variation.

Lean, on the other hand, is a management philosophy defined by Toyota, focused on identifying and eliminating waste along the value creation processes. Waste is approached in its most general sense, at the




same level of abstraction as the term "resource". Thus, waste is classified based on several categories of "waste-able" resources (Bicheno and Holweg, 2009), which can be reduced to the following enumeration:

Production: making more than what is demanded; Inventory: unused buffers of resources (including people); Processing activities: adding perceived value when it's not needed, including more expensive tools; Time: waiting for resources, people, documentation etc.; Logistic motion: transportation or any motion applied to the products; Human motion: document searching, travelling, any motion that is not applied directly to the

product; Defects: non-compliance of process outputs; Rework: products that need to be reprocessed; Competence: untapped or latent skills.

A key requirement for Lean modelling support would be to allow the description of such waste attributes for any activities or tasks within the process. While both SixSigma and Lean rely heavily on statistical methods, they can also get important benefits from usable and intuitive modelling, with import/export mechanisms that allows for a certain degree of interoperability with more statistically focused tools. Process control approaches are defined in the context of methodologies such as DMAIC5, where the following phases can be identified (with their support from diagrammatic modelling):

a. Define – in our context, we need to identify customer demand/requirements and processes to fulfil it. This is the "play in" phase, when reality must be captured in models, thus it relies heavily on modelling;

b. Measure (process performance/output) - this is usually based on execution data from log files. A modelling tool should allow for importing attribute values for existing models from such logs and system in order to support simulation;

c. Analyse – analysis can be visually guided (by models), query-based (applied on models) but relies mostly on statistics and charts; modelling tools should provide exporting mechanisms and interoperability to support the generation of such outputs; however, pure visual modelling can also be employed in certain cases, for example, the fishbone diagram for discussing causality of underperforming processes;

d. Improve – this is the "play out" phase, when models, then reality, are transformed according to analysis results; this can also involve a re-education of the working environment which can rely on a process stepper that guides users throughout the tasks and decisions of a process;

e. Control – this is mainly a maintenance of implementations realized in the previous step. Just as the analysis phase, it relies more on statistics and less on visual modelling.

3.2 Process Structuring: SCOR and VRM

Supply chain operations reference (SCOR), a product of Supply Chain Council (SCC) is a process reference that proposes standard guidelines for supply chains management6. It enables companies to align and converge to best practices, thus it can be considered a normative approach. SCOR tries to encompass in a common view all activities associated with the supply chain, from demand to order fulfilment, and their respective flows and interactions. In order to cover the wider scope of value chain, recent expansions have been proposed for product design (DCOR), customer interaction (CCOR) and market modelling (MCOR) (Bolstorff and Rosenbaum, 2007).

The framework is built around two basic sets: a standard library for modelling supply chain processes, which allows companies to set up environments for collaboration and process alignment, and a set of

5 http://adaptivebms.com/Introduction_to_DMAIC/, last accessed on 26.06.2012

6 http://supply-chain.org/, last accessed on 26.06.2012




standardized semantically-defined metrics, which allows supply chain managers to quantify and benchmark processes and thus to drive supply chain management strategies.

SCOR integrates elements of business process management for the application domain of supply chain management, covering a scope that starts with the supplier's supplier and ends with the customer's customer, thus including 5 entities (with the default organization the centre).

Figure 13: The SCOR process landscape

The processes are grouped on several high level categories, to which we attach a keyword as part of the keyword technique for concept identification during the cognitive phase of the method development:

PLAN: describes aggregation and prioritization of requirements, inventory and capacity planning, estimation of resource and requirements. Keyword: requirements;

SOURCE: processes of sourcing, reception, authorization payment for materials and other purchases. Keyword: supplier;

MAKE: processes of manufacturing and testing, starting with requests for materials (linked to SOURCE processes) and ending with product release (linked to DELIVER processes). Keyword: production;

DELIVER: processes of order management, from pricing and product configuration through managing orders, invoicing and credits, to customer-specific packing, labelling and shipping; Keyword: order;

RETURN: processes of managing products returned from customers, including warranty management and support (determined by DELIVER processes) or returned to suppliers (excessive stock, determined by SOURCE processes). Keyword: customer;

ENABLE: currently this is not a separate category, but is spread between the main five ones; its instances are linked to processes from the main ones, having to do with regulations, policies, maintenance or management processes that enable the planning and execution of activities. Keyword: management.

Further on, SCOR proposes a hierarchical structure for describing supply chain processes in more detail. Each Level 1 category is decomposable in Level 2 subsets, each of these in turn in Level 3 subsets, and each of Level 3 category must be instantiated by a concrete process model which is company specific and not described by the standard. Thus, in a sense, every construct from the SCOR model can be treated as a subprocess of a larger process landscape. The Plan Level 1 process type describes the business activities associated to determining requirements to achieve targeted results. It includes Level 2 segments mapped on the other process types: plan source, plan make, plan deliver and plan resource. The Source Level 1 process type categorizes Level 2 process sets associated with ordering, delivery, receipt, and transfer of sourced products or services. The Make process type categorizes the activities related to production processes and adding value. The Deliver category represents the business activities that transfer a product from the company to the client, and finally, the Return category encompasses the activities of returning goods upstream through the supply chain. Each of these also contains Level 2 enabling processes.




One of the categorization criteria is also the type of production that must be realized: for example, in the make category, make to stock designates production for stocking, associated with push commercial activities; make to order designates order-driven production for pull commercial activities; engineer to order designates order-driven production that also needs internal engineering processes. Each of these have their own planning, enabling, sourcing and delivering categories, thus a certain degree of correlation is imposed within the framework even if it is aimed to support flexible configurations and chaining of these process categories. SCOR defines inputs and outputs that determine certain dependencies between these categories. A SCOR compliant process landscape should reflect these dependencies, first in order to have a SCOR alignment, then to allow for a more compliant management of document flows between them. Level 3 process categories are subject to these inputs and outputs, allowing for a sequential or procedural ordering of process types. The order also influences the performance of level 2 categories and of the entire supply chain. The relation between level 2 and level 3 categories is one of subsumption: every instance of a level 3 process category will also be an instance of the encompassing level 2 process category, a relation that must be properly reflected in diagrammatic and semantic modelling. SCOR provides a standard nomenclature and taxonomy for these levels, thus a vocabulary, together with the input/output compliancy constraints that must link the level 3 categories. Further on, each level 3 category must be instantiated on level 4 as a concrete process model according to modelling languages chosen by each company, enhanced (or not) with organizational and resource models. For the purposes of ComVantage we will propose our own, usability-focused process modelling language, to be implemented on the DKE framework (Karagiannis and Kühn, 2002) and extended with specific mobile interaction and Linked Data resources. Levels 1-3 should be understandable by any manager familiar with the SCOR vocabulary, while level 4 can be company specific (but should be communicable as externalized knowledge in order to support cross-organizational process alignment, a goal for which diagrammatic modelling is essential). While the first 3 levels are a landscape of the business model, level 4 works on a rather operational level. The purpose of level 4 is to describe the processes from the standardized SCOR taxonomy in order to support externalization and communication of knowledge, complexity management, a shift in the corporate culture by training human resources with process stepping tools or even exchange of internal knowledge between partners who closely collaborate in a common supply chain. Concrete modelling tool implementations have to also take into consideration resource mapping along these processes. The organization specific structures, mobile interaction support and Linked Data consumption are the main resource factors to be considered in ComVantage. Thus, we identify the following requirements for the SCOR modelling:

Level 1 has low configuration requirements, being just a set of the main process categories which are basically the same in most companies. While sometimes a level 1 category might be missing from a certain business model or company, we consider that just stating the presence of absence of one of these categories is not a scenario complex enough to justify its own model type. Rather, a "table of contents"-style reporting functionality should provide a landscape of process categories that have been specified on the lower levels;

Level 2 is more configurable and it must reflect the business scope. Thus, it needs a model type to describe that scope regardless of the involved process categories (the scope model), and a model type to assign process type flows to the business actors identified as part of the scope (the thread model). Since different supply chain configurations can be defined within the same business models (depending on customer types and distribution channels), it's possible to have multiple thread models detailing aspects (production-distribution channels) for the same scope model;

Level 3 must be strongly linked to level 2, due to the subsumption relation between their constructs. Level 2 categories can be visualized as aggregations of level 3 categories, thus we propose a model type that integrates both levels in a common view. On level 3 it is of high relevance the flow of information and materials along the supply chain, thus level 3 can be considered a process landscape enhanced with flows, decisions and other elements typical to




process models. Each level 3 construct can be treated as a subprocess further detailed in a level 4 process diagram;

Level 4 visualization is not SCOR-dependent, any modelling language that has enough expressivity can be used. While standards such as BPMN and UML exist, we opt for what we consider a more usable and business-oriented representation, extended with features necessary to ComVantage specific requirements in order to express mobile application support and orchestration or access control policies.

Besides the process taxonomy and dependencies, SCOR also defines semantically a set of metrics to be used in evaluating processes at each level of aggregation (from the SCOR taxonomy). Based on these metrics, underperforming processes can be identified and strategies of process improvement can be driven. Instead of dictating strategy, SCOR defines supply chain attributes that are semantically detailed throughout the lower levels of the taxonomy, until the operational level where concrete data from ERP systems and process execution logs must be collected in order to compute the SCOR metrics that are considered relevant. Comparison with benchmark or target data must be done in order to identify the problematic measures and business areas. SCOR provides a set of metrics that are subordinated to groups called "performance attributes":

Reliability – groups quantifications that describe the ability of a process to perform as expected. At the highest level here we have the Perfect Order Fulfillment metric;

Responsiveness – groups metrics defining speed, for example Order Fulfillment Cycle Time;

Agility – groups metrics that describe the ability to respond to changes such as fluctuations in demand. The highest level metrics here are Flexibility and Adaptability;

Costs – groups metrics that define the cost of process execution: Cost of Goods Sold, Supply Chain Management Cost;

Assets – groups metrics defining efficiency of assets utilization: Cash-to-cash Cycle Time, Return on Fixed Assets etc.

Different companies may put different weights on these attributes. Also, different formulae could be used to compute the same metric, according to each company semantic interpretation and focus. For example there are cases in which order fulfilment is computed at ordered item level and not at order level (Bolstorff and Rosenbaum, 2007). Different cycle times may be based on different process parameters, thus each company needs to define its own concrete formulae within the semantic boundaries and metrics taxonomy provided by SCOR. It is recommended that each of the 5 attributes should be evaluated through at least one high level metric. The metrics are classified on the following levels:

Level 1 metrics are overall, aggregated supply chain diagnostics. On this level the strategic targets are established. For example, reliability is represented at this level by the Perfect Order Fulfillment metric;

Level 2 metrics are a drill-down of the diagnostic, in a dependency relation with the higher level indicators. For example, the Perfect Order Fulfillment metric can be represented or decomposed on this level through percentage of orders delivered in full, delivery performance to commit date, documentation accuracy and product condition. Cause and effect analysis can be realized along this taxonomy;

Level 3 metrics are further decompositions of the level 2 metrics, within narrower process categories. For example, the product condition can be expressed through any or a weighted combination of: percentage of faultless installations, warranty and returns, orders delivered damage free and others.

Metrics don’t always aggregate by addition to their superior level metrics. Different relations can exist between ‘parent’ and ‘child’ metrics:

The parent is the sum of its children (e.g. time and cost);

The children are multiplied to calculate the parent (e.g. yield);

The relationship is undefined (but can be statistically observed).




VRM (Value Reference Model), a product of the Value Chain Group7, has a structure similar to SCOR but covers the wider scope of value chain, by integrating aspects of product design, market research and customer relation. However, the architecture is similarly hierarchical, based on a taxonomy of process classes and metrics:

Level 1 consists in 3 process categories called Planning (overlapping with Plan from SCOR), Governing (overlapping with the concept of "Enable" from SCOR) and Execution (covering the rest of the SCOR scope); all three process categories are expanded beyond the scope of SCOR, by approaching also product development, customer relations and the value chain as a whole;

Level 2 and 3 are a process category decomposition similar to the one provided by SCOR. For example the Execute category is split in process types regarding:

o Product design roadmap, with categories such as: Market (further split in Analyze Market, Analyze Performance etc.), Research (Define Opportunity, Forecast Technology etc.), Develop (Define Product Req, Select Technology etc.);

o Supply chain, largely overlapping with SCOR: Acquire (Qualify Supplier, Issue Request etc.), Build (Schedule Resource, Issue Material etc.), Fulfill (Order Inquiry, Confirm Order etc.);

o Product placement and customer relations: Brand (Define Brand Req, Differentiate Brand etc.), Sell (Target Customer, Position Solution etc.), Support (Register Customer, Manage Incident etc.);

Level 4 is, again, customizable to each company process modelling needs. Just as in SCOR, VRM also provides:

compliancy recommendations in the form of input/output specifications for each process category;

a semantic metric taxonomy; here the metrics are grouped in priority dimensions (Reliability, Velocity, Adaptability, Cost, Asset, Innovation and Customer) and classes.

The VRM approximation of Figure 13 is presented in Figure 14:

Figure 14: The VRM approximation of the supply chain landscape

These similarities allow us to approach the process modelling in an integrated approach, by reusing the thread model so that it is able to reflect process landscapes defined in terms of either SCOR or VRM.

7 http://www.value-chain.org, last accessed on last accessed on 26.06.2012




4 THE COMVANTAGE MODELLING METHOD SPECIFICATION

4.1 The Modelling Procedure

The modelling stack represents the high level structure of a modelling method, indicating a grouping of the model types mapped on the modelling goals. Thus, it is driven by the identified modelling scenarios which determine the procedure to be applied for reaching modelling goals. Based on the approached frameworks we have built the modelling stack by aligning actual methodologies employed in designing processes that are subordinated to Lean, Six Sigma, SCOR and VRM with aspects from marketing, business modelling and business process modelling. Further on, the stack has been expanded to also integrate ComVantage specificities (mobile support, Linked Data, access control). The modelling steps identified in this respect are:

1. Express the "voice of the customer", or more precisely the market structure. This step relies heavily on existing market research campaigns whose results can be visually communicated by indicating the identified market segments, their attributes and shares. If no statistics are available for visual representation, an intuitive persona landscape can be created to suggest targeted customer groups. The modelling method should support both approaches;

2. Define a product structure mapped on the voice of the customer. This step relies on variations of the Kano model (Kano et al., 1984) where the product is decomposed in features of several types and these features are mapped on the identified customer attributes. By estimating the contribution to cost and price of each product feature, a modeller should be able to evaluate different product configurations in relation to the known market structure;

These are mainly marketing-driven steps, not specifically related to SCOR or VRM. The next three steps are suggested by these frameworks, but also the e3 value modelling language which has been successful in high-level design of value chains:

3. A product determines a logistical scope of a supply network. All parties involved in creating the product are visualized in a scope model, which can contain or not geographical details;

4. An alternative view on the scope can be the "value constellation" modelled with the e3 value language8. This can express the entire business model as a network of value flows between value generators (ports);

5. A supply network must be decomposed in supply chains. A supply chain is determined by a combination of product configuration and distribution channel. Thus, a scope model should be detailed in several process landscapes determined by a certain customer request type. If a standard framework like SCOR or VRM is used, this process landscape should also indicate flows, enabling and planning processes, and process categorization;

6. Each process in each landscape should have its own process model. Multiple process modelling languages are available nowadays, but for ComVantage purposes this sixth step should be supported by a model type that integrates elements of mobile support, Linked Data consumption and access control policies. Also, organizational roles have to be assigned to various tasks within the specified processes or even process categories (roles assigned to activities, units assigned to level 2 or 3 process categories). This suggests the following additional steps:

7. Each activity in a process should have assigned resources of various types. Some of these can be further described by connected models:

8. An organizational structure model is necessary to describe the human resource allocation to processes;

8 http://e3value.few.vu.nl/, last accessed on 26.06.2012




9. A mobile mockup model is necessary to describe the mobile interaction requirements for executing an activity or a decision. This is helpful when process designers must collaborate with mobile app designers in order to identify the ideal orchestration of app features;

The next steps are suggested by the DMAIC approach in process control. This methodology suggests the following scenarios:

10. Process execution data should be collectible and importable in a process model. A key indicator for each process should be computed by its attributes as a target for Lean and/or Six Sigma monitoring;

11. A process stepper should be used to share knowledge about modelled processes, for example in training scenarios, when employees must become accustomed to new process implementations or improvements.

12. A cause and effect model type is needed to support brainstorming sessions regarding the underperformance of a specific process.

This sequencing of modelling steps define the ComVantage modelling procedure and are the basis for designing the modelling stack described in the next section.

4.2 The Modelling Stack

As previously mentioned, a modelling requirements definition strategy has been employed in order to identify relevant input for the ComVantage modelling method. Existing tools, theoretical research and the ComVantage requirements and architecture workshops have given the input for the current version of the method. The output is, on an high-level of abstraction, support for supply chain design and alignment, process quality management by means of analysis and model exposure in various export formats.

Figure 15: The inputs and outputs of the ComVantage modelling method (v 1.0)

After the modelling scenarios described in the previous section have been identified, they had to be mapped on a model stack grouping several model types, enumerated in Figure 16, and grouped according to the logical grouping of the modelling scenarios: product design with respect to the market structure must be followed by a strategic design of the scope, flows and process landscape required to create the product, then operational-level design of processes enhanced with a mapping on resources is necessary. A




particular type of resource relevant to the ComVantage visionary scenarios is the mobile support which must be designed and orchestrated. On the operational process level we also have the causality model aimed to communicate possible factors for process underperformance.

Figure 16: The ComVantage modelling stack (v1.0)

Figure 17: Overview of the model types from ComVantage modelling method (v 1.0)




Further on, the model types are integrated in a common structural view expressing their concepts and relations (intra-model and cross-model). The cross-model relations are aimed to provide navigational functionality and to support a common view integration of ComVantage model instances.

We will dedicate the next section to mockup descriptions of these model types. Several mentions will be made to how these model types are linked to each other. These links can be more formally followed in Figure 17 and are specified in section 4.4.

4.3 The Model Types

A model type represents a class of models conforming to a clearly delimited part of the modelling language. A model type is a set of concepts and relations that can be combined on the model instance level in different configurations, depending on the modelling goal (e.g. an Organisational structure model type is intended to graphically represent organisational structures).

4.3.1 The Product Structure Model Type This model type aims to describe the product attributes in a fashion derived from Kano's model. It is meant to support the earliest stages of the modelling procedure, when the company:

designs the product structure and classifies its attributes;

relates the structural elements to the "voice of the customer";

identifies candidates in the current supply network that can contribute to fulfilling this structure, in order to design the logistical scope for that specific product and its possible configurations.

The model is centred on an abstract product which is linked to "customization features". These in turn can be further decomposed, thus obtaining a hierarchical product structure. The leaves of the hierarchies are attributes classified according to a derivation of Kano's model in:

Basic features: the product cannot enter the market without them; their fulfilment is of highest priority, since their absence generates strong dissatisfaction, and their presence is taken for granted, with no impact on satisfaction; they are subject to warranties and service level agreements;

Performance features: companies advertise and compete on these, customers refer to these when expressing their needs; they must be weighted for each customer group and they have a strong contribution to pricing; their presence creates satisfaction, their absence creates dissatisfaction.

Excitement features: they function as "delighters", creating positive surprise to the customer, possibly making him aware of extra needs; their absence does not generate dissatisfaction, but their presence can become a major pricing factor;

Secondary features: they have negligible impact on satisfaction or dissatisfaction but they must be part of the product (for example, the company logo).

4.3.2 The "Voice of the Customer" Model Type This model complements the product structure and visualizes the actual market structure for a particular product type. The model can describe market segmentation results from previous market analysis campaign. It can also present market segment preferences without having actual measurements for the segments. The core concept is a segment, which can include a picture reference, if an image is used to make a customer type more memorable (for example, in persona design). If cluster distances are available, they can be visualized on the intersegment distance relation. Each segment is linked to a set of factors (attributes) describing the segment, such as needs. The factor has type attributes with colour coded values, such as needs and goals, on which the product features from the previous model type are mapped.




Figure 18: Mockups for the product and market structure model types

The product and market structure model types have been selected as relevant mainly due to the customization requirements from WP7 and common market research practices such as the persona methodology (Pruitt and Adlin, 2006). However, we consider the model type abstract enough to serve any type of value structure design that must be mapped on customer needs, thus also WP6 plant customizations and maintenance services can benefit from it. Moreover, any supply or value chain design must start from a goal which is the placement of a product or a service on a certain market. Thus a product will determine a business scope (scope model, e3 business model) and its various product attribute configurations may define different supply chains (thread models).

4.3.3 The e3 Business Model Type

The aim of this model type is to support the design of the value chain and it is an alternative to the scope model which is more concerned with the logistical structure of the supply network. The e3 business model type is based on a modelling language described in (Gordijn and Akkermans, 2001). It is a popular approach in the modelling paradigm and is abstract enough to allow the design of value chains independent of domain. It was selected to complement the supply chain view, as the ComVantage method aims to support alternative standards such as SCOR and VRM and thus provide two different views on a business. High level strategic design of ComVantage businesses is to be supported by the strategic level of the modelling stack, which includes, besides the business model type, the scope and thread models which are specific to supply chain design. The requirements workshops of ComVantage have shown that all application partners require means of managing their processes both on the strategic and operational level.

Figure 19 shows an example model where an AND is applied between two value flows. In this model we expect that a total of 50 customers buy the shirt (O:50 at the Start stimulus) over a period of time like one month. However to produce one shirt we need two meters of textile. Since the transaction with the Textile Producer describes the Value transfer for only one meter of textile, we set the Fraction of the Dependency path to two, meaning that the Value transfer will be executed twice as often (since the incoming fraction to




the AND is one). Therefore the occurrences at this path are 100 instead of the initial 50. The Value transfer of the Sewing Company covers the expenses to create one shirt, that’s why we keep the 50 occurrences at that path.

Figure 20 shows an example model9 where the OR is applied and showing the total occurrences and fractions top help understand the calculations. The model shows a Train company providing a ride and a Food company supplying the customers with food. However, from the 10 Occurrences where a Train ride is sold, only half of the customers also want food. Therefore the OR is used to first split the occurrences into two groups of 5, one only wanting the Train ride and the other wanting both the ride AND the food. Another OR is used to put both groups back together to a group of 10.

Figure 19: Example showcasing an AND in a Business Model depicting the creation of a Shirt.

Figure 20: Example showcasing an OR in a Business Model depicting Train rides and Food provision.

9 Based on a model shown in http://e3value.few.vu.nl/docs/misc/ElementaryWeb.pdf (last accessed on 25.06.2012)




Figure 21 shows an example where actual occurrence values for AND and OR elements are showcased. It is not a correct Business model and its only purpose is to help make the connection between Fractions (F) and Occurrences (O) better understandable. It should be noted that the OR does not consider the incoming fraction.

Figure 21: Example with Occurrences (O) and Fraction (F) for AND and OR.

4.3.4 The Scope Model Type

The aim of the scope model is to provide the highest level view on the business scope for a certain product. It is an alternative to the e3 business model type but with focus on the supply network and location attributes instead of the value chain. It uses aggregators to differentiate between business actor types: suppliers, customers, partners, business units under the modeller's company control.

Besides structuring the scope, this model type should support the generation of maps from location attributes. It also indicates the business entities that will be expressed as threads in the thread model describing each supply chain for different product configurations.

Figure 22: Mockup of the scope model type

The model type is driven, just as the previous one, by the need to establish scope for ComVantage businesses, but this time from a supply chain point of view rather than the value chain. This means that logistical aspects are emphasized here, while the e3 business model is more concerned with value flows. All application partners are concerned with defining their processes in a nonambiguous way and these higher level model types are bird views of the scope in which those processes must be executed. Further detail of the processes can be designed with the following model types:




4.3.5 The Thread Model Type

The thread model type supports the design of a supply chain structured according to process categorization standards. Thus, it can serve both SCOR and VRM modelling, by allowing the modeller to indicate:

Business entities participating to the supply chain as threads (swimlanes);

Level 3 process categories together with their flows of inputs and outputs;

Level 2 process categories as aggregations of level 3 elements;

References to planning and enabling processes for each of the elements.

Figure 23: Mockup for a thread model expressing a process landscape compliant to SCOR

Application partner scenarios and requirements consolidation efforts within ComVantage have brought into light the need for non-ambiguous process definitions. SCOR and VRM offer useful tools for "gluing" together the high level business model (the scope and the e3 value landscapes) and the low level operational process models, by encouraging process alignment and standard classifications of processes and key performance indicators.

4.3.6 The Process Model Type

This model type further details each level 3 element of the thread model type by allowing the modeller to design the operational-level processes, made of activities and decisions. While standards such as BPMN10 already exist, they are too complex, are driven rather by BPEL compliance, are considered too technical as a business view11 and lack integration within a clearly defined model stack. We aim to specialise this model type in order to indicate constraints and resource types that are specific to ComVantage, such as mobile interaction and Linked Data support. Figure 24 presents a mockup of such a model with mobile support 10

http://www.bpmn.org/, last accessed on 26.06.2012 11

http://social-biz.org/2010/09/01/bpmn-2-0-no-longer-for-business-professionals/, last accessed on 26.06.2012




assigned to activities. Other types of resources should also be assignable to the process elements. On one hand, human resources need to be assigned to each activity and decision, with references to an organizational structure model. The mobile app support must be the basis of generating an app orchestration model from the existing order of the activities within the process. The process model type must be flexible enough to also describe user interaction flows.

Figure 24: Mockup for a process model extended with mobile interaction support

Design of mobile interaction flows aligned with technical or business processes have been raised as a critical activity in the requirements and architecture workshops of ComVantage. This model type supports alignment and orchestration between mobile apps and operational activities. Also other types of resources are considered, each of them having access control tables assigned to them. Of particular relevance is the Linked Data support that can be assigned to the process elements, to support automatic retrieval of dynamically generated documentation (embedding or generated from Linked Data) for every step of a process. We also consider training scenarios by formulating a specification for a process stepper.

4.3.7 The Mobile Mockup Model Type

This model type supports the design of mobile interfaces with several simple GUI constructs and to assign them to activities in the process models.

Mobile app design and orchestration should be influenced by process flows, thus the ComVantage modelling method will support it with two model types: the mockup design, and an orchestration model (describing mobile along a process).




Figure 25: Mockup of a mobile mockup model

4.3.8 The Mobile Orchestration Model Type

This model type can be derived from an existing process model with assigned mobile support. Thus, it can be merely a modelling tool functionality, rather than a model type in itself. However, we intend to support further editing and expansion of the mobile usage flow, with respect to adaptations for the ComVantage application areas. For this purpose we specify the need to produce it as a separate model type rather than a view of the process model type. Rules for such a derivation are specified in the Appendix of this document.

Figure 26: Derivation by graph transformation of the mobile orchestration model




4.3.9 The Organizational Structure Model Type

This model describes the organizational structure from the highest level units to the actual roles and performers of tasks. Its aim is to extend the process model with roles that can be checked against the permission tables built for each resource assigned to activities. Also, units can be assigned to standard process categories from SCOR and VRM (the thread model).

The model should provide functionality of creating teams of performers.

Figure 27: Mockup of the organizational structure model

While this is not explicitly required based on the current ComVantage scenarios, it is implicitly required by several factors:

The need to extend the process model with human resources (emphasized by machine expert allocation in WP6 and several project management roles in WP8);

The need to provide a starting point for skill models which will be approached in the adaptation tasks for WP6 and WP8.

4.3.10 The Causality Model Type

Once an underperforming process has been identified, causality must be analysed and communicated. This model type will support brainstorming sessions and communication of knowledge on issue or incident causality, by providing an editable fishbone diagram (Ishikawa, 1982).

The model type is recommended by the SixSigma and DMAIC methodologies and is a starting point for further developments in the adaptation tasks (6.2,7.2,8.2), regarding incident management in WP6 and WP8.




Figure 28: Mockup of the causality diagram

4.3.11 Adaptation Prospects

This section aims to bridge the current document with the modelling method adaptation deliverables, by suggesting several extensions that are considered for the three ComVantage application areas.

The funnel model type is to be integrated with the product structure models and to support the visualization of funnel analysis results, an important practice in web-shop market analysis (WP7).

Figure 29: Mockup of the funnel model type

The value stream model, aimed to support production line monitoring and lean process control:

Figure 30: Mockup of value stream mapping




Adaptation of the process model and extension of the organizational structure model with skill models to support the delegation of machine experts and incident escalation in WP6 and WP8:

Figure 31: Mockup for incident escalation

Figure 32: Mockup for a skill model

4.4 Description of the Modelling Language, Mechanisms and Algorithms

This section describes the Model types and their Object types, Relation types and (Model) Attributes. Additionally the Constraints and some Mechanisms and/or Algorithms are described.

4.4.1 The Product Structure Model Type The type of each customization feature will be indicated by colour coding, based on a type attribute. If the performance or excitement type is selected, then a link to a "voice of the customer" model can be created, in order to support easy navigation between the product structure and the market structure. A certain product structure model shows the configuration of a specific product, with its active features. It is possible to generate a table with all the customer groups detected in that model, and the performance/excitement attribute will get a weight for each group. A feature can also link to another product model, to indicate a product part, with its own product structure. Another reference will link the product structure to a Scope model indicating all parties involved in the product's supply chain and a Thread model indicating the process categories along the supply chain. These links indicate that the product is available for sale in the given configuration.




Regarding pricing, each feature will have a cost and a price contribution attribute. Based on it, a pie chart will be generated with cost distribution and price components for a product, and costs and price quotas will be aggregated throughout the entire hierarchy. Another attribute of features will activate or deactivate a feature (with all its sub-features), in order to allow different configurations. A deactivated feature will have a change in its graphical representation. Classes and attributes:

Class: Product The Product object represents a concrete product which is gained or produced in the supply chain. With the product object it is possible to specify different customization features based on the needs of the customer and a pricing factor, which describes different factors which influence on the total price of the product. Besides, based on these values it is possible to estimate the customization cost of the product, which can help you to find out the best supply chain for a customization. A product can be a material or immaterial product or service and has always the same representation. Because products consist of different components it is also possible to compose products from other already defined products.

Attributes (of Product)

Attribute name Type Description

Name String The given name of the product.

Description String Contains an optional description about the product and is used for documentation purpose.

Cost Number The cost of a product for the company.

Price Number The price for a product paid by the customer.

Class: Customization feature The Customization feature defines a part of a product, usually to satisfy a specific need of a particular customer. It is included in a product or is a sub-feature of another Customization feature. A Customization feature also includes a cost and price attribute, which is used for the calculation of the production cost of the product.

The name of the customization feature should be displayed bellow it. Furthermore the colour of the element itself should change depending on the Type of the feature. Basic features should be dark blue, Performance features should be light orange, Excitement features should be green and Secondary features should be light blue. Deactivated features should use a light grey colour.

Attributes (of Customization feature)


Name String The given name of the customization feature.

<Name>

<Name>




Description String Contains an optional description about the customization feature and is used for documentation purpose.

Type Enumeration The type of the customization feature, the possible values are: a) Basic feature, b) Performance feature, c) Excitement feature and d) Secondary feature.

Cost Number The cost for a specific feature. This can be put in relation to the total cost of the Product, providing a percentage of the contribution.

Price Number The price generated by the Customization feature. This can be put in relation to the total price of the Product, providing a percentage of the contribution.

Active Boolean Activates or deactivates a feature for the calculations. This value should only be valid for a certain Product structure model, meaning that the same Customization feature can have different values for this attribute in different models. This is necessary to allow a Product structure model to depict a specific product configuration and experiment with it.

Relation Class: Includes The Includes relation connects a Product or Customization feature to a Customization feature and allows decomposing Products and Customization features, defining which features is included into a certain product or feature.

FROM: Product; Customization feature

TO: Customization feature

No notation Relation Class: Scope model reference The Scope model reference is used to link a certain Product structure model with a Scope model, indicating all the parties involved in the products supply chain for this specific configuration.

FROM: Product structure model

TO: Scope model

No Notation Relation Class: Thread model reference The Thread model reference relation connects the Product structure model to a Thread model, indicating what thread model creates this product configuration.

FROM: Product structure model

TO: Thread model

includes




No notation Relation Class: Influences factor The Influences factor relation is used to connect a Customization feature of type “Performance” or “Excitement” with a Factor from a “Voice of the customer” model. This allows describing the expectations of the customers and what feature influences the satisfaction or dissatisfaction of the customers.

FROM: Customization feature (of type “Performance” or “Excitement”)

TO: Factor

No notation Relation Class: Is product The Is product relation links a Customization feature to a Product, indicating that a Product is used as a feature of another Product.

FROM: Customization feature

TO: Product

Constraints

1. Every Product structure model should contain only one Product. The same Product can however be used in several Product structure models. This allows a Product structure model to depict one specific configuration of a Product.

2. A Product structure model can have only one Scope model reference. However a Scope model can be linked to several Product structure models, which allows reusing it.

3. A Product structure model can have only one Thread model reference. However a Thread model can be linked to several Product structure models, which allows reusing it.

4. A Customization feature can have no more than one Is product relation. Also a Product can be only part of one Is product relation. This is to enforce the reuse of the Customization feature.

Mechanisms/Algorithms

1. Customer group overview. This should generate a table containing all the customer groups/market segments (from a “Voice of the customer” model) connected to the product of this model together with the performance and excitement features and a weight for them for each group.

2. Price and cost calculation. Based on the price and cost of active Customization features, a pie chart will be generated with cost distribution and price components for a product, and costs and price quotas will be aggregated throughout the entire hierarchy.

4.4.2 The “Voice of the Customer” Model Type The core concept is a segment, whose attributes are:

A picture reference, if an image is used to make a customer type more memorable;

The share of the segment, expressed in percentages. If it exists, the share should be displayable;

A table attribute holding imported attributes available from the segmentation results, which describe a cluster;

The segments are linked by an optional relation holding the cluster distance, if available. Additionally every segment is linked to a set of factors describing the segment, such as needs or goals. The factors themselves can be linked to one or more product features (using the Influences factor relation from a Product structure) indicating what parts of a product influence them. A factor can have one specific type selected from the following options:




Need;

Skill;

Goal;

Knowledge;

Other (with a description). Classes and attributes

Normal Notation

Image Notation

Class: Market segment The Market segment is a part of the market for a product. It is the classification of customers by one or more characteristics, in order to identify groups of customers.

The Name of the Market segment should be displayed inside it. The Share should be displayed in percent to the right of it at the top. If a Picture reference is specified it should replace the black and white rectangle and the name should be displayed below it.

Attributes (of Market segment)


Name String The descriptive name of the Market segment.

Description String A description of the segment for a human reader.

Picture reference Image A picture making the Market segment more memorable.

Share Number The share of the segment in percent.

Segmentation results Table A table containing the attributes from the last segmentation results, which describe a cluster. The table should contain the name of the attribute and its value. To allow all types of attributes both the name and the value should be of string type.

Class: Factor A Factor further describes a market segment, their needs, goals, skills and knowledge. It is connected to a Customization feature from the Product structure model indicating what features influence it.

The type should be displayed inside and name of the Factor should be displayed bellow it. The colour of the element should change depending on the selected Type. Need should use dark

blue, Skill should use light blue, Goal should use light green, Knowledge should use light orange and Other should use light grey for the colour of the element.

<Name>

<%>

<Name> <%>

<Name>

<Type>




Attributes (of Factor)


Name String A name for the Factor.

Type Enumeration The type of the factor, possible values are: a) Need, b) Skill, c) Goal, d) Knowledge and e) Other.

Description String A short description of the Factor, especially if it is of the type “Other”.

Relation Class: Distance The Distance relation connects two Market segments and describes the cluster distance between those two.

FROM: Market segment

TO: Market segment

Attributes (of Distance)


Cluster distance Number A numerical value for the cluster distance between the two connected Market segments.

Relation Class: Described by The Described by relation connects a Market segment to a Factor which describes the Market segment.

FROM: Market segment

TO: Factor

4.4.3 The e3 Business Model Type The Business model is used to provide an overview of how money (or value) is acquired and distributed, providing an idea of how a specific company makes or plans to make revenue. It shows the participants and values for one or several products and can be used to check the feasibility for each participant of a specific constellation of actors, companies and customers.

Classes and attributes

Class: Actor An Actor represents one economically entity, either a real company or an abstract role. They can also aggregate (contain) other actors, denoting either a joint partnership or an ownership of the contained actors.

The name of the Actor should be displayed inside the box.

Attributes (of Actor)


Name String The name of the Actor. Either a real world actor or an abstract role (like Machine Supplier).

<Name>




Class: Market segment The Market segment is a part of the market for a product. It is the classification of customers by one or more characteristics, in order to identify groups of customers. In the Business model it represents a group of undistinguishable Actors at once.

The name of the Market segment should be displayed inside the box.

Attributes (of Market segment)


Name String The name of the Market segment, usually denoting an abstract role (like Buyer).

Multiplicity Number An estimate of the absolute size of the Market segment.

vertical

horizontal

Class: Value interface An interface through which value can be exchanged with the Actor/Market segment. Therefore a Value interface belongs to an Actor or Market segment. If a transfer of values is initiated between Actors/Market segments then all Value transfers participating in all the connected Value interfaces need to be carried out.

It should be possible to change the size of the Value interface, either the height (vertical) or the width (horizontal), but not both.

Attributes (of Value interface)


Description String A short description providing some information about the Value interface, for example what is the idea behind it.

Orientation Enumeration The orientation of the Value interface, whether it should be shown vertically or horizontally.

Class: Start stimulus The start stimulus indicates the origin which initiates the transfer of values in the Business model. It belongs to an Actor or Market segment.

Attributes (of Start stimulus)


Occurrences Number How often the transfer of values is initiated by this Actor or Market segment.

<Name>




AND

OR

Class: AND / OR The AND / OR allows to split a Dependency path into several paths and to manipulate the number of occurrences on each of those path.

The difference between AND and OR is how the resulting occurrences are calculated. With an AND the outgoing fraction is related to the incoming fraction while an OR relates an outgoing fraction to the sum of all outgoing fractions. The actual fractions can be found in the connected Dependency paths.

The AND and OR can also be used to merge two or more separated Dependency paths back together. For an AND the actual occurrences of all the incoming paths after considering the fractions need to be exactly the same and it equals the number of resulting occurrences. An OR sums all the incoming occurrences into one outgoing occurrence.

For details about the calculations consult the Mechanisms/Algorithms section.

Attributes (of AND / OR)


Type Enumeration The type can be either AND or OR.

Description String A description for the element, for instance to provide a reason for a split.

Relation Class: Value transfer The Value transfer relation models the transfer of a specific value between two Value interfaces of different Actors/Market segments. It indicates the provisioning and requesting of a certain object. An execution of a value transfer changes the ownership of the corresponding value object. From the point of an Actor an incoming Value transfers is considered as revenue and an outgoing Value transfers as an expense. Relations of this type can be used to connect the same two objects several times.

The name of the transferred object should be displayed next to and connected with the relation.

FROM: Value interface

TO: Value interface

Attributes (of Value transfer)


Transferred object String The object which has some value to the parties participating in the value transfer (e.g. Money). Two objects with the same name should also be considered the same. It is encouraged to reuse the names of the products described in the Product structure models.

<Object>




Outgoing Valuation Number A number representing the monetary value of the object from the perspective of the provider. Usually indicates the expenses for object. If the transferred object is money then it should have the same value as Incoming Valuation, otherwise they can be different since the value of objects is subjective.

Incoming Valuation Number A number representing the monetary value of the object from the perspective of the receiver. It indicates revenue for the receiver. If the transferred object is money then it should have the same value as Outgoing Valuation, otherwise they can be different since the value of objects is subjective.

Relation Class: Dependency path The Dependency path connects the Start stimulus to a Value interface or two Value interfaces of the same Actor/Market segment. Additionally it can connect to and from AND / OR elements. It shows what other values need to be transfer to be able to allow the initial value transfer.

FROM: Start stimulus; AND / OR; Value interface

TO: Start stimulus; AND /OR; Value interface

Attributes (of Dependency path)


Fraction Number A fraction used to calculate the overall revenue/costs. Has to be bigger than zero.

Constraints

1. Every Actor and Market segment needs at least one Value interface, but can have more as well. 2. Every Value interface should have at least one incoming and one outgoing Value transfer (In the

spirit of “One good turn deserves another”), but it is possible to have multiple incoming and/or multiple outgoing Value transfers.

3. Every Value interface can be part of only one Dependency path relation. 4. A Value transfer must connect two Value interfaces which belong to two distinct Actors or Market

segments. 5. A Dependency path must connect two elements (Start stimulus, Value interfaces, AND / OR) which

belong to the same Actor or Market segment. 6. An AND / OR element can have either multiple incoming or multiple outgoing Dependency

paths but not both. It can also have exactly one incoming and one outgoing Dependency path.


1. Calculate revenue/expenses: a mechanism which calculates the revenues and expenses should be provided. The calculation result should be provided for every Actor and Market segment of a specific Business model.

1. The Start stimulus is used as a starting point for the calculation. 2. The occurrences “travel” from the Start stimulus through the Dependency path and Value

transfers.




3. The total starting occurrences are specified by the Start stimulus. In case it is in a Market segment the occurrences are multiplied by the Multiplicity (Actors are considered having a Multiplicity of 1).

4. The AND / OR element can split into multiple Dependency paths and change their number of occurrences when it has exactly one incoming Dependency path: o Occurrence calculation for path x with AND:

This allows multiplying or dividing the occurrences on the path. o Occurrence calculation for path x with OR:

∑ ( )

5. The AND / OR element can merge several Dependency paths if it has exactly one outgoing Dependency path: o Occurrence calculation for resulting path with AND:

This requires that all incoming paths have the same occurrence after the fraction calculation.

o Occurrence calculation for resulting path with OR:

∑

6. A Dependency path initiates all Value transfers connected to its Value interface, which in turn can lead to other Dependency paths.

7. For each Actor the initiated incoming Value transfers are considered as revenues and outgoing Value transfers as expenses. These should be multiplied with the occurrences to get the actual value. They should use the corresponding valuations of the Value transfers.

4.4.4 The Scope Model Type

A Scope model provides an overview of the environment for a product both abstract through connections between entities as well as on a geographical map indicating the distances the material has to travel. The environment of a Scope model should cover groups like a) the company itself, b) suppliers, c) other services, d) customers as well as e) competitors.

Classes and attributes:

Class: Business entity group With a Business entity group a grouping of different business entities is represented. For example a business entity group would represent a supplier or a customer.

A Business entity group uses as its representation the concept of the swimlanes/pools and should therefore be resizable. The name should be displayed inside the group and it should be possible to rotate the name 90° clockwise.

Attributes (of Business entity group)


Name String The given name of the Business entity group.

<Name>




Description String Contains an optional description of the object instance.

Class: Business entity A Business entity represents a company or a concrete part of a company, which can be grouped based on its responsibility in the scope to a specific Business entity group. These business entities can be exported onto a geographical map based on its geo-attributes (e.g. city and street).

The name of the Business entity should be displayed inside the box.

Attributes (of Business entity)


Name String The given name of the business entity (e.g. Warehouse, Production unit etc.).

Description String Contains an optional description about the business entity (e.g. type of business entity).

City String Describes the location of the company, which is used for representation in a map.

Address String Further describes the location of the company, which is used for representation in a map.

Contact information String Information which allows contacting the Business entity, like a phone number or emailing address.

Material flow

Information flow

Relation Class: Relation connection The Relation connection describes which Business entities are connected in a material or information flow to other Business entities. The relation connection is designed to be bidirectional.

The solid line indicates a material flow, the dashed line indicates an information flow and the dotted line indicates the flow of both material and information.

FROM: Business entity

TO: Business entity

Attributes (of Relation connection)


Type Enumeration The type of the relation connection describes the type of relation between two business entities, which can be either a connection where material is involved or a connection where information is involved or both. Based on the type, the representation of the arc is changed to indicate what type is being used.

Description String The description describes the connection between the two business entities.

<Name>




No Notation Relation Class: Represents actor The Represents actor relation connects a Business entity with an Actor from a Business model.

FROM: Business entity

TO: Actor

Constraints

1. Every Business entity can belong to only one Business entity group.

2. A Business entity can be connected to an Actor through the Represents actor relation.


1. Geographic visualization. The Scope model provides a specific feature for representing the locations of the specified business entities. For this purpose, the location attributes of the business entities are used. Based on the defined attributes and relations a graphic is displayed showing a map with the location of the entities and connections between them. The user has the option to choose between two types of connections between the Business entities, using either straight lines or the roads on the map. Additionally it should be possible to provide information about the distance between two connected Business entities on the map. An example of a generated map using Google Maps is displayed in Figure 33.

2.

Figure 33: Generated maps from Google

4.4.5 The Thread Model Type

A Thread model depicts the actual supply chain for a specific product configuration. It is based on a set of processes where the flow of material or information indicates the sequence of execution. For example in SCOR, the process categories for the creation of a product are “Source”, “Make” and “Deliver” in that order. Furthermore there is a category for covering the return of products/material and for planning the other processes. It is developed to use processes from an available standard or set of best practices, but custom processes from the own company can be used as well.





Model Attributes (of a Thread model) Attribute name Type Description

Reliability Metrics Table Lists the specific metrics used to measure the reliability of the companies part in the supply chain. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Responsiveness Metrics

Table Lists the specific metrics used to measure the responsiveness of the companies part in the supply chain. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Agility Metrics Table Lists the specific metrics used to measure the agility of the companies part in the supply chain. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Cost Metrics Table Lists the specific metrics used to measure the costs of the companies part in the supply chain. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Asset Metrics Table Lists the specific metrics used to measure the reliability of the companies part in the supply chain. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Class: Business entity A Business entity in the Thread model has the same meaning as a Business entity from the Scope model. Therefore the elements from the Scope model should be reused.

In this model type the Process categories and Processes executed by the Business entity are shown inside of the unit. This provides an overview of both the involved businesses in a supply chain as well as the employed processes by each one.

The Name of the referenced Business entity, which is also used as the name for the Business entity, should be inserted at <Name>. The Business entity should resizable and in case it represents an entity from the own organization the name should be printed in bold.

Attributes (of Business entity)


Specified Boolean Indicates if the part of the supply chain has been specified by the business entity for this model.

<Name>




Own entity Boolean Indicates that this business entity belongs to the modeller's company.

Class: Process category The Process categories of a Thread model show the scope and the configuration of each involved business entity. It is an aggregation of processes of a specific type, like “Source”, “Make” or “Deliver” in the case of SCOR. The configuration shows if the employed processes are based on creating “-to-stock”, “-to-order” or “engineer” a customer’s order. The notation displays the general flow of the material/product.

The Identifier of the Process category should be visualized at the position of <ID> and the name can be provided at <Name>.

The element should allow a shrunken and an expended view. The shrunken view should show a fixed size rectangle or arrow with the material flow to the preceding and following Process categories or Processes, while hiding the contained Processes. In the expanded view the arrow or rectangle is bigger, should be resizable and should show the contained/aggregated Processes. The flow should then be drawn directly from the processes.

Furthermore the shape of the Process category should either be derived from its ID if a standard like SCOR or VRM is employed or be specified by the user through the Representation attribute.

Attributes (of Process category)


Identifier String The type of the processes employed by a Business entity. If a specific standard or set of best practices is chosen by the modeller when creating the model, then the available values should be restricted to those of the standard. Otherwise the modellers should be free to enter any identifier s/he wants.

Name String The name of the Process category. When using a standard or set of best practices where they are predefined then it should be automatically derived from the Identifier.

Type Enumeration The type of the process. The possible values depend on the specific standard or set of best practices used and the actual value can often be derived directly from the Identifier.

Representation Enumeration If the shape of the Process category cannot be derived from the Identifier or Type then the user should be able to specify it in this attribute. Possible values are: box, left arrow, right arrow.

View Enumeration Specifies if this element should be shown in the shrunken or expanded view.




Description String A description for this the Process Category. Can be used to describe specifics about the process.

Reliability Metrics Table Lists the specific metrics used to measure the reliability of the Process Category. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.


Table Lists the specific metrics used to measure the responsiveness of the Process Category. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Agility Metrics Table Lists the specific metrics used to measure the agility of the Process Category. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Cost Metrics Table Lists the specific metrics used to measure the costs of the Process Category. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Asset Metrics Table Lists the specific metrics used to measure the reliability of the Process Category. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Class: Process Represents a process necessary for the supply chain. Different types of processes are available, like “Plan”, “Source” and “Make” in the case of SCOR, each one performing activities. A Process is further described by a Process Model.

The Identifier of the Process should be visualized at the position of <ID> and the name can be provided at <Name>. If a process is linked to a “Plan” or “Enable” type process, then the top right corner should contain a “P” and/or “E” respectively.

Furthermore the shape of the Process should either be derived from its ID if a standard like SCOR or VRM is employed or be specified by the user through the Representation attribute.

Attributes (of Process)


Identifier Enumeration Identifies what process is depicted. If a specific standard or set of best practices is chosen by the modeller when creating the model, then the available values should be restricted to those of the standard. Otherwise the modellers should be free to enter any identifier s/he wants.

<ID>

<Name>

<ID>

<Name>

<ID>

<Name>




Name String The name of the Process. When using a standard or set of best practices where they are predefined then it should be automatically derived from the Identifier.

Type Enumeration The type of the process. The possible values depend on the specific standard or set of best practices used and the actual value can often be derived directly from the Identifier.

Representation Enumeration If the shape of the Process cannot be derived from the Identifier or Type then the user should be able to specify it in this attribute. Possible values are: box, left arrow, right arrow.

Description String A description for this process. Can be used to describe specifics about the process for a human.

Waste Table The waste in this process based on Lean management. Each row specifies the waste of something and the table should contain columns to specify a) the type of waste, b) a description about the waste, c) how much is wasted in percentages and d) how much is wasted absolute. The possible types of waste are a) Transportation, b) Inventory, c) Motion, d) Waiting, e) Over-processing, f) Over-production and g) Defects. It should aggregate the absolute values from the referenced process model if possible.

Reliability Metrics Table Lists the specific metrics used to measure the reliability of the Process. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.


Table Lists the specific metrics used to measure the responsiveness of the Process. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Agility Metrics Table Lists the specific metrics used to measure the agility of the Process. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Cost Metrics Table Lists the specific metrics used to measure the costs of the Process. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.

Asset Metrics Table Lists the specific metrics used to measure the reliability of the Process. Should contain an identifier for the metric, the name of a metric, the target value, the current value and a formula for calculating the value.




Class: Decision The Decision element within a Thread model allows influencing the flow of material and/or information. Only one of the outgoing flow relations should be chosen. Therefore it should be understood as an exclusive OR.

The Question should always be visible under the element.

Attributes (of Decision)


Question String The question which should be answered to decide what path to follow. It should be understandable by a human.

Description String The description describes the decision usage and is used for documentation purpose.

Splitting Hub

Joining Hub

Class: Hub The Hub object makes it possible to split into several paths in a Thread model which can be executed at the same time. Every splitting Hub should also have another Hub which indicates the joining of the paths. If the splitting Hub has a question then it should be understood as a normal OR, otherwise as an AND. The differentiation between the two can be made through the amount of outgoing flow relations. If it has multiple outgoing it is a splitting hub, otherwise it should be considered a joining hub.

Since there are two different types of hub (splitting and joining) they should also be visualized differently. Also in case of a splitting hub which contains a Question, the attribute value should be shown underneath the element.

Attributes (of Hub)


Question String The question which should be answered to decide what paths to follow. It should be understandable by a human. This also indicates that the Hub should be understood as an OR instead of an AND.

Description String The description describes the hub usage and is used for documentation purpose.

Class: Start The Start symbolizes the beginning of a process chain or path in a Thread model. One usually starts at the customer, while other processes can start near the Push boundary, in order to create the products which are stored.

The name of the Start can be visualized underneath it or it can be hidden.

<Question>

<Question>

<Name>




Attributes (of Start)


Name String The name attribute describes the assigned name of the start object.

Description String The description describes the start usage and is used for documentation purpose.

Display name Boolean Controls if the name should be shown underneath the element.

Critical path end

Not critical path end

Class: End Indicates the end of a path in a Thread model. A path can either be important for the satisfaction of a customer request (e.g. flow of the product) or not important for the satisfaction but still necessary (e.g. disposal of waste or to authorize payment of a supplier after validation of the received material).

The name of the End can be displayed underneath it. If it is not a critical path end then the second notation with the cross should be used, otherwise the first.

Attributes (of End)


Name String The name attribute describes the assigned name of the end object.

Critical path end Boolean Indicates that the path which ends in it is critical to the supply chain, meaning that elements in its path influence the time for delivering a product to the customer. It always occurs at the customer or right before a Push boundary.

Description String The description describes the end usage and is used for documentation purpose.


Class: Push boundary Indicates a stop of the flow in the supply chain. Usually occurs at warehouses, where the direct flow is interrupted until somebody orders/buys the product.

<Name>

<Name>




Material flow

Information flow

Relation Class: Flow Shows the direct flow of material or information between processes (and therefore also process categories) and the direction in which the material/information flows.

Connects Process, Start, End, Hub and Decision elements.

The solid line indicates a material flow, the dashed line indicates an information flow and the dotted line indicates the flow of both material and information.

It should be possible to visualize the Document type and Document ID next to the Flow relation or to hide it.

FROM: Process; Start; Hub; Decision

TO: Process; End; Hub; Decision

Attributes (of Flow)


Flow type Enumeration The type of the flow. Can either be “Material”, “Information” or both.

Condition String The condition which is necessary to be able to execute a flow.

Document type String Specify what type of document is transferred.

Document ID String The ID of the transferred document.

Document description String A description about the transferred document.

No Notation Relation Class: Described by Connects a Process element to a Process model which further describes the activities performed when executing the Process.

FROM: Process

TO: Process model

No Notation Relation Class: Responsible Connects a Process element to an Organizational unit element from an Organizational structure model which is responsible for the Process.

FROM: Process

TO: Organizational unit

No Notation Relation Class: Plans process Connects a Process of the type “Plan” to another Process, indicating which process plans which.

FROM: Process (of type “Plan”)

TO: Process




No Notation Relation Class: Enables process Connects a Process of the type “Enable” to another Process, indicating which process enables which.

FROM: Process (of type “Enable”)

TO: Process

Constraints

1. Every Process category must be in (exactly) one Business entity. 2. Every Process, Decision, Hub and Push boundary must be in (exactly) one Process category. 3. Every Process must have (exactly) one Responsible relation. However a Role or Organization unit

can be responsible for several processes. 4. Every Process must be described by no more than one process model. A process model can however

be reused to describe several processes. 5. The Start must not have an incoming Flow. 6. There amount of Start elements must be exactly the amount of Push Boundaries plus 1 (for the

customer). 7. The End must not have an outgoing Flow. 8. Every Process must have (exactly) one incoming and one outgoing Flow relation. 9. Every Hub and Decision must have at least one incoming and one outgoing Flow relation. 10. Every Hub and Decision must have either two or more incoming or two or more outgoing Flow

relations. 11. If a Thread model is connected to several Product structure models, then all of those Product

structure models must use the same Scope model in their Scope model reference. This allows affiliating a Thread model to exactly one Scope model.

12. All the Business entities of the Thread model and the Flow connections between the processes must also be reflected in the affiliated Scope model.


1. Dedicated to a specific standard/set of best practices. When creating a new Thread model the user should be prompted to choose to use an available standard (like SCOR or VRM), a set of best practices or to use own custom processes. The selection should impact the available IDs and names for Process categories and Processes as well the names for the metric tables (by default they are Reliability, Responsiveness, Agility, Costs and Assets) and the possible metric IDs and names. For example when the modeller chooses to use the SCOR standard, only IDs from that standard should be available and the process, category and metric names should be derived automatically. It should not be possible to mix Process Categories and Processes from different standards in the same Thread model.

2. Check Standard compliancy. This mechanism should check if the created model is fully compliant to the constraints imposed by the selected specified standard or set of best practices. An example for those constraints can be found in SCOR where the incoming and outgoing flow of a Process can go only to other specific Processes. A specific example using SCOR is shown in Figure 3412.

12

http://supply-chain.org/f/SCOR-Overview-Web.pdf, last accessed on 07.05.2012




Figure 34: Example for input and output restrictions from SCOR.

3. Sharing and aligning of Thread models. It should be possible to share a Thread model, especially the own part of the model, with the customers and suppliers. These parts can then be imported in their Thread model, which allows creating one integrated model for the whole supply chain with all involved parties.

4. Aggregation of values. Metric, time, cost and waste values from lower levels should be aggregated accordingly to the higher levels if possible. For example the absolute wastes from the activities of a process should be aggregated to the process or the metrics from a process should be aggregated to the process category. The levels from top to bottom are as follows:

o Thread model; o Business entity; o Process category; o Process; o Process model; o Process model elements (Activity etc.).

5. Simulation of both costs and times of the individual processes. A simulation for the Thread model depicting the supply chain should be provided. It should reuse the simulation values from the underlying process models if available, automatically inserting the “current value” of the corresponding metric.

o For each Start a separate simulation should be carried out; o Every Process should either use a manually specified value or use an available value from

simulating the linked process model; o Every Process category should aggregate the values of all contained Process which lie on

the critical path; o Every Thread model should aggregate the values of all contained Process categories.

6. A Process overview should generate a report containing a list of all the Thread models and Processes involved in the supply chains of a certain product. The processes should first be grouped by the Product it is used to create, second by the Business entity performing them and further grouped by the Process category they belong to. It should also be possible to delimit the processes in the report by selecting one or several Business entities and one or several Products. The resulting report should only show processes which belong to one of the selected entities or are part of a supply chain of one of the Products. Therefore the origin for the creation of the report should be a Scope model, since it provides the structure for one or several Products (also for several product configurations described in separate Product structure models) and can be used directly to select the desired Business entities. The resulting report can either be visualized as a diagram or using text with a similar format to a table of contents. Links can be provided which allow navigating directly to the corresponding models (thread, process, product or scope).




4.4.6 The Process Model Type

A process model depicts the actual activities performed during the execution of a Process from a Thread model.


Class: Activity

Activities describe which tasks in a process model are to be executed.

The name of the Activity should be displayed bellow it. Furthermore it should be possible to visualize the percentage of Waste through the colour of the Activity (based on the Waste attribute values). The colour should reflect the average of all different waste types. If the waste for a specific type is not specified it is assumed to be 0%. An average waste of 0% should use a light blue colour while an average waste of 100% should use a very dark blue.

Attributes (of Activity)


Name String Defines the name of the activity which describes what is executed in this activity.

Description String The description describes the activity in more detail and is used for documentation purpose.

Time Time/duration This is the time required to perform the whole activity (including waiting, resting etc.). It is used for simulation purposes.

Activity cost Number Describes the costs associated with the execution of the Activity. It should not contain the cost for using a modelled resource, since this cost is specified in the Resource relation.

Instructions String A link to a video or page providing instructions by showing or describing how the activity should be performed.

Waste Table The waste in this activity based on Lean management. Each row specifies the waste of something and the table should contain columns to specify a) the type of waste, b) a description about the waste, c) how much is wasted in percentages and d) how much is wasted absolute. The possible types of waste are a) Transportation, b) Inventory, c) Motion, d) Waiting, e) Over-processing, f) Over-production and g) Defects.

Auditing Requirements

String The requirements for the execution of the activity from an auditing point of view. Should answer the question “How can the proper execution of the activity be proven?”

<Name>




Adds value Boolean Indicates if the performance of the Activity adds value directly to the product or not (according to the Lean approach).

Data series String The data series attribute specifies a data series which can be included into an activity, which can be afterwards be used in the mobile mockup model. Through this attribute it is possible to generate automatically a data series in a mobile mockup.

Data table Data table The data table attribute like the data series is used to specify a table which can be used to generate this table automatically in a mobile mockup.

Class: Decision The Decision element allows the separation of the execution path of the process model. Only one outgoing Sequence relation should be chosen. Therefore it should be understood as an exclusive OR.

The Question should always be visible under the element.

Attributes (of Decision)


Question String The question which should be answered to decide what paths to follow. It should be understandable by a human.

Description String The description describes the decision usage and is used for documentation purpose.

Splitting Hub

Joining Hub

Class: Hub The Hub object makes it possible to split into several paths in a process model which can be executed at the same time. Every splitting Hub should also have another Hub which indicates the joining of the paths. If the splitting Hub has a question then it should be understood as a normal OR, otherwise as an AND. The differentiation between the two can be made through the amount of incoming and outgoing sequence relations. If it has multiple outgoing it is a splitting hub, otherwise it should be considered a joining hub.

Since there are two different types of hub (splitting and joining) they should also be visualized differently. Also in case of a splitting hub which contains a Question, the attribute value should be shown underneath the element.

Attributes (of Hub)


Question String The question which should be answered to decide what paths to follow. This also indicates that the Hub should be understood as an OR instead of an AND.

<Question>

<Question>




Description String The description describes the hub usage and is used for documentation purpose.

Class: Process start Every process model must contain exactly one Process start. It symbolizes the beginning of the process model.

The name of the Process start can be visualized underneath it or it can be hidden.

Attributes (of Process start)


Name String The name attribute describes the assigned name of the start object. Usually this one corresponds to the name of the process.

Description String The description describes the start usage and is used for documentation purpose.

Trigger String The trigger attribute allows specifying a trigger by which the process model starts.

Result String The result trigger allows specifying a result which is gained after execution of the process model.


Class: Process end The Process end marks the end of a path in a process model. It indicates that the process has been executed and that the generated output can be used by any following Process or Decision in the Thread model.

The name of the Process end can be visualized underneath it or it can be hidden.

Attributes (of Process end)


Name String The name attribute describes the assigned name of the end object.

Description String The description describes the end usage and is used for documentation purpose.


<Name>

<Name>




Class: Swimlane A Swimlane can be used to separate objects according to different aspects. The division should be denoted by its name.

The name of the Swimlane should be displayed on the top. The Swimlane itself should be resizable. A version which is rotated 90° counter-clockwise (with the name on the left) should also be available.

Attributes (of Swimlane)


Name String The name of the Swimlane.

Description String A description about the Swimlane.

Class: Information resource An Information resource contains information and supports the execution of an activity. The information resource can only be connected with an activity using the resource relation.

The name of the Information resource should be displayed underneath it. If an Information resource represents Linked Data then the second notation should be used, otherwise use the first notation.

Attributes (of Information resource)


Name String The name attribute describes the assigned name of the information resources.

Type Enumeration The type of the Information resource. Can either be a) Other or b) Linked data.

Description String The description describes the information resource usage and is used for documentation purpose.

Roles and permissions Table The roles and permissions specify which roles have access to the resource and based on their permission which operation can be executed by the role. It therefore contains one column for the role and one for the permissions.

Referenced data String The referenced data allows referencing a real data either from the file system or in case it is Linked Data through a URI of the provider and assigning it to the Information resource. This influences if the resource is

<Name>

<Name>

<Name>




Linked Data or not. The tool should allow retrieving and showing the data in a browser using the Parameter-value list or Query attribute.

Parameter-value list Table This attribute can be used to specify parameters and their values in case the Referenced data is an URI and the data can be accessed by parameterizing it. The table should have two columns to specify the parameter name and what value it should have.

Query String This attribute can be used to specify a query which executed on the specified Referenced data attribute results in the actual data represented by this Information resource.

Transport resource

IT resource

Other resource

Class: Hardware resource A Hardware resource describes an infrastructure element or component, which is used in order to execute an activity. The resource can only be connected with an activity using the resource relation.

The name of the Hardware resource should be displayed underneath it. Depending on the Type of the resource the notation should change as well (displayed on the left)

Attributes (of Hardware resource)


Name String The name attribute describes the assigned name of the resource.

Description String The description describes the Hardware resource usage and is used for documentation purpose.

Type Enumeration The type of the resource; can be a) Transport, b) IT or c) Other.

Roles and permissions Table The roles and permissions specify which roles have access to the resource and based on their permission which operation can be executed by the role.

<Name>

<Name>

<Name>




Capacity Number The capacity of the transportation resource. Only applies to Hardware resources of the “Transport” Type.

Consumption Number How much fuel is consumed per 100km. Only applies to Hardware resources of the “Transport” Type.

Class: Sub-process

It is possible to call other processes with a Sub-process element.

This makes sense when a particular process is carried out in several areas of the business. Rather than repeat the same activities within a larger model a number of times, a Sub-process can be called whenever necessary.

Attributes (of Sub-process)


Name String The name attribute describes the assigned name of the IT resources.

Description String The description describes the IT resource usage and is used for documentation purpose.

Without Mockup

With Mockup

Class: Mobile support feature A Mobile support feature represents a feature which is available on a mobile device.

The name of the Mobile support feature should be displayed bellow it. If it is connected to a Mobile mockup model using the Mockup relation, then the notation should show the mockup, preferably framed by a mobile device. By clicking on the screen the user should be taken to the Mobile mockup model. Otherwise the generic rectangle notation should be used.

Attributes (of Mobile support feature)


Name String The name of the Mobile support feature.

Description String Description of the Mobile support feature.

Keywords String Some keywords describing the feature separated using whitespace. Its main use is to search available App marketplaces for possible applications.

<Name>

<Name>

<Name>




Link / App String Either the name of the App which provides this feature or a link in form of an URL to where an App providing the feature can be obtained.

Class: Feature pool Represents an aggregation of several Mobile support features. Can be used to indicate the use of more than one feature for an Activity.

The Feature pool should be resizable.

Relation Class: Sequence relation The Sequence relation connects all the elements in the process model and defines the flow of the activities. A sequence relation can have defined probabilities, which allows a modeller to specify which path is more probable to be executed.

If the Sequence relation has a specified Transition condition, it should be displayed next to it.

FROM: Activity; Sub-process; Process start; Decision; Hub

TO: Activity; Sub-process; Process end; Decision; Hub

Attributes (of Sequence relation)


Transition condition String This attribute describes the condition when a sequence relation should be followed. Usually the answer to the question of a source Decision or Hub.

Transition probability Number This attribute is used for transitions following a Decision or Hub. It describes the probability in which the condition is evaluated to true.

Relation Class: Resource relation The Resource relation allows connecting Activities with different types of resources and vice versa.

FROM: Activity

TO: Hardware resource; Information resource

Attributes (of Resource relation)


Description String This attribute describes the name of the resource relation and is used in order to show in which context a resource is used.

Operation String States what operation is executed on the resource.




Cost Number States the cost for using the connected resource in the Activity. This value should not be contained in cost of the Activity itself. The purpose of the separation is to differentiate the costs for using different resources (different equipment etc.).

Relation Class: Mobile support Allows linking an Activity or Decision to a Mobile support feature or Feature pool which indicates what feature(s) supports a decision or an activities execution.

FROM: Activity; Decision

TO: Mobile support feature; Feature pool

No Notation Relation Class: Assigned units Assigns a Role from an Organizational structure model to an Activity or Decision.

FROM: Activity; Decision

TO: Role

No Notation Relation Class: Referenced process The Referenced process relation links a Sub-process to a Process model, indicating what process should be executed in place of the Sub-process.

FROM: Sub-process

TO: Process model

No Notation Relation Class: IT resource input This relation represents the input for a Hardware resource of the type “IT”. The resource can take an Information resource as input, which is necessary to execute the activity in which the resource is involved.

FROM: Hardware resource (of type “IT”)

TO: Information resource

No Notation Relation Class: IT resource output A Hardware resource of the “IT” type can also produce an output after an Activity is completed. This relation links the resource to the Information resource representing the output.

FROM: Hardware resource (of type “IT”)

TO: Information resource




Constraints

1. No element can have both multiple successors and multiple predecessors. 2. Every process model must have exactly one Process start and one Process end element. 3. A Process start cannot have any incoming Sequence relations. 4. A Process end cannot have any outgoing Sequence relations. 5. An Activity can have multiple incoming but only one outgoing Sequence relation. 6. The table containing the Waste of an Activity can contain each waste type only once. 7. If the source of a Sequence relation is a Decision, then the sum of the Transition probabilities of all

outgoing Sequence relations (from the Decision) must be exactly 1.


1. Access validation. The access validation should check if the elements of a process model access any resource (Information or IT) to which they have no permission. A resource has a permission table containing the Roles and what operations they are permitted to perform. If the responsible Role or Performer of an Activity is accessing a resource with an operation for which it has no permission then the validation fails and should provide an error to the modeller.

2. Simulation of both costs and times of the individual processes. The simulation of processes resulting in total cost and time values for the entire process should be made available. The simulation should use the specified Transition probabilities when confronted with several outgoing relations to determine which path to take. The results from the simulation should be made available to all Thread models referencing the process.

3. Different views on the model should be provided by the tool. o Mobile support feature view. The tool should provide the means to visualize the Mobile

support features in place of the Activities in the process while still showing the Activities which are not supported by a Mobile support feature.

o Selective view. The tool should provide the means to hide some or all of the elements of the type Mobile support feature, Hardware resource and Information resource and the relations in which they participate. It should be possible for the user to choose which of those types to hide. Through this the readability of the model can be enhanced.

o Reduced view. The tool should provide the means to hide all elements of the type Mobile support feature, Hardware resource and Information resource and instead show a small icon for each of those types next to (preferably above) the Activity which has a connection to such an element. Additionally the Assigned unit should also be shown as an icon. It should also be possible to retrieve information about those linked elements without having to change the view. Again this is meant to enhance the readability of the model. An example for how this can look can be seen in Figure 35, where both Activities are connected to a Role and a Hardware resource, but only the first one is connected to an Information resource and the second one to a Mobile support feature.

Figure 35: Example for the reduced view of a Process model




4. Support in creation a Mobile orchestration model. The process model can be used to automatically generate the corresponding Mobile orchestration model. A description how this can be achieved can be found in Appendix A.

5. Process stepper mechanism is a functionality aimed to support the process implementation phase of the DMAIC methodology. When used in training scenarios, to acquire employees with newly designed processes, it allows the user to run through the process step by step. While going through each step, the process stepper needs to show in a separate view/panel information on the current step, taken from the existing attributes of the activity/decision from that step, for example:

o The mobile mockup assigned to the step; o A video describing the activity; o A popup question indicating the key question of a decision; o Other instance attributes (name, description, documentation links etc.).

After reviewing the instance information provided, the user can move forward to the next instance of the process model type by clicking on the “Next” button in the process stepper popup window. In Figure 36 it is shown how the process stepper should behave when encounters an activity, whereas in Figure 37 it is shown how the process stepper behaves when encountering a decision.

Figure 36: Process stepper encounters an Activity.




Figure 37: Process stepper encounters a Decision

4.4.7 The Mobile Orchestration Model Type

The Mobile orchestration should help in designing and developing mobile applications to support a certain process model. For this it uses the basic constructs of the Mobile support feature, the Feature pool (an aggregation) and the Followed by relation. A graph rewriting algorithm generates the Mobile orchestration model from an existing process model.

Classes and attributes

Without Mockup

With Mockup

Class: Mobile support feature A Mobile support feature represents a feature which is available on a mobile device.

The name of the Mobile support feature should be displayed bellow it. If it is connected to a Mobile mockup model using the Mockup relation, then the notation should show the mockup, preferably framed by a mobile device. By clicking on the screen the user should be taken to the Mobile mockup model. Otherwise the generic rectangle notation should be used.

<Name>

<Name>




Attributes (of Mobile support feature)


Name String The name of the Mobile support feature.

Description String Description of the Mobile support feature.

Keywords String Some keywords describing the feature separated using whitespace. Its main use is to search available App marketplaces for possible applications.

Link / App String Either the name of the App which provides this feature or a link in form of an URL to where an App providing the feature can be obtained.

Class: Feature pool Represents an aggregation of several Mobile support features. Can be used to indicate the use of more than one feature for an Activity.

The Feature pool should be resizable.

Relation Class: Followed by Indicates what Mobile support feature or Feature pool follows after another Mobile support feature or Feature pool, resulting in a sequence.

The Trigger should be displayed next to the relation.

FROM: Mobile support feature; Feature pool

TO: Mobile support feature; Feature pool

Attributes (of Followed by)


Trigger String The event which triggers the change from one feature to the next.

Description String Description about the trigger.

No Notation Relation Class: Has mockup The Has mockup relation indicates which Mobile mockup model describes which Mobile support feature.

FROM: Mobile support feature

TO: Mobile mockup model

Constraints

1. A Mobile support feature can be connected to only one Mobile mockup model using the Has mockup relation.





1. App search in available markets. It should be possible to search the most common stores and markets providing Apps for the different mobile device operating systems based on the Keywords specified for a certain Mobile support feature. Before starting the search the user should specify the platform of the mobile device.

4.4.8 The Organizational Structure Model Type This model describes the organizational structure from the highest level units to the actual roles and performers of tasks. Its aim is to extend other models via references, by assigning:

Roles to activities or decisions;

Roles or units to processes.


Class: Organizational unit The object Organizational unit allows you to show the hierarchy of the departments and units in a company. The unit also shows which actors are responsible in it. Also it is possible to hierarchically structure one Organizational unit into smaller Organizational units.

The name of the Organizational unit should be displayed inside it.

Attributes (of Organizational unit)


Name String The name attribute describes the assigned name of the Organizational unit.

Description String The description describes the Organizational unit usage and is used for documentation purpose.

Type Enumeration This attributes indicates the type of the unit from a list of types, which are: standard, company, division and department.

Manager String This attribute is used to enter the name of the head of the Organizational unit.

Function String This attribute is used to enter the function of the manager.

Number of positions Number This attribute indicates the planned number of positions in an Organizational unit.

Number of occupied positions

Number This attribute indicates the number of occupied positions in an Organizational unit.

Number of open positions

Number This attribute indicates the number of vacant or open positions in an Organizational unit.

<Name>




Class: Performer

The objects of the Performer class represent the individual performer or person in a working environment. Every performer can have one or more roles specified and belongs to one or more Organizational units.

The name of the Performer should be displayed below it.

Attributes (of Performer)


Name String The name attribute describes the assigned name of the actor.

Description String The description describes the actor usage and is used for documentation purpose.

Further education Table This attribute is defined as a table and allows you to specify the education of the actor through the seminar/course title and the participation date.

Hourly wages Number This attribute is used to define the hourly wage which the performer receives. This attribute is important because it is the base for further analysis and simulations.

Availability Number The availability indicates the percentage of the time the performer was available.

Class: Role The Role describes a task-range or job description and is assigned to one or several Performers.

The name of the Role should be displayed below it.

Attributes (of Role)


Name String The name attribute describes the assigned name of the role.

Description String The description describes the role usage and is used for documentation purpose.

Class: Team A Team is an aggregation of several Performers, indicating that the contained performers work together as a team on something.

The name of the Team should be displayed in the top left corner.

R

<Name>

<Name>




Attributes (of Team)


Name String The name of the team.

Description String A short description about the team, its purpose etc.

Relation Class: Has subunit The relation Has subunit connects 2 Organizational units creating a hierarchy. The relation is used from the object which is super ordered to the lower ordered one.

FROM: Organizational unit


Relation Class: Has position The relation Has position connects a Performer with an Organizational unit. The relation is used to indicate which performer is positioned in which Organizational unit.

FROM: Performer


Relation Class: Acts in role The relation acts in role connects a Performer with a Role object and indicates the responsible roles of the performer. A performer can be assigned with this relation to more than one role.

FROM: Performer

TO: Role

Constraints

1. Every Performer must be assigned to an Organizational unit.

2. Every Team must contain at least one Performer.

4.4.9 The Mobile Mockup Model Type The Mobile mockup model is used to define a mockup for Mobile support feature. One model represents a screen on the mobile device. Therefore its size should be fixed to the size of the mobile device. Classes of the Mobile mockup model can only be put in into the defined space of the model. The Mobile mockup model will also provide different types of predefined models (patterns), which can be used by the user in order to design the model faster. The Mobile mockup model will support two different types of creation:

1. Autonomous – in which the Mobile mockup model is created standalone, without any information provided by the process model.

2. In context of a process model – the Mobile mockup model will be provided with information from a process model (e.g. different data series and tables from activities, questions and possible answers from decisions), so every time the user changes the information from the activity or decision, the information in the mobile mockup model gets changed. This functionality is implemented through a reference, which is called Reference to attribute.





Model Attributes (of a Mobile mockup model)


Name String Defines the name, which is relevant for identification of the element.

Background colour String Describes the colour which is drawn in the background.

Image path String The image path is used to specify an image which will be shown in the background, like the common user interface of the Android OS.

Height Double Defines the height of the whole mockup.

Width Double Defines the width of the whole mockup.

Device type Enumeration The device type specifies which device can use the defined mockup. As value of the attribute there will be shown an enumeration list of different device types (e.g. HTC, Samsung, iPhone, Nokia, Sony Ericsson, Motorola, Blackberry, LG etc).

OS Enumeration The OS attribute allows the user to specify the underlying operation system, which can be used with the developed mockup model (e.g. Android, Windows Phone, iOS, Symbian, HP WebOS, Blackberry OS etc.).

OS Version String The version of the operating system for which it is intended.

Class: Label The Label class defines a regular text which is displayed in the mockup. A Label is displayed as a rectangle and has all relevant options and attributes for different text representations. The lines of the rectangle are usually not displayed when created.

Attributes (of Label)


Content String Describes the content of the label.

Text size Number Describes the size of the text which is written in the label.

Font Enumeration Describes the used font in the label.

Colour Enumeration Describes the used colour of the text.

Background colour String Describes the colour of the label itself.

Border Number Describes the thickness of the border.

Border colour String Describes the colour of the border.

Width Number Describes the maximum width of the label box.

Height Number Describes the maximum height of the label box.

Label text




Class: Text box The Text box class defines an input possibility for the mobile app user. As input it takes every text which is defined in it.

Attributes (of Text box)



Value String Defines the value, which is put in by the user.


Font Enumeration Describes the used font in the text box.

Colour String Describes the used colour of the text.

Background colour String Describes the colour of the text box itself.


Border colour Enumeration Describes the colour of the border.

Width Number Describes the maximum width of the text box.

Height Number Describes the maximum height of the text box.

Class: Button The Button class enables the user to make an interaction with the mobile app.

Attributes (of Button)




Font Enumeration Describes the used font in the button.

Colour String Describes the used colour of the text.

Background colour String Describes the colour of the button itself.


Border colour String Describes the colour of the border.

Width Number Describes the maximum width of the button.

Height Number Describes the maximum height of the button.

Action String Describes what the outcome is of the button when clicked.

Class: Media The Media class allows the user to specify a certain media file like an image or video.

Button name




Attributes (of Media)



File path String Defines the path of the file which is included.

Show content Boolean Allows the user to specify if the content should be displayed or not.

Width Number Describes the width of the media representation content.

Height Number Describes the height of the media representation content.

Class: Radio button The Radio button describes options which can be chosen by the user. The user can only select one of the given options.

Attributes (of Radio button)



Selected Boolean Defines weather the Radio button is selected or not.

Group name String The name of the group to which this Radio button belongs to.

Width Number Describes the width of the radio button.

Height Number Describes the height of the radio button.

Class: Checkbox The Check box describes options which can be chosen by the user. The user can select multiple given options at the same time.

Attributes (of Checkbox)



Checked Boolean Defines weather the check box is checked or not.

Width Number Describes the width of the check box.

Height Number Describes the height of the check box.

Class: Table The Table class allows the user to better arrange the defined object.




Attributes (of Table)



Cell value String Defines the value which will be shown in the cell.

Number of columns Number Defines the number of columns of the table.

Number of rows Number Defines the number of rows of the table.

Height of cells Number Defines the height of the cells.

Width of cells Number Defines the width of the cells.

Background colour String Defines the background colour for each cell.

Text size Number Describes the size of the text in the cells.

Text font Enumeration Describes the used font for each cell.

Constraints

1. The size of a Mobile mockup model should be fixed to the size of the mobile device.

2. Exactly one Radio button from all Radio buttons belonging to the same group must be selected at a

time.

4.4.10 The Causality Model Type The Causality model depicts the decomposition of a certain problem into smaller and more manageable causes.


Class: Problem The Problem describes the main problem. It is possible to link other causes with influence on the problem.

Attributes (of Problem)


Name String The name of the Problem.

Description String Contains an optional description about the main problem, clarifying ambiguities and is used for documentation purposes.

Reason String Indicates the reason or cause of the problem (e.g. omission, lack of knowledge, miscommunication, and accidental).

Solution String Defines the possible solutions for the problem (e.g. revise standards, guidelines, provide training etc.)

Class: Cause The Cause object enables you to specify causes which influence on another cause. An influenced cause is graphically connected to the Problem.




Attributes (of Cause)


Name String The given name of the cause.

Description String Contains an optional description about the cause and is used for documentation purposes.

Reason String Indicates the reason of the cause (e.g. omission, lack of knowledge, miscommunication, and accidental).

Solution String Defines the possible solutions for the problem (e.g. revise standards, guidelines, provide training etc.)

No Notation

Relation Class: Decomposed by cause The Decomposed by cause relation is used to link a Cause or a Problem to another Cause, indicating decomposition. This is necessary to trace a leaf Cause to the main Problem.

FROM: Problem; Cause

TO: Cause

No Notation Relation Class: Problem process A Problem process connects the Problem of a Causality model with a Process model, allowing the decomposition of a specific problem from the process model in to smaller and easier to handle causes.

FROM: Problem

TO: Process model

Constraints

1. A Causality model can contain only one Problem.


1. Creation of causes. The Causality model should provide a mechanism for adding new causes and properly linking them to other causes or the problem. This should preferably happen by right clicking the cause to further decompose and then selecting “create new cause”. When creating a new Cause connected directly to the Main cause a popup should appear providing the modeller with the option to choose either a label from a predefined list of causes e.g. people, process, equipment, management, environment and materials or to specify his own cause. For all other created causes a popup should prompt the modeller to specify his own label.

4.5 Model Type-independent Requirements

4.5.1 General Classes and Attributes

The here described classes have a general purpose and should therefore be available in all model types.





Class: Note A Note is a general element which can be used to leave comments or graphics on the modelling canvas. It is intended to provide information to human readers.

The content should be displayed inside the note. If a background graphic is specified it should be visualized as the background of the note with the text in front of it.

Attributes (of Note)


Text Content String The text to be displayed inside the note

Background graphic String A graphic which should be used as the background of the note.

No Notation Relation Class: Contains The Contains relation describes the relation between an aggregation or a container and its contents. The source and target of the relation are different from container to container and are therefore described below.

Specific cases (of Contains)

Container (FROM) Element (TO)

Actor Actor, Value interface, Start stimulus, AND / OR

Business entity group Business entity

Business entity Process category, Process, Decision, Hub, Start, End, Push boundary

Feature pool Mobile support feature

Market segment Value interface, Start stimulus, AND / OR

Process category Process, Decision, Hub, Start, End, Push boundary

Swimlane Activity, Decision, Hub, Process start, Process end, Information resource, Hardware resource, Sub-process, Mobile support feature, Feature pool

Team Performer

Table Table, Label, Text box, Button, Media, Radio button, Checkbox

4.5.2 Generic Requirements

It should be possible for the modeller to traverse all relations in both directions, meaning from source to target and from target to source. This is especially important for relations which are not shown graphically (have no notation), thus they define inter-model navigation;

Element types with the same name should be reused in the model types and instances of those types should be reusable throughout the models as far as possible and meaningful. For example the same Market segment elements should be usable in the “Voice of the customer” model as well as the Business model. The descriptions in this specification provide a “view” on the instances, describing what information must be provided in the actual models. The elements can however

<Content>




provide more information as well (e.g. the attributes of the Market segment described in the “Voice of the customer” model can also be accessible from the Business model) if deemed necessary.

All described relations have exactly two endpoints and the default cardinality for a relation type is many-to-many (n:m), if not further specified under constraints. For the most relation types it should not be possible to connect two objects with the same relation type twice. If it should be necessary to connect two objects with several relations of the same type it will be stated in the relation description.

An option to expose the model structures as Linked Data should be made available. The exported file should allow reconstructing the major parts of a model and to query the data using SPARQL. It is not necessary to provide the data which is used purely for visualization (positions etc.). For example the Market segments from a “Voice of the customer” model or the execution time of the Processes employed by a Business entity in a Thread model representing a specific supply chain should be available in the exported Linked Data. Section 4.5.2 will be dedicated to describe the exposed RDF data structure.

The owner of a model (user who created the model) should be made aware of any changes to the models he created. These changes can occur either by the owner itself, someone else which has access to the models or automatically through propagation from other models. An example for automatically propagated changes would be to change the name of a Market segment in a “Voice of the customer” model which also changes the name of the same reused Market segment in an e3 business model.

An option to query the different model types. The query option provides the user with a query template, which can be used to query information about the models and their components. Also an option to present the results of a query as a report should be available. These reports can provide an overview either graphically as a diagram, a chart or using text (plain or formatted). The user will be provided with predefined queries in order to query faster and easier. Categories of predefined queries could be following:

o Get all objects/instances of a certain class in a certain model type (e.g. Get all activities from an instance of the process model type).

o Get all objects/instances of a certain class in a certain model which have an attribute with a specific value or value range, e.g.:

Get all activities from a process model with attribute adds value set to false. Get all activities from a process model with attribute activity cost greater/equal

than 150.00. o Get all objects/instances of a certain class in a certain model which are connected with a

relation to another object/instance, e.g.: Get all activities which are connected with a mobile support relation to a mobile

support feature. Get all activities which are connected with a resource relation to an information

resource. o Get all relations of a certain relation class in a certain model, e.g.:

Get all sequence relations in a process model. Get all has subunit relations and their connected units in the organizational

structure model. o Get all relations of a certain relation class in a certain model type which have an attribute

specified with a specific value, e.g.: Get all resource relations from a process model, with attribute cost less than 50.00. Get all sequence relations from a process model type, with attribute transition

probability greater than 0.85. o Get all objects/instances of a certain class in a certain model which have an attribute stored

as table and where one of the records has a certain value or value range, e.g.:




Get all activities in which the attribute mockup input has a record with value “checkbox” in the column type.

4.5.3 The Exposure of Models as Linked Data

The tool should provide means to expose the created models in the here described Linked Data format. For this it should provide two options: a) saving the Linked Data locally in a file or b) upload it directly to a URI from the Linked Data cloud via HTTP. It should be saved using TriG syntax13 to conserve named graphs. When uploading models into the Linked Data cloud the HTTP PUT method14 should be employed to ensure that previous data is replaced.

The namespace used for depicting the concepts from the specification (classes, relations etc.) like Process or Product is “http://www.comvantage.eu/mm#” (for the following examples, the cv: prefix will be used to indicate this namespace). For the elements created by the user any valid namespace can be used. To identify the individual concepts the here specified names are to be used. The identification on the model level should be composed from either the Identifier (if available) or the Name together with a unique number placed afterwards to further distinguish different elements with the same name. If a name or identifier contains a whitespace it should be replaced by an underline (_) and underlines should be escaped using a backslash (\_). As an example:

2. the identifier for the Process Category type is http://www.comvantage.eu/mm#Process_Category, 3. for the Flow relation type is http://www.comvantage.eu/mm#Flow, 4. for the Description attribute the identifier is http://www.comvantage.eu/mm#Description, 5. and for an Activity with the name “Repair” the identifier is

http://www.example.ex/MaxSample#Repair_2.

Table 1 shows the specific constructs (classes) which have been predefined to allow distinguishing models, instances relations and other concepts. In Table 2 the mappings between the modelling concepts and corresponding Linked Data elements are provided. These mappings describe how the models should be exposed in Linked Data format. In Figure 38 the described constructs and mappings are applied to a small part of this specification, showing the relations between the different constructs.

Specific constructs introduced

Construct Description

cv:Model_class A class containing models, meaning that a resource of this type represents a model (The set of all possible models). For example the model type process model is a subclass of this.

cv:Instance_class

A class containing instances, meaning that resources of this type represent an instance/object (The set of all possible concept instances). For example the concept class Activity is a subclass of this.

cv:Relation_class

A class containing relations which have attributes, meaning that resources of this type represent a relation with attribute values. The resources should also use cv:from_instance and cv:to_instance to indicate the source and target of the relation (The set of all possible relation instances with attributes). For example the relation class Sequence relation is a subclass of this.

13

http://www4.wiwiss.fu-berlin.de/bizer/trig/, last accessed on 26.06.2012 14

http://www.w3.org/TR/2011/WD-sparql11-http-rdf-update-20110512/#http-put, last accessed on 26.06.2012




cv:na_relation_property

A class of properties containing relations without attributes between resources, meaning that properties of this type have no attributes (The set of all possible relations without attributes). Its main purpose is to facilitate cross-model querying. For example the relation without attributes Assigned units is an instance of this.

cv:attribute_property

A class of properties containing attributes, meaning that properties of this type represent an attribute and the object is its value. It is a subclass of rdf:Property (The set of all attributes). For example the attribute Activity cost is an instance of this.

cv:contains A property stating that a thing (e.g. instance, relation) is contained by an aggregation.

cv:described_in

A property stating that additional information about a thing (e.g. instance, relation) can be found in a different graph. Therefore it also states that the object is foreign in the graph (i.e. is not part of the model).

cv:from_instance

A property providing the source of a relation with attributes (i.e. of cv:Relation_class type). The subject is the relation and the object is the source. It is not possible to use rdf:domain to denote the source of a relation, because they are used on the instance level and not the schema level.

cv:to_instance

A property providing the target of a relation with attributes (i.e. of cv:Relation_class type). The subject is the relation and the object is the target. It is not possible to use rdf:range to denote the target of a relation, because they are used on the instance level and not the schema level.

Table 1: Predefined Linked Data constructs to be provided as reference classes by the modelling tool

Metamodel level

Modelling Concept Linked Data mapping

Any Model type is … Instance of rdfs:Class

Subclass of cv:Model_class

Any Concept class is … Instance of rdfs:Class

Subclass of cv:Instance_class

Any Relation class with attributes is …

Instance of rdfs:Class

Subclass of cv:Relation_class

Any Relation class without attributes is … Instance of cv:na_relation_property (and rdf:Property)

Any Attribute is … Instance of cv:attribute_property (and rdf:Property)

Model level

Modelling Concept Linked Data mapping

Any Model is … Instance of the corresponding Model type class.

An RDF-Graph (called model graph).

Any Instance is … Instance of the corresponding Instance type class in




every model graph where it is used.

Any Relation with attributes is …

Instance of the corresponding Relation type class in every model graph where it is used.

It also has two properties indicating the source and target using cv:from_instance and cv:to_instance.

Any Relation without attributes is …

A triple where the subject is the source instance and the object is the target instance. The predicate should use the corresponding relation property type. If the two elements are in different models then the statement should also be in both model graphs.

Any Attribute value is ..

The object of a triple where the subject is the instance and the predicate is the corresponding Attribute property. If the value is a complex value (for example, a table), it should be represented in rdf:XMLLiteral format.

Table 2: Modelling concepts mapped on the Linked Data constructs

Figure 38: Linked data constructs for describing the models




Next, an example of two simple models exposed as Linked Data will be provided. Figure 39 shows both a process model and an organizational structure model which are linked through the Assigned units relations. For the example only certain attributes of the elements will be considered: a) Activity cost, b) Question, c) Transition probability and d) Transition condition. In Code 1 the Linked Data using the TriG notation for the example models is shown.

The first graph (cv:metamodelgraph) for the predefined constructs and general metamodel concepts like Activity. It is suggested to create or export these parts only once and further reuse them, since the things described there should not change from model to model. The second graph (:MaintenanceModel_1) contains the process model data and the third graph (:OrgStrModel_10) shows the data from the Organizational structure model. The ownership connection between a model and a contained modelling element (instance or relation) is realized by stating the type of the element in the graph. However it can also be made explicit using the cv:described_in property relating the element directly to a model as used in the example of the Expert Role.

Figure 39: Exemplary models to be exposed as Linked Data

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.

@prefix cv: <http://www.comvantage.eu/mm#>.

@prefix : <http://www.dke.univie.ac.at/MaxSample#>.

cv:metamodelgraph {

# Specific constructs introduced

cv:Model_class rdf:type rdfs:Class.

cv:Instance_class rdf:type rdfs:Class.

cv:Relation_class rdf:type rdfs:Class.

cv:na_relation_property rdf:type rdfs:Class.

cv:attribute_property rdf:type rdfs:Class.

cv:contains rdf:type rdf:Property.

cv:described_in rdf:type rdf:Property.

cv:from_instance rdf:type rdf:Property.

cv:to_instance rdf:type rdf:Property.




# Metamodel level

cv:Process_model rdf:type rdfs:Class.

cv:Process_model rdfs:subClassOf cv:Model_class.

cv:Organizational_structure_model rdf:type rdfs:Class.

cv:Organizational_structure_model rdfs:subClassOf cv:Model_class.

cv:Process_start rdf:type rdfs:Class.

cv:Process_start rdfs:subClassOf cv:Instance_class.

cv:Process_end rdf:type rdfs:Class.

cv:Process_end rdfs:subClassOf cv:Instance_class.

cv:Activity rdf:type rdfs:Class.

cv:Activity rdfs:subClassOf cv:Instance_class.

cv:Decision rdf:type rdfs:Class.

cv:Decision rdfs:subClassOf cv:Instance_class.

cv:Role rdf:type rdfs:Class.

cv:Role rdfs:subClassOf cv:Instance_class.

cv:Performer rdf:type rdfs:Class.

cv:Performer rdfs:subClassOf cv:Instance_class.

cv:Organizational_unit rdf:type rdfs:Class.

cv:Organizational_unit rdfs:subClassOf cv:Instance_class.

cv:Sequence_relation rdf:type rdfs:Class.

cv:Sequence_relation rdfs:subClassOf cv:Relation_class.

cv:Assigned_units rdf:type rdf:Property.

cv:Assigned_units rdf:type cv:na_relation_property.

cv:Has_position rdf:type rdf:Property.

cv:Has_position rdf:type cv:na_relation_property.

cv:Acts_in_role rdf:type rdf:Property.

cv:Acts_in_role rdf:type cv:na_relation_property.

cv:Question rdf:type rdf:Property.

cv:Question rdf:type cv:attribute_property.

cv:Activity_cost rdf:type rdf:Property.

cv:Activity_cost rdf:type cv:attribute_property.

cv:Transition_condition rdf:type rdf:Property.

cv:Transition_condition rdf:type cv:attribute_property.

cv:Transition_probability rdf:type rdf:Property.

cv:Transition_probability rdf:type cv:attribute_property.

}

# Graph data

:GraphMetadata

{

:MaintenanceModel_1 rdf:type cv:Model_class.

:MaintenanceModel_1 rdf:type cv:Process_model.




:OrgStrModel_10 rdf:type cv:Model_class.

:OrgStrModel_10 rdf:type cv:Organizational_structure_model.

}

# Model level

:MaintenanceModel_1

{

:Repair_2 rdf:type cv:Instance_class.

:Repair_2 rdf:type cv:Activity.

:Repair_2 cv:Activity_cost "".

:Repair_2 cv:Assigned_units :Expert_5.

:Expert_5 cv:described_in :OrgStrModel_10.

:Analyse_4 rdf:type cv:Instance_class.

:Analyse_4 rdf:type cv:Activity.

:Analyse_4 cv:Activity_cost "".

:Analyse_4 cv:Assigned_units :Expert_5.

:Maintenance_start_8 rdf:type cv:Instance_class.

:Maintenance_start_8 rdf:type cv:Process_start.

:Process_end_7 rdf:type cv:Instance_class.

:Process_end_7 rdf:type cv:Process_end.

:Decision_14 rdf:type cv:Instance_class.

:Decision_14 rdf:type cv:Decision.

:Decision_14 cv:Question "Broken?".

:Sr_3 rdf:type cv:Relation_class.

:Sr_3 rdf:type cv:Sequence_relation.

:Sr_3 cv:from_instance :Decision_14.

:Sr_3 cv:to_instance :Repair_2.

:Sr_3 cv:Transition_condition "Broken = Yes".



:Sr_6 cv:from_instance :Maintenance_start_8.

:Sr_6 cv:to_instance :Analyse_4.



:Sr_9 cv:from_instance :Repair_2.

:Sr_9 cv:to_instance :Process_end_7.



:Sr_15 cv:from_instance :Analyse_4.

:Sr_15 cv:to_instance :Decision_14.



:Sr_16 cv:from_instance :Decision_14.

:Sr_16 cv:to_instance :Process_end_7.

:Sr_16 cv:Transition_condition "Broken = No".

}




:OrgStrModel_10

{

:Expert_5 rdf:type cv:Instance_class.

:Expert_5 rdf:type cv:Role.

:Repair_2 cv:Assigned_units :Expert_5.

:Repair_2 cv:described_in :MaintenanceModel_1.

:Analyse_4 cv:Assigned_units :Expert_5.

:Analyse_4 cv:described_in :MaintenanceModel_1.

:Schubert_11 rdf:type cv:Instance_class.

:Schubert_11 rdf:type cv:Performer.

:Schubert_11 cv:Acts_in_role :Expert_5.

:Schubert_11 cv:Has_position :IT_Department_12.

:IT_Department_12 rdf:type cv:Instance_class.

:IT_Department_12 rdf:type cv:Organizational_unit.

}

Code 1 Exemplary models from Figure 39 exposed as Linked Data

Exposure of model structures in such a format allows for their querying outside the tool, in a Linked Data cloud such as the one envisioned by ComVantage, together with unlimited linking possibilities between the model elements and other resources captured in the cloud. For this example, additional fictive data from an ERP system is used. It is assumed that the ERP system has exposed two (relational) tables via its Linked Data adapters, one containing human resource information and the other execution data about processes. An example of how this Linked Data could look can be found in Code 2.

@prefix : <http://www.erp.org/#>.

@prefix ex: <http://www.dke.univie.ac.at/MaxSample#>.

:HumanResources

{

ex:Schubert_11 :hasSSN "1235200480";

:Has_position ex:IT_Department_12;

:hasFullName "Schubert";

:hasPhoneNr "004301100400";

:Wage "30" .

}

:Logfile

{

:Entry1 :hasActivity ex:Analyse_4;

:hasCost 100;

:Execution "1" .

:Entry2 :hasActivity ex:Repair_2;

:hasCost 30;

:Execution "1" .


:hasCost 105;

:Execution "2" .





:hasCost 34;

:Execution "2" .


:hasCost 101;

:Execution "3" .


:hasCost 36;

:Execution "3" .


:hasCost 96;

:Execution "4" .

}

Code 2 Exemplary Linked Data that could be exposed from an ERP system

Exemplary SPARQL15 queries and their results are shown in Code 3. The queries operate in several directions – from the human resources table to the log file via the models, vice versa or extracting execution data based on the relations expressed in the models (see Figure 40).

1. What is the average cost of activities performed by the person with Social Security Number 1235200480?

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-

syntax-ns#>

PREFIX cv: <http://www.comvantage.eu/mm#>

PREFIX ex: <http://www.dke.univie.ac.at/MaxSample#>

PREFIX erp: <http://www.erp.org/#>

SELECT (AVG(?x)) AS ?Average

WHERE {

GRAPH erp:HumanResources {

?perf erp:hasSSN "1235200480".

}

GRAPH ex:OrgStrModel_10 {

?perf cv:Acts_in_role ?role.

}

GRAPH ex:MaintenanceModel_1 {

?actv cv:Assigned_units ?role.

?actv rdf:type cv:Activity.

}

GRAPH erp:Logfile {

?entry erp:hasActivity ?actv.

?entry erp:hasCost ?x.

}

}

Result:

2. Who can I call to ask about Activities with a cost above 100?


syntax-ns#> Result:

15

http://www.w3.org/TR/rdf-sparql-query/, last accessed on 26.06.2012







SELECT DISTINCT ?actv ?fullname ?phone

WHERE {

GRAPH erp:Logfile {

?entry erp:hasActivity ?actv.

?entry erp:hasCost ?cost.

FILTER (?cost > 100)

}


?actv rdf:type cv:Activity.

?actv cv:Assigned_units ?role.

}

GRAPH ex:OrgStrModel_10 {

?perf cv:Acts_in_role ?role

}

GRAPH erp:HumanResources {

?perf erp:hasFullName ?fullname.

?perf erp:hasPhoneNr ?phone.

}

}

3. How many times has the process been executed on a broken component?


syntax-ns#>




SELECT COUNT(?x) AS ?Count

WHERE {


?dec cv:Question "Broken?".

?subseq cv:from_instance ?dec.

?subseq rdf:type cv:Sequence_relation.

?subseq cv:Transition_condition 'Broken = Yes'.

?subseq cv:to_instance ?firstactv.

?firstactv rdf:type cv:Activity.

}

GRAPH erp:Logfile {

?x erp:hasActivity ?firstactv.

}

}

Result:

Code 3 Possible queries on example Linked Data and results




Figure 40: Querying directions for the exemplary SPARQL queries

4.5.4 Six Sigma Functionality Requirements The modeller should be able to load the attributes of a process model with execution data sets from external sources (at least CSV). The aim is to have the same process model reflect multiple executions. The functionality should provide:

Regarding input: o A means of selecting the attribute(s) to be filled, from the ones available in the model; o A means of building the ordered list of objects for which the attributes should be filled (this

should reflect the order of columns from the data source).

Regarding output: o Ability to create an expression that represents a key process indicator (for example, total

cost, total time, total waste of a certain category) and to state its minimum and maximum acceptance limits; in the current version this would be an Excel formula using references of the original data source table;

o Ability to pass the formula and data source to a computation service (e.g. Mathematica, Excel) and bring back a chart to be assigned to the model:

As a timeline chart (Line), showing each execution output; As a frequency chart (Columns or Scatter), showing how many executions had a

certain output range; o Ability to diagnose the process by computing the average, standard deviation and the

number of standard deviations between average and acceptance limits. While this mechanism of passing execution data through the modelling tool in order to compute formulas outside the tool might look forced, it sets the terrain for what is currently an open issue (see section 5.2) – the design of a model type that allows visual design and semantic annotations for key performance indicators.




Figure 41: Functionality for loading and visualizing data from the process execution time




5 CONCLUSIONS AND OUTLOOK

5.1 Conclusions

The document describes version 1.0 of the ComVantage modelling method specification, together with its development methodology relying on the DKE metamodelling framework. It approaches ComVantage through the generic domain of supply chain management and incorporates specificities of the project, namely mobile support and Linked Data interaction. Further adaptations need to be done in tasks 6.2, 7.2, 8.2 to optimize the method for the three application areas and specific problems of the application partners. The document describes the modelling requirements definition strategy and the envisioned modelling steps that determined the selection and definition of the modelling stack. This stack consists currently in the following inter-related model types:

The product structure model type;

The voice of the customer model type;

The e3 business model type;

The scope model type;

The thread model type;

The process model type;

The mobile mockup model type;

The mobile orchestration model type;

The organizational structure model type;

The causality model type. Interaction with the ComVantage Linked Data cloud is specified by generating RDF-formatted descriptions of the model structures. Thus, the ComVantage modelling method mixes requirements from supply chain management, business process management, mobile interaction design, access control and Linked Data exposure in order to provide a tool set aimed at supporting the goals of business models aligned to the ComVantage architecture.

5.2 Outlook and Open Issues The next iteration of the deliverable (D3.1.2) will have to consider the following open issues:

Impact of recent SCOR extensions such as DCOR, CCOR and MCOR, thus bringing the SCOR and VRM approaches closer in scope;

Coupling of the proposed RDF model structures with the concrete architecture design produced by WP2. Assumptions made regarding the integration of RDF model structure with data lifted from the legacy systems of the application partner will be better grounded in the actual progress of the technical work packages;

Adding new model types and corresponding algorithms to support domain-specific simulations; of particular importance are:

o a model type for designing key performance indicators in a flexible way, to support definition of SCOR and VRM metrics, but also definition of Six Sigma and Lean indicators or simulation formulas;

o a model type with animation support for simulations, for example in the manner used in system dynamics simulation (Forrester, 1961);

o a model type for access control policy design aimed to replace the current approach of assigning permission tables to resources from the process model type.




6 REFERENCES Bicheno, J. and Holweg, M. (2009) The Lean Toolbox, PICSIE Books.

Bolstorff, P. and Rosenbaum, R. (2007) Supply Chain Excellence, AMACOM.

ComVantage Description of Work (2011)

Forrester, J. W. (1961) Industrial Dynamics. Pegasus Communications.

Gordijn, J. and Akkermans H. (2001) E3-value: Design and Evaluation of e-Business Models. IEEE Intelligent Systems, Vol. 16(4): 11-17

Ishikawa, K. (1982), Guide to Quality Control, Asian Productivity Organization.

Kano, N., Nobuhiku S., Fumio T., Shinichi Ts. (1984) 'Attractive quality and must-be quality', Journal of the Japanese Society for Quality Control, 14 (2), pp. 39–48.

Karagiannis, D. and Kühn, H. (2002) 'Metamodelling Platforms', in Bauknecht, K., Min Tjoa, A., Quirchmayer, G. (Eds.): Proceedings of the Third International Conference EC-Web 2002 – Dexa 2002, LNCS 2455, Springer, Berlin/Heidelberg, pp.451-464

Pruitt and Adlin, T. (2006) The Persona Lifecycle, Morgan Kaufmann.

Rother, M. and Shook, J. (1999) Learning to See: value-stream mapping to create value and eliminate MUDA, Lean Enterprise Institute.

Tennant, G. (2001) SIX SIGMA: SPC and TQM in Manufacturing and Services, Gower Publishing, Ltd.

Womack, J.P., Jones, D.T. and Roos, D. (2007) The Machine that Changed the World, Free Press.

http://books.google.com/?id=O6276jidG3IC&printsec=frontcover#PPA25,M1




7 APPENDIX – PROCESS TO MOBILE ORCHESTRATION TRANSFORMATION RULES

Based on the here provided transformations using the bellow described graph rewriting rules a Process model with Mobile support features can be automatically transformed into a Mobile orchestration model. All together five transformations are required:

1. The first one connects the predecessors or successors of elements with an attached Mobile support feature to the Feature using a followed by relation and removes the other relation.

2. The second one reconnects parts where a process element has multiple successors/predecessors correctly to the next Mobile support feature.

3. The third one removes all process elements with both a predecessor and successor and reconnects their predecessor/successors using a followed by relation, resulting in directly connecting all the Features.

4. The fourth one removes all process elements with a predecessor or successor and removes the relation as well. More specifically this is performed to remove Process start and Process end elements. This transformation can be omitted if the implementation ensures that no loose relations are present (i.e. removing them as well if one of its endpoints is no longer valid), because in this case the fifth transformation takes care of the elements and relations.

5. The fifth one removes all remaining process elements. Basically, the semantics of the transformation steps are:

Transformation set 1 exchanges process elements for the appropriate Mobile support feature elements.

Transformation sets 2 and 3 “short circuit” process elements, connecting the Mobile support feature elements directly.

Transformations 4 and 5 clean up by removing all process elements. Throughout the transformation the constraints imposed on the model types must not apply, only before (on the input) and after (on the output) the entire transformation.




First (chronologically) set of transformation rules (every occurrence of the left-side pattern should generate the right-side pattern):

Second set of transformation rules

Third set of transformation rules

Fourth set of transformation rules

Last transformation rule

Figure 42: Transformation rules for deriving mobile orchestration models




Following is an example showing the transformation of a simple Process model using the above described transformation rules.

Original model

This shows a starting model for the transformation rules.

After first transformation

The first transformation connects the mobile support features to the preceding and

following elements of their corresponding activities.

It also removes the relations from the activities to prevent the rules from firing again for

the same element. This applies for all

transformations.

After second transformation

The second transformation takes care of splits in the path (through decisions or hubs).

For splitting paths it connects the mobile support features

on all paths directly except for one path.

Relation which has been created during the transformation and then removed




After third transformation

The third transformation connects all mobile support

features directly to one another.

After fourth transformation

The fourth transformation removes the process start and

process end elements connected to the mobile

support features as well as any remaining sequence

relations.

After fifth transformation

The last transformation removes all the remaining process elements, leaving

behind only the mobile elements.

Figure 43: Process model-to-mobile orchestration model transformation steps




DISCLAIMER

The information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law.

Copyright 2012 by SAP AG, Asociación de Empresas Tecnológicas Innovalia, Ben-Gurion University of the Negev, BOC Business Objectives Consulting S.L.U, Comau S.p.A., Dresden University of Technology, Dresscode 21 GmbH, Evidian S.A., ISN Innovation Service Network d.o.o., Kölsch & Altmann GmbH, Nextel S.A., RST Industrie Automation GmbH, University of Vienna.

Collaborative Manufacturing Network for Competitive Advantage · 2017-04-21 · Project title...

Documents

Transcript of Collaborative Manufacturing Network for Competitive Advantage · 2017-04-21 · Project title...