CASE STUDY: A rapid digital evolution at Discover Airlines

Author: Alexandra Kosjuberda, Manager Crew Training, Discover Airlines | Sarah Kurowsky, Manager Flight Ops Engineering Support, Discover Airlines | Arne-Martin Gruene, Project Manager, Lufthansa Industry Solutions

Subscribe

Alexandra Kosjuberda, Manager Crew Training, Sarah Kurowsky, Manager Flight Ops Engineering Support and Arne-Martin Gruene, Project Manager, Lufthansa Industry Solutions recount Discover’s three-month journey to a new Flight Ops documentation platform

Not every evolution is rapid, so this case study is a bit different. We’ll take you through Discover Airlines’ digital evolution, how it was managed in just three months and the outcomes. But before that, we want to share something about Discover Airlines, which you can see in the short video below.

Before we dive into the case study proper, we’ll look at the story behind Discover Airlines and how it came to life as shown in figure 1.

Figure 1

Since our first flight in 2021 we have carried over 8 million guests from our hubs in Frankfurt and Munich; our team has grown to more than 2000 people, and we’re still growing every day. We currently serve over 60 destinations such as Zanzibar, Mauritius, Florida, Greece – our most popular destination – or to see the spectacular Northern Lights in Norway and Finland. The fleet is growing, and we are scheduled to be operating 16 Airbus A330 and 17 Airbus A320 by mid-2027.

We invite our clients to “let’s discover the world together”, and we invite readers to discover our journey with Volabase to implement, in just three months, a new flight documentation platform, starting in September 2024. This case study will guide you through our project, the challenges and its journey to a successful implementation.

BEFORE THE CHANGE

With any case study about change, the first question is usually why make that change? In our case, our old solution no longer met the growing requirements of our airline regarding maintainability, stability and scalability, as well as overall performance. We wanted to make changes in these areas and improvements. In particular, we did not have the option to revise OEM documentation which, for us, was mainly Airbus documentation in original OEM XML format. There was a need for an option to change as not having that option prolonged revision cycles while exposing the airline to increasing safety and compliance risks. It did not leave us with the level of flexibility that we would have preferred. Making a change was not without risk because the transition would need to happen during ongoing operations and heavily depended on manual revision cycles that needed to be coordinated quite closely. Since the contract with the old provider was coming to an end near the end of 2024, we needed to ensure that everything was ready by December 2024 to always ensure an active DMS that we could use in flight operations, which limited the time available and did not leave us with the option to recruit more personnel and Human Capital that could support us on the journey. Nevertheless, we decided to go for the change but wanted to make sure that we were opting for a solution that best suited our needs.

FINDING A NEW SOLUTION

For such an important decision, we wanted to objectively compare the solutions that were out there on the market. So, we drafted a list with about 209 requirements comparing different areas, such as the user management, the data format that was available for visioning, whether we have the option for a change request workflow that would manage our change requests, the search function, as well as the overall performance, the look and feel of the user interface. We also wanted effectivity management, which is extremely important for Airbus documentation, as well as options for customizability, which is important for our crews with features such as favorites, bookmarks and the likes. Finally, we had a few compliance requirements that needed to be fulfilled to match IOSA controlled documentation standards such as visibility, revision dates and the likes. After completing this comparison, we concluded that Volabase from Lufthansa Industry Solutions was the perfect match for us as it offered several technical as well as procedural advantages that we could make use of, which we’ll expand on below.

VOLABASE, THE SOLUTION CHOSEN

As we‘ve said, Volabase provides several advantages which we’ve illustrated in figure 2.

Figure 2

The first advantage is the high rate of automation. Volabase offers automation for importing OEM documentation. So, if a technical editor is working on a customized manual and receives new OEM documentation, s/he can be very flexible in choosing whether they want to implement the content automatically or even manually. This allows for efficient and tailored handling of the manufacturer’s content to ensure a streamlined and accurate manual creation process. With its advanced capabilities, Volabase also automatically generates a table of content or also a list of effective pages, effectively organizing and streamlining the manual’s structure. What’s more, Volabase also provides comprehensive markups for revision comparison, allowing editors to collaborate more efficiently and ensure the accuracy and consistency of the content.

Furthermore, Volabase operates on an XML based data platform, providing diverse options for exporting into various output formats. It offers traditional PDF output on the one hand and, on the other hand, up to outputs suitable for importing into the Airbus FlySmart suite. The XML-based infrastructure offers a multitude of outputs for efficiently managing the whole technical content. Also, within the Volabase product suite, there’s a high level of collaboration among airlines using the solution. There are the annual Volabase user conference where editors from all airlines gather to exchange experiences and discuss best practices. It enables them to stay informed about new developments, including demonstrations of new features and updates in the Volabase suite. The user conference also provides an excellent opportunity for attendees to gain insights into the future direction of the product and the platform. Another form of collaboration within the Volabase suite is the community among the airlines, and that was established by the airlines. These communities, for example, hold weekly meetings to facilitate an exchange of ideas and experiences. These interactions serve as a valuable platform for users to share knowledge and experiences or address challenges that might come up. Finally, Volabase also supports the native Airbus XML format that editors can use.

Support of multiple outputs

The challenge of airlines today is that, with multiple fleets, when customizing Airbus data, you still want to use this customized data in the Airbus FlySmart suite and Volabase can be integrated into the documentation chain without loss of any functionality as shown in figure 3.

Figure 3

Especially for operators of multiple Airbus aircraft, reliance on the Airbus apps within FlySmart is crucial, and Volabase integrates into this ecosystem, offering seamless integration to the Airbus data chain through support for the native Airbus XML format. This allows customization of the output, facilitating its use and applications such as the eQRH (electronic Quick Reference Handbook). Discover Airlines considered that integration to be pivotal to our decision. Moreover, some of the apps are essential for cockpit operations, making it imperative to consolidate all data within a single system to maximize its utility.

Volabase is also a collaboration enabler as seen in figure 4.

Figure 4

When all group airlines are working on the same platform, then new airlines can onboard quite easily and benefit from all existing documentation, like Discover Airlines does today. One example of this is the ground operations manual, which can be edited and customized within a shared database. And Discover Airlines can address variations from other airlines and tailor content or specific pages to meet our own requirements. Another use case is that providers at the ground operations stations can rely on and leverage the same content, thereby creating synergies so that text content can be published to the target audience through filters as needed.

There were quite a few advantages that we could benefit from, working with the Volabase suite. However, as readers will know, no project is without challenges and major changes. One thing that we really needed to get used to was that, whereas our old solution was using a compliance workflow that ensured that all changes could be tracked within the system, we no longer had that option at the time that we were making that switch. As we were already putting quite a huge amount of change on the whole organization, we wanted to mirror the workflow that we used to use with the old solution, just to make sure that no content changes were missing and that the whole change in general was not too overbearing. Figure 5 illustrates the general workflow that we set up.

Figure 5

We created our own power app where each editor had the responsibility to track all changes they made in the documentation. It started  at a basic level; the editor would enter any change they made into the system, just stating the manual and chapter, as well as just a few reasons why the change was made and whether the topic was a prior approval issue that needs to be discussed with the competent authority or a manual owner. Our compliance department would then receive the change information and could decide whether they wanted to acknowledge the change and send it over to the safety department for further proofreading, or whether they wanted to reject it send it back to the editor and ask for more improvement. When all changes have been checked by compliance and safety, the draft could then be used by the editor and moved over to either the manual owner or the works council, the competent authority or whoever needs to oversee the document before final publication.

This was probably one of the biggest changes that we needed to get used to, one of the challenges we faced, but obviously there are quite a few other tasks that need to be finished before project completion. So, we set up an ambitious timeline of different milestones that we wanted to hit – see figure 6.

Figure 6

First was the general tenant setup that we wanted to finish by September 15. We were even faster than that, having completed the setup by September 3. That left us time to finalize the migration routine that would then transfer the documentation from the old solution to the Volabase environment and allowed us to create our first documentation revisions within the Volabase ecosystem. We were planning that for mid- to late October. Again, we were faster than that by about two weeks, which left us with enough time to complete everything that we needed to do before the final system cut over on December 15.

The project didn’t quite last three months, but rather two and a half months, and, with figure 7, we wanted to show readers what that meant.

Figure 7

Almost all operational departments were involved in the project, and most of the work was concentrated within the last four to six weeks of the project. This may seem a little bit counterintuitive at first, as we usually wanted to make sure that everything was ready as soon as possible, but we were severely limited due to one major reason: we needed the approval of the competent authority before we could effectively publish documentation and use it in active flight operations. This approval usually takes about eight weeks. Given the project timeline, we were aware that we did not have the option to get approval for both a parallel operation of the old and new system, as well as the complete switch over.

That gave us two problems. We had to decide if we wanted to migrate the existing documentation to Volabase and then, if we needed to revise anything, essentially force the editors to mirror every change that they made on the old system and communicate to crews in Volabase as well. This left room for compliance errors, in case an editor forgot to mirror the changes, or if we wanted to work with manual freeze periods, meaning that once the document was migrated, there was no longer an option to revise the manual until the final cut over on December 15. This had its disadvantages, but we still opted for the second option.

We wanted to make sure that we reduced the workload on the editor so that they didn’t need to do everything in two systems, as there were quite a few projects going on within the organization already. But that also meant that each editor needed to make sure that they knew the exact date that they needed to revise the document last because after the document was migrated, no revision was possible. This meant that most documents were not ready for migration until mid-October to early November, to still have enough time for quality assurance for creating new revisions, which is the main reason why we had to cram in everything in the last four to six weeks.

Another reason was the fact that we obviously needed to set up the migration routine first, which you can see in figure 8.

Figure 8

We were faced with the main challenge of migrating 50 manuals from Discover Airlines. The driver for the rapid migration was the XML structure within our product suite. Initially, the manuals had to be exported from the legacy system of the previous provider. As the previous XML structure of the manuals did not align with the XML structure of the Volabase platform, a migration routine had to be developed. This routine enabled mapping the XML structure of the previous provider to the Volabase XML structure, so facilitating the import of Discover manuals into Volabase to commence. The team at Volabase swiftly devised a strategy to seamlessly integrate the manuals from Discover Airlines, ensuring a smooth transition and continuity of operations. The successful migration marked a significant accomplishment, demonstrating Volabase’s commitment to addressing complex migration tasks with agility and precision, ultimately facilitating the seamless adoption of the platform at Discover Airlines.

To ensure a successful document migration, we developed a process starting with the migration routine to transfer the data structure from the previous provider’s format for the Discover Airlines manuals to the Volabase format. The manuals were then automatically migrated using the developed established routine, which also automatically set up the linkages within the manuals. Next, the manuals had to undergo a quality control check for which we created checklists which you’ll see further along. Following a successful quality control check, the manuals were then handed over to Discover Airlines, including also the initial revision, meaning that technical editors could seamlessly continue their work for editing the manuals. This process exemplifies Volabase’s dedication to providing seamless solutions for the migration and integration of complex data structures and ensuring a smooth transition for Discover Airlines as they continue their technical editing work.

We compiled a quality assurance checklist, which can be seen in figure 9, to make sure we didn’t miss anything during our implementation.

Figure 9

The quality assurance covered two areas. One was Lufthansa Industry Solutions, and the other one was in our own departments, such as crew training. Both were checked separately, because there is an important point here, that in our AVC, we have our own ATO, and branding was really important because, before we launched the documentation in our AOC, we needed another branding, and we need another logo in our ATO. Because of that, we had to update our logo to stay compliant, to stay with our requirements, and whenever there were any discrepancies, or we had any issues, we gave feedback directly to our Project Manager, Arne, and he found solutions that we could change before we worked with our documentation.

WHAT HAPPENED NEXT

Figure 10 shows what happened once everything was in place.

Figure 10

After we made our quality assurance checklist, we had our first documentation using the new system on December 15 and had a successful go live. Importantly, we had a high level of user satisfaction regarding the new system.

LESSONS LEARNED

As with every project, there were a few lessons learned. We have shown that it is possible to have an in-depth migration of a huge amount of documentation within a really short period of time, under real-time conditions and during ongoing operations. Of course, we would have preferred to have a little bit more time just to make everything more relaxed and leave room for errors or unexpected things coming up. But due to a high level of planning, teamwork and strong commitment from all parties involved, we were able to successfully make that transition. We were incredibly lucky to have such a good supplier to guide us throughout the whole process because, had we not worked with someone like Lufthansa Industry Solutions, we would not have been able to stick to the timeline and ensure such a smooth transition in general

We are now able to profit from several favorable side benefits shown in figure 11.

Figure 11

Favorable side-benefits include enhanced link handling, everything is done automatically so we don’t have any broken links, wrong references or errors in the documentation. Also, the fact that we are now able to revise the manuals in OEM XML format makes sure that we have a huge amount of time savings and can now perform every step of the way by ourselves. Furthermore, descriptions of changes are conveniently embedded in the documentation and stay on top of everything to keep track of all changes happening in the documentation. We can also make use of strong barrier management through generic activities, which is important for other documentation and allows us to filter documentation as needed. To summarize, we are very happy with the switch and how everything turned out.

FEEDBACK FROM USERS

It was very important for us to get feedback from our users and from colleagues who work every day with the systems. So, we gathered some feedback, which you can see in figure 12.

Figure 12

Working every day with this new system generated positive feedback which we’re really pleased to report. We hope that our experience will be useful for readers who are facing a similar situation.