Greetings and Salutations,
There’s a great story from my journeys that symbolises the base theme of my topic today.
Out at a manufacturing plant, there was a problem that required resolution. It seemed that a particular line that inserted the light globes into the carton sleeves would occasionally insert an additional sleeve onto the line empty. The problem was that the timing was fine, and the rest of the production was perfect … Until the packed boxes reached the retailers who would have to ask for refunds for the 8-13% of empty tubes that made it out.
So, management requested a solution from the engineers. “Help us solve the issue and save us the $300,000 year this issue is costing us.”
So, the engineers went away, they looked at the problem from a hundred different angles and researched the latest and greatest razors edge technologies and came up with an AI interfaced x-ray scanner and robotic arm that would identify the empty tubes and remove them from the line.
They presented their solution to the board, along with a production implementation cost proposal of $420,000.
Besides the usual factors of high upfront capitol budget, extended ROI and downtime for installation, the major factor for rejecting the solution was due to being outbid on the solution by a factory floor worker.
The innovative line worker installed a small fan on the side of the belt that blew the empty tubes onto the floor – total cost of $12 up front capital for the fan and running operational costs of approximately $30-40 a year in electricity.
We sometimes get lost in the technology rather than the solution.
This is often the case in arguing a case for any form of work we aim at the corporate decision makers. We focus on the tighter integration, faster processing, integrated usability … but we never answer the key issues of the problem.
Sometimes the best solution is not IT. Heresy? Perhaps.
We need to take a step backwards and re-think the problem, the endpoint requested solution and then match a technology to fit this scenario – if required.
There have been a plethora of projects that I have worked on that would have been better served by a structural re-organisation, business process re-engineering or even a re-evaluation of the core business requirement.
On the flip side of the coin, when a technology project is the way forward, then regardless of the current technology sets already in-house, your process should include a full evaluation of the products available on the market that match the endpoint solution criteria.
Sometimes you’ll find that a product that is not part of your “standards” will do the job perfectly – other times, you can put pressure on your current vendor to provide the missing functionality that other packages offer, you might even find that your standard vendor offerings are the best options after all. Your due diligence requires that you explore every option and perform a full comparison evaluation … further evaluation upon conducting a cost/benefit analysis on each of the options will assist you in finalising the business case and the final proposal.
However, the final straw should always be on the solution – you can justify anything to the board (and the accountants) if you can line up the solution with each of the spoken (and just as important, the unspoken and/or implied) requirements, show the business value (i.e. not the processes per second but the % per year operational saving) and the all important ROI.
Just some food for thought …