L’implementazione di un processo di lettura ottica può avvenire a più livelli:

  – acquisto di una soluzione software di lettura ottica già configurata, ready-to-use;
  – acquisto di una soluzione software di lettura ottica configurabile in autonomia;
  – acquisto di componenti software da integrare in una propria applicazione.

Nei primi due casi la scelta è limitata alla sola fase di configurazione del software: è meglio demandare al fornitore tutte le attività di configurazione? O conviene configurarsi tutto da soli? La scelta dipende da cosa occorre sviluppare, dalla complessità del progetto, dal tempo e dalle risorse a disposizione, dall’esperienza del fornitore nell’ambito di nostro interesse, e dall’eventuale ripetibilità del progetto: se per una lavorazione una tantum può risultare conveniente demandare tutta l’attività di configurazione all’esterno e avere una soluzione “chiavi in mano”, per una lavorazione ricorrente o nel caso in cui si preveda un utilizzo del software su più progetti potrà invece risultare più conveniente la strada della configurazione in autonomia. 

Nella maggior parte dei casi la scelta vincente è a metà strada: le attività iniziali di configurazione sono demandate al fornitore, e sono seguite da un percorso di formazione mirato al raggiungimento di un adeguato livello di autonomia. Tra i tanti vantaggi di questo approccio c’è anche quello di consentire una più rapida visibilità dei benefici derivanti dall’adozione di una software OCR, così da stimolare positivamente tutte le attività successive e creare un ambiente di crescita favorevole. Ovviamente diamo per scontato che la soluzione OCR preveda la possibilità di operare in autonomia, mettendoci a disposizione appositi strumenti utili alla configurazione del software, una manualistica dettagliata e completa (preferibilmente in italiano), degli esempi, tutorial e supporto tecnico: purtroppo non tutte le soluzioni disponibili sul mercato offrono questa possibilità, costringendo il cliente a contattare il fornitore per qualsiasi modifica, anche banale, con la possibilità che i tempi di risposta siano tutt’altro che brevi. 

Qualora sia strettamente richiesta l’integrazione delle funzionalità di data-capture all’interno di un proprio applicativo, è invece possibile ricorrere ai componenti software a basso livello, così da sviluppare “in casa” la soluzione di lettura ottica. Anche qui è possibile seguire più strade, in funzione soprattutto delle competenze tecniche di cui si dispone. Bisogna stare attenti però a non tralasciare nulla in fase di valutazione: come più volte ribadito nelle pagine precedenti, un sistema di lettura ottica è molto più di un “motore OCR”: è probabile infatti che il solo “OCR sdk” non sia sufficiente, e che sia necessario dotarsi di ulteriori sottosistemi di image pre-processing (raddrizzamento, orientamento, allineamento, pulizia, binarizzazione, rimozione linee, imaging, etc.), oltre a sviluppare tutto quanto richiesto per arrivare ad una corretta attribuzione della confidenza di lettura (possibilità di eseguire controlli esterni su file/DBMS, sottosistemi di lookup e auto-correzione, etc.). 

Una valida alternativa è la scelta di soluzioni SDK “complete”, che includano cioè tutte le singole funzioni utili in fase di pre-elaborazione, in fase di riconoscimento e in fase di post-elaborazione. In questo caso sarà possibile configurare le applicazioni di lettura in modo facile, mediante appositi strumenti di Application Design, richiamando la configurazione attraverso una API “all-in-one”, alla quale passeremo il file da processare e la configurazione (template) da utilizzare. In questo modo avremo a disposizione tutte le funzionalità del software di lettura ottica in un unico componente integrabile.