System Modelling and Analysis to Support Economic Assessment of Product-Service Systems †

: The evolution towards more customer-centric operations within manufacturing and service industries gave rise to novel ways of value creation and delivery such as Product–Service Systems (PSS). PSS integrate tangible and intangible elements to create new values for both customers and providers. Therefore, a close collaboration is required among various actors in a value network to co-create values towards win–win gains. For companies to keep up with this pace, new decision support tools are needed to accompany PSS engineering and to adjust business models. This need is confronted with the scarcity of PSS-oriented economic assessment models and methods. This paper presents a comprehensive framework for the economic assessment of PSS. The framework relies on a novel combination of system modelling and analysis approaches to enable cost and revenue attribution to different actors in a value network. The applicability and relevance of the framework are demonstrated through a case study in the industrial cleaning sector.


Introduction
Manufacturing and service industries are facing two-way pressures from fiercer competition and more demanding customers. On the one hand, in order to gain customer loyalty, more business model innovations are demanded to replace unsustainable price wars. On the other hand, cost remains an important factor in a customer's decision-making when it comes to comparing various offers in the market. Product-Service Systems (PSS) are one of the drivers of business innovation, which can increase values not only for customers but also for various actors within a PSS value network. In previous studies, several definitions of PSS have been proposed, providing complementary insights on PSS characteristics. According to a holistic literature review published in [1], Goedkoop's definition of PSS is one of the most widely adopted ones. This definition is consistent with the authors' understanding of PSS. In the work of [2], PSS is regarded as "a system of products, services, networks of players and supporting infrastructure that continuously strives to be competitive, satisfy customer needs and have a lower environmental impact than traditional business".

Methodology
The authors followed a DRM approach for the research design. DRM is a design research methodology that aims to support a more rigorous approach towards more effective and efficient research design [16]. It consists of four main stages namely Research Clarification, Descriptive Study I, Prescriptive Study, and Descriptive Study II (as illustrated in Figure 1). Systems 2021, 9, x FOR PEER REVIEW 3 of 17 framework, based on system modelling and system analysis, which aims at assessing different alternatives of value network from an economic point of view spanning costs and revenues. This framework is presented in Section 4. In the Descriptive Study II, the applicability and effectiveness of the proposed framework are evaluated through a case study, as detailed in Section 5. The case study shows that the proposed framework provides operational guidance during the development of PSS offers, based on estimating cost and revenue consistently with a multi-actor dimension and integrating a life cycle dimension spanning production and use phases of the PSS. Thus, the authors focused on conducting an "application evaluation" [16], in order to assess the applicability and usability of the framework. The case study serves to showcase how the artefact works as intended in this instance. As observed by [17], the evaluation of an outcome-based DRM project should focus on whether and to what extent the artefact suits a range of contexts. In this regard, the proposed framework is yet to be evaluated in other settings, which constitutes a worthwhile future work-study. It should be noted that, while different DRM stages are explained in a linear way, in practice, the process involved multiple back-and-forth iterations [16]. This paper reports a single iteration, during which the Descriptive Study II provides initial insights on the framework applicability rather than a full assessment of the usability and performance [17].

Literature Review
A holistic literature review is conducted to identify major requirements for the economic assessment of PSS, with a particular focus on cost. The review was performed based on the databases of Google Scholar and Science Direct, primarily covering journal articles  Research Clarification aims at identifying and refining "a research problem that is both academically and practically worthwhile and realistic" [16]. In this study, the research objective is to support PSS industrialization by assessing the economic values generated from a PSS delivery. As previously explained, this is an academically worthwhile problem because the cost estimation of PSS offers remains a complex and under-studied issue, especially from a multi-actor perspective. It is also a realistic problem, since moving to PSS-based business models requires companies to be aware of the subsequent benefits and risks. Descriptive Study I aims at obtaining "sufficient understanding of the current situation" [16], and relies mainly on a detailed literature review. According to a comprehensive literature review conducted by the authors, a framework for assessing the economic values generated from a PSS delivery should accommodate multiple cost elements (that are related to products, services, and activities), approach from a dynamic perspective (considering different phases of a PSS lifecycle), and spread over an entire value network (involving all relevant stakeholders who play various roles in the PSS delivery).
In the Prescriptive Study, an artefact, such as a model, a structure, or a method, is developed to achieve the desired situation based on the outcome of the Descriptive Study I. Based on the requirements identified at the previous stage, the authors built a new framework, based on system modelling and system analysis, which aims at assessing different alternatives of value network from an economic point of view spanning costs and revenues. This framework is presented in Section 4. In the Descriptive Study II, the applicability and effectiveness of the proposed framework are evaluated through a case study, as detailed in Section 5. The case study shows that the proposed framework provides operational guidance during the development of PSS offers, based on estimating cost and revenue consistently with a multi-actor dimension and integrating a life cycle dimension spanning production and use phases of the PSS. Thus, the authors focused on conducting an "application evaluation" [16], in order to assess the applicability and usability of the framework. The case study serves to showcase how the artefact works as intended in this instance. As observed by [17], the evaluation of an outcome-based DRM project should focus on whether and to what extent the artefact suits a range of contexts. In this regard, the proposed framework is yet to be evaluated in other settings, which constitutes a worthwhile future work-study.
It should be noted that, while different DRM stages are explained in a linear way, in practice, the process involved multiple back-and-forth iterations [16]. This paper reports a single iteration, during which the Descriptive Study II provides initial insights on the framework applicability rather than a full assessment of the usability and performance [17].

Literature Review
A holistic literature review is conducted to identify major requirements for the economic assessment of PSS, with a particular focus on cost. The review was performed based on the databases of Google Scholar and Science Direct, primarily covering journal articles in the domains of industrial engineering and business management. In light of a relevant literature review about PSS assessment performed by [18], the searching timeframe was determined to be 2010-2020. A total of 25 articles were identified as relevant and analyzed in detail. Two complementary literature streams were considered: PSS multi-actor and life cycle dimensions, and PSS economic assessment with a focus on cost. For the first stream, a selection of keywords was used, including "PSS" OR "productservice system" AND "multi-actor" OR "multi-stakeholder" AND "value network" AND "assessment". Then the articles were filtered after a diagonal reading, leading to a set of 13 relevant studies. For the second stream, another selection of keywords was used, including "PSS" OR "product-service system*" AND "costing" OR "economic assessment" OR "cost calculation". The searching resulted in 12 relevant articles. Finally, the two bodies of relevant literature were analyzed to make visible the research gaps that will be addressed by this study.

Multi-Actor and Life Cycle Dimensions in PSS Assessment
Developing a functional PSS often requires competencies, resources, and capabilities that may be new to the company and hence require collaboration with other partners [19]. Therefore, implementing PSS requires an orchestration of a complex network of stakeholders, both within and outside of a company [20]. The delivery of PSS thus requires manufacturers to access and coordinate a network of external suppliers and partners throughout the system's life cycle [21]. For instance, [22] underlines the importance of clarifying the roles of different actors in collaborative value co-creation, as well as in the repartition of values captured among them. Thus, in order to provide PSS, manufacturers should be prepared to accommodate changes in their activities and processes, both internally and externally with/for other actors. The changes may include adjustments concerning how activities, and their associated values, are allocated. In PSS networks, the value co-creation and capturing are expected to result in win-win outcomes where the financial benefits are fairly distributed among the contributing partners.
Although many researchers highlighted the importance of accurate costing methodologies that incorporate the multi-actor dimension, the literature suggests a clear gap in this regard. The multi-actor aspect of PSS has been addressed from either the dimension of value creation and business model innovation [21,22], or in the context of sustainable PSS [23]. In contrast, the multi-actor aspect is hardly studied from the specific viewpoint of PSS costing [10,24]. Most of the existing studies on PSS costing have been approached from the Original Equipment Manufacturer (OEM) dimension [8,25,26], while few efforts have been devoted to the customer-provider relationships [27]. Above and beyond, even though some studies underlined the need for the cross-organization or multi-actor dimension in PSS costing, practical operational methods remain scarce.
For instance, [10,28] proposed a methodology that coupled TCL and ABC costing methods, which were applied to industrial cases specific to use-oriented PSS. Along the same lines, [29] introduced a methodology for uncertainty assessment in PSS costing based on the Monte-Carlo simulation, which was complementary to the costing method reported in [28]. Moreover, [30,31] approached the problem of multi-actor integration from a PSS development angle, which however lacked detailed costing methods. Ref. [31] proposed an assessment method that considered the multi-actor dimension only during the requirement phase of PSS development, whereas the costing phase was carried out exclusively from the service provider's point of view. Ref. [30] proposed a set of four cost parameters in the context of multi-actor PSS development: (i) incentive system for stakeholder involvement in PSS development, (ii) ecosystem efficiency related to the PSS production process, (iii) ecosystem efficiency related to the PSS use phase, and (iv) ecosystem efficiency related to the PSS disposal. For the moment, however, practical applications of those parameters are not found. To support a fair economic value sharing in the PSS offer, the lifecycle costs and the financial benefits should be assessed for the network as a whole and then allocated to individual partners, which constitutes a complex research problem that calls for further investigation.

Economic Assessment and Costing Models for PSS
The cost estimation of PSS offers, especially for the use-oriented and result-oriented PSS, is by no means straightforward, considering their level of complexity compared to traditional product-oriented offers [32]. The main challenges are related to the considerations of the product and service life-cycles, the system view spanning across organization boundaries, the delimitation of assessment objects (i.e., product units, service units, activities, etc.), as well as the uncertainties of PSS performance during the use phase [8,18,25,33,34].
In spite of the scarcity of literature about the costing of use-oriented and result-oriented PSS, some researchers introduced quantitative or qualitative costing models [24,25,33,35]. Two main categories of PSS costing can be identified in the literature: (1) seeking operational methods to perform PSS cost calculation, and (2) adopting a methodological view of the PSS costing process. In the first category, works are built on existing methods such as Life Cycle Costing (LCC) [27], Through Life Costing (TCL) [25]), Stochastic Modelling [34], and Lean Accounting [26]. In the second category, efforts are devoted to extending the scope of existing approaches to overcome one or more of the PSS costing hurdles [8,25,36]. In particular, most of the existent studies in this category suggest that an operational method per se is not enough to understand the logic under PSS costing. For instance, [8] presented a process-oriented method for PSS cost calculation, which integrated three main features of PSS, synthesized from a comprehensive literature review: (i) the dynamic and non-linear behaviour of PSS operations; (ii) the interaction between interconnected cost objects; and (iii) the integration between providers and customers.
Furthermore, the literature reveals some characteristics that should be taken into consideration for performing PSS costing. Firstly, the contextualization of PSS offers (according to the industrial sector, the level of innovation, and so forth) is fundamental to build accurate cost calculation methodologies, since the inherent complexity of the topic makes it difficult, if not impossible, to propose generic solutions [8]. Secondly, cost calculation approaches are typically developed based on cost inference or retrospective models that statistically derive relationships between cost variables based on historical data, as opposed to attribution models that establish a causal link between cost variables prior to the cost estimate [18,25,37].
Based on the above analysis, the key requirements of a framework for PSS economic assessment can be summarized as follows: • Comprehensiveness: PSS costing methodologies should involve multiple cost elements from a dynamic perspective (activity-oriented).

•
Life cycle: The scope of PSS costing should be inter-temporal, considering a whole offer lifecycle. • Collaboration: PSS costing should consider the collaborative relationships taking place within the actor value network across the offer lifecycle.

Framework Design
This step is concerned with the prescriptive study aiming to develop a framework for economically assessing PSS value networks. Such an approach should be consistent with the requirements formulated in the previous section (i.e., comprehensiveness, life cycle dimension, and collaboration). Therefore, an interdisciplinary approach is needed to support the prescriptive study. PSS can be viewed as an engineered system, which is composed of different combinations of hardware, software, people, and service [38,39]. To this end, a combined system modelling and analysis is adopted as the backbone of the proposed framework. In line with [40], the modelling will support architecting efforts in terms of specification and design. System analysis will support the economic assessment of PSS as well as various drivers and impacts on the assessment.
An overview of the proposed framework is shown in Figure 2. The iterative process of system modelling includes scope definition, knowledge elicitation, and contracts specification. The process of system analysis relies on the interplay among simulation settings, cost and revenue calculation, and result interpretations. The methodological guidance of system modelling and system analysis are detailed in Sections 4.2 and 4.3, respectively. The implementation within a software platform is reported on in Section 4.4. What activities are required for PSS provision? Who is involved in the PSS (i.e., PSS actors and roles)? Contract specification is a reworked version of the functional unit inherited from TLC (Through Life Costing). In TLC, a functional unit is used to assess the overall performance of a delivery system: it is considered as a quantified index used as a reference to measure the functionality delivered by the system. Thanks to such a reference index, it is possible to evaluate the performance of a system in comparison with other alternative systems that are designed to provide comparable functionalities. The objective is to develop a generic functional unit, which can be (re)used for a variety of assessment projects. Thus, we propose the use of the "contract specification" as a functional unit. Contract attributes gather a well-defined and comprehensive specification of the functionality expected to be delivered by the PSS solution. In line with [9], we use the notion of a contract to denote an agreement among two or more partners concerning their involvements in service provision with respect to the financial, physical and information flows. Contracts can be located at different tiers within the value network (e.g., between PSS provider and customers, between PSS provider and suppliers, etc.). A contract can embed either product, service or product and service. A contract specification should fully cover the required information for defining a functional unit of an assessment project.
Knowledge elicitation consists of collecting data and iteratively modelling PSS and their related value network. A structured process of PSS definition and specification can support the information and knowledge collection. Such a process relies on: (i) a set of questionnaires used to capture key data among various actors involved in the PSS solution; (ii) a software tool to build, represent, and share domain-specific knowledge; and (iii) various workshops contributing to a collaborative design of the PSS solution. Figure  3 shows a conceptual representation of the main cost elements involved in the proposed framework. Each of the objects in Figure 3 represents a class of a given cost element. These elements include products, services (parts of the PSS), activities, and resources. The contract is a key element in the model because it defines the functional unit. Since the proposed framework incorporates a multi-actor dimension, actors are a key element in the conceptual model.
Through iterations among the above steps, a set of alternative scenarios of a PSS solution are built. A scenario specifies the role of each actor in delivering a PSS offer under the conditions defined by the contract, in particular, concerning services and products included in the offer as well as the contract duration. The roles are depicted through activities (related to product or service provision). Afterwards, data on resources and/or activities' unit costs are collected and stored in a database (structured according to the concepts of Figure 3) to prepare for the subsequent steps.

System Modelling
Scope definition aims to define the boundaries of the assessment, i.e., the actions performed and managed by people in organizations, the outcomes of the actions, and the relationships between actions and outcomes [25]. Scope definition is derived by answering the following questions: What are the PSS offers (specified in the set of PSS contracts)? What activities are required for PSS provision? Who is involved in the PSS (i.e., PSS actors and roles)?
Contract specification is a reworked version of the functional unit inherited from TLC (Through Life Costing). In TLC, a functional unit is used to assess the overall performance of a delivery system: it is considered as a quantified index used as a reference to measure the functionality delivered by the system. Thanks to such a reference index, it is possible to evaluate the performance of a system in comparison with other alternative systems that are designed to provide comparable functionalities. The objective is to develop a generic functional unit, which can be (re)used for a variety of assessment projects. Thus, we propose the use of the "contract specification" as a functional unit. Contract attributes gather a well-defined and comprehensive specification of the functionality expected to be delivered by the PSS solution. In line with [9], we use the notion of a contract to denote an agreement among two or more partners concerning their involvements in service provision with respect to the financial, physical and information flows. Contracts can be located at different tiers within the value network (e.g., between PSS provider and customers, between PSS provider and suppliers, etc.). A contract can embed either product, service or product and service. A contract specification should fully cover the required information for defining a functional unit of an assessment project.
Knowledge elicitation consists of collecting data and iteratively modelling PSS and their related value network. A structured process of PSS definition and specification can support the information and knowledge collection. Such a process relies on: (i) a set of questionnaires used to capture key data among various actors involved in the PSS solution; (ii) a software tool to build, represent, and share domain-specific knowledge; and (iii) various workshops contributing to a collaborative design of the PSS solution. Figure 3 shows a conceptual representation of the main cost elements involved in the proposed framework. Each of the objects in Figure 3 represents a class of a given cost element. These elements include products, services (parts of the PSS), activities, and resources. The contract is a key element in the model because it defines the functional unit. Since the proposed framework incorporates a multi-actor dimension, actors are a key element in the conceptual model.
Through iterations among the above steps, a set of alternative scenarios of a PSS solution are built. A scenario specifies the role of each actor in delivering a PSS offer under the conditions defined by the contract, in particular, concerning services and products included in the offer as well as the contract duration. The roles are depicted through activities (related to product or service provision). Afterwards, data on resources and/or activities' unit costs are collected and stored in a database (structured according to the concepts of Figure 3) to prepare for the subsequent steps.

System Analysis
The calculation of cost and revenue lies at the heart of system analysis, which enables the attribution of costs and revenues to the actors according to contract specification and to their roles defined in the PSS scenarios, represented by a given value network configuration. Cost calculation follows a bottom-up procedure, flowing from the identification of activity costs upwards to the assignment of costs to different actors. Firstly, the activity costs are calculated based on the unit cost and quantities of resources, if available, or using activity unit cost provided by domain experts (i.e., aggregated values considering the unit cost and quantities). The contribution of a given activity to the cost of a given actor is derived from the unit activities' costs and the required volume of product or service for the actor. The revenues are calculated based on the contract information, in particular, concerning the renting or selling prices in the case of product-oriented PSS.
Renting and selling prices are derived from total costs, i.e., a predefined margin rate is applied to the total costs to determine the selling prices and the monthly/annual rent.
As shown in Figure 4, cost aggregation is executed through an algorithmic approach that comprises of one initial operation, namely "contract assignment" and one iterative operation, namely "contract management". The latter is responsible for managing the contracts through three parallel operations, namely "contract service execution", "calculation of contract material requirements" and "components replacement". A simplified version of the algorithms is presented to a brief overview of the main variables, procedures, and functions.
Algorithm 0 refers to "contract assignment" which initializes demand profile, in a one-shot operation (Figure 5a). Algorithm 1 updates the current simulation period ( Figure  5b) and triggers Algorithms 2 to 4 ( Figure 6). These latter algorithms are executed for each simulation period and for each ongoing contract.

System Analysis
The calculation of cost and revenue lies at the heart of system analysis, which enables the attribution of costs and revenues to the actors according to contract specification and to their roles defined in the PSS scenarios, represented by a given value network configuration.
Cost calculation follows a bottom-up procedure, flowing from the identification of activity costs upwards to the assignment of costs to different actors. Firstly, the activity costs are calculated based on the unit cost and quantities of resources, if available, or using activity unit cost provided by domain experts (i.e., aggregated values considering the unit cost and quantities). The contribution of a given activity to the cost of a given actor is derived from the unit activities' costs and the required volume of product or service for the actor. The revenues are calculated based on the contract information, in particular, concerning the renting or selling prices in the case of product-oriented PSS.
Renting and selling prices are derived from total costs, i.e., a predefined margin rate is applied to the total costs to determine the selling prices and the monthly/annual rent.
As shown in Figure 4, cost aggregation is executed through an algorithmic approach that comprises of one initial operation, namely "contract assignment" and one iterative operation, namely "contract management". The latter is responsible for managing the contracts through three parallel operations, namely "contract service execution", "calculation of contract material requirements" and "components replacement". A simplified version of the algorithms is presented to a brief overview of the main variables, procedures, and functions.

System Analysis
The calculation of cost and revenue lies at the heart of system analysis, which enables the attribution of costs and revenues to the actors according to contract specification and to their roles defined in the PSS scenarios, represented by a given value network configuration. Cost calculation follows a bottom-up procedure, flowing from the identification of activity costs upwards to the assignment of costs to different actors. Firstly, the activity costs are calculated based on the unit cost and quantities of resources, if available, or using activity unit cost provided by domain experts (i.e., aggregated values considering the unit cost and quantities). The contribution of a given activity to the cost of a given actor is derived from the unit activities' costs and the required volume of product or service for the actor. The revenues are calculated based on the contract information, in particular, concerning the renting or selling prices in the case of product-oriented PSS.
Renting and selling prices are derived from total costs, i.e., a predefined margin rate is applied to the total costs to determine the selling prices and the monthly/annual rent.
As shown in Figure 4, cost aggregation is executed through an algorithmic approach that comprises of one initial operation, namely "contract assignment" and one iterative operation, namely "contract management". The latter is responsible for managing the contracts through three parallel operations, namely "contract service execution", "calculation of contract material requirements" and "components replacement". A simplified version of the algorithms is presented to a brief overview of the main variables, procedures, and functions.
Algorithm 0 refers to "contract assignment" which initializes demand profile, in a one-shot operation (Figure 5a). Algorithm 1 updates the current simulation period ( Figure  5b) and triggers Algorithms 2 to 4 ( Figure 6). These latter algorithms are executed for each simulation period and for each ongoing contract.  Algorithm 0 refers to "contract assignment" which initializes demand profile, in a oneshot operation (Figure 5a). Algorithm 1 updates the current simulation period (Figure 5b) and triggers Algorithms 2 to 4 ( Figure 6). These latter algorithms are executed for each simulation period and for each ongoing contract. The algorithm of contract assignment (Algorithm 0) is shown in Figure 5a. In the light of a time horizon predefined by the user, this algorithm assigns the available contracts to a demand profile, by defining the required type of contracts for every period. Several distinct types of contract can be assigned, depending on the duration, the type of product selected, and the services included. The second algorithm (Figure 5b) concerns contract management, i.e., the periodic update of the contract status, depending on the simulation period and the triggered events. For instance, the status of the contract can switch to "closed contract" or, on the contrary, "ongoing contract", depending on whether it comes to an end during the current period. Product life span is checked and the way to generate the provider's revenues is selected depending on the contract type (e.g., rent if use-oriented, selling price in case of product-oriented contract).
Algorithm 2 is dedicated to the execution of service operations (Figure 6a). It involves iteratively triggering the execution of various service-related activities as per the contract specification (i.e., service frequency). Costs and revenues are assigned to a service provider and customer (based on attributes specified in the service class).
Algorithm 3 focuses on the calculation of material requirements to launch product provision (Figure 6b). A product required by a contract can be provisioned by two alternative ways according to the stock level. In the case of the product being available in stock, then the stock needs only to be decremented with the required quantity. If the stock is insufficient, then the material requirement will trigger the execution of production activities (which also generates costs and revenues for the product provider). Finally, the algorithm updates customer costs, which equals the revenues of the provider.
Algorithm 4, as shown in Figure 6c, tracks the products and components lifetime to properly proceed with their replacement at the end of their lifespan. Based on an initial estimation of a component's remaining lifetime, the algorithm identifies the necessary replacements. The replacement can be executed in two alternative ways: a replacement service is triggered if this replacement is included in the offer, or the replacement is executed internally as per equipment requirements. In the first case, the activities of "replacement service" are triggered and associated costs and revenues are assigned to the involved actors (e.g., customers and service providers).
The algorithmic approach is launched after an initial simulation setting, which aims at checking cost data, completing missing data, and establishing hypotheses. The typical decisions made at this point include, for example, the validation of profit margin rates (used to compute monthly rent of a given contract) and selling prices of manufactured products. Additionally, a structured experimentation plan is built to explore various alternatives to the scenarios and compare their economic results. Simulated scenarios can be differentiated by the type of PSS contracts as well as the content of the service offer. Several simulation runs are then triggered to analyse the experimentation plan.

Implementation
The proposed approach was implemented within a web-based software platform in PHP (Hypertext Preprocessor Language). The working environment is structured into five menus: users, instances, scenarios, simulation and results. The user menu is intended The algorithm of contract assignment (Algorithm 0) is shown in Figure 5a. In the light of a time horizon predefined by the user, this algorithm assigns the available contracts to a demand profile, by defining the required type of contracts for every period. Several distinct types of contract can be assigned, depending on the duration, the type of product selected, and the services included.
The second algorithm (Figure 5b) concerns contract management, i.e., the periodic update of the contract status, depending on the simulation period and the triggered events. For instance, the status of the contract can switch to "closed contract" or, on the contrary, "ongoing contract", depending on whether it comes to an end during the current period.
Product life span is checked and the way to generate the provider's revenues is selected depending on the contract type (e.g., rent if use-oriented, selling price in case of productoriented contract).
Algorithm 2 is dedicated to the execution of service operations (Figure 6a). It involves iteratively triggering the execution of various service-related activities as per the contract specification (i.e., service frequency). Costs and revenues are assigned to a service provider and customer (based on attributes specified in the service class).
Algorithm 3 focuses on the calculation of material requirements to launch product provision (Figure 6b). A product required by a contract can be provisioned by two alternative ways according to the stock level. In the case of the product being available in stock, then the stock needs only to be decremented with the required quantity. If the stock is insufficient, then the material requirement will trigger the execution of production activities (which also generates costs and revenues for the product provider). Finally, the algorithm updates customer costs, which equals the revenues of the provider.
Algorithm 4, as shown in Figure 6c, tracks the products and components lifetime to properly proceed with their replacement at the end of their lifespan. Based on an initial estimation of a component's remaining lifetime, the algorithm identifies the necessary replacements. The replacement can be executed in two alternative ways: a replacement service is triggered if this replacement is included in the offer, or the replacement is executed internally as per equipment requirements. In the first case, the activities of "replacement service" are triggered and associated costs and revenues are assigned to the involved actors (e.g., customers and service providers).
The algorithmic approach is launched after an initial simulation setting, which aims at checking cost data, completing missing data, and establishing hypotheses. The typical decisions made at this point include, for example, the validation of profit margin rates (used to compute monthly rent of a given contract) and selling prices of manufactured products. Additionally, a structured experimentation plan is built to explore various alternatives to the scenarios and compare their economic results. Simulated scenarios can be differentiated by the type of PSS contracts as well as the content of the service offer. Several simulation runs are then triggered to analyse the experimentation plan.

Implementation
The proposed approach was implemented within a web-based software platform in PHP (Hypertext Preprocessor Language). The working environment is structured into five menus: users, instances, scenarios, simulation and results. The user menu is intended for user administration such as creating new users and editing their access rights. The instance and scenario menus are intended to support system modelling ( Figure 7). Specifically, the instance menu accommodates a set of objects (compliant to the model shown in Figure 3) that can describe a PSS within a given engineering/assessment project. The instance menu provides a pool of objects that can be combined freely by users to define alternative PSS scenarios. The simulation generates the economic results according to the perspectives of actors. Firstly, several simulation runs are executed with partial datasets for testing and validation purposes. Then the platform is used for a full experimentation plan, which functions to fine-tune some economic parameters such as rent and margin rate. The result menu provides a visualization of cost and revenue indicators for each actor, with a reminder of the input data in a way to keep track of the experimentation plan. Systems 2021, 9, x FOR PEER REVIEW 10 of 17 Figure 7. Excerpt from the web platform for PSS economic assessment (PS3A-PSS Analyzer).

Overview and Scenario Definition
The aim of this section is to illustrate the applicability of the framework and to provide some insights into the economic drivers of different PSS alternatives through a case study. The case concerns a PSS project for industrial cleaning. The offer consists of an autonomous cleaning robot along with several services. A similar industrial cleaning robot is illustrated in Figure 8. The actors involved in the value network included the solution provider (currently involved in the equipment design), the battery provider (energy module for the robot), and a customer that is a prominent company in the meat production field.
Currently (scenario S0), a service provider is taking care of the cleaning process of customer premises. The PSS engineering project is coordinated by the Solution provider that can be regarded as the focal company within the value network in all envisioned scenarios. Core skills of the Solution provider include robotics integration and special machines assembly. The Solution provider operates in a business-to-business context and adopts a project-based organisation to meet customized requirements through an engineer-to-order strategy. The Solution provider aims to reinforce the customer-centricity by introducing integrated offers of products and services in new markets. The current PSS engineering project involves a first step that is to introduce a novel cleaning solution to the meat-processing industry.
A prominent company in this sector is interested in the new solution of autonomous cleaning. The interest of this company, hereafter referred to as the Customer, is driven by a productivity and quality improvement strategy. The highly regulated meat processing sector requires that only qualified personnel can process the meat. This constraint applies to not only the cleaning personnel (usually with no such qualification) but also for production personnel who need to remove obstacles for easing the cleaning process. Therefore, the Customer is interested in an autonomous cleaning solution to prevent the overload on production personnel and to improve the quality of cleaning.
In this sense, several "to-be" scenarios were identified and are filtered afterwards in collaboration with the project consortium. The current case study will be limited to the

Overview and Scenario Definition
The aim of this section is to illustrate the applicability of the framework and to provide some insights into the economic drivers of different PSS alternatives through a case study. The case concerns a PSS project for industrial cleaning. The offer consists of an autonomous cleaning robot along with several services. A similar industrial cleaning robot is illustrated in Figure 8.

Overview and Scenario Definition
The aim of this section is to illustrate the applicability of the framework and to provide some insights into the economic drivers of different PSS alternatives through a case study. The case concerns a PSS project for industrial cleaning. The offer consists of an autonomous cleaning robot along with several services. A similar industrial cleaning robot is illustrated in Figure 8. The actors involved in the value network included the solution provider (currently involved in the equipment design), the battery provider (energy module for the robot), and a customer that is a prominent company in the meat production field.
Currently (scenario S0), a service provider is taking care of the cleaning process of customer premises. The PSS engineering project is coordinated by the Solution provider that can be regarded as the focal company within the value network in all envisioned scenarios. Core skills of the Solution provider include robotics integration and special machines assembly. The Solution provider operates in a business-to-business context and adopts a project-based organisation to meet customized requirements through an engineer-to-order strategy. The Solution provider aims to reinforce the customer-centricity by introducing integrated offers of products and services in new markets. The current PSS engineering project involves a first step that is to introduce a novel cleaning solution to the meat-processing industry.
A prominent company in this sector is interested in the new solution of autonomous cleaning. The interest of this company, hereafter referred to as the Customer, is driven by a productivity and quality improvement strategy. The highly regulated meat processing sector requires that only qualified personnel can process the meat. This constraint applies to not only the cleaning personnel (usually with no such qualification) but also for production personnel who need to remove obstacles for easing the cleaning process. Therefore, the Customer is interested in an autonomous cleaning solution to prevent the overload on production personnel and to improve the quality of cleaning.
In this sense, several "to-be" scenarios were identified and are filtered afterwards in collaboration with the project consortium. The current case study will be limited to the The actors involved in the value network included the solution provider (currently involved in the equipment design), the battery provider (energy module for the robot), and a customer that is a prominent company in the meat production field.
Currently (scenario S0), a service provider is taking care of the cleaning process of customer premises. The PSS engineering project is coordinated by the Solution provider that can be regarded as the focal company within the value network in all envisioned scenarios. Core skills of the Solution provider include robotics integration and special machines assembly. The Solution provider operates in a business-to-business context and adopts a project-based organisation to meet customized requirements through an engineer-to-order strategy. The Solution provider aims to reinforce the customer-centricity by introducing integrated offers of products and services in new markets. The current PSS engineering project involves a first step that is to introduce a novel cleaning solution to the meat-processing industry.
A prominent company in this sector is interested in the new solution of autonomous cleaning. The interest of this company, hereafter referred to as the Customer, is driven by a productivity and quality improvement strategy. The highly regulated meat processing sector requires that only qualified personnel can process the meat. This constraint applies to not only the cleaning personnel (usually with no such qualification) but also for production personnel who need to remove obstacles for easing the cleaning process. Therefore, the Customer is interested in an autonomous cleaning solution to prevent the overload on production personnel and to improve the quality of cleaning.
In this sense, several "to-be" scenarios were identified and are filtered afterwards in collaboration with the project consortium. The current case study will be limited to the following PSS: product-oriented (Product-PSS), use-oriented (Use-PSS) and resultoriented (Result-PSS), each sold in a 5-year contract. The selection of these scenarios for further analysis resulted from grouping the initially identified scenarios using Tukker classification [32]. The actors involved in the engineering project jointly validated the scenario classification and removed irrelevant scenarios. In the product-oriented scenario, the robot is sold based on a transactional sales model, but is accompanied by a service contract that includes staff training and robot maintenance. In the use-oriented scenario, the Solution provider is responsible for the robot setup and maintenance services. In the resultoriented scenario, the Solution provider takes over the full responsibility of the cleaning activity. These scenarios are summarized in Table 1. The battery provider prefers to be distanced from the customers to avoid additional complexities of customer relationship management. Their preference, regardless of the scenario, is to sell the battery directly to the solution provider. Typical datasets required for the assessment include the bill of materials, activities related to maintenance and cleaning services, the unit cost of different activities, the service frequency and the margin rate of product/service. Data related to cost and revenue were double-checked for accuracy and consistency throughout the project. Due to confidentiality, the technical data about the equipment and unit costs are not fully disclosed. The cost of the robot, that is, the product embedded in the PSS amounts to EUR 100,000. Several services are identified by the project consortium with the support of the authors. Table 2 shows the list of the selected services together with their unit cost estimates. The results are generated for ten simulation periods (i.e., a period refers to one year). The principal aim consists in comparing alternative scenarios. The analysis focuses more on the result variability among the distinct scenarios, as opposed to providing exact total costs for the value network actors. The total service costs increase as per the required execution frequency (generally between once and twice a year). The major part of total costs related to the PSS is the one related to renting the robot itself (rather than to related services) given its high manufacturing and assembly cost. Table 2. Service groups and cost estimates.

Service Group Unit Cost Estimates (EUR)
Customer co-design 700 Installation services 1200 Equipment cleaning 400 Maintenance 900

Simulation Setting and Economic Results
The three scenarios shown in Table 1 were simulated upon modelling all required objects and entering cost data using the software platform. The assumption is that the demand will grow incrementally throughout the first year after launching the PSS. Then, it is expected to increase more rapidly in the following years, until the growth stagnates in the last year. Figure 9 shows the demand profile for the simulation, which applies equally to all three scenarios.
installation fee is set to be EUR 4,000, which applies equally to both PSS. All services are executed at the same frequency regardless of th stochastic variables are introduced in the cost and revenue calculati tion run is required for each input dataset. It is worth noting that results lies in the comparative analysis. The monthly rent, selling pri determined based on the assumption that the fixed costs are the same acr ( Figure 10). The results reported on in Figure 10 show the cumulative pr PSS scenario in consideration of the demand profile over ten periods (F  It can be seen from Figure 10 that the net profit for the battery over the three scenarios. The transformation towards PSS provides a Battery provider to gain steady revenue with mitigated risk. On the o for the Solution provider increases by almost 60% in Use-PSS comp For the Solution provider, the profit of Result-PSS is significantly hig PSS by 200%. A result-oriented contract provides the Solution prov portunity to diversify its revenue stream. In the Result-PSS, the Sol over the cleaning activities instead of the Customer. In this way, the enabled to sell not only the equipment and its related services but also itself. A major revenue for the Solution provider comes from the clea  Based on discussion with actors from the Solution provider and the Battery provider, the margin rates for manufacturing and service are set to be 0.2 and 0.3, respectively. The robot selling price in Product-PSS amounts approximately to EUR 117,000. The annual rent is about EUR 57,000 in the Use-PSS and EUR 179,000 in the Result-PSS. The fixed installation fee is set to be EUR 4000, which applies equally to both Use-PSS and Result-PSS. All services are executed at the same frequency regardless of the scenarios. Since no stochastic variables are introduced in the cost and revenue calculation, only one simulation run is required for each input dataset. It is worth noting that the relevance of the results lies in the comparative analysis. The monthly rent, selling price, and unit costs are determined based on the assumption that the fixed costs are the same across all three scenarios ( Figure 10). The results reported on in Figure 10 show the cumulative profits per actor and per PSS scenario in consideration of the demand profile over ten periods (Figure 9). Systems 2021, 9, x FOR PEER REVIEW 12 of 17 in the last year. Figure 9 shows the demand profile for the simulation, which applies equally to all three scenarios. Based on discussion with actors from the Solution provider and the Battery provider, the margin rates for manufacturing and service are set to be 0.2 and 0.3, respectively. The robot selling price in Product-PSS amounts approximately to EUR 117,000. The annual rent is about EUR 57,000 in the Use-PSS and EUR 179,000 in the Result-PSS. The fixed installation fee is set to be EUR 4,000, which applies equally to both Use-PSS and Result-PSS. All services are executed at the same frequency regardless of the scenarios. Since no stochastic variables are introduced in the cost and revenue calculation, only one simulation run is required for each input dataset. It is worth noting that the relevance of the results lies in the comparative analysis. The monthly rent, selling price, and unit costs are determined based on the assumption that the fixed costs are the same across all three scenarios ( Figure 10). The results reported on in Figure 10 show the cumulative profits per actor and per PSS scenario in consideration of the demand profile over ten periods (Figure 9).  It can be seen from Figure 10 that the net profit for the battery provider is the same over the three scenarios. The transformation towards PSS provides an opportunity for the Battery provider to gain steady revenue with mitigated risk. On the other hand, the profit for the Solution provider increases by almost 60% in Use-PSS compared to Product-PSS. For the Solution provider, the profit of Result-PSS is significantly higher than that of Use-PSS by 200%. A result-oriented contract provides the Solution provider with a new opportunity to diversify its revenue stream. In the Result-PSS, the Solution provider takes over the cleaning activities instead of the Customer. In this way, the Solution provider is It can be seen from Figure 10 that the net profit for the battery provider is the same over the three scenarios. The transformation towards PSS provides an opportunity for the Battery provider to gain steady revenue with mitigated risk. On the other hand, the profit for the Solution provider increases by almost 60% in Use-PSS compared to Product-PSS. For the Solution provider, the profit of Result-PSS is significantly higher than that of Use-PSS by 200%. A result-oriented contract provides the Solution provider with a new opportunity to diversify its revenue stream. In the Result-PSS, the Solution provider takes over the cleaning activities instead of the Customer. In this way, the Solution provider is enabled to sell not only the equipment and its related services but also the cleaning service itself. A major revenue for the Solution provider comes from the cleaning service.
While Result-PSS seems to be the best scenario for the Solution provider from an economic point of view, it still entails big organisational and technical challenges. The Solution provider must reposition itself as an integrator of robotic solutions (i.e., hardware and software) and targets the cleaning activity as a completely new market. The process of repositioning and retargeting will inevitably impose new skills, more uncertainties, and higher risks for the Solution provider.
From the customer perspective, Product-PSS involves the lowest total cost, though it requires that the Customer should take over the cleaning activities. This is feasible if the Customer can reach a new agreement with the current service provider to adopt the new autonomous robot. In Use-PSS, the Customer's responsibility can be lowered through a contract engaged with the Solution provider, which however will result in a 50% increase in the purchasing cost. Result-PSS is more costly for the Customer. Therefore, a rational decision on the best scenario for the Customer depends upon the comparison between its current cleaning cost and the result-oriented rent. Such a comparison, in turn, depends on a variety of factors such as whether the cleaning is outsourced and to what extent the cleaning process can be further optimized. In the light of the Customer priorities on minimizing the impact on production and improving the cleaning quality, a hybrid between Product-PSS and Use-PSS would be ideal.
The above analysis shows how the framework integrates multi-actor perspectives and enables collaborative negotiations on alternative PSS scenarios. The next section will be based only on Use-PSS to carry on further analysis. In practice, a decision on whether to choose Use-PSS requires further analysis and a full business plan.

Identification of Economic Drivers
The aim of this iteration within the system analysis is to increase the actors' awareness of the main economic drivers. The discussions among the PSS engineering team resulted in a subset of input variables, entailing uncertainties that may have impacts on the revenues and costs. These variables include the average yearly demand volume (dv), product margin rate (pmr), service margin rate (smr), and contract duration. Initially, a linear regression was conducted to investigate the correlation between profits (predicted variable) with dv, pmr, and smr (predictive variables). The analysis resulted in a high value of R square, around 0.95, so it was decided to focus on a simple one-at-a-time (OAT) sensitivity analysis ( Figure 11).
The tornado diagram ( Figure 11) shows the profit changes for A1 and A2 with different input values of dv, pmr, and smr. It is clear that the lion's share goes to the demand volume; a change with 25% leads to almost 40% increase in the net profit. Unsurprisingly, the margin rates of product and service contribute to an increase in profit for both actors. However, the increase in profit of A2 (30%) is more significant than for A1 (10%). This can be explained by the specialisation of A2 in manufacturing and selling the battery, so its single revenue stream is product sales. In contrast, A1 generates revenues from product manufacturing as well as service delivery. This is confirmed by the impact analysis of service margin rate, which amounts to approximately 5% for A1 and imposes no impact on A2 profit. revenues and costs. These variables include the average yearly demand volume (d product margin rate (pmr), service margin rate (smr), and contract duration. Initiall linear regression was conducted to investigate the correlation between profits (predic variable) with dv, pmr, and smr (predictive variables). The analysis resulted in a h value of R square, around 0.95, so it was decided to focus on a simple one-at-a-time (O sensitivity analysis (Figure 11). The tornado diagram ( Figure 11) shows the profit changes for A1 and A2 with dif ent input values of dv, pmr, and smr. It is clear that the lion's share goes to the dem volume; a change with 25% leads to almost 40% increase in the net profit. Unsurprisin the margin rates of product and service contribute to an increase in profit for both act However, the increase in profit of A2 (30%) is more significant than for A1 (10%). This

Drivers of A2 profit
Low High Figure 11. OAT sensitivity analysis results.
While system modelling and data collection were challenging due to the large number of objects and parameters included in the framework (e.g., product, service, contracts, unit costs, margins, etc.), they allow for sensitivity analysis and can lead to a more reliable analysis result. This confirms the importance of comprehensiveness as a key requirement of the proposed framework.
From a practical point of view, these conclusions are likely to drive the decisionmakers within the PSS engineering project towards potentially viable alternatives. In this sense, the identification of drivers can help mitigate risks through a more informed decision-making process. Furthermore, more accurate cost data can be made available at subsequent steps of the PSS development and thus could be used to fine-tune the cost and revenue calculation. On the other hand, the development of a PSS or any complex system requires a full business plan. The current framework comes into play, after a PSS is designed, to provide relevant actors with a rough economic assessment of alternative scenarios for moving forward. Therefore, it can provide valuable insights in support of the subsequent PSS ramp-up phase. Proceeding with the ramp-up should however be supported by detailed analysis of the market and capacity requirements [41].

Discussion and Concluding Remarks
The proposed framework is developed to fulfil three key requirements derived from the literature; namely comprehensiveness, life cycle, and collaboration. It combines system modelling and analysis to enable economic assessment of PSS. Consistent with DRM, one evaluation run was conducted using a case study, which shows how the framework can be applied to address real-world problems and what insights can be drawn. The proposed framework provides comprehensive guidance in supportive of the economic assessment of PSS value networks. The implementation within a software platform fosters the reusability and drives down the time and cost for performing the assessment.
As such, the framework is complementary to the existing literature in several ways. The literature includes several classifications of (PSS) costing approaches, which exhibit however some similarities [18,25,36]. Generally speaking, costing methods call for one or more of the following computational techniques: intuitive technique (e.g., based on expert judgment), analogical technique (i.e., based on similarity with an existing cost object), parametric technique (i.e., based on the top-down identification of costs), and analytical technique (i.e., based on the bottom-up principles) [18]. Intuitive and analytical techniques are combined to proceed with cost attribution [25] before moving forward to the industrialization process. The proposed framework addresses several challenges mentioned by [25] in PSS cost assessment, which are related to "what?" (cost object), "why/to what extent?" (scope and boundaries), and "how?" (computation and metrics). Regarding the question of "what constitutes an appropriate cost object", we suggest the use of contracts that can specify, for instance, the content of a PSS in terms of products, services, product-service integration, and the contract duration. Regarding the scope and boundaries of the analysis, we are aligned with [25] who argued that the scope should "cover interlinked activities performed within and across the organisational boundaries". The required activities for PSS are derived from contract specification in terms of product and services. Finally, regarding computation and metrics, the proposed approach is based on a bottom-up cost attribution approach that builds progressively upon unit activity cost.
In order for the economic assessment to be successful, it is important for the PSS engineering team to work closely and collaboratively. In fact, the reliability of the economic assessment depends upon the consistency of the system modelling and on the established hypotheses. Consequently, substantial efforts should be dedicated to the definition of hypotheses and the modelling of PSS. Improvements of the proposed framework could cover this need by providing further support during the data collection process. The aim is to guide the PSS engineering team to make all hypotheses explicit and validate them as a whole set. On the other hand, the proposed approach still has some limitations since for the moment it has not considered uncertainty [8] that could be a major characteristic of certain PSS markets. Another improvement area relates to the non-monetary metrics such as environmental and social ones. The main challenge at this point is the amount of data required to conduct a more holistic assessment. One possible option could be to narrow the scope of the environmental assessment and use only a subset of environmental indicators. These perspectives are being considered, and further refinements of the framework are being explored.
In summary, value network is a backbone of PSS design, in particular the need for a multi-actor dimension to foster the more collaborative PSS development. The economic assessment is an important means to inform PSS actors about various impacts on different configurations of the value network. The economic assessment of PSS is a challenging task, due to the natural heterogeneity of data about product, service, process and actors. Built upon existing costing approaches (TLC and ABC), the framework presented in this paper extends the literature in different ways. Firstly, it enables informed attribution of cost and revenue to different actors in a value network, leading to more collaborative PSS development. Secondly, it incorporates the PSS use phase into assessment by considering the costs and revenues related to product replacement and service execution within a contract duration. The case study shows how the framework can support decision-making in a real-world PSS scenario, thus paving the way for risk mitigation in the PSS domain.