Quand votre entreprise dépasse les limites des tableurs : un logiciel sur mesure est-il rentable ?

Un tableur est un bon outil. C'est un mauvais système d'exploitation. Le problème commence sans bruit : un classeur devient l'endroit où l'on suit les dossiers, puis un second classeur est envoyé chaque vendredi pour que la comptabilité ait « les mêmes chiffres », puis une troisième personne garde une copie privée parce qu'elle ne fait pas confiance au fichier partagé. Rien ne plante. La semaine devient simplement plus courte.

Le logiciel sur mesure est une réponse, et ce n'est pas la première à essayer. La décision consiste à savoir si votre façon de travailler a dépassé à la fois le classeur et les produits que vous pourriez acheter, correctement configurés. Une plaquette qui transforme chaque tableur en raison de construire une plateforme vend le plus gros projet, pas le plus petit projet utile.

Ce qui commence à céder quand l'entreprise grandit

Les signes sont opérationnels. Un responsable peut les voir sans audit technique.

• Les mêmes informations sont saisies dans une boîte mail, un classeur et un outil de facturation.
• Deux fichiers ne sont pas d'accord sur un client, un prix ou l'état d'un dossier, et personne ne sait lequel a été mis à jour en dernier.
• Le rapport du lundi attend une seule personne, parce qu'elle seule sait quel onglet est à jour.
• Un passage entre la vente et les opérations oublie un champ, et l'erreur apparaît sur le chantier ou sur la facture.
• Personne ne voit la file des deux équipes sans demander un export.
• Les outils déjà payés ne partagent pas un dossier, ou ne le partagent que par un fichier nocturne que quelqu'un contrôle à la main.
• Une tâche répétée, comme relancer un devis ou préparer un ordre de travaux, prend la même demi-heure à chaque fois.
• Le coût de maintenir le contournement, en licences, en heures supplémentaires et en corrections, continue de monter alors que le processus ne change pas.

Une entreprise de services locale peut le vivre comme des dossiers copiés d'un e-mail vers un classeur, puis vers une facture. Un cabinet peut le vivre comme trois versions du pipeline. Le schéma est le même. Le dossier du travail et le travail lui-même se sont séparés.

Quatre façons de répondre

1. Un logiciel que l'on peut acheter

Des produits existent pour la comptabilité, les fiches clients, la réservation, le support et de nombreux métiers. Ils sont la bonne réponse lorsque votre processus est proche de celui pour lequel le produit a été conçu. Vous échangez de la souplesse contre un éditeur qui maintient le produit, et vous acceptez sa définition d'un « dossier », d'un « contact » ou d'un « ticket ». Cet échange est sensé quand le modèle convient. Il devient cher lorsque vous passez les deux années suivantes à le contourner.

2. Une meilleure configuration des outils déjà en place

Avant que quiconque n'écrive un nouveau logiciel, demandez si le produit déjà dans les murs fait le travail et n'a simplement jamais été configuré. Des champs inutilisés, un statut manquant, deux équipes dans deux comptes, et un rapport que personne n'a appris à lancer sont des problèmes de configuration. Ils coûtent moins cher qu'un développement, et ils constituent le premier projet honnête lorsque l'outil correspond. Ils n'inventeront pas un flux que le produit ne peut pas représenter.

3. Un logiciel construit pour le flux de travail

Le développement sur mesure a sa place lorsque les règles sont les vôtres : la façon dont un devis devient un dossier, les contrôles qu'un coordinateur doit noter, la séparation entre ce que le client voit et ce que le sous-traitant voit. Un logiciel métier peut suivre ce chemin et s'intégrer aux systèmes que vous comptez garder. Il faut ensuite l'héberger, le modifier et le comprendre après la première mise en service. Cette possession dans la durée fait partie du choix. Ce n'est pas une surprise au sixième mois.

4. Une approche hybride

La plupart des entreprises en croissance n'ont pas besoin d'un système unique qui remplace tout. L'hybride garde un produit pour le travail standard, comme la facturation ou la messagerie, et ajoute une application ciblée là où ces produits ne se rejoignent pas. La file du matin d'un coordinateur, décrite dans l'article sur les sites des entreprises de bâtiment britanniques, a cette forme : un site public, plus un espace que l'équipe ouvre vraiment. L'étude de cas Ecobuild montre cette même séparation dans un projet livré. La limite compte. Si la pièce sur mesure devient en silence une seconde copie du logiciel de comptabilité, l'hybride a échoué.

Les coûts et les compromis, sans prix inventé

Personne ne peut chiffrer cela depuis un article, et un montant inventé pour l'exemple ferait semblant d'être un devis. Ce que l'on peut faire, c'est nommer les familles de coûts, et refuser une comparaison qui ne compte que la première facture.

• Le développement initial, ou le projet de configuration si vous réglez un produit plutôt que de le construire.
• Les licences qui continuent pour chaque produit conservé, y compris ceux dont un hybride dépend encore.
• L'hébergement et les environnements nécessaires pour tester un changement avant que les clients ne le voient.
• La maintenance : corrections, petites évolutions, et quelqu'un à appeler quand un formulaire échoue un mardi.
• L'intégration. Relier un CRM, la comptabilité ou un prestataire de paiement, c'est de la correspondance de données et de la gestion des échecs, pas un interrupteur, sauf si les données sont déjà d'accord.
• La sécurité et les accès. Qui peut voir une fiche client, qui peut l'exporter, et comment un départ coupe l'accès. Un tableur partagé échoue souvent déjà à ce test.
• La formation et l'adoption. Un outil que l'équipe n'ouvrira pas n'a pas rendu la demi-heure.
• La dépendance. Un produit peut changer de prix ou retirer une fonction. Un système sur mesure dépend des personnes qui peuvent le modifier. Aucune des deux voies n'est exempte de dépendance. La question est de savoir laquelle vous pouvez assumer.
• Le temps rendu à l'entreprise. C'est le bénéfice, et il n'est connaissable que par rapport à une base que vous avez enregistrée, pas par rapport à un pourcentage dans une proposition.

Si un coordinateur passe une part récurrente de la semaine à ressaisir les mêmes dossiers, notez ce temps sur une vraie quinzaine. Le logiciel mérite d'être discuté si un outil plus petit, réellement adopté, rendrait une part utile de ces heures une fois la formation terminée, tout en traitant correctement les cas difficiles. Cette part est une mesure que vous prendrez plus tard. Ce n'est pas un retour qu'un fournisseur peut honnêtement imprimer avant que la base existe.

Un test simple avant de faire développer

Parcourez les questions dans l'ordre. Arrêtez-vous à la première qui a déjà une réponse moins chère.

• Pouvez-vous nommer le flux en une phrase qu'un collègue reconnaîtrait ?
• Avez-vous une trace du temps, du délai ou des erreurs, même approximative, issue de votre équipe ?
• Avez-vous essayé de configurer le produit que vous payez déjà, avec quelqu'un qui connaît ce produit ?
• Le travail dépend-il de règles qu'aucun logiciel du marché ne modélisera sans une pile d'exceptions ?
• Quel système existant doit-il joindre dès le premier jour, et quelles connexions peuvent attendre ?
• Qui le modifiera dans un an, et que se passe-t-il si la personne qui tenait le tableur part ?
• Quelle est la plus petite version qu'un vrai utilisateur peut terminer, et qu'est-ce qui vous ferait arrêter ?

Si les trois premières réponses sont « non », vous n'avez pas encore un projet logiciel. Vous avez un processus qui n'a pas été décrit. Si un produit convient déjà, achetez-le ou configurez-le. Si les règles sont spécifiques et si le contournement est devenu un vrai coût, un développement sur mesure ou hybride reste l'option, limité à ce seul flux.

Commencer par un seul flux

La version la plus risquée de cette décision est une plateforme qui remplace tous les classeurs de l'entreprise d'un coup. La version plus sûre est un flux important, une preuve de concept qui teste l'hypothèse risquée, ou un produit minimum viable qu'un membre de l'équipe peut utiliser un vrai mardi. Ce qui appartient à cette première version, et pourquoi s'arrêter est un résultat réussi, est décrit dans le développement d'un MVP pour une entreprise britannique. Laissez le second service de côté jusqu'à ce que la première tranche soit vraiment utilisée.

Les données personnelles n'attendent pas le système complet. Les noms, les adresses et les notes de demande sont des données personnelles au sens du RGPD britannique, qu'elles soient dans un classeur ou dans une application. Les accès, la conservation et la trace de qui peut exporter le fichier appartiennent à la première tranche, pas à une phase de conformité que l'on programme après la mise en service.

Ce qu'il faut apporter à un premier échange

Web Works Rise est une équipe dirigée depuis Birmingham, avec une capacité de livraison depuis un pôle en Tunisie. Le brief utile est un flux devenu pénible, les outils qu'il touche aujourd'hui, et à quoi ressemble une tâche terminée pour la personne qui la fait. Contactez l'équipe avec ce processus. Si un produit que vous possédez déjà peut le porter, c'est une bonne réponse. S'il ne le peut pas, le travail sur mesure doit quand même commencer plus petit que la collection de tableurs qu'il remplace.