At Commit Works, we’ve spent nearly a decade building and implementing integrated planning and short term interval control (SIC) software to bridge the gap between monthly plans and the work done by frontline teams.
The hours we’ve worked with teams on mine sites have given us a comprehensive understanding of the challenges facing operations and the results that they need to achieve. Throughout the years we’ve watched mining companies invest significant amounts of money and time with consultants, software companies and internal teams to develop solutions to this problem – in most cases, they have run into dead ends.
We’ve written this article to share our insights and guide you through the reasons this kind of project often fails to deliver a useful tool to the team at the frontline.
Why are they falling short? Let’s take a look at the three approaches we’ve seen used, which try to build tools for frontline planning and scheduling and short term interval control (SIC) on mine sites around the world.
The MOS consultant approach
Almost every mine we’ve been on has a set of whiteboards, spreadsheets or paper tools for planning, doing, checking and acting on site. Most of the time these were developed and implemented during a Management Operating System (MOS) project.
In one project we recently helped on, the mine had over 65 spreadsheets stitched together with pivot tables and macros. No one on site really knew how all these were supposed to work together and when one thing stopped working the whole system was broken. A massive amount of time was wasted on this operation in pre-planning, planning and lock-in/commitment meetings in the quest for a plan everyone could agree to – and most weeks the plan was wrong within hours of starting.
Spreadsheets and whiteboards developed by MOS specialists, even if they continue to be used on an operation, require considerable manual work in order to keep them going. Their biggest failing, however, is in their inability to produce real cross-functional/integrated planning and scheduling. This is not a safe or reliable way to coordinate a mining operation, and it doesn’t have to be the case.
In-house IT approach
Sometimes, mines or their head offices choose to go it alone, using an internal IT team to build a solution for the sites. Some of these are successful at delivering useful tools to the front line to meet the particular needs of that mining operation.
However, three things are difficult:
- The tool is normally very specific to one operation so can’t easily be used on other operations in the group. This means the whole development cost is covered by one site.
- In-house projects are often plagued by issues around product design, software integration, scope creep and change management. Many are ultimately left unfinished following changes in organisational structure or redundancies in the company. This is because effective software in this space takes years to get right and many corporate IT departments don’t last that long without change.
- To continue to provide value to an operation, certain support infrastructure and people need to be employed. We have heard of mining companies employing customer success and DevOps teams to look after the software they have built in-house. This can last for a while but recently we have seen these teams being disbanded by new leaders looking to save head office costs. In these cases, sites are left with an unsupported system that no one knows how to fix or improve.
Software mashup approach
Often a number of systems are pulled together into an uncomfortable collaboration, or a systems integrator is brought in to create a “system of systems” for work scheduling and production reporting. They might bring planning and Short Interval Controlsystems with them to implement in the operation, or they may work with a software company to build a customised solution for the specific need.
A recent example in North America saw no less than six software and consulting organisations engaged to collaborate and deliver a planning and Short Term Interval Control solution. They experienced all the integration and “turf war” issues you would expect and, in the end, spent over $14m to deliver something that can now be bought off the shelf from one vendor (us). The team involved in this work were made redundant recently, so the sites have a system without the support they need and the system is, as far as we know, likely to be replaced.
Another angle on this is the “wrong tool forced to work”. For example, it has been suggested by some that “mining is just like maintenance” so you should be able to set up standard jobs in SAP and schedule them using Prometheus to enable frontline planning. Although there have, no doubt, been some successes in plant environments, where the majority of work is maintenance work, it is very hard to get frontline mining teams to use SAP for this kind of planning. You have to look very hard to find a real mining operation where this toolset has been able to provide frontline teams with a shift plan to deliver each shift.