“Agile” è sicuramente tra i termini più usati nel 2017. Ed è anche la tipica buzzword che travalica i propri obiettivi con l’uso eccessivo. Ecco perché intraprendere una trasformazione di tipo Agile è più l’eccezione che la regola. È un fatto che l’implementazione di una trasformazione Agile di successo rimane difficile. È vero che cresce il consenso per il cambiamento, oltre che per la necessità di un servizio completo in cui tutte le parti interessate sono ugualmente coinvolte nello stesso processo, allo scopo di creare valore di business più rapidamente. Ma come possono le aziende raggiungere questo obiettivo? E per quali fattori le aziende hanno bisogno di adattare le loro pratiche di tipo Agile?

Cosa è successo nel 2017

Al giorno d’oggi, la necessità di lavorare in modo Agile è molto chiara. C’è una necessità diffusa di co-creazione, e il numero di richieste di aziende che intendono intraprendere una trasformazione Agile aumenta rapidamente. Le nuove tecnologie e le innovazioni si evolvono rapidamente, quindi è importante che le organizzazioni siano in grado di fornire prodotti in tempi rapidi. Se ci si trova in un’azienda incapace di rispondere alle innovazioni ora e in futuro, allora si avrà difficoltà a sopravvivere. La metodologia Agile si sta sviluppando da tempo. La nascita di alternative all’approccio sequenziale tradizionale, quello consecutivo, risale a decenni fa. Nel 1990, alcuni esperti hanno approfondito ulteriormente i diversi metodi di lavoro. Con diciassette esperti abbiamo condiviso tutte le nostre esperienze che, una volta combinate, hanno formulato il Manifesto Agile. Nei Paesi Bassi, la metodologia DSDM è stata ampiamente applicata nella seconda metà degli anni Novanta. Poco dopo aver scritto il Manifesto nel 2001, XP si fece avanti con forza, e successivamente fu la volta di Scrum. Dal 2003, la metodologia Agile sta gradualmente attirando l’attenzione. Da circa cinque anni, il concetto di interazione Agile viene applicato su larga scala al di fuori del circuito IT. Non solo il reparto IT ha iniziato a lavorare in modo diverso, ma l’intera azienda ha dovuto essere rivista per sfruttare tutti i vantaggi del funzionamento di Agile. Nel 2017 si sono fatte avanti molte opportunità per le aziende in questo ambito, e sono state identificate tre tendenze principali.

#Agile Il coraggio di cambiare per uscire dalle vecchie logiche – @arievanbennekum
Click To Tweet

Dall’Agile scalato a quello corporate

Alcuni anni fa, i principi Agile venivano applicati principalmente all’interno dei team, mentre oggi l’attenzione si è spostata sull’interazione tra i diversi team. Nei programmi, questo movimento è iniziato con il termine “scalabilità”. Per un numero crescente di team, nasce la necessità di coordinare le attività tra i team Agile: se non vi è alcun coordinamento, potrebbero esservi attriti. La sfida per il 2018 è quella di integrare la cooperazione dell’intera organizzazione. In questo modo, il lavoro Agile può essere implementato sulla base del concetto di erogazione di un servizio completo, che lo rende un modello Agile di tipo corporate. Con questo servizio completo è importante che tutte le parti interessate lavorino insieme sullo stesso progetto dall’inizio del processo in poi. Un esempio frequentemente usato è la produzione di un gioco di Monopoli. Progettisti e uomini del marketing iniziano subito con il gioco da tavolo e non coinvolgono l’ufficio legale fino a quando il gioco da tavolo non è finito. Nel frattempo, gli errori di tipo giuridico non vengono notati, facendo sì che il gioco passi direttamente nella spazzatura: l’intero processo può ricominciare da capo. Ciò avrebbe potuto essere evitato coinvolgendo tutte le parti interessate dall’inizio del processo, realizzando un approccio di tipo completo. Disciplinando i rituali di interazione di tipo Agile, si coglie uno dei driver di questa metodologia: prevenire i ritardi. Chiunque abbia il controllo (anche di un solo aspetto) del prodotto deve rimanere coinvolto: analisti, sviluppatori, utenti, avvocati, operatori di marketing, designer e così via.

Il management risvegliato

Il management e i membri del consiglio di amministrazione sono sempre più consapevoli della necessità di integrare tutti gli stakeholder in un unico processo. Se il management e i membri del consiglio di amministrazione comprendono l’utilità di coinvolgere tutte le parti interessate, ciò si traduce in una consegna più veloce di prodotti o servizi. Finalmente dal 2017 operare Agile non è più visto come un compito dell’IT, ma qualcosa che deve essere fatto insieme. Evviva! Insieme al crescente numero di applicazioni per le trasformazioni Agile, il numero di coach Agile è aumentato. Un problema comune a questi coach, sul quale devono prestare attenzione, è che loro stessi non rientrano nei metodi sequenziali tradizionali. I coach Agile che eseguono trasformazioni Agile, ma non agiscono in questa modalità, sono un esempio pogo gradevole, e questo succede davvero! È compito dell’allievo Agile non solo proteggersi contro i vecchi principi e affrontarli con il classico comportamento di resistenza, ma farlo specialmente per il cliente della trasformazione, interno o esterno. Una dei nostri senior coach ha notato di recente questa necessità: era sorpresa che il management chiedesse a gran voce la trasformazione, ma quando poi è arrivata non volevano trovare il tempo per il cambiamento e ricadevano nei loro vecchi comportamenti. Che spreco! La crescita di coach Agile non deve essere solo nei numeri: la qualità deve essere mantenuta e monitorata. E non solo nei team, ma anche e specialmente a livello di governo delle organizzazioni. La leadership Agile è un fattore essenziale per il successo, nel quale conta il role model.

I vecchi paradigmi di lavoro sono ancora lì

Nonostante la consapevolezza, il modo tradizionale di lavorare nel 2017 sembra essere ancora osservato. A mio parere, ci sono solo poche organizzazioni che sanno come applicare i principi Agile nel modo giusto. La causa sta nel fatto che in tutto il mondo le persone hanno l’abitudine di pensare in modo sequenziale. Ciò significa che sono abituate ad agire passo dopo passo, e questo si traduce in organizzazioni che pianificano ancora determinati passaggi per testare, integrare e accettare un prodotto o una soluzione dopo che sono stati sviluppati. Non c’è spazio nello scenario di mercato di oggi per persone e organizzazioni che continuano a pensare e lavorare in questo modo. Che lo vogliamo o no, il time-to-market sarà il differenziatore nei prossimi anni. I paradigmi scompaiono solo quando i principi Agile vengono applicati correttamente. Le persone dovrebbero avere il coraggio di gettare a mare i loro principi radicati e utilizzare i principi del lavoro Agile nell’attuale ambiente di lavoro. Qui la cultura avanzata, che è determinata dalle persone e dal loro comportamento, è essenziale. Ci sono persone che vogliono vedere opportunità e persone che escogitano argomentazioni contrarie. Ogni “sì, ma…” suggerisce un vecchio paradigma. Non c’è tempo per argomenti contrari, perché ora c’è uno spirito del tempo che richiede reazioni adeguate e rapide. Qui c’è un ruolo importante per i coach: è importante che questi abbiano un background comportamentale e, come tali, partecipino alla competizione Agile, distinguendosi così dai praticanti Agile. Anche i coach hanno davvero bisogno di volere il cambiamento come traguardo, perché fa una grande differenza se qualcuno si allena da solo o fa parte di una trasformazione mirata: il coaching rende qualcuno migliore in quello che fa, e la trasformazione non porta solo cambiamenti all’interno dei team ma all’intera organizzazione.

Come pensare e agire #Agile @arievanbennekum – Roma 29-30 Nov 2018 @techtran
Click To Tweet

Arie van Bennekum

Co-autore del Manifesto Agile e ancora molto attivo nell’area dello sviluppo di soluzioni Agile dove opera da circa venti anni. Esperto di Agile Project Management, facilitazione del team e coinvolgimento dell’utente. È un pragmatico che incorpora il suo pragmatismo nella struttura, nella disciplina e nel buon senso. Credere nel team, facilitarlo a ottenere il massimo con il coinvolgimento dell’utente finale è il suo focus quando parla, presenta, dimostra e insegna Agile. È presidente dell’Agile Consortium International.

Arie van Bennekum presenterà a Roma per Technology Transfer il seminario “Agile Project Management con Certificazione” il 29-30 novembre 2018.

L'articolo Uno sguardo Agile per capire il passato e progettare il futuro proviene da Data Manager Online.

Dedagroup inaugura il prossimo 12 marzo l’edizione 2018 di Dedagroup Digital Academy, programma rivolto a 24 giovani che mira a formare le nuove professioni digitali del futuro attraverso un percorso didattico, teorico e pratico, con finalità di reclutamento e inserimento in azienda.

Il programma annuale – suddiviso in due edizioni di 6 mesi, una in partenza a marzo ed una in ottobre, con 12 partecipanti ciascuna –  è rivolto a giovani laureati e neo-laureati sia in discipline tecnico scientifiche sia umanistiche, di età non superiore ai 28 anni e con un buon livello di conoscenza della lingua inglese. Si tratta di un percorso di formazione full time e di training on the job che, tramite incontri con docenti esterni e testimonianze interne, preparerà i partecipanti ad affrontare con competenza e visione le esigenze più avanzate del mercato.

“Crediamo molto in questa iniziativa, che ha l’obiettivo di offrire l’esperienza unica della scuola d’impresa, creando un collegamento tangibile fra realtà aziendale e giovani aspiranti. Uno spazio aperto, nel quale approfondire le competenze richieste dalle nuove professioni legate al mondo della digital economy, in continua evoluzione, e il loro contributo alle strategie aziendali. L’Academy vuole essere un luogo di confronto e crescita professionale e personale, nel quale mettersi alla prova e colmare il divario tra le abilità acquisite nel percorso universitario e le competenze richieste delle aziende del nostro settore, attraverso un percorso completo, forte dell’esperienza e del know-how del Gruppo. Siamo una realtà in costante crescita e prevediamo quindi con continuità momenti di selezione, per questo siamo convinti che l’Academy possa fornire un contributo importante nel costruire il futuro di Dedagroup.” commenta Valentina Gilli, HR Director Dedagroup.

L’Academy sarà suddivisa in attività d’aula della durata di 15 giorni, che si terranno presso la sede Dedagroup di Trento, e in attività applicata all’interno delle diverse Business Unit del Gruppo, con modalità di training on the job, per permettere di sperimentare la realtà lavorativa interagendo con i colleghi nel loro quotidiano.  La formazione in aula sarà strutturata in 4 moduli, organizzati in lezioni teoriche e laboratori di pratica, che permetteranno ai partecipanti di affrontare tematiche legate alla digital economy, al valore d’impresa (economics & performance), al project management (gestione progetti, vendita a valore, metodologie agili) e all’ambito del people value (comunicazione in azienda, team work e problem solving).

Un ruolo importante nel percorso di training sarà svolto dai Dedagroup People, che saranno coinvolti sia durante le sessioni teoriche sia in qualità di coach, promuovendo il trasferimento di know-how, la diffusione di valori, cultura ed esperienze. Ogni partecipante sarà infatti seguito, per tutta la durata del corso, da un tutor dedicato.

Infine, la novità di questa edizione è l’opportunità offerta ai partecipanti di accedere ai percorsi di sviluppo interno già a disposizione dei collaboratori Dedagroup. Si tratta di FIT Talk, faccia a faccia informali e interattivi con i grandi nomi della trasformazione digitale per parlare di futuro, idee e prospettive, e TECH Talk, webinar che promuovono la condivisione interna e la diffusione di tecnologie innovative. Fra i personaggi che hanno partecipato/parteciperanno ai FIT Talk vanno menzionati Carlo Purassanta, già CEO Microsoft Italy, Pietro Scott Jovane, CEO ePrice, l’Onorevole Stefano Quintarelli, Maria Chiara Carrozza, già Ministro dell’Istruzione, dell’Università e della Ricerca, e molti altri.

L'articolo Dedagroup alla ricerca di 24 giovani da formare nella Digital Economy proviene da Data Manager Online.

Nell’affrontare la problematica della digitalizzazione della fabbrica, dichiara l’ICT director di Gruppo Brembo, Paolo Crovetti, sono state individuate quattro macro categorie progettuali: la Digital Infrastructure, l’Automation, i Digital Assets e i Media. «La tumultuosa convergenza tra il mondo OT (Operational Technology) e quello IT ci ha dato l’opportunità di ripensare tutte le componenti dell’infrastruttura informatica in funzione dei nuovi prodotti e servizi. Per questo motivo, abbiamo sviluppato progetti di digitalizzazione delle macchine utensili installate in Brembo, rendendole in grado di supportare le esigenze degli attuali e dei futuri centri di lavoro della fabbrica: una produzione totalmente over IP».

[amazon_link asins=’0393254291,B01FIXMQ00,0307887898,0061766089,0393634639,B06XC81DKV,B010CLU1LY,B009NOYTIS,1521134367,B00M0ILXD8′ template=’ProductCarousel’ store=’dmo0e-21′ marketplace=’IT’ link_id=’df4ce70d-16e9-11e8-91e1-59efbf0953c0′]

Viste digitali sui prodotti

Le macchine utensili, attuali e future, del parco installato Brembo sono di fatto considerate e gestite come appliance IT, governate in rispetto delle best practice e dotate di tutta la suite di software necessaria a proteggerle da qualsiasi minaccia di attacco interno ed esterno. «Una evoluzione – precisa Crovetti – facilitata da un approccio collaborativo tra clienti e fornitori di macchine utensili, che supera la sterile contrapposizione sulla proprietà del dato e si concentra piuttosto sul valore aggiunto che la condivisione può dare». Quali sono state le aree di maggior investimento? Oltre all’acquisizione di macchine e robot di nuova generazione, secondo Crovetti, il focus dell’ICT di Brembo insiste sul progetto di adattamento (“retrofitting”) dell’attuale parco installato. Con l’obiettivo non solo di raccogliere i dati dalle macchine, ma di trasformare le informazioni base in informazioni certe, contestualizzate. «Questa trasformazione del dato di prodotto, di processo e di supply chain, in “data asset”, è uno dei nostri sforzi principali e ci consente di realizzare veri e propri “media” informativi da cui gli utenti – dal conduttore della linea al C-level – possono ottenere risposte online sui fenomeni che avvengono in fabbrica e comprendere da un diverso punto di vista i processi operativi». Tutto, incluso lo sviluppo delle competenze che il capitale umano in Brembo deve necessariamente acquisire, è mirato a una trasformazione digitale che va oltre la creazione e il mantenimento di questi “data asset” e si completa ed evolve, mutando informazioni e documenti a supporto dei processi in fabbrica da una modalità di archiviazione e distribuzione elettronica ma ancora sostanzialmente analogica, a una struttura completamente digital e visual. «Siamo convinti, e abbiamo già evidenza di questo, che l’apprendimento per immagini, 3D e video, sia il mezzo per abbattere le barriere culturali e di linguaggio in un mondo globale».

Paolo Crovetti CIO @BremboBrakes #Industry40 Nuove connessioni
Click To Tweet

Cabina di regìa

Per coordinare le azioni a livello strategico, Brembo ha definito una “cabina di regìa” di C-level, con l’obiettivo di guidare, orientare le diverse organizzazioni nel viaggio di trasformazione digitale garantendo nel contempo la convergenza verso standard comuni a tutta l’azienda. La regìa del management è supportata da una tradizionale struttura di Project Management Office, alla quale fanno riferimento i project manager delle differenti unità organizzative – precisa ancora Crovetti – aggiungendo qualche dettaglio su come il suo gruppo sta affrontando il problema delle competenze esterne reclutate in affiancamento a risorse e skill di provenienza endogena. «Ci siamo avvalsi di competenze esterne per effettuare un benchmark con l’obiettivo di analizzare esperienze di trasformazione digitale all’avanguardia in Europa e negli USA, rivolgendoci ai partner anche per le competenze tecniche specialistiche di execution nelle aree “data asset”, “3D asset” e per le soluzioni tecnologiche presenti sul mercato nella categoria: data analytics, augmented reality e visual management». Ancora prematuro, afferma in conclusione il responsabile ICT di Brembo, valutare l’impatto produttività e time-to-market dei prodotti. Ma gli effetti dell’approccio 3D e data asset e il ritorno sugli investimenti sono già evidenti in termini di efficienza e qualità.

Visita il sito ufficiale del WeChangeIT Forum, i relatori, gli argomenti, aggiornamenti sulla edizione 2018 e la possibilità di Pre-Registrazione http://www.wechangeit.it/

L'articolo Macchine utensili over IP proviene da Data Manager Online.

La società padovana comunica di aver costituito Corvallis PMC Srl, attiva nelle soluzioni informatiche per il project management. L’operazione fa seguito all’ingresso del Gruppo Corvallis, con una quota del 51,1 %, nel capitale sociale di BMT Italia, società milanese attiva da oltre trent’anni nelle attività di project management. In Corvallis PMC (sigla di Project Management & Consulting) è stato inoltre conferito il ramo di azienda Soluzioni e Servizi per l’Enterprise Project Management (EPM) della Corvallis SpA. La nuova realtà occuperà complessivamente 35 risorse.

Alla presidenza della nuova società è stato chiamato Matteo Del Sole, figlio di Enrico Del Sole, uno dei fondatori nonché Amministratore Delegato di Corvallis Holding, che giunge alla nuova nomina dopo diversi anni di incarichi operativi nel gruppo.

«L’operazione – spiega Matteo Del Sole, presidente di Corvallis PMC – si inserisce nell’ambito di un più ampio progetto di ridefinizione e riorganizzazione industriale finalizzato a incrementare le attività di EPM anche tramite la creazione di un polo specialistico. La crescita delle attività di PMC procederà anche attraverso un graduale processo di internazionalizzazione».

Corvallis comunica inoltre di aver inaugurato a Tirana, in Albania, un nuovo polo produttivo che impiega oltre  30 persone. Si tratta del primo passo di un processo di internazionalizzazione che guarda all’est europeo. Questa struttura inoltre fungerà da supporto operativo per le attività del Gruppo in Italia e sarà al centro, nel medio periodo, di un progressivo e rilevante piano di rafforzamento.

L’agenzia di rating Cerved ha intanto confermato il giudizio A2.2 sul gruppo Corvallis, in una scala in cui A1 risulta il valore più alto, attestando fondamentali molto solidi e una elevata capacità di far fronte agli impegni finanziari.

L'articolo Corvallis investe nei servizi di Project Management e apre un nuovo polo in Albania proviene da Data Manager Online.

Se si parla di requisiti ai business stakeholder, cioè alle parti interessate nel business, si rischia di sentire affermazioni come: «Vorrei un altro schermo che mi mostri i totali di produzione giornalieri. Vorrei che Excel mi visualizzi le vendite per il trimestre precedente. Vorrei sapere quanti dipendenti nuovi si aggiungono ogni mese». Oppure, si sentono racconti come questo: «In qualità di direttore di produzione, vorrei uno schermo che mostri la produzione di ogni fabbrica in modo da vedere la produttività di tutti i nostri stabilimenti». In ciascuno di questi esempi, lo stakeholder sta esprimendo la soluzione da lui percepita per una qualche necessità inespressa. Ma non sappiamo perché lo stakeholder vuole i totali di produzione giornalieri, dato che non ha spiegato cosa farà con i dati di vendita. Solo quando si conosce il motivo per cui qualcuno sta chiedendo qualcosa, allora si è in grado di fornire un valore. Cioè, è possibile fornire una soluzione che corrisponda alla reale esigenza di business, anche se la vera necessità è ancora inespressa. In questo senso, qualsiasi soluzione che non soddisfa un bisogno reale è uno spreco di risorse.

#RequirementsProcess Che cosa significa valore? @techtran
Click To Tweet

Ascoltare le richieste

Bisogna quindi prendere in considerazione il motivo per cui vengono chieste soluzioni, e cosa si può fare per arrivare alla reale esigenza. In primo luogo, è abbastanza naturale per un essere umano chiedere una soluzione che sia vicina alla propria realtà tangibile. Se si sta progettando un viaggio si è più propensi a dire: «Prendiamo l’autobus delle 9.30» – invece di dire – «Voglio spostarmi da casa al lavoro con mezzi di trasporto che mi portino in tempo al meeting delle 10.15». Qui il punto è che si parla in termini tangibili invece che per astrazioni. Uno skill chiave di business analysis è quello di ascoltare le richieste degli stakeholder, e poi applicare il pensiero analitico e sistemico per scoprire la reale esigenza. E questo scopo si raggiunge soprattutto chiedendosi perché: «Perché avete bisogno dei totali di produzione giornalieri? Per confrontare le unità prodotte con quelle vendute? E poi cosa ne farete? Per regolare il ciclo produttivo della prossima settimana in modo da coprire le previsioni di vendita»?

Il risultato di questa conversazione è che l’analista comincia a comprendere la reale esigenza di business: «In qualità di responsabile di produzione, posso confrontare le unità prodotte ogni giorno con quelle vendute, in modo da sapere come regolare il ciclo produttivo per la prossima settimana e assicurare che siamo in grado di soddisfare tutti gli ordini dei nostri clienti». Va anche notato che adesso vengono usati termini come “posso” invece di “voglio”, dove “posso” indica un bisogno, mentre “voglio” suggerisce una soluzione.

#TechnologyTransfer Suzanne Robertson sarà a Roma 17-19 ott per @techtran
Click To Tweet

Fornire valore di business

Applicando il pensiero analitico e sistemico, il business analyst scopre cosa può fornire valore al business. Anche se può sembrare strano, spesso gli stakeholder non chiedono direttamente valore di business, e lo fanno per molteplici ragioni. Gli stakeholder pensano in termini di come le cose vengono fatte ora. Non sanno cosa è possibile. La mentalità a silos mette pareti intorno al loro modo di pensare, rendendo difficile vedere il quadro più ampio. Pensano in termini di come fare qualcosa, invece che di quello che deve essere fatto. Il loro pensiero è centrato su se stessi, invece che sul business complessivo. In considerazione di tutto questo, l’analista di business può (e deve) chiedere perché la richiesta è stata fatta: comprendendone la ragione, il business analyst è in grado di fornire una soluzione che produce reale valore di business. Ma l’analista ha anche bisogno di esplorare altre possibilità di miglioramento del business. Per esempio, dovrebbe suggerire idee innovative per migliorare la policy di business esistente: anche se il business analyst non la determina, può però fare raccomandazioni in modo che gli stakeholder di business siano in grado di scegliere le innovazioni che forniranno il massimo valore.

L’analista deve quindi chiedere agli stakeholder: «Quanto sarebbe utile essere in grado di fornire una soluzione che offre un ciclo di produzione giornaliero rettificato al fine di evitare ordini inevasi? Quanti ordini sono inevasi in questo momento? Quanto ci costano questi ordini inevasi? Ci sono altri fattori che causano ordini inevasi? Potrebbe essere utile correlare il programma di produzione con le consegne dei materiali da parte dei fornitori»? Queste domande indicano che l’analista di business sta usando il pensiero sistemico per trovare le reali esigenze, guardando all’intera attività e all’effetto di ciascuna parte sulle altre. È solo trovando la reale esigenza che la soluzione ottimale può essere realizzata. La soluzione ottimale è quella che corrisponde alle reali esigenze e fornisce il massimo valore di business per il suo costo.

La scoperta dei bisogni reali è responsabilità dei business analyst, ma la scelta della soluzione ottimale è di solito responsabilità degli stakeholder: operando insieme, entrambi possono garantire che stanno fornendo il massimo valore di business.

#TechnologyTransfer James Robertson sarà a Roma 20-21 ott 2016 per @techtran
Click To Tweet

James Robertson

Consulente, insegnante, autore e project leader. La sua opera nel campo della Business Analysis e della raccolta dei requisiti è apprezzata in molte parti del mondo. È co-autore di “Mastering the Requirements Process”, “Requirements-Led Project Management” e dell’approccio Volere per l’engineering dei requisiti. È anche fondatore dell’Atlantic Systems Guild, un think thank conosciuto in tutto il mondo per le sue tecniche innovative di systems engineering.

Suzanne Robertson

Principal dell’Atlantic Systems Guild. Indiscussa autorità nel mondo della system analysis e requirements modeling. È co-autrice con James Robertson di “Complete Systems Analysis: the Workbook, the Textbook, the Answers” e di “Mastering the Requirements Process”. È roving ambassador per il Reuse Group della British Computer Society e ha fatto parte del comitato per Object Technology 97.

Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” il 17-19 ottobre 2016 e James Robertson terrà sempre a Roma il seminario “Mastering Business Analysis” il 20-21 ottobre 2016.

L'articolo Che cosa significa “valore” per un business analyst? proviene da Data Manager Online.

Doppio anniversario nel 2014 per Piteco (www.pitecolab.it), società milanese attiva nell’ambito della gestione della tesoreria e della finanza per le medie e grandi imprese.

La società, nella sua ragione sociale attuale, nasce infatti nel 2004, mentre la soluzione originaria, e tuttora presente con successo sul mercato grazie alle evoluzioni che si sono succedute nel corso degli anni, risale al 1984. Oggi, Piteco è la prima società in Italia nell’ambito della progettazione e implementazione di soluzioni gestionali in area tesoreria e finanza, con più di 2.500 clienti, un fatturato di 11 milioni di euro, in crescita costante del 10% all’anno, 80 persone e sedi a Milano, Roma e Padova.

Trenta anni di soluzioni

«Siamo sul mercato dalla metà degli anni Ottanta, quando sviluppammo un sistema informativo di tesoreria, che fu tra i primi prodotti specifici realizzati in Italia» – esordisce Paolo Virenti, amministratore delegato di Piteco. Il nome della società è l’acronimo di PIanificazione TEsoreria COmputerizzata, un termine – quest’ultimo – che all’epoca aveva una connotazione d’avanguardia, come tutto quello che era “computerizzato”. In trenta anni, che per l’informatica corrispondono a molti di più, Piteco ha seguito e anticipato tutte le evoluzioni tecnologiche. «Inizialmente, la nostra soluzione operava sui mainframe IBM, presenti presso i nostri primi clienti, che erano soprattutto grandi aziende come Bosch, Pirelli, Rizzoli-Corriere della Sera, RAI e tanti altri di queste dimensioni – prosegue Virenti – poi siamo passati a una versione per i midrange Sistema 36 e AS/400, fino ad arrivare alla decisione strategica, adottata a metà anni Novanta, di integrare la nostra soluzione con il mondo SAP, che all’epoca era come noto il sistema ERP di riferimento e che non aveva un modulo interno di tesoreria». Le aziende che passavano a SAP avevano l’esigenza di una soluzione che coprisse anche la gestione della tesoreria, che costituisce uno degli aspetti fondamentali della vita quotidiana di un’impresa, per connettere i sistemi contabili aziendali con le banche e gli altri soggetti operanti in ambito finanziario, omogeneizzando dati e informazioni di natura economica e finanziaria.

Vincere nella consulenza

«La scelta di andare verso SAP è stata la chiave di svolta per la nostra società, e ci ha consentito di imporci sulla concorrenza, gettando le basi per una leadership che continua tutt’oggi e che ci vede presenti sul mercato con servizi di consulenza di alto livello e con una gamma di prodotti allargata, tra cui spiccano Piteco Evo, che si integra con tutti i più diffusi sistemi ERP, e la soluzione CBC, per la gestione di workflow autorizzativi e flussi dispositivi interbancari» – spiega Virenti. Il riferimento alla consulenza, che riguarda soprattutto l’ambito della riorganizzazione dei processi di tesoreria, non è casuale, visto che si tratta di un ambito dal quale Piteco ricava oggi il 25-30% del proprio fatturato: «Una quota significativa che ci differenzia notevolmente sul mercato e che premia il nostro approccio, fondato su una metodologia specifica di project management, mutuata anche dall’esperienza compiuta operando fianco a fianco con le grandi società di consulting». È anche per questo che tra i clienti attuali di Piteco ve ne sono molti che risalgono a quando la soluzione faceva i suoi primi passi sul mercato. «Anche la fidelizzazione dei nostri clienti, che appartengono a tutti i settori di business, a dimostrazione della trasversalità e dell’adattabilità delle nostre soluzioni, costituisce un ulteriore elemento di differenziazione, ma soprattutto ci rende molto orgogliosi, per la consapevolezza di poter offrire prodotti validi e soluzioni ritagliate specificamente sulle esigenze dei nostri clienti, oltre che servizi di assistenza sempre in grado di fornire risposte in tempi rapidi e con competenza» – dichiara Paolo Virenti. «Ma soprattutto, le nostre offerte sono sempre caratterizzate da elevati livelli di innovazione tecnologica e funzionale, oltre che nella tesoreria, anche nelle aree della pianificazione finanziaria, del risk management e del reporting finanziario».

Soluzioni innovative

I prodotti e l’innovazione di Piteco vengono illustrati da Nicola Thurner, responsabile Ricerca e Sviluppo della società. «Al nostro interno si trova una Factory formata da 30 persone, 20 delle quali sono dedicate allo sviluppo, per essere sempre in grado di fare ricerca e innovare. Non vi sono altre aziende nel nostro settore capaci di mettere in campo un gruppo di queste dimensioni e anche questo è un elemento premiante sul mercato». Su tutte le proposte della società, spiccano in particolare Piteco Evo e Piteco CBC. Prima di analizzarle da vicino, bisogna rimarcare che Piteco ha da tempo «adottato l’ambiente di sviluppo .Net di Microsoft, realizzando un’architettura dei prodotti basata interamente sui servizi» – come sottolinea Thurner. Più in dettaglio, Piteco Evo costituisce la declinazione più recente del prodotto glorioso della casa, ed è riconosciuta come l’unica soluzione informatica in grado di integrare il sempre più complesso panorama delle soluzioni gestionali che vengono utilizzate nelle aree Amministrazione, Finanza e Tesoreria. Caratterizzato dalla massima scalabilità e da una struttura modulare, Piteco Evo costituisce un importante supporto nella gestione finanziaria e aiuta le aziende nell’automazione di processi informativi articolati, svolgendo un ruolo di collegamento tra il mondo bancario e il mondo aziendale, salvaguardando l’integrità dell’informazione gestita. Inoltre, grazie all’automazione dei processi, è possibile gestire modelli di tesoreria per singole società e organizzazioni di tesoreria complesse su diversi livelli utilizzando la medesima installazione.

Gestire i flussi verso le banche

Piteco CBC, acronimo di Corporate Banking Communication, rappresenta invece una soluzione per la gestione in totale sicurezza dei flussi di dati verso le banche, con automazione completa dei workflow autorizzativi, gestione sicura dei flussi dispositivi e completa indipendenza dai servizi di remote banking. Riguardo a Piteco CBC, è da sottolineare in particolare la gestione della sicurezza, soprattutto in ordine alle autorizzazioni a trattare i flussi finanziari, che nelle aziende sono in capo a specifici soggetti, usualmente di profilo elevato e che tendono talvolta a delegare agli assistenti le funzioni più routinarie, anche se si tratta di aspetti delicati. Per ovviare a possibili inconvenienti, Piteco ha «sviluppato specifici connettori verso le controparti bancarie, che operano in modo da ridurre le complessità e colmare i gap di autorizzazione, senza però perdere di vista la sicurezza» – spiega Thurner. Ma non solo: questa piattaforma può anche essere gestita via smartphone e tablet, in modo da minimizzare ulteriormente la possibilità che le funzioni autorizzative siano delegate agli assistenti.

Futuro anche all’estero

«Le aziende come la nostra continuano a vivere e a prosperare se fanno ricerca e se si rivolgono verso l’estero» – sintetizza Virenti. Se la ricerca continuerà a progredire senza sosta, con un’attenzione particolare verso il mondo delle soluzioni mobile, il 2014 si pone come l’anno della svolta anche per l’estero. «Finora la nostra presenza fuori dall’Italia ha riguardato le attività volte a seguire quelli tra i nostri clienti che avevano necessità di supporto per le loro operazioni estere, ma quest’anno inizieremo ad avere una presenza diretta in altri paesi, a cominciare da Francia e Stati Uniti, dove sono state inaugurate le filiali di Dedagroup ICT Network, il Gruppo di 11 aziende italiane specializzate in ICT di cui facciamo parte» – dichiara Paolo Virenti.

L'articolo La gestione della tesoreria. Fare i conti con Piteco proviene da Data Manager Online.

by Aaron Shenhar 

Se la guida “Project Management Body of Knowledge” (PMBOK) e la certificazione PMP del Project Management Institute (PMI) sono elementi importanti e necessari per la professione, sembra che le tradizionali competenze di project management non siano più sufficienti per le attuali esigenze dinamiche e innovative di business. I progetti sono più che mai complessi, mutevoli e incerti. Inoltre, sono fortemente influenzati dal contesto economico e dall’innovazione, e si trovano ad affrontare maggiori pressioni in termini di tempi. Ma non solo: nessun progetto si completa esattamente come previsto e il criterio “one size fits all” non è più valido. E – dato che poche di queste nuove realtà sono affrontate dal tradizionale approccio di project management – la domanda è: cosa c’è di nuovo nel project management? In primo luogo, centrare i tempi, il budget e gli obiettivi del progetto non ne garantisce il successo. Salvo che il progetto non abbia raggiunto gli obiettivi di business, non si può dare per scontato che la missione sia compiuta. Ed è per questo che i progetti devono essere visti come attività connesse al business e devono essere gestiti con una mentalità strategica per raggiungere i risultati di business.

Una seconda evoluzione consiste nel fatto che si comincia a vedere il ruolo del project manager come quello di un leader, che deve creare una visione per la motivazione e l’ispirazione del team. Infine, molti progetti di oggi comprendono l’innovazione, e i project manager devono imparare a distinguere tra i diversi tipi di innovazione e adattare il loro progetto al contesto e all’ambiente specifico. L’agilità è solo un passo in questa direzione, perché è anche necessario imparare a coniugare la gestione dell’innovazione nel project management e scegliere il giusto approccio per ogni progetto.

La nuova generazione del PM

 La nuova generazione del PM trasformerà i project manager in leader che devono affrontare gli aspetti strategici e di business dei propri progetti, costruire una visione per ispirare e motivare il loro team divertendosi e saper adattare il progetto al suo specifico livello di innovazione. Il nuovo mondo del project management può essere illustrato da uno schema nel quale in cima al PM tradizionale si pongono tre nuovi strati: l’approccio dinamico all’innovazione, la prospettiva della leadership ispirata e l’approccio strategico focalizzato sul business.

L’approccio Strategic Project Leadership (SPL, un marchio registrato) rappresenta questo nuovo mondo, ed è stato realizzato sulla base del project management tradizionale nel corso di venti anni di ricerca e di lavoro con le aziende. Con l’approccio SPL le organizzazioni sono aiutate ad affrontare l’innovazione in modo dinamico e adattivo, concentrando i loro progetti sui risultati di business attraverso la creazione di valore e di vantaggi competitivi sul mercato. Questo approccio integrato e già sperimentato, oltre che premiato dal PMI, combina le esigenze di business dei progetti, gli aspetti operativi necessari per svolgere il compito e la prospettiva di leadership per ispirare e motivare la squadra. L’approccio SPL consente ai team di progetto di integrare la Strategic Project Leadership nelle loro pratiche attuali, aggiungendo nuove competenze in cima alle aree di competenza del PMBOK esistenti.

In un precedente articolo, avevo previsto che la prossima generazione del PM avrebbe trasformato i project manager in leader che devono affrontare gli aspetti strategici e di business dei propri progetti, costruire una visione per ispirare e motivare il loro team di progetto e devono gestire correttamente il livello specifico di innovazione nel loro progetto. Ho descritto l’approccio Strategic Project Leadership (SPL) per la pianificazione e l’esecuzione di progetti focalizzati sul business e per adattare i progetti alla loro particolare innovazione. In questo articolo – invece – mostrerò in particolare come trattare con l’innovazione nel progetto, adattando il giusto stile di project management al grado appropriato di innovazione.

Il diamante dell’innovazione

 L’innovazione è definita come “la commercializzazione di un’idea”. L’idea diventa novità solo quando è implementata e utilizzata. Questo implica che non c’è innovazione senza un progetto, e ogni progetto è in realtà anche una novità. Tuttavia, la gestione dell’innovazione e il project management sono ancora trattati come due discipline distinte e sono affrontate da diverse comunità, pubblicazioni e conferenze. Il “Diamante dell’Innovazione” sta integrando l’innovazione e il project management in un solo modello unificato che consente di identificare i diversi tipi di innovazione e selezionare il giusto approccio di project management per ogni innovazione. Per esempio, poiché l’innovazione in un progetto di costruzione è diversa dall’innovazione nella realizzazione di un veicolo spaziale, ognuno di questi progetti deve essere gestito in modo diverso. La domanda è: «Come»? Il project management tradizionale e anche le recenti tecniche agili non forniscono risposte chiare.

Modello a quattro dimensioni

 Il “Diamante dell’Innovazione” è una figura che può offrire un quadro di riferimento per l’analisi del contesto innovativo specifico di un progetto, per scegliere il giusto stile e pianificare il progetto per renderlo di successo. Il modello comprende quattro dimensioni che caratterizzano l’innovazione di un progetto. Ogni dimensione è classificata in quattro tipi di progetto, con diversi livelli di impatto, portando a differenti stili ottimali di gestione.

Innovazione di mercato – Quanto nuovo è il prodotto per il mercato e gli utenti. Riguarda gli sforzi e il tempo necessari per definire chiaramente i requisiti del prodotto. L’innovazione di mercato è suddivisa in quattro tipologie: derivativa, piattaforma, nuova per il mercato, nuova per il mondo.

Innovazione tecnologica – Quanto è utilizzata la nuova tecnologia. Riguarda il numero di cicli di progettazione necessari e il tempo necessario prima di congelare il progetto. La tecnologia ha i seguenti livelli: low-tech, medium-tech, high-tech, super high-tech.

Complessità – Livello di innovazione di sistema, individuato dalla complessità del prodotto o dell’organizzazione. La complessità riguarda il grado di formalità e di coordinamento necessari per gestire in modo efficace il progetto. Ha questi livelli: materiale/componenti, assemblaggio/sottosistema, sistema, array.

Urgenza dell’innovazione – Riguarda la gestione del tempo e l’autonomia del team di project management. Ha questi livelli: normale, rapido/competitivo, time critical, blitz.

Il contesto del progetto

 Il Diamante dell’Innovazione descrive ogni contesto del progetto, e i livelli specifici determinano quello che è lo stile migliore per il progetto. Inoltre, aiuta ad analizzare le difficoltà del progetto, pianificare le giuste risorse e gli orari, calcolare le tolleranze e gli imprevisti – e infine – aiuta anche a rimettere in carreggiata un progetto in difficoltà.

Per saperne di più: www.splwin.com

Aaron Shenhar

Dopo aver operato a lungo nel settore della difesa, Aaron Shenhar è stato professore di ruolo in diverse università, dove ha istituito nuovi programmi accademici, tra cui i programmi di project management presso la Stevens e la Rutgers University. È uno degli autori più pubblicati e citati nell’ambito del project management. Ha lavorato come consulente per grandi aziende come 3M, Honeywell, Intel, NASA, Dow Jones & Co., US Army e Tata. È anche co-autore del recente “Reinventing Project Management”, l’unica opera sull’argomento pubblicata dalla Harvard Business School Press e selezionata tra i primi cinque migliori libri di business di quest’anno.

Aaron Shenhar presenterà a Roma per Technology Transfer i seminari: “The Strategic Project Leadership Program: la nuova generazione di Project Management” il 9-11 dicembre 2013 e “Mastering Project Leadership” il 12-13 dicembre 2013.

L'articolo Cosa c’è di nuovo nel project management? proviene da Data Manager Online.

“Quando sono in ritardo per andare in aeroporto, dico al tassista ”raddoppio il prezzo della corsa se riesce a non farmi perdere l’aereo”. Nove volte su dieci, arrivo in tempo. Se faccio una proposta simile al mio Direttore IT, finisco col pagare tre volte più caro sforando comunque la scadenza prevista!”

Ecco come uno dei nostri clienti, il CEO di una grande banca europea, si è espresso durante il nostro primo incontro.

Questo fenomeno è confermato dal noto studio di Standish Group: in media il 29% dei progetti informatici in azienda ha successo, nelle grandi aziende solamente il 9%. Si oltrepassano i budget, non si rispettano le scadenze, con conseguenti penali per il ritardo, e la qualità ne soffre. In certi casi, a fine progetto, il progetto viene anche rifiutato dal cliente perché non risponde più alle sue necessità.

Noi ci miglioriamo, ma troppo lentamente. Senza un cambiamento radicale nella maniera di gestire i nostri progetti informatici, ci vorranno ancora due generazioni prima di essere in grado di condurre dei progetti IT di successo al primo colpo … con un po’ di fortuna.

Lo studio indica inoltre che più della metà dei progetti IT costa in media due volte più caro rispetto al preventivo iniziale. Ovviamente, questo non è comprensivo dei costi addizionali derivanti dalle opportunità perse, che sono di difficile misurazione, ma che potrebbero essere nell’ordine di milioni di euro.

Di recente, ho analizzato un campione di una ventina di progetti IT di medio-grande dimensionamento ed emerge lo stesso tipo di problema: ritardi di consegna da 30 a 100% rispetto alle scadenze iniziali. Il Lead Time di un progetto è definito come il periodo fra la data della richiesta del cliente e la data in cui viene accettato come completo.

Al problema del ritardo, si aggiungono lamentele dei Direttori dei Sistemi Informatici (DSI): “Non c’è trasparenza sui nostri progetti informatici”, “i nostri team sono mal organizzati” e, ancora, “abbiamo la sensazione di essere continuamente in una situazione di crisi. Durante le nostre giornate non facciamo altro che gestire le emergenze legate alle lamentele di clienti insoddisfatti ”

Osservando sul campo le operazioni dei team IT (il cosiddetto “Gemba”, secondo il linguaggio della Lean) ci rendiamo conto che certi problemi si presentano continuamente:

• Affidabilità delle specifiche, senza una chiara comprensione dei problemi del cliente

• Una visione frammentata del progetto

• Mancanza di sincronia tra i differenti attori del progetto

• Schede progetto non corrispondenti alla realtà perché realizzate senza il coinvolgimento degli operativi sia nella fase di stima che in quella di pianificazione

• Identificazione tardiva dei problemi (ritardi, errori, “not right first time”)

• Turnover in seno ai team con conseguente perdita d’expertise

• Scarso coinvolgimento dell’utilizzatore finale

L’approccio Lean

L’approccio Lean permette di aggredire queste ed altre tipologie di problemi e si effettua in quattro tempi:

1. Visualizzare la produzione per rilevare i problemi

2. Reagire immediatamente

3. Risolvere i problemi uno per uno

4. Migliorando i metodi di lavoro

Tale approccio non è un’azione puntuale di miglioramento, quanto, piuttosto, un sistema di gestione che si applica sul campo quotidianamente. Lo spirito di collaborazione è assolutamente cruciale per implementare questa maniera di lavorare. Le persone del team svilupperanno delle nuove prassi lavorative, delle nuove azioni e dei nuovi strumenti che garantiranno l’efficacia operativa sul lungo periodo.

1. Visualizzare la produzione per rilevare i problemi

La prima tappa del metodo Lean è la visualizzazione della produzione. Nella Lean ciò che permette di visualizzare la produzione nei progetti informatici è l’Obeya, la gestione visiva del progetto. L’Obeya, termine giapponese che significa “grande stanza”, è uno spazio nel quale sui muri si affiggono tutte quelle informazioni che permettono di condurre efficacemente i progetti e di ridurre il “time-to-market” dei suoi prodotti.

Ogni giorno, i rappresentanti di tutti i team che partecipano al progetto si riuniscono nell’Obeya per sincronizzare le loro attività e trattare rapidamente i problemi prima che questi possano compromettere il raggiungimento degli obiettivi.

Presso la Toyota, l’Obeya è utilizzata nella fase di concepimento di prodotti e nella gestione dei progetti. Le riunione nell’Obeya viene condotta dall’ingegnere capo e dal rappresentante di ognuna delle differenti attività chiave (ricerca, sviluppo, QA, ecc). L’ingegnere capo indica una chiara direzione progettuale, si assicura del buon seguito degli indicatori di performance, dell’osservanza dei piani d’azione e delle scadenze, del rispetto della qualità e della risoluzione dei problemi identificati di volta in volta.

L’Obeya non si rivolge ad un’attività o ad un contesto particolari. Nei progetti informatici, l’animatore dell’Obeya potrebbe essere il Direttore IT o un responsabile del progetto. I partecipanti ad un progetto di sviluppo informatico di media dimensione potrebbero essere il marketing, i gestori del prodotto, gli sviluppatori, i tester, gli integrator e la produzione informatica.

In generale, i team si riuniscono regolarmente nell’Obeya in maniera che tutti siano aggiornati. Il team si incontra:

• Al mattino per circa quindici minuti (il cosiddetto flash meeting). Ogni partecipante aggiorna gli indicatori e il planning dei rispettivi team, presenta gli obiettivi della giornata del proprio team e condivide quei problemi operativi che possono avere un impatto sul progetto.

• Una volta alla settimana viene pianificata la settimana successiva, ciò che permette di dare al progetto un ritmo di consegna cadenzato, vengono sincronizzati i piani d’azione, condivise le “lessons learned” (lezioni apprese), aggiornati gli indicatori settimanali e risolti i principali problemi.

• In maniera puntuale, per risolvere dei problemi bloccanti.

2. Reagire immediatamente:

Di fronte ad un incidente o un errore, ci si ferma (“stop the line”). Si corregge/ripara immediatamente l’incidente per riuscire a proteggere il cliente.

3. Risolvere i problemi uno per uno:

Durante il flash meeting quotidiano, il team segnala i gap di performance evidenziati dagli indicatori e dai piani d’azione, e condivide i problemi del giorno prima. Dopo il flash meeting, ai problemi vengono attribuite delle priorità; le criticità vengono segnate e scritte sul foglio della risoluzione dei problemi e affrontate uno per uno seguendo rigorosamente l’approccio del Plan Do Check Act (PDCA), il processo interattivo di risoluzione dei problemi ideato da Deming e d’ispirazione scientifica:

1. Identificare e misurare il problema

2. osservare il problema sul campo

3. trovare le ipotetiche cause attraverso brainstorming in seno al team

4. sperimentare localmente, su scala ridotta

5. misurare i risultati/verificare le ipotesi

6. trarre gli insegnamenti, cambiare le pratiche e metodi lavorativi e ricominciare nuovamente

4. Migliorando i metodi di lavoro:

I membri del team, tutti insieme, verificano se le loro azioni di risoluzione dei problemi hanno portato dei frutti. Se è il caso, allora mettono in piedi dei nuovi standard di lavoro, cioè, creano delle nuove prassi lavorative che vengono poi condivise con i restanti attori del progetto.

Testimonianza di un progetto

L’esempio che verrà presentato qui di seguito è quello relativo ad un team di sviluppo di applicazioni web di una grande banca europea. Questo team deve gestire circa trenta progetti all’anno. Ha deciso di costruire un’Obeya per fare fronte all’emergenza progettuale. Chiameremo questo team il “webteam”.

Il webteam è composto da 10 persone, tutte sul posto. E’ stato creato come alternativa al normale processo di sviluppo IT e gode di una grande indipendenza. Ha per missione quella di rispondere efficacemente alle richieste puntuali provenienti dalla rete di agenzie su dei nuovi strumenti web o degli strumenti esistenti migliorati. Il suo valore è legato alla capacità di consegnare rapidamente delle applicazioni rispondenti esattamente ai bisogni delle agenzie, in meno di 4 mesi per le richieste più complesse. Gli obiettivi stabiliti dal Direttore IT sono di 10 consegne nell’anno in corso (da marzo a dicembre) e di 30 per l’anno successivo (da gennaio a dicembre).

Nella foto qui sotto, un team di sviluppo informatico, simile al web team. Cosa succede?

Niente di anormale, direte voi. Ed invece, questo team è al limite di una crisi.

Come lo si può vedere? Ebbene, giustamente non vediamo niente ed è proprio questo il punto. Non si vede come procede il progetto, né lo stato di soddisfazione dei clienti. Altro sintomo evidente di un team in difficoltà: le persone intervistate non sono neppure a conoscenza dell’andamento dei loro progetti, e, da ciò che emerge dalle interviste fatte, non sembrano rendersi conto della situazione critica nella quale si trovano. Né tantomeno conoscono i loro clienti. D’altra parte, i clienti percepiscono in maniera palese che la situazione è ben distante dall’essere soddisfacente.

Da settembre del primo anno era stata consegnata solamente un’applicazione mentre le altre erano in ritardo di consegna di parecchie settimane ed anche di mesi. La qualità del team webteam (misurata dal numero di rilavorazioni richieste prima che il cliente accetti l’applicazione) ne stava chiaramente soffrendo.

Il team non aveva consapevolezza di avere un problema né tanto meno aveva la percezione di essere in ritardo: “è il cliente che domanda ogni giorno sempre più, stiamo cercando di soddisfare le sue richieste”. D’altro canto, la maggior parte dei clienti diceva che le versioni consegnate erano incomplete, contenevano errori e che i ritardi di consegna erano troppo alti.

Il web team ha così deciso di mettere in piedi il metodo Lean e creare la propria Obeya per risolvere i propri problemi. Qui di seguito le principali azioni intraprese:

1. Visualizzare la produzione per rilevare i problemi:

La prima settimana il web team ha affisso al muro le informazioni necessarie per costruire la prima Obeya. E’ stata affissa la “voce del cliente” creata durante il workshop Kaizen, il back log dei progetti, un nuovo macro planning, un “task board” per seguire la produzione giornalmente, diversi indicatori di performance concepiti durante il workshop (ritmo della consegna, errori, carichi di lavoro) ed infine un cartellone con tutti gli incidenti di produzione.

Hanno inoltre aggiunto il foglio della risoluzione dei problemi (alla fine del progetto un’intera parete della stanza era utilizzata per la risoluzione dei problemi). Gradualmente, il team ha integrato altri elementi utili per l’Obeya, come il “red basket” per mettere in evidenza i problemi di qualità, il “customer sastisfaction survey” ed il box dei suggerimenti.

Il team ha fatto ricorso a degli strumenti poco costosi e di facile utilizzo (post-it, lavagne).

Nelle foto qui sotto, potere vedere la prima versione dell’Obeya costruita dal web team. Successivamente la loro Obeya è stato ulteriormente sviluppata:

2. Reagire immediatamente:

Tutti gli incidenti sia in ambiente di test che in produzione sono immediatamente evidenziati nei “red basket” e analizzati con priorità. Nelle foto qui di seguito, potete vedere due incidenti di produzione che sono identificati e aggiunti nel taskboard per essere trattati prima di ogni altra cosa dal primo sviluppatore disponibile. Non appena l’incidente è categorizzato come “bloccante”, un esperto interrompe il proprio lavoro per risolvere il problema, in generale con il supporto del team leader.

3. Risolvere i problemi uno per uno:

Nell’esempio qui sotto, a sinistra, il team segnala diversi ritardi di uno dei progetti sul planning. Identifica delle ipotesi delle cause del ritardo: “non comprendiamo bene le specifiche dei clienti e attendiamo a lungo dei chiarimenti da parte loro”.

Il team segna con una croce ogni volta che c’è un ritardo e ne attribuisce una causa.

Dopo qualche sperimentazione locale mirante a migliorare la maniera con la quale raccogliere e capire i bisogni dei clienti, il problema è quasi scomparso. Il punto chiave è ovvio (linea verticale in nero) e conferma che il team ha trovato una soluzione efficace.

4. Migliorando i metodi di lavoro:

Completando i cicli di risoluzione dei problemi, il team ha tratto numerosi insegnamenti e ha cambiato i propri metodi lavorativi. A titolo di esempio, a seguito dell’analisi dei problemi legati al ritardo sul planning, pocanzi descritto, e dopo diverse soluzioni sperimentate, il team ha radicalmente modificato la maniera di raccolta delle necessità dei clienti.

Allo stato attuale, il webteam segue uno standard semplice ma preciso che ha creato in collaborazione con i clienti e che ha affisso sui muri dell’Obeya. Questo standard richiama ad un ciclo di sviluppo interattivo, demo sistematiche con i clienti, l’uso di template e check-list durante il processo di raccolta delle richieste.

I risultati ottenuti dal webteam in tre mesi sono spettacolari:

• 8 applicazioni consegnate in novembre e un totale di 11 prima della fine di dicembre (obiettivi superati)

• Qualità: nessun incidente nel corso dell’ultimo mese di misurazione

• Tempi: in media, un’applicazione consegnata ogni 10 giorni, capaci di soddisfare le richieste del cliente (la cosiddetta frequenza “takt time”, secondo la Lean)

• Indice di soddisfazione cliente: +61%

• Costi: in media, l’80% delle ore-uomo sono state impiegate in attività a valore aggiunto per il cliente contro 50% all’inizio del progetto

Le condizioni necessarie per il successo

Trattandosi di un approccio dinamico e collaborativo, l’Obeya genera numerosi e scontati benefici. Consente di promuovere e sviluppare il teamwork, permette al team di vedere e risolvere i problemi molto rapidamente; è uno strumento di monitoraggio e riduce il “Lead Time” dei progetti. Sebbene i team percepiscano i suoi vantaggi, hanno spesso delle difficoltà ad integrare l’Obeya nella routine quotidiana.

Il webteam ha conseguito dei successi appropriandosi della metodologia Obeya per diverse ragioni: innanzitutto per la rapidità dei primi risultati ottenuti. In appena tre mesi il team è riuscito non solo a conseguire gli obiettivi stabiliti ma addirittura a superarli con 11 applicazioni consegnate anziché Grazie all’Obeya, il team ha rapidamente imparato ad identificare i “veri problemi”, ciò che rappresenta un decisivo fattore per il successo di ogni progettualità Lean. Tuttavia, per garantire la perennità del metodo Lean e per essere certi che sia applicato nel lungo periodo, è necessario il verificarsi anche di altre condizioni.

La prima s’incarna nel concetto di “sfida manageriale”: il Direttore IT e i manager del webteam hanno effettuato delle visite sistematiche nell’Obeya in modo da spronare il team sulle performance e per sostenerle nella risoluzione dei problemi operativi. Anche il CEO della banca ha visitato l’Obeya per costatare i progressi apportati dal progetto pilota. “Vedo finalmente la luce in fondo al tunnel”, ha dichiarato. Le visite regolari del Management costituiscono senz’altro un supporto necessario e motivano nel perseguimento del miglioramento continuo.

La seconda condizione è legata alla capacità del team di appropriarsi dell’approccio e di adattarlo al proprio contesto. Il webteam ha implementato la propria versione dell’Obeya. Ha scelto i propri strumenti di gestione, i propri indicatori di performance e sviluppato una reale autonomia e acquisito la capacità di innovare attraverso la risoluzione dei problemi. Il team ha imparato a “vedere” il cliente per capirne le necessità. Il team ha soprattutto sviluppato uno “spirito guerriero” che non possedeva in precedenza: il desiderio di lottare non solamente per i propri progetti, ma anche e specialmente nell’interesse dei propri clienti.

L'articolo Il successo dei progetti informatici grazie all’Obeya proviene da Data Manager Online.

EasyVista, uno dei principali attori europei del settore dell’IT service & asset management in SaaS, annuncia il rilascio di EasyVista 2012, una nuova versione ancora più performante con una focalizzazione customer-driven per aiutare i dipartimenti IT a definire, gestire e dimostrare il valore dei servizi IT nei processi di business, allineando l’IT alle iniziative strategiche, migliorando le prestazioni e fornendo costi certi e trasparenti.

EasyVista 2012 offre una gestione integrata del portfoglio e dei progetti IT e una nuova applicazione di Business Intelligence in modalità SaaS, oltre a una serie di miglioramenti come: la nuova interfaccia utente Web 2.0, l’ampliamento del supporto multilingue, la migliore configurazione codeless, l’estensione della gestione dei processi aziendali, le personalizzazioni definite dagli utenti e l’automazione dei workflow.

IT Project Management

EasyVista IT Project Management è stata sviluppata e integrata con le applicazioni IT Service, IT Asset e IT Financial Management della suite EasyVista, e include le best practice ITIL per offrire ai dipartimenti IT un controllo completo su tutto il ciclo di vita del progetto.

I moduli così integrati aiutano il dipartimento IT ad avere una visione unificata dei progetti e dei servizi e una visibilità completa del costo di ogni progetto, ottimizzando e tenendo traccia delle risorse e degli asset impiegati, attraverso la consegna puntuale del progetto. I clienti possono quindi beneficiare immediatamente di una migliore collaborazione e di una maggiore visibilità, riducendo al contempo i costi e i rischi legati al project management.

Tra le principali caratteristiche:

• migliore il controllo dei progetti IT di grandi dimensioni, come ad esempio l’implementazione di strumenti o software;

• accurate attività di planning e di budgeting;

• template “out of the box” per una rapida implementazione e adozione da parte degli utenti;

• identificazione e descrizione del progetto: scadenze, budget, risorse;

• pianificazione del progetto e assegnazione delle risorse: diagramma di Gantt;

• portfolio progetto: monitoraggio del budget attraverso rappresentazione grafica, scadenze, carico di lavoro e stato di avanzamento;

• impostazioni di notifiche “out of the box” su scadenze o elementi non tracciati;

• integrazione completa con i processi ITIL, inclusi asset, configurazioni, incidenti, cambiamenti, budget.

IT Business Intelligence in modalità SaaS

La nuova e potente applicazione IT Business Intelligence, erogata in modalità SaaS, offre una maggiore flessibilità e conoscenza del proprio business, per permettere ai dipartimenti IT di gestire in modo ottimale gli obiettivi strategici, fornendo al contempo i massimi livelli di servizio ai clienti.

EasyVista IT Business Intelligence consente di accedere alle principali informazioni relative all’infrastruttura IT, rappresentandole con grafici riassuntivi che consentono all’organizzazione di prendere le decisioni appropriate nel momento giusto. I servizi possono essere misurati e allineati facilmente, in un’ottica di continuo miglioramento.

Disponibile esclusivamente in modalità SaaS, si caratterizza per:

• best practice misurabili integrate, per allinearsi agli obiettivi strategici e di business;

• ROI, monitoraggio e tracciabilità delle performance;

• dashboard e scorecard;

• template “out of the box” per analisi multidimensionali con azioni drill-through e capacità di tracciare e gestire nel tempo sedi, risorse, livelli aziendali, business unit;

• funzionalità di simulazioni e scenari, per anticipare i rischi e attivare appropriate azioni correttive.

Miglioramenti nelle funzioni chiave

Interfaccia utente grafica

• “look and feel” migliorato, che permette all’utente di visualizzare e di accedere alle attività e alle to do list;

• smart tab con anteprima e sempre disponibili senza bisogno di cliccare;

• motore di visualizzazione ottimizzato con wizard rapidi visualizzati in base alle attività e alle preferenze dell’utente;

• caricamento dei documenti via drag & drop, integrando funzionalità e immagini personalizzabili.

Ambiente codeless e configuration engine

• usabilità migliorata con elenchi, viste dettagliate e menu colorati;

• visualizzazione grafica dei workflow;

• completa automazione con la creazione di worlkflow;

• nuova grafica drag & drop per un utilizzo semplice e veloce;

• nessuna conoscenza di scrittura codici o database richiesta.

Pianificazione del change management

• gestione dei periodi di blackout degli asset e dei servizi, al fine di evitare cambiamenti nei periodi critici per il business;

• nuova progettazione grafica delle richieste di cambiamento per rilevare potenziali conflitti nei cambiamenti stessi;

• nuovi wizard di simulazione per identificare potenziali conflitti tra i cambiamenti pianificati;

• agenda cambiamenti migliorata (FSC);

• invio di informazioni rilevanti per gli utenti, per consentire un facile utilizzo e una maggiore produttività.

Governance e Compliance

• estensione del supporto multilingue (12 lingue);

• conformità ai requisiti legali.

Una soluzione di IT Service Management completamente integrata

EasyVista 2012 supporta i processi IT chiave delineati da ITIL v3 e certificati da Pink Elephant: incident management, problem management, change management, configuration management e service level management. L’ultima release di EasyVista ha superato con successo la valutazione ITIL v3 ottenendo la certificazione PhinkVerify su 15 processi.

EasyVista è nativamente conforme alle best practice ITIL per offrire ai dipartimenti IT la possibilità di: implementare rapidamente una soluzione con un ottimo rapporto costo/prestazioni; gestire le risorse e gli asset IT; ottimizzare le competenze all’interno di una community di utenti e favorirne l’allineamento. Il risultato è una maggiore produttività, efficienza dei servizi IT e basso cost of ownership.

L'articolo EasyVista 2012: nuove funzionalità di Project Management e di IT Business Intelligence in modalità SaaS proviene da Data Manager Online.

Un nuovo approccio per costruire un gruppo di lavoro capace di portare a termine il progetto nei tempi necessari

by Larissa T. Moss 

All’interno di un team di progetto le attività di coordinamento, di assegnazione dei compiti, così come le attività di controllo e aggiornamento, sono tradizionalmente di competenza del project manager. Quest’ultimo è responsabile delle scadenze e di tutte le decisioni inerenti il progetto. I singoli membri sono invece responsabili delle attività loro assegnate e della relativa tempistica. Per esempio, l’analista dei requisiti raccoglie i requisiti applicativi per poi passarli alla persona che si occupa della modellazione dei dati la quale, a sua volta, ha il compito di creare la logica dei dati per poi girarla all’architetto del database che produce il modello fisico dei dati e, conseguentemente, le strutture di database; queste ultime vengono infine passate allo sviluppatore che ha il compito di creare l’applicazione.

Nel processo sopra descritto le uniche interazioni collaborative che coinvolgono l’intero team avvengono mediamente una volta la settimana, durante i consueti incontri che servono a fare il punto sull’avanzamento dei lavori. In progetti DW/BI, che devono essere realizzati in un timing compreso tra i 90 e i 120 giorni, un approccio di questo tipo si può rilevare inefficiente e di scarsa efficacia.

Project team di tipo self-organizing

Per riuscire ad affrontare con efficienza ed efficacia progetti agili DW/BI è utile ricorrere a un approccio Extreme Scoping in base al quale la funzione del project manager viene distribuita tra tutti i membri del team e non univocamente a un singolo project manager. Ne deriva un’organizzazione basata su un approccio definito self-organizing.

Core Team

Il core team dovrebbe prevedere un project manager di grande esperienza, un esponente della componente business in grado di prendere decisioni inerenti le politiche aziendali, una persona dell’enterprise information management (un data administrator esperto nelle discipline che riguardano la gestione dati quali modellazione logica, regole di normalizzazione, standard, tassonomia) e, infine, una persona con un profilo tecnico con grandi capacità tecnologiche e di programmazione che possa assumere responsabilità di lead developer o technical architect.

I membri del core team rappresentano il gruppo di gestione del progetto che sostituisce la funzione unica del project manager; devono essere in grado di gestire tutte le release software di un’applicazione in modo da assicurare continuità e mantenimento della conoscenza all’interno del progetto.

I core team sono team Swat (SoftWare Action Team) di tipo self-organizing. La loro peculiarità è caratterizzata dall’interazione tra tutti i membri. Ciascuno analizza il lavoro dell’altro, collabora sul rilascio dei progetti e assume decisioni. Sono previsti incontri giornalieri e, quando necessario, ciascun membro deve essere in grado di prendere in carico attività di altri membri. Il core team, infine, deve essere molto piccolo: la dimensione ottimale varia da 3 a 5 persone e non dovrebbe mai superare le 7 unità.

Development track team

I development track team sono delle estensioni del core team e non partecipano alle decisioni che vengono prese giornalmente in merito alla gestione del progetto. All’interno delle loro attività mantengono comunque delle funzioni simili a quelle del core team.

I più comuni track sono relativi ad attività ETL, sviluppo di applicazioni di BI, installazione e sviluppo di repository di metadata. Se il metadata non è una deliverable si devono prevedere almeno due paralleli development track team, primariamente ETL e sviluppo di applicazioni BI.

I development track team sono guidati dal lead developer o dal technical architect del core team. Si può anche scegliere di avere un lead developer o technical architect per ciascun development track se, compatibilmente con la disponibilità delle risorse, si ritiene che questo possa servire a supportare meglio l’organizzazione. I membri dovrebbero corrispondere a sviluppatori che hanno skill appropriati per il compito assegnato; la loro partecipazione deve essere mirata esclusivamente alla durata delle specifiche attività.

Un development track team deve essere ancora più piccolo di un core team: la dimensione ottimale deve comprendere 2 o 3 persone e non dovrebbe mai superare le 5 unità.

Extended team

I membri dell’extended team giocano un ruolo tradizionale e partecipano a progetti DW/BI in base alle esigenze e allo scheduling previsti. Non sono ingaggiati a tempo pieno, ma vengono coinvolti in alcune fasi del progetto; possono quindi essere chiamati a partecipare in modo intermittente in base alle necessità e ai loro skill. Tecnici e persone del business possono contribuire nello stesso modo in cui contribuiscono nei progetti tradizionali. Sono previsti ruoli di supporto con funzioni di tipo tecnico, operativo, di sicurezza, di auditing così come il coinvolgimento delle persone che, a livello business, sponsorizzano il progetto.

Il core team, il development track team e l’extended team costituiscono l’intero gruppo di progetto DW/BI.

BI Steering Committee

Il BI steering committee (comitato di coordinamento) è una componente di advisory costituita da business executives e senior business manager che comprendono le logiche BI e DW e che supportano attività estese a livello enterprise. I membri di questo gruppo si incontrano in modo regolare per discutere, pianificare, reclutare personale e trovare investimenti per iniziative business. Sono coloro che stanno dietro una determinata strategia DW/BI tesa a supportare i driver del business; finanziano il gruppo EIM per sviluppare iniziative di data governance in una dimensione enterprise globale; liberano persone del business dalle loro responsabilità operative in modo che possano partecipare al progetto del core team.

BI program manager

La gestione del programma di BI è guidata da un BI program manager che lavora direttamente con o per il BI steering committee. Il BI program manager svolge attività di assessment periodico volte a identificare nuove esigenze informative così come accertarsi della soddisfazione della componente business in merito al DW e alle applicazioni BI. Con il supporto dello steering committee, il BI program manager crea una strategia BI e rafforza le componenti di infrastruttura tecniche e non tecniche dell’ambiente BI. Lavorando con lo steering committee, il BI program manager assegna le priorità ai progetti BI/DW, determina le interdipendenze del progetto e coordina le risorse di progetto così come le attività che si creano attorno a queste interdipendenze.

L’interazione e la comunicazione del team

Le dinamiche di un team self-organizing sono diverse da quelle di un project team tradizionale. I membri del core team non sono infatti sempre presenti alle proprie postazioni. Collaborano, svolgono attività di brainstorming, risolvono problemi, prendono insieme decisioni nella war room dedicata al progetto; si incontrano giornalmente per analizzare lo stato e le derivable, discutere dei problemi e delle soluzioni possibili. Gli incontri possono durare solo dieci minuti, ma possono anche essere necessarie working session prolungate nel corso delle quali le attività dei singoli sono distribuite tra i vari membri del team, i quali lavorano su di esse il giorno stesso per poi fornire un report il giorno successivo.

Anche i membri dei development track team si incontrano giornalmente, ma solo per analizzare lo stato e le derivable all’interno del loro track: collaborano, fanno brainstorming, risolvono problemi, prendono decisioni su questioni inerenti il track di riferimento. La comunicazione con il core team, viene eseguita automaticamente dal lead developer o dal technical architect responsabile del development track team.

L’extended team, infine, si incontra con il core team una volta la settimana, di solito allo stesso giorno e alla stessa ora. All’avvio del progetto i membri del core team impostano lo scheduling degli incontri mentre sono gli sponsor a inviare le notifiche ai membri dell’extended team. Gli incontri possono avere la durata di un’ora o di soli dieci minuti, se non vi sono grossi problemi. L’obiettivo degli incontri settimanali è fare in modo che tutti i membri siano al corrente di tutto ciò che riguarda le attività del progetto.

Conclusioni

In sintesi, quando si vuole intraprendere un progetto agile di DW/BI si devono convertire i team di progetto tradizionali in team di tipo self-organizing. L’importante è tenere sotto controllo il numero dei membri, non eccedere nella dimensione. Tutte le attività di project management devono essere trasferite ai membri del core team e ci si deve garantire il coinvolgimento di un rappresentante della componente business. Il development track team deve prevedere 2 o 3 sviluppatori (per track, per project). Si deve inoltre fare attenzione nel coinvolgere i membri dell’extended team in base alle specifiche necessità.

—————————–

Larissa Moss

Larissa Moss è una senior consultant nei settori della Business Intelligence e nel miglioramento della qualità dei Business Information Systems. È fondatrice e presidente della Method Focus Inc. Ha una esperienza di 27 anni nel settore IT, i suoi articoli sul Data Warehousing, Project Management, Information Asset Management e Data Quality sono pubblicati regolarmente su The Navigator, DM Review, Journal of Data Warehousing e Analytic Edge. È co-autrice con Sid Adelman del libro Data Warehouse Project Management e con Shaku Atre del libro BI Roadmap: the complete lifecycle. È una frequent speaker alle Conferenze sul Data Warehousing e Crm negli Stati Uniti, Europa e Asia.

Presenterà a Roma per Technology Transfer il seminario “Approcci Agili al Data Warehousing e alla Business Intelligence” dal 20 al 21 Ottobre 2011

L'articolo Organizzare team di progetto efficienti in ambienti DW/BI proviene da Data Manager Online.