CASE STUDY: EDELWEISS

Digitizing of EFB, Flight Operations and Compliance Bruno Speck, Head of Ops Support at Edelweiss Air, chronicles the airline’s transformation from Static Documentation to Dynamic Content Management

AIRCRAFT IT Operations • MARCH-APRIL 2021 • 46 CASE STUDY: EDELWEISS

n this article, we’re going to look at the digitization of EFB and flight operations THE CURRENT EFB SETUP manuals plus regulatory compliance. But before we get into those topics, let Looking at our present EFB setup, we use iPads as electronic flight bags with the Ime introduce Edelweiss Air. following operational applications (figure 2). EDELWEISS AIR EFB Setup Edelweiss (a member of the Group) operates 16 Airbus aircraft and

serves over 70 destinations worldwide. We have about 300 pilots with 750 Cabin EDW uses iPad as EFB with the following operational applictions: Crew, plus roughly 150 employees in the back office and administration. Looking at where we fly to (figure 1), the operation covers quite a large area. There are • Airbus FS+ (Performance und ACFT Manuals) also a significant number of destinations throughout Europe, albeit not shown in the figure below. • Sabre eFM (Flightplanning) • LIDO mPilot (Kartenmaterial + Manual Access) • Honeywell WIS (Flugwetter) • IQSMS Reporting (Reports) • GoodReader (Manual Access) Figure 2 We have all of the OEM software from Airbus and FS+ for performance and aircraft manuals. In the flight planning domain, we use Sabre eFM for charting material and both Lido/mPilot and Honeywell WIS for weather information. Meanwhile, reporting is managed via the IQSMS reporting system. However, most noteworthy for the topic at hand is that we use GoodReader to display manuals. These are also synchronized with the document module of mPilot, as we’ll discuss in more detail below. In figure 3 you can see an example of how we currently present documents to our pilots, namely via the Present setup Edelweiss Intranet that is based on a SharePoint site collection. Static library of PDF documents: As can be seen in figure 3, documents are presented to pilots via a static library of PDF Figure 1 documents. While SharePoint may be a good collaboration tool, it certainly isn’t for publishing “…we have to manually implement our naming documents that need to be managed rather rigidly. For convention, which frequently leads to mistakes, mainly example: SharePoint doesn’t due to documents being published by editors and devise a naming convention nor does it check whether a given file publishers that don’t necessarily adhere to the agreed name adheres to a pre-defined Figure 3 upon naming convention” set of rules. Thus, we have to manually implement our naming convention, which frequently leads to mistakes, mainly due to documents

AIRCRAFT IT Operations • MARCH-APRIL 2021 • 47 CASE STUDY: EDELWEISS

“…we certainly want to achieve reliable document synchronization to one single App in the future. Yet another priority is to limit the number of sources for revision inputs and to manage approval processes by means of document specific workflows.”

The second method syncs files from the Intranet to GoodReader. Unfortunately, we’ve also encountered some issues with that approach, since admins could alter being published by editors and publishers that don’t necessarily adhere to the documents on GoodReader and would then push them back into our SharePoint agreed upon naming convention. In fact, we had to address this issue by providing Library, thereby accidently changing files without adhering to our document additional training and reducing the overall number of administrators in order to revision processes. stabilize our setup and to ensure that crews are able to locate the necessary Speaking of revision and approval processes: These were available to us by information in a timely manner. means of paper-based Process Manuals, without a dedicated workflow tool at our When it comes to uploading files to our electronic flight bag (EFB), there are disposal. To that end, change requests were usually sent to us either by email, by two ways in which Edelweiss has done this in the past (figure 4). physically passing on a piece of paper, via the reporting system, and sometimes even orally over the counter. It goes without saying that this is not really a workflow Present setup that we can stick to and by no means a reliable alternative to a workflow-based IT Upload to EFB system. WHY CHANGE THE SYSTEM? We really want to get rid of the fixed file names for the sake of organizing files more reliably and to avoid editors publishing documentation that doesn’t adhere to our naming convention. At times, admins may have even put in a wrong file name altogether or uploaded a document in the wrong format (e.g. Word instead of a PDF). In short, there was room for improvement. We’d also prefer to INTRANET avoid the extensive publisher training from the past and would instead rather prefer a system that carefully controls what and how content is published. As alluded to before, the process of syncing documentation to mPilot is not reliable and, on the GoodReader App, there is the potential issue of altering files by accident and pushing these changes back to the document library. Another issue that we face with GoodReader is that it doesn’t provide a full text search functionality, which surely would be advantageous to have. All things being Figure 4 considered, we certainly want to achieve reliable document synchronization to One way is for the documentation to be automatically synchronized with Lido/ one single App in the future. Yet another priority is to limit the number of sources mPilot via an API (Application Programming Interface). However, results are for revision inputs and to manage approval processes by means of document rather unreliable since, at times, SharePoint fails to execute the upload correctly. specific workflows.

AIRCRAFT IT Operations • MARCH-APRIL 2021 • 48 CASE STUDY: EDELWEISS

REQUIREMENTS we still want the possibility to publish to different file types (e.g. PDF), we want Given all of the above, what are the requirements established for a new system documents to be based on an XML based structure via an editor that allows at Edelweiss Air? We need the new system to include the following features users to specify documentary units (DUs) that can be easily controlled. (figure 5). Furthermore, the visible content of a given document should be limited to Requirements display only information that is actually relevant to someone’s particular role and that can be dynamically filtered even further based on document specific The system fulfils the following features: metatags. Document specific workflows must ensure that we can reflect our • One publishing system for all documents internal revision and approval procedures without compromise. Moreover, such • XML based structure with the possibility to publish different kind of files (e.g.pdf) workflows must allow for inclusion of the Civil Aviation Authorities (CAA) on a documentary unit level, thereby enabling the collaboration with our CAA and • Custom role based content view allowing it to review changes in a transparent and efficient manner. • Customisable filters The system must further allow to limit access to information based on user • Customisable revision workflow (including CAA) permission (document access control) and also provide insights on who has read • Document access control including read status of the users what and when. A seamless audit and revision trail must be available at all times, in • Audit trail order to accommodate for CAA and IOSA (IATA Operational Safety Audits) related • Regulation compliance links audits, which will facilitate demonstrating how changes are managed and on what Figure 5 grounds changes were issued to begin with. Last but not least, we would also like The new system needs to be capable of managing the entire documentation life for DUs to be directly linked to the corresponding regulation (e.g. IOSA) whenever cycle. Hence, from creating and publishing content, all the way to revising it that applies, and to receive automatic change requests whenever the official based on document specific workflow and approval procedures. And although counterpart changes.

INTERACTIVE Click here for full product details

Deliver reliable information to frontline employees

Dynamic Content Filtering Customizable Workflow Provide users with role specific documents thanks to our unique Dynamic Content Filtering Shorter, role specific documents for users Change handling becomes a breeze and show relevant changes for their specific role through our Integrated Revision Task List. A Fully Customizable Workflow makes change handling a breeze. Thanks to a Seamless Audit Revision Task List Audit Trail & QMS Interface Trail and a Full QMS Interface, compliance is Show changes relevant to a user‘s role Compliance is always guaranteed always guaranteed.

www.yonder.info Register here for Our Upcoming Yonder Mind Webinar

AIRCRAFT IT Operations • MARCH-APRIL 2021 • 49 CASE STUDY: EDELWEISS

YONDER MIND After researching the market, we came to the conclusion that Yonder Mind is the content management solution (CMS) best suited to our needs. It includes an easy-to-use editor that allows for the creation of DUs or information modules, in Yonder speak. Information modules are discrete units of information that can be further refined by means of adding additional information to them. In that sense, a document is merely a collection of such information modules, which brings about many benefits: information can easily be copied (or referenced, in Yonder speak) between documents without physical duplication. Meaning that whenever the source module is being changed, it is automatically updated wherever it has been reused, thereby avoiding conflicting information and outdated duplicates that may otherwise be scattered across the documentation landscape. As briefly mentioned, a given module can also be enriched with metadata and tags, consequently enabling functionalities such as dynamic filter capabilities (e.g. limit visible content of a document for a particular role or topic) and linking modules to regulatory databases (e.g. IQSMS), to name but two examples. Now let’s take a brief look at Yonder Mind and how we will work with it in the view will be pre-set by our active directory. For A320 pilots, there will be a mark future. Figure 6 shows an excerpt of Edelweiss Air’s Operation Manual — Part A both on the A320 and cockpit field, ensuring that they’ll see exactly what they (OM-A), including the custom role-based content view (the sidebar can be need according to their function. Users are of course able to change these collapsed at any time of course). settings on the fly, should they like to display all of the content instead, for We defined some roles (figure 6) and filters (figure 7) to make it easier for crews example. Meanwhile, figure 7 shows the filters that we’ve decided to use for the to get straight to the information that they need. This custom role-based content OM-A: ‘Best Practice’, ‘Policy’, ‘Procedure’, and ‘Winter Ops’.

Figure 6 Figure 7

AIRCRAFT IT Operations • MARCH-APRIL 2021 • 50 CASE STUDY: EDELWEISS

Document Revisions particular. What follows are the respective steps necessary to Each and every information module can be accessed by means of clicking on the approve a given change. During each of the stages corresponding chevron displayed on the right-hand side of a given module (see (‘Preconsultation’, ‘In Edit’, ‘Internal Approval’), there’s a defined figure 6 and 7 for examples). By clicking on a chevron, users can pull up set of stakeholders (or roles) that can jointly discuss the change additional information about the module at hand. It’s also where qualified users in detail and one that can move the workflow along. During the can issue change requests (figure 8), namely by clicking on the ‘CHANGE ‘In Edit’ stage for example, it is the Editor that can trigger the REQUEST’ tab and choosing the appropriate option. action ‘Request Approval’ to progress to the ‘Internal Approval’ stage of the workflow. Since all of the discussions and decisions are made within the system, a seamless audit and revision trail is available at all times. Once the change is ‘Ready for Publish’, we can even specify which stakeholders shall be actively informed about it, thereby allowing us to selectively communicate changes based on someone’s particular role. Hence, instead of having to go through lengthy highlights of revisions, users get notified about only those changes that actually have an impact on their role and are therefore relevant to them. A given notification also includes Figure 9 instructions on whether the related information only has to be read or whether a given user group must actively acknowledge having done so. Consequently, the system is indeed capable of providing us with insights on who has read what and when. Figure 10 shows a generic example of a Yonder Mind Dashboard including two such change notifications in the ‘My Tasks’ section for a particular user, who may access the change details simply by clicking on the respective item.

Figure 8 Once a user has issued a change request, relevant stakeholders are automatically notified based on the document-specific approval and revision workflow. We decided that we will manage changes by having three available workflow options, depending on the scope of the change: • Editorial, which is used for change requests with no real impact (e.g. misspellings); • Minor Changes, for true content changes without concern to the Swiss CAA; and… • Major Changes, for changes that need to be approved by the Swiss CAA as well. Figure 9 shows an example of one of these workflows, namely the minor one. It’s important to understand that it is during the ‘In Analyze’ stage where the responsible person (Document Owner in this case) can classify the change request coming from a given user. Hence, this is where we decide whether to classify a change either as an editorial, minor, or major change. Depending on the classification, the workflow will branch out differently thereafter; in the case of figure 9, we get to see what that would look like for the minor workflow in Figure 10

AIRCRAFT IT Operations • MARCH-APRIL 2021 • 51 CASE STUDY: EDELWEISS

and revision procedures without constraints and ensures proper control over our entire documentation. Since everything in Yonder Mind is role-based, document access control is ensured by default, including the provision of insights on the read status of users for crucial information. Regulatory compliance is covered to our full satisfaction by linking content within our documentation directly to corresponding EASA and IOSA regulations, automatically triggering a workflow for the information module whenever the official counterpart changes. Lastly, a seamless audit and revision trail is available at all times, since Yonder Mind is set up to manage the entire document management life cycle without exception. With that being said, it is safe to say that Edelweiss Air’s transition from static documentation to dynamic content management has been a true success for all stakeholders involved.

BRUNO SPECK Bruno Speck has 30 years’ experience in the industry, starting as a Swiss Air THE OUTLOOK — NEXT STEPS Force pilot before transitioning to as a commander on the A320 and Once we have all Edelweiss Air manuals in Yonder Mind, we will also tag them for A330. Today he is a Captain and Type Rating Instructor on the A320. With a regulatory compliance (figure 11). In fact, we’ll be able to tag and link EASA and BA in law from the University of Zurich, Bruno flies fighter jets as a reserve IOSA standards directly to related information modules within our documents. officer. At Edelweiss Air, he leads the Flight OPS Support and Engineering team, responsible for the EFB and compliance for relevant operation manuals. Outlook EDELWEISS AIR Regulation Compliance Edelweiss Air is a Swiss leisure airline and the sister company of • Automated workflow Swiss International Air Lines. It operates flights to European and initiation after a regulation change. intercontinental destinations from its base at . The long-haul fleet consists of four -313 and two -300, while ten Airbus A320s serve short- • Initially planned for the following regulations: and medium-haul routes. When necessary, the fleet is extended by SWISS aircraft types – EASA CAT OPS with a SWISS crew. – IOSA YONDER Figure 11 Yonder has over 15 years’ experience with electronic documentation in aviation. The business calls on the diverse The beauty of this is that, whenever an EASA or IOSA standard linked to an backgrounds of team members to bring operational documentation and manufacturer information module changes, Yonder Mind automatically generates a workflow manuals together in one solution. Pilots work with the easy-to-use YM Offline App and for Edelweiss, prompting us to have a look at the regulatory change and to profit from role-specific revision updates. While editors create and enhance content in the decide thereafter whether we need to amend the content of the information YM Editor, revisions become manageable thanks to the fully integrated YM Workflow. module to reflect the new reality and remain compliant. Company guides can be created without having to worry about duplicates anymore and So, looking again at the requirements formulated at the beginning (figure 5), updates in regulations are never missed thanks to Yonder Mind’s IQSMS connector. let’s see if we actually have met them. We wanted one publishing system for all documents which we have achieved. Yonder Mind features an easy-to-use editor that provides us with the desired xml-based content structure, consequently INTERACTIVE GIVE US YOUR OPINION allowing for dynamic filtering, thereby also addressing the need for a custom CLICK HERE TO POST YOUR COMMENT role-based content view and for customizable topic filters. Also of importance is INTERACTIVE SUBSCRIBE HERE the customizable revision workflow that allows us to reflect our internal approval CLICK HERE TO READ ALL FUTURE EDITIONS

AIRCRAFT IT Operations • MARCH-APRIL 2021 • 52