Printing Company Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does estimating get scoped as a pricing table?

Because that is what a pricing screen looks like from the outside. Stock, quantity, colours, finishing operations, a rate per hour, a total. It is a reasonable description of a simple job and it is how every off the shelf estimator is built.

The trouble arrives with the work you actually want. A repeat customer orders six variants of a packaging insert, different quantities, same stock, same colours. Ganging them onto one large sheet saves two makereadies and a meaningful block of press time. Your estimator knows this. A system that models an estimate as one job on one imposition cannot, so the six get priced separately and discounted by hand to reflect the gang. The same failure shows up on versioned work, on customer supplied stock, and on anything where the cost driver is decided after the quote goes out.

This is specific to commercial printing because the price is quoted before anyone knows what the job will cost to make, and the biggest lever on that cost is how work is combined on a sheet.

The fix is a data model, agreed before anyone quotes the project. An estimate references components, each with stock, ink, finishing operations and quantity. An imposition planner takes any set of components and returns candidate press plans with real sheet counts, makeready counts and waste. The estimator picks a plan, and the quote, job ticket and cost baseline all derive from that plan object. Ask a prospective developer to model a gang run on a whiteboard. If they cannot explain how one press sheet carries components from three jobs and how cost is allocated back, they have not built this.

What goes wrong with job history and the estimator's spreadsheet?

Two migrations matter here and only one of them is a data export.

Job history comes out of your management information system database directly, and it is the most valuable thing you own, because it seeds real speed and waste tables per press per stock category rather than vendor defaults. What makes it awkward is that history reflects how jobs were recorded, not how they ran. Operations never clocked appear as zero time. Jobs that went sideways look identical to clean ones. Stock codes have been superseded twice. Loading it uncritically encodes your worst reporting habits as production standards.

The second migration has no export at all. Your estimator's private workbook holds the exceptions, the fudge factors and the knowledge that the folder jams on heavier text stock. That has to be interviewed out of his head, rule by rule, and he is also quoting all day.

The fix on history is to clean before you calibrate: exclude jobs with obviously incomplete capture, segment by press and stock category rather than averaging across the plant, and have a pressman review the standards for his own presses before anyone quotes from them. The fix on the workbook is to schedule it as real work, several sessions across the project rather than one meeting, accepting that some of it only surfaces when a quote from the new system looks wrong to him.

Why do press, paper and management system integrations break after launch?

The integrations that make a print system honest are the ones nobody owns after go live.

Press data is the first. Equipment supporting job definition format messaging emits counts and state changes, and older equipment gets a counter tap on the delivery. Both drift. A press is re commissioned after a service and the configuration reverts. A counter tap loses power during a shutdown and nobody notices, because the pressmen were never relying on it. The press keeps producing good sheets, so the failure is silent and job costing returns to guesswork on that machine.

Paper supply is the second, and it breaks the schedule rather than the costing. A merchant changes how confirmed delivery dates arrive, or a rush purchase order is raised outside the system, and the schedule stops knowing that stock for a job is on a truck. A scheduler that does not consume inbound stock receipts is a Gantt chart.

Third, if you kept your existing system for invoicing, that handoff has to survive its upgrades and your own changes to customer codes and general ledger mapping.

What to require: a per press data quality report showing the proportion of jobs with complete machine capture, reviewed weekly by the plant manager. An alert when a press that normally reports stops. Stock receipt exceptions surfaced to a named buyer rather than silently ignored. And a written owner for each integration, because a print floor at capacity has nobody spare to investigate a quiet failure.

What happens when floor capture and shipping are left out?

These two get deferred to a later phase and they are the two that decide whether the numbers are real.

Shop floor capture fails when it is designed as a clocking exercise. A pressman on a tight schedule clocks in at shift start, forgets the changeover and clocks out at the end, and the terminal is thirty feet from the press anyway. Job costing then shows an eight hour job that took two, and the jobs it gets most wrong are the ones that went sideways, which are the ones you needed to understand. Policy does not fix this, because the pressman's job is to make good sheets.

Shipping fails for a different reason. Commercial print shipping is not parcel shipping. One job goes to four addresses in different quantities, some on skids by less than truckload, some by parcel, one overnight, with a packing list per drop referencing the customer's own purchase order lines. If the distribution plan is not part of the job record, a clerk rebuilds it in a word processor every time and sorts a spreadsheet row into the wrong address about once a month.

The fix on capture is to take from the machine what the machine already knows and ask the human one question when something anomalous happens, with a few buttons, in two seconds. The fix on shipping is distribution plans as first class objects on the job, with quantity splits by destination, carrier rules, rate shopping and labels and bills of lading generated from the plan. Extraction of the customer's distribution list from whatever format they emailed removes the retyping that causes most wrong address shipments.

Should you build custom or configure what you already own?

A good number of shops should configure rather than build, and the test is volume and how you sell.

PrintSmith Vision is a reasonable fit for a single plant shop under roughly 150 jobs a week doing conventional sheetfed and digital work, where the estimator can hold the exceptions in his head. Printavo suits smaller shops that mostly want quote to invoice flow without a plant scheduling problem. If that describes you, building is a poor use of a hundred thousand dollars. Configure it properly, re cost your rate tables against recent actuals, and put the money into a press.

EFI Pace, Avanti Slingshot and Tharstern are all capable systems of record and worth configuring fully before you conclude they cannot do the job. The honest limitation across the category is the pricing engine: it assumes one job on one imposition, and that assumption is structural rather than a setting.

Build when two or more of these hold. Your estimator maintains a private spreadsheet that overrides the system, and if he left tomorrow you could not quote accurately. Your real press schedule is a whiteboard. Your job costing reports are ignored in management meetings because everyone knows the labour data is unreliable. You are losing gang run or versioned work because you cannot price it fast enough. Or you have added a second plant and the two cannot see each other's capacity.

How do hidden costs get into the quote?

These are the lines that move a print software number.

• Distinct press and finishing configurations. Sheetfed, digital, wide format and a bindery are several cost models, not one. Count them before pricing.
• Machine integration depth. Full job definition format messaging against a press controller and a counter tap on an older machine are different amounts of work, and a quote should say which applies per press.
• Multiple plants with work sharing, which turns scheduling from a queue into an allocation problem.
• Web to print storefront integration, where orders arrive pre configured and have to map onto your component model.
• Accounting integration that is not the simple case, since an enterprise finance system is a different exercise from a small business ledger.
• Regulated work. If you print statements or targeted mail carrying personal or health information, encrypted storage, access logging and defined retention are design requirements, not later additions.

In Digital Heroes delivery experience, a focused first release covering the estimating engine, job ticket and press schedule with real machine data runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding shipping and distribution, shop floor capture, a customer portal and accounting integration runs $150,000 to $400,000 phased over 6 to 12 months.

What separates a build that works from one that fails here?

Four habits, and the first is sequencing.

They keep the existing system for invoicing through the first year. Most shops do not need to replace the financial system, they need to stop pricing blind, and separating those two decisions keeps the first release small enough to finish. It also avoids a financial cutover during production, which nobody has appetite for once it is described honestly.

They phase the rollout, because a printer cannot stop printing while a system is replaced. Estimators run in parallel for a quoting cycle before anyone relies on the new numbers, and the plant moves onto the schedule only after the estimating side is trusted. Any plan that requires a single cutover weekend should be rejected on that basis alone.

They ask humans for as little data as possible. Every field a pressman has to fill is a field that will be filled inaccurately under pressure, and the pressman is right to prioritise the sheets. Take counts and state changes from the machine, and reserve the human interaction for the reason a stop happened.

And they let the standards correct themselves. Once actuals flow from the presses, the speed and waste tables should update from your own results rather than waiting for an annual re costing project nobody schedules. That feedback loop is what keeps the estimating accurate two years after go live, and it is the difference between a system that pays for itself once and one that keeps paying.