LezIA|HUB
← Informatica →Quiz: Quiz Sistema Informativo Aziendale
Dispensa SIA 5ª

Il Sistema Informativo Aziendale

Come un'azienda raccoglie, organizza e distribuisce le informazioni per far funzionare i propri processi e prendere decisioni — dalla gestione con semplici archivi fino alla progettazione professionale di una base di dati e all'integrazione con un ERP.

✓ Sistema informativo vs informatico ✓ File vs DBMS ✓ Modello E-R ✓ Sistemi ERP ✓ Flashcard + Quiz

01Il concetto di sistema informativo aziendale

Prima di parlare di database serve un punto fermo: che cos'è, esattamente, un sistema informativo, e in che cosa si distingue dal sistema informatico che spesso — sbagliando — gli viene sovrapposto.

Definizione

Il sistema informativo (SI) è l'insieme organizzato di persone, procedure, dati e tecnologie che un'azienda utilizza per raccogliere, elaborare, archiviare e distribuire le informazioni necessarie a svolgere le proprie attività e a supportare le decisioni, a ogni livello dell'organizzazione.

Il sistema informativo esiste in ogni azienda, anche in quelle che non usano un solo computer: un negozio che tiene i conti su un quaderno ha comunque un sistema informativo, semplicemente non automatizzato.

i
Da non confondere

Sistema informativo e sistema informatico non sono sinonimi. Il sistema informatico è la parte del sistema informativo che viene realizzata con l'ausilio di hardware, software e reti: è cioè la componente automatizzata. Il sistema informativo, più ampio, comprende anche le procedure manuali, le persone e le regole organizzative che non passano da un computer.

Le componenti del sistema informativo

Risorse umane

Le persone che producono, raccolgono, elaborano e utilizzano le informazioni: impiegati, dirigenti, addetti al data entry, analisti.

Procedure

Le regole, manuali o automatizzate, che stabiliscono come i dati vengono raccolti, trattati e comunicati all'interno dell'organizzazione.

Dati e informazioni

Il dato è un fatto grezzo (es. 07/03); l'informazione è il dato interpretato in un contesto che gli dà significato (es. "il 7 marzo è la data di scadenza della fattura n. 118").

Tecnologie

Hardware, software e reti di comunicazione che, quando presenti, costituiscono il sistema informatico: la parte automatizzata del sistema informativo.

Il flusso informativo

Qualunque sia il grado di automazione, il sistema informativo compie sempre lo stesso ciclo di operazioni sui dati aziendali:

  1. Raccolta — acquisizione dei dati dalla realtà aziendale (un ordine ricevuto, una consegna, un pagamento).
  2. Elaborazione — trasformazione dei dati grezzi in informazioni utili (calcolo di un totale, di una giacenza, di uno scaduto).
  3. Archiviazione — memorizzazione dei dati per un uso futuro.
  4. Distribuzione — comunicazione delle informazioni a chi ne ha bisogno, nel momento e nella forma adeguati.

L'organizzazione per livelli: la piramide di Anthony

Le informazioni prodotte dal sistema informativo non servono tutte allo stesso modo: cambiano per dettaglio, frequenza e orizzonte temporale a seconda del livello organizzativo a cui sono destinate.

Strategico Direzionale / tattico Operativo dettagliate, frequenti, interne → sintetiche, periodiche, anche esterne

Livello operativo

Attività quotidiane e ripetitive: registrare una fattura, aggiornare il magazzino, evadere un ordine. Servono informazioni dettagliate e frequenti.

Livello direzionale (tattico)

Controllo di gestione e pianificazione a medio termine: verificare gli scostamenti dal budget, valutare le vendite del trimestre. Servono informazioni aggregate e periodiche.

Livello strategico

Decisioni di lungo periodo: aprire un nuovo mercato, lanciare una linea di prodotto. Servono informazioni sintetiche, spesso integrate con dati esterni all'azienda.

Requisiti di qualità

A ogni livello, l'informazione deve essere rilevante, tempestiva, accurata, chiara ed economica da produrre rispetto al beneficio che porta.

02Gestione tradizionale e gestione tramite database

Lo stesso sistema informativo automatizzato può essere realizzato in modi molto diversi. Il confronto tra archivi tradizionali e basi di dati spiega perché, dagli anni '70 in poi, il secondo modello abbia sostituito il primo in quasi ogni contesto aziendale.

Nella gestione tradizionale, ogni applicazione gestisce i propri archivi (file) di dati, progettati in modo indipendente dalle altre applicazioni. Ufficio vendite, ufficio fatturazione e magazzino, ad esempio, tengono ciascuno un proprio archivio clienti.

archivio_vendite.dat
Rossi Mario
Via Roma 12, Prato
archivio_fatture.dat
Rossi Mario
Via Roma 12, Firenze
archivio_magazzino.dat
Rossi Mario
Via Roma 12, Prato

L'indirizzo del cliente è duplicato in tre archivi diversi: se uno viene aggiornato e gli altri no, i dati diventano incoerenti tra loro.

I problemi tipici

  • Ridondanza — gli stessi dati sono ripetuti in più archivi, con spreco di spazio e di lavoro.
  • Inconsistenza — aggiornando un dato in un archivio e non negli altri, le informazioni diventano discordanti.
  • Dipendenza dati-programmi — la struttura fisica dei file è scritta dentro il codice dei programmi: cambiare un archivio significa dover modificare tutti i programmi che lo usano.
  • Difficoltà di condivisione — applicazioni diverse non accedono facilmente agli stessi dati.
  • Interrogazioni rigide — si possono ottenere solo i report previsti in fase di programmazione; una domanda "nuova" richiede di scrivere nuovo codice.
  • Sicurezza debole — è difficile controllare in modo fine chi può leggere o modificare cosa.

Nella gestione tramite base di dati (database), i dati sono un'unica risorsa centralizzata, condivisa da tutte le applicazioni e gestita da un software specializzato: il DBMS (Data Base Management System).

Base di dati clienti
Rossi Mario — Via Roma 12, Prato
un'unica versione del dato, letta da vendite, fatturazione e magazzino

I vantaggi

  • Controllo della ridondanza — i dati non scompaiono, ma vengono condivisi invece che duplicati.
  • Indipendenza dati-programmi — grazie a un'architettura a livelli, i programmi non "conoscono" il modo in cui i dati sono fisicamente memorizzati.
  • Condivisione — più utenti e applicazioni accedono agli stessi dati, anche contemporaneamente.
  • Integrità — il DBMS applica vincoli (di dominio, di chiave, referenziali) che impediscono l'inserimento di dati scorretti.
  • Sicurezza — utenti e permessi granulari su chi può leggere, inserire, modificare, cancellare.
  • Gestione della concorrenza — meccanismi (transazioni, blocchi) che regolano accessi simultanei senza conflitti.
  • Backup e ripristino — strumenti integrati per recuperare i dati dopo un guasto.
  • Linguaggi di interrogazione — con SQL si possono formulare domande nuove sui dati senza scrivere un programma dedicato.

L'indipendenza dei dati: l'architettura a tre livelli

Il vantaggio più importante del modello a database — l'indipendenza tra dati e programmi — si realizza tramite un'architettura a tre livelli di astrazione, nota come modello ANSI/SPARC. È anche il ponte naturale verso il prossimo argomento: le tre fasi di progettazione corrispondono, non a caso, a questi tre livelli.

Livello esterno viste personalizzate per singoli utenti o applicazioni Livello concettuale (logico) descrizione completa dei dati e delle relazioni, indipendente dal DBMS Livello interno (fisico) modalità reale di memorizzazione su disco: file, indici, strutture di accesso
Fig. 2.1 — Architettura a tre livelli ANSI/SPARC: ogni livello può cambiare senza obbligare a modificare quelli sopra o sotto di esso.
Confronto sintetico
CaratteristicaGestione tradizionaleGestione tramite database
Ridondanza dei datiAltaControllata
Coerenza tra datiA rischioGarantita da vincoli
Dipendenza dati-programmiForteMinima
Condivisione tra applicazioniDifficileNativa
Sicurezza e permessiLimitataGestita dal DBMS
Interrogazioni non previsteRichiedono nuovo codiceSQL, immediate

03Le tre fasi della progettazione di una base di dati

Progettare una base di dati significa costruire uno schema che rappresenti fedelmente la realtà di interesse — la porzione di mondo reale che vogliamo modellare — rispettando correttezza ed efficienza. Il processo si articola in tre fasi, ciascuna a un livello di astrazione via via più concreto: concettuale → logica → fisica, esattamente i tre livelli visti nel capitolo precedente.

La progettazione concettuale traduce la realtà di interesse in uno schema indipendente da qualsiasi DBMS: si descrive cosa rappresentare, non come verrà poi implementato. Lo strumento standard è il modello Entità-Relazioni (E-R).

Entità

Una classe di oggetti del mondo reale, con esistenza autonoma e di interesse per l'applicazione (es. Cliente, Prodotto, Ordine). Si rappresenta con un rettangolo.

Attributi

Le proprietà che descrivono un'entità (es. Cliente: CodiceCliente, Nome, Indirizzo). Uno o più attributi costituiscono la chiave, che identifica in modo univoco ogni occorrenza dell'entità.

Associazioni (relazioni)

Il legame logico tra due entità (es. Cliente EMETTE Ordine). Si rappresenta con un rombo collegato alle entità coinvolte.

Cardinalità

Indica quante occorrenze di un'entità sono associate a occorrenze dell'altra: 1:1, 1:N, N:N (massima), più una minima (0 = opzionale, 1 = obbligatoria).

⚠
Attenzione all'esame

Un'associazione N:N può avere attributi propri, che non appartengono a nessuna delle due entità ma alla relazione stessa: ad esempio la quantità di un prodotto in un ordine appartiene alla relazione "Ordine–Prodotto", non al Prodotto né all'Ordine singolarmente.

Esempio: schema E-R di un'azienda commerciale

Cliente Ordine Prodotto Emette Contiene (1,1) (0,N) (1,N) (0,N) CodiceCliente Ragione sociale NumeroOrdine Data ordine CodiceProdotto Prezzo Quantità Legenda: rettangolo = entità · rombo = associazione · ellisse = attributo · (min,max) = cardinalità "Quantità" è un attributo dell'associazione Contiene, non del Prodotto: dipende dalla singola riga d'ordine.
Fig. 3.1 — Schema E-R concettuale: Cliente (1,1)–(0,N) Emette Ordine; Ordine (1,N)–(0,N) Contiene Prodotto, con l'attributo Quantità sull'associazione.

La progettazione logica traduce lo schema concettuale in uno schema logico, tipicamente secondo il modello relazionale: i dati sono organizzati in tabelle (relazioni), le righe sono tuple (record), le colonne sono attributi (campi). Lo schema è ancora indipendente dal DBMS fisico specifico che verrà scelto in seguito.

Le regole di derivazione da E-R a relazionale

  • Ogni entità diventa una tabella; i suoi attributi diventano colonne; l'identificatore diventa chiave primaria (PK).
  • Un'associazione 1:N si traduce inserendo la chiave primaria della tabella "1" come chiave esterna (FK) nella tabella "N".
  • Un'associazione N:N richiede una tabella ponte, la cui chiave primaria è l'unione delle due chiavi esterne provenienti dalle tabelle collegate, con l'aggiunta degli eventuali attributi propri dell'associazione.
  • Un'associazione 1:1 può essere risolta fondendo le due entità in un'unica tabella, oppure inserendo la FK in una delle due.

Lo schema logico del caso Cliente–Ordine–Prodotto

CLIENTI
CodiceClienteRagioneSocialeIndirizzo
C001Rossi MarioVia Roma 12, Prato
ORDINI
NumeroOrdineDataOrdineCodiceCliente
O100112/09/2026C001
PRODOTTI
CodiceProdottoDescrizionePrezzo
P200Trapano avvitatore64,90
DETTAGLIO_ORDINE — tabella ponte per la N:N
NumeroOrdineCodiceProdottoQuantità
O1001P2003
i
Leggenda colori

chiave primaria in ambra, chiave esterna in verde-teal. Nella tabella ponte le due FK insieme formano la PK composta.

La normalizzazione

Uno schema logico va verificato — e se serve corretto — per eliminare ridondanze e anomalie di inserimento, modifica e cancellazione. Il processo si chiama normalizzazione ed è organizzato in forme via via più restrittive:

  • 1ª Forma Normale (1NF) — ogni attributo deve contenere un valore atomico, non ripetitivo (niente elenchi multipli in una sola cella).
  • 2ª Forma Normale (2NF) — ogni attributo non chiave deve dipendere dall'intera chiave primaria, non solo da una sua parte (rilevante quando la chiave è composta).
  • 3ª Forma Normale (3NF) — nessun attributo non chiave può dipendere da un altro attributo non chiave (eliminazione delle dipendenze transitive).

A questo livello si definiscono anche i vincoli di integrità referenziale: il valore di una chiave esterna deve corrispondere a un valore esistente della chiave primaria referenziata, oppure essere nullo.

La progettazione fisica traduce lo schema logico in una struttura effettivamente implementabile su un DBMS specifico: qui, per la prima volta, entrano in gioco le caratteristiche del prodotto software scelto (es. MySQL, PostgreSQL, Oracle, SQL Server) e dell'hardware su cui verrà eseguito.

Le attività principali

  • Scelta del DBMS in base a costi, prestazioni, compatibilità con l'infrastruttura esistente.
  • Traduzione delle tabelle in strutture fisiche reali: file, record, tipi di dato specifici del DBMS scelto (es. VARCHAR, DECIMAL, DATE).
  • Definizione degli indici per velocizzare le ricerche più frequenti — tipicamente sulle chiavi primarie e sulle colonne usate spesso nelle ricerche o negli ordinamenti.
  • Allocazione dello spazio su disco: organizzazione dei file, eventuale partizionamento delle tabelle più grandi.
  • Ottimizzazione delle prestazioni: bilanciare velocità di lettura, velocità di scrittura e spazio occupato.
  • Politiche di sicurezza fisica e pianificazione dei backup.
⚠
Concetto chiave

Il risultato della progettazione fisica è lo schema fisico: a differenza di quello concettuale e di quello logico, questo schema dipende dal DBMS scelto. È il motivo per cui, in teoria, si può cambiare DBMS senza dover rifare l'intera progettazione concettuale e logica: solo lo schema fisico va riadattato.

Esempio — dallo schema logico al DDL fisico

Il caso Cliente–Ordine–Prodotto implementato in SQL

Lo schema logico del capitolo precedente, tradotto in linguaggio DDL (Data Definition Language) per un DBMS relazionale: si scelgono i tipi di dato concreti, si dichiarano chiavi primarie ed esterne, e si crea un indice sulla colonna più interrogata.

schema-fisico.sql
CREATE TABLE Clienti (
  CodiceCliente   CHAR(5)      PRIMARY KEY,
  RagioneSociale  VARCHAR(60)  NOT NULL,
  Indirizzo       VARCHAR(80)
);

CREATE TABLE Ordini (
  NumeroOrdine    CHAR(6)      PRIMARY KEY,
  DataOrdine      DATE         NOT NULL,
  CodiceCliente   CHAR(5)      NOT NULL,
  FOREIGN KEY (CodiceCliente) REFERENCES Clienti(CodiceCliente)
);

CREATE TABLE Prodotti (
  CodiceProdotto  CHAR(5)       PRIMARY KEY,
  Descrizione     VARCHAR(80),
  Prezzo          DECIMAL(8,2)
);

CREATE TABLE DettaglioOrdine (
  NumeroOrdine    CHAR(6),
  CodiceProdotto  CHAR(5),
  Quantita        INT NOT NULL,
  PRIMARY KEY (NumeroOrdine, CodiceProdotto),
  FOREIGN KEY (NumeroOrdine)   REFERENCES Ordini(NumeroOrdine),
  FOREIGN KEY (CodiceProdotto) REFERENCES Prodotti(CodiceProdotto)
);

-- indice per velocizzare le ricerche degli ordini di un cliente
CREATE INDEX idx_ordini_cliente ON Ordini (CodiceCliente);

Notare la scelta dei tipi: CHAR(5) per codici a lunghezza fissa, VARCHAR per testi a lunghezza variabile, DECIMAL(8,2) per gli importi (mai FLOAT, che introduce arrotondamenti). L'indice su CodiceCliente è una scelta tipicamente fisica: non cambia il significato dei dati, ma accelera le interrogazioni più frequenti.

Perché tre fasi e non una sola?

Separare concettuale, logico e fisico permette di rimandare le scelte tecniche alla fine del processo: prima si capisce bene la realtà da rappresentare (fase concettuale, con l'utente/committente), poi la si struttura in modo formale ma ancora astratto (fase logica), infine la si adatta a un prodotto reale (fase fisica). Un errore nella comprensione della realtà, se scoperto solo alla fine, costerebbe molto di più da correggere.

Altri esempi di progettazione

Tre casi diversi da quello dell'azienda commerciale, per vedere all'opera le altre cardinalità e qualche difficoltà pratica in più: un'associazione 1:1, una 1:N in un contesto diverso, e una N:N che richiede una chiave surrogata.

Esempio 1 — associazione 1:1

Dipendente e Badge aziendale

Ogni dipendente ha esattamente un badge, e ogni badge è assegnato a un solo dipendente: cardinalità (1,1) su entrambi i lati.

Dipendente
(1,1)
Assegnato a
(1,1)
Badge

In fase logica, un'associazione 1:1 non richiede una tabella a parte: si può fondere tutto in un'unica tabella Dipendenti, oppure — se le due entità restano concettualmente separate — inserire la chiave esterna, resa univoca, in una delle due tabelle.

DIPENDENTI (schema con fusione)
MatricolaDipendenteNomeCodiceBadge
D014Bianchi LauraB-0091
Esempio 2 — associazione 1:N in un contesto diverso

Istruttore e Corso in una palestra

Un istruttore tiene più corsi nel corso della settimana, ma ogni corso è tenuto da un solo istruttore: la stessa struttura vista per Cliente–Ordine, applicata a un altro dominio.

Istruttore
(1,1)
Tiene
(0,N)
Corso
CORSI — la FK va sempre sul lato "N" della relazione
CodiceCorsoNomeOrarioCodiceIstruttore
CR07PilatesLun/Mer 18:00I003
Esempio 3 — associazione N:N con chiave surrogata

Prestiti in biblioteca

Un utente può prendere in prestito più libri e uno stesso libro può essere prestato, in momenti diversi, a più utenti: è una N:N, come Ordine–Prodotto. Ma qui c'è una complicazione in più.

Utente
(0,N)
Prestito
(0,N)
Libro
⚠
Un caso limite da riconoscere all'esame

Se lo stesso utente potesse prendere in prestito due volte lo stesso libro (in date diverse), la coppia (CodiceUtente, CodiceLibro) da sola non sarebbe più univoca: non potrebbe fare da chiave primaria della tabella ponte, perché si ripeterebbe. La soluzione è introdurre una chiave surrogata: un identificativo artificiale, generato dal sistema, che non ha significato nella realtà ma garantisce l'unicità di ogni riga.

PRESTITI — tabella ponte con chiave surrogata IdPrestito
IdPrestitoCodiceUtenteCodiceLibroDataPrestitoDataRestituzione
1U120L04503/02/202617/02/2026
2U120L04528/08/2026—

Le due righe mostrano proprio lo stesso utente che prende in prestito lo stesso libro in due periodi diversi: senza IdPrestito le due righe sarebbero indistinguibili come chiave.

04I sistemi ERP e l'integrazione dei processi aziendali

Tutto ciò che abbiamo visto — gestione tramite database, indipendenza dei dati, progettazione a fasi — trova la sua applicazione più ambiziosa in un ERP: un'unica base di dati che, invece di sostenere una sola applicazione, sostiene l'intera azienda.

Che cos'è un ERP

Un ERP (Enterprise Resource Planning, "pianificazione delle risorse d'impresa") è un sistema informativo integrato che gestisce, attraverso un'unica base di dati condivisa, la maggior parte dei processi aziendali: amministrazione e contabilità, vendite, acquisti, gestione del magazzino, produzione, risorse umane, e spesso anche la relazione con i clienti (CRM).

Un ERP non è un singolo programma, ma un insieme di moduli — uno per ciascuna area aziendale — che condividono tutti gli stessi dati, invece di tenerne copie separate.

Dalle isole informative all'integrazione

Prima della diffusione degli ERP (a partire dagli anni '90, evolvendo dai sistemi MRP — Material Requirements Planning, anni '70 — e MRP II, anni '80), ogni reparto aziendale tendeva ad avere un proprio programma gestionale scollegato dagli altri: le cosiddette isole informative (o "isole di automazione"). È esattamente il problema della gestione tradizionale visto nel capitolo 2, ma su scala aziendale.

Prima: isole informative

gestionale_vendite
Anagrafica clienti
propria e separata
gestionale_magazzino
Giacenze
non sincronizzate
gestionale_contabilità
Fatture
inserite a mano

Ogni reparto lavora con i propri dati: un ordine inserito in Vendite non aggiorna automaticamente Magazzino o Contabilità.

Con l'ERP: un processo, un dato

Base di dati aziendale unica Vendite Acquisti Magazzino Produzione Contabilità Risorse Umane

Tutti i moduli leggono e scrivono sulla stessa base di dati: un evento registrato in un modulo è immediatamente visibile agli altri.

La funzione di integrazione dei processi

Il valore di un ERP non sta tanto nei singoli moduli — che, presi da soli, farebbero più o meno quello che farebbe un programma gestionale dedicato — quanto nel fatto che i processi attraversano i moduli senza soluzione di continuità, perché tutti condividono lo stesso dato.

i
Esempio di processo integrato

Un addetto alle vendite registra un ordine cliente nel modulo Vendite. Automaticamente: il modulo Magazzino impegna la quantità di prodotto disponibile; se il prodotto non è sufficiente, il modulo Produzione (o Acquisti) può generare un ordine di produzione o di riordino; alla consegna, il modulo Contabilità genera la fattura, senza che nessuno debba re-inserire manualmente cliente, prodotto o importi in un sistema separato.

Questa integrazione elimina i doppi inserimenti e, di conseguenza, gran parte della ridondanza e delle incoerenze descritte nel capitolo 2: è la stessa logica della gestione a database, applicata non più a una singola applicazione ma all'intera azienda.

Vantaggi e criticità

Vantaggi

  • Elimina i silos informativi e la ridondanza tra reparti diversi.
  • Offre una visione unica e aggiornata dei dati aziendali (single source of truth).
  • Aumenta l'efficienza e la tracciabilità dei processi end-to-end.
  • Migliora il supporto alle decisioni, grazie a dati coerenti e in tempo reale a ogni livello della piramide di Anthony.

Criticità

  • Costi di acquisto e implementazione elevati.
  • Tempi di adozione lunghi e necessità di formare il personale.
  • Forte impatto organizzativo: spesso richiede di ripensare le procedure esistenti (change management).
  • Necessità di personalizzazione per adattarlo alle esigenze specifiche dell'azienda.
SAP S/4HANA Oracle Cloud ERP Microsoft Dynamics 365 Odoo (open source)
⚠
Collegamento con il capitolo 3

Anche la base di dati di un ERP nasce da uno schema concettuale (E-R), tradotto in schema logico e poi fisico, esattamente come nel caso Cliente–Ordine–Prodotto — solo su scala molto più ampia: centinaia di entità collegate, invece di tre o quattro.

05Glossario lampo

Clicca su ogni scheda per vedere la definizione. Utile per un ripasso veloce prima dell'interrogazione.

Sistema informatico
La componente automatizzata del sistema informativo: hardware, software e reti che realizzano, in tutto o in parte, la gestione delle informazioni.
DBMS
Data Base Management System: il software che crea, gestisce e protegge la base di dati, facendo da intermediario tra utenti/applicazioni e i dati fisici.
Ridondanza
Presenza dello stesso dato in più punti dell'archivio o della base di dati, con rischio di spreco di spazio e di incoerenza tra le copie.
Entità
Nel modello E-R, una classe di oggetti del mondo reale con esistenza autonoma e rilevante per l'applicazione. Si rappresenta con un rettangolo.
Cardinalità
Indica quante occorrenze di un'entità possono essere associate a occorrenze di un'altra entità in una relazione: 1:1, 1:N, N:N.
Chiave esterna (FK)
Un attributo (o gruppo di attributi) di una tabella che fa riferimento alla chiave primaria di un'altra tabella, realizzando un legame tra le due.
Normalizzazione
Processo di verifica e correzione di uno schema logico per eliminare ridondanze e anomalie, attraverso forme normali progressive (1NF, 2NF, 3NF).
Integrità referenziale
Vincolo secondo cui il valore di una chiave esterna deve corrispondere a un valore esistente della chiave primaria referenziata, o essere nullo.
Chiave surrogata
Identificativo artificiale, generato dal sistema, usato come chiave primaria quando gli attributi naturali non bastano a garantire l'unicità di ogni riga.
ERP
Enterprise Resource Planning: sistema informativo integrato che gestisce, con un'unica base di dati condivisa, la maggior parte dei processi aziendali.
Silos informativo
Sistema o archivio isolato, usato da un solo reparto, non collegato agli altri: genera dati duplicati e non coerenti tra i reparti.

06Verifica autocorrettiva

Quindici domande a risposta multipla in stile esame. Scegli una risposta per vedere subito se è corretta, con spiegazione.

Punteggio: 0 / 0