You're assuming that the cost of human capital actually matters in big corporations. As someone who has worked for several Fortune 100s and a couple of government agencies, I assure you, that is not the case. Employee time is treated as having no value, and things that damage the efficiency of employees are not relevant.
I once saw a "cost saving" round prohibit our team's QA engineer from getting a new SoapUI license (we were supporting an API!). It took three five-person meetings to get official approval to buy a $100 license - at a human capital cost of thousands of dollars. Not an eye was blinked at this absurdity.
Along the same lines, I once saw a lead architect go through the same nonsense to get a $100 Adobe Acrobat license (at a government agency). He said to me "It's easier for me to spend $100,000 dollars than to spend $100". He could have asked for a couple of new heavy-duty Unix servers with Oracle, and gotten it approved easily. But Adobe Acrobat? No, that's waste!
It works in the other direction, too. I've seen (and been in charge of) a depressing number of projects that spent hundreds of thousands of dollars' worth of people's time on writing an in-house replacement for a piece of software that cost, at most, tens of thousands of dollars.
My working hypothesis is that management types don't really think the costs are comparable, because licensing fees are an operating expense while in-house development costs are a capital expense. Which is true, but I imagine in-house development is a tricky thing compared to other capital expenses, since the final product generally has zero market value.
It is absurdly easy to burn through thousands of dollars worth of employee time. Call something “review”, “emergency”, or simply discuss the colour of the bike shed. Everyone has an opinion on that.
Now invite all sorts of heads, leads, and other important people. Done.
I did consider setting up a mock meeting just to make that point. Let’s see.
Maybe the world has changed now, but around 2006/2007 I was an embedded software engineer for a company that built public transport smart-card ticketing systems.
I was working on a device that sat on a bus, operated by the driver. It had a monochrome screen with something like 640x480 resolution and around 16 or 18 buttons.
One of the things the bus drivers needed to do was to sell tickets, but the number of buttons they needed to press to sell a ticket was like 10 or 12 when I started working on the software.
I explained to our project manager who was in charge of the delivery that I could improve things to reduce the number of button presses to around half that amount, and it be much more usable for the drivers.
She told me very sharply that I was never allowed to improve the software in any way by my own decisions. The only kind of improvements to UI/UX (which was not even a term back then) was after the customer requested it, because then my company would try to file it as a "change request" rather as a "bug" because that way they could squeeze more money from the customer.
The flip side of that argument was that the company all too frequently would accept a loss on the main contract in order to win the bid (working in the public sector and all), and then have to earn money on all the change requests. It was one of the specific responsibilities of a project manager back in those days to drum up as many change requests from the customers as possible.
It was horrible and I'm glad I don't work there any more, but I can sympathize with the problems from both sides of the aisle.
You have to careful with this. Things that sound like good ideas to the programmer can often be bad ideas for the user.
Case in point: a customer (we do embedded design services) came to us to redesign a manufacturing tool and mentioned that it was used both in the US and Costa Rica. We suggested adding Spanish language screens because, well, it lets more people in Costa Rica use the device.
Problem was, the users pushed back because knowing English got them more money and they could be replaced by cheaper Spanish-only speaking people if we added the translations.
To the point of making money on the ECO's, the problem is that if all your competition is structuring their bids this way, then you have to do the same if you're to have a hope of winnning anything.
In a company of that size, there's literally nobody who would be receptive to such an argument.
End users don't really matter, because they're not in charge of these decisions.
Their managers have a bit more clout, but they're almost certainly not in charge of the vertical that writes the enterprise apps, so they're still not really in charge of these decisions.
Developers writing in-house apps are swamped, both by incoming requests and by paperwork and suchlike. There just aren't enough of them to be able to spare the resources to worry too deeply about UX. Besides, none of them is actually a UX person.
Their managers have limited budget, and can't afford to be allocating resources toward UX. They're worried about their own bottom line, and increased costs due to poor UX invariably come out of someone else's budget.
Whoever's in charge of in-house development cares about these things in only the most abstract of ways. They definitely don't care about individual apps and projects; they're just allocating the resources they get. Which aren't many, because in-house development is a cost center.
The executives in the C suite probably exclusively hold the power to re-allocate budget toward a more optimal solution, but they really, really really don't care about these things. As they shouldn't - the actual dollar cost associated with any inefficiency due to sub-optimal in-house app UX is probably way too small to be worth their attention.
As someone who wrote internal software for a fortune 100, probably all of them. EDIT: When I first read your question, I thought you meant 'which companies?', now I realize you're asking who to talk to within a given corp. The answer to that probably boils down to 'whoever is getting bribed with kickbacks from enterprise software makers'
The people who set the requirements for my biggest project tried to massively expand them about 2 weeks before the end of the project, then tried to bury it after we instead focused on polishing UX and debugging for those 2 weeks. Several years later I hear it's still in use internally and the users refuse to migrate to a third party solution despite pressure from execs who probably want kickbacks.
Giant corps have no idea what the difference is between usability and number of features.
It drives down costs at scale when you can amortize the UX work over many users. A lot of enterprise applications, are built for a small number of users so it doesn't amortize as well.
Most of the time it is either a small number of users, or it is not used that frequently.
Since developers/designers probably cost more than the end-users of the application, most businesses consider it OK to push that cost to the actual user.
Once people become accustom to using a piece of software, it doesn’t matter. I witnessed this first hand, we wrote software for field service techs running on old Windows CE based ruggedized devices. The techs could navigate through the Windows with the keyboard, 5 deep without waiting on the screens to catch up.
Training is already a line item and comes with the cost of the software. "Good" or "easy" training isn't valued as compared to the feature checklist, and it never will be. Unless the buyers of the software are accountable to the users of it, not the other way around, nothing will change.
I once saw a "cost saving" round prohibit our team's QA engineer from getting a new SoapUI license (we were supporting an API!). It took three five-person meetings to get official approval to buy a $100 license - at a human capital cost of thousands of dollars. Not an eye was blinked at this absurdity.
Along the same lines, I once saw a lead architect go through the same nonsense to get a $100 Adobe Acrobat license (at a government agency). He said to me "It's easier for me to spend $100,000 dollars than to spend $100". He could have asked for a couple of new heavy-duty Unix servers with Oracle, and gotten it approved easily. But Adobe Acrobat? No, that's waste!
See also "bikeshedding".