XKCD has a number of statements worth pondering about automation. The most directly applicable may be the table showing the trade off between cost of automation and time saved, https://xkcd.com/1205/
Note that that table is actually unreasonably optimistic since it doesn't include the time required to train people to use the automation, or the time spent maintaining it after first release. Or the delay in other tasks due to the resources being used to develop the automation.
But it does point out that the fact that something can be automated doesn't always mean it's worth doing so. In school or in research, elegance is it's own reward, but in business that isn't enough; it needs to be enough of an improvement to justify the costs.
This is especially true when there are other immediate priorities the company needs you to focus on.
Brainstorming better approaches is an excellent thing to do. Document the idea, come up with realistic costs vs. benefits estimates (remember that coding usually takes at least twice as long as you think it should, then add the other costs I mentioned) then submit the whole lot for prioritization.
The alternative is to ask your manager if you can carve out a bit of time in your work week for this and develop the first version as a "skunk works" personal project. Getting that permission may require working harder so all your current responsibilities continue to be met. Or you might put together a prototype on your own time to demonstrate the basics of the idea; one project I helped with started when the lead developer was out on sick leave and used that time to play with an idea.
If you can't explain it in a way that makes it clearly in the business's interest to invest in it, you probably don't understand it well enough yet.