I have an unusual perspective when it comes to print businesses. I look at print businesses from the perspective of the business software they are utilizing. When I talk to printers, I immediately want to know about their current software “technology stack”—that’s the term I use for the set of software solutions that you are running your business on. Generally, I first want to know about your Print MIS/ERP + accounting package (foundational), then ecommerce/web-to-print, then prepress automation, CRM, etc.

I realize most people don’t think this way. Even a lot of people in the print software business don’t think this way. I’ve had lots of print software sales people tell me that I slow down their sales processes by overcomplicating it. This is in reaction to me asking the questions about what other software solutions are present at the printer and which ones are staying and which ones are on their way out. I ask these questions because you can’t make a good decision about software unless you know what other software is already in the business. I’m interested in helping printers make good decisions about print software. Making a decision about one software solution without considering the other software solutions would be like buying a door for your home without knowing the dimension of the door frame.

Print software solutions need to work and play together well—you know, like kindergartners are expected to do on the playground. One unsaid thing in our industry is that there are moving boundaries in the feature sets of software solutions. Each product team listens to their user community and keeps adding features. At some point features from one of your software solutions overlaps or is duplicative of another software solution. Lots of printers live with this today; you can do imposition within some Print MIS/ERPs, on some digital RIPs, in a standalone imposition tool, in a prepress automation tool, or as part of some web-to-print packages. There is no inherent problem with having this capability in multiple places. In fact, there are valid use cases where imposing at the RIP makes perfect sense for some workflows. Whereas very complex impositions which impact costing and scheduling generally needs to be done further upstream.