Come ho avuto modo di dire nel mio primo articolo della serie, stipulare un contratto per servizi di stampa gestiti (MPS) è sicuramente positivo e può apportare considerevoli miglioramenti e vantaggi concreti. Eppure, forse non soddisfa tutti i requisiti aziendali in fatto di stampa, o forse bisognerebbe ricavare più valore da questi contratti.
Quando parlo con i miei clienti, effettivi o potenziali che siano, voglio capire quali applicazioni usano, e soprattutto quali applicazioni supportano i processi chiave dell’azienda. Se si tratta di una banca, dove gira l’applicazione bancaria principale? Gran parte delle banche più importanti affida tuttora i sistemi bancari di base al fedele mainframe IBM zSeries. Nel settore manifatturiero su un sistema SAP o UNIX. Nel settore della logistica, anche il sistema di gestione del magazzino è generalmente su UNIX.
Dopo aver stabilito la natura delle applicazioni mission-critical, chiedo ai clienti che percentuale dei volumi di stampa proviene da Windows e quale da altre piattaforme applicative. E sempre, senza alcuna eccezione, gran parte dei volumi di stampa proviene da piattaforme applicative business-critical diverse da Windows. Addirittura, una grande compagnia assicurativa del ramo vita mi ha confidato che oltre il 75% dei volumi di stampa aziendali proviene da sistemi di amministrazione delle polizze che girano su mainframe IBM zSeries. Quante volte ci scordiamo di questa piattaforma quando dobbiamo definire la strategia di stampa?
E quindi? Be’, innanzitutto investendo in un MPS potrete consolidare il numero dei dispositivi, innalzando il rapporto utente/dispositivo (in realtà questo potete farlo facilmente anche da soli, ma lasciamo quest’argomento per un altro post). In più, sottoscrivendo un MPS avrete diritto all’assistenza tecnica e al servizio riparazioni, nonché al rifornimento di materiali di consumo dietro pagamento di una tariffa mensile fissa. Altri vantaggi sono contabilità dei costi, riduzione dei volumi di stampa e degli sprechi, applicazione delle politiche di stampa e trasmissione sicura dei documenti. Ma tutti questi vantaggi saranno validi anche per l’output proveniente da applicazioni non basate su Windows, vale a dire l’output aziendale? Probabilmente no.
Ad esempio, gli strumenti contabili inclusi nell’MPS registrano le statistiche di stampa relative all’output associabile a un account utente di Windows. Però l’output proveniente dall’ambiente di stampa back-end di SAP o da un sistema zSeries o iSeries preesistente non è associato ad alcun account utente di Windows, per cui rientra in toto nella categoria “altro” o “varie”. Questo complica la faccenda se desiderate una panoramica più precisa dei costi totali associati alla stampa e di quali dispositivi operano a un livello di capacità inferiore, pari o superiore, quando si tratta di stampa aziendale o di produzione.
La situazione peggiora ulteriormente se desiderate una di quelle soluzioni cosiddette di “pull printing”, spesso incluse nei contratti MPS. Anche queste, infatti, dipendono dalle credenziali di un account utente (ad esempio l’autenticazione di utenti Windows con Active Directory), perciò potrebbero non trasmettere i documenti aziendali se l’utente si autentica direttamente sul dispositivo di stampa. Le applicazioni SAP sono largamente usate in diversi settori aziendali, soprattutto per le funzioni di RU (provate a immaginare un documento RU riservato che viene trasmesso direttamente a un MFP senza che l’utente si autentichi sul dispositivo). Ma le stampe provenienti da processi di stampa back-end di SAP non sono associate alle stesse credenziali utente richieste dal processo di autenticazione, quindi non passano per la soluzione di “pull printing” e devono invece essere trasmesse direttamente a una stampante. In una simile situazione il vantaggio MPS di consolidamento delle stampanti spesso viene meno, in quanto il reparto RU dovrà usare un maggior numero di dispositivi dedicati per suo uso esclusivo, per evitare l’esposizione di documenti riservati.
Potrei continuare, ma credo che il quadro sia chiaro: è molto probabile che la vostra azienda produca gran parte delle stampe con modalità che non vi consentono di usufruire di tutti i vantaggi dell’MPS. Ed è possibile che non abbiate osato investire fino in fondo in un MPS perché le vostre applicazioni business-critical hanno esigenze specifiche. Ad esempio, linguaggi di stampa proprietari dei vecchi mainframe quali Xerox e AFP, metodi di accesso complessi e particolari tipi di dispositivi utilizzati nelle definizioni SAP, per citarne solo alcuni. Poiché non rientrano nella semplice stampa da Windows, questi scenari spesso rimangono fuori da un’implementazione completa dell’MPS, o addirittura la ostacolano.
Ma esiste un rimedio. È possibile “normalizzare” l’output in modo che la coda di stampa personale di un utente, autenticata dalla soluzione di “pull printing” prima del rilascio, contenga tutto l’output destinato a quell’utente, indipendentemente dal sistema o dall’applicazione di origine.
Ripeto ancora una volta, e non mi stancherò di ripetere anche nelle prossime settimane, che il mio intento non è criticare i servizi di stampa gestiti, o MPS. Si tratta di investimenti in grado di portare vantaggi dal punto di vista finanziario e della salvaguardia ambientale. Ma i risultati possono essere ancora migliori se si considera il quadro nel suo complesso.
La prossima volta parleremo di chi stampa cosa, dove e quando. Arrivederci tra una settimana circa.
Steve