Tailoring Process System Engineering Handbook PDF

8 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING Standards and handbooks address life cycle models and systems engineering (SE) processes that may or may not fully apply to a given organization and/or project. Most are accompanied by a recommendation to adapt them to the situation at hand...

8 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING Standards and handbooks address life cycle models and systems engineering (SE) processes that may or may not fully apply to a given organization and/or project. Most are accompanied by a recommendation to adapt them to the situation at hand. The principle behind tailoring is to ensure that the process meets the needs of the project while being scaled to the level of rigor that allows the system life cycle activities to be performed with an acceptable level of risk. Tailoring scales the rigorous application to an appropriate level based on need. The life cycle model may be tailored as described in Chapter 3. Processes may be tailored as described in this section. All processes apply to all stages, tailoring determines the process level that applies to each stage, and that level is never zero. There is always some activity in each process in each stage. Figure 8.1 is a notional graph for balancing formal process against the risk of cost and schedule overruns (Salter, 2003). Insufficient SE effort is generally accompanied by high risk. However, as illustrated in Figure 8.1, too much formal process also introduces high risk. If too much rigor or unnecessary process activities or tasks are performed, increased cost and schedule impacts will occur with little or no added value. Tailoring occurs dynamically over the system life cycle depending on risk and the situational environment and should be continually monitored and adjusted as needed. For ISO/IEC/IEEE 15288, process tailoring is the deleting or adapting the processes to satisfy particular circumstances or factors of the organization or project using the process. While ISO/IEC/IEEE 15288 tailoring focuses on the deletion of unnecessary or unwarranted process elements, it does allow for additions and modifications as well. This chapter describes the process of tailoring the life cycle models and SE processes to meet organization and project needs. Refer to ISO/IEC TR 24748‐1 (2010) and ISO/IEC TR 24748‐2 (2010) for more information on adaptation and tailoring. This chapter also describes the application of the SE processes in various product sectors and domains, for product lines, for services, for enterprises, and in very small and micro enterprises (VSMEs). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition. Edited by David D. Walden, Garry J. Roedler, Kevin J. Forsberg, R. Douglas Hamelin and Thomas M. Shortell. © 2015 John Wiley & Sons, Inc. Published 2015 by John Wiley & Sons, Inc. 162 For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. am oun t of ta iloring m co pr st od uc t/s yst em inte grit y to t h ro ep ce ss t of Cos ing rm o f per SE al m for 163 Formal systems engineering process followed a gr ro t/p jec Pro ct ss re pr oc e C or o et du ks ris No or ad hoc systems engineering applied e dul sche Cost/ Risk of schedule and cost overruns TAILORING PROCESS Degree of formal systems engineering process used on the project FIGURE 8.1 Tailoring requires balance between risk and process. INCOSE SEH original figure created by Michael Krueger, adapted from Ken Salter. Usage per the INCOSE Notices page. All other rights reserved. 8.1 TAILORING PROCESS 8.1.1 8.1.1.1 Overview Purpose As stated in ISO/IEC/IEEE 15288, [A.2.1] The purpose of the Tailoring process is to adapt the processes of [ISO/IEC/IEEE 15288] to satisfy particular circumstances or factors. 8.1.1.2 Description At the organization level, the tailoring process adapts external standards in the context of the organizational processes to meet the needs of the organization. At the project level, the tailoring process adapts organizational processes for the unique needs of the project. Figure 8.2 is the IPO diagram for the tailoring process. 8.1.1.3 Inputs/Outputs Inputs and outputs for the tailoring process are listed in Figure 8.2. Descriptions of each input and output are provided in Appendix E. 8.1.1.4 Process Activities The tailoring process includes the following activities: r Identify and record the circumstances that influence tailoring. – Identify tailoring criteria for each stage— Establish the criteria to determine the process level that applies to each stage. r Take due account of the life cycle structures recommended or mandated by standards. r Obtain input from parties affected by the tailoring decisions. – Determine process relevance to cost, schedule, and risks. – Determine process relevance to system integrity. – Determine quality of documentation needed. – Determine the extent of review, coordination, and decision methods. r Make tailoring decisions. r Select the life cycle processes that require tailoring. – Determine other changes needed for the process to meet organizational or project needs beyond the tailoring (e.g., additional outcomes, activities, or tasks). For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 164 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING Controls Inputs Organization strategic plan Life cycle models Activities Outputs Identity and record the circumstances that influence tailoring Take due account of the life cycle structures recommended or mandated by standards Obtain input from parties affected by the tailoring decisions Make tailoring decisions Select life cycle processes that require tailoring Organization tailoring strategy Project tailoring strategy Enablers FIGURE 8.2 IPO diagram for the tailoring process. INCOSE SEH original figure created by Shortell and Walden. Usage per the INCOSE Notices page. All other rights reserved. Common approaches and tips: r Eliminate unnecessary outcomes, activities, and tasks, and add additional ones. r Base decisions on facts and obtain approval from an independent authority. r Use the decision management process to assist in tailoring decisions. r Conduct tailoring at least once for each stage. r Drive the tailoring based on the environment of the system life cycle stages. r Constrain the tailoring based on agreements between organizations. r Control the extent of tailoring based on issues of compliance to stakeholder, customer, and organization policies, objectives, and legal requirements. r Influence the extent of tailoring of the agreement process activities based on the methods of procurement or intellectual property. r Remove extra activities as the level of trust builds between parties. r Identify a set of formal processes and outcomes/ activities/tasks at the end of the tailoring process. This includes but is not limited to: – A documented set of tailored processes – Identification of the system documentation required – Identified reviews – Decision methods and criteria – The analysis approach to be used r Identify the assumptions and criteria for tailoring throughout the life cycle to optimize the use of formal processes. 8.1.2 Elaboration 8.1.2.1 Organizational Tailoring When contemplating if and how to incorporate a new or updated external standard into an organization, the following should be considered (Walden, 2007): r Understand the organization. r Understand the new standard. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. TAILORING FOR SPECIFIC PRODUCT SECTOR OR DOMAIN APPLICATION r Adapt the standard to the organization (not vice versa). r Institutionalize standards compliance at the “right” level. r Allow for tailoring. 8.1.2.2 Project Tailoring Project tailoring applies specifically to the work executed through programs and projects. Factors that influence tailoring at the project level include: r Stakeholders and customers (e.g., number of stakeholders, quality of working relationships, etc.) r Project budget, schedule, and requirements r Risk tolerance r Complexity and precedence of the system Today’s systems are more often jointly developed by many different organizations. Cooperation must transcend the boundaries of any one organization. Harmony between multiple suppliers is often best maintained by agreeing to follow a set of consistent processes and standards. Consensus on a set of practices is helpful but adds complexity to the tailoring process. 8.1.2.3 Traps in Tailoring Common traps in the tailoring process include, but are not limited to, the following: 1. Reuse of a tailored baseline from another system without repeating the tailoring process 2. Using all processes and activities “just to be safe” 3. Using a preestablished tailored baseline 4. Failure to include relevant stakeholders 8.2 TAILORING FOR SPECIFIC PRODUCT SECTOR OR DOMAIN APPLICATION The discipline of SE can be applied on any size and type of system. However, that does not mean that it should be blindly applied in the same fashion on every system. While the same SE fundamentals apply, different domains require different points of emphasis in order to be successful. This section provides a starting point for people looking to apply SE in different domains. An objective of this section is to provide guidance on how to introduce the concepts of SE to a new field. As an example, the 165 audience for this guidance might be SE champions that already work in the field and want to promote SE. The domains are listed in alphabetical order and should not be considered to be exhaustive. In addition, one needs to recognize the evolving maturity of SE in these applications. The following descriptions capture the current state of the practice and may not necessarily be representative of the state of practice at the time this handbook is being read/used. 8.2.1 Automotive Systems SE has been traditionally applied with success by industries that develop and sell large complex systems, with a relatively long life cycle and small production volumes. In contrast, the automotive industry has manufactured high volumes of consumer products with a great diversity for more than 120 years, with quite a success. A highly cost‐driven industry, the automotive sector is characterized by a permanent quest for cost‐efficiency and massive reuse of parts and engineering artifacts. Modern commercial automobiles have become complex, high‐technology products in a relatively short time span. The complexity drivers usually pointed out by the actors of the industry are: r The increasing number of vehicle functionalities supported by software, electronics, and mechatronic technologies r Increasing safety constraints r Increasing environmental constraints, such as air pollution and decreasing fossil fuel stocks, leading to a partial or total electrification of the vehicle power train r Globalization and the car market growth in emerging countries, which induce greater variations in the product definition and a different repartition of worldwide production of vehicles r New trends such as “advanced mobility services,” “smart cities and smart transportation systems,” and autonomous vehicles, which induce changes in the purpose and scope of the traditional automobile product Most engineering specialties and domain specific practices involved in the automotive industry follow international For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 166 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING TABLE 8.1 Standardization‐related associations and automotive standards Organization/standard Description SAE International, formerly the Society of Automotive Engineers One of the main organizations that coordinate the development of technical standards for the automotive industry. Currently, SAE International is a globally active professional association and standards organization for engineering professionals in various industries, whose principal emphasis is placed on transport industries such as automotive, aerospace, and commercial vehicles An organization that sets automotive standards in Japan, analogous to the SAE International An incorporated association under German law whose members are primarily international car manufacturers, suppliers, and engineering service providers from the automotive industry. The ASAM standards define protocols, data models, file formats, and application programming interfaces (APIs) for the use in the development and testing of automotive electronic control units An open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers, and tool developers. Some of its key goals include the standardization of basic system functions, scalability to different vehicle and platform variants, transferability throughout the network, integration from multiple suppliers, maintainability A nonprofit consortium whose goal is to establish a globally competitive, Linux‐based operating system, middleware, and platform for the automotive in‐vehicle infotainment (IVI) industry. GENIVI specifications cover the entire product life cycle and software updates and upgrades over the vehicle’s lifetime An international standard for particular requirements for the application of ISO 9001 quality management systems for automotive production and relevant service part organizations An international standard for set of electrical connectors and charging modes for electric vehicles maintained by the International Electrotechnical Commission (IEC) Japan Society of Automotive Engineers (JSAE) Association for Standardization of Automation and Measuring Systems (ASAM) AUTomotive Open System ARchitecture (AUTOSAR) The GENIVI Alliance ISO/TS 16949 IEC 62196 standards. Some important automotive‐related standards, associations, and SE standards are shown in Table 8.1. These standards usually define characteristics, measurement procedures, or testing procedures for specific vehicle systems or specific aspects of the product and are often adapted to establish regulations by local authorities. Automotive standards are normally used for product qualification or “certification” purposes, although it should be noted that certification procedures in the automotive industry differ greatly from those applied in other sectors, like aerospace. Usually, the scope of these standards is either the product or the manufacturing process, with specific regulations ruling each vehicle system. One remarkable exception to this type of standards is the functional safety standard ISO 26262 (2011), which defines activities and work products covering a full “safety life cycle” and allowing a systematic and traceable mastery of safety risks. SE as a discipline started to develop rather recently in some automotive organizations, around the mid‐1990s or early 2000s, mainly as a response to the aforementioned challenges. While the organizations that have shown interested in SE agree that most of these challenges could be leveraged by applying a systems approach, SE is not yet a standard practice in the industry. The application of SE is not mandatory in the automotive industry to develop and sell products. The cultural and organizational changes that are required for an effective global industry‐wide implementation of SE are beginning to take place. The automotive industry is characterized by an extensive reuse of legacy engineering artifacts (requirements, architectures, validation plans) and system constituents (systems, system elements, parts) and by the management of huge product lines (at vehicle, system, and part levels), with high stakes associated to the efficient management of those product lines. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. TAILORING FOR SPECIFIC PRODUCT SECTOR OR DOMAIN APPLICATION When applying SE in the automotive industry, one should take into consideration these specificities. An adapted SE process for the automotive domain should then be an ideal combination of product‐driven and stakeholder‐/requirement‐driven approaches. The weight of the former type of approach will be more important for “classical” vehicle systems and based on typical variant management techniques (product derivation or configuring), while the relative weight of the second type of approach will be more important for innovative systems and “untraditional” vehicle scopes or usages. In particular, when implementing the SE technical processes for the first time, the importance of upstream SE activities (e.g., operational analysis and requirement elaboration) must be underlined. Ideally, these activities should take place off‐line, that is, “disconnected” from the development of the product, so that the produced SE artifacts baselines are properly defined and verified. Since the involvement of carmakers in the development the different vehicle systems differs from one car maker to the other and from one vehicle domain to the other, care should also be taken in the tailoring of agreement processes, which will depend on the particular project context. The formalization of the exchanges between the Original Equipment Manufacturer (OEM) and their providers during the lifetime of a project should help tailoring these processes and could set the groundwork for their future standardization. 8.2.2 Biomedical and Healthcare Systems SE has come to be recognized as a major contributor to biomedical and healthcare product and development, particularly due to the need for architectural soundness, requirements traceability, and subdisciplines such as safety, reliability, and human factors engineering. Biomedical and healthcare systems range from low complexity to high complexity. They also range from low risk to high risk. Many of these systems must work in harsh environments, including inside the human body. SE within the biomedical and healthcare environment may not be as mature as the defense and aerospace domain, for example, but the growing complexity of medical devices, their connectivity, and their use environment is quickly increasing the breadth and depth of the practice. Standards such as ISO 14971 (application of risk management to medical devices) and IEC 60601 (medical device safety) are driving organizations to take 167 a deeper look into safety and the engineering practices behind it. Other government standards and regulations such as the US Code of Federal Regulations (CFR) Title 21 Part 820 (medical devices/quality system regulations) shape the development process for medical devices sold therein. Thus, systems engineers are increasingly being brought on board to leverage their life cycle management skills and validate that the final product does indeed meet the needs of its stakeholders. In the biomedical and healthcare environment, it is important to understand that risk management is generally centered around user safety rather than technical or business risks and that traceability is often a key factor in regulatory audits. Organizations that have strong SE practices are therefore in a better position to avoid development pitfalls and to effectively defend their design decisions if a regulatory audit does occur. Going forward, biomedical and healthcare organizations that effectively leverage SE standards such as ISO/IEC/IEEE 15288 and ISO 29148 will be in a much better position to develop safe and effective products. In general, such standards do not need to be excessively tailored, although firms with new or maturing practices may want to focus on lean implementations in order to obtain early and effective adoption. 8.2.3 Defense and Aerospace Systems While SE has been practiced in some form from antiquity, what has now become known as the modern definition of SE has its roots in defense and aerospace systems of the twentieth century. It has been recognized as a distinct activity in the late 1950s and early 1960s as a result of the technological advances taking place that led to increasing levels of system complexity and systems integration challenges. The need for SE increased with the large‐scale introduction of digital computers and software. Defense and aerospace evolved to address systemic approaches to issues such as the widespread adaptation of COTS technologies and the use of system‐ of‐system (SoS) approaches. Defense and aerospace systems are characterized as complex technical systems with many stakeholders and compressed development timelines. The systems must also be highly available and work in extreme conditions all over the world—from deserts to rain forests and to arctic outposts. Defense and aerospace systems are also characterized by long system life cycles, so logistics is of For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 168 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING prime importance. Most defense and aerospace systems have a strong human interaction, so usability/human systems integration is critical for successful operations. Since SE has a strong heritage in defense and aerospace, much of the SE processes in this handbook can be used as is in a straightforward manner, with just the normal project tailoring for the unique aspects of the project. It is important to note that as ISO/IEC/IEEE 15288 has evolved into a more domain‐ and country‐ neutral SE standard, some care must be taken to ensure that the defense and aerospace focus is reasserted upon application. The defense organizations of many countries have specific policies, standards, and guidebooks to guide the application of SE in their environment. 8.2.4 Infrastructure Systems Infrastructure systems are significant physical structures used for commodity transfer (e.g., roads, bridges, railroads, mass transit, and electricity, water, wastewater, and oil and gas distribution) or are major industrial plants (e.g., oil and gas platforms, refineries, mines, smelters, nuclear reprocessing, water and wastewater treatment, and steelworks). The domain is multidisciplinary, vast and diverse, and characterized by large‐scale projects often with loosely defined boundaries, evolving system architectures, long implementation (which can exceed a few decades) and asset life periods, and multiphase life cycles. Infrastructure systems are distinguished from manufacturing and production by most often being one‐ off, large objects and where construction takes place on a site rather than in a factory. Infrastructure projects tend to exhibit a degree of uniqueness, complexity, and cost uncertainty. A significant proportion of time and cost is spent during the construction stage. These difficulties are exacerbated by changes in project environments (economical, political, legislative, technological, etc.) and hence to the stakeholders’ expectations and design solutions that take place over an extended period of time. Unlike other SE domains, most infrastructure projects cannot be standardized and do not involve a prototype. In addition, significant external interfaces exist, and failures in one element may cascade to other elements. For example, falling debris from the World Trade Center attack damaged the water system and flooded the New York Stock Exchange, resulting in severe impacts to an interconnected system of infrastructure systems. Within infrastructure, many of the engineering disciplines (e.g., civil, structural, mechanical, chemical, process, and electrical) have well‐established, traditional practices and are guided by industry codes and standards. SE practices are more developed in the high‐technology subsystems that involve software development (e.g., modern communications‐based train control systems, intelligent transportation systems, telemetry and process control) and particularly in industries where system safety is paramount. The benefit of SE to the infrastructure domain lies in the structured approach to delivering and operating a multidisciplinary, integrated, and configurable system and needs to align with the associated project management and asset management practices. Many of the processes described in this handbook are being employed to handle that complexity but using a different terminology. The “Guide for the Application of Systems Engineering in Large Infrastructure Projects” (INCOSE‐ TP‐2010‐007‐01, 2012) emphasizes the relationship between system, work, and organizational breakdown structures and the importance of good configuration management, not only through the project life cycle but during the whole asset lifetime. These items and the interactions between them are determined by a multitude of constraints, with the physical structure of the object and access being the most obvious but also many others, such as availability of suitable contractors and of manpower and machines, fabrication and shipping durations, and ones arising from the environment in which the construction takes place. Infrastructure projects tend to quickly define the high‐level design solution (e.g., a high‐speed railway or nuclear power plant), and therefore, the greatest benefit of applying SE principles is gained in the systems integration and construction stage. Careful analysis to identify all the potentially affected organizations, structures, systems, people, and processes is required to ensure proposed changes will not adversely impact other areas and will lead to the required outcome. The domain could benefit from better organization and integration of activities leading into the construction stage of the project life cycle. This would help manage the risks and uncertainty associated with cost estimating and changing scope and could improve construction productivity, hence making the industry more cost‐effective. SE efforts tailored to meet the uniqueness characterized by infrastructure projects control the project’s internal For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. TAILORING FOR SPECIFIC PRODUCT SECTOR OR DOMAIN APPLICATION and external dynamics (including uncertainty caused by natural events) and consider the project and postproject conditions will allow the domain to respond to the unique challenges it faces due to its broad, diverse, unique, and unpredictable makeup. The documentation of infrastructure processes is largely company and project specific, although based on general standards, such as the ISO 9000/10000 series (quality management), ISO 10845 (construction procurement), and ISO 12006 (organization of information about construction works), as well as various national and international standards for the contractual (legal) framework in which a construction project is embedded. The choice of contractual framework and the allocation of liability and commercial risk is a major factor in designing the construction process. 8.2.5 Space Systems Space systems are those systems that leave the Earth’s atmosphere or are closely associated with their support and deployment. Due to the extremely high costs and physical exertion of deploying assets into Earth orbit or beyond, space systems typically require high reliability with no maintenance other than software changes. This makes it necessary for all system elements to work the first time or be compensated by complex operational workarounds. SE was developed in large part due to the demands of the space race and associated defense technologies such as ballistic missiles. The discipline is very mature in this domain and does not require adaptation. Key emphases of SE in the space domain are validation and verification, testing, and integration of highly reliable, well‐characterized systems. Risk management is also key in determining when to incorporate new technologies and how to react to changing requirements through multiyear developments and programmatic challenges. The traditional SE Vee approach has its basis in space systems, as they are typically relatively new designs conceived, built, and deployed by agencies or prime contractors. Declining budgets are making the unity of vision less common as consortia and partnerships are made to pool resources. A large number of standards are used in the space domain. Telecommunications is a major source, since spectra and noninterference must be negotiated on a global basis. Electrical and data standards are also used 169 in many parts of both in‐space and ground support systems. National space agencies and militaries often set standards as well (e.g., the European Cooperation for Space Standardization, US “MIL” Standards). An excellent example of a space‐based SE handbook is freely available from the NASA (2007b). As space systems are deployed by more countries, standardization via ISO and IEEE is becoming more common for an increasing set of interoperability issues. 8.2.6 (Ground) Transportation Systems The use of SE has emerged as the standard approach for complex capital programs in the fields of aerospace engineering, defense, and information technology. In the transportation industry, however, the assimilation of SE principles and methods has grown more slowly. The historical orientation of most transportation agencies has been to structure capital projects by engineering disciple and adopt low‐bid procurement methods. However, in the past few decades, the use of SE in transportation has been growing, with several progressive transit agencies (including London Underground and Network Rail in the United Kingdom, ProRail in the Netherlands, New York City Transit in the United States, and the Land Transport Authority in Singapore) having established SE departments and many others beginning to embed SE principles into their capital programs. Emerging experience from these agencies suggests the following aspects are most relevant to consider when applying and tailoring SE principles to the transportation domain: r Recognize the single‐discipline tendency—the historical orientation in transportation agencies is to organize projects by engineering discipline. This can generate disciplinary silos that flow from early engineering through procurement and into system design, build, and test. SE must work across these silos, which can introduce tension to organizations used to working in the traditional way. r Working with in‐service SoS—many transportation systems are large, distributed, in‐service SoS. This means that transportation SE work is often focused on systems upgrade and must work with and around the existing operation while still maintaining appropriate levels of public service. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 170 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING r Delivering socioeconomic benefits are often the key driver, yet the operator has an important role— transportation systems primarily existing to provide socioeconomic benefits to the public. The key drivers for many transportation agencies are therefore often focused on improving customer experience and public safety. However, care should be taken to also focus on operational benefits, and operability and maintainability should be considered throughout. r Demonstrating the value of SE—many transportation agencies have a historic divide between capital delivery and operations that persists into today’s organizations. Project managers face cost and schedule pressure to deliver quickly, and this can sometimes generate opposition from those who perceive that the emphasis SE places on early‐phase analysis injects delay into the project manager’s schedule, while the benefits accrued from the analysis are felt most strongly by the operational stakeholders who are outside of the project manager’s immediate organization. r Considering the commercial and public pressures— there is increasing dependence on private investment to fund the larger transportation infrastructure projects, which increases the demand for a faster return on investment (ROI), which in turn places greater restrictions on time available to explore the problem space. Furthermore, while the desire to select to a jump to technology solution is endemic in many sectors, many transportation agencies face acute pressure from the public, the media, and politicians to demonstrate early signs of progress in terms that internal and external stakeholders understand— typically in specifics of technology. These pressures can sometimes negatively influence an agency’s ability to apply SE to its projects. 8.3 APPLICATION OF SYSTEMS ENGINEERING FOR PRODUCT LINE MANAGEMENT Product line management (PLM) is a combination of product, process, management, and organization to migrate from single‐system engineering to a product line approach. PLM can support the goal of improved organizational competitiveness as it decreases the development cost, increases the quality, and enlarges the product catalog. For the customer, a product line approach allows an organization to offer a family of products, which are adapted to the customer. This can lead to optimization of the product or service, the cost and time of acquisition, the quality of the system, and the cost of ownership. For the organization, PLM leads to optimization of its commercial position and its industrial loads, usually highlighting the identical functionality leading to standardization. These relationships are shown in Figure 8.3. Customer Peugeot 407 Organization Citroen CS Peugeot 407SW Product line FIGURE 8.3 Product line viewpoints. Reprinted with permission from Alain Le Put. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. APPLICATION OF SYSTEMS ENGINEERING FOR SERVICES Domain system engineering Application system engineering Reuse Product line management Capitalization FIGURE 8.4 Capitalization and reuse in a product line. Reprinted with permission from Alain Le Put. All other rights reserved. When implementing PLM, both the domain and the application SE processes must change as shown in Figure 8.4. The domain products (or generic products) address the product line requirements and are the results of domain SE. The generic products produced by the domain SE activities are capitalized from the application artifacts (e.g., generic requirements, generic architecture, and generic tests). These artifacts may be common or variable. The application products are the results of application SE. These products are the result of the instantiation of the generic products (i.e., reuse). 8.3.1 Product Line Scoping Product line scoping defines the main features of the product line, which provide sufficient reuse potential to justify the setting up or the evolution of a product line organization. Product line scoping is mainly based on: r The market analysis: target the perimeter of the concerned product line and the main external features of the product that provide enough commercial potential. r The SE process assessment: process maturity, weaknesses source of errors, and repetitive work without greater added value. (For example, it is even possible that some teams already have a process akin to the product lines.) r The products analysis: product tree and the presence of numerous common artifacts. 171 r The industrial process analysis: production and maintenance. (For example, the objective to be able to produce in several plants can be source of variability.) r The acquisition strategies analysis: the desire to diversify suppliers and the need to integrate different system elements (in size, performance, etc.). r The technology analysis: evaluation of technology readiness levels, design maturity, and domain applicability. 8.3.1.1 Return on Investment Developing a first system in a product line is an investment. The initial development is more expensive and longer than for a single‐ system development. But the following systems developed in the same product line are less expensive and may be delivered earlier (i.e., reduced time to market). In either case, the ROI must be evaluated, measured and managed. As illustrated in Figure 8.5 three projects are developed either in a single‐system engineering classical approach (top part) or in a product line SE approach (middle part). The ROI (bottom part) is initially negative (e.g., investment phase) and then positive (benefits of the product line approach). In this example, the break‐even point is reached for the third project. 8.4 APPLICATION OF SYSTEMS ENGINEERING FOR SERVICES This section introduces the concept of service SE, where SE methodologies are adapted to include a disciplined, systemic, and service‐oriented, customer‐centric approach among different stakeholders and resources for near‐ real‐time value cocreation and service delivery. The twenty‐first‐century technology‐intensive global services economy can be characterized as “information driven, customer‐centric, e‐oriented, and productivity focused.” It requires transdisciplinary collaborations between society, science, enterprises, and engineering (Chang, 2010). Several researchers and businesses are utilizing a socioeconomic and technological perspective to investigate end‐user (customer) interactions with enterprises by developing formal methodologies for value cocreation and productivity improvements. These methodologies have evolved into service SE, which mandates a disciplined and systemic approach (service For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 172 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING Single system development P1 SE effort for proposal for development P2 P3 Time Product line development SE effort for proposal for development Overcost and delay Savings P1 P2 P3 Savings and early delivery Time Investment (overcost) Savings 30 Return on investment 20 10 0 – 10 – 20 Monthly savings Monthly investment Total savings (cum.) – 30 Break even point Total investment (cum.) – 40 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 45 49 Time (months) FIGURE 8.5 Product line return on investment. Reprinted with permission from Alain Le Put. All other rights reserved. oriented, customer‐centric) among different stakeholders and resources in the design and delivery of the service to help customize and personalize service transactions to meet particular customer needs (Hipel et al., 2007; Maglio and Spohrer, 2008; Pineda et al., 2014; Tien and Berg, 2003; Vargo and Akaka, 2009). Service systems can be viewed as an SoS, where individual, heterogeneous, functional systems are linked together to realize new features/functionalities of a metasystem and to improve robustness, lower cost, and increase reliability. For service systems, understanding the integration needs among loosely coupled systems and system entities along with the information flows required for both governance and operations, administration, maintenance, and provisioning (OAM&P) of the service presents major challenges in the definition, design, and implementation of services (Domingue et al., 2009; Maier, 1998). Cloutier et al. (2009) presented the importance of Network‐Centric Systems (NCS) for dynamically binding different system entities in engineered systems rapidly to realize adaptive SoS that, in the case of service systems, are capable of knowledge emergence and real‐time behavior emergence for service discovery and delivery. The typical industry example given of this progression toward services is the International Business Machines (IBM), which still produces some hardware but view their business as overwhelmingly service oriented wherein hardware plays only an incidental role in their business solutions services. Furthermore, Apple, Amazon, Facebook, Twitter, eBay, Google, and other application service providers have provided the integrated access to people, media, services, and things to enable new styles of societal and economic interactions For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. APPLICATION OF SYSTEMS ENGINEERING FOR SERVICES at unprecedented scales, flexibility, and quality to allow for mass collaboration and value cocreation. Several researchers have concluded that even manufacturing firms are more willing to produce “results,” rather than solely products as specific artifacts by collaborating with end users that can potentially help define such results (Cook, 2004; Wild et al., 2007). As the world becomes more widely interconnected and people become better educated, the services networks (created by the interaction of the system entities) will be accessible from anywhere, at any time, by anyone with the proper access rights. 8.4.1 Fundamentals of Service Services are activities that cause a transformation of the state of an entity (a person, product, business, region, or nation) by mutually agreed terms between the service provider and the customer. Individual services are relatively simple, although they may require customization and significant backstage support (e.g., knowledge management, logistics, decision analysis, forecasting) to assure quality and timely delivery. A service system enables a service and/or set of services to be accessible to the customer (individual or enterprise) where stakeholders interact to create a particular service value chain to be developed and delivered with a specific objective (Spohrer and Maglio, 2010). In service systems practice, the service value chain is described in terms of links among the system entities connected via the NCS. A value proposition can be viewed as a request from one service system to another to run an algorithm (the value proposition) from the perspectives of multiple 173 stakeholders according to culturally determined value principles (Spohrer, 2011). Spath and Fahnrich (2007) defined a service metamodel comprising nine types of system entities and their corresponding attributes as shown in Table 8.2. Thus, a service or service offering is created by the relationships among service system entities (including information flows) through business processes into strategic capabilities that consistently provide superior value to the customer. From an SE perspective, participating system entities dynamically configure four types of resources: people, technology/environment infrastructure, organizations/institutions, and shared information/ symbolic knowledge in the service delivery process. Systems are part of other systems that are often expressed by system hierarchies (Skyttner, 2006) to create a multilevel hierarchy. Thus, the service system is composed of service system entities that interact through processes defined by governance and management rules to create different types of outcomes in the context of stakeholders with the purpose of providing improved customer interaction and value cocreation. This concept can be extended to create the service system hierarchy shown in Figure 8.6. The fundamental attributes of a service system include togetherness, structure, behavior, and emergence. As mentioned earlier, today’s global economy is very competitive, and the service system’s trajectory should be well controlled as time goes by (Qiu, 2009) since services are “real time in nature and are consumed at the time they are co‐produced” (Tien and Berg, 2003), that is, during service transactions. The service system should evolve and adapt to the conditions within the TABLE 8.2 Attributes of system entities Entity type Attributes Customer Goals Inputs Outputs Processes Features, attitudes, preferences, requirements Business, service, customer Physical, information, knowledge, constraints Physical, information, knowledge, waste, customer satisfaction Service provision, service delivery, service operations, service support, customer relationships, planning and control Service providers, support providers, management, owner organization, customer Enterprise, organizations, buildings, equipment, enabling technologies at customer premises (e.g., desktop 3D printers), furnishings, location, etc. Information; knowledge; methods, processes, and tools (MPTs); decision support; skill acquisition Political, economic, social, technological, environmental factors Human enablers Physical enablers Informatics enablers Environment For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 174 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING Service system Service system entities Outcomes (value change) Interactions (service networks) Identity Value proposition Governance mechanism Reputation (aspirations/lifecycle/risks) (offer/reconfig/incentives/risks) (rules/constraints/penalties/risk) (opportunities/variety/risks) Access rights (relationships) FIGURE 8.6 reserved. SLA (ranking of entities) Organization Security management Service system conceptual framework. Reprinted with permission from Dr. James C. Spohrer. All other rights business space in a manner to ensure that the customized service behaves as expected. This adaptive behavior of service system implies that its design must be truly transdisciplinary and must include methodologies from social science (e.g., sociology, psychology, and philosophy) to natural science (mathematics, biology, etc.) to management (e.g., organization, economics, and entrepreneurship) (Hipel et al., 2007). 8.4.2 Service management Properties of Services Services not only involve the interaction between the service provider and the consumer to produce value but have other intangible attributes like quality of service (e.g., ambulance service availability and response time to an emergency request). The demand for service may have loads dependent on time of day, day of week, season, or unexpected needs (e.g., natural disasters, product promotion campaigns, holiday season, etc.), and services are rendered at the time they are requested. Thus, the design and operations of service systems “is all about finding the appropriate balance between the resources devoted to the systems and the demands placed on the system, so that the quality of service to the customer is as good as possible” (Daskin, 2010). A service‐level agreement (SLA) represents the negotiated service‐level requirements of the customer and establishes valid and reliable service performance measures to ensure that service providers meet and maintain the prescribed quality of service, user‐perceived performance, and degree of satisfaction of the user. The service system’s SLAs are then the composition of these categories evaluated on a systemic level to ensure consistency, equity, and sustainability of the service (Spohrer, 2011; Theilmann and Baresi, 2009; Tien and Berg, 2003). The twenty‐first century is witnessing accelerated technology development and global mass collaboration as an established mode of operation. Value cocreation is achieved as loosely entangled actors or entities come together in unprecedented ways to meet mutual and broader market requirements. This transformation will radically reshape the nature of work, the boundaries of the enterprise, and the responsibilities of business leaders (McAfee, 2009). Spohrer (2011) has captured this trend in service by categorizing the different service sectors into three types of service systems: r Systems that focus on flow of things: transportation and supply chain, water and waste recycling, food and products, energy and electric grid, information, and cloud. r Systems that focus on human activities and development: buildings and construction, retail, hospitality/media, entertainment, banking and finance, business consulting, healthcare, family life, education, work life/jobs, and entrepreneurship. r Systems that focus on governing (city, state, nation): the classification helps in identifying different objectives and constraints for the design and operations of the service system (e.g., strategic policies under For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. APPLICATION OF SYSTEMS ENGINEERING FOR ENTERPRISES limited budget, education, strategic readiness for quick response, national defense, maximizing profit while minimizing cost) and determining the overlap and synergies required among different service entities and required science disciplines. 8.4.3 Scope of Service SE Current enterprises must plan, develop, and manage the enhancements of their infrastructure, products, and services, including marketing strategies to include product and service offerings based on new, unexplored, or unforeseen customer needs with clearly differentiated value propositions. Taking the service SE approach is imperative for the service‐oriented, customer‐centric, holistic view to select and combine service system entities to define and discover relationships among service system entities to plan, design, adapt, or self‐adapt to cocreate value. Major challenges faced by service SE include the dynamic nature of service systems evolving and adapting to constantly changing operations and/or business environments and the need to overcome silos of knowledge. Interoperability of service system entities through interface agreements must be at the forefront of the service SE design process for the harmonization of OAM&P procedures of the individual service system entities (Pineda, 2010). In addition, service systems require open collaboration among all stakeholders, but recent research on mental models of multidisciplinary teams shows integration and collaboration into cohesive teams has proven to be a major challenge (Carpenter et al., 2010). Interoperability among the different service system entities becomes highly relevant in service SE since the constituent entities are designed according to stakeholder needs; the entity is usually managed and operated to satisfy its own objectives independently of other system entities. The objectives of individual service system entities may not necessarily converge with the overall objectives of the service system. Thus, the service system design process (SSDP) adapts traditional SE life cycle best practices, as illustrated by Luzeaux and Ruault (2010), Lin and Hsieh (2011), Lefever (2005), and the Office of Government Commerce (2009). Another important role of service SE is the management of the service design process whose main focus is to provide the planning, organizational structure, collaboration environment, and program controls required to ensure that stakeholder’s needs are met from an end‐to‐end customer perspective. The service design 175 management process aligns business objectives and business operational plans with end‐to‐end service objectives including customer management plans, service management and operations plans, and operations technical plans (Hipel et al., 2007; Pineda et al., 2014). 8.4.4 Value of Service SE Service SE brings a customer focus to promote service excellence and to facilitate service innovation through the use of emerging technologies to propose creation of new service systems and value cocreation. Service SE uses disciplined approaches to minimize risk by coordinating/orchestrating social aspects, governance (including security), environmental, human behavior, business, customer care, service management, operations, and technology development processes. Service systems engineers must play the role of an integrator, considering the interface requirements for the interoperability of service system entities—not only for technical integration but also for the processes and organization required for optimal customer experience during service operations. The service design definition process includes the definition of methods, processes, and procedures necessary to monitor and track service requirements verification and validation as they relate to the OAM&P procedures of the whole service system and its entities. These procedures ensure that failures by any entity are detected and do not propagate and disturb the operations of the service (Luzeaux and Ruault, 2010). The world’s economies continue to move toward the creation and delivery of more innovative services. To best prepare tomorrow’s leaders, new disciplines are needed that include and ingrain different skills and create the knowledge to support such global services. Service systems engineers fit the T‐shaped model of professionals (Maglio and Spohrer, 2008) who must have a deeply developed specialty area as well as a broad set of skills and capabilities in addition to the service system management and engineering skills, as summarized by Chang (2010). 8.5 APPLICATION OF SYSTEMS ENGINEERING FOR ENTERPRISES This section illustrates the applications of SE principles in enterprise SE for the planning, design, improvement, and operation of an enterprise in order to transform and continuously improve the enterprise to survive in a For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 176 TAILORING PROCESS AND APPLICATION OF SYSTEMS ENGINEERING globally competitive environment. Enterprise SE is the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise. Enterprise SE is an emerging discipline that focuses on frameworks, tools, and problem‐solving approaches for dealing with the inherent complexities of the enterprise. Furthermore, enterprise SE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of enterprise SE is provided in the book by Rebovich and White (2011). For more detailed information on this topic, please see the enterprise SE articles in Part 4 of SEBoK (2014). 8.5.1 Enterprise An enterprise consists of a purposeful combination (e.g., a network) of interdependent resources (e.g., people, processes, organizations, supporting technologies, and funding) that interact with each other to coordinate functions, share information, allocate funding, create workflows, and make decisions and their environment(s) to achieve business and operational goals through a complex web of interactions distributed across geography and time (Rebovich and White, 2011). Money Time Energy Is an Business Depends on Knowledge People Other stakeholders for Value Creates Manages Asset Projects Is type of Tacit knowledge Society Material consumes/ Produces Explicit knowledge An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment. It is worth noting that an enterprise is not equivalent to an “organization” according to the definition earlier. This is a frequent misuse of the term enterprise. Figure 8.7 shows that an enterprise includes not only the organizations that participate in it but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical, or self‐organizing network. To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a system,” rather than merely as a collection of functions connected Include work in Is type of Organization Participates in Enterprise Manages Teams Resource Is type of Includes/uses all these things Notes: 1. All entities shown are decomposable, except people. For example, a business can have sub businesses, a project can have subprojects, a resource can have sub resources, an enterprise can have sub enterprises. 2. All entities have ether names. For example, a program can be a project comprising server all subprojects. (Often called merely projects). Business can be an agency, team can be group, value can be utility, etc. 3. There is no attempt to be prescriptive in the names chosen for this diagram. The main goal of this is to show how this chapter uses these terms and how they are related to each other in a conceptual manner. FIGURE 8.7 Organizations manage resources to create enterprise value. From SEBoK (2014). Reprinted with permission from BKCASE Editorial Board. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. APPLICATION OF SYSTEMS ENGINEERING FOR ENTERPRISES Since there could possibly be several organizations involved in this enterprise venture, each organization could be responsible for particular systems or perhaps for certain kinds of elements. Each organization brings their own organizational capability with them, and the unique combination of these organizations leads to the overall operational capability of the whole enterprise. These concepts are also illustrated in Figure 8.7. The word “capability” is used in SE in the sense of “the ability to do something useful under a particular set of conditions.” This section discusses three different kinds of capabilities: organizational capability, system capability, and operational capability. It uses the word “competence” to refer to the ability of people relative to the SE task. Individual competence (sometimes called “competency”) contributes to, but is not the sole determinant of, organizational capability. This competence is translated to organizational capabilities through the work practices that are adopted by the organizations. New systems (with new or enhanced system capabilities) are developed to enhance enterprise operational capability in response to stakeholder’s concerns about a problem situation. As shown in Figure 8.8, operational capabilities provide operational services that are enabled by system solely by information systems and shared facilities (Rouse, 2009). While a system perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers. 8.5.2 Creating Value The primary purpose of an enterprise is to create value for society, for other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 8.7, which shows all the key elements that contribute to this value creation process. There are three types of organizations of interest to an enterprise: businesses, projects, and teams. A typical business participates in multiple enterprises through its portfolio of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of subprojects. 8.5.3 177 Capabilities in the Enterprise The enterprise acquires or develops systems or individual elements of a system. The enterprise can also create, supply, use, and operate systems or system elements. Includes these kinds of “products” Hardware, software, personnel, facilities, techniques, data, materials, services, etc. O