La comparsa in letteratura e nella pratica dello sviluppo del software

Documento di ricerca n. 131-quater
TEMATICHE DI INDIPENDENZA RELATIVE AI SERVIZI DIVERSI DALLA
REVISIONE: SERVIZI RELATIVI AL SISTEMA DI CONTROLLO INTERNO
SERVIZI RELATIVI A SISTEMI INFORMATIVI
1.
SCOPO DEL DOCUMENTO
Il presente documento deve essere letto nel quadro di riferimento delineato dal Documento di
ricerca n. 131 intitolato “Tematiche di indipendenza relative ai servizi diversi dalla revisione:
servizi relativi al sistema di controllo interno – Principi generali” e della terminologia ivi
utilizzata e si riferisce agli enti di interesse pubblico (nel seguito anche “EIP”), alle società
controllate da EIP, alle società che controllano EIP ed alle società che sono sottoposte con
questi ultimi a comune controllo per i quali trovano applicazione i divieti alla prestazione dei
servizi previsti dall’art 17 comma 3 del D.Lgs. 27 gennaio 2010, n. 39 (nel seguito anche il
“Decreto”) 1. Per le entità non soggette alla disciplina appena richiamata si rimanda al
documento “Principi sull’Indipendenza del Revisore” emanato dai Consigli Nazionali dei
Dottori Commercialisti e dei Ragionieri e raccomandato dalla Consob.
Il documento, dopo aver svolto una prima panoramica di taluni servizi attinenti all’area dei
sistemi informativi (nel seguito i “S.I.”) che una società potrebbe richiedere ad uno specialista
esterno, si propone l’obiettivo di definire quali di questi servizi possono essere svolti dal
Revisore (di seguito anche solo il “Revisore”) e/o da entità aderenti alla rete del medesimo (di
seguito anche solo la “Rete”) per conto del Soggetto sottoposto a revisione o di sue Consociate
(nel seguito anche la “Società”).
Come noto, l’art. 17 comma 3 lettera b) del Decreto, stabilisce che il Revisore e la sua Rete non
possono fornire “servizi di progettazione e realizzazione dei sistemi informativi contabili” al
Soggetto sottoposto a revisione e alle sue Consociate.
Nel presente documento sono dunque esaminati in modo specifico i servizi relativi all’analisi,
progettazione e realizzazione dei S.I. contabili, al fine di riscontrare l’applicabilità agli stessi del
divieto stabilito dalla norma appena citata. Tale esame tiene inoltre conto delle ulteriori regole
in tema di indipendenza del revisore che riguardano la prestazione di servizi diversi dalla
revisione relativi al sistema di controllo interno (nel seguito anche “SCI”), per le quali si rinvia
al Documento di ricerca n. 131.
Per quanto riguarda i servizi di analisi, progettazione e realizzazione dei S.I. non contabili, che
in quanto tali non sono soggetti alle limitazioni disciplinate dal menzionato art. 17 comma 3
lettera b) del Decreto, si rimanda al framework metodologico ed ai criteri definiti nel
Documento di ricerca n. 131, fermo restando che le descrizioni delle tipologie di servizi
illustrati nel presente documento di ricerca possono riferirsi anche a S.I. non contabili.
1
Il Decreto ha stabilito l’abrogazione del comma 1 ter dell’art. 160 del D. Lgs. 58/98, che è stato sostituito dal citato art. 17 comma
3 del Decreto, il cui contenuto è allineato a quello della norma abrogata, salvo il fatto che la nuova disposizione ha come ambito
di applicazione gli EIP ed i relativi Gruppi, mentre la precedente norma era applicabile alle società soggette al TUF.
1
Si precisa che nel prosieguo è stata utilizzata la terminologia inglese comunemente adottata
dalla prassi professionale internazionale nella definizione di alcune fasi operative che
caratterizzano i progetti relativi all’area dei sistemi informativi, senza procedere alla traduzione
in italiano dei relativi termini.
2.
SISTEMA INFORMATIVO CONTABILE: IL SISTEMA INFORMATIVO E I PROCESSI DI
GESTIONE CORRELATI, RILEVANTI PER L’INFORMATIVA ECONOMICO-FINANZIARIA E
LA COMUNICAZIONE
Il Principio di Revisione n. 315, approvato dai Consigli Nazionali dei Dottori Commercialisti e
dei Ragionieri e raccomandato da Consob individua il “Sistema Informativo ed i processi di
gestione correlati, rilevanti per l’informativa economico-finanziaria e la comunicazione” tra le
componenti del Sistema di Controllo Interno e ne adotta la seguente descrizione: "Un sistema
informativo è costituito dall’infrastruttura (componenti fisiche e hardware), software, persone,
procedure e dati. Infrastruttura e software sono assenti, o hanno meno rilevanza, in sistemi che
sono esclusivamente o principalmente manuali. Molti sistemi informativi fanno ampio uso di
tecnologia informatica (IT)”.
Il citato principio di revisione fornisce inoltre la seguente spiegazione dettagliata: “Il sistema
informativo rilevante per gli obiettivi di informativa economico-finanziaria, che include il
sistema informativo per la redazione del bilancio, è costituito dalle procedure e dalle
registrazioni stabilite per rilevare, registrare, elaborare le operazioni dell’impresa e darne
informativa (come pure per eventi e condizioni) e mantenere evidenza contabile delle relative
voci di attività, passività e patrimonio netto”.
I sistemi informativi e le relative informazioni gestite che sono rilevanti per l’informativa
economico – finanziaria (nel seguito anche “Sistemi Contabili”) non comprendono soltanto
ambiti che sono direttamente connessi a dati iscritti nel bilancio, ma anche qualsiasi altro dato,
processo o sistema rilevante ai fini di una valutazione o qualsiasi altro dato fisico ai quali si
ricolleghino i dati di bilancio. Queste informazioni sono generate da sistemi informatici integrati
o da sistemi autonomi (per esempio sistemi di contabilità, di rilevamento dei costi, di gestione
dei libri paga o di cassa, come pure i sistemi che sono in grado di produrre soltanto valori
relativi a quantità fisiche, come taluni sistemi di controllo del magazzino e della produzione,
ecc.).
Il Code of Etichs emesso dall’International Federation of Accountants non definisce i sistemi
informativi contabili, ma stabilisce che il Revisore di società di pubblico interesse e/o la Rete
cui esso appartiene non possano fornire servizi relativi a progettazione e realizzazione di sistemi
informativi che: (a) formano una parte significativa del controllo interno per la redazione del
bilancio o (b) generano informazioni che sono significative per il Sistema Contabile della
Società o per il bilancio su cui il Revisore esprime il proprio giudizio.
3.
IDENTIFICAZIONE DEI PRINCIPALI SERVIZI DIVERSI DALLA REVISIONE CHE POSSONO
ESSERE RICHIESTI AD UNO SPECIALISTA ESTERNO
I principali servizi diversi dalla revisione che potrebbero essere richiesti ad uno specialista
esterno da un soggetto sottoposto a revisione o da una sua Consociata in relazione all’area dei
S.I. possono essere articolati, indicativamente, nelle macro attività di seguito indicate:
2
 Attività principali
A.
B.
Analisi delle esigenze e dei bisogni
Progettazione delle componenti tecniche e tecnologiche strumentali
soddisfazione dei bisogni
C. Realizzazione delle soluzioni tecnologiche per la soddisfazione dei bisogni
D. Testing
alla
 Attività integrative
Altre attività che potrebbero essere richieste ad uno specialista esterno da un soggetto
sottoposto a revisione o da una sua Consociata in relazione all’area dei S.I., e che possono
precedere o rappresentare un’estensione delle attività principali precedentemente illustrate,
sono di seguito indicate. Tali attività integrative possono, in talune circostanze, essere a loro
volta articolate e suddivise al loro interno nelle fasi di Analisi, Progettazione, Realizzazione
e Testing precedentemente descritte. In particolare, si tratta di:
E. Manutenzione
F. Software
G. Project management
 Attività principali
A.
Analisi delle esigenze e dei bisogni
Trattasi dell’indagine preliminare sul contesto in cui il S.I. deve inserirsi, sulle caratteristiche
che deve evidenziare, ed eventualmente su costi e aspetti logistici/operativi della sua
realizzazione; questa fase può essere scomposta in sottoattività quali:
i.
studio di fattibilità (ovvero di macro-rilevazione dei requisiti utente, di rappresentazione
di massima delle soluzioni informatiche teoricamente possibili, di definizione dei piani
d’azione metodologici e delle stime d’impegno), analisi e modellazione dei domini
applicativi. Lo studio di fattibilità è condotto di regola attraverso l’analisi di più
alternative teoricamente possibili.
ii.
macroanalisi, ovvero rilevazione dello status attuale delle componenti applicative e
descrizione delle loro funzioni di massima e delle relazioni con altri sistemi;
iii. rilevazione analitica, inventariazione ed organizzazione dei requisiti attesi dagli utenti in
termini di componenti applicative che una volta realizzate potrebbero soddisfare i
requisiti operativi degli utenti (processi, normative interne ed esterne), di performance,
funzionalità, ecc.
iv. assessment, costituito dalle attività di rilevazione del funzionamento del sistema
informativo in essere (check-up) e dalla gap analysis in termini di rispondenza alle
esigenze dell’organizzazione e di efficienza interna;
v.
benchmarking ovvero confronto dei risultati ottenuti dall’assessment con i parametri di
riferimento dei S.I. di realtà esterne analoghe a quella di riferimento;
La fase di analisi ha lo scopo di rilevare l’esigenza dell’utente finale/Società attraverso la
raccolta dei dati tramite colloqui tra Società e/o i soggetti incaricati dello sviluppo dei
sistemi, analisi della documentazione interna elaborata dalla Società, analisi dei processi e
delle procedure esistenti. Al termine della fase è redatto un documento che descrive le
caratteristiche del sistema e del contesto in cui sarà inserito.
3
Esempi di output di tale fase sono:
• Obiettivi del progetto: rappresentazione di quello che la Società ha definito, in termini di
metodologia, piano di lavoro, utenti da intervistare, processi da esaminare, ed altro che
sia utile a circoscrivere l’ambito del progetto.
• Studio di fattibilità: ovvero di rilevazione dei requisiti utente, di rappresentazione di
massima delle soluzioni informatiche teoricamente possibili, di rappresentazione delle
metodologie presenti per le soluzioni informatiche e delle stime d’impegno del progetto.
• Inventario requisiti funzionali: rilevazione dei requisiti richiesti dall’utente
• Inventario requisiti di performance,
• Inventario requisiti di usabilità
• Matrice requisiti/processi di business: mappatura dei requisiti definiti dalla Società
rispetto ai singoli processi di business
• Matrice utenti/processi di business: mappatura degli attori/owner dei singoli processi di
business
• Vincoli tecnico/funzionali
• KPI (Key Performance Indicator): Rilevazione degli indicatori in essere presso il cliente
• Variabili di analisi da misurare (misure), dimensioni di analisi e loro gerarchie:
rappresentazione delle diverse viste delle singole informazioni (es. con riferimento al
dato “paese”, la dimensione può essere: Europa, Italia, etc.)
• Risultati dell’assessment: elencazione della situazione in essere di sistemi, processi ed
utenti.
• Risultati del benchmarking, rappresentazione delle analisi di benchmarking
• Mappatura e scomposizione dei bisogni elementari
• Modello di correlazione dei bisogni
B.
Progettazione delle componenti tecniche e tecnologiche strumentali alla soddisfazione
dei bisogni
Trattasi della traduzione della fase di analisi in specifiche funzionali e tecniche di dettaglio,
ed è quindi dipendente: (i) dalle scelte "economico-aziendali", in cui si definiscono i bisogni
della Società e le linee essenziali delle modalità strumentali alla loro soluzione, in funzione
dei requisiti evidenziati dall'Analisi e dal documento finale da essa creato e (ii) dalle scelte
tecnologiche in cui si definiscono le linee essenziali della struttura del sistema da realizzare,
in funzione dei requisiti evidenziati dall'Analisi e dal documento predisposto a conclusione
di tale fase. Anche questa fase può essere scomposta in sottoattività, dal progetto
architetturale al progetto dettagliato, che hanno lo scopo di definire la soluzione tecnica e
tecnologica del problema. In questa fase è redatto un documento finalizzato alla definizione
della struttura - architettura tecnica di alto livello e delle caratteristiche tecniche dei singoli
componenti (moduli) del sistema informativo.
Esempi di output di tale fase sono:
• Analisi funzionale delle soluzioni strumentali definite dalla Società per singola tipologia
di bisogni elementari
• Modello dei Dati
• Principali fonti di dati (sistemi alimentanti)
• Principali fonti extra-aziendali di dati (banche dati esterne)
• Progettazione degli indicatori
• Interfacce
4
•
Architettura software
a. componenti (classi, package, strutture dati), programmi, procedure (di sistema,
esterne,dll), strutture dati di supporto, interfacce (hw/software) ecc. che comporranno
il sistema
b. entità/relazioni (modello dei dati relazionale)
c. Procedure di conservazione dei dati
d. Dimensionamento
e. Datawarehousing
f. Piattaforma hardware/software del Sistema
g. Soluzione tecnologica individuata
h. Progettazione delle procedure di popolamento della base dati
i. Estrazione dei dati (procedure, frequenze, supporto) dai database esistenti.
C.
Realizzazione delle soluzioni tecnologiche per la soddisfazione dei bisogni
Trattasi delle attività connesse alla realizzazione concreta del sistema informativo, ovvero
finalizzate alla realizzazione della soluzione.
Esempi di output di tale fase sono:
• produzione della documentazione tecnica di dettaglio
• personalizzazione di sistemi standard disponibili sul mercato
• organizzazione del codice in termini di dettaglio della architettura software
• implementazione delle componenti software (interfacce, sorgenti, eseguibili, ecc.)
• disegno fisico e implementazione delle basi di dati negli ambienti di riferimento
(relazionale, multidimensionale, ecc.)
• produzione del codice software e delle basi di dati.
D. Testing
Successivamente alla Realizzazione è svolta la fase di testing, diretta a valutare in che misura
il sistema realizzato soddisfa i requisiti stabiliti nella fase di analisi, ovvero a valutarne la
correttezza rispetto alle specifiche.
Esempi di output di tale fase sono:
• definizione delle specifiche di test
• pianificazione delle attività di test
• test dei componenti progettati e realizzati, della loro integrazione e del sistema risultante.
• Valutazione degli esiti dei test e progettazione e realizzazione di eventuali azioni
correttive conseguenti
• manuale utente (definitivo), installazione
In aggiunta all’attività di testing svolta a conclusione della Realizzazione del sistema,
possono configurarsi, altre attività di testing, miranti ad esaminare specifici aspetti del
sistema per individuarne eventuali criticità e debolezze. Tali attività di test possono essere
svolte in varie circostanze, anche indipendentemente da una attività di progettazione e
realizzazione.
 Attività integrative
E.
Manutenzione
Al termine della fase di Realizzazione, ovvero quando il sistema è entrato in esercizio, viene
attivata la fase di manutenzione, che comprende tutte le attività di modifica del software
successive all’avvio in produzione presso la Società o alla sua immissione sul mercato.
5
In particolare, tale fase di manutenzione può essere suddivisa nelle due tipologie di seguito
indicate:
• manutenzione correttiva: ha per oggetto quelle attività che si rendono necessarie nel corso
dell’esercizio del sistema volte alla correzione del malfunzionamento del sistema o al
ripristino dello stesso;
• manutenzione evolutiva: attiene a quelle attività rivolte al miglioramento o
all’aggiornamento del sistema in essere.
La fase di manutenzione può avere un ciclo di processo come descritto in precedenza, ovvero
suddiviso nelle fasi di Analisi, Progettazione e Realizzazione, anche se rivolte a specifiche
funzionalità del sistema.
F.
Software selection
È il servizio avente ad oggetto la predisposizione di una rassegna dei diversi sistemi
disponibili in alternativa sul mercato, esaminandone i requisiti tecnici, nell’ambito di criteri
preventivamente definiti dalla Società in base alle caratteristiche dei propri processi. Sulla
base di questa rassegna, il Soggetto Sottoposto a Revisione decide quale sistema installare.
G. Project management
Trattasi dell’insieme di attività, trasversali ad un dato progetto, che tipicamente possono
essere raggruppate in due sottoinsiemi:
1. la gestione del progetto stesso, delle relative risorse assegnate, degli obiettivi, ecc.. In tale
ambito sono incluse anche le attività di governo del progetto e i relativi processi
decisionali;
2. attività amministrative di raccolta e organizzazione di informazioni funzionali: (i) al
monitoraggio del piano di progetto, (ii) alla verifica della completezza rispetto a rischi
individuati nell’ambito della fase di Analisi, (iii) a conoscere l’avanzamento del progetto
rispetto al piano (ad es.: “status report”). Si tratta, di fatto, di attività di tipo
amministrativo che non prevede alcuna partecipazione ai processi decisionali.
4.
IL RUOLO DEL REVISORE E/O DELLE ENTITÀ ADERENTI ALLA SUA RETE
Al fine di definire la portata degli eventuali servizi diversi dalla revisione che il Revisore e/o le
entità aderenti alla sua Rete possono svolgere a favore del Soggetto Sottoposto a Revisione con
riferimento agli ambiti sopra descritti, appare opportuno applicare il framework metodologico
descritto nel paragrafo 5 del Documento di ricerca n.131 intitolato “Tematiche di indipendenza
relative ai servizi diversi dalla revisione: servizi relativi al sistema di controllo interno –
Principi generali” e qui di seguito sintetizzato.
⇒ Con riferimento all’oggetto dei servizi diversi dalla revisione, i servizi di progettazione e
realizzazione dei S.I. contabili, di cui ai punti B) e C) del paragrafo 3. del presente
documento di ricerca ricadono nella categoria di cui al punto a) del paragrafo 5 del
Documento di ricerca n. 131: i prospettati servizi hanno infatti per oggetto aree
specificatamente individuate dalle norme relative alle incompatibilità stabilite dall’art. 17,
comma 3, lett. b), Decreto. Tali servizi non sono consentiti con riferimento al Soggetto
sottoposto a revisione ed alle sue controllate, controllanti ed entità soggette a comune
controllo;
⇒ Per quanto riguarda i servizi attinenti alle restanti attività descritte nel paragrafo 3. del
presente documento di ricerca, si ritiene che gli stessi ricadano nelle categorie di cui ai
punti b) e c) del paragrafo 5 del Documento di ricerca n.131: i prospettati servizi hanno per
6
oggetto categorie o aree del SCI che, a seconda delle circostanze, possono o meno essere
rilevanti ai fini della revisione;
⇒ Con riferimento alle modalità con le quali i servizi diversi dalla revisione possono essere
resi, si ritiene che risultino applicabili, nella fattispecie, per le attività inerenti le fasi
consentite, solo le modalità Advisory, come di seguito specificato;
⇒ Per i servizi che abbiano ad oggetto categorie o aree del SCI che non risultino rilevanti ai
fini della revisione, permane la necessità che il Revisore e / o la sua Rete non siano
coinvolti, nel corso dell’esecuzione di tali servizi, in attività che si configurino come
management function.
Come definito nel Documento di ricerca n. 131, nello svolgimento del servizio secondo la
modalità “Advisory” il Soggetto sottoposto a revisione è parte attiva nel progetto, che gestisce e
governa in tutte le sue varie fasi, dalla pianificazione all’esecuzione, attraverso un apposito
Gruppo di Lavoro. I servizi diversi dalla revisione resi dallo specialista esterno sono limitati
all’assistenza di natura metodologica e tecnica al gruppo di lavoro della Società. La Società
assume la responsabilità della definizione dei risultati delle analisi e delle azioni conseguenti,
nonché dell’assunzione di tutte le decisioni attinenti il progetto. In tale scenario, in presenza
delle condizioni più avanti descritte, il Revisore e/o la sua Rete possono prestare servizi al
soggetto sottoposto a revisione. In questa ipotesi, infatti, il Revisore e/o le entità aderenti alla
sua Rete mettono a disposizione della Società la propria esperienza professionale e le proprie
conoscenze metodologiche relativamente alla rilevazione, documentazione e valutazione dei
sistemi contabili e di controllo interno, senza tuttavia esercitare la gestione e/o il governo del
progetto e quindi non partecipando al processo decisionale del soggetto sottoposto a revisione,
che rimane di esclusiva competenza dell’Alta Direzione della Società.
Tenuto conto degli elementi sopra illustrati e del framework di riferimento sopra descritto, avuto
riguardo alle salvaguardie da adottare per ricondurre entro un livello ragionevolmente
accettabile le minacce per l’indipendenza del Revisore e con riferimento alla descrizione
analitica dei possibili ambiti dei servizi relativi ai sistemi informativi contabili precedentemente
fornita, è quindi da ritenersi che la prestazione di servizi in quest’area può essere svolta, solo se
la Società dispone di un’adeguata struttura IT, in quanto diversamente potrebbe configurarsi un
coinvolgimento del Revisore e/o della Rete nel processo decisionale. In tali condizioni:
1.
Nelle fattispecie in cui la Società istituisca un gruppo di lavoro, il Revisore e la sua Rete
possono partecipare alle attività a carattere ricognitivo incluse tra quelle descritte alla fase
A (Analisi), se svolte secondo le modalità Advisory, come definite nel Documento di
ricerca n. 131 e sopra richiamate.
2.
Con riferimento alle fasi B (Progettazione) e C (Realizzazione o codifica) i relativi servizi
hanno per oggetto aree specificatamente individuate dalle norme relative alle
incompatibilità stabilite dall’art. 17, comma 3, lett. b), Decreto. Tali servizi non sono
pertanto consentiti con riferimento al Soggetto sottoposto a revisione e alle sue controllate,
controllanti ed entità soggette a comune controllo.
3.
Il Revisore e/o la Rete non possono partecipare al complesso delle attività descritte nella
fase di Testing per il rilascio in produzione del sistema, in quanto alcune delle stesse
presuppongono la partecipazione a processi decisionali e, nel loro complesso, esse
rappresentano una parte integrante della realizzazione del sistema. E’ invece ammissibile il
coinvolgimento nelle sole attività di esecuzione di test svolte in varie circostanze,
indipendentemente da una attività di progettazione e realizzazione, finalizzate ad
individuare criticità e debolezze del sistema in funzione a condizione che: (i) tale
partecipazione abbia portata, estensione e pervasività limitate, anche in relazione alle
decisioni che l’Alta Direzione aziendale riterrà di assumere all’esito dei tests; (ii) le
procedure da svolgere, la loro portata ed estensione e le modalità da adottare per lo
7
svolgimento delle stesse siano definite dall’Alta Direzione; (iii) le valutazioni da svolgere
all’esito delle attività rimangono di esclusiva responsabilità dell’Alta Direzione (iv) i
risultati e le valutazioni effettuate all’esito dei tests non siano rilevanti ai fini dell’attività di
revisione. Queste modalità di partecipazione risultano infatti coerenti con la normativa
vigente in relazione all’affidamento al Revisore e/o alla Rete di incarichi mirati allo
svolgimento di specifiche attività di verifica e di analisi delle procedure che concorrono a
formare il sistema amministrativo-contabile, a condizione che l’Alta Direzione mantenga la
piena responsabilità del programma di lavoro e della valutazione dei risultati delle verifiche
svolte. Gli incarichi in oggetto sono di regola condotti secondo modalità che fanno
riferimento alle agreed upon procedures.
4.
Con riferimento alla fase E (Manutenzione), è generalmente consentita la prestazione di
servizi di manutenzione correttiva che consistano nel ripristino di condizioni pre-esistenti
di funzionamento del sistema. Per i servizi di manutenzione evolutiva si rimanda a quanto
detto nei precedenti punti 1, 2 e 3 con riferimento alle fasi di Analisi, Progettazione e
Testing in cui tali servizi si possono articolare.
5.
Con riferimento alla fase F (Software selection) la prestazione di un simile servizio è in
generale consentita al Revisore e/o alle entità aderenti alla sua Rete a condizione che essi si
limitino alla presentazione fattuale delle caratteristiche tecniche di tutti i sistemi disponibili
che ricadono nell’ambito dei criteri preventivamente definiti dalla società. Le
caratteristiche tecniche, i costi ed i benefici dei sistemi oggetto della rassegna devono
essere adeguatamente documentati e discussi con il Soggetto Sottoposto a Revisione.
Inoltre il Revisore e/o la Rete non possono partecipare alla selezione dei fornitori, né
prendere autonomamente contatti con gli stessi, in quanto attività proprie del management
della Società.
6.
Le attività di gestione del progetto descritte al punto 1. della fase G (Project management)
comportano il coinvolgimento nel governo del progetto e nei relativi processi decisionali e,
quindi, lo svolgimento di funzioni proprie del management, incompatibili con il ruolo del
Revisore. Per tali motivi, tali attività non possono prevedere il coinvolgimento del Revisore
e/o di entità aderenti alla sua Rete.
7.
Le attività della fase descritte al punto 2 della fase G (Project management), vale a dire
l’insieme delle attività amministrative di raccolta e organizzazione delle informazioni
funzionali al monitoraggio del piano di progetto e alla elaborazione dello “status report”,
avendo, appunto, un carattere di tipo amministrativo, rappresentano un supporto per la
Direzione della Società al fine del monitoraggio dell’attività di Project Management e sono
in linea generale consentite, in quanto non prevedono un coinvolgimento nel processo
decisionale.
NOVEMBRE 2010
"I contenuti del presente documento, aggiornati alla data di elaborazione del documento stesso,
riguardano tematiche di carattere generale, senza costituire assistenza e consulenza professionale per
singole e concrete fattispecie. Tutti i diritti riservati."
8