SmartLink
ERP

ERP consultation and selection in Pakistan

ERP consultation in Pakistan is worth buying for one reason: the decision it protects is far more expensive than the advice. Market ranges put an implementation at PKR 800,000 to 1,500,000 at the focused end and PKR 3,000,000 upwards at the enterprise end, and the wrong platform choice is paid for every year afterwards. SmartLink Services runs selection work from Karachi as advisory only, with no implementation attached to the answer and no vendor commission behind it. This page covers what such an engagement costs, how long it runs, and why we keep the advice and the build apart.

Engagement
2, 6 weeks
Output
Decision pack
Independence
No vendor commission
Overview

Advice that is not attached to an implementation.

Choosing an ERP is mostly a procurement problem dressed as a technology problem. The demonstrations all look capable, the licence quotes are structured differently enough to be hard to compare, and the people who will use the system daily are often the last to be asked.

This engagement is advisory only, and we do not take vendor commission. Requirements are gathered from the people doing the work, then scored against real platform capability rather than sales material. Licence, implementation and five-year run costs are modelled side by side so the comparison is about total cost rather than year-one price.

The output is a decision pack: a requirement catalogue, a scored comparison, a cost model, a risk register and a phased roadmap. You can hand that to any implementer, including one that is not us. That is the point of keeping the advice separate from the build.

Scope

What ERP consultation & selection covers

Everything below is agreed in writing before any erp & core systems work starts, so both sides know what is in and what is not.

What the work covers

  • Process discovery workshops per department
  • Requirement catalogue with must-have and nice-to-have separation
  • Platform shortlist scored against those requirements
  • Licence, implementation and five-year run cost comparison
  • Readiness assessment: data quality, ownership, change capacity
  • Implementation roadmap with phasing options

What you get at handover

  • Requirement catalogue
  • Scored platform comparison
  • Five-year cost model
  • Risk register
  • Phased roadmap and business case

Typically involves

ERPNext
Discuss this service
01

Running a demonstration that tells you something

A standard vendor demonstration is designed to be impressive, and it succeeds. Rehearsed data, a clean happy path, an experienced presenter who steers away from anything untidy. Watching four of those in a fortnight leaves a committee with an impression rather than information. Take control of the format instead. Send scenarios in advance, drawn from your own transactions and your own data, and require them to be run live, in the order you set, by a consultant rather than a marketing lead.

Exceptions are where the useful information hides. Ask for the partial delivery, the credit note against a prior period, the customer paying three invoices with one short transfer, the item purchased in cartons and sold in pieces, the price agreed in a foreign currency and settled two months later. Ask to be shown rather than told, then ask a second question after every answer: was that standard behaviour, configuration, or development. The answers separate what the product does from what the vendor is willing to build.

Scoring should happen individually, immediately, before the room discusses anything. Give every attendee the same sheet and collect it before the conversation starts, otherwise the most confident voice in the room becomes the group's memory of what happened. Include the people who will use the system daily, not only the managers who will sign for it. One boundary is worth naming. A demonstration proves the software can be made to do something. It does not prove that your team will operate it that way on a Tuesday in March.

  • Scenario scripts issued in advance and built from your own transactions and data
  • Every answer classified as standard behaviour, configuration or development work
  • Individual scoring collected before any group discussion of what was seen
  • Daily users present in the room alongside the managers who will approve the purchase
  • Exception cases scripted deliberately, since happy path demonstrations separate nothing
02

Telling a requirement apart from a habit

Requirement lists usually contain three different things mixed together. There are legal, tax and contractual obligations that are genuinely not negotiable. There are real operating needs that reflect how the business makes money. Then there are habits inherited from the limitations of a system bought fifteen years ago, kept because that is how it has always been done. Presented as one list, they make every platform on the shortlist look like a poor fit and every implementation look expensive.

Separating them takes three questions asked patiently. What happens if we stop doing this. Who reads the output and what do they decide with it. Which rule, contract or regulation requires it, and can we see it. A statutory return stays mandatory. A report that has been produced monthly for six years and never opened is not a requirement, it is a residue, and carrying it into a new system means paying to rebuild something nobody wants.

Inflation of the mandatory list is the failure to guard against. When everything is marked essential, evaluation collapses into a price comparison and the organisation buys the cheapest reading of its own words. Cap the number of mandatory lines per department and force the prioritisation to happen while the stakes are still low. This makes people uncomfortable, and somebody senior has to be prepared to say no in front of colleagues. Without that, the catalogue grows, the scores converge, and the decision quietly reverts to whoever quoted least.

  • Obligations, operating needs and inherited habits separated into three distinct categories
  • Each mandatory line traced to a rule, contract or regulation that can be produced on request
  • Reports validated by asking who reads them and what decision they support
  • A capped number of mandatory requirements per department, forcing genuine prioritisation
  • A named senior owner willing to decline requirements in front of the people who raised them
01

What ERP consultation costs in Pakistan

There is no published market band for ERP advisory in Pakistan the way there is for implementation, and anyone quoting one is quoting themselves. What can be stated is the shape of the pricing. Selection work is sold as days rather than as a deliverable, the engagement runs two to six weeks, and the rate reflects seniority: published market rates for full stack technical work in Pakistan run PKR 3,500 to 8,000 an hour, with senior specialist work at the top of that range and junior work at PKR 500 to 1,000. Advisory sits with the senior figures, because a requirement workshop run by somebody who has not implemented the product is a transcription service.

Scale the engagement against the decision rather than against the fee. The implementation it precedes carries market ranges of PKR 800,000 to 1,500,000 for a focused single site scope, PKR 1,500,000 to 3,000,000 for five to seven modules and PKR 3,000,000 upwards for multi location manufacturing. Advisory that changes any one of those numbers has usually paid for itself before the platform is chosen.

Four things move the effort. Department count, because discovery is a series of workshops and each function needs its own. Site count, since a second plant is a second set of processes rather than a copy of the first. Whether a five year cost model is built, which requires licence quotations from every shortlisted vendor and a genuine comparison of them. And whether readiness assessment is included: data quality, ownership and the organisation's capacity to absorb change in one year. Treat the market rates above as market rates. Our figure follows a short scoping conversation, because a fee quoted before we know how many departments and sites are in scope is a number without a basis.

  • Priced as senior days, with the engagement running two to six weeks
  • Department count and site count as the main drivers of discovery effort
  • A five year cost model priced separately, since it needs licence quotations from each vendor
  • Readiness assessment covering data quality, ownership and change capacity
  • No vendor commission, so the shortlist reflects fit rather than margin
02

How long an ERP selection takes

Two to six weeks covers most selections, and where an engagement lands inside that range depends on how many people have to be interviewed rather than on how many products are being compared. A single company with four departments and one site can be done in a fortnight. A group with three plants, two legal entities and a shared services function will use the six, and most of the extra time is calendar rather than effort, spent waiting for the finance director and the production manager to be in the same room.

Vendor demonstrations set the other half of the schedule and they are worth controlling. A demonstration run to the vendor's script proves the product can do what the vendor rehearsed. A demonstration run to your script, using your material codes, your pricing conditions and your awkward month end case, tells you something. Scripted demonstrations take longer to arrange because vendors need lead time to prepare against real data, and that lead time belongs in the plan.

Set against implementation, the selection is short. Reported go live timelines run six to twelve weeks for a focused single company scope, three to six months for an SME and nine to twelve months for a large enterprise. Four weeks in front of a nine month commitment is not a delay. Rushing it is the reliable way to spend month seven arguing about a scope boundary.

  • Two to six weeks for most engagements, set by the number of people to be interviewed
  • Scripted demonstrations arranged with vendor lead time built into the plan
  • Reference calls with organisations of comparable size, arranged rather than accepted
  • Licence quotations requested in a common format so the comparison is honest
  • Decision pack delivered to a date, with the shortlist and the rejections written down
03

Why the advice is kept separate from the build

An adviser who will implement whatever they recommend is not giving advice, they are writing a proposal with a research phase attached. That is not an accusation of dishonesty. It is a description of what incentives do to judgement over eight weeks, quietly and without anybody deciding to be biased. The requirement that fits the product you know best begins to look like the important one. The gap that would be difficult for your team begins to look like a process change the client should accept.

SmartLink runs selection work with no implementation tied to the answer and no commission from any vendor. The practical result is that we can recommend a platform we do not implement, and we have. It also means the shortlist can say the uncomfortable thing: that the requirement does not justify a tier one licence, that the existing system would be adequate with three months of clean up, or that the organisation is not ready to absorb an ERP this year and should fix data ownership first.

Ask any adviser three questions before you engage them. What is your commercial relationship with each vendor on the shortlist, in writing. Will you bid for the implementation, and if so at what point do you step back. What happens to the deliverables if we choose a platform you do not work with. An adviser who cannot answer those cleanly is not necessarily wrong, but you now know how to read their recommendation.

The deliverable is built to be read by somebody who was not in the workshops: a requirement catalogue separating what must be true from what would be pleasant, a scored comparison, a five year cost model, a risk register and a phased roadmap. Two years later a finance director should be able to open it and see why the decision was taken, which options were set aside and what was assumed. That is what independence is for.

  • Advisory sold on its own, with no implementation attached to the recommendation
  • No vendor commission, stated in writing before the engagement begins
  • A requirement catalogue separating must have from nice to have before scoring starts
  • Every rejected platform named in the decision pack with the reason for rejecting it
  • A decision pack written to be understood by somebody who attended no workshop
How we deliver

Delivering ERP consultation & selection

The six steps below run on every ERP engagement, whether the platform is SAP, Oracle, Dynamics or Odoo. What changes is depth, and how many legal entities and sites have to be carried through one cutover weekend.

  1. 01

    Discover

    We follow a real order, a real goods receipt and a real payment run from desk to ledger. What the procedure says and what people do rarely match, and that gap is the requirement.

  2. 02

    Blueprint

    The functional design fixes chart of accounts, entity structure, costing method and document numbering. Nothing here is easy to change once postings exist, so finance signs it before a consultant touches configuration.

  3. 03

    Build

    Configuration is done in a development client and travels one way to test. Key users see each process area demonstrated on their own material and customer records rather than on vendor sample data.

  4. 04

    Test

    Integration testing runs order to cash and procure to pay end to end, on migrated data. Then key users work written scripts, and every defect is logged with the screen, the document number and a severity.

  5. 05

    Go live

    A timed cutover sequence with named owners: final legacy postings, opening balance load, stock count, reconciliation, then the go decision at a stated hour. The rollback point is a restore that has been tested.

  6. 06

    Run

    Hypercare covers the first month-end close, which is where ERP problems actually surface. After that, a named key user group answers routine questions and changes are batched into a release cadence.

Working together

A decision you can explain in two years

The purpose of a selection is not only to choose well. It is to be able to explain the choice later, to a board, an auditor or a successor, using a document rather than a recollection. That is why the deliverable is a pack rather than a recommendation: the requirements as gathered, the scoring as recorded, the costs as modelled and the risks as they were understood on the day. If the decision turns out to have been wrong, you will at least know which assumption failed.

Occasionally the honest conclusion is that no purchase is required, and that process discipline, data quality or training would deliver most of the benefit for a fraction of the money. We are content to reach that conclusion and say so, because the advice is not attached to a build. That independence is only worth something if it survives contact with an outcome that does not suit us.

Credentials

Accreditations behind ERP & core systems

ERP buyers ask two things before shortlisting: which platforms we are accredited to deliver on, and how the system will meet Pakistani tax reporting once it is live.

Client words

What ERP & core systems clients say

Comments from people who run erp & core systems systems day to day.

  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
  • We had been through one failed implementation already, so we were sceptical of the whole category. The difference here was the migration work. Two full rehearsal loads before the real one, with a reconciliation pack we could check ourselves. Nobody had ever handed us evidence like that and asked us to sign it.
    Head of IT Wholesale distribution business
  • Our cost reports used to show what we had paid, never what we had committed. Once the subcontract orders and approved variations started registering as commitment, the forecast stopped flattering us. It was uncomfortable reading for a month and then it became the most useful number we have.
    Chief Financial Officer Construction and contracting firm
Questions

Questions about ERP consultation & selection

Advisory is sold as senior days rather than as a fixed product, and no published market band exists for it here. Market hourly rates for skilled technical work in Pakistan run PKR 3,500 to 8,000, with advisory at the senior end. Judge the fee against the decision it protects: implementations carry market ranges from PKR 800,000 to well beyond PKR 3,000,000.

Two to six weeks for most organisations. What sets the length is the number of departments and sites to be interviewed rather than the number of products compared. Scripted vendor demonstrations need lead time, and reference calls have to be arranged. Against reported implementation timelines of three to twelve months, a four week selection is not a delay.

Many do, and it is a fair thing to ask about directly. Request the commercial relationship with every shortlisted vendor in writing before you engage anybody. We take no vendor commission and sell selection work separately from implementation, which is what allows a shortlist to recommend a platform we do not implement ourselves. An adviser who cannot answer the question cleanly is not necessarily wrong, but you now know how to read the recommendation.

For a single site distributor or trader with straightforward processes, Odoo and ERPNext usually give the most function for the money, and SAP Business One is the step up where manufacturing or audit expectations are real. There is no single answer. The shortlist should be scored against your process chains, your entity structure and your appetite for change.

The community edition is free to download and it is not free to run. Hosting, implementation, support and most of the applications a business actually needs sit in the enterprise edition or in third party modules. Open source lowers the licence line and moves the money to effort. Judge it on five year total cost rather than on the download price.

A requirement catalogue with must have and nice to have separated, a scored platform comparison, a five year cost model covering licence, implementation and running cost, a risk register and a phased roadmap with a business case. The pack is written so a finance director reading it two years later can see what was decided and what was set aside.

Choosing an ERP and want an independent read?

Tell us what you run today and where erp consultation & selection is causing you trouble. The first conversation is a consultation rather than a pitch.