The request usually arrives as a shopping decision. We need a system for scheduling, or for approvals, or for tracking who has been trained. Which one should we buy.
That is the second question. Software does not improve a process. It takes whatever process you describe to it and makes that version the one everybody has to follow from now on. The parts that were working stay working. The parts where people had been quietly improvising get frozen, and the improvising stops being possible.
The disagreement surfaces during configuration
Most implementations hit the same wall at the same point. Somebody has to say what happens after a request is submitted, and three people who have worked here for years give three different answers. One says it goes to the department head. One says it depends on the amount. One says they usually just handle it.
Nobody was wrong and nobody was hiding anything. The process had never been written down, so it had three versions, and the organization ran on whichever version the person handling it believed in. The configuration screen only accepts one.
This is not an implementation problem. It is the thing the organization did not know about itself, and it would have surfaced eventually. A software project is an expensive way to find it.
Write the current state down first
Before any of it, get the process onto one page. Not the policy. What actually happens, including the steps that exist only because of something that went wrong years ago.
Two things reliably fall out. Steps nobody can justify, which can go. And steps that three people describe differently, which need a decision rather than a system.
Make those decisions while they are still cheap to change. A disagreement resolved in a document takes an afternoon. The same disagreement resolved in a configured system takes a change request.
Then automate what is left
Whatever survives that is worth building. It will usually be smaller than what you started with, which means a smaller system, a shorter implementation and less to maintain.
The organizations that get the most out of software are the ones that did the unglamorous part first. They are not buying a fix. They are buying speed for something that already works.