Une certaine confusion entoure le positionnement d’un Business Analyst dans un projet d’implémentation d’ERP (Enterprise Resource Planning) ou de BI (Business Intelligence).
Pourquoi ? Essentiellement pour deux raisons :
- Tout d’abord parce que bien souvent, le Client a déjà choisi l’éditeur de la solution d’ERP ou de BI, avant même de démarrer son projet.
- « Dans mon ancienne entreprise, j’utilisais SAP, donc je veux l’utiliser à nouveau car je le maîtrisais bien et il me convenait parfaitement ». Sans nul doute, cet outil faisait l’affaire à votre précédent poste et dans une autre entreprise. Est-il pour autant approprié à vos nouveaux besoins et au contexte de votre nouvel employeur ?
- « Notre concurrent a choisi d’implémenter JD Edwards. Nous risquons de nous faire distancer technologiquement. Il a déjà dû faire un benchmarking des solutions du secteur. Ne perdons pas de temps, nous allons implémenter la même solution ». Votre concurrent a choisi un outil probablement adapté aux besoins de votre secteur d’activité. Et aux siens propres. Êtes-vous sûr d’avoir les mêmes ?
- D’autre part, comme ces solutions sont des packages « clés en main » aux modules intégrés, elles sont perçues (et vendues) comme au minimum à moitié spécifiées sur le plan fonctionnel. Il ne resterait théoriquement plus qu’à définir les configurations et la « cosmétique » des données présentées aux utilisateurs. C’est d’ailleurs un argument commercial de la part des éditeurs pour justifier le coût des licences et peser sur une décision mettant en balance un choix d’ERP/outil de BI et une solution personnalisée à développer « from scratch ».
Dans ces conditions, il arrive fréquemment que les projets d’ERP et de BI ne soient pas soutenus par un Business Analyst. C’est souvent le consultant spécialiste de la solution choisie – voire d’un module en particulier de la solution ERP/BI sélectionnée) qui fait office d’analyste métier, quand ce n’est pas le développeur technique lui-même.
Si un Business Analyst intervient, son rôle consiste le plus souvent à collecter les règles métiers déjà écrites/utilisées par le client, quand ce ne sont pas celles enregistrées en base, dans le code de la précédente solution. On peut aussi lui demander de fournir les maquettes de rapports déjà utilisés par les utilisateurs finaux. Celles-ci sont d’ailleurs souvent des copies de l’existant (“Regarde ce que je fais dans Excel / Access. Je veux la même chose.”).
Les spécifications fonctionnelles détaillées sont à la limite de l’analyse technique : le Business Analyst y décrit par exemple les champs et les métadonnées à paramétrer dans la solution.
Enfin, celui-ci se transforme en développeur / configurateur technico-fonctionnel afin de préparer et tester les rapports et les indicateurs, en attendant que les utilisateurs finaux soient formés et qu’ils puissent prendre la main en direct.
Bon, je schématise, et je sais que je vais faire bondir mes confrères et consœurs Business Analysts ERP / BI… Mais, pour avoir fait partie de cette joyeuse bande avant de découvrir toutes les autres facettes de ce beau métier, je peux vous assurer que cette description est très proche de la réalité 😉.
En réalité, un Business Analyst d’ERP / BI devrait effectuer les mêmes activités que dans n’importe quel autre type de projet. A savoir :
- Faire le lien entre le Client (MOA) et le Réalisateur (MOE).
- Être responsable de la conformité de la solution d’ERP /de BI aux besoins du Client, ce qui implique de collecter les besoins explicites ou tacites, les contraintes externes et internes auprès des seuls contributeurs MOA.
- Le Business Analyst devrait recommander la meilleure solution en cohérence avec les besoins métier du Client, son organisation, ses contraintes externes et internes. Le choix de l’éditeur et de sa solution technique ne devrait donc pas arriver avant le début du projet.
- Le Business Analyst devrait par conséquent être présent avant le début du projet (cadrage, benchmarking etc) et devrait rester après le GO LIVE pour s’assurer que la solution délivrée répond aux besoins réels.
A contrario, un Business Analyst ERP/BI ne devrait pas :
- Développer techniquement la solution (création de rapport, du framework…), ni tester les données restituées dans les rapports ERP/BI. C’est bel et bien d’une tâche technique et de tests unitaires qu’il s’agit – pas de tests fonctionnels.
- Avoir l’obligation d’être expert dans une technologie ou un outil particulier.
- Réécrire aveuglement les règles métiers qui lui ont été poussées par la MOE – même si elles émanent d’un Senior Manager technique. Ce sont les utilisateurs finaux qui sont les seuls éligibles à la transmission des règles métier.
Alors, bien sûr, entre la théorie et la pratique, il y a un gouffre… Car dans la réalité, les recruteurs de Business Analysts ERP / BI recherchent avant tout des candidats faisant tout ce qu’un Business Analyst ne devrait PAS faire…
Et vous ? Quelle est votre expérience ? Partagez-la en commentaire 😊
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
