La plupart des entreprises ont au moins une feuille de calcul que la direction aimerait voir disparaître. Personne ne lui fait vraiment confiance, mais la supprimer provoquerait probablement une petite crise immédiate.
Elle a peut-être commencé parce que le logiciel de rapports ne pouvait pas répondre à une question pourtant assez ordinaire. Avec le temps, quelqu’un a ajouté une colonne, puis un deuxième onglet, puis une formule copiée d’un vieux fichier que personne ne comprend tout à fait. Il y a peut-être une cellule qui devient rouge pour des raisons connues d’un seul employé et un onglet nommé quelque chose comme UTILISER CELUI-CI. Le fichier est difficile à entretenir et facile à briser. Il peut aussi être l’une des descriptions les plus fidèles de la façon dont une partie de l’entreprise fonctionne réellement.
Ces arrangements ne ressemblent pas toujours à des logiciels. Un fil Teams peut devenir l’endroit que les gens consultent avant de répondre à un client en particulier parce qu’il contient des détails qui ne se sont jamais rendus dans le dossier client. Les nouveaux employés apprennent eux aussi à le consulter, et l’équipe finit par dépendre d’une conversation que personne n’avait prévu de maintenir comme référence.
Il existe de bonnes raisons de ramener cette information dans un système contrôlé. L’équipe TI peut avoir des préoccupations légitimes de sécurité concernant des logiciels non officiels, et un gestionnaire qui doit réconcilier des dossiers contradictoires a tout intérêt à ce que tout le monde utilise la même source. Mais les personnes qui proposent le nettoyage doivent comprendre pourquoi les employés continuent d’utiliser la version non officielle.
Imaginons qu’une équipe de service à la clientèle tienne une feuille de calcul à côté du CRM de l’entreprise. Le CRM indique si un dossier est ouvert ou fermé, tandis que la feuille distingue les dossiers en attente des finances de ceux en attente du client. Il y a aussi une catégorie dont le sens revient à peu près à « Maria s’en occupe ».
L’amélioration évidente serait de cesser de maintenir deux dossiers. Mais ces catégories sont probablement apparues une à une à mesure que l’équipe découvrait qu’elle en avait besoin. Un dossier en attente de l’entreprise exige une réponse différente d’un dossier en attente du client, même si les deux sont ouverts. À force, l’équipe avait construit un modèle approximatif du travail que le CRM représentait mal.
Remplacez le fichier sans préserver ces distinctions et les gens leur trouveront un autre endroit. Leur travail exige toujours cette information. Six mois plus tard, il y aura peut-être une nouvelle feuille de calcul que quelqu’un devra encore réconcilier avec le CRM. La direction pourra conclure que les employés refusent d’adopter le nouveau système alors qu’ils auront simplement reconstruit quelque chose que le projet avait supprimé par accident.
Les gens modifient continuellement l’entreprise
Une représentante commence à noter un détail qui n’avait pas été jugé important au moment de configurer le CRM. Elle a remarqué qu’il l’aide à prévoir quelles ventes risquent de stagner, alors elle trouve un endroit où l’inscrire et continue de le suivre. Au moment où quelqu’un revoit la configuration du CRM, elle utilise peut-être cette information depuis des années.
Les systèmes formels sont rarement mis à jour chaque fois que quelqu’un apprend quelque chose d’utile ou que le travail change. Une acquisition peut laisser une équipe travailler beaucoup plus longtemps que prévu avec deux ensembles d’outils. Le gestionnaire qui combine les rapports des deux tous les lundis a quand même besoin d’une réponse pour la réunion de dix heures. Il développe une façon de l’obtenir, et cette routine peut survivre bien après que tout le monde a oublié qu’elle était censée être temporaire.
Il y a naturellement de mauvaises habitudes là-dedans. Certains Processes survivent à leur raison d’être, et un compte personnel utilisé pour le travail de l’entreprise peut devoir être fermé, peu importe sa commodité. Comprendre un contournement ne vous oblige pas à le conserver. Cela vous donne une meilleure chance de le retirer sans empêcher les gens de faire une partie de leur travail.
Parfois, la dépendance est une personne. Une employée se retrouve d’une manière ou d’une autre intégrée à cinq Processes sans que personne ait décidé qu’elle devrait l’être. Elle se souvient d’une vieille entente qui a créé une exception pour un client et sait pourquoi un certain statut dans le système ne veut pas dire ce qu’un nouvel employé supposerait raisonnablement. Quand une commande devient bizarre, quelqu’un lui envoie un message. Rien dans l’organigramme n’indique que l’entreprise dépend d’elle pour tout cela, mais planifier autour de ses vacances peut révéler à quel point c’est le cas.
Le nettoyage peut effacer des connaissances
Les projets de modernisation commencent souvent par un inventaire de tout ce qui est désordonné dans l’exploitation actuelle. Il y a des systèmes qui se chevauchent, des gens qui recopient de l’information de l’un à l’autre et quelques Processes que personne ne peut expliquer sans faire venir quelqu’un qui travaille là depuis quinze ans. Devant cet inventaire, on comprend facilement l’attrait de tout consolider.
Certaines organisations ont désespérément besoin de ce travail. La difficulté consiste à établir quels doublons apparents font réellement le même travail. Un service peut tenir sa propre liste de clients parce que la hiérarchie officielle ne décrit pas les relations qu’il doit suivre. Déplacer ces dossiers dans le système principal exige une décision sur la façon dont ces relations seront représentées, ou sur le fait que le service devra désormais s’en passer.
Les projets logiciels peuvent faire apparaître ces questions en plein milieu de l’implantation. Quelqu’un demande ce que signifie un statut particulier et obtient une réponse différente de chaque service. Un écran qui semblait être un remplacement simple doit soudainement représenter des distinctions que personne n’avait documentées parce que tous ceux qui utilisaient l’ancien Process les connaissaient déjà. Le désaccord doit être réglé avant que quelqu’un puisse construire un remplacement qui fonctionne pour tout le monde.
L’automatisation rend cela plus facile à négliger parce qu’une grande partie du travail administratif autrefois effectué par une personne peut maintenant être automatisée. Pensez à une employée qui ignore régulièrement un champ et lit une note avant d’approuver une commande. Le champ est peut-être peu fiable, ou la note contient peut-être une condition que le système ne sait pas représenter. Automatiser l’approbation en se fiant uniquement au champ supprime une vérification sans nécessairement supprimer le besoin de cette vérification. Quelqu’un doit déterminer ce que l’employée vérifie et comment le nouveau Process en tiendra compte.
Parfois, le contournement est la partie intéressante
Un système non officiel peut contenir une idée qui mérite d’être développée. Un outil maison de suivi des ventes peut regrouper les clients d’une façon qui aide l’équipe à prévoir quels comptes auront besoin de plus de soutien. Les catégories ont peut-être commencé comme le raccourci d’une seule personne, puis se sont répandues parce que ses collègues les trouvaient utiles. L’entreprise a alors quelque chose de précis à examiner : ces catégories prédisent-elles le travail plus fidèlement que celles de ses systèmes existants?
Il n’y a peut-être jamais eu de proposition ni de tentative consciente d’innover. Quelqu’un a créé un fichier Excel un mardi parce qu’il en avait assez de répondre à la même question, et d’autres ont continué de l’utiliser. Il vaut la peine de découvrir ce qui l’a rendu assez utile pour durer.
C’est une partie de ce que nous cherchons chez ShanVic quand nous lisons une organisation à travers People, Processes et Products. Nous voulons comprendre où le Process formel ne rend plus compte de ce que les gens doivent faire. Un contournement peut nous aider à repérer cette lacune, tandis que la façon dont les employés l’utilisent peut nous indiquer ce qu’un remplacement devra permettre. Il arrive qu’ils aient déjà trouvé une meilleure approche et qu’ils aient simplement besoin d’aide pour la rendre assez fiable pour un usage plus large.
Cette façon de penser fait partie du Clarity Brief. Nous voulons comprendre pourquoi quelque chose d’étrange a survécu avant de décider ce qui devrait le remplacer. Un examen plus attentif peut révéler que l’équipe a besoin d’une décision sur la responsabilité du travail avant d’avoir besoin d’un nouveau logiciel. Quand nous disons Read the Signals. Build the Systems., cela comprend la question de savoir pourquoi une équipe a encore besoin d’une feuille de calcul que tout le monde convient qu’on aurait dû retirer depuis longtemps.
Posez des questions sur les choses bizarres
Si vous voulez comprendre comment une entreprise fonctionne, lisez la documentation du Process, puis demandez à quelqu’un de vous montrer un cas récent qui ne cadrait pas avec elle. Découvrez ce qu’il a dû vérifier et où il a trouvé l’information. S’il a eu besoin de l’aide d’un collègue, demandez ce que cette personne savait qu’il ne savait pas.
Il vaut aussi la peine de demander ce que les gens seraient nerveux de perdre demain, même si cette chose n’est pas censée être importante. Cette question peut vous mener à un fichier non officiel ou à une routine si familière que personne n’a pensé à la mentionner quand vous avez posé des questions sur le Process.
Une partie de ce que vous trouverez sera inutile, et les personnes qui l’entretiennent seront peut-être soulagées de le voir disparaître. Mais vous trouverez peut-être aussi une feuille de calcul dont tout le monde se moque parce qu’elle est vieille, laide et beaucoup trop importante. Avant de la supprimer, découvrez pourquoi.