Wölfischhttps://woelfisch.de/blog/2012-07-21T22:48:00+00:00Jörg's BlogRoot Cause Analysis2012-07-21T22:48:00+00:00o'wolfhttps://woelfisch.de/blog/author/owolfhttps://woelfisch.de/blog/root-cause-analysis<p><p style="float: right; clear: both;font-style: italic">Cause: It crashed<br/>Root Cause: The admin is an idiot</p><p style="clear: both"><br>As some of my readers know, I'm a technical support engineer. Lately, I've observed a massive increase of customers asking for a <a href="http://en.wikipedia.org/wiki/Root_cause_analysis">Root Cause Analysis</a>. Judging from the Wikipedia article, an RCA is a management tool, a process which needs a formal definition and uses standardized, best-practice or customer specific reports and methods.</br></p><p>As a technical support provider we cannot do this. We do not know the customer's formal expectations, RCA is a process the customers owns. It is not even the job of a vendor's technical support. We can try to find the cause, which is hard enough with most of information about the customer setup missing in the service requests.</p><p>When we do, a lot of customers (especially those of typical "offshore" countries) do not feel it is sufficent: "It crashed because of a bug in the kernel, here's a fixed one" or "it doesn't work this way, here's a better configuration" is technically correct, but doesn't qualify as an RCA. A 500 page report does. Most likely the customer's customer expects that, being fed up with incompetence, poor excuses and outright lies of their outsourced IT services. Though not able to understand the technical details, at least their management can judge the effort put into it. But the technical support service of a software provider is simply not the right party to assemble this information.</p></p>