This is the working version of the Globis white paper on software selection: the questions to ask on each of the five dimensions, and the evidence to demand for each. It is meant to be opened while you are running a selection, not read once.
For the argument behind it — why four of the five dimensions get less attention than they deserve — read the article. For a version you can print and hand round a selection committee, download the PDF.
13 pages, formatted for printing and circulation. No form, no email address required.
Use it in three passes
Finish the first pass before you meet any vendor. The most common process error is collecting evidence before deciding what matters.
Set the bar, then score what you have
Start from where the business must be in one, five and ten years. Derive the score you need on each dimension and weight them — explicitly and together, because a CIO loads technology and a COO loads functional fit and both are right about their own column. Then score your current systems and current vendor against that bar.
Score the candidates on the same scale
Same dimensions, same weights, same bar. Not who scores highest overall, but who moves you furthest against the goals from pass one. A candidate who clears the bar on the two heaviest dimensions beats one who scores respectably on all five.
Demand the evidence — only now
Everything in pass two is a claim until someone makes it hard. A scripted demo shows what was rehearsed; a workshop on your own processes or a proof of concept on your own data shows how the vendor behaves when the material is unfamiliar. Bring what they have not seen.
1. Functional fit
What the platform handles for your operation.
Usually raised by the COO or operations lead
Ask
- Where do our current systems slow the operation down, and where do they keep up?
- Which processes would we redesign if the software allowed it? Most operators have quietly shaped a process around a system limitation and stopped noticing.
- What do our customers come to us for that they could not get from the operator down the road — and how much of that sits in flows no standard system expects?
- How much configurability do we need, as opposed to how much functionality? These are routinely conflated. Standard A-to-B work needs a system that does those processes well and little more; winning work on awkward handling needs a system that can hold it without a development project each time.
- Which kind of organisation was this software designed around — a shipper controlling its own transport, or an operator selling logistics? A shipper system accounts for cost. An operator platform has to know revenue, cost and margin per shipment and invoice a different contract per customer.
Evidence to demand
Have them configure your most awkward exception live, not describe it. Then ask who could have done that: their consultant, or your own team.
2. Technology
How it is built, how it integrates, how it scales, how it ages.
Usually raised by the CIO or CTO
Ask
- Where in our current stack is there maintenance debt that limits us — not what it cost to build, but what it costs to keep from breaking?
- What does the platform support across the full range: file exchange, which is not obsolete and is still how a large part of the chain works, APIs, message queues, event streaming?
- When a new customer arrives with their own format, can our own people build and monitor that interface — or is every connection a vendor project with a price and a queue?
- Do an order, a handling and an invoice line point at the same underlying object, or at three copies someone reconciles afterwards? That is the difference between a report you run and a report you rebuild.
- If we bring further business units, entities or countries onto the platform, can it carry that — and what has it already carried elsewhere?
- Can they prove security rather than assert it: ISO 27001 certification, third-party penetration testing, documented incident handling?
- What does “future-proof” mean for our operation, tested against a change we can already see coming rather than answered with adjectives?
Evidence to demand
The upgrade history of a heavily configured customer across three versions, and a security certification rather than a security slide.
3. Strategic alignment
Whether the vendor is going the same way you are.
Usually raised by the CEO or CFO
Ask
- What is on the roadmap — and what have they deliberately decided not to build? The second answer is the more informative one.
- Does their strategy rest on a deep configuration layer? That asks more of the implementation and gives you a system your own people can reshape. Excellent with an IT team that can carry it; a poor trade if you want the fastest implementation and will adapt to the standard.
- Vertical depth, or one record across activities and partners with less depth in each? Neither is right in the abstract — the question is which matches how we intend to run the business over ten years.
Evidence to demand
The roadmap, and something they deliberately decided not to build — with the reasoning.
4. The vendor
Who stands behind the platform, and for how long.
Usually raised by the CEO or CFO
Ask
- Who is at the table now, and who will actually run our implementation and take our call in year four? Can we meet that second group before signature — and is the request easy or awkward?
- Which references operate in our model? Context beats count: three in your operating model tell you more than a hundred in someone else’s.
- Where on the vendor-scale range do we want to sit? A five-person supplier can fit perfectly and still leave you exposed — thin bench, dependence on one or two individuals. A global vendor gives resources and continuity, and makes you one account among several thousand on a roadmap you cannot influence.
- Over ten years something will go badly wrong. Do we need to be able to phone a named person who can make a personal commitment about the fix — and at what vendor size does that stop being realistic?
- Ownership structure, funding model, and what happens to roadmap priorities after an acquisition. Legitimate criteria, not impolite questions.
- What does your product not do? A vendor who cannot name a single boundary either has not thought about it, or plans to tell you later as a change request.
Evidence to demand
A reference that operates like you do, spoken to without the vendor in the room, asked about the worst month of the project and what the vendor did about it.
5. Implementation method
How the vendor turns your operation into a working system.
Usually raised by the COO or IT lead
Ask
- How is the translation from our operation into requirements organised? Serious answers have a shape: milestones decomposed through capabilities to features, test scenarios written from the business process rather than from the software, every feature through the same four phases — design, develop, configure, deliver — so “done” means the same thing every time.
- Who configures what, now and in three years? There is no single right model, but the split has to be designed against the capacity we actually have, written down before signature, and expected to move: mostly vendor at the start, progressively less.
- Is knowledge transfer a deliverable in both directions — they learn our operation, our team learns the platform well enough to change it? Both usually happen by accident, if at all.
- To a reference: how much do you configure yourselves now, and how long did it take to get there?
- What is the migration sequence? In logistics you cannot stop the trucks while you cut over, which makes this a design problem rather than a project-plan detail.
- Which outcomes are defined before signature — adoption, margin visibility, reduced manual work — rather than negotiated afterwards?
Evidence to demand
The requirement structure and test scenarios from a comparable implementation, and the proposed split of configuration work for your case.
The question that runs across all five: AI
Not a technology question. It touches rate of change, how the software gets built and supported, how requirements get produced, and what your people see in the screens they use all day.
Usually raised by everyone — and therefore nobody
Ask
- What runs in production today, at a named customer, and what is roadmap? The gap between vendors experimenting and vendors shipping is wide right now and invisible in a demo.
- What did you stop doing manually in the last year?
- What happens to our data — does it train anything, where does it run, who can see it? That is a procurement question as much as a technology one, and the answer is usually available in writing or not at all.
Who needs to be in the room
Each role enters the evaluation at a different dimension. That is healthy. It is also where selections quietly go wrong: everyone evaluates thoroughly inside their own area and assumes the rest is covered.
| Dimension | Who naturally enters here |
|---|---|
| Functional fit | COO, operations lead |
| Technology | CIO / CTO |
| Strategic alignment | CEO / CFO |
| The vendor | CEO / CFO |
| Implementation method | COO, IT lead |
| AI | Belongs to everyone’s column — and therefore to nobody’s |
Where each role naturally enters, and the question that falls between them.
The test of a sound selection is not that all five were examined, but that the answers were compared in the same room. The functional lead’s enthusiasm and the CIO’s reservations are data about the same decision.
The full white paper, with the reasoning behind each dimension: 13 pages, no form.
Karel Van den Berghe is founder and CEO of Globis Software, a platform for logistics service providers handling complex cargo flows. These are the questions we use on strategic software decisions ourselves, and the ones we expect to be asked. Disagreement welcome.
Cookie Policy