In questa edizione de Il Caffè Sospeso, Gian Franco Stucchi descrive l’analisi della Internet value chain, un modello di riferimento per la pianificazione delle attività di e-business. ed evidenzia come essa non prenda in considerazione solo le modalità di risparmio dei costi, ma si rivolga anche agli aspetti legati alla produzione di valore aggiunto di un sistema reticolare.
L’avvento di Internet come strumento economico efficace ha avuto – e continua ad avere, sia sulle aziende, sia sui loro sistemi informativi – un impatto dirompente, superiore a quello che si manifestò su queste unità organizzative aziendali a causa della diffusione del personal computer. La stampa specializzata in Management dell’ICT oggi si concentra con enfasi crescente sui due principali aspetti legati a Internet e al web, ovvero sulle possibili strategie da adottare e sugli aspetti economici del “fare business” su Internet (o con Internet).
Eppure, dato il mare magnum di pratiche, lezioni e aneddoti al riguardo, si avverte seriamente il bisogno di capire quali sono gli elementi comuni e le particolarità che distinguono le aziende web-based (o web-oriented) dalle aziende tradizionali. In particolare, è di fondamentale importanza capire se le tradizionali metodologie di pianificazione strategica sono ancora valide quando vengono applicate a questa specie di business, e se sì, in che modo.
Nel tentativo di fornire una risposta a questa domanda, ci si avvarrà nel seguito di due paradigmi, classici ma piuttosto significativi, ovvero dell’analisi della Internet value chain e dell’economia dei costi di transazione, oltre che dei risultati di un’ampia serie di ricerche sui sistemi informativi strategici e sul valore dell’informazione, al fine di fornire una struttura che sia di aiuto per formulare una strategia di e-business.
Ancora prima che ci si rendesse conto dell’immenso potenziale di Internet come strumento per acquisire un vantaggio competitivo, era già chiaro il potenziale insito nei sistemi informativi aziendali e dell’impellente necessità di teorie, tecniche e strumenti di pianificazione di tali sistemi. La pianificazione strategica dei sistemi informativi (talvolta indicata con l’acronimo SISP, Strategic Information Systems Planning) si basa, in generale, sull’analisi delle informazioni e dei processi operativi e decisionali di un’impresa, effettuata tramite l’impiego di modelli volti a valutare i rischi, le esigenze attuali e i requisiti dell’organizzazione.
Il risultato è un piano d’azione che, riportando il corso ideale degli eventi, consentirebbe di sincronizzare, in un circolo virtuoso, generatore di valore, l’uso delle informazioni, le esigenze informative e la direzione strategica dell’azienda. Alcune caratteristiche della pianificazione strategica delle informazioni, che possono essere d’ausilio per la definizione di una struttura di e-business, sono le seguenti.
| Compito principale | acquisire un vantaggio strategico/competitivo; realizzare un collegamento con la strategia di business. |
| Obiettivo principale | sviluppare pienamente le opportunità; integrare il sistema informativo e le strategie di business. |
| Direzione | dirigenza e utenti aziendali, coalizione di utenti/dirigenza e sistemi informativi. |
| Approccio | imprenditoriale (innovazione da parte dell’utente) e nel contempo bidirezionale (analisi top-down, sviluppo bottom-up). |
La pianificazione strategica dei sistemi informativi, con o senza il web, non è un compito facile poiché si tratta di un’attività profondamente integrata con i vari processi aziendali. Questi sistemi devono essere in grado di soddisfare le esigenze strategiche ovvero devono essere al servizio degli obiettivi di business e dell’acquisizione di un vantaggio competitivo, soddisfacendo, nel contempo, le esigenze di elaborazione dei dati e di MIS (Management Information System). Per ottenere tale obiettivo è di fondamentale importanza che le direzioni aziendali non considerino i sistemi informativi come semplici strumenti per la riduzione dei costi bensì come mezzi per generare valore aggiunto.
L’impatto principale dell’IT sulla conduzione di un’impresa sta infatti nel ridefinire e riorganizzazione la struttura aziendale piuttosto che nel ruolo di elaborazione dati/MIS. L’e-business apre una nuova gamma di opportunità per l’utilizzo dell’IT all’interno di un’azienda: la tecnologia trasforma l’azienda, divenendo, in alcuni casi, essa stessa business. Come hanno rilevato molti studiosi di Management, talvolta in tono drastico ma realistico, “… le aziende che non pianificano i propri sistemi informativi in modo strategico non saranno in grado di individuare le implicazioni di business insite nell’utilizzo dell’IT, finché non sarà troppo tardi per porvi rimedio. Infatti, in situazioni simili, ovvero quando l’IT cambia le basi della competizione all’interno di un mercato, gran parte delle aziende che vi operano scompare entro i primi dieci anni”.
Questa osservazione assume proporzioni ancora più sinistre per le aziende web-based, visto che attualmente la tecnologia richiesta per portare un’organizzazione sul web è alla portata di qualsiasi impresa, anche della più piccola.
Una classificazione delle metodologie SISP le ripartisce in due categorie: quelle a impatto e quelle di allineamento. Le metodologie cosiddette “a impatto” aiutano a creare e giustificare nuovi utilizzi dell’IT, mentre le metodologie di “allineamento” consentono di allineare gli obiettivi IT con quelli aziendali.
La metodologia da impiegare per pianificare il trasferimento di una o più attività sul web dipende dal ruolo che si intende destinare a Internet all’interno dell’azienda. Se essa verrà utilizzata solo come strumento di posta elettronica o di connettività interna, allora sarà utile scegliere la prospettiva di allineamento, ma se il web verrà impiegato come strumento alternativo per fare business ovvero per raggiungere clienti, fornitori e partner, per creare organizzazioni e gruppi virtuali di utenti e partner, per svolgere transazioni commerciali e finanziarie online, allora si dovrà scegliere la prospettiva a impatto. In realtà è proprio questo che si dovrebbe intendere come “fare business sul web”, ovvero disporre di un’alternativa elettronica al mercato tradizionale, alternativa che non è solo pratica, ma anche molto più efficiente, tale da valicare i confini geografici e i fusi orari, che cresce a un ritmo senza precedenti, che presenta barriere di ingresso ridotte, che si rinnova a una velocità impressionante e, per confondere ulteriormente le cose, che si basa su vari paradigmi di business.
L’analisi della Internet value chain fornisce una struttura per la pianificazione dell’e-business. Essa infatti non si rivolge solo dell’aspetto del risparmio dei costi, ma, in particolare, agli aspetti legati al valore aggiunto generato da un sistema organizzato, aperto, organizzato e finalizzato. In quanto tale, può essere di grande aiuto nella valutazione dell’impatto che la tecnologia dell’informazione e della comunicazione può avere su un’impresa. Il concetto che sta alla base della value chain è presto detto: si considera l’azienda come una serie di attività eseguite per progettare, produrre, vendere, consegnare e supportare determinati prodotti/servizi e in tale contesto la tecnologia dell’informazione costituisce una delle attività di supporto principali per la value chain. I sistemi informativi svolgono poi un ruolo cruciale nella value chain, in quanto ogni attività di valore crea e utilizza informazioni e può influire sostanzialmente sul vantaggio competitivo dell’azienda. Secondo Michael Eugene Porter, professore alla Harvard Business School e “ideatore” della value chain, un’azienda che riesce a scoprire una tecnologia più avanzata per lo svolgimento di un’attività, consegue un notevole vantaggio competitivo rispetto alla concorrenza. In breve si può definire l’analisi della catena del valore come una forma di analisi dell’attività aziendale che scompone un’impresa nelle sue parti costitutive; aiuta ad adottare una tecnologia che consente di aumentare il profitto aziendale; supporta l’identificazione del vantaggio competitivo potenziale che può essere realizzato grazie all’interscambio di informazioni tra aziende che compongono la value chain estesa (siano queste aziende appartenenti allo stesso settore oppure operanti in mercati correlati); si concentra sulle attività aziendali che possono creare valore aggiunto (e naturalmente dipende dalla struttura organizzativa dell’azienda).
Internet influenza positivamente ciascuna parte della value chain. Oltre ai costi contenuti richiesti per pubblicizzare un prodotto sul web, bisogna anche considerare che una parte considerevole del costo di marketing viene sostenuta dal consumatore, ovvero da colui che acquista un computer, un modem, una connessione a Internet e così via. Con il miglioramento e la diffusione della tecnologia, un numero sempre crescente di consumatori disporrà di una connessione a Internet tramite device sempre più economici o mobili. Quando ciò avviene, la funzione di costo è simile a quella applicata alla televisione e ai canali televisivi di marketing, dove i consumatori investono in tecnologia e servizi per il valore educativo o di intrattenimento, oltre che per il vantaggio di poter fare acquisti standosene comodamente seduti a casa.
Una dettagliata analisi della value chain può rivelarsi utile in vari modi per aiutare le aziende a formulare la propria strategia di e-business. Essa infatti fornisce una struttura solida e intuitiva per valutare l’impatto di Internet all’interno dell’azienda; offre metodi innovativi di tipo “forward & backward chaining” per sfruttare al massimo l’utilizzo di Internet. Proiettando la visione su una scala più ampia, grazie all’interscambio di informazioni all’interno dell’azienda e tra i vari partner della value chain, i manager delle aziende sono in grado di acquisire una panoramica più completa ed estesa, che consente di individuare nuovi metodi per riorganizzare e migliorare la propria attività. Attraverso lo studio del potenziale offerto da Internet in termini di personalizzazione e interattività, le aziende possono fare dei tentativi per implementare le filosofie del “just-in-time”, della gestione della qualità totale, della personalizzazione di massa, è possibile coinvolgere i clienti nella progettazione di prodotti e servizi, ridurre al minimo i tempi di reazione alle mutate esigenze dei clienti. Infine, l’analisi della value chain consente di comprendere meglio l’intero funzionamento della “system chain” (o supply chain estesa), in modo che alcuni flussi di informazione possano essere commercializzati come prodotti/servizi. Questa cristallizzazione e commercializzazione dell’informazione è estremamente facilitata dalla connettività interattiva raggiungibile tramite Internet.
Le aziende che svolgono questo tipo di analisi devono tuttavia tenere presente che una parte dei vantaggi appena elencati, come accade nel caso della maggior parte degli investimenti nelle nuove tecnologie, sono di tipo “qualitativo” e non sempre possono essere misurati con la precisione ottenibile nel caso dei tradizionali sistemi di contabilità. Il che, per inciso, è un limite dei sistemi contabili, non della tecnologia.
Di Gian Franco Stucchi
Dall’evoluzione delle interazioni tra impresa e cliente, una tendenza sempre più importante nel contesto competitivo, emergono alcune proprietà caratteristiche del CRM descritte da Gian Franco Stucchi in questa edizione de Il Caffè Sospeso.
Sembra così ovvio che per competere efficacemente in ogni settore socio-economico – e non solo da oggi – le imprese, e in generale le organizzazioni, devono focalizzarsi sia sulla loro attività caratteristica (e condurla bene!) sia sui loro clienti (e trattarli bene!).
Purtroppo troppe imprese hanno assunto implicitamente, quasi fosse un dogma, la convinzione che i loro prodotti e servizi fossero così nativamente superiori a quelli della concorrenza da pensare che potessero imporsi “de facto”. Nell’attuale contesto socio-economico, così altamente competitivo, il management delle imprese di ogni tipo non può confidare esclusivamente sull’attrattività dei suoi prodotti o di un brand perché i clienti diventano sempre più sofisticati nelle loro richieste, domandano prodotti e servizi nuovi, con maggiore varietà e in tempi minori, chiedono livelli di servizio più elevati e rapporti più stretti con i propri fornitori. Per tramutare questo scenario in un’opportunità competitiva la risposta giusta sembra essere l’adozione di un modello di business basato sul Customer Relationship Management (CRM).
La prima domanda che qualunque impresa deve porsi è relativa all’identificazione del cliente. Per raggiungere una posizione di eccellenza bisogna capire chi sono e di cosa hanno bisogno, esaminando il loro comportamento, le loro caratteristiche distintive e qualificanti.
Il termine “cliente” originariamente era riferito alla persona o all’ente o all’unità organizzativa che aveva il compito di acquistare un prodotto o un servizio erogato da uno o più fornitori. Aree di business quali il Marketing e il Servizio Clienti possono includere in questa categoria altri attori della vita e dei processi d’impresa, per esempio chi decide di acquistare o chi influenza le decisioni d’acquisto e, oltre all’utilizzatore finale, anche i dipendenti, identificati come i clienti “interni”. La visione del cliente come “colui-che-paga” non è più sufficiente per determinarne l’identità, le caratteristiche e le abitudini, quindi la definizione emergente e ormai consolidata è quella di tipo marketing-oriented secondo la quale la parola “cliente” designa tutti coloro con i quali si stabiliscono relazioni di business, siano essi interni o esterni all’impresa o all’organizzazione, ovvero gli stakeholder
.
Sebbene sia considerata una tematica rivoluzionaria da parte di alcune imprese ultra-conservatrici, il CRM è una testimonianza dell’evoluzione naturale dei processi di marketing e di vendita. In passato, i clienti venivano serviti dai negozi situati nelle vicinanze, “sotto casa”, e dai venditori “porta a porta”. Il negozio era piccolo, intimo, e provvedeva a fornire un bene e/o un servizio personalizzato alla sua clientela; i venditori porta a porta erano la personificazione della loro azienda e le relazioni personali da essi stabilite con i clienti costituivano, talvolta in misura maggiore dell’eccellenza del prodotto, i fattori critici di successo di ogni azione di vendita.
L’era del marketing di massa ha spazzato via l’intimità della vendita diretta: la produzione centralizzata, realizzata su larga scala, la distribuzione su un’area geografica sempre più estesa e variegata, una comunicazione a senso unico e ad ampio raggio hanno creato un’enorme varietà di prodotti/servizi che sono alla portata di tutti (basta avere quattrini!). Questa combinazione ha messo sotto pressione il poco efficiente modello precedente, tant’è vero che il piccolo negozio è stato sostituito dai supermercati, dai megastore e dai centri commerciali (anche se oggi molti santuari del consumismo sono costretti contenere le proprie mire espansionisti e spesso a chiudere i battenti).
Mentre la società, in generale, ha tratto beneficio in termini di riduzione dei costi, sicuramente il singolo consumatore ha perso quella “intimacy” che aveva con suo negoziante e grazie alla quale recepiva il rapporto come una sorta di fornitura di un servizio personalizzato, che probabilmente era reale, pazientemente costruito nel tempo. Lo scopo principale del marketing era quello di “spingere” il prodotto e creare un rapporto di fedeltà al marchio; la misura del successo di questa strategia era la quota di mercato.
Nella metà degli anni Ottanta, con lo sviluppo e l’affinamento della tecnologia associata al Direct Mailing ed al Telemarketing”, nasceva un nuovo approccio per comunicare direttamente con il cliente con la creazione delle Targeted Customer Base .
Al contrario del Mass Marketing, il Target Marketing aveva il vantaggio, se colto, di ricevere un responso diretto dal cliente. La strategia generale era quella di portare alla luce potenziali clienti contattando un gran numero di persone. La quota di mercato rimaneva comunque la misura del successo del business.
Il Target Marketing riconosce la necessità di interagire maggiormente con il consumatore, quantunque ad un livello superficiale, ma non va oltre. C’è una mancanza di dati specifici in quanto si tende a estrarre informazioni su particolari categorie di clienti (il target) partendo comunque da dati che sono relativi a tutto il campione. Ciò nondimeno, il Target Marketing è una tappa significativa nell’evoluzione dell’odierna filosofia di Customer Orientation.
Il CRM è il passo successivo nell’evoluzione del rapporto Cliente-Fornitore e spinge le aziende verso lo sviluppo di una familiarità con il cliente, usando gli strumenti attualmente disponibili e mantenendo i sistemi produttivi e distributivi esistenti. Esso riconosce che l’equazione che lega la fiducia e la fedeltà del cliente, ha due variabili: la prima è la conoscenza, che comprende l’informazione e l’analisi: bisogna sapere cosa il cliente vuole, le sue necessità e ciò che ritiene utile; la seconda è la necessità di sviluppare l’interazione, il contatto personale e l’attenzione alle modalità con le quali l’azienda interagisce con il suo ambiente. Le due pietre angolari del CRM sono quindi la piattaforma della “knowledge of customer information” e la piattaforma della “customer interaction”.
In definitiva, al fine di ottenere miglioramenti continui, è necessario analizzare i risultati della “customer interaction” e usarli per raffinare le azioni future. Questo implica la capacità di acquisire delle informazioni essenziali scambiate attraverso i punti di interfaccia (i cosiddetti touchpoint). Il successo di una strategia centrata sul cliente è misurato non solo dalla quota di mercato ma anche dalla “share of customer” intesa come la percentuale (share) di una certa tipologia di cliente che si rivolge all’azienda: è ovviamente diverso avere tanti clienti poco profittevoli dall’avere pochi clienti molto profittevoli.
Ma qual è la natura del CRM? E’ necessario, innanzitutto, convenire su un’argomentazione fondamentale: il cuore del CRM è più di un insieme di tecniche manageriali e certamente è un processo ripetibile che assicura risultati consistenti e sempre crescenti. Il CRM comprende l’acquisizione e lo sviluppo di conoscenze sul cliente per permettere all’azienda di vendere in maggiore quantità e più efficientemente i propri prodotti/servizi. Ciò vuol dire che l’azienda deve mirare alla soddisfazione del cliente.
L’applicazione delle tecniche di CRM inizia con un’analisi approfondita degli attributi e dei comportamenti del consumatore per raggiungere una sua conoscenza completa, delle sue abitudini, dei suoi desideri e delle sue necessità. Applica poi questa conoscenza alla formulazione di campagne, strategie e piani di marketing. Comunque, gestire la relazione implica anche un’interazione diretta con il cliente, perciò il CRM comprende una rete di touchpoint (Web, Call Center, tool di Sales Force Automation) tramite i quali l’organizzazione può stabilire, coltivare e mantenere interazioni di mutuo beneficio e di lungo termine con il cliente.
Molto critico è l’impatto che il processo orientato al CRM ha sulla forma dell’organizzazione e sul ruolo delle persone che vi lavorano. La chiave di volta di una struttura CRM-oriented consiste nella costruzione di un sistema organizzativo ed informativo “avvolto” attorno al cliente. Questo è particolarmente evidente nei touchpoint, che sono i punti critici nei quali il processo ed il cliente entrano in contatto. L’obiettivo è quindi quello di far penetrare la voce del cliente all’interno dell’azienda ed è per questo che le imprese leader stanno investendo sempre più risorse in strumenti atti a migliorare le interazioni con i clienti.
Siccome il CRM è inteso come un processo ripetibile allora è possibile rappresentarlo come un ciclo che consiste in una fase di valutazione, una fase di pianificazione e una di esecuzione.
La fase di valutazione – che è la più “technology intensive” – è costituita dall’acquisizione di informazioni sul processo e sviluppa un modello del comportamento del cliente-target, usando un combinazione di dati demografici, psicologici e di altro tipo, sia interni che esterni all’azienda. Qui il marketing si porrà alcune domande, probabilmente le seguenti: Chi sono i clienti? Quali sono le loro abitudini e le caratteristiche demografiche? Dove vivono? Vengono applicate misure basate sulla localizzazione geografica? Quanto valgono? Qual è il loro potenziale valore futuro? Cosa e come acquistano? Quali sono le loro modalità d’acquisto? E’ possibile modellare la profittabilità o il rischio associabili ad eventuali rapporti da stabilire e intrattenere con loro? Come possono essere raggiunti? Come hanno risposto in passato alle attività di promozione e attraverso quali canali preferiscono essere contattati? … (e così via poiché le domande possono essere moltissime).
La pianificazione è la parte creativa del processo. In questa fase il marketing decide come meglio affrontare il cliente definito durante la valutazione, progettando strategie e campagne pubblicitarie. Sebbene esistano soluzioni IT disponibili a supportare la pianificazione, la tecnologia non è fondamentale perché il successo è basato sulla creatività.
L’esecuzione mappa gli elementi di interazione con il cliente. In questa fase l’organizzazione mette in campo tutta la conoscenza ottenuta attraverso i propri touchpoint poiché la chiave di volta è l’effettiva interazione con il cliente. Essa ha due dimensioni: l’esecuzione e la gestione delle campagne di marketing e delle strategie di contatto con il cliente; l’analisi dei risultati per supportare le successive campagne. Se questi dati sono raccolti con successo, il prossimo ciclo sarà più produttivo e la ripetibilità del processo ne trarrà beneficio.
Quale potrebbe essere dunque un supporto informatico per il CRM? Ricordiamo che, in generale, un’architettura è frutto di un’analisi e di un piano creato per definire la soluzione di un problema e integrare gli elementi della soluzione in modo tale che essi lavorino insieme come una singola, coesa entità. Più il sistema è complesso, più è necessario un buon piano per coadiuvare gli specialisti dei processi di business e i professional ICT nello sviluppo delle singole attività operative e decisionali.
Tra le strutture informative più adatte a supportare il CRM certamente i data warehouse rappresentano il fulcro delle architetture di riferimento. Ovviamente, dalla loro qualità dipendono tutti i componenti del processo di marketing e l’accuratezza dei risultati che ne derivano. All’interno di questa struttura informativa si individuano tre elementi che è utile commentare.
Innanzitutto l’analisi e la “profilazione” del cliente. Questa attività usa strumenti e tecnologie “ad hoc” per ottenere informazioni sui clienti; valuta le precedenti strategie di interazione e usa gli “analytics” per ottenere indicazioni atte a modificare i differenti tipi di modelli adottati per individuare la propensione all’acquisto di un particolare cliente o gruppo di clienti. I risultati di questa attività sono utilizzati ampiamente nella fase di pianificazione per costruire le diverse campagne promozionali e le strategie di trattamento – che producono poi gli input per una Customer Interaction Platform (esistente o erigenda).
La seconda attività notevole è la pianificazione e la gestione delle campagne. Una volta terminata la fase di analisi/profilazione, è possibile pianificare una grande varietà di strategie di gestione del cliente che aiutano a collegare la valutazione e l’esecuzione del ciclo CRM. I risultati di ogni campagna devono essere raccolti e memorizzati, così che le organizzazioni possano imparare dai successi o dai fallimenti della promozione. Dopo che un certo numero di campagne è stato portato a termine e i risultati raccolti, questi ultimi possono essere analizzati per favorire regolazioni o “aggiustamenti di tiro” su algoritmi e modelli di targeting.
Infine, è utile valutare la struttura e le prestazioni della Customer Interaction Platform. Le imprese (o le organizzazioni in generale) non possono sviluppare una relazione con i loro clienti senza aver istituito meccanismi di contatto diretto e bidirezionale. Questi meccanismi – che sono i già citati touchpoint o “channel” – consistono di tre costrutti architetturali:
– una serie di sistemi automatizzati di vendita, che permettono ai venditori di promuovere prodotti e acquisire feedback dal cliente;
– i call center, che consentono di realizzare un contatto diretto con il cliente;
– il web per gli acquisti on-line.
Il fattore critico di successo per questi touchpoint è la mutua integrazione. I clienti devono poter ottenere la medesima informazione dal web, dai call center e dalle forze di vendita; queste ultime due devono conoscere il cliente e la sua storia in modo non conflittuale; le strategie di vendita e le campagne devono essere coerentemente propagate attraverso questi canali, in modo da assicurare un’altrettanto consistente gestione della relazione.
Tre sono i modi per incrementare la profittabilità: acquisire più clienti, ottimizzare il valore dei clienti esistenti, mantenere più a lungo i clienti maggiormente profittevoli.
Basandosi sulla posizione di mercato che vuole mantenere, un’impresa deve essere in grado di determinare quali sono i clienti che apportano il maggior valore ed identificare qual è il segmento nel quale sta attualmente perdendo competitività. Perdere un cliente oggi è un evento di semplice attuazione e perdere quelli che realmente si vorrebbero mantenere può avere un costo molto significativo.
Siccome il clima economico diventa sempre più competitivo, la lotta sul cliente s’intensifica: l’acquisizione di un nuovo cliente è certamente un’attività a costo elevato. Gli studi di settore dimostrano che acquisire un nuovo cliente costa dalle cinque alle dieci volte in più del costo di mantenimento di un cliente esistente. Il cliente fedele acquisterà più prodotti/servizi durante la sua vita e sarà disposto a pagare un premio, in termini di prezzo, per acquistare da chi ha conquistato la sua fiducia. Perciò, anche se le imprese continueranno a cercare nuovi clienti, investire per mantenere i clienti acquisiti porta a un sicuro ritorno.
Il CRM è nato proprio da questa constatazione e una strategia di business di tipo Customer Centric determina un accrescimento generalizzato della conoscenza (intesa in senso lato, di cultura imprenditoriale e manageriale), permettendo alle imprese di adottare più razionalmente nuovi modelli di business ottenendo un ritorno degli investimenti anche nel breve-medio termine. A partire dagli anni Ottanta, accanto all’affermazione della Customer Orientation, sono apparse sul mercato ICT diverse soluzioni applicative di tipo CRM. Non solo: “Il Cliente è Re” è stato un slogan molto presente e conclamato dalla stampa specializzata, che cercava di convincere il tessuto connettivo dell’impresa italiana che era il momento di investire nulle soluzioni emergenti orientate al “celebrazione” del cliente. Entrarono così nel lessico di tutti i giorni i termini tipici del CRM, poi allargatosi al concetto di “ERM” (Enterprise Relationship Management), inglobando la gestione dei partner aziendali e molto altro ancora.
In quest’ottica, più che un prodotto, più che una tecnologia abilitante, l’approccio al Relationship Management doveva sposare una visione strategica di tipo top-down, che coinvolgesse tutta l’organizzazione e il ridisegno di processi e modalità operative, analitiche e collaborative. Questo, sostanzialmente, è il manifesto di partenza del CRM.
A distanza di anni, oggi il futuro del CRM parte da una presa di coscienza generale che mostra come occorra rivedere modelli e architetture, facendo leva sull’ICT come risorsa abilitante del CRM stesso che porta alla gestione globale del cliente, del singolo cliente.
In nuce, il CRM si avvia (o dovrebbe avviarsi) ad essere una vera e propria filosofia aziendale, più che un semplice complesso di apparati, di applicazioni e di persone.
Di Gian Franco Stucchi
In questo Caffè Sospeso, Gian Franco Stucchi descrive le Balanced Scorecard, strutture informative multi-dimensionali usate per descrivere, implementare e gestire la strategia a tutti i livelli di un’impresa, favorendo la progettazione e la comprensione dei processi operativi e decisionali.
Se la strategia plasma l’azienda, c’è da chiedersi se e come i piani elaborati dal management possano effettivamente raggiungere ogni livello organizzativo. Condividere la strategia significa collaborare per conseguire gli obiettivi comuni, coscienti di quanto si sta facendo, vigili sui risultati e pronti a reagire in funzione del contesto e delle linee guida tracciate. Un organismo collaborativo – in cui ogni cellula si muova all’unisono, reagendo agli stimoli interni ed esterni – è un modello plastico capace di interagire con l’ambiente. L’azienda – fatta di uomini per gli uomini – è molto più simile ad un organismo vivente che non a un modello matematico; ci sono perciò elementi difficili da individuare e quantificare per la complessità delle relazioni che ne maschera le funzioni e la collocazione.
L’ottica funzionale non esclude l’approccio sistemico; anzi la sistematicità metodologica acquista una valenza pedagogica perché traccia una via da seguire, da utilizzare come parametro complessivo ed oggettivo di riferimento. E’ sul piano logico-funzionale della struttura che ci si confronta perché è da qui che scaturiscono strategia ed obiettivi da seguire: la strategia si trasforma nell’unità semantica e la gestione diventa la semiotica d’impresa.
Identificato il linguaggio comune si tratta di definire l’alfabeto da utilizzare affinché tutti si parli davvero la medesima lingua. E’ a questo punto che sistematizzare le fasi di progettazione ed operatività diventa importante: dalla complessità si torna al particolare per sviscerare le tappe di un flusso senza soluzioni di continuità; un flusso costante di operazioni che generano risultati da analizzare e confrontare. L’analisi offre quindi lo strumento più adatto per definire gli obiettivi strategici e poi particolari, associando ad ognuno di essi le operazioni e le unità di misura appropriate. Non sempre e non solo matematica, dunque: in azienda si definiscono obiettivi che sfuggono alla quantificazione con indici e richiedono una valutazione non numerica. Non sempre, infatti, un giudizio espresso può essere trasformato in un numero: l’analisi dimensionale che sovente si utilizza in fisica può chiarire molto bene questo concetto. Mettendo a confronto le unità di misura di grandezze diverse si verifica la coerenza del risultato ottenuto, semplicemente accertando la congruenza tra la relazione matematica scritta e le definizioni delle grandezze in gioco.
Altrettanto accade in azienda: i risultati devono essere coerenti con l’analisi dimensionale delle grandezze in gioco. Chiarezza, coerenza e congruenza: le “3C” – per utilizzare un acronimo tanto gradito al mondo anglosassone – che caratterizzano le strategie. Per ogni “C” è necessario inventare strumenti che concretizzino il requisito e lo comunichino all’intera struttura aziendale. Ad essi se ne aggiungeranno altri che ne misurino le prestazioni.
Le Balanced Scorecard (BSC, in italiano schede di valutazione bilanciata) http://en.wikipedia.org/wiki/Balanced_scorecard si collocano in questo contesto: sono strumenti strategici perché integrano la comunicazione; sono strumenti di controllo perché quantificano i risultati in funzione degli obiettivi. La loro origine è recente. Fu nel 1992 che Robert S. Kaplan, Professor of Accounting alla Harvard Business School, e David P. Norton, presidente della Nolan, Norton Company. Inc., pubblicarono, nella prestigiosa Harvard Business Review, l’articolo “The Balanced Scorecard – Measure That Drive Performance” http://www.hbs.edu/faculty/Pages/item.aspx?num=9161 che rese popolare, per la prima volta, il concetto di Balanced Scorecard.
Estremamente pratico era il problema di partenza da risolvere: si era appurato che gli strumenti disponibili per la misura delle performance aziendali erano inadeguati alle reali necessità del management. La visione parcellizzata non soddisfaceva la necessità di osservare, nella sua complessità, ogni risultato; gli indici escludevano preziose variabili del contesto, offrendo una prospettiva ridotta dei fenomeni da controllare. Si cercava uno strumento olistico, che offrisse contemporaneamente misure operative e finanziarie. Nacquero così le BSC, una risposta pratica ad un problema urgente. Applicate in via sperimentale a dodici aziende di grandi dimensioni regalarono in breve i risultati sperati. Da allora si sono via via migliorate, integrate da strumenti software sempre più adatti alla gestione complessa dei dati e proposte da società di consulenza aziendale dotate di ampia preparazione. Implementare un sistema BSC, infatti, richiede una conoscenza davvero approfondita delle realtà d’impresa ed impone un’analisi capillare delle modalità di gestione della stessa.
Per quanto affinata nel corso degli anni, la struttura portante di una Balanced Scorecard non è cambiata, comunque, da quella proposta nel famoso articolo di Kaplan e Norton. Quattro sono le prospettive focalizzate, che definiscono altrettante aree operative, o macroaree: clienti, attività interna, apprendimento e crescita della struttura organizzativa, finanza. In termini di comunicazione integrata significa individuare i flussi informativi interni ed i flussi esterni. Per ogni macroarea si definiscono poi gli obiettivi strategici generali, gli strumenti e le unità di misura e si fissano tempi e modalità di azione. Il risultato finale è una sorta di matrice a strati multipli – almeno uno per ogni macroarea – in cui si ha visione sinottica della situazione. L’elemento “destabilizzante” rispetto alla consueta reportistica di performance è l’inserimento del tempo come variabile critica di progettazione: la dimensione temporale influenza la gerarchia della struttura e determina la scansione delle misurazioni. Il tempo – nella Balanced Scorecard – non è un elemento accidentale e scontato; è l’elemento discriminante che consente di discernere tra obiettivi e misure. Il nome stesso “Balanced” ne sottolinea il ruolo strategico; e sottolinea come le misure condotte siano bilanciate tra dati interni e dati esterni, tra misure dei risultati raggiunti e misure dei processi futuri, tra passato e futuro.
Fonte: Robert S. Kaplan and David P. Norton, “Using the Balanced Scorecard as a Strategic Management System”, Harvard Business Review (January-February 1996)
Perché adottare un sistema BSC in azienda? Perché definire la strategia senza comunicarla e senza misurarla è come guidare un’auto ad occhi chiusi. Attenzione: questo non significa che non esistano altri strumenti o che la BSC sia la panacea adatta ad ogni azienda. Costi di realizzazione ed implementazione, articolazione del software disponibile e cultura del management ne limitano l’utilizzo. Ciò non toglie che ogni azienda – per quanto piccola – possa fare suo l’approccio metodologico che guida alla BSC, non fosse altro per abituarsi all’idea di progettare, misurare e verificare. Insomma è bene cominciare a pensare che la struttura aziendale non è immobile; si trasforma invece in funzione del contesto in cui opera e degli uomini che lavorano. Plasticità come requisito strategico di partenza: ecco il messaggio da cogliere nella teoria delle Balanced Scorecard. Si diceva poco sopra delle quattro macroaree: optare per un sistema BSC significa innanzitutto agire su quei contesti, per definire un sistema coerente di obiettivi e di indicatori. L’esperienza di Kaplan e Norton dimostra come non ci siano valutazioni univoche; ogni azienda scopre il proprio sistema e plasma le BSC in funzione di quanto identificato.
Andiamo per ordine, seguendo, una per una, le quattro aree definite nella teoria classica. L’universo “Clienti” è un mondo complesso, in cui – alla percezione dei fruitori finali – si aggiunge quella degli operatori interni in azienda. E non è affatto scontato che il sistema obiettivi e misure definito in azienda corrisponda a ciò che veramente chiedono i clienti. Ecco perché il primo passo è quello di scoprire cosa si aspettano gli utilizzatori. E’ anche possibile che queste informazioni esistano già; in tal caso è necessario scovarle e sistematizzarle. Solo a questo punto si può tentare di inquadrare il sistema obiettivi – indicatori. In genere qualità dei prodotti e tempestività del servizio sono considerate le chiavi di sviluppo e gli indicatori più frequenti sono la soddisfazione del cliente, il grado di fidelizzazione, la redditività per cliente, l’acquisizione di nuovi clienti, la quota di mercato per segmenti.
Nella macroarea “Attività interna” si collocano invece tutti i processi aziendali che integrano trasversalmente il business; la complessità d’analisi è subito evidente. Qui si intrecciano dati provenienti dalla produzione, dal marketing, dalla logistica. E’ la catena del valore che richiede una visione integrata dell’azienda.
Quanto a complessità non ne è carente neppure l’area “Apprendimento e crescita della struttura organizzata”. Qui si misura il potenziale di reazione dell’azienda al cambiamento con la conseguente capacità di inventare e introdurre nuovi prodotti e servizi, adeguando filosofie e tecnologie produttive. Si valuta anche la capacità di far crescere il personale. In questa macroarea si misurano così la soddisfazione dei dipendenti, la produttività, il grado di fedeltà, le competenze professionali, la formazione in azienda e quella esterna. Inoltre si misurano i sistemi informativi disponibili e le procedure organizzative, per verificare i livelli motivazionali del personale.
Infine c’è la macroarea “Finanza”, forse quella più semplice, non fosse altro perché i dati sono reperibili con maggior facilità e gli indici sono noti. Gli indicatori sono economici, finanziari e patrimoniali.
Così inquadrate, le BSC si propongono davvero come strumenti di gestione integrata d’azienda: la complessità progettuale è tale da richiedere una revisione approfondita di ogni area; ad essa di aggiungono la ricerca e la gestione dei dati perché siano fruibili dai software dedicati per Balanced Scorecard. Forse le BSC attuali non sono ancora adatte alle PMI italiane ma è certo che la proposta metodologica – opportunamente valutata – può essere di grande utilità alle imprese familiari, impegnate in avvicendamenti generazionali e ristrutturazioni.
Individuare gli indicatori e le metriche per verificare le prestazioni rende indispensabile costruire una infrastruttura informativa adeguata che sia in grado di rendere disponibili le misure, condividere gli obiettivi a tutti i livelli stabiliti, controllare nel tempo la corrispondenza tra piani attuativi e piani strategici, cogliere ed interpretare dinamicamente le interazioni tra indicatori di diverse aree. Le BSC diventano così l’infrastruttura su cui sviluppare uno “Strategic Management System”; conservano un ruolo di controllo ma assurgono al rango di strumenti di pianificazione, concentrando l’attenzione sulla gestione e la comunicazione strategica organizzativa. Optare per un sistema BSC in azienda significa così progettare e realizzare un sistema informativo adeguato, davvero in grado di rispondere ai requisiti richiesti dalla nuova metodologia.
Ciò posto, non sorprende che, in molti convegni, si discuta del rapporto tra BSC e di IT e si presentino interessanti testimonianze e preziosi suggerimenti da parte dei consulenti. Perché un sistema IT possa al meglio utilizzare le BSC è necessario che disponga di un sub sistema di visualizzazione, uno di costruzione, uno di analisi ed infine uno di amministrazione delle BSC. Tutto questo dovrebbe essere fruibile da una molteplicità di utilizzatori autorizzati tramite un insieme di tecniche, dei metodi e dei tool in grado di fornire sia un accesso (regolato) ai dati di un’organizzazione, sia una serie di strumenti d’analisi dedicati a quegli utenti che dispongono di telefoni cellulari o di altri dispositivi web-based, quali i Personal Digital Assistant (PDA), gli iPad, i notebook e altri Mobile Internet Device (MID).
Per visualizzare la BSC è indispensabile, infatti, che il sub sistema sia semplice, fruibile anche da non esperti; inoltre deve fornire il quadro sinottico degli indicatori chiave permettendo l’analisi degli stessi: la compatibilità con gli ambienti di elaborazione distribuiti è fondamentale così come quella con il mondo web, un utile strumento per la diffusione di una “cultura” delle BSC. Il sub sistema di costruzione di norma consente agli utenti di implementare le BSC senza dover programmare. Quello di analisi invece include tutte le operazioni di tipo analitico e statistico richieste da alcune attività inserite nelle BSC. Infine, il sub sistema riservato all’amministrazione del flusso informativo deve raccogliere, depurare e organizzare una notevole mole di dati, con origine disparata (ERP, per esempio); si tratta quindi di costruire una struttura informativa che potremmo definire “Performance Data Warehouse”.
Realizzati i sub sistemi, si passa alla realizzazione del progetto, passando per l’individuazione degli indicatori, l’implementazione del Performance Data Warehouse dedicato ed infine alla personalizzazione e parametrizzazione dell’applicazione che crea la BSC. “Last but not least” – come direbbero gli anglosassoni – si affronta la fase più delicata, quella di messa a regime del progetto: formare il personale è il primo passo. cui però deve seguire un’opera costante di aggiornamento. Il dinamismo strutturale e di contenuti delle BSC impone una continua revisione dei risultati; costringe a responsabilizzare i capi progetto in funzione degli obiettivi ora misurabili; agisce sulla percezione stessa del proprio lavoro – che è diventato quantificabile e verificabile.
Nel pragmatismo della metodologia BSC c’è una dimensione epistemologica che non può sfuggire: verificare e falsificare le teorie per imparare dagli errori e progredire.
In questa puntata del Caffè Sospeso, Gian Franco Stucchi descrive come esse possono risolvere molti problemi posti dai processi di business. La diffusione e la pervasività dell’ICT sono due caratteristiche che favoriscono la collaborazione tra unità organizzative e tra imprese
Business Process definition: “Series of logically related activities or tasks (such as planning, production, sales) performed together to produce a defined set of results. Also called business function” (da BusinessDictionary.com) .
Bella definizione, molto aziendalmente corretta! In effetti, la volontà di costruire i sistemi informativi trans-funzionali, abbattendo i confini delle unità organizzative, non è certo una novità. Già nei primo anni Sessanta i manager delle grandi imprese constatavano la difficoltà che incontravano quando, cercando di correlare le varie attività dipartimentali, dovettero sviluppare dei sistemi di pianificazione e controllo a livello enterprise molto complessi e articolati.
Il fatto che, a distanza di oltre cinquant’anni, molti manager continuino a richiedere sistemi trans-funzionali per il controllo dei processi indica chiaramente che il livello dello sviluppo di sistemi siffatti non è ancora ritenuto soddisfacente (o, nel migliore dei casi, che la richiesta si è fatta più raffinata). I sistemi trans-funzionali hanno sempre sollevato delle questioni di politica organizzativa e di differenze (se non conflitti) nei bisogni informativi delle varie funzioni.
Alcune importanti iniziative di applicazione di questi sistemi sono la prova dei sostanziali cambiamenti che stanno avvenendo nei processi trans-funzionali. Questi sistemi sono importanti perché introducono innovazioni nelle attività di servizio ai clienti e promuovono una rapida crescita della redditività e della profittabilìtà. E’ curioso osservare che le imprese che hanno avuto più successo nell’uso dell’ICT sembrano aver creato innovazioni di processo senza rendersene assolutamente conto (o quasi).
I dati macroeconomici sulla produttività imprese indicano che le aziende non sempre hanno impiegato (e impiegano) nel modo corretto l’ICT per sostenere il cambiamento, anche se siamo nel pieno di un periodo di continui potenziamenti delle funzionalità offerte dalla tecnologia. Le linee di telecomunicazione, sulle quali viaggiava solo la voce, oggi sono i vettori principali dell’invio degli ordini di vendita e per il trasferimento di enormi quantità dì denaro, dei disegni di progetto, di opuscoli informativi di marketing, di meeting, di conferenze. Il computer, che inizialmente aveva automatizzato i procedimenti di calcolo, oggi è un componente dei DSS, “consulenti virtuali” per i processi decisionali. E’ possibile accedere a enormi quantità di testi, dati ed immagini grafiche, simulare i processi e gli effetti causati dai mutamenti di scenario.
Nonostante i “numeri” del mercato di riferimento, a livello macroeconomico diversi studiosi di Management Science non sono mai stato tanto convinti degli effetti benefici dell’ICT. Per esempio, Lester Turow, docente di Economia presso la Sloan School of Management del prestigioso MIT, scrisse: “Possono essere citati casi in cui le nuove tecnologie hanno permesso enormi incrementi di produzione o tagli nei costi, ma alla base non vi sono prove certe che queste nuove tecnologie abbiano aumentato significativamente la produttività o la profittabilità”. Numerosi sono gli studiosi che, già a cavallo di anni Ottanta e Novanta avevano dimostrato come non esistesse una relazione tra le spese per l’ICT e la profittabilità del business. La probabile causa dei mancati incrementi di produttività a fronte di interventi anche massicci dell’ICT sta nel fallimento dei tentativi di utilizzarle per cambiare il modo in cui si lavora.
L’implicita assunzione che l’ICT consente di velocizzare i processi esistenti o di portarli a termine utilizzando una minore quantità di risorse è indubbiamente corretta in alcuni ambienti, ma la mancanza di riscontri economici concreti derivati dall’applicazione della tecnologia informatica indica che questa assunzione debba essere resa esplicita e provata. Non sempre infatti sono chiare le modalità e i termini in cui il miglioramento tecnologico possa davvero incrementare il rendimento dei lavoratori, soprattutto dei cosiddetti “colletti bianchi”.
In altre parole, sia i ricercatori che tentano di capire i benefici dell’ICT, sia i manager che sì sforzano di massimizzare il valore di detta tecnologia, devono iniziare a pensare al cambiamento dei processi come a un fattore di mediazione tra le iniziative d’innovazione e il ROI (Return of Investment ). Bisogna arrivare a un radicale cambiamento di prospettiva: non ci si deve aspettare, per esempio, che un investimento in ICT possa, da solo, dare un ritorno in termini economici, bisogna, invece, arrivare a riconoscere che solo un cambiamento dei (o nei) processi può apportare questo tipo di beneficio e che il ruolo dell’ICT, unitamente ad altri fattori, è quello di rendere possibile la progettazione di nuovi processi.
Il cambiamento, in realtà, deve essere favorito e gestito a diversi livelli organizzativi, dal lavoro individuale al processo di gruppo e alle iniziative strategiche d’impresa. Vanno rimessi in discussione i processi per i quali le applicazioni sono già state create e, se necessario, occorre riprogettare iniziative di sviluppo di nuovi sistemi informativi per incrementare la probabilità di innovazione dei processi.
Se la relazione fra ICT e performance è influenzata dal cambiamento, è molto probabile che incidano su di essa anche altre leve del cambiamento stesso. E’ necessario che le aziende utilizzino l’ICT in maniera congiunta e integrata con un’altra leva d’azione del cambiamento: le risorse umane. Giusto per portare un altro esempio, un’analisi quantitativa dell’investimento in ICT in una grande industria automobilistica ha evidenziato che gli investimenti non davano alcuna produttività o incrementavano la qualità se non erano uniti a contributi d’innovazione, di livello similare, nel settore delle risorse umane. Non a caso le ricerche in quest’area si sono moltiplicate, esplorando, con in particolare attenzione, le relazioni fra le iniziative ICT e l’uso di team auto-gestiti nell’organizzazione della produzione.
E’ già stato rilevato, in base alle esperienze reali, che l’ICT è solo una delle svariate leve che, operando tipicamente insieme, possono produrre dei cambiamenti nei processi. Esse devono essere identificate nella prima fase dello sviluppo di un’iniziativa d’innovazione dei processi. In questa fase si deve valutare, nel contempo, ciò che è possibile implementare, gli ostacoli dovuti alla tecnologia corrente e l’impatto sull’organizzazione. Le leve del cambiamento devono allora essere analizzate accuratamente per determinare i gradi di libertà che un’azienda ha nel mettere a punto le nuove tecnologie e le nuove forme organizzative, e ciò è essenziale per poter effettuare un’analisi costi/benefici corretta e una pianificazione efficiente ed efficace.
Per esempio, l’adozione di un modello innovativo potrebbe richiedere la sostituzione dello staff attuale, un’opzione che certamente non si tende spesso ad accettare nelle politiche aziendali. Parimenti, i cambiamenti nelle tecnologie proposti potrebbero implicare sostanziali revisioni delle applicazioni di base installate, talvolta proibitive dal punto di vista finanziario.
Le principali attività da svolgere per individuare le leve del cambiamento sono:
- l’identificazione del potenziale tecnologico, delle opportunità per il cambiamento di processo e dei fattori di ostacolo all’innovazione;
- la ricerca delle opportunità applicabili a processi specifici;
- la determinazione delle tipologie degli ostacoli che verranno accettate
Dopo aver identificato le opportunità e gli ostacoli potenziali, bisogna determinarne la rilevanza nel processo che si sta analizzando. Si devono ricercare le opportunità per determinare il modo in cui l’innovazione umana o tecnologica potrebbe essere impiegata; gli ostacoli, invece, sono generalmente esaminati più tramite la discussione piuttosto che con la ricerca.
Una domanda che tipicamente ci si pone è: “Quali ostacoli possono essere considerati come sopportabili e quali, invece, devono essere necessariamente rimossi?”. L’analisi di questo punto contribuisce a chiarire meglio le leve che diventeranno parte della visione process-oriented e come dovranno essere impiegate.
Il processo dovrebbe essere progettato prima d’approfondire le tecnologie o i sistemi da utilizzare come leve. Per esempio, l’approccio del Westinghouse Productivity and Quality Center, leader nel pensiero process-oriented grazie a una radicata cultura della qualità totale, è sempre stato: “Prima pensa al processo e poi al sistema”. E’ un approccio interessante ma pericoloso, in quanto rischia di non ottimizzare le logiche di efficienza ed efficacia a causa dell’enfasi ridotta posta sui benefici che potrebbero derivare da un utilizzo integrato e sistematico dell’ICT.
Queste tecnologie offrono delle opportunità ma impongono anche alcune restrizioni alla progettazione. Le opportunità riguardano i nuovi modi per usare le tecnologie a supporto dell’innovazione (si pensi al mobile computing, al cloud computing); le restrizioni sono relative a quegli aspetti delle infrastrutture tecnologiche che non possono, per qualsiasi ragione, essere modificate in un lasso di tempo ridotto.
Le occasioni per supportare l’innovazione dei processi con l’ICT si possono ricondurre a una ristretta gamma di categorie, che presumono la definizione di obiettivi generali di business (riduzione dei costi e del time-to-market, potenziamento del fatturato, ecc.). Le categorie riflettono i mezzi specifici con i quali vengono raggiunti questi obiettivi, ognuno dei quali viene brevemente descritti nel seguito.
Automazione. Il vantaggio più comunemente riconosciuto all’ICT consiste nella sua capacità di eliminare le attività prive di valore e di creare processi più articolati ma flessibili. Questa opportunità, peraltro già utilizzata da lungo tempo nella Produzione, è la sfera d’azione della robotica, del controllo numerico e nel Manufacturing Executive System (MES). Nell’ambiente dei servizi, dove i processi sono definiti da flussi di documenti, le occasioni per l’automazione si basano sempre più su sistemi di gestione documentale che sottraggono carta al processo, accompagnati da package di workflow che definiscono i “sentieri” che gli oggetti di business seguono attraverso un processo.
Informazione. Molte analisi socio-tecniche mostrano che l’informazione può essere usata non solo per ridurre o eliminare il lavoro umano ripetitivo, ma anche per accrescere il lavoro creativo e le attività knowledge-based. L’ICT è spesso impiegata per ottenere informazioni su tutte le attività che compongono un processo, le quali, a loro volta, possono essere utilizzare dall’uomo per migliorare i fattori critici di successo del sistema-impresa o le performance del processo stesso.
Sequenzialità. L’ICT può favorire i cambiamenti nella sequenza dei processi o trasformare un processo da sequenziale a parallelo per ottenere riduzioni dei tempi dei cicli operativi. Questa opportunità è alla base degli approcci progettuali basati sulla cooperazione. Talvolta, con l’aiuto di un database ben strutturato e di strumenti computerizzati di reingegnerizzazione, è possibile progettare per componenti paralleli ciò che in passato era realizzato in base a una rigida sequenza operativa.
Tracking. Per eseguire in modo efficiente i processi della logistica, in particolare quelli impiegati da aziende che operano nel settore dei trasporti, è necessario realizzare un alto grado di controllo e di tracciabilità. La Federal Express, per esempio, controlla un pacco anche dieci volte per essere in grado di localizzare quelli dispersi e per dare al cliente informazioni riguardo lo stato del pacco. Essa dispone anche di mezzi di ricerca via satellite che danno alle imprese di trasporto l’esatta dislocazione di ogni vettore della loro flotta. Vi sono casi di ricerca e tracking anche in processi non logistici. Per esempio, le attrezzature centralizzate di gestione della ricerca della Johnson & Johnson permettono ai manager di controllare i progressi compiuti nel settore della Ricerca e Sviluppo. Tracciare lo stato dei processi permette all’azienda, per esempio, di evitare i colli di bottiglia che si hanno quando si verifica un passaggio contemporaneo di molti farmaci alla fase dei test farmacologici (si bloccano quelli meno promettenti in certi punti del processo di test).
Business Analysis. Nelle attività che prevedono l’esame di informazioni e il supporto decisionale, l’ICT consente di realizzare delle business analysis molto complesse e articolate. Un esempio è dato dall’Authorizer’s Assistant (AA) dell’American Express, un sistema esperto knowledge-based introdotto già alla fine degli anni Ottanta e predisposto per autorizzare gli acquisti tramite carta di credito. L’AA permetteva di raccogliere informazioni sempre più precise, prendeva meno decisioni sbagliate e agiva in un tempo più breve rispetto a qualsiasi persona addetta alle autorizzazioni della società. Un altro caso è costituito dall’analisi del rischio, particolarmente importante per le società di assicurazione. Esse utilizzano l’ICT per identificare, tra gli assicurati, i guidatori ad alto rischio onde stabilire correttamente i premi in base alle varie categorie.
Aspetti geografici. Un beneficio chiave dell’ICT, che risale all’invenzione del telegrafo, è stato quello di risolvere i problemi geografici. Le aziende che operano a livello mondiale si stanno sempre più rendendo conto della necessità che i loro processi si svolgano in maniera efficiente e senza soluzione di continuità in tutto il mondo. Le società automobilistiche, per esempio, usano strumenti assistiti dal computer per progettare e costruire componenti in differenti nazioni, mentre i corrieri aerei internazionali si servono di una rete mondiale per trasmettere informazioni ai propri clienti, in modo che le formalità di scarico delle merci siano risolte prima dell’arrivo delle merci stesse. Infine, è in crescita il numero delle corporation che utilizzano, a livello mondiale, la posta elettronica e i sistemi di teleconferenza per lo sviluppo dei sistemi di pianificazione e controllo.
Integrazione. Le aziende che trovano difficile migliorare radicalmente la performance dei processi, data la distribuzione di compiti altamente segmentati tra molte mansioni, si stanno orientando verso un approccio organizzativo in cui un individuo – o un gruppo di lavoro – sia messo in grado di completare o, almeno, gestire tutti gli aspetti di rilascio di un prodotto/servizio. Tale approccio è usato nell’industria delle telecomunicazioni per approvvigionare la filiera di realizzazione dei circuiti, nelle assicurazioni per la sottoscrizione delle polizze, nelle banche per la concessione dei prestiti e negli ospedali per le cure ai pazienti.
I processi di business – e il BPM (Business Process Management ) – stanno attraendo un’attenzione crescente da parte degli uomini d’impresa. Essi percepiscono che la complessità della situazione socio-economica attuale trova un punto di snodo fondamentale proprio nella gestione dei processi, siano essi rivolti alla riduzione dei costi interni che alla massimizzazione della spinta sul mercato.
Proprio a causa del fatto che questi processi riguardano fondamentalmente il business – e quindi la strategia dell’azienda – scaturiscono spontanee due considerazioni: per il successo del BPM è fondamentale il coinvolgimento, la sponsorizzazione e il controllo da parte dell’uomo di business, mentre per il responsabile dell’ICT si apre l’opportunità di assumere un ruolo di primo piano contribuendo in maniera concreta e proattiva allo sviluppo delle strategie di business della propria azienda.
Riuscirà quindi il CIO a diventare CEO? Ai posteri l’ardua (ed annosa) sentenza.
Gian Franco Stucchi
Dai database relazionali ai database ad oggetti e ibridi fino ai database associativi. Gian Franco Stucchi propone, in questa edizione de Il Caffè Sospeso, una panoramica sulle strutture informative, un dominio informatico antico quasi quanto gli elaboratori stessi
Qualunque sia il tipo di organizzazione aziendale che si intende studiare, dalla più piccola società individuale alla megacorporazione multinazionale, i dati coinvolti in ogni processo a questa afferente, inerente o consequenziale, intesi come elementi costitutivi dell’informazione, assurgono al rango di variabili critiche per lo sviluppo dell’azienda stessa, quando addirittura non sono vitali. I dati possono essere di tipi diversi – finanziari, di prodotto, di clienti, di fornitori, di mercato, di risorse umane ecc. – ma tutti si trovano codificati e memorizzati in qualche forma più o meno persistente all’interno di ogni sistema informativo aziendale.
Ogni sistema di elaborazione dei dati è dotato di un componente software, chiamato (DBMS) che memorizza e gestisce tutte queste informazioni. Questo componente spazia dal più semplice file manager, disponibile in ogni Personal Computer, ai sistemi più complessi, in grado di “stivare” notevoli quantità di dati e di fornire, a un elevato numero di utenti, un accesso simultaneo alle strutture informative.
Secondo le serie storiche delle ricerche di mercato relative al comparto dei sistemi di livello Enterprise il mercato si è consolidato attorno a tre leader assoluti, ovvero Oracle, IBM e Microsoft. Gli altri produttori di sistemi DBMS, anche di quelli molto citati dalla stampa di settore – come Hadoop, MongoDB o HANA – sono ancora poco diffusi a livello di strutture di supporto per le applicazione business-critical.
La diffusione del concetto di database management system (DBMS) coincide con l’introduzione dei primi dischi magnetici come unità di memorizzazione, avvenuta negli anni Sessanta, che ha reso possibile l’accesso quasi istantaneo e puntuale a qualsiasi dato memorizzato, piuttosto costringere uomini e macchine a defatiganti ricerche condotte in modo sequenziale, tipiche dei nastri magnetici e perforati o delle ancestrali – e ormai dimenticate – schede perforate.
Le continue innovazioni a livello hardware hanno stimolato le ricerche sul modo migliore di immagazzinare dati all’interno di un computer allo scopo di renderli facilmente accessibili e gestibili. I risultati via via ottenuti compongono oggi una disciplina scientifica denominata Data Modeling (o Modellazione dei Dati) che ha come oggetto lo studio di varie concezioni dei dati chiamate, appunto, data model (modello dei dati). Un modello dei dati può essere definito come un insieme di meccanismi di strutturazione, o di astrazione, per modellare un database, con certi operatori e vincoli d’integrità predefiniti. I modelli più diffusi, perché adottati dai sistemi commerciali, sono il gerarchico, il reticolare e il relazionale. Il gerarchico si basa su un meccanismo di strutturazione ad albero, il reticolare su un meccanismo a grafo etichettato (rete) e il relazionale sul meccanismo delle relazioni, intese in senso algebrico.
Queste concezioni hanno anche dettato i principi costruttivi dei corrispondenti DBMS , intendendo con “database” un insieme di dati strutturati e permanenti raggruppati in insiemi omogenei in relazione fra loro, organizzati con la minima ridondanza per essere usati da applicazioni diverse, in modo controllato. Tralasciando i DBMS di tipo reticolare o gerarchico, attualmente di scarsa importanza, indubbiamente il modello relazionale è stato quello che ha conquistato, dalla fine degli anni Settanta, la maggior diffusione di mercato, al punto da rappresentare attualmente l’85% dell’intero panorama applicativo. A questo si è aggiunto, a partire dagli anni Novanta, il nuovo modello a oggetti, seguito da quello ibrido oggetti/relazionale, ma nessuno di questi è riuscito a scalfire in qualche modo il predominio del modello relazionale, divenuto ormai uno standard di fatto.
Sostanzialmente il mercato globale dei database può essere suddiviso in 3 diversi settori – database tradizionali; database relazionali; database ad oggetti (object database) – ove gli ultimi due costituiscono l’oggetto e il supporto della maggior parte delle applicazioni attuali, sempre comunque proiettate alla ricerca di nuove soluzioni in grado di meglio soddisfare le mutate esigenze introdotte dalla diffusione di Internet, del Mobile Computing e delle app.
Il concetto di database relazionale deriva in gran parte dall’attività di Edgar Frank Codd, un informatico di IBM che nel 1970 pubblicò uno studio considerato di fondamentale importanza per la Data Science, tanto da essere citato nella prestigiosa ACM Classic Books Series. Anche grazie al contributo di molti altri ricercatori, l’opera di Codd si concretizzò nel “System R”, un prototipo di DBMS relazionale sviluppato presso il laboratorio di ricerca IBM di San Josè, in California. I sistemi commerciali che ne derivarono furono l’SQL/DS e, successivamente, il diffusissimo DB2. Da notare che il linguaggio SQL (Structured Query Language), creato per gestire il System R, divenne uno standard industriale e il riferimento per la versione dell’International Organization for Standardization (ISO).
Il modello relazionale dei dati si basa sulla memorizzazione degli stessi in tabelle che registrano le informazioni specifiche di un particolare tipo di informazione: clienti, fornitori, prodotti, ordini e così via. Entro ogni tabella, ogni riga (o record, tecnicamente tupla o ennupla) rappresenta una specifica istanza dell’informazione memorizzata – un cliente, un fornitore, un prodotto, un ordine e così via – mentre ogni colonna (o campo) identifica uno specifico attributo della stessa memorizzata per ogni cliente, fornitore, prodotto, ordine. Il singolo record è univocamente identificato tramite uno o più campi chiamati chiavi primarie che, con la loro presenza in tabelle diverse, permettono di implementare la relazione tra diversi tipi di informazioni.
Nel modello relazionale ogni tabella è strutturata diversamente, ove la differenziazione è insita nel significato attribuito ad ogni singola colonna o campo, e poiché i programmi applicativi vengono sviluppati facendo riferimento alla struttura delle tabelle, ne deriva che è sostanzialmente impossibile realizzare applicazioni efficienti che accedono a tabelle senza che la loro struttura sia stata precedentemente definita. Conseguentemente ogni nuova applicazione di database relazionale deve essere sviluppata ex-novo, poiché un programma scritto per una specifica applicazione non può essere riutilizzato per un’altra, conoscendo fin dall’inizio e nei minimi dettagli la struttura delle tabelle di cui si fa uso.
Nell’evoluzione dei sistemi informativi si assiste sempre più ad uno spostamento dalla tipica struttura monolitica verso insiemi di server cooperanti e consolidati, collegati in rete e a Internet. Il ruolo dell’elaboratore si espande dalla tradizionale elaborazione di transazioni verso nuove aree applicative dotate di capacità multimediali. Il modello relazionale soddisfa pienamente le necessità di elaborazione di transazioni ma non è efficiente quando si tratta di gestire strutture complesse di dati, quali immagini e suoni, tipiche delle applicazioni multimediali. In aggiunta il modello relazionale non supporta facilmente la distribuzione di un database attraverso molteplici server, come tipicamente avviene nelle applicazioni Internet.
Per ovviare ad alcune delle limitazioni esposte, negli anni Novanta è stato è stato introdotto il modello di dati a oggetti con il preciso scopo di permettere la riutilizzazione del codice di programma. Dopo diversi anni di presenza sul mercato, l’obiettivo è ben lungi dall’essere raggiunto, e non per la mancanza di specifici linguaggi e strumenti di sviluppo, bensì per il semplice fatto che i dati sono memorizzati in modo tale che non permettono tali implementazioni.
Il modello di dati a oggetti è una semplice aggiunta allo sviluppo dei linguaggi di programmazione orientati agli oggetti . In questo contesto ogni singola informazione del dato viene custodita come un oggetto a cui non si può accedere direttamente. Qualsiasi programma che ha necessità di leggere o modificare tale informazione, deve inviare un messaggio al “custode” dell’oggetto richiedendo l’attivazione di uno dei suoi specifici processi per l’esecuzione della funzione desiderata. I tipi di informazione e i processi di cui il custode dell’oggetto dispone dipendono dalla classe dell’oggetto. Una tipica analogia per descrivere meglio il concetto di oggetto è quella del conto corrente bancario, su cui non si può agire direttamente per apportarne modifiche, ma bisogna inviare messaggi sotto forma di assegni, disposizioni di pagamento, richieste di saldo ecc.
Inizialmente il database a oggetti è stato individuato come il successore naturale di quello relazionale, ma ben presto tale previsione si è rivelata totalmente inconsistente. In effetti il modello di dati a oggetti non è stato concepito per migliorare o competere con quello di tipo relazionale, ma semplicemente per garantire la persistenza dei dati nell’ambito dei relativi linguaggi di programmazione. Sotto molti aspetti il database a oggetti è decisamente inferiore, in termini di prestazioni, a quello relazionale, principalmente nell’elaborazione delle transazioni, specie sotto l’aspetto dell’implementazione di processi di query. Questo deriva primariamente dalla necessità di incapsulare i dati all’interno di un oggetto, che comporta una sostanziale elaborazione aggiuntiva per la memorizzazione dei dati, nonché un incremento della dimensione dei medesimi.
In pratica un database a oggetti memorizza in modo più efficiente un piccolo numero di grandi oggetti, piuttosto che un grande numero di piccoli oggetti, e questo implica una minore granularità dei dati nei confronti di quella fornita da un database relazionale. Anche questo tipo di database è stato concepito prima dell’esplosione del fenomeno Internet, che favorisce tecnologie “leggere” i cui componenti possono essere facilmente distribuiti tramite la rete stessa se non inglobati all’interno dei browser e dei siti. La ricerca di soluzioni in questa direzione, unita alla necessità di competere con il modello relazionale, hanno introdotto un maggiore complessità e “peso” nella tecnologia a oggetti, al punto da renderla sostanzialmente impraticabile per applicazioni Internet.
Un tentativo, da parte dei provider di database relazionali, di recepire le istanze insite nei database a oggetti è l’introduzione dei database di tipo Object/Relational, ove vengono incorporate alcune caratteristiche del modello a oggetti all’interno di una struttura relazionale.
In base alla definizione più accettata, un database object/relational è caratterizzato da un modello dei dati che, in quanto relazionale, supporta il linguaggio SQL e, in quanto a oggetti, supporta strutture complesse di dati. Questo paradigma spesso appare più un’operazione “cosmetica”, di facciata, piuttosto che una reale innovazione tecnologica, in quanto nella maggior parte dei casi la soluzione object/relational aggiunge capacità marginali al consolidato predominio dei database relazionali.
Il modello relazionale ha rappresentato per molto tempo l’architettura di base per l’implementazione di database standard, ma ora appare funzionalmente carente a fronte delle esigenze evidenziate dal diffondersi di Internet. Le soluzioni proposte nel frattempo, identificate con il modello a oggetti e quello ibrido object/relational, non sono state in grado di costituire una valida alternativa, per cui è tuttora aperto il dibattito sulla futura architettura dei database.
Una soluzione che desta un certo interesse è quella basata su un modello di dati associativo poiché supera le limitazioni del modello relazionale ed evita le complessità di quello a oggetti, strutturando le informazioni in modo più accessibile e intuitivo. In aggiunta, questo approccio fornisce la soluzione a due fondamentali limitazioni delle attuali tecniche di programmazione: la necessità di scrivere un nuovo programma per ogni nuova applicazione e la necessità di memorizzare gli stessi, identici tipi di informazione per ogni singola istanza.
Il modello associativo struttura le informazioni nello stesso modo con cui le elabora il cervello umano, ovvero come singole entità e associazioni tra che le correlano. Queste associazioni vengono espresse mediante semplici frasi secondo una sintassi di tipo soggetto-verbo-oggetto.
Esempi tipici di frasi che rispettano la sintassi del modello associativo possono essere: “Paola è sorella di Marco”, “ACME SpA ha un fido di 250.000 Euro”. Una frase può essere a sua volta oggetto o soggetto di altre frasi, permettendo al modello associativo di implementare concetti particolarmente complessi, quali “Il volo AZ312 è arrivato alle ore 10:30 di sabato”
Le “cose” del mondo reale vengono suddivise in due tipi distinti, sulla base dei dati da memorizzare:
– le entità che sono dotate di esistenza distinta e indipendente, in quanto non condizionata dall’esistenza di altre cose;
– le associazioni, la cui esistenza dipende da quella di una o più altre entità, per cui se qualcuna di queste cessa di esistere, la relativa associazione diventa senza senso.
Per una maggior comprensione di quanto esposto si possono citare gli esempi seguenti:
– una persona è un’entità finché viene intesa come cliente, impiegato, venditore, azionista e su queste basi si definiscono le relative associazioni;
– una società è un’entità finché viene intesa come cliente, fornitore, subcontractor e su queste basi si definiscono le relative associazioni;
– un edificio è un’entità finché viene inteso come sede centrale e luogo di lavoro e la localizzazione delle proprietà sono le relative associazioni.
Classificando le cose del mondo reale come entità e associazioni, il modello associativo introduce due concetti nettamente separati: quello di qualcosa che possiede una propria esistenza distinta e indipendente e quello dei diversi modi in cui le cose interagiscono tra loro. La distinzione tra entità e associazioni è dovuta al fatto che questo principio è maggiormente aderente alla realtà e quindi di più facile comprensione e più in grado di recepire i cambiamenti e di essere integrato in altri modelli di dati. Questa distinzione è propria del modello associativo e non è prevista da altri tipi di modelli, in particolare da quello relazionale.
Un database associativo è costituito da due diverse strutture dati:
– un insieme di elementi, ognuno dei quali è dotato di un identificatore univoco, di un nome e di un tipo;
– un insieme di collegamenti, ognuno dei quali è dotato di un identificatore univoco unitamente agli identificatori univoci relativi a soggetto, verbo ed oggetto, ognuno dei quali può essere a sua volta collegato ad un altro elemento
Il confronto tra i due differenti tipi di database, quello relazionale e quello associativo, evidenzia come quest’ultimo permetta di superare alcune limitazioni intrinseche ai modelli finora adottati. In particolare, uno stesso insieme di programmi può essere utilizzato nel nuovo modello per implementare molte applicazioni di tipo associativo, senza alcuna necessità di modifiche o riscritture, permettendo all’utente di creare nuove applicazioni da quelle esistenti, con un sostanziale risparmio nei costi di sviluppo software.
Le applicazioni associative includono delle funzionalità che possono essere usate o ignorate selettivamente da parte degli utenti, senza alcuna necessità di parametrizzazione o personalizzazione, con conseguenti notevoli vantaggi per i fornitori di soluzioni in modalità SaaS (Software-as-a-Service) o di tipo ASP (Application Service Provider), che devono costantemente adeguarsi alla diverse richieste operative di un gran numeri di utenti individuali. Questa facilitazione è resa possibile dalla struttura “a capitoli” di un database associativo, nel senso che l’accesso al medesimo da parte di ogni singolo utente avviene sulla base di un suo specifico profilo che include la lista dei capitoli che possono essere utilizzati individualmente.
Un database associativo è in grado di memorizzare informazioni che sono rilevanti solo per alcuni elementi di uno specifico tipo, senza che queste siano notevoli per tutti gli altri elementi dello stesso tipo, permettendo in tal modo di continuare a migliorare la qualità del servizio ai clienti senza dover necessariamente far crescere a dismisura il database stesso. Relativamente poi all’importante problema dell’unione di database diversi, nel caso relazionale questo può essere assimilato alla combinazione di molteplici blocchi scritti in linguaggi diversi, con conseguente necessità di individuare e comparare le varie tabelle e colonne, nonché di risolvere tutte le differenze riscontrate. In contrapposizione, l’unione di database associativi diversi equivale al mettere insieme documenti scritti nelle stessa lingua e con il medesimo programma di elaborazione testi. Questa immediatezza è resa possibile dalla struttura intrinseca “a frasi” per tutti i tipi di dato, nel senso che un database associativo è dotato di capacità di autodefinizione, cioè include le definizioni stesse al suo interno. La possibilità di unire o correlare tra loro molti database associativi, senza alcuna necessità di programmazione, permette di ottenere notevoli risparmi nei progetti di data warehousing.
In conclusione, un database basato su un modello di dati associativo, potendo essere visto come una rete di associazioni espresse nella forma soggetto-verbo-oggetto, costituisce un’implementazione di una struttura dei dati specificatamente realizzata per le applicazioni Internet, in grado di soddisfare le nuove necessità di compattezza, leggerezza, distribuzione e pubblicazione su web a costi contenuti e con elevati livelli di efficienza.
Di Gian Franco Stucchi
L’ICT ha assunto una valenza strategica nei processi di produzione e della supply-chain passando da mero strumento operativo e di controllo a leva d’azione business-critical. Gian Franco Stucchi ne descrive le tappe in questa edizione del Caffè Sospeso.
Qualche decennio or sono, Peter Drucker, uno studioso definito come “the founder of modern management”, rilevò che I’economia del Mondo Occidentale stava virando verso una nuova direzione. Nel suo libro “Post-Capitalist Society”, Drucker osservò che era in corso una transizione di stato “dal capitalismo alla società della conoscenza” e da questa affermazione derivò la necessità che ogni organizzazione dovesse incorporare, nella propria struttura, la capacità di gestire il cambiamento.
A conferma di questo principio, vediamo che in questi ultimi anni nel mondo dell’economia il vero capitale è effettivamente diventato la conoscenza, Ie aziende si sono internazionalizzate, la produzione tende a spezzettarsi in piccoli gruppi, o celle, altamente specializzate. Non sappiamo se questa tendenza continuerà negli anni futuri, certo che oggi i fatti sono questi.
Considerando più analiticamente il tema dei sistemi produttivi, vari studiosi della tematica, già dagli anni Sessanta, avevano messo in evidenza che la complessità dei prodotti e le incertezze che affliggevano i sistemi socio-economici allora esistenti indicavano, come principale obiettivo da raggiungere nella progettazione dei processi, la capacità di risposta alle sfide/minacce, e nel decentramento del potere decisionale la condizione necessaria – anche se non sufficiente – per competere con successo.
Un grande impianto produttivo doveva essere concepito come un insieme di celle ciascuna delle quali portava a un determinato “prodotto”, con un responsabile che era in grado, man mano che le circostanze esterne si modificavano, di adattare Ie attività in modo da rispettare i piani. Di conseguenza, gli “evangelisti” del decentramento decisionale non erano molto favorevoli ai sistemi di controllo della produzione gestiti centralmente; essi, tra l’altro, contestavano alcuni aspetti dei sistemi MRP e MRP II perché pensavano che ipotizzare sia dei lead-time immutabili, sia la completa prevedibilità del comportamento delle macchine e degli operatori potevano alla fine rendere I’intero edificio produttivo poco aderente alla realtà e portare all’inefficienza.
Negli anni Ottanta ci si è trovati di fronte ad alcune fasi di recessione, mentre nasceva una maggiore competizione a livello internazionale e, contemporaneamente, si poneva sempre una maggiore attenzione ai bisogni del cliente: ne derivò la necessità di disporre di una sempre maggiore flessibilità organizzativa e produttiva. Nel frattempo, si stabilì una quasi completa deregolamentazione del commercio internazionale, passando così da un mercato statico e omogeneo a uno multidimensionale e dinamico. Nacque allora la tendenza a cercare algoritmi di gestione della produzione più flessibili, che offrissero la possibilità di trovare le migliori soluzioni tra più possibili alternative.
Venendo al presente, osserviamo come le aziende si trovino oggi nella necessità di fronteggiare e gestire il cambiamento e, nel contempo, sia loro richiesto di dare la massima capacità di risposta alle turbolenze dei mercati (sempre più ballerini). Si estende così la necessità di delegare la responsabilità decisionale poiché la complessità aziendale e ambientale richiedono una suddivisione in piccoli sistemi, delegando a ciascuno una singola specializzazione, che può essere trovata anche fuori dell’azienda, presso terzi – una tendenza che determina I’espansione dell’outsourcing.
Il conferimento di parte del potere decisionale a aziende terze può essere visto anche come un cambiamento della forma contrattuale con chi produce i componenti: prima era un contratto con dei dipendenti, dopo diventa un contratto commerciale. E’ una tendenza che si è notata molto bene nell’industria automobilistica: la competizione non può essere vinta dal solo costruttore, ma il successo corona quelli che sono riusciti ad allineare alla loro visione strategica i principali fornitori; è solo così che si riesce a gestire la complessità, raggiungendo, da un lato, I’efficacia grazie alla flessibilità e alla capacità di risposta, e, dall’altro, una maggiore efficienza, con I’allineamento delle diverse gestioni.
L’industria automobilistica è stata così la prima a concentrarsi sul suo core business e a incrementare I’outsourcing, contribuendo ad allargare la produzione non solo verso una molteplicità di aziende, ma in certi casi suddividendola tra diversi paesi. Quindi, in conclusione, la complessità, I’incertezza e il rischio stanno influenzando sempre di più i metodi produttivi.
Ma come arrivare e gestire sempre meglio questi fattori? Dalla letteratura si ha la conferma che sono molti ormai i settori produttivi dove domina il principio che per ottenere un sistema ad alta capacità di risposta occorre un decentramento dell’intelligenza con il ricorso allargato alle tecnologie di gruppo, alle celle di produzione, alla terziarizzazione.
La difficoltà risiede, in questo contesto, nell’ottenere il controllo centralizzato di un sistema che, per sua natura, è complesso e disperso ed è immerso in un ambiente dove la domanda è incerta. L’integrazione verticale del passato è stata sostituita da una molteplicità di supply-chain formate da aziende diverse, anche perché l’integrazione verticale è di difficile gestione. Ma le supply-chain possono essere troppo influenzate dal diverso comportamento dei partecipanti e diventa difficile allora il compito delI’attore finale – quello che interfaccia il cliente, la vera fonte di guadagno di tutto il complesso di sistemi-ambiente e catene – di regolare i processi di management con un’organizzazione adeguata e con la leadership.
Se dal lato dei metodi di produzione queste sono le conclusioni e i comportamenti odierni delle aziende, si rileva che nel mondo industriale sono ormai onnipresenti i sistemi informativi per I’Enterprise Resource Planning (detti suite ERP). Questi sistemi hanno conosciuto (e conoscono) considerevoli ritmi di sviluppo e i provider affermano che essi permettono la gestione di tutte le risorse dell’impresa (ERP di prime generazione) e consentono di realizzare la completezza gestionale anche quando I’impresa è allargata nelle supply-chain (ERP di seconda generazione o estese).
C’è coerenza tra i nuovi sistemi e i principi prima enunciati? Per rispondere si riprenda in considerazione l’evoluzione temporale degli obiettivi fondamentali dell’azienda. I vari guru della Management Science, basandosi sull’analisi delle serie storiche, hanno postulato che, in periodi successivi, le imprese hanno cercato di raggiungere diversi gradi di economie: innanzitutto le economie di scala, con le produzioni di massa; successivamente Ie economie di scopo, con la lean production come risposta alla maggiore diversificazione richiesta dal mercato; infine l’economia di governo, con la produzione flessibile, le gerarchie piatte, la distribuzione delle competenze, la tendenza alla delega del potere decisionale, I’espandersi dell’outsourcing. Queste traiettorie possono essere interpretate come le tappe del passaggio alla focalizzazione sull’output e non più a quella sull’input, attribuendo perciò maggior peso alle esigenze del cliente piuttosto che alla riduzione dei costi.
Se oggi l’obiettivo fondamentale è quello di raggiungere l’economia di governo, I’impostazione dei sistemi ERP non sembra coerente con questo principio. Possiamo anche ricordare che, se torniamo agli anni Settanta, il non corretto funzionamento dei primi sistemi MRP nasceva da ritardi nella comunicazione, oltre che dal fatto che si esprimevano gli stessi dati in versioni diverse e incompatibili in punti differenti dei processi produttivi. Oggi tutte queste difficoltà sono superate dalla facilità di comunicazione e dall’enorme capacità di elaborazione dei sistemi d’impresa, ma resta sempre la limitazione legata al fatto che i database sono finiti, perché contengono solo i dati che il progettista ha deciso che debbano essere considerati. Gli attuali sistemi informativi e di comunicazione devono comunque lavorare solo nell’ambito del sovra-sistema per cui sono stati progettati; la direzione e la gestione sono perciò centralizzate. L’enfasi ancora una volta è sull’efficienza piuttosto che sull’efficacia. Nell’evoluzione dei sistemi informativi si è poi notato che, se è vero che gli elaboratori inizialmente sottraevano agli operatori l’iniziativa individuale, alla fine i PC e successivamente i dispositivi web-based – quali i Personal Digital Assistant (PDA), gli iPad, i notebook e altri Mobile Internet Device (MID) – hanno dato loro maggiore capacità di iniziativa. Rispetto a questa tendenza, i sistemi ERP rappresentano potenzialmente un passo indietro, tornando al potere centralizzato, estendendo l’impero al di là dei sogni dei suoi fondatori. È anche vero che i produttori di ERP hanno la tendenza a passare a sistemi che possono essere suddivisi, ma si sta andando più verso una suddivisione di funzioni che di aree di responsabilità.
Ci poniamo a questo punto I’interrogativo: stiamo veramente adoperando le nostre energie di sviluppo e la nostra creatività nella giusta direzione? Ormai certi concetti dovrebbero essere completamente superati: abbiamo abbandonato la catena di montaggio di Ford per passare a sistemi produttivi nei quali I’intelligenza è distribuita; il concetto che il lavoro è fatto dagli operatori ma che la gestione è la prerogativa dei capi, come diceva Taylor, è pure finito. Eppure , nell’automobile, spesso continuiamo a mettere il motore davanti ai passeggeri, ricordando che una volta davanti alla carrozza c’era il cavallo, e analogamente i progettisti di sistemi informativi non possano dimenticare il concetto che gli operatori hanno bisogno di un capo, e che il sistema perciò deve essere gerarchizzato. Vediamo in altre parole che continua la tendenza a portare avanti miglioramenti, restando però sempre nell’ambito delle strutture verticistiche esistenti. E questo mentre i sistemi produttivi stanno cambiando e reagendo alla complessità con i piccoli gruppi con potere decisionale, con la terziarizzazione, in altre parole con un sistema di produzione che si organizza da solo, perciò con un’impresa virtuale.
Per cercare una soluzione al problema, è necessario concepire e portare avanti una molteplicità di progetti dl sistemi di gestione che permettano di far lavorare in modo integrato e coerente molte celle che si autoregolano, agendo soprattutto sui punti di interfaccia e senza pretendere di arrivare a una gestione centralizzata del sistema, che da un lato viene giudicata troppo complessa e dall’altro non in coerenza con la possibile dinamicità del gruppo.
Una struttura organizzativa simile sarebbe governata da un algoritmo di allocazione virtuale delle risorse: i diversi componenti una supply-chain dovranno aderire a questo sistema con protocolli comuni (elettronici e commerciali) comunicando e scambiando i dati che interessano gli altri componenti la catena (ad esempio le proprie capacità, gli stock, l’avanzamento delle lavorazioni) conservando però la propria autonomia gestionale. E’ come se ci trovassimo su un’autostrada dove ogni guidatore conserva la propria autonomia, obbedendo però a certe leggi comuni e comunicando agli altri le proprie
intenzioni.
Che fare? Certamente un matrimonio, che s’ha da fare: quello tra Produzione e ICT.
“… Il fatto più rilevante che si osserva in un’analisi degli ultimi anni consiste nel trasferimento intensivo delle tecnologie elettroniche sia sugli impianti produttivi che sui sistemi di elaborazione e trasmissione dell’informazione”.
Questa autorevole dichiarazione dei professori Romeo Castagna ed Antonio Roversi del MIP – School of Management del Politecnico di Milano, tratta dalla prefazione del loro libro “Sistemi Produttivi” (ISEDI), si accoppia con una tesi secondo la quale è ormai riconosciuto che le tecnologie dell’informazione hanno assunto una valenza strategica per le aziende, passando da mero strumento operativo o di controllo a leva d’azione per la realizzazione di una strategia competitiva. In effetti l’ICT entra nei prodotti, allargando la sfera d’azione dei “peripheral” che rendono più appetibile il “core” di beni e servizi; permettono di differenziare il prodotto, apportando delle caratteristiche innovative o dei tratti distintivi unici; contribuiscono a creare i nuovi prodotti oppure ad individuare i nuovi mercati.
L’ICT viene impiegata per comporre sistemi informativi di nuova generazione, oltre alle usuali funzionalità operative e gestionali, tendono a realizzare la base informativa e strumentale per il supporto decisionale sino ai più alti livelli della gerarchia aziendale. I sistemi informativi aziendali, proiezione interna di questa valenza, sono una variabile organizzativa fondamentale per l’impostazione di un’architettura di sostentamento, robusta e flessibile, della strategia aziendale. Pur mantenendo, anzi consolidando e approfondendo le loro caratteristiche originarie di strumenti operativi e di controllo, essi si sono evoluti in modo sofisticato, assumendo delle connotazioni proattive e stimolanti.
L’enfasi assunta dalla filosofia di orientamento ai processi nei metodi di produzione – e la caratteristica dimensionalità interfunzionale di questi – ha determinato una decisa metamorfosi dei sistemi informativi dedicati alla produzione, che vedono aggiungersi alle funzionalità tipiche di un sistema di rilevazione e di controllo, un nuovo strato di leve d’azione, tese all’ottimizzazione globale del flusso produttivo piuttosto che all’efficienza del singolo comparto.
Non è raro, inoltre, rilevare che nell’ambito della singola azienda coesistano diverse modalità produttive, sia determinate dalla natura della gamma dei prodotti o dei servizi realizzati, sia da una precisa scelta di natura strategica concepita dall’azienda. Ne discende che il sistema informativo aziendale deve estendersi per riflettere questa realtà, adattandosi alle varie modalità produttive, ma conglobando, in un’unica prospettiva integrata, i fattori critici vitali e strategici per l’azienda.
La realizzazione di un sistema del genere è un progetto che richiede doti di competenza, d’esperienza e di professionalità sviluppate in un contesto, possibilmente internazionale, grazie al patrimonio accumulato in una vasta gamma di realizzazioni diversificate. A causa del ritmo sempre più rapido dell’innovazione tecnologica, i responsabili della produzione sono costantemente impegnati a valutare nuove applicazioni e nuove opportunità indirizzando gli investimenti tecnologici. Infatti, se da un lato la tecnologia può rivelarsi l’elemento vincente per dare “una marcia in più” alla produttività dei reparti di produzione, dall’altro può trasformasi in un “buco nero” senza alcuna speranza di un ritorno sull’investimento.
Nell’ambito della gestione della supply-chain, alcuni personaggi coinvolti nei processi dei sistemi di produzione covano un pregiudizio, a volte represso, che si potrebbe esprimere, parafrasando il Re Sole, con un motto del tipo “La supply-chain sono io”. Ciò che questi professional più o meno apertamente ritengono è che la funzione di produzione sia il vero focus della supply-chain.
Le operazioni di produzione, conglobano, interagiscono o sono influenzate praticamente da ogni gruppo funzionale esistente: ricerca e sviluppo, marketing, acquisti, IT, amministrazione, progettazione. Un unico centro di produzione rappresenta un asset che assorbe notevoli investimenti, impiega molti dipendenti, tratta con diversi fornitori, produce per un parco clienti anche molto consistente e realizza un fatturato di svariati milioni di euro. È inevitabile, quindi, che le operazioni di produzione rappresentino solitamente il “corpus” del costo e, nel contempo, del valore aggiunto di tutta la supply-chain di un’azienda. Riuscire ad ottenere un prodotto effettivamente vendibile, considerata la complessità e le interdipendenze che regolano questo scenario, è già di per sé un trionfo della logistica. A complicare ulteriormente la situazione interviene il fatto che oggi le unità produttive sono sottoposte a una pressione continua, indotta dalle esigenze di cambiamento, di evoluzione e di adattamento a una serie di fattori esterni e interni, siano questi una nuova tecnologia di produzione, l’introduzione sul mercato di nuovi prodotti o i costanti sforzi di miglioramento. Il contesto nel quale si svolgono fa sì che l’ambito ed i metodi delle operazioni produttive siano raramente statici: queste sfide del cambiamento vengono raccolte e gestite cercando di realizzare prodotti o servizi d’alta qualità, in modo da soddisfare la domanda del mercato pur operando in presenza di vincoli di spesa e controlli amministrativi estremamente rigidi.
L’ambito, le dimensioni e la complessità delle operazioni di produzione generano un’inerzia organizzativa unica, simile a quella di una nave cisterna di enormi dimensioni, dotata di un’immensa capacità di carico e di un’elevata produttività, ma che deve tuttavia disporre di informazioni e potenza con largo anticipo per essere in grado di modificare la propria velocità e la propria rotta. Considerato questo ruolo, estremamente delicato all’interno della supply-chain, non è poi così difficile capire la tradizionale prospettiva egocentrica comune a diversi responsabili della produzione.
Se le sfide che le unità di produzione devono affrontare sono considerevoli, è tuttavia necessario riconoscere che rappresentano un’opportunità senza precedenti in termini di nuovi utili, un diamante grezzo che spesso viene ignorato. La tecnologia svolge un ruolo fondamentale nell’aiutare i responsabili a capire e cogliere questa opportunità.
E’ indubbio che le forze di mercato generano delle sfide uniche per un’azienda e che tali sfide si stanno intensificando sempre più. Una breve rassegna delle problematiche che principali per i responsabili della produzione devono affrontare è la seguente: innovazione dei prodotti dettata dalla tecnologia; riduzione dei cicli di vita dei prodotti; aumento del numero dei consumatori e del grado di sofisticazione delle attese dei clienti in termini di personalizzazione dei prodotti, qualità, servizi, prezzo; modifica dei canali di distribuzione (disintermediazione e reintermediazione, commercio elettronico); globalizzazione riguardante i mercati, la concorrenza, l’impatto sulle organizzazioni, le opzioni di approvvigionamento, la modifica dei regolamenti commerciali.
Alcune di queste forze, per esempio l’aumento dei consumatori e delle loro attese e la globalizzazione, sono semplicemente nuove manifestazioni di sfide esistenti da tempo; altre, quali la tecnologia dei prodotti, il ciclo di vita e i nuovi canali, rappresentano uno spostamento nelle dinamiche dominanti del mercato. Tutte aprono però nuovi fronti sul fronte della concorrenza, con conseguenti opportunità di successo e rischi di fallimento.
Nel tentativo costante di far fronte alle nuove sollecitazioni, le operazioni di produzione sono state investite da continui cambiamenti, un condizionamento che dura tutt’ora. Il boom delle iniziative di miglioramento intraprese nel corso degli ultimi decenni è stato reso possibile, in gran parte, dalle nuove tecnologie e dalle economie di scala che hanno generato. Diversi sono i tipi di tecnologie che interessano la produzione; vi sono infatti tecnologie di produzione, tecnologie dei processi di produzione; tecnologie di misurazione e controllo dei processi di produzione; tecnologie per la gestione, il controllo e il tracciamento dei materiali; tecnologie di progettazione ed engineering dei prodotti; tecnologie delle informazioni operative, gestionali e decisionali. Ciascuno di questi ambiti tecnologici ha contribuito significativamente alla corsa per l’aumento di produttività.
I cambiamenti originano sempre vincitori e vinti. Le aziende che sono in grado di “darsi una vision” (corretta, non un miraggio) e implementare una strategia coerente con essa riusciranno a trasformare le nuove opportunità in vantaggi competitivi ed avere successo.
Le aziende di produzione leader dei vari settori, che costituiscono delle icone (i champion dicono gli statunitensi) da citare ed imitare, possono – e devono – svolgere un ruolo trainante in questo sforzo. A tale proposito gli analisti e gli studiosi individuano alcuni fattori critici di successo che sono riportati nel seguito:
- Liberarsi della sindrome “del peso massimo” e intendere la supply-chain come un sistema centrato sul cliente (o meglio, sul cliente del cliente), estremamente complesso, con interdipendenze articolate ed un impatto globale sul business.
- Applicare competenze analitiche e sinottiche interdisciplinari.
- Capire le opzioni della tecnologia, le loro applicazioni, le opportunità e le sfide.
- Valutare le prestazioni operative e l’impatto finanziario che generano.
- Garantire che le operazioni di produzione siano allineate con la strategia e che questa sia allineata con le realtà operative.
- Dimostrare leadership ed impegno ai massimi livelli.
- Articolare una vision ed un percorso verso il successo.
- Supportare i processi del cambiamento.
Questi fattori sono tutti centrati sulle competenze dei soggetti coinvolti. La capacità di capire le complessità operative, identificare le implicazioni strategiche, definire gli impatti finanziari, progettare e gestire il cambiamento sono competenze molto rare e preziose, alle quali le aziende non possono rinunciare.
Conclusioni
La scienza e la tecnologia (in particolare l’ICT come sostengono Castagna e Roversi) continueranno a cambiare il volto delle operazioni di produzione: oltre a contribuire al miglioramento dell’efficienza elle operazioni, guiderà lo sviluppo e l’implementazione di nuove strategie di supply-chain che potranno modificare radicalmente la posizione, la sequenza e le responsabilità delle attività di produzione. Valutare tutti questi aspetti presuppone un’attenta considerazione di tutti gli elementi di una strategia di business più ampia rispetto a quelle tradizionali.
Un fattore chiave delle strategie aziendali è l’impatto di Internet e del commercio elettronico, due enabler che aprono nuove opportunità per le aziende che affrontano questi canali con strategie di supply-chain in grado d’offrire un valore aggiunto ai clienti.
I concetti di gestione della produzione e della supply-chain sono noti; anche se in continuo divenire, hanno prodotto efficienza operativa e vantaggi a molte aziende. In questi ultimi tempi si sta originando un’opportunità per elevare la supply-chain da semplice comparsa, che contribuisce all’efficienza operativa, a personaggio chiave di valore strategico. Questa opportunità è ulteriormente amplificata dalla rivoluzione dell’e-business. Le lezioni apprese da inizio del Secondo Millennio mostrano sia le opportunità di successo che le conseguenze che dovranno affrontare le aziende troppo inerti, incapaci di riallineare le proprie capacità e le proprie operazioni alle nuove forze di mercato.
di Gian Franco Stucchi
In questa puntata del Caffè Sospeso, Gian Franco Stucchi propone alcune considerazioni sulle applicazioni di prossima generazione che permetteranno la coesistenza di best practice consolidate con processi di management ancora in divenire.
Lo sviluppo applicativo, un tempo focalizzato sulla realizzazione di nuove funzionalità operative destinate agli utenti finali, oggi tende alla realizzazione di sistemi di business integrati, composti da una molteplicità di funzioni che, in gran parte, sono ancora realizzate da uno o più moduli software, più o meno “best-of-breed” ma in genere piuttosto datati. Parallelamente, nel settore dei servizi professionali di Information and Communication Technology (ICT) si assiste alla comparsa di una nuova generazione di sviluppatori, spesso geniali, formati nelle scuole e nelle università, i quali, armati di metodi, tecniche e tool di tipo collaborativo, tentano di aprire nuove strade alla soluzione di un problema di origine antica: l’integrazione delle applicazioni, appunto.
Chiunque abbia praticato per qualche tempo l’affascinante ma turbolento mondo dello sviluppo del software riconosce che una preparazione teorica di base, unita a una forma mentis, nativa o inculcata, orientata alla collaborazione, è di fondamentale importanza (quasi un prerequisito) per recepire ed esprimere nei programmi le dinamiche che hanno origine nell’attuale contesto socio-economico e agitano in modo turbolento le modalità con cui vengono condotte le relazioni e i processi di business. Ne discende che le discipline afferenti, inerenti o consequenziali allo sviluppo applicativo – la realizzazione di software ad hoc, l’implementazione di suite ERP di prima generazione, estese o postmoderne, l’attualizzazione dei sistemi legacy (i retaggi o lasciti del passato), e così via – stanno vivendo un periodo di crescente importanza nelle costruzione e nella rappresentazione dei moderni modelli e delle pratiche di gestione aziendale. Talvolta la loro valenza è tanto rilevante che diventano strategiche per l’impresa che li adotta o, addirittura, assurgono esse stesse ad area di business. E’ questo il caso tipico delle società di consulenza, un fenomeno esploso nell’ultimo ventennio, poi attenuatosi a causa dei postumi di alcuni clamorosi flop verificatisi nel corso delle implementazioni di alcune suite ERP.
Governare l’evoluzione dello sviluppo applicativo non è – e men che meno sarà – un processo facile e routinario. La prossima generazione di applicazioni “new age” richiederà capacità professionali in grado di combinare tra loro, in modo sinergico, risorse di varia natura, metodi, architetture e tecnologie secondo nuove modalità che produrranno una serie di soluzioni che dovranno coesistere sia con la vasta gamma di best practice ormai consolidate, sia con filosofie di management e processi ancora in divenire. La sfida principale per le imprese sarà di gestire con successo la transizione da “Old” a “New”, dalla Società Industriale alla Società della Conoscenza, un cammino che dovrà aver luogo senza che nelle organizzazioni dedite allo sviluppo applicativo (imprese, enti, poli, centri di ricerca, etc.) vengano meno le esigenze imposte dai principi del time-to-market, pur facendo fronte alle pressioni dell’evoluzione del settore ICT.
Questa poi sarà trainata dalla domanda delle aziende e investirà pesantemente nella nuova generazione degli sviluppatori. La metamorfosi dello sviluppo applicativo continuerà senza sosta – magari tra alti e bassi, tra migrazioni trans-nazionali o trans-continentali – e lascerà alle aziende che non saranno in grado di adattarsi in maniera adeguata alla turbolenza ambientale e socio-tecnica ben poche alternative, anzi solo una: l’outsourcing, con tutte le conseguenze del caso.
Diverse sono le strategie d’azione che sono state proposte nell’ampia letteratura e nella casistica disponibile sullo sviluppo dei sistemi d’impresa. Si riportano nel seguito alcuni consigli, desunti dalle analisi condotte da alcune società di ricerca, manifestamente ispirate dal “sano buon senso”.:
- Pianificare l’evoluzione (che avverrà comunque)
- Mantenere gli aspetti più solidi del processo di sviluppo applicativo, adottando le best practice per supportare il trasferimento tecnologico dai “legacy programmer” agli sviluppatori di nuova generazione
- Concentrarsi sul capitale umano, supportando contemporaneamente gli obiettivi di business
- Cercare nuovi metodi (robusti e sperimentati) per le integrare le funzioni innovative con quelle di back-office di tipo legacy
- Utilizzare nuovi metodi di progettazione che includano la collaborazione tra domini di conoscenza diversi al fine di creare catene del valore eterogenee
- Adottare discipline e tecniche di modellizzazione dei processi di business per identificare quelli business-critical
- Classificare le applicazioni in base all’impatto che producono sia a livello locale, di processo, sia globale, d’impresa
- Sviluppare una strategia di interoperabilità basata sulle architetture componentizzate orientate ai servizi (SOA) e sul supporto di più modelli di programmazione applicativa e del middleware
- Valutare in che modo i sistemi di storage svolgeranno un ruolo significativo nelle strategie di e-business (i big data e la business analytics incombono).
- Puntare su componenti associabili tra loro in maniera molto libera e su modelli architetturali diffusi (standard de facto) o in rapida diffusione (cloud/mobile computing)
- Pensare sempre in maniera strategica, anche quando si sceglie una soluzione per la gestione del software legacy
- Creare un piano di addestramento per ogni generazione di sviluppatori (e rispettarlo … compatibilmente con le esigenze di budget).
Il prezzo che i team di sviluppo applicativo dovranno pagare per integrare nuove linee di business sarà certamente molto alto, anche in termini di stress personale o di gruppo. In effetti, i ritmi di lavoro stanno diventando sempre più intensi, a tutto svantaggio della qualità. Ovviamente, di norma il management è poco sensibile a queste argomentazioni, quindi gli sviluppatori dovranno inventarsi un percorso personale per trasformarsi in integratori esperti, sviluppando una profonda sensibilità per le urgenze e un’immediata reattività alle situazioni stressanti.
Il processo di evoluzione dello sviluppo applicativo, per trasformarsi in integrazione dei processi, deve iniziare immediatamente – appena presa coscienza della sua necessità – e richiederà alle generazioni future di individuare le competenze necessarie per dar luogo a tale transizione. Pertanto, ogni impresa deve definire un obiettivo minimo in termini di competenze professionali da acquisire (internamente o esternamente) ed evolvere, in termini di risorse umane, verso questo livello di competenza generalizzata, senza trascurare le problematiche che tali cambiamenti origineranno a livello organizzativo.
Nel corso dei primordi dell’era dell’elaborazione dei dati (anni Sessanta e Settanta del secolo scorso), l’attenzione progettuale dei team di programmazione era rivolta all’accesso ai dati. A questo primo passo ha fatto seguito un periodo nel quale il focus era costituito dal tentativo di migliorare la connettività tra i sistemi eterogenei tramite Remote Procedure Call (RPC), Application Programming Interface (API) e Reti con Protocollo Point-to-Point (PPP).
Più recentemente, l’attenzione è stata rivolta all’integrazione inter/intra-aziendale, quindi i settori nei quali si è concentrata l’innovazione sono stati i servizi erogati dal middleware – cioè il recapito dei messaggi, gli adattatori delle applicazioni ai vari ambienti, la trasformazione dei dati e l’elaborazione rule-based – soluzioni che con l’andare del tempo si sono rivelate sempre più inadeguate in termini di valore, tempismo e flussi operativi.
Gli analisti prevedono che, nel corso dei prossimi anni, si verificherà un aumento dell’attenzione rivolta al workflow “trainato” dai processi di business [Per un approfondimento si rimanda il lettore al Caffè Sospeso “Workflow, una panoramica funzionale”]. Ciò sarà reso possibile dall’affermazione dei sistemi per la modellizzazione dei gruppi di lavoro (groupware), la gestione del workflow e l’integrazione dei servizi via Web e XML.
Altre evoluzioni, facilmente prevedibili, sono le seguenti:
- Elaborazione globale. I progetti di elaborazione globale (cioè ultra-estesa) utilizzeranno molte funzionalità di Internet al fine d’offrire una visione di tipo “inside-out” del sistema-impresa, realizzata grazie ad applicazioni focalizzate sull’ambiente esterno anziché orientate verso l’interno dell’impresa. Gli aspetti chiave dell’elaborazione globale emergeranno dalle transazioni multi-proprietario e multi-operatore (cloud computing). Le applicazioni di portata globale dipenderanno sempre più da transazioni svolte in ambienti applicativi diversi e in imprese diverse.
- Le transazioni OLTP (On Line Transaction Processing) rimarranno un elemento fondamentale delle applicazioni di livello globale. Si affermerà il concetto di interazione, che dominerà gli stili delle applicazioni. Le interazioni sono elenchi di attività, di accessi a informazioni e ad altre transazioni OLTP volte a soddisfare le esigenze degli utenti. Il flusso processuale di un’interazione incorporerà contenuti – sia non strutturati che strutturati – con la logica di business necessaria per produrre le risorse e i servizi richiesti.
- Esperienze utente personalizzate. Le interfacce utente personalizzate enfatizzeranno l’unicità di una certa user experience derivata da una o più interazioni tra un utente con un sistema di livello globale (come accade nel caso del cloud computing).
- E-service onnipresenti. Gli e-service costituiranno la futura generazione dei servizi di fornitura delle informazioni all’utente finale tramite periferiche client indipendenti dalla posizione (mobility computing). I servizi Web saranno implementati tramite Internet a livello di trasporto e mediante un protocollo o linguaggio standard (per esempio XML su HTTP). Trascinato dalla crescita delle implementazioni Business-to-Business (B2B), il modello di business promosso dall’e-service catturerà probabilmente investimenti molto significativi sia dai vendor di middleware e di strumenti di sviluppo, sia dalle imprese. I servizi Web sono essenzialmente dei componenti software collegati tra loro in maniera molto “lasca”, libera, e vengono resi disponibili tramite tecnologie Internet.
Mentre queste infrastrutture si stanno realizzando, le aziende prendono in costante considerazione anche un percorso evolutivo dell’informatica d’impresa che prevede l’utilizzo di risorse legacy come elementi nel “nuovo ordine dei servizi” sfruttando il wrapping via XML delle interfacce grafiche, delle transazioni, dei programmi, dei componenti legacy e dei dati. Normalmente queste risorse legacy non dispongono di tutti gli attributi di un’applicazione di livello globale, tuttavia sono in grado di funzionare egregiamente nel contesto attuale (e lo saranno ancora per diversi anni).
Si vengono così a creare le cosiddette “compond application” che presentano alcune particolarità, come indicato nel white paper “Ensuring Operational Integrity of Web Services and Services-Oriented-Architecture (SOA) Applications”. Infatti, come riportato in questa pubblicazione:
<<There are significant differences between applications implemented as Web Services (or to SOA) and previous more monolithic (legacy) applications: these new applications are much more likely to be compound applications – there are, in fact, a number of legacy applications combined and integrated via SOA into a Web Service; compound applications are much more complex than even the sum of their parts, since a single transaction now has to flow through multiple applications (and their supporting infrastructure)>>.
Le applicazioni composte sono una potente modalità di rappresentazione della realtà aziendale perché sono in grado di realizzare la combinazione di implementazioni legacy dei processi di business con nuove implementazioni o nuovi processi. Esse possono essere considerate una risposta – conforme alle indicazioni degli analisti – alla domanda di “latenza zero” per l’e-business, resa possibile dall’accesso indifferenziato alle informazioni da parte di clienti, fornitori e partner aziendali. Essenzialmente, in un’applicazione composta, due o più applicazioni progettate indipendentemente vengono “incollate” tramite una nuova logica per dar vita a un’applicazione virtuale. Le applicazioni composte tentano di sfruttare le implementazioni correnti della funzione di business, anziché ri-sviluppare da zero delle nuove implementazioni di un processo, in fondo “dèjà vu”. Ciò che può essere sfruttato è la logica di business, tuttavia, di norma, si rende necessario ristrutturare la logica di interfaccia.
L’esigenza di rispettare i tempi di progetto – la spada di Damocle alla quale sono soggette le organizzazioni dedite allo sviluppo applicativo – unita alla crescente disponibilità di software preconfezionato, indicano che il problema è (e sarà) l’assemblaggio o l’integrazione delle applicazioni. L’assemblaggio implica l’assunzione di una decisione importante, spesso vitale, in merito al meccanismo di comunicazione. Sviluppare o assemblare applicazioni distribuite, e successivamente gestirle, richiede disciplina, coerenza e ripetibilità. Uno dei fattori critici di successo è il livello di accessibilità delle applicazioni da assemblare, che, a loro volta, sono una funzione dell’infrastruttura tecnica disponibile, ovvero delle reti, del middleware, dei sistemi di gestione di database, dei sistemi operativi e dell’architettura dell’applicazione legacy.
Lo sfruttamento dei sistemi legacy per realizzare applicazioni nuove o composte può avvenire a vari livelli, come elencato nel seguito:
- gli screen-scraper, gli strumenti host-to-Web o gli strumenti di estensione dei dati utilizzano il livello di presentazione o il livello dei dati come interfaccia verso i sistemi legacy
- gli strumenti di estensione dei dati offrono la possibilità di accedere alle strutture informative legacy direttamente dalle nuove applicazioni
- per eseguire il wrapping del codice legacy sono disponibili strumenti di comprensione della conoscenza della logica dei sistemi e dei programmi, di suddivisione del codice, di estrazione e ristrutturazione delle regole di business.
Quando si realizzano nuove infrastrutture di e-business è di fondamentale importanza poter dedicare molta cura all’esame dell’insieme delle architetture presenti sia nel proprio portfolio applicativo che nel “portafoglio innovativo” aziendale onde evitare di ingessare l’azienda a causa della presenza di tecnologie poco flessibili, che possono provocare ritardi nel time-to-market.
L’utilizzo di infrastrutture monolitiche e immutabili, tipiche di alcuni sistemi legacy mal progettati e peggio realizzati, sta rapidamente scomparendo, dato che gli attuali campioni di questa specie non sono affatto flessibili. Essi congelano le regole di business oppure richiedono uno sforzo eccessivo per cambiare i parametri incorporati, hanno un’applicabilità limitata e hanno ormai raggiunto l’ultimo stadio della loro maturità. Le strutture basate sui componenti (oggetti, web-services, etc.) costituiscono invece un insieme di architetture e tecnologie in rapida evoluzione.
In futuro, gli scenari di business e i rapidi mutamenti da questi introdotti costituiranno il modello predominante. Il processo di re-engineering dei componenti da sistemi legacy dovrebbe essere di tipo evolutivo, pertanto le aziende dovrebbero iniziare a modellare e a implementare le attività business-critical con componenti di alto livello, perfezionandoli gradualmente nel tempo tramite un processo istituzionalizzato e appositi strumenti di transizione.
Come requisito minimo, gli analisti consigliano di isolare il livello di presentazione, ovvero di riconoscere quali parti compongono realmente un livello di interfaccia progettata per la presentazione. Quando i destinatari di tali informazioni aumenteranno, non essendo più limitati a utenti interni, ma comprendendo anche elementi esterni – che utilizzano tecnologie di presentazione diverse, per esempio il Web, le tecnologie wireless e così via, o interfacce di programmazione diverse, per esempio i partner aziendali o i fornitori – la componentizzazione faciliterà notevolmente l’integrazione delle applicazioni.
Per passare dall’estensione dei sistemi legacy alla loro riutilizzazione sono disponibili quattro approcci di base, che possono essere suddivisi a loro volta in due categorie: approcci invasivi e approcci non invasivi.
Gli approcci non invasivi mantengono immutati il codice dei processi di base, i dati, le transazioni e le interfacce utente e solitamente “interpretano” il comportamento di una o più di queste fonti legacy per rendere disponibili ulteriori funzioni (integrazione apparente o wrapping). La maggior parte delle aziende utilizza attualmente approcci non invasivi, a meno che non si impieghino tecnologie molto datate, che probabilmente non sarà possibile conservare in futuro. Il mercato delle estensioni dell’interfaccia grafica utente, nota anche come GUI (dall’inglese Graphical User Interface ), si sta sviluppando sempre più velocemente ed è verosimile che imprese prediligeranno quei vendor che forniranno una serie di funzionalità atte a garantire la flessibilità e la facilità di sviluppo o di integrazione.
Due sono le classi di requisiti richiesti:
- Requisiti operativi: riguardano le capacità di gestire volumi elevati di dati (i big data), numerose opzioni server, multi-threading [NdA. Il threading consente di eseguire elaborazioni simultanee in un programma in modo da poter eseguire più di un’operazione alla volta], monitoraggio del traffico, oltre a funzionalità di registrazione, tracciamento visuale, workflow integrato e varie opzioni di emulazione.
- Requisiti di sviluppo: includono le normali funzionalità di sviluppo delle applicazioni, la cattura (semi)automatica delle schermate, la cattura di regole o di modelli, la manutenzione automatica, le interfacce aperte, lo sviluppo condiviso, il mapping delle schermate many-to-many, le interfacce grafiche dinamiche a valore aggiunto, etc.
La conoscenza dei sistemi legacy, di natura non invasiva, non è un approccio nuovo, né tanto meno è specifico per l’e-business. Molte aziende hanno infatti adottato i prodotti di questa specie durante la conversione all’anno 2000. La maggior parte dei vendor presenti in questo mercato è nel settore da molti anni e può fornire un supporto qualificato nell’identificazione delle regole di workflow implicite nella logica legacy o da questa implicate.
Gli approcci invasivi prevedono la modifica, più o meno massiccia, di una o più fonti legacy. Esempi di modifiche massicce sono le espansioni dei file e la ristrutturazione del codice. I prodotti di natura invasiva si applicano ugualmente bene alle iniziative di miglioramento dei processi software tradizionali, senza conversioni di sorta (molte aziende li stanno valutando proprio a questo scopo). La maggior parte dei prodotti viene offerta all’interno di un’offerta globale di adattamento all’e-business di un sistema informativo “attivo”, cioè fortemente orientato al marketing e alle vendite. Ovviamente questa è una buona ragione per potenziare l’attualizzazione di un sistema software, dato che le pressioni più forti alle quali sono sottoposte le software house sono correlate alle opportunità offerte delle tecnologie Web di aumentare l’accesso ai sistemi legacy da parte di clienti, partner commerciali e fornitori.
I sistemi legacy racchiudano un’immensa e preziosa conoscenza di business, ma estrarre tale “tesoro” rimane un’impresa molto difficile. Per di più, molte aziende non amano aprire all’esterno i propri sistemi legacy, preferendo approcci di estensione dei propri confini meno invasivi. Estendere a nuovi ambienti, in modo regolato e controllato, solo le applicazioni è la soluzione più diffusa, meno rischiosa e spesso meno invasiva. Consente inoltre di realizzare una soluzione immediata, di breve termine e poco rischiosa, per la problematica (tipica dell’e-business) di rendere le applicazioni aziendali, che sono tradizionalmente disponibili ai soli soggetti interni, accessibili senza traumi a nuovi soggetti esterni. Si sta lavorando sui metodi di conoscenza dei sistemi legacy per poter estrarre con successo la logica di business in essi intrappolata (e spesso dimenticata).
I rischi intrinseci della trasformazione completa di un’applicazione legacy in una equivalente, destinata a operare su una nuova piattaforma, costituisce un limite per quelle aziende che dispongono di piattaforme meno recenti, le cosiddette piattaforme “che scottano”, per le quali non esiste più alcuna speranza di crescita o di evoluzione futura.
Diverse aziende stanno cercando di trasformare i vecchi sistemi informativi anche per ragioni diverse da quelle legate alla longevità della piattaforma corrente. In alcuni casi tali aziende sono indotte alla migrazione dalla crescente scarsità di risorse professionali adeguate. Un esempio è dato dai programmatori COBOL, la cui carenza imporrà inevitabilmente lo sviluppo ex novo delle applicazioni scritte in questo linguaggio su mainframe in un altro linguaggio di tipo Object Oriented, come Java.
Il ruolo della tecnologia legacy nel futuro di un’organizzazione deve essere compreso e valutato già nelle prime fasi del ciclo di pianificazione di un nuovo sistema informativo o di una ristrutturazione del sistema esistente. Un’attenta pianificazione è di fondamentale importanza per evitare che una soluzione di breve periodo diventi un problema nel medio-lungo periodo.
Considerazione ovvia, … ma di difficile assimilazione da parte di alcuni CEO purtroppo corrotti da certa “informatica da rotocalco” che banalizza l’integrazione tra le applicazioni (un problema che affligge anche le mitiche app, che pure hanno il dono dell’ubiquità)
Di Gian Franco Stucchi
Caffè Sospeso, redatto da Gian Franco Stucchi, si occupa del Workflow Management, una disciplina dedicata allo sviluppo di soluzioni per il supporto dei meccanismi operativi e decisionali coinvolti nei processi di business
Con il termine “workflow” (flusso di lavoro) si designa tutto ciò che è afferente, inerente o consequenziale all’automazione, totale o parziale, di un processo di business. Nel corso di questo metaprocesso, i documenti, le informazioni o i compiti sono trasferiti da un partecipante a un altro per compiere una determinata azione secondo quanto specificato da un insieme di regole procedurali ben definite. Il workflow è quindi costituito da una serie di attività elementari (task), eventualmente cicliche o alternative, da eseguire per ottenere un preciso risultato. Esso può configurarsi come una progressione sequenziale di attività (azioni e decisioni) oppure un insieme complesso di processi concorrenti che si influenzano l’un l’altro in base a una serie di regole, di protocolli procedurali o di ruoli organizzativi.
Esistono diverse tecniche di modellizzazione dei processi per definire dei percorsi dettagliati e i requisiti di elaborazione di un flusso di lavoro. I sistemi per la gestione del workflow (Workflow Management System o WMS) sono delle suite software che permettono di definire e controllare le varie attività associate a un processo di business. Alcuni consentono anche di effettuare la simulazione del workflow oppure offrono la possibilità di creare prototipi e/o versioni pilota di un particolare workflow prima di renderlo operativo.
Molti sistemi di gestione offrono anche la possibilità di misurare e analizzare l’esecuzione del processo in modo da poter trarre l’ispirazione per sviluppare delle strategie di miglioramento continuo. Tali miglioramenti possono essere avvertiti nel breve termine (per esempio la riallocazione delle attività al fine di equilibrare il carico di lavoro in qualsiasi momento) o nel lungo termine (per esempio la ridefinizione di porzioni del processo di workflow per evitare colli di bottiglia futuri). La maggior parte dei sistemi di workflow si integra con gli altri sistemi o suite presenti nel sistema informativo aziendale, quali i package di gestione dei documenti, i database, la posta elettronica, i prodotti di office automation, i sistemi per la fornitura di informazioni geografiche, le applicazioni dedicate alla progettazione e alla produzione, e così via. Questa integrazione favorisce la costituzione di un’infrastruttura robusta ma sensibile al contesto per l’integrazione dei processi aziendali ed è anche in grado di fornire un metodo per organizzare i documenti, normalmente multimediali, provenienti da fonti diverse in un unico ambiente (per esempio una cartella di progetto).
Nel seguito sono elencati alcuni componenti e funzionalità tipiche dei sistemi di gestione del workflow.
• Strumento di definizione processi. E’ uno componente, grafico o testuale, per la definizione del processo di business. Ogni attività del processo viene associata a un individuo o a un’applicazione; vengono quindi create delle regole per determinare l’avanzamento delle attività nel corso del workflow e i controlli implementati per governare ciascuna attività. Alcuni sistemi di workflow ammettono anche la modifica dinamica delle attività di business tramite la selezione di partecipanti dotati di privilegi amministrativi.
• Simulazione, prototipizzazione e progetto pilota. E’ una funzionalità grazie alla quale è possibile creare simulazioni di workflow o prototipi e/o versioni pilota di un particolare flusso di lavoro in modo da poterlo sperimentare e verificare su pochi casi emblematici prima di renderlo operativo.
• Avvio e controllo delle attività. Una volta definito, si dà il via al processo di business e vengono allocate le risorse umane e IT adeguate per completare ciascuna attività.
• Processo decisionale basato su regole. Per ciascun passaggio vengono create delle regole che determinano in che modo i dati relativi al flusso di lavoro vengono elaborati, distribuiti, tracciati e controllati. Una regola potrebbe, per esempio, generare notifiche trasmesse via email ogni volta che viene soddisfatta una particolare condizione; un’altra regola potrebbe implementare la distribuzione condizionale dei documenti e delle attività in base al contenuto di vari campi; un’altra regola ancora potrebbe richiamare una data applicazione per la visualizzazione dei dati.
• Distribuzione di documenti. Nei sistemi più semplici, la distribuzione dei documenti può essere ottenuta passando un file o una cartella da un destinatario all’altro, per esempio come allegato di posta elettronica. Nei sistemi più sofisticati, ciò potrebbe essere ottenuto invece verificando i documenti in arrivo e in uscita in un archivio centrale. Entrambi questi due tipi di sistemi consentono ai vari soggetti che prendono parte al processo di aggiungere commenti personali, senza tuttavia modificare il documento originale.
• Attivazione di applicazioni per la visualizzazione e la modifica dei dati. Elaboratori di testi, fogli di calcolo, sistemi GIS, applicazioni di produzione, e così via, possono essere richiamate per consentire ai soggetti implicati nel processo di creare, aggiornate e visualizzare dati e documenti.
• Liste di lavoro. Consentono ai vari soggetti di identificare rapidamente l’attività corrente e altri dati quali: la data attuale, una data di scadenza, il livello di priorità, e altro. Alcuni sistemi sono in grado di visualizzare persino il carico di lavoro previsto per l’attività. Tali sistemi analizzano a che punto si trovano le varie attività nel corso del workflow e il tempo richiesto per portare a termine ciascun passaggio; quindi, sulla base di tali valori, effettuano una stima della data in cui le varie attività raggiungeranno un soggetto.
• Automazione delle attività. Le attività computerizzate, quali la redazione di comunicazioni, le notifiche tramite posta elettronica o l’esecuzione di applicazioni, possono essere richiamate automaticamente. L’automazione della attività richiede spesso una personalizzazione del prodotto di workflow.
• Notifica degli eventi. Il personale addetto e/o i responsabili possono essere informati automaticamente del verificarsi di determinati eventi chiave, dell’aumento del carico di lavoro e di altri tipi di criticità.
• Elenchi di distribuzione per i messaggi e/o la posta elettronica. E’ possibile creare degli elenchi di distribuzione per inviare messaggi ad hoc ai vari partecipanti.
• Controllo del processo. Il sistema può fornire informazioni importanti relative al carico di lavoro corrente e futuro, ai colli di bottiglia (correnti o potenziali), alla durata delle varie attività, alle scadenze non rispettate e così via.
• Accesso alle informazioni via web. Ormai tutti i sistemi sono dotati di moduli che consentono l’interfacciamento con il web al fine di fornire informazioni di workflow a clienti, fornitori, collaboratori e utenti remoti.
• Tracciamento e registrazione delle attività. E’ possibile registrare le informazioni relative a ciascun passaggio ovvero data/ora di inizio e di completamento, risorse umane assegnate all’attività e funzioni di stato importanti. Tali informazioni potranno essere utilizzate in seguito per analizzare il processo o fornire la prova del completamento di determinate attività.
• Amministrazione e protezione. Solitamente esiste una serie di funzioni che consentono di identificare i partecipanti a un processo con i rispettivi “profili” e di amministrare le routine associate a ciascuna applicazione, quali i backup dei file, le archiviazione di register file, etc.
L’introduzione degli strumenti per la gestione del workflow dovrebbe essere vista come un’opportunità per migliorare l’insieme dei processi di business e la struttura di un’organizzazione nel suo complesso. L’implementazione di un sistema di gestione del workflow all’interno di una più ampia soluzione di gestione aziendale consente infatti di ottenere numerosi vantaggi.
Essa è innanzitutto un’opportunità per effettuare delle modifiche organizzative. Gli attuali sistemi per la gestione del workflow sono in grado di sostenere singole business unit o intere imprese nell’implementazione di modifiche organizzative necessarie per operare in maniera più efficiente. Tali modifiche potrebbero comprendere il passaggio a una struttura organizzativa più orizzontale e maggiormente orientata al lavoro di squadra. Poiché i passaggi, i ruoli e le regole dell’attività risultano integrati nel sistema WMS, la gestione del processo di business dovrebbe richiedere un minor intervento esterno. Inoltre, il miglioramento delle comunicazioni consentito dalle notifiche automatiche, dalla condivisione dei documenti e da una maggiore comprensione dell’intero processo possono contribuire al miglioramento del livello di collaborazione tra i membri dei vari team coinvolti. I sistemi di gestione del workflow tendono infatti a riunire soggetti con competenze diverse all’interno di un’unità (reale o virtuale) più coesa ed integrata.
Il secondo vantaggio consiste nella capacità di apportare modifiche al processo di business. Poiché i sistemi di workflow costringono le aziende a (ri)esaminare e (ri)definire i propri processi, queste occasioni costituiscono il momento ideale per considerare un eventuale reengineering dei processi operativi o decisionali. Prima di implementare un sistema di workflow è infatti di fondamentale importanza che il processo sottostante venga analizzato e raffinato, evitando in tal modo di integrare pratiche non valide o poco efficienti. Gli studiosi di Workflow Management (WM) suggeriscono che si ottimizzi un processo tenendo in considerazione tre obiettivi: riduzione del tempo di processo, ottimizzazione del contenuto a valore aggiunto del processo, ottimizzazione della flessibilità nel punto di contatto iniziale con il cliente. Altrettanto importante nella ridefinizione delle attività è il supporto fornito dalla gestione del workflow al miglioramento continuo delle performance: in effetti i WMS più avanzati registrano le informazioni sul modo in cui il processo definito funziona effettivamente nella pratica consentendo di identificare le aree che richiedono una messa a punto più raffinata.
Un altro vantaggio è dato da un accesso più efficiente ed efficace alle informazioni. I sistemi di gestione del workflow consentono potenziare la creazione del “sapere aziendale” insito nell’esperienza e di arricchire il patrimonio cognitivo di un’impresa. Le informazioni di processo, che altrimenti sarebbero sparse tra i vari membri dei team coinvolti nell’esecuzione delle varie attività, possono essere combinate e rese disponibili a tutti i soggetti aziendali. Ciò si rivela particolarmente utile per la formazione di neo-assunti, che non dispongono ancora di una vasta conoscenza delle operazioni di business più complesse.
Infine, una altro vantaggio deriva dal miglioramento della sicurezza e dell’affidabilità poiché la gestione del workflow fornisce delle modalità di accesso sicure a un insieme di dati relativi a un servizio o a un processo. Essa riunisce i dati provenienti da applicazioni diverse dando loro un’organizzazione e una struttura coerente. Utilizzando meccanismi quali i privilegi di ruolo (che determinano chi può accedere e/o modificare le informazioni), il controllo del processo (ovvero regole che stabiliscano la sequenza delle attività e dei controlli puntuali), il controllo delle versioni del software e dei backup di sistema, è possibile far sì che i dati diventino più protetti ed affidabili.
Ma l’adozione di un WMS non è un percorso tappezzato da rose e fiori. Gli investimenti in questi strumenti non sono in grado di risolvere i problemi relativi ai processi sottostanti se vengono utilizzati per automatizzare attività condotte in modo anomalo. Anzi, i problemi potrebbero farsi più pressanti quando processi mal strutturati vengono automatizzati e la flessibilità rimossa. Nel seguito sono illustrati gli aspetti problematici da considerare prima di implementare qualsiasi sistema di WM
• Resistenza dei partecipanti. Secondo quanto affermano i soliti guru dell’ICT, in più del 50% dei casi gli aspetti legati al fattore umano costituiscono l’ostacolo principale per l’accettazione delle applicazioni di WM. Molti partecipanti considerano la gestione del workflow un meccanismo messo in atto per togliere loro del potere decisionale oppure per ridurre le risorse umane; altri si oppongono all’idea di essere controllati e avvertono il WMS come un’invasione della propria privacy; altri ancora individuano come problema la reale o presunta mancanza di rapporti interpersonali che si creerebbe nei team di lavoro con l’adozione di un sistema automatizzato.
• Eccesso di gestione. I processi di workflow possono essere definiti a vari livelli di dettaglio e un sistema che tenti di definire e controllare tutti i possibili dettagli di un processo potrebbe essere eccessivamente “pesante” e determinare un carico di attività gestionali inaccettabile (oltre a incontrare la resistenza dei partecipanti).
• Perdita di flessibilità. Alcuni processi di business richiedono che i partecipanti siano flessibili e un po’ autonomi, ricorrendo alla propria esperienza e alle proprie capacità per prendere decisioni. Tali processi non sono ovviamente dei buoni candidati per essere gestiti tramite WMS.
• Costi di implementazione tecnica. I sistemi di gestione del workflow possono risultare molto complessi, prevedere una vasta gamma di risorse da implementare e gestire. Durante la fase di valutazione dei costi è necessario considerare lo sviluppo e la gestione delle reti, dei server e delle workstation, il prezzo di acquisto dei prodotti software per la gestione del workflow, lo sviluppo e l’implementazione delle applicazioni e la personalizzazione.
• Costi di definizione dei processi complessi. Il processo di business in esame potrebbe risultare difficile da definire e ancora più difficile da riorganizzare. Il successo, in questi casi, dipende dall’impegno dei responsabili aziendali e dei partecipanti e può richiedere molto tempo. Lana definizione di un workflow affidabile presuppone una conoscenza profonda e dettagliata del processo di business sottostante.
I processi più adatti per essere gestiti tramite un sistema di WM sono quelli che più facilmente possono essere definiti o controllati e integrati in sistemi coordinati. I candidati tipici sono quei processi che comportano un impiego intensivo di documenti, includono molti passaggi di dati tra i partecipanti e richiedono una notevole integrità strutturale. Ma anche processi semplici e/o “ad hoc” possono trarre vantaggio dalla gestione del workflow se implementati tramite un sistema di gestione altrettanto semplice e flessibile.
Una volta identificati i candidati ideali per il reengineering dei processi, sarà necessario assegnare delle priorità a quelle soluzioni che determineranno un impatto più significativo sull’azienda. Un metodo di valutazione consiste nell’assegnare delle priorità ai fattori identificati come fondamentali per il successo dell’azienda (i CSF, da Critical Success Factors) e ottenere dai decisori il consenso in merito ai progetti che permettono di risolvere gli aspetti con priorità superiore.
La tematica del WM non è affatto moderna: è un’arena nel quale si cimentano diverse scuole di pensiero e altrettante soluzioni, anche perché il mercato associato è piuttosto redditizio. Un tentativo di unificazione degli standard emergenti è attuato con la definizione e il perfezionamento del modello del Workflow Management Coalition (WfMC), che definisce un’architettura di riferimento generalizzata destinata a guidare lo sviluppo di gran parte delle soluzioni di workflow destinate al mercato, indipendentemente dal fatto che i vendor intendano o meno implementare tutte le interfacce tecniche standard pubblicate dal WfMC stesso. L’obiettivo del modello è quello di fornire uno standard per consentire l’interoperabilità tra i principali sottosistemi di workflow.
Mettere d’accordo tante teste (e tanti cospicui budget investiti i R&S) è sempre una mission piuttosto ardua, ma è auspicabile che, con il passare del tempo, i prodotti disponibili sul mercato includano delle interfacce aderenti a tali standard e consentano la cooperazione tra le varie suite di Workflow Management.
di Gian Franco Stucchi
In questo Caffè Sospeso, Gian Franco Stucchi tratta il tema del Concurrent Engineering, un approccio progettuale imperniato sull’integrazione e la collaborazione tra gruppi di lavoro.
Il continuo miglioramento, in termini di utilizzo di risorse, di controllo e di coordinamento, delle attività che compongono i processi aziendali sono le funzioni-guida che consentono di raggiungere obiettivi strategici quali la riduzione dei costi e dei tempi operativi e l’ottenimento di livelli di qualità elevati. Ne discende che una costante ed accurata governance dei processi assicura notevoli incrementi di efficacia e di efficienza, che a loro volta si riflettono sulla soddisfazione del cliente e sui risultati economici dell’impresa.
La gestione dei processi implica un cambiamento ed un conseguente intervento di miglioramento sugli stessi che può essere di due tipi: un cambiamento graduale o incrementale (spesso denominato Business Process Improvement) che, a partire dall’analisi dei processi esistenti, ne individua le criticità e ne propone un miglioramento, mantenendo costanti gli elementi essenziali), oppure un cambiamento radicale, alias Business Process Reengineering (BPR), che mette in discussione tutte le caratteristiche dei processi esistenti e “disegna” un nuovo modo di lavorare a partire da un “foglio bianco” [NdA: In proposito si rimanda al Caffè Sospeso “Un tris di “Re-” per la strategia d’impresa”]
Come motivazione dell’attenzione crescente che riscuotono le tematiche della gestione dei processi, gli studiosi di Management indicano il potenziamento della concorrenza giunta ormai a livello globale e che da tempo affligge il settore delle imprese. Non tutti, però, subiscono in ugual misura questa concorrenza: è il caso di chi opera in ambiti nei quali il monopolio è ancora vivo. Il monopolista gode di tutti i vantaggi dati da una posizione protetta e, talvolta, è in buona fede quando sostiene che non percepisce il cambiamento … perché, semplicemente, non può percepirlo. Per chi non gode di queste facilitazioni, essere un leader, o semplicemente sopravvivere nell’attuale scenario, è sempre più difficile.
Alcuni “guru” sono molto drastici sul futuro delle imprese e sostengono che oggi la concorrenza non dà tregua e se l’azienda che non si trasforma è destinata a soccombere.
Quali sono i fattori principali che hanno determinato questo notevole sviluppo della concorrenza mondiale? Innanzitutto bisogna osservare le caratteristiche del mercato e notare che è ormai una realtà consolidata la riduzione a commodity dei principali beni e servizi. Per commodity si intende un bene o un servizio difficile da differenziare, in particolare ricorrendo alla tecnologia, anche se richiede cambiamenti continui. Inoltre, grazie alle nuove tecniche di produzione, oggi vi è una sorta di personalizzazione di massa: abbiamo beni sempre più simili, con differenze modeste, in numero sempre maggiore.
Questo fatto è causati da vari fattori, tra i quali la ormai notevole diffusione delle tecniche di benchmarking , cioè di confronto continuo con altri produttori, che impedisce una reale differenziazione tra i concorrenti.
Contribuisce a questo appiattimento anche il Reverse Engineering in cui, semplificando al massimo il concetto, per produrre un oggetto si parte da uno analogo, prodotto da un concorrente – talvolta il “best-of-class”, ma non sempre – lo si decompone e si cerca di riprodurre il “core” migliorando e facendo in modo di differenziare i “peripheral. Questa strategia è anche una reazione al progressivo innalzamento delle richieste dei consumatori in termini di disponibilità e di qualità, fattori attualmente più importanti rispetto al passato.
Con queste premesse è facile comprendere perché l’offerta sia così articolata. La notevole evoluzione dell’ICT ha favorito una capillare diffusione di strumenti quali la posta elettronica, la videoconferenza, Internet, i sistemi software (ERP e best-of-breed) che sostengono le fasi critiche del ciclo di vita di un prodotto (progettazione e produzione). La mutata situazione del mercato impone quindi a enti ed aziende la necessità di ristrutturarsi, di rivedere continuamente i propri processi in chiave competitiva, anche se vi sono ancora resistenze, soprattutto da parte di chi fa notare che due ristrutturazioni aziendali su tre sono destinate al fallimento.
Certamente nelle esperienze di reengineering sono stati commessi errori come, per esempio, iniziare il reengineering senza un forte coinvolgimento di vari protagonisti della vita aziendale, sottovalutare i pensieri e i valori delle persone, accontentarsi di risultati marginali, permettere che una cultura dominante possa bloccare un progetto fin dall’inizio, dissipare le energie tra troppi progetti. È anche per queste cause che talvolta si ritiene che le trasformazioni aziendali, come il downsizing o il BPR, siano iniziative destinate al fallimento.
Nel contesto di competizione globale nel quale le imprese si trovano ad operare, uno dei fattori critici di successo consiste nell’essere in grado non soltanto di integrare in modo eccellente l’innovazione tecnologica nei processi di produzione, ma anche nella capacità di sviluppare in anticipo sulla concorrenza prodotti e servizi rispondenti alle aspettative del mercato. In altri termini, viene riconosciuta l’importanza crescente della capacità di progettare prodotti, processi e sistemi in grado di costituire una soluzione globalmente ottimizzata. Il mercato richiede entità complesse ed integrate – definibili come un “continuum prodotti/servizi” – che rispondano sia alle aspettative della clientela, per quanto riguarda la funzionalità e la qualità, sia ai requisiti di producibilità, individuando, già a partire dalla fase di progettazione concettuale. tutte le implicazioni relative alla produzione e al ciclo di vita del prodotto.
In questo quadro di sfide/opportunità – anch’esso un continuum – si declina la “mission” del Concurrent Engineering (CE), un insieme di metodologie e di strumenti informatici che consentono di integrare gli aspetti commerciali, finanziari, progettuali e produttivi che intervengono nei processi aziendali. Il CE è un approccio che consente di perseguire, in modo mirato ed efficace, due priorità strategiche fondamentali, il time-to-market e la qualità, mantenendo inalterati o addirittura riducendo i costi complessivi di produzione.
A tal fine risulta innanzitutto necessario – si ribadisce ancora una volta – progettare prodotti in grado di soddisfare le esigenze del cliente e ciò deve essere ottenuto con l’obiettivo di ridurre i costi dovuti alla non-qualità, i quali risultano collegati a vari parametri tra cui le modifiche successive, più o meno rilevanti, al prodotto o al processo produttivo; i problemi di produzione dovuti a difficoltà realizzative; l’errato utilizzo del prodotto da parte del cliente, con conseguenti alti costi di assistenza tecnica.
I costi di eliminazione di un difetto crescono esponenzialmente con l’avanzare del prodotto lungo il suo ciclo di vita e un altro obiettivo del CE è di spostare sempre più a monte la rilevazione dei difetti, possibilmente già a livello di pianificazione o progettazione.
L’obiettivo della qualità viene perseguito mediante l’adozione di approcci sia organizzativi sia tecnici. La dimensione organizzativa mira ad impostare lo sviluppo di un nuovo prodotto in modo corretto già all’origine, vale a dire sin dalla nascita delle esigenze del cliente (espresse o potenziali). Tali esigenze seguono tutte le fasi di sviluppo del prodotto, minimizzando le probabilità di modifiche a valle.
La dimensione tecnologica riguarda invece l’utilizzo di approcci mirati a particolari aree funzionali. Tra i molti acronimi esistenti, che designano metodi e tecniche correlati al CE (e richiederebbero ognuno una trattazione approfondita), i più diffusi sono: il Design For Assembly (DFM); il Design for Manufacturing and Assemby (DFMA); la Value Engineering (VE); la Value Analysis (VA); il Design Review (DR).
L’obiettivo temporale viene invece perseguito attraverso un’azione combinata che prevede la riduzione dei tempi persi per problemi di qualità, la revisione dell’intero processo di sviluppo dei nuovi prodotti; la riduzione del tempo necessario per espletare ogni singola fase del processo.
Gli aspetti di riorganizzazione sono di fondamentale importanza per ottenere i risultati sperati. A tal fine, l’approccio suggerito dal Business Process Reengineering consente la revisione sia della sequenza delle fasi di lavoro sia delle modalità organizzative per realizzarle. L’obiettivo è di limitare al minimo la necessità di operare in serie, anticipando, ove possibile, le fasi precedentemente espletate a valle, portandole a monte o svolgendole in parallelo.
Lo stesso termine CE è infatti riferito all’insieme di soluzioni e discipline tecnico-scientifiche che hanno come finalità l’attuazione congiunta (parallela, simultanea) dell’ingegnerizzazione e della progettazione di un prodotto. Ciò consente un abbattimento dei tempi complessivi necessari per la realizzazione, dato che i progettisti hanno modo di interagire fin dall’inizio della progettazione concettuale con gli ingegneri responsabili del processo produttivo. In tal modo vengono scoperti in anticipo i potenziali problemi di fabbricazione, che altrimenti rimarrebbero nascosti anche per lungo tempo.
Il CE prevede in particolare l’abbandono delle fasi funzionali-tayloristiche (cui corrispondono le strutture organizzative “a silos”), con passaggi di consegne tra i vari enti coinvolti, a favore di una maggiore integrazione lungo il processo attuata tramite il ricorso a gruppi di lavoro (strutture reticolari). Questo approccio garantisce che i punti di vista delle varie funzioni siano sempre presenti durante il processo di sviluppo del progetto. Si evitano inoltre quelle snervanti “partite di ping-pong” delle responsabilità tra le funzioni, che ottengono il solo risultato di allungare i tempi di progettazione e di aumentarne i costi, non garantendo affatto che il risultato del lavoro sia quel prodotto che risponde esattamente alle esigenze indicate dal marketing.
I gruppi di lavoro possono essere costituiti da aggregazioni temporanee di persone provenenti dalle varie funzioni interessate e dedicate a tempo pieno allo sviluppo di un nuovo prodotto. In alternativa, i gruppi possono essere formati da persone dedicate, ancora a tempo pieno, alla gestione di una molteplicità di prodotti, ognuno con un suo grado di “maturità” nell’ambito della conoscenza del ciclo di vita dei vari prodotti.
Accanto agli approcci indicati, esistono alcuni aspetti strategici, che influenzano grandemente lo sviluppo dei nuovi prodotti, indotti da scelte aziendali di portata più generale. Tra di esse si citano: il co-design, il carry-over, il mushroom concept.
– Il co-design riguarda la decisione di coinvolgere i fornitori di parti o lavorazioni già durante la progettazione dei nuovi prodotti. Esso si configura come un interscambio di know-how tra cliente e fornitore, ove l’oggetto della fornitura risulta specifico e non comune. Il cliente e il fornitore possono collaborare sia a partire dalle fasi alte della progettazione concettuale oppure da fasi intermedie, quali il progetto del prodotto e del processo produttivo. La necessità di basi informative comuni è ovviamente più critica nel primo caso, mentre all’estremo opposto (sub-fornitura), il fornitore produce semplicemente quanto gli è stato richiesto senza aggiungere alcun contributo originale. Le leve strategiche con cui governare il fenomeno di legame evoluto cliente-fornitore sono molteplici: si va da investimenti comuni in risorse specifiche a sistemi di protezione del fornitore come i contratti di lungo termine, la definizione di volumi di produzione minimi garantiti, le metodologie comuni di determinazione del prezzo di fornitura e gli accordi per assorbire i rischi, le comunicazioni orizzontali tra fornitori diversi.
– Il carry over riguarda la scelta di limitare il più possibile i cambiamenti nei componenti di un prodotto, per lo meno per quelle parti che meno lo caratterizzano, mantenendo quelle con provata affidabilità, con conseguente minori problemi causati da nuovi difetti e minori costi. Questo approccio, in genere, viene combinato con una riduzione del ciclo di vita del prodotto (quindi minori innovazioni sui nuovi prodotti, ma maggiore frequenza nei cambiamenti).
– Il mushroom concept prevede una struttura dei prodotti poco diversificata ai primi livelli di distinta base per poi esploderla agli ultimi livelli. La struttura del prodotto ricorda quindi la forma di un fungo (mushroom).
Il risultato complessivo delle scelte strategiche indicate è quello di ottenere strutture di prodotto più flessibili, più facilmente personalizzabili e con costi totali inferiori, grazie appunto alla riduzione del numero dei componenti.
Riassumendo, il Concurrent Engineering deve essere visto come doppio approccio organizzativo-tecnologico, anche se il primo dei due “poli” pesa molto più del secondo. Le tecnologie che lo supportano si avvalgono di strumenti quali i sistemi di Workflow Management e Groupware, oltre naturalmente dei sistemi di Project Management, nei quali viene enfatizzata la collaborazione tra persone e unità organizzative.
Ma il problema non è di tipo informatico e non riguarda esclusivamente la variabile tecnologica: esso investe la gestione aziendale, la sua organizzazione, la gestione delle risorse umane e, in generale, tutti i processi aziendali coinvolti nello sviluppo di nuovi prodotti.
Non è sufficiente, infatti, aver compreso ed applicato le varie metodologie esistenti o avere a disposizione sofisticati sistemi informatici o definire strutture organizzative di conduzione dei progetti perché il CE sia un’effettiva realtà aziendale. Occorre che si operi sui processi di apprendimento, sui processi di trasferimento delle informazioni, sulle motivazioni; soprattutto occorre acquisire la capacità di far operare insieme le persone delle diverse funzioni aziendali.
Un compito tutt’altro che semplice.
di Gian Franco Stucchi
In questo Caffè Sospeso seguiamo Gian Franco Stucchi nella “selva oscura” del Data Mining alla ricerca della conoscenza latente o nascosta nelle strutture informative e nei processi d’impresa.
L’estensione della conoscenza, permessa dai progressi della Scienza e della Tecnologia, riguarda le facoltà intellettive e creative dell’uomo, avviene senza alcun contributo dovuto all’evoluzione biologica e consente la creazione di beni, prodotti e servizi, sempre più knowledge-intensive (o technology-intensive) in sostituzione di quelli labor-intensive. L’evoluzione tecnologica e una serie di cambiamenti organizzativi e strutturali di vasta portata stanno accelerando la trasformazione delle imprese in sistemi in grado di apprendere dall’esperienza e di adattarsi ai mutamenti esterni. La nozione di ripetibilità, per quanto spesso sia intesa nel senso di “fare continuamente la stessa cosa”, implica in realtà il ricorso a un’esperienza precedentemente acquisita in situazioni simili al fine di assumere le decisioni migliori per ogni iniziativa imprenditoriale.
Tuttavia, sviluppare la capacità di impossessarsi della conoscenza insita nell’esperienza è una sfida non indifferente, ma utilizzare i dati prodotti dai processi di natura endogena o esogena ad un sistema come depositi di conoscenze ovvero come “memorie” del sistema stesso costituisce una potente leva d’azione per governarne l’evoluzione e per modificare le modalità con le quali vengono attuate le interazioni con l’ambiente. Catturare, gestire e integrare la conoscenza insita nei dati ed elaborata nei processi significa offrire alle organizzazioni una serie di strumenti efficaci che possono essere utilizzati per reagire ai ritmi derivanti dalla turbolenza dei contesto ambientale.
Ma tra il dire e il fare c’è di mezzo il solito mare. E’ necessario, innanzitutto, dare un significato ai dati, un’attività che nella letteratura ICT corrente è denominata in termini differenti. A seconda della comunità di ricerca che se ne occupa, si incappa in termini quali knowledge extraction, information harvesting, data archeology, data pattern processing. Il termine Data Mining, oggi “sugli scudi” in molte discipline di Management, è utilizzato per lo più dagli studiosi di database, in ambito statistico e, sempre più spesso, in campo economico.
L’acronimo KDD (Knowledge Discovery in Databases) è utilizzato per riferirsi ad un processo che mira a scoprire informazioni utili a partire dai dati disponibili. Il Data Mining costituisce solo una fase particolare in questo processo, la fase in cui si opera l’applicazione di algoritmi specifici per estrarre modelli o pattern significativi dai dati. Sono gli altri passi del processo KDD, come la preparazione, la selezione, la pulizia dei dati, la fusione di appropriate informazioni antecedenti e la corretta interpretazione dei risultati del mining, che assicurano che l’informazione sia significativa. La cieca applicazione dei metodi di Data Mining può essere un’attività pericolosa, che conduce sovente alla scoperta di modelli privi di senso (non a caso, un tempo, la letteratura statistica definiva come “drogati” i risultati di queste tecniche).
Il KDD, come disciplina tecnico-scientifica, sta evolvendo e si potenzia grazie alla fertilizzazione incrociata delle ricerche nei campi più disparati; non solo, quindi, dal settore che si occupa dello studio e della progettazione dei database (e di tutto ciò che vi è di afferente, inerente o consequenziale come i data warehouse o i data mart) ma anche da settori apparentemente più distanti quali quelli che si interessano di intelligenza artificiale, di statistica, di modellistica, di sistemi esperti, di metodi di reporting, di metodi per il recupero dei dati e di metodi per accrescere la velocità di calcolo. I sistemi software di KDD incorporano perciò teorie, algoritmi e metodologie derivate da un elevato numero di settori di indagine.
L’approccio tradizionalmente adottato per ottenere informazioni da un database è basato sull’uso di strumenti che consentono di effettuare semplici interrogazioni (query), formulate in un linguaggio naturale o formale, come l’SQL; questi strumenti risultano, però, inaccettabilmente lenti su grandi quantità di dati. Un approccio popolare al Data Warehousing è chiamato OnLine Analytical Processing (OLAP): gli strumenti della metodologia OLAP si focalizzano sulla fornitura di un’analisi multidimensionale dei dati che è qualitativamente superiore a quelle ottenibili con il tradizionale linguaggio SQL. Nel paradigma OLAP viene preparata in anticipo una vasta classe di query, sommarizzando i dati in categorie di business predefinite. Per esempio, una regola potrebbe indicare un certo importo di reddito come piccolo, medio o grande, permettendo quindi di condensare i dati in modo da facilitare la creazione di fogli elettronici e tabulazioni incrociate.
L’approccio OLAP è quindi più veloce di quello basato sulle query tradizionali, poiché opera su dati aggregati. Lo svantaggio è che le norme, che rendono possibile la sommarizzazione, scartano i dettagli, con la possibilità, a volte, di perdere importanti informazioni.
I settori della ricerca coinvolti nello studio dei modelli di deduzione, quelli che studiano la rilevazione statistica di modelli, la statistica applicata, la scienza dell’informazione e le reti neurali sono stati lo stimolo per molti nuove attività di KDD, prime fra tutte il Data Mining.
E’ comunque importante domandarsi in che cosa il KDD sia effettivamente differente dagli altri processi di indagine. Esso si focalizza sul processo generale di knowledge discovery comprendendo tutto ciò che riguarda le metodologie di memorizzazione e accesso; valutando come gli algoritmi possano essere commensurabili e coerenti con le dimensioni (spesso enormi, come i big data) e la natura (quasi sempre eterogenea) di strutture informative complesse e possano funzionare efficientemente con operandi siffatti; o ancora individuando come i risultati possano essere visualizzati e interpretati in modo significativo (riducendo al minimo l’errore sistematico o il “rumore”); o, infine, come possano essere modellate e supportate le complesse interazioni uomo-macchina. Il KDD, inoltre, pone un’enfasi particolare nella determinazione di modelli non-standard in grado di rilevare una conoscenza significativa o quantomeno interessante latente o occulta. La scalabilità degli algoritmi di modellazione e le proprietà di robustezza al rumore rappresentano, infine, aspetti altrettanto fondamentali.
La statistica ha molto in comune con il KDD. Essa fornisce un linguaggio e una struttura adatta a quantificare l’incertezza derivante dal tentativo di generalizzare i modelli, quasi sempre tratti da particolari campioni di una popolazione generale. Come accennato precedentemente, il termine Data Mining ha avuto connotazioni negative in ambito statistico sino agli anni ’60, fino a quando, cioè, apparvero le prime tecniche di analisi basate sull’utilizzo degli elaboratori.
Il fatto è che se si ricerca abbastanza a lungo, ogni “universo” di dati (anche quelli prodotti casualmente) può generare modelli che appaiono, pur non essendolo, statisticamente significativi. Da questa rilevazione, di fondamentale importanza, nasce la seguente considerazione: solo se il processo KDD viene svolto correttamente è possibile legittimare, in ambiente statistico, il Data Mining.
Il KDD ha sicuramente una visione più allargata rispetto alla visione statistica, poiché cerca di generare strumenti per automatizzare l’intero processo di analisi dei dati, includendo l’arte, tipicamente statistica, della selezione delle ipotesi.
Si arriva dunque ad ottenere, per il KDD, la prospettiva di una struttura unificata e processo-centrica. Lo scopo è quello di giungere a una panoramica delle attività di questi campi multidisciplinari e di mostrare come questi interagiscano. Si definisce il processo KDD come: “Il processo non-banale di identificazione di modelli di dati validi, originali, potenzialmente utili e comprensibili”.
Da questa definizione si deduce la possibilità di individuare misure quantitative per valutare i modelli trovati. Concetti come originalità e comprensibilità sono, chiaramente, molto più soggettivi anche se, in certi contesti, la comprensibilità può essere stimata con semplicità.
Un aspetto importante, che combina validità, originalità, utilità e semplicità, è definito come “interestingness” (attrattività) ed è generalmente assunto come misura generale del valore di un modello.
Il Data Mining si occupa di enumerare i modelli, ma, dal momento che questi, anche considerando un insieme finito di dati, sono potenzialmente infiniti, e poiché questa operazione richiede una ricerca ad ampio raggio d’azione, i limiti computazionali pongono severe limitazioni allo spazio che può essere esplorato attraverso i suoi algoritmi.
Il processo KDD è interattivo e iterativo e comprende numerosi passi descritti come segue:
- Comprensione del campo di indagine: capire quali sono le priorità di approfondimento e individuare gli obiettivi.
- Target dataset: creare una base di dati da cui partire, cioè selezionare un particolare insieme di dati o focalizzarsi su un sottoinsieme di variabili o modelli sui quali si vuole indagare.
- Data cleaning e preprocessing (avvio delle attività di analisi): ovvero avvio delle operazioni di base, come la rimozione dei disturbi o di dati estranei, la raccolta di tutte le informazioni necessarie per modellare e spiegare il rumore, la definizione delle strategie per il trattamento dei dati eliminati, l’orientamento dell’informazione rispetto al tempo (informazioni in sequenza e in cambiamento), come pure la spiegazione di tutto ciò che emerge dal DBMS – come, per esempio, i modelli di dati, i pattern e la mappatura dei valori mancanti e incogniti.
- Riduzione e proiezione dei dati: ricerca di modalità utili per rappresentare i dati, in relazione all’obiettivo dell’applicazione, e utilizzo di riduzioni dimensionali e metodi di trasformazione per cercare rappresentazioni alternative dei dati o per diminuire l’effettivo numero di variabili sotto osservazione.
- Scelta della funzione di Data Mining: individuazione del fine che si propone il modello derivato dall’algoritmo di Data Mining (per esempio sommarizzazione, classificazione, regressione, etc.).
- Scelta dell’algoritmo (o degli algoritmi) di Data Mining: scelta del metodo da usare per ricercare modelli dai dati e decisione su quale tra questi possa essere il più appropriato e accoppiamento di un particolare metodo di Data Mining con i più generali criteri del processo KDD (un utente potrebbe essere più interessato alla comprensione del modello piuttosto che alla sua capacità di predizione).
- Data visualization: ricerca di modelli di interesse per una particolare forma di rappresentazione.
- Interpretazione dei modelli scoperti e possibilità non solo di rimandare il processo ad uno dei passi precedenti ma anche di generare forme di visualizzazione dei modelli estratti comprensibili agli utenti finali.
- Utilizzo della conoscenza acquisita: acquisizione e fusione di informazioni e esperienze precedenti nei sistemi in uso, avvio di azioni basate su di esse o attività di documentazione o di reporting.
Sebbene ognuno di questi passi rivesta particolare importanza per il successo di questo processo conoscitivo è interessante focalizzare l’attenzione sul Data Mining. Gli analisti e la comunità accademica interpretano il Data Mining come un’attività basata sull’utilizzo di quei dati di dettaglio sui quali le query tradizionali risultano inefficaci. Per fare del Data Mining si tende quindi a non utilizzare strumenti di query e di OLAP, ma piuttosto le tecniche sviluppate nei campi della statistica e del machine learning.
Gli algoritmi di ricerca si dividono in due tipologie: quelli che ricercano i parametri critici, e da essi ricavano il modello, e quelli che arrivano direttamente a esso operando in uno spazio appropriato. Ne discende che gli approcci di Data Mining possono essere classificati in due tipi: l’approccio top-down e l’approccio bottom-up.
L’approccio top-down. Chi effettua l’analisi dei dati, servendosi dei mezzi della statistica, “guida” l’esplorazione cercando di trovare conferme a fatti che ipotizza o che già conosce (per esempio quali fattori hanno prodotto un risultato conosciuto), o cercando di ampliare la sua conoscenza su nuovi aspetti di un fenomeno che conosce, ma solo in parte. A questo scopo si utilizzano le tecniche statistiche tradizionali come il clustering, l’analisi fattoriale ed i metodi previsionali. La statistica resta, però, difficile da applicare e da interpretare da parte di utenti non competenti; inoltre le difficoltà di utilizzo aumentano all’aumentare del numero di fattori, in particolare, quando si è in presenza di fenomeni non lineari.
L’approccio bottom-up – E’ quel processo mediante il quale l’analista si mette alla ricerca di informazioni utili “scavando” fra i dati e collegandoli tra loro, in modo non aprioristico, per costruire ipotesi (per esempio quali fattori sono le cause più probabili che producono un certo risultato).
La maggior parte degli algoritmi di Data Mining può essere vista come composizione di tre momenti e tecniche di base:
- Il modello – Due sono i fattori rilevanti: la funzione del modello (classificazione, clustering etc.) e la forma di rappresentazione di esso (funzione lineare a variabili multiple, Gaussiana, etc.). Un modello contiene sempre parametri derivati direttamente dai dati.
- Il criterio preferito – E’ il criterio che regola la scelta di un modello o di un insieme di parametri rispetto ad altri. Il criterio è generalmente una funzione di ottimizzazione del modello dei dati, spesso stabilizzata da un termine correttivo (smoothing term) per evitare errori (overfitting) o la generazione di un modello con troppi gradi di libertà per essere descritto in modo univoco dai dati estratti.
- L’algoritmo di ricerca – Concerne la specifica di un algoritmo per ricercare particolari modelli e parametri (e contribuisce a stabilire un proprio criterio di preferenza).
Pur essendo, quindi, ogni algoritmo frutto dei tre componenti (modello-preferenza-ricerca), raramente la letteratura sull’argomento spiega con chiarezza il modello di rappresentazione, il criterio di preferenza ed i metodi di ricerca usati; questi, nella descrizione di un particolare algoritmo, sono spesso impliciti ed indistinguibili.
La visualizzazione multidimensionale favorisce l’esplorazione poiché presenta all’analista i dati in modo tale da sfruttare quelle capacità di percezione che sono proprie agli esseri umani, così da facilitare la ricerca di relazioni nascoste. Tali strumenti di visualizzazione avanzata permettono di osservare tre o più dimensioni o variabili alla volta. Il vantaggio di utilizzare strumenti avanzati sta nel fatto che si possono scoprire legami, tendenze e anomalie presenti nei dati, molto più velocemente che non tramite la grafica o la reportistica tradizionali.
La modellistica riguarda la forma funzionale che lega i dati. Avere a disposizione un modello significa avere la possibilità di fare delle previsioni e delle simulazioni. Le funzioni di modellizzazione(model function) più comuni nell’attuale pratica di Data Mining sono:
- Alberi di classificazione – Un albero di classificazione viene costruito suddividendo ripetutamente i dati secondo sottogruppi definiti dai valori delle variabili di risposta per tentare di trovare sottoinsiemi omogenei. Questa suddivisione genera una gerarchia in cui i sottoinsiemi di partenza vengono chiamati nodi, e quelli finali, foglie. L’albero decisionale può essere usato per generalizzare le regole, con i nodi che costituiscono i punti di decisione.
- Clustering – Le tecniche di clustering arrivano ad ottenere uno schema di segmentazione dividendo una popolazione in sottogruppi distinti. Il punto debole di questa tecnica è che non può essere utilizzata direttamente per fare previsioni o per applicare la classificazione ad altri insiemi di dati poiché i cluster non sono definiti come funzioni esplicite dei predittori, ma cercando aggregazioni naturali di dati, basate su modelli a densità di probabilità.
- Neural network – Le reti neuronali (o neurali) sono una vasta classe di modelli sviluppati nell’ambito delle Scienze Cognitive che, grazie ad un processo di apprendimento in cui “imparano” la forma dei dati modificando i propri parametri interni, riescono a risolvere complessi problemi di classificazione e di previsione. La capacità di valutare un gran numero di fattori e la tolleranza verso dati imperfetti – come la presenza di dati mancanti o altri problemi di qualità dei dati – ne fanno uno strumento particolarmente adatto per analizzare i dati del mondo reale. La loro capacità di generalizzare la conoscenza appresa le rende adatte a funzionare in un ambiente dinamico, dove i dati cambiano continuamente.
- Regressione – Si classifica un dato secondo il valore reale della variabile di predizione.
- Summarization – Si genera una descrizione compatta di un sottoinsieme di dati. Ad esempio ci si può semplicemente servire della media e della deviazione standard calcolate per tutti i campi. Funzioni maggiormente sofisticate potrebbero essere invece procedure di sommarizzazione, tecniche di visualizzazione multivariate, e tecniche che stabiliscono relazioni funzionali tra variabili. Le funzioni di sommarizzazione sono usate spesso nelle indagini a carattere esplorativo e interattivo e nella generazione automatica di resoconti (report).
- Dependency model – Questi modelli evidenziano le dipendenze più significative tra le variabili e operano su due livelli distinti: strutturale e quantitativo. Il livello strutturale specifica (sovente in forma grafica) quali variabili sono dipendenti localmente; il livello quantitativo specifica l’intensità delle dipendenze per mezzo di una scala numerica
- Analisi di legame – Sono metodi per determinare le relazioni tra differenti campi di un database (es. regole associative per descrivere quali articoli sono comunemente acquistati insieme ad altri in un supermercato). Lo scopo è derivare correlazioni multicampo che soddisfino le soglie di confidenza e di fiducia.
- Analisi di sequenza – Sono tecniche che servono a modellare gli stati del processo che generano la sequenza dei dati, oppure a estrapolare e visualizzare scostamenti e tendenze in un dato arco temporale.
Altre rappresentazioni popolari sono i modelli di campionamento (example-based metod), i modelli grafici di dipendenza probabilistica (per esempio le Baesyan Network) e altri tipi di modelli non lineari e relazionali. La forma di rappresentazione determina sia la flessibilità nel gestire e mostrare i dati sia la trasparenza, la leggibilità e la chiarezza in termini di relazione con l’analista. In generale, se da un lato i modelli di maggior complessità possono adattarsi perfettamente ai dati, essi sono altresì difficoltosi da comprendere e da modificare. Mentre i ricercatori spingono nella direzione della complessità, gli utilizzatori spesso prediligono applicazioni basate su modelli più semplici, ma robusti e ben interpretabili.
È la metodologia di scelta a determinare quanto un modello e i suoi parametri si adattino ai criteri del processo KDD. Generalmente si tratta di un metodo quantitativo esplicito, inserito in un algoritmo di ricerca (per esempio il Criterio di Massima Verosimiglianza nella ricerca dei parametri che massimizzano una funzione di probabilità dei dati osservati). Anche un criterio implicito – che rispecchia il punto di vista soggettivo dell’analista, in termini di errore, del modello iniziale – è spesso utilizzato nelle iterazioni successive del processo KDD. La ricerca dei parametri migliori è spesso ricondotta ad un problema di ottimizzazione. Gli algoritmi di Data Mining fanno affidamento su tecniche di ottimizzazione piuttosto semplici, sebbene nella teoria ne siano previste anche alcune molto sofisticate. Un fatto da tenere in considerazione è che ogni tecnica rivolge particolare attenzione soltanto ad un numero limitato dei possibili problemi, quindi non si possono definire metodi di Data Mining migliori in senso assoluto.
Scegliere un particolare algoritmo per una specifica applicazione richiede una “sensibilità” notevole. In pratica gran parte dello sforzo consiste nella formulazione corretta dei problemi (ponendo le giuste domande) piuttosto che nell’ottimizzare i dettagli algoritmici di un particolare metodo di Data Mining.
Gli obiettivi di più alto livello del Data Mining possono essere di tipo predittivo, descrittivo, o riguardare una loro combinazione. Mentre un obiettivo puramente predittivo si focalizza necessariamente sull’accuratezza nell’abilità di previsione, un obiettivo puramente descrittivo concentra l’attenzione sulla profonda comprensione dei processi che sostengono la generazione dei dati: è una distinzione sottile ma importante. Nella predizione, l’utente non è tenuto a preoccuparsi se il modello riflette o meno la realtà purché esso abbia valore predittivo (per esempio: un modello che metta in relazione, in modo non lineare, indicatori finanziari attuali allo scopo di prevedere i tassi di cambio futuri di una certa valuta). Di converso, un modello descrittivo va visto come un quadro della realtà: per esempio un modello che correli variabili economiche e demografiche allo scopo di produrre risultati che siano utili a fornire raccomandazioni per una politica sociale volta al cambiamento. Nella pratica. comunque, la maggior parte delle applicazioni KDD attinge da entrambe le tipologie di modellizzazione.
Con buona pace di tutte le scuole di pensiero che si rifanno alle Scienze Cognitive e ai Processi Decisionali
Di Gian Franco Stucchi