Vendor lock-in, un male gestibile

I sintomi

Il vendor lock-in è un male da cui è difficile guarire e colpisce le aziende clienti. I primi segnali evidenti sono un incomprensibile aumento dei costi, per attività che nell’accezione comune richiedono un costo di implementazione molto basso.

La situazione tipica è questa:

Cliente: “Vorrei cambiare l’etichetta da quietanzamento a rinnovo. Riusciamo ad averlo online per Lunedì e quanto costa”

Fornitore: “Certo, il costo è di ca. 5ggu”

Cliente: “5ggu?!?!?! Ma è solo un etichetta”

Fornitore: “Non è così semplice, le etichette sono gestite dal database, ogni volta che tocchiamo il DB dobbiamo chiamare il sistemista che valida gli script, preparare un delta script e farlo girare in ambiente di collaudo, lì facciamo girare un insieme di test di non regressione per essere certi che non abbiamo creato problemi in altre aree dell’applicativo. Prima ovviamente faremo un analisi di impatto”

A questo punto il cliente vorrebbe capire se tutti i passaggi sono necessari, si rivolge a un esperto interno il quale stima: 5 minuti per cambio etichetta, 10 minuti per la creazione di un delta script che si traduce in “update db.labels set label=”rinnovo” where cond AND cond AND label=’quietanzamento’”, 30 minuti per installare lo script sul ambiente di collaudo, 30 minuti di test. Arrotondiamo 1 ora, 30 minuti. Cerchiamo di essere realisti, il primo tentativo fallisce sempre. Raddoppiamo: 3 ore. Vabbé ma sta pausetta caffè, una mail da rispondere? non vogliamo mettercela? 4 ore.

Fatto il passaggio con l’esperto che fiero della propria stima di 4 ore, il cliente torna dal fornitore. Con una contro proposta.

Cliente: “Abbiamo fatto dei ragionamenti interni, possiamo arrivare a riconoscere 1 giornata uomo”

Fornitore “Per quel ‘impegno non possiamo assumerci il rischio, tenete l’etichetta cos’ì com’è. (O al più cambiate solo il primo 20% dei caratteri)”

E’ questo punto il cliente vorrebbe rivolgersi a un altro fornitore, ma non può il contratto prevede che solo l’attuale fornitore può intervenire sul codice, sulle configurazioni, sul database e su qualsiasi altra componente direttamente o indirettamente connessa con l’oggetto del contratto. In quel preciso momento il cliente matura la consapevolezza di essere affatto dal male chiamato “vendor lock-in”.

Parliamoci chiaro, tutti i rapporti cliente/fornitore si trovano in una situazione di questo tipo per quanto riguarda i software proprietari dei sistemi core. Basti pensare che un progetto di migrazione di portafoglio dura mediamente 2-3 anni per rendersi conto degli elevati costi a cui si va incontro per sostituire i software core proprietari. Il punto importante è trovare un modo per rendere sostenibile questo rapporto, per sua natura sbilanciato a favore del fornitore.

Gare

Gare, sempre gare, per ogni attività. Le gare sono come la Tachipirina per il febbricitante. Se ci trova in una situazione di vendor lock-in le gare (per le nuove attività) aiutano a contenerne gli effetti, anche se nel lungo periodo creano assuefazione nel fornitore. La percezione di essere messi in concorrenza, di essere messi alla prova aiuta a calmierare i prezzi del fornitore dominante. Non sempre è possibile fare gare per i contratti che già legano al fornitore dominante, ma occorre sfruttare ogni singolo spiraglio. Se la gara riguarda i sistemi in situazione di vendor lock-in occorre prestare massima attenzione. Non puntare esclusivamente a una gara al ribasso sul progetto di avviamento.

Mi viene in mente il caso delle stampanti, oggi una stampante viene venduta anche a 40€ cartucce incluse, le singole cartucce costano 20€. Possibile che il costo della stampante sia solo 20€? Il fornitore ha semplicemente caricato sulle cartucce il costo delle stampanti. Il una gara al ribasso per un progetto che porta a un vendor lock-in il fornitore sarà disposto a scendere di prezzo fin dove vuole il cliente. Tanto rientrerà di costi in una fase post-rollout. Cercare di ragione sui costi post avviamento durante una gara è pressoché impossibile. Il costi  negli anni post “rollout” dipendono dal numero di adeguamenti  o innalzamenti funzionali richiesti. I business si muove e richiede sempre nuove funzionalità.

In sintesi:

• Fate sempre gare. Aiuta a calmare i fornitori dominati.
• Diffidate del cliente che in fase di gara sconta fino ad avere il prezzo più basso. Pagherete tutto dopo con gli interessi composti.

Separazione tra vendor di piattaforma e system-integrator

Ogni piattaforma software installata presso un cliente ha due componenti, una di “prodotto” e una di “personalizzazione”. Con prodotto si intendo il software nudo e crudo come è stato realizzato dalla software-house di riferimento, mentre con personalizzazione sono tutte le configurazioni e implementazioni necessarie alla soluzione software per funzionare correttamente nel ecosistema aziendale (flussi, connettori, integrazione,…). Per molte soluzioni software questa separazione viene naturale. Ad esempio database Microsoft o Oracle, il database Administrator è tipicamente di una società terza. Questa separazione deve essere mantenuta per tutto il software proprietario. Sempre.  I vantaggi sono:

• possibilità di cambiare system-integrator senza cambiare piattaforma software
• cambiare piattaforma software preservando il system-integrator e quindi le competenze specifiche legate all’azienda

Avere lo stesso fornitore ha inoltre il grosso svantaggio di rendere opachi sia i difetti di piattaforma che le mancanze nelle varie fasi progettuali.

In sintesi: E’ bene tenere separato il vendor di piattaforma dal system-integrator che gestisce il progetto di avviamento e la manutenzione

Pluralità di fornitori

Forse questo è uno degli elementi più importanti.  Ad alcuni è sicuramente capitato di andare in un negozio per comprare un adattatore per il nuovo dispositivo, considerato il topo della gamma, e di scoprire e che il dispositivo non usa connettori ma proprietari, che costano mediamente 3 volte tanto (ai tempi che fu c’era betamax, oggi capita sui cellulari di alcuni produttori)

Occorre sempre avere diverse alternative per tutte le attività di sviluppo/innalzamento funzionale della soluzione software scelta. Ossia diversi fornitori devono poter intervenire nello sviluppo di nuove funzioni. Affinché questo sia possibile occorre che la soluzione software abbia una caratteristica fondamentale: deve essere progettata a componenti con interfacce di estensione standard.

Esistono una moltitudine di standard (JSON SOAP e XML per integrazione, CMIS per i sistemi documentali, BPMN2 per i processi, OSGi come container,…). Tutti questi protocolli standard consento una facile estensione delle funzionalità. L’attività di system integration deve concentrarsi solo sullo sviluppo di questi connettori. E non cadete nel tranello di pensare che se i connettori vengono sviluppati dal vendor del sistema risparmiate perché il vendor conosce la piattaforma. Il vendor andrà a creare dei connettori talmente avvitati alla piattaforma che ogni attività di manutenzione costerà 3 volte tanto. Meglio spendere qualcosa di più prima che far lievitare a dismisura i costi dopo.

Diffidate inoltre dei fornitori che dichiarano di avere una piattaforma “aperta” o “open” come si dice oggi con tanto di architettura SOA e non fornisce documentazione a riguardo. Per Dichiarare di avere un architettura SOA è sufficiente disporre di web-service, ma ciò che conta è cosa posso farne di questi WS. Se non comprendono le funzionalità che interessano all’azienda avremo costi che lievitano in modo sproporzionato.

In sintesi:

• Scegliere soluzioni per le quali esistono diversi system-integrator indipendenti in grado di sviluppare i connettori di integrazione
• Scegliere una soluzione che abbia tutti i connettori necessari pronti e ben documentati (diffidate di chi dichiara di avere la piattaforma aperta e non fornisce l’elenco dei servizi aperti)

Proprietà intellettuale delle personalizzazioni

Ho visto situazioni in cui il cliente chiede delle personalizzazioni sulla soluzione software e quanto viene sviluppato rimane di proprietà intellettuale del fornitore. Perché questo? Motivi contrattuali è la prima risposata, ma qual’era la base di questa scelta? Semplice, ogni personalizzazione richiede espone il fornitore a rendere noti alcuni aspetti implementativi e per tutelare la proprietà intellettuale del proprio software tende a chiedere contrattualmente di mantenere la proprietà intellettuale di quelle che sviluppa. Dall’altro lato il cliente ritiene di non farsene nulla del sorgente e della proprietà intellettuale di quello che viene sviluppato e così il fornitore tira e il cliente cede a fronte di uno sconto che pagherà nei mesi successivi con l’interesse.

Mantenere il controllo delle personalizzazioni consente al cliente di entrare nel merito di quanto è stato realizzato, capirne la qualità e infine di chiedere a terzi di intervenire per correggere problemi. Un mito da sfatare è che “tanto del sorgente non sappiamo cosa farcene”. Basta un team di 2-3 bravi sviluppatori e qualsiasi sorgente viene ribaltato dalla a alla z in poco tempo.

In sintesi: Chiedere sempre la proprietà intellettuale degli sviluppi che vengono fatti e conservare in modo diligente il relativo sorgente compilabile.