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
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 descrive l’evoluzione della virtualizzazione, oggi un paradigma computazionale che ha come obiettivo la trasformazione delle risorse informatiche in suite di elaborazione funzionalmente potenti e integrate
Nelle discipline informatiche di base, con il termine “virtualizzazione” si intende il processo di creazione di una versione non reale di una certa risorsa computazionale (come, per esempio, un sistema operativo, un server, un dispositivo di memorizzazione di massa, una rete, una risorsa di rete, ecc.). La versione virtuale è – anzi, deve essere – funzionalmente analoga o superiore all’entità reale, ovvero mostrare almeno lo stesso comportamento. La prima forma di virtualizzazione, la più semplice ma anche la più rozza, si sperimenta quando si suddivide un disco fisso in due partizioni, ovvero in due dischi virtuali apparentemente disgiunti ma funzionalmente simili.
I processi di virtualizzazione si incontrano anche nell’ambito dei sistemi operativi: sono frutto di una prassi in auge crescente fin dagli anni Sessanta, consistente nell’utilizzo di un sistema software di alto livello (detto ipervisore) per permettere a un pool di risorse infrastrutturali (hardware, software, storage, reti) di eseguire delle attività applicative o sistemistiche in modo concorrente, ma sotto il governo di uno o più sistemi operativi diversi o istanze diverse di uno stesso sistema operativo.
Le tecnologie atte a favorire la virtualizzazione dei sistemi operativi si svilupparono in ambiente mainframe (IBM CP/CMS, VM, ecc.) e consentirono agli amministratori di sistema di evitare sprechi di risorse memory-based e di potenza computazionale in un periodo in cui la richiesta di servizi IT era in continua crescita e i costi di elaborazione piuttosto elevati. Successivamente, con la crescente diffusione dei minicomputer e la diminuzione dei costi di elaborazione, la virtualizzazione della memoria si diffuse anche in ambienti meno poderosi e ponderosi: emblematico fu il caso del Digital VAX ove l’acronimo designava una proprietà nativamente virtuale della macchina: la Virtual Address eXtension).
A partire dal 2005 i sistemi software per la virtualizzazione, intesa in senso lato e riguardante ogni tipo di risorsa, sono stati adottati molto più velocemente di quanto gli esperti potessero immaginare.
Attualmente sono sostanzialmente tre i settori dell’ICT in cui la virtualizzazione si sta diffondendo: le reti, lo storage e i server.
La virtualizzazione di rete è un metodo per combinare le risorse disponibili in una struttura reticolare ma in modo tale da suddividere la larghezza di banda in canali, ognuno dei quali è indipendente dagli altri e può essere assegnato (o riassegnato) in tempo reale a un determinato server o un dispositivo. L’idea di base è di far sì che la virtualizzazione possa nascondere la complessità gestionale e topologica della rete, separando la banda in modo tale che le operazioni risultino assolutamente gestibili, proprio come un disco rigido partizionato rende più facile la gestione dei file.
La virtualizzazione dello storage consiste nella capacità di mettere a disposizione del parco utenti una quantità, anche notevole, di memoria di massa ottenuta grazie alla configurazione virtuale di una rete di dispositivi di storage fisici e tale che appaia come un dispositivo di archiviazione singolo e gestito da una console centrale.
La virtualizzazione dei server è il mascheramento delle risorse di elaborazione (compreso il numero e l’identità dei singoli server fisici, dei processori e dei sistemi operativi) attuato nei confronti degli utenti. L’intenzione è di risparmiare a questi l’onere di dover comprendere e governare la complessità delle informazioni riguardanti i server, di aumentare la condivisione e il grado di impiego delle risorse disponibili, nonché di potenziare la capacità di espandere facilmente il pool delle risorse di elaborazione.
La virtualizzazione può essere vista come un aspetto del “Computing on Demand” , una tendenza generale che da alcuni anni anima l’evoluzione dell’ICT di classe enterprise e comprende anche l’”Autonomic Computing”, uno scenario in cui l’ambiente IT è in grado di gestire se stesso in base al livello di attività percepita, e l’”Utility Computing , in cui la potenza di elaborazione dei sistemi è percepita come un servizio di utilità che i clienti pagano solo se e quando è necessaria per le loro esigenze. L’obiettivo della virtualizzazione è di centralizzare le attività amministrative migliorando la scalabilità e la distribuzione dei carichi di lavoro.
La tendenza sopra menzionata trova la sua massima espressione nello stato di frenetica e curiosa eccitazione che il mercato manifesta nei confronti del Cloud Computing – anche se esiste un solo tentativo di modellare, in modo rigoroso e formale, questo fenomeno ed è quello proposto dal National Institute of Standards and Technology statunitense. [NdA: In proposito si rimanda il lettore al Caffè Sospeso “Le tre dimensioni del Cloud Computing”
Dato questo contesto, il tema della virtualizzazione, dopo essere stato anch’esso sugli scudi da qualche anno a questa parte, è stato poi trattato come una commodity – ovvero una voce da spuntare nella “to-do list” di ogni CIO (o IT Executive che dir si voglia) – piuttosto che come un argomento apicale, stimolo di un’adeguata e costante prassi operativa che può determinare il successo o il fallimento di un’iniziativa ICT. I tempi, però, stanno cambiando (e quando mai nell’ICT si sono cristallizzati?) e la virtualizzazione sta riassumendo una valenza strategica anche grazie all’importanza che riveste e all’onnipresenza di cui gode nei vari modelli emersi dal paradigma del Cloud Computing
I vantaggi e gli svantaggi della virtualizzazione sembrano abbastanza chiari e recepiti dal mercato, mentre il passaggio al Cloud Computing – forse per mancanza di esperienze consolidate – si sta rivelando spesso come la sostituzione di una serie di problemi con un’altra, talvolta più gravosa. La gestione delle risorse in ambiente cloud è sempre frutto di un progetto, molto complesso, riguardante la risoluzione dei conflitti che possono insorgere tra le infrastrutture fisiche; inoltre spesso si evoca un’immanente inaffidabilità della “nuvola” e si portano come prove i casi di insuccesso avvenuti in passato. In realtà molti eventi di questo genere, come altri già verificatisi nel corso della storia dell’ICT, sono avvenuti come diretta conseguenza di implementazioni reali di bassa qualità, piuttosto che di incoerenze intrinseche nel modello del Cloud Computing.
Da questa osservazione discende che la scelta di adottare, per l’ICT aziendale, l’opzione del Cloud Computing produce un incremento delle responsabilità che gravano sull’Unità Organizzativa Sistemi Informativi (e sul suo manager). Infatti, al fardello dei compiti nativi della funzione, si aggiungono quelli del controllo della qualità e della valutazione dei rischi di ogni soluzione innovativa. Ciò avviene anche quando il CIO non è responsabile della decisione finale o della scelta, e nemmeno ha interpretato il ruolo di “primus inter pares” in un comitato guida. In ogni caso è naturale che a questa figura manageriale si debba far risalire la pianificazione delle risorse virtualizzate e l’impostazione di un accurato piano di bilanciamento del carico elaborativo tra le varie aree in cui si articola il sistema informatico.
Quando si concepisce un progetto di virtualizzazione delle infrastrutture informatiche sorge innanzitutto il problema dell’identificazione e del trattamento dei fattori critici di successo e di insuccesso, cioè di quei processi vitali o mortali per il buon esito del paradigm shift computazionale.
In primo luogo bisogna considerare il contesto nel quale avviene la transizione verso la virtualizzazione. Molte unità organizzative IT hanno utilizzato la virtualizzazione dei server per de-sincronizzare (prima) e spostare nel cloud (dopo) i carichi di lavoro non critici, ma i requisiti di sicurezza e di controllo richiesti da questo approccio – piuttosto rigorosi, quindi dispendiosi – hanno impedito l’attuazione di numerose piccole implementazioni di “private cloud” a causa degli alti costi di realizzazione e di esercizio.
Secondariamente, si noti che i primi progetti di Cloud Computing erano basati su blade server connessi a un’architettura indipendente di Storage Area Network. Era un modello che consolidava l’unità centrale di elaborazione e la memoria in configurazioni di server piuttosto “dense” e collegate, tramite diverse reti ad alta velocità, a grandi impianti di SAN. Questo è stato il modello tipico delle tradizionali infrastrutture di virtualizzazione di tipo “off the shelf” pre-costruito, adottato, in particolare, nelle imprese che realizzano implementazioni di private cloud.
Di recente i produttori di hardware hanno iniziato a offrire alcune commodity hardware modulari, in configurazioni sempre più dense, che costituiscono i “mattoni” elementari per costruire il cosiddetto “Hyperscale Computing”
L’obiettivo primario delle hyperscale platform è di realizzare due funzioni critiche del Cloud Computing (e dell’ICT in generale) – la scalabilità e l’affidabilità – esclusivamente a livello di piattaforma, isolandole dal sottostante livello dell’hardware e dal sovrastante livello applicativo.
La differenza più evidente rispetto ai dispositivi preesistenti è la disponibilità di unità di memoria di massa a stato solido un’opzione che permette al server virtualizzato di eseguire le macchine virtuali in modo nativo nel sistema host senza uscire dalla SAN, una modalità che si traduce in una rete molto meno complessa e, quindi, con notevoli vantaggi rispetto ad altre configurazioni. Ne discende che non solo cambia radicalmente il rapporto prezzo/prestazioni del Cloud Computing, ma viene semplificata l’implementazione delle infrastrutture del cloud, riducendo, di conseguenza, anche il livello delle competenze IT necessarie per gestirlo. E’ un’architettura che offre ai team di implementazione una flessibilità notevole, tanto che si dice che permetta di assumere il “modello Lego” come archetipo per combinare nodi di calcolo e di storage in unità ottimali, incapsulate all’interno di un raggruppamento di LAN virtuali appartenenti a una certa dislocazione fisica di risorse. Si osservi, infine, che è enormemente facilitata la gestione di un pool di risorse di elaborazione e di storage di grandi dimensioni, dislocato in un sottoinsieme delle infrastrutture di un data center univocamente controllato.
Da quanto riportato finora si osserva che è ormai consolidato il fatto che la rivoluzione della virtualizzazione – l’atto secondo – sia in corso più a livello di data center che non di server. Con l’implementazione delle architetture virtualizzate e modulari, ogni impresa può godere contemporaneamente dei vantaggi che derivano dalla virtualizzazione a livello di reti, di storage e di server, con notevoli risparmi in termini di costi e di ottimizzazione delle prestazioni.
Il problema che emerge quando si progetta un data center totalmente virtualizzato è come identificare e realizzare le operazioni IT in modo tale da configurare in modo intrinsecamente coerente e monitorare efficacemente il complesso delle risorse virtuali. Dato che l’ecosistema globale del Cloud Computing è ancora relativamente “giovane”, rimanere al passo con le tecnologie e con le best practice costituisce una sfida non indifferente per ogni Unità Organizzativa IT (sia questa un reparto, un dipartimento, un’azienda nata da uno spin-off, un outsourcer, etc.). Inoltre, siccome il patrimonio delle competenze e delle esperienze nella gestione di grandi infrastrutture virtualizzate è piuttosto esiguo, molte imprese devono affrontare la sfida della virtualizzazione riconvertendo il personale IT al Cloud Computing (con il rischio di vederselo poi sottrarre da altre aziende) oppure ricorrendo all’outsourcing (con il rischio di accrescere a proprie spese la competenza esterna).
Forse una soluzione esiste, poiché si sta affermando una semplice ma potente killer application: la Cloud User Interface (CUI) che incapsula e favorisce l’operatività a livello di orchestrazione del cloud. Negli ultimi anni nel settore del Cloud Computing sono avvenuti diversi eventi significativi che hanno riguardato sia i grandi player dell’ICT (le Major) che le imprese di media dimensione. Tutte hanno proposto delle architetture di riferimento per i data center, puntando sulla convergenza di vari modelli infrastrutturali e su combinazioni ottimali di hardware e software per gestire i sistemi virtualizzati.
Esaminando le soluzioni proposte, si osserva che la CUI sta assumendo un’importanza crescente come fattore critico di successo del Cloud Computing in azienda. In un buon sistema di Cloud Orchestration, un’altrettanto buona UI non riveste solo un ruolo di semplice “trasformatore” – dal vecchio paradigma al nuovo, ovvero di fattore abilitante della massimizzazione delle funzionalità cloud (come il bilanciamento del carico) – ma anche di fattore critico decisionale in fase di scelta della soluzione da implementare.
Gli utenti di estrazione tecnica normalmente apprezzano i pannelli di controllo e i dashboard basati sul web, ma sono sempre un po’ conservatori e spesso richiedono, almeno inizialmente, anche un controllo supplementare delle fasi operative e di governo di una struttura ICT ottenibile tramite i tool di Command Line Interface (CLI ) e le Application Programming Interface (API ). Ne discende che rendere più o meno complessa l’interfaccia può avere un impatto significativo sulla produttività degli sviluppatori e degli amministratori di sistema, così come l’hanno, in generale, le operazioni di riqualificazione del personale (ma questo meriterebbe una trattazione a parte.
La virtualizzazione, per definizione, impone un livello di astrazione che coinvolge i dettagli dei server fisici, le specifiche delle macchine virtuali e i parametri “di targa” del networking. E’ un’operazione complessa, che a volte suscita in azienda delle lamentele perché le soluzioni di Cloud Orchestration sembrano essere delle “scatole nere” che, riducendo il controllo umano sulla tecnologia di base, sarebbero poco affidabili. In realtà, analogamente a ciò che avviene a livello del sistema operativo, raramente gli utenti interagiscono a livello di codice con la complessa tecnologia sottesa dal Cloud Computing; inoltre, è possibile aumentare la comprensione di questo paradigma grazie a corsi di formazione sulle caratteristiche del modello computazionale adottato. Infine, se la virtualizzazione potenzia veramente l’Unità Organizzativa IT nelle sue attività caratteristiche (riduzione del time-to-market, utilizzo dell’hardware e risparmio di tempo nella gestione delle risorse consentendo agli sviluppatori di creare autonomamente delle macchine virtuali autorizzate,etc.) allora dovrebbero risultare potenziate anche le attività e i processi dedicati alla crescita del business.
Il fenomeno Cloud Computing è stato discusso per anni – e la virtualizzazione per decenni – ma, al di là di ogni elucubrazione teoretica, restano alcuni problemi aperti e di non facile soluzione. Il fascino di una risorsa virtuale sta nel fatto del suo essere effimera: se si hanno delle necessità di elaborazione variabili si possono, più o meno semplicemente, aggiungere on-demand dei pool di risorse e, successivamente, ridimensionare la struttura informatica e l’assorbimento delle risorse computazionali quando il carico di picco diminuisce. Rimane però il problema del Cloud Burst (letteralmente: scoppio del cloud), una locuzione utilizzata per denominare l’esigenza di un’organizzazione di scalare velocemente verso l’alto le proprie applicazioni di rete per soddisfare improvvisi picchi di domanda. Questo sembrerebbe un evento auspicabile ma, se non fosse gestito correttamente, potrebbe causare seri danni.
Ben vengano quindi i cambiamenti dei paradigmi computazionali, sperando che possano convertire le monolitiche architetture di elaborazione esistenti in una pluralità di infrastrutture più modulari, che mettano a disposizione livelli di controllo e di operatività tali da consentire di comporre un data center avanzato e governato da un sistema software avanzato di Cloud Orchestration.
L’evoluzione delle risorse virtualizzate da gruppi di “slices of servers” a strutture “slices of full data center infrastructures” comporta un significativo cambiamento nell’utilizzo delle risorse di calcolo, incidendo sul time-to-market delle nuove applicazioni, sulla velocità di innovazione e sui costi delle risorse di base. Ognuno di questi argomenti dovrebbe essere esplorato in modo più dettagliato, individuando alcuni fattori critici come il consumo di energia e la pianificazione della capacità.
Ma questa è – al solito – un’altra storia, che innesca un tema di grande attualità: il green computing.
Ne parleremo; restate connessi.
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
Gian Franco Stucchi dedica questo Caffè Sospeso alla definizione degli obiettivi del Customer Relationship Management. Le relazioni con i clienti sono diventate un asset strategico per le imprese che investono risorse crescenti per rendere questo rapporto sempre più stretto e proficuo.
Nonostante l’attuale grigiore che avvolge il panorama economico, diverse aziende pubbliche e private stanno intraprendendo un cambiamento paradigmatico nel modo di concepire la strategia aziendale, e quindi i processi che ne derivano. Si sta passando da una visione del mondo basata sul prodotto (catena: design-build-sell) ad una caratterizzata dalla centralità del cliente (catena: sell-redesign-rebuild). Tale transizione comporta, per la maggior parte delle aziende, modifiche strutturali ed organizzative sostanziali.
Mentre le start-up che sorgono dal nulla o per gemmazione da un’impresa esistente possono definire, volendo, la propria struttura direttamente in funzione del servizio al cliente, le aziende ormai affermate devono compiere sforzi notevoli per riallineare la struttura a tale visione. Anziché porsi domande del tipo “A chi vendere questo prodotto?”, la questione fondamentale diventa: “Che tipi di clienti abbiamo e che prodotti/servizi desiderano?”.
Nasce dunque in questo contesto la filosofia manageriale del Customer Relationship Management (CRM) che, in nuce, si occupa della personalizzazione di massa ovvero di identificare e connotare in modo univoco l’interazione tra chi vende e chi acquista, così che la fedeltà dei clienti – ed il valore aggiunto che ne deriva – aumentino nel tempo. In fondo è l’applicazione attuale di un vecchio “trucco” di vendita, la stessa strategia che adottavano i negozi sotto casa; l’unica “differenza” – e scusate se è poco – sta nelle dimensioni coinvolte: trattare migliaia (a volte milioni) di clienti come “individui”, e non come codici, rimane la croce e la delizia del CRM.
La domanda tuttavia è: in che modo celebrare il cliente, il singolo cliente? La transizione verso una struttura organizzativa CRM-compliant può provocare un’esplosione dei costi senza alcuna garanzia di un ROI (anzi, le percentuali di fallimento sono piuttosto alte), quindi disporre di una strategia ben ponderata e di una notevole visibilità sui processi interni e sul contesto concorrenziale esterno sono due elementi determinanti per avere successo o, almeno, per migliorare il livello di governance dei processi. Dato che tutti i clienti vanno dove sono “riconosciuti per nome”, si fa sempre più importante la disponibilità di una strategia multicanale ovvero la capacità offrire ai clienti varie opzioni per interagire con l’azienda. Il CRM richiede ben più che una struttura informativa statica: per sostanzialo è necessario sviluppare un sistema dinamico, che fornisca funzionalità operative e analitiche ad ampio spettro.
Il supporto del CRM avviene mediante una serie di applicazioni e di supporti documentali volti alla conoscenza del cliente e all’organizzazione delle informazioni derivanti dal suo rapporto con l’azienda. L’esigenza di informatizzare questi dati è nata verso la metà degli anni ’80, quando si cominciava a parlare di “soddisfazione del cliente” e di “integrazione tra marketing e vendite”. Allora vennero creati i primi moduli etichettabili come “sistemi CRM” che gestivano (a fatica, in realtà) il settore delle vendite. I risultati furono scoraggianti perché emersero problemi di comunicazione ed organizzazione con le reti di vendita che non riuscivano a monitorare la loro attività a causa della pluralità delle architetture e dei sistemi software eterogenei. Inoltre, questi primi esperimenti di CRM non affrontavano il rapporto con i processi organizzativi aziendali, che sono diventati oggetto di studio solo dalla fine degli anni ’80. Nei primi anni ’90 è stata data una risposta a questo tipo di esigenza con i sistemi ERP (Enterprise Resource Planning) di prima generazione, rivolti alle aziende di dimensioni o complessità organizzative notevoli. Le Suite ERP (così si chiamavano) erano in grado di facilitare lo scambio di dati e di informazioni tra i diversi comparti aziendali, ma non di interagire in modo fluido e controllato con l’esterno. Con l’affermazione di Internet migliorarono certamente le relazioni con i clienti, ma vennero a crearsi spesso, in una stessa azienda, due sistemi informativi differenziati, uno online e uno offline.
La Net Economy ha reso inadeguate le vecchie tecniche di Customer Relationship Management volte ad agire su un mercato di massa. Oggi Internet ha imposto un maggior flusso di comunicazioni che contribuisce a ridurre l’impatto di marketing dei messaggi generici, rivolti ad un pubblico indistinto. Proprio la facilità d’uso del mezzo incrementa le opportunità di cambiare fornitore: tra un’azienda e un’altra c’è solo la distanza di un click, perciò i consumatori sono più esigenti. Inoltre, i clienti vogliono poter scegliere tra diverse varianti dello stesso prodotto, visto che acquistano via Internet proprio per ordinare, direttamente a chi li produce, i beni e i servizi desiderati. Questi devono essere, quindi, personalizzati e, soprattutto, cambiare tempestivamente in funzione delle richieste del mercato.
I sistemi software di supporto del CRM hanno alcune caratteristiche principali e altre dipendenti dal tipo di azienda e dalla presenza di altri software gestionali, per esempio di Business Intelligence o di classe ERP. Le funzioni essenziali sono, da una parte, la raccolta dei dati sui clienti e la loro profilazione effettuata in base a criteri di segmentazione più o meno sofisticati ed utili al marketing; dall’altra, la fornitura di servizi di supporto sui prodotti tramite varie strutture socio-tecniche, come le cerchie, le chat, il co-browsing, la voice over IP, ecc. Le funzioni più evolute dei package CRM permettono di operare in modo “intelligente” sul flusso di comunicazione con i clienti, facendone una classificazione secondo gruppi più o meno omogenei o secondo modalità e consuetudini di acquisto. Molto importante è poi la rintracciabilità della storia dei singoli contatti, che permette di dare una risposta personalizzata al cliente. Sul fronte delle informazioni offerte risulta centrale il ruolo del sito aziendale, che può dare alcune risposte automatiche tramite email o più semplicemente tramite le FAQ. Anche i servizi di comunicazione tra clienti sono un servizio aggiuntivo da inserire nell’ambito del CRM. I dati che emergono dai forum, dalle chat e dalle mailing list sono di fondamentale importanza per capire le tendenze della domanda e i punti di criticità nella percezione dei prodotti da parte dei clienti.
Con l’avvento del web molte imprese hanno pensato di poter ridurre l’impegno dei call center, abbattendo (talvolta anche drasticamente), il numero degli addetti e ricorrendo a prodotti software standardizzati, ma nel tempo si è visto che le soluzioni precostituite davano risultati piuttosto parziali. Anche la gestione automatizzata delle e-mail, sia in house che in outsourcing, rende un servizio di qualità a volte scarsa. Internet rappresenta, infatti, solo un canale che deve essere personalizzato, reso il più possibile interattivo per risultare efficace e, soprattutto, essere integrato con le strutture preesistenti.
Uno degli obiettivi di questa integrazione è senza dubbio la realizzazione del mitico “one-to-one marketing”, una delle frontiere più sofisticate dell’approccio CRM, cioè la segmentazione dell’offerta di mercato in gruppi sempre più piccoli fino a raggiungere la soddisfazione del singolo cliente. Oggi gli strumenti informatici lo permettono, ma è ancora un’operazione troppo costosa e non sempre conveniente. L’one-to-one marketing rappresenta la fase più evoluta del CRM perché presuppone una corretta identificazione dei clienti dell’impresa, la classificazione in gruppi omogenei, lo sviluppo di sistemi di comunicazione interattiva con essi. Solo su questi presupposti si può innestare una vera e propria personalizzazione della relazione e dell’offerta di prodotti e servizi. L’obiettivo di un approccio di questo tipo è l’incremento della penetrazione sul singolo cliente e non l’acquisizione di nuovi clienti, che si raggiunge più facilmente con operazioni di mass marketing. Il motivo per cui c’è una certa resistenza ad attuare il marketing individuale non è tanto sull’efficacia, su cui non ci sono dubbi, quanto sulla difficoltà di quantificarne i benefici e, quindi, i relativi investimenti ammissibili. Un’azione di one-to-one CRM esprime i suoi effetti nel medio-lungo periodo perché agisce sulla fedeltà del cliente e quindi sui suoi acquisti nel tempo, piuttosto che su un aumento repentino del volume globale degli acquisti.
Nel corso dell’ultimo decennio la segmentazione si è articolata in fasce sempre più sottili, ma senza raggiungere il vero e proprio one-to-one marketing. Fanno eccezione i settori delle Telecomunicazioni e delle Banche, che più si sono avvantaggiati degli investimenti in CRM. Le difficoltà nello spingersi oltre nella segmentazione sono dovute ovviamente al numero elevato dei clienti e delle transazioni in gioco, ma anche ad ostacoli organizzativi interni alle imprese soprattutto quando si implementano diversi livelli di CRM gestiti da sistemi che acquisiscono dati senza interagire efficacemente.
Il CRM originario aveva due scopi principali: l’acquisizione di nuovi clienti, soprattutto nella fase di start up, e la fidelizzazione di quelli acquisiti, in corrispondenza di una fase più matura dell’impresa. Oggi gli applicativi di CRM perseguono obiettivi più complessi, anche perché l’ICT è un potente fattore abilitante. Si dice, infatti, che le aziende diventano sempre più “customer oriented”, ovvero si organizzano completamente intorno ai clienti: in funzione della domanda si imposta la produzione, sia in termini quantitativi che qualitativi. L’efficacia di una struttura di CRM si misura proprio sulla tempestività dell’azienda nel modificare il proprio assetto in funzione degli input che arrivano dall’esterno, soprattutto via Internet. L’offerta, dunque, si piega alle dinamiche della domanda e non viceversa. E’ un metodo efficace perché garantisce risposte più sicure anche se richiede investimenti importanti e una certa flessibilità della struttura organizzativa aziendale.
Lo scopo finale del CRM è quello di integrarsi con il Supply Chain Management (SCM), ovvero con la struttura interna della produzione e, a catena, con la rete dei fornitori. I dati provenienti dal CRM devono, infatti, essere sempre disponibili a tutti i settori dell’azienda interessati, oltre che al management. Per realizzare la perfetta condivisione delle informazioni con l’interno e/o l’esterno, le applicazioni di CRM sono costruite proprio per incapsulare e convogliare i dati tramite soluzioni di Data Management che consentono di analizzare i profili utente e di generare sistemi che adattano contenuti e interazioni sulla base dei profili-tipo individuati. Una delle tecniche più usate è il Data Mining, che elabora i dati correlati al cliente in modo da trarre azioni che permettano un reale orientamento al mercato, secondo modelli e regole statistiche. Ne esistono anche versioni avanzate (quali l’Advanced Customer Data Analysis, la Data Analysis, il Web Mining, ecc.) che formulano previsioni sul comportamento specifico del singolo cliente o del segmento di clientela. Un altro tipo di applicazioni sono quelle di Customer-Centric Data Warehousing, che realizzano basi di dati per l’integrazione e la storicizzazione dei dati aziendali sul cliente derivanti dai canali classici o dal canale web, integrando in un’unica struttura informativa tutte le informazioni raccolte. I Customer Reporting e i sistemi On-Line Analytical Processing (OLAP) descrivono, invece, il comportamento di aggregati di clienti, costruendo moduli di Query & Reporting e analisi multidimensionali.
Questi sistemi software, che rappresentano l’anima analitica del CRM, rientrano tutti nella super-classe della Business Intelligence; i più sofisticati consentono anche di attivare degli “alert” che richiamano l’attenzione su elementi che possono segnalare la presenza di situazioni critiche. Tutti devono poi integrarsi con gli applicativi gestionali (di tipo Best-of-Breed integrato o suite ERP), possibilmente della stessa famiglia o che almeno usino lo stesso tipo di database.
Secondo gli studiosi e gli analisti di Marketing, il CRM costituisce uno dei più importanti fattori critici di successo in ogni area di business. In effetti, ogni impresa riscontra oggi che è sempre più difficile competere sul piano dell’innovazione visto che le soluzioni, i programmi e le tecnologie sono tutto sommato clonabili e sovrapponibili nel tempo. Bisognerà, perciò, puntare sempre di più sulla relazione con i propri clienti attuali, una risorsa fondamentale e da “coltivare” con cura. Il modo di gestire la relazione e le informazioni che derivano da questo rapporto sono beni unici e non replicabili dai competitor. Inoltre, la crescita della massa informativa legata ad operazioni di marketing, alla maggiore di disponibilità di contenuti “editoriali” generati dai diversi media, così come allo sviluppo di nuovi canali di comunicazione, porterà necessariamente alla moltiplicazione e alla segmentazione delle esigenze dei consumatori.
Si è ribadito più volte che il CRM ha come obiettivo anche l’aumento della durata del rapporto con l’utente e il potenziamento del “valore” del cliente, ovvero della sua capacità di produrre maggiori entrate per l’impresa, rispondendo alle proposte di nuovi beni/servizi. Da diverso tempo ne stanno facendo uso soprattutto gli operatori di telefonia mobile, che hanno a disposizione uno strumento efficace di ricezione dei dati sui consumi – le SIM card – che registra continuamente le informazioni sull’uso dei servizi. La telefonia – e tutto ciò che c’è di inerente, afferente e consequenziale – ha lo straordinario vantaggio di poter avviare un canale diretto di comunicazione con il cliente (tramite contact center, sms, ecc.) che si va ad aggiungere al sito web. Il solo limite di questo genere di CRM è ovviamente la privacy, perché è difficile distinguere tra le informazioni che la società di telefonia raccoglie per uso interno da quelle che ledono il diritto alla riservatezza sulle informazioni sensibili. Il crescente bisogno dei reparti di marketing di elaborare promozioni e offerte sempre nuove farà aumentare la puntualizzazione delle registrazioni fino alla creazione di profili dinamici, realizzati in funzione dei cambiamenti dei consumi. Si può immaginare, dunque, quanto sia importante l’esigenza di sviluppare un marketing non invasivo, di tipo “permission based”, ideato come un servizio per il cliente, che deve, a sua volta, percepirlo come un valore aggiunto piuttosto che come un’intrusione.
Proprio come nel CRM realizzato con i mezzi tradizionali, come rete di venditori e call centre, il punto debole di ogni progetto di fidelizzazione è la qualità dei contenuti e del servizio. Non ha senso – anzi, ne ha uno negativo – aprire un canale di comunicazione con i clienti per poi non avere niente da dire o persino dire cose sbagliate. Con Internet il problema del controllo sulla qualità aumenta perché il flusso di informazioni è maggiore. Il rischio è quello di investire in infrastrutture e software per poi sbagliare il messaggio. Un altro errore possibile è di essere troppo concentrati sulla raccolta dei dati invece che sulla fornitura di un servizio aggiunto. Sono importanti sia la capacità di ascolto sia la tempestività delle risposte, ma uno degli ostacoli più diffusi nella realizzazione di progetti di supporto del CRM si rileva nelle risorse umane. Molto spesso, infatti, gli applicativi devono essere usati da esperti dei reparti marketing e vendite che non hanno le competenze tecniche e informatiche necessarie a sfruttarne in pieno le potenzialità. Una risposta può venire dall’outsourcing: sono moltissime, infatti, le aziende che offrono servizi di CRM come la raccolta delle domande dai clienti (consigli, lamentele e segnalazioni varie), l’organizzazione delle risposte standard, le campagne speciali di informazione tramite mailing list, l’assistenza, l’invio di documentazione, la gestione servizi personalizzata, ecc. E’ anche possibile misurare il feedback su azioni specifiche, valutarne subito il ritorno, con opportunità di retroazione rapida.
Per concludere, non resta che ribadire che la carenza di buone relazioni con i clienti ha un impatto fortemente negativo sui risultati aziendali. I cicli di vendita e quelli decisionali risultano prolungati; le frizioni che si determinano lungo la supply chain riducono il livello di soddisfazione dei clienti e minacciano il processo di fidelizzazione, due minacce che, nell’attuale quadro economico, sono assolutamente da stigmatizzare e contrastare.
Mentre un tempo era impensabile personalizzare le strategie di marketing e di vendita dei propri prodotti nei confronti di ogni singolo cliente, oggi gli strumenti di supporto del CRM offrono in tal senso nuove opzioni e opportunità.
Diversi sono i vantaggi competitivi che i sistemi CRM possono realizzare. In termini di valore finanziario, la gestione del rapporto con il cliente favorisce un aumento delle entrate per cliente e sostanziali miglioramenti in termini di produttività. A livello organizzativo, le applicazioni CRM contribuiscono ai processi aziendali associando i servizi e il supporto post-vendita alle operazioni di vendita e marketing. Per quanto concerne le vendite, l’implementazione di un sistema CRM consente a chi lo adotta di presentare ai propri clienti un’offerta personalizzata.
Infine, in termini di posizionamento sul mercato, forniscono alle aziende un significativo elemento di differenziazione e un indiscusso vantaggio competitivo.
di Gian Franco Stucchi
Un Caffè Sospeso da gustare, insieme a Gian Franco Stucchi, in un tour guidato tra i business object alla ricerca di qualche certezza in un mondo in perenne formazione
Non è mai esistito, nella breve ma tumultuosa storia delle tecnologie dell’informazione, un momento come quello attuale caratterizzato dalla concentrazione di una molteplicità di condizioni estremamente favorevoli per l’attuazione di un mutamento paradigmatico nello sviluppo del software applicativo.
Le metodologie, le architetture, gli indirizzi strategici, le visioni tecnologiche e gli approcci organizzativi stanno confluendo in un unico punto virtuale, nel quale si accumulano ed interagiscono creando fenomeni di risonanza e pervasività. La tecnologia degli oggetti (OT), le architetture distribuite, i database multidimensionali, i sistemi OLAP (On Line Analytical Processing) e la ripatizione delle applicazioni e dei dati sono solo alcuni degli indirizzi tecnici emergenti.
Le direzioni funzionali lungo le quali si articola lo sviluppo dei sistemi economici e sociali evidenziano una tendenza alla focalizzazione degli obiettivi strategici su pochi elementi chiave, all’appiattimento delle strutture, all’eliminazione delle barriere burocratiche, ed enfatizzano le comunicazioni tra varie entità, le attività svolte in collaborazione ed operanti secondo una logica globale di tipo pull (trainata dal mercato), sostitutiva della precedente di tipo push (spinta dall’interno).
Uno dei concetti più significativi, dal punto di vista dello sviluppo del software applicativo, è quello di business object (BO), particolarizzazione dell’idea di “oggetto” ed elemento costruttivo fondamentale delle nuove soluzioni applicative gestionali. Il vantaggio principale dei BO consiste nella riduzione del grado di difficoltà insito nella modellizzazione dei processi di business e nella possibilità di creazione di un alveo favorevole ad una transizione, uniforme e non traumatica, dal modello concettuale astratto dell’entità o del processo in esame alla sua implementazione fisica.
Il termine “oggetto” vaga da molto tempo nel mondo delle tecnologie dell’informazione ma solo recentemente è uscito dagli ambienti di nicchia, collocandosi nel cosiddetto mainstream tecnologico. Anch’esso, come il termine “sistema”, è inflazionato e logorato dall’uso improprio che spesso ne viene fatto dalla letteratura più o meno specialistica e dal marketing di talune case produttrici.
L’idea fondamentale dell’OT, dal punto di vista dello sviluppatore, consiste nella rappresentazione di un’entità reale con un oggetto, cioè con un unico modulo software – sicuro, robusto, compatto ed autoconsistente – che incapsula sia lo stato di un’entità (i dati) sia i suoi possibili comportamenti (i metodi). Non tutti gli oggetti hanno lo stesso scopo: per progettare le applicazioni gestionali, gli oggetti possono essere divisi in due categorie: gli application object ed i business object.
Un application object è un oggetto che realizza una generica infrastruttura di programmazione e viene utilizzato per costruire il substrato operativo di una soluzione applicativa. In questa classe rientrano, ad esempio, gli oggetti impiegati per la creazione delle interfacce grafiche, per l’esecuzione delle funzioni di ordinamento o di sequenzializzazione delle informazioni, per la realizzazione delle applicazioni query SQL, etc.
Un business object è la rappresentazione di un elemento di rilevanza aziendale e costituisce, come tale, una cristallizzazione di un frammento della conoscenza aziendale. Una working definition derivata da quelle proposte dal BOMSIG (Business Object Management Special Interest Group) dell’OMG (Object Management Group, un consorzio al quale appartengono diverse centinaia di imprese IT) è la seguente:
“Un BO è la rappresentazione di un’entità di business attiva ed è costituito, almeno, da un nome, da una definizione e da un insieme di attributi, comportamenti, relazioni e vincoli. Un BO può rappresentare, per esempio, una persona, un luogo, un concetto. La descrizione di un BO può essere espressa in un linguaggio naturale, in un linguaggio formale di modellizzazione o in un linguaggio di programmazione.”
Secondo questa definizione, tipici BO sono i clienti, i fornitori, gli ordini, le fatture, i prodotti, i magazzini, i cespiti, etc. Le mutue interazioni tra i BO, innescate da eventi con una significatività aziendale, compongono i processi che modellano il sistema impresa (gestione degli ordini, fatturazione, carico a magazzino, gestione dei cespiti, gestione dei flussi di cassa, etc). Le entità che originano i BO sono le funzionalità richieste in azienda, le relazioni tra queste, i processi di business e gli eventi.
Un BO può essere concepito come un blocco rappresentativo di funzionalità applicative che viene dislocato ed utilizzato in contesti differenti – sia come elemento indipendente, sia in congiunzione con altri BO – per fornire servizi informativi agli utenti. Le funzionalità applicative in un’azienda possono essere generate da varie fonti, ma assumono due nature: sono tangibili, ovvero sostenute e documentate da un medium dotato di consistenza fisica (le informazioni cartacee o elettroniche), o intangibili, cioè si stabiliscono tra le varie entità aziendali solo per il fatto che queste emergono ed interagiscono nello svolgimento dei processi.
Le funzionalità tangibili sono tali proprio perché sono state individuate con precisione e rappresentate, tramite un mezzo fisico univocamente accettato, sia in modo formale sia in modo informale. Esse si riferiscono ad attività che, di norma, sono di tipo operativo e a questa categoria si possono far risalire, per esempio, gli ordini di acquisto o di vendita, i resoconti finanziari, le fatture, le comunicazioni interne, la posta (elettronica o cartacea) in arrivo o in partenza, etc. Le funzionalità intangibili sono più sottili e delicate poiché, spesso, sono relative a processi e relazioni essenziali per la sopravvivenza e la competitività dell’azienda (le cosiddette attività mission-critical).
Per quanto concerne le altre due entità generatrici di BO, si osservi che i processi riguardano tutta la gestione aziendale, coinvolgendo gli ordini, le vendite, la produzione, il controllo della qualità, le transazioni finanziarie, la logistica in entrata ed in uscita, etc.; le relazioni emergono naturalmente poiché l’azienda, in quanto sistema economico-sociale aperto e comunicante, stimola la nascita di interazioni tra le risorse umane, i clienti, la forza commerciale, etc.
I BO possono essere costruiti anche intorno agli eventi più significativi della vita aziendale, quali: la chiusura mensile o annuale dei conti, il lancio di una nuova campagna di marketing, l’attivazione di una particolare linea di credito, etc. In questo caso essi non rappresentano funzionalità o processi o relazioni, bensì avvenimenti, talvolta eccezionali, ritenuti di rilevanza essenziale per la gestione aziendale.
Qualunque entità rappresentino, i BO sono, dal punto di vista dello sviluppatore, delle strutture informative che incapsulano in un modulo software le regole e le relazioni che intervengono nei processi aziendali: le regole determinano i comportamenti degli oggetti nel loro contesto ambientale (di business); le relazioni (anche conflittuali) si originano in funzione dell’interazione di un oggetto con le entità ambientali (altri oggetti o utenti o eventi) e stabiliscono le potenzialità dell’oggetto.
Lo studio dei BO, esaurita la componente definitoria, può concentrarsi su un insieme di caratteristiche, la composizione del quale è molto varia in funzione del grado di approfondimento dell’analisi e del retroterra culturale dell’analista. In questa trattazione si considerano quattro proprietà – da intendersi come “cardinali”, cioè fondamentali per lo studio successivo – che, data la loro immediatezza, possono contribuire ad illuminare il neofita nella comprensione dei BO.
Una delle caratteristiche principali di un oggetto, che riguarda la sua composizione, è il grado di granularità, una valutazione dell’articolazione strutturale interna che può assumere almeno tre valori crescenti: componente, contenitore o composito (o composto).
Un oggetto è detto componente quando si ritiene che possa essere utilizzato nella costruzione di un altro BO (questo concetto è simile a quello di subroutine utilizzato in programmazione). Gli oggetti componenti non sono necessariamente oggetti banali: essi possono spaziare dal semplice calcolo di uno sconto per quantità ad una procedura di controllo del credito per giungere sino ad un’analisi di profittabilità realizzata con sofisticati metodi matematici. Il tratto distintivo principale di un oggetto componente è la sua transitorietà: essi sono attivati da un input, lo elaborano, producono un output e si riportano in uno stato di quiescenza. Ne discende che il contributo che apportano alla conoscenza dei problemi aziendali è frutto solo del periodo di attività del comportamento dell’oggetto.
Un oggetto contenitore avvolge, gestisce e contiene altri BO ed è, dunque, un tipo di oggetto appartenente ad una categoria di complessità superiore alla precedente, poiché incapsula in sé almeno la somma delle conoscenze degli oggetti contenuti incrementata di un’ulteriore quota dovuta alle modalità di interazione e di gestione dei componenti. Un buon esempio di un oggetto contenitore è costituito dai documenti composti da testi, grafici, tabelle di calcolo, immagini e suoni, quali sono i compound document resi disponibili dai maggiori produttori di software. A rigor di termini, un contenitore non è un vero BO poiché il suo scopo consiste nell’armonizzazione di una complesso di oggetti, coordinandone i comportamenti ma prescindendo dal contesto (si veda nel seguito il significato di questo termine). Questo non significa che non sia possibile costruire delle applicazioni, anche potenti, tramite i contenitori ma che la responsabilità della comprensione del contesto implicato dall’oggetto è demandata all’utente.
Gli oggetti compositi sono l’espressione più alta della granularità e costituiscono gli esempi più emblematici della categoria dei BO. Un oggetto di questa specie è costituito da componenti, contenitori e da una certa quota di intelligence che rendono la combinazione molto più potente ed espressiva della semplice “addizione” delle parti. Si ottiene un fenomeno sinergico simile a quello di certe leghe metallurgiche, che presentano delle caratteristiche fisiche e chimiche notevolmente superiori alla semplice combinazione lineare di quelle corrispondenti dei materiali elementari.
La seconda caratteristica dei BO, precedentemente accennata ma lasciata all’interpretazione intuitiva, è quella del contesto. Con questo termine si intende la posizione di un oggetto in un processo di business oppure il ruolo che esso gioca nella costruzione di un BO contenitore. Ben pochi BO hanno una significatività in uno stato di perfetto isolamento ambientale: essi, non avendo alcuna rilevanza agli effetti dei processi aziendali, sarebbero completamente inutili e la loro esistenza risulterebbe ingiustificata. Talvolta questa singolarità esistenziale potrebbe essere addirittura dannosa poiché contribuirebbero ad aumentare il “rumore ambientale”: l’esistenza di un BO è giustificata solo nel contesto di un processo ed in relazione con gli altri BO che vi partecipano.
I BO, come tutte le entità rappresentative dei fenomeni reali, sono dotati di un’altra caratteristica inalienabile: il ciclo di vita. Una volta creato, un BO inizia il suo ciclo vitale cambiando il proprio stato ed è importante comprendere le implicazioni di questa evoluzione, poiché ogni transizione può innescare degli eventi che influenzano sia l’oggetto sia stesso sia quelli a questo correlati nei processi di business.
L’ingresso dell’OT nel mainstream tecnologico ha creato molte aspettative da parte del mercato, sostenute ed attivate dai “boatos” di marketing. In realtà, pur essendo l’OT una disciplina che data dal lontano 1967, con la definizione del linguaggio Simula, molto spesso i conclamati “plug-and-play” si trasformano in strazianti “plug-and-pray” (dopo essere transitati, tutti, nello stato “plug-and-pay”). Queste delusioni sono originate, soprattutto, dalla superficialità degli approcci adottati per attualizzare il paradigma proposto dall’OT in una certa realtà aziendale, spesso caratterizzata da una cultura d’impresa inadeguata all’innesto tecnologico. Nonostante ciò, l’OT non è l’ennesimo sogno di visionari, bensì una mondo in creazione e consolidamento intorno ad un nucleo di concetti, di proposte e di soluzioni standard che agiscono da catalizzatori per l’interoperabilità.
Dal punto di vista commerciale, l’OT viene ampiamente utilizzata, da molti anni, in diversi settori ed in primo luogo quelli di natura strettamente tecnologica. Sono molti, infatti, i moduli appartenenti alla categoria del software di base o dei tool di sviluppo avanzati (CASE, CAD, CAM, CAE, Sistemi Operativi) concepiti e realizzati impiegando l’OT. I BO, in particolare, possono trovare vasti campi d’applicazione nella creazione di sistemi software complessi, realizzando in tal modo i concetti dell’attuale corrente filosofica imperante nel mondo dello sviluppo applicativo: la composizione per parti (o per componenti) del software. I BO si propongono, infatti, come candidati ideali per lo sviluppo di applicazioni wrapper atte a recuperare, in ottica OT, i sistemi software sviluppati in passato (i legacy system). Essi, inoltre, possono essere utilizzati per la costruzione di “mini-applicazioni” autoconsistenti (simili alle app diffusissime nel mondo del Mobile Computing) destinate ad operare singolarmente o in armonia con altri moduli software.
Un altro impiego dei BO può essere individuato nella costruzione di librerie di classi, una sorta di collezione di “matrici software” alla quale attingere per costruire oggetti complessi grazie alle trasformazioni di generalizzazione o specializzazione. Questi oggetti-archetipo, acquistati o costruiti e perfezionati nel tempo, diventeranno presumibilmente un asset aziendale, poiché, se adeguatamente ingegnerizzati, si propongono come gli elementi portanti per il consolidamento del patrimonio di conoscenze dell’impresa, la vera arma competitiva con valenza strategica del futuro.
Affinché possano campionare in modo adeguato la realtà, i BO però devono possedere alcune caratteristiche fondamentali in termini di generalità e di sicurezza.
Innazitutto i BO sono delle entità condivise da una notevole quantità di applicazioni eterogenee e da una molteplicità di utenti con esigenze informative diverse. Per esempio, un oggetto che rappresenta un ordine di vendita è un’entità interessante per vari dipartimenti aziendali, quali l’area delle vendite, la produzione, il marketing, l’amministrazione. E’ facile immaginare, dunque, che la descrizione dell’oggetto, consolidata nella classe dalla quale questo deriva, debba essere estremamente esaustiva per rappresentare tutti gli aspetti organizzativi indotti dai vari processi di business.
Appunto perché sono entità condivise – e, spesso, vitali per l’azienda – sia i BO stessi sia l’ambiente operativo che li sostiene devono essere garantiti da un adeguato meccanismo di sicurezza, articolato su vari livelli. Si rendono necessari, per esempio: degli schemi di autenticazione e di autorizzazione; dei meccanismi di controllo delle versioni; dei sistemi di firewall anti-intrusione, sia questa accidentale o intenzionale; un ambiente operativo fault tolerant generalizzato e coerente tra le varie piattaforme applicative; un tool di system management sofisticato e sensibile che sappia intercettare in tempo utile tutte le anomalie e reagire in maniera anticipatoria.
Dal “brodo primordiale” dell’OT stanno emergendo forme di vita superiore. Affinché questo sforzo evolutivo abbia successo, esso deve essere sostenuto e protetto da tutti gli attori che interpretano un ruolo decisivo sul mercato delle tecnologie dell’informazione. Utenti, sviluppatori e case produttrici devono partecipare congiuntamente allo sviluppo dell’OT, coagulando l’interesse e gli indirizzi di ricerca e sviluppo intorno alla definizione ed alla realizzazione di standard terminologici, concettuali ed operativi che consentano la massima interoperabilità – o meglio, la massima interscambiabilità – tra i prodotti e le soluzioni applicative. Questa è una questione vitale per ogni evoluzione tecnologica: le imprese sono oberate da problemi di business e mostrano una crescente insofferenza nei confronti di tecnologie che, pur proclamandosi innovative, producono, in realtà, un incremento della complessità dei problemi piuttosto che contribuire alla realizzazione efficiente dei processi di business.
Gian Franco Stucchi