Why the big system project fails and the small one does not
Most operational projects fail because they were too large to stop. Keeping the first piece small is a commercial decision, not a technical one.

The pattern is familiar to anyone who has been running a business for a decade. A significant system project is scoped. It takes longer than planned. Somewhere around month seven it becomes impossible to say whether it is working, and equally impossible to stop, because too much has been spent to walk away.
The project rarely fails because the technology was wrong. It fails because it was structured so that finding out required committing first.
Sequence beats scope
The useful question at the start is not how much of the operation we should fix. It is how quickly we can find out whether this approach works at all, and how cheaply we can be wrong.
That points at one process, or one location. Small enough that stopping costs almost nothing. Real enough that the result is not a demonstration but an actual number from actual work.
Name the number first
Before anything is built, the result should be written down in a form that can be checked. Hours returned to a named team. Enquiries recovered per week. Support contacts per order.
This is uncomfortable, which is why it usually gets skipped. A project without a stated number can never be shown to have failed, and that is precisely the problem. It can also never be shown to have worked, so it survives on opinion and momentum instead of evidence.
Build on what is already there
Replacing working software is expensive, slow, and almost never the reason a process is broken. The broken part is usually the gaps between systems, the manual relay steps, and the handoffs that depend on somebody remembering.
Building around what your team already opens every morning keeps the risk low, keeps the training cost near zero, and keeps you able to walk away.
Then expand only what worked
Once the number moves, the same pattern extends to the next process or the next location, with the argument already settled. Once it does not move, it stops, and the total cost of finding out was one small piece of work rather than a year.
Both outcomes are acceptable. That is the point. A project you cannot afford to stop is not a project, it is an exposure.
This sequence, friction first, then a small pilot, then a measured expansion, is how we run every engagement.
Does this look like your operation?
Tell us the problem