Make or Buy: strategia e tattica per costruire il motore di ricerca aziendale

Dalla neonata startup alla multinazionale quotata, tutte le aziende a un certo punto si trovano davanti alla fatidica scelta del “make or buy”: che sia il nuovo sistema HR, un CRM, uno dei componenti che sostituiscono la proposizione aziendale, il manager si trova a decidere se il nuovo software è da costruire (“make”), o comprare (“buy”).

Mentre in alcuni casi questa decisione è piuttosto ovvia, nessuno si metterebbe mai a farsi un suo foglio di calcolo o un suo sistema operativo, in altri diventa il campo di battaglia fra chi farebbe sempre tutto da zero, e chi non viene mai sfiorato da questo pensiero.

Dietro a questa diatriba c’è effettivamente la difficoltà dietro a ogni scelta strategica: da una parte ci sono costi di licenza, costi di integrazione, il rischio dell’effetto vendor lock-in (i.e., sostituire un domani il venditore è talmente costoso che la scelta diventa insostituibile e il venditore ottiene una forte posizione di controllo), la complessità nel lavorare con tecnologie proprietarie, il maggior costo per le personalizzazioni.

Dall’altra parte invece seguire la filosifica del make costringe il manager a prendersi una responsabilità importante: cosa succede se il progetto fallisce? Cosa succede se il software costruito non fa quello che dovrebbe? Chi posso chiamare se qualcosa non va?

Quindi è meglio il make o il buy? Come ogni domanda mal posta, l’unica risposta possibile è: dipende.

Per aiutare a rispondere è però indispensabile approfondire meglio il concetto di “make”. Comunemente, il make lo si immagina come la volontà di re-inventare la ruota partendo da zero e andando a scrivere ogni componente e ogni funzione. In alcuni casi può essere vero, in altri è un’estremizzazione assolutamente poco ragionevole.

Per spiegarvi meglio questa complessità, permettetemi di prenderla alla lontana con un esempio.

Quasi tutte le aziende hanno un problema in comune, legato a una delle necessità primordiali dell’uomo, ossia come fare per gestire la conoscenza. Era un problema per i sumeri, che inventarono la scrittura cuneiforme per condividere la conoscenza sui confini dei campi dei diversi contadini. Era un problema durante il medioevo, dove i poemi medioevali avrebbero dovuto sopravvivere ai personaggi reali o di fantasia di cui narravano le gesta. Era un problema per il mondo pre dot-com revolution, dove un progetto nato in ambito militare era diventato il mezzo fisico per condividere la conoscenza. Era un problema parzialmente risolto subito dopo, dove quelli che sarebbero diventati le nuove super-potenze capirono che dietro alla complessità della strutturazione della conoscenza solo una ricerca testuale e poco vincolata avrebbe potuto governare questo nuovo mondo. E allora Yahoo, i fratelli Lycos, Google, tutti colossi nati negli anni 90, battezzarono la nascita di una nuova era.

Oggi nessuno si pone più il problema di chi abbia ragione su un dato argomento: ricordo ancora quando ero piccolo, quando a tavola una discussione diventava troppo animata, mia madre andava a prendere l’enciclopedia per sancire chi avesse ragione. Oggi basta “googlarlo” o cercarlo su wikipedia.

Quindi nel mondo comune l’idea di un singolo motore di ricerca che ci da accesso a tutta la conoscenza disponibile è talmente scontato che nessuno si immagina di vivere senza.

Ma perché non si può dare per scontato lo stesso servizio all’interno dei perimetri aziendali?

Immaginiamo un’azienda manifatturiera che vive della genialità e capacità dei suoi reparti di ingegneria e ricerca e sviluppo. Quanto sarebbe comodo per loro avere un motore di ricerca che contiene tutti i documenti progettuali, tutti i Cad o il codice sorgente, i capitolati, le presentazioni, i manuali, i ticket dei bug aperti, le distinte base, i dati sui fornitori, i dati sui clienti, le informazioni delle linee di produzione, la tracciabilità. E’ un desiderio utopico?

E’ in questo contesto specifico che la scelta make or buy diventa ancora più sottile: esistono sistemi “off-the-shelf” con connettori per collegarsi ai più comuni software di mercato e con tantissime features mirabolanti, dalla ricerca nelle immagini, alla similarità fra documenti, alla ricerca testuale. Ma poi “il sistema di PLM (product lifecycle management) ha una serie di customizzazioni”, “quelle altre informazioni le teniamo su un excel”, “per avere questo devi prendere le mail”, “ci sono poi dei documenti pdf da elaborare per estrarre il cartiglio”, “attenzione, il nome del prodotto è il nome del file”, … spesso seguendo pedissequamente l’idea del buy per “evitarsi grane” ci si porta solo a casa una complessità e inefficienza molto grande. Quindi vediamo sistemi che sono veramente avanzati e completi, come Cadenas, portarsi a casa tantissime funzionalità pronte per l’uso, ma faticare a portarsi a casa quell’ecosistema complesso di software, soluzioni, regole, abitudini sedimentate che spesse volte rappresentano le vere sfide nelle grosse realtà industriali.

Allora no, voglio fare tutto io” potrebbe balenare nella testa del manager: “costruisco l’indice”, “costruisco il mio OCR“ (software per riconoscere il carattere nelle immagini), “costruisco il mio connettore a Teamcenter” (uno dei prodotti più diffusi nel mondo della PLM). Sarebbe molto bello, ma quanto costa? Quanto tempo ci vuole? Chi mi garantisce che sarà compliant con tematiche normative come quelle legate ai dati e alla GDPR? Quale strategia scegliere? La scelta migliore è probabilmente il make and buy, ottenibile con un approccio molto semplice:

  • Disegno l’architettura e la soluzione
  • Identifico i componenti logici utili per realizzare la soluzione
  • Componente per componente
    • Valuto quanto mi costi farlo
    • Valuto quanto mi costerà mantenerlo
    • Valuto quanta personalizzazione mi servirà

Tornando al nostro problema, la gestione della conoscenza, servirebbe:

  • Un componente per estrarre i testi da qualsiasi tipo di file (immagine, cad, pdf, excel, documento, …)
  • Una serie di connettori per estrarre i file dai vari sistemi legacy
  • Un contenitore che ospiti il processo e faccia si che l’estrazione sia incrementale (ogni giorno voglio solo i file nuovi, non tutti i file ogni volta)
  • Un engine che permetta di indicizzare questi testi
  • Un’applicazione web che permetta di interrogare questo engine con un’esperienza utente il più vicina a quella che è abituata ad avere (text-box di google ad esempio)

Connettori e logiche probabilmente trovandoci davanti a sistemi custom ha molto senso costruirseli, così come una semplice applicazione web. Engine di indicizzazione molto meno, esiste uno standard de facto open source di nome Lucene, disponibile vanilla o attraverso varie distribuzioni (come Azure Search).

L’estrazione dei testi, che sembra quasi la parte meno importante, diventa vitale: la sola idea di coprire qualsiasi casistica di formato scoreggerebbe anche il più accanito sostenitore del make. Che soluzioni esistono sul mercato per questa “nicchia”? In realtà non moltissime. Sicuramente Aspose è un sicuro candidato per questo ruolo (soluzione che alla fine abbiamo adottato in ogni nostro progetto/prodotto), per via sia della copertura notevolissima dei possibili formati, che per la possibilità di utilizzare qualsiasi tipologia di linguaggio di programmazione. Di fatto è l’unica soluzione che copre sia la parte puramente “office” che formati più complessi come i vari CAD. Anche se a prima vista potrebbe non sembrare un prodotto “economico”, andando a vedere la quantità effettiva di feature offerte, nel momento in cui c’è la possibilità di ri-utilizzarlo su più progetti e quindi ripartire il suo costo, la scelta diventa veramente semplice da fare. In questo momento ci sta permettendo, oltre all’estrazione del testo da qualsiasi formato file (e parliamo anche di cose assolutamente esoteriche come i QAF, formati mai sentito prima di incontrarlo in un progetto), di fare in maniera semplice e intuitiva le thumbnail di preview del documento (feature molto apprezzata dagli utenti che utilizzano il motore di ricerca tailor made sulle loro esigenze).

Quindi… scegliere tra make or buy non è mai una scelta banale e scontata, che viene resa più semplice trovando prodotti “primi della classe” (best of breed) come Aspose, in grado di accelerare progetti complessi e far si che sia possibile fare focus sulle parti applicative delegando una grossa complessità alle sue librerie.

Ti interessa scoprire come applicare potenti e innovativi modelli predittivi per calcolare il rischio?

Compila il form in basso per richiedermi una consulenza gratuita.







AccettoNon accetto


AcconsentoNon acconsento