Abstract:
The invention is generally related to operations support systems and more specifically, to a method of and system for managing and planning future use of resources. One embodiment of the invention comprises an operations support system which displays multiple visits across a timeline, each visits being associated with a set of resource requirements. The system tabulates, in real-time, the total level of resources required for all of the visits, for each given day, comparing these totals against nominal available resource levels. If there is a shortfall, the system displays a number associated with the short-fall, such as the number of additional technicians that would be required. This provides the user with feedback so he/she can amend visits and tasks within visits to resolve short-falls in resources.

Description:
FIELD OF INVENTION 
       [0001]    The invention is generally related to operations support systems and more specifically, to a method of and system for managing and planning future use of resources. 
       BACKGROUND OF THE INVENTION 
       [0002]    Operations support systems exist to provide efficient monitoring and support of line, heavy, shop maintenance, engineering, materials management, finance and other aspects of aviation and other fields. However, existing operations support systems do not provide effective ways of planning for future use of multiple resources. As a result, they are not helpful, for example, when companies are attempting to bid on future work or manage their future commitments. 
         [0003]    There is therefore a need for an improved method of and system for providing operations support. 
       SUMMARY OF THE INVENTION 
       [0004]    Airframe repair stations are in the business of selling labour, which in turn means selling ‘tracks’ or ‘slots’ of time in hangars to their customers. Keeping track of what has been tentatively booked (i.e. quoted) versus confirmed work, along with hangar capability and capacity, gets more difficult as the company grows. 
         [0005]    At an MRO (maintenance, repair and operations) organization, the Sales team may review the contracted and quoted work planned in their maintenance locations. When booking new business they will look to find available timeslots at locations that have the capability and capacity to perform the work. They have to take into account the multitude of factors that affect such plans, for example: human resources availability, location capabilities and availability, long term contracts, etc. The goals are to keep the hangars full, identify maintenance window opportunities, and ensure that they are not overbooked. The system and method described hereinafter, sets out ways of managing such resources. 
         [0006]    The system described gives up-to-date information needed for making crucial day-to-day strategic decisions in an operations support environment. The system is preferably structured to provide hangar utilization and planned projects to be viewed out 1 to 2 years, though of course any window of time could be used. Work is often only contracted/quoted about 3 to 6 months ahead of time, and about 10 tracks will be necessary for a large 3 rd  party MRO. Thus, 1000 tracked visits is likely sufficient for most applications. 
         [0007]    In order to respond to quotes or queries from potential customers on when they could bring their aircraft in for maintenance it is necessary to know what projects are tentatively booked (i.e. awaiting contract) and where contracted work is in place. It is quite common for an organization to have a number of Salespersons or Planners booking work. Hence, the system provides a centralized, real-time management system to accommodate this. 
         [0008]    Long range planners schedule maintenance activities across a number of tracks, with potentially multiple hangar locations. Thus, the system takes into account the capabilities of each location, and the capacity of each location. The capacity of a location may fluctuate over the course of a week, over the course of a season, over the course of a 2-year plan. The system also allows the user to apply a business preference or priority model for their locations. For example, the system allows a user to define a slot or track as usually handling wide-bodied aircraft, although it could alternatively hold two narrow-bodied aircraft. The system of the invention does not make any decisions on the basis of such priorities, rather, it provides the user with the capacity to identify a track in a particular way. The user can easily change the track if he/she wishes to. 
         [0009]    Again, in order to respond to quotes or queries from potential customers on when they could bring their aircraft in for maintenance the system indicates where projects are tentatively booked (i.e. awaiting contract) and where contracted work is in place. Assuming there is a timeslot available in the window being asked for by the customer, the system allows us to verify that the hangar track has the capability to work on this type of aircraft, and the physical space to squeeze another aircraft on to this track. That is, a track may fit one wide-body aircraft (e.g. B777 is 6.2 m in diameter, 65 m wingspan) or two narrow-body (e.g. B737 is 3.8 m in diameter, 35 m wingspan). As explained in greater detail hereinafter, there is no complexity in providing this flexibility as the system itself does not perform any processing or decision-making in this regard. Rather, the system provides the functionality and flexibility for the user to make such distinctions and specifications. 
         [0010]    One needs to look at resourcing to make sure you have the skilled labour available and a project manager to manage a given project. That is, one must be able to answer the question: do I have the capacity to do the work, looking at nominal resource types across my hangar or hangars? Thus, the system provides the means to look down to the skill level. The system does this by treating all resources in the same quantified way, regardless of whether they are related to labour, equipment or other resources. In this way, all of the resource needs can be measured and accounted for in the planning/scheduling of work. Also, in the interest of simplicity, these resources are handled by the system in terms of nominal capacity. The system does not deal with minutia such as breaking each employee down to their allocation on an hour-by-hour basis, or part-days on weekends. This ‘nominal’ approach was done because schedulers will have a good idea of how to handle these minutia themselves. In developing the system it was decided that client schedulers are very capable of handling such issues and that it would be a detriment to limit clients to a specific, rigid model and limitations as determined by an off-the-shelf program. 
         [0011]    The system also allows the user to quickly see what happens if they change certain things in the slot plan. That is, they can experiment with different ‘what if scenarios’ and see what the impact would be, without committing the tentative changes to the system. Thus, other users accessing the system will still see the proper, committed schedule stored on the central database, without another user&#39;s experimental changes. Usually a client scheduler will investigate possible changes if they want to know whether they can fit in a new visit, or someone is asking what would happen to the plan if the resource profile (capacity) is changed. Other exemplary ‘what if’ scenarios may include the following: 
         [0012]    1. Add new visit to determine effect on labour demand 
         [0013]    2. Add new labour capacity 
         [0014]    3. Reschedule a current visit 
         [0015]    4. Move a current visit from one line to another line 
         [0016]    5. Add another line of maintenance 
         [0017]    As aircraft hangars generally have only one large door, it is often necessary to move aircraft and MRO tasks around so one aircraft does not “box in” another aircraft in the same hanger. When a visit is first created on the system, it can be moved around. You can also “lock” a visit, setting a flag which prevents the visit from being accidently moved. This is done by clicking on the “lock” icon shown in  FIGS. 7 to 9 , or actuating the slide shown in  FIGS. 10 and 11 . Such an action sets a flag in the data record for the visit, to the “locked” state. ‘What if’ scenarios are done in a way that is analogous to the “Apply” and “Save” approach which is commonly seen on Microsoft based personal computers (PCs). That is, the user can manipulate the schedule on his/her PC to observe the possible impact, and the changes are only updated on the main database  40  if the user clicks on the “save” button. Otherwise, the user can cancel the experimental changes and the proposed amendments will disappear. 
         [0018]    Other systems, methods, features and advantages of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0019]    These and other features of the invention will become more apparent from the following description in which reference is made to the appended drawings wherein: 
           [0020]      FIG. 1  shows an exemplary user network overview in accordance with an embodiment of the invention; 
           [0021]      FIG. 2  shows an exemplary software architecture overview in accordance with an embodiment of the invention; 
           [0022]      FIGS. 3 and 4  show exemplary slot planner user interfaces in accordance with an embodiment of the invention; 
           [0023]      FIG. 5  shows an exemplary ‘edit capacity’ user interface in accordance with an embodiment of the invention; 
           [0024]      FIG. 6  shows an exemplary ‘edit work areas’ user interface in accordance with an embodiment of the invention; 
           [0025]      FIG. 7  shows an exemplary user interface for a newly created visit in accordance with an embodiment of the invention; 
           [0026]      FIGS. 8 and 9  show, respectively, expanded and collapsed displays of a visit record in accordance with an embodiment of the invention; 
           [0027]      FIG. 10  shows an exemplary user interface for displaying visit details in accordance with an embodiment of the invention; 
           [0028]      FIG. 11  shows the exemplary user interface of  FIG. 10 , in edit mode, in accordance with an embodiment of the invention; 
           [0029]      FIG. 12  shows an exemplary user interface for displaying resource demand details in accordance with an embodiment of the invention; 
           [0030]      FIG. 13  shows the exemplary user interface of  FIG. 12 , in edit mode, in accordance with an embodiment of the invention; and 
           [0031]      FIGS. 14 and 15  show exemplary process flow diagrams in accordance with embodiments of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0032]    One or more currently preferred embodiments have been described by way of example. It will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims. 
         [0033]    This document describes Slot Planning in the context of an independent repair station, also known as a 3rd Party MRO (maintenance, repair and operations). Operators who do their own heavy maintenance are generally concerned about achieving maximum yield, following operational extraction rules, etc. In contrast, 3rd Party MROs want to book as much work as possible, where they have available capacity and resources. But aspects of the invention may be employed in both such environments, as well as in other operations management environments. 
         [0034]      FIG. 1  presents an overview of an exemplary computer network  20  that could be used to implement the slot planning invention. In short, the computer network  20  can comprise any local or distributed arrangement of user computers  22  and servers  24 . For example, the main software can be installed in a stand-alone installation on one or more servers, which can be accessed through a local network such as an Ethernet, over a wireless network such as a WiLan, over the Internet possibly using a VPN (virtual private network), or be deployed in the cloud. Project management and data management systems exist which provide the underlying infrastructure for distributed real-time data management systems, addressing issues such as data coherency, that is, ensuring that data on the server and clients are all the same and resolving conflicting instructions arriving from disparate sources. The invention could be implemented on such a distributed data management system. 
         [0035]      FIG. 2  presents an exemplary overview of a software architecture that could be used to implement the slot planning invention. Remote users could access the system, for example, by means of a web browser  30  via http over the Internet  32 . An application server  34  could support and run the main business logic software  36 , making it accessible to the user via an API  38 . The application server  34  can store and access data on a separate database server  40 , which may or may not be in the same physical location. The application server  34  may communicate with the database server  40  via a Java Persistence API (JPA)  42  or similar interface. 
         [0036]      FIGS. 3 and 4  present an exemplary graphic user interface (GUI)  50  for a slot planning application. 
         [0037]      FIG. 3  shows an arrangement of seven visits  52 , that have been scheduled to be executed in two different slots  58 , which are labelled as Slot  1  and Slot  2 . As explained above, a ‘track’ or ‘slot’ is a defined area in an aircraft hangar, in which an aircraft can be located so that maintenance, repair and inspection tasks can be performed. A visit  52  typically contains multiple resource demand bars  54 . These resource demand bars  54  represent the time required for a given resource demand generated by the visit  52 . These resource demand bars  54  therefore mimic phased resource demands of a visit  52 . A resource demand bar  54  is added by double-clicking in an empty area of a visit pane  56 . The resource demand bars  54  can be moved within the confines of the visit  52  they belong to, simply by dragging and dropping them. 
         [0038]    A visit  52  is added by double clicking in an empty area of a slot  58 . When a new visit  52  is added, there are no resource demands yet (see  FIG. 7  as an example of a display for a new visit). Clicking on the “Add a demand” tab  90  in  FIG. 7  allows the user to enter new tasks. As the new tasks are added, they will appear as the resource demand bars  54  shown in  FIG. 8 . The titles of the tasks in  FIG. 8  may be edited by clicking on the resource demand bars  54  themselves. One user may refer to the tasks as “phases” while another may use explicit labels such as “inspection”, “repair”, “testing”, “wrap-up”, etc. The user may also drag the left and right edges of each resource demand bar  54  to amend the duration. Clicking between the resource demand bars  54  in  FIG. 8  will launch a new resource demand bar  54  between the resource demand bar  54  already appearing. When the visit  52  is collapsed as shown in  FIG. 9 , an icon  92  consisting of a number of horizontal bars, will appear in the top right corner, showing that the visit  52  includes a number of resource demand bars  54 . 
         [0039]    Once the user has a set of visits  52  initially and provisionally planned, the user will understand that within a given time frame, there are potential resource shortfalls driven by having too many visits  52  overlapping. The user may then move visits  52  around to alleviate the problematic time windows, or may plan to hire temporary workers for certain time periods. Visits  52  are moved simply by dragging and dropping them. Each of the visits  52  is stored as a row in a table in a relational database system. Additional tables or rows are maintained for each of the phases in a given visit. Standard tools and functions are available for windows-type interfaces which extract the data from such dragging and dropping, so that it can be used in local calculations and/or save on the system. 
         [0040]    Visits  52  can appear in  FIGS. 3 and 4  in either expanded or collapsed form. In the expanded form all of the resource demand bars  54  appear for a given visit, while in collapsed form none of the resource demand bars  54  associated with the visit will appear. For example, visit B727-100QC 255 is shown in  FIGS. 3 and 4  in collapsed form, while visit B727-100QC 245 is shown in expanded form. Each resource demand bar  54  has a label, assigned resource types and demand values for each of the assigned resource types. For example, the visit B727-100QC 245 in  FIG. 4  comprises four resource demand time windows. Phase 1 may have Inspector demand at 2, Phase 2 may have Engineers at 1 and Mechanics at 10, and so on. 
         [0041]    The details of a visit  52  may be viewed via a single click on the middle area of the visit bar.  FIG. 10  presents an exemplary display window  98  showing the details of a visit  52 . As shown, this window  98  may include a label  100  for the given visit  52 , the current start date  102 , the duration  104 , the release date (that is, the expected date at which the visit  52  will be completed)  106  and the lock status  108  (i.e. whether this visit is in a locked or unlocked state). The user may simply review the data in  FIG. 10 , and then close the interface  98  by clicking on the “close” tab  110 . Upon clicking on the “Edit” button  112  of  FIG. 10 , the window  98  enters the edit mode  120  shown in  FIG. 11 . All of the fields in  FIG. 11  are the same as those of  FIG. 10 , except that their entries can be changed while in the editing mode  120  simply by clicking on the field, or by using other standard window functionality such as clicking on up/down arrows or using an interactive pop-up calendar. Note that updating the value in the duration field  104  in  FIG. 11  will recalculate the release date  106 , and conversely, updating the release date  106  in  FIG. 11  will recalculate the duration value  104 . These calculations can be effected with simple code within the GUI. Once the edits have been completed they can either by saved by clicking on the “save” tab  122 , or cancelled by clicking on the “cancel” tab  124 . Note that clicking on the “save” tab  122  of  FIG. 11  does not save the data back to the main database  40 , but merely saves the changes locally. It is only when changes are saved from the interface of  FIGS. 3 and 4  that the changes are sent back to the main database  40 . 
         [0042]    Similarly, the details of a resource demand bar  54  may be viewed via a single click on the middle area of a given resource demand bar  54 . This action launches the resource demand user interface  60  of  FIG. 12 , which shows the label  62  for the given resource demand bar  54 , the current start date  64 , the duration  66 , the release date (that is, the expected date at which the task will be completed)  68  and the resources  70  that the task will consume. The user may simply review the data in  FIG. 12 , and then close the resource demand user interface  60  by clicking on the “close” tab  72 . Upon clicking on the “Edit” button  72  of  FIG. 12 , the window enters the edit mode  76  shown in  FIG. 13 . All of the fields in  FIG. 13  are the same as those of  FIG. 12 , except that their entries can be changed while in the editing mode  76 . Like the visit interface described above, values in  FIG. 13  can be amended by clicking on the field, or by using other standard window functionality such as clicking on up/down arrows or using an interactive pop-up calendar. Note that updating the value in the duration field  66  in  FIG. 13  will recalculate the release date  68 . Conversely, updating the release date  68  in  FIG. 13  will recalculate the duration value  66 . These calculations can be effected with simple code within the GUI. Once the edits have been completed they can either by saved by clicking on the “save” tab  78 , or cancelled by clicking on the “cancel” tab  80 . Note that clicking on the “save” tab  78  of  FIG. 13  does not save the data back to the main database  40 , but merely saves the changes locally. It is only when changes are saved from the interface of  FIGS. 3 and 4  that the changes are sent back to the main database  40 . 
         [0043]    The title pane  130  of  FIG. 4  is a text area that is not allowed to grow in size as a function of the number of characters. If there are too many characters to display, the font size auto-shrinks and wraps within the designated title pane area. The title pane area  130  is used to describe the nature of the current slot plan. As shown in the example of  FIG. 4 , this exemplary slot plan is for Hangar  2 . 
         [0044]    The toolbar area  132  of  FIG. 4  contains the user action buttons that affect the plan itself. The ‘save’  140 , ‘save as’  142  and ‘print’  144  commands are self-explanatory and would be implemented as known in the art. Standard tools and functions are available for windows-type interfaces to database management systems which allow the user to drag and drop elements, and manipulate edges. When the user makes such changes and “saves” or “accepts” them, the corresponding records in the main database  40  are updated accordingly. 
         [0045]    The ‘Edit Capacity’  146  function enables the user to change the nominal capacity of resources for the current slot plan. Clicking on this ‘Edit Capacity’  146  function causes the edit capacity interface  160  of  FIG. 5  to launch. The user is able to change the nominal capacity  162  for a given resource type  164  by entering a new number in the capacity field, or by clicking on the up/down arrows. The name of the resource type  164  may be edited by clicking on the pencil icon  166  associated with the resource type  164 . The user is able to add a new resource type by clicking on the empty box  168 , and entering text which describes the new resource type. The user may also delete existing resource types  164  from the plan by clicking on the “X” symbol  170  associated with a given resource type. The user is prompted for confirmation when deleting a resource type that is assigned to a resource demand bar  54 . Once the user has completed their edits, they can be saved by clicking on the “Save” tab  172 , or they can be abandoned by clicking on the “Cancel” tab  174 . Note that the “save” tab  172  on the edit capacity interface  160  only effects a local save. Changes to the data and the resulting calculations will only be effected on the main database  40  if the “save”  140  or “save as”  142  are affected on the main slot plan GUI  50 . 
         [0046]    The ‘Edit Hangar Area’ tab  148  in  FIG. 4  enables the user to change the hangar areas by launching the hangar area interface  180  of  FIG. 6 . The user is able to add a new hangar area (i.e. a “slot” or “track”)  58  in this hangar area interface  180 , and/or delete existing ones from the plan. As explained above, slots or “tracks” are physical areas in a hangar, in which an aircraft can be positioned for inspection, maintenance or repair. By clicking on the pencil icon  182  the user can amend the title of a slot to suit whatever identification system the user wishes to have: compass position (N, S, W, E), zone number or letter, project manager name, etc. If, for example, a certain customer uses a given location all the time they may use an explicit heading such as “Southwest-narrow”. The user is able to add a new slot  58  by clicking on the empty box  184 , and entering text which describes the new slot. The user may delete existing slots  58  from the plan by clicking on the “X” symbol  186  associated with a given slot  58 . The user is prompted for confirmation when deleting a hangar area/slot  58  that has a visit  52  scheduled. Once the user has completed their edits, they can be saved locally by clicking on the “Save” tab  188 , or they can be abandoned by clicking on the “Cancel” tab  190 . 
         [0047]    The ‘timeline pane’  134  of  FIG. 4  includes a timeline display that can be shown in Month view or year view. Month view is selected by default. The timeline shows three rows in Month view: Month of Year, day of the month, and day of the week. In year view, the timeline will show three rows in view: Year, Month, week of the year. Scrolling through the timeline will scroll both the Resource Demand pane and the Visits pane. Days or weeks where the total resource demand is higher than the nominal capacity for any of the resource types are highlighted. Scrolling with the mouse wheel  192  in this pane  134  will scroll the timeline left and right. 
         [0048]    The ‘resource demand’ pane  136  of  FIG. 4  is used to indicate to the user where the total demand for a given resource across the slot plan exceeds the nominal capacity set for the hangar. The left hand side of the ‘resource demand’ pane presents a list of resource types  164  defined in the system. It is sorted by a custom order value assigned to each resource type. For example, Avionics may be assigned a value of 2 and Electrician may be assigned a value of 1, in which case Electrician will be displayed above Avionics. Each resource type  164  is assigned a nominal capacity via the edit capacity interface  160  of  FIG. 5 . The total nominal capacity for each resource type  164  is displayed as part of the label in brackets, these nominal capacity values being obtained via a simple call to the main database  40 . The user may edit the label and nominal capacity values by clicking on the “edit capacity” tab  146 , which opens the interface of  FIG. 5 . 
         [0049]    The intersection of the resource type  164  and a day/week in the ‘resource demand’ pane  136  is where the comparison of nominal capacity and total demand is calculated. If the total demand is greater than the nominal capacity, then the degree of over capacity is displayed  196  to indicate that there is a resource shortfall. The resource demand indication  196  may consist of a number representing the degree or extent of the resource shortfall. The shortfall values are preferrably colour-coded for severity, drawing the user&#39;s attention to them. The vertical date/week line is highlighted across timeline, resource type, and visit pane. Also the date cells of the phases of the visit that is involved in the demand peaks are also highlighted. In the case of  FIG. 4 , the dates of March 28 to 30 and April 5 to 9 are shown as highlighted, with numbers entered in the ‘resource demand’ pane  136  indicating the level of the shortfall in terms of the numbers of the resources which are over-committed. 
         [0050]    The ‘visits’ pane  138  of  FIG. 4  presents all of the currently quoted and committed visits  52 , sorted by hangar area or slot  58 . A slot  58  can contain multiple visits  52  and visits may overlap in the time dimension. Scrolling with the mouse wheel  194  in the ‘visits’ pane  138  will scroll the contents of the pane up and down so that other slots  58  may be viewed. 
         [0051]    Note that the visit  52  in the ‘visits’ pane  138  of  FIG. 4  can be edited interactively, for example, as follows: 
         [0052]    a) dragging the start date side of a resource demand bar  54  to edit the start date; 
         [0053]    b) dragging the end date side of a resource demand bar  54  to edit the end date; 
         [0054]    c) dragging the resource demand bar  54  itself inside the same work area to slide the whole visit  52 ; or 
         [0055]    d) dragging the resource demand bar  54  itself to another work area. 
         [0056]    As the user moves the visits  52  around, the user interface  50  updates the over capacity resource demand indicators  196  in the resource demand pane  136  in real time. This may be done via database updates/calls and simple calculations, but it is preferred that the calculation of the over capacity resource demand indicators  196  be done by code on the GUI. Performing the calculations on the GUI would be faster than having the calculations done by the database management system. But it is also less complicated to have the calculations done by code on the GUI. Performing the calculations on the database management system would require ‘what if’ scenarios to be sent to the database management system itself rather than keeping them local (i.e. on the user&#39;s personal computer only). 
         [0057]      FIGS. 14 and 15  present exemplary process flow diagrams for implementing the slot planning system described above. These high level workflows and design specifications are sufficient for a developer to apply the concepts of the invention to any particular platform and/or existing MRO or LRP system. 
         [0058]      FIG. 14  presents a process flow diagram  200  for a scenario in which a Request for Quote is being received and addressed. Referring to  FIG. 14 , a user will typically receive a Request for Quote  202  and possible changes or amendments  204  via email, online postings or in some other manner. The user determines the estimated duration for the project, the work type, the aircraft type, the requested completion date and other relevant aspects of the project  206  and uses this information to find a slot in the work plan  208  to accommodate the new work. He/she then drags the work type into the slot  58  that he/she wants. If it is determined that no suitable slot  58  exists, the user may advise the customer that the RFQ will be declined  210 . If a suitable slot  58  does exist then the user may assess the resource capacity  212  and optimize the use of the resources by considering the nominal capacity and currently committed demand  214  and: 
         [0059]    a) creating an appropriately sized visit in the slot selected  216 ; 
         [0060]    b) increasing or decreasing the duration of the visit as required to ensure that the resource consumption does not exceed the nominal amounts; and 
         [0061]    c) adjusting the start date or end date to ensure that the resource consumption for all of the visits on the system, does not exceed the nominal amounts. 
         [0062]    Of course, the user may also move around other unlocked visits to free up the resources needed for the new project. 
         [0063]    When the user sets up the new slot claim  216 , the slot will be “saved” as a proposed visit, having the title read “quoted” or “approval pending” to show that the visit is not yet confirmed to go ahead. The user may also “lock” the quoted visit to ensure that it is not accidently erased or disregarded by others. The user may then send a quote to the customer  218  without being concerned that the resources will be committed elsewhere. 
         [0064]    The user will then typically have to wait until the customer advises who has been awarded with the contract  220 . If the quote is not accepted, then the quoted visit may be deleted from the plan  222 . If the quote is accepted  224 , then the user: 
         [0065]    a) finds the quoted visit in the slot plan; 
         [0066]    b) switches the status in the quoted visit title from “quoted” or “approval pending”, to “committed”, “contracted” or something similar. This change is then saved on the main database  40 ; and 
         [0067]    c) switches the status of the now committed visit to a “locked” state, saving that change on the main database  40  as well. 
         [0068]    There is no explicit quoted/contracted button on the system, but such a button could be provided to automate the tasks of locking the visit, and updating the visit title to a term like ‘Contracted’ or ‘Quoted’. It was felt that this task should not be implemented in this way as it provides users with less flexibility. 
         [0069]      FIG. 15  presents a process flow diagram  250  for the handling of a generic request for a MRO visit. The processes shown in clear boxes are processes that would typically occur, while the processes shown in the boxes with cross-hatches refer to processes that are particular to those of the current invention. 
         [0070]    Referring to  FIG. 15 , a user will typically receive a new visit request  252  containing the aircraft information, a list of work, and a time period between which the aircraft is available for maintenance. The user then estimates the effort, material, and duration, considers the established work standards and consults with their parts store on the availability of the parts required to satisfy the contract  254 . Based on these estimates, the user then finds a suitable time and space within the facility  256 , using the slot planning application described above. This is done by using the slot planning application to consider current visits, confirmed visits and resource capacity planning. The possibility of double booking is reduced by reserving the facility area  258  at the same time as the quotation is prepared  260 . When the quotation is sent  262 , the user can be assured that the necessary resources are reserved as required. 
         [0071]    In some cases the user and customer may agree to additional change or amendments  264 , before a contract is awarded. If the user receives the contract/agreement with the customer  266  he will mark the visit as being committed  268 . This is done simply by amending the title of the visit to “committed”, “locking” the visit, and saving these changes on the main database  40 . 
       CONCLUSIONS 
       [0072]    The present invention has been described with regard to one or more embodiments. However, it will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims. 
         [0073]    The method steps of the invention may be embodied in sets of executable machine code stored in a variety of formats such as object code or source code. Such code may be described generically as programming code, software, or a computer program for simplification. Clearly, the executable machine code or portions of the code may be integrated with the code of other programs, implemented as subroutines, plug-ins, add-ons, software agents, by external program calls, in firmware or by other techniques as known in the art. 
         [0074]    The embodiments of the invention may be executed by a computer processor or similar device programmed in the manner of method steps, or may be executed by an electronic system which is provided with means for executing these steps. Similarly, an electronic memory medium such computer diskettes, hard drives, thumb drives, CD-Roms, Random Access Memory (RAM), Read Only Memory (ROM) or similar computer software storage media known in the art, may be programmed to execute such method steps. As well, electronic signals representing these method steps may also be transmitted via a communication network. 
         [0075]    All citations are hereby incorporated by reference.