Guide
Introduire un logiciel sur mesure dans l'équipe, sans résistance
La partie technique d'un logiciel sur mesure est rarement le problème. Ce qui fait vraiment échouer les introductions tient aux personnes qui doivent l'utiliser — et cela peut être traité en amont.
La résistance à un logiciel sur mesure ne vise presque jamais la technique, mais la crainte d'un surcroît de travail ou d'être remplacé. Qui effectue le processus concerné au quotidien devrait être consulté avant la réalisation, non informé après — et rien ne devrait être introduit qui exige une saisie supplémentaire.
01 — Équipe
Comment l'équipe adhère
- Impliquer tôt, non informer tôt. Qui effectue le processus quotidiennement sait où se situent les exceptions. Cette information n'existe qu'avant, non après la mise en production.
- Prendre la résistance au sérieux. Elle ne vise presque jamais la technique, mais un surcroît de travail ou l'inquiétude d'être remplacé. Les deux méritent une réponse ouverte.
- Ne rien introduire qui génère un surcroît de travail. Les systèmes qui exigent une saisie supplémentaire sont contournés — à juste titre.
- Désigner une personne comme premier point de contact. Non comme responsabilité, mais pour que les questions ne se perdent pas.
- Rendre le succès visible. Si après quatre semaines personne ne sait si cela a apporté quelque chose, c'est le souvenir de la transition qui s'impose, non l'utilité.
02 — Participation
Ce dont nous avons besoin de votre part
- Une personne de contact qui a le pouvoir de décision — pas seulement de transmettre.
- Accès aux systèmes concernés, en temps utile et pas le jour de la mise en ligne.
- Exemples concrets du quotidien — plus ils sont bruts, plus ils sont utiles pour le test.
- Deux à quatre heures pour la coordination, réparties sur la durée du projet.
- Une réponse à la question de ce que signifie le succès. Sans cela, impossible d'évaluer quoi que ce soit par la suite.
03 — Mesure
À quoi vous mesurez le succès
- Fixer le chiffre unique au préalable. Sans valeur de départ, rien ne peut être prouvé a posteriori. Compter pendant deux semaines suffit pour un ordre de grandeur fiable.
- Temps de traitement par opération. La mesure la plus directe : combien de temps dure le processus concerné aujourd'hui, combien de temps après.
- Part des cas qui passent sans intervention. Ce taux augmente typiquement nettement durant les premières semaines, lorsqu'on affine — c'est le meilleur indicateur précoce.
- Temps de réaction vers l'extérieur. À quelle vitesse quelqu'un qui fait une demande obtient-il une première réponse contraignante.
- Ce que vous ne devriez pas mesurer : la satisfaction dans l'équipe durant les deux premières semaines. Tout changement se ressent au début comme plus difficile qu'il ne l'est.
04 — Questions
Questions fréquentes
Quand un logiciel propre se justifie-t-il face à un logiciel standard ?
Lorsque votre processus est un véritable avantage concurrentiel, lorsque le logiciel standard ne correspond qu'à soixante-dix pour cent et que le reste finit en travail manuel, ou lorsque les coûts de licence par utilisateur dépassent le développement sur quelques années. S'il s'agit seulement de confort, le logiciel standard est meilleur marché.
Que se passe-t-il si nous ne travaillons plus ensemble ?
Vous avez le code, la documentation et les accès. Nous misons délibérément sur des technologies répandues, afin qu'un changement soit possible sans que quelqu'un doive tout reconstruire.
Combien d'utilisateurs un tel système supporte-t-il ?
Cela dépend de l'architecture que nous planifions selon votre croissance attendue — de quelques utilisateurs dans l'entreprise propre jusqu'à plusieurs centaines sur plusieurs sites.
Cela fonctionne-t-il sur nos propres serveurs ou dans le cloud ?
Les deux sont possibles. Pour la plupart des entreprises, une solution cloud nécessite moins de maintenance ; là où les données ne doivent pas quitter les locaux, nous l'installons sur l'infrastructure propre.
Pouvons-nous commencer par un tableur ?
Souvent oui, et c'est un bon test. Si le tableur reflète le processus et échoue uniquement sur le multi-utilisateur, les droits ou le volume de données, l'exigence est claire et le projet chiffrable.
Que se passe-t-il si nous découvrons de nouvelles exigences pendant le développement ?
C'est normal et prévu, car le travail se fait par petites étapes. Une nouvelle exigence est intégrée à l'étape suivante, au lieu de bloquer tout le projet.
À qui appartient le code source ?
À vous, intégralement, dès le paiement. C'est dans le contrat. Vous pouvez aller avec vers n'importe quel autre développeur — c'est le principe.
05 — Suite
Pages correspondantes
- Logiciel sur mesure — Vue d'ensemble
- Logiciel sur mesure — Protection des données
- Logiciel sur mesure — Subvention
- Logiciel sur mesure — Rentabilité
- Logiciel sur mesure — Faire soi-même
- Logiciel sur mesure — Liste de contrôle
- Logiciel sur mesure — Processus
- Logiciel sur mesure — Erreurs typiques
- Automatisation de processus
- Connexion CRM
- Interfaces API
- Tous les guides
Logiciel sur mesure par région
Prochaine étape
Parlons brièvement de savoir si cela vaut le coup pour vous.
Une conversation de vingt minutes suffit généralement pour clarifier si un projet a du sens. Sinon, nous le disons — c'est moins cher pour les deux parties qu'une offre dont personne n'a besoin.