Management Summary ... 3 1 Introduction ... 4 1.1 KLM E&M ... 4 1.1.1 Maintenance ... 5 1.1.2 Organization ... 6 1.2 Problem ... 7 1.2.1 Problem introduction ... 7
1.2.2 Diversity of information systems ... 7
1.2.3 End-‐user computing ... 8 2 Methodology ... 9 3 Literature ... 10 3.1 Planning ... 10 3.2 Scheduling systems ... 11 4 Results ... 13
4.1 Staff planning at KLM E&M ... 13
4.1.1 Authorizations at KLM E&M ... 13
4.2.1 Aggregate level ... 14
4.2.2 Intermediate level ... 14
4.2.3 Detailed level ... 16
4.3 Planning Information Systems ... 19
4.3.1 TM/PMplan ... 19 4.3.2 TYF ... 20 4.3.3 TYF(FA) ... 21 4.3.4 Artemis ... 21 4.3.5 Prognose planning ... 22 4.3.6 Arrows (+ TOPmodel) ... 22 4.3.7 MPS ... 23 4.4 Harmony ... 24 5 Analysis ... 26
5.1 IS in the scheduling process ... 26
5.1.1 The functionalities ... 27
5.1.2 Recapitulation ... 28
5.2 Organizational structure and ICT ... 29
Management Summary
The replacement of the central labour registration system of KLM opens up an opportunity to reconsider the process of staff scheduling and the information systems used to support it. In the current process a large amount of different systems is used of which some are End-‐User Computing (EUC) systems. The use of a high variety of systems leads to a reduced spread of information throughout the organization. This reduces the ability of the organization to improve itself. Furthermore, the usage of EUC systems leads to risks that could be avoided when using supported systems. One of these risks is very apparent in practice; this is the risk of “Programs not as efficient”. A lot of labour-‐hours are spent inefficiently by processing information from one system to the other. In the new design for systems supporting the staff scheduling three different designs are created for the three different environments in aircraft maintenance (line maintenance, short-‐cycle and long-‐ cycle maintenance). In total the amount of systems used in the new designs is reduced from seven down to four. Moreover, the amount of EUC systems is reduced from four to one and eventually to zero. Regarding the organizational structure the amount of employees involved in the planning and registration can be reduced. The remaining planners that will then operate per division however will gain more power and responsibility. The newly designed process has three major advantages over the present process: unification of
1 Introduction
1.1 KLM E&M
KLM Engineering & Maintenance (E&M) is a department of KLM Royal Dutch Airlines. E&M provides maintenance for commercial aircraft. In fiscal year 2009-‐2010 KLM generated 8 billion Euro of income, 1.1 billion of this was generated by KLM E&M (management report, 2010).
Aircraft maintenance can be provided in different shapes and sizes ranging from a relatively simple P-‐check performed after each landing to a 5-‐week complete rebuild called a D-‐check. KLM E&M provides maintenance not just for KLM but also for many other airlines. KLM E&M does a lot of work for Transavia and Martinair, which are two other Dutch airlines owned by KLM.
In figure 1 the mission and strategy of KLM E&M is displayed. The main goals of E&M are providing superior support to AF-‐KLM (AF is Air France) and to be a profitable aircraft MRO (Maintenance, Repair & Overhaul) business player. The superior support consists of operational safety, availability, reliability and competitive costs. A profitable MRO business player means that E&M is not seen as a cost centre within the company but as a separate company that needs to be profitable in order to secure its own existence. Also it allows E&M to serve other companies besides KLM and AF to make a profit.
Figure 1; KLM E&M mission, strategy & goals
KLM E&M is based at Schiphol where various hangars and operational divisions are located. At Schiphol centre line maintenance is provided. At Schiphol Oost there are various locations where the other more time
consuming checks are performed.
At Hangar 10, the Boeing 737 fleet is maintained; occasionally a Boeing 767 is handled here.
Hangar 11 performs A -‐checks for the wide-‐body fleet. The wide-‐body fleet consists of the MD-‐11, Boeing 747, Boeing 777 and Airbus A330 type aircraft and numbers up to around 70 planes for KLM.
Figure 2; Schiphol Oost
An overview of all KLM terminology and abbreviations can be found in Appendix D.
1.1.1 Maintenance
Savsar (2006) provides an overview of the different types of maintenance. First he makes the distinction between corrective maintenance, which takes place when a machine breaks down, and preventive
maintenance that takes place to prevent a machine from breaking down. Preventive maintenance policies next can be separated in age-‐based and block-‐based. Age-‐based policy means that if a failure occurs before the scheduled maintenance, the maintenance is rescheduled from the time the corrective maintenance is carried out on the machine. In block-‐based policy however maintenance is always done regardless of corrective maintenance. Secondly, preventive maintenance policy can be based on whether it is at scheduled times or at other opportunities (which arises when the machine is stopped).
Aircraft MRO (Maintenance Repair and Overhaul) is delivered by KLM E&M in different shapes. They can be roughly divided in three sorts:
Line Maintenance represents small jobs that occur between flights. These maintenance jobs are preventive maintenance which is scheduled after an occurrence (being a take-‐off/landing combination). Next to this scheduled preventive maintenance, line maintenance also provides corrective maintenance. These are aimed at either small jobs which are easy to fix or larger jobs to correct failures with which the aircraft is not allowed to fly.
Short-‐cycle maintenance takes a maximum of 24 hours. It consists of scheduled preventive maintenance which is based on a block-‐based policy.
And long-‐cycle maintenance that takes longer than 24 hours. It also consists exclusively of scheduled preventive maintenance based on a block-‐based policy.
1.1.2 Organization
KLM E&M is organized as seen in figure 3; it only shows the departments that are of influence in this research.
Figure 3; KLM E&M aircraft maintenance organization
The MCC is the Maintenance Control Centre. This department of E&M develops the maintenance schedules together with the planning departments of the various divisions (Hangars, piers etc.).
ATM (Arbeidstijd Management) department is an HR department that is responsible building the staff schedules; it also focuses on efficiency improvements.
Every division within E&M such as the hangars have a PUM (Production Unit Manager), he/she is the head of the division. Beneath the PUM are the PMM’s (Production Maintenance Manager) who are responsible for a part of the employees (one or more team) or a certain production line within the hangar. Under the PMM’s are MO’s (Maintenance Officers) who control a team per shift. MO’s are called LMO in hangar 11, BMO in hangar 10 or MOO in hangar 14. Each team (ploeg) consists of more than one team, often four. These maintenance officers are the operational managers in the E&M organization. Each hangar has its own planning and PSG departments. PSG (Production Support Group) has close contact with the MCC to manage tasks/jobs that are incorporated in an aircraft check. Planning also has close contact with the MCC for the scheduling of the aircraft visits. The MPS employee is responsible for the processing of all mutations in the staff schedules. They are part of the ATM department but hierarchically fall under divisional managers (for example PMM or PUM). Every division has one or two MPS employees. In the FC line of hangar 10 there are no PMM’s, instead there are team managers and maintenance officers are called project supervisors. Within the teams sometimes contact points are appointed, these need not be the most senior employees; they have the responsibility to assign team members to specific jobs.
1.1.3 Labour planning & registration
there are always enough employees with the correct skills and qualifications to perform the demanded jobs in the designated time. Third, history of all performed labour has to be saved by the law for up to seven years.
To perform the labour planning & registration task various ICT systems are in use, they perform different functionalities. The central registration system is MPS, in this system rosters are available and it registers deviations from the rosters such as holidays and overwork. These deviations are called mutations. There also is a central HRM IT system called SAP-‐HR. In this system all personnel data is stored and payslips are calculated based on data received from MPS. Finally there is SABA, SABA is a central system which registers all
authorizations that employees have. These three systems represent the official central labour registration systems within KLM E&M. However, these two systems do not satisfy all the needs in the divisions.
Maintenance officers in the hangars require an overview of available personnel and their capabilities to make sure that there are always sufficient employees with the required capabilities in a shift. For this reason PSS (Personnel Scheduling Systems) are in use. But not every official KLM PSS delivered the required specifications of the divisions. Therefore various solutions were constructed locally at the Hangars. These solutions are called EUC (End User Computing) systems. There is a large amount of EUC systems present in the KLM E&M
organization. Approximately six of them are involved in the aircraft maintenance staff planning/registration process.
In order to have clarity about what planning actually is, one definition (proposed by van Wezel, Jorna & Meystel, 2006) is used in this research. They propose that a planning problem consists of groups of entities, whereby the entities from different groups must be assigned to each other. The assignments are subject to constraints, and alternatives can be compared on their level of goal realization.
Regarding this definition in chapter three and four we will see what entities are assigned to each other to achieve which goals and what restrictions are of influence in the process.
1.2 Problem
1.2.1 Problem introduction
The present central labour registration system MPS is “end of life” and no longer being maintained or supported by the supplier. This means that new labour laws are not incorporated in it and that it is no longer being improved. Due to this fact it is possible that certain labour laws could be infringed (one of MPS functionalities is to check the rosters with labour laws). This means that it becomes ineffective. Next to this, different divisions found that the central ICT system never sufficiently met their needs. Also the cooperation of MPS and the EUC systems causes a lot of work that could be avoided if there was an efficient labour
registration system. Therefore central management has decided that MPS will be replaced by Harmony. Harmony is an extensive labour registration system developed by ORTEC.
Harmony is a different system than MPS with different and overlapping properties and functionalities. Thus, it is possible that Harmony can fulfil functionalities that are now performed by any of the EUC systems. Also the opportunity arises to unify all the divisions within E&M. Nowadays it seems that different divisions use different EUC systems and planning processes to fulfil similar functionalities. The undesirability of this current situation is emphasized by literature.
1.2.2 Diversity of information systems
level. Such automation of only individual functions and divisions that resulted in ‘islands of automation’ is unlikely to have significant impact on the productivity of an organization (Grover et al. 1998 in Rejapogal, 2002). In the seven different divisions that provide aircraft maintenance six different PSS are used, this creates islands of knowledge (as a result of islands of automation). An example of this could be the lack of central knowledge of spare capacity at the divisions, which slows down lend-‐outs that could stimulate efficiency. Logically this isn’t a preferred situation for KLM E&M. Also there is no data available for an analysis of the results of the planning process (efficiency).
1.2.3 End-‐user computing
Extensive literature on End-‐user computing (EUC) has appeared in the 1980’s and 90’s. KLM’s definition of EUC system is an information system which has been developed by someone outside the IS (information systems) department (also called ICT community) and/or is not supported by IS. This largely matches the EUC definition of Cotterman & Kumar (1989) who describe it as the usage of computer-‐based information systems that are developed, operated and controlled by the end-‐users.
Cotterman and Kumar (1989) provide an extensive but useful summarizing list in their article. They separate their list in three groups of risks with their distinctive problem owners. The three categories are “Operation”, “Development” and “Control”. Risks falling under the development dimension are consequences of users developing their own systems. Under the control dimension risks fall consequences of the users having the authority to acquire computing resources. The operation dimension risks are consequences resulting from the operation of EUC systems. Of these three categories risks resulting from the operation and development categories are the most of influence in this research as this research focuses on EUC systems in use and not the policy regarding the development EUC systems.
Among the two categories some risks are more applicable for the current situation than others, some of these risks are:
-‐ “Threats to data security and integrity”
Some systems might not require a login or password before someone can make changes are see information he/she is not supposed to.
-‐ “Unstable user systems in organizational situations requiring stable systems”
Operations of an organization might be very dependent of the function that the system performs. If the systems fails the operations might to, causing trouble.
-‐ “Failure to upgrade the applications”
As an organization changes over time so might the requirements for the system. If this is not accounted for operations may be let down by the system.
-‐ and especially “Programs not as efficient”
Systems might solve a functionality demand for some department/person but cause a lot of extra work at the back-‐end.
These risks were never considered by the KLM organization. Therefore these risks are still eminent in the KLM organization. Also these risks might become problems when for example a EUC developer finds a job outside KLM and is no longer around to maintain or update the system or he might mean mischief. This indirectly indicated the above-‐mentioned risk of “Unstable user systems in organization systems requiring stable systems”. Of all PSS four are EUC systems that bring the above risks into the organization.
2 Methodology
This research is limited to KLM Engineering & Maintenance and within E&M to the divisions that perform aircraft maintenance. This comes down to hangar 10 FA&FC, hangar 11, hangar 14 FC&FD, D-‐pier and F-‐pier. Furthermore this research is limited to the operational labour planning (staff scheduling) process within these divisions together with the information systems that support this process. Information systems that are used within the staff scheduling operations are here called PSS (Personnel Scheduling Systems). Labour/staff planning involves the allocation staff/personnel. Work (load) planning involves the allocation of jobs/projects over time. This could be either the allocation aircraft checks over time or assigning a specific task to a point in time. The allocation of workload or tasks is another comprehensive planning task that interacts with staff planning. However because Harmony is a dedicated staff planning system and work planning is not
incorporated in the span of control of the problem owner, it is left out of scope in this research. Work planning is considered an input in the staff scheduling process.
The research is focussed on the situation as it is at this moment and left future developments of projects out of scope. The research will be build up by the following central question:
Central question:
How can the labour registration and planning process at KLM E&M be improved with the use of Harmony?
In order to answer this question correctly a few steps have to be taken. Firstly an analysis has to be made of the current process. Second an indication has to be made what the flaws of the process are and how these can be overcome. A large factor contributing to the future change is the introduction of Harmony, so knowledge of that system has to be acquired. Finally a design has to be made for the future process.
This collection of information should be found while answering the following sub-‐questions.
Sub-‐questions:
(1) What does the current planning process look like and how is it supported by information systems? (2) What functionalities do the EUC systems offer and what planning and registration tasks do they support? (3) What functionalities and planning tasks can Harmony support?
(4) What is suggested by literature regarding the current process and a new design? (5) What should the future process look like after Harmony’s introduction?
This research is based on information that was available within the KLM E&M organization. All information is gathered through interviews and hands-‐on experiences facilitated by taster-‐days and master classes. In approximately 35 interviews have taken place with system developers, key-‐users, functional application managers, Maintenance officers, external ORTEC developers and some others. In total three taster-‐days have been held within the work operations.
Afterwards and during the information finding process literature has been gathered to group and structure all available information in a framework. This is inherently difficult due to the fact that most found information is local knowledge that is difficult to communicate without local background knowledge. The nature of most information is tacit as opposed to explicit knowledge that is clear and easily communicated. An example of this could be the explanation of structure of authorizations for MRO personnel this is very difficult to explain due to the lack of a clear system in it and even harder to explain without the knowledge of aircraft type specifications.
In chapter 3 literature will be provided to base a framework on through which the current planning process will be analysed. In chapter 4 we will apply this framework to the labour planning process at KLM E&M to gain a clear picture of how the process is structured. Also in chapter 4 is an identification of the information systems that are used in the staff planning process. In chapter 5 an analysis will be made of the current (operational labour planning) situation and problems and opportunities that arise when MPS is replaced by Harmony. Finally in chapter 6 a new situation will be designed that will cover the problems and opportunities that were
3 Literature
In this chapter a framework will be presented through which the current situation can be analyzed.
3.1 Planning
In order to describe the current process through which planning and registration is done a framework should be provided to structure the information found.
Based on the planning definition from chapter 1 and using object-‐oriented techniques a certain modelling framework can be established. Van Wezel (1994) and Bakker (1995) their analyses show that planning situations use a combination of two or more of the following seven abstract object types: person, time, task, location, product, machine and vehicle.
This classification is suitable for different forms of scheduling and is not fixed. Meaning that some of the proposed abstract object types can be chosen but also others could be applied. Within this modelling framework more aggregation levels (hierarchy) can be applied. There are two main reasons to take planning decisions in a hierarchy.
First, some decisions must be made hierarchically due to a lack of information in that stage. Second, decisions can be taken hierarchically because it reduces the amount of information that a planning entity must process. (van Wezel, Jorna & Meystel, 2006)
In an aggregation sub plan, the problem is looked at from multiple levels of resolution. Aggregation can be used to establish boundaries or constraints for individual assignments of entities that fall within an aggregated group.
An entity such as time (for example) can be specified as a day, a shift or an hour in the different aggregation levels.
Decision in a certain aggregation level can cause constraints in lower aggregation levels. For example the decision to assign team A to nights shifts means that on the lower aggregation level person 1 from team A cannot be assigned to job which is to take place during the day shift. Each aggregation stage creates boundaries (constraints) for the next stage. Next to these internal constraints, external constraints can be imposed. Examples of external restrictions could be laws or self-‐imposed rules.
Staff scheduling often deals with (a) persons, tasks and time or (b) persons, locations and time (Jorna and van Wezel, 1997). In the KLM E&M staff scheduling problem location is a factor restricting the maximum workload, no more work (aircraft) can be handled at the same time than concrete is available. (Concrete symbolises parking spaces for aircraft in the hangars or on the “parking places” in front of the hangars where small jobs can be done.) Location influences the work(load) parameter and is only indirectly involved in the staff planning problem.
Persons, tasks and time are the three abstract object types (of the seven) that are of influence in this problem. Persons have to be assigned to tasks on a certain time. The person abstract is here (for clarity) called Staff and the
Figure 4; Planning abstracts
Staff Work Time person location time task product machine vehicle …... Planning
Planning typically concerns the medium-‐ and long-‐term (tactical & strategic) decisions that are generally made monthly, quarterly or yearly. Scheduling concerns the short-‐term (operational) decisions, such as the
assignment of staff to cover labour requirements (van Wezel & Jorna 1999; Huang et al. 2009). Applying this to abstraction levels, the high and intermediate abstraction levels could be described as planning and the detailed abstraction level as scheduling.
3.2 Scheduling systems
In this section a framework will be presented by which the PSS can be described.
Framinan & Ruiz (2010) provide an extensive list of components of the architecture and functionalities of scheduling systems. Their list has been build up based on an analysis of existing literature (approximately 24 articles) dealing with the structure and requirements of scheduling systems. Framinan & Ruiz (2010) also confirm that with systems planning and scheduling activities are usually treated independently. Planning functionalities are therefore not included in their analysis. This fits the situation as we are trying to describe functionalities of staff scheduling systems.
Although the focus of the list of functionalities seams to be mainly on production scheduling systems, this is not emphasized. Stadtler & Kilger (2005) acknowledge in their sum up of APS (advanced planning software)
modules that personnel planning often is covered by a master planning modules and that personnel scheduling is very rarely covered by any of the modules. This clarifies the Framinan & Ruiz framework focus on production scheduling. Here we argue that the functionalities can also be applied to personnel scheduling systems because personnel scheduling just as production scheduling emphasizes the allocation of resources (macines, shops or personnel) to jobs over time.
Table 1; Scheduling systems functionalities by Framinan & Ruiz (2010)
Type of functionality Functionality Scope of the system Production planning
Shop floor control of schedules
Problem modelling Model detection Constraints abstraction Representation of the solutions
Problem Solving Rescheduling
Multi-‐algorithms scheduling Generation of new algorithms Evaluation of algorithms Incorporation of human expertise
Solution evaluation Evaluation of solutions for different objectives Stochastic evaluation of solutions
Analysis of scenarios
Reactive scheduling Monitoring of execution
Automatic triggering of rescheduling/scheduling functions
Capacity analysis Schedule capacity analysis Instance capacity analysis
User interface Interactive scheduling
Integration with existing business information systems Input data checking Feasibility analysis
Because the functionality list specified by Framinan & Ruiz (2010) is generated for all scheduling systems in the spectrum it provides a lot more functionalities than the personnel scheduling systems (PSS) at hand perform and/or are aimed at. For clarity reasons the list will be altered to fit the situation. The two main functions served in the scheduling phase seem to be Assigning and Capacity analysis (Stadtler & Kilger, 2005 & Ernst et al.,2004). The assignment functionalities are very much emphasized in Framinan & Ruiz (2010) while the capacity analysis functionality is a bit underexposed. Especially the functionality types “problem modelling” “problem solving” and “solution evaluation” are very much described with the idea that the program to be analyzed fully simulates a problem situation and proposes one or more solutions for assignment. The PSS do not operate to that extent; the PSS filter the data available and provide the relevant numbers. Therefore these three functionality types will be replaced by the functionality type “assignment” which covers one of the functionalities that often appears in staff scheduling. This new category will contain information about problem modelling and solving when those functionalities are performed the PSS. Reactive scheduling is not supported by any of the PSS in this situation and therefore left out.
This results in the framework that will be applied in this research as seen in table 2.
Table 2; PPS functionalities
Type of functionality Functionality Scope of the system Available capacity Available workload Capacity check Assign staff
Assignment Constraints abstraction Assignment of individuals Assignment of amount Incorporation of human expertise
Capacity analysis Aggregation level Schedule capacity analysis
User interface Interactive scheduling
Integration with business Data input Data output
4 Results
For the sake of context and task planning analysis it is necessary to have some insight in what field the PSS are active. Therefore an overview of the staff planning entities and process will be presented with the use of the object-‐oriented approach (van Wezel, Jorna & Meystel 2006) presented in the previous chapter.
4.1 Staff planning at KLM E&M
For this specific planning problem three aggregation levels are considered. First is the high aggregation level, it concerns the matching of the three objects for the long-‐run (up to 5 years). Second is the intermediate aggregation level, it is a more detailed level of matching which is done twice a year (summer and winter schedule). Last is the detailed aggregation level, it concerns the final match of instances of the three objects just before execution.
The three abstract objects types take different shapes (objects) in the different aggregation levels.
Table 3; Abstract and object types
Shift Division Check High Intermediate Detailed Shift Teams Work-load Shift Individual Aircraft
Staff Work Time
All the object types have their attributes for example individuals has attributes such as (among others) authorization and presence.
In all aggregation stages the time object-‐type is operationalized as shifts. Even in the high-‐aggregation level planning (long-‐run) workload and staff levels are grouped and scheduled per shift.
As mentioned in paragraph 3.1 constraints are at play in the E&M staff planning problem. One constraint that is involved in all aggregation levels and is worth some extra attention is the authorization constraint.
4.1.1 Authorizations at KLM E&M
An employee needs quite some certificates and licences before he/she (of all direct KLM E&M employees 99.3% is male) is allowed to work on a commercial aircraft. The qualifications can be divided into four categories,
- Skills
- Levels/AML categories - Aircraft type-‐ratings and - Airlines (P&P).
Skills
Within aircraft MRO (Maintenance Repair & Overhaul) there are four different specialties, Mechanical work, Avionic work, Sheet metal work and Cabin maintenance work. These specialities are called skills.
The mechanical skill represents all work that takes place on the airframe and on the engines of the aircraft. Avionic work consists of all jobs involving the electronics that are in the aircraft. Cabin maintenance work involves all work related to components in the cabin of the aircraft. Sheet metal work regards the work done on the metal sheets which shape the outside of the aircraft.
Levels / AML categories
AML’s (Aircraft Maintenance Licence) are provided through the national Ministries in EU countries. They are available in different categories, A, B1, B2, C & D.
These AML categories are represented in the KLM levels, with a higher level an employee is authorised for higher qualified work.
Table 4; KLM levels
KLM AML Description 0 none -‐ 1 none Mechanic
2 CAT A Line Maintenance Mechanic 3 CAT B1/B2 GWK
4 CAT B1/B2 Engine tester
Aircraft type-‐ratings
Within these levels one needs type ratings for aircraft/engine combinations. Without a type-‐rating (part 145) an employee is not allowed to perform certified (level 2 and up) work on the aircraft. When an employee has an AML license for a particular aircraft (thus is a level 2 or up) he also is allowed to work on other aircraft for which he doesn’t hold a type-‐rating he is allowed to work as a level 1 mechanic. Staff of level 2 and up are often described as certifying staff, level 0 and 1 are called non-‐certifying staff.
Airlines (P&P’s)
If an employee needs to work on a non-‐KLM aircraft it needs a P&P (protocols & procedures) for that specific airline.
More extensive reading on authorizations is available in appendix A.
4.2.1 Aggregate level
In this phase team compositions and sizes are considered together with total amount of employees per division. The high aggregation level is not described further as it doesn’t contribute to the goal of information for the analysis of the scheduling systems.
4.2.2 Intermediate level
In the intermediate aggregation level schedules (roosters) are generated for all staff members. This is done based on a maintenance schedule that was developed in a previous phase. In this phase teams (consisting of individuals) are assigned to shifts (for example an evening shift on January 3rd) when a specific workload is required (which can be specified to an amount of aircraft which are in for maintenance). More than one team can be assigned to a single shift and workload. Every shift has one specified workload per division. The scope of intermediate planning level is one division, so the larger problem is divided into one sub-‐problem per division.
Internal restrictions imported from the higher-‐level aggregation:
- An employee working in a certain division cannot be assigned to workloads in another division. - Employees assigned to a team are not scheduled outside their team.
From the outside external restrictions are applied to this process, these are: - ATW laws, labour laws enforced by the Dutch law.
- Restrictions set by the division team managers
Goal functions:
- Punctuality, punctuality of service (especially for KLM) is the big goal function. Aircraft must be delivered in time to make sure that every flight is serviced.
- Minimize costs; weekend and night shifts are more costly.
- Minimizing the amount of rosters, e.g. assign teams to identical rosters with differing offsets. - Personal rosters are developed for unusual cases, but amount should be minimized.
Task model
In order to accomplish the planning various tasks have to be executed by various persons. The overall task of the described process is to assign teams to specific series of shifts with a predicted workload. The timeframe within which the tasks are performed ranges from roughly 7 months to 1 month in advance to the execution of the actual work (rosters are build up once for a complete season). The actors who are involved in this planning process are the ATM department and the division representatives of the division for which a roster is
developed. The specific tasks involved in the process are shown in table 5 and described below. Team Work-load Shift
Figure 6; Intermediate level staff
planning 1 Aggregate workload PMM MO ATM 2 Required personnel 4 Shift determination 3 Restrictions 5 Developing roster 6 Assigning teams 1 Aggregate workload 3 Restrictions 3 Restrictions 6 Assigning teams 7 Communicating Actors Tasks
Description:
1. For the roster creation an aggregate workload has to be known, this will be specified in a prediction of required man-‐hours per hour.
2. Inefficiency factors are applied to the required man-‐hours to calculate the required amount of staff per hour.
3. Collecting restrictions set by division representatives, CAO, ATW and unions. 4. Determining shift start and end times.
5. Rosters are developed based on the restrictions set in task 3 and 4.
6. Teams are assigned to the roster with different off-‐sets to establish right spread over the shifts. 7. The rosters are published and communicated to the divisions so that they can be executed as planned.
After all these tasks have been executed this phase is complete. Now the personal roster are known and communicated to the divisions. In the next phase the workforce that is available is managed.
4.2.3 Detailed level
In the more detailed operational level individual employees are assigned to work on certain aircraft or specific jobs on an aircraft. After this aggregation level an even more detailed level could be described where
employees plan (for example) to first get tools before they can start to disassemble the landing-‐gear, but this no longer adds to the research. The scope for detailed planning is smaller than that of the intermediate level, it is now a sub-‐problem per (PMM/MO) which plans his own employees which belong to his team. Therefore differences between the various locations could emerge in the restrictions. A good example of this is the difference between one project per shift in long-‐cycle maintenance or more than one in line maintenance.
Individual
Aircraft
Shift
Figure 7; Detailed level staff planning
Internal restrictions:
- Individuals working in day shift cannot perform a task or work on an aircraft during the night or evening shift on that specific day.
- An individual staff member can only be assigned to an aircraft during a certain shift when the staff member has been assigned to that shift in the intermediate level planning.
External restrictions:
- An individual employee needs the right authorization (skill, level, type-‐rating, P&P) to work on a certain aircraft/job card.
- Job cards could have a time or sequence dependency. - ATW law
- Individuals are assigned to one project per shift (Long-‐cycle maintenance) - Individuals are assigned to several aircraft during a shift (line maintenance)
Goal functions:
- Punctuality, punctuality of service (especially for KLM) is the most important goal function. Aircraft must be delivered in time to make sure that every flight is serviced.
- Establishing job satisfaction with employees - Efficiency
Task model
The tasks incorporated in the detailed staff planning process are executed by actors of the divisions, these are: Maintenance Officers (MO), MPS employee, PSG and contact points. The main objective of the process that they execute is managing the capacity and assigning individuals to specific aircraft or job cards. The timeframe in which these tasks are executed ranges from about 2 week in advance till the moment of task execution.
Table 6 displays the tasks involved in the detailed planning level grouped per actor. Description of tasks:
1. Determining which/amount of staff members are available for each shift according to the roster including their skills and authorizations.
2. Determining actual work, aircraft and/or job cards
3. Performing a capacity check, about a week in advance of task/shift execution. 4. Allowing and declining mutation requests such as holiday requests
5. When workload greatly exceeds capacity flex-‐workers can be hired (sub-‐contracting)
6. Processing mutations so that the capacity keeps up-‐to-‐date on behalf of the capacity check. This is not a fixed moment but an on-‐going process, as mutations do not come in at fixed moments
7. Determining actual staff availability day in advance of shift execution.
1 Available staff Contact point MO PSG MPS 2 Determining work 4 Mutation request 3 Capacity check 6 Processing mutations 5 Determining sub-contracting 2 Determining work 10 Determining overwork 9 Capacity check 11 Determining lend-outs 8 Updated workload 7 Actual staff available
12 Determining course days 13 Assignment of staff 13 Assignment of staff 14 Processing mutations Actors Tasks
8. Establishing the actual workload shortly in advance of the shift with updated information about delayed, advanced or extended projects.
9. Performing another capacity check shortly in advance of the shift execution with updated information about the staff capacity and workload.
10. In the previous task capacity is checked to the workload, if capacity is too low extra capacity is required to get the work done in time. One option for this is overwork.
11. When the capacity check showed that there is well enough or too much staff capacity staff can be lend out to other departments where the capacity check might have showed that staff capacity is too low. 12. When capacity exceed the required amount employees can be send out on course days where they
keep there knowledge up-‐to-‐date.
13. Staff that is available for work has to be assigned to perform work an a project (work can be specified on different levels, see section 5.1.1).
14. According to the ATW law all performed labour times of every staff member has to be registered and stored. This is done in the MPS database. Therefore all preformed labour times have to be entered into MPS as they were performed, not as they were planned. It is possible that this step is
incorporated in step 4, 10, 11 & 12.
4.3 Planning Information Systems
This paragraph provides an overview of the systems that are used in the staff planning process at KLM E&M. An overview of the locations and the information systems (IS) they use that fall within the scope of this research is provided in table 5.
Table 7; Overview locations and IS's
Location Information System(s)
Hangar 10 FA-‐line TYF (FA)
Hangar 10 FC-‐line TYF Prognose Planning Hangar 11 TMplan/PMplan
Hangar 14 FC & Mod line TMplan/PMplan Artemis D-‐pier Arrows
F-‐pier Arrows TOPmodel
In this paper six scheduling systems are addressed, these are Tmplan/PMplan (combination), TYF, TYF(FA), Artemis and Arrows (TOPmodel). All the scheduling systems involve in some way a link with MPS and the management of staff capacity. These systems are all used in the more detailed planning phase as described above, they will therefore be called PSS (Personnel Scheduling Systems) Also Harmony will be described.
There are quite some other information systems active; Saba & compliance manager are a database and an internet based read-‐out of the database which register all the authorities that employees have. MARS is a similar database. SAP-‐HR is the KLM wide information system in which all employee data are stored; it also is the system from which salaries are paid. Maintenix and Proper are systems used mainly by the PSG department for building up the job-‐cards for the aircraft.
With the help of the framework proposed in table 2 we will analyze the staff scheduling functionalities of the PSS. In the results some terms about interfaces will be used. A manual interface constitutes the processing information from one system to another by a person who actually reads the information from a screen or a print and enters it into the other system. A digital download/upload constitutes an actual digital file which is exported from one system and uploaded by an operator into the other system. A digital interface represents an export of information from one system to the other without the help of an operator.
Some functionality types of the framework presented in table 2 are strongly related to tasks out of the detailed planning process described in paragraph 4.2. The assignment functionality type is related logically to task 13 staff assignment, just as task 3 and 9 are performed using the capacity analysis functionality. The user interface functionality is called upon in all tasks where information is either extracted or entered into one of the
information systems, which these are will be answered in the next chapter.
4.3.1 TM/PMplan
Scope of the system TMplan and PMplan are two separate applications who were developed together and work closely together, The scope of the combination is to gather and calculate the available staff capacity per shift. Required workload is gathered per project. By distributing staff over projects a capacity check is performed. Assignment of individual staff members to projects is not done.
