Il modo migliore per avvicinarsi a un business partner per capire la necessità di servizi web B2B

Ho lavorato su questo problema esatto con diversi clienti B2B e ciò che viene sempre in mente è avere una conversazione con il team sul loro fine in cui discuti chiaramente i pro e i contro della tua proposta e lavori per mitigare ogni preoccupazione sollevano.

Prima di farlo devi capire da dove viene il tuo cliente. È estremamente difficile far sì che le aziende facciano cambiamenti significativi (o anche minori) nei loro sistemi, perché quello che hanno, non importa quanto schifoso, sta lavorando per loro e sanno come aggirare tutte le zone difficili e bug. È abbastanza sorprendente come le persone si adatteranno e diventeranno abbastanza abili con software scadenti. È facile dire che l'aggiornamento a un nuovo sistema li trasporterà in una terra mistica di efficienza, unicorni e arcobaleni, ma il fatto è che l'aggiornamento a un nuovo sistema comporta rischi significativi in termini di nuovi bug e potenziali tempi di inattività. Tutte queste cose equivalgono a perdita di denaro per un business.

Quindi l'argomento principale che devi fare è che la tua configurazione proposta renderà il sistema più efficiente con meno errori. Questo è qualcosa che la maggior parte dei team IT otterrà poiché vogliono fare meno lavoro e rendere i loro sistemi più efficienti. Devi presentarli con una soluzione chiara e ben pensata e poi lavorare con loro per rispondere alle loro preoccupazioni.

Ecco due soluzioni generali che ho usato in passato:

Servizio web push

Un servizio web push è un servizio web impostato dall'utente e il cliente invia i dati (non è sicuro se questo è il nome ufficiale di questo, ma è quello che ho sempre chiamato). Ho scoperto che la maggior parte dei clienti preferisce questa opzione in quanto li colloca saldamente al posto di guida in termini di dati che stanno uscendo dal loro sistema.

Servizio Web pull

Questo è l'opposto di un servizio push e di ciò che hai menzionato nella tua domanda. In questo scenario, il client imposta un servizio Web che si chiama per ottenere dati dal proprio sistema. In genere, ai clienti non piace questo per le variazioni sui motivi che hai indicato nella tua domanda. In effetti, ho configurato un sistema del genere solo una volta e poi il server che ha effettuato la chiamata per prima cosa doveva connettersi alla VPN del client (spoiler: era un completo rompicoglioni).

Ci sono altri dettagli che devi considerare. Ad esempio, impostando il tuo servizio push in modo che non venga sovraccaricato da un cliente che spinge troppi dati troppo spesso.

Alla fine si tratta sempre di avere una buona e stretta collaborazione con il team IT del cliente. Se stabilisci questa relazione sarai bravo.

Molte organizzazioni sono riluttanti a chiedere a una fonte esterna di estrarre dati da loro. Forse un compromesso potrebbe essere quello di configurare un endpoint sul tuo terminale che consenta loro di inviare periodicamente dati. In questo modo sanno esattamente quali dati stai elaborando e controllano la frequenza degli aggiornamenti dei dati.

L'istruzione sulla tua definizione di "servizio web" è spesso il modo migliore per portarli dalla tua parte. Un gran numero di addetti IT nel mondo aziendale sembrano un "servizio web", un processo che esegue SSH / FTP in un server e scarica i dati. Non si rendono conto che possono configurare un endpoint REST / SOAP / XMLRPC (con autenticazione strong [ish]) e esportare solo i dati che hanno scelto di condividere.

Direi di creare un semplice proof-of-concept, presentare la tua implementazione e dare loro un codice di esempio con le istruzioni per l'installazione. Lascia che giochino con l'idea, stabilisci che è sicuro e vedi dove vanno da lì.

Infine, offri loro l'opportunità di porre domande, in primo luogo cosa ne pensa di tutto questo riguardo a questa idea. Idealmente, sii di persona o in videoconferenza in modo da poterti vedere faccia a faccia e dare ampia opportunità di brainstorming e di pensare ad alta voce.

Devi ricordare che la tua idea di nuovo e migliore potrebbe non adattarsi ai loro obiettivi. Ovviamente, dovrai indicare chiaramente i vantaggi del passaggio alla tua architettura proposta. Tuttavia, devi anche delineare gli svantaggi.

Solo perché il cliente rifiuta la tua idea, ciò non significa che agiscano in modo irragionevole. Entra e fai molte domande mirate e ottieni risposte molto specifiche su quali siano le loro preoccupazioni riguardo al cambiamento dei loro sistemi. Se ritieni che una risposta sia troppo vaga (ad es. "Il cambiamento è sbagliato"), quindi approfondisci per un motivo.

L'obiettivo finale è collaborare con loro per determinare la soluzione migliore per il problema in questione. Potresti scoprire che il loro ragionamento è completamente valido.