Post on 31-Mar-2015
transcript
IS Tech Application
Resistance to change
Is necessary Competition, consumers, technology
demand▪ Better, more perfect products/services▪ Lower costs/prices▪ Faster execution, delivery, recovery
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
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
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”
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)
Approved repair manuals Company generated Vendor manuals
Work cardsElectronic sign-off
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
Demonstrate status quo is not viable
Demonstrate status quo is not viableDemand broad involvement in
design, test and implementation planning
Demonstrate status quo is not viableDemand broad involvement in
design, test and implementation planning
Do a slice at a time whenever possible
Demonstrate status quo is not viableDemand broad involvement in
design, test and implementation planning
Do a slice at a time whenever possible
Have credible experts on tap to help
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”)
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”?