Implementazione di un CRM: un confronto tra approccio applicativo e organizzativo (software selections e TCO)

In una buona parte di aziende si ritiene che l’acquisto di un applicativo di CRM (ossia una o alcune delle sue componenti Line of Business: Customer Care/Support, SFA – Sales Force Automation, Contact Center, Marketing Automation, Customer Services e così via) esaurisca in concreto il processo di implementazione della piattaforma Customer Relationship Management. Personalmente ritengo che l’acquisto rappresenti anche un punto di partenza.
È un punto di arrivo in quanto l’azienda che intende adottare un CRM vuol dire che intende (più o meno consapevolmente) sposare la filosofia/strategia di mettere il cliente al centro delle proprie attenzioni/relazioni: a tal fine la software selection non può prescindere dagli obiettivi che l’azienda intende conseguire dai relativi requisiti/funzionalità che tendono a concretizzare tali obiettivi.
È un punto di partenza perché gli applicativi di CRM sono validi (e non sempre indispensabili) supporti di automazione e di analisi: se la software selection è stata fatta con i criteri sopra riportati, l’implementazione degli applicativi in qualche modo è l’avvio alla realizzazione degli obiettivi prefissati.

1. Ripartizione dei costi per l’adozione di un CRM

I costi per un progetto CRM includono gli hardware, i servizi e i software per sviluppare il CRM selezionato, i costi del primo anno di supporto e manteinance, ai quali vanno aggiunti i costi di implementazione veri e propri (composti dai costi del personale interni ed esterni impiegato per tutta la durata della selezione, analisi, personalizzazione, test, ecc., vedi capitoli successivi).
L’istogramma riporta dei dati ricavati da un benchmark tra i più importanti competitor a livello mondiale, basato su implementazioni di CRM per 75/100 utenti, per un mercato di fascia alta (sopra i 50 mila €uro di soli costi licenza).
Nel grafico sotto riportata si possono notare le percentuali stimate dei costi divise per categoria, in particolare viene segnalato il fatto che i costi software sono un quarto dei costi di implementazione.

image

Una dimostrazione della validità di quanto sostenuto, la voce di costo della componente applicativa è solamente il 9% del totale. Per implementazioni con meno utenti e/o con meno esigenze o dimensioni aziendali, la percentuale delle licenze software (licenze, attivazioni, canoni, ecc.) è destinata a crescere sensibilmente. Ad esempio per un CRM per un mercato di fascia medio basso (con budget dai 10 ai 20 mila €uro), il costo delle licenze è destinato a raggiungere, mediamente, il 40-50% del TCO – Total Cost of Ownership basato sui primi tre anni.

Andiamo ora ad approfondire le varie fasi al fine di avere una visione di assieme delle problematiche e delle soluzioni apportate. Diamo per scontato che la software selection sia stata effettuata con un definizione dei requisiti, dei parametri di TCO – Total Cost of Ownership e con la successiva scelta dell’implementatore.

2. La prassi di implementazione “applicativa”, utilizzata per implementazioni di CRM per il mercato di “fascia bassa” (fino ai 10 mila €uro)

image Esistono soluzioni di CRM erogate in ASP (Application Service Provisioning), che richiedono un tempo limitato per la configurazione: i servizi vengono erogati direttamente attraverso il browser.
Nel caso di un’installazione onsite (presso la sede/data center del cliente), esistono applicativi di CRM sono semplici da installare, e richiedono requisiti server Open Source.
In altri casi, ci sono CRM che sono dotati addirittura di supporti software ed altra documentazione dettagliata. Tale documentazione si rivolge all’amministratore di sistema ed è basata sul presupposto che tutte le organizzazioni in cui viene implementato il software di CRM dispongano dei servizi di un fornitore di software indipendenti (ISV, Independent Software Vendor) o di un rivenditore a valore aggiunto (VAR, Value-Added Re-seller).

Riporto qui di seguito un esempio d’implementazione per un CRM con budget dai 5 ai 10 mila €uro (per i soli costi di licenze, canoni, ecc.). In questo contesto più che un’acquisto di un applicativo di CRM (o una o più delle sue componenti di LOB/Line of Business), possiamo parlare di moduli singoli, con caratteristiche prevelentemente operative e di gestione di canale.

FASE 0: Ricerca applicativo, visualizzazione demo e trattativa di acquisto
– Effettuata dal cliente sulla base delle sollecitazioni provenienti dai vendor (fornitori di applicativi di CRM)
– In questo caso si potrebbe prefigurare una non piena consapevolezza (strategica, di orientamento al cliente, ecc.), da parte dell’azienda, ma solamente una o più esigenze di tipo funzionale/operativo (gestione assistenza post vendita, gestione di DEM – Direct e-Mail Marketing, necessità di un Customer DataBase, ecc.)
FASE 1: Attivazione
– Attivazione del prodotto/applicativo, in questa fase il cliente, avendo un approccio operativo, essendo stato approcciato e convinto dal vendor che i suoi problemi/esigenze potevano essere risolti/tradotti in funzionalità (soluzioni = funzionalità), si concentra sull’attivazione e sul primo utilizzo delle funzionalità/moduli acquistate.
– È importante che nella fase di attivazione sia nominato un responsabile dell’implementazione interno che faccia da riferimento al fornitore.
– Nel caso di un’installazione onsite (presso la sede/data center del cliente), occorre che vengano rispettati i requisiti server, dei sistempi informativi e degli applicativi e/o database richiesti.
FASE 2: Personalizzazione
– Il prodotto/applicativo di CRM, in molti casi, per poter diventare pienamente operativo deve essere personalizzato attraverso:
> Importazione di dati (clienti, prodotti, ecc.), setup iniziale, definizione utenti, permission, ecc.
> Interfacciamento o integrazione con DataBase e/o applicativi esistenti (es.: fax, Outlook/e-mail, Gestionali/ERP – Enterprise Resource Planning, ecc.)
FASE 3: Test di efficienza e di interoperabilità
– Vengono testate o quanto meno provate l’efficienza delle funzionalità ed i processi che sono interessati del CRM (es.: la trascrizione delle offerte, in caso di SFA – Sales Force Automation, e la loro importazione nel gestionale come ordini, l’importazione dei dati da Outlook o da OWA – Outlook Web Access, ecc.)
FASE 4: Formazione
– Effettuata dal fornitore al responsabile dell’implementazione interno
FASE 5: Richiesta e implementazione di moduli aggiuntivi
– In un secondo tempo, il cliente, una volta soddisfatte le aspettative iniziali

3. Confronto tra implementazione “applicativa” e “organizzativa” del CRM

image Quest’articolo intente introdurre all’implementazione di un CRM come un vero e proprio progetto. Tale progetto, può essere assunto come modello per quelle imprese che intendono adottare un CRM (inteso come strategia, processi di marketing e commerciali nonché l’adozione di una o più soluzioni applicative).
L’approccio è prevalentemente “organizzativo“: considera l’azienda nei suoi processi da e verso la clientela, prevalentemente, considerando gli strumenti (piattaforme/applicativi) come strumenti a supporto dei processi considerati.
Un approccio “applicativo” non è da considerarsi alternativo a quello “organizzativo”, ma, direi, complementare. In che cosa consiste questo approccio applicativo? Nel considerare (prevalentemente) l’aspetto software del CRM. In dettaglio, il confronto tra le fasi implementative dell’approccio organizzativo con quello applicativo possono essere così rappresentate:


Implementazione applicativa (enfasi sul supporto/software)

Implementazione organizzativa (enfasi sui processi aziendali)

Fascia di mercato medio/bassa:
Per un progetto di implementazione con budget dai 10 ai 20 mila €uro (per i soli costi di licenze, canoni, ecc.)
Fascia di mercato medio/alta:
Per un progetto di implementazione con budget di almeno 20/30 mila €uro (per i soli costi di analisi, licenze, canoni, ecc.)
  • FASE 0: Definizione requisiti
    (per la software selection): effettuata dal cliente sulla base delle funzionalità degli applicativi di CRM presi in considerazione
  • FASE 1: Definizione dei requisiti di implementazione dettagliati
    (utile anche per focalizzare le integrazioni necessarie con la piattaforma e con i dati preesistenti)
  • FASE 1: Elaborazione PROGETTO e definizione Obiettivi Operativi(costituzione del Project Manager e del team d’implementazione)
  • FASE 2: Implementazione dei requisiti (creazione ambiente di sviluppo, di test e di produzione, migrazione, importazione dei dati, server, sistama operativo, ecc.)
  • FASE 2: Analisi processi e attività operative
    (definizione delle caratteristiche e delle attività/cliente in riferimento agli obiettivi ed ai processi “as is” e “to do”
  • FASE 3: Rollout (fase di rilascio in cui sistemi precedenti convivono con il nuovo sistema)
    e
    Test (effettuato per funzionalità, per carico con particolare attenzione all’usabilità)
  • FASE 3: Piano esecutivo
    Sviluppo e implementazione interventi di innovazione e miglioramento
    N.B.: in questa fase potrebbe anche essere effettuata la
    software selections
  • FASE 4: Formazione
    (effettuata dall’implementatore e/o dai key user, gli utenti interni abilitati al test)
  • FASE 5: Comunicazione con utenti interni ed esterni (al fine di garantire l’accettazione del sistema)
  • FASE 4: Ottimizzazione e verifiche finali
    (check-up complessivo sul progetto, relativamente al grado di utilizzo ed al raggiungimento degli obiettivi prefissati, in ordine alla
    misura delle prestazioni ed ai necessari interventi correttivi)

Dalla tabella sopra esposta, si evince quanto segue:
image · I due approcci, come accennato, sono complementari: l’approccio prevalentemente organizzativo e di processo arriva a salvare anche applicativi di CRM appena discreti, al contrario un’implementazione troppo sbilanciata sugli aspetti tecnologici e funzionali può compromettere il successo stesso dell’iniziativa.
· l’approccio organizzativo e di processo garantisce la misurazione (vedi l’articolo sulla misura delle prestazioni) delle performance e la finalizzazione in attività mirate verso prospect e clienti che la pura disponibilità (anche enorme) dei dati da sola non garantisce (vedi: CRM Analitico e CRM Intelligence)
image · L’ideale sarebbe il mantenimento di entrambi gli aspetti (organizzativi e applicativi) in un unico progetto d’implementazione, anche se nella realtà accade molto raramente.
· Le fasce di mercato sono molto indicative e basate, per comodità, sul budget a disposizione dell’azienda per i soli costi esterni (consulenze per analisi ed integrazione, licenze, canoni, ecc.), ma servono per dare l’idea dei costi che i due approcci generano e che quindi devono essere coperti da un budget adeguato.
· Ricordiamo che le implementazioni di CRM possono essere molto lunghe e complesse: le implementazioni ben gestite possono determinare il successo stesso del progetto.

In un prossimo articolo, approfondirò il case history di un progetto e le fasi dell’implementazione di un CRM, con l’approccio “organizzativo”, di progetto d’implementazione. Tale progetto, potrà essere assunto come modello per quelle imprese che intendono adottare un CRM (inteso come strategia, processi di marketing e commerciali nonché l’adozione di una o più soluzioni applicative).

Leonardo Milan

Technorati Tag: Glossario CRM

Contatore visite gratuito

Implementazione nuove funzionalità CRM: Procedure di esecuzione Test

Qui di seguito sono riportate alcune informazioni di natura metodologica relativamente ai vari test e procedimenti da eseguire nel processo di implementazione delle funzionalità per lo sviluppo e la personalizzazione di un CRM.

  1. Requisiti Utente: REQUISITI CLIENTE e ANALISI FUNZIONALITA’
  2. Requisiti di Sistema: ANALISI TECNICA
  3. Requisiti del Software: PROGETTO ESECUTIVO D’IMPLEMENTAZIONE
  4. Sviluppo
  5. Verifiche

Ecco uno schema esaustivo di quanto sopra elencato (Fonte: ing. E. Tramontana – Ingenieria del software), che riporta gli input ed i ruoli/persone coinvolte nel processo:

image

Riporto qui di seguito il dettaglio delle tipologie di verifica e di Test che sono necesarie, sia durante la fase del PROGETTO ESECUTIVO D’IMPLEMENTAZIONE (test sui prototipi) che, ovviamente, durante e dopo la fase di SVILUPPO/PRODUZIONE/IMPLEMENTAZIONE.

A. TEST FUNZIONALI (o di funzionalità)
Servono per confermare le funzionalità implementate in rapporto alla lista delle specifiche.
Chi fa il test non conosce i dettagli della programmazione ma i risultati attesi
· Tale test deve garantire il funzionamento di quanto sviluppato.
· Tale funzionamento è riscontrabile dalle documento di ANALISI TECNICA, funzionalità ad esempio, del v-CRM
· Si conviene che i Test Funzionali si articolino in tre tipologie, dalla più semplice alla più complessa: il test di funzione, test di modulo e test d’integrazione. · TEST DI FUNZIONE
test effettuato dallo sviluppatore direttamente al rilascio della funzionalità sviluppata (pagina, task o insieme di task componenti una funzionalità)
In tal caso i BUG rilevati dal TEST FUNZIONALE, dovranno essere risolti all’interno del task di sviluppo (senza creare un apposito item)
Per le funzionalità che hanno una certa complessità, il test funzionale deve essere effettuato i TEST DI MODULO
Importante: in questa fase l’approccio migliore è quello di adottare il Test Driven Development (TDD) (vedi anche Blogs.ugidotnet>>) · TEST DI MODULO
effettuata da un altro collega sviluppatore
In tal caso i BUG rilevati dal TEST FUNZIONALE, rileverà la seguente tipologia avranno (prevalentemente) la seguente codifica/type nell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
A1 – Errore di funzionamento
A2 – Errore di comportamento (eventuale
Pre-test delle componenti:
verifica ciascuna componente della pagina web prima dell’assemblaggio e dell’integrazione · TEST D’INTEGRAZIONE
effettuata dal responsabile tecnico
In tal caso il test rileverà la seguente tipologia dei BUG rilevati dal TEST FUNZIONALE avranno (prevalentemente) la seguente codifica/type nell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
A1 – Errore di funzionamento
A2 – Errore di comportamento (eventuale)
B1 – Funzionalità/Adeguatezza
B2 – Funzionalità/Interoperabilità
B3 – Funzionalità/Aderenza standard
E – Affidabilità
F2 – Qualità d’uso/Sicurezza
· TEST DI RILASCIO (Deployment):
test di carico:
si simulano un gran numero di accessi simultanei per verificare i limiti di carico di lavoro che il server riesce a sostenere
controllo finale:
svolto a posteriori, dopo aver effettuato il debugging. Garantisce che tutti i bug siano stati coretti e che il codice funzioni dopo le correzioni.
test di sicurezza:
verifica che hacker e accessi illeciti ai dati raccolti siano esclusi

B. ALFA TEST
Rientrano in questi test:
testing informale:
senza un piano formalizzato, è quello più frequentemente utilizzato
alpha testing:
è il controllo iniziale di un sito dopo il completamento di produzione e funzionalità (e dei test funzionali) che avviene prima della pubblicazione
Test che serve a riscontrare quanto segue:
L’adeguatezza, la comprensibilità, la navigazione, ecc. ed altri requisiti di usabilità
Tale test viene effettuato successivamente al TEST FUNZIONALI.
Tale test viene effettuato da personale diverso dagli sviluppatori, personale interno, che tende a simulare il comportamento degli utenti finali
Tipologia dei BUG rilevati dall’ALFA TEST avranno (prevalentemente) la seguente codifica/typenell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
C – Usabilità/Comprensibilità
D1 – Usabilità/Apprendibilità
D2 – Usabilità/Operabilità
D3 – Usabilità /Attrattività
D4 – Usabilità /Conformità
F1 – Qualità d’uso/Produttività
F2 – Qualità d’uso/Sicurezza
F4 – Efficienza
G – Nuova Feature
H – Personalizzazione
I – Altro

C. BETA TEST
Rientrano in questi test tutto ciò che riguarda la User Experience:
test di utilizzo:
è un’analisi delle effettive interazioni tra utente e software/sito. Sono stabiliti dei task da raggiungere e l’utente è osservato direttamente
· user acceptance:
è una batteria di test che dipendono dalle caratteristiche del progetto e hanno l’obiettivo di verificare la rispondenza ai requisiti degli utenti
· check up contenuti:
controllo dell’esatta collocazione e correttezza dei contenuti pubblicati (testi, labelling e immagini)
· beta testing:
controllo finale di tutto il software/sito appena prima del lancio (quando il software/sito è stato già caricato sul server)
· Test che servono a rilevare i requisiti di accessibilità e di usabilità.
Tale test viene effettuato dai KeyUser (rappresentanti di categorie di utenti finali)
· Tipologia dei BUG rilevati BETA TEST avranno (prevalentemente) la seguente codifica/type nell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
C – Usabilità/Comprensibilità
D1 – Usabilità/Apprendibilità
D2 – Usabilità/Operabilità
D3 – Usabilità /Attrattività
D4 – Usabilità /Conformità
F1 – Qualità d’uso/Produttività
F3 – Qualità d’uso/Soddisfazione
F4 – Efficienza

Leonardo Milan

Contatore utenti connessi

]] >