Posts

assorted medals

Perché prendere certificazioni come PM?

Durante i corsi e le consulenze in agenzia, puntualmente la domanda arriva: perché prendi le certificazioni sul Project Management e soprattutto sull’Agile e Scrum? Servono davvero? Qui le mie considerazioni assolutamente personali partendo da una panoramica sulle certificazioni, a cosa servono e perché le prendo.

Read more
four rock formation

Lean Presentation Design

Personalmente adoro fare presentazioni 1 e recentemente, per il Freelance Day, io e Chiara abbiamo fatto una presentazione a quattro mani e, quando metti un PM con una PO succedono cose straordinarie che meritano di essere raccontate.

Il lavoro sulle slide (la parte facile)

Dopo aver concordato Argomento, Titolo e Descrizione del nostro intervento con Chiara ci siamo messi all’opera: dal momento che avremmo lavorato a distanza abbiamo optato per Google Slides (evitando in questo modo rimpalli di email e lavorando su un’unica versione condivisa).

Ci siamo dati appuntamento e in (video) presenza abbiamo inserito la copertina fornita dagli organizzatori e scelto un tema, tra quelli disponibili, con elementi che ricordassero lo stile. Poi, prima di lavorare sui contenuti, usando la prima slide e il sito, abbiamo personalizzato il tema (colori e font).

Definito lo stile era giunta l’ora dei contenuti: tempo a disposizione (25-27 minuti), scaletta, organizzazione dei temi, divisione delle slide.

A questo punto ci siamo dati appuntamento alla settimana successiva: avremmo lavorato in autonomia sulle slide e rifatto il punto. Concordata la data del prossimo incontro ognuno ha organizzato il proprio lavoro.

Martedì altro momento insieme e revisione leggera sui contenuti, ordine e qualche prima considerazione su cosa aggiungere, togliere. Definite le attività ognuno avrebbe lavorato in autonomia (provando le sue parti) e il lunedì successivo avremmo fatto una prova.

Altro incontro e prima prova: considerazioni, prendiamo qualche appunto, siamo leggermente sopra con i tempi, ripensiamo qualcosa. Appuntamento alla settimana successiva con i cronometri alla mano e slide già consegnate (5 giorni di anticipo sulle richieste degli organizzatori).

Ultimo test, 25 minuti, ci siamo: ci diamo appuntamento a sabato 24, all’una un test per il video, alle 16.30 speech, 27 minuti

Cosa c’è dietro (la parte difficile)

Io lavoro come consulente in Project Management, Chiara è una Professional Organizer: probabilmente usiamo strumenti diversi, ma condividiamo alcuni principi e soprattutto un metodo, anzi una filosofia di lavoro.

Organizzare il lavoro

Le nostre slide non hanno visto una “webex permanente”, un lavoro costantemente in presenza, ma una valutazione di cosa ci serviva (per lavorare meglio) in presenza (time boxed 2 e quando invece lavorare in maniera indipendente.

Una rappresentazione visiva è la seguente: un’alternanza di lavoro sincrono e asincrono

Nei momenti “live” lavoravamo contemporaneamente condividendo delle attività che richiedevano la presenza di entrambi, negli altri momenti ognuno dei due aveva una serie di attività da realizzare secondo la propria organizzazione, i propri impegni e le proprie preferenze (ad esempio io sono un Gufo e Chiara un’Allodola).

Sembra quasi Lavoro Agile (e non una brutta copia in digitale del lavoro in ufficio).

Metodo e disciplina

Questo modo di organizzare, fare le prove, non ce lo siamo imposto: per me e Chiara è stato naturale organizzare le attività perché fa parte, come dicevo prima, della nostra filosofia di lavoro, del modo in cui gestiamo le attività.

La buona notizia è che non siamo nati così (per lo meno io), ma che con allenamento, pratica e disciplina abbiamo trovato delle soluzioni che ci consentono di lavorare meglio. Al tempo stesso questa è anche la cattiva notizia perché non esiste uno strumento magico che consenta di gestire bene le cose: bisogna darsi un metodo di lavoro. Un metodo che non deve essere solo nostro, ma condiviso anche con le persone con le quali stiamo lavorando (immaginate se io avessi voluto lavorare in un modo e Chiara in un altro, disastro).

Come ogni gruppo di lavoro dovrebbe fare, abbiamo definito prima strumenti, pratiche e appuntamenti per definire il nostro framework (o WoW, Ways Of Working) e poi abbiamo semplicemente lavorato.

“Eh, ma per un intervento di 27 minuti, tra sincrono e asincrono, sommando le attività avete lavorato 8 ore”

Sì. E su questa osservazione due considerazioni:

  1. può sembrare tanto tempo 3, ma il nostro lavoro è stato lineare e non c’è stato nemmeno un rework, una correzione. Nessun momento in cui ci siamo detti “aspetta il template è sbagliato – il font non è quello giusto – no rifacciamo tutta la scaletta”. Nella maggior parte dei progetti si parte molto veloci e poi ci si perde: si pensa che a correre subito si sia più veloci, ma alla fine, quando si misurano i risultati, si vede che sul lungo periodo l’organizzazione paga;
  2. siamo consapevoli di quanto tempo ci abbiamo messo e dei passi cha abbiamo fatto. Molto spesso, tornando all’esempio di sopra, chi parte senza una strategia, non sapendo come lavorerà o come organizzerà il proprio lavoro farà più fatica a misurare e sapete qual è uno dei grandi segreti per far quadrare i budget di progetto? Non rendicontare. Ma credo che misurare aiuti non a controllare persone e colleghi, ma a lavorare meglio: come direbbe Mando: This is the way.

Anche qui, molto Agili.

La qualità non si aggiunge

E arriviamo alla parte finale, quella più importante e difficile, ovvero quella di filosofia (che da anche il titolo al post). C’è un elemento chiave nel modo di lavorare che abbiamo deciso di utilizzare io e Chiara che possiamo riportare agli approcci Lean e Agile

Build a culture of stopping to fix problems, to get quality right the first time.

The Toyota Way – Principio n° 5

Continuous attention to technical excellence and good design enhances agility.

Agile Manifesto – Principio n°9

Nel fare le slide, le prove, non siamo mai tornati indietro: quando si verificava un problema ci siamo fermati e abbiamo identificato la soluzione: quante volte negli uffici si finisce una presentazione e ci si accorge che il logo è vecchio? che i titoli non sono allineati? che il template non è giusto e cambiandolo bisogna rimpaginare?

La qualità di un prodotto, in questo caso una presentazione, è qualcosa che abbiamo inserito come caratteristica del nostro lavoro, non come qualcosa che è stato aggiunto dopo.

Pensiamo a quanto tempo sprechiamo nel correggere lavori fatti in maniera approssimativa e quanto invece sarebbe più interessante e produttivo lavorare meglio e dedicare quel tempo (che è finito) ad altre riflessioni e ad altre attività (anche a supporto dei colleghi).

Questo modo di lavorare, un po’ alla volta, diventa un’abitudine e difficilmente riuscirai a farne a meno per il semplice fatto che si lavora meglio e a nessuno piace lavorare male (soprattutto quando scopri quanto sia diverso e positivo il diverso approccio).

Cultura aziendale

Fare le cose giuste al primo tentativo è difficile, ma se iniziamo a non passare cose mal fatte, a fermarci qualche minuto in più, sul lungo periodo lavoreremo tutti meglio.

Non si tratta di un cambiamento facile perché questa è una tematica di cultura aziendale e non tanto di metodo o di strumenti. Se ci pensiamo bene molte scelte lavorative discendono direttamente dallo stile manageriale dell’impresa e dalla cultura dell’azieda 4A volte poi viene mitigato o ingigantito dall’attitudine personale/ref].

In un’azienda dove ti guadano male se ti fermi per una riflessione, chi si prederà del tempo per correggere? in un luogo dove “non c’è tempo” chi si sentirà autorizzato a prendersi qualche minuto in più? Se non viene data importanza al lavoro dei colleghi, quanti si prenderanno il tempo per ascoltare? E così via.

Ovviamente, per me, è un discorso molto profondo perché ha a che fare con i valori profondi di un’impresa e soprattutto con il rispetto degli altri: lasciare “le slide” in ordine in modo che qualcun altro possa lavorare meglio è rispetto per l’altro, non un semplice vezzo.

Come ha detto Deming: la qualità non si aggiunge, buona o cattiva è già nel prodotto. Per cui lavoriamo bene 🙂

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.

W. Edwards Deming

Note:

  1. Sulla mia vetrina Amazon – facendo gli esperimenti da Influencer – ho creato una sezione dedicata ai miei libri preferiti sul tema del Presentation Design
  2. È il concetto che un’attività/evento può occupare al massimo un determinato tempo
  3. Ecco, pensare che fare le presentazioni fatte bene sia un lavoro semplice è una grande illusione: richiedono tanto tempo per essere pensate e realizzate. Ovvio, lavorare male è sempre possibile, ma non è il modo in cui credo sia giusto lavorare

È possibile usare Scrum in Agenzia e nel Marketing?

In questi anni ho avuto la possibilità di fare tanta consulenza sulla gestione dei progetti di comunicazione e marketing ad agenzie e aziende di varie dimensioni e una delle domande ricorrenti è: possiamo usare Scrum in questi contesti?

NOTA: questo post è un po’ più tecnico del solito e presuppone la conoscenza di Scrum. In estrema sintesi Scrum è uno dei framework 1 della metodologia Agile. Esistono vari video: questa breve introduzione su YouTube può servire ad avere un’idea generale

La risposta breve? No.

Scrum è un framework fantastico che consente di fare “miracoli” quando è:

  1. nel giusto contesto
  2. è utilizzato per fare quello che è stato creato per fare.

Per cui: sei un’agenzia/unit/area alla quale è stato affidato lo sviluppo di un prodotto e sei struttuato con competenze intern[un team multidisciplinare composto da tre/sette persone con poche dipendenze esterne[/ref]e in grado di sviluppare il prodotto? Vai con Scrum.

  • Sei un’agenzia alla quale affidano soprattutto progetti?
  • Sei un “area” composta da una sola persona?

Se hai risposto di sì a una di queste due domande non è un problema: molto probabilmente sei una PMI come buona parte delle realtà italiane 2 (spesso più P che M) e difficilmente riuscirai a usare Scrum in purezza.

Nelle grandi realtà (Aziende o Agenzie) è possibile usare Scrum creando dei team multidisciplinari stabili e pescando all’occorrenza dagli SME (Subject Matter Espert) per realizzare dei prodotti (che possiamo anche intendere come “grandi progetti”).

E nel resto del mondo? Condannati ai Gantt? No 3, ma per arrivarci bisogna fare il giro lungo.

Alcuni limiti di Scrum all’interno del contesto agenzia e mondo MarCom

Dal mio punto di vista ci sono tre limiti di contesto (che rappresentano i punti di forza del framework da un altro punto di vista):

Prodotto-centrico

Se prendiamo la Scrum Guide si vede che il focus è lo sviluppo di “prodotti”:

  • Scrum is a framework for developing, delivering, and sustaining complex products.
  • A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
  • has been used to manage work on complex products
  • Product Owner
  • Product Backlog
  • Product Increment

La discussione non è tra l’approccio a Prodotto (focus valore) vs approccio Progetto (focus piano), ma sulla tipologia di attività che vengono fatte in agenzia e nei piccoli uffici comunicazione.

Molte agenzie oggi si specializzano in alcune verticalità: social ads, google ads, CRO, SEO, e-commerce management, reputation, automation, content creation, influencer marketing etc. che rappresentano porzioni di attività più strutturate.

Stiamo quindi descrivendo un contesto di attività lontano da quello di Scrum strutturato più per progetti.

Prescrittivo

Anche se è un modello leggero da localizzare su ogni team, ci sono alcuni aspetti dai quali non puoi sfuggire e qui la criticità è legata alla dimensione e ai ruoli.

In Scrum ci sono tre ruoli con Product Owner (PO), Scrum Master (SM) e Developmen Team (DT) e a livello di dimensioni si dice che il Developmen Team è composto da tre-nove membri (o cinque più o meno due a seconda delle scuole di pensiero).

Adorando la separazione dei poteri nel diritto, credo che il bilanciamento tra i ruoli di PO, SM e DT sia geniale e, anche se è vero che SM e PO sono un ruolo e non una persona e nella Scrum Guide non si esclude che SM lavori allo sviluppo, personalmente nelle fasi iniziali credo che vadano identificare in persone diverse.

Purtroppo il Team tenderà a focalizzarsi sulla delivery e il PO Team perderà di vista il valore, lo SM Team le dinamiche: sono alcuni antipattern 4 già visti (così come quelli introdotti dallo SM che fa anche il PO #ancheno).

Per cui mediamente abbiamo bisogno di almeno tre persone più due che, come frequentemente viene fatto notare dall’italico imprenditore, “non producono e costano”. Oltretutto in molte realtà di dimensione ridotta risulta difficile avere abbastanza persone per riuscire ad avere un team “intero”

Mancando le persone e con un focus sui progetti anche il tema dei rituali tende a venire meno. Immaginate però di dire “non facciamo il daily Scrum”: probabilmente brucerete all’inferno degli Scrummisti.

Se perdiamo ruoli e rituali Scrum ha poco senso (mentre avere mindset Agile/Lean rimane fondamentale).

Team Dedicato e Cross Funzionale

Dal momento che parliamo di Prodotti, in Scrum il Development Team è focalizzato sullo sviluppo di una sola cosa (il Prodotto) in modo da velocizzare la realizzazione di incrementi e generare il maggior valore possibile nel più breve lasso di tempo. Per fare questo lo sviluppo è realizzato da un Team Cross funzionale che contiene tutte le competenze per trasformare gli elementi del Product Backlog in Product Increment: riducendo e limitando le dipendenze esterne il Team procede più veloce (non deve aspettare risposte dagli altri Silos: ha tutto all’interno e può correre velocemente e in autonomia).

  • E se lavoriamo a Progetti (come visto sopra) oltretutto dividendo il nostro tempo tra vari Progetti senza un focus esclusivo sul un Prodotto?
  • E se la realizzazione di alcuni progetti richiede una costante relazione con alcuni SME, ma senza il budget per averli a tempo pieno nel DT?

I due punti qui sopra sintetizzano bene lo scenario prevalente nel mondo delle Agenzie e degli Uffici Marketing e Comunicazione delle PMI: non potendo inserire a tempo pieno dei professionisti verticali si ricorre ai freelance (un modello che a me piace molto se inserito nel giusto contesto culturale, soprattutto in Cooperativa).

Per cui abbiamo anche alcune criticità legate a dimensioni, tipologie di attività e competenze/dipendenze.

Quindi niente Scrum per le Agenzie?

Prima di tutto distinguiamo tra Agile (mindset/filosofia) e Scrum (framework/metodo):

è possibile essere Agile senza usare Scrum ed è possibile non essere Agile usando Scrum

Anche se sembra un gioco di parole ricordiamo uno degli elementi più importanti: alla base di Agile ci sono dei principi e dei valori, quello che il Lean definisce nel suo triangolo come Filosofia: la gestione dei team e dei progetti appoggia e affonda le sue radici nella cultura aziendale, gli strumenti sono una conseguenza.

Usare quindi Scrum seguendo alla lettera (o in maniera molto molto vicina all’originale) è possibile solamente per realtà di dimensione ampie e che seguono lo sviluppo di prodotti o grandi campagne (partecipando quindi a tutto lo sviluppo e non solo ricevendo il compito da fare) e che vanno a sviluppare il giusto contesto.

E tutti gli altri? A mio avviso è necessario sviluppare un po’ di tailoring , ovvero creare qualcosa su misura (che per me è la vera risposta) e prendere Scrum modificandolo 5 senza arrivare a Scrumban. Questo dovrebbe essere l’approccio da seguire quando si cerca di adattare elementi nati nel software (e che ancora faticano a uscire dall’ambito IT/ICT) altrimenti il rischio è come quelli che cercando di usare il modello Spotify non essendo Spotify.

Un punto di partenza per Scrum in Agenzia

Un’agenzia ha una serie di Progetti (le lampadine) con dei Brief dettagliati 6 per clienti diversi: ognuno di questi progetti avrà una serie di attività (alcune ad alto valore, alcune più urgenti, altre ancora fumose etc. etc.).

Chi definisce le attività ad alto livello e le prioritizza cross-progetto? Il PO (che rimane il massimizzatore di valore in senso esteso) che le condivide con i vari DT durante lo Sprint Planning (che in Agenzia a mio avviso a un tempo di una/due settimane).

La parte di prioritizzazione e pianificazione è fondamentale perché è qui che cerchiamo di minimizzare i danni del contest switching e del lavoro su progetti multipli: invece di passare da un’attività all’altra, avendo lavorato bene con il PO, possiamo chiudere delle attività prima di passare alle successive.

In questo caso abbiamo quindi più DT, un solo PO e un solo SM (che rimane il massimizzatore della collaborazione in senso esteso).

Alla fine dello Sprint troviamo la Review e la Retrospettiva (in questo caso obbligatoria per tutti: manteniamo alcuni elementi prescrittivi di Scrum).

Per cui cui non cambiano:

  • pilastri (transparency, inspection, adaptation)
  • valori (commitment, courage, focus, openness, respect)
  • eventi (sprint planning, daily scrum, sprint review, sprint retrospective)
  • artefatti (Backlog, DOD, Increment)

I ruoli invece subiscono una leggera modifica a mio avviso soprattutto lato PO che si trova a dover dialogare con una maggior complessità rendendo il suo ruolo più complicato di quanto già non sia 7. Per quanto riguarda invece lo Scrum Master si trova ad avere un maggior lavoro all’inizio che poi dovrebbe calare e consentirgli di passare il ruolo all’interno dei team o di cambiare attività e diventare un nuovo PO.

Questa ovviamente è una delle possibili modifiche ed evoluzioni (ce ne sono anche un altro paio abbastanza interessanti). In azienda, pensando alle dimensioni ridotte, è invece necessario andare a sviluppare un modello leggermente diverso.

Ma noi lo facciamo già…

Eh, ma alla fine è avere un commerciale/account e noi lo facciamo già!

Il PO non è (solo) un Account/Commerciale e, ad esempio, non cambia deadline a caso, non chiede modifiche random, non interrompe durante lo Sprint (se esiste una pagina The Account Academy ci sarà un motivo) 8.

È una persona che lavora con lo SM e con il DT all’interno di un contesto culturale specifico.

Ma allora basta chiamare l’Account PO ed il gioco è fatto.

Anche qui: se fosse sufficiente cambiare il nome alle cose perché si modificassero le attività sarebbe facile, ma si tratta di un cambiamento più profondo ed è anche per questo che all’inizio ho parlato di un contesto e soprattutto di mindset/cultura.

Per cui, ritornando alla domanda iniziale, anche le agenzie possono usare Scrum? In purezza è dura: con un buon cambiamento culturale, di processi e modificando alcuni aspetti e adattandolo alla proprie esigenze sì.

Note:

  1. ne esistono anche altri: XP, FDD, DSDM. Su wikipedia ne trovi una carrellata https://it.wikipedia.org/wiki/Metodologia_agile.
  2. Ricordiamo che il 92% delle imprese italiane sono PMI e non tutte lavorano in ambito software
  3. . Posto che è possibile essere Agili anche usando il Gantt, possiamo anche vedere come implementare altre soluzioni un pelo più moderrne. Dire che è un problema di strumento è come pensare che basti implementare un Kanban per essere Lean
  4. Un antipattern è un comportamento/soluzione all’apparenza corretto, ma che introduce più problemi e non risolve il problema
  5. Per i puristi ovviamente questo potrebbe dire non fare Scrum
  6. Senza Brief non si dovrebbe lavorare, mai
  7. Spesso ho visto il ruolo di PO banalizzato pensando fosse un PM… è molto più di così
  8. Come il PO spesso il ruolo del commerciale e dell’account è o sottovalutato o fatto molto molto male. È un ruolo chiave che andrebbe gestito al meglio. Quando ti trovi a lavorare con un Account che ha chiaro il suo ruolo e la sua relazione con il team è meraviglioso lavorare con lui/lei. Negli altri casi… diciamo meno.
piero tagliapietra project management

Gestire progetti digitali

Era proprio necessario scrivere un altro libro sulla gestione dei Progetti Digitali? Non c’erano abbastanza testi sul Project Management? Secondo me no, soprattutto in ambito Digital e Comunicazione/Marketing.

Svelerai quindi i segreti per fare tutti i progetti digitali?

No: mi spiace, niente risposta sulla vita, l’universo e tutto quanto (tanto quella rimane 42).

Il tema principale del libro è proprio questo: non è possibile rispondere alla domanda “mi dai il metodo assoluto per fare il progetto x” perché non esistono due aziende, contesti, clienti e progetti uguali e quindi non è possibile dare delle indicazioni puntuali su come fare esattamente lo sviluppo di un sito o una campagna adwords.

Ovvio che si possono dare varie opzioni che possono essere adattate allo specifico contesto aziendale.

Ma quindi è meglio Waterfall, Scrum o Kanban o Lean Startup? Nessuno ed è qui che entra in gioco il libro.

Chi si occupa dei progetti oggi (e soprattutto di quelli in ambito Digital) a mio avviso deve conoscere tutte le metodologie e scegliere quella che potrebbe funzionare meglio (anche se possiamo già sbilanciarci sul fatto che probabilmente Agile e Lean sono le due famiglie più utili).

Si tratta quindi di adottare quello che si chiama un “Agile Mindset” e di non erigersi ad araldi di un metodo, ma di scegliere quello che consente di generare il maggior valore in quel contesto specifico

The goal of project management is to produce Business Value in the best possible way given the current environment. It odes not matter if that way is agile or predictive. The question to ask is “How we can be most successful?” 1

Per cui nel libro parlo tanto di filosofia (che è alla base di tutto: ricordiamoci la famosissima frase di Druker “Culture eats strategy for breakfast” ) della gestione e cerco di dare una prima panoramica sui vari approcci (Predittivi, Iterativi, Incrementali, Agili e Ibridi) in modo che si riesca:

  • a capire meglio il proprio ambiente lavorativo
  • identificare e mappare i propri progetti per scegliere approcci ed evoluzioni
  • sviluppare una cultura del progetto e del Project Management
  • scegliere quale metodo, famiglia e approcci approfondire

Perché leggerlo? Può servire anche a me?

Tutti noi gestiamo progetti e stiamo andando verso una Project Economy: per cui avere una rapida idea di cosa vuol dire gestire un progetto e del perché aggi si parla tanto di Agile, Scrum, Lean e Kanban (che non è Trello) per me è una competenza fondamentale.

Oltretutto ognuno di noi gestisce progetti e organizzare male l’attività significa avere persone poco motivate 2 e non riuscire a fare il progetto o non rispettare i vincoli o ridurre i margini sul progetto (o addirittura andare in perdita).

Per cui il libro serve anche a capire cosa è cambiato il Project Management negli ultimi 25 anni (da una visione ancora meccanicistica ad una più legata alla complessità e ad una visione che potremmo definire quasi Olivettiana) e come possiamo organizzare le nostre attività.

Non troverai però la soluzione migliore a livello di tool (È meglio Asana, Wricke, Monday, MS Projects, Bitrix, Miro, Kanbantool, Kananizer, Mural….), ma il processo per arrivare a trovare da solo la risposta .

Ok, dove lo trovo?

Il libro è edito Franco Angeli e qui puoi leggerne un estratto: puoi prenderlo su Amazon o da qualunque altro store o negozio fisico: sarà disponibile dal 5 marzo.

Note:

  1. Agile Practice Guide – Project Management Institute – pg 29. A mio avviso uno dei testi da leggere per adottare ili giusto approccio
  2. È importante ricordare che non gestiamo progetti, ma persone: sono infatti loro a dare vita al progetto e un Team privo di motivazione, scarsamente collaborativo e che non lavora insieme difficilmente riuscirà a garantire il raggiungimento degli obiettivi del progetto

E quindi questo 2017? Continuo così, grazie

Febbraio 2018 inoltrato e finalmente riesco a sistemare quello che doveva essere il “post” bilancio 2017: direi che già questo racconta un sacco di cose sull’anno passato e anche su quello che si prospetta essere il 2018. In poche parole intenso, di corsa, pieno di cose belle e con alcuni sprazzi di equilibrio.

Read more

L’importanza dei team eterogenei

Uno degli aspetti più interessanti legati ai progetti sui Social Media è il tema delle competenze. Si tratta di una riflessione che può essere applicato anche ad altre aree, sicuramente a tutto il digitale: perché è così difficile sviluppare un’attività di successo? Molto semplicemente perché ci troviamo davanti a materie che richiedono l’interazione tra più persone, materie e (per rimanere in ambito aziendale) più dipartimenti o aree.

Read more