Progetti sempre più grandi

Centralizzare.
La disponibilità di banda larga, la potenza di elaborazione dei server, la capacità delle applicazioni di gestire processi complessi, l' organizzazione aziendale delocalizzata (produzione e servizi) sono fattori che hanno spinto negli ultimi anni i project manager, verso soluzioni fortemente centralizzate.

Naturalmente questo approccio ha un grosso impatto sulla complessità dei progetti.

Ecco alcuni pericoli reali ai quali si va incontro che dovrebbero far riflettere e indirizzare verso altre soluzioni più "maneggevoli" (o comunque dovrebbero indirizzare verso l'individuazione di contromisure).

• Inefficienza
• Spechi di risorse
• Budget non rispettati
• Illusioni si risparmi futuri (a fronte di elevate spese certe)
• TCO con calcoli inaffidabili
• Rigidità a cambiare direzione se necessario
• Controlli e monitoraggio del progetto difficili
• Risorse economiche dirottate all'esterno
• Perdita di conoscenze e professionalità nelle periferie
• Impatto ambientale

La mia idea:
"piccolo, distribuito e interconnesso" è meglio di "molto grande" (probabilmente)

Anche se la mia affermazione è piuttosto vaga ed è solo un'intuizione, penso che
in qualche maniera dovremmo imparare dalla natura.
Nell'evoluzione delle specie (direi che come esempio di complessità non c'è male, vero?) si sono adattati con successo gli organismi più piccoli piuttosto che i giganti. Non sarà così anche per l'organizzazione aziendale e informatica? Forse c'è un principio cibernetico da rispettare.

Shaker di tecnologia

Per progettare una buona struttura ICT non basta fare l'elenco delle migliori tecnologie e delle più promettenti "best practises" e mescerle insieme come si fa per la preparazione di un cocktail.
Una visione pragmatica dell'organizzazione non deve far perdere di vista la gradualità dell'approccio attraverso una scelta basata su priorità tecnologiche e organizzative.
Se si pretende di avviare nel giro di un paio di anni: outsourcing di servizi, procurement centralizzato, revisione dell'architettura WAN e delle infrastrutture di rete, introduzione di server virtuali, standardizzazione dei client e chi più ne ha più ne metta, bisogna poi essere pronti a fronteggiare ritardi eclatanti, resistenze più o meno velate, perplessità, perdita di fiducia nell'obiettivo finale.
E comunque, rimanendo all'esempio del cocktail, bisogna pur sempre azzeccare gli ingredienti per avere un risultato apprezzabile.

Io propongo un metodo che richiede una forte lucidità e una chiara visione strategica.
Un buon piano di ammodernamento informatico non deve superare i tre anni di gestazione per evitare che gli sforzi per attuarlo vengano bruciati dall'abitudine alla precarietà.
Non solo, bisogna mettersi nelle condizioni che il piano sia assolutamente praticabile, considerando ogni potenziale ritardo come un nemico pericoloso.
L'appoggio interno è fondamentale: occorre che gli elementi chiave (spesso i progettisti del precedente sistema) abbiano un ruolo attivo e trainante, per questo motivo occorre prodigarsi nella proposta di motivazioni valide.
L'appoggio esterno è fondamentale (pure lui) ma dovrebbe essere sempre visto come fatto transitorio, a meno che non si sia consapevoli di trascinare l'organizzazione ICT fuori dalle competenze "core" dell'azienda.
Io ci penserei un po'...

Crisi

C'è la crisi: aiuto aiuto aiuto!
Inevitabile revisione di budget, analisi dei contratti con fornitori per strappare un ribasso, esami di coscienza individuali e pubblici per individuare investimenti non strettamente necessari da tagliare.
Inevitabile ma... non bisognerebbe limitarsi a questo esercizio imposto dalla contrazione delle vendite.
Una visione intelligente suggerisce di individuare alcune aree di attuale debolezza e su quelle investire in modo da essere in prima linea al momento della ripresa.

Un po' di sano pragmatismo dovrebbe consentire di focalizzare, all'interno dei progetti avviati, quelle attività che generano costi e ritardi (che poi significa altri costi).

Un impegno extra dovrebbe essere posto al dialogo fra specialisti IT e business: le difficoltà possono essere luogo di risanamento e di compattamento psicologico degli sforzi nella stessa direzione.

Meglio risolvere un problema o gestire un conflitto?

La risposta, ma soprattutto la domanda sembra banale. Come dire: si sta meglio quando si sta bene o quando si sta male?
Nella realtà non è proprio così, non sempre.

Qualche volta nonostante si abbia la percezione di andare a sbattere contro un conflitto, non ci sono i margini per cambiare rotta.
Succede come in certe corse di Formula 1, dove la macchina sull'asfalto bagnato prende una traiettoria trasversale e ogni tentativo di controllo del pilota risulta impossibile.

Uno di questi argomenti così viscidi è quello della riorganizzazione delle mansioni e dei ruoli di un reparto. Le motivazioni possono essere svariate e comprendono la crescita delle attività, una trasformazione, la contrazione delle risorse, e così via.
Sì, perché se nell'organizzare si parte da un foglio bianco e si possono seguire certi principi teorici, la riorganizzazione non può non misurarsi con le abitudini dei singoli, le conoscenze maturate, le incompatibilità dei ruoli, i vincoli organizzativi e normativi.

Allora, pur essendo vero che la domanda iniziale è scontata non sempre lo è la soluzione.

governare la complessità informatica

Quali sono le leve strategiche utilizzate dal Cio per governare la complessità informatica?
Non mi sembra che ci sia una sostanziale differenza, perlomeno in termini di approccio, fra un Cio o un altro manager aziendale.
Gli ingredienti sono: governo, organizzazione, gestione e naturalmente tecnologia, ma con un condimento comune che è l'ascolto. Se non si è capaci di ascoltare non si può pretendere di fare buona strategia. Ascoltare gli azionisti, gli altri manager, le istanze che vengono dal basso, i fornitori, il mercato, significa mettere le premesse per una buona sintesi. Inoltre, chi si occupa del business deve diventare consapevole che il Cio non è un'appendice da consultare in seconda battuta per “fare qualcosa”, ma deve partecipare alla condivisione delle decisioni. E’ importante che rispetto al passato il Cio rinunci ad alcune peculiarità operative per investire sul lato progettuale e manageriale.

(tratto da intervista rilasciata a A. Savarese per conto di Data Manager Maggio 08)

Quanto spago lasciare?

E' giusto, all'interno di una organizzazione IT, introdurre regole severe che impediscano lo svilupparsi di varianti fuori controllo o lasciare un po' di briglia sciolta alle forze 'laterali' è segno di una maturità capace di far emergere elementi creativi che altrimenti rimarrebbero inespressi?
Insomma, quanto spago bisogna lasciare?

Probabilmente si tende a dare risposte diverse a seconda della posizione in cui ci si colloca.
Fino a qualche mese fa la mia azienda, prima di essere incorporata, pur piccola, era comunque "il centro" di un network di lavoro; di conseguenza vedevo le cose dalla prospettiva di chi cerca di aumentare i controlli, di implemetare gli standard, di evitare il proliferare di nuovi software locali e di sistemi decentrati diversi o configurati con politiche diverse.
Oggi che faccio parte della periferia di una grossa organizzazione mi viene più facile esporre delle contro-osservazioni.

In definitiva sono due aspetti della realtà che andrebbero valorizzati di pari passo.
Sviluppare sistemi, funzionalità e politiche, governando il tutto da un centro-stella è spesso una necessità oltre che una efficenza. Il prezzo della disomogeneità potrebbe essere fatale oggi che comunicare, analizzare globalmente i risultati, trasferire informazioni in tempo reale è una esigenza dei processi di erogazione dei servizi/prodotti.
Nello stesso tempo trovare canali che permettano alla periferia di esprimere spinte dal basso, potrebbe essere un modo per evitare una omogeneità stagnante.
Come in fondo ci insegnano le scienze naturali: l'evoluzione delle specie, produce il miglior adattamento all'ambiente mescolando il più possibile i 'geni'.

C'è cliente e cliente

Qualche anno fa qualcuno si è sforzato di mettermi in testa l'idea che per migliorare l'efficienza, la qualità e i costi dei Sistemi Informativi, dovevo cominciare a pensare che gli utenti delle applicazioni software, i colleghi degli altri reparti, sono i miei clienti.
In questo modo sarei uscito dal pantano di un'informatica ripiegata su se stessa e incapace di collaborare al business dell'azienda.
In questi giorni leggo un articolo su CIO.com dove un collega americano, Kumud Kalia, spiega che questa prospettiva non va affatto bene.
Non bisogna confondere i termini. Il cliente è colui che paga per i servizi/prodotti dell'azienda, non il collega del piano di sopra.
In effetti l'articolo è interessante e può aiutare a focalizzare meglio gli obiettivi che tutti, all'interno di una azienda, devono aver chiari: migliorare la soddisfazione del cliente (che alla fine è colui che permette di ritirare a fine mese lo stipendio).
Qualche passaggio del ragionamento sembra però troppo radicale. Perchè l'autore pensa: chi non andrà in questa direzione sarà "terzializzato", cioè in definitiva sarà escluso.
Quindi, tutti di corsa a identificare le reali necessità del cliente: informatici, contabili, legali e altri reparti di supporto.

Il mio parere: va bene, focalizziamo e miglioriamo la consapevolezza, adottiamo una terminologia più consona, ma per favore non confondiamo i ruoli. La produzione di un prodotto o di un servizio è la conseguenza di un processo di attività, alcune direttamente collegabili al cliente esterno, le altre lo sono perchè di supporto o di controllo. Ci vuole equilibrio.

La metrica IT e gli specchi

Richard Scase - Global Remix: The Fight for Competitive Advantage

Potrebbe tradursi come: il miscuglio globale, il combattimento per il vantaggio competitivo.
E' necessaria una premessa: non ho letto il libro ma solo qualche articolo di commento e la sua prentazione sul sito dell'autore. Il contenuto del post si concentra sull'aspetto informatico e potrebbe essere non esaustivo o non pienamente coerente.

Per gli ambienti IT fa quasi parte della "normalità" attraversare periodi di transizione! I paradigmi correnti vengono superati e sostituiti da nuovi. Il periodo che stiamo vivendo non fa eccezione.
In questa situazione avere un forte senso di autoconsapevolezza sarebbe fondamentale per influenzare gli altri. Un leader IT deve conoscere il proprio ruolo per poter supportare l'organizzazione e valutare correttamente il valore che l'IT può rappresentare nell'impresa.
Il fatto è che oggi non basta più essere un manager ma appunto bisogna diventare leader, cioè persona capace di influenzare gli altri.
Diversamente il rischio è che il manager IT venga ignorato o saltato e che subisca una crisi di identità.
L'autore ipotizza che ciò possa dipendere dal fatto che nell'IT c'è una mancanza di capacità "metrica" e che ci vorrebbe qualcosa di simile alla scala di Kardashev (1), ma applicata al campo dell' "organizzazione".
Oggi succede che, pur risultando positivi tutti gli indici nei cruscotti aziendali, nella realtà dei fatti, l'organizzazione IT è spesso deficitaria.

I manager IT vorrebbero convincere i loro amministratori aziendali che l'IT influisce sostanzialmente con l' attuale e futura salute dell'impresa. Per riuscirci, ogni responsabile IT dovrebbe avere uno specchio e un righello graduato.
Lo specchio è qualunque cosa che possa fornire una autoconsapevolezza relativamente ai propri bisogni. Lo specchio aiuta infatti a capire chi siamo, cosa vogliamo essere, cosa facciamo, perchè facciamo quello che facciamo.
Il righello corrisponde a qualsiasi strumento che fornisca le metriche di come l'IT sta facendo le cose che fa; e poichè riflette la realtà, è in qualche modo anch'esso uno specchio. Così risolvendo il problema della metrica si risolve anche il problema della identità IT.

La civiltà sulla Terra è, nella scala di Kardashev, al di sotto dei tre tipi di civilizzazione ipotizzati, infatti non è capace di utilizzare, nè tanto meno controllare tutta la potenza disponibile nel pianeta.
Riportando il concetto sull'organizzazione, si potrebbe ipotizzare che una organizzazione di Tipo I è quella in grado di utilizzare tutta la potenza di calcolo e tutta quella intellettuale disponibile in una organizzazione. Lo stato dei fatti odierno è però ben al di sotto di quello primo livello.


(1) Nikolai Kardashev, astronomo. Nel 1964 ha classificato la civiltà in base all'avanzamento tecnologico. E' una classificazione che si basa sulla valutazione di quanto una civiltà sia capace di controllare l'energia. Ma è, come dire, proiettata al futuro remoto perchè tenta di classificare civiltà oggi inimmaginabili.
Tipo I: capacità di controllo totale dell'energia del pianeta, delle condizioni meteorologiche, capacità di prevenire i terremoti. Completatamento dell’esplorazione del sistema solare (possibile step raggiunto fra 100/200 anni).

Tipo II: capacità di controllare l'energia del sole. Cioè estrarre l’energia direttamente dal sole (1K/5K anni).

Tipo III: capacità di controllo di un’intera galassia (100K/500K anni).

Quello che trovo positivo in queste idee è proprio il carattere un po' utopistico.
Magari si potesse rappresentare in una scala lineare quanto avanzata tecnologicamente è una organizzazione!
Purtroppo mi sembra che proprio la scelta di paragonare la situazione attuale su una scala di tipo Kardashev dimostri quanto poco possa aiutare nei prossimi dieci anni questo tipo di approccio e quanto a tentoni proceda il governo della scienza informatica.

CIO: lavoro estremo?

Oltre agli sport estremi, ci sono anche i lavori estremi?
Sicuramente. Ma includere fra questi anche quello di direttore dei sistemi informatici, mi sembra più che altro una provocazione.
CIO Magazine pubblica un articolo e un quiz per misurare quanto sei estremo.
Il punto di partenza è basato sulla quantità di ore di lavoro per settimana e sulla tua personale percezione di appartenere alla categoria degli "estremi".
Io ho provato, ma ho capito subito di essere fuori gioco perchè lavoro meno di 60 ore/settimana (!) ( inoltre non ho barrato la casella che dice che la mia famiglia va a rotoli per colpa del lavoro).
Sono stato classificato insieme al 43% come "E lo chiami lavoro?", contro un 48% di "Maniaco del lavoro". Il rimanente si divide tra chi è "estremo come un gelato alla vaniglia" e chi è veramente "estremo" (5%).

Comunque le possibili motivazioni proposte per ritenere che il proprio lavorare è "estremo" sono le seguenti:

• flusso di lavoro imprevedibile
• ritmi veloci e scadenze rigide
• eccessiva responsabilità dovuta a più compiti
• attività di lavoro fuori dall'orario normale
• necessità di dare disponibilità 24/7
• responsabilità inerenti profitti e perdite
• responsabilità di reclutamento e guida di persone
• grande quantità di lavoro
• eccessiva quantità di relazioni dirette da gestire
• presenza fisica nel posto di lavoro per più di 10 ore al giorno.

Io ho sempre dubitato dell'effettiva necessità di passare le notti al lavoro.
Salvo periodi ben limitati, situazioni di emergenza o eventi eccezionali, spesso, dietro queste situazioni, si nasconde una lacuna organizzativa, una incapacità a delegare, una cattiva pianificazione, una fuga da altri problemi riguardanti la sfera personale (affettiva o psicologica).

Processo di Revisione ICT

Come ho avuto modo di accennare, in un post dello scorso mese, mi è capitato più volte di dover affrontare la riorganizzazione del reparto 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.

Impatto organizzativo

Alcuni appunti personali relativi alla consapevolezza dell’impatto organizzativo a seguito della decisione di adottare una applicazione World-Wide dei Trasporti Marittimi.

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.

La mia esperienza - parte 4

Costa Container Lines
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.

La mia esperienza - parte 2

Grimaldi - Grandi Traghetti Spa
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.

L'intero progetto fu sviluppato con il contibuto di un forte partner di riferimento, con una tecnica che in gergo si chiama:

BUILT-OPERATE-TRANSFER

Un qualificato team di ingegneri costruì il sistema collaborando con il personale informatico della società, lo mise in funzione, e fornì servizio di manutenzione fino alla maturazione interna di competenze. A quel punto la compagnia di navigazione potè continuare il percorso con le proprie gambe.

Informatica e Organizzazione

Gli anni 60'
Questa è una storia la cui origine va collocata intorno agli anni sessanta, perché solo in quel periodo i calcolatori escono dalla fase pionieristica (vedi miei post "un po' di storia dei computer" e successivi) e si diffondono nelle industrie.
I costi, la flessibilità, le prestazioni permettono infatti investimenti con ritorni economici e organizzativi evidenti.
Non si elaborano più solamente i dati contabili ma si vede l' elaboratore come il mezzo per affrontare tutti i lavori di tipo ripetitivo e di grande volume.





Tra l' esercito dei colletti bianchi nasce una nuova "razza": gli informatici. All' interno del loro ufficio, il CED (Centro Elaborazioni Dati), si moltiplicano, gli operatori, i programmatori, gli analisti, il capocentro.
E' interessante notare che in questo periodo non c'è alcun contatto fra l' utilizzatore finale delle informazioni e la macchina. Il contatto è riservato e mediato dagli specialisti.
I grandi saloni, con aria condizionata, che ospitano le macchine sono come fortezze impenetrabili.

Dagli anni 80' ad oggi
Devono passare alcuni anni perché si modifichi sostanzialmente questa situazione.
C'è di mezzo un' incredibile crescente sviluppo tecnologico, una forte concorrenza fra i costruttori, una evoluzione dei medi/grossi elaboratori e naturalmente, l' avvento dei personal computer.
E' stata una rivoluzione soft, giorno per giorno nelle nostre aziende e nelle nostre fabbriche la realtà è andata cambiando senza che i più se ne rendessero conto.

Chi ha vissuto in 'diretta' questa trasformazione sono proprio gli uomini del CED. Il loro ruolo è andato continuamente cambiando. Se infatti prima erano i tutori del sapere informatico, adesso la diffusione e nello stesso tempo la specializzazione dei vari campi, li ha costretti a diventare una sorta di consulenti interni, di gestori di risorse, di governatori delle tecnologie.
La loro competenza è rimasta importante soprattutto nel saper riordinare, coordinare, raccogliere, stimolare le varie esigenze di ogni reparto, nel saperle tradurre in fatti organizzativi, in scelta dei prodotti più idonei, in sviluppo di applicazioni strategiche e personalizzate per l' azienda.

Ancora fino a qualche anno fa, trovavo qualche collega che resisteva al cambiamento, che si illudeva di dover difendere la propria immagine facendo credere di sapere tanto, che metteva avanti argomenti tecnici per continuare ad accentrare su di sé...ma era una battaglia persa.

La "fortezza tecnologica", è saltata: le macchine sono diventate strumenti di lavoro per uomini di affari, impiegati e operai, strumenti di gioco in mano ai bambini, accessori di casa, strumenti di comunicazione.

Solo apparentemente sembra in contraddizione rilevare che il numero degli specialisti informatici è cresciuto, perché in rapporto al numero delle macchine installate, il numero di addetti è in realtà diminuito.

Allora, potrebbe sembrare tutto lineare, un' evoluzione come tante del ventesimo secolo.

Io penso che non è così. Il computer è una macchina 'particolare'. Il rapporto uomo-macchina assume implicazioni sociali importanti.

Innovazione organizzativa e informatica

Tratto dalla rivista on line Ship2shore

Innovazione organizzativa e informatica; a ciascuno il suo ruolo
Dibattito al Propeller sui sistemi IT: motori o strumento dell’innovazione organizzativa? Rispondono armatori (Tirrenia, CCL, MSC Le Navi e GNV), registri (RINA) e produttori (Siemens)

Possoni i grandi gruppi armatoriali nazionali portare avanti importanti cambiamenti organizzativi attraverso l’implementazione di sistemi informativi? E tali sistemi possono essere strumenti di business oltre che strumenti di automazione dei processi?
Sono alcuni degli interrogativi cui ha cercato di dare risposta l’incontro “I sistemi informativi sono motore dell’innovazione organizzativa o ne sono puro strumento?” promosso da Stefano Costa, partner e responsabile Logistica & Shipping di T.Bridge al Propeller Club Port of Genoa, che ha convenuto un centinaio di responsabili IT, armatori e manager di tutti i filoni dello shipping.
D’acchito si evidenziano le difficolta' riscontrate dall’industria armatoriale a capire e considerare i sistemi informatici come variabile su cui costruire un vantaggio competitivo, con ampi margini di miglioramento che solo pochi operatori iniziano a sondare con tangibili risultati.
“La rapida obsolescenza dei prodotti tecnologici ne rende sempre meno interessante il possesso, mentre l’accesso ai servizi e' sempre piu' importante” sottolinea Marco Bosi, Vice President CS New Solution Business Development di Siemens. “In tale scenario il rapporto tra fornitore di soluzioni tecnologiche e cliente deve sempre piu' tendere verso forme di partnership dove entrambi gli attori investono e si mettono in gioco per poi condividere i risultati del progetto”.
“Ritengo tutt’altro che semplice incasellare il contributo dei sistemi informativi: se da una parte sono spesso concepiti come puro strumento, non si puo' negare che importanti sviluppi del business siano possibili solo attraverso sistemi dalle potenzialita' prima irraggiungibili” afferma, ricordando la propria esperienza da top manager,in Coeclerici Ugo Salerno, Amministratore Delegato RINA, illustrando il nuovo portale del Registro; un investimento strategico sia per la condivisione delle informazioni all’interno del Gruppo (61 sedi in 20 paesi), sia nei rapporti con fornitori e clienti.
Notevoli gli sforzi effettuati da Tirrenia in questi ultimi anni per allineare i propri sistemi al mercato, come testimoniato da Paolo Greco che, dopo ventennale esperienza nelle funzioni IT di aziende multinazionali, dal 2002 e' Direttore Sistemi Informativi del Gruppo statale di traghetti.
Vincenzo Trichini, Responsabile Sistemi Informativi di CCL Costa Container Lines (in precedenza ricopriva analoghi incarichi in Grimaldi e D’Amico/Italia di Navigazione), comparando le proprie esperienze nelle diverse realta' armatoriali, presenta un’interessante schematizzazione delle condizioni che possono rendere strategico per il business un investimento in IT, peraltro mettendo in guardia sulla necessita' di accompagnare gli investimenti con interventi di riorganizzazione. “Implementare una nuova tecnologia senza cambiare i processi ne pregiudica i risultati” osserva.
L’esempio del trasporto aereo e' stato preso da Paolo Favilla, Direttore Generale di Grandi Navi Veloci. “Nei ferry la redditivita' del business e' fortemente dipendente dalla capacita' di offrire forme di tariffazione flessibili come le compagnie aeree; cio' avviene gia' per i passeggeri, ma non ancora per le merci. L’integrazione tra IT e marketing potra' essere chiave d’innovazione e successo”.
Di rilievo la problematica della mancata standardizzazione tra fornitori di tecnologia. “A fronte di dichiarazioni di intenti dei principali player internazionali, la spinta all’affermazione dei propri standard rimane ancora evidente” commenta Roberto Musumeci di MSC Le Navi.

Informatica&Organizzazione

Nel titolo le motivazioni:
raccogliere alcune riflessioni e tecniche che ho imparato in questi anni nel mio mestiere di direttore dei sistemi informativi.
Non tutto quello che dirò ho potuto farlo. Qualche volta ho incontrato aziende con atteggiamento coriaceo verso l'informatica applicata all'organizzazione.
Ma anche questo sarà oggetto del mio diario on-line.