Vogliamo un CRM su misura: come funziona il processo di sviluppo e cosa dobbiamo preparare noi?

L'idea di un CRM su misura suona bene, ma farsi sviluppare un software da zero invece di personalizzarne uno già pronto comporta rischi enormi. Quando il team di sviluppo se ne andrà, a chi rimarrà la manutenzione del codice? La maggior parte delle aziende finisce per abbandonare questi gestionali custom dopo due anni, proprio perché non riesce a gestire le patch di sicurezza e le esigenze del nuovo personale.

Anche noi, con la nostra azienda di commercio all'ingrosso di 14 persone nel Regno Unito, abbiamo preso una strada simile. Il budget inizialmente concordato di 35.000 GBP è salito a 52.000 GBP a causa di continue richieste intermedie e ritardi sull'integrazione contabile, e i 5 mesi previsti sono diventati 11. Se non congelate lo scope fin dall'inizio, i costi si moltiplicano a vista d'occhio.

Quando trattate con l'agenzia pretendete fin da subito rilasci intermedi settimanali. Non accettate assolutamente che vi consegnino tutto il codice in blocco dopo cinque mesi. Se non cliccate e testate voi stessi le schermate funzionanti ogni due settimane, vi accorgerete solo a cose fatte che i documenti approvati a tavolino fanno disperare i dipendenti sul campo.

PS: è stato chiesto qui sotto, ho scritto la risposta nel secondo messaggio.

Inserite tassativamente nel capitolato tecnico sia la struttura del database che la documentazione delle REST API. Deve essere formalizzato come verranno organizzate le tabelle relazionali e quali standard adottare per dialogare in futuro con servizi di logistica o contabilità. Inoltre, per tutelare l'indipendenza del codice, imponete l'uso di un framework moderno e ampiamente diffuso.

Al momento, quanti campi e formule diverse avete esattamente nei vostri fogli di calcolo? Inoltre, la vostra forza vendita dovrà inserire preventivi da smartphone/tablet fuori sede o basta un pannello solo desktop? Già solo queste due variabili possono raddoppiare la complessità del database e, di conseguenza, le giornate uomo di sviluppo.

Fate inserire esplicitamente nel contratto di sviluppo la procedura di Change Management. È fondamentale stabilire che non venga programmata alcuna funzionalità richiesta solo a voce e che il costo uomo/giorno per le modifiche extra sia fissato a monte. In caso contrario, ogni piccola richiesta apparentemente banale farà slittare la consegna e sforare il budget.

ci siamo passati anche noi e l'errore più grande è stato non coinvolgere il personale. boh noi manager abbiamo disegnato un flusso fantastico sulla carta ma poi chi faceva i preventivi trovava l'interfaccia troppo complicata ed è tornato a usare i vecchi file excel. vi consiglio caldamente di non approvare nulla senza prima esaminare i mockup insieme a chi li userà.

il budget è decisamente ragionevole, ma il mio consiglio principale è di non voler fare tutto subito. comunque all'inizio rilasciate una versione base e snella limitata ad anagrafica clienti, calcolo sconti e creazione preventivi. fate iniziare a usare il sistema al team, individuate i punti deboli e solo in una seconda fase fate integrare i moduli di magazzino e logistica.

Sono emerse tre opinioni diverse, si completano a vicenda. L'errore commesso da processo di sviluppo CRM è generalmente reversibile ma costoso.

Se cerchi di cambiare tutto insieme, niente si stabilizza. Spero che le sia utile.

Racconto la mia esperienza. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Sono d'accordo in parte, in parte no. Se il contratto non specifica la proprietà del codice, al momento di andarsene non hai potere contrattuale.

Se non lo rendete scritto fin dall'inizio poi nascono discussioni. insomma se avete domande scrivete rispondo per quanto possibile.

in teoria è giusto, in pratica non funziona così e gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

naturalmente camia se la vostra situazione è diversa.

La mia domanda sarà un po' da principiante, scusate. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Salvato.

Argomento molto attuale.

sono d'accordo poi il vero problema non è il numero ma su cosa si basa quel numero.

se scrivete qui il risultato sarà utile anche ad altri.

Riassumo l'argomento, perché sono state date diverse risposte. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Confermato dall'esperienza.

Assolutamente. Se devo aggiungere qualcosa: L'errore commesso da processo di sviluppo CRM è generalmente reversibile ma costoso.

Questa è la mia opinione, non la scrivo come verità assoluta.