MRO manufacturing operational data must be set up in order to run the IFS Application Complex MRO flows. In the MRO industry, parts are maintained and repaired, rather than manufactured. In the IFS Complex MRO solution, the overhaul process typically consists of the following steps: disassembly, disposition, repair (if needed) and assembly, all performed using shop orders. During overhaul, parts are disassembled to a specified point (a maintenance level), inspected (i.e., dispositioned), predefined maintenance and/or modifications is performed, any additional problems (discrepancies) are noted and repaired, generally using a standardized set of procedures (repair codes), and then the part is reassembled and returned to the customer.
As might be expected, the maintenance for different overhaul parts can be similar. For example, a repair shop might service several different makes and models of airplane engines. However, there could well be - and probably is - considerable overlap in the parts and operations involved in performing an oil change on these different engines. In recognition of this overlap, IFS Applications employs data structures which both facilitate the standardization of repairs and modifications and reduce data entry. This standardization is accomplished through the reusable MRO manufacturing operational data elements; the reduction of data entry through the concept of monolithic structures and routings.
When the VIM template structure for an overhaul part is initially transferred to manufacturing, two monolithic structures, one for assembly and one for disassembly, are created for the overhaul part. These two structures are initially identical when created. Subsequently the user can make changes in them such that the two structures will differ. However, these changes will not be reflected in the VIM template structure. The user manually creates analogous monolithic disassembly and assembly routings. These monolithic routings include all possible operations and components that could be used in the process of performing the disassembly and assembly on the overhaul part. The monolithic structures and routings for both disassembly and assembly are defined for position rather than 'real' parts.
The user also manually creates monolithic structures and routings for repair. Repair structures represent the superset all possible spare and consumable parts used up during the repair process while repair routings are the superset all possible machine and labor operations. Repair structures and routings are defined for 'real' rather than position parts.
Through association with MRO manufacturing operational data elements, these monolithic structures and routings can be tailored for specific purposes. For disassembly and assembly, maintenance levels and repair codes are the relevant data elements; for disposition and repair, disposition codes, discrepancy codes and repair codes are all used. This tailoring involves defining the relevant subset of components and operations to accomplish a specific task. For example, the user can define the subset of parts and operations are required to disassemble an overhaul part to a particular maintenance level. Or the consumable parts and operations involved in performing a certain repair step.
The allows these monolithic structures and routings to be used in the disassembly, disposition and assembly shop orders that are generated out of the order structure associated with a work order for which work scope has been defined.
MRO manufacturing operational data consists of the following:
While certain of these data elements can be defined before any transfer of VIM serial template structures, the assumption is that the user would create these MRO manufacturing operational data elements after transfer had occurred. (Specifically, the user can only define Maintenance Levels per Part, Discrepancy Codes per Part, Repair Codes per Part and Modification Repairs after the transfer has occurred. The actual Maintenance Levels, Disposition Codes, Customer Disposition Codes and Repair Codes could be defined before the transfer if desired.) These data elements are all closely dependant on the monolithic structures and routings created by the transfer or defined by the user. The association of maintenance levels, discrepancy codes and repair codes with inventory parts can only occur after those parts have been created. It is the initial transfer of VIM serial templates that creates inventory part records.
For each part within the monolithic structure which might need disassembly and (subsequently) assembly, we need to specify one or more maintenance levels. Maintenance levels, in the case of disassembly, represent the degree of disassembly an overhaul part or assembly needs to undergo to expose parts requiring service. In the case of assembly, maintenance levels represent the starting point from which assembly of a overhaul part will occur.
It is important to recognize that maintenance levels effect only one level of a structure or assembly. If you are working with a four level structure, where level one was the top level part and level four the lowest level of leaf parts, you would need to define maintenance levels for the parent part, each of the level two assemblies and each of the level three assemblies. Leaf parts at levels two, three and four would not require maintenance levels defined. In this example, it is not possible to define a maintenance level for the top level part that would result is a complete disassembly down to the fourth - or even third - level.
Consider an engine consisting of five main sub-assemblies. A series of maintenance levels could be defined which expose different combinations of the sub-assemblies. For example, a maintenance level 10 could be defined for complete disassembly. Other maintenance levels could be defined for level 1, 2 and 3 disassembly, each level exposing progressively more of the sub-assemblies for maintenance. It is possible to define generic maintenance levels, which could be applicable to many parts (for example, a maintenance level for complete disassembly), or to create maintenance levels that are part-specific or model-specific.
Whether maintenance levels are generic or specific, they must be associated with inventory parts before they can be used. Once associated with inventory parts, the maintenance levels will be fleshed out at the structure or routing level for both disassembly and assembly. Here for the specified maintenance level the subset of parts to be removed or assembled and operations performed are defined. Note that the set of parts and operations can and will vary between disassembly and assembly. During work scope definition, maintenance levels for disassembly and assembly are specified for components of the item being overhauled. These maintenance level translate directly into set of components to be disassembled or assembled and the operations for performing the disassembly or assembly.
Disposition codes are pre-defined values used during disposition to indicate what should be done with disassembled components: for example, accept it, clean it, scrap it, note deficiencies, send to a MRB for review, etc.. Disposition codes do not describe specific problems with a part - that is the purpose the discrepancy codes. Disposition codes are linked to specific customers and sites. However, one disposition code can be tied to many customer-site combinations. Only disposition codes valid for the customer and site associated with the overhaul part will be available for use during disposition.
Discrepancy codes can be either generic or part-specific. Discrepancy codes represent types of problems, deficiencies or discrepancies that can be identified during a disposition inspection. For example, again considering an engine, discrepancy code could be created for cosmetic flaws, structural flaws, mechanical flaws, etc.. Discrepancy codes must be associated with inventory parts before they can be used.
For certain components of an overhaul part, users will want to be able to do repairs. Repair codes represent generic definitions of repair activity used to perform or build up a repair. Some repair code examples for an engine might be: Change Oil, Flush Radiator, Adjust Timing Belt, etc.. Alternatively, repair codes could be defined at a more detailed level - Remove Oil Drain Plug, Drain Oil, Replace Oil Filter, Add Oil - and used to build up a repair (e.g., change oil). However, the details of how the repair is done may differ somewhat from one overhaul part to another. Different operations may be required and even different consumable parts used (e.g., different weights of motor oil). These details are made explicit later on, after the association of repair codes with inventory parts, the creation of monolithic repair structures and routings and the linking of repair codes to subsets of these repair structures and routings.
Once repair codes are created, the user must associate them with inventory parts. The user must also create for each repair part (i.e., part to be repaired) monolithic repair structures and routings, which include the set of all possible parts consumed and operations performed in repairing this part. Repair codes are then associated with subsets of these monolithic repair structure and routings. In this phase, only the relevant set of parts consumed and operations performed for the specific repair called out by the repair code are specified. After all the deficiencies and modifications are defined, a single repair shop order is created as the union of the operations and components from the chosen repair codes.
In a similar fashion, repair codes can be connected to discrepancy codes for a part and to parts affected by a modification. In the former case, the association identifies which repair codes are relevant to address a specific discrepancy for a part. In the latter case, the association identifies which repair codes are relevant for a part affected by a modification. When modifications are defined for an overhaul part, the components of the overhaul part on which the work will actually be performed are identified. These components are called the modification affected parts.