Equipment Time Entry

"Every site is aware of the project." That's what I was told before I started calling them. The first site I reached told me, "This is the first time I've heard of this."

For a consultant, that sentence feels like realizing you are standing in a minefield. A stranger calling from corporate about a system that will change how a site accounts for every hour its equipment runs is exactly how field crews learn to resent a rollout before they've ever seen it. Whatever I said next would be that site's first impression of the entire effort. Nobody had planned for me to be the face of the project. I was anyway.

Rewind to March 2019. A former colleague, by then an executive at a North American coal producer, brought me in to help design a piece of software. The company was halfway through building a company-wide equipment time-entry system, Excel interfaces in the field feeding into JD Edwards, their ERP, as the system of record, for capturing when and how every machine on every site got used. The project was dragging, and he couldn't get the data he needed out of his own operation.

Equipment time sounds like a small thing to build a company-wide system around. It isn't. At a mine, equipment time is where the money lives. Every hour a dozer or a haul truck runs gets coded to what it was doing, and cost accounting, maintenance planning, and production reporting all hang off those codes. When time entry is late or wrong, an enormous operation steers by guesswork.

The reality is I came in thinking they needed someone to help architect a solution. Then I spent about a day on site with the people implementing the project, and a different picture emerged. They had a working strategy. What they needed was legwork, some site-specific knowledge, and a whole lot of improved communication. So rather than opening with here's-how-I'd-do-this, I asked the more useful question. What do you need?

One of the big holdups turned out to be something I'd done before, mapping disparate equipment codes. Pretty much every multi-site miner runs into this the moment they try to unify their data systems. The sites' time usage models don't share tagging systems or hierarchies, so someone has to figure out exactly how each code was meant to be used, and more often than not how it was actually used, before the data can merge into a single source of truth. And the mapping is only half of it. It leaves you a change-management problem, making sure people on each site understand the new system, that what they used to code as X is now Y while over here Z is still Z. None of this is rocket science. But it's a lot like rocket fuel. If you don't put the effort in, nothing is going anywhere.

The reason the mapping is so tedious is history. At every site I've ever been to, the records started on paper, people wrote down whatever they wrote, and when the operation eventually went digital the new system took free-entry text. That data is never clean. The same dozer shows up as D22, D-22, dozer2, and just plain 22, and on and on. Ferreting that out by hand across hundreds of codes is miserable, and this is where a programming and data background earns its keep. Back in my MISOM days, one of our sites had a project sitting on thousands of PLC tags, and the operator eventually scrapped it, because at the time nobody had thought to automate the finding of similar tags. The problem was simply too big to brute-force. It stops being too big when the machine does the first pass. You can pull the unique values, run similarity searches that surface tags close to each other without exactly matching, and turn a problem nobody could hold in their head into a stream of small, fast decisions. So that's what I built, Python scripts that proposed matches as each site came online, with me judging the edge cases a script can't call.

There was a second audience for all this care. Because the system of record was JD Edwards, the project was largely driven by engineers on the accounting team, and if you know one thing about accountants, know that they care about the accuracy of their data. So verification was a first-class part of the work. For each site I pulled the aggregate reports the operation already ran on, recreated them under the new mapping, and checked that the numbers matched one to one. A migration like this has a lot of people who need to get on board, the accountants, the financial analysts, the operations people, the engineering managers, and every one of them needed to know the data coming out was right.

Which brings me back to the phone calls. Every mapping had to be verified by the people who used the codes, so site by site, I picked up the phone. You already know how the first call went. It wasn't the only one like it. That's a communications failure with teeth: rollouts die on site skepticism, and the merger had already given every site reason to wonder what corporate would change on them next. I couldn't fix that a stranger was their introduction to the system, but I could control what kind of introduction it was. So I led with their operation instead of my project. I asked how they ran their equipment and what their codes really meant, and I listened. I'm a miner; we spoke the same language. By the time a site's mapping was verified, the system wasn't a rumor from corporate anymore. It was something being shaped around how they worked, with a person attached that they'd talked to. Then I carried what I heard back to the developers and translated in both directions. The beachhead was never in anyone's plan. Once I realized I was it, I made it count.

Like all good engagements, this one ended with me working myself out of a job. The mapping stopped being the bottleneck, the first sites came online clean, and I left them back on track, confident they could finish the rollout themselves. The merged company got one language for equipment time, and my former colleague finally got the numbers he'd been missing. He'd brought me in to help design software. What his project turned out to need was a miner who could code, and who knew what to say to a site that had never heard of him.