CRM, Business Intelligence e Organigramma

Uno degli aspetti più banali e regolarmente sottostimati di un sistema CRM è il costo in termini di ore uomo nell'utilizzo dello stesso.
Ma una interessante conseguenza del suo uso è la raccolta di dati, spesso eterogenei perchè multiruolo.
Il primo segnale preoccupante, ancor prima del roll-out del progetto, è un eccessivo focus su dati provenienti da fonti "non umane", ovvero dati già esistenti su altri sistemi, come ad esempio ordinato, fatturato, pagamenti e varie amenità tipicamente gestionali.
Unendo questi due fattori, quindi il costo di utilizzo e l'esistenza di dati preesistenti, si ottiene una interessante implosione del sistema CRM in un sistema di Business Intelligence.

Per quanto gradevole possa essere da punto di vista estetico, è evidentemente sia uno spreco che un uso non corretto dello strumento.

E' quindi fondamentale iniziare a definire, in fase progettuale, gli attori ed il ruolo che dovranno giocare all'interno del sistema, valutando quindi i dati che si richiede essi generino e governino.

Una semplice equazione può aiutare a fare chiarezza: basta moltiplicare l'estensione del singolo dato, ad esempio quanti campi devono essere compilati, per la frequenza di compilazione.

• Costo = Estensione Dato X Frequenza compilazione

Per compensare questo costo, un sistema CRM è in grado di generare una serie di benefici, che aumentano notevolmente nella misura in cui sono inclusi nel progetto ruoli differenti, non solo al livello gerarchico, ma anche come mansione.

Il livello gerarchico può sembrare un imperativo perché è logico che il management, a vari livelli, debba interagire con il sistema, ma osservando l'equazione del costo si evince che, salendo nell'organigramma, il contributo sarà sempre meno interessante in termini di dati...e purtroppo non necessariamente più qualitativo.

Invece una molteplicità di mansioni permette di ottenere una base dati eterogenea, generata sul campo, che costruisce un disegno ricco e difficilmente ricavabile dai sistemi esistenti.

Analisi e definizione del modello ARC

Il primo passo è l'acquisizione (o la definizione) dell'organigramma, indagando ad un buon livello di dettaglio l'Architettura dell'azienda.

Successivamente si passa a verificare le Routine esistenti, in modo da evidenziare sia i processi che le interazioni presenti.
Questo secondo aspetto servirà in un secondo momento per ottimizzare e potenziare i processi grazie all'implementazione di automatismi (workflow)

Ultimo ma non meno importante, il sistema CRM deve rispettare ed enfatizzare la Cultura aziendale, perché l'impianto non sia conflittuale e adiacente agli usi e costumi delle persone.

Qualche spunto in più, non proprio leggero, si trova anche qui

Gestire il cambiamento

Se il sistema CRM non genera un cambiamento, è sostanzialmente inutile per non dire dannoso.
Ma il cambiamento deve essere progettato affinché sia possibile e la definizione del nuovo modello, o delle modifiche a quello attuale, è la chiave per il successo.

Un modello futuro troppo distante dal quello attuale è irrealizzabile perché conflittuale e probabilmente troppo costoso (v. equazione del costo), un modello troppo adiacente non fornisce dati oltre a quanto già a disposizione.

Oltre alla definizione di un corretto mix, è più semplice iniziare cercando di identificare le problematiche (Pains) e definire una sequenza di interventi per la loro risoluzione.

Nei prossimi articoli vediamo alcuni temi (Pains) classici su cui operare