Download presentation
Presentation is loading. Please wait.
Published byJack Baney Modified over 10 years ago
1
IS Tech Application Resistance to change
2
Is necessary Competition, consumers, technology demand ▪ Better, more perfect products/services ▪ Lower costs/prices ▪ Faster execution, delivery, recovery
3
Is necessary Competition, consumers, technology demand ▪ Better, more perfect products/services ▪ Lower costs/prices ▪ Faster execution, delivery, recovery But painful People have to change ▪ the way they do their jobs ▪ the things and people whom they trust ▪ The way they are evaluated
6
Safety sensitivity….lives and licenses at stake Immense Complexity Every part on every component on every air craft must be tracked, inspected, scheduled for service Air craft almost constantly in motion (getting the right part to the right place at the right time) Supply chain includes hundreds of vendors and contractors Financial survival requires reliability
7
Illustrated parts catalogue A list of every part and component on the a/c Schedule of how many hours/flights/cycles of various “time controlled” parts Inventory of spare parts …. By serial number, location, bin including parts “out on repair” at a repair vendor Supply chain ordering system with contract terms, order history for “contracted parts”
8
Maintenance Routine inspections, servicing, unscheduled hoc frame repair Repair Removal, servicing, replacement of componenets Overhaul Major/”Heavy” maintenance (taking the plane apart and re-assembling every few years)
9
Approved repair manuals Company generated Vendor manuals Work cards Electronic sign-off
10
New development efforts harder to justify then maintenance of existing systems/programs Cost of failure is extra-ordinarily high Only the operating people know what they really need, Hard to remove from the operation to do planning They usually want to automate the current process…..which usually sub-optimizes They think they “know” and often minimize the importance of training Want to revert to “the way we used to do it” when ever there is a problem
11
Demonstrate status quo is not viable
12
Demand broad involvement in design, test and implementation planning
13
Demonstrate status quo is not viable Demand broad involvement in design, test and implementation planning Do a slice at a time whenever possible
14
Demonstrate status quo is not viable Demand broad involvement in design, test and implementation planning Do a slice at a time whenever possible Have credible experts on tap to help
15
Demonstrate status quo is not viable Demand broad involvement in design, test and implementation planning Do a slice at a time whenever possible Have credible experts on tap to help Celebrate accomplishments and build ownership (“our system” vs “the system”)
16
Who should run development projects; operators or IT people? How do you gain commitment? Bonuses? Joint accountability? Emotional identification/pride? Why a slice at a time? How do you test whether a vendor can delivery? How do you avoid unnecessary “customization”?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.