La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

Supporter

Fil des billets - Fil des commentaires

dimanche, octobre 20 2013

Comment la MOA peut améliorer la perception des performances ?

Par Olivier Durand le dimanche, octobre 20 2013, 14:08

Du côté des utilisateurs :

Sur notre appli web, les clients attendent trop longtemps avant d'obtenir un prix, ils n'en peuvent plus !

Le processus est plus en plus fastidieux à réaliser, tout est lent !

Du côté de la direction :

Pourquoi nos plateformes sont si lentes ? 

Pourquoi est-ce que les performances ne s'améliorent pas ?

Pourquoi nos concurrents sont meilleurs ?

Alors, comment la MOA peut aider les différentes parties prenantes à mieux percevoir les performances ? Beaucoup de MOA pensent que les performances ne sont pas leur problème. C'est un problème technique.Quoi doit être résolu par des techniciens très pointus. Alors, c'est vrai, la MOA ne résoudra pas les problèmes de performances.Mais elle doit définir les contours du problème et les critères qui permettront de dire que le problème est résolu.

Gestion des exigences

Par contre, la MOA est en charge de la définition des exigences non fonctionnelles. A quelles contraintes le système doit-il répondre ? Comment évoluent ces contraintes ? Ensuite chaque exigence est priorisée et on s'autorisera donc un effort plus ou moins important pour y répondre. 

Mesure de la satisfaction des utilisateurs

La MOA doit également être capable de mesurer la satisfaction des utilisateurs. On pourra par exemple mettre en place un indice de performance en se basant sur les préconisations de l'Apdex. L'idée de l'Apdex c'est de proposer un moyen standardisé de représenter la satisfaction des utilisateurs par rapport aux performances d'un système ou d'un process. Cela permet d'agréger plusieurs indicateurs sous forme d'un indice unique.

Pour les différents indicateurs qui façonnent la perception des utilisateurs, on va définir une limite de temps acceptable ainsi qu'une limite de temps satisfaisante. L'APDEX préconise de prendre  prendra une limite de temps acceptable = 4x la limite satisfaisante.

Il faut définir ces limites pour chaque type d'interaction importante que l'utilisateur aura avec le système. Par exemple, sur une application de traitement de photos on prendra T=1s pour le temps d'enregistrement de la photo, T=2s pour le temps de traitement "anti yeux rouges", T=4s pour le temps de traitement automatique des niveaux... Et sur un périmètre de cas "typiques" on mesurera alors les temps de réponse et on les classera dans la catégorie satisfaits ou acceptables et on pourra calculer un unique indice entre 0 et 1, représentant globalement l'expérience de l'utilisateur vis à vis des performances du système.

Si toutes les mesures sont acceptables mais aucune est satisfaisante, vous aurez un indice de 0.5. Donc en dessous de 0.5 les performances sont clairement mauvaises, entre 0.5 et 0.7 elles sont faibles, entre 0.7 et 0.85 elles sont correctes et au delà de 0.85 on peut les considérer comme bonnes. Bien sur ceci est un modèle qui a besoin d'être calibré en fonction de votre contexte !

La valeur ajoutée de la MOA dans ce cas est donc de bien cadrer les contours du problème, définir les exigences non fonctionnelles. Et pour finir la MOA doit avoir le recul nécessaire pour ne pas remonter les critiques des utilisateurs telles quelles, et pour s'assurer que les efforts fournis iront dans le sens de la valeur optimale pour le système. 

lundi, juin 11 2012

Comment la MOA peut-elle obtenir l'adhésion des utilisateurs sans vendre son âme au diable ?

Par Olivier Durand le lundi, juin 11 2012, 23:16

L'accompagnement du changement (plutôt que la conduite) n'est pas l'épilogue d'un projet. C'est une démarche qui s'exécute sur toute la durée d'un projet. Comment la MOA peut-elle obtenir l'adhésion des utilisateurs sans vendre son âme au diable ?

Définir sa stratégie, ses objectifs

En fonction de la dimension du changement (à l'échelle d'une application, d'un process, d'une organisation, de l'entreprise) et en fonction de la criticité de l'adhésion des utilisateurs finaux pour la réussite du projet, les exigences de l'accompagnement du changement ne seront pas les mêmes. Il est donc important de bien identifier la nature du changement pour identifier la bonne stratégie à adopter. Le déploiement worldwide d'une nouvelle application métier dans le but d'améliorer la qualité d'un processus ou la modification d'un processus métier pour optimiser les coûts avec des réductions d'effectifs ne seront pas gérés de la même manière.

Impliquer les utilisateurs en amont

L'accompagnement du changement ne se fait pas à la fin du projet, comme une cerise sur le gâteau. C'est un facteur clé de la réussite qui se négocie dès le début du projet. Plus les utilisateurs sont inclus tôt dans le projet, moins vous risquez le syndrome du "NIH". Pour cela, certains utilisateurs clés, appelés parfois les "champions", doivent être embarqués afin de convaincre les autres utilisateurs de l'intérêt du changement. Ces "champions" aiment le risque et prendre des responsabilités supplémentaires ou ont un intérêt personnel à ce que le projet réussisse. Il ne faut pas passer à côté de cette opportunité, un "champion" charismatique permettra de convaincre bien plus de monde que la meilleure des présentations par une équipe projet. 

Utiliser les technologies du 21ème siècle

Pour la phase de formation, pensez à utiliser les outils les plus efficaces : visioconférences, webinar... En ces temps difficiles, oubliez La Première et les grands hôtels. 

Enfin, conservez une fois de plus votre bon sens et vos qualités humaines. Je citerai cet utilisateur qui m'a dit aujourd'hui : "Vous facilitez la communication entre les systèmes, c'est très bien, mais n'oubliez pas de faciliter la vie des humains !". Heureusement, même si je ne suis pas parfait, je suis humain et comprend ses problématiques... tant qu'on ne me remplace pas par un avatar robotique humanoïde...

jeudi, août 25 2011

Comment la MOA peut dépasser la dépression post projet ?

Par Olivier Durand le jeudi, août 25 2011, 22:47

Le baby blues survient entre le deuxième et le quatrième jour après l'accouchement, dure en moyenne deux jours. Une fois l'euphorie de l'aboutissement passée, et les premières mises en pratiques approximatives, on y est. Le projet est terminé. Alors que le stress redescend, comment dépasser la dépression post projet ?

 

Identifiez les réussites et les échecs de ce projet

Indépendamment de l'aspect affectif, cherchez à identifier les réussites et les échecs de ce projet. Pour la MOA, en premier lieu il faut identifier si les exigences ont été remplies. Si vous avez les outils adéquats, vous pouvez analyser les caractéristiques des exigences : ont-elles été volatiles ? combien ont été créées en cours de projet ? est-ce que les priorités ont beaucoup changé ? Et comme les parents trouvent toujours leur progéniture merveilleuse, vous pouvez essayer d'obtenir la perception des utilisateurs sur la réussite du projet. C'est moins quantitatif, mais finalement beaucoup plus objectif ! Attention, si vous recherchez le retour des utilisateurs, attendez que s'écoule quelques jours ou semaines. Les projets débutant en production avec quelques couacs (problèmes lors du déploiement, forte résistance au changement...) peuvent se transformer en réussite totale une fois les tensions des premiers jours passées.

Obtenez des retours sur votre travail

Profitez en également pour identifier comment vous avez participé à ces réussites et ces échecs. N'hésitez pas à solliciter vos sponsors ou vos responsables pour avoir un retour sur votre travail. Quand le projet a atterri, il est plus facile d'obtenir un retour objectif car les différentes parties prenantes ont tous les éléments pour juger votre travail, et ils auront la distance nécessaire. Pensez également à faire un point sur vos méthodes de travail et les techniques de la MOA. Avez vous trop voulu formaliser ? Ou au contraire avez-vous manqué de formalisme ? Étiez-vous à l'aise avec la méthode employée sur le projet ?

Capitalisez sur votre travail

Vous avez réalisé un manuel utilisateur de qualité ? Vous avez amélioré la description de vos use case ? N'hésitez pas à reprendre vos documents afin d'en faire des templates ou des exemples en corrigeant leurs défauts. Cela vous permettra d'une part d'améliorer la qualité de vos livrables au fil du temps et d'autre part de gagner du temps sur votre prochain projet. Vous pouvez ensuite partager vos templates avec les autres MOA de votre société.

Cherchez les projets suivants

Faites un point avec vos sponsors habituels pour voir quels sont les besoins stratégiques qui ne sont pas encore couverts. Faites le tour des utilisateurs également, afin d'identifier des problèmes opérationnels qui ne seraient pas encore remontés.  Le meilleur moyen de travailler sur un projet intéressant, c'est encore d'aller le chercher.

 

La fin d'un projet n'est jamais simple. C'est souvent une phase fortement chargée pour la MOA qui doit gérer la conduite du changement. Il faut être très présent. Et assez rapidement, tout s'arrête. Il faut alors savoir gérer la transition avant le ou les projets suivants. Soyez fort, on passe tous par là, surtout lorsque le projet est une réussite. Bizarrement, plus le projet est un échec, moins on a de mal à s'en défaire...


mardi, mars 2 2010

La MOA est-elle une hôtesse de l'air ?

Par Olivier Durand le mardi, mars 2 2010, 08:20

Le support applicatif métier est difficilement externalisable, contrairement au support sur les applications dites "bureautiques" (gestion des courriers électroniques, traitement de texte...). Plus les applications métiers sont critiques pour l'entreprise, plus l'équipe support applicative doit avoir des profils de haut niveau et des compétences pointues. Ce sont parfois directement les maîtrises d'ouvrage qui exercent le rôle de support applicatif ou support fonctionnel, alors que d'autres organisations mettent en place des équipes dédiées à ce support très proche du métier (équipes que l'on peut considérer alors comme assistance à MOA). La MOA doit donc avoir le sens du service ?

Dans l'article Le « sens du service », une question d'organisation sur scienceshumaines.com l'auteur évoque les travaux d'Arlie Russel Hochschild qui dès 1983, dans The Managed Heart, définit le concept de travail émotionnel pour les hôtesse de l'air consistant à réélaborer leur ressenti et à influer sur celui des passagers, notamment en diffusant un sentiment de sécurité. La maîtrise d'ouvrage serait en fait un steward ou une hôtesse de l'air ? Il est vrai que face à un problème de production important ou face à une forte réticence au changement, la MOA peut avoir ce rôle de travail émotionnel : calmer l'utilisateur si ses craintes ne sont pas fondées, communiquer les informations nécessaires sans créer de panique, et éventuellement expliquer comme accéder aux toboggans de secours si le crash est inévitable !

Ensuite l'auteur de cet article parle des travaux du sociologue américain Ervin Goffman (Asile, 1968) pour définir la compétence de service : la capacité de prendre une décision non prévue par une procédure impérative et de la présenter comme professionnellement justifiée. Une telle décision n'est jamais facile à prendre car elle se prend toujours dans un contexte délicat. Donc plus qu'un sens du service commun une MOA doit avoir cette "compétence de service" afin d'être capable de réagir à des problèmes variés qui attendent des solutions spécifiques.

La notion de support informatique est souvent mal perçue car caricaturée en un centre de service outsourcé en Inde, en Afrique du Nord ou en Irlande, où les opérateurs de ces helpdesks sont notoirement incapables de résoudre un problème, ni même souvent de le comprendre. La faute sûrement aux grands opérateurs télécoms qui ont souvent eu des démarches assez radicales en terme d'outsourcing de ces services. Pourtant faire du support applicatif ou fonctionnel sur des applications très critiques demande des compétences pointues sur le domaine géré et également une grande compétence de service. Il me semble également qu'il est toujours bon pour une MOA même si elle est orientée projet d'être au contact de la production et de ses réalités de terrain, cela permettant de concevoir des solutions fonctionnellement adaptées à la réalité.