Godwit AI Labs Talk to us

HomeServices › ERP & CRM

One process area, not one go-live date

These rarely fail on the software. They fail because the process was never agreed, the data was migrated dirty, or the whole estate was pointed at one date. We take one process area, agree the scope in writing, and then stay for the part that lasts years.

HOW IT GOES LIVE one area at a time process areas in the estate 1 phase one, in production and reconciled, then the next WHERE THE COST IS Implementation 8–12 weeks, fixed scope Maintenance for as long as you run it
One area live at a time · the bars are to scale, which is the point
Fee
Fixed-scope implementation + GST · then an AMS retainer sized on the estate
Platforms
SAP ABAP, Salesforce, Zoho
First phase
One process area, 8–12 weeks
Then
AMS retainer, monthly
01

The software is rarely what fails

Talk to us about this

By the time we are called in, the licences are usually bought and the platform is usually fine. What has gone wrong is somewhere else: two departments describe the same approval differently and the configuration had to pick one, the opening balances never reconciled against the old system, or the go-live covered every site at once because that was cheaper on the implementation quote.

So the first thing we do is not configuration. It is agreeing, in writing and with the people who actually perform the work, what the process is, including the exceptions everyone handles by hand and nobody mentions in a workshop.

1 areafirst, not the whole estate on one go-live date
8–12 wksfor a first phase that a business can actually absorb
Yearsis how long the maintenance lasts, which is where the money goes
02

ERP and CRM implementation: what we work on

Talk to us about this
  • SAP, including ABAP. Implementation and rollout work, plus the development and extension side: reports, interfaces, conversions, forms and the custom objects a business genuinely needs. And an honest read on which of your existing customisations should be retired rather than carried forward.
  • Salesforce. Sales and service implementation, the integrations that make it the system of record rather than a second place to type things, and the adoption work without which a CRM becomes an expensive contact list.
  • Zoho. Frequently the right answer at this size and rarely the one that gets proposed, because it is the least profitable to implement. Where it fits, we will tell you it fits.

Those three are what we do. If your estate runs on something else, we will say so and point you at someone who does it properly rather than learning it at your expense.

03

Implementation is the short part

Talk to us about this

A first phase is eight to twelve weeks. The maintenance runs for years, and it is where most of the total cost of an ERP or CRM actually sits: small changes, new users and roles, the quarterly platform releases that break an integration nobody remembered, month-end problems that need somebody who knows the configuration.

That is a retainer, sized on the estate rather than on a list price, and it is quoted at the same time as the implementation. A project team that disbands at go-live is how a working system becomes an unowned one.

04

What we will tell you not to do

Talk to us about this
  • Do not customise what configuration already does. Every custom object is a thing you pay to test at every future release. The question is not whether it can be built, it is whether you want to own it for a decade.
  • Do not migrate data you have not cleaned. Duplicated customers and unreconciled balances do not become correct by moving to a better system. They become correct in a better system that nobody trusts.
  • Do not go live everywhere at once. One area, one site, one month-end survived. Then the next. A single date for the whole estate is cheaper to quote and considerably more expensive to recover.
DELIVERABLES

What you walk away with

Yours to keep, and to hand to anyone else, including a provider that isn't us.

Talk to us about this
A phase that went live

One process area working in production, with the people who use it trained on it, not a sandbox waiting for phase two.

Your data, reconciled

Migrated with the counts agreed and signed off against the old system, because a migration nobody reconciled is a dispute waiting to happen.

The configuration, documented

What was configured, what was customised, and why each customisation exists. This is the document that decides whether your next upgrade costs weeks or months.

Somebody to call afterwards

Support, small changes and the quarterly platform releases handled on a retainer, rather than a project team that disbanded at go-live.

QUESTIONS

Asked before you ask

The ones that come up on nearly every first call.

Talk to us about this
Do we need to replace our ERP?

Usually not, and that is the most common honest answer to this question. Far more often the platform is adequate and the problem is a process that was never agreed, a module that was bought and never configured, or reporting that nobody maintained. A replacement is the most expensive way to fix any of those. If a replacement genuinely is the answer we will say so, and we will say what it costs to run afterwards rather than only what it costs to install.

You name three platforms. What if ours is different?

Then we are the wrong people for the implementation and we will tell you that in the first conversation. We would rather refer it than learn your platform on your project. Where we can still help is around it: the integrations, the data work, the hosting and the support model, and we will be explicit about which part we are doing.

What does the maintenance retainer actually cover?

Support for the people using it, small changes and new reports, user and role administration, the quarterly platform releases and regression-testing what they touch, and month-end support when something does not reconcile. What it does not cover is a new process area or a new module: that is another phase, scoped and priced as one, and we will say so rather than absorbing it and slowing everything down.

Who owns the customisations and the documentation?

You do, from the first day. The configuration workbook, the custom code, the interface specifications and the migration reconciliations sit in your systems and your repository. If you move to another partner they get a documented estate rather than an archaeology project, which is the position we take on every service here: leaving us should be boring.

Can you take over an implementation somebody else started?

Yes, and it is a common way this starts. The first two weeks are an assessment rather than a rescue: what was configured, what was customised, what the data actually looks like, and what is genuinely finished versus reported as finished. You get that as a written position with a costed way forward, and it is useful even if you then decide not to use us.

Not sure this is the one you need?

Tell us the symptom, not the service, and we'll say which of these applies, or that none of them do. A reply within one working day, from someone technical.

Talk to us