Productive IT / Business Operations & ERP briefing · 2026-09-10

The signal

Many established businesses still run critical processes (billing, inventory, settlement, payroll) on mainframe or other long-lived core systems. The headline risk usually discussed is the age of the technology. The quieter risk is the age of the knowledge: a handful of people know why a batch job runs at a certain hour, why a field is overloaded with two meanings, or which exception is handled by a manual phone call. When those people move on, the organisation loses the explanation, not just the code.

What it means for a growing business

You do not need a mainframe to have this problem. Any company that has grown through spreadsheets, a legacy ERP configuration or a heavily customised accounting tool carries undocumented business rules. A modernisation project, whether it is a cloud migration, an ERP replacement or an automation programme, tends to surface them late and expensively, usually as a defect in production that nobody can explain.

Treat the knowledge gap as a project risk with an owner, not as a documentation chore. Three questions help size it:

  • Which processes depend on one or two named individuals?
  • Which rules exist only in code, in a configuration screen or in someone's memory?
  • Which outputs would the business notice within a day if they were wrong, and which would it notice only at month end?

The Productive IT view

  • Interview before you inventory. Start with the people who run the process each week. Ask them to walk through a normal day and then the last three exceptions. Exceptions reveal the real rules.
  • Record rules in plain language. A one-line statement such as "orders above the credit limit are held until finance approves" is more durable than a diagram nobody updates.
  • Test with real cases. Capture a set of representative inputs and expected outputs from the current system. They become the acceptance test for whatever replaces it.
  • Pair, then shadow. Let a newer team member work alongside the expert for a full cycle, including month end, before any cut-over decision.
  • Migrate in slices. Move one process at a time, keep the old path available, and compare outputs side by side before switching off anything.

Common mistakes to avoid

The first mistake is treating documentation as a one-off exercise that finishes before the project starts. Business rules change every quarter, so whoever owns the process should own the written rule and review it on a schedule. The second is assuming the vendor or the new platform will "discover" the rules during configuration. Tools can only implement what someone has specified. The third is leaving the experts out of testing. The people who know the odd cases are exactly the people who can tell you whether the new system handles them, so give them a real role in user acceptance, not a courtesy invitation.

A practical next step

List your five most important operational processes and, next to each, write the names of the people who truly understand them. If any row has fewer than two names, begin knowledge capture there before you plan the technology. If you want a second pair of eyes on that exercise, start a brief with Productive IT and we will help you map the workflow and the exceptions first.

This is original Productive IT commentary on a widely discussed theme. It makes no claim about any specific vendor, product or client.