1. Confirm the business reasons behind the project
Every implementation should start with a clear reason for change. If the team cannot explain why the ERP is needed, the project usually drifts into guesswork, rushed decisions and scope creep. For SMEs in Johannesburg, Pretoria, Durban, Cape Town and Gqeberha, the pressure is often the same: too many spreadsheets, too much manual re-entry and not enough time to keep orders, stock and finance aligned.
Before delivery begins, write down the 3 to 5 business problems the project must solve. Keep it practical. For example, faster invoicing, cleaner stock figures, better job costing or more reliable management reports. If a process will stay the same, note that too. It helps the delivery team avoid changing things that already work.
- List the main pain points in operations, finance and customer service.
- Set measurable goals such as shorter month-end close or fewer stock variances.
- Agree which sites, branches or departments are included in phase one.
- Confirm who signs off scope changes and process decisions.
2. Put the right people on the project team
ERP work is not just an IT task. It affects purchasing, production, sales, stores, payroll and reporting. A strong project team needs decision-makers, process owners and users who understand day-to-day work. At Bizmatics, projects are usually steadier when the client side has one accountable sponsor and a small core team with time carved out for meetings, testing and sign-off.
In South African SMEs, the danger is trying to run a project around normal trading hours without freeing anyone up properly. That leads to missed tasks, delayed feedback and frustration when the go-live date gets close. Make sure each person knows what they must do, when they must do it and how quickly they need to respond.
- Nominate an executive sponsor who can unblock decisions.
- Assign process owners for finance, operations, stock and sales.
- Choose super users who will test the system and support their teams.
- Set a weekly project meeting and keep minutes with action items.
3. Map current processes before anything is configured
Good process mapping saves time later. It shows where work starts, where it slows down and where people are repeating the same task in different systems. If the current process is unclear, the new system often ends up copying old problems into a fresh screen layout. That is why the project team should map each major workflow before configuration begins.
Use plain language and real examples from the business. Include approvals, exceptions, document flow and handovers between teams. For branches in the East Rand or West Rand, also note whether the process differs by location, especially where stock movement, credit control or delivery cycles are handled differently.
- Document the current process from start to finish.
- Mark manual steps, duplicate data entry and approval delays.
- Identify exceptions such as returns, partial deliveries and credit holds.
- List which reports or documents each team needs at each step.
4. Clean up data before migration starts
Data migration is one of the most common pressure points in an ERP project. If customer records, item masters, supplier details or balances are messy, the new system starts on a weak foundation. A proper data cleanup takes time, but it reduces errors after go-live and makes reporting far more reliable.
Start early. Check for duplicate accounts, missing VAT numbers, outdated pricing, inactive stock codes and incorrect unit measures. If your business operates from Centurion and serves customers across Gauteng or the coast, also confirm address formats, delivery zones and branch codes. Small data errors can cause invoicing problems, picking mistakes and poor stock visibility.
- Remove duplicate customer, supplier and product records.
- Check all opening balances, tax codes and payment terms.
- Standardise naming conventions for items, accounts and departments.
- Confirm which historical data must move and what can stay behind.
5. Test integrations, reporting and access controls early
Most SMEs use more than one system. Accounting, payroll, CRM, stock tools, scanners and approval apps often need to speak to each other. If integration testing is left until the end, the project can stall over simple issues like field mapping, user permissions or missing report fields. This is also the stage where managers discover whether the information they want can be produced in time for month-end or daily trading reviews.
South African businesses also need to think about practical conditions such as load-shedding, remote access and branch connectivity. If a team in Durban or Gqeberha must keep working during outages, the process should be tested under real-world conditions, not only in office hours when everything is online and calm.
- Test every required system connection before go-live.
- Confirm user roles, approval limits and access by department.
- Check standard reports, custom reports and dashboard fields.
- Simulate outages, delayed syncing and branch level transactions.
6. Prepare your people for change and go-live support
Even a well planned project can stumble if users are not ready. Training should start before go-live, not after. People need to understand what changes, what stays the same and where to get help when the pressure is on. A clear change plan reduces resistance and gives staff confidence when they move from the old way of working to the new one.
Make the support model known upfront. Staff should know who to contact, what kind of issue gets logged, and how urgent matters are handled during the first weeks after launch. In a busy SME, the first month can be hectic enough without uncertainty about support. If the business has branches in Cape Town, Pretoria or Johannesburg, also confirm which users need extra coaching because their work is more complex or time sensitive.
- Schedule role-based training before go-live.
- Share quick reference guides for common tasks.
- Define support hours, escalation paths and response targets.
- Prepare a go-live checklist for finance, operations and management sign-off.
Before delivery starts: a final readiness check
Once the main preparation work is done, use a final readiness review to confirm nothing important has been missed. This should happen before the project moves from planning into delivery. It is the point where the team checks whether the scope is clear, the data is ready, the users are named and the support model is in place. A short delay here is often better than a bigger delay later.
For SMEs, especially those balancing growth with daily trading pressure, the aim is not perfection. The aim is readiness. When the project starts on a stable base, the business can focus on adoption, reporting and practical results instead of chasing avoidable problems during the first few weeks.
- Scope signed off by the business sponsor.
- Core team assigned and meeting schedule confirmed.
- Data cleanup plan completed and owners named.
- Integration, reporting and access tests completed.
- Training dates and go-live support agreed.
