There are two triggers for invoking the problem management process: a) an observation that a process is not within spec, or failing, without a known cause and b) there’s a value to the business in finding and eliminating that root cause.
The earlier the process is invoked the better, ideally before an incident occurs (proactive PM). For those incidents with enough degree of impact that condition b) is satisfied and an unknown cause, it’s desirable to start PM while the incident team is working to restore. The restoration activities are likely to cloud the data to make finding cause difficult or impossible, so some capture of the conditions while the incident is still live is helpful. This may be true of lower impact incidents too, particularly if they repeat frequently enough to cause significant overall disturbance.
Running the activities in parallel is easy provided you have designed the processes together. If the teams are separate and do their own thing, then some confusion and conflict is inevitable. Let’s remember that ITIL has never prescribed that we should have separate problem and incident teams. There is little or no evidence supporting the efficacy of separation (or of combining the functions). What ITIL says sensibly enough is that there are two processes to follow; my suggestion is that some degree of integration is helpful. Here’s how an integrated process can work:
