Le job d’un BA dans une très grosse entreprise

Le job d’un BA dans une très grosse entreprise


En tant que Business Analyst, j’ai été amené à réaliser des tâches très variées.
Voici quelques exemples de tâches, en douceur:





Trouver où quelque chose est utilisé.





Par exemple, quelqu’un a décidé de changer le nom d’un produit, ou de changer le bas de page standard de tous les sites web de la compagnie.





Il n’y a évidemment pas de liste, trop simple. Et les personnes au courant se sont succédées. Et elles ont d’ailleurs quitté la boîte depuis des lustres.





Tout à coup cette tâche qui me semblait banale devient une quête, de service en service, je rencontre des gens, je construis un schéma pour comprendre les liens entre applications, comment l’information passe d’un responsable d’application à un autre. Je découvre pourquoi cette liste que je voulais construire ne sera jamais à jour automatiquement si rien ne change.





Je suggère un process, ou une mini-procédure simple, et je la fais valider par les acteurs, qui l’adapte pour leurs besoins spécifiques. J’explique tout ça à mon management. Et j’ajoute:
– Ha au fait, voilà où c’est utilisé actuellement
Super Stéphane *





(*) Comprenez « Et ça va coûter combien?« 









Définir les impacts de ce futur changement.





Ce job est la succession logique du précédent. Quand je sais ce qui va changer, je tente de voir comment ce changement va être perçu ou interprété. La mise en place de ce changement n’est peut-être pas si triviale, ou il implique plusieurs équipes?





Il est temps de faire le tour des intervenants:





  • Les utilisateurs:
    • Vont-ils comprendre? Vérifier s’il en ont besoin (même si le demandeur l’aurait déjà fait, ne pas faire confiance)
  • Les développeurs du site web ou des applications:
    • Leur demander le temps d’adaptation afin de donner l’info plus tard, impliquer un architecte si ça devient trop compliqué.
  • Les copywriters/publishers:
    • Ce sont les personnes qui éditent le contenu. Certains changements impactent leur façon de travailler et pourrait leur faire perdre beaucoup de temps (ou en gagner).
  • Le management:
    • Si le contrôle d’un process passe d’une équipe à l’autre, le manager pourrait devoir accepter ce fait. Soit par ego, ou parce qu’il y a d’autres implications organisationnelles.




Suite à ces interviews/réunions, la solution ou le changement est challengé. C’est inévitable. Par les intervenants ou par moi-même. C’est le moment d’écrire noir sur blanc les avantages et inconvénients de chaque solution. Peut-être est-ce évident et on passe au point suivant, peut-être faut-il recommencer du début.





Si tout va bien, Je termine mon rapport ou mon Powerpoint avec une checklist. Ce sont toujours les mêmes points, ça me sert de garde-fou:





  • statistiques
  • date de validité
  • accessibilité,
  • RGPD (GDPR)
  • gestion des langues
  • si nécessaire: dead line, phases suggérées
  • dépendances (systèmes, fournisseurs, …),




Je fais tout valider par le demandeur. C’est un chef de projet, un Product Owner, ou simplement mon chef (et on écoute toujours son chef, sinon on est viré)





Dans le pire des cas:
– Oui OK, c’est ce que je voulais. Je le transmettrai à Machin.





Mais dans le meilleur des cas, il ou elle voit des choses à préciser, d’autres ont été oubliées, une idée vient de germer à nouveau: à investiguer.
En clair, on en parle, on fait évoluer le besoin pour mieux s’aligner avec la réalité. C’est génial parce que le boulot que j’ai fait à l’air d’être utile.
Évidemment ça m’a pris blindé de temps sur mon planning et entretemps ma todo list s’est allongée pour d’autres projets, mais le résultat était déjà positif et on s’accorde sur 1 semaine. OK je l’intercalerai avec les autres tâches en cours.









Et encore bien d’autres tâches





La liste des tâches est presque infinie et très variée. Il y a tout de même un invariant, c’est la découverte. En effet, si le travail devient répétitif, il est temps d’en faire une procédure et de le déléguer à quelqu’un d’autre ou de l’automatiser. Et puis de passer à autre chose.





Voici quelques exemples de tâches:





  • Savoir pourquoi « c’est comme ça »
  • Quel outil choisir pour l’entreprise?
  • Préparer et affiner le travail du Product Owner
  • Mettre en place des statistiques, ou faire le tour des étages pour en avoir
  • Donner un avis qui ne sera jamais suivi, enfin pas avant 2 ans.
  • Se substituer au Project Manager pour gérer le projet qu’on a analysé (pas l’argent)
  • Créer un schéma d’architecture « logique » pour éclairer la lanterne du demandeur.
  • Construire rapidement l’expérience utilisateur que le business voudrait mettre en place. Puis montrer les incohérences et construire ensemble quelque chose d’acceptable.
  • Recommander de phaser un projet, en vain.
  • Découvrir qu’un comportement n’est pas normal, et l’analyser proactivement.




Voici déjà quelques tâches typiques que j’ai réalisées. Il y en a encore beaucoup d’autres.
Prochainement dans un autre post, nous reparlerons de ces autres tâches qui constituent le travail journalier d’un Business Analyst.





Merci et bonne journée.


Bonjour tout le monde !


Bienvenue sur mon blog.





Vous trouverez dans ces pages une partie de mon expérience informatique dans les mondes du médical hospitalier et des professions libérales, dans les domaines bancaire et de la finance, dans les télécommunications, dans le public et dans la distribution.





En effet, lors de ces 30 dernières années, j’ai été:





  • développeur, lead developper,
  • analyste technique, lead analyst,
  • coach, teacher,
  • team manager, team lead
  • digital project manager,
  • business analyst (BA).




Je suis aussi indépendant et patron de ma propre entreprise. J’ai créé des applications pour mon compte et à la demande de mes clients. J’ai eu quelques employés à l’époque. Je suis certifié Product Owner (agile).





Le but de ce blog est de montrer mon expérience de BA, et parfois à travers les autres différents rôles. Un BA dans le monde agile a-t-il encore sa place? Ou comment peut-il la gagner ou la perdre?
C’est quoi un business analyst en vrai? Dans un gros département IT, ou dans un plus petit?





Et je tenterai de répondre à vos questions en complétant mes articles.
Bonne lecture.






GET IN TOUCH

  • Adresse:
    rue du Ruisseau St-Jean 2/B
    1367 Huppaye – Belgique
  • Tel: +32-475.57.43.01
  • Email: phano@oos.be

OPENING HOURS

Monday – Friday: 9am – 5pm

(et j’aime bien aller au resto à midi)

FOLLOW US

Copyright Stéphane Mathieu ©
All Rights Reserved.