Dire che l’informatica sia lo strumento fondamentale di quasi ogni tipo di attività produttiva o commerciale (e non solo, perché anche le attività sociali ed educative vi ricorrono) può sembrare fin troppo banale, ma non è che la verità. Quasi nulla ormai può essere ideato o costruito, trasportato e consegnato, venduto o acquistato, accreditato o addebitato su un conto, registrato o depennato da un elenco, senza che una piattaforma e un’applicazione non entrino in gioco.
La conseguenza è una sola: dalla solidità dell’It dipende la solidità del business. Stabilito questo assunto, vediamo cosa ciò significhi per le due figure manageriali dalle quali dipendono e l’It e il business, ossia il responsabile dei sistemi e dei servizi informativi, o come oggi si preferisce dire, Cio, e l’amministratore delegato, o Ceo. Due figure che oggi devono necessariamente estendere, ai fini di una collaborazione che sarà inevitabilmente sempre più stretta, le rispettive visioni e culture aziendali [e per comprendere meglio questa relazione rimandiamo alla nuova area inaugurata da ZeroUno, dedicata proprio a Ceo&Cio ndr].
I costi sono importanti ma il focus è su crescita e innovazione del business
Cominciamo dal vertice della piramide decisionale, ossia dall’amministratore delegato. Come esordisce Marco Becattini, Hp Software Country Manager (nella foto): “Nell’agenda del Ceo vi sono due priorità: continuare a tenere sotto controllo i costi aziendali, perché il livello di competitività cresce e, seppure in modo meno stressante di qualche anno fa, l’attenzione ai costi continua ad essere un elemento di rilevanza; e riprendere a badare alla crescita e all’innovazione del business”.
Tra i mezzi cui il Ceo può ricorrere per giungere al difficile traguardo di combinare sviluppo e contenimento costi, alcuni hanno un impatto più immediato sui risultati e sono preferiti. Uno è quello di raggiungere, attraverso fusioni e acquisizioni, nuovi mercati (per geografie e/o tipologie di clientela), realizzando nello stesso tempo una riduzione dei costi grazie ad economie di scala. E uno dei costi dove queste economie sono più significative è proprio quello dell’It.
Un secondo mezzo sul quale il Ceo fa affidamento, in questo caso ai fini dell’innovazione, è la compressione del cosiddetto ‘time-to-market’, ossia del tempo necessario a rendere disponibili nuovi prodotti o servizi. Per ridurre l’intervallo tra il concepimento di un prodotto o servizio e la sua offerta sul mercato occorre ottimizzare quella che possiamo definire la ‘supply chain’ di tutte le attività correlate, e poiché, come si è detto, non vi è nulla che venga realizzato senza l’apporto dell’It, questa ottimizzazione passa attraverso l’ottimizzazione delle applicazioni coinvolte. Che sono molte: un nuovo prodotto tocca i diversi moduli dell’Erp e tocca anche applicazioni di Crm, logistica, analisi finanziaria e altre ancora. E nel caso dei servizi, le applicazioni non sono ‘coinvolte’ ma sono esse stesse il nuovo prodotto. Per una banca come per un’agenzia di viaggi, il time to market di una nuova offerta coincide con il tempo di sviluppo, testing e messa in linea dell’applicazione o della procedura che la supporta.
Cosa significa tutto questo per il Cio? I suoi problemi sono, nell’ambito di sua competenza, gli stessi dell’amministratore delegato: mantenere sotto controllo i costi dell’It e garantire che i servizi forniti realizzino, o quanto meno abilitino, le strategia di crescita del business. Secondo Becattini, in termini di costi l’It manager si trova a combattere su più aree. “Una è quella di garantire l’applicazione delle compliance aziendali ed extraziendali, che anche se non generano revenue immediate vanno comunque rispettate. E perché talvolta portano benefici (penso alla riduzione degli accantonamenti attuabile tramite Basilea 2), e perché sono obblighi dai quali non si può derogare. Una seconda area è quella dell’automazione, che oltre a una maggior velocità di processo dovrebbe (uso il condizionale perché non sempre la sua esecuzione porta a questo risultato) garantire una diminuzione dei costi sia in termini di gestione del rischio sia di gestione delle persone”. Un aspetto, quest’ultimo, che nel nostro paese, dove la relativa maggior rigidità del mercato del lavoro impone piani di riutilizzo delle risorse liberate, va studiato con attenzione. “L’automazione – prosegue Becattini – servirebbe anche a spostare quel famoso rapporto tra Opex e Capex [operative expenditure e capital expenditure ndr] che vede la manutenzione assorbire il 70% delle risorse lasciando solo il 30% agli investimenti”.
Sviluppo applicativo: mantenere il controllo dell’intero processo
La sfida dell’automazione investe oggi un modo dell’It che nella maggioranza delle realtà aziendali è ancora organizzato, come si dice, ‘per silos’; ossia con strutture e funzioni verticalizzate sulle diverse applicazioni aziendali. L’Erp è un ‘silo’ con il suo database, il suo centro di sviluppo e implementazione, talvolta anche la sua piattaforma; il Crm un altro; così come sono altrettanti silos le applicazioni finanziarie, di e-commerce e così via. “Non esiste – spiega Becattini – una catena di processo che metta in relazione, o con strumenti o con processi collegati agli strumenti, le attività di chi pensa all’It in termini strategici e di chi la deve gestire”.
In altre parole, mancano all’interno delle aziende strumenti che garantiscano un’unità d’intenti e di visione tra chi chiede un nuovo servizio applicativo, chi lo progetta, chi lo realizza e chi infine lo deve gestire. “Facciamo l’esempio – prosegue Becattini – di un’implementazione di nuove funzioni dell’Erp: si parte da chi gestisce il business che chiede di avere funzionalità aggiuntive rispetto a quelle che già ha; queste richieste giungono a una struttura interna dell’It, che chiamiamo di ‘demand management’, che le traduce in requirement da passare a chi deve sviluppare o cambiare l’applicazione. Costui, a fronte di queste informazioni, fa il suo lavoro e, quando l’applicazione o la modifica è pronta, la passa all’ambiente di esercizio. Questo la prova, la mette in operazione e la gestisce”. Si tratta quindi di un flusso orizzontale rispetto alle strutture coinvolte e legato alle competenze specifiche dei team. Se non si tiene sotto controllo il processo dall’inizio alla fine, si possono perdere informazioni da un passaggio all’altro e se poi in fase d’esercizio sorgono degli inconvenienti non si riesce a ricostruirne l’origine e la causa. Questo è un grave problema per il Cio, che non solo non può garantire o verificare che il servizio fornito al business ne soddisfi le richieste, ma se non le soddisfa, non ha nemmeno gli strumenti per dimostrare che il lavoro è stato fatto in modo conforme alle richieste avanzate. E secondo Becattini sono molte le aziende che stanno prevedendo strutture di cross-governance in grado appunto di affrontare questi problemi.
Ripensare il modello di sviluppo
In questo quadro, per così dire, organizzativo della ‘fabbrica del software’ si inserisce l’evoluzione stessa delle applicazioni business. Queste sono state sviluppate, in maggiore o minore misura a seconda della ‘maturità’ dei diversi ambienti di appartenenza (le banche, per capirci, hanno applicazioni di più vecchia generazione rispetto alle telcom), in modo verticale e autoconsistente, cioè con il proprio database, la propria anagrafica e così via. Con l’aumentare del numero delle applicazioni ciò ha reso talmente complessa la gestione del parco applicativo da indurre a quel ripensamento del modello di sviluppo che, passando per la separazione delle componenti comuni da quelle specifiche, ha portato a concepire gli shared services prima e la Soa poi. Una seconda evoluzione fondamentale è quella che impone una forma di controllo dell’aderenza dell’applicazione alle richieste del business in qualche modo incorporata e automatizzata nel processo di sviluppo. In tal modo la fase di testing si limita alla verifica del funzionamento operativo, e non della logica applicativa, del software, risultando molto più breve e accelerando il rilascio in produzione.
Queste evoluzioni sono supportate e abilitate dagli strumenti di Quality e Performance Management, che accompagnano il processo di sviluppo e delivery delle applicazioni verificandone la rispondenza a tre parametri fondamentali: la funzionalità, cioè che faccia realmente ciò di cui il business ha bisogno; le prestazioni, cioè che una volta in produzione garantisca gli Sla concordati e che possa scalare per seguire la crescita del business; la sicurezza, cioè che non presenti ‘porte aperte’ a intrusioni e sia testata contro tutte le minacce conosciute.
Partecipa alla community