We've been experiencing some record locking errors with an application we host internally on our own infrastructure, but have a support contract with a supplier for.

There's no obvious pattern or reason for it and we've already raised the issue with the supplier's support team. In my mind, this seems to be a textbook case for having a problem record - repeated incidents logged for the same issue, therefore requiring root cause analysis. The problem may be ours, it may be the software, we just don't know. I can't see how we distinguish between whose responsibility it is to investigate when we don't know that? And even if it is the supplier's responsibility, don't we want to keep track of this too? We still have the problem, right?

Our Problem Manager, however, says that because we have supplier support for the software it's up to them to do root cause analysis and we can continue to log incidents, just not create a problem record to link them to because we can do no root cause analysis ourselves (but clearly we can examine our infrastructure etc.).

I think this just makes life unnecessarily complicated, but what do you ITIL experts think?

You must distinguish between managing the problem and solving the problem. Your's (your Problem Manager's) essential responsibility is to manage the problem. Who conducts the technical investigation into the underlying cause(s) - I don't believe in root cause analysis because it is a meaningless phrase - is whoever you (your problem manager) commission to do such work.

In this case it could be internal staff, your third party support organization, a combination of the two [there's that song title again], or first one and then the other according to how things go, who do the investigation.

The key point is that management (and control) remain within your own organization because you own the services - it is your problem._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

Fully agreed. Problem Management is about managing all IT problems in your organization, regardless of who 'owns' the problem. You should have a point of contact within your organization who is responsible for keeping the pressure on the external vendor and for keeping the problem record in your system up to date so all stakeholders can remain informed throughout the process._________________Manager of Problem Management
Fortune 100 Company
ITIL Certified

Just to add, if your supplier is not responding with appropriate responsibility of finding timely solution to problems, you may like to discuss the same with supplier and add it to the official agreement with them, next time you amend/renew the agreement.
==

The simplest answer is that there is no point in analysing beyond the level at which we have the capability to fix something.

The "root" (it is possible to go back further yet) cause of a faulty disc may lie in poor quality ore extraction processes, but you are unlikely to take this beyond your immediate supplier with whom you can negotiate warranties of quality - or you can change supplier.

Also, root cause implies one cause. But there are many examples of combinations or accumulations of circumstances being the cause and sometimes you will tackle one of these, but at others you will deal with a whole array. A system I was associated with was poorly performing and, fed up with sticking plaster solutions, I called in an expert. He identified 17 (!) ways to improve the performance and we implemented most of them. However we did not tackle the underlying cause at that time because it was the nature of the system design and we could not afford to replace the entire system any time soon.

I think the reason that ITIL introduced the term "root cause" was to emphasise that with complex systems (such as a mainframe as it was at that time or a network of interrelated systems) it was important to dig deeper than the superficially apparent cause which was often little more than a symptom. It is still important to do this, but many problems do not lend themselves to anything that could meaningfully be called "root cause analysis".

This is particularly true where the cause is related to people rather than system components. There is not a lot of deep technical analysis to recognize inadequate documentation or a lack of training or even poorly designed procedures as the relevant cause of some problems.

Therefore I prefer the term underlying cause(s) to emphasise a more than superficial approach, but not to exaggerate what is actually required.

Hope this helps. I've rushed it a bit, but I have gone over it a couple of times before either here or at LinkedIn._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718