Sortir votre activité des tableurs : une feuille de route
La plupart des entreprises qui disent n'avoir « aucun système » en ont en réalité quatre : une liste de prix, une liste de clients, un journal de dépenses, un historique de commandes — chacun un tableur, chacun digne de confiance pour exactement une seule personne, chacun à une mauvaise saisie automatique d'un chiffre faux que personne ne remettra en question pendant un mois. Ce qui empêche les gens de les remplacer est rarement l'attachement ; c'est la peur d'une bascule unique, tout ou rien. Alors n'en faites pas une.
Commencez par celui qui vous pose le plus de problèmes
L'ordre classique — le catalogue d'abord, puis les clients, puis l'historique — est un bon conseil si rien ne fait activement mal. Si quelque chose fait mal, commencez plutôt par là : la liste de prix en retard d'une version que deux personnes modifient en parallèle, le journal de dépenses en retard d'un mois de reçus dans une bonne semaine. L'élan de résoudre un problème ressenti vous porte à travers l'effort de mise en place d'une façon que commencer par le tableur « correct » mais indolore ne fait jamais.
Ce qui doit réellement être vrai pour qu'un import fonctionne
Sous n'importe quel véritable outil d'import, trois décisions font tout le travail :
Le mapping — indiquer à la destination que la colonne « Item Name » de votre tableur et son propre champ name signifient la même chose.
Une clé de déduplication — un identifiant stable qui survit d'un import à l'autre, pour que réimporter un fichier corrigé mette à jour trois lignes au lieu d'en dupliquer 2 000. Les noms changent ; une référence externe, un numéro de commande ou un e-mail, non.
Le traitement ligne par ligne — chaque ligne réussit ou échoue de son côté, pour qu'une ligne mal formée ne bloque pas, ni ne corrompe en silence, les quelques milliers d'autres qui étaient correctes.
Les éléments qui se transfèrent généralement sans accroc
Quelques catégories s'importent généralement bien avec un fichier correctement mappé, parce que les champs de destination sont bien définis et que les données elles-mêmes ne demandent en général pas beaucoup d'interprétation :
Catalogue — une liste de prix devient de véritables fiches produits ou services, chacune ensuite modifiable normalement au lieu de rester un import figé.
Clients — une liste de contacts devient des fiches clients, rapprochées ou créées à partir d'un identifiant stable comme l'e-mail, sans inscrire quiconque en silence à un marketing qu'il n'a jamais accepté — ce consentement doit être un oui véritable et distinct, pas un effet de bord du fait d'avoir figuré un jour dans un tableur.
Commandes ou transactions historiques — un journal de ventes passées devient un historique en lecture seule sur lequel vous pouvez produire des rapports, sans faire croire qu'il s'agit de commandes en cours à préparer, à encaisser ou pouvant être remboursées.
Dépenses — des dépenses catégorisées deviennent des enregistrements structurés avec un fournisseur et une catégorie associés, si bien qu'une vue de rentabilité peut les exploiter immédiatement au lieu d'attendre que quelqu'un ressaisisse à la main un an de justificatifs.
La partie qui ne bouge jamais toute seule : les décisions de jugement
Aucun importeur ne peut décider que « Divers », « div. », « Autre » et « Non classé » forment une seule catégorie — fusionnez-les avant l'import ou vous en obtiendrez quatre. Il en va de même pour ce qui relève du coût des marchandises par rapport aux dépenses de fonctionnement (une seule erreur de répartition et chaque chiffre de marge en hérite ensuite en silence), et pour savoir lesquels de vos « clients » vieux de trois ans valent la peine d'être conservés. Migrer de mauvaises données plus vite n'est pas une victoire.
Un ordre pratique des opérations
1
Nettoyez d'abord le tableur
Corriger les erreurs évidentes, se mettre d'accord sur les noms de catégories, supprimer les lignes de test et les doublons — tout cela se fait plus vite en une fois, dans le tableur, qu'une fois réparti dans des enregistrements en production.
2
Importez d'abord la portion la plus petite et la plus sûre
Un mois récent plutôt que cinq ans d'historique, pour vérifier que la correspondance des colonnes fait bien ce que vous croyez avant de lui confier le reste.
3
Vérifiez le résultat avant de vous y fier
Vérifiez à l'œil quelques enregistrements importés par rapport au tableur d'origine — bon prix, bonne catégorie, bon client — avant d'importer quoi que ce soit d'autre.
4
Importez le reste une fois le mappage validé
Une fois le petit lot vérifié, le même mappage et la même clé de déduplication traitent sans risque le reste de l'historique — relancer l'import est sans danger, car la clé de déduplication fait qu'un import répété met à jour les enregistrements existants au lieu de les dupliquer.
Comment Olmira gère cela
Olmira importe par CSV, et non via un unique assistant « tout migrer » — volontairement, car les décisions de jugement ci-dessus sont exactement celles qu'un outil entièrement automatique ne devrait pas prendre à votre place. Le catalogue, les clients, l'historique des commandes et des réservations passent par le même moteur de mapping de champs avec une clé de déduplication, si bien que relancer un fichier est sans risque ; les nouveaux articles du catalogue arrivent en brouillon et les contacts importés ne sont jamais réputés consentants au marketing par défaut, donc rien ne passe en ligne ni n'est envoyé par e-mail par accident.
Les dépenses s'importent séparément : les catégories et fournisseurs sont créés à partir des noms de votre fichier, et chaque dépense importée arrive en brouillon, en attente de la même étape de justificatif et d'approbation qu'une dépense saisie à la main. Le back-office alimenté par ces imports est Management ; la plateforme de connecteurs sous-jacente est Integrations.
S'il peut exporter en CSV — et presque tout le peut — vous pouvez le faire correspondre à l'import. Il n'y a pas de connecteur en un clic par fournisseur à maintenir à jour — un seul import CSV mappé, avec la même protection contre les doublons, couvre chaque système source.
Avec une clé de déduplication stable — une référence externe, un numéro de commande ou un e-mail, plutôt qu'un nom — un import répété met à jour ou ignore les enregistrements déjà existants au lieu de les dupliquer.
Non — les commandes historiques importées sont exclues des analyses de chiffre d'affaires précisément pour qu'un journal de ventes importé à titre de référence ne vienne pas gonfler ce qui a réellement été vendu via le système en service.
Oui — jusqu'à 10 000 lignes par fichier. Un historique plus long implique simplement de le répartir sur deux ou trois fichiers plutôt qu'un seul, ce qui facilite d'ailleurs l'étape « d'abord un petit lot » évoquée plus haut.
Non — ce raisonnement du tout ou rien est précisément la peur dont ce guide veut vous détourner. Commencez à utiliser les parties que vous avez déjà migrées pendant que le reste des tableurs continue de tourner ; aucune règle n'impose que le catalogue, les clients et l'historique arrivent le même jour.