martedì 30 gennaio 2007
Revisione ICT: Architettura del Sistema
Da una parte occorre saper cogliere dal Top Management la direzione del business affinchè il sistema che si proporrà sia coerente con queste scelte.
Dall'altra parte i parametri da considerare sono veramente numerosi.
Si può cominciare con la definizione di standard e di regole che poi man mano che il disegno si compone possono variare anche sostanzialmente.
Attenzione alle procedure interne: piuttosto poche ma chiare.
Identificare i partner esterni che supporteranno il progetto.
venerdì 26 gennaio 2007
Revisione ICT: sistemi e reti
Vorrei segnalare la presenza, nella mia lista, di un inventario particolare: quello delle "conoscenze".
A me è stato utile avendo a che fare con personale che sta dall'altra parte dell'oceano che ho l'occasione di vedere di persona piuttosto raramente.
Per il resto, hardware, reti, contratti, consulenti, tutto va identificato per avere un quadro reale e consapevole della struttura fisica.
Si stanno disponendo i "pezzi" nella scacchiera, prima di decidere una strategia.
Gli inventari possono essere predisposti con interventi diretti o quando possibile con procedure di discovery automatica dei sistemi.
Processo di Revisione ICT
Ho cercato di razionalizzare e definire il processo che ho applicato e nei prossimi giorni cercherò di dettagliarlo.
In questa prima diapositiva ho riepilogato il flusso complessivo.
L'input del processo è fornito dai risultati di due precedenti processi:
- Revisione Organizzazione
- Revisione dei processi di business e amministrativi
Le attività delineate sono in sequenza:
- Analisi dei sistemi e delle reti
- Analisi delle applicazioni software
- Progetto architettura di sistema
- Piano di implementazione
- Realizzazione
- Mantenimento.
Dopo il progetto dell'architettura è previsto un feedback per valutare possibili effetti sui processi a monte già definiti.
Nei prossimi post analizzerò una per volta le sei attività elencate.
giovedì 25 gennaio 2007
make-or-buy (3)
Parte 3
Fattore | TO BUY | TO MAKE |
Personalizzazioni | E’ disponibile il codice sorgente? Che tipo di documentazione viene rilasciata? | Quanto è produttivo e vantaggioso in una visione globale, realizzare tutte le personalizzazioni richieste dai key-users? |
Rischi | Storia e stabilità economica/finanziaria del fornitore? Disponibilità a condivisione del rischio di progetto? | Valutare rischi sulla data di consegna del prodotto, sulla reale aderenza alle specifiche, sui reali costi |
Esperienza | Maturità del prodotto? Base installata? | Competenze |
Vantaggi strategici | Il fornitore partner si configura come un partner in grado di aggiungere valore? | Quali specifiche flessibilità si ottengono rispetto all’acquisto? |
martedì 23 gennaio 2007
make-or-buy (2)
Addestramento utenti, Manutenzione, Costi, adesione a specifiche aziendali, Supporto.
Parte 2
Fattore | TO BUY | TO MAKE |
Addestramento utenti | Impatto notevole sia per durata che per efficacia. | Progressivo con i rilasci. |
Manutenzione correttiva ed evolutiva dell’applicazione | Per tutto il ciclo di vita del prodotto rimane su valori significativi. Le evoluzioni decise dal fornitore diventano patrimonio standard, ma quelle considerate “customer” sono a carico del cliente. | Dopo lo sviluppo il team di lavoro rappresenta un eccesso di risorse (parte del tempo lavorativo viene impiegata per la manutenzione e supporto). |
Costi | Caratterizzati da licenze d’uso, manutenzione, consulenze per realizzazione delle gap. | Caratterizzati dal costo del personale. |
Adesione a specifiche aziendali | C’è un prodotto con una buona aderenza?. Valutare quantità e profondità delle personalizzazioni. | Ci sono le competenze tecnico-aziendali? |
Supporto | Da considerare come parte integrante degli SLA da sottoscrivere: valutare costo in rapporto allo sviluppo, lingua, organizzazione, copertura | Può essere problematico distinguere e pianificare fra risorse adibite allo sviluppo e supporto. |
lunedì 22 gennaio 2007
make-or-buy (1)
The ‘make-or-buy’ dilemma...
Fare la scelta fra produrre in-casa o usare un fornitore esterno.
Poichè i fattori considerati sono molti li elencherò divisi in tre parti.
La tabella, lungi dall'essere esaustiva, contiene soprattutto le considerazioni che mi sono appuntato col trascorrere del tempo.
Comincio considerando i seguenti fattori: dipendenza, formazione, tempi di sviluppo, impatto organizzativo, funzionalità.
Parte 1
Fattore | TO BUY | TO MAKE |
Dipendenza | Forte dipendenza dal fornitore, salvo che per quei prodotti di grande diffusione dove le figure di produttore e implementatore sono distinte. | Forte dipendenza dal personale interno (necessario creare ridondanze nei ruoli chiave, distribuire la conoscenza; adottare metodologie standard nel gruppo di lavoro). | ||
Formazione tecnica | Non necessaria o non strategica | Urgente e fondamentale. | ||
Tempi di sviluppo | Medio-brevi (da 1 a 2 anni) | Medio-lunghi (da 3 a 5 anni) | ||
Impatto organizzativo | Notevole. | Progressivo. | ||
Funzionalità dell’applicazione | Si ereditano tutte quelle sviluppate nel pacchetto inclusi gli aggiornamenti futuri. Parte delle quali sono però inutili e complicano l’uso del prodotto. | Tagliate su misura. Possibili Difficoltà a individuare gli elementi fondamentali (non abitudine ad analisi approfondite e complete cioè a fornire definizioni stabili e prive di ambiguità degli input, degli output e delle regole e/o modalità di elaborazione). |
giovedì 18 gennaio 2007
Valorizzare le gap
Mi riferisco alla attività di identificazione delle differenze fra prodotto offerto e necessità espresse, eseguita durante l'analisi di software cosìdetti "verticali".
Sono applicativi che in buona parte hanno notevoli analogie con i processi interni alla società, perchè sviluppati su specifiche di clienti che operano nello stesso settore e con analisti che provengono dal business.
Quando si organizzano delle "demo" difficilmente si riesce a focalizzare tutte le piccole differenze che esistono fra la propria modalità di operare e quella del software sotto analisi.
Ci sono due modi per risolvere il problema, più un terzo che è una non-soluzione.
Il primo è adattarsi ai flussi di processo proposti. I software più evoluti permettono di "cablare" anche la modalità di esecuzione dei processi, ma fino ad un certo punto.
Se si valuta che la situazione è tale da risultare accettabile "adattarsi", allora lo sforzo e i tempi per andare a regime e la stabilità del software ne beneficeranno notevolmente. Si godranno i benefici in tempi brevi.
Il secondo approccio, purtoppo è il più diffuso ed è letale. Consiste nell'affrontare le "differenze" man mano che vengono in evidenza. Tipicamente questo avviene durante le fasi di training, test e addirittura in produzione. Ammesso che si riesca ad uscirne "vivi", il prezzo pagato sarà altissimo.
Infine l'approccio consapevole: Le gap non sono un intralcio! Sono un patrimonio aziendale che qualche volta caratterizza l'azienda sul mercato, rispetto alla concorrenza.
Valutare seriamente se e quando si può rinunciarci e quando no.
Legale, normativo | Es.: I software progettati fuori Italia, spesso sottovalutano le problematiche IVA in fatturazione e i Cespiti. Le gap di questo tipo vanno sempre appianate, per ovvi motivi di conformità. |
Funzionalità/Moduli | Il software mette a disposizione un portafoglio di funzioni. Confrontare e verificare quelle in eccedenza (sono un serbatoio per il futuro ma anche un appesantimento non necessario) e quelle mancanti, da aggiungere secondo piani prestabiliti. |
Personalizzazioni Aziendali | Con questo termine intendo evidenziare che all'interno di un modulo funzionale, possono esserci modalità di esecuzione delle attività diverse. Non basta verificare che il software gestisce, per esempio, i trasporti terrestri, o la fatturazione, bisogna identificare le modalità con cui le gestisce e valutare caso per caso. |
Data Entry/Reportistica | Sono quelle modifiche che incidono sulla presentazione dei dati a video e su carta. Tralasciando i "vezzi" ai quali qualche key-user non vuole rinunciare, è importante valutare se esistono Layout particolari a cui il mercato locale è abituato, o sui quali la direzione aziendale è focalizzata, se sono possibili semplificazioni nei forms di input, o presentazioni di report più efficaci. |
mercoledì 17 gennaio 2007
Impatto organizzativo
Centralizzazione di funzioni | Alcuni processi si modificano sostanzialmente, valutare la sequenza, i tempi, le responsabilità. A titolo di esempio: l'approvazione tariffe/quotazioni, la gestione dei contratti, il popolamento delle tabelle clienti e fornitori |
Interfacce con la catena del mercato | Occorre valutare la maturità informatica nei paesi coinvolti per accertarsi che , non solo le Agenzie Marittime, ma anche Spedizionieri, Trasportatori, Terminal, Depositi…siano pronti a cambiare la modalità di comunicare le informazioni. |
Assistenza e help desk | In base ai Paesi coinvolti, occorre valutare la problematica legata alla lingua e la copertura dei servizi dovuta ai diversi fusi orari. |
Disponibilità dei sistemi informatici | Il periodo di indisponibilità del sistema per esecuzione di backup o aggiornamenti viene drasticamente ridotto. Valutare se l' architettura del sistema permette di pianificare interventi a sistema attivo. Valutare il numero e la preparazione delle risorse umane necessarie a gestire il sistema. |
martedì 16 gennaio 2007
Come ho fatto a non pensarci?
In questi casi viene da dire: "Eppure ero concentrato sull'argomento, stavo valutando tutte le informazioni in mio possesso".
Così sembrava.
Ma così capita, proprio perchè si è troppo focalizzati su un singolo compito, perdendo di vista altre informazioni, laterali, estremamente importanti.
Manca consapevolezza, o meglio la consapevolezza è confinata in un raggio ristretto.
E' troppo semplice dire che occorre aumentare la consapevolezza. Come si fa?
Ho trovato questi consigli in una rivista di informatica. Ma occorre aggiungere qualche commento.
- Sapere quello che si vuole
- Ragionare con un’ottica da ‘avvocato del diavolo’ .
- Considerare le cose in una prospettiva distaccata, da ‘outsider’ .
- Imparare a pensare in un’ ottica complessiva. Sovrastimare l’importanza di un’area di problemi può portare a sottovalutare importanti informazioni in un’altra area.
- Agire sempre con la certezza che l’informazione che state cercando esiste davvero.
- Fare della condivisione delle informazioni una norma.
Il primo consiglio non è da liquidare, dicendo "logico!". Ci sono situazioni complesse in cui in realtà non è banale sapere cosa si vuole. Occorre fermarsi, fare un punto con se stessi e capire cosa veramente si vuole.
Il secondo consiglio è da capire. Intanto chi è "l'avvocato del diavolo?". E' una espressione che deriva dalle cause di santità ecclesiali. Come in tutti i processi c'è un avvocato a favore che cerca di dimostrare la santità della persona e un'altro che cerca prove ed argomenti contrari. Quest'ultimo viene detto bonariamente "avvocato del diavolo". Può essere utile fare con se stessi l’avvocato del diavolo.
Ci sono riunioni nelle quali, troppo spesso si finisce per utilizzare solo le informazioni disponibili finendo per concordare sugli stessi punti. L’avvocato del diavolo deve invece chiedere “Quale informazione di cui abbiamo bisogno non abbiamo? Quale informazioni possiamo avere che non stiamo usando?” Cosa possiamo sapere che non stiamo condividendo?”.
Andando avanti, il terzo punto è fondamentale. Non essere troppo coinvolti emotivamente è essenziale per mantenere lucidità.
E poi, ancora: allargare il proprio orizzonte per avere una visione ampia, è come salire su un elicottero e sorvolare una zona, si hanno informazioni aggiuntive che dal suolo non si possono ricavare. Cambia la prospettiva. Entrando nel tuo ufficio, qualche volta, prova sederti nella sedia dell'ospite. Non avverti subito che la visuale è diversa?
Al penultimo punto, si fa un'affermazione categorica. L'informazione che si cerca c'è sempre. Di sicuro non vuol dire che a tutto c'è una risposta, o che tutto si può fare. Mi sembra che piuttosto faccia leva su un atteggiamento positivo nei confronti dell'analisi in corso.
E infine, si chiude con un consiglio che per tanti è duro da digerire. Non voler fare tutto da soli. C O N D I V I D E R E. Richiede una grande maturità e fiducia in se stessi.
lunedì 15 gennaio 2007
Le 3i
C'è già uno slogan delle "tre i": investimenti, innovazione, informatica.
Ne propongo un'altro che in comune col precedente ha solo un termine.
Tre sono i punti di forza su cui fare leva per potenziare la capacità imprenditoriale attraverso una visione strategica dell’ICT.
A volte il punto di partenza è un software generalista che viene personalizzato sulle esigenze dell'azienda, a volte è un pacchetto verticale che amplia il suo raggio d'azione coinvolgendo tutti i processi del business. Di fatto i fornitori di applicazioni hanno capit che occorre sfruttare maturità e forza dell'approccio ERP, per processi.
Ma anche la capacità di stabilire condivisione di obiettivi fra management e di potenziare l’interattività con sistemi informatici.
Quindi alla fine sarebbero le 5i...
venerdì 12 gennaio 2007
Valutazione costi-benefici
Personalmente non credo molto all'assegnazione di un "peso" ad ognuno di essi per ottenere una classifica lineare. Infatti molte valutazioni sono inevitabilmente soggettive e la scala è arbitraria. Quello che succede è che si tende ad "aggiustare" i risultati parziali in modo da ottenere quello che si ha in testa. Allora, meglio essere più trasparenti.
Nella tabella che segue ho inserito alcuni elementi che io prendo in considerazione.
Dipendenza dal fornitore | Formazione tecnica necessaria |
Tempi di sviluppo includendo la fase di rodaggio | Impatto organizzativo, sia nella sede centrale che in periferia |
Funzionalità dell’applicazione: valutando anche quelle in eccesso rispetto alle esigenze | Addestramento utenti e incluso piano di esecuzione e post addestramento |
Manutenzione correttiva ed evolutiva dell’applicazione | Costi |
Adesione a specifiche aziendali e di coseguenza valutazione del gap | Supporto tecnico e per utilizzatori, tempistiche e SLA. |
Personalizzazioni e loro impatto sull'applicazione | Rischi connessi al cambiamento e contromisure ipotizzabili |
Esperienza del fornitore nel campo specifico, costo della sua eventuale formazione | Vantaggi strategici ottenibili con l'introduzione del software |
mercoledì 10 gennaio 2007
La mancanza di strategie
- Spreco di investimenti
[Fonte: uno studio di Forrester Research (2002) dal titolo ‘Naked Technology’condotto su oltre 3000 aziende].
- Disillusione
- Disillusione dei vertici aziendali.
- Forte calo della credibilità IT.
- Scarsa considerazione dei vendor Hw e Sw.
- Le motivazioni
- Perché si insiste nell’errore
Perché ripensare e riorganizzare il modo di lavorare e la struttura organizzativa non è cosa facile.
L’IT da sola non cambia assolutamente, né i processi di business, né l’organizzazione del lavoro.
- In sintesi
...e andare al mare.
- Cosa fare
Assicurarsi un approccio collaborativo fra linee di business e IT.
martedì 9 gennaio 2007
La mia esperienza - parte 4
Anni 2004 - in corso
Con l'inizio della mia collaborazione in CCL, mi venivo a trovare, improvvisamente, in una situazione opposta rispetto a quanto avevo appena vissuto in Italia di Navigazione. Passavo da un'azienda che veniva venduta ad una che stava comprando. Costa Container Lines aveva infatti appena ratificato l'acccordo per l'aquisizione di Grandi Traghetti Gilnavi dalla Grimaldi Holding.
L'esperienza "subita" nel periodo di passaggio delle consegne da Italia Navigazione a CP Ships, era un chiaro esempio di mancanza di ascolto del nuovo management, di sistematico disinteresse per le esperienze e competenze maturate, di atteggiamento di arroganza professionale e difesa di un potere.
Credo che tutto questo mi abbia permesso di evitare qualche errore, dedicando, spero, la giusta attenzione all'integrazione delle forze umane a disposizione, e ad una valutazione il più possibile oggettiva degli strumenti a disposizione.
Evidentemente il nucleo principale è stato lavorare intorno alla integrazione dei flussi informativi di due differenti strutture organizzative (sistemi - reti – applicazioni – standard) pianificando le attività e differenziando le scelte in modo da non penalizzare la produttività e favorire l'emergere delle migliori risorse.
Aggiungo che la struttura di CCL, caratterizzata da un numero consistente di agenzie marittime controllate direttamente richiedeva anche una decisa politica di Standardizzazione delle pratiche ICT in ognuna delle organizzazioni controllate.
Infine, per guardare al futuro, è stata avviata da subito una profonda analisi delle offerte off-the-shelf del mercato ITC e parallelamente una valutazione del make-or-buy.
Un lavoro molto analitico e zelante che ha portato a una più che discreta conoscenza dei migliori pacchetti verticali offerti dal mercato per le aziende di trasporto marittimo.
Ad una crescita della consapevolezza di qual è l’impatto Organizzativo dovuto all'introduzione di un software centralizzato con architettura web-based.
Ad una parallela presa di coscienza del Valore delle Gap, come patrimonio aziendale, da non disperdere in un software "pronto all'uso".
Ad una accurata e pragmatica valutazione dei costi/benefici.
lunedì 8 gennaio 2007
La mia esperienza - parte 3
Anni 1999 - 2003
In questo caso fu possibile un approccio alla progettazione del Sistema Informativo più vicino alle teorie indicate nei manuali.
La privatizzazione della società Italia di Navigazione, mi permise di partire da un documento di analisi condotto da un importante Consulting che descriveva una "Diagnosi dei processi aziendali operativi, di controllo e dei sistemi informatici".
Partendo da una "Descrizione dei processi", si soffermava sulle "Principali criticità" e terminava con una serie di "Suggerimenti".
Le aree analizzate coprivano soprattutto:
- Ciclo dei ricavi
- Ciclo dei costi
- Tecnologie informatiche
- Controllo e andamento gestionale
Dovrebbe risultare evidente che con un documento di questo tipo alle spalle, è possibile tracciare dei macro obiettivi associati ad un processo di rinnovamento dell'organizzazione aziendale.
Sintetizzando e generalizzando al massimo i risultati, fu decisa una strategia che puntava a:
- Adeguare le strutture rispetto alle opportunità offerte dai nuovi scenari ICT.
- Superare la frammentazione del software esistente attraverso l’adozione di soluzioni integrate (ERP).
Infatti nessun percorso sensato era ipotizzabile mantenendo la precedente struttura caratterizzata dall'uso di reti locali e geografiche disomogenee, da un largo uso di terminali, e in generale da tecnologia obsoleta.
Inoltre emergeva la chiara necessità di uniformare le applicazioni utilizzate dalla controllata con quella della controllante.
La scelta si indirizzò ad uno dei più noti e consolidati software ERP nel mercato.
Certo bisognava intraprendere un percorso impegnativo per applicare al prodotto le personalizzazioni che il business del trasporto marittimo e le consuetudini aziendali richiedevano, ma, sembrò che l' investimento fosse destinato a dare i risultati sperati al termine di un percorso che sarebbe durato tre anni.
Dire, oggi, che si trattava di SAP, è secondario rispetto alla centralità della "filosofia" che era stata adottata.
Piuttosto è importante segnalare come soluzioni di questo tipo, da una parte si caratterizzano per una forte aderenza agli obiettivi strategici direzionali, elemento estremamente importante in un progetto a medio termine, dall'altra, comportano inevitabilmente una Criticità nell’accettazione del sistema da parte della base di utenti.
L'argomento non è da sottovalutare e richiederebbe una trattazione a parte, per il momento aggiungo che fu deciso un intervento specifico mirato alla Focalizzazione del Cambiamento.
In altre parole fu investito tempo e denaro a motivare le forze migliori dell'azienda, per rivedere criticamente le funzionalità che sarebbero passate da un reparto all'altro e, in un caso, fu eseguita anche una analisi dei tempi per ogni singola attività e una dettagliata descrizione delle mansioni di ogni ruolo, là dove il "Marine Operation" assumeva un ruolo chiave, nell'economia della produzione del servizio di trasporto.
A onor del vero, devo aggiungere che, purtroppo non feci in tempo a vedere il completamento del progetto. Dopo tre anni la proprietà decise, appena risanati i bilanci, di vendere la storica azienda "Italia di navigazione", ad uno dei più grossi vettori marittimi del mercato globale.
Il nucleo centrale del progetto però era stato sviluppato nei tempi e nei costi preventivati e si stava passando alla fase di consolidazione e distribuzione alle agenzie estere.
Il progetto iniziale rimase ancora in carico alla D'Amico, ma le nuovi dimensioni aziendali, la nuova configurazione e priorità del business, avrebbero richiesto una nuova revisione delle scelte strategiche, in modo da rimanere coerenti con la realtà mutata. Di questo si è fatto carico chi mi ha seguito nell'incarico.
venerdì 5 gennaio 2007
I buoni propositi di un CIO, per l'anno 2007
Il primo di questi consigli appare un po' buffo, perchè presuppone un rapporto azienda-dipendente molto maturo . Infatti l'elenco comincia con la predisposizione
di un piano di successione per la prossima leadership IT.
Insomma sta dicendo, "Cari CIO, state invecchiando, avete cominciato a lavorare quando l'informatica richiedeva attitudini e conoscenze ora obsolete, non siete prorio all'altezza di quanto richiede oggi il mercato. Facciamo così, individuate, un possibile successore che abbia 40-45 anni, fatelo crescere, formatelo, meglio se donna, meglio se conosce il business e sappia gestire i "cambiamenti", e poi (questo non lo dice ma sembra la logica conseguenza) mettetevi da parte.
Io veramente, a me stesso e agli altri CIO, direi:
"Non tirare i remi in barca, dieci, otto anni di lavoro prima della pensione, sono tanti. Se sei lì è perchè, hai saputo rinnovare le tue conoscenze e competenze almeno due volte, da quando sei uscito, forte di grandi speranze dai corsi scolastici. Non ti sei mai tirato indietro, quando si è trattato di aggiornarti, di approfondire, di ascoltare, di autovalutarti.
L'informatica è di fronte a una nuova svolta? Bene, tu sei lì, pronto, con pazienza e lucidità, la tua esperienza vale oggi più di ieri. C'è bisogno di te
Comunque, tratte da Computerworld-online, ecco i suggerimenti:
Cose da iniziare a fare
1) Creare un piano di successione per la prossima leadership IT.
2) Tenere traccia e migliorare la sostenibilità ambientale dell'IT, sul piano dell'efficienza elettrica, del riclicaggio, la gestione del ciclo di vita degli apparati, la scelta dei fornitori, e riducendo i viaggi.
3) Identificare e offrire incentivi ai veri innovatori, proprio perché occorreranno nuove idee per innovare e far crescere il business attraverso l'IT saranno determinanti doti come la creatività e la determinazione a superare l'inerzia aziendale.
Cose da fare di più
4) Aiutare le risorse umane a diventare strategiche: gli strumenti socio-tecnologici come le sociale network, la collaborazione, il lavoro remoto e il web 2.0 fanno aumentare l'interazione e la creazione di valore da parte delle persone.
5) Migliorare l'esperienza di business stando al front-office: tutte le persone dello staff IT dovrebbero lavorare almeno una settimana all'anno in una posizione che consenta di venire a stretto contatto con la realtà del business dell'azienda.
6) Ristabilire la visibilità della spesa in tecnologia dell'azienda.
Cose da smettere di fare
7) Restituire i risparmi ottenuti con le efficienze di costo: nel lungo periodo la strategia di ridurre i costi IT danneggia la crescita e conduce a investimenti insufficienti nelle infrastrutture. E comunque i risparmi ottenuti vanno utilizzati per investire in IT.
8) Trattare l'IT governance come se fosse una procedura.
9) Farsi ossessionare dai dettagli tecnologici, come per esempio tutto il rumore intorno a Microsoft Vista: distrae tempo, attenzione ed energie da questioni più importanti.
Una cosa da imparare
10) Impadronirsi delle nuove tecnologie che guidano i trend: in particolare la stampa 3D, i tool di analisi delle informazioni sociali, i più recenti linguaggi di programmazione di alto livello e le comunità virtuali.
La mia esperienza - parte 2
Anni 1987 - 1999
La prima fase di questa esperienza è assimilabile alla precedente. Non esisteva un sistema informativo precedente. Gli obiettivi erano di tipo funzionale concentrati nell'area amministrativa e documentazione export. Ma le zone di influenza dell'informatica aumentavano velocemente coivolgendo le procedure per l'acquisto dei materiali di rispetto/consumo delle unità navali e soprattutto la biglietteria dei passeggeri delle navi traghetto.
L'evoluzione della tecnolgia nelle telecomunicazioni permetteva l'estensione dell'automazione alla emissione e ricezione dei fax e si facevano i primi approcci con collegamenti remoti con le navi, utilizzando modem che comunicavano a terra tramite i sistemi satellitari di bordo (con velocità di 2400 bps!). In questa maniera si potevano però utilizzare prodecure di sincronizzazione dati fra bordo e sede centrale.
I personal computer, inizialmente visti come status-symbol, nel frattempo si sostituivano ai terminali "stupidi" del mini-elaboratore IBM S/38 (e poi IBM AS/400).
Un profondo cambiamento avvenne nei primi anni della decade 90'.
COGLIERE OPPORTUNITA' TECNOLOGIGHE
L'avvento di nuovi sistemi operativi multi-tasking, come IBM OS/2 e MS-WINDOWS, unito a concetti di architettura Client/Server permise di cogliere una importante occasione tecnologica.
L'azienda era impegnata in una profonda e innovativa politica di investimenti su unità navali all'avanguardia che trasformavano il tragitto dei traghetti da Genova alla Sicilia e alla Sardegna in mini-crociere. Il management seppe intuire che anche la tecnologia informatica doveva rinnovarsi e proporre sistemi aperti ad una interfaccia grafica adeguata, ad una flessibilità delle configurazioni tariffarie, all'apertura verso canali di vendita innovativi, inclusa la nuova rete di cui pochi conoscevano l'esistenza: internet.
L'applicazione software dei passeggeri fu completamente riprogettata su queste basi.
PRIMA L'ORGANIZZAZIONE POI IL SOFTWARE
Un'altra occasione di integrazione strategica fu attraverso l'esperienza di sviluppo di una applicazione software per gestire il flusso di passeggeri all'imbarco. Il check-in in auto e a piedi. In questo caso fu studiata, per la prima volta in Italia, una soluzione logistica e le specifiche del software si integrarono con le esigenze organizzative.
mercoledì 3 gennaio 2007
La mia esperienza - parte 1
Anni 1981-1987
Impossibile parlare di informatica strategica:
Siamo negli anni che hanno visto, prima, la diffusione dei mini-calcolatori come gli IBM S/34 (o la serie DPS dell'Honeywell) e subito dopo, dei personal computer.
L'introduzione degli elaboratori elettronici riguardava la gestione della contabilità, l'elaborazione dei cedolini paga e, nel campo dei trasporti marittimi, l'emissione delle polizze di carico per l'export. Ma un certo impatto organizzativo lo ebbe l'interfaccia del mini-calcolatore con la rete telex. Nelle aziende marittime l'attività di preparazione e spedizione di telex copriva una elevata quota della giornata lavorativa di varie persone. La possibilità di gestire direttamente e in tempo reale la comunicazione diede all'azienda vantaggi competitivi.
L'approccio allo sviluppo, almeno per quanto mi riguarda, era privo di pianificazione e seguiva l'intuito e l'estro del momento.
L'arrivo del personal computer fu caratterizzato dalla possibilità di poter produrre reportistica complessa mediante il foglio elettronico, Lotus 123, consentendo nello stesso tempo il calcolo (per esempio dei conti esborsi) e la presentazione grafica del report finale.
martedì 2 gennaio 2007
Gli Scenari
L'approccio e le misure da adottare sono drammaticamente diverse.
- Assenza di sistemi informatici (per esempio, costituzione di una nuova azienda).
- Tecnologia obsoleta (terminal host, reti non strutturate, sistemi operativi abbandonati).
- Sistemi disomogenei (differenti piattaforme server e database).
- Applicazioni frammentate (sviluppi settoriali non armonizzati con altre funzioni aziendali, mancanza di visione per processi).
- Riposizionamento dopo conclusione ciclo di vita dei sistemi.
- Sistema ben strutturato (continuare l'opera in corso).
lunedì 1 gennaio 2007
Strategia e Informatica (7) - CIO
All'americana viene definito il CIO (Chief Information Officer) o in italiano il Direttore dei Sistemi Informativi (ICT).
Paragonerei la sua figura a quella di un direttore d'orchestra.
Fino a poco tempo fa la prospettiva del responsabile era fare in modo che l' ICT venisse percepito come fornitore di servizi e tecnologia, oggi il suo compito è quello di superare il gap fra "il contenuto tecnologico" e il "come influire sul margine competitivo".