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”?