NEDAX
Buyer's guide
How to choose, budget, and survive a business system project. Written for medical equipment distributors, importers, general representatives, and service organizations.
Chapter 1
Most ERP advice is written for manufacturers or retailers. A medical equipment distributor is neither. You buy, stock, sell, and ship like any trading company, and then you do four more things that decide whether a business system helps you or fights you. Evaluate every system against these four before you look at anything else.
You do not sell quantities; you sell units with identities. A pallet of infusion pumps is not 24 pieces, it is 24 serial numbers with a manufacturing lot and, for consumables, an expiry date. Regulation in Europe and North America expects the importer or distributor to know where every unit came from and where it went. The practical test is a field safety notice: when a manufacturer recalls a lot, you need every affected unit, the customer it went to, and the delivery it went on, within hours. A system that treats lot and serial tracking as an optional module bolted onto quantity-based stock will slow you down at receiving, mislead you at picking, and fail you during a recall. Expiry adds a second dimension: stock must leave the warehouse first-expiry-first-out, and no person can do that from memory across a few hundred product codes.
Consigned stock sits on shelves you do not control, in a hospital storeroom two hundred kilometers away, and it is still your asset. The system must hold both truths at the same time: it is on your balance sheet, and it is physically at the customer, available for use. It must capture usage, trigger the invoice when a unit is consumed, propose replenishment, and support counting each site without shutting down your warehouse. Most generic ERPs model none of this out of the box, and workarounds here are where distributors quietly lose stock.
For a service organization, the invoice for the machine opens a relationship measured in years: an install base entry, a warranty period, a maintenance contract, a schedule of preventive visits, spare parts, and response time commitments. Many "distribution" ERP templates end at the delivery note. Yours needs a second life after it: who owns which unit, since when, under which contract, and when the next visit is due.
Public procurement decides a large share of medical equipment revenue, and it runs on paperwork: technical specification sheets, compliance declarations, reference lists, priced forms, and hard deadlines. A tender lost on a missing document is revenue lost to administration. The system should hold the data those documents are built from and produce them without a week of copy-paste.
Feature matrices reward the wrong things. A system with three thousand features that models none of these four properly is a worse choice than a smaller system that models all of them.
Chapter 2
Disconnected systems do not fail loudly. They leak. The leak has four main channels, and each one can be estimated for your own company with an afternoon of counting.
When the quote lives in Word, the order in one system, the stock in a spreadsheet, and the invoice in the accounting package, a person carries the data between them. That person is an integration, paid a monthly salary, and like any integration they have an error rate. A transposed digit in a price is an annoyance. A transposed digit in a lot number is a traceability failure that surfaces months later, when it is expensive. Count the handoffs: every place where someone reads from one screen and types into another. Multiply by minutes per handoff and occurrences per day. That is the visible cost; the error rate is the invisible one.
First-expiry-first-out is impossible from memory. Without live expiry data at the moment of picking, warehouses ship the front row of the shelf, and the back row quietly ages out. The write-off is the visible cost. The worse cost is shipping short-dated stock to a good customer and teaching their staff to inspect everything you send. Pull your write-offs for the last twelve months and ask how many were date-driven rather than damage-driven.
A PM schedule kept in calendars and spreadsheets fails silently: nobody notices the visit that did not happen. Each missed visit is contracted work you were paid for and did not fully deliver. It exposes you to penalties and non-renewal, and in this industry the reputational cost with clinical staff outlasts both. Count the visits currently overdue against contract terms. If you cannot produce that number in ten minutes, that is itself the finding.
When operations and accounting live in different systems, finance spends the first week of every month reconstructing what the warehouse and the sales team already knew. Management then steers with numbers that are a month old by the time they arrive, and cash decisions are made late. The close is also where disconnected systems become audible to owners and banks: a close that takes two weeks says something about every number the company reports.
The quietest cost is the growth ceiling. If administration scales linearly with volume, every new contract needs a share of a new back-office hire, and the person who "knows the spreadsheet" can never take three weeks off. That is key-person risk dressed up as diligence. Put these four numbers on one page: re-keying hours, expiry write-offs, overdue PM visits, days to close. They are the baseline any system project should be judged against, and chapter 7 gives you the budget to compare them with.
Chapter 3
There are three ways to get a business system: build custom software, assemble best-of-breed tools, or adopt an integrated suite. Each is right for someone. The question is which is right at your size.
Custom software fits like a tailored suit, and the fit is real: your process, your terms, your screens. The cost is not construction, it is ownership. From the day it goes live you are a software company, usually with a development team of one contractor. The honest question is not "can we afford to build it" but "who upgrades it in year four, when the original developer has moved on and the operating system underneath has changed." Building is justified when the process is the business itself and no market product exists. For order, stock, and service management in distribution, market products exist.
A strong warehouse system, a strong CRM, a strong service tool, and a solid accounting package: each the best in its category. The seams between them are yours forever. Every integration is a small project; every vendor upgrade can break one; each new tool adds a contract, a login, an administrator, and a support queue. Large enterprises absorb this with integration teams. At ten to one hundred employees there is no integration team. There is you.
An integrated suite offers one data model. The serial number captured at receiving is the same object that is delivered, installed, serviced, and invoiced. That single fact eliminates most of the re-keying described in chapter 2. The trade-offs are real: some modules will be weaker than the best specialist tool, and suites tempt companies to implement everything at once, which chapter 9 argues against.
At distributor scale, integration cost dominates every other cost, so the suite usually wins. But choose it for its data model, not its feature count. The test is one sentence: can a single record travel from quote to order to delivery to installation to service visit to invoice without being re-entered? Ask to see exactly that, demonstrated with a serialized product that carries an expiry date, not with the vendor's clean demo data.
Our own position, stated plainly: we implement on Odoo, which is a suite, so discount our conclusion accordingly. Then apply the test anyway. It does not care what we sell.
Chapter 4
Print this chapter and score every candidate system against it. Mark each item M (must have), S (should have), or N (nice to have) for your business, and insist on seeing every M demonstrated with your own product data, not the vendor's. A requirement that has not been demonstrated is a promise.
The last item is not negotiable, whatever else you trade away. It is your exit, and chapter 9 comes back to it.
Chapter 5
The partner decision matters more than the software decision. The same product, implemented by two different teams, produces two different companies a year later. Ask these ten questions, in writing where you can, and keep the answers with the contract.
Worry if: the answer is "we will assign a team from our delivery center." You are buying people, not a logo. If the people who impressed you in the sales meetings will not be on the project, the sales meetings were theater.
Worry if: the answer pivots to what the software can do instead of what they have done. Distribution with lot, expiry, and service contracts is specific. "The system supports it" and "we have configured it, twice, here is what went wrong" are different answers.
Worry if: the engagement is a pure day rate with no cap and no defined outcome. One of the two must be fixed, or the risk of every estimation error is yours alone.
Worry if: the first demonstrable result comes at user acceptance testing, months in. Weeks of invisible work is where projects rot. You should see working software regularly; weekly is a reasonable demand, not an extravagant one.
Worry if: the answer is "you deliver clean files and we load them." Your files are not clean; nobody's are. A partner who has done this before plans for cleaning, test loads, and reconciliation, and says so unprompted.
Worry if: there is hesitation. The answer should be immediate: you keep everything built, with documentation, and you can continue with someone else. Anything else is lock-in being negotiated politely.
Worry if: training is one "train the trainer" session in the final week. Adoption fails quietly and takes the project's value with it. Training should run alongside delivery, on your data, with your processes.
Worry if: there is no named response time, or support is "something we can discuss later." Later is when you have no leverage. Go-live is the middle of the project, not the end.
Worry if: every reference is a fresh go-live. Systems reveal themselves in year two: the first upgrade, the first staff turnover, the first audit. That is the reference worth an hour of your time.
Worry if: silence. A partner who never says no is planning to bill you for your own mistakes. The right answer names something concrete they have declined before, and why.
Chapter 6
The principle that saves migrations: migrate state, not history. The new system needs to know where the business stands today. It does not need to relive the last decade.
Every migrated record must be mapped, cleaned, and validated. History multiplies that cost and imports the old system's structural problems into the new one's reports. The purpose of the project is to stop living with those problems, not to give them a new home.
Migration exposes what the spreadsheets hid: three spellings of the same hospital, lots without expiry dates, negative stock that "everyone knows about." Plan for it. Assign an internal owner for each data domain: someone owns customers, someone owns products, someone owns stock and contracts. Run at least two full test loads before cutover, and reconcile counts and values after each one. A partner who does not ask you for this time is not planning to succeed.
For lot and expiry data, a physical recount before cutover is often the only honest source. The unreliability of the old records is usually part of why you are migrating; do not launder that unreliability into the new system by loading it unverified.
Pick a quiet date, freeze changes in the old system, load, reconcile, and go. Keep the old system accessible read-only afterwards, for the lookups and the audits that will come.
Chapter 7
Distrust any plan with one date and one number on it. A defensible project has phases, each with its own scope, price, and exit. The structure below is the one we use; the logic holds whoever you hire.
Assess (about two weeks). A process and systems map, a data quality assessment, and a roadmap with fixed prices for what follows. Paying for this separately is not an extra cost; it is what makes every later number a commitment instead of a guess.
Core (about 90 days to first go-live). CRM and quoting, sales orders, inventory with lot, serial, and expiry tracking, purchasing, and accounting, integrated or migrated, with training throughout. Ninety days is long enough to do this honestly and short enough to keep the organization's attention. Plans far shorter are cutting scope they have not told you about; plans far longer are drifting toward a big bang.
Extend (a second phase, after core is stable). Field service and maintenance contracts, consignment stock, tender document workflows, integrations for payments, logistics, and e-invoicing, and management reporting.
Operate (ongoing). A support retainer with a defined response time, and the steady stream of small improvements a live system generates.
As concrete data points, our published fixed prices for this market: the Operations Audit is EUR 1,950 fixed for the two-week assessment, credited 100% against implementation if you proceed. Core Implementation starts at EUR 19,500 fixed. The Full Platform scope starts at EUR 39,500 fixed. Run & Improve support starts at EUR 1,450 per month with 15 hours included and one-business-day response, and advisory work is EUR 95 per hour with a ten-hour minimum. Other competent partners will land in the same order of magnitude for a company of ten to one hundred employees. A proposal dramatically below it usually means the missing scope will return later, dressed as change orders.
A fixed price per phase. A working demonstration of real progress every week. The right to exit at any phase boundary and keep everything built, documentation included. We commit to those three terms in every engagement; ask whoever you shortlist to match them in writing.
Data quality (chapter 6), the number of integrations, custom document volume, multiple companies or currencies, and the number of warehouses. These are legitimate price drivers; a good proposal names which apply to you and prices each.
Your own people's time. A project owner on your side spending a real share of every week, subject-matter people in workshops, staff in training, and a temporary dip in productivity around go-live. Budget that time deliberately, because it will be spent either way; the only choice is whether it is planned.
Chapter 8
Proposals fail in patterns. These ten recur. One of them in a proposal earns questions; three earn a polite refusal.
Chapter 9
Starting small is right. Companies get into trouble not by starting small but by sequencing badly: the corner they paint themselves into is almost always a data-model corner. Six rules keep the exits open.
1. Map before you buy. A two-week assessment of processes and data costs little and converts every later decision from opinion to plan. Do it even if you then do nothing for a year; the map keeps.
2. Start where the data model lives. Products, customers, and stock are the spine. A core of sales and inventory with lot, serial, and expiry tracking carries everything that comes later. Starting instead with a satellite tool, a standalone service app or a tender tracker, feels faster and simply creates disconnected system number six.
3. Make the accounting decision explicitly. Integrate with the accounting package you have, or migrate accounting into the new system. Both are legitimate. Sliding into one of them mid-project because nobody decided is not.
4. Go live in slices, not halves. A slice is a whole process working end to end for the whole company: all orders through the new system, even while service still runs the old way. What fails is the half: every module at sixty percent, no process trustworthy end to end.
5. Defer customization. Run the standard product for a few months before commissioning custom development. Live use dissolves many "must-haves" and sharpens the real ones, and every line of custom code you do not write is a line nobody maintains.
6. Keep the exits open. Your data exportable in full at any time, documentation delivered at every phase boundary, standard platform before deep customization. If chapter 4's last checklist item and chapter 7's exit terms are in your contract, you can change course at any boundary without losing what you built.
Count the systems it takes to run one order, including the spreadsheets. Pull last year's expiry write-offs and the list of PM visits currently overdue. Time your last month-end close. If you want the same reading in a structured form, the ten-question readiness assessment at nedax.net/assessment produces a score and an honest interpretation in three minutes, with no email required.
And if the numbers surprise you, start where chapter 7 starts: a two-week operations audit, fixed price, fully credited against implementation if you proceed. Whoever you run it with, you will own the map.
Nedax d.o.o.
Triglavska 12, 71000 Sarajevo, Bosnia and Herzegovina
info@nedax.net · +387 62 315 555 · nedax.net/contact