Menu

Issue 10005 · Integrazione

System of Record vs System of Engagement: chi possiede la verità, chi l’esperienza

Quando CRM, OMS, ERP e canali digitali mostrano lo stesso oggetto, chiarire ownership e responsabilità evita conflitti operativi e discussioni infinite.

· 5 min

Obiettivo

Distinguere il sistema che possiede il dato ufficiale dal sistema che gestisce l'interazione con utenti, clienti o operatori.

Come distinguere i due ruoli in modo utile

In una revisione architetturale, la domanda non è solo “dove sta il dato?”, ma “chi è responsabile della sua verità operativa e chi della sua esperienza d’uso”. Il System of RecordGlossarioSystem of RecordIl sistema autorizzato a decidere il valore corrente di uno specifico fatto di business.Apri la voce completa è il sistema che può creare, modificare e governare quello stato in modo autorevole. Il System of Engagement, invece, è progettato per raccogliere input, guidare l’interazione e presentare una vista coerente e usabile, spesso aggregando informazioni da più fonti. Il punto pratico è questo: se un sistema mostra un cliente, un ordine o un contratto, non significa che possa anche essere il luogo giusto per aggiornarlo. In architettura conviene separare tre domande: chi è master del dato, chi lo visualizza e chi può modificarlo. Questa distinzione riduce ambiguità su ownership, API, sincronizzazione e gestione degli errori quando le viste divergono.

I trade-off da esplicitare subito

Assegnare un System of Record chiaro porta beneficio su correttezza, auditabilità e responsabilità operativa. Però introduce vincoli: il sistema autorevole può diventare un collo di bottiglia, e gli altri sistemi devono accettare regole di integrazione più rigide. Dall’altra parte, un System of Engagement dà velocità al business e migliora l’esperienza utente, ma spesso lavora con dati aggregati, cache o arricchiti. Il rischio è che il front-end o la CDP vengano percepiti come “la verità”, quando in realtà espongono una vista parziale o temporaneamente inconsistente. In pratica, il trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa è tra autonomia di canaleGlossarioCanaleUn formato o una destinazione attraverso cui una issue raggiunge il lettore.Apri la voce completa e disciplina del dato: più libertà ai canali, più attenzione serve per prevenire drift, conflitti di update e ticket di riconciliazione.

Esempio enterprise: e-commerce, OMS, ERP e CRM

In un contesto retail, il canale e-commerce raccoglie l’intenzione del cliente ed è spesso il System of Engagement. L’OMS governa orchestrazione dell’ordine e fulfillment, mentre l’ERP mantiene aspetti contabili o logistici autorevoli. Il CRM conserva la relazione cliente, e una CDP può arricchire il profilo per segmentazione e comunicazioni. Il problema tipico nasce quando il team di canale vuole “aggiornare il cliente” direttamente dalla web app, o quando il marketing usa la CDP come se fosse il master del customer profile. Se non si chiarisce chi può modificare quale attributo, si finisce con sincronizzazioni opache, dati confliggenti e incidenti su processi a valle, come spedizioni, fatturazione o comunicazioni regolatorie. In una review seria, la mappa da portare al tavolo è: quale sistema possiede ogni attributo, quale espone la vista e quale è solo consumatore.

Per approfondire

Fonti esterne autorevoli per approfondire la distinzione tra system of record e system of engagement. • Martin Fowler, Patterns of Enterprise Application Architecture - https://martinfowler.com/books/eaa.html • Michael Nygard, Documenting Architecture Decisions - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions

Tag