Modular Def PSS DETC 20120217

1 Copyright © 2012 by ASME
Proceedings of the ASME 2012 International Design Engineering Technical Conferences & Computers and Information in Engineering Conference IDETC/CIE 2012 August 12-15, 2012, Chicago, IL, USA
DETC2012-70911
DRAFT: MODULE DEFINITION FOR PRODUCT-SERVICE SYSTEMS
Katja Hölttä-Otto
Department of Mechanical Engineering
University of Massachusetts Dartmouth
North Dartmouth, MA
Katja.Holtta-Otto@umassd.edu
Victor Tang
Robust Systems and Strategy
victang@alum.mit.edu
Taunton, MA, USA
Kevin Otto
Robust Systems and Strategy
Taunton, MA, USA
Otto@Robuststrategy.com
ABSTRACT
More and more manufacturing firms are transitioning to more serviced based offerings. It has been shown that a useful integrated bundle of services through a complimentary product can be a better business model than just adding support services to a product as tactical responses to customer needs. In order for companies to be able define these integrated bundles in an efficient and systematic manner, a process is needed. In the paper we propose a new method to define modular services, ones that can be leveraged efficiently as driving entities, and which can be provided using several product offers. The service modules consist of services modularized for leveraging across several products. The method builds upon the foundations in product platform and modularity research extending it to product service systems. Further, we introduce alternative service modular platform leveraging strategies.
INTRODUCTION
An economic seismic shift has been in motion for a number of years. Economic growth of the world’s major economies is increasingly driven by services. While the per cent contribution of manufacturing is declining, services’ contribution to the world’s GDP has grown from 25% in 1992 to 63% in 2010 [1]. As a result, more and more companies are realizing that in order to increase revenues and profit, a new business model is required [2]. More often than not, corporations are turning into offering services in addition to just manufactured products. Rolls Royce, for example, is now selling flight hours instead of just engines and is doing much better than companies in similar industries that are still following the traditional manufacturing focused model [3]. Caterpillar’s services include financing, which contributed $350M in after tax profits during 2011, a 14% increase Y-Y. It also provides Logistics Services for supply-chain solutions that service 20M SKU’s a year [40]. Caterpillar offers complex service solutions, e.g. Computer Aided Earth Moving Systems, Fleet Management Solutions, and a wide range of maintenance and repair services. Mexico’s $15B cement company, Cemex, launched their "Patrimonio Hoy" initiative to provide financing, and consulting services for first-time low income clients. They found that they could tap into the $1.2B Mexican workers remit to their home country for building. These services have accelerated the demand for Cemex’s products and services [41].
FIGURE 1 ROLLS-ROYCE’S INCREASING REVENUE FROM SERVICES [4]

IBM known for its technology hardware products, now reports that 58% of its 2011 revenues of $99.9B are from services [5]. Others that have similar strategies, they include Apple, GE, TomTom, HP [6] Alston, ABB, Tales [7], Elcoteq [8]. These companies are learning that they have to expand their value proposition. In addition to product excellence, which provided the historical basis for customer value, this value base was grounded on the dominant logic of price mechanism in process of value-in-exchange. However, as early as 1776, Adam Smith recognized the importance of value-in-use. That is to say customer value is not only established in the physical embodiment, but also in its usage [9]. Namely, the benefits are also derived from the products’ use in the customer environment. This fact has now being rediscovered. As products become increasingly technology and knowledge intensive, the economic value of how a product is put to use, efficiently and productively present the customer with irresistible economic and business opportunities [10]. The engineers that conceived and designed the products are most knowledgeable and skilled on the product’s proper use, its maintenance, and optimal performance in a wide variety of customer environments. And although customers know their specific environment intimately, in general they do not have the skills that engineers have cumulatively acquired through years of customer exposure in diverse usage environments. Companies are learning that this means product-service offerings.
While the transition over to service based strategy is lucrative on its own, the field is still relatively young and more research is needed to fully be able benefit from this new approach. For example, traditional manufacturing industry has largely adopted the used of product modularity and module based platforms to offer larger variety in a more efficient and cost effective manner than offering individually designed projects. The idea of modularity and platforms is migrating into the service industry as well [6-7, 11-12], but what is missing the joint consideration of product and service in module selection in a design that integrates both product and service elements. Specifically there is a need for practical tools to help manufacturers in modularizing the service design [6], to define a repeatable set of service processes that can scale over several product offers. This paper aims to start filling that gap by presenting a design method to define service modules for product service platform development.
BACKGROUND
Modularity in services is a fresh challenging subject for engineers because there are fundamental differences between product and services. Whereas products are physical, therefore, tangible; services are intangible. Services embodied in processes. These processes become real only when they are produced and delivered to a customer. These two activities appear simultaneously to the customer, i.e. production and delivery are simultaneous. These service properties, intangibility and simultaneity, make it impossible for services to be inventoried [13]. However, because services are embodied in processes, they can be studied, described and taught to people to act in a service situation. This means that process is not only the “what functionality”, but also how” to apply and when. Service processes, like products systems, have intended functionality determined by its designer. Engineers know how to decompose functions into more elementary functions and how to develop structures organize configure them into coherent structures that produce intended functionality [10]. This engineering skill can be put to work in the design of services.
Design of services jointly with a set of product offers has been approached from different areas and thus there is no one agreed upon widely used term to use for a corporate offering that consists of both a service and a related product. In this paper we call them product-service systems (PSS). This term originated from Scandinavia, but has gained wide popularity [6][14]. In the US term service-system is used in the same connotation (e.g. [15-16].) Product-service systems, as opposed to traditional product focused systems, consist of the product itself, the service to be provided, the corresponding organization, as well the customer using product and being provided with services. Unlike pure products, which are physical embodiments, services are intangible. They are embodiments of social-technical processes which generate value by using products [10].
Typically, a company evolves from a manufacturing company to a product service by increasing the level of integration its products and services step by step. For example, Shelton [5] describes these steps as follows: product only, service as needed, full-line service provider and finally integrated solutions provider. For example, in case of Xerox Corporation, they initially sold printers and then maintenance services for the printers as needed. Recently they moved to more integrated services by charging per document rather than actually selling the printer, and now Xerox offers integrated document management and other solutions, such as packages for higher education. In each instance, we note the importance of the usage PSS but at increased level of integration [17].
There has been some recent research on methods of how to design product-service systems. For example, work on how remote diagnostics or in-service information can improve service design has been explored [16][18]. The focus on services also requires a new approach to requirements engineering [19]. Geng et al [20] developed an approach to better define requirement during conceptual design. To support the product service design process, models have been created to represent the PSS systems [21-22].
Product modularity and use of modules to create modular product platform is a widely adopted practice in manufacturing industry. A module is a reusable chunk of product. It often its own sub-assembly and has a clearly identifiable function. A module is often used as in multiple products. Modular design has multiple benefits from increased economies of scale to ability to offer a larger product variety than with non-modular design [23-25]. The service industry can also benefit from

modularity in a similar manner and thus there is increasing amount of research into how to define service modules and service platforms [7, 26-30]. For example, Voss and Hsuan [29] transformed a previous product modularity metric into a measure of the level of service modularity. In general, in context of services, a module is reusable set of process steps that can be reused in different service situations [7]. In summary, it has been recognized that modularity is beneficial in both products and services, but what is missing the joint consideration or both products and services for PSS modularity.
DEFINING MODULES FOR PRODUCT SERVICE SYSTEMS
We will model our approach after the Dahmus et al’s [31] approach to modular product architecture for manufactured products. More specifically we will adapt their modularity matrix to product-service systems. In this paper, we will focus on redesigning and streamlining an existing service offering and plan for future ones, rather than starting a product-service system design from scratch.
Figure 2 details the steps in proposed process. Each of these steps is described in detail below.
FIGURE 2 STEPS IN THE PROPOSED PROCESS TO DEFINE MODULES FOR A PRODUCT-SERVICE SYSTEM
Identify and define the product families offered by the company
In this first step, the existing products and families are identified and or defined, depending on if the company has a well designed product family or not. If the line is not well defined, we recommend that this process step follow some of the common methods such as described by Simpson et al [32]. The goal is to identify the roadmap of current and planned set of products offered by the company. These are candidates to be bundled into a product service system module. This is illustrated by the columns of the matrices in Figures 3 and 4, for example.
Identify the service functions offered by the company
The second step is to identify the current service functions offered by the company. These can be at any stage of product’s life cycle including but not limited to value enhancement of the customer experiences with product operation, financing services, customer service, technical assistance, maintenance and repair, product take back or recycling. It is useful to order the services by life-cycle chronology, i.e. what a customer must first address when considering the entire repertoire of service functions. This is illustrated by the rows of Table 1, 2, and 3. Other options include organizing the services based on customer use cases or scenarios, for example, but in this paper we will focus on the life cycle chronology of the product services. The services, same as the products, could also be decomposed further into more detailed level of granularity, if relevant for a particular product.
Ensure technical and organizational symmetry between product and service offerings
As identified by Martinez et al [12], organizational issues are the greatest challenges in moving from offering manufactured products to offering product-service systems. Some of these challenges can be overcome by aligning the product and service offerings properly. We are considering the evolution of a manufacturing company to one where integrated products and services become its focus. This entails developing new dynamic capabilities, i.e. the ability to acquire and configure skills to address new situations for competitive advantage [33]. The key capabilities are not only engineering, but service production and delivery skills for specific customer situations. Generic product-services exist, such as automatic cash dispensing, but every bank will want the ATM’s and their use to be specific to its needs competitively serve their end- users. It is important not to overlook the challenging engineering capabilities required even for this relatively simple product service. The ATM has to dispense printed currency with very high reliability to the general public. This customer set is not technology savvy. The artifact and the service actions have to consistently aligned the provider’s capabilities, as well as, the customers’ needs. The set of capabilities for product and service actions are the first alignment that needs to be considered. This is consistent with the starting point of this article, i.e. we base our discussion on existing product families, segments, and modularity capabilities to expand product- services. The second alignment, to consider, is cost. costs to include services must be attractive the product manufacturer, as well as, to the customers in product- service market [34]. In the next step, we will show how can
1. Identify and define the product families offered by the company
2. Identify the service functions offered by the company
3. Ensure technical and organizational symmetry between product and service offerings
4. Construct a product-service modularity matrix using existing product families and services
5. Use the product service heuristics and modularity matrix to construct different possible service modules/service platforms

leverage existing capabilities to develop new ones and thereby
effectively address costs.
Costs to the customer impact their value-in-use calculus.
Although this sounds managerial and like “bean-counting”, it is
a key overlying principle in product and system design {38}
Economic value is important. Recall that the value proposition
of a product-service system is grounded on value-in-use, an
economic formulation. This leads to the third alignment,
namely the provider of the product-service system must have
the skills to align the functional capability of the product-service
system with the benefits that the customer will derive
through the usage of the product-service system [9]. In fact, this
is the sine qua non of product service systems.
All these three alignments are challenging because the
design of the product-service modules must maintain symmetry
with the organizational structure and skills of its customers in
the market. Consider for example, a distributed printing system.
The service modules for the high volume printers, for a
company’s billing department, should be distinct from the
service modules for convenience printers. This appears to be
self evident, but this misalignment contributed to a number of
product-system failures of the BigTrad company we discuss in
our example.
Construct a product service modularity matrix using
existing product families and services
The next step is to build the product service modularity
matrix. In the similar matrix by Dahmus et al [31], their matrix
columns are the product variants and the rows are different
functions that the products have. Their idea is to identify the
functions that could and should be shared by some of the
products in the product family; and which functions are unique
to a particular product. In their example, Dahmus et al [31]
showed, for example, how to share certain power batteries
across a set of products in a family, but use a different variant
battery module for a set of other products in the same family.
Extending the logic to cover service functions, we propose a
similar matrix where the columns of the matrix are the product
offerings from step 1 and the rows are the service functions
from step 2 performed related to each product (Figure 3). We
call this the Product-Service Modularity Matrix.
To form the columns of the Product-Service Modularity
Matrix, one needs to specify the life-cycle of service-actions
that are consistent with the physical scale of the PSS. To form
the rows of the matrix, the product families are decomposed to
a level consistent with the scale of the service actions. In this
case we will look at individual products and not decompose
further, but in many cases further decomposition may be
required and desirable for modularity. This is particularly true
of highly modular systems where arbitrary collections of
modules can be configured into systems. The proposed
approach will work in these cases. If m different products and n
different service functions were identified, the result will be a
matrix of mxn cells.
FIGURE 3 PRODUCT-SERVICE MODULARITY MATRIX
Use the product service heuristics and modularity
matrix to construct different possible service
modules/service platforms
In this step, the mxn matrix is populated based on the
current state of product and service offers. This is done by
identifying a discrete service action for each product, thereby
filling in a matrix cell. For example in Figure 4, a financing
service action can be identified (by the letter X) for each of the
three products in product line 1, but not for any products in
product line 2. Similarly, in this example, the example company
is offering technical support functions for three of its current
products (Product 1A, 2A and 2B). Filling the matrix will
result in a specification for a set of service modules that the
company currently offers, and their scope over the set of
offered products.
FIGURE 4 EXAMPLE OF A PRODUCT-SERVICE
MODULARITY MATRIX.
An essential part of the defining service modules is to
decide and define what is currently offered as products and
what is needed or could be provided as new service functions,
particularly in support of the customer operations to assist them
in doing their tasks. The proposed method is designed to aid in
formulating a plan to develop service modules to extend the
current product service offering.
To use the developed matrix to plan further product-service
modules, we define here product-service modularity heuristics.
Our first set stems from the marketing and product platform
literature. In Kotler [35] and Meyer and Lehnerd’s [36]
Product 1 Product 2 Product 3
Service 1
Service 2
Service 3
Product
1A
Product
1B
Product
1C
Product
2A
Product
2B
Planning
Financing X X X
Installation X X
Operation
Maintenance X X X X X
Upgrading X X
Recycling X X
Support X X X
Product line 1 Product line 2

approach the fundamental construct is a product market matrix,
Figure 5. Without loss of generality, we can identify the rows of
Figure 5 as market segments and columns as products
segments. In Meyer and Lehnerd’s approach (Figure 5), the
product column is segmented into “low”, “medium” and “high”
performance product lines. A horizontal leveraging heuristic
describes a strategy to use the same product platform across the
different market segments but only for one type or scale of
product family. A vertical leveraging heuristic, on the other
hand, suggests sharing the platformed modules across the
different types or scales of product families, but only within a
single market segment. According to the beachhead heuristic,
the platformed modules can be shared both across market
segments and types and scales of product families.
FIGURE 5 PLATFORM LEVERAGING STRATEGIES [36]
We extend here these three product platform heuristics to
product-service systems. We argue that the leveraging
heuristics are also specialization heuristics. The designer
chooses to specialize on a specific product (high, medium, or
low). Or alternatively, chooses to vertically specialize on a
market segment. They are readily and directly extendable to the
product-service modularity analysis as shown in Figure 6. We
define the specialization heuristics for product service systems
as follows.
1) Service specialization: Using horizontal leveraging to extend
a service function from one product to another, thereby offering
new services for that second product.
2) Product specialization: Using vertical leveraging to expand
the types of services offered into new services over the product
lifecycle for one product.
3) Mixed specialization: A joint consideration of extending
product-service offering across services and products or
product modules.
Service specialization
Product specialization
Mixed specialization
FIGURE 6 SPECIALIZATION HEURISTICS FOR PRODUCT-SERVICE
SYSTEMS
In Figure 9, we show a more specific and slightly more
complex product-service matrix, where the potential service
actions are specified. Using Figure 9, potential Service modules
can be defined using the service specialization heuristic for
“financing” “maintenance”, and the combined “recycling” plus
Vertical leveraging
Horizontal leveraging
Low
Medium
High
Segm. 1 Segm. 2 Segm. 3
Low
Medium
High
Beachhead
Low
Medium
High
Service 1 X X →
Service 2
Service 3 X ↔ X
Service 1 X ↑
Service 2 X X
Service 3 ↓ X
Service 1 ↖ X X
Service 2 X X ↘
Service 3

“support“ service functions. In effect, we are specializing on
specific service functions.
In addition to leveraging a service across the entire product
family and extending product services to all services along the
product lifecycle, etc., we propose the following additional
heuristics. One is the concentration strategy whereby we focus
on selected segments. For example, in Figure 9, consider the
intersection of rows “upgrading”, “recycling”, and “support”
with columns “product line 2”. Add the “recycling capability in
Product 2B and we have created a micro-platform of services.
This micro-platform can be offered as a service module, or later
extended using any of the above three heuristics. For example,
from this micro-platform it is now possible to leverage up the
value-chain to “operations”. This is another product-service
module heuristic:
4) Micro-platform: Identify and complete a cluster of
similar product service offerings to form a micro-platform.
The micro-platform heuristic is illustrated in a more
general form in Figure 7. The main difference between the
mixed specialization and micro-platform heuristic is the size,
breadth and focus of the product-service module. The micro-platform
module, as the name indicates, defines a significantly
smaller subset of the potential service modules as a module,
and it is comprehensive within its scope.
FIGURE 7 MICRO-PLATFORM HEURISTIC FOR
PRODUCT-SERVICE SYSTEMS
On the other hand using the previous heuristics, it is
possible to extend the micro-platform across products
(horizontal leveraging), to grow a product offering to cover
more services along the lifecycle of the services functions for
the product family or product modules (vertical leveraging).
Generalizing the mixed specialization heuristic we assert that
use of carefully selected combination of the alternatives ways
to grow the PSS offering could be used as shown in Figure 9.
In this way we can define service variants in a product family.
Similarly using the horizontal leveraging strategy, the company
could extend the financing services to cover all the product
variants in product line 2. Similarly the company could extend
its current recycling and technical support functions to all of its
products using the same heuristic. Overall, the company would
plan to offer financing, maintenance and technical support and
recycling service bundles across all its product lines. In
addition to those three modules, the example company is using
the second heuristic to offer a full service package of all service
functions for product line two. Following heuristic 2, the
company could grow the product service offering for product
line 2 to cover the services currently not offered Figure 9.
In addition to the four newly introduced heuristics to help
populate the PSS matrix to form service modules, we also
observe a company could also grow the matrix itself to offer
either additional products or service functions not yet covered
by the matrix. This can be formulated into the last two service
module heuristics:
5) White space service: Expand a service module bundle to a
new service that to company does not yet offer (add a row in
the matrix)
6) White space product: Expand a service module bundle to a
new product that to company does not yet offer (add a column
in the matrix)
White space service
White space product
FIGURE 8 WHITE SPACE HEURISTICS FOR PRODUCT-SERVICE
SYSTEMS
In practice the white space service heuristic equates to
adding a row in the PSS matrix (Figure 8 top). Following the
proposed life cycle chronology in defining the new potential
services, a company could map the customers’ interaction with
the product over the life cycle of the product, and identify a gap
in the sequence of services currently offered, and listed in the
PSS matrix. For example, observing customers save data on
external drives or emailing files between colleagues could
indicate a need for a web based data storage and sharing
service.
Analogous to the white space service heuristic, the white
space product service heuristic equates to adding a new column
to the PSS matrix (Figure 8). This heuristic aims to fill in the
space identified in the product offering by self and potentially
competitors’ offerings to better fulfill customer needs. Perhaps
Service 1 X ↗
Service 2 X X
Service 3
Service 1 X
Service 2 X X
New service ↓ ↓
Product 1 Product 2
New
product
Service 1 X X →
Service 2
Service 3 X →

a company has previously worked with business to products but now wishes to leverage that product-service expertise in consumer products.
FIGURE 9 EXAMPLE OF THE SPECIALIZATION AND MICRO-PLATFORM HEURISTICS FOR PRODUCT-SERVICE SYSTEMS
TABLE 1 SERVICE MODULE HEURISTICS Service Module Heuristics
Service specialization
Using horizontal leveraging to extend a service function from one product or product module to another.
Product specialization
Using vertical leveraging to expand the types of services offered over the lifecycle of the product for one or product module.
Mixed specialization
A joint consideration of extending product-service offering across services and products.
Micro-platform
Identify a cluster of individual product service offerings and fill it to form a micro-platform.
White space service
Expand a service module bundle to a new service that to company does not yet offer
White space product
Expand a service module to a new product that to company does not yet offer
From the customer point of view, a full matrix may be ideal. Ideally the customer could get service in all areas and for all products. However, from the practical company point of view this is not possible or practical. These are the situations where capability and cost alignment needs to be thoughtfully considered. Analogous to the case of manufactured products, offering all products and services in areas is not possible because lack of resources. Both money and skills limit the extent to which the company can widen their PSS offerings, i.e. filling the entire matrix. If money is not an issue, there are two main means to close the skills gap: training personnel or acquiring companies. The latter is a much faster approach than the former. However, there can be other problems related to merging the newly acquired company culture with new parent company culture. In practice a often builds up the service skills bottom up in matrix. Most companies start with technical support and other late life cycle services and gradually build up to other services. All six proposed heuristics are summarized in Table 1.
We will next illustrate the use of proposed product- service module definition through an example.
EXAMPLE
This example illustrates how a PSS can be created in the IT space (Figure 10). This example is based on actual work implemented in an IT company and it has been shown to be effective both as a services design approach, well new
business creation.
We first list BigTrad’s current product offerings and list them as columns. The columns represent the physically manufactured artifacts from BigTrad. In every PSS design, it is important to determine the unit of analysis for the physical modules. In this example, given the scale and scope of IT space, the granularity is set by the products from BigTrad’s product families. In contrast, due to different scales, the modular components for a car company are likely to be radiators, transmissions, engines, and so on. The organization of the columns is determined by what is most logical based on the situation under which this process is implemented.
Next in step two, we identify the repertoire of service offerings currently offered by the company. The rows represent the service actions the provider will or can perform using a given module or collection of modules. Judicious application of the service heuristics is required. During this step, it is also important to clearly determine the value and price of service actions.
The third step of aligning the organization is a critical consideration. Two fundamental properties of any service are simultaneity and perishability [10]. Simultaneity means that production and delivery of services occurs simultaneously at the place of delivery. It follows that it is impossible to put a service in a box and have it shipped to a customer. Perishability is the corollary property that a service cannot exist as in a physical product. A physical product can be manufactured and put in a warehouse. But it is impossible to inventory a service. However, the capacity to provide a service can be “inventoried”, such as networks of ATMs. But they are useless if they remain unused. No service exists without usage. Next it is fundamental to understand that production and delivery of a PSS is co-created by the provider and client [39]. Co-creation means that the provider and the client bring different, but complementary, factors of production to the development of a solution. A moment of reflection will show its validity for the simplest service, such as a haircut, as well as, for the most complex product service, such as building a smart city or multinational financial clearing system. Value co-creation
Product 1AProduct 1BProduct 1CProduct 2AProduct 2BPlanning↑↑ FinancingXXX InstallationXXOperation↕↕ MaintenanceXXXXXUpgradingXXRecyclingXX SupportXXXProduct line 2Product line 1

between two parties with distinct utility functions has a most
stringent temporal constraint. Value co-creation must be done in
taktchronicity [10]. This is a defining quality of services. A
waiter’s inordinate delay in presenting the food, which has been
ordered, is the provider’s failure to maintain takchronicity. A
customer’s tardy implementation of change management
procedures to ensure system reliability is a client’s failure to
maintain taktchronicity. In both cases, the service has failed.
Work speed of the provider and client may vary vastly, but the
cadence must maintain a mutually satisfactory equilibrium
between the needs of the provider and client. This is especially
important when new and important knowledge emerges that
change requirements, cost, or schedules. Tacktchronicity is the
cadence at which streams of co-development/production
maintain the equilibrium of provider-client reciprocal
satisfaction. The PSS design must therefore ensure technical
and organizational symmetry between the client and provider in
order for tacktchronous value co-creation to remain in balance.
Next, in step four, we populate the cells of the modularity
matrix with binary indicators, an X for having a capability and
blank for the case that no capability exists. In Figure 10, the
module extension plans are illustrated by arrows, same as in the
previous examples. Every cell that is populated represents a
service module that exists. The last step of the proposed process
is to define the service modules. By judicious integration of
these existing modules, PSS platforms can be defined and used
to create new services opportunities. The heuristics of
specialization, micro-platform, and white space apply.
We illustrate the approach using a few examples. For
example, BigTrad has a foundation from which to build a new
strong IT Consulting Business by extending the module rows of
IT Architecture (row 4) and IT Consulting (row 3) upwards to
include the rows of Industry Sector Consulting (row 2) and
Business Strategy Consulting (rows 1). These are the examples
of use of heuristic for vertical of leveraging, i.e. product
specialization. Using horizontal leveraging, i.e. the service
specialization heuristic, BigTrad could offer the above services
for also other products. To accomplish this, BigTrad will have
to develop or acquire the modules which it does not have, i.e.
the empty cells, so that rows 1, 2, 3, and 4 are completely
populated. Depending on resources, capabilities, and
competitive urgency, BigTrad may choose to ignore the
modules for Mobile Devices, non-IT peripherals as low priority.
Of course, this is a bold move from a strong base of IT
Architecture and IT Consulting repertoire of modules. Another
bold initiative into services can be the creation of a Product
Maintenance Service by integrating rows 8, 9, 10, and 11 in an
analogous way as discussed for Consulting.
Another example of leveraging is the creation of a IT
Systems Planning Service. This can be accomplished by putting
the modules (3,1), (3.2), (4,1), (4,2),(4.3) and developing new
module (3.3). This can be considered a sub-assembly of a PSS.
This strategy has created a new micro-platform for BigTrad.
Similarly a Cloud Computing Service can be built by
integrating the columns 1 (large systems), with column 9
(wireless) and column 14 (DB). Developing or acquiring
capabilities for specific wireless services, it is possible to create
Service modular components. For example, combing the
capabilities of Problem determination (row 8), Maintenance
and Fix (row 9) and Asset Management (row 11) for Wireless
(column 9), and in addition for Maintenance and Fix for LAN
(column 7) and WAN (column 7) completes the specification
of a Subsystem Maintenance Module.
Note that adjacent cells, which do not have an X, represent
large systems
midrange
PC
Mobile devices
IT
Non-IT
LAN
WAN
wireless
servers
IT peripherals
Non-IT
peripherals
networking
DB
1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 Business strategy consulting ↑ ↑ ↑ ↑ ↔ ↑ ↑ ↔ ↑ ↑ ↑ ↑
2 Industry sector consulting X ↑ ↑ X ↔ ↑ ↑ ↔ ↑ ↑ ↑ ↑
3 IT consulting X X ↑ X ↔ X X ↔ X X X X
4 IT architecture X X X X ↔ X X ↔ X X X X
5 Application development
6 Project management X X X X X X X X
7 Help desk X
8 Problem determination X X ↑ X X X ↑ X X X X
9 Maintenance & fix X X ↑ X ↕ ↕ ↑ X X X X
10 Install, move, upgrades X X X X X X ↑ X X X X
11 Asset management X X X X X X X X X X X
Servers Peripherals Network Operating system-software
FIGURE 10 EXAMPLE OF A PRODUCT-SERVICE MODULARITY MATRIX FOR BIGTRAD

white spaces for BigTrad. For example, column 12, non-IT peripherals, although it is a white space, not in alignment with the IT capabilities of BigTrad. To avoid cost, BigTrad has decided to forgo the technical and business opportunity that this white space presents. BigTrad’s overriding consideration was its inability to advise the customer on either technical or usage issues. In effect, it could deliver sufficient value-in-use. BigTrad’s executive management can be said to have thoughtfully considered the alignment issues
Row 5, application development is an entire white space. Should BigTrad consider investing in skills and delivery capabilities for all the products identified in columns 1 through 14, BigTrad would be adding a complete new product-service line to its repertoire. Wisely, BigTrad avoided this move. The investments to develop the skills satisfy very complex industry sectors such as finance, health, medical, and others would have been prohibitive.
We note that stepwise refinement of this approach by reducing the scale of selected rows and columns; one can specify much more granular service modules. These can then be viewed as components for service modules.
Example of an IBM PSS
This IBM PSS is embodied as an expert system for designing an enterprise computer network [37]. The modules for this PSS are a mix of server hardware platforms, work stations, terminals, PCs, applications, data bases, user interfaces, and the like. The system is a “means for displaying questions and receiving responsive decisions of whether an application executing in said system is distributed, resource centric or front ended and using said application decisions to determine whether to place components of application logic on said back end model, said fronted model or said intermediate server, it any” [37; 35]. The system is comprised of legacy modules, as well as, and hospitable to new industry standard compatible modules when they become available in the market.
Using Figure 10 for context, the modules are IBM products located in the row 4 (cells excluding columns 4, 6, 9, and 12), but with an additional column 15 specified as “applications”. The idea of this PSS is to produce a modular design using these parts. Otto and Wood [13] describe two types, among others, of platform portfolio architecture. One is the “modular product generations” and the other is “the standard platform”. The former, is “defined as the architecture for product offerings that share the same modular components over time” [13; 309]. The other is the “standard platform”, “where a subset of a product system in a portfolio of products is a platform that conforms to an industry-agreed standard”. This PSS is consistent with these ideas. The PSS shares modular components over time, which conforms to a number of industry standards. For example, the devices used can be an IBM 3270 terminal (a de facto industry standard), AT ASCII terminal, XT terminal, or a PC type work station. The databases can be relational, IBM IMS hierarchical, indexed files, or byte string files; all of which are industry standard.
The main goal of the PSS design process is to minimize the number of server platforms and consolidated data bases used in the final result. Following Shledetsky’s descriptions [37], the following five steps describe the design process:
1. Describe the “backend” data bases. Backend refers to data bases and server hardware platforms on which they reside. Most frequently these resources are in geographically remote locations but shared by large communities of users.
2. Decide if multiple staged databases can be merged into a single staged data base.
3. Describe the “front end”, the collection of end-user devices, their grouping into local clusters, and the style of user-interface desired. Frontend refers to components such as workstations, terminals, and servers which are local and shared by a single user or cluster of users.
4. Decide if intermediate server function can be assigned to an existing “back end”.
5. Decide best way to connect each back end to the front end attach point.
Given the number of parts, size and geographic span IT systems, the combinatorial complexity of potential design is large and potentially intractable. To reduce this complexity, the PSS considers eight “reference network designs”. These “network reference design are the most viable and advantageous combinations of components and interconnections in view of cost, performance, communications bandwidth, and other practical concerns” [37; 4-5]. The reference designs are: Non-distributed, Remote Presentation, Staged Data, Resource Centric, Front Ending, Distributed Logic, Process Driven, and Multi-Application. Due to space limitations, we limit our descriptions of these reference designs to three that are located at different points in the complexity spectrum. From simpler to more complex, they are: Remote Presentation, Data Staging, and Distributed Logic. We note that this PSS is the result of “white space product” and “white space service” heuristics. This service is new to IBM and the industry. In the following, we will note how some of other heuristics are applied.
Remote Presentation is the reference design where the components from column 15, 13, 11, 10, 8, 7, 5, and 3 have been coherently put together to produce a modular design. The front end consists of a user device with the capability processing presentation data streams produced by applications on the backend systems. The protocol between frontend and the backend systems is remote presentation protocol, such as X- Windows. This is an example of the Service Specialization Heuristic that extends the presentation capability from backend to the frontend. This is also a micro-platform since other frontends that have consistent standards can be used in the future.
Data Staging is the reference design where data is staged between data bases on the frontend and backend. Frontend database can be viewed as a data cache and called “staged data base”. Staged may flow in either direction between the two data bases. The term “staged protocol” is used to refer to the variety of data transfer protocols that may be used.

This design uses components from column 15, 13, 11, 10, 8, 7, 5, 1, 2, and 3. This is an example of the Service Specialization Heuristic that extends the data base staging capability between the backend and frontend. Since staged data protocol can be used across devices, this is also a micro platform.
Distributed Logic is the analog of Distributed Data reference design. Distributed Logic is the reference design where the application logic is split between frontend and backend systems and for communications between the two, a “program-to- program” protocol is used. Examples of program-to-program protocols include remote procedure call, and message queuing.
Although we do not have confirmatory information, it is reasonable to suppose that IBM using the “mixed specialization heuristic” will leverage this PSS into row 3 of Figure 10 and thereby create a consulting offering. IBM can likewise use the “mixed specialization heuristic” to leverage this PSS row 6 of Figure 10 to assist customers to manage projects that use this PSS to extend the utility of legacy systems while upgrading standards compatible hardware in their IT systems.
We note that IBM leveraged its diverse hardware product line, systems capabilities, and the service heuristics to develop a service that is hospitable to new compatible products, as well as, flexible to specialization using the “mixed heuristic”.
CONCLUSIONS
Modern companies need to define integrated bundles of products and services in an efficient and systematic manner, and to do this processes are needed. However, the design and development of product-service systems is a new and challenging domain that integrates products and services into integrated customer offerings. It seeks to produce and deliver a new value-proposition that combines physical products and processes. It assembles tangibles and intangibles into coherent systems. As a contribution to this domain, we introduced practical methods to help define service modules for product- service systems. Specifically, we introduced a five step process to guide the product-service module definition with two key elements, a Product-Service Modularity Matrix and a set of six Product-Service Modularity Heuristics. We find the Product- Service Modularity Matrix useful to help visualize the potential Service module options. The six PSS heuristics can be used to develop a management strategy and development plan of new services and or new products. Use of the heuristics helps focus the efforts.
The results of this work present effective options for expanding service offers. The added offers proposals developed here are opportunities with low incremental costs and with pre-existing channels and customer acceptance. Each of these added service modules are ultimately business opportunities, requiring business case analysis to determine worth. Nonetheless, use of the approach will lead to more effective insights and suggestions for product service offers.
REFERENCES
[1] World Bank. [Online] Cited: February 10, 2012.] data.worldbank.org.
[2] Anonymous, 2011, “The Next Frontier in Innovation: Service Innovation,” Research Technology Management, March-April pp. 60-61.
[3] A tale of two industries. The Economist. July 30, 2011.
[4] Rolls-Royce - Britain's lonely high-flier. The Economist. June 8, 2009.
[5] IBM Annual Report. [Online] Cited: April 12, 2012] http://www.ibm.com/annualreport/2011/
[6] Shelton, R., 2009, “Integrating product and service innovation,” Research Technology Management. May- June, pp. 38-44.
[7] Baines, T.S., Lightfoot, H.W. , Benedettini, O., Kay, J.M., 2009, “The servitization of manufacturing: A review literature and reflection on future challenges, “Journal of Manufacturing Technology Management, 20(5), pp. 547 – 567.
[8] Bask, A., Lipponen, M., Rajahonka, Tinnilä, M., 2010, “The concept of modularity: diffusion from manufacturing to service production,” Journal of Manufacturing Technology, 21(3), pp. 355-375.
[9] Otto, K N., Tang, V. and Seering, W. P. Establishing Quantitative Value for Product and Service Features: A Method for Customer Case Studies. The PDMA Toolbook for New Product Development. New York, NY : John Wiley & Sons, 2004.
[10] Tang, V. & Zhou R. Y., 2009, “First Principles for Product- Service Systems,” International Conference On Engineering Design, ICED'09 24 - 27 August 2009, Stanford, CA.
[11] Meyer, M. H., Jekowsky, E. and Crane, F. G. 1, 2007, “Applying platform design to improve the integration of patient services across the continuum of care,”Managing Service Quality, 17(1), pp. 23-40.
[12] Martinez, V., Bastl, M., Kingston, J., Evans, S., 2010, “Challenges in transforming manufacturing organizations into product-service providers,” Journal of Manufacturing Technology Management, 21(4), pp. 449-469.
[13] Otto, K. and Wood, , 2001, Product Design: Techniques in Reverse Engineering, Systematic Design, and New Product Development. Prentice-Hall, New York, NY.
[14] Baines, T. S., Lightfoot, H., Steve, E., Neely, A., Greenough, R., Peppard, J., Roy, R., Shehab, E. Braganza, A., Tiwari, A., Alcock, J., Angus, J., Bastl, M., Cousens, A., Irving, P., Johnson, M., Kingston, J., Lockett, H., Martinez, V., Michele, P., Tranfield, D., Walton, I., & Wilson, H., 2007, “State-of-the-art in product-service systems,“ IMechE Proc. 221 Part B: J. Engineering Manufacture.
[15] Pinhanez, C. and Watson, T. J., 2008, “Service Systems as Customer-Intensive Systems and its Implications for Service Science and Engineering,” 41st Hawaii International Conference on System Sciences.

[16] Yang, X., Moore, P.R. Wong, C.B., Pu, J., “2009, “A practical methodology for realizing product service systems for consumer products, Computers & Industrial Engineering, 56(1), pp. 224-235.
[17] [Online] Cited: February 10, 2012.] http://www.consulting.xerox.com..
[18] McSorley, G., Huet, G. and Fortin, C., 2010, “In-service information for aeroengine designers: A survey,” ASME International Design Engineering Technical Conferences, Montreal, QC, Canada. Paper number: DETC2010-28988.
[19] Berkovich, M., Leimeister, J. M. and Krcmar, H., 2009. “Suitability of product development methods for hybrid products as bundles of classic products, software, and service elements,” ASME International Design Engineering Technical Conferences, San Diego, CA . Paper number: DETC2009-86939.
[20] Geng, X., Chu, X., Xue, D., & Zhang, Z., 2010, “Prioritizing engineering characteristics of product-service system using analytic network process and data envelopment analysis,” ASME International Design Engineering Technical Conferences, Montreal, QC, Canada : Paper number: DETC2010-28382.
[21] Kim, Y.S., Lee, S. W., Maeng, J. Cho, C. K., 2010, “Product-serivce systems design process based on activites and functions.,” ASME International Design Engineering Technical Confereces, Montreal, QC, Canada. Paper nuimber: DETC 2010-29025 .
[22] Kim, Y. S., Lee, S. W. and Koh, D.C, 2011, “Product- Service systems representation with product and service elements and a case study,” ASME International Design Engineering Technical conferences, Washington, D.C, Paper number: DETC2011-48779.
[23] Gershenson, J. K., Prasad, G. and Zhang, Y., 2003, Product Modularity: Definitions and benefits. J. Eng. Design, 14(3), pp. 295-313.
[24] Simpson, T. W. Marion, de Weck, O. Hölttä-Otto, K. Kokkolaras, M. & Shooter, S. B. 2006, “Platform-Based Design and Development: Current Trends and Needs in Industry,”: ASME International design engineering technical conferecnes, Philadephia PA
[25] Hölttä-Otto, K. and de Weck, O., 2007, “Degree of modularity in engineering systems and products with technical and business constraints,” Concurrent Engineering: Research and Applications, 15(2), pp. 113- 126.
[26] Li, J.H., 2004, “Strategy of Mass Customization-based Service Product Innovation,” IEEE International Engineering Management Conference, 3, pp. 939 - 943.
[27] Jinghua, L. & Yan, L., 2006, “Cross-fields Study of Modularity,” IEEE International Conference on Management of Innovation and Technology. pp. 595 - 599.
[28] Pekkarinen, S. and Ulkuniemi, P., 2008, “Modularity in developing, business services by platform approach,” The International Journal of Logistics Management, 19(1), pp. 84-103.
[29] Voss, C.A. & Hsuan, J., 2009, “Service Architecture and Modularity, “Decision Sciences, 40(3).
[30] Zhou, Z., Lin, Y., Ma, S., Yue, F., 2010, “Modularity of service design for IT company,” IEEE International Conference on Service Operations and Logistics Informatics (SOLI). pp. 136 - 141.
[31] Dahmus, J. B., Gonzalez-Zugasti, J. P. & Otto, K. N., 2001, “Modular product architecture,” Design Studies, 22(5), pp. 409-424.
[32] Simpson, T. W., Siddique, Z. and Jiao, J., 2006, Product platform and product family design: methods applications. Springer.
[33] Teece, D., Pisano, G. and Shuen, A., 1997, “Capabilities and Strategic Management,” Strategic Management Journal, 18(7), pp. 509-533.
[34] Coase, Ronald H., 1937, “The Nature of the Firm”, Economica, 4(16), pp. 386–405.
[35] Kotler, P. and Keller, K. L., 2009, Marketing Management, Prentice Hall.
[36] Meyer, M H and Lehnerd, A P., 2000, “The power of product platforms,” The Free Press, New York, NY.
[37]Schedletsky, J. 1996. “Expert system for designing computer networks”. US Utility Patent No. 5557775.
[38]Pahl, G. and W. Beitz. 1996. Engineering Design. Springer. London.
[39]Vargo, S L and R F Lusch. 2008. “Service-dominant logic: continuing the evolution”. Journal of the Academy Marketing Science, 36: 1-10.
[40] [on line] [Cited: Apil 12, 2012]
http://logistics.cat.com/cda/files/1328963/7/Cat_Logistics_Fact_Sheet_2011+_updated+March+2011_+KAR.pdf
[41] on line] [Cited: Apil 12, 2012]
http://businesstoday.intoday.in/story/innovation- cemex/1/20184.html

Modular Def PSS DETC 20120217

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Modular Def PSS DETC 20120217

Similar to Modular Def PSS DETC 20120217 (20)

More from victor tang

More from victor tang (13)

Modular Def PSS DETC 20120217