Presentation is loading. Please wait.

Presentation is loading. Please wait.

421-672 Management of Technological Enterprises Managing Knowledge in Technological Enterprises (Tutorial 1): Knowledge engineering in the engineering.

Similar presentations


Presentation on theme: "421-672 Management of Technological Enterprises Managing Knowledge in Technological Enterprises (Tutorial 1): Knowledge engineering in the engineering."— Presentation transcript:

1 Management of Technological Enterprises Managing Knowledge in Technological Enterprises (Tutorial 1): Knowledge engineering in the engineering organisation William P. (Bill) Hall (PhD) Evolutionary Biology of Species and Organizations Documentation and KM Systems Analyst (retired) Tenix Group Head Office, Williamstown, Vic. (retired July 2007) National Fellow Australian Centre for Science, Innovation and Society Melbourne University Uni Office: ICT 5.59, 111 Barry St., Carlton Phone: (Mon, Tue, Thurs only) TUTORIAL: 20 March 2009

2 Why is knowledge important to the enterprise? Tech enterprises and engineering products are knowledge intensive –to design –to manufacture –to operate Engineering 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

3 KM systems in the high-tech enterprise People Process Technology infrastructure People Process Infrastructure Organizational knowledge Leave one of the legs off, and the stool will fall over

4 Adequate performance on all issues depends on the quality of authoring, management and transfer of technical knowledge from supplier to operators Organisational knowledge management imperatives Capability when it is needed –Reliably does what it is supposed to –Available for service when needed –Maintainable - problems can be fixed when they arise –Supportable - critical needs available in supply chain –Operable within limits of human knowledge & capacity Health, safety and operational knowledge issues –Heavy/complex engineered products can kill! Life-cycle cost –Minimise acquisition cost –Minimise documentation, support & maintenance costs –Implement "lean maintenance" philosophy

5 Major quality issues in delivering product operational and support knowledge Knowledge delivery goals (only people apply knowledge) –Correct Correct information Consistent across the organisation –Applicable/Effective Applicable to the location of use Effective for the time of use re engineering changes, etc. –Available! Accessible to those who need it, when and where it is needed –Useable Readily understandable by humans Readily managed & processed in computer systems Enterprise knowledge production and usage goals –Fast –High quality –Low cost

6 Objective knowledge development lifecycle for a large project Project A Design Study Review, edit, signoff Negotiate Review, negotiate, amend Project A Prime Contract RFT and Bid Review, edit, signoff Project A Bid Documents RFQs Bids Negotiations Project A Subcontracts Review, negotiate, amend Project A Procedures, Design Docs Review, edit, signoff Project A Support Documents 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

7 PROCESS PEOPLE Implementing OODA system of systems in the organisation CULTURE & PARADIGMS INFRASTRUCTURE CORPORATE MEMORY INPUT ANALYSIS SYNTHESIS PEOPLE GENETIC HERITAGE DATACONTENT LINKS RELATIONS ANNOTA- TIONS OBSERVEDECIDE, ACT DOCSRECORDS © William P. Hall

8 Vines, R., Hall, W.P., Naismith L Exploring the foundations of organisational knowledge: An emergent synthesis grounded in thinking related to evolutionary biology. actKM Conference, Australian National University, Canberra, October 2007.Exploring the foundations of organisational knowledge: An emergent synthesis grounded in thinking related to evolutionary biology "Living knowledge: source of organisational knowledge

9 Organisational disciplines creating & using knowledge research and development business development systems engineering logistics support analysis (lifecycle management) project management / project controls contracting & procurement design systems integration configuration management and eng. change control production management technical data and documentation management QA/QC test & trials lifecycle support and maintenance

10 Systems and applications infrastructure recording and transmitting knowledge Tool areas –design & drawing tools –simulation and modelling tools –databases –authoring and content management systems –configuration and change management –cost and schedule control systems –knowledge retrieval –correspondence and action management –Integration environments Enterprise resource planning/management –product/program lifecycle management –information and knowledge retrieval –process automation tools Networking environments –portals –correspondence and action tracking

11 People issues recruitment training and career development facilitation and incentives networking and community building registering and finding skills mapping and tracking knowledge sharing and transferring knowledge making decisions organisational culture etc. ORGANISATIONAL CULTURE Organizational culture refers to the basic values, norms, beliefs, and practices that characterize the functioning of a particular institution. At the most basic level, organizational culture defines the assumptions that employees make as they carry out their work; it defines the way we do things here. An organizations culture is a powerful force that persists through reorganizations and the departure of key personnel.

12 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)Else 2004 Organisations and people have limited capability (subsystem laws) –Bounded rationality (Simon 1957). Models of ManBounded rationalitySimonModels of Man Limits on decision making caused by limits on costs, human abilities, time, technology, and availability of [knowledge]. Boundaryless Careers - Arthur & Rousseau (1996) Boundaryless Careers –People belonging to organisations are not owned by them –People have careers outside of any one organisation Limits of Organisation - Arrow ( see Else 2004) Limits of OrganisationArrowElse 2004 –As limited by bounded rationality of individual people –As limited by organisational structure, governance, etc

13 Process issues (all involve people) overall project management qualification and bidding simulation and modelling design and stage reviews change management problem management document authoring, production and publishing test and trial technical regulatory frameworks etc.

14 Infrastructure issues business analysis personal productivity tools product data, configuration and change management CAD, text authoring and simulation systems workflow enactment planning and control production management and tracking audit product engineering and maintenance support

15 Learning from our mistakes Introduction to Part II of the Columbia Accident Investigation Board Report: Many accident investigations do not go far enough. They identify the technical cause of the accident, and then connect it to a variant of operator error – the line worker who forgot to insert the bolt, the engineer who miscalculated the stress, or the manager who made the wrong decision. But this is seldom the entire issue. When the determinations of the causal chain are limited to the technical flaw and individual failure, typically the actions taken to prevent a similar event in the future are also limited: fix the technical problem and replace or retrain the individual responsible. Putting these corrections in place leads to another mistake – the belief that the problem is solved.

16 Why do engineers need to manage knowledge? Sections from Westgate Bridge at Monash Uni's department of Civil Engineering, Clayton What can go wrong? (most boil down to KM failures) –For example: (Wikipedia is a good place to start) 1984 Bhophal insecticide plant (India) - many thousands killedBhophal insecticide plant 1986 Chernobyl nuclear power plant explosion - hundreds killedChernobyl nuclear power plant explosion 1988 Piper Alpha killedPiper Alpha 1981 Kansas City Hyatt Regency Hotel Walkway Collapse killed (see also)Kansas City Hyatt Regency Hotel Walkway Collapsesee also 2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killedPetrobras P36 Offshore Oil Platform Sinking 2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris)Space Shuttle Columbia –Closer to home 1970 Westgate Bridge - 35 killed, many injuredWestgate Bridge 1998 HMAS Westralia - 4 killedHMAS Westralia 1998 Longford gas plant - 2 killed (see also)Longford gas plantsee also 2005 Sea King Helo Nias Island - 9 killedSea King Helo Nias Island

17 Why do engineers need to manage knowledge? And then there are the economic failures! –Cost overruns –Schedule blowouts –Legal actions –Reputational damages –Again, most could be avoided by better KM Auditor's reports provide good examples –Australian National Audit Office see especially: Management of the M113 APC Upgrade Project Amphibious Transport Ship Project Management of Major Equipment Acquisition Projects New Submarine Project Jindalee Operational Radar Network

18 The Challenger disaster Challenger disintegrated during the boost phase on January 28, crew were killed when the shuttle assemblage disintegrated as the result of a flame leak in the right Solid Rocket Booster (SRB) SRBs are 149 feet long and formed by joining 4 main sections. Two rubber O-rings in the SRB joints are supposed to stop leakage of hot gasses. It was known for several years that the O-rings were suffering burn damage, but managers believed that the second O-ring would stop fire leakage.

19 The Challenger Disaster Rubber becomes stiffer the colder it gets. The launch was decided in the coldest weather ever. Engineers warned of the danger of leakage through cold seals, but were bypassed.

20 The Challenger Disaster On launch, the cold, stiff O-rings to failed to seal in the lower joint of the right SRB. At liftoff, black smoke escaped from the joint, suggesting the O-rings were burning. The smoke stopped after about 2 seconds into the flight, when aluminium soot from the burning fuel apparently blocked the leak. At T+40 seconds, the shuttle was hit by strong wind shear. This was no danger to the shuttle itself, but stresses may have broken the soot blockage. By T+59 seconds, a plume of flame from the leak burned a hole in the external fuel tank (ET), storing liquid hydrogen and oxygen. At about T+73 seconds, the plume burned away the lower strut that attached the SRB to the ET. The SRB swung around and the nose slammed into the ET, causing liquid oxygen to spill out. Then the plume caused the dome on the bottom of the external tank to fail. This released thousands of gallons of liquid hydrogen. The ET is pressurized so the fuel will flow into the orbiter's main engines, so the fuel acted like a rocket motor, adding nearly 3 million pounds of thrust to the shuttle. This extra thrust was more than the ET could stand, and it broke apart. Aerodynamic stresses caused the shuttle itself to break up

21 The Challenger Disaster Primary reference - Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident June 6th, 1986;Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident Brief on the physical failure;physical failure See also: Mahal, The space shuttle Challenger accidentThe space shuttle Challenger accident Primary reference - Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident June 6th, 1986;Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident Brief on the physical failure;physical failure See also: Mahal, The space shuttle Challenger accidentThe space shuttle Challenger accident

22 Challenger: crucial management decisions Boisjoly, R.M Ethical decisions – Morton Thiokol and the Space Shuttle Challenger disaster.Ethical decisions – Morton Thiokol and the Space Shuttle Challenger disaster When Joe Kilminster of MTI was asked by Larry Mulloy of NASA for his launch decision. Jue responded the he did not recommend launching based upon the engineering position just presented. Then Larry Mulloy asked George Hardy of NASA for his launch decision. George responded that he was appalled at Thiokol's recommendation but said he would not launch over the contractor's objection. Then Larry Mulloy spent some time giving his views and interpretation of the data that was presented with his conclusion that the data presented was inconclusive. …NASA'S very nature since early space flight was to force contractors and themselves to prove that it was safe to fly. The statement by Larry MulIoy about our data being inconclusive should have been enough all by itself to stop the launch according to NASA'S own rules, but we all know that was not the case. Just as Larry Mulloy gave his conclusion, Joe Kilminster asked for a five-minute, off-line caucus to re-evaluate the data and as soon as the mute button was pushed, our General Manager, Jerry Mason, said in a soft voice, "We have to make a management decision.… Erosion in an exhaust nozzle O-ring comparable to the field joint O-rings

23 Challenger: crucial management decisions At the end of the discussion, Mason turned to Bob Lund, Vice President of Engineering at MTI, and told him to take off his engineering hat and to put on his management hat. The vote poll was taken by only the four senior executives present since the engineers were excluded from both the final discussion with management and the vote poll…. What is everyone's professional responsibility and ethical conduct code which should be practiced in the work place? The following advice was given by Mr. Adolph J. Ackerman in June, 1967, in an article published by the IEEE. I firmly believe that his advice is timeless and applies to all generations in engineering. Mr. Ackerman said, 'Engineers have a responsibility that goes far beyond the building of machines and systems. We cannot leave it to the technical illiterates, or even to literate and overloaded technical administrators to decide what is safe and for the public good. We must tell what we know, first through normal administrative channels, but when these fail, through whatever avenues we can find. Many claim that it is disloyal to protest. Sometimes the penalty disapproval, loss of status, even vilification--can be severe. Today we need more critical pronouncements and published declarations by engineers in high professional responsibilities. In some instances, such criticism must be severe if we are properly to serve mankind and preserve our freedom. Hence it is of the utmost importance that we maintain our freedom of communication in the engineering profession and to the public. The decades ahead are bound to be a critical and difficult period and there will be occasions for sharp dissent and strong words if we are to meet our responsibilities."

24 Challenger: summary of organisational issues Source: The Group Decision Support System (GDSS) … had the following failures: –The seal ring database was known to be flawed. Ideas, suggestions and objections were solicited, but not anonymously. Individuals who departed from accepted wisdom were flagged as unwelcome members of the GDSS. –An agenda was never defined, hence NASA were surprised by the Thiokol O-ring presentation and appalled by their decision not to launch. –Conflict management was avoided by NASAs domination of the meeting, and hence conflict was not satisfactorily resolved. –The GDSS setting was inappropriate for such an important decision. A face-face meeting would have allowed visual signals to play a role and the unhappiness of the Thiokol engineering representatives would have been apparent. –Thiokol should not have requested a 5 minute disconnection from the GDSS. This allowed other internal pressures to dominate their (undemocratic) decision. –The GDSS put safety last and operational goals first. Note that shuttle crew were not represented at the meeting, although they had the most to lose. Design Failures: –The design of the solid booster joint was insufficiently robust to cope with the effects of re-usability, low temperature O-ring compression response, and movement during acceleration and wing turbulence. –Lack of a safety culture which would put crew safety ahead of operational goals. –A flawed group decision support system.

25 EPMO: engineering project management org Successful $ 7 BN technologically complex and knowledge intense shipbuilding project –10 similar 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, labour rates, raw materials) Happy customers –Profitable cash-cow allowed company to acquire several new divisions

26 EPMO: Follow-on project $ 500 M fixed price follow-on project –Three year project –Built to commercial standards –Seven ships constituting three quite different types for one customer –Finishing way over budget –First ship delivered 6 months late, others all behind schedule Big losses led company owners to hold a fire sale auction –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!

27 EPMO Background Company/management characteristics –Family owned –Distributed work –Absentee senior executives (different state from where work done) –Deep line management hierarchy –Command and control philosophy – dont disagree with boss –Execs & line managers didnt understand IT (i.e., pencil & paper people) –Managers sacked for errors & mistakes –Hence, high turn-over of senior line managers (2-3 yr cycle) 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 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.

28 EPMO Background – cont. Finishing the successful project –Owners hired overseas close-out specialist as divisional EGM 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 follow-on with less technology & control –Started before successful project finished –New (cheaper) people were hired –Few had experience with naval projects –A security fence was built between the projects

29 EPMO failed to 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 hires knew theory but lacked experience in naval engineering programs –Methods for mapping knowledge in the old project were developed & successfully prototyped by people in Group/Division Head Office KM R&D Team: Analyst, KM Intern, Risk Manager/Project Controller, Jr Systems Engineer, Special Projects Manager Prototype proved old hands would happily share experience and war stories Analysis and prototype validated and published as a peer reviewed paperreviewed 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

30 EPMO: 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 –Old style engineers understand tangible technology well, processes moderately well, people not at all Can understand technology proposals and will pay to implement it Do not understand people, cannot 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.

31 HMAS Westralia fire Westralia is an RAN fleet oiler Flexible fuel line burst spraying oil on hot engine manifold Four Naval personnel died in fire The entire ship was close to being lost Out of commission for more than a year

32 HMAS Westralia fire – summary of findings Westralia Board of Inquiry 71. The fire in HMAS WESTRALIA on 5 May 1998 was caused by diesel fuel from a burst flexible hose spraying onto a hot engine component and then igniting. The hose was one of a number of new flexible hoses supplied by the ships support contractor, ADI Limited, to replace the original rigid pipes. In the Boards view, the hoses were not properly designed and were unfit for the intended purpose. 72. A change of this type should have been processed through the RAN configuration change process as well as being approved by the ships classification society, Lloyds Register. Both processes were bypassed, largely as a result of ignorance and incompetence. Key personnel within the RAN, and more particularly ADI Limited, were not adequately trained or qualified for the responsibilities placed on them. Regardless of the scrutiny that was avoided by bypassing these approval processes, ADI Limited should have taken steps to ensure that a safe, properly engineered product was supplied for a demanding application; it demonstrably failed to do so. 73. The four personnel who died in the fire did so as a result of acute carbon monoxide toxicity consequent upon inhalation of fire fumes.

33 HMAS Westralia fire – summary of findings The mistakes (Coroners Report)Coroners Report –No notice taken of manufacturers advice on appropriate replacement for leaking metal fuel pipes –Application made in 1996 to replace leaking fuel pipes not acted on –TM200 engineering change procedure used instead of correct TM187 –Lloyds certification requirements not complied with –Contract not adequately monitored –Warrant officer not adequately skilled to manage contract –Supplier not adequately trained –Support contractor failed to recognise that the TM200 request was a configuration change and did not take appropriate action to investigate –Support contractor failed to monitor supplier or ensure compliance with Lloyds certification requirements Discuss

34 Why do engineers need to manage knowledge? Sections from Westgate Bridge at Monash Uni's department of Civil Engineering, Clayton What can go wrong? (most boil down to KM failures) –For example: (Wikipedia is a good place to start) 1984 Bhophal insecticide plant (India) - many thousands killedBhophal insecticide plant 1986 Chernobyl nuclear power plant explosion - hundreds killedChernobyl nuclear power plant explosion 1988 Piper Alpha killedPiper Alpha 1981 Kansas City Hyatt Regency Hotel Walkway Collapse killed (see also)Kansas City Hyatt Regency Hotel Walkway Collapsesee also 2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killedPetrobras P36 Offshore Oil Platform Sinking 2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris)Space Shuttle Columbia –Closer to home 1970 Westgate Bridge - 35 killed, many injuredWestgate Bridge 1998 HMAS Westralia - 4 killedHMAS Westralia 1998 Longford gas plant - 2 killed (see also)Longford gas plantsee also 2005 Sea King Helo Nias Island - 9 killedSea King Helo Nias Island What can go wrong? (most boil down to KM failures) –For example: (Wikipedia is a good place to start) 1984 Bhophal insecticide plant (India) - many thousands killedBhophal insecticide plant 1986 Chernobyl nuclear power plant explosion - hundreds killedChernobyl nuclear power plant explosion 1988 Piper Alpha killedPiper Alpha 1981 Kansas City Hyatt Regency Hotel Walkway Collapse killed (see also)Kansas City Hyatt Regency Hotel Walkway Collapsesee also 2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killedPetrobras P36 Offshore Oil Platform Sinking 2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris)Space Shuttle Columbia –Closer to home 1970 Westgate Bridge - 35 killed, many injuredWestgate Bridge 1998 HMAS Westralia - 4 killedHMAS Westralia 1998 Longford gas plant - 2 killed (see also)Longford gas plantsee also 2005 Sea King Helo Nias Island - 9 killedSea King Helo Nias Island

35 Why do engineers need to manage knowledge? And then there are the economic failures! –Cost overruns –Schedule blowouts –Legal actions –Reputational damages –Again, most could be avoided by better KM Auditor's reports provide good examples –Australian National Audit Office see especially: Management of the M113 APC Upgrade Project Amphibious Transport Ship Project Management of Major Equipment Acquisition Projects New Submarine Project Jindalee Operational Radar Network


Download ppt "421-672 Management of Technological Enterprises Managing Knowledge in Technological Enterprises (Tutorial 1): Knowledge engineering in the engineering."

Similar presentations


Ads by Google