:GRAPH WIP_DISPLAY :TITLE Parts replacements and workforce :X-MIN 0 :X-MAX 24 :WIP :SCALE :VAR LABOR :Y-MIN 0 :Y-MAX 100 :SCALE :VAR LABOR_UTILIZATION :Y-MIN 0 :Y-MAX 2 :SCALE :VAR TOTAL replacements :VAR proactive replacements :VAR reactive replacements :Y-MIN 0 :Y-MAX 10000 :REPORT TXT1 :TITLE TXT1 :FONT Times New Roman|10||0-0-0 You may need to use the scroll bars to the side and on the bottom to see all of the information contained in this window. This software is intended to help explore issues in the introduction of pro-active equipment maintenance. It is applicable to any situation in which you are moving from a reactive - fix things that are broken maintenance strategy to a pro-active - fix things that have indications they may break strategy. The model used here is a simplification of a model that was used in consulting work to help in this area. It included sufficient detail to help manage parts availability and labor utilization, two important aspects of the transition. The application you are using allows you to explore the consequences of different roll-out, hiring and overtime strategies. This application is menu driven. Each time you take an action, new information will appear on the screen including a menu of choices or, as for this screen, a message that you can hit any key. When you are being asked to enter information, additional instructions may appear in a small window on the bottom of the screen. If you wish to read these instructions use the scroll bar at the right to scroll through the text. :END-OF-REPORT :REPORT COMM1 :TITLE COMM1 :FONT Times New Roman|10||0-0-0 The software allows you to explore a model through a number of menus and output screens. To select a menu item you can click on it, type the first letter in the menu description, or select it using the up and down arrow keys and then press the Enter key. The selected menu item appears highlighted - usually black on white. Additional functionality available in the software is described in places where it can be used. To conserve space, later commentaries will be kept small, and you will need to scroll them to read all the information they contain. :END-OF-REPORT :REPORT COMM2 :TITLE COMM2 :FONT Times New Roman|10||0-0-0 Anything you type will appear in the editing boxes. Use the Tab key or mouse to move between editing boxes. Hold down the Alt key and press the letter for the command you desire, or use the mouse to select the command. You can change any constants or lookup tables in the model. Important constants are shown on this screen. All others can be accessed using the L and C commands for Lookups and Constants respectively. When you type Alt+R your scenario will be run using the changes you have entered. While the scenario runs, you will see a graph showing some of the key indicators of performance. After the simulation has completed, you can print the graph by pressing P or go on to do analysis on the scenario you have just run relative to other scenarios. :END-OF-REPORT :REPORT COMM3 :TITLE COMM3 :FONT Times New Roman|10||0-0-0 You can do analysis of the model by first loading in scenarios of interest, and then reviewing the output or doing causal tracing. The Load and reorder command will put up a small window with two lists. On the left is a list of loaded scenarios, on the right a list of scenarios that have been run. The << button loads scenarios. Click on the scenario you want to load in the right hand list, and then click the << button. The >> button unloads scenarios. Click on the scenario you want to unload in the left hand list, and then click on the >> button. You can load up to 8 scenarios at a time, but it is difficult to read graphs with more than 4 scenarios loaded. If the list on the right is empty, you will need to run some scenarios. Exit back to the Main Menu and do this. You can run one of the four standard scenarios, or make any variations on these scenarios you wish. Causal tracing is a process the allows you to determine the underlying causes of behavior, and differences in behavior between different scenarios. There are two options available for doing causal tracing. The first uses tree diagrams and single graphs. The second uses equations and multiple graphs. You can also trace the uses of a variable (backwards from causes). Try the different alternatives to see which you prefer. :END-OF-REPORT :REPORT COMM4 :TITLE COMM4 :FONT Times New Roman|10||0-0-0 The cause and use screens show lists of different variables. The graphs allow you to compare different scenarios. The trees allow you to investigate the structure of the model. You can double click on a variable name in the graphs, trees or documentation to view the same analysis screen for that variable. You can also use the S command to Select a new working variable. You can Print the contents of the graphs and trees using the P command. Output will be directed to your default printer. During causal tracing you can switch between the Tree and Graph represent- ations of causes. This can be useful as means of understanding both structure and behavior. You can also switch between causes and uses. When looking at causes hit U to see Uses, then C to see Causes again. :END-OF-REPORT :REPORT COMM5 :TITLE COMM5 :FONT Times New Roman|10||0-0-0 Use the Tab key or mouse to move between the number entry positions. When you see the bar | cursor you can type in a new number. To change the lookup tables relating different inputs and outputs click on the small graph for the lookup you want to change, or use the Tab key to highlight the graph, and press the space bar. You will be able to modify the lookup table graphically by dragging points around, or typing in new XY pairs. You will need to hold down the Alt key or use the mouse to select menu items. Changes you make to tables are recorded when you click OK on the table changing window. Changes you make to constants are recorded when you select the Record (R) command. You can Exit without recording changes you make with the E command. :END-OF-REPORT :REPORT OV_FAIL :TITLE OV_FAIL :FONT Times New Roman|10||0-0-0 The failure process is a very simple representation that seems to have empirical validity for a variety of electro-mechanical devices. Parts are installed as good parts and operate with little or no problem for some time. After a certain time, parts enter a class called "failing parts". These are parts that are prone to failure, and will degrade relatively rapidly over time. The degradation of failing parts over time is key to the effectiveness of pro-active maintenance. "Soft faults" generated by the failing parts are used as an indication that service is required. By monitoring and responding to soft faults, a failing part can be replaced before it actually fails. The total age of failing parts is important because it increases both the failure rate of parts, and their soft fault generation rate. The final effect of pro-active service is to get failing parts out faster, reducing both the failure rate, and the soft fault generation rate. There are, of course, a number of difficulties in detecting and responding to soft faults. First, good parts may generate soft faults at a low intensity, forcing a tradeoff between replacing aggressively, and not replacing parts that are not broken. Second, good parts may fail spontaneously without any warning at all. Both of these are abstracted from in the simplified model used here. :END-OF-REPORT :REPORT OV_REACT :TITLE OV_REACT :FONT Times New Roman|10||0-0-0 The traditional reactive service is very straightforward. You wait until something fails, then you replace. In this setup, time is spent pinpointing the part that failed - which can be hard since the whole system is often down - and then replacing the part. The simple model used here assumes that the workforce is put on overtime as much as necessary to replace the failing parts. The long term effects of overtime, such as worker burnout, are not dealt with here. :END-OF-REPORT :REPORT OV_PRO :TITLE OV_PRO :FONT Times New Roman|10||0-0-0 In pro-active servicing you do not wait for parts to fail, but monitor the "soft faults" generated by the parts. Since this is done before outright failure, it is normally easy to associate a fault with a particular part. This means that pro-active service requires little or no diagnosis be done. Pro-active replacements are made on the basis of the indicated pro-active replacements (ind pro-active rpl) and the capacity to do the replacements. Capacity determination is discussed in the screen on pro-active capacity. The indicated replacements are based on the average number of soft faults, and the intensity with which the pro-active replacements will be made (PLAN PRO RPL TIME). Note that the whole process of pro-active replacement does not start up until PRO START TIME, prior to that the process is one of reactive replacement only. :END-OF-REPORT :REPORT OV_WORK :TITLE OV_WORK :FONT Times New Roman|10||0-0-0 In the reactive replacement world labor is hired to meet ongoing requirements, or allowed to attrit away. Once the pro-active replacement program is started there are two possibilities (which can be switched between using the policy switch ANTIC LABOR HIRING) The first is the same as for reactive replacements, i.e. hiring is based on perceived demand for labor. The second is that the labor force is targeted to its equilibrium size under pro-active replacement (which is smaller). Note that decreases in the labor force only occur through attrition. Layoffs are not considered in this model. :END-OF-REPORT :REPORT OV_CAP :TITLE OV_CAP :FONT Times New Roman|10||0-0-0 Pro-active capacity is determined as the amount of working time left over after necessary repairs are made. The important policy lever ACCEPT PRO OVERTIME determines how much overtime is acceptable to perform pro-active work. It turns out that overtime is the only sensible way to bring the pro-active replacement strategy on-line. :END-OF-REPORT :REPORT COMM6 :TITLE COMM6 :FONT Times New Roman|10||0-0-0 In order to run a scenario you need to set up the assumptions you want to use. This is done by first basing your scenario on a predefined or previous scenario. Once you have done this you can change whatever additional assumptions your want to run your scenario. The base scenario assumes that the pro-active replacement technology is turned on at month 3. No overtime is allowed for pro-active replacements, and labor is hired based on the currently indicated amount of work. The slowed roll-out scenario is the same as the base scenario, except that instead of turning on all the pro-active service technology, it is turned on bit by bit. The anticipatory labor hiring scenario is the same as the base scenario, except that labor is hired to meet the expected amount of labor required when pro-active servicing is all in place. This is substantially lower then the amount of labor required for reactive servicing. The 20% overtime allowance scenario is the same as the base scenario, except that the workforce will work overtime to do the pro-active servicing. All of the above scenarios are small, varying one thing at a time on the base scenario. In designing a good policy it is, of course, necessary to vary more than one thing. You can choose a previously run scenario as the basis for a new scenario. This is particularly useful when you are refining the changes you have made. :END-OF-REPORT :REPORT COMM7 :TITLE COMM7 :SIZE 50,15 :FONT Times New Roman|10||0-0-0 In order to optimize performance over the transition it is necessary to define the cost of the transition. The most obvious definition of this is simple the total wages paid - straight time plus overtime. You may, also, however, choose to penalize parts consumption above a certain level. To do this enter the maximum number of parts it is acceptable to replace per month, and the penalty to assessed when this maximum is exceeded. Once you are happy with your choices select optimize to begin the optimization process. :END-OF-REPORT