Vendor support for Fourth Shift has narrowed to a sliver as the product reaches the end of its roadmap. For many plants the alternative has been a support arrangement that grows more complex and more expensive every year, and leaves the plant less able to run its own system. It doesn't have to be that way. We document your system, install monitoring so nothing fails silently, stabilize and improve what's hurting, and — if you want it — apply the Transformation module to make Fourth Shift work for your business again. On a fixed, affordable retainer. You own the system. Simplicity is the deliverable.
Fourth Shift is a good system. We've been saying that for thirty years and we'll keep saying it. It is also a product whose vendor roadmap has, understandably, run its course: Infor's investment has moved to its current platforms, and the Fourth Shift-specific depth available through vendor channels has narrowed to a sliver. That's the normal life cycle of a thirty-year-old product, not a failing, and we work alongside Infor and its partners wherever that's the right answer for a client.
The practical consequence is that Fourth Shift expertise now lives with a handful of people who have worked inside the system for decades. And into that gap has come a style of support that many plants recognize: every fix arrives as another custom program, every custom program needs the provider to maintain it, the monthly number goes one direction, and after a few years nobody on the plant's side understands their own system anymore. Dependence isn't a side effect of that model. It's the model.
We run the opposite model. The measure of a support engagement is whether your team understands the system better a year from now — with documentation they can read, monitoring they can see, and fixes that are simpler than the problems they solve. If we've done the job, you need us less, not more.
In that order, because each step makes the next one cheaper — and because the first three are what most plants have never actually received from support.
Every custom program, Data Import template, VisiBar script, interface, scheduled job and configuration decision — what it does, who depends on it, and whether it needs to exist. Most plants get the first real documentation of their environment out of this step. It's yours to keep.
Night processing watched for failures and duration drift, backups proven by restore, disk and job health graphed, integrations that go quiet raising an alert. Your IT sees the problem first. How monitoring is done →
The month-end that won't close, the MRP nobody trusts, the cost roll that's wrong, the customization that breaks every patch. Fixed at the mechanism — usually a configuration afternoon, not another custom program. Simplify before you extend.
The Transformation module: a business process review with evidence-graded findings, measurement contracts, and a scoreboard reading your own GL. Optional, and only after the system is stable. The review →
Nobody is named here, because the pattern is what matters. Score your current arrangement honestly.
| The question | The dependent model | How we work |
|---|---|---|
| Who has the documentation? | The provider. You have a phone number. | You do — a written inventory of every custom object, job and setting, delivered in the first month. |
| How does a fix arrive? | As another custom program only the provider can maintain. | As the simplest thing that holds — usually a configuration or process fix. Customization is the last resort, and it's documented. |
| How do you find out something failed? | From accounting, three days later. | From monitoring your own team can see, with the log line and the runbook attached. |
| What happens to the monthly number? | It goes up as the customizations pile up. | Fixed retainer, in writing, sized to the environment. Most value delivered up front. |
| After a year, does your team understand the system better? | Less. That's the business model. | Better. If you need us less next year, we did the job. |
| Can you leave? | Not without a migration. | With notice. Everything we build is documented and ordinary; any competent shop can pick it up. |
A transition starts with us doing nothing to your system except reading it. Documentation and monitoring go in first, so nothing fails silently during the handover and you get something valuable whether or not you switch. Your existing arrangement can run in parallel for as long as you like. When you're comfortable, stabilization starts on the things that are already hurting. Nobody re-implements anything.
If, after the discovery call, you're better off where you are, we'll tell you that. We don't get paid more for finding problems.
What you're paying for, what you're getting, and what's still broken. If you're better off where you are, we'll say so. If you're not, you'll get a written proposal with a fixed monthly number and no long-term lock-in.
You'll get a straight answer and a tight scope. If we can't help, we'll tell you that too — and usually who can.
