The role of the maintenance manager has been hijacked by software vendors intent on redefining their roles in terms of how their products will best benefit from it.
And that is fair I suppose. Every person has the right to take care of their commercial risks of course.
But there is a need to think a little deeper than the standard statements revolving around "get the job done", "collect asset data" and the rest of the corporate-speak terms you hear. (Don't you hate the word "strategic"? Seems to mean nothing...)
The primary role of the maintenance manager, in my humble view, is the management of failure.
Not the response to it, although that is important, and not the faithful recording of it; but the management of failure...
This means understanding the likely potential failure modes and putting in place strategies for their management.
Often this pushes people back to rambling on and on about data again, and there is some merit to that argument. But there is a need here to recall what has been termed the Resnikov conundrum...
This basically states that for historical analysis of failure to be accurate you need a lot of failure data, and to get a lot of failure data you need - failures!
And failures cost money, the kill or harm people and they impact on the environmental integrity of the assets being managed.
Not a very ethical way to do it is it?
As engineers we would all love to have oodles of failure data to make decisions with. Yet the reality is that the vast majority of decisions need to be made in the absence of data.
This is the primary role then of the maintenance manager. Building the failure management policies which can then be translated into maintenance processes, efficiency improvements, and data capture via proactive action.
Not ERP, not planning and scheduling, and not data management techniques...