Acquiring and implementing new software systems can be a costly, labour intensive and, more often than not, demanding process. It is, therefore, necessary to watch one's steps, keeping in mind why you are changing. New is not always better.
A lot of people do not have time to learn and adapt to the old software before someone starts introducing another one. This notion is so common it has an expression: BOHICA (Bend over - here it comes again). This is a situation where employees time, and time again, gets exposed to new programs and methods, leading to despair and unwillingness to invest time in these systems - expecting it will be outdated soon enough.
There are a lot of consideration to take into account when acquiring new systems, but when all is said and done there are three questions you need satisfyingly answered before taking further action:
1) Is this a problem we need to solve?
How problematic is the problem? Is it even a problem? And if so, is it a costly problem? Does it take up a lot of time or lead to problems for your employees?
If none of these questions results in a clear need, the "problem" might be better left alone.
2) Does the proposed solution solve our problems?
Does the proposed software offer a solution to the identified problem? And if so, is it a good and efficient one? Are everyday-tasks problematic and time-consuming to solve in the new software?
If so, this just might not be the right solution for you.
3) Does the system cause new (and more massive) problems?
If you need months and months of training, resulting in new problems, it just might be a useless endeavour. There will obviously be some changes in the methods and tasks accompanying a change in software, but you should expect an overall net gain in productivity. Otherwise, the switch can end up as a "BOHICA"- turn, which is not a good thing.
Must one system solve all our problems?
Well, the short answer is no. One system to rule them all might end up both complicated and cumbersome. Even though extra functionality might seem nice at first, it can be a pain to utilise constructively.
It is better to first figure out exactly what you need to be fixed (and preferably why) and then obtaining a system that does just that. If it's not broken, why fix it? This goes for computer systems as well: if it doesn't make it easier why bother?
"We have a problem" - what next?
We here at Crescat are making a platform for concerts, conferences and cultural events, aimed at improving the lives of everyone involved in these productions. The next post will focus on the five reasons why you should have everyone involved in your production on the same platform. If you want to know more and be updated, please contact us or sign up for the newsletter. Stay tuned!
Matteo is one of the founders of Crescat and has experience with producing concerts and conferences before Crescat. If you want to know more about him, look here.