Project: diagnosis of company data culture

Questo è un laboratorio: metterai in pratica tutto il modulo su un caso concreto, diagnosticando la cultura dati di un’organizzazione. L’obiettivo non è produrre un bel report, ma capire dove le decisioni usano davvero le evidenze e dove prevalgono abitudine o gerarchia. Alla fine avrai una roadmap di interventi con owner, metrica di successo e scadenze.

L’idea in una frase

La diagnosi della cultura dati misura dove le decisioni usano davvero le evidenze e dove invece prevalgono abitudine o gerarchia.

Il percorso in cinque passi

1. Scegli tre decisioni recenti da diagnosticare, con owner ed esito noti.
2. Assegna un punteggio da 1 a 5 a literacy, evidenza, metriche condivise, tooling e sicurezza psicologica.
3. Per ogni pilastro sotto 3 definisci obiettivo a sei mesi, azione, metrica di successo e owner.
4. Distribuisci gli interventi in quick win a un mese, formazione a tre mesi e processo standard a sei mesi.
5. Ricontrolla con la stessa tabella se le scelte seguono ora l’evidenza.

Fase 1: assessment

Valuta l’organizzazione su ogni pilastro con un punteggio da 1 a 5. La data literacy misura se i manager sanno leggere un grafico e interpretare una media. La decisione per evidenza misura se le scelte importanti passano davvero dai dati. La metrica condivisa controlla se MRR, churn e MAU hanno una sola definizione. Il tooling controlla se gli analyst hanno gli strumenti per lavorare. La sicurezza psicologica misura se qualcuno puo dire che i dati contraddicono il vertice senza ripercussioni.

Fase 2: piano di miglioramento

Per ogni pilastro sotto il punteggio di 3 definisci quattro elementi. Prima un obiettivo a sei mesi. Poi un’azione concreta, per esempio una review obbligatoria basata su dati per i progetti sopra i 50K. Poi una metrica di successo che dica se l’azione sta funzionando. Infine un owner che ne risponde.

Tra tanti interventi possibili, finanzia prima quelli con owner nominato e metrica di successo datata.

Fase 3: roadmap

La roadmap distribuisce gli interventi nel tempo. Nel primo mese punta i quick win, come definizioni condivise e dashboard accessibili. Al terzo mese forma il middle management sulla data literacy. Al sesto mese standardizza il processo decisionale con evidenza obbligatoria. La diagnosi diventa concreta quando il team mappa tre decisioni recenti: una presa da dashboard, una per escalation gerarchica e una sotto pressione commerciale.

Element	Operational Definition	Controllo minimo
Unit of analysis	Oggetto su cui misuri il fenomeno	Utente, account, evento, ordine o periodo
Variabile osservata	Segnale che rappresenta il comportamento	Definizione stabile e tracciabile
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che puo restare anche dopo l’analisi	Controllo di sensitivita o revisione qualitativa

La vista di controllo in SQL

Il pattern seguente crea una base analitica con metrica, segmento e finestra temporale. Offre alla diagnosi un’evidenza tabellare comune.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

La query produce trend, segmenti e differenze tra canali da allegare al memo di diagnosi.

Il controllo di stabilita in Python

Una metrica di diagnosi resta stabile per orientare gli interventi e sensibile per segnalare i cambiamenti reali.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il controllo distingue le oscillazioni casuali dai segnali che richiedono un intervento sulla cultura decisionale.

Gli errori tipici da evitare

Il primo errore e leggere medie aggregate senza segmentare. Nasconde i team o i periodi dove il processo si rompe. Il secondo e ignorare la qualita del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono diagnosi false. Il terzo e trattare la diagnosi come sondaggio di clima invece che come audit di tre decisioni reali con owner ed evidenze. Ogni diagnosi deve includere definizione esplicita delle metriche, confronto per segmento e controllo contro un periodo precedente.

Un caso reale: lo standard dei memo di Amazon

Dal 2004 Amazon richiede memo narrativi di sei pagine al posto delle slide nelle riunioni dirigenziali, letti in silenzio all’inizio. La pratica costringe chi propone a esplicitare decisione, evidenze, nessi logici e numeri prima di chiedere budget. Vent’anni dopo la regola e ancora in uso perche sposta la diagnosi dal clima alle prove scritte. Il caso mostra lo standard di una diagnosi matura: tre decisioni recenti rilette con owner, evidenza primaria e punto esatto in cui il processo ha retto o si e rotto.

Verdetto: la diagnosi della cultura dati vince quando è un audit di tre decisioni reali con owner ed evidenze, non un sondaggio di clima: finanzia prima gli interventi con owner nominato e metrica di successo datata, e ricontrolla con la stessa tabella se le scelte seguono l’evidenza.

Domande per verificare la tua comprensione

1. Quali tre decisioni recenti useresti per diagnosticare la cultura dati?
2. Quale pilastro sotto il punteggio di 3 affronteresti per primo e perche?
3. Quale azione concreta, quale owner e quale metrica di successo fisseresti a sei mesi?
4. Come dimostreresti tra sei mesi che le scelte seguono davvero l’evidenza?