Conseils

Les tâches qu’une PME ne devrait plus gérer à la main

Si votre équipe recopie encore des informations d’un outil à un autre, ce n’est probablement pas un problème de productivité.

Chez l’un de nos clients, un salarié passait deux heures par jour à recopier des données entre plusieurs fichiers Excel. Chacun avait créé son propre tableau pour répondre à ses besoins. Pour que tout le monde dispose des bonnes informations, il fallait ensuite les reporter à la main d’un fichier à l’autre.

Deux heures peuvent sembler supportables quand elles sont réparties dans une journée. Mais sur un mois de 22 jours travaillés, cela représente 44 heures. Plus d’une semaine consacrée à faire circuler des informations déjà présentes quelque part dans l’entreprise, au détriment des autres missions du salarié.

Dans cette situation, demander à la personne de travailler plus vite ne résout pas grand-chose. Elle fait avec l’organisation à sa disposition. Pour lui rendre du temps, il faut comprendre pourquoi toutes ces manipulations sont devenues nécessaires et ce qui permettrait de les éviter.

Ce genre d’organisation se construit progressivement. Un premier tableau répond à un besoin précis, puis un collègue en crée un autre avec les colonnes qui l’intéressent. Un service ajoute son propre suivi et certaines informations commencent à se retrouver à plusieurs endroits. Chaque fichier peut être utile, mais personne n’a forcément prévu comment ils allaient rester cohérents entre eux.

Une personne finit alors par assurer la liaison : elle récupère les données, les remet dans le bon format, les copie et vérifie que les tableaux correspondent. Ce travail devient une habitude. Il est même parfois indispensable au fonctionnement quotidien, au point qu’on ne se demande plus pourquoi il existe.

Le temps mobilisé ne se limite d’ailleurs pas toujours au copier-coller. Il faut aussi retrouver la dernière version, demander si une information a changé et comprendre pourquoi deux fichiers affichent des valeurs différentes. Une mise à jour oubliée ou une ligne copiée au mauvais endroit peut ensuite entraîner d’autres vérifications. Le risque est de passer de plus en plus de temps à contrôler des données qui devraient déjà être fiables.

Chez Dev-Booster, nous commençons par regarder le travail tel qu’il se fait réellement. Nous demandons à la personne de nous montrer les fichiers qu’elle ouvre, les informations qu’elle récupère et les transformations qu’elle effectue. Une ligne copiée peut cacher un contrôle métier : vérifier qu’une commande est complète, qu’un montant est cohérent ou qu’une validation a bien été donnée. Il faut comprendre ce contrôle avant de modifier le fonctionnement.

Nous cherchons ensuite à répondre à quelques questions simples. Où l’information est-elle créée ? Qui peut la modifier ? Qui en a besoin et à quel moment ? Faut-il qu’elle soit disponible immédiatement, chaque matin ou seulement une fois par semaine ? Que fait l’équipe lorsqu’une donnée manque ou que deux versions se contredisent ? Les réponses déterminent la solution à construire.

Il faut notamment choisir quelle source fait référence pour chaque information. Prenons l’exemple d’une adresse client présente dans un logiciel commercial et dans deux fichiers de suivi. Si tout le monde peut la modifier séparément, connecter les outils ne suffira pas : il faut décider où l’adresse est tenue à jour et comment les autres supports récupèrent cette version. Le même raisonnement s’applique aux commandes, aux statuts de traitement ou aux coordonnées des interlocuteurs.

Cela suppose aussi de reconnaître une même donnée d’un outil à l’autre. Un numéro de client ou de commande permet, par exemple, de rattacher une mise à jour au bon dossier. Une simple ressemblance entre deux noms peut prêter à confusion. Ce sont des détails peu visibles dans une démonstration, mais essentiels pour éviter de créer des doublons ou de modifier la mauvaise fiche.

La réponse peut prendre plusieurs formes. Un fichier partagé et mieux organisé peut suffire lorsque chacun travaille aujourd’hui sur sa propre copie. Un import automatique peut alimenter un tableau qui reste utile aux équipes. Lorsque plusieurs logiciels sont concernés, une connexion peut transmettre les informations d’un outil à l’autre, à une fréquence adaptée au besoin. Une petite interface commune devient intéressante si les utilisateurs ont besoin de droits différents, de validations ou d’un historique que les fichiers actuels ne permettent plus de suivre correctement.

Excel peut donc conserver sa place. Un tableau qui sert à analyser les données ou à préparer une décision reste utile. Le travail consiste à déterminer comment il peut recevoir des informations fiables sans imposer une ressaisie quotidienne. Le choix d’un développement plus important vient ensuite, si les besoins le justifient.

Dans un fonctionnement automatisé, on peut par exemple récupérer les données à un horaire défini, vérifier que les champs indispensables sont présents, puis mettre à jour les éléments concernés. La personne consulte le résultat et intervient sur les anomalies signalées. Si une commande arrive sans référence client, elle doit être identifiée comme un cas à traiter. L’automatisation doit rendre les exceptions visibles et permettre de comprendre ce qui s’est passé.

Il faut aussi prévoir les incidents ordinaires : un fichier qui arrive en retard, une colonne renommée ou un logiciel temporairement indisponible. Le traitement doit pouvoir signaler l’échec et être relancé proprement. Rejouer un import ne devrait pas créer une deuxième fois les mêmes commandes. Une mise à jour incomplète ne devrait pas effacer une information correcte. Ces points font partie du projet dès le départ.

Les relances illustrent bien le même sujet. Et nous sommes directement concernés : nous venons justement de refondre notre propre système de relance chez Dev-Booster. Comme quoi, les cordonniers sont souvent les plus mal chaussés. Nos habitudes internes méritent elles aussi d’être revues lorsque nous consacrons trop de temps à des manipulations répétitives.

Prenons le cas des relances de factures pour comprendre ce qu’un tel système doit gérer. Avant de préparer un message, il faut savoir si la facture est toujours en attente de règlement, si un paiement a été enregistré, si un échange est déjà en cours et à qui la relance doit être adressée. Si ces informations sont réparties entre plusieurs outils, la préparation peut devenir une succession de recherches et de vérifications.

Automatiser ce processus suppose de définir les règles : les échéances à surveiller, les délais entre deux relances, les destinataires et les situations qui nécessitent une intervention. Une facture contestée ou une promesse de paiement déjà convenue doit pouvoir être traitée à part. Selon le fonctionnement de l’entreprise, le système peut préparer les messages pour validation ou les envoyer dans les cas prévus. Il doit également permettre de retrouver les actions réalisées et de suspendre une relance lorsqu’un échange humain prend le relais.

L’intelligence artificielle peut intervenir sur certaines tâches, par exemple pour aider à classer des demandes ou préparer un brouillon à relire. Mais un import de données, une mise à jour de statut ou une alerte d’échéance peut reposer sur des règles définies à l’avance. Avant de choisir une technologie, nous regardons ce qui est répétitif, ce qui est prévisible et ce qui demande réellement du jugement.

Pour avancer, nous privilégions un premier périmètre précis : un échange entre deux outils, un tableau à alimenter ou un type de relance. Cela permet de vérifier les correspondances entre les données, de tester les cas particuliers et de faire essayer le fonctionnement à la personne qui réalise aujourd’hui les manipulations. Pendant cette phase, les résultats peuvent être comparés à ceux de la méthode habituelle avant la bascule.

Le bénéfice se mesure ensuite sur le travail quotidien. Combien de temps reste-t-il à consacrer aux contrôles ? Combien d’anomalies nécessitent une intervention ? Les informations sont-elles disponibles au bon moment ? La personne peut-elle reprendre le traitement si quelque chose se passe mal ? Dans notre exemple, les deux heures quotidiennes constituent un point de départ pour cette mesure. Le temps effectivement récupéré dépendra de ce qui peut être supprimé et des vérifications qui resteront nécessaires.

Ce temps retrouvé doit enfin avoir une utilité pour l’équipe. Il peut être consacré au suivi des clients, au traitement des demandes ou aux autres missions qui passaient après la mise à jour des fichiers. C’est à ce niveau que l’amélioration prend son sens : dans ce que les salariés peuvent accomplir au cours de leur journée.

Pour repérer un premier sujet dans votre entreprise, regardez ce qui se passe lorsqu’une information change. Combien de fichiers faut-il ouvrir ? Combien de personnes doivent la recopier ? Qui vérifie que tout le monde dispose de la bonne version ? Si la même manipulation revient chaque jour, prenez le temps de la mesurer sur une semaine. Vous aurez déjà une base concrète pour décider où intervenir.

Vous avez un processus qui ressemble à celui-ci ? Présentez-nous les fichiers ou les outils concernés et les manipulations que votre équipe doit effectuer. Chez Dev-Booster, nous pourrons examiner avec vous ce qui peut être simplifié, connecté ou automatisé, et définir une première étape adaptée à votre organisation.

 

Un projet autour de « Développement d'applications Windows » ?

Des applications Windows performantes et durables, développées en C# / .NET. Nous maîtrisons également WinDev pour reprendre et faire évoluer vos applications existantes.

</Découvrir cette prestation> Nous écrire