> Too often modernizations fail because they look at the "on paper" process, which isn't what the workers are actually doing. Also software installations fail

> Too often modernizations fail because they look at the "on paper" process, which isn't what the workers are actually doing. Also software installations fail because management decide what they want and go shopping for it, the users are not really in the loop about what they actually need, and management is an interchangeable class of people who think they know management but have often never done the job they are managing. At the core of what you're saying about the "on paper" process is the fact that nobody does time-and-motion studies anymore. Systems analysts barely exist in 2025, largely because interchangeable people in management get interchangeable "solutions providers" in, and they build the only flow that fits their existing tool. A few years back I was hired to fix a bad web-based product for a niche-ish market (a niche within a standardised market) put together by rushed remote subcontractors who'd never talked to the client. I was handed the spec and told I was to implement it. So I implemented it to a certain point, and then (because my mother had worked in that field and I knew what annoyed her) I thought: Hold on, a core flow of this implementation is awful tiresome CRUD busywork and they will hate it within hours. I already hate it and I'm only testing it. So I argued to change the spec, suggested a better flow that better suited their needs (and allowed two use patterns — on-the-spot and at-the-end-of-the-day — which had different flow needs), and was told by the disconnected management: that looks good but we need to stick to our plan. So sure was I that a bunch of hard-working good-hearted people would curse my name that I "prototyped" it to show everyone, and they loved it. Because it wasn't just better and faster, it was instinctive and fun. They had already understood that they were going to quickly hate the thing built for them, but this they wanted to use. And then we put the prototype in production because it wasn't really a prototype at all: the job was so easy that the "prototype" was the solution. It was just something nobody had thought to offer because nobody listens. Upshot: incredibly happy end users who gained back lots of time, and also experienced so much less frustration that a subsequent feature improvement could be less rushed because they were able to spend a little more time on a process they didn't hate as much. I dread to think what this actively-not-listening development process will do to people when solutions providers just shoehorn AI in to solve anything they don't want to do a proper process for.