CEN/TR 17859:2022

SLOVENSKI STANDARD
01-september-2022
Jezik za storitve modeliranja
Service Modelling Language
Sprache zur Modellierung von Dienstleistungen
Langage de Modélisation de Service
Ta slovenski standard je istoveten z: CEN/TR 17859:2022
ICS:
35.060 Jeziki, ki se uporabljajo v Languages used in
informacijski tehniki in information technology
tehnologiji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 17859
TECHNICAL REPORT
RAPPORT TECHNIQUE
July 2022
TECHNISCHER REPORT
ICS 35.240.50
English Version
Service Modelling Language
Langage de Modélisation de Service Sprache zur Modellierung von Dienstleistungen

This Technical Report was approved by CEN on 10 July 2022. It has been drawn up by the Technical Committee CEN/TC 310.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 17859:2022 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms, definitions, abbreviated terms and construct labels . 6
3.1 Terms and definitions . 6
3.2 Abbreviated terms . 7
3.3 Construct labels . 7
4 Service Modelling Architecture and Language . 8
4.1 Overview . 8
4.2 Model Driven Service Engineering Architecture (MDSEA) . 8
4.3 Service modelling language (SML). 10
4.4 Actor construct representing an Organization’s or a Person’s role . 10
4.5 SML Use Case Example . 11
4.6 Service modelling templates. 15
4.6.1 Overview of constructs . 15
4.6.2 Templates and their usages . 16
4.6.3 Ordering of Templates . 17
4.6.4 Modalities of template attributes and class relationships. 17
5 SML Constructs. 17
5.1 Service . 17
5.2 Decision . 19
5.3 Functionality . 19
5.4 Value . 20
5.5 Performance Indicator . 21
5.6 Product . 21
5.7 Process . 22
5.8 Resource . 23
5.9 Service Level Agreement (SLA) . 24
5.10 Organization . 25
5.11 Person . 26
5.12 Service Vendor . 27
5.13 Customer . 27
5.14 User . 28
5.15 Service Provider . 29
5.16 Stakeholder . 30
Annex A (informative) Basic concepts of service modelling at BSM level . 31
Annex B (informative) Service modelling languages, tools and MDSEA . 34
Annex C (informative) Example of a service modelling at BSM level . 37
Annex D (informative) Industry Pilots to in the MSEE and PSYMBIOSYS Project . 41
Annex E (informative) From BSM to TIM and to TSM levels . 43
Bibliography . 45
European foreword
This document (CEN/TR 17859:2022) has been prepared by Technical Committee CEN/TC 310
“Advanced automation technologies and their applications”, the secretariat of which is held by BSI.
During its preparation, contributions have been received from the European FP7 Integrated Project
Manufacturing Service Ecosystem (MSEE) and from the H2020 project PYMBIOSYS.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
Introduction
It is generally considered that Manufacturing Enterprises will progressively migrate from traditional
product-centric business to product-based, service-oriented virtual enterprises and ecosystems. This is
a long and complex process that needs to be carefully assessed, prepared and planned. In particular, it
would be necessary for a company that decides to pursue a manufacturing servitization project, to know
clearly where it is (the current position) and where to go (the target position) so that strengths,
weaknesses and needed investments can be identified. Enterprise Modelling offers the basic concepts for
models, methods and tools to support this servitization process.
Benefits for the user result from a coordinated use of a common modelling language in the design and
operation of service system. This leads to considerable quality improvement in the design process and
cost reduction in the system operation.
A standardized Service Modelling Language (SML) is expected to foster the development of more
compatible products in enterprise service modelling and hence reduce problems in the interoperation of
such ICT products. SML will facilitate not only the modelling of services and service systems but will also
support the development of interoperable software among co-operating organizations.
In addition, the SML will have a positive impact on improving interoperability of model based, service-
oriented products, enabling European virtual factories and enterprises to adapt to the future internet
infrastructure.
The SML with its associated meta-model reduces costly and fragmented development in this domain. SML
focuses on modelling of manufacturing services that a company can develop to support its products.
The main added value of the proposed SML will be threefold:
i. Identification of the language constructs needed to define services needed by the business user.
ii. Integration of existing modelling languages constructs into one coherent meta-model.
iii. Definition of an MDSEA framework based on MDI/MDA to host the language and offer methods of
model transformation between the modelling levels.
Three categories of enterprises are considered for this SML Technical report:
a) SMEs or large companies active in model based servitization or in the process of designing business
models that include servitization aspects. The benefits of an SML standard are seen in a contribution
to ease enterprise interoperability between organisations without the need of strong
(re)engineering.
b) National/Regional projects or IT consultancies willing to integrate an SML standard in their
project/domain. This business model together with the MSEE Toolbox (as described in Annex D) will
enable the transfer of MSEE technology to other projects beyond those already existing. Four use
cases deploying the MSEE technology in SMEs of the industry sectors Machine Tools, Observation,
Furniture and Textile elaborated in the European PSYMBIOSYS project are presented in Annex D. The
use cases demonstrate the applicability and the benefits of (SML) standard-based solutions
c) Large industrial enterprises, who need business models aimed at offering IT assets to other large
industrial partners who are looking for standards-based solutions. A standard for language
modelling will ease enterprise interoperability between the partners of such enterprise network and
create measurable value.
This specification applies to manufacturing enterprises but can also apply to other classes of enterprises.
It is intended for use by system engineers, IT and research specialists who are concerned with developing
and deploying product related services in VMEs and Ecosystems. The constructs specified in this
document are also intended to be used by those business users who are making decisions based on
business rather than technical concerns. For this reason, many of the details are simplified or omitted
compared to their equivalents (where they exist) in ISO 19440:2020.
Compared to ISO 19440:2020, SML employs fewer constructs and has a simpler structure. The SML can
be considered as a derivation (but not a formal specialization) of the more general modelling language
proposed in ISO 19440:2020. The modelling constructs of this proposed Technical Report are
complementary to those constructs and support the design and implementation of future enterprise
systems providing extended products (products + services) to the market.
NOTE Where SML constructs have the same name as those in IS19440, their meaning is the same, but their
attributes are simplified (and sometimes rephrased) to include only those relevant to service modelling.
This document specifies a Service Modelling Language defined according to a Model Driven Service
Engineering Architecture (MDSEA), to support the design and implementation of the service system in a
virtual manufacturing enterprise environment. It also specifies a set of constructs for a Service Modelling
Language.
Five annexes are provided addressing the basics concepts of service modelling, service modelling
languages, tools and MDSEA, an example of service modelling at BSM level, industrial pilots to validate
the SML and the progression between MDSEA levels.
The MDSEA is derived from [1] with necessary adaptation and extension to cover the modelling of service
(and its system) in its most general forms. The modelling language addressed in this document is
specified only at the Business Service Modelling (BSM) level of MDSEA.
1 Scope
This document specifies constructs for modelling and specifying product-related service systems in
general business terms, recognising the service environment and the product lifecycle. The constructs
and their meta-model are consistent with the Model Driven Service Engineering Architecture (MDSEA).
They are intended for use by business users to address their business concerns and decision-making, and
by systems engineers and IT/researchers using a model-driven engineering approach in the design,
development and deployment of service systems in Virtual Manufacturing Enterprises (VMEs), business
ecosystems and other application areas.
2 Normative references
There are no normative references in this document.
3 Terms, definitions, abbreviated terms and construct labels
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1 Terms and definitions
3.1.1
construct-based modelling language
set of constructs and rules for valid groupings, which define the syntax of the modelling language
3.1.2
construct template
common structure that allows the identification and description of distinct modelling language
constructs and the assignment of their properties
3.1.3
extended product
product enriched with associated product related services
3.1.4
manufacturing service ecosystem
manufacturing system of products bundled with associated services
3.1.5
service modelling language
set of constructs and rules for valid groupings of enterprise services, which define the syntax of the
modelling language
3.1.6
servitization
process in a manufacturing enterprise to augment the value of products with services to better satisfy
customer needs and sustainability
[SOURCE: ISO 19440:2020, modified]
3.2 Abbreviated terms
BSM Business System Modelling
GRAI Graphs with Results and Actions
ICT Information and Communication Technology
IT Information Technology
MDA Model Driven Architecture
MDI Model Driven Interoperability
MDSEA Model Driven Service Engineering Architecture
MSEE Manufacturing Service Ecosystem
SME Small- and/or Medium-size Enterprise
SML Service Modelling Language
TIM Technology Independent Modelling
TSM Technology Specific Modelling
UML Unified Modelling Language
VMA Virtual Manufacturing Enterprise
3.3 Construct labels
CUST Customer
DECN Decision
FUNC Functionality
ORG Organization
PERS Person
PI Performance Indicator
PR Product
PROC Process
RE Resource
SLA Service Level Agreement
SRV Service
STK Stakeholder
SVPR Service Provider
SVVN Service Vendor
USER User
VAL Value
4 Service Modelling Architecture and Language
4.1 Overview
A modelling language is defined by a set of modelling constructs. Construct(s) are represented, as
illustrated in Figure 1, by a graphical representation, a template description and text. A template contains
a header part to identify a construct instance, and a body part to describe the particular instance with
descriptive and relationship properties. The proposed service modelling language is consistent with the
enterprise modelling language representation concepts defined in ISO 19440:2020 [3].

Figure 1 — Modelling language constituents (from ISO 19440:2020)
Using this template, this document specifies in Clause 5 a set of core Business Service Modelling
constructs to model Service System at BSM level (which is the first level of the MDSEA).
4.2 Model Driven Service Engineering Architecture (MDSEA)
A Model Driven Service Engineering Architecture (MDSEA) is elaborated on the basis of [1] and [2] to
support modelling of the three types of service system components (IT, human and physical means). This
MDSEA is considered as an adaptation and extension of MDA and MDI to the engineering of product
related services in virtual manufacturing enterprise environment.
As in MDA and MDI, the proposed MDSEA defines three abstraction levels as illustrated in Figure 2.
a) Business System Modelling (BSM), which specifies the models, at the global level, describing the
running of the enterprise or set of enterprises as well as the links between these enterprises.
b) Technology Independent Modelling (TIM), which are the models at a more detailed level of
abstraction, identifying needed resources and the capability independent from the technology used
to implement the system.
c) Technology Specific Modelling (TSM) that combines the specification in the TIM model with details
that specify how the system uses a particular type of technology (such as for example IT platform,
physical means or organization with particular human profiles).

Figure 2 — MDSEA architecture
One result of Technology Specific Modelling is technical specifications of the three types of components
(resources) to use to build the required service system: IT type for information handling, Machine type
for material handling, and Human type for both information and material handling as well as the
organisation. One example is the servitization project carried out in 2018 by the Renault car
manufacturer in Paris Ville called Renault Mobility car service. In collaboration with Paris Municipality
and other service providers in a framework of a virtual enterprise, a network of automated Renault car
renting stations has been implemented in Paris. This service system is built with the three types of
components:
— car information management system implemented by IT type components (computers, software
applications and sensors, etc.);
— parking/Recharging stations implemented with Machine type components (robots, recharging
facilities, etc.); and
— car maintenance system (repairing, cleaning, etc.) implemented with Human type components
(cleaning workers, technicians, etc.).
The relationship between the MDSEA modelling levels (BSM, TIM, TSM) and the Service System lifecycle
phases (user-requirements, design and implementation) have been established. One of the important
innovations in MDSEA is to define the integration between domain components at the BSM level in order
to ensure that these integration aspects will be addressed at the other levels.
4.3 Service modelling language (SML)
The concepts identified in 4.2 are adopted as modelling constructs to represent a Service System at BSM
level. Figure 3 is an overview illustrating the Service concept and relationships with other concepts. This
figure is elaborated to show all SML constructs in Figure 5. In Clause 5, each construct is further described
by a template, and text to explain specific concerns and details.

Figure 3 — Modelling constructs and relationships at BSM level
The kind of service considered in this document is that relating to a manufactured product. To develop
such a service, it is necessary to build a Service System. Various entities are involved in such a
development, ranging from the intended Customer who will consume the service to the Service Vendors
and the Service Providers. Other entities such as technical centres, research centres and banks could be
involved. All these other entities are called Stakeholders and all of them may express their specific
concerns. A Service is used by Customers. A Service System provides functions that are utilities to fulfil
customer’s needs. The provided Service can be evaluated by a set of Performance Indicators, which are
related to a set of decisions that control the Service System, i.e., are related to a set of objectives and
decision variables.
4.4 Actor construct representing an Organization’s or a Person’s role
Persons and Organizations can have several roles and a role can generally be undertaken by either an
Organization or a Person. Construct relationships (and their underlying class diagrams) need to cover
this requirement without proliferating relationship links between Person/Organization and each role
that they can possibly assume. This is achieved by using an abstract ‘Actor’ class model as illustrated in
Figure 4.
Figure 4 — Organization, Person and Actor roles
NOTE 1 Attributes which concern a particular role of an Organization or Person, e.g., usage of a service, have now
migrated to attributes of the Actor specialization, e.g., to the User construct. All Actor role specializations then have
the associated attributes and . Whether a role is undertaken by an Organization or Person
is determined by the Identifier and Name of the Actor specialization.
NOTE 2 Figure 4 is a view on a UML model and since the and attributes are inherited
from Actor they do not need to be shown explicitly as attributes for the Actor specializations. They are shown here
(and in Figures 7 and 8) for consistency with the templates and completeness (since Actor is abstract and so not
included in Clause 5).
4.5 SML Use Case Example
NOTE This clause is an extract adapted with permission from [9].
In today’s service development, it is usual to have combination of services provided by different provides
working together. The use case considered covers different kinds of services, approaches and solutions
in the context of Industry 4.0, Internet of Things, Cyber Physical Systems, Cloud Computing and
integration/federation of services of enterprise applications such as SCM, ERP, MES.
A central component of this use case is a matching service, which provides opportunities to create
partnerships like value or supply chains but also purchasing pools and other networks within the hyper-
connected ecosystem. A matching service running in a cloud infrastructure and using other services has
been selected as one focus for the use case. The complete use case scenario considers cloud
infrastructures, a matching service, a service to provide partner information to different service
providers, a pump producer and a product service provider for water supply as well as a list of part
suppliers (as illustrated in Figure 5).
Figure 5 — Use case scenario for service modelling
The pump producer produces a pump and offers this pump to the customer as part of a water supply
service. An example of a possible customer could be a state water supply authority. This implies several
services to produce the pump and to deliver the service with several contracts with suppliers of parts
and services.
A matching service helps to find the suppliers but also customer networks. The matching service uses a
profile service that provides information about potential business partners. However, these two services
run on cloud service infrastructures. The cloud service provides also the infrastructure to deliver the IT
components of the water supply service such as monitoring the amount of water, potential maintenance,
breakdowns, replacements as well as payment. Maintenance also invokes the matching service
concerning potential material and local maintenance service providers. This creates a far-reaching
network of services and dependencies on a legal, business and technical level.
This use case illustrates the challenges and dynamic arising in the design of a service infrastructure. The
current model is in development and includes the following main elements in terms of instantiated SML
constructs.
This TR defines “Actor” as an abstract class related to persons or organisation and incorporates service
providers, vendors, stakeholders and other roles, for example:
— Pump producer and water supply provider;
— Matching service provider;
— Cloud infrastructure provider;
— Provider of partner profile services;
— Suppliers (parts and maintenance services).
The service construct covers all kinds of services in the use case such as IT services and product as a
service and services around a product:
— Services;
— Water supply service;
— Cloud infrastructure service;
— Matching service;
— Portfolio service;
— Maintenance service.
In the current work, UML is used to express the elements of the use case via instances of SML constructs.
Each SML construct has a related template. Table 1 illustrates an example of such template for the
matching service construct.
Figure 6 shows the part of the use case concerned with the cloud service and the matching service as a
UML model. Each class corresponds to an SML template instance, The example provides an indication of
how to interrelate the service level agreements like the information technology infrastructure library
(ITIL) between providers, sellers, users, services and products in the context of cloud infrastructures.

NOTE Figure 6 is adapted from Figure 2 in [9].
Figure 6 — Use case partial model
The matching service requires the cloud service to provide its functionality. Therefore, the matching
service provider is at the same time a customer of the agreement (SLA) between the cloud service
provider and the matching service provider. The model also shows a further SLA between the matching
service provider and the pump producer using the matching service. Both SLAs are decoupled in terms
of contracting but the integrated view illustrates that they related because if the cloud service disappears
also the SLA of the matching service is affected. The construct of SLAs in the SML is a placeholder for
various regulations such as data ownership, data security and data privacy.
In terms of modelling, the matching services and the cloud service are modelled separately and then
orchestrated in one model thanks to common SML modelling. The example related to the SLAs is just one
usage for the model. SML provides a structured method for modelling a service that provides a better
understanding of the service components. It also helps to include the required elements into the service
blueprint.
Table 1 provides a template example for the matching service and each of its properties.
Table 1 — Example of Service construct template
Header
Construct label SRV
Identifier SRV_0001
Name Matching service
Body
Attributes
Domain Pump provision
Description The service provides a search of potential matches between
potential suppliers and demands.
Objective The service supports the tendering between customers and
suppliers to create a partner network or supply chain.
Constraint A profile service provides partner information in a formal way.
The same for the product description of the supply parts.
Nature Information
Relationships to other model elements
Product Water pump
Functionality Partner search and matching
Resource Cloud infrastructure
Process identify supplier / matching
Customer Pump producer
Decision Not applicable
Performance Indicator PI_001
(containing attributes such as number of alternative providers,
correspondence between demand and identified providers –
correct match)
Value VAL_001
(containing attributes such as fast correlation between demand
and supplier, evolution support by information of the suppliers
about additional demands of potential customers)
Stakeholder Pump producer
Decomposition Containing references to other services such as:
— SRV_002 a set of parameter related correlation services
— SRV_003 a service for logical connecting of the single results
of parameter matching
— SRV_004 a priority service for managing the resulting sets of
suppliers, etc.
4.6 Service modelling templates
4.6.1 Overview of constructs
Figure 7 is a refinement of Figure 3 which shows all SML constructs and their relationships as UML
classes.
Figure 7 — SML constructs and their relationships
For ease of reference, each construct is shown with its attributes in Figure 8 in alphabetical order.
NOTE The Identifier and Name attributes are common to all templates and are not shown in these class
diagrams.
Figure 8 — SML constructs and their attributes
4.6.2 Templates and their usages
Clause 5 describes each modelling construct defined in Figures 5 and 8 in terms of a textual description
and a template to detail its properties (attributes and relationships). The use of the whole or part of
attributes is determined by each specific use case and the objectives of the modelling.
NOTE In addition to relationships with other model elements, each template is related to the BSM model level,
and to the requirement phase of modelling. These other relationships are the same for all templates and are
therefore omitted.
4.6.3 Ordering of Templates
Since there are many interrelationships between the constructs, it is not always possible to list them
without forward references, that is without referring in a construct template to another construct that
has not yet been defined. The ordering chosen is:
a) Service and other constructs which detail Service properties (Decision, Functionality, Value,
Performance Indicator);
b) Product, Process and Resource;
c) Service Level Agreement, Organization and Person;
d) Actor roles (Service Vendor, Customer, User, Service Provider, Stakeholder).
4.6.4 Modalities of template attributes and class relationships
Some attributes [enclosed in square brackets like this] and relationships in the illustrative class models
have a modality notation where they are considered significant. The notation used is as follows.
1 corresponding to a mandatory single value
0.1 corresponding to an optional single value
0.* corresponding to zero, one or many values
1.* corresponding to one or many values
Within square brackets a ‘|’ symbol is used to indicate alternatives, e.g. [Person | Organization].
In the descriptions of template properties, a singular noun or noun phrase implies modality 1, while
mention of a list implies modality 0.* unless explicitly marked as 1.*.
5 SML Constructs
5.1 Service
As illustrated in Figure 5, Service is the core construct of SML with relationships to nearly all other
constructs. A Service is implemented by a Process and may use other Service instances during its
execution.
The service template aims at describing service information and requirements collected from
stakeholders and end-users. It contains attributes summarizing its purpose and capability, and also
references to related constructs which will themselves contain more detailed and specific information.
The service template is shown in Table 2.
Table 2 — Service template at BSM level
Header
Construct label SRV
Identifier Identifier of the service instance
Name Name of the service instance
Body
Attributes
Domain Domain of the service
Description Short textual description of this service instance
Objective Short textual description
Constraint Short textual description
Nature 'Physical' or 'Information' or 'Human'
Relationships to other model elements
Product Identifier/name of Product concerned by the service: described
by Product template
Functionality Identifier/name of functionality of the service: described by
Functionality template
Interface Short textual description or specification
Resource [Identifier/name of Resource](1.*) resources providing the
service: described by Resource template
Process [Identifier/name of Process](1.*) processes providing the service:
described by Process template
Customer [Identifier/name of Customer](0.*) customers consuming the
service: described by Customer template
Decision [Identifier/name of the decision](0.*) decisions controlling the
service: described by Decision template
Performance Indicator Identifier/name of the performance of the service: described by
Performance template
Value Identifier/name of the Value of the service: detail will be
described by Value template
Stakeholder [Identifier/name of the Stakeholder](0.*) stakeholders having a
concern about the service: detail will be described by Stakeholder
template
Decomposition [Identifier/name of Service](1.*) services that are used by this
Service: detail will be described by Service template
5.2 Decision
A decision is the result of a choice between several alternatives to reach a certain objective under a set of
constraints. It also means the activity of making a choice. In a Service System, the decisions are taken
periodically or triggered by events. Those decisions control the way in which the service is provided and
operates.
A decision belongs to a decision function where decision activities are carried out. Decision level is
defined by the pair of horizon and period, specified in terms of days, weeks or years. Decisions are linked
together to form a decision structure. Using a set of defined GRAI rules, it is possible to analyse the
consistency of a decision structure and improve decision making.
Table 3 — Decision template at BSM level
Header
Construct label DECN
Identifier Identifier of the decision instance
Name Name of the decision instance
Body
Attributes
Kind Textual description
Decision Function Decision function, for example (one of) Planning, Managing
resource, Managing product, Managing quality, Managing
maintenance, Managing customers, Managing delivery.
Horizon Time interval for which a decision taken is valid
Period Time interval at the end of which a decision is revised
Constraint Constraint of decision
Objective Objective of decision
Variable Variable of decision
Event Event that triggers a decision making: only for event-based
decision making
Representation Link to possible graphical representations, for example, GRAI grid
graphical representation
Relationships to other model elements
Service Service](0.*) List of identifier/name of services whose delivery is
controlled by this decision
NOTE The decisions, the decision-making activities and relationships between decision activities can be
further modelled and represented using GRAI grid and GRAI net formalisms.
5.3 Functionality
A Functionality refers to any aspect of what a product or service can or cannot do for a user or customer.
These aspects are the reasons why a customer is interested in a product or service, as might be expressed
by the customer. They might include technical capabilities, but not technical functionalities, i.e., the
technical way a functionality is performed, that are described at the lower levels (TIM and TSM). In the
service domain, a functionality is a utility satisfying customer’s need(s). The functionality template aims
at describing the customer-facing functions provided by a service but not their technical characteristics.
A functionality may be decomposed into more detailed functionalities.
Table 4 — Functionality template at BSM level
Header
Construct label FUNC
Identifier Identifier of the functionality instance
Name Name of the functionality instance
Body
Attributes
Kind Information processing, material handling, transportation, etc.
Capability short textual description of capabilities
Constraint short textual description of limitations
Decomposition List of sub-functions
Link to possible graphical representations, for example IDEF0
function modelling
Relationships to other model elements
Service [Service](1.*) List of identifier/name of services providing the
functionality
NOTE The service functionality defines the behaviour of a service in terms of the functions it is expected to
perform. A service functionality (function) can be further detailed (decomposed in sub-functions) using for example
an actigram modelling language.
5.4 Value
Value is a measure of the benefit that may be gained from goods or service. In a manufacturing
servitization project, value(s) is (are) concerned with the benefits of providing a service that is related to
a tangible product in order to increase the competitiveness of this product (and the company) in the
market.
Table 5 — Value template at BSM level
Header
Construct label VAL
Identifier Identifier of the value instance
Name name of the value instance
Body
Attributes
Description Short textual description of this value instance
Relationships to other model elements
Service Identifier/name of Service to which this value instance applies
5.5 Performance Indicator
A Performance Indicator can assess a Service and provide information for Decisions related to that
Service. A performance indicator is quantified data that measures the degree of achievement of a service
in conformance with the objective and strategy of the company. To be efficient, a performance indicator
must be related to a decision variable that is itself related to an objective. The performance indicator
template is defined as below.
Table 6 — Performance Indicator at BSM level
Header
Construct label PI
Identifier Identifier of the performance indicator instance
Name Name of the performance indicator instance
Body
Attributes
Kind e.g. customer oriented, provider oriented
Objective Targeted objective(s) of this performance indicator
Description Short textual description of this performance indicator instance
Information required to build Short textual description
the indicator
Processing required to Short textual description
calculate the indicator
Relationships to other model elements
Service [Service](0.*) List of identifier/name of services concerned with
this instance
Decision [Decision](0.*) List of identifier/name of decisions concerned by
this instance
NOTE The ECOGRAI method can be used to help in identifying and defining a set of performance indicators to
evaluate service and/or service system performance. Other performance indicators might also be identified at the
other stages of the service lifecycle.
5.6 Product
A Product can be covered by an SLA for a product-related Service. A Service Provider can be activated to
execute that Service by an authorized User of the Product or possibly by the Product itself if equipped
with self-monitoring capability. A Product is sold to a customer and is generally considered as a tangible
physical entity. A Product is related to one or a set of services in a virtual enterprise and ecosystem.
Table 7 — Product template at BSM level
Header
Construct label PR
Identifier Identifier of the product instance
Name Name of the product instance
Body
Attributes
Kind Textual description
Function Short textual description of its utility or functionality
Component Short textual description; list of components, bill of materials
Technical characteristics Short textual description
Relationships to other model elements
Service [Service](0.*) List of identifier/name of services covering the
product
Other Relationships
NOTE A product will be modelled in detail at later stages to identify product use information that is needed to
support the service.
5.7 Process
A Service is implemented by a Process. A Process is an asset of an Organization. A Process defines a
sequence of activities and may include sub-processes. In a Service System, various types of services
processes are necessary, such as service booking process, service delivery process, service planning
process, supply process, or maintenance process.
Table 8 — Process template at BSM level
Header
Construct label PROC
Identifier Identifier of the process instance
Name Name of the process instance
Body
Attributes
Objective Short description of the process objectives
Event Condition for which this process instance is triggered
Result Output of this process instance
Constraint Constraint that may apply to this process instance
Decomposition [Process](.*) List of processes used by this process
Link to possible graphical representations. For example, BPMN,
IDEF3, MO GO …
Relationships to other model
elements
Service [Service](0.*) List of identifier/name of services used by the
process
Resource [Resource](0.*) List of identifier/name of resources used by the
process
NOTE At the BSM level, a process can be further detailed using various existing business-user oriented process
modelling languages such as IDEF3, GRAI extende
...