Documenting Processes in Continuing Airworthiness Organizations

Activities in civil aviation organizations are affected by the growing number of requirements both from organizations’ customers as well as from regulatory authorities. The organizations are therefore encouraged to introduce and maintain an effective management system that will ensure achieving of desired objectives. In the area of continuing airworthiness there is a traditional approach to management represented by developing and maintaining organisation exposition, which is organised in accordance with guidelines provided by regulatory authorities. The expositions are therefore focused mostly on describing duties and responsibilities of organization’s departments instead of identifying processes from their inputs to outputs. We can say that the processes are hidden by organization structure creating barriers between individual departments. The issue described above can be addressed by implementing business process management approach which can be supported by number of software applications enabling the organization to clearly identify and organize its processes, workflow, responsibilities and finally its objectives including regulatory requirements to be met. This article introduces a brief methodology for implementing business process management in continuing airworthiness organizations using a commercially available business process modelling tools. By using the methodology the organization can create clear process documentation which can be distributed to all its employees showing their responsibilities in relation to company objectives and processes. With the business process management fully implemented and the approval of competent authority, the process documentation can supplement or even replace the traditional organization’s textual expositions, operations manuals or internal directives.


Introduction
Although there are many publications such as [1] or [2] introducing the business process management (hereinafter referred to as BPM) approach and its advantages, there hasn't been published any study on utilizing this approach civil aviation organization yet. John Jeston and Johan Nelis in their publibacion [1] defined BPM as "A management discipline focused on using business processes as a significant contributor to achieving an organization's objectives through the improve-ment, ongoing performance management and governance of essential business processes." VáclavŘepa, in his publicatin (see [3]), introduced principles of information modeling of organizations distinguishing static and dynamic aspect of real world structure. The static aspects are represented by objects and dynamic aspects are represented by business processes. Currently, there are several software applications available which enable to create both object and process models and define their mutual relations. Many of these applications also provide functionalities for publishing the models in form of process documentation using many different formats. This article introduces the methodology describing how the BPM approach and related software application can be utilized by continuing airworthiness organizations to model their objectives, processes and objects and creating process documentation. This methodology can be applied e.g. by using ADONIS: CE which can be downloaded from website [4].

Objective models
As mentioned above, one of the main reasons for the implementation of business process management is to allow the organization the achievement of objectives. It is therefore reasonable that the first phase of this methodology is addressed to identify and manage the objectives both those the organization wants to achieve, hereinafter referred to as company objectives, and those that shall be achieved in compliance with various requirements, hereinafter referred to as control objectives. The role of objectives in BPM may be compared to the role of requirements in software development, therefore various principles known from requirements engineering can be utilized for the identification and administration of company objectives. In the field of requirements engineering there can be found number of publications introducing different methodologies for extracting and prioritizing rights and obligations from regulations such as [5] or extracting formal descriptions of rules that govern stakeholder actions from policies and regulations such as [6].
The output of this phase is an objective model, which is used both during BPM implementation as well as for subsequent ongoing monitoring of compliance with given requirements.
To facilitate the identification of individual objectives and ensure clarity of the objective model itself, the principles of generalization and specialization should be used when modeling objectives. Figure 1 provides suggested model of basic objective classes which are further described in the following paragraphs. To capture the relations between the objective classes, the relations generalization or compositions are used.

Control objectives
Control objectives represent the requirements of the stakeholders such as suppliers, customers and regulatory authorities. The requirements are based on particular normative documents and contracts. Normative documents and contracts usually have a detailed breakdown that allows tracing of a particular requirement by reference to the relevant part of the document, such as part, subpart, section, subsection, clause, paragraph, point, letter, etc.
Appropriately selected objective taxonomy and marking is an important prerequisite for the organization to utilize the catalogs of the objectives when carrying out audits. If these prerequisites are met, the objective model can be used as follows. Once an auditor chose a specific requirement of regulation or contract, the organization is able to quickly find corresponding item in objective model and by using the process documentation easily identify all processes related to particular objective by one single mouse click.
There must be clearly identified which specific laws or regulations are applicable with respect to scope of approval and scope of activities undertaken. Inapplicable requirements covered by applicable normative document shall be included in the models, and for each such requirement the reason why it is not applicable for the organization in question has to be clearly explained.
There must be also identified applicable aviation standards related to organization's processes such as but not limited to IOSA, Airlines for America, ASA or SAE standards and finally ISO standards such as ISO 9000 or 14000 series.
In the contracts we can meet with several typical cases of requirements. The first case involves the requirements for compliance with specific law or standards which therefore overlap with the requirements of normative documents. An example might be a requirement of the aircraft owner for keeping continuing airworthiness records stated in aircraft lease agreement, which is realized via a link to the appropriate part of the applicable regulation. In this case, it is appropriate to refer the objective based on the agreement to the respective objective based on the requirement of the normative document.
Another case involves explicit requirements that generally govern the rules concerning mutual communication and contact between the contracting parties. An example might be a requirement of the components' vendor on a specific deadline for the return of unserviceable component stated in the pool agreement.

Company objectives
The company objectives represent a desirable target states, which the organization wants to achieve. Company objectives are usually divided into strategic and specific. The strategic objectives are the highest goals of the organization and are used in the context of strategic management. The specific objectives specify the strategic objectives and should be created in accordance with the principles of SMART (see [7]): An example of the strategic objective for the continuing airworthiness management organization which acts at the same time as the commercial air transport operator may be "maximizing serviceability". The specific objectives, which are linked to such a strategic objective can be for example. "Minimizing the number of AOG (Aircraft on Ground) situations due to the unavailability of spare part", "Proactive management of defects" or "Adapting maintenance to flight schedule changes".

Process models
The process design is a key phase in the implementation of BPM, and the personnel involved in this phase must in particular maintain an adequate perspective to identify only those processes that bring some added value. The organization should also clearly distinguish between business processes covered by business process management and projects covered by project management which is not the subject of this article.

Process maps
When modeling the processes it is necessary to create a socalled process maps that represent a static view of all the processes within the organization. Depending on the size and complexity of the organization the process maps may have a few levels. The high level process map is usually followed by process maps related to individual process areas. It is very important to adhere to objectives and not organization structure when identifying the process areas and specific processes and sub-processes within these process areas.
The high level process map represents a general view of the processes within the organization. The purpose of this map is to identify individual process areas and capture their importance within the organization. It is recommended to distinguish the process areas into three categories based on the importance of processes within organization (see [8]): • Management processes -govern the operation of a system, e.g. "Maintaining process documentation" or "Organization changes" • Operational processes -constitute the core business and create the primary value stream, "Developing maintenance programme" or "Incorporating Airworthiness Directives" • Supporting processes -supports the core processes, e.g. "Personnel competence assessment" or "Material Supply" Apart from linking to lower lever process map the high level process map should provide further links to the objective models and related object models (documents, working environment, IT systems and data as described Section 4).
For each process area identified on high level process map there should be created a separate process map with individual processes that are involved in achieving of the specific objectives of the organization. Process map must clearly capture the links between processes, to make it clear what is the role of the individual processes in the realization the added value.

Process diagrams
Process diagrams describe the flow of events and activities for each process within the organization. Process diagrams can be modeled using the graphical notation of BPMN 2.0 which is the most popular standard for modeling processes [9]. The BPMN 2.0 specification can be found in [10].

Object models
The purpose of modeling the objects is to create a model of the static aspects of reality, which enter into the Organization's processes. In the field of continuing airworthiness the author suggests creating below object models:

Process documentation in continuing airworthiness
The objects should be named properly and in compliance with terminology used by applicable source documents such as regulations and standards. The principles of UML Class diagrams [11] can be used to clearly identify relations between both objects representing classes (generalization) and object representing class instances (aggregation or composition).

Document model
Each organization involved in the continuing airworthiness uses a large amount of documents of different nature. The importance of documents in relation to the processes of the Organization can be seen in a number of different aspects. On the one hand, the documents such as the law may contain requirements on the organization itself and its processes. On the other hand the documents such as maintenance data may define procedures for the execution of the individual activities. The documents such as forms and records may represent an input or output of processes or activities. In some cases, the change in document status such as issue, revision or completion can represent a trigger for an activity or a whole process.

Working environment model
The working environment is made up of employees who represent the main source to carry out the processes of the Organization and therefore the most important tool for the realization of its objectives. In the context of the proposed methodology the author create a model work environment, which will consist of the objects listed below.

Organizational unit
Organizational unit represents a keystone of an organizational structure. Moreover organizational unit provides one or more jobs joined together based on the organizational principles such as functional specialization (e.g. Engineering), planning or product specialization (e.g. Boeing Maintenance or Airbus Maintenance). The head of the organizational unit is a manager.

Performer
As a worker, we refer to a particular man, who works for the organization in a working relationship (an employee). Each worker should belong to a single organizational unit and to the manager of this organizational unit respectively, who is his direct superior.

Role
The role is a key concept in the organizational dimension in terms of BPM. Work roles are to some extent comparable to the concept of a job in the description of the tasks of a specific person in the organization. The work role is in its conception more flexible and result-oriented. Therefore, it is more suited to smaller organizations and a flexible and dynamic teams, and also in situations where its exercise does not populate the full time of a specific person. One worker, therefore, may alternatively carry out multiple roles (for example, in the role of a systems engineer, and at the same time in the role of reliability engineer). On the other side one role may carried out by more performers. The role brings dynamics the organization management. By using roles, one can ensure the conditions for an organizational system to become more flexible. The fundamental roles which in general will not be missing in any organization are (see [12]): • Employee -assigned to all employees • Manager -assigned to managers of organizational units • Process Owner -manager responsible for achieving the objectives of specific process

IT systems model
Each organization involved in the continuing airworthiness utilizes some elements of information technology while executing the individual activities. In order to provide the workers and management personnel with a comprehensive overview concerning involvement of IT into individual processes and activities, it is necessary to create a model of IT systems, which will include all components of IT systems, such as infrastructure elements, applications or services, and their interrelations. The elements of the infrastructure are represented e.g. by servers, desktops, laptops, or possibly even peripheral devices such as printers, scanners, card readers, etc. An example of an application can be both purchased software tools and own database applications or general office applications held by virtually every organization, i.e. word processing or spreadsheets. An example of the services may be e.g. web services used for gathering and updating documents, such as regulations, manuals containing instructions for continued airworthiness, service bulletins, etc. Alternatively, it is possible to use the services to model specific functionality of more complex applications.

Data model
Each organization involved in the continuing airworthiness usually uses a database for managing data relating to continuing airworthiness, personnel training, quality system, etc. It may be a purchased application, custom-made application or database application created by an organization itself most commonly by using available office applications, such as. Microsoft Access. The purpose of data modeling is to create models of data structures of each database, and then link the activities editing the data in databases with specific data and thereby get an overview of who and in which cases updates the specific data. This link may help to detect unwanted duplicities in the retained data and associated redundancy of certain activities.
In addition to a UML class diagram, the so-called relational models also referred to as the ERD (entity-relationship diagram) are extensively used for data modeling. In these diagrams, entity (E) represents a thing or an object stored in the database and relation (R) define how entities are connected. There are properties or attributes defined for each object.

Model relations
A key prerequisite for using the above introduced models types to create clear process documentation is to define their relations. Via relation a specific model object may refer to objects from different model or to different models as a whole. Relations between the different models are shown in Fig 2. The meaning of each numbered relation is explained further.

Process → Objective
Each process may refer to one or more objectives from the objective model to be achieved through the implementation of the process.

Process → Performer
The process may refer to a performer from a working environment model, who is the process owner.

Process → Document
The process may refer to a document from the document model, which applies to the process. The document may represent the process input process output, or may represent documentation that is necessary to execute the process.

Process → Process diagram
A process in the process map always refers to a process diagram that shows the detailed process workflow from the start (Start Event) to the end (End Event).

Process → Process map
Process map can have multiple hierarchical levels, where the process in the high level process map refers to a lower level process map related to the high level process. 6. Activity (task or sub-process) → Role, Lane → Role The individual elements of process diagram (task, subprocess, lane) may refer to the selected elements of the working environment models (performed, role) and thus specifying relationship (e.g. responsibility) of particular workers to the individual process activities. 7. Activity (task or sub-process) → Document, Event → Document The activity or event in the process diagram can refer to a document from the document model, which applies to the event or activity. The document may represent the input or output of an activity or event, or may present the documentation that is needed to perform specific tasks.
8. Activity (task or sub-process) → Entity/Attribute, Event → Entity / Attribute The activity or event in the process diagram can refer to entities or attributes from the data model that are related to the event or activity. The data may represent the input or output of an activity or event, or may be required to perform specific tasks.
9. Task → IT system element (application, service, infrastructure element) The task in the process diagram can refer to the IT system element (application, service, infrastructure element), which is required for the execution of the task.

Sub-process → Process diagram
The sub-process in the process diagram refers to the process diagram that shows the detailed workflow of the sub-process.
11. Document → Role A document may refer to the role in working environment model, which is responsible for the document, i.e. for its timeliness and distribution.
12. Document → Document model The document model may have multiple hierarchical levels. The document representing e.g. specific document class may refer to a separate document model, which shows the detailed structure of the respective document class.
13. Entity → Document An entity in the data model may refer to a document representing e.g. the source of the relevant data. 14. IT system element (application, service) → Document The IT system element (application, service) may refer to a document that contains e.g. instructions for use of the application or service 15. IT system element (application, service) → Entity / Attribute The IT system element (application, service) may refer to the element of data model (entity, attribute) that can be accessed through the applications or service or that is possible to be edit through the applications or service.

Conversation diagram → Process diagram
The conversation in the conversation diagram refers to the process diagram that capture the communication with an external stakeholder participant within a specific process.
23. Sub-conversation → Conversation diagram Sub-conversation in the conversation diagram may refer to the conversation diagram, which shows the details of the conversation.

Conclusion
The organizations involved in continuing airworthiness are faced with growing competition on the market and also growing amount of laws and regulations affecting their activities. The traditional management system in form of textual manuals and expositions is not capable of providing complex overview about end-to-end processes, their relations to desired objectives and responsibilities for carrying out individual activities. These challenges can be addressed by implementing business process management supported by suitable business process modelling tool. Using this tool enables the organization to create various models reflecting both static and dynamic aspect of its real world structure. This includes company objectives, process maps, process diagrams, conversation with stakeholders, working environment, documents, IT systems and data. By defining relations between models and objects, it is possible to regard the process environment from various perspectives, which will raise personnel awareness of processes, responsibilities and compliance with regulatory requirements and thus reducing risk of possible human errors.