Critically, still running visually on her machine, and with internal resources for lifecycle support if the process changes.
That's such an elegant and perfect solution. She keeps track of what's happening, it all runs through her GUI so worse* case scenario she does it herself again, and she can get help if/when she needs it.
* actual worse case would be the script going berserk, but as she's not the one who wrote it, she should be shielded from the blame if that ever happens
Sometimes the reason things aren't automated is because there isn't anything more valuable for that person to do so automation doesn't have a positive return on investment.
> because there isn't anything more valuable for that person to do
I've seen an interesting shift post-COVID where (remaining) ops workers are often more coordinators of / responsible for their area of responsibility.
Which is a distinction because in that sort of job, not having Task X leads directing into finding something else you can be doing to improve your area.
Sometimes it’s about the journey and not the destination.
The point being that the "I" is also flexible -- an existing employee fooling around to learn automation whenever they have downtime is much cheaper than hiring a consultant.
Sure, the automation is worse and delivered more slowly. But you can get automations from a lot of people in parallel, plus you're upskilling your workforce.
Growing up, my mom performed a job where she would essentially copy car crash data from one system into another, row by row. As a teenager learning to program, it was obvious to me this could be easily automated. She (perhaps rightfully) didn't want to run anything I cooked up on her company's computer!
A year or so later she was laid off a long with many others in the company performing similar roles.
And this is the problem, isn't it? Once the job is automated, the analyst is no longer necessary. You really need to "learn to fish."
I once had two guys arguing next to me about how it was impossible to produce a simple report about VM storage utilisation in under a month. I produced the report, printed it out, and shoved it in their hands just to shut them up while they were still busy arguing. A “month” of work required five joins.
The comment you're replying just explained why this is not "basically a JOIN." There are two unrelated systems (not SQL databases) which don't expose any APIs to the analyst.
Stop being so helpless.
A dilemma I keep facing in practice is converting a text that someone else has produced in their own special way, like the ghastly cluttered HTML from a word processor. For example, do I attempt to use a Perl script to automatically convert some of the mark-up, or do I throw away all the mark-up and put back the italics by hand, with the risk of making a mistake? (If anyone knows of a good configurable or modifiable tool for converting cluttered HTML into sane HTML/XML I'd be interested to hear about it. My Perl scripts for doing it are not great.)
[0] We'll still sometimes get an entire office of telephone help-desk people who are all convinced that $1/megabyte is the same as $0.01/megabyte, or whatever that story was a few decades back (I can't Google it any more to find it, there was a recording of the phone call).
I may be off by a factor of 10.
* Understand both the cost of making a mistake and of the process not running. Be aggressive on things that are 'nice to have' or have downstream manual re-validation. Be conservative on things that are 'must have' and immediately effect an outcome.
* First, do not harm -- program defensively and break execution on any violated expectations
* Understandable error messages at the user level are gold. The user has no idea what "schema mismatch" means. They can understanding "Column 3 had unexpected value. Was expecting 'X'. Saw: 'Y'"
--
On ugly HTML, that's a bad one, because of how ugly it can get.
I've only done toy work with it, but I hear good things about Beautiful Soup (Python). https://beautiful-soup-4.readthedocs.io/en/latest/
From your bank employee example, it looks like your solution would be to open the bank's internal tool to her excel instance, have it somewhat find the right records and inject the right value, while checking the listed codes. That looks like a series of APIs if they care about data exposure, or huge CSV exports that they need to then track ?
And as it seems to be important enough to warrant verification, it means your program is not some random batch, it needs significant validation.
Then picture the internal tool changing its output format. Reports getting categorized differently because of organizational change. New fields being added to follow new legislations. The tool could break at any of these changes, and the lady's left with a broken system except a lot of money has been invested, it's supposed to have solved her problem, she might not have the same access to data she had before the integration, and overall the situation could be worse than before.
That feels like a bleak scenario, but it happens all the time as well.