Applying System Theoretical Process Analysis Method to Change Programs in Integrated Enterprise ARCHIVES MASSACHUSErCT trv T;rJjTE OF f,-CH1N1CL0LY by Tan Shuijian AUG U 62015 B.Eng., Electrical and Electronics Engineering Nanyang Technological University at Singapore, 2007 LIBRARIES SUBMITTED TO THE MIT SLOAN SCHOOL OF MANAGEMENT AND SCHOOL OF ENGINEERING IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN ENGINEERING AND MANAGEMENT IN CONJUNCTION WITH THE SYSTEM DESIGN AND MANAGEMENT PROGRAM AT THE MASSACHUSETTS INSTITUTE OF TECHNOLOGY FEBRUARY 2014 C 2013 Tan Shuijian. All rights reserved The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part in any medium now known or hereafter created. C Signature 01 AUtU r............. Signature red acted .4 Certified by......................... ,Oem ........... ................ Fellow of Design and Management (SDM) January 17, 2014 redacted SignaturE rd tErid eetsh h .............................. ....... jV Research Associat Eric Rebentisch, PhD n Systems , c2_ Accepted by........................ % R esearch Center, MIT esis Supervisor Signature redacted .... . .............. ......... Pat Hale Senior Lecturer Engineering Systems Division, MIT Director SDM Fellows Program This page left intentionally blank Applying System Theoretical Process Analysis Method to Change Programs in Integrated Enterprise By Tan Shuijian Submitted to the System Design and Management Program on January 17, 2014 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering and Management ABSTRACT Thesis Supervisor: Dr. Eric Rebentisch Title: Research Associate, Sociotechnical Systems Research Center Manufacturing and life science enterprises need a flexible and effective approach to respond to industrial compliances and high complexity in stakeholder communication. The paper proposes a system engineering approach in System Theoretical Process Analysis (STPA) as an enterprise transformation method adopted by IT consultancy firms to better define enterprise requirements for transformation and integrate change interventions into organizational structure. Despite STPA being a hazard analysis method, its corresponding hierarchical control structure applies to organizational structures, with adaptations to value x-matrices based on stakeholder value theory and process models necessary to match operators' mental models for control actions and attain information reusability and harmonized processes. Through alignment of the infological and socio-cultural aspects of integrated enterprises led by change program management, potential flaws in organizational structures and information systems are identified and proposed for resolution. A qualitative and visual approach using 2 change program cases and lean concept was adopted in this study. Surveys were conducted with program participants, and semi-structured interviews were held with program management to explore perspectives on utilizing the enterprise-adapted STPA. The outcomes are the validation of this method, and lean practice in change interventions as recommendations for integration of processes and enterprise functions and promotion of program flow. Keywords: Enterprise Architecture, System Engineering, Change Management, Program Management, Stakeholder Theory, STPA, Architectural Alignment, Communication, lean Page 3 ACKNOWLEDGEMENTS I would like to thank my advisor Dr Eric Rebentisch for providing me the opportunity to work on this thesis and for providing valuable advice and guidance. Along the journey of the research, he has consistently expressed confidence, allowing me the autonomy and motivation to approach this topic with vigor and focus. I would also like to thank Tata Consultancy Service, and especially Sathish Kumar Thirugnanam for continually reviewing my work by providing valuable feedback, and Raja Banerji and Anurag Jain for providing support for exploration of this interesting topic. Many classes I took at MIT have helped to shape my approach for this research and thus covered in this thesis. Some of the classes include Integrating Lean Enterprise by Prof. Deborah J Nightingale, The Economics of Information: Strategy, Structure and Pricing by Prof. Erik Brynjolfsson, System Safety by Prof. Nancy G. Leveson. I have to especially mention that Prof. Nancy G. Leveson's book Engineering a Safer World - Systems Thinking Applied to Safety has been the motivating factor for this research approach. The SDM program has provided me with the platform to engage thought leaders in their fields namely Prof. David Simchi-Levi in supply chain and operations, Jeanne W. Ross in IT architecting, who are worthy of mentions in this thesis. All these would not be possible without the direction of SDM Program director Pat Hale for his dedication to make this program a success today. A personal note of thanks has to be extended to Pat for ensuring the individual needs of us international students are taken care of, so that we can focus on showcasing our talents and exploring our interests. Likewise, I would like to express my deepest gratitude to Singapore University of Technology and Design (SUTD), a fantastic organization which sponsors my graduate studies in MIT. Finally, I would like to thank my parents, Eng Hua and Lay Pin, for always being supportive of what I strive to do. And in memory of my granddad who passed away on the week of this thesis submission. Page 4 Table of Contents Table of Figures.......................................................................................................................................8 Table of Tables ........................................................................................................................................ 9 List of Abbreviations.............................................................................................................................. 10 1 Introduction ....................................................................................................................................... 11 1.1 M otivation for this Thesis....................................................................................................... 11 1.1.1 Challenges facing Enterprises ............................................................................................ 11 1.1.2 M anaging for Complexity and Flexibility ............................................................................ 12 1.1.3 Lean Principles for Change Program Management ............................................................. 14 1.2 Research Objective................................................................................................................. 15 1.3 Organization of Thesis............................................................................................................ 16 2 Industrial Trends and Enterprise Transformation .............................................................................. 2.1 18 W hat's in for the Industries?.............................................................................................. 18 2.1.1 M anufacturing in Automotive ............................................................................................ 18 2.1.2 M edical Devices & Diagnostic in Life Science ...................................................................... 19 2.2 Enterprise Transformation ..................................................................................................... 21 2.2.1 Consulting for Integrated Enterprises ................................................................................ 21 2.2.2 Enterprise Architecting.......................................................................................................... 24 2.2.3 Enterprise System Engineering ........................................................................................... 31 2.2.4 ESTPA.................................................................................................................................... 35 2.2.5 Summary............................................................................................................................... 37 3 Lean on Change Program M anagement .......................................................................................... 3.1 39 Lean Change Programs........................................................................................................... 39 3.1.1 Change M anagement M odels............................................................................................. 39 3.1.2 Lean Principles for Change Programs.................................................................................. 44 3.2 Lean M anagement.................................................................................................................53 3.2.1 M anaging Change Programs.................................................................................................. 53 3.2.2 Process M odel Used in Analysis........................................................................................... 59 3.2.3 Change Program M anagement........................................................................................... 63 Page 5 3.2.4 ESTPA in Lean M anagem ent .............................................................................................. 65 4 Research Overview and M ethodologies ............................................................................................ 4.1 68 Research Procedure ............................................................................................................... 68 4.1.1 Research Hypotheses ............................................................................................................ 68 4.1.2 Selection of Research Participants and Subjects ................................................................. 68 4.1.3 Description of Research Design .......................................................................................... 71 4.1.4 Assum ptions, Lim itations & Delim itations ......................................................................... 73 4.1.5 Proposal w ith TCS ................................................................................................................. 74 4.2 ESTPA Execution on TCS Programs...................................................................................... 75 4.2.1 Defining Value for TCS Integrated Enterprise...................................................................... 75 4.2.2 Generation of Value M atrix ................................................................................................... 76 4.2.3 Hierarchical Control Structures and Process M odels........................................................... 81 4.2.4 Evaluating Survey and Interview Outcom es........................................................................ 84 4.2.5 Extraction of Information from the Engine Manufacturer Change Program........................86 5 Research Findings and Validation........................................................................................................ 5.1 88 Analysis Results...................................................................................................................... 88 5.1.1 Findings from Tractor Program's Control Structure ............................................................. 88 5.1.2 Findings from Tractor Program's Process M odel.................................................................... 94 5.1.3 Findings from Engine M anufacturer .................................................................................... 5.2 100 Lessons Learnt for Change Program s....................................................................................109 5.2.1 Review of ESTPA in TCS Change Programs ........................................................................... 109 5.2.2 Im pact on Program M anagem ent........................................................................................ 111 6 Thesis Conclusion ............................................................................................................................. 115 6.1 Thesis Sum m ary ................................................................................................................... 6.2 Lim itations of Thesis.............................................................................................................115 6.3 Future W ork.........................................................................................................................117 115 Bibliography ........................................................................................................................................ 119 Appendices.......................................................................................................................................... 124 Appendix A - Survey Questionnaire (Part 1)..................................................................................... 124 Appendix B - Survey Description (Part 1).........................................................................................131 Page 6 Appendix C - Program Manager Interview Questions ...................................................................... 134 Appendix D - Stakeholder/Actor Value Role .................................................................................... 138 Appendix E - TCS Tractor and Engine Manufacturer's Change Program ........................................... 143 Appendix F - Major Data from Survey and Interview ....................................................................... 144 Page 7 Table of Figures 12 FIGURE 1: PHARMACEUTICALS POSITION IN BIG DATA ........................................................................................................ 13 FIGURE 2: TOGAF 9 CERTIFICATION FROM THE OPEN GROUP BLOG (22 JULY 2013) ........................................................... 3: CLINICAL TRIAL - SOURCE "WORLDWIDE MEDICAL & OUTCOME RESEARCH " ............................................................. 4: SIMPLIFIED INFORMATION FLOW OF PHRMA..................................................................................................... 5: CONSULTING FIRMS' BUSINESS MODELS (CHRISTENSEN & WANG 2013)............................................................... 20 22 FIGURE 6: THE 25 FIGURE FIGURE FIGURE OPEN GROUP'S ARCHITECTURE DEVELOPMENT CYCLE ................................................................................... 26 2012) ................................................................... 8: LEAN ENTERPRISE'S PROCESS ARCHITECTURE VIEW (SOURCE - NIGHTINGALE & MIZE 2002)..................................... 29 32 9: HIERARCHICAL CONTROL STRUCTURE (LEVESON 2011) ..................................................................................... 33 10: CLASSIFICATION OF CONTROL FLAWS (LEVESON 2011).................................................................................... 36 11: LEAN PRINCIPLES TO ENGINEERING (MCMANUS 2005).................................................................................. 40 12: RELATIONSHIP BETWEEN MENTAL MODELS (LEVESON 2011) ........................................................................... 13: KOTTER'S 8-STAGE CHANGE MANAGEMENT MODEL (KOTTER 2007).................................................................. 42 44 14: LEAN ESTPA............................................................................................................................................ 45 2001) ....................................................................... MONTHLY REVIEW (TENNANT & ROBERTS 15: HOSHIN KANRI FIGURE 7 : CONTENT METAMODEL WITH FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE 19 U ML (SCHERER AND WIMMER 47 FIGURE 16: TCS's SOLUTION OBJECTIVE MATRIX ............................................................................................................ 17: DEFINITION OF OBJECTIVES FROM STAKEHOLDER NEEDS (REBENTISCH 2000)........................................................ 18: EIGHT TYPES OF WASTE IN L EAN PD .............................................................................................................. 48 54 FIGURE 19: FACTORS OF INFLUENCE FOR SOCIO-CULTURAL AND INFOLOGICAL ALIGNMENTS........................................................ 57 FIGURE FIGURE FIGURE 20: 4 TYPES OF OPERATING MODELS (Ross, W EILL, ROBERTSON 60 2006) ................................................................. FIGURE 21: BUILDING BLOCK FOR PROCESS MODEL ......................................................................................................... 61 FIGURE 22: ESTPA IN LEAN PROGRAM ......................................................................................................................... 66 FIGURE 23: TCS CCBT FRAMEWORK............................................................................................................................. 70 FIGURE 24: X-MATRIX FOR TCS - TRACTOR MANUFACTURER CHANGE PROGRAM ................................................................... 76 FIGURE 25: DESCRIPTION FOR STAKEHOLDERS.................................................................................................................. 78 FIGURE 26: VALUE MATRIX OF TCS TRACTOR MANUFACTURER ........................................................................................... 79 FIGURE 27: SIMPLIFIED PROGRAM STRUCTURE ................................................................................................................ 81 82 85 87 88 FIGURE 28: DEMONSTRATIVE PROCESS MODEL ................................................................................................................ FIGURE 29: TERMINOLOGY FOR INFOLOG ICAL SPIDER DIAGRAM ........................................................................................... FIGURE 30: EXTRACT FROM ENGINE MANUFACTURER ....................................................................................................... FIGURE 31: HIERARCHICAL CONTROL STRUCTURE FOR TRACTOR MANUFACTURER CHANGE PROGRAM ......................................... FIGURE 32: SOCIO-CULTURAL-INFOLOGICAL BACKGROUND OF TCS PROJECT MANAGER ........................................................... 91 33: SOCIO-CULTURAL-INFOLOGICAL BACKGROUND OF TCS PROGRAM MANAGER .......................................................... 34: TRACTOR PROGRAM'S PDR PROCESS MODEL .................................................................................................. 93 FIGURE FIGURE FIGURE 35: SOCIO-CULTURAL-INFOLOGICAL BACKGROUND OF FINANCE ................................................................................ FIGURE FIGURE 36: SOCIO-CULTURAL-INFOLOGICAL BACKGROUND OF SMG .................................................................................. 37: HIERARCHICAL CONTROL STRUCTURE FOR ENGINE MANUFACTURER .................................................................... 94 96 97 101 FIGURE 38: SOCIO-CULTURAL-INFOLOGICAL BACKGROUND OF TCS WORKGROUP MANAGER .................................................... 103 FIGURE 39: MODIFICATION TO ENGINE HIERARCHICAL CONTROL STRUCTURE ........................................................................ 104 40: NEW VALUE MATRIX FOR ENGINE MANUFACTURER PROGRAM .......................................................................... 41: PROCESS MODEL FOR ENGINE PCM ............................................................................................................ 105 106 FIGURE FIGURE Page 8 Table of Tables TABLE 1: BENEFITS AND AREAS OF IMPROVEMENT FOR ENTERPRISE ARCHITECTING FRAMEWORKS ................................................ 30 TABLE 2: DESCRIPTION OF STEP-BY-STEP STPA M ETHOD..................................................................................................... 32 TABLE 3: STPA ALIGNMENTS IN ADDITION TO MAGOULES ET AL. 2012.............................................................................. 35 TABLE 4: BENEFITS AND LIMITATIONS IN CHANGE MANAGEMENT MODELS ............................................................................. 43 TABLE 5: STEP SEQUENCE FOR M ODIFICATION A .............................................................................................................. 46 TABLE 6: BENEFITS OF LEAN CHANGE MANAGEMENT APPROACH........................................................................................ 52 TABLE 7: FACTORS OF INFLUENCE FOR SOCIO-CULTURAL AREA OF INFLUENCE ........................................................................... 58 TABLE 8: ESTPA-ASSOCIATED LEAN ENABLERS (EXTRACTED FROM OEHMEN & ET 2012)........................................................ 65 TABLE 9: INADEQUATE CONTROL ACTIONS FROM TRACTOR CONTROL STRUCTURE .................................................................... 89 95 TABLE 10: INADEQUATE CONTROL ACTION FROM TRACTOR P ROCESS MODEL ........................................................................ TABLE 11: PROPOSED ACTIONS FOR TRACTOR PROGRAM FLAW RESOLUTION......................................................................... 100 TABLE 12: INADEQUATE CONTROL ACTION IDENTIFIED FROM ENGINE HIERARCHICAL CONTROL STRUCTURE .................................. 102 TABLE 13: SUM M ARY OF H 1, H2 HYPOTHESIS ............................................................................................................... 110 TABLE 14: BENEFITS FOR A NALYSIS APPROACH............................................................................................................... 112 TABLE 15: RATING OF ESTPA MODELING COMPONENTS FROM PROGRAM MANAGER INTERVIEW............................................... 112 TABLE 16: COMPARISON BETWEEN TCS PROCESS MODEL AND ESTPA PROCESS MODEL ........................................................... 113 TABLE 17: PROGRAM MANAGER RATING OF ESTPA ON LEAN ENABLER ............................................................................... 114 Page 9 List of Abbreviations ADM: CAST: CCBT: CR: CCB/CRB: DARPA: DSM: ESTPA: FDA: ICA: INCOSE: IS: IT: MD&D: MIT: NPI: PCM: PD: PDR: PhRMA: PLM: PMI: R&D: RWD: RWE: SMG: SO: STPA: SUTD: TCS: TOGAF: UDI: UML: VSA: VSM: Architecture Development Method Causal Analysis based on STAMP Customer-Centric Business Transformation Change Request Change Control Board/Change Request Board Defense Advanced Research Projects Agency Design Structure Matrix Enterprise-adapted System-Theoretic Process Analysis Food and Drug Administration Inadequate Control Action International Council on Systems Engineering Information System Information Technology Medical Devices and Diagnostic Massachusetts Institute of Technology New Product Introduction Product Change Management Product Development Product Definition Report Pharmaceutical Research and Manufacturers of America Product Lifecycle Management Project Management Institute Research and Development Real World Data Real World Evidence Senior Management Group Solution Objective System-Theoretic Process Analysis Singapore University of Technology and Design Tata Consultancy Services The Open Group Architecture Framework Unique Device Identification Unified Modeling Language Value Stream Analysis Value Stream Mapping Page 10 1 Introduction 1.1 Motivation for this Thesis 1.1.1 Challenges facing Enterprises Product-oriented organizations today are constantly hearing the buzzword - Big Data - and how it can be a game-changer to their success. The explosion in "volume, variety, velocity and veracity" (Institute for Business Value 2012) in data available is a double-edged sword; how enterprises use these big datasets and multiple data sources are constant challenges that are dynamic and need a timely response as they come, yet they serve as competitive opportunities. Take the consideration of the automotive industry that is at revolutionary crossroad. The emergence of cloud technology, electric vehicle (EV) and automated driving from technological advancement is bringing a new definition to the market automotive manufacturers are currently serving. This demands inflection to existing automobile innovation as they not only serve traditional automobile stakeholders such as Volkswagen and Chrysler, but also meet new demands such as a crowdsourcing channel like Rally Fighter (Munoz, 2013). In the midst of technological disruption, automotive manufacturers are thus exposed to emergent data points that could prove valuable, and demand they are better positioned to reap these communication opportunities. For Medical Devices and Diagnostics (MD&D) in biotechnological and healthcare industry, the Information Technology (IT) movement towards Big Data and Data Analytic is even more pronounced. Pharmaceuticals Research and Manufacturers of America (PhRMA) members invested US$34.8 billion on Research and Development (R&D) in 2009, "representing 19.0% of domestic sales" (Anon 2013), but are they getting value for their investment? Page 11 Figure 1: Pharmaceuticals Position in Big Data Also, many companies such as Pfizer, Eli Lilly, Bayer and Daiichi Sankyo are already extracting value in various forms of Big Data analytics (Figure 11). As such, it is imperative that these organizations understand the risks and benefits from engaging these data channels as they are subjected to strict regulation. 1.1.2 Managing for Complexity and Flexibility Consider organizations having to interface downstream with multiple customers on demands that can be conceptually different, and upstream with various suppliers and partners for support in physical material and information, operation complexity immediately comes to mind as the number and types of channels to manage grow with complexity. This is made all the more interesting by studying integrated enterprises such as IBM, Accenture or Tata Consultancy Services (TCS), as it is paramount for consultancy organizations to understand clients' values in the form of business strategies and realize IT investments by enabling, supporting and enforcing these strategies (Simchi-Levi, 2010). Major data contribution for this paper thus originates from TCS to demonstrate the collaboration with their tractor manufacturing and engine manufacturing clients. 'This interview with the Pharmaceuticals is conducted in 2013 in fulfillment of course project for "15.571 Business Strategy & Role of IT" in MIT. Page 12 Victor Tang, previously Senior Director and VP of IBM China, and Director of Winter Olympics Technology and Client Relation at IBM, reiterated the success of IT being an end-to-end process and demonstrated the Zachmann Framework 2 as his representation for holistic analysis. The Open Group's TOGAF, an extensive enterprise architecture methodology and framework for enterprise information infrastructure, is also growing in popularity in term of number of certifications attained worldwide (Figure 2). 26000TOGAFO 26000+ Certication d CFotoation STotal 10000 6000 '09 '09 '09 '09 '10 '10 '10 '10 '11 '11 '11 '12 *12 '12.11'12 '13 13 Figure 2: TOGAF 9 Certification from The Open Group Blog (22 July 2013) All these trickle down to the argument for a holistic approach in enterprise and IT architecting, and possibly a systems theory methodology to support holistic thinking. Why systems theory is considered is due to its foundational ideas of "Emergence and Hierarchy" and "Communication and Control"; its associated causality model called Systems-Theoretic Accident Model and Processes (STAMP) (Leveson, 2011) is adopted by this paper to 2Zachmann Framework is a schema consisting a 2-dimensional classification matrix based on the intersection of 6 communicative questions What, Where, When, Why, Who and How, with 5 level of reification Contextual, Conceptual, Logical, Physical, Detailed. Page 13 understand the enterprise's complexity in term of its hierarchical structure and control mechanism. The paper predicts that by using this model, analyzing an integrated enterprise system such as TCS and its network of clients within the constraints of its value streams would reveal insights about emergence of desired success attributes. This would be of practical value to program managers for their management of change programs to drive flexibility in client enterprises in the face of fast-changing landscape. 1.1.3 Lean Principles for Change Program Management While there are many change management models - some well-known being Kotter's 8 stage Model for Change Management, Peter Senge's 5 Step Model of Learning Organizations, KAIZEN change management, the common advice has been that application should be focused on organizational situational needs (Syeda and Naarananuja 2013). TCS provides the author the interesting proposition to analyze an integrated enterprise and its extension to individual clients such as a tractor manufacturer and engine manufacturer. Based on Customer-Centric Business Transformation (CCBT) Framework 3, TCS strives to practice lean to introduce change intervention for its clients in its Product Lifecycle Management (PLM) programs. Organically, how this framework stacks up with lean principles (James P. Womack, 2003) will be of interest. This learning would eventually be useful as insights to program managers and enterprise stakeholders, as they grapple with IT demand and challenges of introducing changes within their organizations. 3The Customer-Centric Business Transformation (CCBT) Framework is a Change Management Model created and used by TCS to apply change interventions within their clients' organizations. Page 14 1.2 Research Objective Especially for IT consultancy agencies such as TCS, which relate to its multiple clients in an integrated enterprise environment, problems of missing functions and linkages between designed processes can naturally impact on decision outcomes of PLM programs and customer satisfaction. This means performance is not optimized, information flow impeded and effort wasted, and reactions might be too late when consultants and business owners identify these lost values. The paper looks to identify an approach that would allow actors to timely identify missing gaps for remedies. While process models are widely used in enterprise transformation models and, to some extent, organizational change programs, the paper also finds potential in the utilization of control structures for enterprise modeling. To showcase this potential, the paper presents two TCS client cases in a tractor manufacturer and an engine manufacturer. Applying these modeling based on lean principles, the paper aims to explore complex and dynamic consultancy programs and identify episodic improvements in complex organizational systems. Using the completed tractor manufacturer's program, the paper expects to identify lessons learnt that can be translated to the ongoing engine manufacturer's program. All these lead to the paper's proposal for this systematic approach for analyzing enterprise transformation in TCS's change management programs. This approach primarily draws inspiration from STAMP which mainly focuses on safety as an attribute in system design and analysis. The papers focus is on change program for enterprise design, and program management, and argues that its application of STAMP approach is relevant too. Page 15 1.3 Organization of Thesis Chapter 1 provides the background and context which the paper is based on, in order to allow readers to appreciate the concurrence of the topics being discussed. Subsequently, it describes the objectives of this thesis and how the author plans to fulfill this learning through research activities and industrial collaboration. The structure of the thesis is laid out to facilitate holistic exploration of the thesis topics, in line with the spirit of system thinking. Chapter 2 continues from literature review and industrial cases to accumulate the key learnings from scholars and industrial players. By drawing cases from emerging trends, the paper aims to inform the readers about the urgency in application of our approach for change programs. By drawing a rich repository of information about enterprise transformation, the paper introduces an adapted approach based on Nancy Leveson's STAMP and evaluates how the proposed approach stacks up against current practices. Chapter 3 provides an overview of change management, and lean principles and methods which forms the basis for the functioning and evaluation of lean change programs. Subsequently, the paper introduces the concept of lean management, and how it adapts STPA for the effective evaluation of enterprise changes with the recommended process model. Enterprise-adapted System-Theoretic Process Analysis (ESTPA) is eventually proposed with a couple of adaptations on STPA. Chapter 4 describes the case studies with 2 enterprises in collaboration with TCS for the purpose of evaluating ESTPA for effectiveness in enterprise transformation in lean change programs. Emphasis is placed on Product Lifecycle Management (PLM) solutions in both programs to realize Product Development (PD). Readers would better appreciate the ESTPA Page 16 approach as the paper demonstrates the execution of the value matrix, hierarchical control structure, process modeling on the programs and the validation by survey outcomes. Chapter 5 compiles the findings of ESTPA through the analysis of the tractor manufacturer's change program and extends these findings to that of the Engine manufacturer. From TCS interviews on program management, the paper collects lessons learnt from the execution of ESTPA and its implications on program management. This will provide the leverages for realizing the adoption of ESTPA in change management and program management. Chapter 6 summarizes this paper with the appreciation of this approach on other forms of applications. By discussing on interesting findings from this approach and possible inclusions that could have been covered, the paper recommends extension to this research that would fuel its common application in the IT consultancy industry. Page 17 2 Industrial Trends and Enterprise Transformation 2.1 What's in for the Industries? 2.1.1 Manufacturing in Automotive Traditionally, the majority of the components used within an automobile is led and designed by automotive manufacturers. Henry Ford was famously quoted "People can have the Model T in any color - so long as it's black." And producers in the automotive industry duly defined how the automobiles function with their innovation, and how they are styled with their craftsmanship. As the complexity of the product development increased, more Tier-1 players such as Continental AG entered the industry providing components and engineering support to boast up development efforts, and so were the manufacturers of other tier levels. While the complexity of automobile development never let up with the emergence of semiautonomous and autonomous vehicles, startups and giants in other domains are entering this industry to introduce breakthrough products like the GOOGLE CAR (MARKOFF, 2010) and add more complexity into the mix. The Defense Advanced Research Projects Agency (DARPA) challenges (DARPA URBAN CHALLENGE, 2007) is one instance worth learning that demonstrated successful partnerships among automotive manufacturers. More importantly, the voice of consumers is also getting stronger as these challenges were open to all participants willing to explore and innovate with autonomous vehicle application. Rally Fighter and OpenXC - (OpenXC, 2012) are other cases of "crowdsourcing" platforms - coined by Jeff Howe in 2006 as functions normally undertaken internally by firms are outsourced to an undefined group of people that may be enthusiasts. Eric Von Hippel urged industry players to identify "what your most advanced users are already doing and understanding what their innovations mean for the future of your business" (von Hippel, 1986), which he referred to them as "lead users". With an exponential increase in points of contact for drawing information from partners, multiple-tier Page 18 suppliers, lead users and customers, automotive manufacturers are facing an immense challenge to shore up their organizational structures, so as to keep up with the progression of innovation and pace of competition and cooperation. 2.1.2 Medical Devices & Diagnostic in Life Science The Pharmaceuticals and MD&D manufacturers operating within the life science arena (or known as PhRMA) are highly regulated and supervised by the govemment agency Food and Drug Administration (FDA) to ensure public health. Their products in prescription, over-thecounter pharmaceutical drugs, vaccines, medical devices are some of the items that go through multiple stringent levels of check in the form of clinical trials (Figure 3) as demanded by FDA before they become available in the market. FA Pre-clinical studies a Provides a first assessment of the expected safety and efficacy of a compound using proven animal models 8 Early Phase Clinical trials a Safety focus and the beginnings of efficacy, dose ranging, and tolerability * Pivotal Clinical trials a Demonstrate safety and efficacy in well controlled (generally masked) randomized studies sufficient for market authorization I Phase IIIB w Expanded trials In different use situations or populations * Phase IV a Post marketing safety or "new" indications * Real World Data * Evaluations of safety, effectiveness and outcomes In "routine" clinical practice IN NDA Filed NOA APPrOVed Figure 3: Clinical Trial - Source "Worldwide Medical & Outcome Research" At each level, real world data (RWD) supplements clinical trials for effective modeling approaches and also provides compliance, adherence and decision-making insights in the form of real world evidence (RWE) as interpreted by medical practitioners. Considering several characterizations of this data in terms of outcomes, sources and hierarchies of evidence, the importance is not limited to the data content itself but ranges from understanding its context and Page 19 circumstances to driving benefits in applying good processes from collecting, processing and utilizing the data (Garrison Jr. LP, Neumann PJ, Erickson P 2007). Some of the challenges posed for life science in term of augmenting value from using RWD are variations in acquisition standards, differences in data formats, lack of access to existing data and lack of incentives to share and disseminate data. It is thus paramount for enterprises to set up relevant information infrastructures to integrate available data, provide straightforward access to repositories and develop an integrated-enterprise-wide or community-wide system for data cataloging and monitoring (Kolker, Stewart, and Ozdemir 2012). Approved Produwt nolegeProdtr w, Da Figure 4: Simplified Information Flow of PhRMA The paper (Figure 4) provides a simplified representation of the flow of data/information/product within the collaborative environment of PhRMA who pay for data from healthcare providers and insurance agencies to collect insights for product development. There are also options like contracting independent research organizations for research and development (R&D), and intelligence agencies to analyze data for derivation of RWE. Eventually, PhRMA organizations Page 20 have to make strategic and business decisions on whether to roll out certain products to the market based on RWE, subjected to FDA approval based on outcomes of clinical trials. While the automotive industry is subjected to technology and product uncertainties, life science - is subjected to another uncertainty - regulation. Two recent but major regulatory legislations Obama-care and Unique Device Identification (UDI) integration - come into effect, demanding life science operators to meet compliance, yet encouraging them to coordinate internally with one another to sort out the technicalities. Obama-care looks to expand Medicaid coverage and expects operators' business model changed from 'Pay-for-service' to 'Pay-for-performance', cumulating to lower cost and increased efficiency for business. UDI integration, on the other hand, expects unique identifiers assigned to medical devices distributed within the states to improve patient safety and operators' accountability to their products and services. Both would organically lead to enforced changes on how product, services and customer information is provided. Dependencies with all stakeholders have to be regularly assessed in the dynamic operating environment, and changes have to be actively managed to attain desirable outcomes and respond to undesirable outcomes. This calls for a robust and effective management of changes. 2.2 Enterprise Transformation 2.2.1 Consulting for Integrated Enterprises Traditionally, enterprises in these industries seek reputed and branded consulting firms to change their enterprises for the better by diagnosing and solving problems whose scope are not yet defined. These solution shops delivered values primarily through judgments from their brand-name consultants and charged clients fee-for-service. With them operating in the cloak of opacity which hinder clients from gauging the consultancy services in advance or the delivered performance, clients select external help based on reputation and branding to develop an Page 21 enterprise network of communication and collaboration. However, as these industries mentioned earlier are on the "cusp of disruption", the increasing number and types of uncertainties had prompted these clients to rethink about how they should best engage the services of these solution shops. As access to data is more distributed and democratized to larger extent, opacity in the operation of consulting firms fades. The clients become knowledgeable about the work activities needed to be done, and look to segregate work between high-value services which these firms can provide and other activities most appropriate to other service-providers. By disaggregating consultancy services, clients can assign to predictive technology and big data analytics serviceproviders to deliver value much more efficiently. As the pace of "productization" increases with new intellectual properties, tool kits, frameworks, clients would seek "value-based pricing" (Christensen and Wang 2013). Figure 5: Consulting firms' business models (Christensen & Wang 2013) Page 22 The emergence of other business models other than the solution shop (Figure 5) and their possible disruption to incumbents prompted a rethink for consulting firms. Some recommendations for deviation from traditional solution shops drawn from literature review are: 1. Increase modularization of the services on offer to meet evolving clients' needs 2. Shift from integrated solution shops to modular providers by specializing in supplying specific links in the value chain drawn from client engagement 3. Focus on own boutique consulting services, offering advice based on specialization in research and data gathering 4. Assemble lean project teams to fulfill specific value proposition of clients 5. Conduct asset-based consulting through data- and analytics-enabled processes 6. Accumulate assets and processes with each successive client and reuse 7. Regular analysis and update of circumstances and data to maintain concurrency Although traditional incumbents have the human, brand, technological and financial resources to solve complex problems posed by clients and drive block-buster change management programs to address them, other emerging professional services provide client benefits in terms of speed and quantifiable output by automating customer relationship analysis or predictive technology. With consulting firms such as IBM, Accenture and TCS moving into this form of services, they would look to handle complex problems with quantifiable deliverables to their clients by supporting the latter in building dynamic capabilities for competitive advantage. This allows enterprises to better "sense opportunities and threats, to seize opportunities, and to maintain competitiveness through enhancing, combining, protecting, or reconfiguring a firm's intangible and tangible assets" (Teece 2007). It is also suggested that organizational processes be incorporated in enterprises to collect new technical information, tap environmental developments, monitor competitive markets, customer needs and benefit while creating new Page 23 products and processes. "Information must be filtered, and must flow to those capable to make sense of it."(Teece 2007) Especially for an integrated enterprise which preaches lean practice to their subsidiaries and partner units, more decentralization with greater local autonomy helps participants to respond better to market and technological developments, but are subjected to information decay as information flows within the hierarchy. Procedures and controls must thus be constructed in place to keep management informed(Teece, Pisano, and Shuen 1997). Consulting firms play a key role in providing tangible implementation approaches based on successful strategies to transform client enterprises from 'as is' to 'to be' state. 2.2.2 Enterprise Architecting Before consultancy firms are capable of realizing new or modified enterprise architectures to transform their clients' enterprise, the activities to define several architectures and evaluate these architectures for selection are prevalent in most firms' change programs, en-route to the delivery of the architectures to their clients. However, the approaches adopted by these firms can be highly differentiated. ANSIIEEE P1471-2000 As defined by ANSI/IEEE P1471-2000 that "architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and principles guiding its design and evolution"(Maier, Emery, and Hilliard 2000), architectural stakeholders and concerns, architectural views and viewpoints are of interest to the ANSI/IEEE P1471-2000 conceptual framework. The architect must consider the architecture from the standpoints of the users, acquirers, developers, and maintainers of the system, and address their "concerns" such as user needs, design constraints and corporate strategies. He should also model for multiple architectural views based on specific concerns and capture viewpoints to Page 24 analyze specific views (Maier et al. 2000). It is noted that ANSI/IEEE 1471 is methodindependent. The Open Group's TOGAF@ Figure 5-1: Architecture Development Cde Figure 6: The Open Group's Architecture Development Cycle TOGAF is more practitioner-oriented as it provides a framework with "a detailed method and a set of supporting tools" drawn from learning and contributions in multiple industries. It establishes enterprise architecture that covers entities in "information and technology services, processes, and infrastructure" (Welcome to TOGAF® Version 9.1, an Open Group Standard). Page 25 Its method - Architecture Development Method (ADM) - is iterative, covering the views of business, information system, technologies, and risks as shown in Figure 6. Especially of interest to this paper is the utilization of content metamodel in TOGAF where entities with their key dependencies are represented in traceability matrices (Scherer and Wimmer 2012), exclusive of the dark-colored boxes which represent the Unified Modeling Language (UML) diagrams (Figure 7). In place of UML, the paper suggests hierarchical control structures or value flow diagrams that can complement the usage of content metamodel in TOGAF. igure 7 :Content Metamodel with UML (Scherer and Wimmer 2012) Control structures allow viewing of change programs' stakeholders as entities within the architecture, the linkages between entities representing concerns. This captures the multiple views of inter-related stakeholders with their addressed concerns, and establishes viewpoints with specific references to different classes of stakeholders or interactions between Page 26 stakeholders. With this proposed structured modeling, it would support stakeholder theory in bringing core stakeholders together to cultivate the shared sense of creating value for businesses (Freeman, Wicks, and Parmar 2004) in either producing successful enterprises or developing products among complexity. While hierarchical control structures refer program stakeholders' actions to extending controls and receiving feedbacks, value flow diagrams are similar in term of exchange of values and "concerns". The paper will primarily use hierarchical control structure in this research, and only represent value flow in the format of matrices. Value flow is important to be represented as there is a prevalence of value deficiencies that are reflected as the discrepancy between the 'as is' and 'to be' state for an enterprise, driving enterprise transformation initiatives to address what work needs to be done by the enterprise and how to accomplish it; This results in change programs focusing on improving the performance of existing work, modifying the approaches to existing work or performing different work processes, with the last being most transformative (Rouse 2005). Additionally, enterprise transformation does not only apply to individual work processes but also relationships between processes. This demands the addition of process models in addition to control structures and value flow diagrams. Of significant note is how processes are described to be highly inconsistent and difficult to reuse due to the lack of knowledge in them, or uncertainties and misunderstanding towards them (Day and Lutteroth 2011), thus the modeling of process models using Rational Unified Process (RUP) for visualization and analysis. However, there are drawbacks: 1. Extracting information from enterprises return a low level of abstraction which results in modelers filling in substantial higher level of details 2. Missing details due to workers' internalization of details through routines Page 27 3. Does not show activities over time 4. Visual models saturated with entities and their relationships which make reading and scaling difficult 5. Missing context and relationships with other RUP roles While points 1 and 2 are challenges which modelers should manage continuously, points 3, 4 and 5 are mitigated by the approach proposed by the paper as discussed in the next chapter. Likewise, the need for hierarchical control structure is endorsed for ease of navigation and clear overview of the roles within the structure, which partially mitigates point 5. Nightingale Rhodes Enterprise Systems Architecting Nightingale and Rhodes further emphasized the holistic approach with Enterprise Systems Architecting (Nightingale and Rhodes 2004). The description of activities, processes, entities and the information flow required to support enterprise functions are represented holistically, and characterized in term of hierarchies. Specifically, processes are categorized as Life Cycle Processes, Enabling Infrastructure Processes and Enterprise Leadership Processes in Nightingale's Process architecture view of lean enterprise (Nightingale and Mize 2002), as summarized in Figure 8. Design of an enterprise demands the analysis of the "interrelationship and interdependencies" of all these processes. This might prove challenging to an IT consultancy firm which provides PLM system or software but its role is on realizing requirements definition, product development, information technology, organizational structure and integration, transformation management processes for its client enterprise. Page 28 nt iFocus Figure 8: Lean Enterprise's Process Architecture View (Source - Nightingale & Mize 2002) Enterprise architecture is defined as "the organizing logic for business process, data, and IT capabilities reflecting the integration and standardization requirements of the firm's operating model with the operating model being the desired level of business process integration and business process standardization for delivering goods and services to customers" (J. Ross, 2006). Processes are related and dependent on other enterprise entities such as strategies, information, knowledge, business model. These interrelationships needed to be analyzed would only increase exponentially, and are possibly unique to individual enterprises for integration and standardization of selected processes. This leads the paper to consider enterprise architecture as a system of high complexity as aligned to The Systems Architecting Working Group of the International Council on Systems Engineering (INCOSE)'s definition of architectures as the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors (INCOSE, 2000). A system engineering approach is thus considered and adapted for enterprise architecting in this paper. Page 29 Zachman Framework The earlier-mentioned Zachman Framework (Zachman 1999) provides a structural way of defining an enterprise based on its information system by asking fundamental interrogative words "who, what, when, where, why and how" to induce thinking and learning, and endorses the delivery of model artifacts in multiple perspectives of the planner, owner, designer, builder and programmer (Scherer and Wimmer 2012). As it is primarily a schema, there is a lack of clarity in "socio-cultural, functional, structural, infological and contextual alignments" (Magoulas et al. 2012). Enterprise Architecting Framework Summary The paper proceeds to summarize the enterprise architecting frameworks in terms of their useful applications and areas of improvement in Table 1. Framework ANSI/IEEE P1471-2000 Benefits - Aligned to stakeholder value theory - Focus on development and operating views of systems TOGAF - Operational with methods and tools - Focus on business, IS, technologies view for enterprise transformation Nightingale Rhodes' - Holistic representation of organizational and informational entities - Focus on dependencies between Area of Improvement - Practicality limitation due to lack of methods - Feasibility to apply to IS and enterprise transformation - Lack of specificity to stakeholders - Lack of focus on the interdependencies between organizational entities and stakeholders - Reactive to transformation outcomes - Limited in extending approach to complex enterprises due to scaling issue - Lack of specificity to stakeholders organizational entities Zachman - Focus on IS for enterprise transformation - Endorse organizational learning - Practicality limitation due to lack of methods - Lack of focus on the interdependencies between organizational entities Table 1: Benefits and Areas of improvement for Enterprise Architecting Frameworks Page 30 Consequently, the paper proposes a new approach in the context of transforming IS for an enterprise by incorporating the mentioned benefits in Table 1 and exploring options to resolve the mentioned weaknesses in the described frameworks. 2.2.3 Enterprise System Engineering The discussion of the available enterprise architecting frameworks leads the paper to propose system engineering for the purpose of enterprise transformation, in view of the frameworks' shortcomings. As such, the paper considers Nancy Leveson's STAMP, primarily a causality model that emphasizes promoting system safety based on system theory. Its adoption is found in accident investigations in the form of Causal Analysis based on STAMP (CAST) like the analysis of the 2008 Coast Guard aviation mishap for a HH-65 helicopter (Hickey and Hommes 2013) or System-Theoretic Process Analysis (STPA) - a system safety engineering design approach (Hommes 2012). STPA is selected as the method of interest over CAST as the paper attempts to study the effectiveness of using the former in designing enterprise transformation within the progression of change programs. However, the paper hypothesizes that CAST can be applied equally well in the analysis of a failed change program but that would not be the focus of this paper. The paper proceeds to describe STPA in Table 2: Steps Step 2 Descriptions - Construct the hierarchical control structure, with processes as connecting arrow, and actors as recipients or producers of these processes (Figure 9). Align control structure to closely match organizational structure or enterprise trqnfnrmaqtinn nnvarnqnrP structure. Page 31 Expand control structure containing potentic, ( ICA with process models. Identify mental models of controllers involved in potentially ICA. Pinpoint ICA by comparing actual process models with controllers' mental models Identify causes by tracing through process models and hierarchical control structure from inadeauate control action Doint. - - rable Z: Description 0t step-vy-step bIPA metnoa SYS11ENA DE%*E1LOPRAE3Yr esalbue comguuas SYSTEMO CPERAIDO(S Congress am and Lnogds teu GAe...kmt -aand~ Rapafta UoNermmSetSIaquitory Agesu lne Governmeut RagUIUkMy Agmecisa -- cttos Inkitry.. user AMOMCAne. L =Om. Iansurance Conpafies, Court. I I Come LAM *.=id..r..on 1AW.a IAccxkg USIrM AsAMs 00Uopent . 010es. Insfmnco Coanapemlss. ourts starKNdauIS AC4ida a L ..c.5..ft LuAM10, L.mi. Cass LOW Cami.p.... I mid mrw~do a "-io- -Cft change tapaaft COMWSMY MaMagaMvnt QU Reportds kaideul Msna.s Soty Stondaids I D=, .c SM03 Tmd iany RiskAMRUMa itSn -aaf ent %-"IY sr HuzrAfa~no 30 nzdA=*su I P-3- Ruprt PW Pwage~s I Wor Opwutuag Pfoodwus a opeimfig P100555 E4nu CIfmfor csswimc. Mamutctuin~g Iaind Amipuwas Oaauam.MatMas ~ Opratnu. Axacoeseopa Pftbkau rqpamf Opaug Azunpb Test ruqoimf iCMb~ft and mp aqtu1 Efmsa 6uon Andws ~I RUaeswult Iiralumd I ~ . I SOMURY PUIiY Standurds. ~ aska 535iumicbaEg I Iu W rcenuuaM Changzioqisur Pe~uaum Au~f Figure 9: Hierarchical Control Structure (Leveson 2011) Page 32 =1 CsOMal nt or Moterng lv.E"madn I ugMor atsim Conroiler inessga Chmnsu or adspatkuu)@ Inmaopiete. ineftective, or missing control action Imaulitam Inadequate or rmissing feedback Feedback Delays nadeqalae De rsyed operations Continer 2 Conff colm ~ atos incorrec I or no informa tion provikK qu Measm monte k&BWccu ~ onting Op Mfedentlied or Feedba ck delays Process oUtpu contributes to system hazard mc-of-range disataeace Rignr. 4.8j 1 Aaiaione of control laMws leading to hazarhd Figure 10: Classification of Control Flaws (Leveson 2011) The 4 ICA suggested by STPA in Table 2 Step 3 as demonstrated in Figure 10 are of interest to enterprise transformation due to its relevance to control of information exchange within the enterprise: ICA# Relevance to Information Action information activity or process is absent in hieracia ctrot itructore or process model. ICA2 Specific information that is supposed to be received by or sent to specific actors in hierarchical control structure or process model is received by or sent to incorrect actors. Page 33 ICA4 Information that is received or sent is suspended sooner than it is supposed to. The paper proceeds to explain the interactions between organizational entities based on the concept of alignment in term of harmonious interrelationships between any 2 areas of entity categories and within the enterprise as a whole (Magoulas et al. 2012). Organizational entities comprise of enterprise controllers, processes, functions, programs, information, and activities with regard to enterprise design, governance, and operation. The paper thus describes how STPA addresses the socio-cultural, functional, structural, infological and contextual alignments between organizational entities within enterprise architecture in Table 3: Alignment Socio-Cultural Alignment Benefits Requirements and constraints for business, IS, technologies on development and operating views of enterprise system are expected to be Area of Improvement Shared values, mutual goals are not directly communicated and aligned. Little practical guidance on alignment of stakeholders with requirements defined. and constraints. Functional Alignment Modelling of entities and associated processes within enterprise augment visualization for development and evaluation for generated architectures or solutions. Insufficient guidance how IT services are integrated into processes is aligned for subsequent implementation, as based on decisions and interpretation of development team. Structural Alignment Based on program's codification of responsibilities, roles of functional areas and relationships between these areas to provide overview and system boundaries, and if necessary, focus of details from associated process models. ICAs' identification focuses on quality of information to stakeholders and weaknesses of information flow. Infological Alignment Insufficient guidance regarding how information quality and availability should be defined to impact on communication outcome and capabilities of processes which are Page 34 Contextual Alignment Contexts are required to be defined in term of operating conditions and exceptions of enterprises for basis of interpretation for both current state and future state. Advocate regulatory, legal, ethical and discretionary viewpoints and equal emphasis on development and operation of systems. dependent on stakeholders' response. Advocate safety as emergence, and not program outcomes. Table 3: STPA Alignments in addition to Magoules et al. 2012 In Table 3, the paper reviews the benefits for STPA, and identifies the gap of STPA being a holistic system engineering approach for enterprise architecting. Infological alignment is defined as the efficient use of information systems and capabilities utilized in the enterprise to achieve the 'informational, transactional and relational' requirements for the stakeholders (Magoulas et al. 2012). The paper also defines socio-cultural alignment as the harmonious interaction of stakeholders to meet the enterprise's changing expectations. Both alignments are of interest as improvements on alignment of stakeholders with enterprise requirements and constraints, and dependencies of communication outcomes to definition of information actions are desired. These become the motivations for the adaptation to STPA, and the outcome is Enterpriseadapted STPA (ESTPA). For the rest of the shortcomings such as guidance how IT services are integrated into enterprise processes and focus on program outcomes, the paper predicts that the endorsement of change program to realize enterprise transformation adhered to the lean principles of 'Flow' and 'Pull' would provide an intuitive solution to improve them. Subsequently, the paper discusses about ESTPA, which is the resulting framework from adapting socio-cultural and infological alignment into STPA. 2.2.4 ESTPA Leveson suggests that quality can be another emergence property to be emphasized from using STPA (Leveson, 2011). Quality is an abstract attribute to achieve but it can be defined for Page 35 enterprise transformation by aggregating the needs of all participants involving in the development and governance of the enterprise. The paper thus assumes that quality can be perceived and measured against the values the enterprise stakeholders have defined. While change programs are constructed and advanced to realize enterprise transformation, the enterprise continues to fulfill its business obligation in product development or engineering. As such, the paper endorses stakeholder value theory (Freeman et al. 2004), and adopts STPA with the emphasis to assist change programs in defining values and achieving emergent goals through the process of enterprise transformation (Mcmanus 2005). This approach is necessary for IT consultancy firms which are guided by the lean principle of 'Value' in Figure 11. Manufacturing Engineering Value Visible at each step, defined goal Harder to see, emergent Value Stream Parts and material Flow Iterations are waste Pull Driven by Perfection takt time Process repeatable without errors goals Info n and Planned iterations must be efficient Driven by needs of enterprise Process enables enterprise improvement Figure 11: Lean Principles to Engineering (McManus 2005) Instead of the limitation in the bilateral communication between enterprise leadership team and consultants managing enterprise requirements, Modification A endorses a communication network that regularly engages all stakeholders that also include solution architects, process operators, development team, third-party suppliers based on their individual benefits derived from enterprise transformation programs. With these benefits and information of participating stakeholders codified and updated actively, the involvement of necessary participants ensures focus on the correct program value to be realized. Modification A eventually improves the sociocultural alignment in change programs using ESTPA. Page 36 Additionally, the consultancy firms rely on lean principle of 'Pull' to collect requirements and change interventions' verification, and lean principle of 'Flow' to analyze for controls and communication. The analysis of controls and communication is essential to ensure desired outcome for emergence (Hommes 2012). Originally, STPA focuses on the weaknesses of the information processes based on mental models of the involved controllers in the context of operational safety. However, this is lacking to define the desired or correct information processes as the mental models of the stakeholders are influenced by a disparate set of factors in human communication and communication technologies. Modification B adapts these guiding factors to identify design and operational flaws, and endorse correct information activities and reduce information waste with the endorsement of lean principle of 'Flow'. To explicitly relate the emergence of quality in the transformation of an enterprise to controls, communication and hierarchies, it is insufficient to derive solely from entities such as processes in information systems, process stakeholders, data, contexts et al. Modification B considers the dependencies of communication and enterprise outcomes to the arrangement of the information and information actors operating in the enterprise or IS. ESTPA is thus generated as the holistic framework for enterprise transformation utilized in lean change program, with the adaptation of Modification A and Modification B into STPA. Design and operational details would be forthcoming in subsequent chapter. 2.2.5 Summary This chapter acknowledges that there is numerous enterprise architecting frameworks available to propose solutions for enterprise transformation. TOGAF is popular due to learning from extensive libraries compiled from multiple industries, but the challenge is to focus on the relevant aspects of enterprise transformation. Nightingale Rhodes' framework implies a system engineering approach which follows system theory to provide a holistic view. However, Page 37 considering the explosion of information in 'Big Data' era, this framework faces difficulties in extending its approach. In view of the limitation in the methods of these frameworks or challenges to extend to complex programs, the paper considers the best approach in STPA, which is equipped with the described benefits of the frameworks, and has most of the described shortcomings mitigated. STPA is a causal analysis approach which explores the enterprise holistically as a system and focuses on multiple organizational entities. It uses hierarchical control structure to provide an overview of the system and identify potential flaws. Subsequently, it focuses on these potential flaws by looking into the details from the process models. Root causes of the enterprise's flaws are eventually identified. However, there are 2 major shortcomings that need resolution, so as to achieve inclusiveness of all stakeholders and clear definition of correct information activities for change programs. As such, new tools or methods are proposed to modify STPA's existing ones in the form of Modification A and Modification B. The end product from the literature review and research experimentation is eventually that of ESTPA, as adapted from STPA. Page 38 3 Lean on Change Program Management 3.1 Lean Change Programs 3.1.1 Change Management Models Introducing change interventions in organizations requires overcoming challenges to conflicts of stakeholders' interests, misalignment of mental models towards disruption of routine operations and gaps in availability of both dynamic and core capabilities among other. There are thus multiple change management models to provide guidance towards overcoming these challenges and achieving success outcomes of change interventions. Earlier, the paper had mentioned Teece's theory on the equipping of dynamic capabilities to build core capabilities as organizations triggering for transformations normally identify that they lack certain competencies and capabilities to act effectively in the market or to adopt certain new technologies. Some enterprises build their own enterprise transformation function within their organizations while others engage consultants, or enter into alliances, joint ventures or partnerships to oversee the necessary transformations. All these change functions are expected to build or be equipped with dynamic capabilities, so that they can move to the next step of building core capabilities for enterprises. The next challenge comes from understanding and adapting to the existing mental model of operators and stakeholders within enterprises and change function actors. One is equipped with a mental model on how routine work should be performed or how a decision should be made. This is necessary to interpret subjects of interest with fundamental assumptions and goals. However, with the introduction of change, works may have to be performed differently and decisions may have to be made with different contexts, altering the behavior of the enterprise systems so as to overcome market and technological challenges. Without the conciliation with Page 39 their current mental model, organizational actors become insensitive to these change interventions, and attempts to change fails (Forrester 1995). Works performed by the organization are essential to be modeled by process models, together with the consideration of controllers who exert control over these processes and receive feedback. Critically, these controllers are equipped with a mental model on how works should be performed (Leveson, 2011). manufacturing and construction variances evolution and changes over time ACTUAL SYSTEM original design spec Designerdeals with ideals or averages, not constructed system operational experience operational DESIGNER'S MODEL - procedures,-* OPERATOR'S training MODEL Operators continually test their models againstreality Figure 12: Relationship between Mental Models (Leveson 2011) The complexity for change intervention emerges when the mental models of the designers that introduce changes and operators that act under the constraint of these changes require alignment. This alignment in the form of operational procedures and training (Figure 12) is necessary to speed up understanding the inherent change interventions to make the transformation live sooner. There is the motivation to analyze and align both perspectives of Page 40 designing changes and operating the generated or transformed function in change programs, so as to speed up the learning process of the transformed enterprise. Another approach to complement this would be to allow the enterprise to focus on the hierarchical structure to improve its clients' economic value while not contradicting on the goal of transforming culture. This essentially allows its leadership to drive changes from upstream and engage actors to support transformation downstream (Beer and Nohria 2000). Peter Senge's 5 Step Model of Learning Organization Peter Senge's 5-step model of learning organization is one change management model that supports this concept. By using systems thinking as the fifth discipline to integrate the other four disciplines - personal mastery, mental models, shared vision, team learning (Senge, 2006), it endorses organization learning for continual improvement in enterprise operation. While mental models and shared vision are discussed in some details in this section, team learning is also critical to facilitate collaboration among team members and peers to pool competencies and experience. As the team structure is further decomposed, the personal level for own selfdevelopment is next described as the driving force to create knowledge and information that can be translated for utilization within organizations. All these culminate to the generation of new competencies that meets goals of the engaged enterprise. However, there is criticism of Senge's theory being restricted to learning of employees within enterprises, but ignoring the possibilities of change functions in external consultancies or joint ventures to realize transformation. Other criticisms includes the theory lacking practicality in industrial application, and specificity in the improvements necessary for specific sets of enterprise actors despite showing promises in its categorization of actors into structural teams or discrete units. Page 41 Kotter's 8-Stage Change Management Model Figure 13: Kotter's 8-stage Change Management Model (Kotter ZUU7) While Senge's change management model focuses on short-term results of transforming enterprises, Kotter's 8-stage change management model (Kotter 2007) is showcased in explicit, generic guidelines (Figure 13), and broadens its scope to include phrasal enterprise transformation process. Kotter's gives additional perspectives on: * driving urgency for initiating changes to current status quo, * assessing enterprises' transformational needs outside the boundary of existing hierarchy, * communicating through available and possible channels, * removing obstacles in organizational structure, Page 42 By encouraging quick wins as bouts of motivation during the change journey and instilling organizational habit for consistent changes aligned with transformation vision, the model eventually aims to consolidate the transformation into the fiber of organizational culture. However, instructions could have been dispensed as to how employees involved in the operation of the integrated enterprises can be directed to execute the right actions and evaluated justly. The paper considers for change management models for integrated enterprise, whereby consultancy firms play critical transformation roles during the duration of the change programs. Both change management models are evaluated for the purpose of constructing a better approach for consultancy firms to apply change programs. Subsequently, Table 4 summarizes the benefits and areas of improvement from these considered change management models, so as to incorporate them into a more suitable approach for driving change interventions. Model Senge's 5step learning organization Benefits - Endorse improvement of individual skills to build organizational capabilities. - Acknowledge alignment of stakeholders' mental models necessary to achieve successful change interventions' outcomes. Kotter's 8stage change management model - Consider for phrasal introduction of explicit change interventions. - Cultivate inclusiveness of all stakeholders to maximize program outcomes. - Encourage adaptability for constant Limitations - Insufficient guidance for externally-led program to drive change activities. - Lack of awareness of organizational entities' configurations specific to individual stakeholders for leaming focus. - Limitation in application over complexity within actual industries. - Insufficient guidance for directing actors to proceed correctly and being evaluated accordingly. - Generic guidelines with no specific industrial focus or lessons learnt. but necessary changes. Table 4: Benefits and Limitations in Change Management Models Page 43 3.1.2 Lean Principles for Change Programs In Lean Thinking (James P. Womack, 2003), the lean principles are distilled down to 5 principles in identifying value, mapping the value stream, creating flow, establishing pull and seeking perfection into 5-step iterative thought process for guiding lean implementation (shown in circular loop in Figure 14) while the paper proposes a modelling and analysis technique in ESTPA (shown in circle radiating outward in Figure 14) to complement the lean implementation technique. 1. 2.Map Identify the Value Stream value 3. Create Flow 5. Seek Perfection Establish Pull Figure 14: Lean ESTPA Identify Value The first step of specifying value is critical but not limited to customer value, thus the theory of stakeholder value (Freeman et al. 2004). Organizational transformations are expected to be triggered from within the changed enterprises, as every stakeholder within the organizational system has a role to play and benefits from doing so. This determines consultants who are employees of external consultancy firms to be involved and immersed in their clients' operations to identify value for organizational transformation within the integrated enterprises. An overarching strategy called the "value agenda" defines the value-based organization as exemplified in the proposal for patient-centric health care delivery with the involvement of board Page 44 members, patients, health plans and employers (Porter and Lee 2013). The paper likewise proposes a similar holistic concept to identify the multiple stakeholders and their values or benefits from the transformation of the organizations. Furthermore, this approach adapts the technique used in Hoshin Kanri policy deployment (Tennant and Roberts 2001) proven to work in strategic management for engineering firms . It directs continuous improvements by iteratively identifying the scope for improvements in the milestones, seeking the right people for actions and detecting the outcomes from the targeted improvements (Figure 15). As these organizations are functionally active , the planning needs to be integrated with their current operations to minimize disruptions. Effective vertical and crossfunctional communication is thus essential and is also the foundation for this iterative planning. ,A ~ro" 1 9 B C D el - e --~1~-------~,,_--.,_--~,....--~-~----------- · 0 ~:: 0 0 0 0 ·..· 0 - =~) Q<Ave O.· 'o ·.·. o·. 0 . ••• ·~== · e e ee e S _· ._ 2 - <8thJ w >~ . o. , ~ > 60 w <- ~ . . . o o o o . Figure 15: Hoshin Kanri monthly review (Tennant & Roberts 2001) While organizational vision is constructed and consistently communicated by the enterprise's senior management team to everyone within the organization structure, consultancy firms Page 45 driving change interventions in integrated enterprises do so by dedicating their communication efforts through organization leaders who convey to enterprise actors. This means that these leaders' involvement in change program's design leading to enterprise change plan and pilot execution is necessary, as consultancy firms normally do not have direct access to or feedback from enterprise actors. However, this process by which consultancy firms collect enterprise requirements and identify work activities for changes brings ambiguity for the receiving actors who are supposed to execute according to organizational needs. As such, Modification A is proposed, and consists of the step sequence in Table 5: Step Step Step Step Step 1 2 3 4 5 Step Step Step Step 6 7 8 9 Create a vision for an overview of the change program Devise strategies or policies to achieve the vision Identify the associated objectives or goals in milestones that the program strives for Determine the actions needed to attain these milestones Determine measurable outcomes and effects from these actions, and reaffirm that they are applicable to attain strategies and policies Identify the stakeholders for the change program Determine the benefits to stakeholders derived from milestones Allocate the needed actions to the stakeholders Review all information through X-matrices Table 5: Step Sequence for Modification A Step 1 to Step 5 is represented in X-matrix to show the necessary associations between strategies/policies and objectives/milestones, objectives/milestones and target actions, actions and outcomes/effects, outcomes/effects and strategies/policies. The matrix is named as 'Solution Objective Matrix' or SO matrix by TCS with an example in Figure 16, and is originally utilized by consultancy firms to collect requirements from and establish agreement with clients for planned delivery of changes. However, the intrinsic actions defined for the integrated enterprise by developers and the outcomes that are supposed to emerge are not tightly coupled, leading to lack of clarity to actual deliverables. Page 46 Figure 16: TCS's Solution Objective Matrix Considering the complexity of the integrated enterprises or the change programs of interest, it is essential to acknowledge multiple stakeholders with their "amalgam of complex motives and interests" and critical to comprehensively identify stakeholder values and needs. Objectives are to be structured and reworded for clear representation to individual actors, with possibly weighing factors developed according to importance to program success (Rebentisch et al. 2000), as structured in Figure 17. So while maintaining the original SO matrix, Step 6 to Step 9 in Table 5 is adopted to focus on specificity on organizational elements, and shows the necessary associations between objectives/milestones and stakeholder benefits, stakeholder benefits and stakeholder roles, stakeholder roles and target actions. The paper names this X- Page 47 matrix as 'Value Matrix' (Figure 26) that subsequently constructs the proposed hierarchical control structure. Figure 17: Definition of objectives from stakeholder needs (Rebentisch 2000) Map the Value Stream Next, the paper proceeds to identify the value stream in lean change programs for PLM. While Value Stream Analysis (VSA) is commonly applied to examine business processes based on lean principles, Value Stream Mapping (VSM) is the modeling tool to represent the analysis outcomes of VSA. McManus' VSA (Mcnmanus and Millard 2002) has placed much emphasis on process mapping and value stream mapping but acknowledged that they "tend not to provide much insight into process improvement over high-level representative mapping". Instead, the paper proposes ESTPA which uses control structure and process models in tandem for analysis. By encouraging consultancy firms to adopt the ESTPA framework in their change programs or enterprise transformation frameworks, the paper explores scenarios when stakeholders would receive a better interpretation of where the processes and their dependencies stand in the Page 48 whole enterprise and how data is consumed and generated in this Big Data era. Within the hierarchical control structures, the dependencies defined between information processes also allow explicit and concise presentation to both designers and operators alike, aligning mental models. However, McManus also emphasized that the top challenge in VSA/M process is the data collection on the current state of the process, with 3 levels of depth identified in the PD case studies being "mapping activities and inputs/output, capturing metrics and characteristics of each activity and consideration of activity value". This will be further explored in subsequent section for Modification B. Create Flow While the earlier section is more concerned about eliminating waste and non-value-added, creating flow is to focus on doing things efficiently. Alternatively, the former is about doing the right things, and the latter doing things right. Communication between actors and business processes within the enterprise structure is thus critical as it represents the handing-off of information and knowledge between actors and processes. Modification B is utilized to identify weaknesses in information flow, with the condition that the right sequence of processes and involvement of actors are identified during the value stream identification. Further exploration would be forthcoming in a subsequent section. For information systems (IS), the activities of standardization and integration of business processes are recognized as tools for creating flow (J. Ross, 2006), and acknowledged as necessary for business processes. Improvements can be achieved for multiple actors utilizing the same processes and for multiple processes to draw data from and send data to focal locations. Additionally, with outcomes from analysis on existing IS through high-level control Page 49 structures and detailed process models, it is feasible for actors to identify their tasks, processes and their dependencies while reducing efforts in familiarization of new IS. This view of the entire flow of value-creating activities would position consultancy firms to evaluate the impacts of proposed changes and better redefine their processes and information flow to the needs of the stakeholders along the points of the value stream. This would be of use for iterative evaluation of original state and changed state while getting value to flow faster in changed state, and exposing hidden waste within the value stream (James P. Womack, 2003). Establish Pull Traditional lean principle of establish pull is to let customers pull value from upstream activities. However, as we define there are more stakeholders than only the customer when identifying stakeholder value, establishing pull for change programs is about allowing upstream stakeholders to pull value from downstream stakeholders or activities. The communication matrix or hierarchical control structure is thus in place for regular or continual interaction, so that customers' needs can be attended promptly to trigger evaluations and actions, and suppliers of IT tools and software can notify relevant users of improvement and emerging risks. Various business units are placed in a collaborative environment when uncertainties both positive and negative bring opportunities for changes not only to a single business unit but to everyone within the hierarchy. This is also critical as when needs change due to the uncertainties in the consumers' work and competitive environment and demand actions, the upstream stakeholders can operate and respond with focus instead of chaos, each aware of their roles and their dependencies to others. This eventually brings to the last lean principle. Page 50 Seek Perfection Seeking perfection is a continuous process by itself as it links back to the lean principle of value to form an iterative loop (Figure 14) for lean thought processes. This equips stakeholders with the awareness of their operating environments and the context of their change activities, and provides confidence to respond to proposed technologies and concepts in the aim of eliminating information waste and optimizing activities. It also acknowledges what fits back to the value directed by strategies and policies, and what does not. Despite the notion of strategic fit and the focus among the myriad of distracting opportunities facing enterprises, seeking perfection is not just about reacting to the business contexts. That would have meant the change program being always one step late in delivering to the actual needs of the current business environment. Hayes and Pisano provided a better insight on this view based on manufacturing strategy (Hayes and Pisano 1996). First, focus on processes creates reciprocal risk as different actors specialize on their processes but would not understand how different processes fit together. The approach proposed by this paper is deemed holistic by endorsing process models for actors to focus on their processes but also control structure to fit processes together at a higher level of representation. This positions enterprises and enterprise actors to better respond and adapt to introduction of new technologies or changes. When certain skills are necessary and need building, existing processes and process sequences can assimilate these new capabilities or building of new capabilities. Secondly, enterprise transformation involves path dependencies which dictate the sequence of moves as transformation progresses, thus reducing the number of options for future changes. The paper's method provides the platform to evaluate how change might affect its ability for future changes when considering changing specific structural and organizational entities. This Page 51 form of flexibility - system performance characteristic and strategic flexibility - is one quality or emergence that the proposed ESTPA is seeking to achieve perfection. Overall, the paper appreciates the lean change management concept based on lean principles and evaluation of better-known change management models. Table 6 identifies the motivation for integrating ESTPA into lean change programs. Lean Principle Identify Value Benefits How? - Acknowledge alignment of stakeholders' mental models necessary to achieve successful change interventions' outcomes. - Cultivate inclusiveness of all stakeholders to maximize program Specify the program benefits valued by specific stakeholders and whether they are aligned to the individual or team motivation and organization vision. outcomes. Map the Value stream - Aware of organizational entities' configurations specific to individual stakeholders for learning focus. Create Flow - Guidance for directing actors to proceed correctly. Establish Pull - Guidance for externally-led program to drive change activities. Seek - Consider for phrasal introduction of Promote a culture to analyze over the Perfection explicit change interventions. aggregation of all organizational - Encourage adaptability for constant entities to identify risks for change but necessary changes. interventions. Codification in value matrices, hierarchical control structures and process models allows overview of own activities and also dependencies with other collaborators. Removal of wasteful information actions and redundant communication after identification via process models. Ensure occurrence of regular meetings with customers to enhance participation of change interventions and feedback on outcomes. Table 6: Benefits of Lean Change Management Approach While the paper does not explicitly explain the lean change management approach would improve on: " Individual skills to build organizational capabilities, and * Feasibility on applications over manufacturing industries, It is presumed that program managers should drive training and knowledge transfer, and codify lessons learnt from experimentation of this approach in their industries of interest. Instead, the Page 52 focus of the subsequent research is on investigating change programs according to the lean principles of 'Value', 'Value Stream' and 'Flow', and the role of the program managers is important to drive lean practice in change programs. 3.2 Lean Management 3.2.1 Managing Change Programs The paper introduces Lean based on above 5 Lean Principles and extends the discussion to a management approach - Lean Management. As much as the earlier focus is about optimizing the delivery of value for change programs, eliminating or minimizing waste is the topic of concern for this section, and of critical consideration for actions by program managers and management executives. Oehmen and Rebentisch (Rebentisch and Oehmen 2010) thus recognized that to be lean, product development has to focus on the transformation of information in the identification of waste, resulting in 8 categories of waste (Figure 18) similar to Taiichi Ohno's Lean Production. Page 53 Figure 18: Eight Types of Waste in Lean PD As this is not about more products being digitized nowadays but more processes being so, the paper looks at the influence of information waste in process development. Over production of information occurs when information is delivered unnecessarily or too late to be useful. This demands that the receivers filter and interpret received data in an attempt to derive meanings, and is considered as waste for these efforts. Over processing of information is different to the previous as it refers to the contributors spending unnecessary time to "re-invent the wheel", process defective information which eventually needs discarding, convert incompatible data or simply add too much details beyond specifications for their outputs. Miscommunication of information happens when there is a change of ownership due to handing over of responsibility for information in the form of "hand-offs" or unclear assignment of authority, when there is Page 54 existence of organizational and process barriers, when there is existence of barriers due to ill equipped with knowledge for receivers to handle the information, or when there are interruptions from re-communication, understanding processes for changed information, multi-tasking and task switching. Stockpiling of information refers to the build-up of information inventories, but considers less critical as waste if presuming that storage space for information is of minimal cost and stockpiling information is for the purpose of future value-adding for other programs. However, a more critical concem is over-utilization of capacities in the program actors which lead to delays due to them not being able to process incoming information. Generating defective information is about waste generated from producing defective, obsolete deliverables in parts or final products, and information-sharing malfunction. Correcting information considers for waste associated with repairing, reworking or scrapping as a whole, and additionally accounts for checks for the subsequent re-generation of information. Waiting for people accounts for waste from value stream not flowing due to idle processes from scheduled wait time in activities or unscheduled waiting. The last is the unnecessary movement of people to indicate wasteful efforts to obtain information due to deficiency in existing information systems or inaccessibility of information sources. These eight wastes are summarized over the activities of program actors receiving information, producing information and responsible over quality of information in the form of quality audits and checks. These information activities are subsequently displayed in Figure 19 right-sided diagram for infological alignment, with individual at the head of the unidirectional arrow receiving information and the individual at the tail end of the arrow producing that information. On the same diagram, the bidirectional arrow represents the activity of being responsible over information quality with the individual at the higher position being the responsible. While each individual is determined more of a receiver over a contributor of information from the arrow Page 55 representation in hierarchical control structures, the eight wastes determine the information quality and the rate and volume of information transferred. This covers the 'information' aspect of infological alignment, when the paper sets constant the 'technology' aspect for future research extension. While infological alignment provides a good overview between multiple associations between program actors and information or data represented in hierarchical control structure (Figure 10), and identifies possible weaknesses in change programs, it can be found lacking for detailed analysis or identifying control flaws. As process innovation is the focus for change programs targeting enterprise transformation, the associations between program actors and processes can be identified and integrated for a holistic approach in change program analysis, and verification of findings from this paper. The associations between program actors and processes are also reinforced by Leveson's process model (Figure 11) with consideration of actors' mental models to determine on the quality of the information processes. While empirical research has revealed communication in complex product development being influenced to different extents by different factors such as organization, project, individual, information and product (Maier et al. 2008), the paper identifies communication in process development in change program to be influenced by organization, program, individual, information and technologies providing the processes. Socio-cultural alignment, with the focus on harmonious interaction of stakeholders to meet the integrated enterprise's expectation, is thus influenced by the communication within the organization either the consultancy firm or the client enterprise, within the change program governance and self in Figure 19 left-sided diagram. Page 56 Program Adopted technologies I ii~ii [rcIJ c Figure 19: Factors of influence for Socio-cultural and Infological alignments Elaborating on the context of socio-cultural alignment, the paper recognizes the existence of different factors - organization, program, individual - that can influence the alignment outcomes with regards to the mental models on how the existing processes should be adapted and how to operate new processes. The different factors of influences from organization, program and individual agendas would drive variations on how one accommodates processes or the lack of them to arrive at an outcome that can be unexpected and even undesirable. As such, these factors need to be aggregated as a whole for analysis. The paper recognizes that individuals have different motivations and wish to derive different benefits in performing their information activities. Instead of the value matrices which indiscriminately list down all benefits, the paper categorizes these motivations and assigns to benefit-distinct groups - organization, program, individual - who may share same actors. This implies that apart from individuals having their own motivations, they also strive for some similar Page 57 benefits with other actors in the same group (Figure 19 left-sided diagram). This helps to focus for the purpose of basic analysis for socio-cultural alignment in this research. Below is the list of basic motivations in consideration for this paper with primarily most of them extracted from Maier (Maier et al. 2008). Socio- Factors of Influence cultural Influence Category Organization Program Individual - Endorse Hierarchical organization structure - Support Standardized Process - Assign Clearly Defined Role to employees - Active Communication maintained with employees - Decision Transparency from Senior Management or supervisors - Communicate a Clear Vision to program participants - Assign Clear Objective for execution - Mutual trust for decision-making and driving actions - Have Task Overview and aware who is expected of oneself - Autonomy in applying decision and actions - Encourage Innovation in self-modification of current work status - Motivated to work and be involved in process Table 7: Factors of Influence for socio-cultural area of influence These factors are thus considered areas of influence to the mental models of actors applying the processes within the proposed process model, as aligned to Leveson's. Based on the 5 categories in socio-cultural and infological alignments, the paper proposes a survey format in Appendix B. Structuring the survey in this format has its benefits. First, it can extend to represent multiple functional groups in the hierarchical control structure but can also focus on underlying elements such as actors and information without losing specificity. Secondly, as the effectiveness of change management is determined by 6 activities in leading, communicating, learning, measuring, involving and sustaining (Merrell 2012), the structure of the survey includes factors necessary for these activities, and thus extensible to the proposed process model. Lastly, this survey methodology provides the detailed "socio-causal complex" that is used to explain the specific behaviors and cultures of the actors internally, interrelated with their dependencies or Page 58 influenced by their environments at development and operating levels (Nastase, Giuclea, and Bold 2012). Considering that people make changes from current state to reach their desired state, it is of relevance to this paper to identify the discrepancy between current and desired states for specific actors, so as to verify mis-alignment of value and evaluate their motivation for acting in the change programs. 3.2.2 Process Model Used in Analysis While Figure 7 is one representation of process model, the paper explores an alternative or adaptation that fits better to ESTPA for detailed reproduction of enterprise architecture, ability to extend from hierarchical control structure and representation for identification of potential flaws in processes. The process model would be constructed based on these 3 objectives. To match these objectives for ESTPA, the constructed process model needs to be useful for gap analysis, "hazard" analysis and causal analysis. Gap analysis is commonly applied by consultants to review enterprise requirements and constraints, and map requirements to responsibilities. The IT Value Creation Cycle considers enterprises driving strategic value from IT to 'commit' business and IT resources according to these strategic priorities (Ross, Beath, and Quaadgras 2011), and determines 'exploit' activities like process integration and standardization as major decisions IT executives need to make to meet these requirements (Figure 20). It is thus critical to identify human controllers and the processes to assign to them, so as to improve on articulation of strategies in operational language, and dedicate business transformation to enduring propositions. Layered models with actors, processes, data and responsibilities in each layer (Figure 7) are thus prevalent for their reproduction of existing enterprise architecture to provide detailed and elemental information. Page 59 Coordination * Unique business units with a need to know each other's transactions * Examples: Commonwealth Bank of Austra, MeCe, Aetna * Key ITcapability: access to shared data, t1hough standard technology interfaces Unification Single business with global process standards and global data access a Examples: southwest Airlines, Dow chemical, Intel manufacturing . m Key IT capability: enterprise systems retnforcing standard processes and proam i ng global data acess Replication Diversification e Independent business units with different customers and expertise . c rExamples: Johnson &Johnson, Paific Life, ING . Examples: DIRECT m lKey IT capability- prmide economies of scale without limiting ndepeapnce Independent but siilar business units sharing best practice srreott, 7-Eleven Japan, ING Key ITcapability: provide standard Ua re and application infrasew components for globl eficiencies Figure 20: 4 Types of Operating Models (Ross, Weill, Robertson 2006) On the other hand, hierarchical control structure is used in "hazard" analysis to identify problematic control actions and programmatic risks defined in Figure 11. While control structure is useful to give indications of possible areas of weaknesses, process models are required to be extended from control structure and inputted with more details to identify specific elements that contribute to these problems. Also, similar to the concept of service-oriented architecture (SOA), modularity is exhibited in the proposed process model so that cross-system processes connecting to functionalities can adapt to new goals from organizations by assembling them in different fashions (Rettig 2007). However, the challenge is to identify potential flaws in processes and perform causal analysis. While it seems reasonably easy to identify required control actions not provided or incorrect control actions, identifying 2 other potentially inadequate control actions - control action out-of- sequence too late or too soon, and action stopped too soon - are arguably more difficult either in the perspective of value matrix or hierarchical control structure. Time would tell when flaws in Page 60 the enterprises emerge from improperly-designed enterprise architecture which initially looks right. As the enterprise operates in the dynamic environment, it would be subjected to stress, leading to emergence of degradation scenarios. Performing causal analysis for all these potentially inadequate control actions would be possible with ESTPA Step 5 for employing both time-conscious and ESTPA's tools. With consideration to all 3 objectives, the paper introduces Modification B to ESTPA with the inclusion of adapted process model to facilitate these analysis expected of ESTPA. With the norm of representing associations between processes and information for process models maintained, the proposed model is adapted to include representations for associations between actors and information found in hierarchical control structure, and between actors and processes defined in Figure 11. The association between actor and information is defined as a subset of the association between actor and process, or specifically the association between actor's mental model and process. ental Modd Process Responsible/ Contributing /ftotnied information Figure 21: Building Block for Process Model Figure 21 displays the discrete unit of the proposed process model, consisting of the process, actor and information in one building block. The dashed line between actor and process is to indicate the indirect dependency while the solid line between actor and information is to indicate Page 61 the explicit dependency. This is aligned to the concept of creating viable aggregate views that provide a compact representation for the different layers of entities and relations while maintaining visibility of essential complexity (Kreimeyer 2011). Represented processes in the proposed view can be further decomposed into functions and tasks to facilitate software simulation, but it would not be the focus for this paper. Instead, the paper aims to verify the identified process flaws from the associations between actors and information by confirming the findings through the survey defined in Appendix B. Modification B is, through the study of the adapted process model, to identify discrepancies between the expected information flow and actual information flow. This is to indicate missing flow in between processes or activities, or incorrect flow based on enterprise requirements. By adopting this methodology which promotes modularity and complexity, existing processes from readily-available enterprise software and networking technologies can be scrutinized, changed and constructed in different permutations to achieve process standardization at multiple locations and ease of propagation of new work flows. As actors are identified as sources of knowledge or information, and are represented explicitly, this also facilitates executive decisions for process integration by recognizing duplication of data sources or fragmentation of processes consuming data. Both process standardization and integration triggered by organization executives or consultants account for process innovation within the integrated enterprise. Change programs are thus equipped with the capability to enable lean changes and improvements in enterprises' operating models. Apart from being well-equipped with tools to realize lean management, change program management demands a proper approach to utilize these tools to direct changes in enterprises. Page 62 3.2.3 Change Program Management Program managers and consultants looking to realize changes within enterprises through change programs would do well to focus on 2 major aspects of change management: Change control and Change Leadership. Change control is commonly the focus for mainstream change management practice. Integrated change control process adopted by mainstream practice * identifies whether a change needs to be implemented, * determines and compiles the necessary factors that can contribute and implement the needed change, * evaluates and approve the change requests, and * manages the progression of change activities. With the benefits of regularly and actively monitoring the enterprises for unauthorized changes, and identifying and recording consequence from intended or unauthorized changes for review, this process leads to the prevalence of change control board (CCB) as a function within enterprises or integrated enterprises to control changes by addressing the triple constraint of project management - budget, schedule and scope. Change control remains essential as process innovations do not necessarily originate from headquarters or senior management but emerge organically from the lower levels of the enterprises, and tend to flow to great benefits without central management direction (Mcafee & Brynjolfsson, 2008). As such, senior management such as Chief Information Officer (CIO), IT managers and program managers should put in place change management policies that implement the necessary controls and receiving of updates, so that enterprises would respond to the business needs regularly and actively without eroding user satisfaction or acceptance (Melancon 2007). However, change management cannot be effective with only emphasis placed on change control. Change leadership is defined as the other side of change management that constructs Page 63 the strategies to improve acceptance to changes, and is referred as deriving a set of techniques and activities to internalize implemented changes into an enterprise structure so as to reduce staffs' inertia to changed operations (Griffith-Cooper and King 2007). However, empirical studies have revealed that less emphasis is placed on change leadership compared to change control, as traditionally, enterprise leaders initiate changes and respond only when undesirable outcomes emerge, leading to constant firefighting. Consultancy firms assisting these enterprise leaders provide solutions for continuous improvement through process innovation within their enterprises, but often do not offer options to detect and remove hurdles at each phase of the change process. This makes it difficult for CIO, IT managers or program managers to manage risks and focus their mitigation actions to optimize resolution outcomes. Change leadership is supposed to resolve the mentioned drawbacks by engaging leaders and staffs in collaboration to build and realize change. By maintaining bilateral communication between upstream and downstream actors throughout all phases of the programs, a robust communication model for change leadership is endorsed to provide ownership and shared meaning to all actors, and is managed to handle complexity necessary to represent all communication points. Codification of the communication matrix also happens to provide a common language for all actors to manage their activities by assuming responsibilities, requesting feedbacks and providing information and knowledge. This allows leaders to orchestrate the running of their functional groups without fuss. Eventually, this provides anticipation of potential failures and encourages responses based on informed facts during the dynamic phases. By emphasizing on change leadership, the paper is not proposing program managers to study every facet of their change programs, but to equip with an overview of their programs, focus on their objectives and milestones and ensure others do so as well, manage program dependencies and risks, and plan accordingly, regularly and actively. Page 64 Findings of the Joint MIT-PMI-INCOSE Lean in Program Management Community of Practice have identified 10 themes for major engineering program management challenges, and 43 Lean Enablers with 286 subenablers to overcome these challenges and lead to better outcomes (Oehmen and Et 2012). However, it can be daunting for program managers or actors who wish to look through these 286 enablers to generate the necessary mitigation plan. Based on the context of the analysis approach, the paper filters down to only ESTPA-associated Lean Enablers in Table 8: # 1.6 Overview of ESTPA-associated Lean Enablers Encourage personal networks and interactions 2.1 Establish the value and benefit of the program to the stakeholders 2.2 3.1 Focus all program activities on the benefits that the program intends to deliver Map the management and engineering value streams and eliminate non-value-added elements Ensure clear responsibility, accountability, and authority (RAA) throughout the program from initial requirements definition to final delivery Pursue collaborative and inclusive decision making that resolves the root causes of issues Integrate all program elements and functions through Program Governance 4.2 4.5 4.6 Table 8: ESTPA-associated Lean Enablers (Extracted from Oehmen & et 2012) The paper is not eliminating the possibility of program managers identifying lean enablers outside Table 8 to overcome their programs' challenges. Instead, it predicts that program managers adopting ESTPA would intuitively derive lean enablers listed in Table 8, without painstakingly reviewing all available enablers. Generated changes associated to enablers would be based on business requirements and changes identified at the current stage of enterprise transformation for the enterprise of interest. 3.2.4 ESTPA in Lean Management ESTPA, generated from STPA with the adaptation of Modification A and Modification B, is proposed to best analyze enterprise transformation. By mapping ESTPA onto the lean approach in term of socio-cultural and infological alignments, the paper is operationalizing an analysis Page 65 approach through one of the best known practices to achieve best enterprise transformation outcomes. h2. Map 1. Identify Valuethe Value ValueStream Create Flow 5. Seek Perfection Establish Pull Figure 22: ESTPA in Lean Program Earlier, the paper identifies the value matrices proposed by ESTPA hard to scale in the representation of enterprise transformation to align with stakeholders. Instead, the paper introduces an approach based on the lean principle of 'Value' to focus on shared benefits of stakeholders belonging to same categories of actors that can possibly extend to cross-functional teams. These benefits are thus aggregated and registered within the value matrices of ESTPA. This explains Figure 22 ESTPA Step 1's inward direction of 'Identify Value' to ESTPA for using the inputs for further analysis; the direct outputs of ESTPA are the 'value stream', and 'flow' with the elimination of waste actions through the assistance of ESTPA Step 2 and Step 3 in model Page 66 generation. While collecting valuable feedback from clients about change proposal and predicted outcomes from change interventions for execution of ESTPA Step 4, the lean principle of 'Establish Pull' is established by aligning changes with all impacted stakeholders. Execution of ESTPA Step 5 ensures that change interventions generated from ESTPA are aligned with the mental models of enterprise actors, so that the integrated enterprise achieves a sufficient level of readiness before change interventions are deployed to maximize success outcome. The result is the approach introduced to TCS in Figure 22 for evaluating TCS's change programs on PLM development in integrated enterprises. Additionally, this paper recommends 2 internal iteration cycles LI and L2 for future consideration. The Li cycle requires that consultants iteratively evaluate recommended changes simulated in the flow and collect feedback from stakeholders for further analysis using ESTPA, before the final change intervention is properly designed and reviewed to minimize failure risk of leading change. This is recommended for TCS OCM process. The L2 cycle demands that the motivation and needs for the change program are regularly checked based on stakeholder value theory and evaluated, before going through act of 'seeking perfection', so that concurrency for the transformed enterprise is constantly evaluated against its dynamic environment. On top of that, it could be beneficial in term of efficiency for evaluators to execute L2 cycle than the whole ESTPA cycle in lean programs, so as to maximize return from resource limitation. For appreciation of this approach and validation of analysis outcomes, TCS is engaged for empirical study. Page 67 4 Research Overview and Methodologies 4.1 Research Procedure 4.1.1 Research Hypotheses The paper identifies some available enterprise transformation frameworks nowadays, but questions whether they provide a holistic yet clear approach adopted by consultancy firms to transform 'to be' enterprises. To address the discussed limitations of these frameworks, a synthesized approach for aligning enterprise transformation requirements and identifying weaknesses in information activities is validated. The intent is to define an approach that is effective for program managers to apply lean practice to change programs. Below are the hypotheses for study by this paper: (H1) The paper predicts that ESTPA would effectively identify weaknesses in the communication structure amid the complexity of the integrated enterprise. (H2) The paper hypothesizes that the utilization of ESTPA in change programs would meet the need for transformation of enterprises in their IT and process facilities. (H3) ESTPA would be a better tool for program managers to identify lean enablers for lean change programs. 4.1.2 Selection of Research Participants and Subjects Tata Consultancy Services Limited (TCS) is a multinational IT services and business solutions consulting company with an extensive network of global partnership. It focuses to add value to partner enterprises through its domain expertise and solutions with its proven track record. With the TCS advantage - Customer-centric Engagement Model, it strives to support clients in Page 68 business operations with its wide array of services and experiences by offering them specialized solutions to meet their distinct business needs. From its presence in Life Sciences and Manufacturing, the challenges of complex problems and attaining operational excellence over enterprise transformation that TCS faces today mirror the concerns addressed by this paper. The paper continues the analysis for automotive in the Manufacturing sector with case studies of tractor manufacturer and engine manufacturer in realizing their PLM solutions. PLM is part of the IT or process infrastructure that manages the entire flow of product development from introducing new product concept, through product design and manufacture, down to maintenance and disposal of resulting products. Specifically, the paper looks to explore TCS's CCBT framework (Figure 23) with regards to its practical concept of: * Identifying challenges and improvement areas for programs and providing innovative solutions, * Gaining advantages on Time, Quality and Cost for effective implementation, and " Triggering innovation through small group activities for programs. Despite CCBT's official endorsement in 2007, facets of its practice have emerged organically and are already conducted within TCS' previous integrated enterprises before their consolidation. Small Group Activity (SGA) is conducted daily to review clients' needs and learn from outcomes of current change interventions, so that new ideas for implementation can be iteratively incorporated into the clients' business models. It also demands the involvement of cross-functional teams, so that domain experts can communicate concerns and identify opportunities to the solution team to better tune the program with best practice and benchmarks that are of relevance. Page 69 Appfication Rationatization - omabn specNic Technology Rationalization- Architecture Strategie5 Crodis Functinat Busness Process Business Mode Ermpro enents ChangS Pracdces sA", sap Apencammir Valuation Value Strean Maps s-Appacaion IDTrain exp s- Trarin the Traimr 3r 0 SGA TATA COPSULTANCY GroPIPWL SORICES Figure 23: TCS CCBT Framework The paper also considers for Organization Change Management (OCM) functions prevalent in TCS change programs, which starts at the initiation of the change program and conducts reviews regularly throughout phases of change. OCM is conducted weekly with clients to pull valuable feedbacks for consideration and evaluation of innovations for the enterprises. This is in line to the functional concept of the proposed ESTPA which endorses the lean approach to change management by: * Identifying stakeholder values as necessary to interpret program requirements, * Encouraging client involvement on change management on a regular basis, * Viewing the needs for changes due to 'big data' environment, and * Owning rapport of clients in the field of IT governance. 2 programs are selected from TCS portfolio. The change program for tractor manufacturer is selected due to its 100% completion status with availability in program outcomes and lessons Page 70 learnt. The change program for engine manufacturer is selected due to its ongoing status with availability of actors for interview and survey. This allows for experimentation with recommendations from lessons learnt in analyzing completed tractor program through ESTPA. It should be noted that both programs are under the ownership of the same program manager which facilitates providing of insights from past events and flaws in enterprise transformation. His involvement includes identification of appropriate human subjects for survey and interview. 4.1.3 Description of Research Design A month-long data collection and ESTPA activity over the programs for tractor manufacturer and engine manufacturer is conducted. During this period, the paper evaluated TCS-provided SO matrices for both programs to identify programs' stakeholder values, and generated value matrices to better focus on the needs of specific entities to transform client enterprises through the programs. This is necessary as SO matrices lack specificity to entities functioning within the change programs and the hierarchical control structures. From prior discussion with TCS program manager, program governance structures are constructed to represent the controls and feedbacks necessary for enterprise transformation. While control structures are utilized for representation of program governance structures and identification of potential weaknesses in communication, 2 process models are constructed for identification of inadequate control actions of specific entities engaging on specific work procedures. The first process model is constructed for Product Definition Report (PDR) process based on New Product Introduction (NPI) for tractor program, and is generated from user manual delivered previously to tractor manufacturer client. The second process model is constructed for Product Change Management (PCM) process for engine program, and is generated as codified in ongoing TCS program. A month-long survey (Appendix A) is conducted after that based on survey design described in Appendix B to confirm benefits, control actions Page 71 and information flow associated with survey participants. These participants comprise actual actors from both programs and in the absence of actual actors, human representatives who have intricate information about their involvement in the programs, so that all specific roles that are of interest are represented. These representatives are either knowledgeable with the specific roles or have collaborated with the actual actors for 2-3 years within the same program. Below is the distribution of all participants in both programs: Tractor Manufacturer Engine Manufacturer Actual 3 9 Representative 15 0 Concurrently, the methodology is shared and familiarized, and representation and analysis of TCS programs using ESTPA are demonstrated to the program manager over telephone conference. This is to facilitate collection of insights of ESTPA implementation in future change programs through later interviews with program managers. Program managers from TCS and Engine client are interviewed based on interview questions and clarifications compiled in Appendix C and are derived from both lean enablers (Oehmen and Et 2012) associated to ESTPA, and other literature review. After that, a 2-week final evaluation of the research hypotheses is conducted by: * (H1) Validating the infological alignment for control/information actions from findings in ESTPA with survey outcomes from program actors, " (H2) Validating the socio-cultural/value alignment from findings in ESTPA with survey outcomes from program actors, and " (H3) Consolidating the practical insights of execution of ESTPA in change programs with interview outcome. Page 72 4.1.4 Assumptions, Limitations & Delimitations Program managers are commonly concerned and constantly monitoring generic metrics in the programs in term of number of defects detected and time to resolve them. The paper identifies these as the outcomes for reaction but not necessary for responding to uncertainties and new information needs. Instead, the paper assumes that: " Identification of stakeholder values and value streams reflect better the needs of programs, " The information, knowledge and possibly decisions required by the programs is better sourced from actors within the programs, * The hierarchical control structures or process models alone are insufficient to model the functional or operational perspective of enterprise transformation for program managers or actors to respond, " Success of change programs is best reflected in closing the gap between the 'as-is' state and the 'to-be' state, and * Lessons leamt extracted from Tractor manufacturer change program are extendable to engine manufacturer change program from the perspective that both are TCS change programs to PLM using the same WindChill4 technologies in manufacturing or product development. However, the paper acknowledges the limitations or constraints that: * Findings are based on lean change programs and do not necessarily apply to all change programs or enterprises, * There is a small sample size of 2 change programs servicing by the same consultancy firm , and insights might not be applicable to other consultancy firms, 4Windchill is a PLM software provided by PTC, a third-party supplier engaged by TCS. Page 73 * Mental models of controllers are evaluated without consideration to the influence of applied technologies to the programs, as TCS helps clients to only adopt Windchill -the generic PLM software from PTC -and customize it to clients' business needs, and * The interviewees approached by the research of the paper might be subjected to hindsight bias and exposure effect (Virine and Thrumper 2007). On the other hand, the delimitations of the paper are: " The programs are restricted within manufacturing industry and the provision of IT services and solution to PLM, and not applicable to other programs such as supply chain management and financial budgeting, and * Insights are applicable to IT consultancy firm TCS and its integrated enterprise or partner network but not to PD enterprises who obtain and adapt PLM tool in-house. 4.1.5 Proposal with TCS The paper thus focuses on the lean principles of 'value', 'value stream', 'flow' and to a lesser extent, 'perfection' with the condition that TCS employees have some working knowledge about lean practice. The paper strives to encourage TCS and its clients to adopt ESTPA in their change program or CCBT framework to reap the expected benefits from better interpretation of its entire flow of value-creating activities and meet the needs of enterprise transformation. Also, the paper proposes to assist TCS to strive for perfection by first evaluating the quality of the information flow before eliminating resultant information waste within the value stream. Eventually, program managers or consultants of TCS should derive lean enablers that match the needs of the change programs. Armed with the intent described above, the paper showcases the ESTPA approach for integrating multiple episodic improvements in complex organizational systems in PLM. The Page 74 research on the change programs is conducted with regular involvement and support with their program manager, so as to interview and survey the relevant stakeholders, and to guide the program manager on the proposed approach. The subsequent sections describe our research approach in details. 4.2 ESTPA Execution on TCS Programs 4.2.1 Defining Value for TCS Integrated Enterprise As TCS's business objective is to deliver value to partner enterprises through their superior product knowledge such as Windchill, it makes sense to explicitly define the value TCS is delivering. A couple of the value or benefits for TCS are having access to business process management specification documentation and availability of development resources to realize this delivery. On top of that, as TCS uses change programs to add value and changes to integrated enterprises' existing processes, other value includes customized Windchill program adoption and change alignment between stakeholders such as users and designers. The paper defines this value as commonly associated with enterprise development that is matched to TCS as a value-added process business. However, this value such as change alignment can also apply to enterprise governance or user. Apart from value associated with enterprise development, the initiated change programs by TCS also specifies the value that they are defined for, so as to realize client enterprises' corporate and IT strategies or execute IT policies. These strategies can comprise of customer-centric requirement management or the objective in our research case, a collaborative structured IS to generate NPI projects. The value applied to enterprise users includes generic ones like user satisfaction, on-time delivery of functions, or specific ones like new product recommendation, budget-approved product proposal. Page 75 However, while TCS's SO matrices (Figure 24) explicitly record strategies, objectives, target actions and metrics, the value and the associated actors involved in the change program are not recorded explicitly with their associations. 4.2.2 Generation of Value Matrix Figure 24: X-Matrix for TCS - Tractor Manufacturer Change Program As emphasized, the strategies or policies selected for the change program are generated from clients' inputs and mapped to objectives and intents for the programs, and the associated activities required to attain these objectives. Subsequently, these activities are mapped to the metrics the change programs would be measured against to quantify the success of enterprise transformation. These would eventually be consolidated to achieve the original strategies set out in the programs. The above-described sequence is reflected in TCS's SO Matrices (Figure 24), which perform functional alignments from goals and objectives to program activities. Additionally, to conduct Page 76 socio-cultural and infological alignment, the execution of the value matrix is proposed to appreciate how values emerge for specific stakeholders and how the working configuration of the designed processes bring about that (Mcmanus 2005). The proposal is to mitigate the lack of specificity to the individual stakeholders and lack of details to the required information actions. With reference to SO Matrix provided by TCS for tractor manufacturer, the paper identifies the high-level value of the change program in the form of policies and strategies which define and map the objectives for client stakeholders, their activities and expected outcomes for success. For the focus in this paper, 2 policies with their associations in Figure 24 are selected for study: * Product Portfolio Rationalization * Right First Time Both are selected due to their dependencies to each other to trigger an initial concept for a new product, and the availability of specific information from Tractor manufacturer to generate the necessary process model for subsequent detailed analysis. After review of the SO matrix, the paper determines that the extracted requirements for the program as represented by the 'Activity Targets" in Figure 24 are too abstract for analysis. The paper needs to identify the necessary information flows and actors interfacing with them, leading to the focus of 'Design an effective NPI dashboard' as the requirement of interest. The relevant program objectives are 'Have Enhanced Collaborative Culture & Systems' and 'Define common definition of NPI program'. Reducing the scope to the available objectives and requirements for analysis, the paper defines the relevant stakeholders and information flows to program governance. Page 77 {Group Name (To classify actors within group boundary) Benefit or Value (common rationale for actor's output) Information (input to actor) Tcg ore - Man DevekopmwntTeam ftnefh Senefichates be, a n~iw Ewm Projecs stemp Meet Proje et clue- Input originator within'group Red - Input'originator outside grou p ule Qmty Status Actors belonging to Group Medium of information (optional for future research) Figure 25: Description for Stakeholders Stakeholders are identified as beneficiaries as they are expected to derive benefits or value from the system in enterprise transformation or change program for PLM. Stakeholders applicable to tractor or engine manufacturers are categorized elementally in Appendix D with descriptions in Figure 25. In the study, benefit is defined as the decomposed value to the stakeholders being beneficiaries of the program. It is observed that benefits form the basis or motivation for beneficiaries' outputs within a program. To ensure these benefits are met, the pre-condition is that inputs have to be provided by their dependencies. Value matrices are utilized to aggregate all these stakeholders, benefits and information activities, together with their associations to each category into a consolidated viewpoint, so that an efficient approach is achieved by tracing for dependencies over specific multiple items and analyzing within a common view. As the paper proceeds downstream in the construction of the value matrix (Figure 26), the paper detects the activities of producing/receiving information and responsibilities over Page 78 information quality are getting more coupled, such that the sole contributor of that information is the actor responsible for that information. This coupled relationship of the contributors with the multiple information actions is registered as 'X' in Figure 26, to be further studied in proposed process model. 11 X X 10 Control Cost X 9 Number of approved proposals X 8 Number of new product proposals X 7 Optimize new product success X X 6 User Satisfaction 5 Meet expectation of Enterprise Changes X X 4 Program Adoption X 3 System Golive (Schedule) 2 Change Alignment X X X Enterprise Reputation X X X X X X X X X X X X X X X X X X X X X X XX X X X X X X X X X X X XX X X X X X X X X X X X Benefits 0( -cwE B C D E X F X RPIIII PP Information 0 Actions ____________0__7__ _J ID~~ a M E M E ~ ~ E 0__ E E) aaaa G X X H Xl J X Windchill specification doc Function specification doc Bug Fix Solution Alignment K Test Outcorne X E Project Proposal XK X~~~ X M New Product Recommendation X N Marketing Approval ~~ X 0 Project Approval X P Budget Approval X 0 Schedule Availability Figure 26: Value Matrix of TCS Tractor Manufacturer P P P P R I RP Program Feedback Program Progress Function Progress ProjectProgress Customer Requests/Requirements X X RPI U A Client Satisfaction X X X X X 2 E - Role & Responsibility a z a:Objectives RI I IRI IPPPP P IRP I I I I P R PPPPPPPP P P Pr I J" P I R 111 I P 1 P I I P P I _ _ R - inftOucrmedII responsible P-producing info x X- all of above X X I I I I I J Page 79 It should be noted that the paper is selective over the choices of objectives used from the 'tractor' SO matrix, so as to scope down the value matrix for ease of comprehension in the format shown in Figure 26. Design Structure Matrix (DSM) (Smith and Eppinger 1997) is another alternative for representation of the value matrix, but it is likely to face the same problem of visual scalability from the complexity involved in the program. However, through value matrices, the paper instantly detects exclusions of specific roles from specific processes and activities of enterprise transformation (highlighted in Figure 26), or involvement of multiple activities for a specific role. Both observations are further analyzed in Chapter 5.1. Also, the 'information actions' are different and aggregate to the high-level 'Activity Targets'. Primarily, these actions in Figure 26 are decomposed entities for the target 'Design an Effective NPI Dashboard'. Apart from potential in analysis, the value matrix is extended to build a proper hierarchical control structure with the selected activities and their actors in consideration. Page 80 4.2.3 Hierarchical Control Structures and Process Models Enterprise Development (TCS) Enterprise Governance (Tractor) Figure 27: Simplified Program Structure The paper focuses on the Tractor manufacturer PLM change program's NPI function and constructs both the high-level control structural representation and detailed-level process models for PDR to discuss some possible control flaws. The paper uses block diagram (Figure 27) to simplify representation of high-level control structure for purpose of explanation, with the left-sided view showcasing the hierarchical structure of the development organization TCS and the right-sided view that of the tractor manufacturer which is both the client and the enterprise maintaining and operating the IT process infrastructure. The top sections of the model represent the upstream stakeholders while the bottom sections map closer to the downstream stakeholders. The paper conducts a top-down approach first on the hierarchical control structure from the upstream "Steering committee" to identify the initiation of changes and the processes that direct them. Next, from the "NPI" process function downstream, the analysis traces up by bottom-up approach to determine the effectiveness of the change leadership through the strengths of the feedbacks flowing upstream. Page 81 Actot, 3 Act >r 3 rMMpon :Pto:~~ ...........Resp AcdpU 3 Informedd Figure 28: Demonstrative Process Model The paper constructs a demonstrative process model at Figure 28 to further explain the flaws of interest: * Missing Control Action * Incorrect Control Action * Missing Actor Information entity flows from one task to the next task, with an actor either having a responsible, contributing or informed role. When one is assigned a responsible role, he is obligated to contribute the information entity and be informed of the outcome of his contribution. This format allows information entity to be generated from one actor and transfer to another actor through a task. However, it is necessary for the actor to be informed about the outcome or the information entity of the previous task, so that the current task can start. Page 82 Missing Control Action Based on Figure 28, there is one missing control action whereby the output of Task 1 is not informed to Actor 2, who is supposed to act on Task 2 using Task 1's output. Another case is Actor 3 supposed to act on Task 6 but he is not informed of the previous Task 4 or Task 5. Another missing control action is that Actor 6 is not informed of the outcome of Task 6 although he contributes to the output of Task 6. Incorrect Control Action A process is designed to follow a sequence based on the mental model of the process designer. However, it is possible that the task sequence for that process is not aligned to the mental model of the process actor, leading to the incorrect action on the process. One scenario is the wrong sequence of tasks by transiting from Task 3 to Task 5, and then transiting from Task 5 to Task 4. Another scenario is the excessive transition of tasks between actors, which increases the stress on communication. Instead of Actor 3 responsible for Task 5, the scenario of Actor 4 replacing to be responsible for Task 5 would result in not being informed of the outcome of Task 3. Having the right actor or a correct sequence of actors working in the process is essential to avoid incorrect control action. Missing Actor The flaw of missing actor is most prominent. As observed in Figure 28, there is no actor responsible, contributing or informed of the outcome of Task 4. Other cases not demonstrated in Figure 28 can be identification of missing task, leading to missing information flow between 2 specific actors. Flaw cases not explicit from process models Page 83 are whether the information flows are consistently conducted and checked. This would need further analysis through survey and audit of assignment of responsibilities and outcome of the information activities. 4.2.4 Evaluating Survey and Interview Outcomes The research is narrowly focused on exploring the specific hypotheses it has determined in advance. The paper uses statistical analysis and designs the survey in Appendix B to provide an infological (information) and socio-cultural (organization, program and individual) overview of each specific actor for comparison with findings from ESTPA. Eventually, the survey finding is aligned with the specified research hypotheses and is used to validate the ESTPA analysis outcomes. The hierarchical control structure in ESTPA helps to provide an overview of the change programs, and draws the focus of the analysts to specific areas for further analysis. It serves as a network of nodes representing actors and information actions which are activity-oriented or deliverable-oriented. As such, it follows the scalability rule for human perception by limiting the nodes to no more than 100 - 200, and using the proposed process model otherwise for ESTPA. The extent of coverage ESTPA thus has over all the information actions is dependent on the stakeholders considered, while the survey outcome on the information actions is subjected to the perception of individual stakeholders surveyed. The latter is assumed to be more accurate due to the specificity of the actors surveyed and the complexity of work activities encapsulated within each actor. This facilitates the paper's validation on the findings of ESTPA on the 2 change programs. Focusing on Hypothesis H1, infological alignment is defined as the efficient use of information systems and capabilities utilized by the program to achieve the 'informational, transactional and relational' requirements for the stakeholders (Magoulas et al. 2012). To validate the infological Page 84 alignment of the integrated enterprises in the programs, the infological activities of the actors represented in the hierarchical control structure is evaluated with individual actors' perception for their effort distribution in producing information, interpreting the data received and verifying the quality of the information through monitoring and tracking, as reflected in the survey. Process or structural weaknesses are detected through ESTPA, and are validated through the survey to explore the infological fundamental of the stakeholders - information. Figure 29 is provided for description on interpreting a specific actor's perception on information actions based on his expectation. Quality of Output 4 Insufficient to my expectation More giving info than normal Contributing over Informing info Processing Load o slow for information to meet my needs Velocity of Info Quality of Output 4 More being inform than normal Contrfut 2 oo much to r ess/interpret over info Processing Load fast for rocessing/interpret Velocity of info Figure 29: Terminology for Infological Spider Diagram Additionally, as hypothesized in H2 that ESTPA would meet the need of enterprise transformation, ESTPA is expected to identify weaknesses in 'current state' of enterprise in term of its specific entities before endorsing changes to rectify them. However, doing so would Page 85 demand identification of discrepancies from the 'desired state' of the change programs determined by stakeholder value theory, or also known as the 'value agenda'. To validate these value discrepancies detected through ESTPA, the paper proposes using socio-cultural alignment extracted from program actors through surveying the fundamentals of the individual stakeholders - organization, program, individual. The paper defines socio-cultural alignment as the harmonious interaction of individual actors within the organization working in the direction of the program to meet the changing expectations of stakeholders in the integrated enterprise. Chapter 5.1 utilizes these aspects of the survey to focus on specific stakeholders for analysis. 4.2.5 Extraction of Information from the Engine Manufacturer Change Program Based on the SO matrix for the Engine Manufacturer Change Program provided by TCS, Figure 30 is extracted to display the objective similarities in the engine manufacturer to that of the tractor manufacturer. The target action 'Provide ability for better product data visualization' in engine manufacturer change program's SO matrix provides the best fit to the tractor manufacturer change program's target action 'Design an Effective NPI Dashboard' as studied by this paper. Although this target action is intuitive to program managers and steering committee, the related information actions showcased in Figure 26 are subsets of the target action, and are applied by development and user team downstream to transform and govern the enterprise, and realize changes. Page 86 0 - a ) Objectives Roles Actions XItA Design and implernent efficient enterprise change manageent process X B Ensure implementation L to/fro portfolio management X E Link product development X G Enable X ona#00t H Prvdi gMiclent and effective search I Implement harmonized process to handle compliance (intemnal & external) data across X Figure of global template of PD process 30 on-dema nd t secure access across value chain : Extract from Engine Manufacturer Subsequently, the hierarchical control structure for the Engine Manufacturer is constructed, with descriptions and comparisons between integrated enterprises of both manufacturers. Value matrix also follows. The process model for PCM is further generated to appreciate the activity sequence of product change control. PCM process facility is part of the change program's deliverable, and is under the scope of Enterprise Governance in Figure 27. OCM of change program has the sole purpose of change control for enterprise transformations mentioned earlier in Chapter 3, and is under Enterprise Development in Figure 27. Both are basically different processes. The paper proceeds to describe details of findings from conducting ESTPA in both manufacturers' change programs. Page 87 5 Research Findings and Validation 5.1 Analysis Results 5.1.1 Findings from Tractor Program's Control Structure I- I S*$~27~ I I I IL SI SI I I I I F-7 - I- TOWLt~a -- * -r---- m o~TiJnc I I II I ~< Figure 31: Hierarchical Control Structure for Tractor Manufacturer Change Program Referring to Figure 31 for the tractor change program, the paper detects potential inadequate control actions for specific actors listed in Table 9: Page 88 S2 Actor Customer Program Manager TCS Project Manager S3 TCS Delivery Center Case# S1 Potential Inadequate Control Action An incorrect control action is provided through overdrive of concurrent information by multiple actors in program An incorrect control action is provided through overdrive of concurrent information by multiple actors in program A missing control action to TCS Program Manager Head S4 Customer Steering A missing control action to Customer Program Manager Committee Member Table 9: Inadequate Control Actions from Tractor control structure Case SI and Case S2: Incorrect Control Action First, the paper identifies that there are multiple actors driving or drawing information to either the Customer Program Manager or TCS Project Manager. As described earlier on scalability issue, the paper suggests having 25 to 40 stakeholders represented with up to 4-5 communication nodes each in the control structure to maintain the total communication nodes at 100 to 200. While the control structure in Figure 31 demonstrates that the normal number of communication nodes per actor is 2-3, the paper detects 6 for the Customer Program Manager and 7 for TCS Project Manager. This abnormally high number of contacts for interaction puts both actors at a higher risk of communication failure. The paper does not define that interfacing with multiple actors would be the condition for the emergence of incorrect control actions. The paper defines that with the need to interface with multiple actors, an effective and robust control and communication structure is required to lead changes by coordinating different values inherent to the actors and information actions among the actors. Using Case S2, the paper interprets in Figure 26 that TCS project manager shares the same benefit 'Change Alignment' or 'System Golive' with his interfacing actors TCS Program Manager, Customer Program Manager, Customer Project Leader, Tech Lead @ Near Shore and Tech Lead @ Client. The paper determines that these interfacing actors would share the same motivation as the TCS project manager to act in the common interest and interact in the Page 89 common language. The exceptions are Customer Functional Team and IT members whose benefits differ and are at risks of conflicts of interest to TCS project manager. The paper subsequently refers to the survey to extract insights of TCS project manager role on his operation in the program amid possible infological and socio-cultural discrepancies, and an overview is generated in Figure 32. It is recorded that TCS project manager determines the information received is more than he is capable to interpret in term of velocity and volume, and he is under the stress to dispatch more information (dispatching more information than is desired). This validates the presence of a communication stress for TCS project manager to receive and process information, to respond quicker and more sufficiently. It also indicates that detection of multiple interfaces for a specific actor within the hierarchical control structure can reflect potential flaws in the design of the communication structure for the enterprise. Checking the survey result for Case S1 Customer Program Manager turns out similar findings and validation. This confirms the H1 hypothesis with 2 cases that ESTPA's detection of multiple interfaces of one actor to multiple correspondents through hierarchical control structure can detect potential flaws in enterprise transformation process. Page 90 Hierarchical 4 Standardized Process Decision Transparency Clear Vision Active ""... 4 learly Defined Role Communication Organization TrustClear ual Trua 5 Technology Program Current -- Quality of Output Information individual 4 - Desired Task Overview 4 m Motivated Info Processing Contributing over informing N Objective Autonomy on Task Load Encourage Velocity of Info Innovation Figure 32: Socio-Cultural-infological Background of TCS Project Manager Case S3 and Case S4: Missing Control Action Next, the paper identifies through the hierarchical control structure that there is missing control action from the TCS Delivery Center Head to the Program Manager, and possibly from the Customer Steering Committee Members to either the Customer Program Manager or the Enterprise Function members. There is only the presence of a unidirectional arrow linking TCS Delivery Center Head and TCS Program Manager, or Customer Steering Committee Members to Customer Program Manager, instead of bidirectional, as shown in Figure 31. Page 91 Based on Case S3, the paper proceeds to validate the interaction between the TCS Delivery Center Head and the Program Manager. From Figure 31, it is observed that there is missing communication flow from TCS Delivery Center Head to TCS Program Manager although communication flow exists from TCS Program Manager to TCS Delivery Center Head to provide regular status reporting for Tractor change program. The value matrix also affirms that the TCS Delivery Center Head is primarily in the role of being informed, requiring TCS Program Manager to inform him of the program status. From the value matrix in Figure 26, it is observed that there are differences in benefits for both actors. While 'program adoption' is the benefit for TCS Program Manager, it is not necessary to TCS Delivery Center Head as there are other programs apart from this program that promotes the adoption of Windchill, and he is expected to provide equivalent support for all programs. However, to receive reporting from TCS Program Manager, he needs to exert control to the latter to ensure responses are regular, timely and accurate, which is absent in this scenario. To validate the quality of the exertion of control to the TCS Program Manager, Figure 33 is generated to detect discrepancies between the current state and the desired state, for utilizing information and practicing own work scope for TCS Program Manager. As TCS Program Manager is shown to perceive primarily insufficient information to meet his functional expectation, this is aligned to the finding from ESTPA that the control action from the TCS Delivery Center Head to the Program Manager is missing or weak as detected by ESTPA. Interview with TCS Program Manager further confirms and validates this finding. Expectation on having a better overview of own tasks involved and autonomy to act encapsulates the Program Manager's motivation for this program. The paper recommends that any mitigation actions to be monitored and aligned according to these benefits. For example, Page 92 management team should avoid imposing rules and constraints to drive control that would reduce autonomy of downstream actors. Interview with TCS program manager has also revealed that TCS Delivery Center Head's role is confirmed to be an informed role with respect to the program, and the control action is of providing additional resource approval in the event of escalation from TCS program manager, which is inconsistent for program governance. Also, although the TCS program manager is getting informed more than desired as reported from survey, it is verified with TCS program manager that the referred information primarily flows between him and Customer Program Manager, and not the TCS Delivery Center Head. This validates H1 that missing connection detected between actors in hierarchical control structure can infer flaws in program governance. Organization 10 Technology Program 5 Current - -Desired Individual Information Task Overview 4 Quality of Output 4 Motivated on Task 2 Contributing over informing 2 -- ---- Autonomy Info Processing Load - -. ~--.. Encourage Innovation Velocity of Info Figure 33: Socio-Cultural-Infological Background of TCS Program Manager Page 93 5.1.2 Findings from Tractor Program's Process Model Missing Control Actioj lob PoCas ~~Ae~~onsbb~eim CabuiglWJ~s' Lad *Ald Atah c SumtPC)K PRAs Raqu uDC hbii KI P4t czsct Ift Figure 34: Tractor Program's PDR Process Model While hierarchical control structure provides modeling for identification of inadequate control actions of specific actors, cases SI-S4 have proven that obstacles exist in identifying weaknesses that are focused on specific organizational entities other than human actors and information actions. Also, it does not support decision making because the model provides limited information for changes while improving judgment. As such, it is essential to decompose this high-level model to detailed process models. As each actor is involved in multiple activities, interactions between actors in term of collaborative activities and information exchange are complex to interpret, thus the objective is to overcome this obstacle through the proposed Page 94 process model. With reference to the PDR Process User Manual provided by TCS depending on its completeness and accuracy, the process model in Figure 34 is constructed based on the format proposed by the paper. The paper subsequently detects further inadequate control actions listed in Table 10: Case# P1 P2 Actor Marketing Project Office P3 Finance Potential Inadequate Control Action Missing control action An incorrect control action aligned to 'Iron Triangle' or 'Triple Constraints' Missing Actor Table 10: Inadequate Control Action from Tractor Process Model Case P3: Missing Actor From the SO Matrix in Figure 24, one of the target activity or requirement set for the program is the 'involvement of Finance from concept phases'. However, this is in contrast to the process model which detects the absence of Finance unit in assisting the transformation of IS in PDR process or involvement in the operation of the PDR process. This can be detected from the hierarchical control structure as well. However, this appears to be discounted by the involvement of Senior Management Group (SMG) from understanding its role being in budget control over the PDR process as reflected in the value matrix. While it might be counterintuitive to review the infological aspect of Finance in view of its absence, the socio-cultural and infological aspect drawn from the survey in Figure 35 helps to explain Finance's current state of practice in the enterprise. Page 95 Hierarchical 4 Standardized Process Decision Transparency Clear Vision learly Defined Communicatio Organization Mutual Trust Technology 5 Obectiv Objective Program ==--Current I - Information -Desired Individual Task Overview Quality of Output 4 Motivated on Task Autonomy info Processing Load Contributing over Informing Encourage Velocity of Info Figure 35: Socio-Cultural-infological Background of Finance The infological aspect for Finance reflects it is fairly efficient in using the IS and process capabilities put forward by the enterprise to achieve the objective of its operation. The paper also identifies that Finance is fairly program-aware, and interview with TCS Program Manager reveals that Finance is much involved in the program. However, it fares substantially worse off at the organization level and individual level in the survey, which results in its comparatively high deviation from the desired socio-cultural state. Page 96 When compared to SMG role which is assigned budget control rather than Finance, its deviation from the desired socio-cultural state is substantially lower than Finance's, as indicated in Figure 36. The expected benefits of SMG are better met than that of Finance. This indicates that SMG is in a better position to handle budget control or is positioned better by the program. However, the socio-cultural discrepancy between 'as is' state and 'to be' state for Finance implies that the integrated enterprise is at risk of not optimizing its performance, leading to the argument that Finance's involvement in the other aspects of the program should have been considered, such as PDR design or PDR operation. It can be realized through integrating this SMG function into Finance processes, so that all finance information can be centralized and audited by third party for PDR process. Organization 10 Technology Program ----- Current - Information - Desired individual Figure 36: Socio-Cultural-infological Background of SMG While endorsing transformation of processes and functions related to Finance and SMG, consideration should be given to review the socio-cultural and infological aspects of specific actors and determine the motivation for the actor's involvement. The value matrix and hierarchical control structure need to be revised and evaluated with the inclusion of Finance and emerging conflicts mitigated or resolved before changes are triggered in the next iteration. Page 97 Case P1: Missinq Control Action Missing control actions are identified with regard to the non-availability of notifications by Project Office to Marketing on New Project and SMG to Marketing on Budget Approval as shaded in Figure 34. There is missing 'informed' action to Marketing for the output of 'Create Project' and 'Budget Approval' tasks. This has implications on the proper functioning of PDR and operational requirement of Marketing. While the objective of the PDR process is to 'Define common definition of NPI program', it is the benefits to Marketing such as maximizing the 'Number of approved proposals' drawn from ESTPA's tractor value matrix that provide focus to identify the missing control action. As such, missing notification of availability of new project or budgetapproved project to Marketing leads to unnecessary waiting time before projects are initiated and disrupts the flow to new product conceptualization. These missing control actions could have been handled manually outside the scope of the IS of interest. However, the paper proposes to resolve this flaw by integrating To-Marketing notification of "New Project" or "Budget Approval" into the PDR process, and the user manual updated. Alternatively, Marketing can be assigned a 'Responsible' role for complete PDR process, so that Marketing has complete visibility of all PDR entities. The proposed process model is thus demonstrated to be capable of identifying actions in discrete tangible units and representing how PDR actors interact with others to transfer information in the format of documentations and notifications. Appendix F Part 2 representing the socio-cultural-infological background of Marketing confirms the need of Marketing for better standardized process and overview of activities, and deems Marketing to be less informed than desired. Case P2: Incorrect Control Action Page 98 The same PDR process model is utilized to demonstrate an action sequence for identification of incorrect control actions in the change program. Based on the 'Iron Triangle', the mental model adopted by project management professionals to manage and plan projects, the project offices and project leads are expected to balance the desired project scope for a new product, available resources to meet the schedule for its delivery and needed budget to bring product to fruition, so that feasible projects are initiated. However, the proposed process model is projecting a different sequence conflicting with the 'iron triangle' by having the project office determining the availability of resources based on the proposed project scope without consideration of budget constraint. The budget approval is the responsibility of SMG, which demands the involvement of another group outside of project office for budget-controlling action in PDR process. Appendix F Part 1 representing the socio-culturalinfological background of Project Office confirms the needs for better standardized process and defined role, since existing practice conflicts on the mental model controlling their project management activities. Also, hands-offs have to occur multiple times between Marketing and Project Office/Project Lead, and between Marketing and SMG. Eventually, project proposals with significant invested efforts by Marketing and Project Office are subjected to discards on the basis of budget constraints, leading to waste at the end of the PDR process. This runs contrary to the principles of Lean which promotes flow as uninterrupted sequence of work activities and strive to remove the existence of information waste. As such, the proposed process model demonstrates the process flow or the lack of it, and allows analysts to trace process sequence in details down to the actions, information entities, program actors. This allows for understanding of the organization structure and IT governance Page 99 based on tangible elements and generation of improvement ideas based on these entities' arrangements that are visual for review and able to facilitate and lead changes. Both Case P1 and P2 are aligned to H2 to meet the needs of integrated enterprises to transform their IT and process facilities. Proposed actions to improve situations in each case are summarized in Table 11: Case# P1 P2 P3 Proposed Actions * Integrate new notification functions for Marketing into PDR process S Assign 'Responsible' role to Marketing for visibility of complete PDR process * Assemble 'Consolidate PDR', 'Create Project' and 'Budget Approval' functions into one sequence under Project Office/Project Lead responsibility * Integrate SMG 'Budget Approval' function into Finance process Table 11: Proposed Actions for Tractor Program Flaw resolution An iteration cycle of ESTPA is necessary to be conducted on the tractor manufacturer change program to identify conflicts of proposed actions. The tractor program is used to demonstrate the utilization of ESTPA on an actual enterprise transformation program to validate its feasibility in actual manufacturing industry. Key learning such as the usefulness of survey as an investigative tool for root causal analysis is identified, and is subsequently integrated into ESTPA. While the tractor program is a complete program, the engine program is an ongoing program that provides the research with an opportunity to assess ESTPA and collect insights on utilizing ESTPA during enterprise architecting. 5.1.3 Findings from Engine Manufacturer Previously, the focus on the ESTPA approach of the delivered Tractor manufacturer change program is to identify weaknesses in enterprise definition and enterprise transformation, and validate them through survey with program actors. After the findings for the Tractor program have been verified by TCS, the objective of ESTPA approach on ongoing Engine manufacturer change program is to absorb lessons learnt from tractor program and propose practice or lean Page 100 enablers to potential weaknesses of the Engine manufacturer's integrated enterprise. It would be of benefits for TCS and her Engine manufacturer client to integrate these practices during enterprise transformation. Executing ESTPA on Engine manufacturer change program demands the construction of the value matrix and hierarchical control structure from the SO matrix. To facilitate capture of tractor's lessons learnt, the paper extracts the policies and objectives for product conceptualization from the engine manufacturer program and matches them to those of the tractor program. - rr -4 - -p ---------------- 9 ............. gran Ti ri mnan4 Led)Aw SMobca * O40nV $ Organud*at Riquimmmms P-aep i few~~at Dat I ugVA( toa a, I Tat Figure 37: Hierarchical Control Structure for Engine Manufacturer Page 101 Figure 37 represents the resulting hierarchical control structure generated solely from prior discussion with TCS Program Manager. Some potential inadequate control actions except for two are hypothesized but not discussed in this paper due to insufficient details. Table 12 focuses on the two potential inadequate controls in the engine program: Case# Structure Entities El TCS Workgroup Manager E2 PCM Process Potential Inadequate Control Action An incorrect control action is provided through overdrive of concurrent information by multiple actors in program Weakness in Process Model - Detailed Study Required Table 12: Inadequate Control Action Identified from Engine Hierarchical Control structure Case El: Incorrect Control Action From detected flaw of the Engine program's hierarchical control structure similar to the tractor program, it is identified that at least 7 actors driving or drawing information from TCS Workgroup Manager. However, to validate the case, the same survey applied to the Engine program is referred for insights on operation of the TCS Workgroup Manager. By drawing infological and socio-cultural alignment for this specific actor, Figure 38 is generated from the survey. Page 102 Hierarchical 4 Standardized Process Decision Transparency Clear Vision learly Defined Role Active Communication Organization Technology Mutual Trust Program 10 5 Objectve Current -. - Individual Information Task Overview 4 Quality of Output 4 Info Processing Load Contributing over Informing Desired Motivated on Autonomy Task Encourage Velocity of Info Innovation Figure 38: Socio-Cultural-infological background of TCS Workgroup Manager The review of the survey result contrasts with that of the Tractor program's incorrect control action. This leads to the paper's interviewing with TCS Program Manager to obtain verification, and a new insight on modification of control structure due to presence of 'Customer Project Manager' in program is obtained as shown in Figure 38. The Customer Project Manager assists the TCS Workgroup Manager to interface with the multiple stakeholders on the 'Program Govemance' functional group, reducing the interaction load of the TCS Workgroup Manager. Page 103 I Workgroup Manager Program Governance Figure 39: Modification to Engine Hierarchical Control Structure A new value matrix in Figure 40 is generated to integrate this modification. From the value matrix, the paper observes the benefit for 'Program Adoption' is weak based on available active participants supporting it. However, this indication is non-conclusive as the value matrix does not comprise of all program stakeholders and their dependencies. Page 104 13 9 8 X 7 X 6 X X 5 X X X 4 X 3 2 1 X X X Optimize engine/variant adoption Meet assignment schedule Meet Product Requirement Minimize product changes (rework) Enterprise User Satisfaction Meet Expectation of organization changes Program Adoption System Golive Change Alignment X X X X X X X X X X X X X X X XX XX X X X X X X X X X X X X X X, M aU X x X Xx X Benefits Objectives A Client Satisfaction Program Feedback C Program Progress Function Progress E Project Progress X X X X B X X X X __X XX E0 F G H I J Customer Requests/Requirements Enterprise Bug Fix Test Outcome p pP PRP RRRPPPPPP _ iiiiiiiii l Change Proposal R Change Approval X X K Product Plan X Roles R R E L Changed Product Figure 40: New Value Matrix for Engine Manufacturer Program Case E2: Weakness in Process Model Likewise for the engine manufacturer change program, the ESTPA-proposed process model in Figure 41 is constructed for 'Product Change Request', with focus to its procedures, information flow and actors participating in Change Request Board (CRB) and its associated Change Request (CR) processes. The completed Product Change Management (PCM) process is Page 105 selected, as TCS plans to integrate this flow into the Engine manufacturer's NPI flow which is slated for the coming Phase n (Appendix E Part 2). Lessons learnt from tractor manufacturer's NPI program is proposed to migrate to the engine manufacturer to improve this process and consistently deliver better products. Figure 41 is generated for the PCM process of interest for analysis and reference of incorrect and missing control actions. 0 1. 10;3 IkTA AJAt Acdw MWAWN Just" (X Nowp s ~ 04 Figure 41: Process Model for Engine PCM Page 106 Incorrect Control Action Based on the value matrix to understand the mental model of the actor involved in the PCM process, the paper identifies CR coordinator as striving for benefit of 'Meet assignment schedule' while CRB Lead a different benefit of 'Meet Product Requirement'. CR coordinator has the responsibility to select between the 'Fast Track' to CR Planner, and 'Full Track' to CRB Lead, and is sequenced before the CRB Lead in the PCM process. As such, the paper predicts that CR coordinator has a higher tendency to select the 'Fast Track' based on his benefit and skip the CRB Lead review and transition to the CR planner, resulting in the lost benefit of 'Meet Product Requirement'. Additionally, it results in information waste by resulting in higher risk of CR Planner reverting CR to review by CRB Lead, generating possibly multiple iterations of review that are more difficult to manage. It should, however, be noted that some iterations are necessary but should be limited to optimize their value to the process. The paper proposes to remove the 'Fast Track' mode and allow the process to always go through CRB Lead. Alternatively, CRB Lead review function is removed from PCM process or decoupled from the CR coordinator's function, and CRB Lead is assigned with responsibility for complete visibility of PCM process, provided the interfaces between both actors are wellunderstood to identify the resulting impact from de-coupling. Missing Control Action CR Creator strives for the benefit of 'Optimize product/variant adoption', and is predicted to have the risk to submit many CR without sufficient review. The paper deems assigning 'CR Creator' role by Product Manager as insufficient control to exert on CR Creator's action. Page 107 The paper proposes the Product Manager to be assigned a direct responsibility to the CR Creator and his actions, so that he has the complete view to audit CR Creator's actions. Else, the Product Manager should ensure the correct actor is assigned as CR Creator, which is more challenging to determine. Additionally, the paper determines that the Product Manager should be assigned a Responsible role to the complete PCM process to audit the associated functions and their intermediate outputs. Missing Functions or Actors The function to manage the 'Canceled State' of CR is detected to be missing from the PCM process, as denoted by 0 within the shaded region in Figure 41. Key learning from the engine program reaffirms that the integration of the survey into ESTPA does not duplicate the analysis effort but improves the accuracy of representing the enterprise in its governance. The additional identification of the client project manager is testament to this. The engine program also verifies that missing control actions, incorrect control actions and missing organizational entities are common flaws that exist in change program for enterprise transformation. Application of ESTPA on new or ongoing program ensures that these flaws are timely detected, and useful insights are received for consideration of resolution. Additionally, the detected flaws serve as real-program examples of ESTPA's flaws of interest, and are described to TCS for verification. The subsequent proposed change interventions are for TCS to review for program improvement. Page 108 5.2 Lessons Learnt for Change Programs 5.2.1 Review of ESTPA in TCS Change Programs The paper regards ESTPA as primarily a modeling and analysis approach. Generation of improvements to enterprise transformation is expected to be intuitive once ESTPA provides analysts with the platform to be enterprise-aware and naturalized with common architecting language. The conditioning in Lean mental model on users would also advance this approach, as proven by the compilation of 43 Lean Enablers for managing engineering programs. In terms of how well ESTPA strive to meet the need of enterprise transformation in H2, the paper finds that while the SO matrix is unable to determine the program value to specific actors that drive their actions, the value matrix improves on this aspect but needs robust information and details from organizations. This indicates that when data is insufficient, information gap has to be filled up for the value matrix by the analyst which increases its subjectivity. The same applies to hierarchical control structure as it is generated from the value matrix. Suggestions on improvement mostly apply to rearrangement of sequence, addition or extraction of entities such as controllers and control actions within processes. With regards to ESTPA effectiveness in identification of weaknesses in integrated enterprise for H1, the paper notes that the visual modeling of the hierarchical control structure facilitates analysts to represent and align with actors for exploration and investigation due to familiarity to existing program governance structure. However, there is some discrepancy to existing organization structure due to the nature of enterprise transformation, whose objective is to change the client organization structure. Additionally, the control structure provides the overview to determine potential flaws, and assists in the establishment of informal or hierarchical communication between stakeholders. On the contrary, it is found lacking in identification of formal and detailed communication such as the codified process communication and IT Page 109 infrastructure, due to the increased complexity and distinct function for each entity. Process model looks to mitigate this limitation, and identify specific weaknesses on this aspect. Table 13 summarizes the descriptions: ESTP A H1 H2 What it does well * Helps stakeholder alignment of findings 0 Provide overview of informal/hierarchical for resource communication * Identify formal communication in lifecycle process and IT What it is limited * Differential in mental model between analyst and stakeholders * Scalability and extension to modeling for representation What it does well * Specificity to stakeholder values * Flexible to incorporate information for analysis * Managing of modular entities in organization What it is limited * Need for robust information and data points to construct * Tend to be subjective & Improvement restricted to flow and organizational entity involvement Table 13: Summary of H1, H2 Hypothesis This leads the paper to determine that ESTPA to be incorporated into OCM process to reap the benefits. The participation of clients in this process facilitates alignment of different mental models in term of how the enterprise should be governed and collection of data both formal and informal. Computerization of this approach would improve on scalability issue. The same applies to CCBT (Figure 23) which although applied internally, it is able to improve learning by setting ESTPA as the Best Practices / Benchmarks to generate ideas and system thinking among cross-functional teams . Senior Management can also identify organizational weaknesses for improvement and apply a holistic approach to manage stakeholders and direct actions, especially lean. Page 110 5.2.2 Impact on Program Management The purpose of this paper is not to introduce an approach so complex that substantial resources and budget have to be employed to integrate ESTPA into consultants' operation. Major organizations already have their organization structures codified and regularly refer to those in their communication with stockholders and employees, in company bulletin, financial statements etc. IT consultancy firms such as TCS have also shown that their operations have incorporated existing tools such as X matrix for gap analysis, and employed practice such as lean. As such, the paper determines that incorporating ESTPA into IT consulting practice should not pose a high barrier, and proceeds to determine the paper's hypothesis H3. Based on our interview for engine manufacturer program, the ESTPA hierarchical control structure is deemed feasible to be generated from existing organization structure and program governance structure. The argument from the interview is that 90% of TCS program governance structure and 50% of client program governance can be mapped to their respective organization structure, and 80% to 90% of the hierarchical control structure represents the whole program governance. Thus, the motivation is for programs to build the program governance up front to match the format of ESTPA hierarchical control structure. Likewise, a continuation of the interview also reflects that the value matrix proposed by ESTPA is also deemed feasible to be generated, with 70% to 80% of the data drawn from TCS SO matrix. From literature review and research hypothesis, the paper compiles a list of benefits that consultancy firms desire for an approach for representing enterprise transformation in Table 14: No. B1 B2 Approach Benefit Aligning on program expectations+ Facilitating on identification of required resources and activities+ B3 Facilitating definition of deliverables for program+ Page 111 B4 B5 B6 Tracking progress of programMeasuring outcomes and resultsFacilitating modifications to react to undesirable outcomes+ Table 14: Benefits for Analysis Approach To identify how each component of ESTPA compare in achieving the listed benefits, both TCS program manager and client program manager are interviewed to give their perception with 1 being the worst performing, and 5 being the best performing in Table 15: No. Value Matrix Solution Objective Control Structure Process model Client TCS Client TCS Client TCS Client TCS B1 5 4 4 4 2 2 1 1 B2 B3 B4 B5 B6 3 5 1 3 2 2 4 2 3 2 5 5 3 2 3 5 4 2 2 2 5 3 3 4 3 5 2 2 2 3 5 4 4 3 3 5 4 4 4 3 Table 15: Rating of ESTPA modeling components from Program Manager Interview In the program managers' opinion, ESTPA fares prominently well in identifying resources and activities for change programs through its components in value matrix, control structure and ESTPA-adapted process model. However, improvement is needed for ESTPA to better measure the performance of enterprise transformation and enterprise governance, and manage risks for the programs. The interview outcome for B6 runs contrary to research finding due to the indication that it introduces modifications to mitigate enterprise weaknesses which might not necessarily culminates to undesirable outcomes. Since process models are already employed by TCS in their change programs, the paper further probes TCS program manager on a comparison between TCS process model and ESTPA-adapted process model, and the outcome of comparison is listed in Table 16: No. B1 B2 B3 ESTPA Process model Client TCS 1 1 5 5 4 4 Current Process Mod TCS 1 5 4 Page 112 4 3 3 B4 B5 B6 4 4 3 3 3 2 IM Table 16: Comparison between TCS process model and ESTPA process model The insight from these interviews on ESTPA benefit indicates that ESTPA differentiates from TCS current practice by improving on: * 'Tracking progress of program' and * 'Facilitating modifications to react to undesirable outcomes'. However, better performance is required for: * 'Measuring outcomes and results' and * Facilitating modifications to react to undesirable outcomes'. Program managers generally agree in the interviews that the ESTPA-associated lean enablers are relevant to program improvement with a rating of 3 and above out of a total of 5 in Table 17. Enabler No. ESTPA-associated Lean Enabler Relevance Rating ESTPA Rating (TCS-Client) (TCS-Client) TCS Client TCS Client 1.6 2.1 Encourage personal networks and interactions Establish the value and benefit of the 5 3 4 5 5 5 3 3 4 4 3 2 4 3 3 4 5 5 5 5 5 4 5 5 program to the stakeholders 2.2 3.1 4.2 4.5 Focus all program activities on the benefits that the program intends to deliver Map the management and engineering value streams and eliminate non-valueadded elements Ensure clear responsibility, accountability, and authority (RAA) throughout the program from initial requirement definition to final delivery Pursue collaborative and inclusive decision making that resolves the root causes of issues Page 113 4.6 Integrate all program elements and functions through Program Governance 5 5 4 4 Table 17: Program Manager Rating of ESTPA on Lean Enabler When requested to rate how ESTPA would perform in term of generating change interventions matching these lean enablers, the responses of the program managers are also listed in Table 17 for comparison with relevance. Opinion from the program managers indicates that ESTPA is most useful for them to create the 'program flow', but also fulfils most of their critical needs for improvement except for "Establish the value and benefit of the program to the stakeholders". Alternatively, the discrepancy in Enabler 2.2 might consider an abnormality as value matrix is primarily the tool utilized to achieve Enabler 2.2. A plausible explanation is that the benefits reflected in the value matrix are not intuitive to the program manager who is more familiar to the high-level benefits that the program is necessary to deliver. This explanation is verified and confirmed with TCS program manager. As such, the association between the program's highlevel benefits and stakeholders' benefit would be an area of interest for further research. Page 114 6 Thesis Conclusion 6.1 Thesis Summary From program managers' interviews (Appendix F Part 3), three main topics have emerged in program management - mentality to changes, human communication and optimization of operation. ESTPA focuses on delivery of values specific to stakeholders who act within the program scope to seek their acceptance to changes. It represents a hierarchical control structure that can match to a human network of communication, and drives integration of data sources and harmonizing of activities through process model. Based on varying degree of success for two TCS lean change programs, the paper considers ESTPA to be suitable to drive lean program flows but urges extra focus on program initiation to properly define program value and its value stream (H3). While risk management is critical to change programs which ESTPA strives to support, there is room for improvement. Being a predictive approach to look at system failure based on enterprise architecture's weaknesses, facilitation of improvements into existing process infrastructure still needs more exploration and verification by real-life actors. However, the paper sees high potential in ESTPA in identifying communication weaknesses in term of stakeholder communication and process communication (Hi), and some encouraging outcomes in proposing valid solutions to meet the need for enterprise transformation (H2). It would best serve H2 by having internal analysts from integrated enterprises who have in-depth knowledge of organization structure and governance to utilize ESTPA for an objective and accurate analysis. 6.2 Limitations of Thesis Determining the success outcomes of change programs through ESTPA is not as direct as first assumed. Although the defined information actions may be tangible and intuitive to understand, Page 115 measuring the productivity of operating these low-level activities by specific actors is complicated, and their aggregation to reflect program outcome is more a prediction of program risk than actual performance of the program. Using actual failure cases pre-determined in complete programs instead of generic metrics such as 'total bugs detected' could provide better insights to detect enterprise design flaws based on validating the risk factor generated from the approach. Also, the validation using survey with human actors is subjective to the mental model of the individual controller selected, and the paper is not discounting the case when multiple actors of the same role or responsibility might be equipped with different mental models to the enterprise, process and functional governance. Next, as mentioned earlier for ESTPA, Step 5 (Table 1) represents a sequence to apply causal analysis on change programs through the degradation of control actions over time. However, the absence of detectable and measureable outcomes in more than 2 phases of development or review gates for TCS means that it is not feasible to validate prediction of problems beyond the current state. This is true for TCS programs as bugs detected in one test phase is solved and delivered in the next, with 100% resolution. As such, other metrics have to be considered instead of common and available ones such as the bug solving rate. Having regular insightful responses from TCS program manager in interviews is very much appreciated, but a couple of professional feedbacks do not reflect a complete overview of utilizing ESTPA across the consultancy industry, and tend to be subjective. The paper urges more consultancy firms to evaluate this topic and form their opinions on whether the approach optimizes their operation. As this paper only employs two manufacturers for empirical study, and both are different in that the Engine manufacturer's change program is an ongoing program. TCS may want to consider Page 116 integrating ESTPA into the practice of its organization and the integrated enterprise of the change program to determine sufficient change interventions, so that multiple iterations are conducted to extract program progress from the influence of these interventions. 6.3 Future Work This paper focuses on the value of ESTPA in identifying weaknesses in enterprise architecture for enterprise transformation and establishing correct changes for proposed change interventions. To bring across this concept, the paper depends on visual representation for demonstration of the approach sequence and its validation. The association between stakeholder values and information actions related to the enterprise controllers is thus of interest, as the paper focuses on specificity to organizational entities for integrated enterprise's improvements. Future work can be considered for developing the conducted survey in this research into an investigative tool for ESTPA to collect qualitative data with emphasis to controllers' mental models and convert it to quantifiable format. This would generate ESTPA into a comprehensive package of enterprise transformation analytic tool for lean change programs and learning. In the research process, the paper identifies significant potential in exploration of processprocess, stakeholder-stakeholder associations to provide divergent or complementary insights on information actions or benefits so as to achieve of harmonized activities in integrated enterprises. The signal flow graph (Eppinger, Nukala, and Whitney 1997) is a popular modeling tool for circuit analysis that may possibly be modified to apply to improvement of enterprise transformation by assigning discrete organizational entities with scored weights of importance. By applying the associated graph transmission approach to provide a quantitative system to manage weighed entities, the tool can determine the best combination of entities to achieve best enterprise outcomes. Page 117 Earlier, the paper has also revealed the iterative nature of some activities in the Engine process model, and DSM (Cronemyr, Ronnback, and Eppinger 2001) can be considered for exploration to assess the quantifiable dependencies between these activities, so that the best process flow may be derived. Eventually, both quantitative approaches can be considered for integration into ESTPA for better support for decision-making and directing changes. Empirical study has also introduced system dynamics modeling for analysis of dynamic behavior of closed-loop system (Lehr, Thun, and Milling 2013), and it would make sense to explore this modeling approach on the integrated enterprise to manage enterprise complexity with multiple feedback loops and delays within the system. This would serve better for ESPA's step 5 to identify communication degradation over time by quantifying the time-varying factors within the enterprise and the impacts of exogenous shocks in the uncertain environment. Additionally, more work could be done to encourage lean practice, but this could be prohibitive to change programs without matching the lean approach to the organization or adopter's mental model. Focus should thus be exerted to evaluate how influential an approach like ESTPA can encourage lean thinking, before incorporating lean change interventions in programs. Lastly, managing complexity has been the constant theme of this paper to present the complete view of the analyzed programs. ESTPA through computer vision and simulation can be the answer to handling complexity, so that analysts can achieve holistic viewpoint of enterprise transformation and evaluate effectively on programs of all levels of complexity. Page 118 Bibliography Anon. 2013. "Industry Trends And Developments - United States - Q2 2013." Business Monitor International (Epidemiology - Burden of Disease Projection). Beer, Michael, and Nitin Nohria. 2000. "Cracking the Code of Change." Harvard Business Review (MayJune):133-42. Christensen, Clayton M., and Dina Wang. 2013. "Consulting on the Cusp of Disruption." (October). Cronemyr, Peter, Anna Ohrwall Ronnback, and Steven D. Eppinger. 2001. "A decision support tool for predicting the impact of process development." Journal of Engineering Design 12(3):177-99. Day, Bryce, and Christof Lutteroth. 2011. "Climbing the ladder: capability maturity model integration level 3." Enterprise Information Systems 5(1):125-44. Retrieved October 13, 2013 (http://www.tandfonline.com/doi/abs/10.1080/17517575.2010.495789). Eppinger, Steven D., Murthy V. Nukala, and Daniel E. Whitney. 1997. "Generalised Models of Design Iteration Using Signal Flow Graphs." Research in Engineering Design 9:112-23. Forrester, Jay W. 1995. "Counterintuitive behavior of social systems." 1-29. Freeman, R. Edward, Andrew C. Wicks, and Bidhan Parmar. 2004. "Stakeholder Theory and 'The Corporate Objective Revisited'." Organization Science 15(3):364-69. Retrieved November 7, 2013 (http://pubsonline.informs.org/doi/abs/10.1287/orsc.1040.0066). Garrison Jr. LP, Neumann PJ, Erickson P, et al. 2007. "Using Real World Data in Pharmacoeconomic Evaluations: Challenges, Opportunities, and." Value Health 10(326-3). Griffith-Cooper, Barber, and Karyl King. 2007. "The Partnership Between Project Management And Organizational Change : Integrating Change Management with Change Leadership." Performance Improvement 46-1(January). Hayes, Robert H., and Gary P. Pisano. 1996. "MANUFACTURING STRATEGY : AT THE INTERSECTION OF TWO PARADIGM SHIFTS." 5(l):25-41. Hickey, Jonathan, and Qi Van Eikema Hommes. 2013. "Effectiveness of accident models : system theoretic model vs . the Swiss Cheese model : a case study of a US Coast Guard aviation mishap Jonathan Hickey * and Qi Van Eikema Hommes." Int. J. Risk Assessment and Management 17(1):46-68. Hommes, Qi Van Eikema. 2012. "APPLYING SYSTEM THEORETICAL HAZARD ANALYSIS METHOD TO COMPLEX." IDETC/CIE 1-13. Page 119 Institute for Business Value, IBM. 2012. Analytics: The real-world use of big data - How innovative enterprises extract values from uncertain data. Kolker, Eugene, Elizabeth Stewart, and Vural Ozdemir. 2012. "Opportunities and challenges for the life sciences community." Omics : a journal of integrative biology 16(3):138-47. Retrieved March 13, 2013 (http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=3300061&tool=pmcentrez&renderty pe=abstract). Kotter, John P. 2007. "Leading change: Why Transformation Efforts Fail." Harvard Business Review (January):16-18. Retrieved (http://www.ncbi.nlm.nih.gov/pubmed/17927072). Kreimeyer, Matthias. 2011. "Aggregate views to manage complex dependency models." Int. J. Product Development 14:144-64. Lehr, Christian B., Jorn-Henrik Thun, and Peter M. Milling. 2013. "From waste to value - a system dynamics model for strategic decision-making in closed-loop supply chains." InternationalJournal of Production Research 51(13):4105-16. Retrieved January 12, 2014 (http://www.tandfonline.com/doi/abs/10.1080/00207543.2013.774488). Magoulas, Thanos, Aida Hadzic, Ted Saarikko, and Kalevi Pessi. 2012. "Alignment in Enterprise Architecture : A Comparative Analysis of Four Architectural Approaches." 15(1):88-101. Maier, Anja Maier et al. 2008. "Exploration of Correlations between Factors Influencing Communication in Complex Product Development." SAGE 16(1):37-59. Retrieved December 16, 2013 (http://cer.sagepub.com/cgi/doi/10.1177/1063293X7084638). Maier, Mark W., David Emery, and Rich Hilliard. 2000. "ANSI / IEEE 1471 and Systems Engineering." 1-23. Mcmanus, Hugh L. 2005. "Product Development Value Stream Mapping (PDVSM) Manual." Lean Aerospace Initiative (September). Mcmanus, Hugh L., and Richard L. Millard. 2002. "VALUE STREAM ANALYSIS AND MAPPING FOR PRODUCT DEVELOPMENT." Proceedings of the International Council of the Aeronautical Sciences 8-13. Melancon, Dwayne. 2007. "Managing Change From The Top : Using Fact-Based Enforcement To Support Change Management." EDPACS 35-6(Jun). Merrell, Phil. 2012. "Effective Change Management : The Simple Truth." Management Services 562(Summer):20. Nastase, Marian, Marius Giuclea, and Oliviana Bold. 2012. "The Impact of Change Management in Organizations - a Survey of Methods and Techniques for a Successful Change." Review of International Comparative Management 13(1). Page 120 Nightingale, Deborah J., and Joe H. Mize. 2002. "Development of a Lean Enterprise Transformation Maturity Model." 3:15-30. Nightingale, Deborah J., and Donna H. Rhodes. 2004. "Enterprise Systems Architecting : Emerging Art and Science within Engineering Systems." (March):1-12. Oehmen, Josef, and Al Et. 2012. The Guide to Lean Enablers for Managing Engineering Programs. Joint MIT-PMI-INCOSE Community of Practice on Lean in Program Management. Porter, Michael E., and Thomas H. Lee. 2013. "The Strategy That Will Fix Health Care." Harvard Business Review (October). Rebentisch, Eric, and Josef Oehmen. 2010. "Waste in Lean Product Development." LAI Paper Series (July):1-35. Rebentisch, Eric S., Edward F. Crawley, Geilson Loureiro, John Q. Dickmann, and Sandro N. Catanzaro. 2000. "Using Stakeholder Value Analysis to Build Exploration Sustainability." American Institute of Aeronautics and Astronautics. Rettig, Cynthia. 2007. "The Trouble With Enterprise Software." MIT Sloan Management Review Fall(49101). Ross, Jeanne W., Cynthia M. Beath, and Anne Quaadgras. 2011. "The IT Unit of the Future : Creating Strategic Value from IT." CISR Research Briefing XI(X). Rouse, William B. 2005. "A theory of enterprise transformation." Systems Engineering 8(4):279-95. Retrieved December 10, 2013 (http://doi.wiley.com/10.1002/sys.20035). Scherer, Sabrina, and Maria A. Wimmer. 2012. "E-participation and enterprise architecture frameworks: An analysis." 17:147-61. Smith, Robert P., and Steven D. Eppinger. 1997. "Identifying Controlling Features of Engineering Design Iteration." Management Science 43(3). Syeda, Asiya Zenab Razmi, and Marja Naarananuja. 2013. "Comparative approaches of key change management models - a fine assortment to pick from as per situational needs!" 3rd Annual international Conference on Business Strategy and Organizational Behaviour (BizStrategy 2013) 217-25. Teece, David J. 2007. "EXPLICATING DYNAMIC CAPABILITIES : THE NATURE AND MICROFOUNDATIONS OF (SUSTAINABLE) ENTERPRISE PERFORMANCE" edited by Norconk Et Al. Strategic Management Journal 1350(August):1319-50. Retrieved (http://doi.wiley.com/10.1002/smj.640). Teece, David J., Gary Pisano, and A. M. Y. Shuen. 1997. "DYNAMIC CAPABILITIES AND STRATEGIC MANAGEMENT." 18(March):509-33. Page 121 Tennant, Charles, and Paul Roberts. 2001. "Hoshin Kanri: a tool for strategic policy deployment." Knowledge and Process Management 8(4):262-69. Retrieved (http://doi.wiley.com/10.1002/kpm.121). Virine, Lev, and Michael Thrumper. 2007. "Heuristics and Biases in Project Management." in Project Decisions: The Art and Science. Zachman, J. a. 1999. "A framework for information systems architecture." IBM Systems Journal 38(2.3):454-70. Retrieved (http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5387107). DARPA URBAN CHALLENGE. (2007). Retrieved Nov 28,2013, from DARPA: archive.darpa.mil/grandchallenge/index.asp INCOSE. (2000). Systems Engineering Handbook (Version 2). International Council of Systems Engineering. J. Ross, P. W. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. HBS Press. James P. Womack, D. T. (2003). Lean Thinking - Banish Waste and Create Wealth in your Corporation. Free Press. Leveson, N. G. (2011). Engineering a Safer World - Systems Thinking Applied to Safety. Cambridge, Massachusetts: the MIT Press. MARKOFF, J. (2010). Smarter Than You Think - Google Cars Drive Themselves, in Traffic. Retrieved Nov 28, 2013, from The New York Times - Breaking News, World News & Multimedia: http://www.nytimes.com/2010/10/10/science/lOgoogle.html?pagewanted=all&_r=0 Mcafee, A., & Brynjolfsson, E. (2008, July-August). Investing in the IT That Makes a Competitive Difference. Harvard Business Review. Munoz, J. A. (2013, March 13). How the Internet built a $100,000 race car. Retrieved Nov 28, 2013, from CNN: http://edition.cnn.com/2013/03/12/tech/web/crowdsourced-carsxsw/index.html?iref=allsearch OpenXC. (2012). The OpenXC Platform. Retrieved Nov 28, 2013, from OpenXC: http://openxcplatform.com/ Page 122 Senge, P. M. (2006). The Fifth Discipline: The Art & Practice Of the Learning Organization. Crown Publishing Group. Simchi-Levi, D. (2010). Operations Rules - Delivering Customer Value through Flexible Operations. The MIT Press. von Hippel, E. (1986). Lead users: A source of novel product concepts. Management Science 32(7), 791805. Welcome to TOGAF* Version 9.1, an Open Group Standard. (n.d.). Retrieved Dec 9, 2013, from The Open Group: http://pubs.opengroup.org/architecture/togaf9l-doc/arch/ Page 123 Appendices Appendix A - Survey Questionnaire (Part 1) Kindly help us answer the following questions which will help us understand TCS and the program scope better. 1. How knowledgeable are you on lean principles: 0I Not Knowing (1) 0 Basic Knowledge (2) 0 Knowledgeable (3) 2. How much do you practise lean in your work? P9 Less than 25% (1) 0 Between 25% to 75% (2) 95 More than 75% (3) 3. Does your company, in any way, encourage you to practise lean in your work? D9 Discourage (1) 0 Neutral (2) 0 Encourage (3) 4. Please specify your current role in the organization? Please specify 5a. Which one best describe your current work environment? A hierarchies in No Nommhichiesn communication B Hierarchies are only ny Hirrhelr called upon to report deviation/problem C Hierarchial Heaciladapt communication is consistent D Continuous effort to hierarchial adaptirarchialto !communication work-to -do_ Page 124 5b. Which one best describe your desired work environment? B A No hirarchiin 'communication D C Hierarchies are only ~irrha called upon to report 'communication I deviation/problem irrha -ni jdp _Co Lwok-o is consistent _oto 6a. How would you describe current procedurefor work? A Not clearly defined D Continuous effort to improve procedures themselves and usagej of procedures C B Procedures are used Procedures are inconsistently generally standardized 6b. How would you describe desired procedure for work? A 'Not clearly defined D Continuous effort to improve procedures themselves and usage 'of procedures C B are used Procedures i inconsistently I 'Procedures are generally gtndrdized standardized 7a. How would you describe the current role you perform in your work? A :Not clearly defined B D C Mine and others' are I am fully aware of somewhat clear to me mine and somew hat aware of others' I know mine and others' for every task and use it consciously while communicating 7b. How would you describe the desired role you perform in your work? A 'Not clearly defined B D C I iamand fully swat aware Mine and others' are somewhat clear to me aware of others' of I know mine and others' for every task and use it consciously while communicating 8a. How would you generally describe your current communication experience with others in your work? A B Their communication reactive tThey tend to forget uss is ratv D ~ T rcommu nicati ~ Their communication with each other is is proactive continuously proactivei deoeadina on needd C Page 125 8b. How would you generally describe your desired communication experience with others in your work? C B A Their communication tend to forget us 15iThey reactive jTheir communication jis proactive D Our communication with each other is continuously proactive 9a. How is current decision made in your work? A B It is sort of clear how decisions are made land we correct the way decisions are made once a mistake occurs Happens as it happens C The decision making process is transparent. My own contribution to the decision making ,process is clear D The decision making process is adequate with continuous effort to reassess transparency and whether right people are involved 9b. How do you desire decision should be made in your work? B A C It is sort of clear how The decision making decisions are made and we correct the way decisions are made once a mistake occurs Happens as it happens process is transparent. My own ,contribution to the decision making ,process is clear D The decision making process is adequate with continuous effort to reassess transparency and whether right people are involved 10a. How are processes in your work being adapted? B A No clear method of improvement or adaptation C Standardized Processes are adapted inconsistently procese ae whenneed when need arises. arises D Continuous effort to refine processes and their usage 10b. How do you desire processes in your work being adapted? No clear method of iimprovement ~adaptation C Standardize d orProcesses are processes are adapted inconsistently adopted when need when need arises. B A or D Continuous effort to refine processes and itheir usage Page 126 11. How much do you know the program's vision/strategies? B A Not known and !applied D C Known what is to be Known and application hown work apphcation is done. Continuous Known but not known Kppliwd specifscabe applied specifically to effort to optimise totoy how 12. How much do you know the goals and objectives behind your actions/work? B A D t~tfr~elyclearand C Known and Not known. No thinking about it identification with it which is expressed in communication and continuous effort to lassess and adjust goals and objectives and the way to reach sometimes Known but everyone consideration of the follows just his or her 1way common goals can be reached own goals through working Itogether ~them 13. How much do you trust other you interface with for your work? B A We it don't think about D C We change the course Wtare aw re o u to trust towards the of action depending on whether there is cpmmsncwhow trust or not There is trust and continuous effort to create trust and learn to trust 7. communicating 14a. How much of an overview does everyone have on the sequence of tasks according to their own job description? B D C Everyone has according to their job sdescription - enough - A No overview There are some who have overview of the task sequence but they should generally know more Most people have overview of the and sequence Isequnce off tasks t know how these are related - overview of the sequence of tasks andl there is continuous othe thirn s sequence of tasks could be clearly Jdenictr1~l Page 127 14b. How much of an overview does you wish everyone have on the sequence of tasks according to their own job description? C B A -Eve D ryone h as according to their job 1No overview There are some who Most people have have overview of the overview of the sequence of tasks and task sequence but they should generally know how these are Iknow more related descriptin - nough servew of the of tas sere ontnout h thi tthenyo hw thin eof the sequence of tasks could be clearly rdPnirctPd 15a. How much autonomy do you have in doing your own work? A C B I It is not thought off have sufficient freedom in my Actions are changed Idecisions to fulfil my whenever something tasks autonomously in lalignment with my goes wrong. No further consideration responsibilities and i n coordination with others D have sufficient freedom in my decisions to fulfil my tasks autonomously in! alignment with my responsibilities and in coordination with others and this applies to the whole proqram. 15b. How much autonomy do you desire in doing your own work? A It is not thought off B C II have sufficient freedom in my Actions are changed !decisions to fulfil my whenever something tasks autonomously in ,alignment with my goes wrong. No further consideration responsibilities and i n coordination with others D ~~ have sufficient freedom in my decisions to fulfil my tasks autonomously in alignment with my responsibilities and in coordination with others and this applies to the whole program. 16a. How does management perceive on innovation or new ideas? A Not seen as necessary B C D Are accepted but only Continuously There is a certain supported and reluctance to mention rewarded have been new ideas laccomplished Page 128 16b. How do you desire management to perceive on innovation or new ideas? Not seen as necessary D C B A .e r Are accepted but only Continuously the daily tasks t reluctance to mention once ted supported and been rewarded newhave new There is a certain .!once iaccomplished 17a. How much of your capabilities is demanded by your current work? A fIt is not thought off B It is not a matter of using my capabilities in the best way but of fulfilling the assigned and demanded tasks C I am given the opportunity to think )through how my capabilities could be !best utilised D I am at the right place where my potential and capabilities are continuously realised and utilised accordingly 17b. How much of your capabilities do you desire to be demanded by your current work? A It is not thought off B It is not a matter of using my capabilities in the best way but of fulfilling the assigned and demanded tasks C ,I am given the opportunity to think through how my Icapabilities could be best utilised D I am at the right place where my potential and capabilities are continuously realised and utilised accordingly 18. Are you confident the information you provide is what is required by the receiver? A B C D It is entirely clear ro No Sometimes, we learn from mistakes us what information Mostly since it is we need and the documented and information communicated which transmission process information is needed is continuously optimized 19. How would you rate the amount of information/documents provided to you? A Too much than ,necessary B A bit much C A bit little D Too little or nearly non-existent Page 129 20. How frequent would you rate the amount of information/documents received? A D C B Too frequent that I Ifind it challenging to interpret A bit too frequent A bit too delayed Too delayed that it leaves me almost no time to react 21. How do you mainly draw the needed information for your work? A Not necessary. The information would come to me. D C B I would ask for it before it is available I would delegate and information would be forecoming Not necessary. I would mainly be the one providing information 22. PIs rate the percentage of work time you spend on the below activities: _% Informed (eg interpreting, analysis, studying) % Contributing (eg providing info, generating deliverables/documents) % Responsible (eg monitoring, tracking) Page 130 Appendix B - Survey Description (Part 1) Identify the awareness of employees of the company in I princ : p es Le rms of lean 1estify the behavior of mployees of the company to act !an 'I 1 I lentfy te entify if the company operates a lean contest 2 Jentify the respondent at his sle and responsibility in the ompany entify if respondent works in a tructuraI environment with clear ommunication channels t that r punt efforks to 6an0 nify iroment that put effort to rnprove process usage )etermine level of knowledge bout the roles and esponsibilities of oneself and thers and theuse of itwhile Lean.Principle.01 beavio Lean.Practice.02 2 I 3 Lean.Organization.03 4 RCJobPosition.04 5 ORG.Hierarchical.05 6 7 1. How knowledgeable areyou on lean principles: o Knowng .OT p1i 3 Basic Knowledge (2) 3 Knowledgeabl 3) (1) (2) 25%toa% yourM Less than 2Lss 2. How much do you practise lean m yo M Between 25% to 75% (2) work? Mmore th an 75% (3) R Discourage (1) 3. Does your company, in any way, encourage you to practise lean in your M Neutral (2) work? MEncourage (3) oin 4. Please specify your current role In the organization? Please specify No hierarchies in communication best d r ysdr work nCurrent[] Desired[} 5. Which one best describe your work environment? 6. How would you describe procedure for Current ( Not dlearly defined Procedures are used needuesarre HiContinuous Hierarchies are only delatlon obreport ith regard to interaction with 8 ORG.Interface.08 >thers )etermine thetransparency of lecision makingand involvement if the right people in the deci sion naking process 9 ORG.Decision.9 )ummy to Question 7 10 Dummy.Process.10 9. How is decision made In your work? Their They 10. How are processes in your work beiIg Current) Desired)) adapted? communication mc tend to forget us i r ecie and of program vision ipplicato nd val ues 11. How much do you know the program's Drred [ ] P .Visio.11 11 dentify the knowledge and ppicatonogoasan12 pplication ofgoals and 12 PROoal.12 PRO.Goal.12 Not known and Known but not known Knplnd Fill by Program i ratv cniuul depending on need No clear method of improvement or Standardized Processes are adapted inconsistently processes are adopted when need when need arises. Continuous effort to refine processes and their usage applied how to apply Known what Is to be Known and application own effort to optimise application Entirely dear and identification with it which is expressed in communication and continuous effort to assess and adjust goals and objectives and the way to reach sprk Manager 12. How much do you know the goals and Current)) objectives behind your actions/work? Desired)) > Fill by Supervisor Our with communication each other is adaptation it Current)) scalb is done. Continuous vision/strategies?Desired> Their communication i ratve i pommticationtnuotey thers' for every task aduei osiul while communicating The decision making process is adequate with continuous effort o reassess transparency and whether right people are Involved Organization (ORG) detify the knogam knowledge o visnd dnti atvo o It is sort of clear how The decision making process is decisions are made My own transparent we correct the and tr brt.ynto ay decons tre contribution oktng way decisions are is dear prac occurs occus prces is ear Happens as Happens happens Current Desired themselves and usage of procedures mine and know arImflyaaeo w Mine and others' are Im fl d aware of others' Current)] 7. How would you describe the role you h and use itconsciously mo Not derydfnd somewhat Desired poyour work? idsmwaclrtoe perform in yuwokDe 8. How would you generally descri be your communication experiencewith others in Cusredt Desired)) your work? effort to adapt hierarchial communication to wrk-t-do Continuous effort to Is Inconsistently ommunicating )etermine the degree of activity Ioerarchial communiation Procedures are Improve procedures RG.Process.06 ORG.Role.07 D C B A Not known. No thinking about it Known and sometimes Known but everyone consideration of the follows just his or her way common goals own goals can be reached through working together Page 131 13. How much do you trust other you Current[) )egree ng toof trtwith interpersona res ect continuous effort to We don't think about of action dependi Wiort to create trust within the 3roject team 1 13 of our We change the course We are aware PRO.Trust.13 nterface with for your work? Desired [> Fill by Respondent it There Is trust and create trust and learn how to trust on whether there Is person we are pemmnweare not not communicating trust ortrust __________ Everyone has according to their job description - enough overview of the sequence of tasks and thinkig cfnhiwuthe thinking of how the sequence of tasks could be clearly - trust and dentify the degree of overview of :he sequence of tasks according n own job description. 14 IND.Sequence.14 14. How much of an overview does everyone have on the sequence of tasks according to their own job description? Current Deowntorow No overview There are some who have overview of the task sequence but they shouldd generally g r knowum Most people have overview of the sequence of tasks and know how these are l w sr I have sufficient identify the degree of freedom in own decision and task execution in alignmentwith one's :ises is IND.Autonomy.15 15. How much autonomy do you have in doing your own work? Current[) Desired []It is not thought off responsibilities and :oordination with others Actions are changed whenever something goes wrong. No further consideration freedom In my decisions to fulfil my tasks autonomously in alignment with my responsibilities and in coordination with others - How does manageent perceiveon Determine16. innovation and alternativeideas is supported and reewarded. 16 IND.Innovation.16 .nnowadoen mnedent pce Current ]There Credt[] Neens necessary Determine how one's capabilities arerealised and utilized To determine the degree of awareness of other party's needs and preferences 17 18 IND.CapableUse.17 INF.External.18 Current!! demanded byyour currentwork? Desired!! certain once the daily tasks reluctance to mention have been new ideas matter of using my capabilities It is not thought off 18. Are you confident the information you Current[] provide is what is required by the receiver? No 19. How would ratethe amountof Information/documents provided to you? Currentu] Too much than necessary 20. How frequent would you rate the amount of information/documents received? Current!! 21. How do you mainly draw the needed Information for your work? Current[] rnnrAm Are accepted but only is a It is not a 17. How much ofyour capabilities is I have sufficient freedom in my decisions to fulfil my tasks autonomously in alignment with my responsibilities and in coordination with others and this applies to the whole I am given the opportunity to think in the best way but of through how my fulfilling the assigned capabilities could be and demanded tasks best utillsed supported and rewarded I am at the right place where my potential and capabilities are continuously realised and utillsed accordingly It is entirely clear ro us what information is Mostly since Itand we need and the Sometimes, we learn documented communicated which Information from mistakes Information Is needed ansmission process optimized To determinethe appropriate volumeof information available for Proper functioning 19 INF.Volume.19 To determine the appropriate velocity of information received for proper functioning 20 INF.Velocity.20 To determinethe appropriate number of channels of interaction/sources of intrcinsucso nformation innformation fryu ok Too little or nearly non-e xistent A bit much A bit little Too frequent that I find it challenging to Interpret A bit too frequent A bit too delayed Not necessary. The Information would I would ask for it before It is available I would delegate and come to me. information forecoming Too delayed that it leaves me almost no time to react Not necessary. I would mainly be the would be one providing information Page 132 % Responsible (eg monitoring, tracking) activities in role of responsible, :ontributing or receiving of nformation 2 22 INF.Sources.22 PIS rte you spend of work pent the below activi ties: onthe Contributing (eg providing info, generating delivera bles/documents) % ro determine the weight of actor' Informed (eg interpreting, analysis, studying) Page 133 Appendix C - Program Manager Interview Questions Kindly help us answer the following questions which will help us understand how the approach would help your program better. Interview about your Program 1. How long do you expect a typical program to last, such as this? 2. Do you perceive that similar programs would last longer or cut short in the future? What are 3 or more factors that drive this trend? 3. Of the 3 program attributes of delivery date, budget and availability of resources/ participation, which one is the most rigid to changes? Why is that so? 4a. What are the 3 challenges that you deem can fail the program if not handled properly? How do you manage these challenges? 4b. Rate between 1 and 5for each, with 1 being the worst and 5 being the best to using the belowfor program improvement: " * " Integrate all program elements and functions through Program Governance Pursue collaborative and inclusive decision making that resolves the root causes of issues Ensure clear responsibility, accountability, and authority (RAA) throughout the program from initial requirement definition to final delivery e Map the management and engineering value streams and eliminate non-value-added elements Focus all program activities on the benefits that the program intends to deliver * * Establish the value and benefit of the program to the stakeholders Encourage personal networks and interactions * 5a. What are the 3 limitations of using the 'solution objective matrix' of TCS? Page 134 5b. Rate between 1 and 5for each, with 1 being the worst and 5 being the best for using the 'solution objective matrix'for e Aligning on program expectations * " Facilitating on identification of required resources and activities Facilitating definition of deliverables for program " " Tracking progress of program Measuring outcomes and results * Facilitating modifications to react to undesirable outcomes Interview about your Organization 6a. What are the 3 capabilities you deem lacking in your organization? 6b. What are the 3 capabilities you deem competitive in your industry? 7a. What are the 3 benefits of the technologies that drive your organization to adopt? Eg WindChill 7b. What are the improvements you deem necessary on top of these technologies? 8. What percent of the program governance can be mapped to the existing organization structure? Interview about your Practice (This is a continuation on Survey Questionaire Part 1) 9. Please state your definition of "Responsible" and describe your role and responsibility within the program. 10. How do you ensure that you are informed of necessary information? If not, how would you propose you are informed of necessary information? Page 135 Interview about ESTPA 11a. By what percent do you deem the value matrix can be generated from the 'solution objective matrix'? 11b. Does the 'value matrix' solve the limitations of the 'solution objective matrix' and how does it do so? 11c. Rate between 1 and 5for each, with 1 being the worst and 5 being the best for using the 'value matrix'for e " * * Aligning on program expectations Facilitating on identification of required resources and activities Facilitating definition of deliverables for program e Tracking progress of program Measuring outcomes and results * Facilitating modifications to react to undesirable outcomes 12a. By what percent do you deem the hierarchical control structure can be generated from the existing program governance structure? 12b. Rate between 1 and 5for each, with 1 being the worst and 5 being the best for using the hierarchical control structure for * * * Aligning on program expectations Facilitating on identification of required resources and activities Facilitating definition of deliverables for program " Tracking progress of program * * Measuring outcomes and results Facilitating modifications to react to undesirable outcomes Page 136 13. Rate between 1 and 5for each, with 1 being the worst and 5 being the best for using the ESTPAproposed process modelfor * Aligning on program expectations * e Facilitating on identification of required resources and activities Facilitating definition of deliverables for program " * Tracking progress of program Measuring outcomes and results e Facilitating modifications to react to undesirable outcomes 14. Rate between 1 and 5 for each, with 1 being the worst and 5 being the best to using ESTPA for program improvement: 0 * Integrate all program elements and functions through Program Governance Pursue collaborative and inclusive decision making that resolves the root causes of issues * Ensure clear responsibility, accountability, and authority (RAA) throughout the program from initial requirement definition to final delivery Map the management and engineering value streams and eliminate non-value-added elements Focus all program activities on the benefits that the program intends to deliver 0 * * * Establish the value and benefit of the program to the stakeholders Encourage personal networks and interactions 15. Please give 1 recommendation for each of the above applicable to the program. 15. Please describe the necessary actions required to apply ESTPA to change programs and the potential negative impacts to the: * Program " * Organization Your Practice (Individual processes, activities and information management) ~THANKYOU~ Page 137 Appendix D - Stakeholder/Actor Value Role *Engine Manufacturer Steering Committee Rpnpficiaripq Bpnefits/Information TCS Delivery Center Head Change Alignment/Client perception on program From: OC Manager, Business Process Lead, IT Leader, Quality Leader, Deployment Manager How: Client feedback from individual customer BU Client-TCS Alignment /Program planning progress From: Program Manager How: Proeram comoiled reDorts Enterprise Golive/Function progress From: Enterprise Function How: Quality Leader BU Golive/Function progress From: Enterprise Function How: - - Business Process Lead TCS Near Shore - Main Development Team Benefits/information Beneficiaries Page 138 Project Manager Meet Project Plan (Schedule, Quality)/Project Progress From: Technical Lead, Q.A Lead, Development Lead How: Status report of deliverable items completed and tested. Meet expectation of Enterprise changes/Customer Requests From: Customer Program Manager, Client Project Leader - How: WindchIll Developer Meet expectation of Enterprise changes/Windchill specification doc From: PTC - How: Meet expectation of Enterprise changes/Functional specification doc From: Business Consultants/Analysts How: Through reouirement management tool. QA Lead* Meet Project Quality/QA report From: Tester How: Through generated reports Solution Architect* Architecture/Change Control From: Technical Lead/Workgroup Manager How: Through renuirement management tool. CCB. Business Consultant/Analyst* Functional Design/Requirement From: Technical Lead/Workgroup Manager How: Through reauirement management tool Technical Analyst* Completion of assignment/Functional Design doc From: Solution Design Lead/Business consultant How: Through requirement management tool. Page 139 TCS Near Shore - CoE Centers Beneficiaries PLM CAD ERP Benefits/Information TCS Near Shore - Support Group Beneficiaries Benefits/Information Tester Training Lead Trainer Tr Content Creator OCM Lead OCr Member (1U)2Data Migration Lead Database Developer tWing TCS @ Customer - Onsite Development Team Benefits/Information Technical Lead @client Meet expectation of Enterprise changes/Function & bug fix progress From: Windchill Developer @ client How: - Beneficiaries Page 140 Business Consultants/Workgroup Manager @client Change Alignment/Requirement From: Customer Cross Functional Team/IT How: 'Pull' meeting - Meet expectation of Enterprise changes/Solution alignment From: Windchill Developer, solution architect How: Customer - Conference Live Test Benefits/Information Beneficiaries Program QA Lead Quality Manager Customer - Enterprise Function r 'Pet pannmng progress 7 2 ogmss(signoff) 11 OVY enf/Am 0Poj leader, CFT mrembe rKe ) Benefits/information Ch Po %imenit /Un tion progress Cfia FromMC5 Poj ct Mariagr Project Leader Change Alignment /Customer Requests From: TCS Project Manager - How: Change Alignment/Functional Test feedback From: Function team members, IT How: - wae Beneficiaries CustoMe'r Program Ma"ge Functional Team . ifat'~or /Te Osi ato rn $ Poject, Manager' Kc P IT User Satisfaction/Test simulation Page 141 - From: TCS Project Manager How: Customer - Function Team (focus on NPI) Beneficiaries Benefits/information Marketing Lead New Rational Product Proposals/New Product Recommendation From: Marketing How: Windchill customized PDR (details in process model) Project Office New project success (iron Triangle trade-off)/Project proposal From: Marketing How: Windchill customized PDR (details in process model) New project success (Iron Triange trade-off)/Schedule availability From: Project Leader - Hnw: Finance Not mentioned(Value: Involvement of Finance from Concept Phasej Page 142 Appendix E - TCS Tractor and Engine Manufacturer's Change Program Part 1 - Tractor Manufacturer Change Program (Completed) wave 1 Wave 2 C-ost Managernent ConceptI Beul Vendo Mainteeface Mcdu -oui modute - vendwr Managemewnt aidation Modul ProjeCt AnaWy"jCS rkk SAP X -- P -1n; rface Mdlu;e Part 2 - Engine Manufacturer Change Program (Ongoing) Page 143 Appendix F - Major Data from Survey and Interview Part 1 - Socio-Cultural-Infological Background of Tractor Project Office Hierarchical 4 Standardized Process Decision Transparency Activej learly Defined Communication Role Organization 20 10/ Technology Program 5 -C a Quality of Output A information Current -Desired Individual Task info Processing Load Contributing over Informing Velocity of Info Overview 4 Motivated on Task Autonomy Encourage Innovation Page 144 Part 2 - Socio-Cultural-Infological Background of Tractor Marketing Hierarchical 4 Stan( Decision Transparency Pr Active Communicati on Clear Vision Clearly Defined R ole 3 Organization 20 Clear Objective MutualTrust 10 5 Technology Information Irogram 4 info Processing Load informing 4 Velocity of Info .- Desired Task Overview 4 over Current - Idividu a lity of Output Contributing - Motivated on Task Autonomy y A Encourage Innovation Page 145 Part 3 - Major Data for Program Management Factors driving trend of short-duration program (2-4yr): Reusability of processes and data with migration, availability of out-of-the-box (OOTB) process, maturity of PLM product, harmonized processes, mental acceptance to change Program challenges: Quest for sponsorship, proper governance, meet program scope, process acceptance by users, customer change requests, scope creep, human communication, visibility and reporting, decision making Benefits of IT to program: Harmonized process, reduced cost, product scalability, in-time collaboration, visibility, traceability, centralized knowledge base, accessibility for design, build, support Necessary improvement to IT for program: Human readiness to change, business buy-in, flexibility to derive customized reporting and notification, engineering cost management improvement, robust tools and processes, harmonized enterprise architecture Page 146