Le key user dans SAP Business One : ce qu'est le rôle, ce qu'il demande avant et après le démarrage, et comment choisir et former les key users

Ce qu'est un key user.

Key user n'est ni un paramètre ni un type de licence de SAP Business One ; c'est un rôle dans le projet et dans l'organisation. Par service (ventes, achats, entrepôt, comptabilité, parfois production ou service après-vente), une personne apprend comment tout le processus de ce service se déroule dans B1, et devient le lien entre ses collègues et le partenaire. Dans une petite entreprise, une même personne couvre parfois deux services ; le rôle reste le même.

• Support de premier niveau. Un collègue bloqué s'adresse d'abord au key user. Celui-ci résout ce qui relève de l'utilisation, et transmet ce qui est une erreur ou un paramètre, avec une description claire de ce qui s'est passé.
• Responsable du processus. Avec le partenaire, il décide comment le service travaille dans B1 : quels documents, quels champs sont obligatoires, quels états on utilise.
• Tests. Il teste le paramétrage avec ses propres cas avant le démarrage, puis chaque modification, mise à jour ou nouvel add-on.
• Former les collègues. Il forme son service, puis chaque nouveau collègue qui le rejoint.
• Contact avec le partenaire. Il regroupe les questions et les demandes de modification, pour que le partenaire entende une histoire claire au lieu de dix.

Avant le démarrage et après.

Avant le démarrage, le key user travaille surtout sur le projet. Il explique au consultant comment le service travaille aujourd'hui, vérifie le paramétrage proposé, fournit et contrôle les données de base de son domaine (clients, fournisseurs, articles, prix), teste des processus complets dans une société de test et rédige de courtes instructions de travail dans les mots du service. À la fin, il forme ses collègues et il est sur le terrain les premiers jours en production.

Après le démarrage, le travail change mais ne s'arrête pas. Le key user répond aux questions, repère tôt les erreurs (une livraison jamais facturée, une goods receipt PO encore ouverte alors que la facture est arrivée), teste les mises à jour et les modifications avant qu'elles n'arrivent en production, forme les nouveaux collègues et tient les instructions de travail à jour. C'est aussi lui qui remarque que l'activité a changé et que B1 doit suivre.

Le temps que cela prend.

Plus que ce que la plupart des entreprises prévoient. Pendant le projet, les semaines de conception, de migration des données et de tests prennent une grande partie de la semaine de travail du key user. Si son travail habituel reste le même, ce sont les tests qui en pâtissent, et cela ne se voit qu'après le démarrage. Les premières semaines en production apportent la plupart des questions, et le key user doit alors être disponible pour ses collègues, pas enseveli sous son propre retard. Ensuite, cela se stabilise à quelques heures par semaine pour les questions, les modifications et les nouveaux collègues.

Rendez ce temps visible : convenez avec le responsable du travail qui part ailleurs pendant le projet, et désignez un remplaçant qui connaît au moins le processus principal, pour les congés et les absences.

Ce qu'un key user doit savoir.

Un key user ne paramètre pas le système ; c'est le travail du partenaire. Mais il doit comprendre assez le paramétrage pour expliquer ce que fait B1 et pourquoi.

• Le processus complet de son service, du premier document au dernier, et ce qui se passe avant et après dans les autres services. Les ventes doivent savoir ce que l'entrepôt fait d'une commande client, et ce que la comptabilité fait de la facture.
• Le flux de documents : documents de base et documents cibles, Copy From et Copy To, quantités ouvertes, et quand clôturer ou annuler. Voir le guide sur le flux de documents dans SAP Business One.
• Ce que chaque document comptabilise : stock, quantités engagées et commandées, et l'écriture comptable. Un key user qui sait lire l'écriture d'une livraison ou d'une goods receipt PO répond à la moitié des questions de la comptabilité.
• Les paramètres qui touchent son service, au moins en lecture : Document Settings (Administration → System Initialization → Document Settings), les périodes comptables, la G/L account determination derrière ses documents, et les procédures d'approbation (Administration → Approval Process → Approval Templates) si des documents doivent être approuvés.
• Requêtes et alertes : le Query Manager (Tools → Queries → Query Manager) pour lancer les listes enregistrées du service, et les alertes (Administration → Alerts Management) qui signalent ce qui demande une action. Écrire du SQL complexe n'est pas nécessaire ; savoir ce qui existe et qui le maintient, si.
• Autorisations : ce que les collègues peuvent voir et faire. General Authorizations (Administration → System Initialization → Authorizations → General Authorizations) est maintenu par le partenaire ou l'administrateur, mais le key user sait ce dont le service a besoin et le vérifie pendant les tests.
• S'y retrouver : Form Settings (Tools → Form Settings) pour afficher les bonnes colonnes, la Relationship Map d'un document, le Change Log (Tools → Change Log) pour voir qui a modifié quoi, et l'Open Items List pour les documents encore ouverts.

Comment choisir et former les key users.

• Choisissez pour la connaissance du travail, pas pour le rang. Le meilleur key user sait comment le service fonctionne vraiment, exceptions comprises, et il est respecté par ses collègues. Un responsable jamais disponible est un mauvais choix.
• Choisissez quelqu'un qui aime expliquer. Un key user qui garde ses connaissances pour lui devient un goulot d'étranglement.
• Désignez-les au début du projet, pas deux semaines avant le démarrage. Celui qui a assisté aux ateliers de conception comprend pourquoi le paramétrage est tel qu'il est.
• Formez-les plus en profondeur que les utilisateurs : le processus complet, les écritures et les paramètres qui sont derrière, dans une société de test avec leurs propres données. Les façons de le faire, et ce que couvre une bonne formation, sont dans le guide sur la formation SAP Business One.
• Laissez-les s'exercer jusqu'à ce qu'ils y arrivent sans instructions, puis faites-leur former un collègue pendant que le consultant est encore là pour aider.
• Donnez-leur une ligne directe avec le partenaire, et convenez de ce qu'ils traitent eux-mêmes et de ce qui va au partenaire.

Là où cela se passe mal.

• Pas de temps. Le key user est désigné mais garde un poste à plein temps. Les tests sautent et les problèmes apparaissent en production.
• Trop tard. Le key user arrive après la conception et n'apprend jamais pourquoi le paramétrage est tel qu'il est.
• Une seule personne pour tout. Tout le savoir repose sur une personne, qui finit par partir.
• Ne tester que le cas idéal. Des tests avec des commandes idéales passent à côté des exceptions : livraisons partielles, retours, lots, devises étrangères, un prix différent sur la facture.
• Former avec des captures d'écran. Un dossier de captures remplace la pratique, et il est dépassé dès la première modification.
• Key user paramétreur. Le key user reçoit toutes les autorisations et modifie des paramètres sans le partenaire, ce qui fragilise le paramétrage et sa documentation.
• Personne après le démarrage. Le rôle s'arrête avec le projet, et les nouveaux collègues apprennent de celui qui est assis à côté d'eux.

Check-list : avant de désigner des key users.

• Un key user par service, plus un remplaçant qui connaît le processus principal.
• Du temps convenu avec leur responsable, pour le projet et pour les premières semaines après le démarrage.
• Présents aux ateliers de conception et à la vérification des données de base de leur domaine.
• Une société de test et un plan de tests avec leurs propres cas, exceptions comprises, et le résultat attendu pour chaque cas.
• Une formation sur le processus complet, le flux de documents et ce que chaque document comptabilise.
• Des accords avec le partenaire : ce que traite le key user, ce qui va au partenaire, et comment.
• De courtes instructions de travail par service, tenues à jour après le démarrage, et un plan pour former les nouveaux collègues.

Comment KoonLearn s'y prend.

KoonLearn, notre simulation de formation pour SAP Business One, propose un parcours pour les utilisateurs et les key users : les parties utilisateur des chapitres 00 et 02 à 09, sur les achats, les ventes, le stock, la production, le service et la comptabilité. Vous travaillez dans un client reconstruit pour la formation sur SAP Business One 10.0 FP 2608, avec son propre moteur comptable qui comptabilise vraiment : vous voyez ce qu'un document fait au stock et au grand livre, et la journal entry preview vous le montre avant que vous n'ajoutiez le document. Les tâches sont vérifiées champ par champ, des tâches de dépannage vous font trouver pourquoi une écriture est fausse, et chaque chapitre se termine par un test. Aucune licence SAP, base de test ou serveur n'est nécessaire.

Pour un key user, c'est un endroit pour apprendre toute la chaîne avant le démarrage et la répéter ensuite ; pour le service, c'est un moyen de former les nouveaux collègues sans salle de cours. Les organisations achètent des places dans le portail client et attribuent chaque place à un collègue. Cela ne remplace pas une formation sur votre propre paramétrage, et le paramétrage lui-même (autorisations, procédures d'approbation, alertes, migration des données) fait partie du parcours partenaires, pas du parcours key user. Le chapitre 03 Achats est gratuit et sans compte : commencez le chapitre gratuit sur learn.koonsystems.com. KoonLearn n'est pas affilié à SAP SE.

Sources : la documentation d'aide de SAP Business One 10.0 (Document Settings, General Authorizations, Alerts Management, Query Manager, procédures d'approbation, Form Settings, Change Log, Open Items List, Relationship Map) ; l'aperçu des chapitres de KoonLearn. SAP et SAP Business One sont des marques de SAP SE.