Descriptive Service Product Architecture for Communication Service Provider. Oliver Budde1, Julius Golovatchev2. 1 Institute for Industrial Management (FIR), ...
Descriptive Service Product Architecture for Communication Service Provider 1
Oliver Budde , Julius Golovatchev 1
2
Institute for Industrial Management (FIR), RWTH Aachen, Aachen, Germany 2
Detecon International GmbH, Bonn, Germany
Abstract The product structure plays a major role in the PLM as an integral design element for coping with product complexity. As a prerequisite for enabling product structuring, a descriptive model of the product is needed, a product model. Product models for the service industry have been subject for scientific examination nowadays, but so far a general and practical definition, as for tangible goods, is still missing. This paper proposes a general product architecture for services in the telecommunication industry by reflecting on existing work from the manufacturing industry. These theoretical findings have been evaluated by an international study to provide indications for its adequacy. . Keywords: Product Architecture; Telecommunication Industry; Product Lifecycle Management
1 MOTIVATION The manufacturing industry has anticipated the benefits of product models for a long time now for coping with complexity problems [1]. Although there are still some problems unsolved, like information consistency of product models across the whole product lifecycle, IT-systems support and corresponding processes have been established in the industry for a while now. Due to the high popularity of product models in the manufacturing industry it stands for a reason to transfer the idea of product modularity to services. In the following paragraphs we will propose the cornerstones of a product model for product and service systems for ccommunication service provider (CSP). The need for product models here is similar to the manufacturing industry: coping with product complexity. In order to derive such a model from pre-existing work e.g. from the manufacturing and service industry, we need to define the special characteristics of this industry first. Thereby we define the subject of matter, the product in network industry, on a descriptive basis. Building on that the specific layers of a product model can be identified and distinct design elements can be extracted. As a final step in this paper these design elements have been examined in an international study regarding their implementation degree. Based on these empirical findings we derive the usefulness of our model. 2 DEFINITION OF THE SERVICE PRODUCT Before proposing a product model for the network industry, the main characteristics that determine the product model needs to be described. For our purpose we suggest the following four characteristics that apply for CSP products. Network effect Network industries, like the Communication Service Industry, are characterized by the existence of direct or indirect network effects that have specific requirements concerning the adoption and diffusion of innovations in the market. Besides the original product benefit, telecommunication companies have to consider the derivative product benefit, which can be controlled by them only to a limited extent [2].
Value Net Network industries are based on a special value configuration: the value net [3]. Typical for this value configuration is a reciprocal production technology and a system technology (the physical net), which imposes special requirements on the coordination of value adding partners involved in the product lifecycle. Service characteristics The simultaneity of production and consumption as well as the integration of the external factor are characteristics of telecommunication products. This involves the need to describe CSP products in 3 dimensions: potential, process and resource [4]. Immateriality A further characteristic of the telecommunication industry is the immateriality of the product. This leads to specific product characteristics: simple mutability, reproducibility and first-copy-effects. In contrast to physical goods and services, high fixed and low variable costs of production and sales are combined. New business models with zero marginal costs are possible only with digital goods [5]. Based on these general characteristics we have derived a detailed scheme for a further concretization of the CSP product. This definition of the product provides essential perspectives on the product that lead to consequences in the defining a corresponding product model. The following scheme compiles the classification schemes from Corsten [4] for a general product classification, from Gerpott [6] for network industries, from Stabell [3] for value configuration, from Meffert [7] for services characteristics and from Mowshowitz [8] for immateriality. According to this compiled scheme we concretize the CSP Product for the purpose of this paper. The universality of this scheme can not be scientifically proven within the given scope of this paper. This work has to be undertaken in the future.
J. Hesselbach and C. Herrmann (eds.), Functional Thinking for Value Creation: Proceedings of the 3rd CIRP International Conference on Industrial Product Service Systems, Technische Universität Braunschweig, Braunschweig, Germany, May 5th - 6th, 2011, DOI 10.1007/978-3-642-19689-8_38, © Springer-Verlag Berlin Heidelberg 2011
213
214
IPS² - Integration and Process Management partners are involved, like content providers in case of a triple play product). Additionally the need for the execution of mass service processes sets constraints on the organisation, e.g. distributed call centres, which has an impact on the process complexity in terms of establishing the same quality of service standards. IT-Complexity The business application landscape of a typical CSP is dominated by individual software, since standard software like Enterprise Resource Planning (ERP) for CSP has generally not been available. Beside this heritage of heterogeneity of the IT-Systems, a second reason for IT complexity arises through the existence of many different data sources for managing the product related data and a missing alignment between these data silos. This diversity on the IT-system level as well as on a data level is primarily responsible for the IT-Complexity, which has led to high cost for the maintenance and for the functional extension of these systems.
Figure 1: Classification scheme for a CSP product. Based on this scheme the CSP product can be characterised as network-based product service systems that focuses on the retail market. The service fulfilment depends on the existence of network intermediary providing a communication infrastructure for exchanging information between value partners and customers. The components of a network based service product will be described in paragraph 5. In the next section the challenge of complexity management will be described and linked to the subject of matter the product architecture. COMPLEXITY MANAGEMENT: AN RISING ISSUE FOR TELCOS Having brought some light into the CSP product definition, the question arises why complexity is an important issue for CSP that needs to be managed adequately. Based on the consulting experiences from several PLM implementation projects in this area, the authors have identified three fields that need to be tackled in the telecommunication industry.
4 PRODUCT ARCHITECTURE MANAGEMENT IN THE PLM For coping with these complexity issues PLM has been proven for being a valid instrument in general, and the product architecture in specific [1]. Budde et al. have motivated the integral role of the product architecture within a holistic PLM-model [9]. They propose three layers that have to be taken into consideration, when designing the product architecture (cp. Figure 3). These three general layers will be described briefly before specifying those in the context of the characteristics of CSP.
Figure 2: General design areas of a Product architecture. Product Specification and Function Structure
Description of the product from a functional perspective taking into account the specific requirements from the branch of industry, e.g. in the service industry the functional description of the product focuses on the specification from a market perspective [10].
Description of the interrelation between the function structure with the construction and working structure [11]. For the service industry this includes the specification of a process model [10].
3
Product Complexity The telecommunication product is constituted by a big variety of interdependent product components (e.g. Network access, end user device, information goods and IT services). Moreover the individual life cycle of each product component needs to be synchronised with each other. If it happens otherwise, problems may arise like in the case of the introduction of MMS, where a limited market diffusion of appropriate end user devices impedes a fast success of corresponding services. Therefore a high product complexity is a general phenomenon for CSP. Process Complexity The process complexity, as the second source of complexity, results from the fact, that in the service industry the complexity of the service processes, which can be categorized in fulfilment, assurance and billing process, increase with the number of subscribers and the variety of the product bundles. A more complex product has other requirements on the service processes than an old fashioned telephony product (e.g. the billing process is more complex, if more
Especially for the manufacturing industry there exists a distinct differentiation between the product structure and the function structure [12]. For the goal to have a generalized model being adoptable for specific industries, we integrate the product specification with the function structure in order to emphasize the differentiation between an abstract product concept and its physical representation. Product Structure from a technical perspective
Definition of the construction and working structure [11]. The construction structure includes the definition of parts structure
The specification of the interfaces among interacting physical components [13].
Product Data Information Framework (PDIF)
Information model scheme that integrates all relevant information of a product for all stakeholder in the PLM [14].
Facilitating the generation of different views on the product like design structure, purchasing structure, manufacturing structure, order management structure, spare parts structure, service structure [12].
IPS² - Integration and Process Management Based on this general structure and the main characteristics of the CSP product a descriptive Service-Product Model will be proposed in the next section. 5 DESCRIPTIVE SERVICE PRODUCT MODEL Having mentioned the importance and the popularity of Product models in the manufacturing industry, a trend in the service industry towards service modularization becomes visible as well. Thereby most of the authors try to transfer the concepts from the physical goods industry to the service industry (cf. [10]; [15]). But resulting from the extent of heterogeneity of services in general, a widely accepted descriptive model has not been evolved yet. Our classification scheme from chapter 2 points out the service characteristics of the CSP product. Against this background it becomes evident to examine the general dimensions of a service: structure, process and outcome under consideration of the CSPcharacteristics. According to [15] these dimensions have to be taken into account whenever services are to be developed. Consequently the authors suggest using distinct models for each dimension in order to describe the service product in a holistic way. In specific the authors refer to a resource, process and product model. In the next paragraphs these three models will be specialised taking the characteristics of CSP industry into account. 5.1 Product, Process and Resource-Model Product-Model According to [15] a product model describes the outcome dimension, the “what” of the service. It typically comprises a definition of the service content and a structural plan of the service products. The relevance for such a product model for CSPs results from the dynamic by which the product portfolio changes compared to other service industries (according to [16] the CSP industry belongs to the most dynamic ones). In order to anticipate the need to respond to the high market dynamic a structuring of the range of offerings helps to align the product portfolio to specific customer segments, capturing the complexity of portfolio changes, by a flexible rearrangement of product modules to new offerings. Thereby the comprehensiveness of the product description on an aggregated level as well as on a module level from a customer perspective is crucial and needs to be taken into account by product manager. Beside this functional description of the product, reflecting the original understanding of the “what”-dimension, for CSP a complementary model has to be added to cover the outcome dimension: the price model. This is in line with [11], who also concludes that the outcome dimension is not completely covered by the product model, like proposed by [15]. Within the price model the end customer prices have to be defined and specific rules for calculating the price under consideration of rebates or socio-economic aspects like age / location need to be defined and applied on the product model. Nowadays the customer of a CSP is typically confronted with a huge number of tariffs. These tariffs need to be managed separately from the product description in order to conduct changes on the product model without interfering with the tariffs and vice versa. From an operational point of view the tariff is often perceived as the “CSP Product”, which is why the number of those kinds of “products” is continuously increasing, but actually this is only a modelling shortcoming, which results into a growing catalogue of products. Process Model According to [15] the process model describes how the outcome of a service is achieved towards a customer. Therefore the process model defines explicitly activities and their execution sequence as well as the interfaces between activities [11]. Corsten distinguishes between two processes in this regard [17]. First, the service agreement phase, in which a customer orders is initiated and the configu-
215 ration of the service product is agreed upon under consideration of the customer specific settings (e.g. line capacity at the habitation). Second, the service fulfilment phase, in which the service is provided towards the customer and the service outcome, fulfils the expectation. The service agreement phase corresponds to the fulfilment process in the CSP industry according to the reference process model enhanced Telecom Operations Map (eTOM). This process needs to be designed during the product development phase and consequently implemented in the IT-systems in order to ensure a high automatisation degree for ensuring the delivery of mass processes through different sales channels (e.g. online, on-site, reseller). Simply because of the existence of different sales channel, process variants for the fulfilment process are thinkable and probably necessary. This has to be taken into account in the conception phase and later on in the PLM. The service fulfilment phase differs in the Telco industry from the general or better saying abstract service industry, due to the fact that the service delivery is automated. In comparison to e.g. a hairdresser that has to execute a manual and personal task in order to deliver the service that results into an outcome for the customer, the service delivery of a CSP is in the regular case completely automated, since it is focused on the establishment of a connection between two or more parties or by providing an IT-service to one customer. In consequence a process execution, which involves resources other than IT-systems, is not needed. Therefore we assume in this paper, that the conceptualisation and implementation of the service delivery process can be characterized as an IT development project that fits better into the Resource Model, which is defined in the next paragraph. Since the CSP product is in the most business models, at least in West-Europe, delivered on a contractual basis, a long term relationship between the customer and the service company is a prerequisite for the service delivery. This is similar to the insurance business, but different to the hair dresser example. Therefore the CSP needs to provide a service assurance process during the whole customer lifecycle in order to ensure a constant service quality and, in case of disturbance; processes are needed to resolve the customer problem (e.g. technical fault clearance). Consequently the service fulfilment process, proposed by Corsten, has to be extended by a service assurance process. Another consequence of the long term relationship can be identified in regards to the billing of a CSP product. Since the direct customer interaction is normally limited to the service agreement phase (only accidently in the case of the service assurance process), the billing process plays a major role for CSP in order to transfer the relationship into a prosperous one for both sides. CSP use the billing process, which is normally carried out every month, to interact with the customer e.g. for cross-selling purposes. Another aspect why the billing process, at least nowadays, needs to be designed, is the high error rate, which often involves a manual interaction by a customer agent, either via a call centre or an onsite shop. These processes that occur in the course of the billing need also to be considered within this process model layer of CSP product architecture. In summary three processes need to be considered in a process model for product architecture: service fulfilment process, service assurance process, and service billing process. The eTom-processmodel provides valuable information about the process design. Resource-Model According to [15] the resource model describes the outcome of the product development that is necessary for the provisioning of a service. In the resource model the resources have to be described
216
IPS² - Integration and Process Management
that are consumed in the “production”-process for the provisioning of the services. In the context of the CSP product multiple resources are needed for the provisioning of the service. Obviously the foundation of the service provisioning is the communication network, as a material resource. In order to establish and use communication services user equipment is needed like mobile devices. According to [4] these resources can be classified as merchandise goods, since their production is mostly not in the scope of Telco Companies, but specialised companies like customer-premises-equipment-providers e.g. Nokia. These devices consume ICT-services on the network and have to be provided either by the network operator or by third parties. In the context of the convergence trend other resources need to be considered. Most importantly this refers to multimedia content, that can also be generated and provided by the network operator or, more often, by third parties like for movies or ring tones. In order to ensure the service assurance, service processes are required like on-site installation services e.g. for WiFi installations. Weber defines another resource in the context of complex product bundles, the legally protected interest good [18]. In case of CSPs this refers to accommodations and warranties. Since the service quality is a critical success factor, CSP have to guarantee response times for service inquiries and are willing to provide accommodations like anytime minutes for compensating faults on the network or errors in the billing process. In the following table the resources and their classification according to [4] have been listed with a corresponding symbol being used in figure 4.
Figure 4: Product Architecture for CSP without the PDIF. settings as well as the information about the purchased product itself need to be managed side by side in a product data management system. Therefore we distinguish between the product architecture, as a conceptual description of the product features, and the product inventory, that links the product with a specific customer and its individual settings. The second requirement deals with the definition of the stakeholders for a product model, which differs e.g. from the manufacturing industry, which focuses on production, assembly and sales [20]. For CSP different perspectives of the product including the product inventory are needed. We distinguish between the following four perspectives: 1. Technical Product Development
Figure 3: Classification of resources of the CSP-Product. Figure 4 illustrates the three layers of the product architecture and their interrelations. 5.2 Product Data Information Framework (PDIF) The product data information framework manages all product related data consistently across the product lifecycle and offers different perspectives on the product depending on the user’s role. Product data information frameworks are widely known in the manufacturing industry and have been the subject of special ITsolutions: Product Data Management Systems (PDMS). For the service industry general frameworks are not that common. Instead special product data models have been elaborated like e.g. for the insurance sector [19]. An overview for product data model for services is given in [10]. For CSP two distinct requirements need to be considered. The first requirement is about the differentiation between the product concept and its instantiation for a specific customer. A product, described in the aforementioned dimensions, is instantiated by the customer in the moment of the first use, not by the purchase of the product in contrast to the manufacturing industry [2]. This instantiation is characterised by the configuration of the external factor (the customer) e.g. by the installation of the WiFi and the integration of different devices like PC or TV. That is why the specific instantiation
From a product development perspective the elements of the product and the structure including the relationships between the elements in the three dimensions need to be available. The product development of a CSP focuses from a technical point of view on the network resources and specific ICT-services. In some cases the network resources have been outsourced to a third party like with Bharti Telecom in India. But in general the development and at least the maintenance of the network stays with the network operator. For modelling the different resources the industry association TM Forum has published a reference information framework (SID), which provides valuable guidelines and models for the specification of the resources. 2. Sales From a sales perspective the range of the product offerings needs to be defined and the sales process for specific products needs to be determined. Regarding the range of the offerings, the sales needs to define the components of a product bundle as well as the price. In terms of the sales process, this includes the selection of the appropriate sales channels as well as the determination of customer segments, which are addressed by a specific product bundle. These information need to be managed, so that a rather automatic service fulfilment can be enabled (e.g. by releasing a new product from the sales perspective, the product should be consistently available in all sales channels offline or online). Similar to the perspective of the technical product development, the SID standard provides guidelines and models, which are subsumed under the customer facing specification 3. Billing The billing is crucial for CSP and currently one the biggest fields of concern in this industry due to problems with the increasing number and variety of billing events. This is one reason why the topic of revenue assurance is at present very popular in this industry (see Google Trends results on revenue assurance). From our under-
IPS² - Integration and Process Management standing, this relates to an insufficient modelling of the product from a billing perspective. Within this perspective the pricing terms and conditions that have been determined from a sales perspective needs to controlled and monitored throughout the customer lifecycle. Resulting from quite complex billing schemes (e.g. a price is dependent on the time, habitation and the number of optional products) the monitoring and controlling tasks put major requirements on subsequent IT-systems. Since these systems are predominately legacy systems, which have been laid out for much simpler billing schemes, dating back from a monopoly market, these requirements can not be fulfilled, which results into hot fixes and workarounds, that cause the problems in the revenue assurance. 4. Customer Care From a customer care perspective a complete view on the product and the customer is needed in order to resolve a problem efficiently and effectively. The granularity of the information required differs from the service concept. In case that a CSP has installed a first and second level support, the second level support needs to have detailed information on the technical resources like network capacity, number of open ports on a DSLAM (Digital Subscriber Line Access Multiplexer). The first level support needs access to the product configuration and customer data like account details. These four perspectives need to be integrated and operate on the same product data, so that a consistent view on the product and the customer is provided. Currently major CSPs are struggling to fulfil this rather simplistic sounding requirement. In the following figure the four perspectives on the product architecture have been illustrated. In this figure the product inventory as a complementary element for managing the customer configuration and the link with the product has been included.
217 conference sessions. The average duration of the interview did last approximately 2hrs, whereby the relevant product architecture part amounts to ca. 25% of the whole interview. For details regarding the research methods please refer to the study document, which can be downloaded from Detecon´s corporate website. Through this empirical investigation we wanted to explore the implementation degree of the proposed product architecture concept. Based on our theoretical findings we derived indicators that have been evaluated through a factor analysis. Since the study addressed mostly product managers, we did not explore in detail the implementation of the product inventory, since its configuration and implementation could have been answered presumably only by the IT-department. In the next section four factors will be presented. The implementation degree for each factor and its associated indicators will be presented for three complexity groups that have been identified through a cluster analysis. 6.2 Empirical findings The empirical findings are graphically represented in a radar chart. Each spoke within the chart represents a design element that has been statistically validated. The data length of a spoke ranges from 0 to 100%, whereby 0% represents the lowest value and 100% represents the highest factor value found in the sample. A data point refers to the average implementation degree of one group for a given design element.
Figure 6: Radar chart.
Figure 5: Complete Product Architecture including PDIF. In the next paragraph the results from an international PLM study regarding the product architecture of CSP will be presented. 6
VALIDATION
6.1 Empirical study Between May 2009 and October 2009 FIR and Detecon conducted an international study about the Status Quo of PLM in the Communication Service Provider Industry. The goal of this study was to explore PLM design elements in the first place and secondly to identify interdependencies between the implementation degree of the PLM design elements and a PLM target achievement. As a moderating variable the external complexity level was chosen, which has been measured according to [21]. The classification label “Global Elephants” describes a high complexity level, whereas “Emerging Zebras” represents less complex companies. The questionnaire of this study included a dedicated section for the design elements of product architecture and only this section has been evaluated for the purpose of this paper. In this study 47 CSP worldwide have been interviewed either on-site or through web-
From the radar chart it can be concluded that even companies facing a high external complexity (termed as Global Elephants) have an average implementation degree just above 60% for the three dimensions of the product architecture. Regarding the ability to provide different perspectives on the product, it can be stated, that the implementation is considerably low, even with the highest complexity group. Considering the implementation degree of the specific indicators for the factor Product Model, it is interesting to notice, that especially the ability to provide cross strategic business unit (SBU) bundles has a comparatively low implementation degree.
Figure 7: Product Model. In terms of the fulfilment, assurance and billing (FAB) processes the indicators reflect the consideration of process modularity in the service fulfilment, service assurance and service billing processes.
218
IPS² - Integration and Process Management
The empirical findings show that there is a considerable gap between the different complexity groups, but still the average implementation of the highest complexity group reaches only almost 60%.
Figure 8: Process Model. In regards to the Resource model three indicators could be confirmed with the factor analysis. From a modelling perspective the existence of a production view has an average implementation degree in most complex group of 70%. The biggest shortcomings have been identified in considerably low specification communality in the product design. This indicates that for new products the specifications will be reworked again, although for some aspects like the network, the specification can possibly be reused, since the lifecycle of these product elements are rather long.
Figure 9: Resource Model. Regarding the implementation of different perspectives on the product, the provisioning of one invoice from the billing perspective achieves the highest implementation degree among the three indicators shown in figure 10. Especially the less complex companies indicate that their average implementation degree for each indicator is below 50%.
[2]
Weiber, R. (1995): Systemgüter und klassische Diffusionstheorie - Elemente einer Diffusionstheorie für kritische MasseSysteme. In: Stoetzer (Editor.): Die Diffusion von Innovationen in der TK. Berlin: Springer, p. 39–66.
[3]
Stabell, C. B.; Fjeldstad, O. D. (1998): Configuring value for competitive advantage: on chains, shops, and networks. In: Strategic Management Journal 19 (5), p. 413–437.
[4]
Corsten, H.; Gössinger, R. (2007): Dienstleistungsmanagement. 5., vollst. überarb. U. ext. Edition. München: Oldenbourg.
[5]
Anderson, C. (2008): The long tail. Why the future of business is selling less of more. Rev. and updated. New York:
[6]
Gerpott, T. (2005): Unternehmenskooperationen in der Telekommunikationswirtschaft. In: Zentes,J. (Editor.): Kooperationen, Allianzen und Netzwerke. Grundlagen - Ansätze - Perspektiven. 2., Edition.: Gabler, p. 1205–1230.
[7]
Meffert, H. (1994): Marktorientierte Führung von Dienstleistungsunternehmen–neuere Entwicklungen in Theorie und Praxis, Die Betriebswirtschaft, 54. In: Die Betriebswirtschaft 54 (4), p. 519–541.
[8]
Mowshowitz, A. (1992): On the market value of information commodities. I. The nature of information and information commodities. In: Journal of the American Society for Information Science 43 (3), p. 225–232.
[9]
Budde, O.; Schuh, G.; Uam, J-Y (2010): Holistic PLM Proceedings of International Conference on Product Lifecycle Management, Bremen Germany.
[10] Mörschel, I. C. (2005): Produktmodelle für Dienstleistungen. Mögichkeiten zur Strukturierung und Beschreibung von Dienstleistungen. In: DIN (Editor.): Wege zu erfolgreichen Dienstleistungen. 1. Edition. Berlin: Beuth, p. 46–115. [11] Pahl, G.; Beitz, W.; Blessing, L.; Feldhusen, J.; Grote, K.-H.; Wallace, K. (2007): Engineering Design. A Systematic Approach. Third Edition. London: Springer London Limited [12] Svensson, D.; Malmqvist, J. (2002): Strategies for product structure management at manufacturing firms. In: Journal of Computing and Information Science in Engineering 2, p. 50. [13] Ulrich, K. (1995): The role of product architecture in the manufacturing firm. In: Research policy 24 (3), p. 419–440. [14] Grabowski, H.; Anderl, R.; Polly, A.; Warnecke, H. J. (1993): Integriertes Produktmodell: Beuth.
Figure 10: Different perspectives on the product. 7 DISCUSSION AND OUTLOOK As the results from the empirical study indicate, the implementation degree of specific aspects of product architecture for CSP remains relatively low. But from the interviews with decision makers of CSPs in the context of our study, it was clearly indicated that the benefits of modular product architecture in the understanding of this paper are feasible. The biggest obstacles towards such modular product architecture seem to be the high IT-complexity with diverse data sources and diverse data schemes. Coping with the IT-complexity by eliminating old legacy systems and executing data harmonization projects, seems to be from our perspective a good start to a modular future. Due to similarities between the telecommunication and the utility sector, our findings might be applicable for upcoming products in the area of smart metering and e-mobility. Future research activities have to explore the adaptability in this direction. 8 REFERENCES [1] Schuh, G.; Assmus, D.; Zancul, E. (2006): Product structuring - the core discipline of product lifecycle management. In: Proceeding 13th CIRP International Conference.
[15] Bullinger, H.-J.; Fähnrich, K.-P.; Meiren, T. (2003): Service engineering--methodical development of new service products. Structuring and Planning Operations. In: Inter. Journal of Production Economics 85 (3), p. 275–287. [16] Schläffer, C.; Arnold, H. (2007): Media and network innovation. technological paths, customer needs and business logic. In: e & i Elektrotechnik und Informations-technik 124 (10), p. 317– 322. [17] Corsten, H.; Gössinger, R. (2003): Gestaltungsdimensionen von Dienstleistungen: Lehrstuhl für Produktionswirtschaft. [18] Weber, R. (2005): Leistungsbündel als Angebotsform für konsumentengerichtete Technologiegüter-Konzept. [19] Schönsleben, P.; Leuzinger, R. (1996): Innovative Gestaltung von Versicherungsprodukten. Flexible Industriekonzepte in der Assekuranz. Wiesbaden: Gabler. [20] Rapp, T. (1999): Produktstrukturierung. Komplexitätsmanagement durch modulare Produktstrukturen und -plattformen. Wiesbaden: Gabler [u.a.] [21] Budde, O.; Golovatchev, J.; Taner, S.: Evaluating Product Complexity in Network Industries. Lugano (ICE 2010 The 16th International Conference on Concurrent Enterprising).
