1. Simulazione dei costi di ritiro
I costi sommersi offuscano il giudizio dei dirigenti.
Confronta la perdita quando si interrompe un progetto con un contratto tradizionale a prezzo fisso rispetto a un modello flessibile DaaS/Staff Augmentation.
Confronto dei costi cumulativi
Sposta il cursore per cambiare il mese in cui decidi di uscire (annullare).
Rischio tradizionale (prezzo fisso)
Spesso si applicano penali di risoluzione e obblighi di acquisto dei deliverable intermedi, massimizzando l'esposizione ai costi sommersi.
Rischio DaaS (contratto flessibile)
Paghi solo per il lavoro svolto. Poiché puoi fermarti in qualsiasi momento, puoi decidere di uscire prima che il danno cresca.
La possibilità di annullare in qualsiasi momento incentiva il fornitore a mantenere alta la qualità.
2. L'anatomia del vendor lock-in e della "trasparenza"
La paura del lock-in nasce dal non vedere cosa c'è dentro.
Confronta gli elementi che evitano la black box e ripristinano il controllo autonomo.
Sviluppo black-box
La specifica dettagliata vive solo nella testa del fornitore
-
✕
Proprietà del codice ambigua
Framework e librerie personalizzati rendono difficile il passaggio a un altro team.
-
✕
Documentazione mancante
Ottieni un prodotto funzionante, ma non il "perché" che lo motiva.
-
✕
Dipendenza dalle persone
Se una persona chiave se ne va, il sistema può bloccarsi.
Sviluppo white-box
Mantieni il sistema pronto al passaggio in qualsiasi momento
-
✓
Selezione di tecnologie standard
Scegli linguaggi e framework ampiamente adottati per mantenere opzioni di sostituzione.
-
✓
Sempre condiviso su GitHub, ecc.
Fai commit quotidiani nel repository del cliente così progresso e qualità sono visibili in tempo reale.
-
✓
Strategia di uscita definita fin dall'inizio
Progetta un piano di internalizzazione/transizione fin dal primo giorno.
Assi di valutazione per la selezione dei partner (Risk Radar)
Quando scegli un partner, valuta i cinque assi sotto, non solo il prezzo, per misurare la reversibilità.
- Trasparenza: Accesso alle informazioni
- Tecnologia standard: Quanto è comune lo stack tecnologico
- Flessibilità contrattuale: Facilità di cancellazione
- Documentazione: Intento di design registrato
- Supporto all'autosufficienza: Disponibilità ad aiutare l'internalizzazione
3. Liberarsi dalla dipendenza: Strategia di uscita
Passa dal lock-in contrattuale a una relazione basata sul valore.
Definisci la roadmap per un ritiro e un handoff fluidi quando necessario.
Step 01 Garantire la proprietà degli asset
Assicurati che il codice sorgente, i dati di design e la documentazione siano di proprietà del cliente.
Il cliente crea il repository (GitHub, ecc.) e invita il fornitore.
Step 02 Rendere la conoscenza impersonale
Documenta non solo i verbali delle riunioni, ma anche commenti nel codice e ADR.
Lasciare il contesto del "perché" riduce il costo del passaggio.
Step 03 Periodo di sovrapposizione
Quando si internalizza o si cambia fornitore, prevedi 1-2 mesi di sovrapposizione.
Usa pair programming e code review per trasferire l'autorità a livello operativo.
Obiettivo Piena indipendenza
Uno stato in cui il sistema continua a funzionare senza partner esterni.
Questo è l'obiettivo finale della gestione del rischio: una postura di sviluppo sana.