Progettare un servizio gestito senza la delivery produce un modello coerente sulla carta, ma non è detto che sia erogabile.
La domanda che mi faccio sempre in fase di solutioning è: chi lo fa, questo, e con quali strumenti?
Il solutioning definisce perimetro, SLA, orari, processi, governance, prezzo. Ma è la delivery a sapere quanto i team possano davvero reggere: competenze disponibili, vincoli degli strumenti, tempi reali delle attività, dipendenze tra i livelli di supporto.
Se il confronto arriva solo a offerta chiusa, la delivery eredita un impegno già preso col cliente e può solo provare ad adattarsi. L’esito è quasi sempre lo stesso: effort sottostimato, attività non previste, escalation, margine che si erode in corsa.
Coinvolgere la delivery non vuol dire farsi firmare una delega economica o girare una RFP chiedendo un prezzo. Vuol dire verificare insieme il modello operativo: quali attività, eseguite da chi, con quali strumenti, in quali fasce orarie, con quale escalation.
Le RACI devono essere approvate da chi dovrà rispettarle. I tempi medi di lavorazione devono reggere il confronto con la casistica reale. Patching, monitoraggio, reperibilità, reporting, presidio on site, terzi livelli: ognuno con un owner e un costo. Anche le esclusioni vanno scritte in modo applicabile: una clausola corretta in astratto ma non traducibile in regola operativa non protegge nessuno al primo ticket fuori perimetro.
Il coinvolgimento operativo serve anche a tenere insieme cost case e contratto. Uno SLA può sembrare accettabile commercialmente e rivelarsi insostenibile se il fornitore non controlla tutte le variabili che servono a rispettarlo. Una garanzia su continuità o consistenza dei dati non può ricadere sul servizio se dipende da tecnologie, applicazioni o responsabilità del cliente.
La delivery deve poter contestare le assunzioni non verificabili e trasformarle in prerequisiti, esclusioni o meccanismi contrattuali misurabili, prima che diventino obblighi.
La responsabilità non finisce quando l’offerta è validata. Alla firma, cost case, allegati tecnici, baseline e contratto passano al project manager di transizione e poi al service manager, con un kick-off che coinvolge tutte le delivery interessate. Il PM deve sapere cosa è stato venduto per costruire piano di transizione e manuale operativo. Il service manager deve conoscere costi, vincoli e meccanismi ARC/RRC per governare il contratto senza consumare margine.
Progettare con la delivery significa evitare che il servizio venga “scoperto” dopo la firma. Un servizio gestito è solido solo se chi lo eroga ne riconosce attività, responsabilità, costi e rischi.
Quello che non è stato verificato prima non sparisce: riemerge dopo il go-live come extra effort, conflitto organizzativo o erosione del margine.