It worked out for me until a got hospitalized for weeks and the college who took over my tasks figured it out. I did the same two more times and leard a lot about refactoring bad architectures. I jumped ship an sold myself as the guy who automates processes. Now I can refuse doing boring manual tasks. It makes me really satisfied.
It didn't take me long to start editing the HTML document directly to skip the physical work (someone before me had figured this much out, but hadn't been able to teach anyone else well enough to pass it along when he left, just a vague rumor that it had happened). Then I went ahead and made a crude script to edit the documents automatically, ultimately turning an hour long job into a 2 minute one with cleaner looking results. Ended up spending a lot of time at that job just watching TV.
My next job after that was all about automating manual processes, but with less down time since I was automating other people's jobs, rather than my own. I think I preferred the former.
I personally think the biggest benefit to every company would be to drill into people's heads how software should automate your day to day work. Software people think that way, but most employees don't.
Many years ago there was a post on an obscure online forum about some guy who hired virtual assistants do to 100% of his work for him for a tiny, tiny fraction of his salary. I don't remember the details, but he would basically go to work and do nothing all day. After a while he started staying at home, and no one at his company even noticed.
As someone who's interested in this kind of work, do you have any advice?
I do not know anybody doing consulting/contracting here in Germany, it seems to be an uncommon thing. I wish I would know how to get into it.
What is the ROI?
What is the cost of the current process (time, money, resources, FTEs, etc)?
What is the cost to implement (time, money, resources, FTEs, etc)?
What will be the maintenance cost?
What is the risk of implementing this?
What is the risk of not implementing this?
Once you have all this take it to your manager or your manager's manager or the business manager this affects.
I think one major issue is that manual processes often don't really "hurt" managers, they hurt the people doing them. To a developer or ops admin, "This $badthing caused by a typo won't happen again if we automate this" sounds very reasonable but sometimes managers just see it as a mistake that someone will need to be more careful about. Once they've factored the turnaround time into how they estimate they don't seem as interested in speeding things up. All that seems exacerbated by reactionary/feature driven mindsets which makes any kind of improvement that doesn't have an external event/person driving it very hard to get slotted. This seems to be made worse if you're working with a manager that's never really done the work that the people they're managing do or they did it so long ago they don't have an intuitive understanding of how it works today.
Another one is that a lot of people who perform a manual process for a long period of time become invested in it and defensive of it. No matter how much faster or better it is and no matter how involved they are if they end up feeling threatened it's probably dead in the water. Pretty typical human nature thing I think but at a big company with a lot of old established manual processes this can slow automation efforts down to a glacial crawl. Even if there's only one person that fully understands it I don't think managers appreciate the risk of having all of your eggs in one basket.
Eventually things do get automated but it seems like it's driven by a disaster or politics more than anything else. And sometimes not even disaster seems to be enough to drive real change if someone isn't pursuing it.
If anyone has tips on how to deal with any of this I'd love to hear them.