除去定义与测量阶段，此项目的分析思路是这样的：首先是头脑风暴鱼骨图，罗列所有大家能想到的可能原因；然后将这些原因按照告警的逻辑处理流程组织成FMEA，进行RPN分析，筛选出RPN值大于100的少数因素，作为潜在的关键因子；之后对这些潜在因子逐一试验，进行确认。整个项目的突破就出现在第一个因子的试验中，其试验数据如图1所示，横坐标表示输入的告警流量，纵坐标表示告警处理延时。图中的曲线显示有周期性的拐点，而在拐点之后，告警流量增加，服务器的处理延时反而有较大的降低。这个现象如果没有针对此原因的试验，没有这些数据是无法看到的。分析这个现象的原因，难不到我们的软件工程师，很快就得出了结论：TCP协议参数设置不当。修改此参数后，重新做同样的试验，得到数据如图2所示，可见其告警吞吐率基本上与输入流量呈线性关系增长，瓶颈已经消除。这不仅仅是确认了此因子是关键因子，同时也验证了改进措施的有效性。另外几个因子也是类似的，通过针对每一种可疑因子的试验，或确认此因子为关键因子，或筛选影响不大的因子；然后针对每个关键因子寻找技术上的解决办法，就更不在话下了。此项目的成功为公司创造了每年166万的收益。
回顾这个项目，又应验了一句老话：“解决难题经常是99％的努力在于寻找关键原因所在，而修改只需要1％的努力。”6sigma本身并不提供技术解决方案，但是它的思路引导我们向着正确的方向迈进，而数据是保障我们方向正确的重要依据。此项目虽然是软件项目，但是问题本身Y是可以清晰度量的，这也是它能够适应6sigma特色，得以成功的一个原因。