Services05 · Implementation and support

Make sure new software supports the way the work has to run.

A software project needs more than a list of features. It needs business requirements that say what has to happen, who is responsible and what the system must not let through, and a way to check the build against them. Your implementer builds and configures the software. We work on your side of it: writing those requirements and testing whether they have been met.

01 · When this can help

When this can help.

01You are selecting or implementing business software and need clear requirements from the people who will use it.

02The software records completed work, but important approvals, checks or responsibilities still sit outside it.

03An implementation has stalled, or teams rely on spreadsheets and workarounds to keep it running.

02 · How we work

How we work.

01 · Phase one

Agree the business requirements

Map the agreed workflows with your team. Define what must happen, who owns the data, which decisions need approval and what evidence the software must retain. Platform selection is included only where needed.

02 · Phase two

Give the implementer a clear brief

Translate those needs into a specification and acceptance criteria. Your implementer builds and configures the software; we review it against the agreed requirements on your behalf.

03 · Phase three

Test readiness for use

Test normal and exception cases, record gaps and support your readiness decision. Agree who owns migration, training, security, hosting and support, with our involvement, where there is any, stated in the scope.

03 · What you get

What you receive.

The proposal confirms the outputs, boundaries and responsibilities for your engagement.

A documented business scope, with selection criteria or a platform recommendation where agreed

Workflow maps and requirements covering approvals, responsibilities, information and exceptions

A specification and acceptance criteria for your implementer, not a software build we supply

A test and findings register, with evidence, owners and unresolved issues visible before sign-off

A readiness and handover plan; user guidance, training or later assurance where included in the agreed scope

Discuss this problem →

04 · Is this the service you need

Scope, and what this is not.

We do not build the software. Development and configuration sit with your implementer or a vendor you select, and that is deliberate: it keeps the people who check the build independent of the people who wrote it. Migration, security, hosting and ongoing support are assigned explicitly in the project rather than assumed from this page. If a vendor is already contracted, the same work runs as a readiness engagement beside them.

05 · An example of the work

23 · 147 · 200

One engagement covered 23 ERP modules, a 147-row process-to-ERP map and 200 recorded findings, including four structural gaps outside the vendor’s build scope. These figures describe specification and testing work, not a promised implementation result. Read the engagement example →

06 · Questions clients ask first

The questions clients ask first.

Which platforms?

We are vendor-neutral, with recent work on Odoo. Requirements and acceptance testing can be scoped around your chosen platform. Platform-specific configuration and development remain with a suitably capable implementer.

Who does the technical work?

Your implementer builds and configures the software. We define the agreed business requirements and checks the build against them. Technical responsibilities, including migration, security, hosting and ongoing support, must be assigned explicitly.

What about our existing implementer?

We can work alongside your existing implementer, with a clear division of responsibilities. If you have not selected one, supplier selection support can be included. You do not need to restart the entire project to scope a focused review.

Already contracted a vendor?

ERP readiness, alongside your implementer.

An existing contract does not prevent a focused readiness review. Your vendor continues the build; we help you identify unresolved business requirements, ownership questions and test evidence before you make a sign-off decision.

Process readinessCheck that the specification reflects the agreed work, approvals and exception paths, and make any gaps clear to the implementer.

Data and ownership readinessIdentify who owns key data, who can approve decisions and which access roles need to be agreed before migration and testing.

Acceptance on your sideTest whether required information and approvals can be bypassed, and whether records can be changed or deleted inappropriately. Record the evidence and unresolved findings for your sign-off decision.

People readinessIdentify the procedures, guidance and training users need for the agreed workflows. Assign owners and dates for the remaining readiness actions.

Optional: the method behind the work

The thinking behind it

The method, for anyone who wants it.

Requirements may cover mandatory fields, named approval roles, status locks and retained evidence. Acceptance testing checks those rules with normal, missing-information and exception cases. A passed test provides evidence about the cases tested; it does not guarantee the absence of all defects.

Fig. 01. Developed, and implementedDeveloped

The system as developed

The management system as designed and written.

Complete, coherent and signed off.

System re-design Process optimisation

Tell us what is happening at your workplace.

Start with the problem, not a service name. We will discuss whether we can help, what information is needed and what a sensible next step could be.

Tell us what is happening →