Following aircraft disassembly and the inspection of disassembled parts on the shop floor, technicians evaluate each part and assign each part a status: cleared for reassembly, routed for maintenance, or condemned and in need of reordering. At this juncture, critical parts are also identified-parts that are needed immediately in order to complete maintenance work on schedule. These critical parts become the focus of both technicians and administrators. For schedule-minded technicians, procuring critical parts becomes an immediate need, whether through ordering parts or "robbing" parts from a kit whose need for the part is less pressing. For administrators, the challenge was to track the inventory of parts and the number and type of parts ordered, and to gauge the impact of inventory status on a variety of production assemblies. Consequently, from the perspective of administrators, the kits themselves also assumed a status-assembled, assembled with part orders against it, or disassembled and awaiting ordered parts. Each of these perspectives had to be addressed.

KCHR is an Oracle®-based software tool that uses a client/server architecture (Windows NT) to provide technicians and administrators with real-time part and kit status data through web-based reports and the ability to order parts on-line. KCHR interfaces with the Air Force's existing G402A parts ordering system and provides a wrap around to the Air Force's EPS ordering system, allowing users to perform drag-and-drop ordering of parts while automatically recording and archiving these transactions. This system gives mechanics in and administrators of the GE Rotor Shop immediate access to parts data.

The project originated under the auspices of KBSI's Lean Value Chain (LVC) project with the US Air Force. Already employing the KBSI-developed Inventory Tracking System (ITS), management at Tinker were interested in recording and minimizing undocumented part robs on the shop floor. The KBSI team, headed by project manager Michael K. Painter and LVC project manager Dr. Mike Graul, recognized that there existed a number of supply chain threads that allowed technicians on the shop floor to acquire critical parts. Following sponsorship from the Air Force Research Laboratory, Materials and Manufacturing Technology Directorate, Manufacturing Technology Division (AFLR/MLM), KBSI set to work on developing a system that could be used by both mechanics on the shop floor and high level administrators and that was scalable enough to implement beyond the initial rotor shop production line run.

KBSI's first step in developing the KCHR system was to gain an understanding of the problem by performing extensive interviews with mechanics and administrators and identifying those personnel who, as "domain experts," could help define an overarching concept of operation for maintenance activities and in developing and implementing KCHR. This addressed one of the top challenges facing the KBSI team: consensus building and communication among the many players involved in both the day-to-day operations at Tinker and in the development of KCHR.

The KBSI team next began to document the concept of operation using IDEF3 process modeling, in the form of KBSI's ProSim® software, to model the current parts maintenance workflow and, in particular, the critical part resolution chain. From these models, again using ProSim®, the KBSI team generated simulation models and analyzed these models to pinpoint the shortcomings of the current workflow. SmartER®, KBSI's information and data modeling software, was used to map data system requirements to each process in the workflow. Using these base models, the KBSI team built prototype workflows to streamline and optimize the critical part procurement process. These models then underwent a review cycle with domain experts and their feedback was used in developing another version of the models.

With a clear understanding of the various supply chains used at Tinker, the KBSI team began building a prototype implementation of the software itself. The models identified a number of focus scenarios that would be central to KCHR functionality-in other words, current practices at Tinker that KCHR must electronically support. Foremost among these scenarios was creating kits.

As we described earlier, when an aircraft arrives on the shop floor for maintenance, mechanics disassemble the plane's parts, inspect the parts, and store the parts into designated kits. At this juncture, mechanics will document the disassembled parts and record each part's status. Prior to KCHR, Tinker personnel manually recorded this data, passing sheaves of paperwork from one division to the next for each new aircraft disassembly-a method that was both time consuming and error-prone. Checking the status of a particular part meant leafing through a stack of forms or locating the kit on the shop floor, and these inquiries were frequently out of date before a response was received. As a consequence, Tinker personnel were forced to maintain numerous, inconsistent parts lists hampering their ability to determine kit contents, critical part needs, kit location, and kit status.

A central concept in KCHR is the eKit-electronic records that, as the counterpart to physical kits, capture and compile part lists and part status for the corresponding kit. KCHR provides technicians with an array of eKit templates that can be used in the creation of new eKits. The templates provide a standard list all parts contained in the corresponding kit and allow users to designate the location of the corresponding kit and the kit's disassembly technician. When an aircraft arrives in the shop, the mechanic identifies the standard SRU to which he's been assigned, and, using the template that corresponds with the SRU, creates a new eKit. The new eKit on his workstation now lists all of the parts in the SRU allowing him-electronically-to record the status of each part and to save the record to the database.

A second critical scenario is the procurement of parts that, following inspection, have been designated as condemned. Depending on the maintenance schedule, these parts can be either ordered or "robbed" from another kit. Either option must be recorded in KCHR and this data must be accessible. This represents a second challenge that KCHR had to address: how can the system track the ordering of parts and the more unorthodox-but widely practiced-method of robbing parts both in relation to the parts themselves and in relation to the kits?

KCHR's interface with the G402A parts ordering system allows users to access the EPS and order parts on-line. A mechanic who discovered the need for a part could, within KCHR, log into the familiar EPS system and, using drag and drop, add the listing for the needed part (which includes all documentation for the part) in the eKit to an Ordered Parts list in EPS. Once the part has been added to the Ordered Parts list, users can then designate the number of parts units to be ordered-the number of units of the part condemned is listed on the same screen on their workstation. The EPS automatically generates an invoice and all part order data is automatically saved to the database. Administrators who want to check the number of orders placed against a particular eKit need simply log into KCHR and, in the proper window, select the eKit-the data will be compiled for them.

Robbing parts from kits is as simple and uses the same principle. Users select the eKit that requires the robbed part (the destination kit) and the stock number of the part that is to be robbed (KCHR will filter the parts list to include only those parts in the eKit that have been condemned). When the part to be robbed has been selected, KCHR will automatically provide a list of eKits that have the part available, indicating the status of the kit and the number of units of the part that can be robbed. Users can select a part from the list and, using drag-and-drop, add the part to a shopping list for the destination part. All robs are automatically saved to the database. Administrators who want to check the number of robs placed against a particular eKit-i.e., the inventory of a particular kit-can log into KCHR, and, in the proper window, select the eKit-the data will be compiled for them.

Once parts have been robbed or ordered, the receipt of those parts within the kit must also be recorded and tracked. KCHR allows users to select the invoice number of a particular order and will then lists each of the parts corresponding with the selected invoice, indicating the number of units ordered for each part, the number of units received in the most recent shipment, and the number received to date. The dialog also identifies the eKit against which the order was placed, the status of the corresponding kit, and the location of the kit.

KCHR's reports allow users to instantly compile kit history data and distribute that data electronically or as hard copy. Reports are generated as *.html documents, providing an easy means for circulating and viewing reports among a distributed network of users. Users can individually select eKits in the database and generate reports from the selected items. KCHR allows users to generate several types of reports for kits and parts in the active shop including:

	Kit Contents lists the current status of selected eKits, the location of the corresponding kit, and all parts in the eKit indicating the number condemned, routed, and ordered.
	Shortage Across Kits lists parts shortages for each of the selected kits.
	Shortage By Kit lists parts shortages in the selected kits.
	Complete Kits lists all kits according to their status and location.
	Storage Location Assignments listing the location assignments of all kits in the shop.
	Status History listing the status history of the selected eKits including the date and time created and the date and time of each status change.

KCHR is a client/server system (Windows NT) using web-enabled reports and virtual data basing to provide real-time information on kit contents, location, status, and the procurement history and status of critical parts. Tinker's existing methods for parts tracking were cumbersome and critical part orders were difficult to track and slow to resolve. Tinker needed not only to streamline this process, but also to record the history of critical part needs and, based on this history, forecast critical part needs.

Following KCHR's initial implementation in Tinker's GE rotor shop, the time required to close the procurement loop for critical parts was reduced by over 50%. Our data shows that for resolved critical parts the average time to resolution, before implementing KCHR, was 213 days. That average was reduced to 61 days after KCHR implementation. More directly, with the amount of time mechanics spend procuring parts greatly reduced, more mechanics are now focused on maintenance activities-less time chasing parts and more time turning wrenches. With more reliable and timely order history and part inventory data, administrators can make more informed scheduling and pricing decisions, thus increasing productivity and lowering costs.