SunTech SolutionsPublished · SunTech Solutions
Why these projects go wrong
An internal management system, the kind sometimes called an ERP, replaces the spreadsheets, chat groups and memory that a growing business runs on. The idea is simple: one system, one version of the truth. The projects that fail rarely fail on the code. They fail because the business tried to build everything at once, because the old data was never cleaned, or because the people who would use the system every day were not asked what they actually do. The checklist below is what we settle with a client before a line is written.
1. Pick the one process that hurts most
Do not start with "an ERP". Start with the process that costs the most time or causes the most mistakes: usually orders, inventory or scheduling. Build that first, use it for a few weeks, and only then add the next module. A system that handles one process completely is worth more than one that handles five processes halfway, and it is live months sooner.
2. Map how the process works today, honestly
Sit with the people who do the work and write down every step: who starts it, what gets typed where, which spreadsheet is updated, who gets emailed, what happens when something goes wrong. The written procedure and the real procedure are rarely the same, and the system has to match the real one. This map is the single most useful document in the whole project.
3. Find out where the data lives
List every place the information currently sits: spreadsheets, the accounting package, an old database, paper, a chat group, someone's phone. Decide which of these the new system will replace and which it will connect to. Anything that will be imported needs cleaning first, and that takes longer than anyone expects. Duplicated customers, products with three spellings and prices that were never updated all have to be resolved before migration, not after.
4. Decide the source of truth for each kind of record
For every kind of record, customers, products, prices, stock levels, staff, decide which system owns it. If the accounting package owns customers, the new system reads from it rather than keeping its own copy. Two systems that both think they own the same record will drift apart within a month, and you are back to double entry.
5. Work out who needs to see and do what
Write down the roles: warehouse staff, sales, office, management, maybe suppliers or customers. For each role, what should they see, what should they be able to change, and what must they never see (margins, salaries, other customers' orders). Permissions are easy to build in from the start and painful to retrofit.
6. Name the reports people will actually open
Every system promises dashboards; most are never looked at. Ask each manager for the three questions they ask every week ("what is shipping today", "what is overdue", "what is low in stock") and build exactly those. A report nobody asked for is a cost, not a feature.
7. List what it has to connect to
Accounting, payment processing, email, shipping carriers, a web store, barcode scanners, label printers. Each integration is work, and some systems do not expose their data at all. Know the list before quoting; it changes the price more than any screen does.
8. Plan the documents it has to produce
Quotes, invoices, purchase orders, packing slips, pay stubs. Collect a real example of each, in both languages if the business works in two. Automatic documents are one of the biggest time savings a system delivers, and they only come out right if the current ones are copied exactly.
9. Decide where it runs and who looks after it
A web-based system runs in a browser on any computer or phone with nothing to install, and can be hosted in the cloud or on the business's own server. Either way, someone has to own backups, updates and access. Settle this before launch, along with what maintenance costs after the project ends.
10. Plan the first week, not just the launch
Run the old process and the new system side by side for a short period, with the people who mapped the process in step 2 as the first users. Train in small groups, in the language each person prefers. Expect to change a few things in the first week; a system built from the real process needs small corrections, not large ones.
The checklist
- One process first; the rest later.
- The real workflow written down, by the people who do it.
- Every place the data lives today, and which will be replaced.
- Data cleaned before migration.
- One owner for each kind of record.
- Roles and permissions defined.
- Three questions per manager, built as reports.
- Integrations listed before quoting.
- Real examples of every document.
- Hosting, backups, maintenance and a rollout plan settled before launch.