There is no single best ERP for Saudi companies, and any page that names one without first asking about your business is selling something. What there reliably is, is a best ERP for a company like yours - and in this market the variables that decide it are unusually legible. Your size and transaction volume. Whether you run one legal entity or several. How much genuine manufacturing, project or supply-chain complexity you carry, as opposed to complexity inherited from processes nobody has revisited in years. And how well a platform meets a set of Saudi regulatory obligations that no international feature matrix scores at all.
This guide is the shortlist-building half of that decision. It sets out five company profiles and what each should be looking at, the local criteria - e-invoicing integration first among them - that eliminate candidates faster and more decisively than functionality does, what an implementation genuinely costs and what actually drives its duration, and the mistakes that turn a sound choice into a failed programme. We resell nothing, hold no reseller or distribution agreement for any platform named on this page, and take no commission on anything we recommend. That is the only reason this guide is worth reading rather than one of the several hundred others competing for the same search. This page is also available in Arabic: العربية.
If you read nothing else on this page, read this. Match the tier to your profile first, score the Saudi criteria second, and compare features third - in that order. Most ERP selections that go wrong in this market were decided in the reverse order: a feature comparison picked a product, the product turned out to be a tier too large or a tier too small for the business, and e-invoicing integration was verified after the contract was signed rather than before it.
| If this is your company | Where to start |
|---|---|
| One entity, modest transaction volume, finance run by a small team | Confirm you need an ERP at all before buying one. Section 6 covers the tell. |
| Growing mid-market company, one or two entities, distribution or services | A mid-market cloud suite. This is where the majority of Saudi ERP decisions correctly land. |
| Multi-entity group with consolidation, intercompany and multi-currency | A suite with native consolidation rather than a single-entity product with a reporting layer bolted on |
| Manufacturing, engineering projects or a regulated supply chain at scale | A large-enterprise process platform - and a serious look at whether the complexity is real |
| Retail or hospitality across many locations | Settle the point-of-sale and stock decision first; the ERP choice is downstream of it |
Four rules apply to every profile in that table, and they are the ones most commonly broken:
ERP selection has been a live question in the Kingdom for years. What has changed is that several independent clocks are now running at once, and they have moved the decision from "something finance would like to fix" to something with an external deadline attached.
The compliance clock is the loudest of them. ZATCA's e-invoicing programme moved the requirement from issuing a compliant invoice to integrating your billing system with the authority's platform, with organizations onboarded in waves defined by size. For a business still invoicing out of spreadsheets or an unsupported legacy system, that is not a reporting change - it is a systems change with a date on it. Our ZATCA e-invoicing guide covers the requirement itself; what matters for this page is that it has become the single most common reason a Saudi company starts an ERP evaluation at all, and the most common reason a shortlist collapses from five candidates to two.
Reporting obligations have become systems obligations. Zakat and VAT reporting, GOSI contributions, the Wage Protection System and Saudization reporting each assume a payroll and finance function that can produce accurate, traceable data on a fixed cycle. Every one of those is survivable manually at small scale and becomes a standing operational risk as headcount and entity count grow. Companies rarely buy an ERP because of any single one of them; they buy one when the combination stops fitting into the month.
Growth in this market is structurally multi-entity. The pattern we see repeatedly is a company that added a second CR, then a third, then a subsidiary in another activity, each on its own books - and now needs a consolidated view that its accounting software was never built to produce. Consolidation is the requirement most frequently discovered late, and it is one of the few that genuinely cannot be retrofitted cheaply.
Data residency has moved from a preference to a contract term. In regulated sectors and in government-adjacent contracting, where data physically resides and what the vendor will commit to about it in writing is now a procurement question rather than an architectural footnote. It should be asked before a shortlist forms, because it disqualifies options rather than scoring them.
All of which raises the cost of choosing badly, and the cost is asymmetric. Picking a platform that is slightly too small is recoverable: you outgrow it, and you migrate on your own timetable with your data in reasonable order. Picking one that is far too large is recoverable too, expensively. Picking one that cannot meet a regulatory obligation is not recoverable on any useful timetable, because the deadline belongs to somebody else.
The most useful thing to understand about ERP systems is that they are not arranged along a single axis from worse to better. They are arranged in tiers, and the tiers solve different problems. Within a tier, mainstream products will do what most organizations need and the differences are real but marginal. Across tiers the differences are not marginal at all - they decide implementation cost, duration, the skills you need in-house afterwards and whether the system will still fit in five years.
Getting the tier wrong costs far more than getting the product wrong within a tier. That is why this section comes before any discussion of features, and why a comparison between two products from different tiers - however rigorously conducted - produces a confident answer to a question that should not have been asked.
| Tier | Fits | What it is genuinely good at | Where it fails you |
|---|---|---|---|
| Accounting and bookkeeping platforms | Single entity, contained transaction volume, no manufacturing | Fast to adopt, cheap to run, adequate for VAT and invoicing obligations at small scale | Multi-entity consolidation, inventory at depth, production, granular permissions and audit |
| Mid-market cloud suites | Mid-market companies, one to a handful of entities, distribution, services, light manufacturing | One integrated set of books, inventory and order management; consolidation without bolt-ons; predictable implementations | Heavy discrete or process manufacturing, very large transaction volumes, deeply industry-specific processes |
| Large-enterprise process platforms | Large organizations with deep manufacturing, supply-chain or group-reporting demands | Depth and rigour in specific industry processes; scale; established audit and control frameworks | Cost and duration of implementation, and the standing internal capability the platform assumes you have |
| Industry-specific systems | Businesses whose core process is the whole business - retail, hospitality, construction, healthcare, logistics | The core process, out of the box, without configuration that takes a year | Finance depth and group reporting; they frequently need a finance system alongside them rather than instead of one |
These are the five shapes we actually encounter in Saudi ERP evaluations. Find the one that describes you, and note that the advice includes, in one case, not buying anything.
Profile one: the single entity that has outgrown its accounting software. One CR, one set of books, a finance team of a few people, and a growing sense that month-end takes too long. Before shortlisting an ERP, be precise about what is actually failing. If the answer is "our invoicing cannot meet the e-invoicing requirement", that is a solvable problem and does not by itself justify an ERP programme - several accounting platforms address it directly. If the answer is "we cannot see stock accurately", or "we have three spreadsheets that must agree and never do", the constraint is real and a mid-market suite is the right next step. The cheapest ERP implementation is the one you correctly postponed, and this profile is where that saving is most often available.
Profile two: the growing mid-market distributor or services business. One or two entities, real inventory or real project delivery, a finance function that has started to reconcile between systems rather than within one. This is the profile a mid-market cloud suite exists for, and it is where the majority of correct Saudi ERP decisions land. The shortlist should be short - two or three products - and the decisive criteria are rarely functional. They are e-invoicing integration, the quality of Arabic outputs, the depth of local implementation capacity behind each candidate, and total cost over several years rather than at signature.
Profile three: the multi-entity group. Several CRs, intercompany transactions, more than one currency, and a consolidated view currently assembled by hand. This is the profile where the tier question becomes genuinely difficult, because it sits on the boundary between a mid-market suite with native multi-book consolidation and a large-enterprise platform. The honest discriminator is not entity count but process complexity inside the entities: a group of six trading companies is a different problem from a group of two manufacturers. This is where NetSuite vs SAP is the comparison to read, because it is that tier question in its clearest and most common form.
Profile four: manufacturing, engineering projects or a regulated supply chain. Production planning, bills of material, quality and traceability, or long-running projects with percentage-of-completion accounting. A large-enterprise process platform is a legitimate candidate here and frequently the right one. It is also the profile most likely to over-buy, so it is worth being honest about whether the complexity is inherent to what you make or has accumulated around how you happen to make it. The second kind is cheaper to remove than to automate, and an implementation that automates it locks it in for a decade.
Profile five: multi-location retail or hospitality. Many branches, high transaction counts, stock moving between locations, and a point-of-sale estate that is already the operational heart of the business. Here the ERP decision is downstream of the POS and inventory decision, not the other way round, and evaluating ERPs first is the most common sequencing error in this profile. Settle how sales are captured, how invoices are issued compliantly at the moment of sale, and how stock reconciles across locations. Then choose the finance system that those realities can feed cleanly.
This is the section that makes a Saudi ERP shortlist different from an international one, and it is where generic "best ERP" content quietly fails a reader in the Kingdom. The criteria below eliminate candidates. They do not merely score them - and they do it faster than any functional comparison, which is why they belong before the feature discussion rather than after it.
One thing this page will not do is publish a table of vendor names with ticks against them. Compliance status is a live regulatory fact that changes without notice, and a tick next to a product name would be a claim about that status which this page cannot stand behind next quarter. What follows is the scorecard instead: the criteria, what "ready" actually means for each one, and how you verify it yourself against a specific vendor, on the day you are deciding. A verification method stays true for as long as the regulation does.
| Criterion | What "ready" actually means | How to verify it |
|---|---|---|
| E-invoicing integration | Not "we generate a compliant PDF" but a working integration with ZATCA's platform in the form the authority requires, for invoices, credit notes and debit notes alike | Ask which entry on ZATCA's own published list of compliant solutions the integration runs under, and whose it is - the vendor's, a middleware provider's, or your implementation partner's |
| Arabic interface | Arabic available to the users who need it, including finance and warehouse staff, not only in a marketing screenshot | Ask for a demonstration driven in Arabic by a colleague of yours rather than by the vendor |
| Arabic in the outputs | Invoices, credit notes, statements and audit-facing documents rendered correctly in Arabic - a different problem from an Arabic interface, and solved to a different standard | Ask for a real, printed and PDF Arabic credit note from a live system, not a template mock-up |
| Right-to-left layout | Documents a regulator or auditor will read are laid out correctly, including tables, totals and mixed Arabic-Latin lines | Inspect the documents above rather than the screens |
| Hijri date handling | Where a process, contract or report requires a Hijri date, the system carries it natively rather than in a free-text field | Name the specific processes where you need it and ask to see each one |
| Zakat and VAT reporting | Returns produced from the system's own data, with a traceable line back to the transactions behind them | Ask to see the audit trail from a return figure back to a source document |
| Payroll obligations | GOSI contributions, the Wage Protection System file and Saudization reporting handled by the platform or by a named, integrated payroll product | Establish which of the two it is, in writing, before signature |
| Data residency | Where your data physically resides, and what the vendor commits to contractually - not what a datasheet implies | Ask for the commitment as a contract clause; a marketing page is not a commitment |
| Support in Arabic, in Kingdom hours | Support reachable in Arabic during your working day, rather than a follow-the-sun queue that answers overnight | Ask for the support hours and languages as a service level, and test the channel during the evaluation |
| Local implementation capacity | Certified people in the Kingdom who have delivered your profile, and who are actually available on your timeline | Ask for named consultants and their availability, not a partner logo |
Every vendor selling into this market will tell you they are ZATCA-ready, and most of them will be telling the truth as they understand it. The phrase covers several quite different states, and the distance between them is where implementations go wrong. These are the questions that separate them, in the order worth asking.
Whose compliance is it? Establish whether the integration is the vendor's own, a third-party middleware product bundled into the quotation, or something your implementation partner builds for you. All three can be legitimate. They carry very different renewal costs, very different support paths when something breaks, and very different answers to the question of who is responsible when the regulation changes.
Is it in production somewhere in the Kingdom? Ask for a reference running the same version, with the same integration, at a comparable volume. "Certified" and "live at a company like yours" are different claims and only the second one predicts your experience.
What happens to the edge cases? Credit notes, debit notes, returns, foreign currency invoices, self-billing arrangements and cancellations are where compliance gaps actually appear. A clean sales invoice demonstrates very little.
Who absorbs the next regulatory change? The requirement has moved before and will move again. Establish in writing whether adapting to a future change is covered by your subscription and support agreement, or is a chargeable project - and get that into the contract rather than into an email.
What does it cost per year, and per what? Some integrations are priced per document, per entity or per connection. That is a cost line which grows with your business and which rarely appears in the licence comparison you are shown.
Run those five questions against every candidate before you compare a single feature. In our experience they are the fastest way to turn a shortlist of five into a shortlist of two, and they cost nothing but the time to ask.
We publish no price range for an ERP and no standard implementation duration, and the reason is not coyness. Both are genuinely a function of your scope, your data, your entity count and your own team's availability, and a number published here that cannot be stood behind would be worse than no number at all - it would anchor a budget conversation on a figure invented for a page. What can be published honestly is the full list of what you will pay for, and the specific things that move the timeline. Both are more useful than a range, because you can apply them to the quotation actually in front of you.
What a licence quotation leaves out. The subscription or licence itself is the line everyone compares and the smaller half of what is spent. The rest, in rough order of how often it is forgotten: implementation and configuration services; data migration, which is priced by how bad your data is rather than by how much of it there is; integration with the systems you are keeping; the e-invoicing integration and its own recurring fee; any additional modules that turn out to be separately licensed; the sandbox or test environment; training, including the second round nobody budgets for after go-live; internal staff time, which is a real cost even though no invoice arrives for it; hypercare support in the weeks after go-live; the annual support and maintenance percentage; and the upgrade or re-implementation cost in a few years' time, which differs enormously between platforms and is almost never discussed during selection.
What actually drives the duration. Not the software. The number of legal entities and whether they share a chart of accounts. The state of your master data - customers, suppliers, items - which is the single most common cause of a slipped go-live in our experience. The number of integrations and whether the other side of each is cooperative. How much configuration is genuinely required versus how much is a process nobody wants to change. Whether the decisions the project needs can be made quickly, which is a function of governance rather than of technology. And, more than any other factor, whether your own people are actually available to the project or are doing it on top of their real jobs.
Where the estimate reliably goes wrong. Three places. Data migration is scoped on volume rather than on quality. Reporting is left to the end and turns out to be the thing the business will judge the whole programme by. And the second entity is assumed to cost a fraction of the first, which is true when it is genuinely similar and badly wrong when it is not.
Our ERP consulting page covers how we scope this work and how a cost model is built against real volumes rather than against a published range. The fee structure for the evaluation itself is not published yet; ask for it and you will have it before speaking to anyone.
These are the failures we are called in to unwind, in rough order of how expensive they turn out to be. None of them is a failure of diligence - most happened to organizations that ran a careful process on the wrong question.
Buying an ERP that was never needed. The most expensive mistake on this list, and the most common one in Profile one. If the requirement is accounting, invoicing, VAT and e-invoicing compliance for a single entity, an ERP programme is an expensive answer to a question an accounting platform already solves. The tell is a requirements list that describes today's workarounds translated into software terms.
Letting the demonstration decide. A demonstration shows a vendor's best path through their own product with their own clean data. It is a sales exercise and a good one. The corrective is cheap: give every vendor the same scripted scenarios, built from your own processes and run on a sample of your own data, and score them on the same sheet.
Treating e-invoicing as a checkbox. "ZATCA-ready" is a phrase, not a specification. Section 4.1 lists the five questions that turn it into one. Organizations that skip them discover the gap during implementation, when their negotiating position is gone.
Scoring the Arabic interface and forgetting the Arabic documents. The interface is what gets demonstrated; the documents are what an auditor, a customer and a regulator actually read. They are different pieces of engineering and they are frequently at different levels of maturity in the same product.
Comparing across tiers without saying so. A mid-market suite and a large-enterprise platform can certainly be scored against one another, and the exercise will be rigorous and misleading simultaneously. Settle the tier first; a comparison is only meaningful within one.
Choosing the platform and inheriting the partner. In this market the implementation partner determines the outcome at least as much as the software does, and the pool of genuinely experienced local consultants for any given platform is smaller than the partner directory suggests. Evaluate the named people who will do the work, and their availability on your timeline, as a scored criterion rather than as a formality after the product is chosen.
Leaving data migration until the plan is already fixed. Migration is priced and scheduled by the quality of your master data, not its volume. Look at it in week one. It is the single most reliable predictor of whether the date you are being promised is real.
Having no named internal owner. A programme without one person inside the business who owns the outcome, has the authority to settle process disputes and is measurably available to the project will drift regardless of which product was chosen. This is the criterion no vendor will raise with you, because it is about you rather than about them.
A buyer's guide that weighs everything carefully and then declines to conclude anything is not neutral, it is useless - it has handed the decision back to you with more information and no more clarity. So here is what we actually recommend, stated at the level this page can evidence, with the conditions under which each recommendation flips.
For most Saudi mid-market companies, a mid-market cloud suite is the right answer. It carries multi-entity consolidation natively, implements in a timeframe a business can absorb, and does not assume a standing internal capability most mid-market companies do not have. This flips when genuine manufacturing, engineering-project or regulated supply-chain complexity is present at scale - at which point a large-enterprise process platform stops being over-buying and becomes the honest requirement.
For single-entity companies whose real problem is compliance and reporting, our recommendation is usually not to buy an ERP this year. Solve e-invoicing and reporting on the platform you have or on an accounting platform built for it, and revisit the ERP question when a second entity, real inventory depth or a genuine consolidation requirement makes the constraint structural. This flips the moment you are reconciling between systems rather than within one.
For multi-entity groups, the tier question is the whole decision and it deserves more time than the feature comparison that follows it. Read NetSuite vs SAP for that question in its clearest form. We deliberately do not pre-announce a winner here: that comparison has to carry a score sheet, its evidence and a revision date, and declaring an answer on this page would pre-empt the page that owns it.
For every profile, three things are non-negotiable. Verify e-invoicing readiness against ZATCA's own published list of compliant solutions rather than against a vendor statement, and do it before the shortlist closes. Weight the Saudi criteria in section 4 at least as heavily as functional fit, because they disqualify rather than score. And keep the shortlist to three candidates at most - a longer one does not produce a better decision, it produces a longer process and a more tired committee.
And the recommendation that matters most: do not accept a product name from us, from a vendor, or from any ranking site, until your own criteria are written down and weighted. Criteria written after the products are known tend to describe the product the author already preferred, which is how a selection reaches a predetermined answer while looking rigorous throughout. If you want that done properly and independently, that is the engagement described on our technology and vendor selection page. If the honest answer turns out to be that your incumbent is adequate, that is what you will be told - it costs us nothing to say, which is rather the point of being paid by you and by nobody else.
Long enough that the honest answer is a range you should not trust from a web page, because the variables that set it are yours rather than the software's. A single-entity mid-market implementation with clean master data, few integrations and a dedicated internal owner is a different undertaking from a multi-entity group implementation with legacy data, several integrations and a part-time project team - and the second can take several times as long on the same product. Section 5 lists the specific drivers. If you want a defensible timeline, the useful exercise is to score your own situation against those drivers before you ask a vendor, so that you can tell whether the date you are offered was estimated or negotiated. Be especially sceptical of any duration quoted before anyone has looked at your master data.
Materially more than the licence, and the gap is where budgets fail. Over three years you are paying for the subscription or licence plus annual support, the implementation itself, data migration, integrations, the e-invoicing connection and any recurring fee attached to it, additional modules that turn out to be licensed separately, test environments, two rounds of training, hypercare after go-live, and your own people's time. Section 5 has the full list. Two items are worth pulling out because they are the ones most often missed entirely: the cost of adding the next entity, which is rarely proportional, and the cost of the upgrade or re-implementation cycle, which differs enormously between platforms and is almost never raised during selection. Ask every vendor to quote all of it over three years on the same template, and compare the totals rather than the headline.
We deliberately do not publish a list of vendor names with compliance ticks against them, and the reason is that such a list would be wrong sooner than you would notice. Compliance status is a live regulatory fact: it attaches to a specific solution and version rather than to a brand, it changes as the requirement changes, and it is frequently delivered by a middleware product or an implementation partner rather than by the ERP vendor at all. The reliable method, which stays true as the list moves, is in section 4: check ZATCA's own published list of compliant solutions for the specific product and version you are being offered, establish whose integration it actually is, and get the data-residency commitment as a contract clause rather than a datasheet claim. Section 4.1 lists the five questions that separate a genuine readiness claim from a sincere one.
Four, and they should be evaluated in this order. First, doing nothing: if the incumbent is adequate and the real grievance is price, support or an untrained module, replacement is the most expensive available response to a commercial problem. Second, a tier down: an accounting platform that meets your compliance and reporting obligations, which is the right answer far more often than the ERP market finds convenient to mention. Third, fixing the process rather than the system, where month-end runs long because several teams maintain their own version of the same data and nobody owns the reconciliation between them - a new system inherits that and adds a migration to it. Fourth, an industry-specific system alongside a lighter finance platform, which frequently beats a general-purpose ERP for businesses whose core process is the whole business. Only when all four have been considered and rejected on evidence is a full ERP evaluation the right next step.
Three pages take the questions this guide raises further. NetSuite vs SAP is the head-to-head behind the tier question in section 3 - the comparison to read once your shortlist has narrowed to a mid-market cloud suite and a large-enterprise platform and you need the trade-off scored rather than described. Our ZATCA e-invoicing guide covers the requirement itself, which section 2 treats only as the clock it has become and section 4 treats only as a criterion to verify. And our comparison hub indexes every independent system comparison we publish, including the ones still in preparation, together with the method each is scored by and - in its fourth section - the cases in which comparing two products is the wrong question altogether.
A heading promising facts should supply facts a reader can actually check, so these are structural rather than statistical. Each one is verifiable by asking us directly, and each one is a commitment you can hold us to.
What you will not find here is an aggregate number - no count of selections run, no percentage of shortlists changed, no average saving. Those figures are unverifiable by a reader and trivially easy to construct, and on a page arguing that you should discount claims whose author has an interest in them, publishing one would refute everything around it. Documented work is published individually on our success stories page as clients clear it for release.
The organizations that bring us an ERP selection share a position rather than a sector: a decision large enough that being wrong about it is expensive, and a set of advisers each of whom earns something from a particular outcome. In practice that means finance-led mid-market companies outgrowing an accounting platform; multi-entity groups trying to consolidate onto one system; subsidiaries of international groups reconciling a global template with Saudi statutory and e-invoicing obligations; manufacturers and contractors whose production or project accounting has outgrown a general-purpose system; retail and hospitality operators standardising across locations; and organizations midway through a stalled procurement in which two vendors have made irreconcilable claims and nobody internal is positioned to adjudicate between them.
Rather than listing names here ahead of each client's own confirmation to be featured, the current permissioned list is maintained on our customers page and updated as relationships are cleared for publication. Selection work carries an additional sensitivity worth stating: an evaluation names vendors and records what the assessment found, often alongside a live commercial negotiation, so a client's willingness to be publicly associated with it is not something to assume on their behalf.
Individual engagements are documented case by case on our success stories page, and the delivery work that followed a selection is on our projects page - in both cases as clients clear them for publication, rather than compressed into a headline figure here. What is worth stating is the shape those outcomes take, because it is frequently not the shape a client expects when they commission an ERP evaluation.
The most common result is a shortlist that changes: once criteria are written down and weighted against the Saudi requirements in section 4, they eliminate a front-runner that arrived through a relationship rather than through a requirement. The second is a tier correction - an organization about to buy a platform one size too large for it, or one size too small for where it is heading. The third is a renegotiation rather than a replacement, where the evaluation establishes that the incumbent is adequate and hands the client a defensible position at renewal. And the fourth, which no vendor-funded comparison will ever produce, is a decision not to buy at all: the process is fixed, the purchase is postponed, and the money is not spent. We record that as a result, because it is one.
We do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, so this section will carry real, attributed testimonials from ERP selection engagements as those approvals arrive - rather than a composite or a paraphrase standing in for one in the meantime. A quote assembled by the firm it praises is worth precisely nothing, and on a page whose argument is that you should discount claims their author has an interest in, it would quietly undo every other section.
If a reference matters to your decision - and on an ERP selection it reasonably should - raise it in the first conversation and we will connect you with a comparable past client wherever confidentiality allows. That is more useful than a published quote in any case, because the questions worth asking are about how the evaluation held up a year after go-live, and those are answered in a conversation rather than in a sentence.
On a page recommending against vendor-authored advice, our own incentives should be the first thing disclosed rather than the last. We maintain technical relationships and accreditations with a number of enterprise technology vendors, and we maintain them for one reason: advising on a platform without people who have genuinely worked inside it produces advice that reads well and fails in delivery. Those relationships buy us training, product access and engineering contact. They do not involve reselling, they carry no sales quota and no revenue share, and no partnership obliges us to recommend anything to anyone.
Three rules govern how that interacts with this guide. First, our evaluations are not restricted to products we partner with - a shortlist limited to a partner roster is a catalogue wearing an evaluation's clothes. Second, where we hold a partnership with a vendor under consideration, it is disclosed to you at the point of the recommendation rather than left to be discovered afterwards. Third, no vendor sees, funds, reviews or approves this page or any evaluation before it reaches you, and none has editorial input of any kind. Our current accreditations and technology partner network are listed on our partners page, and if you want to know whether a particular relationship touched a particular conclusion, ask - you will get a direct answer.
This guide builds a shortlist. The pages around it answer the questions on either side of that. ERP systems sets out the platforms we work with and what each is built for. ERP consulting covers implementation, optimisation and recovery once a platform is chosen - including the engagements that begin after a programme has already gone wrong. Technology and vendor selection is the engagement that turns the criteria in section 4 into a weighted, scored evaluation of your own shortlist. Enterprise systems integration covers the part that most often decides whether a correctly chosen platform succeeds at all. How we work sets out the five stages and where an evaluation sits among them, and what each engagement costs is not published yet - ask, and you will have it before you speak to anybody. If you are selecting systems as part of establishing an operation in the Kingdom rather than replacing one, start at market entry advisory.
If you would like this decision taken properly, tell us three things: what you run today, what is actually failing, and what has to be true a year after go-live. That is enough for a first conversation, and enough for us to tell you whether you need an evaluation, a smaller piece of work, or nothing at all.
What that conversation is not is a sales call for a product, because we do not sell one. We earn nothing from which platform you choose, which is what makes it possible for us to say that your incumbent is adequate, or that the purchase you are considering should wait a year. Both are outcomes we reach regularly and neither costs us anything to say. If a full evaluation is the right next step, technology and vendor selection describes how it runs, and what it costs is not published yet - ask, and you will have both before you commit to anything.