Enabling part defect 360 s: the practitioner s view

Transcription

1 Journal of Decision Systems ISSN: (Print) (Online) Journal homepage: Enabling part defect 360 s: the practitioner s view Keith Drummond To cite this article: Keith Drummond (2016) Enabling part defect 360 s: the practitioner s view, Journal of Decision Systems, 25:sup1, , DOI: / To link to this article: Published online: 16 Jun Submit your article to this journal Article views: 344 View related articles View Crossmark data Full Terms & Conditions of access and use can be found at

2 Journal of Decision Systems, 2016 VOL. 25, NO. S1, Enabling part defect 360 s: the practitioner s view Keith Drummond Business Data Analyst / Hardware Engineer, Cork, Ireland ABSTRACT Delays in detecting and addressing defects typically results in higher costs to a business. Having a 360º view of defects helps a business determine the next steps needed to minimise the impact that defects have on customers and costs to the business. This project has provided an addition of a data model for part defect-tracking through the lifecycle of a product. KEYWORDS Defect; data model; hardware; replacements; classification What is the data driven initiative being reported? The HEAL project (Hardware Engineering Analytics & Leads) is targeted at the following problem: how are defects detected in the business. The later defects are found, the more costly they are to the business. In the organisation under study, the area of interest is hardware defects, which are typically captured as part numbers, which are expected to perform at a certain (target) level. There are usually two questions that need to be answered. First, what part number is underperforming, and second, why it is underperforming. An earlier project (focused on the first question) reduced the amount of data post-processing that was done by individuals by 90%. However, there remained a significant challenge in trying to answer the second question. There are numerous manual processes. These processes arise because: (a) Different IT systems hold different pieces of the puzzle, (b) A large number of people involved in the information supply chain and (c) The different IT systems and large numbers of people lead to data quality issues. This is depicted in the information supply chain shown in Figure 1. Unfortunately for the business, a lot of the time the key piece of information to answer the why appears much later than the business would have liked. The later it is answered, the more costly to the business. The long-term objective of the HEAL project is to deliver advanced analytic capabilities to the business to save on costs via the early identification of defects. One of the key reasons we can t answer the why is that we don t have an integrated set of data. As noted in the Information Supply Chain graphic, there is a lot of time and effort that goes into getting data for analysis to enable important questions for the business to be answered. CONTACT Keith Drummond keithdr01@hotmail.com 2016 Informa UK Limited, trading as Taylor & Francis Group

3 606 K. Drummond Figure 1. Information supply chain. As part of the journey to establishing the analytics for HEAL, a relational data model has been developed which serves as the foundation upon which the analytics can be built. A data model is a tool to abstract and visualise business problems, and to understand data. It is a highly effective way of having conversations with the business about what things are important and establishing a solid foundation upon which useful analytics can be built. Why is it an important initiative? The early detection of defects is a means to avoiding significant costs to the business. If there are too many defects, there is a risk of customer outage which leads to customer satisfaction suffering. In one instance, an undetected defect ended up costing the company $12.5 M ($8 M due to customer outages plus an additional $4.5 M in cost of service). In another instance, there is a recurring waste occurring due to a defective process leading to an unnecessary cost of service of $1.5 M per annum! Within the organisation s products (or systems), there are multiple hardware components such as Printed Circuit Boards, Disk Drives, Power Supplies, Cables, etc. There may be hundreds or even thousands of parts making up a system which are housed in a chassis / cabinet. Key Performance Indicators (KPIs) are used to assess the quality / health of these hardware components. The KPI that is used is the Annualized Replacement Rate (ARR). There is a strong connection between ARR and downtime, as indicated in Figure 2. The real risk to the business is if an emerging trend is missed failing to nip it in the bud (or detecting it in a timely manner). This could lead to an epidemic, which increases the likelihood of customer dissatisfaction.

4 Journal of Decision Systems 607 Figure 2. Customer outage v. ARR. Annualized Replacement Rate (ARR) is the % of the population of parts that is expected to have a replacement every year. For example, if there are 100 units in the field and the ARR is 12%, then you expect 12 parts to fail each year (or about one per month). Since we typically review the ARR on a monthly basis, we would expect to see only 1 failure each month, and if there is more than that, we suspect that something is wrong. How was the initiative implemented? The initiative was implemented using design research to provide rigour to the research process and Agile Methods to guide the development of the artefact itself. In design research, an artefact is used as the intervention (action). For this initiative, the relational data model which is a model artefact type (Hevner et al., 2004). It is a visual representation of the things of interest to the business. Agile provides a closely-aligned approach to design research. Many Agile techniques were used throughout the initiative. For example, envisioning techniques were used early on with the team to develop a shared understanding of what the objectives were. User stories were also written by the team and collectively prioritised. These were useful in understanding what the big pain points were that needed to be addressed. The 4 steps of a sprint align very well with steps 1 through 4 from design research as shown in Figure 3. User stories helped to formulate a problem and user acceptance testing helped to evaluate the artefact at different stages. Since Agile requires client engagement from start to finish, this helped ensure that we were fixing a problem worth solving. When did this initiative take place? Figure 4 shows the evolution of this project. In June 2015, an envisioning workshop was held. A desired outcome of this session was to have the ability to quickly identify what parts are troublesome, and why they are troublesome.

5 608 K. Drummond Figure 3. Design research & Agile alignment. In August and September, it was clear that a lot of the data sources needed to answer the important questions for the organisation were not available. Therefore, it became clear that the business did not truly understood what the things of interest were. In late October, the first iteration of the data model was undertaken. Essentially, this was a time of learning about the effectiveness of a data model. In mid-november, the second iteration of the data model identified a lot of the things that the business was interested in. The evaluation approach used in this iteration proved very useful for subsequent iterations, and was also crystalizing the problem even further with a clearer objective for the overall project now identified as push defects left. In mid-december, the third iteration was designed collaboratively with the local organisational team. The evaluation was much more focused on this iteration and proved more useful, with the data model scorecard (Hoberman, 2015) used in conjunction with a survey providing useful feedback, and a score for the data model. In late-december, the fourth iteration was designed collaboratively using the feedback from the third iteration. Once again, the scorecard was used to evaluate the data model to garner further feedback and to arrive at a score. In January and February of 2016, the fifth iteration (shown in Figures 4 and 5) was designed and evaluated in a collaborative manner. This was perhaps the most dramatic point in the exercise. The initial focus was on the ARR aspect and deriving value from the data model for that area was the primary objective. This objective was met. Interestingly, it was when the data model was reviewed with other departments within the business that significant additional benefits were identified.

6 Journal of Decision Systems Figure 4. Timeline for HEAL. Figure 5. Data model for HEAL. 609

7 610 K. Drummond Figure 6. Data model beneficiaries. Who has benefited from the initiative? Interestingly, everybody in the business who has seen the data model has seen potential benefits, and the groups are highlighted in Figure 6. The change management team will have an early-warning system which will allow them to see that unapproved parts have appeared in the supply chain and prevent these from getting to customers. Customer service will have improved processes to ensure that parts that are not actually defective don t get needlessly replaced. The original problem was trying to be solved for numerous teams: GPQE, GSCE, GDE, and Product Teams. Answering why is the part number troublesome question with the data from the model takes a lot less effort. The logistics team (who need to ensure adequate stocks of part numbers are maintained), will have better notification of where parts are needed based on the data from the model. Test Engineering will be in a better position to analyse test process effectiveness and therefore be able to drive optimisation efforts. The compliance team will have a better understanding of the product genealogy through the lifecycle and will be able to ensure that any non-compliant parts are detected early. Where is the business value being realised from this initiative? Many benefits as shown in Figure 7 have been derived by undertaking this design research initiative. The most interesting finding comes from the fact that the bigger contributions

8 Journal of Decision Systems 611 Figure 7. Benefits from HEAL. Figure 8. Tables to alert change management of non AMPL part in a phase. were found by meeting with different parts of the business while using the artefact developed as a centre-piece and visual aid for the conversations that took place. One example (from the Change Management Team) is described here: The data model was reviewed with the change management group (outside the project area, Hardware Engineering). They wished they had this earlier. Why? They described an issue that actually happened and led to serious pain.

9 612 K. Drummond Figure 9. Financial benefits. There was a significant increase in power supply field failures. 179 K suspect power supplies shipped in 2010 Q3 and Q4, with 7.5% ARR (expected ARR is 0.6%). The excessive replacements resulted in cost of service of $4.5 M. In addition, a high # of escalations resulted, with approximately 80 customer outages, costing $8 M. Outage occurred due to both power supplies in the same Disk Array Enclosure failing at the same time defeating the redundancy! This was root-caused to a component supplier redesigning a 5v regulator used on this PS. The new part was susceptible to delamination which permitted humidity to lead to the component failure and the component failure resulted in a shutdown of the power supply. Here s the thing the organisation was not notified of the component change. Nor did the organisation find the issue internally. By leveraging the data model as a foundation to build a BI solution, it could have played out like this.

10 Journal of Decision Systems 613 A Component Part Number not on the Approved Manufacturers Parts List is found in the test process (either within the organisation or at their supplier). An alert is sent to the Change Management Group (using tables in Figure 8). Issue is addressed (nipped in the bud) and 179 K power supplies are not shipped This means that there are no customer outages and $12.5 M saved. By utilising 4 tables from the model as in Figure 5, we are able to see opportunities to do things better (change management) and to do new things (alert notifications) that will help drive improvements in business processes. This essentially serves as risk mitigation in that the detectability of a problematic (unapproved) part is enhanced. These opportunities align with one of the objectives of this team (prevent non-approved parts from getting to a customer). This objective is tied to the business driver of enhancing TCE - a commonly-shared goal of many of the stakeholders interviewed during this analysis. When 4 examples were explored with the business, financial benefits were identified as shown in Figure 9. Conclusion Design research as an approach to solving business problems has proven to be very useful in this initiative. Using Agile techniques to iteratively develop an artefact is a powerful way of getting value early. The artefact evaluation at the end of each iteration serves as a means to improve the next version, ensuring that there is alignment to the user needs, and that the artefact gets closer to those needs. A data model is a highly effective way of having conversations with the business about what things are important and establishing a solid foundation upon which useful analytics can be built. Disclosure statement No potential conflict of interest was reported by the author. References Hevner, A., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS quarterly, 28, Hoberman, S. (2015). Data Modeling Made Simple: A Practical Guide for Business and IT Professionals. Technics Publications.