La nascita e lo sviluppo di software

“assemblati” (Software and Organisations p.45)

Presupposti :

-capacità e possibilità generiche possono essere

applicate ad un vasto insieme di usi;

-soluzioni standardizzate da applicare a diverse

situazioni possono essere utili non solo
economicamente, ma anche in fase di
programmazione;
Storicamente
’80 software per applicazioni industriali generali.
Ma sembra difficile estrapolarli al di fuori dell’uso e della
funzione per la singola azienda: “isole di automazione”.

→ intereresse a rendere certe soluzioni adattabili

Le prime soluzioni si vedono nel settore dei servizi finanziari per

organizzazioni che conducono operazioni simili (es. credito).
Alcune aziende cominciano a sviluppare le basi di quello che è
oggi il sistema E.R.P. (storica azienda tedesca S.A.P. fondata nel
1972 da tecnici che avevano lasciato l’IBM).
Applicazioni
Organizzazioni commerciali: più flessibili e orientate ai clienti
=> idea di integrare il loro operato con sistemi computerizzati.

Inizialmente per aumentare l’efficienza dei compiti -

Poi a scopi commerciali per il trattamento dei clienti

database clienti diventano una risorsa chiave nel

mercato (ad es. per le banche)
 Post implementazione
(Software and Organisations p.89)

Adozione ERP = investimento, anche se i suoi benefici in termini di

prestazioni dell’organizzazione richiedono tempo, almeno 12 mesi
(Mabert et al., 2001).

→ fase di sperimentazione volta ad identificare gli errori e i

gap tra il
sistema e le attività dell’organizzazione.

Azioni volte al progresso organizzativo.

Importanza dei processi di apprendimento sociale per integrare il
software nelle pratiche e nei processi dell’organizzazione.
Con i software assemblati gli interventi di mantenimento e
aggiornamento cambiano radicalmente:

esigenze di “commodificazione”

I miglioramenti diventano una fonte di guadagno per i

distributori di software E.R.P.
Ma si deve anche trovare un equilibrio tra le nuove esigenze
degli utilizzatori e il numero di versioni e aggiornamenti
esistenti.
 SUPPORTO POST-
IMPLEMENTAZIONE
• SFIDA: i venditori devono fornire supporto
nella post-implementazione dei pacchetti
di software e adattare il prodotto standard
al contesto e agli scopi degli utilizzatori
• PROBLEMATICHE difficilmente individuabili
che derivano dalle relazioni impreviste tra
le componenti in differenti condizioni e
dalle interferenze nelle operazioni del
sistema
• Conoscenza tecnica in continua evoluzione
 SOLUZIONI

• Progettazione modulare
• Importante individuare interazioni tra
un prodotto e le altre componenti
della infrastruttura socio-tecnica in
diverse condizioni
• Conoscenza tecnica spesso acquisita
e comunicata informalmente
 EVOLUZIONE DEI SISTEMI

• Innovazione incrementale
• Transizioni causate anche da
cambiamenti nei sistemi e nel
business
 DUE LINEE

1. Cambiamenti nelle infrastrutture

tecniche: component-based
architecture vs component based
technologies (verso architetture
alternative basate su piccoli gruppi
flessibili e personalizzati)
2. Cambiamento degli obiettivi
commerciali: da prospettiva interna
all’impresa alla competizione
• Utilizzo di protocolli composti di
interfaccia e standard di integrazione
(modello di rete di sistemi
interoperativi)
• Sotware as a Service (Saas) anche
per le piccole e medie imprese