Are you suggesting that delay attribution is removed entirely? If so, where are the analysts (which already exist and are doing what you suggest they do) getting their data from within TRUST if it isn't attributed to a cause?
Yes. In the system I would rather follow, it does not need to be attributed to a cause.
I look at my systems (I know that you know how TRUST works, I'd probably suggest binning that and replacing it with something more 21st century too but even I have some sense of realism) and identify there is a trend of delays occurring at a certain time between x and y. That then allows me as the analyst to ask, why is that delay occurring disproportionately there? Is the timetable reliant on the train being booked for a DeLorean? Is there an exceptionally high passenger flow at a station causing increased dwells because it's just after all the offices kick out? Therefore, I am not wasting time trying to investigate the cause of minor delays which are statistically irrelevant and in the grand scheme of things do not matter.
A passenger falls over on the train, breaks their leg and causes a 55 minute delay waiting an ambulance. There is clearly nothing which can be gleaned from the delay attribution process in terms of reducing said delay in the future as it is a random act. However, the individual TOC can undertake a lessons learned exercise following the incident on an individual basis which can examine whether there is anything in *their* control which could have reduced the delay, such as quicker calling of 999 by the crew, link in with the safety investigation in respect of trip hazards or whatever.
Re the above two posts, my understanding is that if you are blaming Network Rail for a million quid's worth of delays (caused by their infrastructure) then that's an incentive for them to try and deal with the root cause of the problem - e.g. if it'd cost five million pounds to improve the power supply in an area where the TOC is getting a million pounds a year off Network Rail then someone has to make a decision over whether that's enough to warrant taking action.
Any large organisation would have different cost codes/ cost centres etc - given the money sloshing around the railway (ten BILLION quid a year from passengers, plus all of the support from various levels of Government), I think that we need to assess where the problems are so that we can fix issues - anyone who's ensured Cross Country will know that one minor problem can have severe knock on problems hundreds of miles away.
I suppose that one problem with all of this is that the inflexible nature of the railway means that, even if you identify a conflicting move that causes reliability issues, it might be very hard to amend things. e.g. if Stagecoach find that their bus route needs to be stretched by a couple of minutes at certain times of the week (whether that's rush hour or passing a busy shopping centre at weekends or whatever) then they can have a new timetable in operation six weeks later. But if you discover that a North Berwick - Edinburgh service crosses onto the ECML at Drem and therefore "checks" a southbound Cross Country service (which regularly accrues delays down the ECML and beyond, all the way to Plymouth) then that might take several months before a revised timetable can be implemented.
Look at it the other way round; if you didn't have people assessing where the problems lay then how would you assess where the root cause of problems actually lay (and start fixing things)?
You're of course correct, in a perfect world - but actually what happens is, let's say someone says, PC, go and look after the conductors at Smalltown Depot. I'm getting 260 minutes of delay each weekend as a result of my conductors being thumped by drunks on a Saturday night, that costs me x in delays, paying for additional policing will cost me y, telling my conductors to not delay the train will get me a dispute, so I'll just accept the 260 minutes of delay each weekend. Under the current system, there becomes incentive to sort the root cause of the problem out only if the delays cost more than the solution.
I'm all for spending some of the 'money sloshing round the railway' (we have been banned from ordering stationary, make what of that you will) but it is only worth spending that money on performance improvement measures if such measures actually lead to performance improvement otherwise you are just throwing money away which could be spent on additional customer facilities, safety improvements, god forbid, reduce ticket prices (call me cynical, but it will never happen).
I think from your last paragraph, you have misunderstood my proposed replacement. I propose having people assess where the problems lie, however on a broader scale. Using your example, my systems would flag up to me that there is a trend of delays being incurred and then I would use that information to ascertain the cause. Therefore instead of having spent my day ringing signalboxes to find out why 100 trains lost however many minutes, I can focus on the big issues which cause the most delays.
It's all quite a moot point, the railway is resistant to change and whilst the current system still works it's unlikely to change. For what it's worth, I'm actually a proponent of 'big data' use within the industry. If we have the data (eg delay root causes in TRUST) we should use it better. We have so many systems, but they all run independently of each other. Imagine a railway where you can bring up Speedy Trains' 1B09 and be able to identify performance, revenue, passenger numbers, safety incidents, defective equipment, customer experience trends, catering sales data where there's a Cafe Bar, whatever else we keep, all from one dashboard - when we look at everything together, how much is that train making us or costing us and how can we make it more profitable?
Case study: A station manager receives feedback from staff telling her that there is a fare evasion problem at the station. In deciding whether there is a need for extra revenue support she could look at such a system and the dashboard for Anytown Central would show them how many delay minutes have occurred on trains around said station due to ticket irregularities from TRUST, the proportion of revenue gained off the flow vs passenger numbers recorded to identify areas where fare evasion may be endemic from revenue MI systems and TOC records, staff assaults on station staff and conductors due to revenue protection issues from SMIS, customer feedback from whatever CRM systems get used. I've no doubt other systems are used to hold data too.