Embedding Real Print Workflow Change

A print software application can do certain jobs for your business. Once you’ve proven it works, don’t forget to execute. Deploy the software so it does that job across your entire organization. Read on to find out how.

Every print business is using software to run their business, from Microsoft Word to their Print MIS. At some point in the print business’ history, the software was purchased and “implemented.” This could have happened 20 years ago, or it could be in progress today.

Your business is made of people who have ideas and think a certain way. Your software was created by people who have ideas and think a certain way. The success of your business depends on how well your people can work with the software. In some print businesses the software and the people are at total odds. The people have created elaborate workarounds to use the software as little as possible. In other print businesses the people have invested tremendous time and effort to learn the software and then adapt it to the business for optimal outcomes. Most print businesses land somewhere in between those extremes.

One of my favorite quotes from Buckminster Fuller is:

You cannot change how someone thinks, but you can give them a tool to use which will lead them to think differently.

I think this quote applies to the world of print business software. Believe me, I have wasted a lot of my life force trying to get people to change the way they think about their print business workflows. It is a much better approach to introduce a tool that gradually leads them to think differently. The use of a tool is empowering; the gradual nature of learning a tool does not meet the resistance that someone telling you to change does.

The big challenge with the introduction of a new tool is that we have a collective shortage of attention and willingness to, first and foremost, learn the tool, then spend the time to ensure that it is properly embedded in our workflow. When you bring a new piece of software in, the expectation is that people should just be able to start using it. This is an expectation for which we can thank Apple (yes, the computer company). They have mastered the art of creating an extremely complex product and then delivering it via a user experience that a toddler can figure out. Print business software is not that.

We are in a hurry. So, we take a new tool, we rush through the learning process, then as soon as we have a bit of confidence, we push on the vendor to make changes so we can move onto the next thing. There is no issue with exuberance and wanting software to do more and more. The issue is that we move on before the print software is embedded in our workflow. There is a stickiness to the status quo; if you move on too quickly the business has a tendency to slide back to where they were before you introduced the tool. How many printers out there have adopted a new print software package, been really enthused about it, then months later find that nobody is using it anymore?

What do we do about this? Here are a couple of suggestions.

Think of software as a resource that does jobs for you. What jobs do you want the software to do for you? The key aspect of this thinking is that more is not better. If a software solution does the most important aspect of your workflow brilliantly, that’s enough. Let’s say you bought a web-to-print solution that helps automate customers re-ordering from you. You love the system, and the few customers you’ve introduced the system to love the system. You get excited, so you make a request of the vendor: can you make the solution help us with new orders, can you make the solution help us with kitting of orders, can you make the solution do a bunch more jobs that we’re struggling with?

There is nothing wrong with asking those questions. The issue is that you haven’t embedded the initial job the software does for you into your business. What percentage of your customers are re-ordering from the site? How many re-orders are you processing manually today? You are skipping the actual execution part of software. See, execution in software isn’t the first few customers. Execution in software is the masses; it is looking at your entire business and implementing the software solution to do the job it does well for all your customers. When you deploy it across the entire organization, you embed it as the new status quo.

I was working with a printer and I asked five different people in the organization if they used any tools for proofing with customers. All five people described a different solution. Each of these solutions was a software that they had purchased over the years to do the job of “proofing.” Not one of them got truly executed across the organization. The organization doesn’t even know what their proofing workflow is. The printer uses multiple systems, pays for multiple systems, and then has to have people who know multiple systems all to do the one job of proofing.

You must execute on the print software tool. It is what embeds it in your workflow. There is a real pull to jump to the next thing; print business leaders need to hold everyone accountable to executing on the print software so that the job you hired it to do is being down across the entire business.