Supporting business decisions in the technological enterprise
Download as PPTX, PDF2 likes594 views
The document outlines William P. Hall’s insights into business decision-making within technological enterprises, emphasizing the complexity of organizations as living systems. It explores the importance of knowledge management, organizational imperatives, and the balance between decision-making authority and bounded rationality, illustrated through the successful management of a $7 billion shipbuilding project. Additionally, it discusses the implications of failure to transfer knowledge across projects, leading to corporate disintegration.
![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](https://image.slidesharecdn.com/supportingbusinessdecisions-140428230555-phpapp02/85/Supporting-business-decisions-in-the-technological-enterprise-32-320.jpg)
Supporting business decisions in the technological enterprise
- 1. William P. Hall, PhD President Kororoit Institute Proponents and Supporters Assoc., Inc. - http://kororoit.org Associate EA Principals – http://eaprincipals.com william-hall@bigpond.com http://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 Attribution CC BY
- 2. 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
- 3. 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 enterprises3
- 4. 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.
- 5. 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 Organizational knowledge Leave one of the legs off, and the stool will fall over
- 6. 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
- 7. 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
- 8. 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
- 9. 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
- 10. 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
- 11. Putting theory into practice Understanding how to manage organizational knowledge flows naturally from the biological point of view
- 12. 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
- 13. 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 profitably13
- 14. 14 ANZAC Ship Project What 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
- 15. 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.
- 16. TE&V Test, 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
- 17. 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
- 18. Measures for RAMS Reliability = MTBF = (op hrs / failures) Availability = Ao = uptime / (uptime + downtime) Maintainability = MTTR = avge (TTR) Sustainability = MLDT = avge (job time - ADT - TTR)
- 19. 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
- 20. CSARS: What does it look like? Hierarchy Failed threshold Search engine Calculation results Ship Calculation Calculation thresholds Hierarchy:
- 21. CSARS: What does it look like? Calculation results Redundant equipment Non-critical equipment Zoom Drill-down block Failed threshold Print Calculation thresholds Availability Block Diagram:
- 22. 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.
- 23. 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 system23
- 24. 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
- 25. Knowledge development lifecycle for a large project Project A Design Study Review, edit, signoff Negotiate Review, agree, amend Project A Prime Contract RFT and Bid Review, edit, signoff Project A Bid Documents RFQs Bids Negotiations Project A Subcontracts Review, agree, amend Project A Procedures, Design Docs Review, edit, signoff Project A Support Documents •20 - 50 year lifecycle Project B Design Study Review, edit, signoff Project B Design Study Review, edit, signoff Project B Design Study Review, edit, signoff Operational experience Negotiate
- 26. MRP / PRODUCTION MGMT • MBOM • Production planning • Production schedule • Procurement • Warehousing • Establish & release workorders HRM Accounting CS 2 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 specifications and attributes DOCUMENT CONTENT (structured documents ) MODELS: • Element definitions - Content - Attributes • Element hierarchies • Element sequences OUTPUT OBJECTS • Contract/subcontract documents • Procedures/instructions • Deliverable documents • All other controlled documents 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 Catalogue Drawings VAULT Requirements tracking DOCUMENT PROD MGMT • Author • Production schedule • Check out / check in • Track and review • Deliver • Manage configuration & change Project Schedule
- 27. The full knowledge management environment for ship support Tenix Navy
- 28. 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
- 29. 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.
- 30. 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
- 31. KM systems in the high-tech enterprise People Process Technology infrastructure Organizational knowledge Leave one of the legs off, and the stool will fall over
- 32. 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
- 33. 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
- 34. 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
- 35. 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.
- 36. 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
- 37. 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”
- 38. 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.
- 39. END