Choosing ERP and Business Software

A practical course for owners, managers and project leads in small and mid-sized businesses who are choosing major business software. You will learn to recognize when you have outgrown your systems, understand the main types of software, map processes, build a business case, write scenario-based requirements, shortlist vendors and partners, run scripted demonstrations, score options, compare total cost of ownership and negotiate contracts. It closes with implementation governance, data migration, testing, training, go-live and a selection roadmap.

Course structure

• Module 1: Do You Need New Software? (4 lessons). Signs you've outgrown your systems, types of business software, process mapping and the business case.
• Module 2: Requirements and the Market (4 lessons). Writing requirements, shortlisting vendors and partners, focused RFPs and scripted demonstrations.
• Module 3: Decide and Contract (4 lessons). Scoring and selection, total cost of ownership, contracts and negotiation, and the implementation approach and partner.
• Module 4: Implement and Get Value (4 lessons). Project team and governance, data migration, testing, training and go-live, and the roadmap after go-live.

Interactive labs

• Which system usually handles it?: Match twelve business functions to the type of system that usually handles them in an SME: accounting or ERP, CRM, or a warehouse management system. Then check your answers.
• Comparing shortlisted options: Place seven options from a fictional software selection on a grid of fit to requirements against total cost, to see which deserve the final round.
• Five-year total cost of ownership: Enter users, subscription price, implementation fees, internal time and other annual costs to see one-time costs, recurring costs, year-1 cost and total cost of ownership.

How it works

• Work through 16 short lessons at your own pace. Each has key takeaways, an exercise for your own workplace and a quick knowledge check.
• Try the three interactive labs as you reach them in the course.
• Pass the 20-question final exam (70% or higher, unlimited retakes) to unlock your Chmltech certificate of completion.
• Free, with no sign-up. Your progress is saved in this browser.

Most SMEs start with accounting software, spreadsheets and email. That works until growth, complexity or customer expectations outpace it. Knowing the warning signs helps you decide when new software is worth the cost and disruption.

Common signs

• Re-keying: the same order, customer or product is typed into several systems or spreadsheets.
• No single view: nobody can quickly say what is in stock, what is on order or what a customer owes.
• Reporting takes days: month-end and management reports are assembled by hand.
• Errors and rework: wrong prices, missed orders, shipping mistakes and inventory that never matches.
• Key-person dependence: critical processes live in one person's spreadsheet or head.
• Growth limits: new locations, product lines, e-commerce or customer requirements, such as lot traceability or EDI, can't be supported.
• Unsupported software: the current system is old, unsupported or no longer secure.

Software is not always the answer

Some problems come from unclear processes, untrained staff or poor data rather than the software itself. A new system on top of a broken process automates the mess. Before shopping, ask whether better use of current tools, cleaner data or a fixed process would solve the problem.

What this course covers

This course walks through the full path: understanding needs, building a business case, writing requirements, shortlisting, running scripted demonstrations, scoring, comparing total cost, negotiating contracts, choosing an implementation partner and preparing for a successful go-live. It applies to ERP and to other major business software, such as CRM and warehouse management systems.

Before choosing, understand what each type of system does and how they fit together.

Suite versus best of breed

A suite offers many functions from one vendor on one database: fewer integrations and one source of truth, but some modules may be weaker than specialists. Best of breed combines specialist systems, such as an ERP with a separate CRM and WMS: deeper functions where you need them, but more integrations to build and maintain. Many SMEs choose an ERP suite and add one or two specialist systems where their needs are demanding.

Cloud versus on-premises

Most new SME software is cloud-based (software as a service): subscription pricing, vendor-managed updates and security, and access from anywhere. On-premises software runs on your own servers: more control and possibly lower long-term licence cost, but you handle hardware, updates and security. Cloud is the default for most SMEs today unless there is a specific reason otherwise.

Examples of SME-focused systems include QuickBooks, Sage, Xero, Acumatica, Microsoft Dynamics 365 Business Central, Oracle NetSuite, Odoo and SAP Business One; there are many others, including industry-specific options. These are examples, not recommendations. The lab after this lesson asks you to match functions to systems.

The most common selection mistake is shopping for software before understanding the business's own processes. Vendors then lead the conversation with their features rather than your needs.

Map the core processes

Map the main end-to-end processes as they work today, with the people who do them:

• Quote to cash: enquiry, quote, order, fulfilment, invoice, payment.
• Procure to pay: requisition, purchase order, receipt, supplier invoice, payment.
• Plan to produce (for manufacturers): forecast, plan, materials, production, quality.
• Inventory: receiving, put-away, storage, counting, picking, shipping.
• Record to report: month-end close and management reporting.

Swim-lane maps work well: one lane per role or department, showing handoffs, systems used, spreadsheets, approvals and waiting.

Mark pain points and improvements

On each map, mark re-keying, delays, errors, workarounds and missing information. Then sketch the future process: what should happen, with which system doing what. Some improvements need no software at all; others become clear requirements.

What makes you different

Identify the few processes that are genuinely unusual or give you an advantage, such as complex product configuration, special pricing or unique compliance needs. These deserve the closest attention in selection. For standard processes like payables, adopting the software's standard way of working is usually cheaper and easier than customizing it.

Process maps also become the backbone of your requirements and the scripts for vendor demonstrations, covered later in the course.

New business software is a significant investment of money and staff time. A business case clarifies why you are doing it, what success looks like and what you can afford.

What the business case covers

Measurable goals

Write goals you can check after go-live: "month-end close in 5 working days instead of 12", "inventory accuracy above 95%", "eliminate re-keying of orders", "same-day order confirmation". They guide every decision during selection and implementation.

Budget realistically

The subscription is often not the largest cost in the first years. Implementation services, data migration, integrations, training and the time your own staff spend can each be substantial. Internal time is the most underestimated cost: key users may spend a large share of their week on the project for several months.

Funding

Some government programs support technology adoption by SMEs, including planning and implementation. Check the Funding page on this site, and confirm current eligibility and terms directly with each program before relying on them.

Requirements describe what the software must do for your business. Good requirements make vendors show what matters and make comparisons fair.

Prioritize

• Must have: essential; a system without it is unacceptable (for example, lot traceability for a food distributor).
• Should have: important but workable without, or with a workaround.
• Could have: nice to have.

Keep must-haves genuinely essential. A list of 300 must-haves makes every vendor look the same and hides the few requirements that decide success.

Write scenarios, not just features

A feature list ("supports units of measure: yes/no") invites every vendor to tick yes. A scenario shows how it really works:

"A customer orders 10 cases of product A. We buy it by the pallet of 40 cases and sell it by the case or by the each. Show how the order is entered, how inventory is reduced in the right unit, and how the invoice shows the correct unit price."

Cover all requirement types

Build requirements from your process maps and pain points, with input from each department.

With requirements in hand, build a long list of possible systems and narrow it to a shortlist of three or four for detailed evaluation.

Building the long list

• Systems used by similar businesses in your industry and size range.
• Recommendations from peers, industry associations, your accountant and advisers.
• Industry-specific systems, which may fit unusual needs better than general ERPs.
• Review sites and analyst reports, read with some skepticism.

Narrowing to a shortlist

Screen the long list against a few knock-out criteria:

• Covers all must-have requirements, at least on paper.
• Suits your size and complexity: neither too basic nor built for much larger companies.
• Has a capable implementation partner or vendor team in your region or time zone.
• Fits your budget range.
• Has references in your industry.

The partner matters as much as the software

Many ERP systems are sold and implemented by partners (resellers) rather than the vendor directly. The same software can succeed or fail depending on the partner's industry knowledge, team quality and approach. Evaluate the partner alongside the product, and meet the people who would actually work on your project, not only the sales team.

Check references early

Ask each shortlisted vendor or partner for two or three references from similar companies that went live in the past few years. Call them and ask what went well, what they would do differently, how the partner handled problems and whether the project stayed on budget.

A structured request helps you compare vendors on the same basis. For SMEs it should be proportionate: clear and focused rather than a hundred-page document.

Request for information (RFI) or proposal (RFP)

An RFI is a short questionnaire to narrow a long list. An RFP asks shortlisted vendors for a detailed proposal and price. Many SMEs combine them into one focused document.

What to include

• Company overview: what you do, size, sites, users, growth plans.
• Current systems and the problems you want to solve.
• Scope: processes, modules, integrations and data migration.
• Requirements, with must-haves highlighted and key scenarios.
• What you need back: how each requirement is met (standard, configuration, customization, add-on or not available), implementation approach, team, timeline, pricing for software and services, support model and references.
• Your timeline and how you will evaluate responses.

Ask how, not just whether

Ask vendors to classify each requirement as standard, configured, customized, third-party add-on or not met. A requirement met only through customization or an add-on carries more cost and risk than one met as standard.

Pricing in a comparable format

Give a pricing template: users by type, modules, subscription per year, implementation services by phase, data migration, integrations, training and support. Without a template, proposals price different scopes and can't be compared.

A standard vendor demo shows the software's best features with perfect sample data. A scripted demonstration makes vendors show how their system handles your processes, using your scenarios and, ideally, your data.

Preparing the script

• Pick 6 to 10 key scenarios from your process maps and must-haves.
• Provide sample data: a few real products, customers, prices and orders.
• Specify what you want to see step by step, including reports and exceptions, such as a partial shipment, a return, a price change or a backorder.
• Send the script two to three weeks ahead so vendors can prepare.

Running the demonstrations

• Give each vendor the same script and time.
• Involve the people who will use the system: sales, purchasing, warehouse, finance.
• Ask "show me", not "can it?". If they say it can, ask them to show it now or in a follow-up.
• Note whether each scenario was shown as standard, configured or "we would customize that".
• Score each scenario immediately after it is shown, using a common scorecard.

Watch for

• Screens that switch to different products or add-ons not in the proposal.
• Workarounds that look simple in a demo but would be tedious daily.
• How easily users could find their way: count the clicks for common tasks.

The lab after this lesson asks you to compare shortlisted options by fit and cost.

A structured scorecard turns many opinions into a defensible decision.

A weighted scorecard

Agree the criteria and weights before the demonstrations, so they are not adjusted to favour a preferred option afterwards.

Who scores

Each evaluation team member scores the areas they know. Discuss large differences between scorers: they often reveal a misunderstanding or an important concern.

Beyond the numbers

Use the scorecard to inform the decision, not to make it mechanically. Close scores call for a final round: a follow-up demonstration of the weakest areas, a site visit to a reference customer or a short paid workshop to test a critical scenario in more depth.

Due diligence on the winner

• Check the vendor's and partner's financial stability and how long they have supported the product.
• Confirm the product roadmap and how upgrades work.
• Review security certifications and where your data will be hosted.
• Call at least two more references.

Comparing first-year subscription prices can mislead. Total cost of ownership (TCO) adds up every cost over a realistic period, usually five years.

TCO components

Example

Twenty-five users at $110 per user per month is $33,000 a year. Add $60,000 of partner fees, $25,000 of internal time and $6,000 a year for add-ons and support. Over five years, TCO is about $280,000, or about $190 per user per month: much more than the subscription alone suggests. The lab after this lesson calculates TCO for your options.

Questions to ask about pricing

• What are the user types, and which roles need full versus limited licences?
• How much can the subscription rise at renewal?
• What is included in support, and what costs extra?
• What happens to price if users or modules are added or removed?

The contract sets your rights for years. Review it carefully, ideally with a lawyer experienced in technology contracts.

Software subscription terms

• Term and renewal: length, automatic renewal and notice periods.
• Price protection: caps on increases at renewal.
• Users and modules: how to add or reduce them, and minimums.
• Service levels: uptime commitments, support response times and remedies.
• Data: you own your data; where it is hosted; backups; security obligations and breach notification.
• Exit: how you get your data back in a usable format, and for how long after termination.

Implementation services terms

• Scope: a clear statement of work listing deliverables, assumptions and what is excluded.
• Pricing model: fixed price, time and materials, or a cap; how changes are priced.
• Team: named key people and how replacements are handled.
• Acceptance: how deliverables and go-live readiness are accepted.
• Payment milestones tied to delivered results, not just elapsed time.

Negotiating

Leverage is highest before you sign. Common negotiable items include multi-year price caps, implementation discounts, extra training, a ramp-up of user licences during implementation, and favourable payment timing. Be wary of deep first-year discounts that disappear at renewal. A fair deal that keeps the partner motivated is worth more than squeezing the last dollar.

How the system is implemented matters as much as which system you choose. Settle the approach and the partner's role before signing.

Implementation approaches

Methodology

Many partners use a structured method: discovery and design, configuration in iterations, testing, training, data migration, go-live and support. Ask to see the plan, the deliverables of each phase and how decisions are documented. Look for a method that shows you working software early, rather than only documents.

What a good partner brings

• Experience in your industry and with businesses your size.
• A named, stable team including a project manager and functional consultants.
• Willingness to challenge requests for customization and recommend standard practice.
• Clear communication about risks and changes.
• Post-go-live support and ongoing improvement.

Your side of the bargain

Partners configure software; your team owns the processes, decisions, data and adoption. Projects fail most often on the customer side: key users without time, slow decisions and poor data. Commit your people before you start.

A software implementation is a business change project, not an IT project. Its structure should reflect that.

Key roles

Free up key users

Key users are usually your most knowledgeable staff, which is exactly why they are busy. Plan backfill, temporary help or reduced responsibilities so they can spend real time on the project. Without them, the system is designed by people who don't do the work.

Governance

• Weekly project meetings with the partner: progress, issues, decisions.
• A monthly steering meeting with the sponsor: budget, timeline, risks and major decisions.
• A decision log and a change request process, so scope changes are deliberate and costed.
• A risk and issue register with owners.

Resist customization creep

Each request to make the new system work exactly like the old one adds cost and complexity. Ask "what business result does this deliver?" and prefer changing the process to changing the software, unless the requirement is truly what makes you different.

Moving data from old systems into the new one is often underestimated. Bad data in a new system undermines trust from day one.

What to migrate

• Master data: customers, suppliers, products, prices, bills of materials, chart of accounts.
• Open transactions: open sales and purchase orders, open invoices, inventory balances.
• History: decide how much is needed. Often summary balances or a few years of history are enough, with older data kept accessible in an archive.

The migration cycle

1. Extract data from old systems and spreadsheets.
2. Cleanse: remove duplicates and inactive records, fix errors, standardize formats.
3. Map old fields and codes to the new system's structure.
4. Load into a test environment.
5. Validate: check record counts, totals and samples with key users.

Repeat the cycle in two or three trial runs before the final load at go-live.

Start cleansing early

Data cleansing is business work, not IT work: someone must decide which customers are inactive, which products are obsolete and which prices are correct. Start months before go-live. It is the best time to clean up years of accumulated clutter.

Reconcile at go-live

Plan a cut-over: when old systems stop taking transactions, how final balances are loaded and how inventory is counted. Reconcile opening balances, open orders and inventory against the old system and have finance sign off before trading starts in the new one.

The weeks before go-live decide whether the first month is smooth or chaotic.

Testing

Test exceptions as well as the normal path: returns, credits, partial shipments, price overrides, month-end.

Training

• Train by role, using your processes and data, close to go-live.
• Provide short reference guides and recorded walkthroughs for common tasks.
• Have key users act as first-line support for their colleagues.

Go-live readiness

Hold a go/no-go decision with the sponsor against clear criteria: critical tests passed, data validated, users trained, support in place, cut-over plan rehearsed. If key criteria aren't met, a short delay is usually cheaper than a failed go-live.

Hypercare

Plan intensive support for the first weeks: partner consultants available, daily issue meetings, quick fixes and extra staff for slower processing. Expect productivity to dip temporarily while people learn.

Go-live is the start of getting value, not the end of the project.

The first months after go-live

• Stabilize: resolve issues, fix data errors, refine reports.
• Measure: check results against the business case goals, such as close time, accuracy and order cycle time.
• Adopt: retire old spreadsheets and workarounds; check that people use the system as designed.
• Improve: plan a second phase for features deferred from the first, such as advanced planning, portals or automation.

A typical SME roadmap

Durations vary widely with scope, complexity and how much time your team can commit.

Selection checklist

• Processes mapped and pain points agreed.
• Business case with measurable goals and full-cost budget.
• Prioritized requirements with scenarios.
• Shortlist of three or four, with partners evaluated.
• Scripted demos with users and a pre-agreed scorecard.
• Five-year TCO, references called, contract reviewed.
• Key users committed and project governance in place.

The Digital Automation for SMEs course helps place software selection within a wider digital plan, and Data and Dashboards for SMEs helps you get value from the data the new system collects.