Information technology is complex, difficult to manage and a challenge getting people to use it. It can also be either a tremendous corporate asset or a huge drain on resources.
The value of IT to your business can be highly positive or negative. I've seen multi-million dollar investments that do little more than generate costs and tie up resources that are needed elsewhere. On the other hand I've seen systems that deliver value consistently and constantly.
Regardless of the system or systems you have or choose to use, how do you make sure it is a valuable asset?
Answer: Consider what you want from it BEFORE you start!
Let's say (for example) that your corporate financial department wants consistent and accurate cost reporting across all divsions, regions, etc. Of course there are solutions so that can happen, provided everyone else uses those systems. Everyone else must input consistent and accurate cost data. So now you ask, why should you the maintainer care? That's a great question. My answer is that you shouldn't care, unless there's something in it for you too.
Getting others in your organization to do what you want is much more than a matter of merely asking for or (worse) dictating it. Like any other request we put on our people, there must be something in it for them. Otherwise, why would they bother?
Along with the poor system matches to business requirements, the poorly executed system implementations, the ill-concieved, poor fit (or non-existent) business processes, the "user hostile" systems and other technology or process related reasons for failure, not providing value to all users is one of the biggest reasons for systems that fail to deliver, or even destroy, value.
I'm not talking about how you "sell" the new system to the users or how you carry out change management. Those are very important, but more so, the system must deliver value to all users. No amount of salesmanship will get you buy something you just don't need or want.
There needs to be an answer to the question, "what's in it for me?" The answer that works best is "it adds value for you, and here's how..." The answer can't be too far removed from the users. If the new system doesn't do something directly for your users like make their job easier, enhance the value that they perceive they add for the company, put more money in their pockets, eliminate some headache or problem that they want to solve, or some other direct benefit TO THEM, then your chances of gaining their buy-in and their use of the system to help you achieve your goals is diminished.
For instance: asking a mechanic (or any other trades-person) for inputs that don't get used to reduce failures on equipment won't get a lot of support. If they don't see the results - the reduced incidents of failure, they will see the system for what it is - a waste of their valuable effort. If you try to sell them on the capability of a system to deliver that sort of result, but you have no one on staff who can do the needed data analysis work (like a reliability engineer), then they will see through your smoke screen. They aren't stupid. If they know you can't, or won't deliver on what you promise, they will nod appreciatively and go about ignoring you.
So how to you avoid this? How do you make sure the system provides value added output?
Before you start, decide on the inputs needed to provide the desired outputs. It is that simple, but it is almost never done well.
Ask around and find out just how many reliability engineers were asked for their desired data inputs to be built into the system(s) that you are using today. Were your planners asked what they needed in order to plan more effectively? Did you hire the needed reliability personnel or planning personnel to take advantage of all those new features and system functionality? If not, then your company didn't choose success with its systems. I'd bet that there is some degree of dissatisfaction with your systems or the results they are not delivering.
Where does it all go so wrong?
Systems are selected to serve one function only (e.g.: finance) but not all. Systems are "user hostile" and difficult for casual users (i.e.: most of your workforce) to use. All too often there is a lot of focus on converting old (and often corrupt) data into the new format for loading into the new system. If the data was not used in the old system what makes you think you'll use it in the new one? Effort is put into loading vendor prescribed PMs into the system without adding the needed job planning to ensure they get done efficiently.
In one case recently hundreds of vendor recommended PMs were all loaded with the same due date, just to meet a project milestone. The project looked like it was on track and everyone was happy. Of course those PMs were never revised so shortly after the system went "live" the planners were overloaded with hundreds of PMs all due at the same time. No planning of those jobs had been done so not one of them was ready to issue as a work order. Needless to say, that system did not add value in their perception - it created a nightmare for the planners. The PMs didn't get done for a long time due to all the work needed to get them in a state where they were useful and failures that should have been prevented occurred. Production time was lost and value was destroyed along with the credibility of the system itself.
A good carpenter knows that it's best to measure twice and cut once. Unfortunately the IT world seems to have missed this. The laser sharp focus on the technology often results in a complete miss on the very practical things needed to ensure that technology delivers results.
A close friend who is an IT implementation project manager recently told me about some of the obvious "holes" in a large project he was managing. No one (from neither the client nor the contractor) had responsibility for maintenance planning of all the PMs, yet there was responsibility for loading them into the system. No one had responsibility for data cleansing before old records were transferred from the old system to the new one. No one had responsibility for linking parts data from the old system catalogue to the equipment on which it was used. No one had responsibility for hiring the analysis resources that were needed to get useful information from the data that would be collected. No one specified what reliability data was really needed to be collected. And so on...
Some of these problems are carry overs from past practices but no effort was made to correct them. The new system has little chance of delivering value.
No one stepped back from the technology coal face and looked at what the business really needed and of course, no one had responsibility for delivering business results. There was an IT deliverable, a process deliverable, certain milestone deliverables, reports, etc., but no one had responsibility for results.
Data is now being collected. Little of it is being converted to useful information and the only knowledge they've gained is the sad awakening that they are not particularly good at implementing major business systems that cross multiple functional boundaries within the corporation.
If you want to learn more and make knowledgable informed choices you will need good (accurate, timely, specific) information. To get that information you will need to collect some very specific pieces of data. To do that you will need to set your systems up so that that specific data can be collected consistently and accurately. It may or may not be the data that some systems are designed to collect "out of the box". The system you choose must be capable of collecting that data that your business needs, not data that someone else thinks you might need.
All this requires a great deal of foresight and careful thought. It requires effort up front, before you even select your system. It require careful selection and implementation. It requires the dedication of the right resources to the system implementation project. Token efforts and part-time resources rarely deliver the results you need. They are often preoccupied with their other "real" job so the system gets the short end of the stick almost every time.
That is a recipe for failure - at least, for delivering results that fall short (perhaps far short) of expectations.
It is not tough to get it right, but it does cost in terms of resources, effort and knowledgeable support up front. The IT system suppliers are a good source of help, but bear in mind that (despite their protestations to the contrary) they alway have an ulterior motive. After all, they make their money from selling system licenses and maintenance support contracts. They are IT experts, not business process experts. They are not independent professional advisors with the aim of solving management and business problems for you - they are professionals at IT.
Get the right sort of strategic level professional help. Get it up front, before you've committed huge human and financial resources. Measure twice, then cut. Plan your work effectively and then work your plan.
I challenged the US electric utility industry to do just this - understand what you want from all the data you collect so you can generate information and make informed choices. Read an article about that event as it was reported on the wire services:
http://finance.7online.com/abc?ID=3264978&Account=wabc&Page=NewsRead
