As I mentioned in with in my first article of this series, a Managed Print Services agreement (MPS) is a good thing that can deliver lots of real-world benefits and improvements. But does it address all of your printing requirements across the enterprise, or should we be looking for ways to drive greater value from the MPS?
When I am out talking to customers and prospects, I like to understand what applications they run. Specifically, what are the applications that support key business processes? If it’s a bank, where is the core banking application running? (Many of the large, long-established banks still rely on the trusted IBM zSeries mainframe for core banking systems.) In manufacturing, it could be SAP on UNIX. In logistics, the Warehouse Management System is often on UNIX as well.
After understanding those business or mission-critical applications, I’ll ask what percentage of the printing comes from Windows servers versus other business application platforms. Without exception, the majority of printing comes from non-Windows, business-critical application platforms. In fact, one major life assurance company told me that 75% or more of its printing came from policy administration systems running on IBM zSeries. How often do we forget about that platform when looking at our printing strategy?
So what? Well, the benefits of an MPS investment start with consolidating the number of devices thereby obtaining a higher user-to-device ratio (you can do that quite easily yourself, but that’s an article for another day). The MPS offering will also provide a managed service desk with break/fix service and consumables replenishment for fixed monthly pricing. But there are other claimed benefits such as cost accounting, print and waste reduction, print policy enforcement and secure document delivery. Will all of these apply to output originating from non-Windows applications, i.e., the business output? Quite simply, they probably won’t.
As an example, any accounting tools included in the MPS will record print statistics for output that it can associate with a Windows user account. However, output coming from SAP back-end printing or from a legacy zSeries or iSeries system won’t be associated with a Windows user account. As a result, all the business output gets reported in the “Other” or “Miscellaneous” bucket. This is not helpful if you want a more accurate view of the total costs associated with printing and which devices are operating under, at, or over capacity when dealing with production or business printing.
The problem is exacerbated when you look to use Pull- or Follow-Me-printing solutions, which are often included as part of an MPS. These solutions are also dependent on user account credentials (e.g., authenticating Windows users with Active Directory) and may not be capable of delivering those business documents when the user authenticates at a device. SAP applications are widely used across business sectors for, amongst other things, the HR functions. (Just imagine a confidential HR document being delivered directly to an MFP without a user first authenticating at the device!) Yet all printing from the SAP “back end” processes will not be associated with the same user account credentials that are required in the authentication process and will therefore bypass the Pull Print solution and need to be delivered directly to a printer. In this scenario, the MPS message of printer consolidation often falls down as HR maintains a higher number of departmental devices just for their own usage — a common workaround to avoid the confidentiality exposure.
I could go on, but you get the picture – your business may well be producing the majority of its print in ways that do not enable you to realise the full benefits of your MPS. You may even have been frightened away from a full MPS investment as your critical business applications have quirks with the way they print. Quirks like the old proprietary mainframe print languages from the mainframe such as Xerox and AFP, the complex access methods and device types used in SAP definitions, and more. Because they do not fit neatly with simple Windows printing, these are often omitted from, or are an obstacle to, a full MPS deployment.
Luckily, they don’t need to be. There are ways to “normalise” output such that an individual’s “Personal Queue”, authenticated by the Pull Print solution before release, contains 100% of the output intended for that individual, regardless of system or application of origin.
Let me repeat my earlier comment, which will become a mantra over the coming weeks – this is not about MPS bashing. These are investments that realise financial and environmental benefits but they can deliver more if organizations look at the wider picture.
Next time, let’s look at Who prints What, Where and When. See you in a week or so.
Steve