Upload
william-hall
View
120
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Lecture for Business Systems Analysis. Explores some aspects of organization theory and bounded rationality as these have been applied over the 17+ year history of a major shipbuilding contract in the context of a large defense engineering and project management enterprise. Cases include (1) proving to the Client that contractual operational availability targets were met over 10 ship-years in service, (2) analyzing and designing a system to capture, manage, and deliver to both crew and a relationally based computerized management system all technical data and procedural knowledge required to maintain the ships through a 27 year life-span, (3) understanding how the company failed through its failure to complete a smaller, simpler shipbuilding project following on from the successful and profitable completion of the much larger and more complex project
Citation preview
William P. Hall, PhD
PresidentKororoit Institute Proponents and Supporters Assoc., Inc. - http://kororoit.org
AssociateEA Principals – http://eaprincipals.com
[email protected]://www.orgs-evolution-knowledge.net
Supporting business decisions in the technological enterprise
Access my research papers from Google Citations
Presentation for
MGMT20005 Business Decision Analysis
4/30/2014
AttributionCC BY
Overview
A bit of theory– Organizations are complex living systems– Understanding organizational imperatives– Herbert Simon and the limits to rationality
Some practical experiences– Tenix Defence – once a $ bn defence engineering project
management company now extinct– Organizational imperative: successfully complete a $7 bn
contract to build 10 warships for two national navies– Contract analysis– Operational Availability Assessment– Feeding a relational database with documents written by
fallible humans
2
My background
Physics / evolutionary biology (PhD Harvard, 1973) 1981-1989: tech communicator/doc manager (computer
literacy, software development, banking) 1990-2007: documentation and KM systems analyst/designer
for Tenix Defence/$ 7 BN ANZAC Ship Project 2001: research focus on knowledge-based organizations 2011: TOGAF9 Certified Enterprise Architect Currently finishing a book project, Application Holy Wars or a
New Reformation - A fugue on the theory of knowledge– Co-evolution & revolutions in human cognition and cognitive
tools– Theory of knowledge-based living systems (cells, organisms,
organizations)– How did savanna apes become human and conquer the world– What’s next?
Humano-technical cyborgs Sociotechnical enterprises
3
A Peek at some theory
• Vines, R., Hall, W.P. 2011. Exploring the foundations of organizational knowledge. Kororoit Institute Working Papers No. 3: 1-39.
• Hall, W.P., Else, S., Martin, C., Philp, W. 2011. Time-based frameworks for valuing knowledge: maintaining strategic knowledge. Kororoit Institute Working Papers No. 1: 1-28.
• Hall, W.P. 2011. Physical basis for the emergence of autopoiesis, cognition and knowledge. Kororoit Institute Working Papers No. 2: 1-63.
What is an enterprise?
A coherently definable organized entity that may be:– Public or private sector organizations – Coherent military tactical unit – Ship and its crew
Exhibits some or all characteristics of hierarchical complexity, reactivity, adaptability, emergence, downward and upward causation, self-organization, non-linear / chaotic responses
An organized, notionally bounded socio-technical system, addressing its internal / external imperatives for success / survival (i.e., an “organic” entity), comprised of
– People (participants in the organization from time to time)– Processes (automated, documented, tacit routines, etc.)– Infrastructure (ICT, physical plant, etc.)– Defined by organizational knowledge (i.e., contributing to org.
structure/success) Knowledge as a deliverable product (e.g., technical documentation) Knowledge about and embodied in deliverable products Knowledge about and embodied in organizational processes
and infrastructure Members’ personal knowledge relating to their organizational
roles
Peop
le
Pro
cess
Infra
stru
ctu
re
Organizational knowledge
Leave one of the legs off, and
the stool will fall over
Enterprises are living,complex systems of systems
Systems address the enterprise’s imperatives– Systems are comprised of interacting processes supported by applications and
infrastructure and involve people as well as technology– Knowledge determines how systems work
Enterprise architecture designs and develops frameworks and methodologies for analyzing, understanding, and improving the systems structure
Working with living organizations
Imperatives: Living things have requisite inputs they must satisfy to avoid disintegration– Living people work together to make living
organizations– Living things that contain living components
must satisfy their components’ imperatives for life
Possibilities: Capabilities inherent in the organization
Constraints: The environment constrains possible actions, both positively and negatively
Enterprise management considerations
Focus on the situation of the enterprise– External situation
Dynamic environment– position relative to competitors– changing factors
Strategic context: challenges & advantages (how to protect and extend control over requisites for existence)
– Internal situation Organizational structure (functional subdivisions, etc.) Purpose, vision, values, mission People profile Organizational assets (tangible, intangible) Product/service offerings Stakeholders (internal/external) Performance management/improvement system capabilities
– External must enable internal / Internal must satisfy external
Enterprise management considerations
Focus on making and supporting decisions– Provide the environment for effective decisions
Recognize the bounds of rationality: Manage delegation– provide adequate time (no decision is worse than a bad
decision!)– make important knowledge reliable and readily retrievable– establish responsibility and authority
Provide & manage appropriate organizational resources and technologies to support decisions
– tacit and implicit personal knowledge– valid and effective documentation and appropriate data– effective training and decision procedures
– Audit and manage organizational performance (i.e., maintain effective feedback for continuous improvement)
Measure Analyze & review Improve
Bounded rationality and limits to organisation:
Herbert Simon and Steve Else
Steven Else (2004) Organization Theory and the Transformation of Large, Complex Organizations -- Donald H. Rumsfeld and the U.S. Department of Defense, 2001-04, PhD Thesis, Denver University– people are limited - 'bounded rationality' (H. Simon 1955,
1957)– best decision the organisation can strive for is 'just good
enough', or 'satisficing' rather than optimising ; (K. Arrow 1974)
– Do your best and go on to the next (Amway sales training) Some conclusions
– Overcentralization of decision making is a recipe for disaster bounded rationality puts upper limit on observation overloaded central decision maker loses touch with reality
– Orgs must delegate decisions to periphery as they grow Need to balance between ability to observe and ability to make
effective decisions The management style and management of knowledge both
must change as the organisation grows in order to maintain balance
Putting theory into practice
Understanding how to manage organizational knowledge flows
naturally from the biological point of view
17 years in production In service for 27 years Integrated Logistic Support Warranty
– 12 months for each ship – 2 year latent defects period
10 ship years of Operational Availability Assessment Period– Ship to be available 80% of time– Critical systems available 90% of time– Develop system to prove to the
Client that thresholds have been met
8 ships RAN ( + 2 for RNZN) 2 Shore facilities (+1 for RNZN) Design & systems integration 80% Australian & New Zealand
Industry Participation
Fixed price/schedule contract! Support engineering
– Full fitouts & supply chain spares– Crew training– Operations manuals– 2000+ maintenance procedures/ship– Readable by relational database
system!
The 17 year ANZAC Ship Project Contract
To survive enterprises must address imperatives in their contexts
Enterprises are living entities– Require cash flow & staff replacement– Failure to satisfy imperatives leads to disintegration
No enterprise exists in isolation from its contexts– What are its imperatives for continued existence?– Organizational systems satisfying imperatives must track
continually changing contexts with observations, decisions and actions
Tenix’s primary imperatives– Win contract(s)– Deliver on contract(s)– Satisfy customer(s)– Comply with regulatory requirements– Perform profitably
13
14
ANZAC Ship ProjectWhat does an imperative look like?
10 ships must be accepted $A 7 Bn project value Non acceptance = non-payment, project delay, liquidated
damages + reputational damage Make a profit - Satisfy customers
Operational Availability Recording and Reporting
System
• Hall, W.P. Beer, J., & McFie, K. 2002. Managing maintenance to reduce life-cycle costs for a multi-national fleet of warships. Proceedings. International Maintenance Management Conference, 29-30 August, 2002, Gold Coast, Queensland
• Hall, W.P., Beer, J. & McCauley, B. 2002. Improving the quality of fleet/facility support knowledge. Proceedings of the Australian Conference for Knowledge Management & Intelligent Decision Support, ACKMIDS 2002 Melbourne, Australia, 9-10 December 2002.
TE&VTest, Evaluation, & Validation
Contract requirements: – Each ship in service is available to meet operational
requirements 80% of time and each of ~20 “critical” systems available 90% of time.
– Contract requirement: prove to Client that contractor provided ship design and integrated logistic support package has met these requirements over first 10 years of operational experience (“Operational Availability Recording and Reporting”)
4 years for Ship 1 3 years for Ship 2 2 years for Ship 3 1 year for Ship 4
Covers on-board, base & supply chain spares, maintenance procedures (i.e., knowledge transfers via documentation & training), initial fitout.
Contractor must bear all costs of correcting any/all shortfalls & changes required to meet OA thresholds
16
CSARS: Class Systems Analysis And Reporting Software
Tenix's TE&V role with OARRS– Data collection completed 19 Oct 00– ILS TE&V completion Dec 01 – Passed with complete customer satisfaction
Client wanted to extend our software tool for analysing ‘actual’ system & equipment performance across entire fleet
Means of conducting:– Reliability – Availability– Maintainability– Sustainability
RAMS Analysis
Measures for RAMS
Reliability = MTBF = (op hrs / failures)
Availability = Ao = uptime / (uptime +
downtime)
Maintainability = MTTR = avge (TTR)
Sustainability = MLDT = avge (job time - ADT -
TTR)
Where does CSARS help?
Informed Decision Making− Determine existing capability− Prioritise tasks for maintenance − Manage repairables and materiel support− Determine effectiveness of support− Prioritise systems for cost analysis
Continuous Improvement− Data collection and reporting mechanisms− Org, Intermed & Depot level planned maintenance− Estimating required inventory for "surge" capacity− Input to life-cycle costing tools
CSARS: What does it look like?
Hierarchy
Failed threshold
Search engine
Calculation results
Ship
Calculation
Calculation thresholds
Hierarchy:
CSARS: What does it look like?
Calculation results
Redundant equipment Non-critical
equipment
Zoom
Drill-down block
Failed threshold
Calculation thresholds
Availability Block Diagram:
Engineering a knowledge capture and transfer
system to support ships
• Hall, W.P. 2001. Writing and managing maintenance procedures for a class of warships: A case for structured authoring and content management. May 2001 issue of Technical Communication, the professional journal of the Society for Technical Communication.
• Hall, W.P., Richards, G., Sarelius, C., Kilpatrick, B. 2008. Organisational management of project and technical knowledge over fleet lifecycles. Australian Journal of Mechanical Engineering. 5(2):81-95.
Support engineering and operating knowledge
Contractual responsibility to provide training and documentation package as well as ships (i.e., a complete knowledge base)– Training facilities and simulators– Crew training materials– Complete operating manuals (captain and
crew)– Maintenance philosophy– Maintenance procedures and documentation
Original concept – paper manuals Cost neutral contract amendment
– Feed everything into computerized maintenance management system
23
Imperatives for delivering knowledge or using it in an engineering/production
environment
Customer end user's knowledge imperatives– Correct
Correct information Consistent across the fleet / product range
– Applicable/Effective Applicable to the configuration of the individual product Effective for the point in time re engineering changes, etc.
– Available To who needs it, when and where it is needed
– Useable Readily understandable by those needing it Readily managed & processed in computer systems
Supplier's knowledge production and usage goals– Fast– High quality– Low cost
Knowledge development lifecycle for a large project
Project ADesign Study
Review, edit, signoff
Negotiate
Review, agree, amend
Project APrime Contract
RFT and Bid
Review, edit, signoff
Project ABid Documents
RFQs
BidsNegotiations
Project ASubcontracts
Review,agree, amend
Project AProcedures,Design Docs
Review,edit,
signoff
Project ASupport Documents
•20 - 50 year lifecycle
Project BDesign Study
Review, edit, signoff
Project BDesign Study
Review, edit, signoff
Project BDesign Study
Review, edit, signoff
Operationalexperience
Negotiate
MRP / PRODUCTION MGMT•MBOM•Production planning•Production schedule•Procurement•Warehousing•Establish & release workorders HRM
Accounting
CS2
Contract Requirements
Capability requirements Documentation requirements
PRODUCT MANAGEMENT(structured designs )
MODELS:•Component definitions•Component hierarchies
-System-Physical structural-Availability
OBJECTS MANAGED•Drawings•Parts lists•Configurations•Component specificationsand attributes
DOCUMENT CONTENT(structured documents )
MODELS:•Element definitions
-Content-Attributes
•Element hierarchies•Element sequences
OUTPUT OBJECTS•Contract/subcontractdocuments
•Procedures/instructions•Deliverable documents•All other controlleddocuments
COMMON REQUIREMENTS•Config control / Change mgmt
-Develop/Author-Release-Applicability, Effectivity
•Workflow management-Configuration changes-Document changes-Other business objects
•Track and control source data
Link element to component
Manage elements
LSAR databaseEBOMEBOM
Docu
ment
changes
Catalogue
Drawings
VAULT
Requirements tracking
DOCUMENT PROD MGMT• Author• Production schedule
• Check out / check in• Track and review• Deliver• Manage configuration & change
Pro
ductio
n ch
ang
es
ProjectSchedule
The full knowledge management environment for ship support
Tenix Navy
Tenix ANZAC’s measured improvements from KM solution
Tenix’s Ship 05 delivery challenge– For safe maintenance “documents” must be understood by human
maintainers and computerized maintenance management system– Document & engineering change management issues– Client threat to not accept 05 if still dissatisfied
Structured authoring solution resolved the issue– Condensed 8,000 procedures for 4 ships to class-set of less than
2,000 ‘structured documents’ for 10 ships Routines delivered for Ship 5 CUT 80% Subsequent content deliveries CUT 95% Keyboard time for one change CUT more than 50% Change cycle time CUT from 1 year to days
$ 7 Billion 17+ year long project completed successfully– Each ship delivered on time - every time– For the stringently fixed price – no cost overruns!– For a healthy company profit– Today, the customers are still happy with the ships
The company failed and disintegrated on its next largish project because it did not transfer its learning from the old project
Some businesses work hard to be stupid
• Nousala, S., Miles, A., Kilpatrick, B., Hall, W.P. 2005. Building knowledge sharing communities using team expertise access maps (TEAM). Proceedings, KMAP05 Knowledge Management in Asia Pacific Wellington, N.Z. 28-29 November 2005.
• Hall, W.P., Nousala, S., Kilpatrick B. 2009. One company – two outcomes: knowledge integration vs corporate disintegration in the absence of knowledge management. VINE: The journal of information and knowledge management systems 39(3), 242-258.
Why is knowledge important to the enterprise?
Tech enterprises and products are knowledge intensive– to design– to manufacture– to operate
Processes and products are fallible! Organisations are complex dynamic systems
– Difference between complex and complicated Organisations have minds of their own (my research
area) Cannot be predicted, can only be constrained
– Depend on "system of systems" to manage knowledge
– System of systems components include People Processes Infrastructure technology
KM systems in the high-tech enterprise
People Process Technology
infrastructure
Peop
le
Pro
cess
Infra
stru
ctu
re
Organizational knowledge
Leave one of the legs off, and the stool will fall over
Limits to knowledge and organisation
Rationality in making decisions (key part of OODA loop)“A decision making effort that exhausts all potentially relevant [knowledge] in order to make decisions in a transparently logical and objective fashion.” (Else 2004)
Organisations and people have limited capability (subsystem laws)
– Bounded rationality (Simon 1957). Models of Man Limits on decision making caused by limits on costs, human abilities, time, technology, and availability of [knowledge].
Boundaryless Careers - Arthur & Rousseau (1996)– People belonging to organisations are not owned by them– People have careers outside of any one organisation
Limits of Organisation - Arrow (1974 - see Else 2004)– As limited by bounded rationality of individual people– As limited by organisational structure, governance, etc
Tenix: engineering project management org
Successfully completed $ 7 BN technologically complex and knowledge intense ANZAC shipbuilding project
– 10 similar (but not identical!) ships for two customers– Fixed price contract negotiated 17½ years previously– Managed ~20 subcontracts worth more than $100 M ea– Finished
On time On budget (with escalation clauses to cover currency fluctuations, labor rates,
raw materials) Happy customers
– Profitable “cash-cow” allowed company to acquire several new divisions
Tenix: Project Protector (RNZN)
$ 500 M fixed price follow-on project– Three year project– Build to “commercial” standards– Seven ships constituting three different types for one customer– Complete budget blow-out– First ship delivered 6 months late, others farther behind
schedule Company owners auctioned company at “fire sale” price
– Multi-billion dollar order book– Pre auction estimate was that company was worth $A 1 BN– Sold in January 2008 for ~$A 775 M– Cost to owners thus on the order of $A 225 M!
1 2 4
Background Company/management characteristics
– Family owned– Distributed work sites– “Absentee” senior executives (different state from where work done)– Deep line-management hierarchy– Command and control philosophy – don’t disagree with boss always
knows best– Execs & line managers didn’t understand IT (i.e., pencil & paper people)– Senior managers sacked for errors & “mistakes” with high turn-over (2-3
yr)– Retrospective bonuses (Tenix value added)
Aspects of successful project– Stable, conscientious work force – many with 10 and 20 year pins– Long duration, with significant serial production facilitated org learning– Costly problems in design and early production stages
Difficulties/delay getting IP and technical data for engineering and support Engineering configuration management and change control Difficulties delivering coherent technical data and documentation to client
– Cost-effective solutions found and built into processes and practices, but…
Executives did not direct and were probably unaware of solutions Solutions requiring investment often suffered inordinate approval delays Some critical solutions funded by subterfuge from current operating budgets
– Solutions + effective IT significantly reduced costs.
Background – cont.
Finishing the successful project– Owners hired overseas “close-out” specialist as divisional EGM
His bonus based on added profit squeezed from old project Line managers only knew smooth running serial production Implemented strict time-costing to the half hour All time required to be allocated to project line item cost code Costly staff quickly made redundant when no longer needed for
project EGM approval required for “outsiders” to meet project staff Morale became very poor
Follow-on project– 3 year fixed-price project– Assumed to be “commercial” work– Limited opportunities for serial production– Costing assumed existing efficiencies would transfer to
Protector with less technology & control– Started before ANZAC Project finished– New (cheaper) people were hired for Protector
Few had experience with naval or even defence projects– A security fence was built between the projects
EPMO failed to recognize and transfer organisational knowledge
Knowledge management expertise located in “rump” head office– R&D manager, Chief Engineer, Snr Systems Engineer, KM analyst, 2 PhD
students as KM Interns– Verbal support from GM Engineering who lacked enforcement power– KM funding only for analyst salary (i.e., no budget, no travel)– Advisory only (no power to implement anything)
As the new project was being negotiated– New staff knew theory but lacked experience in naval engineering
programs– KM group developed prototyped methods identify, map and transfer
critical knowledge & lessons learned by ANZAC project Prototype proved old hands would happily share experience and “war stories” Analysis and prototype validated and published as a peer reviewed paper
– Three formal attempts to implement knowledge mapping/transfer program
Pre-negotiation stage – first prototype by KM analyst & Risk Manager - knocked back by Production Manager
Early negotiations – proposal additionally supported by availability of PhD student to manage interview & mapping process & systems engineer to develop software – knocked back by line managers
Project mobilisation – proposal additionally adopted by Special Project Manager responsible for IT implementation – same result.
Line management blocked access to both new hires and old hands as “time wasting”
The importance of people and culture
Example: board spent $ M to implement corporate portal– Hired outside contractor to select system– Did not consult staff to understand what was needed– Would not pay for additional modules to make it work– Would not fund support staff
To develop processes To develop taxonomies To provide more than minimal training
Fundamental issues for the technology organisation– Living knowledge is intangible and is produced and used by
people– Executive’s bounded rationality
Understand some technology proposals and would pay to implement it
Did not understand people, or follow value arguments about people and culture, and will not approve what they do not understand
– Finance and admin people, can identify the cost of everything but cannot compute the value of knowledge developed by people and processes.
Managing technological enterprises is mostly about managing people and knowledge
Failing to understand manage people and organisational culture can kill people & destroy organisations.
END