People are traditionally very good at relationships. Relationships with friends, loved ones and family are very well documented. Relationships with inanimate objects however, or even virtual objects as many regard software and production operations to be, perhaps less so.
People often tell me that they think I am in love with my car. When it was new, quite some time ago now, I would wash it frequently, make sure it was garaged when it was wet and cold outside, and generally keep it looking its best, applying lots of polish and resin to resist the elements. As time went on, this regime relaxed, but I continued to enjoy driving the car. I frequently compare in my mind, my car with others on the road. As time has gone by, most other cars seem to be newer than mine, but I know that mine has the performance edge on most, and certainly in my opinion, the looks, and pretty much everything about the car is, “as good as new”. I continue to justify my purchase decision in terms of what the car delivers for me, in terms of the price I paid.
There will soon come a time however when the car needs to be changed. Cars have a certain practical life expectancy, it cannot go on for ever. To be honest though, I cannot find a car that I like better than the one I have, no matter how liberal I imagine I could be with the budget. The arguments are there, the question of continued reliability, the fact that newer cars are safer and a lot more frugal with fuel. Am I “in love” with my current car, or am I just resistant to change?
The same relationship and questions can be asked about software. There is a similar momentum in ownership, defence of decisions made and justification for purchase. It may make it seem as though the “owner” of the system is in love with the software. Software developed internally especially can have a hugely greater “momentum”. Home grown manufacturing software often develops, like a child, growing up, as capability increases, with successive achievements. On the other side, critics will point out that there is a stagnation comparing the current system to the latest available in the market. Defenders will respond to explain that it is not just an issue of the software, but of the whole process that the software is working within. There is a huge cost to change.
As time goes on, it becomes necessary to modify expectations. Demands from the market, product technology and manufacturing technology change continuously. Systems need to be refreshed, if not, there can be severe limitation on agility and compliance, as well as threats to the fundamental metrics of quality, cost and on-time delivery.
The decision comes down to whether you wait for a compelling event to happen, which is normally quite negative and stressful, such as in my car analogy, it fails to start one morning when I am on my way to the airport, or, I create a positive compelling event through justification of a nice new car based on what is good for me.
To create a positive compelling event, being objective, I would:
- Continuously look for the Best Practice
- Compare the Current Practice to the Best Practice, as defined in the industry
- Understand the reasons for the differences, are they justified or not?
- What are the lost opportunities by not adopting the Best Practice?
- Look for the tools that drive me towards making the transition to Best Practice in terms of providing significant benefits versus any cost of change
It is so much more effective to make a controlled and planned change, rather than being driven by the failure of a key element of something that we rely on. It is the difference between “bringing success” as opposed to “dealing with failure”
What I love about the software that I work with, Valor MSS, is that there is continuous effort to provide the Best Practice in the industry, to create the most excellent operation, starting with design, the material supply chain, through to the end of the production process, creating the best working environment for each contributor to the “production engine”. In fact, this goes further with Valor. There is also the look forward to future challenges which may bring additional elements to create the Best Practice of tomorrow. Being passive, just automating current processes is not something that I could really respect. Being active, to invent software products that create solutions that in turn create the Best Practice of tomorrow, that is what it is really all about.
Your challenge for today – how do you see the operation in which you currently work, honestly? Are you executing the Best Practice? Are you “in love” with your current operation? Do you want to find out how to create that positive compelling event? Let me know………..