Angolo

Un requisito tecnico di un grande cliente — il database nella propria sottoscrizione cloud, il proprio gateway email, il proprio fornitore di modello linguistico — si negozia sul motivo, mai sulla fattibilità. Il motivo dice che cosa basta concedere; rispondere alla richiesta così come è formulata significa concedere il massimo senza sapere perché, e quel massimo si paga poi con la divergenza del prodotto, su voci che nessuna tabella dei costi mostra.

Sintesi

Un grande gruppo sta valutando il tuo software per le buste paga. La trattativa va avanti. Poi arriva una frase: «il database deve stare nella nostra sottoscrizione Azure».

La discussione che segue si svolge quasi sempre sullo stesso terreno: è fattibile? Sì, tecnicamente. Quanto tempo? Due mesi. Si fa una stima, ci si impegna, si passa oltre.

Questa discussione ha saltato l'unica domanda che ti mette in mano la trattativa: perché questa richiesta. Un audit ISO da superare, una policy di sicurezza che vieta i dati fuori dal proprio tenant, un team di cybersecurity che vuole i log nel proprio strumento di monitoraggio. Non sono giudizi sulla tua competenza — nessuno pensa che il cliente ospiterà i dati meglio di te. È controllo: poter rispondere dei propri dati davanti al proprio auditor.

Il motivo conta perché fissa il dosaggio. Se il bisogno è dimostrare che i dati non escono dall'Unione europea, bastano una regione di hosting e un impegno scritto. Se è tenere la chiave di cifratura, basta una chiave gestita dal cliente. Nessuno dei due bisogni richiede il database nella sua sottoscrizione. Rispondere alla richiesta così come è formulata significa concedere il massimo per un motivo che non si è individuato.

Perché ciò che si concede ha un prezzo, e lo si paga su voci che nessuno tiene sotto controllo. Il database sta presso il cliente: ogni messa in produzione che tocca la struttura dei dati diventa una procedura da inviare, un'approvazione da attendere, una finestra di manutenzione da prenotare. Il primo cliente la applica martedì, il terzo la rimanda al mese successivo, e tre mesi dopo le tue correzioni vanno testate su quattro stati diversi del database. Ciò che si perde è esattamente ciò che rendeva interessante il modello: un prodotto unico che si fa avanzare per tutti nello stesso momento. La voce di infrastruttura, intanto, è scesa — ed è quella che il commerciale vede quando propone uno sconto.

C'è un caso in cui il calcolo si ribalta: un blocco che non differenzia niente può bastare da solo a impedire la vendita. Il SSO non distingue nessun software per le buste paga dai suoi concorrenti, eppure la sua assenza basta a escluderti. Lo si costruisce quindi non per ciò che aggiunge, ma per ciò che costa la sua assenza. La domanda non è mai «crea valore?» — è «che cosa apre, e su quale voce si paga?».

Da qui la conclusione, che non è tecnica. Questi requisiti non sono casi particolari da trattare uno per uno: sono la cultura di governance di un segmento di mercato. Decidere di vendere lì significa accettare questo vincolo come un dato del mercato, quantificarlo una volta per tutte e negoziare ogni richiesta sul suo motivo invece che sulla sua fattibilità.

Tensioni / contraddizioni

Due note non dicono la stessa cosa su ciò che si può cedere. Una sostiene che sostituire un fornitore senza cambiare il valore rende il servizio sostituibile — quindi che bisogna resistere; l'altra che la sostituzione resta costosa non appena il blocco contiene lo stato durevole — quindi che il rischio è minore di quanto sembri. Il confine tra le due non è tracciato.

Altra tensione irrisolta: la tesi chiede di negoziare sul motivo, ma niente garantisce che l'interlocutore lo conosca. Un requisito trasmesso dall'ufficio acquisti può aver perso per strada la propria ragione.

Domande

• Come risalire al motivo quando l'interlocutore si limita a trasmettere una regola interna?
• Fino a quanti stati diversi del database un team riesce a reggere prima che i test diventino impraticabili?