InsightsBuyer’s guides

Buyer’s guides

16

modules, each a category rather than a capability

How to read a vendor’s module list without being misled by it.

A module list is a table of contents, not a scope. Two systems that both say ‘procurement’ can differ by an order of magnitude in what the word covers. A short guide to reading the list the way an implementer does.

· 1 min read

Stackmark documents sixteen modules and records, for each system, which of them the vendor offers. The counts are useful for narrowing a field. They are useless for choosing between the last three systems on a shortlist, and it is worth being clear about why.

A module name is a category, not a capability

‘Inventory management’ can mean a stock quantity on an item record, or lot and serial tracking with landed cost and cycle counting across bonded warehouses. Both vendors are telling the truth when they tick the box. The buyer’s job is to find out which truth.

The module pages on this site carry demonstration questions for exactly that purpose. They are written to be asked in order, because the later ones assume the earlier answers.

Three readings of the same list

  • The marketing reading: every module is a strength. Ignore it.
  • The implementer’s reading: which modules are native, which are partner products relabelled, and which are a connector to someone else’s system. Ask this directly.
  • The finance reading: which modules post to the ledger natively, and which post through an interface that will need reconciling. This is the one that decides month-end.
Ask which modules were built by the vendor, which were bought, and which are somebody else’s product with the vendor’s logo on the login page.

What to write in the requirements

Do not write ‘procurement’. Write the three things procurement has to do in your business that it does not do today, and the two it must keep doing. A requirement stated as an outcome cannot be satisfied by a tick.

On this site

More notes

Keep reading.

All insights