On veut un CRM sur mesure — comment se déroule le développement et que doit-on préparer de notre côté ?

Le sur-mesure donne envie sur le papier, mais repartir de zéro au lieu de personnaliser une solution existante comporte d'énormes risques. Si l'équipe de dev s'en va, qui assurera la maintenance du code ? Beaucoup de boîtes finissent par abandonner leur outil maison au bout de deux ans, faute de pouvoir suivre les patchs de sécurité et les besoins des nouvelles recrues.

On est passés par là avec notre boîte de négoce de 14 personnes au Royaume-Uni. Le budget initial signé à 35.000 GBP est monté à 52.000 GBP à cause de demandes en cours de route et de galères d'intégration comptable, et les 5 mois annoncés sont devenus 11 mois. Si vous ne gelez pas le scope dès le départ, la facture explose à toute vitesse.

Lors des négos avec l'agence, exigez impérativement des livraisons intermédiaires régulières (toutes les semaines ou deux semaines). N'acceptez jamais l'effet tunnel où on vous balance tout le code d'un bloc au bout de cinq mois. Si vous ne testez pas vous-mêmes des écrans fonctionnels à chaque sprint, vous réaliserez trop tard que ce qui paraissait parfait sur un document Word fait péter un câble à vos équipes sur le terrain.

PS : c'est demandé plus bas, j'ai répondu dans le deuxième message.

Intégrez d'office l'architecture de la base de données et la documentation des API REST dans le cahier des charges technique. Tout doit être formalisé : organisation des tables relationnelles et standards d'échange pour les futures connexions compta ou logistique. Exigez aussi un framework moderne et éprouvé pour ne pas vous retrouver pieds et poings liés avec un seul prestataire.

Vous avez combien de colonnes et de formules complexes qui tournent actuellement dans vos tableurs ? Et vos commerciaux doivent-ils pouvoir saisir des devis sur mobile en clientèle ou une interface desktop classique leur suffit ? Rien que ces deux réponses peuvent doubler la complexité du schéma de données et, par ricochet le nombre de jours-hommes de dev.

Veillez à inclure une clause stricte sur la gestion des demandes de changement (change requests) dans le contrat. Aucun développement ne doit être lancé sur simple accord verbal, et le coût au jour-homme des extras doit être fixé dès le départ. Dans le cas contraire, la moindre petite demande rallongera les délais et fera déraper votre budget.

on a fait la meme betise : ne pas impliquer les equipes des le debut... nous les managers on a pondu un super workflow sur le papier mais les gars qui font les devis ont trouve l'interface trop lourde et sont direct repartis sur leurs vieux excels. franchement validez rien sans leur avoir montre les maquettes d'ecrans.

votre enveloppe est tout à fait choérente mais le meilleur conseil que je puisse vous donner est de ne pas vouloir tout faire d'un coup. sortez d'abord un MVP axé uniquement sur les fiches clients le calcul des remises et la génération de devis et laissez l'équipe se l'approprier, notez les points de friction, puis ajoutez les modules stock et logistique dans une phase deux.

Trois avis différents sont sortis, ils se complètent tous. L'erreur commise du côté de processus de developpement crm est généralement réversible, mais coûteuse.

Quand on essaie de tout changer en même temps, rien ne prend. J'espère que cela vous sera utile.

Je partage mon expérience. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Je suis d'accord en partie, pas en partie. Si la propriété du code n'est pas mentionnée dans le contrat vous perdez tout pouvoir de négociation au départ.

Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard... Si vous avez des questions écrivez-moi, je répondrai au mieux.

c'est vrai en théorie, mais ça ne marche pas ainsi en pratique... la plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

bien sûr, cela change si votre situation est différente.

Ma question va paraître un peu novice, désolé d'avance. Si vous ne formalisez pas cela par écrit dès le départ des disputes éclateront plus tard.

Enregistré.

Sujet très actuel.

je suis d'accord puis du coup le vrai problème n'est pas le chiffre mais la base sur laquelle il est calculé.

si vous écrivez le résultat ici cela aidera aussi d'autres personnes.

Je vais résumer le sujet car plusieurs réponses différentes ont été données. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant j'ai appris cela trop tard.

C'est confirmé par l'expérience.

Absolument... Si j'ajoute quelque chose : L'erreur commise du côté de processus de developpement crm est généralement réversible mais coûteuse.

C'est mon avis, je ne l'écris pas comme une vérité absolue.