Tag: analyse fonctionnelle


This post is also available in English on my blog.

Dans un billet précédent, je vous faisais part de l’intérêt que mon profil LinkedIn avait soulevé auprès d’une de mes anciennes professeures de HEC Montréal.  J’ai eu l’occasion de méditer sur le sujet, et je m’apprête à aller faire cette présentation au début décembre.  L’idée de base est très intéressante, et ceux qui sont passés par les programmes TI de HEC Montréal pourront en convenir.

Malgré toute l’attention que reçoivent les logiciels de type ERP comme SAP, et malgré leur popularité croissante, il n’en demeure pas moins qu’ils constituent rarement une solution unique à l’ensemble des problèmes d’une organisation.  En effet, les solutions aux problématiques d’affaires complexes sont souvent composées d’une multitude de systèmes (certains étant déjà en place) qui doivent interagir, dans lequel on trouve souvent un logiciel ERP (mais rarement seulement un logiciel ERP).

Dans cette optique, on peut se demander pourquoi les programmes de formation en TI de HEC Montréal (et probablement ailleurs) sont aussi axés sur l’enseignement au travers de SAP (loin de moi l’idée de renier totalement cette perspective; j’ai moi-même passé par ce chemin, et je profite encore de toutes ces notions).  Compte tenu de cela et de mon expérience des 5 dernières années sur deux projets majeurs non-ERP, j’ai identifié 7 des plus grands défis qu’un analyste d’affaires / fonctionnel peut rencontrer dans un monde de systèmes intégrés (au pluriel).

    1. Élargir ses horizons: comprendre l’organisation et ses systèmes
    2. Être visionnaire: élaborer des solutions sans nuire à la situation actuelle
    3. Savoir mieux communiquer: qui dit plusieurs systèmes dit plus de points de friction
    4. Travailler en équipes: qui dit plusieurs systèmes dit plusieurs équipes
    5. Respecter ses engagements: s’engager pour assurer la stabilité de la solution finale
    6. Foncer vers le succès: progresser de façon itérative pour atteindre ses objectifs
    7. L’IIBA, une bonne carte dans votre jeu: rigueur et méthode pour réussir

Ces comportements ne sont pas propres à ce genre de projet, mais ils sont particulièrement critiques lorsqu’on se retrouve dans cette situation.  Surveillez bien mon blogue dans les prochaines semaines; chacun de ces sujets fera l’objet d’un billet approfondi.  Vous pourrez revenir à ce billet, je mettrai les liens vers les articles au fur et à mesure.

Et vous, avez-vous déjà été confronté à ce contexte?  Comment vous en êtes-vous sorti?  Laissez vos commentaires!

Excellent article de Barbara Davis sur les oublis trop fréquents des analystes dans le cadre de projets, lors de la rédaction de spécifications.  Pour les avoir expérimentés à divers degrés (et en avoir subi les conséquences), je vous suggère de garder cette liste à portée de la main:

  1. Effectuer des recherches – l’utilisateur ne connaît pas tout!
  2. Identifier les écarts ET les gérer – la gestion de risque n’est pas limitée aux chargés de projet
  3. Gérer l’ambiguité – s’assurer d’avoir la perspective de différents groupes afin de bien documenter les spécifications
  4. Valider les spécifications par différents moyens – il existe plusieurs techniques qui peuvent être exploitées de façon complémentaire
  5. Faciliter l’approbation finale – ne pas se contenter de faire lire les spécifications aux utilisateurs; les guider dans leur lecture

Bonne lecture!

Les outils de l’analyste agile

Petit tableau très intéressant sur les principaux livrables d’un analyste en contexte agile: http://www.agilemodeling.com/artifacts/

À mettre dans vos favoris!

EricProvost.net est hébergé par Servage sur Wordpress | Thème: Motion by 85ideas.