Cambiato il mondo del cliente: come lo gestiamo?

Qualche tempo fa, ci è stato assegnato il compito di un progetto per entrare e sostituire il vecchio sistema mainframe di un cliente con una nuova soluzione ASP.NET intranet che utilizza SQL Server come back-end. Parte di questo era anche una reingegnerizzazione del business - essenzialmente, mentre cambiamo il sistema, dovevamo pensare a come possiamo fare meglio il business.

Quindi, il primo compito era quello di entrare e fare i modelli di dati logici e quindi fisici. Il cliente ha partecipato a queste discussioni e ha ottenuto l'approvazione completa. La fase successiva è stata quella di realizzare effettivamente la progettazione e la costruzione di ciascun modulo. Bene, per farla breve, la programmazione è stata fatta e ora stiamo testando in parallelo il sistema. Finora le cose sono andate meravigliose per la maggior parte dei moduli, tranne uno.

Abbiamo un sistema in cui - se tu volessi solo consentire agli utenti aziendali di vedere l'applicazione e i rapporti, tutto andrebbe bene. Funziona con il nuovo flusso di lavoro integrato e automatizza i processi precedentemente manuali e offre prestazioni eccezionali secondo le specifiche. I test paralleli hanno scoperto alcuni problemi con i dati legacy migrati. I costruttori del sistema legacy hanno difficoltà a comprendere il nuovo schema e il processo aziendale, quindi hanno difficoltà a capire come prendere i dati legacy e inserirli nel nuovo schema. Per questo motivo, stanno convocando riunioni degli utenti aziendali e delle parti interessate e dicendo loro che il nuovo sistema non fornisce dati che il vecchio sistema ha fatto (quando realmente lo fa) - questo fa sembrare il nuovo sistema cattivo.

Questo è frustrante, per non dire altro. Il nuovo sistema funziona alla grande e fornisce tutto ciò di cui hanno bisogno e che desiderano e, se non fosse per l'impossibilità del personale IT di riempire le nuove tabelle con i vecchi dati, gli utenti aziendali sarebbero contenti delle nuove caratteristiche e funzionalità.

Chiedo suggerimenti su come gestirlo. A causa di alcune mosse politiche, il nuovo "architetto" non ha idea di come funzioni il sistema e non può comprendere appieno le ramificazioni dei cambiamenti richiesti dallo staff IT. Lo staff IT desidera alcune modifiche fondamentali al sistema, che sono essenzialmente non necessarie e in realtà sono un cattivo design - ma SONO il cliente.

qualche idea?

Il tuo team deve fare la conversione dei dati per loro. È davvero dovrebbe avete fatto per loro in primo luogo.

Sono stato coinvolto in una serie di costose migrazioni della piattaforma e il fornitore ha sempre, sempre il proprio team di conversione dei dati che è responsabile della comprensione del sistema legacy, della scrittura di tutti gli script di migrazione, dell'esecuzione di tutti i test e in generale della verifica che tutto fa quello che dovrebbe.

Alcune aziende possono disporre di personale IT brillante che può farlo da soli. Altri possono affermare di essere in grado di farlo da soli, ma in realtà non possono. In quest'ultimo caso, devi essere abbastanza umile da rilassarti, ma anche essere pronto a intensificare se e quando il management ha deciso che il team interno non sta facendo un buon lavoro.

Questo è il tuo sistema e la tua implementazione. Tu e solo tu sei responsabile di assicurarti che abbia successo. Non aspettarti che il cliente sia in grado di fare tutto da solo. Solo se insistono assolutamente nel fare questa parte da soli, dovresti anche prendere in considerazione quell'opzione e, in tal caso, devi coprire i tuoi mozziconi - ci dovrebbe essere qualcosa nel contratto che dice che se scelgono di farlo da soli, allora sono responsabili per il suo risultato.

Possono pagarti per fare da baby-sitter alla loro squadra se vogliono, e possono pagarti per ricominciare da capo se vogliono, ma non sprecano cicli inutili senza un qualche tipo di accordo. Soprattutto se hai un contratto a tempo limitato o a costo fisso, questa situazione è la morte.

Il punto è, come dici tu, che sono il cliente, il che significa che non funzionano per te. In effetti, se sei un cinico come me, potresti sospettare che alcuni di loro lavorino attivamente contro di te per mantenere la loro sicurezza sul lavoro. Affidarsi al cliente per fare qualsiasi parte della propria implementazione è un errore.

Se devi assumere un paio di slave per l'immissione dei dati con salario minimo per eseguire manualmente la conversione dei dati , fallo. Qualsiasi cosa per rimettere il risultato tra le mani.

Sono quelli che pagano le bollette, quindi alla fine devi dare loro quello che stanno chiedendo anche se non sarebbe la soluzione migliore e un passo indietro.

Devi considerare tuttavia che forse le persone che erano solite usare il mainframe hanno ragione. Mia moglie lavorava per una banca in cui utilizzava un sistema mainframe per immettere varie transazioni finanziarie utilizzando centinaia di diversi tipi di codici. Era essenzialmente il suo mini-linguaggio. Quando la banca ha speso milioni di dollari per implementare un sistema basato sulla GUI che ha notevolmente ridotto la complessità e le fasi coinvolte, hanno scoperto in seguito che la produttività è precipitata e non è mai tornata indietro.

Il fatto era che mentre il sistema mainframe era inutilmente complicato e aveva un'alta curva di apprendimento, erano MOLTO più veloci con esso rispetto al sistema GUI perché diventavano esperti nell'immissione di centinaia di transazioni all'ora semplicemente digitando velocemente su una tastiera. Ha portato a un rifiuto di massa da parte della base di utenti e il progetto è stato scartato come un fallimento completo. Produttività restituita.

La morale è, non respingere completamente le preoccupazioni dei clienti. Prendi sul serio le loro considerazioni e chiediti se la soluzione che stai fornendo soddisfa le esigenze di TUTTI gli stakeholder.

quelli che il nuovo sistema non fornisce dati che il vecchio sistema ha fatto (quando realmente lo fa).

Dovresti prenderlo MOLTO seriamente ..

Poi:

1) Assicurati che stai lavorando con i ragazzi legacy per risolvere tutti i problemi.

2) Assicurati di comprendere appieno ciò che stanno dicendo è mancante e perché è necessario. Lavora con i ragazzi legacy per assicurarlo. Quindi RESTATE il problema e invitali a dire "Sì, questa è la nostra preoccupazione".

Se sei d'accordo con le preoccupazioni, allora:

3) Quindi proporre una soluzione, ottenere l'input \ validazione su \ della soluzione dei team legacy.

4) Procedere con misure correttive.

Se non sei completamente d'accordo con i ragazzi del Legacy e ritieni che le preoccupazioni non siano valide, allora:

3) Esprimere preoccupazione per il management utilizzando la stessa lingua che i Legacy Guy hanno dichiarato corretta. E chiedi alla direzione di decidere dove preoccuparti o meno.

"I ragazzi legacy hanno paura che XXX, non sono sicuro che sia un problema a causa di YYY. Hanno ragione a riguardo?"

Suggerisco un'e-mail che soffoca il panico, colpisca chiunque sia associato non solo alla sua gestione. Tienilo breve e al punto.
2 punti:

1) Siamo in grado di rispondere alle vostre preoccupazioni in una riunione / telefonata (proporre un orario)

2) Abbiamo completa fiducia nel sistema in quanto è privo di seccature e spese per ulteriori modifiche

Sembra che tu abbia un elenco delle loro preoccupazioni e puoi discuterle punto per punto durante la riunione. Devi solo fermare il panico, lasciarli raffreddare un po 'e poi colpirli con la verità. Offri persino di venire e di aiutare a mappare i vecchi dati con i nuovi. Se continuano a chiedere cambiamenti ... beh, sono i loro soldi.

Innanzitutto, desidero sottolineare che, sebbene la sezione IT possa essere la tua interfaccia, il vero cliente NON È la sezione IT, ma l'attività per cui la sezione IT funziona. Fare qualcosa per danneggiare il business e placare l'IT non sarebbe un buon servizio.

Siediti con l'IT, in modo informale. Compra loro le ciambelle. Assumi il ruolo di studente per il suo insegnante e chiedi "Cosa c'è di sbagliato nella progettazione del nostro software?" Ascolta sia quello che stanno dicendo sia quello che non stanno dicendo. Potrebbero avere un punto che è stato trascurato nelle specifiche originali o avere preoccupazioni basate su problemi passati. Inoltre, potrebbero reagire a causa della paura di qualcosa di nuovo. Ma il punto è che se conosci le loro obiezioni intimamente, sei in una posizione migliore per effettuare un risultato positivo e rispondere alle loro obiezioni.

Avevi detto che il problema riguardava la migrazione dei dati dal sistema legacy al nuovo sistema. Se la sezione IT sta riscontrando problemi durante la migrazione dei dati, prenderei in considerazione l'idea di costruirli come un piccolo strumento per farlo in modo rapido e pulito.

Consultare lo staff IT del cliente per supportare la migrazione dei vecchi dati nel nuovo sistema. Qualcuno della tua azienda che capisce il nuovo formato di dati dovrebbe fisicamente andare lì e aiutare i ragazzi IT a fare la migrazione.

In questo modo si spera che possano insegnare ai ragazzi IT il nuovo sistema, i dati vengono migrati correttamente e l'implementazione procede in modo più fluido.