Mistakes 1 and 2: tools before problems, and no owner
The first is starting from a tool: "we need an ERP" or "we need AI" before anyone has named the actual problem. You end up with a system full of features that does not match what the team does each day. Start by writing the problem as one sentence, such as "quotations take three days to reach the customer", then look for a tool that fixes that.
The second is having no owner. A project that every department co-owns often ends up owned by nobody. Name one person with the authority to decide and accountability for the business result, not only the technical side, and free up their time from regular duties so they can actually do it.
Mistake 3: the big bang
Switching every system on one day sounds decisive, but the risk is high. A single fault can stop the whole company, and there may be no easy way back.
The safer route is small steps. Pick one department or process as a pilot, learn from it, adjust, then widen. Let the old and new systems run side by side for a while so you have a way back if something breaks.
A system half the company uses every day beats a perfect one nobody opens.
Mistake 4: ignoring the people who will use it
Front-line staff know how the work really happens, including the shortcuts and the reasons that never made it into the manual. If a new system is designed without asking them, expect resistance or a quiet return to Excel and LINE groups.
Bring real users in during design, give them a prototype to try, listen for where they get stuck, and train them using their own work data rather than generic slides. UX research with internal staff matters as much as research with customers.
Mistake 5: moving messy data into the new system
A new system does not clean old data by itself. If one customer exists under three names, product codes do not match, or key fields are blank, you just carry the same problems into a more expensive home.
Before migrating, audit the data quality, decide what to discard and what to fix, and assign an owner for each data type. Check PDPA too: personal data that is no longer needed should not travel along.
Mistake 6: measuring numbers that look good but mean little
Vanity metrics such as registered users, features shipped or number of dashboards look fine in a report but say nothing about whether the business improved. Tie metrics to the problem you named at the start, for example time from order to delivery, how often staff re-key the same data, or how many customers ask for a status update.
Measure before the project starts as well. Without a baseline you cannot tell whether things got better or just feel better.
Mistake 7: no run budget, plus a checklist
Many organisations budget to build a system but not to keep it running, even though hosting, subscriptions, bug fixes, changes as the business moves and people to look after it all cost money. A system with no run budget decays quietly until it becomes the next legacy system, to be replaced in a few years.
Set an annual run budget, as a sensible share of the build cost, when the project is approved, and decide who is responsible for upkeep. Before you start, try this checklist.
- Can we state the problem in one sentence?
- Is there one owner with authority and time?
- Is the rollout in small steps with a way back?
- Were real users involved from the design stage?
- Is the data to be migrated clean enough, with owners?
- Do metrics tie to the problem, with a baseline taken?
- Is there a budget and a team for after go-live?
Key takeaways
- Start from a problem you can state in one sentence, not from a tool name.
- Appoint one owner who has authority to decide and time to do it.
- Roll out in small steps with a way back, not a one-day switch.
- Involve the people who use the system, and clean data before migrating.
- Measure against the problem and budget for running the system after launch.
FAQ
Related services
Have a project like this in mind?
Tell us where you are today and we will suggest a sensible first step, with no obligation.
Talk to us
