Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Part IV. Case Studies

Chapter 21. Configuring Services and Processes

Juha Tiihonen^a, Wolfgang Mayer^b, Markus Stumptner^b and Mikko Heiskala^a, ^aAalto University, Aalto, Finland, ^bUniversity of South Australia, Adelaide, SA, Australia

Abstract

Many modern product offerings are bundles of physical and service elements. The mass-customization by configuration approach is applicable to services, but may require extensions to traditional configuration techniques. The service production process is more intimately involved with the customer and his/her environment, which may need to be modeled to effectively manage service configuration and delivery. Configurable processes can be imperative for flexible development and provisioning of services. This chapter summarizes differences between sales configuration of services and that of physical goods, and gives an overview of techniques for process configuration.

Keywords

Knowledge-based Configuration; Service Configuration; Process Configuration; Configurable Process Model; Service Variability

Acknowledgments

We thank Technology Development Centre of Finland (projects WeCoTin, ConSerWe, and Cosmos), related companies, and Aalto University Service Factory for financial support.

21.1 Introduction

The focus of economic activity in industrialized countries is moving from goods production to service provision. The service sector represented in 2005 about 70% of aggregate production and employment in OECD economies, and further growth was expected. Products increasingly become commodities, and services, whether on their own or as parts of integrated solutions to customers, are growing in importance.

Unfortunately, there is no single consistently used definition of services. Grönroos (2000) “reluctantly” proposes that “A service is a process consisting of a series of more or less intangible activities that normally, but not necessarily always, take place in interactions between the customer and service employees and/or physical resources or goods and/or systems of the service provider, which are provided as solutions to customer problems.”Services are often characterized with the following IHIP attributes(Grönroos, 2000): intangibility, heterogeneity, simultaneity of production and consumption (inseparability), and perishability. Furthermore, customer participation in service production process differentiates services from goods and causes different management challenges.

Why Service and Process Configuration. The motivation for service configuration is similar to that for physical products—it can potentially provide an adequate balance of fit to customer needs and benefits of standardization. However, due to the IHIP characteristics and process nature of services, the results of research on mass customization of goods (see e.g., Piller and Blazek, 2014¹) may not be directly applicable. Moreover, combined product-service systems or value bundles have increasingly been offered to customers (Becker et al., 2009; Queva, 2011). These consist of physical goods, service elements, and software; all these elements may be configurable. Service configuration can also be an essential support mechanism for service providers and resellers (Felfernig et al., 2007). Configuration systems enable customer representatives to quote suitable offerings more quickly and with fewer errors, while drawing from a large pool of available service components that may be outside of their expertise. This in turn decreases time-to-market and facilitates dissemination of product knowledge. Resellers of service bundles can benefit from identification of cross-selling opportunities, recommendation of related offerings, and automatic reporting. Configuration systems can cater for a wider user audience by adapting presentation and interaction style based on user preferences (e.g. self-service becomes feasible). Moreover, configuration can also extend to entire supply chains where the underlying processes and IT systems are configured flexibly. Service delivery processes can be customized to individual service contracts, and generic development processes can be tailored to individual projects. Configuration technologies help eliminating unnecessary tasks and errors arising from missed dependencies between tasks and controlling the evolution of processes over time.

21.2 Sales Configuration of Services

21.2.1 Variation of Services and Differences from Physical Products

According to our experiences, providers of configurable services may offer variations of:What is in the scope of the service? What optional and alternative service elements are included? When are service or some elements provided? For example, problem solving starts within 2, 4, or 8 hours. Is weekend service delivery included? With what? Who? How? Human, physical, and software resources provide service, such as qualifications of personnel, characteristics and type of physical elements, and the delivery process itself; for example, repairs with original or third party spares, or how reporting, billing, and payment take place. To Whom? Properties of the service recipient can significantly affect availability of the service, service delivery, and pricing. For example, all-inclusive maintenance contracts may not be available for old equipment. Where? Is a service element delivered at the premises of the service provider, the customer, or remotely? Similarly as in the context of physical products, service delivery based on sales specification is often a separate process that can be subject to further detail level configuration.

Main differences from modeling variability of physical products include:

• Model stakeholders and environment. Service cases often require modeling the customer and other stakeholders, related equipment, environment, and their properties in order to verify that services, service elements, and specific parameter values are available and can be priced.

• Model service process and resources. Explicit modeling of service delivery processes and resources clarifies the customer’s role, helps manage expectations, and may increase trust.

• Price calculation. Services based on a contract may require several prices due to initiation, periodic and pay-per-use price elements. Estimates on total cost of customership may be necessary.

• Straightforward “internal technical compatibility” of the services is often given, as rules governing combination of service elements are often less strict than those for goods. However, constraints related to stakeholders and environment are relevant.

During long-term relationships, the need for service reconfiguration arises from changes in customer needs, equipment, and environment. Service reconfiguration may be easier than reconfiguration of goods because the primary target of configuration is not a physical product individual. Therefore, inaccuracies of as-maintained configurations and condition of physical elements are not as relevant. Maximal use of old components may not be necessary, and reconfiguration instead of project-based modernization may be possible more often. When service offerings are changed, it may be possible to mass-update (map) old configurations to corresponding new ones.

21.2.2 Example: Elevator Maintenance Contracts

Figure 21.1 illustrates configurable maintenance contracts for elevators. Contract types are Basic, Silver, and Gold, offering guaranteed availability of 95%, 99%, and 99.5%, respectively. The Guaranteed_response_time can be 2, 4, or 8 hours. In case of a corrective maintenance call, the goal is to dispatch a technician (Internal_response_time) within 30, 60, or 120 minutes for Gold, Silver, and Basic, respectively. The sum of Internal_response_time and Travel_time to the site must not exceed the guaranteed corrective maintenance response time: . Availability of Gold contracts is limited to sites where all elevators of the site have Condition_class good: .

FIGURE 21.1 Elevator Maintenance contract configuration model.

For Basic contracts, work and spare parts are charged separately, Gold includes both, and Silver is configurable. Furthermore, the customer may specify an Approval_limit: if charges of spare parts and work exceed the Approval_limit, prior approval is acquired. Finally, Silver and Gold contracts include provisioning of Assisting_workforce for officials that perform periodic safety inspections, but Basic customers are responsible themselves.

21.2.3 Technologies for Service Configuration

A comprehensive view of the issues in modeling configurable services can be obtained from Akkermans et al. (2004), Becker et al. (2009), and Heiskala et al. (2006). Akkermans et al. (2004) and Heiskala et al. (2006) define conceptualizations specifically aimed toward service configuration. Both argue that it is important to model customer needs, the service offering, and the processes required to provide the different elements of the offering. Heiskala et al. (2006) also posit that modeling the recipient of the service, often the customer, and the environment are important as these can affect what is available in the offering or how the service should be carried out.

Anderson (2005) concludes that sales configuration of most configurable services can be handled with traditional configurators. However, the scope of modeling is broader, as relevant stakeholders, equipment, or environment must be included to verify the availability, and to determine pricing.

Knowledge-based configuration technologies have recently been combined with user modeling techniques and recommendation systems in order to aid the elicitation of decision criteria and preferences from users (Falkner et al., 2011). With growing complexity of service bundles and options, guidance mechanisms to explain (in)feasibility of certain offerings have become important, especially when users unfamiliar with the underlying technologies, business rules, and regulations must be accommodated.

Apart from modeling conceptualizations, we are aware of few specific technologies for core sales configuration of services. However, domain-specific extensions for services exist in major enterprise software suites, for example to manage telecommunications services.

21.2.4 Achievements and Cases

Commonalities between service sales configuration cases we witnessed include customers who were committed through contracts that were configured. The service providers exhibited characteristics of systems firms identified by Salter and Tether (2006) as typically large and based on detailed division of labor, sophisticated operating routines, and a heavy dependence on technologies, typically on information and communications technology, and sometimes logistics. Examples include banking, insurance, telecommunications, supermarkets, and airlines. Such companies potentially benefit significantly from service configuration due to the high volumes of potentially complex services in their offerings. Service delivery based on modular elements enables efficient processes with moderately skilled employees and relatively low provider discretion.

Our example cases included broadband and mobile subscriptions, elevator maintenance contracts, and insurance. The subscriptions were managed in large quantities with the configurator module and telecommunications extensions of a major enterprise software system. Automated provisioning, installed base management, and reconfiguration were supported and among central business requirements for the system. Large volumes and desire to enable customers to configure their subscriptions necessitated a configurator.

Intelligent sales configuration in the financial industries has led to significant improvements in several key performance indicators, such as quality of solution, time to quotation, and maintenance effort (Felfernig et al., 2007).

21.3 Process Configuration

21.3.1 What Is Process Configuration?

Provision of configurable products and services is most effective if configuration is extended from the features of products and services to the supporting business processes. Effective delivery of configurable services requires equally configurable development and delivery processes in order to streamline business processes and manage the stakeholders’ expectations.

In this context, process configuration can be described as the act of transforming a given process model into one that is specifically tailored to a given set of requirements. The input process model will often be a generic reference model that governs a wide range of activities, which must be configured to suit a given scenario. Typically, configuration involves selecting the tasks, subprocesses, and execution paths that should be retained in the custom process and eliminating others while maintaining the integrity of the overall process. Customization may be applied incrementally resulting in a sequence of process models of varying scope and detail.

In general, it is not enough to restrict attention to task selection and ordering. Several perspectives are considered equally important: The control perspective focuses primarily on the tasks and the parallelism, sequencing, and synchronization of tasks permitted in a process. The decision tasks and their associated conditions selecting between alternative execution paths are included here. The resource perspective embodies available resources and business rules governing the assignment of resources to tasks. Explicit models of roles, privileges, and organizational structure form the basis of this perspective. The data perspective captures the representation and utilization of business objects and data in the process. It is needed to ensure all information required to support both human and automated tasks in a process is available at appropriate times.

A configurable process model embodies the possible variation points and relationships between choices and elements in the reference model in order to ensure that the customization results in a correct process model. In general, not all parts of a process are allowed to change, and relationships between process elements within and across perspectives can further restrict the available choices. It enables users to perform configuration without manipulating the underlying process models directly. Furthermore, configuration models also facilitate verification of process variants with respect to a reference process and business process compliance requirements (Mayer et al., 2011).

We can distinguish configuration from adaptation of process models. Configuration refers to customizing a reference process to reflect the needs of an organization, and adaptation refers to the subsequent addition of organization-specific detail that is not reflected in the reference process (Becker et al., 2007). Some extensible process configuration models cover aspects of both (Becker et al., 2007; Mayer et al., 2011; Rosa et al., 2011).

21.3.2 Technologies for Process Configuration

Most established process modeling notations provide no systematic approaches for managing variations within families of related processes nor decision support for configuration (Rosemann and van der Aalst, 2007).

Configuration systems can address these challenges but require modifications to account for difficulties arising from processes. Process configuration systems must provide extensible models in order to be able to capture the processes, entities, and constraints specific to an organization or a project scenario. Thus, the scope of configuration is wider than a single product family, and structure of the processes, supporting models, and constraints may not be known in full when the system is developed. Moreover, constraints refer to properties of execution paths in instances of (sub-)processes rather than the static process structure. Input and configured processes may both be incomplete, and reconfiguration of partially executed processes may be required. Configuration of processes can affect the (data) dependencies between tasks. Users are often domain experts without expertise in building and maintaining formal models. Capturing the user’s processes, requirements, and constraints intuitively is key to the success of process configuration applications.

Process configuration frameworks can be broadly classified in approaches that obtain a customized process by projecting from a given reference process and approaches that employ sophisticated search procedures to build up a process that conforms to given constraints. The former are most appropriate when customizing imperative process specifications with tight control (Pesic et al., 2010), whereas the latter techniques facilitate concise specification and compliance verification of loosely constrained processes.

Reference Process Configuration. The Configurable Event Process Chains (C-EPCs) framework by Rosemann and van der Aalst (2007) introduces configurable entities within a reference process comprised of tasks and control connectors. Configurable tasks can be either retained or skipped, whereas configurable control connectors can be assigned a variety of control functions. Relationships between configurable elements are represented as constraints restricting the possible choices. The C-iEPC model (Rosa et al., 2011) unifies control, resource, and data perspectives in a single model. The C-YAWL (Gottschalk and La Rosa, 2010) workflow modeling framework embodies a questionnaire to determine domain facts, which in turn determine the elements and available paths in the resulting process model.

Reference processes capture common process variations but do not reflect all organization-specific detail. Extensible meta-models have been proposed that unify configuration and adaptation by enabling organizations to customize and extend reference processes and configuration models (Becker et al., 2007; Mayer et al., 2011; Rosa et al., 2011).

Declarative Process Constraints. Constraint-based process configuration techniques rely on specifications of process properties. Constraints specify what must (not) hold in any valid customized process. Pesic et al. (2010) present a model using linear temporal logic as constraint specification language and a method for synthesizing conforming workflows from partial executions. Mayer et al. (2011) discuss a hybrid approach, where a reference process is tailored to project-specific requirements using dynamic constraint satisfaction techniques and an extensible process and resource model.

Composition and configuration of computational processes from individual Web Services has also been addressed using various automated planning (Baryannis and Plexousakis, 2011) and dynamic constraint satisfaction (Thiagarajan et al., 2009) techniques. These methods rely on comprehensive formal specification of process components and goals.

21.3.3 Example

Let us revisit the elevator example and examine how process configuration can support customized service delivery. Figure 21.2 depicts a (simplified) reference process of our elevator service provider. It comprises six tasks (), a decision gateway (), and two guarded flows (). However, not all tasks are relevant for all contracts: billing depends on the contract type and options, and approval of work exceeding a preset limit (tasks and ) is optional and does not apply to Gold contracts.

FIGURE 21.2 Maintenance reference process.

The possible process variants can be captured in a configuration model like the one shown in Figure 21.3. The variables Type, Approval_Limit, Spares_included, and Repair_work_included correspond to the service options set in the contract. We write to denote that task shall be skipped, and to denote that flow shall be blocked. Tasks that are not skipped by some rule are retained in the customized process. Once skipped tasks and blocked flows have been determined, additional tasks and flows may be removed to eliminate unreachable tasks and unnecessary gateways.

FIGURE 21.3 Elevator maintenance process configuration model.

Let us assume that the process is to be configured for a Gold contract. The configuration model entails that , and ; hence tasks , and are skipped. Task , its outgoing flows, and the Rejected end state are removed, as they are unreachable if is blocked. Gateway is also skipped because it degenerates to a simple sequence. The resulting process comprises the task sequence .

21.3.4 Achievements and Cases

Process configuration has been successful in several large projects. Gottschalk and La Rosa (2010) describe a case study from the Film industry using a process of several hundred tasks and a questionnaire model with 53 questions and 162 facts. Mayer et al. (2011)describe configuration and validation of a large software and hardware development process that comprised several thousand elements. Their model revealed more than 130 errors in manually created adaptations and eliminated unnecessary tasks from configured processes. Gottschalk et al. (2009) applied process configuration in Dutch municipalities and conclude that configuration of control aspects is beneficial but should include other perspectives as well.

21.4 Conclusion

Service and process configuration technology can deliver significant benefits for providers and their customers, in particular in the services sector, where a variety of services from different providers can be bundled together over extended periods of time. Configuration technologies have extended from purely technical compatibility to the customers’ environment and maintenance of long-term customer relationships. Configuration systems have themselves become configurable in order to accommodate customers’ preferences, where models of technical systems and product features have been complemented with adaptive user and dialog models. Extensible configuration frameworks have been devised in order to capture, configure, and validate process aspects related to service development and provisioning.

Bridging the gap between the often informal use of product and process models in organizations and the formal precision required for automated configuration however remains challenging, as is supporting domain experts in the development of extensible configuration models from (abstract) domain concepts. Current methods and commercial systems for developing and validating configuration models are mostly focused on relatively static feature models or require expert knowledge in formal methods. Acquisition, testing, and validation of configuration models for processes, recommender systems, and reconfiguration mechanisms require further research in order to become applicable in mainstream configuration systems.

References

1. Akkermans H, Baida Z, Gordijn J, Peña N, Altuna A, Laresgoiti I. Value webs: using ontologies to bundle real-world services. IEEE Intelligent Systems. 2004;19(4):57–66.

2. Anderson, A., 2005. Towards tool-supported configuration of services. Master’s thesis, Helsinki University of Technology, Department of Computer Science and Engineering, Espoo, Finland.

3. Baryannis, G., Plexousakis, D., October 2011. Automated web service composition: state of the art and research challenges. Tech. Rep. ICS-FORTH/TR-409, Institute of Computer Science, Foundation for Research and Technology – Hellas.

4. Becker J, Delfmann P, Knackstedt R. Adaptive reference modeling: integrating configurative and generic adaptation techniques for information models. In: Becker J, Delfmann P, eds. Proceedings of the Reference Modeling Conference (RM’06). Heidelberg: Physica Verlag; 2007:27–58.

5. Becker J, Beverungen D, Knackstedt R, Matzner M. Configurative service engineering – a rule-based configuration approach for versatile service processes in corrective maintenance. In: Proceedings of the 42nd Hawaii International Conference on System Sciences, Big Island, HI. 2009:1–10.

6. Falkner A, Felfernig A, Haag A. Recommendation technologies for configurable products. AI Magazine. 2011;32(3):99–108.

7. Felfernig A, Isak K, Kreutler G, Kruggel T, Teppan E. Knowledge representations for the interactive selling of financial services. Information Systems and e-Business Management. 2007;5(2):143–166.

8. Gottschalk F, La Rosa M. Modern business process automation: YAWL and its support environment. In: Hofstede AHM, Aalst WMP, Adams M, Russell N, eds. Modern Business Process Automation. Berlin, Heidelberg: Springer; 2010:459–487. (Chapter: Process configuration in YAWL).

9. Gottschalk F, Wagemakers TAC, Jansen-Vullers MH, van der Aalst WMP, Rosa ML. Configurable process models: experiences from a municipality case study. In: van Eck P, Gordijn J, Wieringa R, eds. Advanced Information Systems Engineering, 21st International Conference, CAiSE 2009. Amsterdam, The Netherlands: Springer; 2009;486–500. Lecture Notes in Computer Science vol. 5565.

10. Grönroos C. Service Management and Marketing: A Customer Relationship Management Approach. Chichester: John Wiley & Sons, Ltd.; 2000.

11. Heiskala M, Tiihonen J, Anderson A, Soininen T. Four-worlds model for configurable services. June 22–23 In: Blecker T, Friedrich G, Hvam L, Edwards K, eds. Customer Interaction and Customer Integration Proceedings of the Joint Conference IMCM’06 & PETO’06, Hamburg/Germany. 2006:199–216.

12. Mayer W, Stumptner M, Killisperger P, Grossmann G. A declarative framework for work process configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM). 2011;25(2):143–162.

13. Pesic M, Schonenberg H, Aalst W. Declarative workflow. In: Hofstede AHM, Aalst WMP, Adams M, Russell N, eds. Modern Business Process Automation. Berlin, Heidelberg: Springer; 2010:175–201.

14. Piller FT, Blazek P. Core capabilities of sustainable mass customization. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:107–120. (Chapter 9).

15. Queva, M., 2011. A framework for constraint-programming based configuration. Ph.D. thesis, Technical University of Denmark, Informatics.

16. Rosa ML, Dumas M, ter Hofstede AHM, Mendling J. Configurable multi-perspective business process models. Information Systems. 2011;36(2):313–340.

17. Rosemann M, van der Aalst WMP. A configurable reference modelling language. Information Systems. 2007;32(1):1–23.

18. Salter, A., Tether, B.S., 2006. Innovation in services – through the looking glass of innovation studies. Background paper for Advanced Institute of Management (AIM) Research’s Grand Challenge on Service Science.

19. Thiagarajan RK, Mayer W, Stumptner M. A generative framework for service process composition. In: Service-Oriented Computing, Seventh International Joint Conference, (ICSOC-ServiceWave 2009). Stockholm, Sweden: Springer; 2009;358–363. Lecture Notes in Computer Science vol. 5900.