Ask a simple question inside most IBM i shops: when a document needs to go out — an invoice, a shipping label, a statement, a packing slip — what happens next?
The honest answer is usually: it depends which document.
Invoices might print and get mailed. Statements might go out by email, through a process someone set up years ago. Shipping labels run through an entirely different system because they need barcodes. Checks have their own process, with their own rules, because money is involved. Somewhere along the way, each output type accumulated its own separate way of getting designed, formatted, and delivered — and nobody ever stepped back to ask whether that made sense, because each piece worked well enough on its own.
IBM i itself isn’t the problem here. It’s handled generating this output reliably for decades. The question worth asking is whether the process around designing and delivering that output ever got consolidated — or whether it’s still running as a collection of separate systems that happen to coexist.
If any of that sounds familiar, here are five signs worth paying attention to.
1. Every Output Type Has Its Own Separate Process
This is the pattern described above, made concrete. If invoices, labels, checks, and statements each go through a genuinely different system to get designed and sent out, that’s not a reflection of those documents actually being different enough to require it — it’s usually just how things accumulated over time, one project at a time, with nobody tasked with unifying them afterward.
The real cost shows up whenever something needs to change across the board — a new logo, an address change, a new compliance requirement. Instead of one update, it becomes several, each one touching a different system, each one needing someone who still remembers how that particular piece works.
2. Changing a Document Template Means Finding the Right System First
Here’s a test worth running: if someone needed to update the layout of a shipping label tomorrow, would they know immediately which system to open — or would the first step be figuring out where that particular template actually lives?
When document design is scattered across multiple disconnected tools, “make a simple change” stops being simple. It becomes a small investigation before the actual work even starts. That friction adds up, especially for the kind of minor, frequent changes that should take minutes, not a search.
3. Fax and Email Delivery Happen Through Separate, Undocumented Steps
A lot of IBM i shops have a way of emailing or faxing documents that works, but that nobody could fully explain if asked — a script someone wrote, a workaround someone set up, a process that’s never been written down because the person who built it never left.
This tends to be invisible until that person is unavailable, or until a new compliance requirement means someone needs to actually document how delivery works today. If the honest answer is “I’m not entirely sure, but it works,” that’s worth treating as a real gap, not a quirk.
4. Labels Live in a Completely Different World Than Everything Else
Barcode labels often get treated as a special case — a separate system, a separate process, sometimes a separate vendor relationship — because they have requirements invoices and statements don’t (barcode formats, label stock, thermal printers). That’s a reasonable starting point. It becomes a problem when “special case” turns into “completely disconnected from everything else we design and send,” with no shared process, no shared template system, and no one person who understands both sides.
5. One Person Understands How All of This Actually Connects — And Won’t Be Here Forever
This is the sign that matters most, because it’s about risk rather than inconvenience.
If there’s a specific person who knows which system handles which document, how the fax process actually works, and where the label templates live — that knowledge is holding together something that should be a documented, shared process instead. It’s genuinely valuable today. It becomes a real problem the moment that person is on vacation, changes roles, or retires, and the rest of the team has to reconstruct institutional knowledge that was never written down anywhere.
The Real Question Isn’t Whether IBM i Can Handle This
IBM i has never been the limiting factor here — it reliably generates this output today, the same way it always has. The real question is whether the design and delivery layer wrapped around that output was ever actually unified, or whether it’s a collection of separate systems that happen to coexist because nobody had the time to consolidate them.
That reframes what “fixing this” looks like. It was never a question of replacing IBM i. It’s a question of whether one connected process — design once, deliver however the recipient needs it — has ever actually replaced the patchwork that grew up one project at a time.
What This Looks Like in Practice
Organizations that make real progress here treat it as a few specific, fixable steps rather than one disruptive overhaul:
- Start with whichever output type changes most often. If invoices get revised every time pricing or branding changes, consolidating that one first delivers the fastest, most visible win.
- Bring design and delivery together before touching everything else. A single place to design a template and decide how it goes out — print, email, fax, PDF — solves the “which system do I even open” problem immediately.
- Document the process as you consolidate it, so the next person doesn’t have to reverse-engineer what the current one quietly carries in their head.
Done this way, unifying document design and delivery becomes a steady, incremental improvement — not a disruptive rebuild, and not something that touches the IBM i applications generating the underlying data in the first place.
If any of the five signs above sound familiar, it’s worth taking a closer look at how many separate systems your organization actually relies on to get a document out the door — not because IBM i needs to change, but because the process wrapped around it usually hasn’t been looked at as a whole in years.
