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