Technical Manual Feedback Report System The Technical Manual Feedback Report (TFBR) System is a process which allows end users of specific equipment the ability to input feedback about the technical documents they work with. This is usually limited to technical manuals but can also expand out into Planned Maintenance Schedule (PMS) as well. The feedbacks consist of anything from a typo to an obsolete part number and it is up to the technical specialist to develop an appropriate solution. Recently the TMFB Staff has been reporting that numerous reports go unanswered for over 100 days. Since most of these issues are in response to ship force complaints they need to be answered as soon as possible. While some answers require more detailed investigation than others it is my feeling that the average amount of reports over 100 days can be reduced by applying the principles of Six Sigma and the DMAIC process. To begin the Define phase of DMAIC I felt it was important to understand more about the process by identifying some CTQ’s. When I surveyed ships force whom are involved with this process from a customer end (see Fig 2 SIPOC) timeliness, correct solution, minimal “down time”, and swift technical manual updates were found to be the most important. Timeliness; the issues being raised about various tech manual discrepancies often require an immediate answer. Some issues reference incorrect part numbers which are required for purchases ASAP. These issues are often found when someone attempts to order a replacement part. If a system is down, and a new part number is required a solution needs to be developed as quickly as possible in order to get the system back up and running. Correct Solution; solutions must meet the needs of the inquiry as well as any other applicable Navy guidance. Minimizing "down time”; takes into account all the pieces that go into elevating a correct solution to the next step and getting it in the hands of the navy. A stock part number may need to be developed, a vendor selected. Various testing may need to take place to ensure the solution is correct. All of this requires funding and arrangements that are often above the expertise of the individual technical specialist. This fills the time between correct solution and physical implementation and plays a large role in how long a system is out of commission for. Tech Manual updated; the tech manual is only updated once a solution has been selected, tested, and potentially given a part number. Since this is a step removed from most of the previous process it is not always completed correctly. Any mention of this previous part in drawings, schematics and functional descriptions needs to change. If the new part has to be calibrated differently than the previous part that needs to be discussed. Yet the tech manual has to ensure that it can still provide support for systems that contain the previous part. In effect this is a fairly lengthy process and needs to be done carefully to avoid future confusion. To begin my Six Sigma process I developed a charter, Fig 1, to outline the focus and goals of the project. Additionally a SIPOC was written, Fig 2, to better understand the TFBR process and how it tied in with the customers. Once this was accomplished I was able to develop of a more detailed process map, which can be seen in Fig 3. Project Title Description Goal/Objective Scope/process Primary key process output variables Benefits Reducing Inefficiencies in the Technical Manual Feedback Report system The TFBR (technical feedback report) system is used by the Navy to report discrepancies found while using tech manuals. These feedback reports can be submitted by sailors or DoD employees whom submits the form through the TFBR system and it is pushed through to the proper technical expert in the DoD who can work on discovering a solution. The technical expert will then send his solution to be updated in the tech manual. While the system works as expected it is bogged down by inefficiencies. The reports that are assigned to technical experts often require an in-depth study as they usually deal with obsolete components and are discovered at a time when the part is attempted to be ordered. The process to find a replacement part can be quite lengthy while the person trying to purchase this part may need it immediately. The technical experts are also already dealing with projects and current tasks when they are bombarded with reports that require time consuming answers as well as demand immediate attention. Experts don’t always have the time to drop what they’re doing and focus extensively on the solution. Some questions deal with discrepancies in technical drawings which are originally provided by the shipbuilder. Unfortunately there is no good means of communication with the shipbuilder to deal with these questions and solutions. Due to the inefficient process most of these issues go unsolved for extended periods of time and only when visibility on the issue gets high does anyone begin really putting in the effort to find solutions. There should be provisions made to ensure these issues don’t interrupt technical experts who are already deep into various projects while at the same time providing a balance so that the questions do get answered in a timely fashion. Additionally an open dialogue with the shipbuilder should be establish such that there is a direct path to answering questions that rely on their expertise or priority materials. If the proper mechanisms were put in place to facilitate the internal customers the end result to the external customer would be more effective. The objective of this Six Sigma analysis is the following: 1) Reduce average tickets > 100 days by half on average a. Reduce the time delta between submitting a TFBR and receiving an answer. b. Time to update tech manuals with solutions will be decreased in order to avoid duplicate report submissions. c. Average funding per solution will be decreased. See COPIS Time to solution Time delta between solution and tech manual update Average funding per solution Customer: Navy Operational: Less repeat complaints, less system downtime. Financial: Funding saved from processing repeat complaints, critical systems up and working increased productiviy of Navy, less time spent on solutions reduces average funding per solution. Figure 1 – Project Charter Figure 2 – SIPOC Figure 3 – Process Map Once I had an accurate definition of the process I moved into the Measure phase of DMAIC by collecting data on tickets over 100 days, Fig 4. I found that on average per month there are 21 tickets that have been waiting a response for over 100 days. While a better metric for overdue tickets would be to measure the average response time to answer a ticket this data was not available to me at the time of this study. Figure 4 – Data on tickets > 100 days Standard deviation of the sample of tickets over 100 days is 8.69 days. Trying to reduce the amount of tickets over 100 days to approximately 10 per month, a decrease in 50% is not even possible with the process in its current state. Calculating the Cp using an upper limit of 10 days and a lower limit of 0 returned a capability of .2. The current process variation is larger than the specification range and therefore 100% conforming output would never be reached. With the current process capability and data in mind I moved into the Analyze phase of DMAIC where I began by parsing the various tickets from my sample set. What I found was that the tickets could be broken down into 5 main categories; tech documentation typo, tech documentation clarification, obsolete parts, tech documentation recommendations, fleet wide issues and new guidance. From this I developed a Pareto Chart, Fig 5. What I noticed from the chart was that 70% of the total reports put in dealt with Tech Documentation Typos and clarification. Not even the more significant issues such as obsolete parts of fleet wide issues. These were issues that could easily be solved in less than 100 days. Figure 5 – Pareto Chart Next I needed to outline where the potential problems could be occurring. Figure 6 shows a Cause and Effect diagram I developed in order to understand the potential sources of error. Figure 6 – Cause and Effect Diagram It can be seen from the Cause and Effect diagram that many of the issues are contained in the TFBR system and the TFBR staff. More information about the TFBR Staff was revealed by looking at a Swim Lane Chart, Figure 7. Figure 7 – Swim Lane Chart After developing this chart I noticed that the TFBR Staff is only involved at two steps; assigning the feedback report to a lead engineer and receiving the solution. TFBR staff often screens feedback reports to lead engineers incorrectly as they are not familiar with the equipment or understand the intricacies of which specialist deal with what pieces of equipment. Additionally their involvement in receiving the solution and passing it along to the ILS staff for correction is unnecessary since they do not understand the equipment to determine if the solution is acceptable or not. The TFBR computer system is also inundated with potential problems. There are significantly more potential areas for error in that aspect of the process as is evident from the chart. While there is not a clear way to speed up the research phase there are ways to increase the efficiency of the TFBR system to more effectively get the specialist involved. This could be accomplished by improving the email system to provide a description of the inquiry assigned to them. Often issues are not complex and solutions could be provided quickly but a specialist has to log into the system using a password that needs to be changed every 90 days. Inevitably most specialists will wait for multiple reports to be sitting in their queue before looking at them. The process could be improved by provided a synopsis of the issue in an email. That way an issue would be brought to a specialist’s attention immediately. This gets them involved and thinking about a solution much earlier than if they had to log into a specialized system. Since many specialists are involved in multiple projects unrelated to the TFBR’s that are being assigned to them this is also a good method for introducing them to the problems without interrupting their current work flow. A common complaint from specialists is that they are already deep into multiple projects and TFBR’s keep piling in. Further research into this process will focus on the benefits of removing the TMFB staff and implementing more detailed functionality into the TFBR computer system. To begin removing the bloat in the TFBR process I will begin by removing the TFBR staff from low level activities and focus their efforts on assisting specialist with detailed projects. Securing funding and coordinating with outside specialist where projects may overlap will be their main objective. The TFBR computer system will then need to be updated to include detailed synopsis of the issues as well as incremental reminders to the specialist to keep them aware of the pending complaints and how many days they have been waiting a response. The TFBR system will also be updated to contain auto assign functionality to pass the tickets and solutions between the engineering leads and the ILS Staff respectively. Moving into the Improve phase a sequence of activities, Fig.8, was developed. This sequence incorporated training that would be involved for the TFBR staff’s new focus as well as any training requirements and familiarization for anyone involved with the new system and processes. Each of these steps was weighted with a time, in months, of how long it would take to complete. Figure 9 shows this weighted critical path and that it would take 13 months to full implement the process. A Gantt chart was also developed; see fig.10, to illustrate the process as multiple steps happen simultaneously. Figure 8 – Sequence of Activities Figure 9 – Critical Path Figure 10 – Gantt Chart An updated process map, Fig 11, shows the new process with the additional/modified steps. Figure 11 – Updated Process Map Once the streamlined Teach Manual Feedback Report process has been fully introduced, which based on the critical path of implementation it was determined that approximately 13months would be required, data will begin to be collected on the subsequent TMFB reports generated each month. The total amount of TMFB reports open at the end of the month and the number of those reports over 100 days will be used to create a P-chart. It may be best to begin using weekly data until multiple months have passed by to provide adequate data sampling. A p-chart was chosen as it most efficiently took into account ever changing sampling size of reports per month. In the future it would be best to begin understanding TFBR tickets in terms of length of time to complete as the percentage of tickets over 100 days may stay the same at times, it is the metric of how long it takes to answer all tickets that is a more telling sign of progress or regression in the process. Currently goal over time is to see a reduction in reports >100 days by 40%. This was derived from the Pareto analysis which showed that ~70% of TMFB reports >100 days consisted of tech manual typos and clarifications. If even 40% of all >100 day tickets could be eliminated this would signify of huge success in the new process. The following is the control plan for the new system. Process Name: Streamline of Technical Manual Feedback Reports Tool used: TFBR software, engineering support, Integrated Logistics Support system Standard operating procedure: (See updated process map for additional details) 1. Problem with tech manual is identified by Person A. 2. As soon as the discrepancy is discovered Person A inputs a detailed description of the discrepancy using the TMFB system. 3. Based on various input criteria defining the problem the TMFB report is send to the appropriate technical lead who deals with the system in question. 4. A notification is received by technical lead giving them the discrepancy synopsis. They have the ability to click the supplied link for more details as well as use that link to assign the report to a specialist who can investigate and respond to the complaint. 5. The technical specialist receives an email notifying them that they have been assigned a feedback report to investigate. This email provides them with the synopsis of the issue discovered. 6. The technical specialist receives 14 days from receiving the report to respond. 7. A response back to the technical lead is required if it is evident that the response will take more than 14 working days. 8. Email notification of >10 working day issues are provided to all technical specialist in the appropriate group such that they may provide assistance to the original assignee. 9. Email notification of >15 day issues are provided to TMFB staff who contact originally assignee to determine if additionally funding or special project need to be made to satisfy in-depth projects and solutions. 10. TMFB reports >30 days must be identified as special projects before 30 day mark. a. If 30 day mark is reached without designation of special project by TMFB staff division head of original assignee is notified. 11. Solutions are input into the TMFB system and assigned accordingly: a. If discrepancy involves new part identification ILS staff receives notification of the discrepancy/solution and update the stock system accordingly. i. Person A is notified of the solution and the new part number. ii. Tech manual update staff is notified of part number change such that tech manuals can be updated for future reference. b. If discrepancy involves tech manual update but not involving a part number change tech manual update code is notified of discrepancy/solution and update the appropriate tech manuals accordingly. i. Person A is notified that tech manual has been updated to reflect their concerns. Tolerance: Projects identified as non-special projects are to be provided a solution within 30 working days of input. Aiming for 40% reduction of TMFB reports >100 days in following year of implementation. Inspection frequency: Monthly Sample size: All active TMFB reports being worked Person responsible: TFBR staff Report documents: P-chart taking into account weekly amount of open TMFB reports and how many are currently over 100 days. Since reports tend to build up throughout the year comparison data can be drawn to last year’s metrics for the same month. Ensure the trend it leaning towards less tickets >100 days as compared to the same month last year. This will not be used to determine if the system is in or out of control but serve as a metric for successful implementation and reduction of tickets overall. Reaction plan: Due to the nature of the feedback reports samplings and reports would need to be collected monthly in order to see the overall trend. These P-charts would be observed closely for signs of the system going out of control. If this occurs the process will continue but TMFB staff will closely monitor various conditions which are contributing the system not meeting the specified goals. Is a particular assignee to blame? Are the overdue reports belonging to a specific system or the same general complaint? Is the TMFB staff providing assistance as necessary when these projects reach the 15 day mark?
