Anymore companies know that data and IT infrastructure has to be integrated into anything. But in some rural areas higher speed internet and infrastructure isn’t still available.
Actually, no…you made that statement and I have no idea how you got there from what I wrote.
STB chairman Patrick Fuchs has sent this letter to CEO Keith Creel asking for CPKC to submit their Service Action Plan to fix the IT integration issues and restore service levels back to normal:
CPKC has until tomorrow, June 20th, to respond to the STB’s request. We should learn more from CPKC’s response about the root cause of the problems.
Based on the rail service section of the STB’s website, it appears that the CP and KCS were operating as completely separate railroads with separate IT systems until the second week of May. STB’s website shows that KCS and CP were sending separate rail service data feeds to them two years after the merger was approved. KCS’ last rail service submittal was on 5/7/2025. CP’s was on 5/28/2025. CPKC’s new combined rail service data feed started on 5/14/2025 (see Surface Transportation Board).
Weekly average dwell time at KCS’ two biggest US yards in Shreveport, LA and Kansas City, MO ballooned from 34.5 and 15.3 hours on 5/7/2025 to 66.2 and 47.0 hours on 6/18/2025. Average train speeds dropped from 25.9 mph on KCS and 21.7 mph on CP as of 5/7/2025 to 19.1 mph for the combined CPKC US system on 6/18/2025. Each one mph decrease in system average train speed has very negative effects in terms of locomotive, freight car, and crew availability. So far as I can tell, there have only been minor impacts on the CP side of the railroad up to this point. The big concern here is that the congestion problems on KCS side of the railroad become such a large resource drain, especially with regard to locomotives, that the service problems start metastasizing to other parts of the system.
From that stat, it doesn’t appear that the KCS is slowing down CP but the reverse.
KCS was a faster average speed railroad than CP, according to the STB’s historical stats. I suspect part of that is due to the fact that KCS didn’t have to operate trains into or thru Chicago. There are also differences in traffic mix and train types that affect average speeds. And each railroad has its own methodologies for collecting and reporting this data. Comparing data between railroads quickly becomes an apples to oranges conundrum.
The number that concerns me most is the 2.6 mph decrease between CP’s last independent report and 19.1 mph figure reported on the 6/18/2025.
Where does the trouble lie and/or what could be the cause for such a drop?
Read the news story linked in my first post. Operations on the former KCS in TX, LA, and MS went into the ditch after KCS’ US operations got switched over to CP’s computer system.
Typically, IT issues and lack of employee training on how to properly use the new computer system causes problems with misrouted and “no bill” freight cars. When this happens the operating plan goes out the window. The IT system is what sets up and runs the plan - garbage in/garbage out. This in turn causes cars to accumulate in terminals as employees attempt to manually straighten out the mess. This in turn causes trains to get held out of terminals, which in turn causes traffic congestion along the line of road. It’s a vicious cycle made even more virulent by the fact that P$R roads don’t have the numbers of extra crews and locomotives on hand that they did before implementing P$R. There were 25-30% cuts in both categories, pre-COVID.
P.S. I’m just speaking in generalities here. I don’t have any inside information on what is specifically going on in this case and I’m not a railroader. I just know where all the performance metrics are located on the web. I’m waiting with bated breath to hear what Keith Creel and CPKC have to say about all this tomorrow.
I suppose Creel will give some generalities posing as answers.
Board Room Management rarely have any understanding of the clerical world and data that is required to make their railroad operate efficiently or for that matter operate at all. Every train is a data stream - defining destination location, load or empty, ultimate consignee, contents - HAZMAT or Clearance implicated instructions as well as freight charges
I am surprised the CPKC hasn’t been operating some kind of conversion program in order to state data in a format either of their legacy systems can utilize.
When I was working in the Chessie organization that installed ‘Terminal Service Centers’ at the major terminals, except Chicago. The process of taking that terminal from a manual paper based system with myriad of yard clerks to the TSC computerized form of operation it would routinely take a month to six weeks to get personnel trained and fully functional on their new job responsibilities. The manpower procedures to create the ‘new’ TSC would have all the ‘old’ clerical jobs abolished and all the new jobs advertised with the effective date as the cutover date. The reality was that on cut over day - the clerks would ‘ride’ their seniority displacement privileges’ waiting for things to ‘shake out’ and then let them to make their bump. Within the first week most all jobs would get filled with their permanent job holders. Each cutover was staffed with non-contract personnel to act as job trainers. At the start of the cutover what would END UP being a 15 minute job would take an hour or more with many incorrect actions being attempted - as the clerks became more proficient on what the system required and how to do the job efficiency increased.
What CPKC is actually doing - I have no idea.
CPKCS is solving this problem the same way every company has in the past throwing bodies and cash at the problem until they get it fix up properly. UP did it in 96 NS and CSX in 99 it’s called how many cubic feet of hundred dollar bills are needed and how much overtime you pay for.
CSX DID NOT throw bodies and money with the ConRail split. They got rid of the ConRail official that had been placed in charge of operations at the time of the split.
The ConRail guy had in his mind that ALL CSX terminals had the bloated capacities that ConRail facilities had - with his misguided ‘operating plan’ the entire property was brought to gridlock in relatively short order. Once he was given his walking papers and a CSX person that understood the CSX side of operations and could work well with the excess capacities that ConRail had the operations and metrics of CSX returned to a manageable situation.
The WRONG operating plan can bring a property to grid lock in short order. Those creating the Operating Plan always have to keep in mind the strengths and weaknesses of each terminal involved in the plan.
1 Like
Hence the second part all the overtime needed to fix the issues that people cause. CSX got it fixed fairly quickly as they found the problem. UP refused to admit defeat that closing the outer yards around Houston for a while. They did the same thing when they took over the CNW in 95 aka they acted like they were the Borg of all railroads and didn’t need to know what the old hands knew to keep the systems running smooth.
What was the problem was to try to integrate as a merger of equals. When I hear that phrase I divest in the companies. It’s a recipe for disaster.
One system and one system only needs to prevail. Operate two systems simultaneously if necessary for as long as is needed.
Delta’s acquisition with Northwest was seamless because everything moved over to the Delta way of doing things.
The NW people really grumbled at first but then they realized it worked!
UA and CO tried to do a merger of equals. It was a mess.
So was PC. Again tried to be a merger of equals.
Just don’t get arrogant. See whose system is best overall. It may be the acquired company.
CPKC’s service action plan filing was finally posted to the STB’s website this morning: https://dcms-external.s3.amazonaws.com/DCMS_External_PROD/1750688210397/309692.pdf
The pertinent section listing the primary causes of the IT problems are listed on pages 5 and 6:
(a) The interchange data provided by some connecting carriers for cars delivered to
CPKC at legacy-KCS locations did not support CPKC’s onward processing of
those cars without extensive re-work of the data;
(b) The transition on the legacy-KCS network from MCS to TYES led to difficulties
maintaining accurate railcar inventories for railcars placed or requested for pick
up at customer facilities, particularly at locations with complex trackage layouts,
in part owing to imperfect mapping of storage, team, and in-plant tracks used to
place railcars; and
(c) The new system data requirements post Day N and the resulting car inventory
issues created challenges for customers (many of whom were using the systems
for the first time outside of a training environment) during the billing and
releasing of railcars (i.e., placing orders for empty cars and directing the
movement of loaded cars), particularly for more complex billing permutations
that were difficult to replicate in a training environment.
I’ll post some other thoughts and comments once I have had a chance to read thru the document in detail.
TRAINS just posted this story on the News Wire:
Thanks. So helpful for someone to post factual information not just speculation no matter how knowledgeable the poster is in general on the topic.
1 Like
Just the types of problems to be expected in such a change.
I don’t really get the Interchange data issues as the data to be exchanged is defined by the AAR and has been for decades.
1 Like
Here is a crazy notion. What if the 1992 software systems of KCS and L&A were close enough that the IT back then was able to keep the L&A system with a fairly easy software patch? But bang! when CP tried to tie in the KCS the walls came tumbling down?
There you go. 
About the time of the cutover, UP sent out a message requiring the use of CPKC instead of KCS on interchange info sent to them.
About a month later, another message was sent out when CN finished integrating the Iowa Northern into their system. Same thing, use CN insread of IANR or it wouldn’t accept the data.
Jeff
I think Balt nailed it. All of the problems CPKC has encountered are the ones that should have been expected and accounted for. The planning and execution of the cutover has been an unmitigated disaster. Fortunately for CPKC, the amount of railroad affected is small enough that they should be able to recover relatively quickly. They still have to eventually cut over the operations in Mexico from MCS to TYES. It will be interesting to see if any of the lessons learned with the KCS-US cutover will be put into practice.
Related to my original concern that any large transcontinental merger could devolve into absolute chaos on a scale that would make the UP-SP merger look like child’s play, Bill Stephens posted this news wire story yesterday: