Part of it is "clarifying ideas". But I think there's another important part:
Clarifying processes
I'd wager that the vast majority of businesses have no idea how their internal processes actually operate, what steps they take, what steps are already automated, what steps are not automated but could be, and what steps don't seem like steps but are actually super-important parts of the overall process.
I'm not an expert in the domain, but a few employers ago I worked for a company that was heavily involved in Six Sigma. Yes, it was a management buzzword. In many cases it was probably being used wrong. Or was being applied in a manner orthogonal to the problem. Or...any number of other things.
But one thing we studied in our "off time" (the company was a focused membership organization - we had magazines, conferences, everything) was how to apply 6S to our own business (you'd think that would have been done from the beginning - you'd be wrong). One thing we looked into, and attempted to understand and apply, was business process mapping.
That is - everything (and more) that I noted above - in various forms of flow-charting and other process mapping diagram systems, mostly done by hand, as it was easier for multiple people to see the processes and reason about them. Once we had things relatively "tacked down", we would convert those over to an electronic form.
It was an interesting exercise, and we never completely finished it before I moved on (the company went belly up soon after I left, as I was the only SWE left - it wasn't a large business). But we did notice in the exercise some interesting things:
1. If your business process flowchart looks messy, and can't be "untangled" - there are problems with your process.
2. Similar to #1 - if the flowchart looks unbalanced, even after untangling, there may be issues with the process as a whole.
3. Process flow lines that cross should be avoided; usually this is just a result of how things are arranged, but if you re-arrange things and still find a lot of criss-crossing lines, and can't make them not cross - again, issues may be there.
4. Soft processes are real processes - and trips things up. These are things where you might do something "out of the loop" or talk to somebody about something - but it doesn't seem like a real part of the process - but if it weren't done - the whole thing would break. Usually, these kinds of things aren't uncovered until one or another party leaves, either permanently or while "on vacation". Sometimes, the issue doesn't appear until some automation is put in that leaves that soft-process out, or unintentionally goes around it - then it can stick out like a sore thumb. Identifying these processes - and they can be difficult to identify, as sometimes even the person doing it doesn't know they do it, as you talk to them about their role in the overall process. You have to watch them do it.
This last one - there's a story I once read, I'll condense it as best as possible:
A woman brings her car into the shop complaining that the vehicle isn't running well after driving it a while. She gets in it to go to work, and at first it's ok, but within a mile or so it doesn't run very well. She doesn't know what is wrong. The mechanic looks at it, starts it up, it seems like it runs well. He tries it in the morning, everything is ok. He calls the owner and she comes into the shop and gets her car, but returns the next day complaining that it is still running strange. The mechanic asks if he can take a ride with her, to show him the problem. She says sure, they get inside the car, and as he sits down in the passenger seat, he sees her pull out the choke and hang her purse on it. It turns out that her previous car had a special pull out "hook" for just that purpose, and she didn't know. After the mechanic explained the problem, she had no idea, but the problem was fixed. No charge.
Ok - showing my age a bit there, and it's a somewhat contrived story - but the point is there: A process can be so ingrained for a single individual (or even within an automated process) that it is forgotten that it is needed (or shouldn't be done - depending on the situation) that it is overlooked when automation, or even just "process mapping" is done.
This can lead to interesting problems - and sometimes they can be hard to understand unless you are "in the driver's seat" so to speak.
So, that's also part of the job of a software engineer - figuring out these processes. The problem is for many if not most companies, they don't even know what their processes are, because they never actually planned them. More often than not, they mostly grew organically, and evolved, and quite often if you attempt to process map (physically graph) these processes, you'll find the many of the issues I noted above stand out. You'll find omissions and inefficiencies all over the place. You'll find redundancy (and sometimes, this redundancy is there because if it is taken out - things break in weird ways - figuring out how to restructure things to fix this can be a real challenge).
You'll find you're dealing with an organism more so than a machine.
Automating such a thing can be an exhausting challenge even for a proper team of developers...