A Hypergraph-Based Modeling Approach for Service Systems

Abstract

Currently, research on service science has emerged as its own discipline, where service systems are its basic unit of analysis. However, without a clearly defined modeling approach for service systems, analyzing a service system is challenging. We therefore propose a conceptual hypergraph-based modeling approach, which can be used to model services for both traditional goods-dominant businesses, as well as service-businesses. We define key elements of a service system, while drawing upon hypergraph theory and present three modeling properties which are required to model a service systems graph (SSG). The focus of SSGs is to describe the relationships between the various resources, actors and activities, thus configuring a service system. It provides the foundation for computer graphic simulations and database applications of service business structure for future research.

1 Introduction

Throughout the emergence of Service Science, service systems have always been a key concept of the discipline [27]. Since the seminal paper on service dominant logic [30] both service-centric businesses and traditionally goods-dominant businesses have begun to apply a service perspective on their organization in order to remain competitive and innovate [20]. Especially research on the transition to services has gained traction by terms, such as servitization [16].

Service as a way of thinking has gradually evolved and is used by both manufacturing and service-businesses, since production can be also be seen as internal services for providing an end-customer a value proposition [15]. Thinking in service systems can help identify service innovation potentials [5, 8]. However, we model service systems using a multitude of modeling approaches focusing on actors and a processual perspective [6, 19, 26, 28] or more technical perspectives. Yet, it can be challenging for practitioners to utilize the concept of service systems from a business perspective [1]. Since service scientists “study, manage, and engineer service systems, solving problems and exploiting opportunities to create service innovations” [24], our research goal is to provide a tool to model and analyze service systems. Our research question is therefore as follows: How can we model basic service systems both correctly and graphically?

2 A Service Systems Perspective

The service system’s inherent focus lies in finding the right configurations of resources for actors in order to create value in the right context (value-in-context, formerly referred to as value-in-use) through the use of services to customers [7, 16, 30]. Vargo and Lusch [30] have addressed the configuration in applying their concept of service dominant logic and called it resourcing. A service system is guided by a value proposition, which in turn has a corresponding configuration of actors and resources [7, 30].

We define a service system as a value co-creation configuration of resources [22]. This perspective is rooted in service dominant logic [23]. Resources include both operand and operant resources [21]. Different configurations of resources are connected by respective value propositions, sometimes also seen as service exchanges [29].

Recent research revisits the importance of value propositions and engagement of service systems [11], in which organizations seek to find the right constellation of actors (“who”) within a service system that enables actors to find the correct resources (“who” and “with whom”) for a specific context (“when”) in order to co-create value [11, p. 1], whereas the creation of value (“value-in-use”) happens through activities between actors, also referred as interactions [30]. This coincides with an input-output perspective, in which the realization of value happens through a transformation process of resources by actors [11].

The actors are essential to realize the initially proposed value. They act upon the resource configurations to achieve the value proposition. Since a service system includes different types of resources and actors, who create value to a customer, we define the term “service objects” that pairs corresponding resources and actors, for a value proposition. Realizing the value proposition for the customer is imperative. From a service-provider perspective, it is decisive to know the constellation of resources that actors require. An actor can be individuals, teams, organizations or even software systems, if they mobilize the required resources. The service system therefore needs to be orchestrated to bring all resources and actors together. Hence, our service system graph is focused on service orchestrators as key stakeholder.

In conclusion, the constituent elements of a service systems are: resources, actors, service objects and activities. These elements should be configured to realize value. These elements serve as form of lightweight ontology for our service system modelling approach. Key contribution of this paper is the definition of their relationships using hypergraph theory.

3 Developing Service Systems Graphs (SSG)

First, we define the key concepts of our service system using hypergraph theory, which has its origins in graph theory and generalizes upon the concept of graphs [3]. A hypergraph G = (V, E) exists as a pair of edges E and set of vertices V, where the edges e ∈ E does not only connect two, but any number of vertices v ∈ V, thus calling E a set of hyperedges. A hyperedge e ∈ E is therefore a subset of all vertices V, which are connected by it, e ⊆ V. Additionally, E is a subset of P(V)\∅, where P(V) is the power set of V.

Since service systems require resources as input factors, we define a set R with r ∈ R as all required forms of resources. Service systems also require actors [9]. We define actors as a set A with a ∈ A representing an actor. Since we define A as the set of required actors, it would be better to consider A as a team or organizational unit that is required for providing the service. An actor a can thus be an individual, a group, an organizational unit or even software systems.

A service system for a specific value proposition requires both actors and related resources. We called a pair of actor and required resources, “service objects” and define all service objects as a set O with o ∈ O being a single service object. Formalized, a service object is a tuple of the required resources and the required actors specific to a value proposition. Hence, service objects are the subject matters of service systems, which are defined in a specific context as input sets of respective outputs. Let O ≠ ∅ be the set of required service objects of any service-driven organization, with o ∈ O defined as a service object. Thus, a service object is a tuple consisting of resources and actors. Formalized, service objects are defined as follows:

Definition 1

A finite non-empty set O with tuple of (R, A) is called service object where

• i. R is a finite set of resources with ${\text{R}} = \left\{ {{\text{r}}_{1} ,{\text{r}}_{2} , \ldots ,{\text{r}}_{\text{n}} } \right\}$;

• ii. A is a family of subset actors of R with A = (a_i) in which a_i ⊂ R and ${\text{R}} = {\bigcup }_{{{\text{i}} = 1}}^{{\rm n}}\,{\text{a}}_{\text{i}}$ for i ∈ {1, 2, …, n}.

Definition 1 shows that service object O is essentially a hypergraph [3]. Therefore, the service object O, the tuple (R, A) is a hypergraph of service objects, which inherently represent all possible value propositions of said service system. In other words, the potential of a service system can be unlocked by reconfiguring its resources and assigning it a suitable actor.

Hypergraph theory has extensively focused on its sets of vertices [10], whereas we put equal importance to its hyperedges. Due to the roles of actors in service science, we inscribe the semantic meaning of actors into hyperedges. A service object includes both actors and resources, both paramount for the realization of the service.

The service object is the static part of a service system. It constitutes the necessary input resources R, which actors A require, before an actor can provide value to a service consumer. In other words, it represents the potential value an actor can provide to a potential consumer.

The vertices (sometimes known as nodes) of a hypergraph G_i represent resources and hyperedges of G_i represent actors, whereas we define required actors and resources as service objects. Following hypergraph theory, hyperedges can intersect with each other, illustrating shared resources.

The service object can be the end result, as well as intermediate results of any service, each representing value propositions in terms of service exchanges. If the above mentioned elementary object is put together with other service objects, another service system can be configured. This is an analogous characteristic to “traditional” manufacturing cases (e.g., [15]), in which outputs are used as inputs for other processes, thus creating a path. We will revisit the path characteristic shortly, when introducing service activities.

An element graph is a graph of order = 1, that is, |G_i| = 1 for i ∈ {1, 2, …, n} [3]. It represents a service object o₀ ∈ O with tuple (a₀, R₀) where |R₀| = 1. It is apparent that the elementary graph itself has edges. We changed the representation from a solid dot by adding a circle around it to indicate that it also has an hyperedge and hence constitutes a service object, as depicted in Fig. 1. We argue that single resources can always be considered as element graphs. However, we recommend only drawing the hyperedge if it is either an explicit output of a service object or if the element graph itself is a single input.

Fig. 1

Hypergraph G

Although we have mapped service objects, which consist of actors and resources, we have yet to map a sequence of activities into our modeling approach. Up until now, a hypergraph can be used to model non-directional set of elements that contains the information of relationships among elements with the help of hyperedges. To map the relationship of elements of different hypergraphs, directional hypergraphs can be used to map the relationship of elements towards other elements of different graphs [13]. However, it is not possible to map entire hypergraphs towards other hypergraphs or toward elements of other hypergraphs. We need to expand upon the existing definitions of hypergraphs. We do so by introducing an approach to map a service object to other service objects with $\psi$. In the following section we will define how to map hypergraphs to other hypergraphs. This enables us to model service systems with hypergraphs.

Definition 2

O is a finite non-empty set of service object and O is a hypergraph of service objects. A mapping $\psi(\psi^{ + } ,\psi^{ - } )$

$$ {\text{with}}\qquad\psi:{\text{O}}:{\text{O}} \times {\text{O}} \to {\text{Boolean}}\,\,\,\,\,{\text{where}}\,\,\,{\text{O}} \times {\text{O}} \subset 2^{\text{O}} $$

is called a service activity of service objects.

Service activities for service objects are represented by the binary mapping between different service objects. One service object is seen as input, whereas the other is seen as output, while the value realization is enabled by an activity that makes the transition from one service object to another possible. The mapping $\psi$ is a tuple of ($\psi^{ + }$, $\psi^{ - }$), which is a directed or counter-directed mapping of hypergraphs. In this paper, $\psi$ and $\psi^{ + }$ are used synonymously for directed mapping (Fig. 2), accompanied by the drawing of an arrow line. This is not to be confused with directed hypergraphs, which only allows relationships between elements of different hyperedges [13].

Fig. 2

Directed mapping of hypergraphs

Definition 3

Let R be a finite nonempty set of resources, A a finite nonempty set of actors and O a set defined as tuple (R, A) be a hypergraph of a service object and Ψ be a set of functions as service activities. Then the tuple (R, A, Ψ) is called the SSG or service system graph,

$$ {\text{where}}\qquad\Psi :\Psi \left( {\text{O}} \right) \to\Psi ^{ + } ({\text{O}})\quad {\text{with}}\,\,\,\exists \,{\text{o}} \in {\text{O}}\,|\,\Psi ^{ - } \left( {\text{o}} \right) \cap\Psi ^{ + } ({\text{o}}) = \emptyset . $$

Function Ψ(O) defines which service objects are required as input factors and function Ψ⁺(O) defines the output service objects.

A service system graph is a directed graph, which models the value creation and value propositions of a chain of services. The service system is a family of subset service objects. Thus, strictly speaking, a single service object can include a configuration of service object and corresponding activities. This means that service systems can consist of service systems.

To illustrate the relationships of a service system, we present the detailed example of a SSG (R, A, Ψ): Fig. 3 shows the SSG with a set of resource R = {r₁, r₂, …, r₁₀}, a family of the subset A = (a₁, a₂, a₃, a₄, a₅); a₁ = R₁ = {r₂, r₃, r₅}; a₂ = R₂ = {r₁, r₂}; a₃ = R₃ = {r₄, r₆, r₇}; a₄ = R₄ = {r₁, r₉, r₁₀}; a₅ = R₅ = {r₅}; and the function Ψ = (ψ_1, ψ_2, ψ₃, ψ₄) where ψ₁ = ((a₁, {r₂, r₃, r₅}), (a₅, {r₄, r₆, r₇})); ψ₂ = ((a₄, {r₁, r₉, r₁₀}), (a₀, {r₄})); ψ₃ = ((a₅, {r₄, r₆, r₇}), (a₀, {r₈})); ψ₄ = ((a₃, {r₄, r₆, r₇}), (a₀, {r₅})).

Fig. 3

Example service system graph with R_i $\Leftrightarrow$ O_i

4 Properties of Modeling Service Systems

Compared to the definition of hypergraphs, SSGs allow the existence of a predicate between two hypergraphs, which is represented by ψ_t. In order to model, we will present a selection of three modeling properties in the following section:

Multi-required (MR) service object: In an application environment, one service object is required by multiple activities, that is, it can be the input of more than one activities. According to the definition of SSG $\langle {\text{R}}, {\text{A}},\,\Psi \rangle$ and Ψ(Ψ⁻, Ψ⁺) we said a service object is a multi-required service object if $\mathop {\bigcap }\nolimits_{{{\text{i}} = 1}}^{\text{n}}\psi_{\text{i}}\left( {\text{o}} \right) \ne \emptyset$ where $\psi \in {\Psi}^{ - }$ and ∃ o ∈ O, n ≥ 2. In Fig. 4a the service object O₃, O₄ are multi-required service object for activities ψ₂, ψ₅ and ψ₃, ψ₄.

Fig. 4

a Multiple required service object and b multi-delivered service object

Multi-delivered (MD) service object: One service object can be delivered by more than one activity. It is similar to or operators. According to the definition of SSG(R, A, Ψ) and tuple Ψ(Ψ⁻, Ψ⁺) a service object is called a multi-delivered service object when ∃ $\mathop {\bigcap }\nolimits_{{{\text{i}} = 1}}^{\text{n}}\psi_{\text{i}}\left( {\text{o}} \right) \ne \emptyset$, where $\psi \in {\Psi }^{ + }$ and ∃ o ∈ O, n ≥ 2. In Fig. 4b the service object O₃, O₄ are multi-required service object for activities ψ₂, ψ₅ and ψ₃, ψ₄.

Sequence of service process: To model the service system, we still require to define the sequence of activities: Based on service system graph SSG(R, A, Ψ) and the service object O, subset of activities $\Psi _{\text{after}} \subset\Psi$ and $\Psi _{\text{before}} \subset\Psi$ with

$$ \Psi _{\text{before}} = \left\{ {\mathop {\bigcup }\limits_{i = 1}^{n} \left. {\psi_{\text{i}} \,\,} \right|\,\,\mathop {\bigcap }\limits_{{{\text{i}} = 1}}^{\text{n}} \psi_{\text{i}} \left( {\text{o}} \right) \ne 0\,{\text{where}}\,\psi \in\Psi ^{ + } \,{\text{and}}\,\exists \,{\text{o}} \in {\text{O}}} \right\}\,\,{\text{and}} $$

$$\begin{aligned} \Psi _{\text{after}} &= \left\{ {\mathop {\bigcup }\limits_{i = 1}^{n} \left. {\psi_{\text{i}} \,\,} \right|\,\,\mathop {\bigcap }\limits_{{{\text{i}} = 1}}^{\text{n}} \psi_{\text{i}} \left( {\text{o}} \right) \ne 0\,{\text{where}}\,\psi \in\Psi ^{ - } \,\,{\text{and}}\,\exists \,{\text{o}} \in {\text{O}}} \right\},\\ &\quad {\text{then}}\,\,{\text{a}} \in\Psi _{\text{after}} \,\,{\text{follows}}\,\,{\text{each}}\,\,{\text{b}} \in\Psi _{\text{before}}. \end{aligned} $$

We employ service system graph as a modeling approach to both formalize the relationships of configurations and visualize them using the inherent graphical notation. The next section discusses possible applications and areas of future research.

5 Application Scenario

Our modelling approach SSG has several application scenarios. The most evident one lies in its role as a tool to analyze both the organization’s status quo and to structure possible alternative service system configurations. This chapter includes a detailed modeling example to show how this tool can be utilized. We focus on presenting both the graphical representation and the formal realization of a real-world service system scenario. The graphical illustration helps service systems engineers and business decision makers to structure their current business using a service systems perspective. It can also help authors make different system configurations of the same service apparent, thus giving decision makers the option to choose “paths” to reach their desired goal.

To illustrate our SSG, we modeled a possible service system based on our research project, an implementation of a CRM system at a mid-size German company “PowerCorp”. PowerCorp faces the challenge of implementing a complex CRM system, for which they have tasked a team of IT consultants, service support providers, experts from the software provider and researchers. For the success of the IT-enabled organizational change project [25], four core services have been commonly understood as crucial: First, the technical task of installing and configuring the CRM system based on the PowerCorp’s existing IT-infrastructure. Second, the users require sufficient training using workshops or online courses that are specifically tailored to the needs of both the user’s and the system’s technical configurations. Third, the implementation of the CRM system requires extensive organizational analyses, which are usually provided by IT-consultants (including system tests). Fourth, the organization requires extensive after sales service support in case new requirements or questions arise. Part of the support requirements is also realized by a crowd support approach, which utilizes the potential of peer-advice hidden among PowerCorp’s business units [18].

Figure 5 shows a service system with its service objects and activities. O₁–O₄ are the key service objects that are required for a successes project O₁₄. They cover the above-described core services. Each service object consists of resources and an actor. See below for a complete and detailed list of all elements.

Fig. 5

Service system graph of the CRM implementation project

For a successful CRM system implementation, an organization also requires involvement from business units not just an external project team consisting of consultants. By relying on key users, valuable contextual domain-knowledge can be integrated to overcome potential organizational pitfalls. We therefore define the service object O₅ as an internal domain-knowledge service.

All five service objects are necessary, while using a SSG helps in clearly denoting where they come from. We view O₁ and O₂ as basic support services, whereas a total solution would include all implementation and testing services, as well as ongoing after sales services (O₇). If these services are guaranteed and the necessary adaptations were made by incorporating rich domain-specific knowledge provided by O₅, the reins can finally be handed over in terms of a turn-key service (O₈) to the board of directors. The provisioning of the turn-key service (O₈) to project success is represented by ψ₅.

To understand how we reach O₇, we see them as MD service objects. This helps us realize that there are two possibilities in providing a total solution to PowerCorp: (A) By configuring total solution practices (O₁₃) to the contextual conditions ψ₂. (B) Configuring the basic support practices O₁₁ accordingly ψ₁ and configuring both the hotline services O₉, ψ₃ and consulting portfolio O₁₀, ψ₄. It lies with the decision maker (e.g. service systems engineer) to choose which path to order to reach project success. As Fig. 6 shows, the different service system configurations are very similar to “paths”, with two alternative paths highlighted in the graphic.

Fig. 6

Service activities with optional path

The resulting service system is linked to a detailed list of resources and actors. This information is important for implementing a SSG as a software system. Relying on our formal definitions, we use can derive machine-readable data formats to integrate other systems. The following paragraphs give a detailed information on the service systems structure and thus according to the application scenario, SSG(R, A, Ψ) is described as follows:

R = {r₁: CRM Software, r₂: Hardware, r₃: Crowd Support System, r₄: Netware; r₅: Customer Specialist, r₆: Project Specialist; r₇: Software Trainer, r₈: Hardware Engineer; r₉: Software Developer, r₁₀: System Analyst, r₁₁: Project Leader; r₁₂: Telephone Service Support, r₁₃: Server with OS; r₁₄: Documents, r₁₅: Tester; r₁₆: System Platform r₁₇: Key Users; r₁₈: CRM Platform, r₁₉: Crosse Support/Online Platform, r₂₀: Running Application Hotline}.

A = (a₁ = {r₁, r₂, r₃, r₄, r₇}: Package A definition, a₃ = {r₆, r₈, r₉, r₁₀, r₁₁, r₁₂, r₁₃, r₁₄, r₁₅}: Implementation Team, a₄ = {r₆, r₈, r₉, r₁₀, r₁₁, r₁₂, r₁₃, r₁₄, r₁₅, O₁₁}: Total Solution Concept with Team, a₅ = {O₁, O₂}: Solution A Team with Training, a₆ = {O₁, O₂, O₃, O₄}: Project Solution Concept with Team, a₇ = {O₇, O₅}: Service Contract and Project Team, a₈ = {r₆, r₉, r₁₀, r₁₁, r₁₄, r₁₅}: Business Analyze and Implementation Team, a₉ = {r₁₂, r₁₃}: Project Team, a₁₀ = {r₅} Customer Project Team).

Ψ = {ψ₁ Solution A Configuration, ψ₂ Solution C Configuration, ψ₃ Consulting Configuration, ψ₄ Hotline service Configuration, ψ₅ Turn Key service provisioning} with ψ₁(O₁₁) = O₆; ψ₂(O₁₃) = O₇; ψ₃(O₉) = O₃; ψ₄(O₁₀) = O₄; ψ₅(O₈) = O₁₄}.

O = {O₁(a₀, {r₁₆}), O₂(a₀, {r₁₇}), O₃(a₀, {r₁₈}), O₄(a₀, {r₁₉}), O₅(a₁₀, {r₅}), O₆(a₅, r₁₆, r₁₇), O₇(a₆, {r₁₆, r₁₇, r₁₈, r₁₉}), O₈(a₇, {r₁₆, r₁₇, r₁₈, r₁₉, r₅}), O₉(a₈, {r₆, r₉, r₁₀, r₁₁, r₁₄, r₁₅}), O₁₀(a₉, {r₁₂, r₁₃}), O₁₁(a₁, {r₁, r₂, r₃, r₄, r₇}), O₁₂(a₃, {r₆, r₈, r₉, r₁₀, r₁₁, r₁₂, r₁₃, r₁₄, r₁₅}), O₁₃(a₄, {r₁, r₂, r₃, r₄, r₆, r₇, r₈, r₉, r₁₀, r₁₁, r₁₂, r₁₃, r₁₄, r₁₅}), O₁₄(a₀, r₂₀)}.

6 Discussion and Future Work

In conclusion, a SSG can be utilized to model complex service systems. Consider Fig. 3, where O₅ is the service object for the end-customer a5. We see the equivalents of “OR” and “AND” operators. To create service object O3, one can either choose (ψ₂ AND ψ₄) or one can choose activity ψ₁. For the first, both actor a₂ and a₄ are required, whereas a₂ utilizes shared resources from two different actors. As an alternative path to O₃, ψ₁ is also an option. This enables us to model different configurations of one service system as sub-systems, leveraging the systems of a systems principle [4].

This enables service engineers to model their service systems both from a process perspective and from a structural perspective. Theoretically, we employed the input-output perspective for our modelling approach thus strengthening a service approach that does not differentiate between traditionally goose-dominant logic [16].

Furthermore, the formal description can be transferred into a corresponding database. This would enable an integration of our service system model with existing Enterprise Systems and applications. Similarly, the SSG approach would also greatly benefit from a set of computer-aided tools to model a service system based on our concept. Such a tool would greatly benefit from an interface to other databases.

Future SSG research should also consider focusing on manufacturing [13] and operations applications. SSG enables us to cross the divide of process and structural models, with the latter often including bill of materials [14]. Since both approaches are based on simple graphs, a hypergraph based SSG enables the combination of both, whereas future research could focus on projections from SSG, which could be used to map the relation of traditional process or structural graphs to a SSG [2].

To sum up, the paper presents the foundation of a hypergraph-based service system graph, which can be used to model service systems both formally, as well as graphically. Our concept grounds the concepts of a service systems using hypergraph theory and helps to demarcate the distinction between service systems and service ecosystems [12]. Finally, future research could also include applying SSG into real-world scenarios and the limitation of our service system conceptualization through additional specifications.