|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, RusadaSubscribe
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.
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.
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.
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
- A need to consolidate your data – I think we have established why.
- A company that understands the benefits of such a warehouse and is willing and capable of working with multiple vendors and data platforms.
- A company that has a track record of delivering such projects.
- A company that is embracing technology that can maximise the availability of data – such as the deployment to intranet, internet and mobile devices.
Physically, you need:-
- 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.
- A reporting deployment solution such as SQL Server Reporting Services (other products are available).
- Should you wish to use automated texting, then access to your providers SMS gateway.
- A report building solution, and that’s it…
- Oh, and, of course, help and guidance – but most of all, self-sufficiency training.
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 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.