How to choose an ERP in Morocco

Start from your processes, not from features

The first mistake is comparing feature lists. Almost every ERP can produce a quote, an invoice or a stocktake. What sets them apart is how they follow your real workflows: who approves an order, above what amount, how a partial delivery is invoiced, who may change a price.

Before meeting a vendor, describe two or three representative journeys end to end, for example from customer request to payment, or from purchase order to supplier payment. Note the roles, approvals and documents at each step. That description becomes your evaluation grid.

Standard, configurable or custom-built ERP

Three approaches are common in Morocco:

• Standard packaged software: a widely used product with little adaptation. Quick to start, it fits when your processes are close to common practice.
• Configurable ERP: a shared foundation configured around your organisation (workflows, permissions, documents, modules). Often the right balance for an SME with a few specific needs.
• Custom development: software built for you. It matches your needs, but takes more time, budget and maintenance.

The right question is not "which ERP is best?" but "how much of the way we work is truly specific?". If very little, a standard product is enough. If it carries your competitive edge, it deserves to be configured, or even built.

Cloud (SaaS) or installed on your servers

As SaaS, the ERP is hosted by the vendor and billed by subscription: no server to run, regular updates, access from every site. Installed on your servers, it leaves you in control of the infrastructure, but backups, security and updates are yours to handle.

To decide, ask three questions. Where is the data hosted, and does that suit your clients and your obligations? Who runs the backups, and how quickly can data be restored? How do you get your data back if you change solutions?

Local configuration

An ERP used in Morocco must produce documents consistent with your accounting: currency, VAT regime, company identifiers (ICE, IF, RC) on invoices, document templates and numbering.

Do not settle for "yes, that's handled". Ask to see an invoice and a credit note produced by the tool, and have your accountant validate the configuration before go-live. Also check how the vendor keeps up with regulatory changes.

Assess the full cost

The list price does not tell the whole story. Compare offers over three years by adding up:

• the licence or subscription, per user or per module;
• implementation: scoping, configuration, data migration, training;
• changes and support: change requests, new features, assistance;
• your teams' time during the project, which is often forgotten.

A low quote with a vague implementation often costs more than a higher but detailed one. Ask for a written scope, deliverables and success criteria.

Access rights and traceability

An ERP concentrates sensitive data: prices, margins, customer balances, payments. Check that you can define precise roles (who sees what, who approves what), that sensitive operations are logged (who changed a price, who cancelled an invoice) and that access is easy to remove when someone leaves.

Data migration and integrations

Data migration is the most underestimated step. Customers, items, suppliers, opening stock and outstanding balances must be cleaned before they are imported. Plan who does it, and by when.

Also list the tools to connect: accounting software, bank, online shop, business tools. Ask how the ERP exchanges data (exports, API) and who maintains those connections.

The most common mistakes

• Deploying everything at once instead of starting with the priority modules.
• Choosing on a generic demo, without running your own journeys.
• Underestimating data migration and user training.
• Leaving access rights for later.
• Involving the accountant only after go-live.

A five-step method

1. Map two or three real business journeys, with their roles and approvals.
2. Shortlist two or three solutions and ask each for a demo of those journeys.
3. Compare the three-year full cost and the written implementation scope.
4. Run a pilot on a limited scope, with success criteria set in advance.
5. Roll out module by module, measuring real use before extending.