When NOT to automate...

...and why the standardization of software could be bad for printing companies

Over the years we’ve heard a lot about the commoditization of print and how printers are aiming to standardize the way in which they produce work.

But something occurred to me recently while reading about Microsoft’s so-called Dataverse – could we now be looking at the standardization of the computer software industry, and with it, the end of any opportunity for printing companies to differentiate themselves using technology?

Let me explain... almost every time you read anything about technology in the printing industry, it’s about automation and connectivity. We’ve always been evangelists of automation here at ePS too, that’s because there’s no denying that the world has gone through an accelerated evolution from a technological point of view.

We’re constantly being told to automate and integrate everything we can to increase efficiency and improve quality.

Over the years, I’ve seen various platforms launched to help printers achieve this and join their business and production workflow together, and it all started with JDF.

JDF

JDF was infinitely flexible, and we managed to achieve some fantastic integrations with it, but unfortunately, it was without structure, so there wasn't a consistent experience for everyone – different vendors implemented different levels of integration.

There was another problem too - JDF didn’t cover all of a business’ workflow, only the manufacturing part. So, we also saw other solutions introduced to the industry to work alongside JDF - anyone remember something called PrintTalk? This exchange format was used to automate the more generic parts of a print business’ workflow; it allowed you to define an order, invoice, RFQ, etc. But even adding technology such as this wasn't enough, you could still only automate select parts of your workflow.

Application Programming Interfaces (API)

And then came APIs, which offer a more universal experience encompassing every facet of a technology stack that you would want to include. Plus, once your link has been written (following the guidelines of the creator of the API), it should continue to operate effectively even after version updates. The problem here is in the writing of the link – you still need a developer to write the link in the first place.

Dataverse

So, what about the earlier mentioned Dataverse that started me pondering on this subject? Dataverse is the new name for Microsoft’s interface to its Power Platform features and the gateway for all other third-party connections.

In the most basic of explanations, it’s just a place where you can host your data and where all other applications can access that data. This is a good solution because it’s also a universal one (it covers all the different areas of any workflow in any sector) and because it gives you the freedom to be creative.

But you still have to do all the heavy lifting and write all the different entities that go into the tables and rows. So, it suffers from the same issue described above – you still need a developer to create all these connections. It’s not a plug-and-play solution, which is what companies want.
 
And that’s why we’re now seeing a new breed of applications designed to help businesses automate.

Horizontal platforms such as Zapier have been around for a while, but we’re also starting to see more industry-specific solutions emerging – starting with PrintOS a few years ago and, more recently, Zaikio.

Both are applications trying to standardize connectivity and provide companies with a plug-and-play solution.
 
At first, when the likes of PrintOS and Zaikio emerged, I thought “Brilliant! What great solutions!” The geek in me got very excited. But then something struck me…
 
If software providers are merely required to offer up a list of entities that can be passed from one piece of software to another via such middleware, then won’t everyone’s workflow essentially be the same? Won’t all software applications consist of the same basic entities, with the same architecture, to meet the requirements specified by these plug-and-play applications?

If we all have to describe everything the same way, does that mean that the experience will be the same for everyone who uses an MIS, no matter who their provider is? Will we all end up being the same shape and size!? We saw evidence of this when using JDF - your workflow was only ever as good as your weakest connection.
 
While this could be a blow for all of us MIS providers, I wasn’t being entirely selfish with this thought, I was also thinking about how this would affect our customers. You see, we work with a lot of printing companies who have differentiated themselves from the competition through their clever use of technology. They’ve created super cool workflows that allow them to provide added value to their offering and an improved experience for their customers. And if we standardize MIS (and other) software and make connectivity standard, then these companies will lose their competitive edge.

This would be a real shame for us too, because at ePS we pride ourselves on helping companies create superior integrations that take advantage of features that are vendor-specific (i.e. not part of the standard, out-of-the-box type integrations that you can achieve with middleware).

A bit of a tangent here...

...but I’ve also been wondering, “Who is in charge of all this?” Of course, we MIS providers can all describe what a ‘company’ or ‘contact’ or ‘material’ entity looks like. But who owns that definition?

Who is the best person to say what the ‘material’ entity looks like, for example? Paper merchants? The MIS providers? Press manufacturers? This takes us full circle back to the beginnings of JDF and the formation of working groups within CIP4 – this is exactly the issue they set out to tackle. Someone needed to own the definitions of the entities back then, so the working groups were formed, and they took responsibility. But who will do it now? 

Back to my original point...

If this standardization of software becomes a reality, how are tech-savvy printing companies going to be able to differentiate themselves if they can no longer do it using technology?
 
Personally, I believe the answer could lie in deciding NOT to automate. Don’t get me wrong, I’m not suggesting we avoid automation entirely, you absolutely SHOULD work on automating your business and production processes where appropriate. And I do think the likes of PrintOS and Zaikio are absolutely fantastic platforms that allow companies without technical resources to create automated workflows themselves.

But what I do believe is that the companies who will win the day in this scenario I’m painting, are the ones who will pause for a moment before deciding whether a process should be carried out using technology, or if it would be better delivered by a human being.

Let me try and give you an example to illustrate what I mean

Consider a Hotel Porter – someone who stands outside a hotel and opens the door for guests coming in or out of the hotel. You could easily automate their job with an automatic door, and you would very quickly see the financial savings from that. But there are significant downsides to this move.

From the guests’ point of view, their experience has been lessened – they have to hail their own cabs, open their own doors, look for local information elsewhere, and they may even have lost out on a concierge service too.

But the hotel will have lost out even more - hotels that have a Porter to open and close the door for their guests are able to charge more per room per night because of the impression that guests have about a hotel with a Porter. That’s why the job still exists, even though automatic doors have been around since 1931.

My point here is that we shouldn’t be trying to automate every part of our workflow and business – there will be some parts that we deliberately should not connect so we can add innovation and value in these areas.

So, the solution to the printer’s differentiation problem is to reframe the question that is asked at the start of every automation project, “HOW do we automate this process?” and instead start off asking, “SHOULD we automate this process?”.
 
Going back to my earlier, more selfish question, how do we MIS providers differentiate ourselves in a world of standardized software? I actually think the solution here is the same – it’s all about the humans again. Software features can be copied, prices can be mirrored, marketing campaigns can be imitated, but if you have quality people working for you, and work hard to provide a quality experience for your customers, you will always be able to stand out from the crowd.