BI Dashboards for CAAs

BI Dashboard in 6 Steps

How to build a BI Dashboard for CAA

1 | P a g e BI Dashboards for CAAs BI Dashboard In 6 steps

Introduction

The importance of data is widely recognised for all organisations. Not only the information stored in the data, but also, what can be extracted from the data. For example, within a Civil Aviation Authority (CAA), data from the Inspection, Aircraft Registration, the Occurrence Report, Licenses, and Certificates, can be analysed to provide the CAA, important insights about the performance of the Authority. This includes yearly planning preparation, and strategic business creation.

What is a Business Intelligence Dashboard?

A BI dashboard is an information management tool to analyse data and present the data into a report, summaries, graphs, and chart. It provides users with a better understanding of data: E.g. to track KPIs, metrics, and other relevant data to a specific process.

The BI dashboard automatically pulls together available data into charts and graphs and gives a sense of the organization's immediate state and turning data into actionable insight.

However, deploying BI dashboard is a complicated task. It requires a lot of thought and planning. This whitepaper will explain the best practices to successfully deploy the BI dashboard within a CAA.

How to build an insightful Dashboard to achieve client's company vision and mission?

4. Testing and 6. 2. Design • Who is the User? QA • Solicite Feedback Documentation • Design • Iteration • Platform • Wireframing • Functional Testing • User Related Documentations • Deadline • Technical • Non Functional Requirement Testing • Technical Documents • User Bahaviour • Storyboard • Regresision Testing • Project Management 1. Requirement 3. Build 5. Feedback Gathering Dashboard and Iteration

Figure 1 - Development Stages

2 | P a g e BI Dashboards for CAAs

1. Requirement Gathering

This is the most critical step of the process. In this step, it is vital to ask the stakeholders and the users the right questions and collect the requirements. This will become the foundation of the process and influence the success rate of the implementation. There are several things that should be considered at this step:

Define the User Before jumping into the user requirement, it is essential to map who the Dashboard user is. It will help form an idea of how the dashboard is needed based on the goal or the user's vision and mission for the company.

In defining the user, it is also important to determine how to group the Dashboard, whether it will be per department, or team, or selected process. Afterwards, create a timeline to gather the requirement with the users based on the defined group.

What would the users like to see? This is one of the most important parts of this stage. It is necessary to ask the users and stakeholders the right questions to understand what will be displayed in the dashboard. Ask whether there are any KPI or metrics that are currently used. Is some analysis required to support the business strategy? What kind of problems are the users and stakeholders trying to solve through the dashboard?

How the users would like to view the Dashboard? Users will be primarily responsible for operating the dashboard, so it is necessary to build a dashboard that is intuitive and user-friendly. Start by gathering the user's information about what they would like to see on the first page, which requires drill-down, how the data should be filtered and broken down because, in the end, the user is the person who will manage the dashboard. Dashboard Platform

Think about how the user usually accesses the dashboard. Is it via smartphone, tablet, laptop, or desktop? Think about who is the user and what is the user's preference. For example, an Inspector who is primarily working in the field, might rarely have access to a desktop or laptop. Tablets or smartphones will be commonly used instead to display the data.

Another example is the C-Suites executives, who usually have little time at the office, so they may want to see daily KPI reports on their tablet or smartphone.

3 | P a g e BI Dashboards for CAAs

Define the Deadline It is always good to discuss about the timeline of the dashboard. Ask, confirm, and agree with the stakeholder when the stakeholder would like to see the first version of the dashboard.

Understanding User's behaviour on sharing the information The function of the dashboard is not only to provide the users with the insight of the organization but also to make it flexible for the user to share the information in dashboard at their fingertips. For example, the Head of Airworthiness Department would like to share the KPI of the Airworthiness department, he/she can easily export the current report into pdf or jpg file and be able to directly send it per email to the Director.

2. Design

Once the requirements are gathered, it is important to focus on the final draft of how the dashboard will look. Then, divide the dashboard into smaller sections, and develop a plan. By dividing into smaller sections, it will be easier to delegates the tasks to the team and achieve their goals. There are several things to be considered at this step:

Storyboarding: After checking all the requirements, come up with a few critical questions that the users may try to answer from the dashboard and see if those questions can be answered, e.g. which license has the highest application, which organization has the highest finding, how many aircraft registered per organization.

The critical point of the storyboarding is to answer: What questions will be answered? Who is the audience? What is the organization objective and goal? What story is trying to be told?

Wireframing: Now that it is known what information is needed in the dashboard, it is time to start brainstorming and come up with mock-ups of how the end product will look. Based on the requirement, discuss with the team which graph to use, where to put, how it will look, the title, where to place the logo or icon, what colour to use for the dashboard, etc. It may need several brainstorming sessions with the stakeholder and the team until it is agreed, and the proposed solution is confirmed.

4 | P a g e BI Dashboards for CAAs

Figure 2 - Pen and Paper Mockup Draft

It is possible to create a pen and paper mock-up draft – see Figure 2, or power point – see Figure 3, online drawing using Balsamic for the first time to get the idea of the solution and discuss it with the stakeholder and revise it when needed.

Figure 3 - Power Point Mockup Draft 5 | P a g e

BI Dashboards for CAAs

Technical requirement: This step should be to analyse the technical requirements. This includes the KPI formula and calculation, data source, the database relationship and table and the automation process, and selecting the BI dashboard tools that suit for the requirement. Document all detail information for the reference if needed.

Project management: Manage the project by first, defining the task, assign who will do what, and create a time plan based on the defined task.

3. Build Dashboard

Once the confirmation is received, it is now time to build the dashboard in the BI dashboard tools as per the team confirmed wireframe. Everything is now in place to begin creating the dashboard.

The benefit of designing the draft from the wireframe is to avoid unnecessary effort to change the graph, the missing data, or the different data type during this stage.

4. Testing and Quality Assurance

After the dashboard has been created, it is important to perform some mandatory quality check before it is shared with the users and stakeholders. There are several testing phases that need to be performed:

Functional Testing Data Validation

Numbers are the heart of the dashboard. If the data is wrong, then there is a problem. It can cause the organization to take the wrong decision. It is important to validate that the data is extracted correctly, to validate the formula or the calculation, and to validate that the formula and the calculation can perform at different levels. The analyst should make sure that every number shown in the dashboard is correct and matching with the database numbers.

Searching, Sorting, Filtering

Searching, sorting, and filtering are the features that are most common in the dashboard. Hence, it is strongly recommended that these features are working correctly, as they play a major role in the dashboard. Sometimes, the searching function, works as it should but when the filter is added, the search function can break down. It is important to pay attention to this.

Non-Functional Testing Design & Consistency Check:

At the last step, ensure that the dashboard design is matching with the dashboard design shared/approved by the users and stakeholders and whether it follows the organization level standards of font, size, colour code, etc. It should always proofread, before sharing the dashboard with the users and stakeholder.

6 | P a g e BI Dashboards for CAAs

Usability Testing

It is recommended to walkthrough the dashboard step by step and test the user experience in operating the dashboard. Put yourself in the users' point of view to test if the dashboard is easy to understand, read, and use. Sometimes the result looks different than in the wireframe. Sometimes, it is forgotten that the end-user might have difficulty using the dashboard, for example, older generations, who have no experience in using a particular technology might struggle to understand how to operate the dashboard. Also, sometimes, it might be difficult to grasp the insight as to what is expected from the wireframe draft.

Compatibility Testing

The dashboard must compatible with the technology used by the users. Look back to the requirements, and check what technology is preferred by the users and stakeholder. For example, to test what type of browser (Chrome, IE, Firefox, Safari) and which version of the browser, and which device is compatible, such as mobile (IOS, Android), tablet, laptop, and desktop.

Performance testing

Performance plays a significant role in the user experience. For example, C-Suite executives, who spend little time in the office, will not be satisfied if it takes too much time to load the dashboard. The executives do not want to waste their time waiting for the dashboard to be loaded. This can lead to the end users to operate the dashboard much less than they should or even worse, not at all. As suggested, the initial load time of a dashboard should not exceed 5-10 seconds.

Regression Testing

This is also another major challenge for dashboard implementation. Regressing the dashboard after every fix and update is mandatory, as that fix, and update may bring many other issues. For every software update, sometimes the data field name might be changed, resulting in the relationship between the data being changed, etc.

7 | P a g e BI Dashboards for CAAs As showing in the image, sometimes what the analysts see is different from what the users see. Likewise, what the users understand, sometimes differs from the analysts understanding

5. Feedback and Iteration

Solicit Feedback Once the dashboard is finished with the testing, it is the time to check the users and stakeholder feedback. Do they approve the dashboard, or do they want to change some chart or graph? It is important to gather feedback from the users and shareholder.

Iteration This step might be short or long depends upon the quality and thoroughness with which steps 1 through 4 have been completed. The iteration step will be short and sweet, if the feedback complaints and suggestions from the users and stakeholders are few. Otherwise, multiple iterations of soliciting feedback and implementing the result changes or fixes may be required.

8 | P a g e BI Dashboards for CAAs 6. Documentation

The last step of the dashboard development is to create supporting documentation for the dashboard. It is essential to develop the two types of documentations shown below:

User Related Documentations

• These documents include user manual providing instruction on how to use the dashboard, factsheet about the dashboard - purpose of the dashboard, location of the documents and contact person if they have any questions or need further information. • FAQs: Should cover information on terminologies used, how frequently the data is updated etc. • Data source detail information.

Technical Documentation It is necessary to detail information of the future reference development process starting from the 1st stage until the last step.

This paper highlights how dashboards should be created within CAAs and how the data stored, can be used to improve the decision-making process of the Authority. To summarize, it is important not to build a dashboard that does not solve the problem as required, because it will not be used. It is recommended to spend more time to understand why the users want to build the dashboard and explore multiple ideas before selecting a solution to build. On the design, confirmation should be received from the stakeholders and users for the final wireframe and technical requirements. Seabury Solutions IT specialists have adopted these steps, which has supported their ongoing success, creating dashboards not just for CAAs, but also, a large number airlines and MROs.

About the Author:

Sarasati Palawita is a Business and Data Analyst at Seabury Solutions. Before joining Seabury Solutions, Sara received a scholarship from the 'Make It in Germany' program in 2014, by the German Federal Ministry for Economic Affairs and Energy to work in Germany. While working, Sara continued to study in major Business Intelligence and Process Management in Berlin Economic and Business School to develop her skills in data analytics. As a Business Analyst in Seabury Solutions, Ms Palawita is responsible for analyzing and designing the client Safety Oversight System, eAuthority. Sara spends time to understand 9 | P a g e BI Dashboards for CAAs what the client wants and enjoys working hand in hand with the developers and users to produce requirements and specification that reflect business needs. Sara’s understanding of the business operations and analytical skill enables her to transform the client data into meaningful information, that supports the client to achieve their company goals. During Sara’s time as Business Analyst in Seabury Solutions, she has lead manty implementation projects, where she brings understanding, communication, and organization to her role as a project manager to ensure Seabury Solutions meets its deadlines with excellent results.

About Seabury Solutions

Seabury Solutions was established in 2002 and forms part of Seabury Capital. Since then, the company has been delivering leading IT solutions to enhance the operational and financial performance of multiple industries. Utilizing decades’ of technological expertise in-house, this knowledge has been leveraged into a suite of products that enhance the decision making process for MROs/M&E, Regulatory Compliance, Safety Oversight & Performance Analysis.With a truly global reach, the network of offices is located in Argentina, Australia, Berlin, Canada, Ireland, Korea, Kenya, the Netherlands, Philippines, & USA. This wide geographical spread allows the Seabury Solutions team to provide support 24/7 to all their customers in real-time.

10 | P a g e