Il mito del connettore CDP

In una recente demo CDP a cui ho partecipato, un cliente nervoso ha chiesto al fornitore se disponeva di un connettore per Salesforce Sales Cloud. Il venditore ha risposto affermativamente e il cliente ha tirato un sospiro di sollievo. Ma la verità è che la maggior parte dei fornitori di CDP (Customer Data Plaftorm) dispone di connettori pacchettizzati deludenti. Continua a leggere per sapere perché è così e cosa puoi fare al riguardo.

Un po' di storia: la gara dei 'portlet' aziendali

Questo incontro mi ha ricordato l'era del “portale d'impresa”. Per favore concedimi mentre guardo indietro alla fine degli anni 2000 e all'inizio degli anni 2010, un periodo che la maggior parte dei clienti e dei fornitori vorrebbe dimenticare, ma che porta ancora lezioni oggi.

I portali aziendali avrebbero dovuto fornire un'interfaccia singola e conveniente in una gamma potenzialmente ampia di applicazioni aziendali, visualizzate come blocchi separati su uno schermo in un motivo dashboard. La tecnologia alla base di quei singoli blocchi aveva molti nomi, ma per ora chiamiamoli "portlet".

È diventato subito chiaro che i programmi del portale erano fondamentalmente progetti di integrazione molto complessi, quindi le aziende hanno naturalmente cercato di sfruttare il codice del connettore prefabbricato. I fornitori hanno risposto con cataloghi di portlet e ne è seguita una corsa agli armamenti. "Abbiamo 250 portlet", si vantava un fornitore.

Questi portlet variano notevolmente in termini di provenienza, supporto, usabilità, prestazioni, sicurezza e (soprattutto) basi tecniche. Un "portlet" era in genere un'istanza di riferimento di un codice Java o C# scritto da qualcuno per un'implementazione di un singolo client. Il più delle volte, il codice doveva essere revisionato, a volte da zero.

I fornitori hanno ribattuto, non ingiustamente, che i problemi spesso derivavano dal modo in cui i sistemi remoti erano configurati piuttosto che dalla piattaforma del portale stesso. Forse è così, ma alla fine le aziende si sono stancate dei portlet. Tra altri cambiamenti tecnologici e aziendali nel mondo digitale, la tecnologia della piattaforma del portale è gradualmente passata di moda.

La nuova gara di connettori CDP

Avanti veloce fino ad oggi e il mondo sta arrivando a comprendere i CDP come ambienti di integrazione (tra le altre cose). Ogni team di selezione CDP con cui lavoriamo si impegna a trovare fornitori con connettori predefiniti da confrontare con le loro piattaforme storiche. Tuttavia, quasi tutte le implementazioni CDP trovano costosi sviluppatori che modificano o riscrivono in modo significativo quei connettori.

I fornitori di CDP stanno apparentemente soccombendo alle pressioni subite dai loro fratelli del portale. Se i clienti apprezzano un catalogo diversificato di connettori, in qualità di fornitore di CDP è necessario visualizzarne molti, pronti o meno. Nelle demo CDP, i connettori appaiono sullo schermo come blocchi ordinati (con il logo della piattaforma connessa che appare ben visibile) che puoi trascinare in giro, quasi come portlet!

Beh, non così in fretta. Come i portlet, i connettori del fornitore CDP possono derivare semplicemente dall'output di una singola implementazione. Ancora più importante, in alcuni casi, un singolo connettore non può affrontare la complessità della piattaforma martech dall'altra parte.

Considera Salesforce Sales Cloud, menzionato sopra. La piattaforma soffre di un modello a oggetti problematico che la maggior parte dei licenziatari contorce o estende pesantemente. Può essere come connettersi a un polpo molto arrabbiato. E Salesforce non è affatto solo qui. In tali situazioni, il connettore di un fornitore CDP può fornire solo l'impalcatura di base e lasciare il resto allo sviluppatore.

Il nemico siamo noi?

I portali si sono estinti per un altro motivo. Se gli occhi sono finestre sull'anima, i portali erano finestre su intestini aziendali. Un portale era utile solo quanto le applicazioni sottostanti. Spesso quelle applicazioni erano disordinate, prive di contenuti comuni e modelli di metadati, utilizzavano diversi regimi di controllo degli accessi, esibivano modelli UX diversi e talvolta esponevano dati di bassa qualità.

Nella mia azienda assistiamo a un fenomeno simile con i CDP. A seconda di come definisci uno sforzo CDP (e qui stanno emergendo diversi modelli), il CDP potrebbe esporre l'immaturità del tuo più ampio regime di gestione dei dati dei clienti: una ragione in più per abbinare qualsiasi potenziale CDP alla tua architettura di dati più ampia.

Scava più a fondo: come identificare e organizzare i dati con un nuovo CDP

Fai attenzione ai fornitori di CDP che affermano di avere diversi cataloghi di connettori

Come sempre, uomo avvisato mezzo salvato. Innanzitutto, riconsiderare la sovraponderazione di un fornitore che afferma di avere cataloghi di connettori che corrispondono bene al tuo stack. Tra le altre ragioni, il semplice spostamento dei file CSV può risolvere molti casi d'uso (non in tempo reale). Quando hai bisogno di pacchetti di connettori, l'esperienza di integrazione specifica diventa utile ma non costituisce intrinsecamente una protezione contro uno sviluppo sostanziale nel tuo futuro. La chiave è scoprire quanto sviluppo.

Si spera che tu stia seguendo un agile processo di selezione CDP che si concluda con un bake-off competitivo e una prova di concetto (PoC) più tecnica con uno o due finalisti. Un PoC è un ottimo ambiente per testare alcuni connettori essenziali. Verrai quindi a capire il livello di sforzo per la revisione ove necessario, e potrebbe essere spesso.

Come i loro predecessori di fornitori di portali, i fornitori di CDP prometteranno pacchetti di "avvio rapido" per accelerare un'implementazione iniziale. Non crederci. Ancora una volta, alcuni ritardi potrebbero derivare dal tempo necessario per mettere in ordine la propria casa dati, ma posso anche garantirvi che qualcuno si occuperà dello sviluppo del connettore e questo lavoro viene misurato in trimestri, non in mesi. Budget le tue risorse di conseguenza.