How we work out what your system needs — and what it will cost

On a discovery call, a business tells us how it runs and what it needs a system to do. Some of that is general — the modules in use, the connection to Xero. Most of it is particular to the business: a customer who won't accept stock under a minimum shelf life, freight that arrives on a separate invoice.

After the call, the next thing the business receives from us is a document. The first part describes their operation as we understood it: how orders arrive, how stock is held and moved, what production or despatch involves, what reaches the accounts and how. It's written from the call and from what the business shows us — the spreadsheets, the documents that go to customers and suppliers, the reports someone builds at month end. The second part sets out what the system will do about each of those — what gets configured and, if anything, what gets built. The third is what it will cost. Nothing is configured or built until it has been agreed.

If we've misunderstood something, or missed what matters, it shows in that first part and is corrected there, before anything has been setup.

How each requirement is met

For each requirement, the document gives one of three answers.

The standard platform already does it. Every system has the whole platform, so a good share of the requirements are met before any tailoring starts.

A setting gets it there. Configuration is part of every implementation and is where most of the fitting happens: fields and forms for what the business records, documents in the format customers and suppliers already receive, reports showing the figures the business uses, and stages, price lists and terms set up to match how the business sells and makes. It also covers switching off a module or a screen the business won't use.

Or configuration can't reach it. Some requirements are specific to the business — a calculation particular to how they price, or a file from a supplier that the system has to read — and settings won't get there. That's written down as a piece of development, scoped against that process and priced by the technical effort involved.

The delivery and freight piece shows all three on one requirement: apportioning costs into product cost was standard, the itemised cost list was configuration, and keeping the total updated when orders were saved or copied needed two small functions. The document is where that split is made and agreed.

Scoping sometimes moves a requirement from one answer to another. What looked like development turns out to be a setting; sometimes the reverse.

What it costs

The implementation fee covers the work of setting the system up: workshops, configuration, data load and go-live. Where the document identifies development, the amount for it is added and agreed at the same time. Most implementations include some. We build only the part the platform and its settings can't handle, and it's usually a small piece of work.

The figure is a budget. Implementations don't always run exactly to it, and when one is tracking over or under, the customer hears early.

Workshops

The document is agreed with the people who commissioned the system. The workshops that follow are with the people who'll use it. A project manager works through each area of the operation with the people who run it, and the system is configured area by area as they go.

That's a finer level of detail than the document, and specific requirements sometimes surface there that didn't come up at discovery. Most are met with a setting and go into the configuration as part of the work already agreed. Where one needs development, it's scoped and priced the same way as in the original document, and agreed before it's built.

After go-live

The document describes the business as it was at discovery, and businesses change. Small adjustments — a new field, a report change, hiding something no longer used — are part of the ongoing service. Larger changes arescoped and quoted separately.

The customer can check our understanding of their operation and see what we're proposing, including the budget, before agreeing to the implementation. How the work runs from there is on our configuration and customisation page.