There are three cases for a task that takes a regular human 5 minutes and a computer programmer 5 hours to automate:
1 The task is very complex, this means that there's a lot of room for human error. A well-tested and specified program will reduce this fragility and improve predictability.
2 The programmer is inexperienced, the programmer either is not a very good programmer (yet) or is using tools that he is not familiar with. The 5 hours mostly go into the learning process of the programmer, not in the task itself.
3 The task is simply something computers are not very good at, or hasn't been fully explored. For example speech recognition. The 5 hours go into exploring the domain, creating something reusable that the world could profit from.
In my opinion, it's always worth it, isn't that nice?
4 The task requires interacting with a system that was not designed with automation in mind.
For instance you have a third party GUI which you don't have source to that you have to push a button on based on what it is showing you. So you wind up having to research this, work around it, etc. Often you can use a GUI test kit to solve it temporarily, but that is going to be fragile - on the next upgrade it will likely break.
In this case automation may not be worthwhile. What you're learning is not connected with what you do. The automated solution is more fragile than the human one. The time saved is not that important.
Great if you implemented the thing with the GUI that you have to interact with. Not so great if it comes from a third party.
Even if your people did implement it, depending, getting rid of the GUI might be easier said than done. I remember an Access app that I had to automate stuff around. In the end the best solution to all of the different popups that were buried in their app was to make the machine it was on remotely accessible, and have a watching process page someone if it took too long. A human would then look at the screen, and press the appropriate button.
Yeah, I worked with something like that about 10 years ago. We had an ETL process that involved like 20 Access macros manually triggered in sequence (click, wait, click, wait...over several days per cycle). I converted this entire process to a Perl script that would be pointed at the raw data directories, clean and process the data and throw it into the DB. Access was taken completely out of the equation. It took a few months, but I was an IT guy who had never programmed before and had to learn Perl at the same time.
1 The task is very complex, this means that there's a lot of room for human error. A well-tested and specified program will reduce this fragility and improve predictability.
2 The programmer is inexperienced, the programmer either is not a very good programmer (yet) or is using tools that he is not familiar with. The 5 hours mostly go into the learning process of the programmer, not in the task itself.
3 The task is simply something computers are not very good at, or hasn't been fully explored. For example speech recognition. The 5 hours go into exploring the domain, creating something reusable that the world could profit from.
In my opinion, it's always worth it, isn't that nice?