Printing a report to type it into another system

Somewhere in most businesses over ten years old, a report is printed so that a person can key it into another system. Everyone involved knows this is absurd. It persists anyway, and not because anyone is careless.

How it gets there

Two systems are bought years apart. Neither vendor has much commercial interest in connecting them. When someone finally asks, the integration is quoted at a price that exceeds the cost of the manual work for several years, and often requires an upgrade nobody has budget for. So the manual step gets adopted “for now”, and then it is simply how the process works. New staff are trained in it.

The tell is that nobody can say when it started.

Look for the narrowest bridge

A full integration is rarely the only option. Most systems of that age can already do two useful things: write a scheduled export to a folder, and accept an import file in some specific format. Neither vendor calls that an interface, but between them there is usually only a small mapping problem — codes, units, and a handful of records that exist on one side and not the other.

That is a week or two of work rather than a capital project. It is not elegant. It removes the printer.

Design for the mismatches

The mapping is where these bridges fail, and it fails through drift: a code changes and nobody tells the script. So give the mapping table to the team who knows when codes change, in a format they can edit, and treat anything unmatched as an exception to report rather than a value to guess at. Two or three held-back lines a week is a healthy sign. Zero usually means something is being silently coerced.

Then leave the manual path in place. A bridge that can be bypassed on a bad afternoon is one people will trust; one that cannot is one they will quietly work around, which is where we started.