Le piccole aziende e l’informatica: da dove iniziare?

Autore: Ivan Codarin
Pubblicato il 24 aprile 2007

Post Correlati

• Nessun post correlato

Ricollegandomi alla scorsa puntata vorrei proporre alcuni spunti dai quali partire per introdurre nella propria piccola azienda una gestione informatizzata dei processi.

Molte volte mi sono trovato davanti ad imprenditori che richiedevano un’immediata e completa riorganizzazione dei loro sistemi informativi con l’idea che ciò che stavano utilizzando era completamente sbagliato ed inefficiente.
Nella gran parte dei casi mi sono trovato a lavorare “contro i miei interessi” consigliando un atteggiamento più prudente per diversi motivi:

1. le persone (e quindi gli utenti) sono tipicamente resistenti al cambiamento; sconvolgere tutto il loro modo di lavorare in una sola volta porta ad un elevato rischio di fallimento dell’intero progetto nonchè delle ambizioni dell’imprenditore;
2. affrontare in una sola volta un cambiamento “totale” porta spesso a progetti troppo lunghi nel tempo; la loro dimensione temporale, poi, si riflette nella modifica dei requisiti software che si erano espressi e quindi dei cicli di revisione del sistema stesso ancor prima che questo possa entrare in produzione;
3. il costo economico di operazioni di questo genere è elevato e spesso troppo rischioso.

E quindi? Cosa si può fare?

In molti casi si pò partire automatizzando e innovando le piccole cose ma tenendo in considerazione che tutto questo, alla fine, deve confluire in un sistema globale, centralizzato ed integrato.
Semplice a dirsi, molto difficile a farsi ma soprattutto equivale a fidarsi di qualche persona che abbia capacità adeguate nel guidare l’azienda in questo processo di innovazione e che tenga il “filo logico” delle varie mosse che verranno compiute.

Cerco di spiegare con un esempio semplice un contesto (a dire il vero abbastanza banale) sul quale mi sono cimentato alcuni anni fa; consideriamolo come case-study.

Un ente faceva affidamento su un sistema per la gestione degli studenti basato su Microsoft Access 97; di questo programma avevano un’unica licenza poichè a turno utilizzavano un’unica postazione per inserire pagelle, voti, piani di studio, ecc.
Ogni anno accademico i dati venivano copiati ed archiviati su un file .zip, messi su un dischetto e riposti da qualche parte.

E’ chiaro che questo pone qualche problemino ad un manager che vuole verificare i dati degli studenti di 3 anni fa oppure confrontare delle statistiche negli ultimi 5 anni, vero?

Mi venne affidato l’incarico di rivedere il tutto e la mia proposta fu:

1. centralizzare tutti i dati degli studenti in un unico database opensource (su richiesta dell’ente ed in questo caso PostgreSQL);
2. realizzare un serivizio Web accessibile per tutti gli utenti (docenti, studenti, staff amministrativo ed altri);
3. realizzare un sistema di statistica, reportistica PDF ed esportazione su sistemi di Office Automation;
4. lasciare “la porta aperta” per integrare altri sistemi.

Tempo massimo in cui produrre la centralizzazione dei dati? 3 mesi lavorando 1 giorno per settimana… praticamente impossibile.

Ulteriore problema, quando si ri-progetta un database, le sue strutture dati, i tipi di dato, la quantità e la qualità delle informazioni sono diverse…
E poi? Senza un’interfaccia grafica non è possibile accedervi!
In quei “3 mesi” e con quel ritmo è impensabile metterci vicino un’interfaccia per un DB che alla fine conta circa 160 tabelle ed altrettante view.

Utilizzai un approccio per gradi, per piccoli passi.

1. ridisegnai il DB completamente, normalizzandolo e aggiungendo la struttura per i contenuti informativi futuri;
2. attraverso una simpatica feature di PostgreSQL (denomiate rules) creai una serie di view (query) che fingevano di essere le vecchie tabelle di Access (ma centralizzate, normalizzate su un DB degno di questo nome) con la grossa caratteristica di essere inseribili, modificabili e cancellabili;
3. attraverso drivers ODBC di PostgreSQL redirezionai l’interfaccia di Access verso il nuovo database.

Risultato del tutto:

• gli utenti hanno lavorato per qualche mese senza accorgersi di nulla;
• il management aveva tutte le statistiche di ogni anni a portata di clic;
• io in quei mesi di latenza ho avuto l’opportunità (ed il contratto) per realizzare un’interfaccia Web decente (Java+JSP) che ha sostituito completamente Access;
• l’imprenditore ha potuto vedere i progressi man mano che questi venivano prodotti; senza dover pagare una grossa cifra alla cieca e rendendosi conto che le cose andavano avanti e che producevano “valore aggiunto” (permettetemi questa terminologia commerciale).

Quel progetto attualmente mi impegna ancora con estensioni che nessuno avrebbe “potuto immaginare” partendo da quel povero file Access (ora il sistema è disponibile per diversi istituti sparsi qua e là per il Mondo con circa 5.000 utenti).

Penso che un approccio di questo genere sia ottimale per le piccole aziende che non possono permettersi investimenti di molte decine di migliaia di euro per vedere “se qualcosa migliorerà”. Molte tecniche di progettazione software (denominate Agili) di cui parleremo presto hanno tra i loro principi base quello di “rilasciare spesso funzionalità che offrono valore/utilità al cliente” non arrischiandosi in progetti costosissimi, lunghissimi e con alti rischi.