Tag: IIBA


Ce billet est aussi publié en français sur mon blogue.

In a previous post (in French), I was telling you that my LinkedIn profile has generated some interesting opportunities, one of my HEC Montréal teachers asking me to go in one of her master class to speak about challenges the analyst meet in an integrated systems projet.  The premises behind this idea are very interesting, and those of you who studied in IT at HEC Montréal will agree with me.

Indeed, no matter the interest coming from ERP-style software like SAP, and despite their growing popularity, ERP are rarely the unique solution to business problems in an organization.  Actually, solutions to these problems are usually made of many systems (some of them being already in place) that need to interact closely, and among which we may find an ERP system.

Considering this, we might argue why IT programs at HEC Montréal (and probably in other universities) are so focused on teaching through SAP or other ERP systems (although I learned a lot through these classes).  Based on that and on my last 5 years on two major non-ERP projects, I identified the 7 biggest challenges faced by a business analyst in a integrated systems (plural form) project.

    1. Expanded horizons: understand the organization and its systems
    2. Define a vision: create solutions without destroying the current one
    3. Communicate better: many systems means many friction points
    4. Teams work: many systems means many teams
    5. Meet commitments: commit to provide a stable solution
    6. Rush for success: go ahead in an iterative way to reach your objectives
    7. The IIBA to get it done: structure and methodology to succeed

These behaviors are not specific to this type of project, but are especially critical when you are in one of these.  Check out my blog in the upcoming weeks; all these challenges will be covered by a detailed post.  This list will get updated with links to these posts.

Have you ever found yourself in this situation?  How did you get through it?  Leave your comments!

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!

We, the Business Analysts

I’m reading a lot about what is exactly a business analyst since the beginning of the year.  I do know what I do as a business analyst, but I’m often asked (either by colleagues, managers or my undergraduate students at HEC Montréal) what is exactly a business analyst.  I can provide them an convincing answer, but it’s never short to explain nor easy to understand without some context (for students, it’s a lot harder to understand as most of them don’t have any business analysis experience).

My first personal tentatives to define what is a business analyst were essentially focused on categorization (strategy analyst, business process analyst, functional analyst, system analyst, etc.).  However, I didn’t find the result very convincing, nor easy to understand for non-business analysts.

Then I tried to look at the IIBA definition (in the BABoK), but it does not give a full understanding of what we really do, or how we think, as business analysts (although it provides very useful information on how to perform business analysis work).

Although I didn’t find one unique answer yet, I did find some interesting thoughts that I printed and put in my office.  It’s not perfect, but it provides a good source of motivation when I feel lost :-)

We, the Business Analysts

Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve.

Business analysts lead teams from the inside out. We create positive change for our organizations. We inspire others to follow us on our path toward positive change. We help everyone understand exactly what that change is and how they can contribute to it. We help teams discover what the change should be.

As business analysts willing to create value for the business:

  • We will understand what the business needs, and help our teams deliver a solution that the business will own.
  • We will balance our goals with our constraints to achieve a valuable result.
  • We will lead our teams toward the best possible solution to the problem we are trying to solve.

As business analysts willing to create value for the users:

  • We will do what is easy for the reviewers and users of our deliverables, instead of doing what’s easy for us.
  • We are not specifying requirements because we am important, but because those who will use them to deliver solutions that satisfy the requirements are important.
  • We will not demand that users of our requirements put up with our quirks (bad spelling, bad organization, sloppiness).
  • We will  model and package the requirements so that they might be easily understood by those who will be using them.

We are not simply translators.  We create and maintain a conductive holding environment that enables our teams to achieve a shared understanding of a business problem for the time required to deliver the solution that will solve it.

(Thanks to Laura Brandenburg, Jonathan Babcock and Paul Culmsee for their precious input).

Feel free to comment or add any reflexion you have on this matter.  I will also submit this to my students at the next semester to see what are their impressions on this, and if it helps them to figure out what they could do as business analysts.

Stay tuned!

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