A couple of weeks back I wrote a blog post entitled:
“Why isn’t MRO Software Simpler?”
This generated quite a bit of debate here on our blog, but also on a couple of LinkedIn discussion boards including the Aircraft Lifecycle Wikinomics group where it was a featured discussion.  There were loads of really insightful comments and thankfully my opinions didn’t get flamed.  This morning I addressed the 30+ comments on LinkedIn by attempting to distil all of the suggested reasons to the root problem.  Here is that response copied and tidied up in one or two places.

I think that the reasons that MRO Software is not currently simpler can be distilled into 6 key factors.

1. The MRO process is very complex or at least is perceived to be so.
I don't argue that MRO processes are not highly sophisticated, but this should be an argument to strive to make the software simpler not MORE complicated. Other industry sectors have proven that it is possible to make the solution to a problem as simple as possible. I like using the example of the Windows Vista shut down button vs. the iPod off button. Windows Vista had 7 different options to shut down the PC, the iPod doesn't have any way to turn itself off... it does it by itself when it’s not being used.

Windows Vista. 7 options to shut down.


The 5th generation iPod Nano. 0 options to shut down

This of course is an abstract example, but it goes to show how overly complicated things can be made and how ultra-simple they could be if applying a bit of thought and common sense when designing a solution.

2. The software vendors are to blame.
Again there are some excellent points being made here. Without question these vendors need to have industry experts to correctly interpret business requirements and convert those into functional specifications. It is taken for granted that a software vendor employs adequate technical experts. In my opinion there is something missing between these two mandatory nodes of the software business. Where are the UI designers, the micro copywriting experts, and the event tracking gurus?? How much time is spent in the R&D of software in really understanding how users consume software? What makes them happy? What makes them use it more? What makes them use it more efficiently?? How much time is spent by MRO software designers in figuring out exactly what shade of green a button should be to make a user more inclined to press it? How many MRO software providers change the size of an object by one pixel to see the effect it has on tracked events? Other sectors of the IT industry do this. Why not MRO software? If a software vendor can tell me that hand on heart they do this I will cheerfully apologise and will eat my hat (and will provide photos to prove it.)

3. The MRO companies are to blame.
There have been some good points here. The MRO software vendors will only provide what the customer asks for. The customer doesn't actually know what they want. They know the process is complex, they know the engineer wants something simple, they know the accountant wants something sophisticated, they feel if they are spending hundreds and thousands on something it needs to have lots of bells and whistles and flashing lights.... all fair enough. Who is going to educate the MRO that they should be doing something else? Actually with no alternative on the market this proves impossible to even the wisest IT guru. So in my opinion the onus is on the vendor to make the leap of faith here.

4. The Regulations won't allow changes.
This is utter nonsense and I whole heartedly disregard this statement. Remember it is the MRO business process that is approved not the IT tool. As someone rightly stated the regulations have remained largely unchanged for years whilst technology has moved on at pace. At what point did the regulator decide that perhaps there isn't quite enough information being stored about this particular defect. I'm not satisfied that you are recording the ATA chapter to 8 digits. You need to also record the Reliability Chapter, the repetitive chapter, the next higher assembly chapter and so on. This bloating of software is not down to the regulators demanding it, it is surely down to the processes surrounding the software. In the early years on IT in business (what I call Enterprise 1.0) computers were used to do the mandatory compliance stuff that needed a bit of number crunching like payroll, invoicing, stock holding. As the years have gone by we have simply added more stuff to the compliance category, so we have forecasting, scheduling, etc. etc. all thrown into the same pot. Enterprise 2.0 should not be about doing more stuff because we have to. It should be about doing things better and easier. A client of mine has challenged the idea that a CAMO needs to operate from a single base in some kind of shared office. He has been the first EASA Part M approved organisation in the UK (perhaps the world) to utilise a virtual office of airworthiness where all his staff work from home. Many people said the UK CAA wouldn't buy it... but they did. Admittedly they did a bit of head scratching, but it goes to show that if you can provide a compelling case and a bullet proof exposition to the authorities then they will go with it....

5. The sales process is to blame.
I guess elements of item 2 and 3 are involved here. The sales guys I have met have certainly been keen to extoll the virtues of a really complicated system and whilst buyers are lapping that up then nothing will change in the near future.

6. It’s too hard to change the software and make it simpler.
Yep, this is dead right. Millions of man hours go into making wall-to-wall enterprise level software. Like the proverbial super tanker a product cannot suddenly perform a hand brake turn and change direction. By the time the next generation software has gone through the planning and production phases it could already be out-dated by several years. Perhaps the future doesn't lie in massive enterprise level software - perhaps it lays in true SOA, focussed, interconnected, niche software? But that is heading towards a sales pitch.

Related Posts:
Why isn’t MRO Software Simpler?
This is what we believe: Web Apps