OKR e pensiero sistemico: obiettivi che tengono conto delle conseguenze

Gli OKR collegano un obiettivo a risultati chiave verificabili. Il pensiero sistemico aiuta a vedere come quel risultato influenza il lavoro delle altre parti. Usarli insieme significa chiedersi che cosa cambia intorno alla misura scelta, prima di premiarne il miglioramento.

Considera un esempio illustrativo: il marketing deve aumentare le richieste commerciali. Le campagne producono più moduli, il risultato locale migliora. Il team vendite, già saturo, richiama più tardi. Alcuni contatti validi si perdono e quelli meno pertinenti assorbono tempo. L’obiettivo è stato raggiunto, ma non sappiamo se l’azienda venda meglio.

Non è una critica alla misurazione. È una richiesta di misurare la relazione che conta. Un indicatore di attività diventa pericoloso quando viene trattato come una descrizione completa del risultato.

“Installare un CRM” descrive una consegna. “Ridurre le richieste valide senza responsabile” descrive un cambiamento nel lavoro. Il primo può essere necessario al secondo, ma non lo dimostra. Quando scrivi un risultato chiave, verifica quale comportamento osservabile dovrebbe cambiare.

Aggiungi poi un limite di controllo: qualcosa che non deve deteriorarsi mentre persegui il risultato. Per esempio, aumentare gli ordini non dovrebbe produrre un livello di errori di consegna che l’azienda considera inaccettabile. La soglia si decide sui dati iniziali e sugli impegni reali, non prendendo un numero da un modello online.

Una misura operativa può rimanere importante per anni: ordini consegnati correttamente, richieste ancora aperte, costo di una lavorazione. Serve a sapere come sta andando il lavoro. Un OKR individua invece un cambiamento su cui concentrare l’attenzione in un periodo. Confondere le due cose produce liste molto lunghe, nelle quali ogni attività diventa una priorità.

La guida Google re:Work sugli OKR, conservata come riferimento storico, distingue risultati e lista delle attività. È utile per impostare il formato. Le pratiche di una singola organizzazione, però, non sono un regolamento da trasferire senza adattamento: la tua azienda deve chiarire quali impegni sono vincolanti e quali obiettivi rappresentano un’esplorazione.

“Provare un nuovo modo di qualificare le richieste” può avere un esito incerto. “Rispondere agli ordini già accettati nei tempi contrattuali” non diventa facoltativo perché il team ha adottato un metodo ambizioso. Mescolare queste due categorie rende difficile capire quando uno scostamento sia apprendimento e quando sia una mancata consegna.

Per ogni risultato chiedi quindi se stai monitorando un servizio già dovuto o cercando di cambiare una condizione. Mantieni visibili entrambi, ma non trasformarli nello stesso punteggio. Il team ha bisogno di sapere cosa può sperimentare e quali responsabilità deve continuare a presidiare.

Un risultato può dipendere da un reparto che non ha partecipato alla sua definizione. Può emergere dopo il periodo di valutazione. Può persino modificare il comportamento delle persone in un modo inatteso: se premi solo il numero di chiamate, qualcuno potrebbe accorciare le conversazioni che richiedono più attenzione.

Nel saggio sui punti di intervento nei sistemi, Donella Meadows distingue parametri, informazioni, regole e obiettivi. È un riferimento per capire perché cambiare un numero-obiettivo non equivalga a cambiare il funzionamento che lo produce. Qui applichiamo quel ragionamento agli OKR, senza attribuire al saggio un metodo proprietario o percentuali di efficacia. Fonte: Leverage Points di Donella Meadows.

Disegna soltanto le relazioni necessarie alla decisione. Nel caso delle richieste: campagne, criteri di qualificazione, capacità di risposta ed esito commerciale. Se una parte non è misurata, segnala l’incertezza. Una freccia nel diagramma resta un’ipotesi finché non hai osservazioni che la sostengano.

Torniamo al team commerciale. All’inizio del mese arrivano più richieste di quante ne vengano lavorate. La differenza si accumula: non sparisce quando il report riparte da zero il mese successivo. Se misuri solo gli ingressi nuovi, puoi non vedere che stai lasciando indietro persone entrate prima.

Prendi un piccolo conto illustrativo, senza attribuirlo a un cliente. Lunedì ci sono 20 richieste valide da assegnare. Nella settimana ne entrano altre 50 e il team ne prende in carico 40: venerdì ne restano 30. La produzione commerciale è aumentata rispetto a una settimana da 35 prese in carico, ma anche la coda è cresciuta. Le due cose possono essere vere contemporaneamente.

Il calcolo è semplice: coda finale uguale coda iniziale più nuovi ingressi meno prese in carico, a parità di definizione. È utile proprio perché costringe a collegare i periodi. Se alcuni contatti vengono esclusi dopo una verifica, registra separatamente quell’uscita: non chiamarla presa in carico per migliorare l’indicatore.

Guarda poi l’età delle richieste ancora aperte. Una media può sembrare accettabile perché molti contatti recenti nascondono pochi casi fermi da settimane. Per una decisione operativa può essere più utile un elenco dei casi oltre il tempo concordato, con responsabile e motivo del blocco, che un’altra media colorata.

Una coda crescente non prova automaticamente che servano più commerciali. Le richieste potrebbero essere più difficili da gestire, l’assegnazione potrebbe dipendere da una persona assente oppure la qualifica potrebbe essere cambiata. Scrivere queste alternative evita di trasformare il primo sospetto in un progetto.

Confronta, per esempio, “manca capacità” e “manca una regola di assegnazione”. Nel primo caso le richieste risultano assegnate, ma aspettano perché ciascun referente ha troppo lavoro. Nel secondo si fermano prima ancora di arrivare a qualcuno. Le azioni da finanziare sono diverse. Un’automazione di assegnazione non crea ore disponibili; un’assunzione non chiarisce una regola ambigua.

Decidi quale osservazione potrebbe farti cambiare idea. Una prova utile deve poter smentire l’ipotesi di partenza. Se qualunque esito viene interpretato come ragione per comprare lo stesso software, stai preparando una giustificazione, non una verifica.

Una misura non si limita a descrivere il lavoro quando diventa il criterio con cui il lavoro viene giudicato. Se conta soltanto il numero di opportunità aperte nel CRM, la tentazione può essere classificare come opportunità anche contatti ancora poco chiari. Se conta soltanto la velocità di chiusura, i casi difficili possono essere spostati fuori dal conteggio.

Non serve presumere cattiva fede. Una persona può seguire correttamente la regola ricevuta e produrre un effetto indesiderato. Per questo l’audit di un risultato deve guardare come viene costruita la misura: quando un caso entra, quando esce, chi può cambiare lo stato e cosa accade ai casi che non rientrano nelle categorie.

Nel commerciale, la qualificazione delle richieste deve essere concordata con chi le lavorerà. Nell’e-commerce, vendere più articoli non basta se cambia il contributo per ordine. Nel software, contare rilasci non dice se le persone riescano a svolgere un’attività senza errori.

Una verifica utile consiste nel chiedere: potremmo raggiungere questo numero lasciando il problema iniziale esattamente com’è? Se la risposta è sì, la misura ha bisogno di un controllo o di una definizione migliore. Aggiungere altri dieci indicatori non risolve automaticamente il difetto del primo.

La mappa non deve contenere tutta l’azienda. Scrivi il cambiamento desiderato al centro del confronto e individua chi fornisce informazioni, chi esegue il lavoro e chi riceve il risultato. Per ogni collegamento descrivi una dipendenza concreta: il commerciale può assegnare correttamente solo se zona e disponibilità del referente sono aggiornate.

Accanto a ogni dipendenza segna se è un fatto osservato oppure un’ipotesi. “Le richieste si fermano per dati incompleti” è verificabile aprendo un campione autorizzato di casi. “Il team resiste al cambiamento” è un giudizio molto più ampio: prima di usarlo per decidere, devi capire quali comportamenti lo sostengono e quali spiegazioni alternative esistono.

Chiudi la riunione con una modifica che qualcuno possa eseguire e una data in cui rileggerne l’effetto. Se decidete di cambiare una regola di assegnazione, documentate anche le eccezioni e il sostituto in caso di assenza. Se serve intervenire sul software, chiarite se sia sufficiente una configurazione o se occorra integrare o costruire una funzione.

Un assistente può aiutare a raggruppare motivi di blocco, confrontare note autorizzate o preparare una bozza del report. Sono attività utili se riducono il lavoro necessario a vedere le eccezioni. La classificazione deve però poter essere controllata sui casi di origine: una sintesi molto fluida può nascondere differenze decisive.

Non lasciare al modello il compito di inventare il dato mancante o cambiare la definizione di successo. Se mancano informazioni sulle richieste perse, il report deve conservarne l’assenza. Il criterio è lo stesso della validazione dei dati prima di una scrittura nel gestionale: la proposta e la verifica sono passaggi diversi.

La responsabilità di scegliere il nuovo obiettivo resta alla direzione. Un report può segnalare che la capacità è satura; non autorizza da solo assunzioni, variazioni di budget o promesse ai clienti. Se l’ostacolo principale è la scelta delle priorità commerciali, il confronto con un incarico di direzione marketing chiarisce chi dovrebbe prendere quelle decisioni.

Quando il risultato non arriva, chiedi prima se l’ipotesi fosse corretta. Il team potrebbe aver eseguito le attività concordate mentre il vincolo si trovava altrove. Un rituale in cui ogni scostamento diventa solo una richiesta di impegnarsi di più impedisce di imparare.

Conserva dato iniziale, definizione e data di verifica. Se cambi il modo di contare, non confrontare automaticamente il nuovo valore con quello vecchio. Per i contatti commerciali, parti dalla definizione condivisa di lead qualificato.

Se gli obiettivi si contraddicono tra reparti, serve una decisione di direzione. Può essere utile una lettura del sistema aziendale o una responsabilità operativa come il Fractional COO. Il software non arbitra da solo priorità incompatibili.

Lo stesso ragionamento si vede nel rapporto tra crescita degli ordini e margine. Un buon OKR rende questo collegamento discutibile con prove, invece di nasconderlo dietro un risultato di reparto in verde.