Aircraft IT MRO – May/June 2014

Subscribe
Aircraft IT MRO – May/June 2014 Cover

Articles

Name Author
Column – How I see IT Michael Wm. Denis View article
Also a business process – Air Works Case Study Ravinder Pal Singh (Ravi), CTO and CIO, Air Works View article
Lost in Translation? – Data Warehousing Tim Alden, Commercial Director, Rusada View article
Case Study: Facing up to the IT challenge of offshore helicopter operations Brian P. McDonald, Principal & Managing Director, SFS Aviation Thailand View article
Mobility Deep Dive – Future Mobility Platforms Paul Saunders, Global Product Manager, Flatirons Solutions View article

Lost in Translation? – Data Warehousing

Author: Tim Alden, Commercial Director, Rusada

Subscribe

Lost in Translation? – Data Warehousing

Tim Alden, Commercial Director for Rusada explains the application of data warehousing and the practical translation of business data for greater cross platform efficiency.

Data: when you want it where you need it

You’re in aviation; ask yourself, why do we have warehouses? It’s a simple question and to be honest, it’s a simple answer. Warehouses act as a repository or store of ‘stuff’ on hand for when it is needed. For centuries, central warehouses of goods have served to minimise the peaks and troughs of supply and demand by matching the needs of both supplier and user. It’s a well proven concept in use throughout the world. Unless you are a manufacturer or you have very specific needs for very specific widgets you don’t stand at the end of the production line for your widget and then rush off to fit it – it’s just not an efficient way of doing business.

You’re in aviation; your IT systems are large and complex. Just like a manufacturing plant they create masses of data stored in lots of tables ready for someone to associate ‘a’ with ‘b’ and decide ‘c’. Just like a manufacturing machine, these systems are configured to receive and use data in a way fashioned by the designers to serve up functions requested by the customers. In order to do this in an efficient manner these manufacturing processes are pre-configured with manufacturing rules. However, users are creative and want to combine ‘a’ with ‘e’, compare it with ‘f’ and monitor the result as ‘g’. Using the manufacturing system will then be slower because it was never initially designed to do this. So, why can’t you use a copy of the data and manipulate it the way you want to. Indeed, why isn’t there a ‘warehouse’ of data created just for that purpose? While we are at it, why can’t this warehouse be a simplified representation of the data?

You’re in aviation and you need data warehousing.

Big data creates big management challenges

Consider modern systems, as alluded to above, they are complex beasts borne out of the minds of developers in response to functions demanded by an industry with equally complex rules and regulations. Some systems focus entirely on one area of operations, be that flight operations or stock management. Other systems have wider scopes and cater for the entire needs of an MRO or CAMO and yet others are capable of catering for all needs. Typically companies have one, two or more of these systems that have been acquired at different times in the IT buying history of the company and perhaps its previous partners. So now the analogy becomes not of a single manufacturer’s warehouse but more of a distribution system of a major supermarket chain. The ideal is to have one location being ‘fed’ with the products of the individual producers for consumption by the customers of the organisation.

So, you have probably seen the phrase ‘big data’ numerous times in the trade press with lots of discussion about the ideals but, let’s face it, it is boring stuff to read at times. Suffice to say that the supermarket distribution warehouse is a useful comparison.

Source everywhere, read anywhere

But, here’s the next problem; storing all this data is nice but let’s go back to our supermarket analogy again and consider the suppliers. The last time you walked down the aisles there were goods from all over the world. Each of those suppliers has a different native language – but in order to communicate effectively with their consumers they need a common language. As such, each supplier needs to translate their product details into a language recognised by the consumers. The consumers can then choose what to fill their baskets with because they understand what the products are. This process is the other role of the data warehouse. Each business application will have its own ‘language’ this language is a combination of different operating systems and different system designs. What is called ‘partnumber’ in one system could equally be called ‘mpn’ in another. It is a task of the translation service within the warehouse to create a common definition of the same information. This definition can then be used by analytical business reports rather than the original source data. Moreover, adopting this methodology solves one of the biggest problems of all – version compatibility. The various data system suppliers are free to continue independent development without fear of degrading the viability of the reporting service.
Useful reports

Now, of course, we need to consider the output, why go to all this bother in the first place? Surely the IT systems already have business reports? Well yes, let’s assume they do but then consider that you have parallel systems. It is highly unlikely that they have been designed in the same manner with exactly the same structure and yet, as a business, both systems hold useful data that is even more useful if compared dynamically. Consider the usage of parts compared to the cost of returned parts for particular vendors. It is more than likely that the account information is in one system and the usage information is in another. Put that data together somewhere where it can be translated and compared in a report and now we become more efficient.

Is yours a typical office? If yes then you live with reports, but here’s the other thing about data warehousing. Much like goods, data is relevant to the time it was extracted, moreover there’s nothing more useless than an old report right? Furthermore, do you find yourself spending all the time producing the reports but virtually no time physically using them to drive change?

Ask yourself, what is a report actually for? after all, most of them are static data. If it’s for a statement of fact at a specific moment in time such as a stock report or an airworthiness report then these make sense to have as printed documents. Some of these reports can be highly complex gathering data from all corners of an application. Calling on these reports creates a load on the system and often the net result is a reduction in speed. Frequently run reports should be optimised for best performance but a more efficient way is to store the business data in the warehouse and run the reports from there. An even more efficient process is to think about why we have the report in the first place. If a report is being run often, it’s usually because the person is trying to review changing results – it makes sense right? So, why not use the warehouse and its time-relevant data to recognise the change itself and then only highlight conditions that change?

Sounds like trend analysis doesn’t it? We’ve been doing it for years on engines – why can’t the same principles hold true for the business. Why have a static report where 95% of the data says you are doing great but the 5% that’s bad is hidden in amongst the lines? Fixing the 5% is much more important than sitting back on the 95% success. How often do you hear in the news that ‘Fancy-Clothes PLC’ announced a 5% drop in profits this year’ and it’s treated as bad news? The company didn’t lose money, but it didn’t maximise its potential by focusing on what was changing.

Ways of seeing information

Now if you are still thinking about printed reports then stop. Why? If you are reading this in a magazine you are more than likely not more than one metre from a device capable of displaying data. If you are reading this online then you are even closer and already using a browser. With modern databases and deployment services, data can be pushed in almost any direction. We are used to booking flights and then receiving a reminder text that the flight is due – or worse, delayed. There’s no real magic in that – just some company that has created a function to alert you when the condition of a piece of data has changed from one state to another. By using these industry standard functions and coupling them with the power of this warehouse of data we can now become more efficient, concentrate on the matters that need our attention as and when those matters arise in next to real time. You now have the ability to take information from multiple sources, compare and analyse this information and then push the results out in almost any format you choose – to a mobile solution (app), to a web page, as a dashboard, a text, the options are only limited by your imagination.
Let’s get practical; what do you need for a data warehouse?
  1. A need to consolidate your data – I think we have established why.
  2. A company that understands the benefits of such a warehouse and is willing and capable of working with multiple vendors and data platforms.
  3. A company that has a track record of delivering such projects.
  4. A company that is embracing technology that can maximise the availability of data – such as the deployment to intranet, internet and mobile devices.
  5. Physically, you need:-
    1. A server to locate your new database on and the ability to transfer data if this new server is physically separate from your business systems.
    2. A reporting deployment solution such as SQL Server Reporting Services (other products are available).
    3. Should you wish to use automated texting, then access to your providers SMS gateway.
    4. A report building solution, and that’s it…
    5. Oh, and, of course, help and guidance – but most of all, self-sufficiency training.

Conclusion

I have been at pains to exclude technical jargon and explanations of servers, reporting servers, OLAP cubes (make lousy gravy) etc. but if anyone wants a more in-depth explanation I can arrange for them to speak with ‘the clever people’ that we keep under the stairs.

Contributor’s Details

Tim Alden, Commercial Director, Rusada

After leaving the RAF, Tim joined a leading airline, trained to work on the Boeing 747 and became more involved with technical authorship and planning, and putting practical engineering knowledge into the execution of technical work. He then became Planning Services manager for a cargo airline and MRO facility, expanding his airframe experience to all Boeing types and regional Airbus aircraft. Moving to consult on end of lease hand-backs, VIP aircraft management and business transformations with a specialisation in realising the potential of IT systems, led him to Rusada where he has managed projects, regional operations, bid campaigns and the pre-sale and marketing roles.

Rusada

Rusada is an aviation software provider, consultancy to the aviation industry and system integrator. It’s a global company headquartered in Switzerland, with operations in the Middle East, Asia, Europe and the Americas. Currently serving 50 major customers worldwide, Rusada software manages over 1500 aircraft in 20 countries. The flagship product Envision is CAMO compliant, providing key management information and operational process control for operators, original equipment manufacturers (OEMs), maintenance and repair organisations (MRO’s) and service organisations on every continent.

Comments (0)

There are currently no comments about this article.

To post a comment, please login or subscribe.