Lavoriamo regolarmente al fianco di altri fornitori — non obblighiamo nessuno a sostituire il proprio IT attuale. Facciamo audit non invasivi, entriamo su perimetri ben definiti (un SaaS, una posta, una rete), coordiniamo handoff e runbook con chi c'è già. Nessun obbligo di consolidamento. Se il cliente sceglie di portarci tutto, lo facciamo gradualmente. Se non sceglie, manteniamo il perimetro assegnato con qualità invariata.
01Come capiamo dove inserirci
La prima cosa che facciamo non è vendere. È ascoltare il problema e capire se è un problema che abbiamo già visto e risolto. Nove volte su dieci il cliente ci contatta per un punto specifico — un software gestionale da scrivere, una posta che non scala, un DR che non c'è, una virtualizzazione che va ripensata — non per un'analisi generale del suo IT.
Facciamo un audit non invasivo solo sul perimetro in questione. Significa: leggiamo le configurazioni accessibili, capiamo i flussi, parliamo con chi usa il sistema, stimiamo il lavoro. Non entriamo nei sistemi del fornitore esistente, non chiediamo documenti contrattuali altrui, non produciamo "diagnosi gratuite" del lavoro di altri per venderci al posto loro. Quel tipo di approccio è scorretto, e si vede subito.
Alla fine dell'audit diciamo tre cose: cosa ci sembra funzioni già, cosa è nel nostro perimetro di competenza, cosa invece è meglio che resti dov'è. Se la risposta è "state bene così", la diciamo.
02Scenari tipici di coesistenza
La coesistenza non è un'eccezione, è la normalità. Qualche caso concreto dalla pratica degli ultimi anni:
- SaaS custom scritto da noi + hosting gestito da altri. Il cliente ha un fornitore storico che gestisce server e reti, ma ha bisogno di un'applicazione specifica (gestionale, portale clienti, automazione di flusso). Scriviamo il software, lo consegniamo con documentazione e accessi, e il fornitore esistente continua a gestire l'infrastruttura sottostante. Noi facciamo manutenzione applicativa, loro fanno manutenzione sistemistica. Tutto scritto.
- Posta nostra, rete di altri. Il cliente vuole uscire da Office 365 o Google Workspace ma la rete interna la gestisce qualcun altro. Mettiamo la posta sulla nostra infrastruttura (server italiani, MX, filtri antispam con Proxmox Mail Gateway), configuriamo DNS e SPF/DKIM/DMARC, coordiniamo col fornitore di rete per il cutover. Da lì in poi la posta è nostra, la LAN resta loro.
- DR nostro, primario on-prem di loro. Molto comune. Il cliente ha un sysadmin interno o un fornitore che gestisce i server in sede, ma non ha un piano di disaster recovery. Costruiamo il DR sulla nostra infrastruttura geografica, con repliche asincrone e RPO misurato. Se il sito primario va giù, noi facciamo failover; quando torna su, coordiniamo il failback col loro sysadmin.
- Virtualizzazione nostra, applicativo di altri. Il cliente ha un software verticale gestito dal vendor del software stesso. Noi mettiamo Proxmox sotto, il vendor continua a gestire la sua applicazione dall'interno delle VM che gli forniamo. Confini netti.
03Il primo contatto col fornitore esistente
Quando il cliente ci chiede di inserirci su un perimetro, il primo contatto col fornitore esistente lo facciamo insieme al cliente, mai alle sue spalle. Ci presentiamo per quello che siamo — un fornitore specializzato chiamato per un pezzo specifico — e chiediamo tre cose concrete: quali sono le interfacce tecniche tra il nostro perimetro e il loro (DNS, VLAN, API, punti di integrazione); chi chiamare quando qualcosa va storto a cavallo; come documentiamo insieme il confine per non rimbalzarci problemi.
Non chiediamo credenziali che non ci servono, non chiediamo dettagli economici del loro contratto, non chiediamo accesso a sistemi fuori dal nostro perimetro. Se serve un passaggio di informazioni tra loro e noi, passa sempre dal cliente — è lui che decide cosa condividere.
Nella maggior parte dei casi questo approccio funziona e la relazione col fornitore esistente diventa collaborativa. Nei rari casi in cui l'altro fornitore rifiuta di coordinarsi, lo segnaliamo al cliente con i fatti (email senza risposta, richieste ignorate), senza giudizi di valore. La decisione su come gestire quella relazione è del cliente.
04Cosa non facciamo mai
Tre cose sono fuori discussione, a prescindere dalla pressione commerciale:
- Diffamazione del fornitore esistente. Non esiste il "guardi che questi lavorano male, noi faremmo meglio". Se vediamo qualcosa di oggettivamente rotto lo comunichiamo al cliente in forma tecnica — "il backup non è testato da X mesi", "il DNS è configurato così e questo causa quello" — senza commenti sulla competenza altrui. I fatti parlano, gli aggettivi no.
- Sostituzione strisciante. Non accettiamo mandati impliciti del tipo "entrate piano piano e poi vedrete che il cliente vi darà tutto". Se il cliente vuole cambiare fornitore, lo deve decidere apertamente e deve essere una scelta sua, non un risultato di manovre nostre.
- Doppia fatturazione nascosta. Se c'è sovrapposizione tra quello che facciamo noi e quello che già fattura il fornitore esistente, la solleviamo subito col cliente. Meglio perdere una voce di fatturazione che scoprirla a sei mesi dentro un contenzioso.
05Il passaggio graduale al consolidamento
Capita — non spessissimo — che il cliente, dopo sei-dodici mesi di lavoro insieme su un perimetro specifico, decida di consolidare tutto con noi. Quando succede, non è perché abbiamo spinto; è perché il paragone quotidiano sul perimetro assegnato ha prodotto una valutazione.
In quei casi costruiamo un transition plan su 3-12 mesi, a seconda della complessità, con milestone scritte: inventario completo dei servizi attualmente gestiti dal fornitore uscente, mappatura dipendenze, ordine di migrazione, finestre di cutover, runbook di rollback per ciascuna fase. La fase più delicata è sempre il knowledge transfer — documentazione nascosta, configurazioni non banali, contatti con fornitori terzi del cliente. Se il fornitore uscente collabora, il tempo si dimezza; se non collabora, allunghiamo le scadenze e alziamo i test prima di ogni cutover.
Mai migrazioni big-bang. Mai "stacchiamo tutto il venerdì sera e lunedì si riparte". Il rischio operativo in quel tipo di transizione è troppo alto per ignorarlo.
06Quando invece conviene restare col fornitore esistente
Non siamo la risposta universale e siamo i primi a dirlo. Scenari in cui lo diciamo chiaramente al cliente:
- Il fornitore esistente ha competenze verticali (un ERP di nicchia, un software industriale custom, una certificazione regolatoria specifica) che noi non abbiamo e che costerebbero anni di apprendimento per replicare. In quel caso costringere un cambio è un danno, non un servizio.
- Il rapporto funziona, i costi sono nella media, non c'è un problema tecnico reale. A volte il cliente ci chiama perché "si sente" che qualcosa non va, ma dopo l'audit emerge che il problema è di comunicazione o di aspettative, non di fornitore. Lo diciamo.
- La dimensione del cliente non giustifica la nostra struttura. Siamo un piccolo gruppo di persone con esperienza lunga — costiamo quello che costa quel tipo di profilo. Per microclienti con esigenze semplici, un fornitore locale meno specializzato spesso è la scelta più sensata.
Perdere un cliente potenziale dicendogli "state bene così" è il modo più economico per guadagnarlo quando davvero serviremo. E succede.
07Come iniziare
Una chiamata di un'ora, gratuita, senza commerciali. Si parla del problema specifico che avete in mente, si capisce se è nel nostro perimetro di competenza, si mette sul tavolo il rapporto col fornitore esistente e come gestirlo. Alla fine della chiamata avrete un'idea onesta di cosa possiamo fare, cosa no, e se ha senso andare oltre. Se non ha senso, lo diciamo direttamente — è tempo risparmiato a entrambi.