Where to start
Not with software. Start by mapping the process as it actually runs — as it runs, not as the policy document describes it.
The gap between those two is usually large, and the gap is where the money is. An approval process documented as three steps may in practice pass through seven people, four of whom sign only for form’s sake. Digitising all seven is an expensive way to preserve a mistake. Removing the four redundant steps, then digitising the remaining three, is the work worth doing.
This phase means sitting with the people doing the work, not only with their managers. The people doing it know where it jams, and they have usually invented workarounds already — those workarounds point at the right design.
A phased roadmap
A three-year transformation plan with a single go-live at the end is a plan that will fail. Three years is long enough for the market to shift, for people to leave, and for the original assumptions to stop holding.
The lower-risk approach splits the work into phases where each phase is worth having on its own, even if the next one never happens. That forces the ordering question: do the part with the clearest result first, so there is evidence to justify the next investment.
It also helps politically. A project showing results after four months survives a budget cut; one promising results in three years does not.
System architecture
Architecture decisions are the most expensive kind to reverse later, which is why they deserve time up front.
The most important question is usually not which technology to pick, but where the boundaries between systems sit — what belongs to which system, and how they exchange data. Put the boundaries in the wrong place and every small change afterwards has to be made in several places at once.
Alongside that come the data questions: where the system of record lives, who may write to it, and which system wins when two disagree. Leave those unanswered and within a few years nobody knows which number is correct.