Projet

Projet

Assistance à maîtrise d’ouvrage

Assistance à maîtrise d'ouvrage

Vous avez besoin d’assistance dans la mise en place de vos systèmes d’information ? Le pôle consulting d’AMJ GROUPE vous propose une assistance à maîtrise d’ouvrage (AMOA).

La raison d’être de cette activité est d’assister la Maîtrise d’ouvrage face à la Maîtrise d’œuvre dans les domaines suivants :

Les différentes prestations d’assistance à maîtrise d’ouvrage (AMOA)

A ce titre, AMJ GROUPE assure les entretiens et réunions de groupes de travail nécessaires pour permettre de recueillir les besoins. A l’issue de chaque entretien/ réunion, un compte rendu est rédigé. Il est ensuite soumis à la validation des participants et contribue à l’élaboration du recueil des besoins. A partir de l’analyse de ces éléments et des divers documents récupérés AMJ GROUPE, assure la rédaction du cahier des charges.

Les divers documents sont rédigés dans le respect de la charte de rédaction d’AMJ GROUPE. Par ailleurs les tâches sont exécutées conformément à la démarche d’assistance à maîtrise d’ouvrage d’AMJ GROUPE.

Une fois validé, ce document sert notamment de base à l’élaboration des cas de test qui seront utilisés lors de la recette. AMJ GROUPE rédige ainsi le cahier de recette et peut ensuite effectuer tout ou partie de l’exécution des cas de recette.

Si besoin, AMJ GROUPE peut prendre en charge la rédaction de la documentation utilisateurs. A ce stade et compte tenu de la connaissance fonctionnelle d’AMJ GROUPE, nous prenons généralement aussi en charge les formations des utilisateurs.

En parallèle, AMJ GROUPE peut également assurer le suivi et pilotage de l’ensemble du projet pour le compte de la maîtrise d’ouvrage.

Enfin, AMJ GROUPE peut assurer la communication et la conduite du changement auprès des utilisateurs concernés.

Nous pouvons cibler notre intervention sur un domaine particulier comme par exemple la rédaction de cahier des charges ou de cahiers de recette. Nous pouvons également couvrir l’ensemble des travaux de type assistance à maitrise d’ouvrage : du recueil des besoins à la recette en incluant une participation au pilotage de vos projets.

Construire son analytique

La gestion analytique

La gestion analytique est aujourd’hui devenue un élément incontournable afin de piloter l’activité d’une entreprise.

Auparavant, les entreprises se contentaient souvent de démultiplier les comptes au sein de leur plan comptable afin de réaliser une gestion pseudo-analytique. Cela avait pour effet de disposer d’un plan composé d’une multitude de comptes et pouvait générer les problèmes suivants :

  • suivi analytique long et fastidieux par regroupement des totaux de comptes,
  • suivi de la balance des comptes complexe.

Actuellement, il est acquis que la comptabilité analytique doit être séparée de la comptabilité générale, de par la création d’axes analytiques, composés de centres analytiques. Ainsi, lors de la saisie des mouvements, pour chaque compte général utilisé en analytique, un ou plusieurs centres analytiques sont renseignés, de manière manuelle ou automatique, selon les paramétrages effectués.

Les comptes généraux utilisés en analytique sont généralement les comptes de charges et produits. En effet, une analyse sur l’ensemble de ces comptes permet de faire ressortir des résultats selon les critères souhaités (service, affaire, etc.).

Afin de définir au mieux l’analytique à mettre en place au sein d’une entreprise, il est nécessaire de se projeter sur les résultats escomptés. En effet, il est préférable de réaliser en premier lieu une maquette des états souhaités. Cela permet de :

  • visualiser au mieux les différents axes de restitution envisagés,
  • effectuer le tri parmi ces axes analytiques, afin de conserver les axes les plus pertinents,
  • regrouper les critères analytiques qui peuvent être associés, en tenant compte des contraintes des applications de gestion existantes. Par exemple, dans le cas où un axe analytique serait composé de 2 critères (département/service), il convient de s’assurer que les éditions dans les différentes applications de gestion de l’entreprise sont en mesure d’effectuer des regroupements et sous-totaux suivant l’un ou l’autre de ces critères.

Cela permet d’éviter l’erreur classique consistant à vouloir gérer trop d’axes analytiques (par exemple, par service, par projet, par zone géographique, etc.). Cela rend la saisie des mouvements très lourde et, de plus, ces informations ne s’avèrent pas toutes utiles pour l’entreprise.

L’imputation

Une fois que les axes analytiques ont été déterminés, il s’agit de s’assurer que la saisie des centres analytiques au sein des différentes applications de gestion soit possible dans tous les cas de figure. Par exemple, pour certains comptes de charges, il n’est pas toujours possible d’imputer directement une facture d’électricité sur un centre analytique donné. Il est alors  nécessaire d’effectuer une répartition suivant divers critères pré déterminés, ce qui peut s’avérer complexe. Dans ce cas, il est parfois préférable de gérer certains axes analytiques uniquement sur des comptes de ventes.

Il s’agit également de s’assurer que l’analytique choisie soit compatible avec toutes les applications de gestion concernées (paie, gestion commerciale, comptabilité immobilisations). Dans ce cas, une étude doit être réalisée dans le but d’une harmonisation de l’analytique au sein de celles-ci. Cette étude doit notamment aborder le sujet de la codification, qui doit tenir compte des contraintes relatives à chaque application.

En termes de codification analytique, il convient d’ajouter qu’elle doit faire l’objet d’une analyse approfondie. Celle-ci permet de déterminer notamment le nombre de caractères requis pour chaque critère d’analyse au sein d’un axe analytique (par exemple : 3 caractères pour le département et 2 caractères pour le service).

Enjeux des recettes

Tampon2

L’activité de recette est une activité particulièrement sensible dans un projet car son objectif est de définir le niveau de  qualité des produits livrés par rapport à un seuil d’acceptation défini dans un cahier des charges. En effet, pour mesurer, il faut un objet à mesurer (le logiciel développé), un outil de mesure (le cahier de recettes) et une référence pour la mesure (le cahier des charges).

Bien entendu, ce cahier des charges aura notamment intégré les critères de qualité de la norme ISO qui permettent d’évaluer la qualité des logiciels.

La recette consiste à apporter en quelques sortes une certification de la qualité. Comme toute activité d’évaluation, elle doit reposer sur une méthodologie éprouvée et être exécutée avec une très grande rigueur.

Les principaux risques

Les principaux risques liés au fait de ne pas formaliser les tests de recette sont les suivants :

  • passer l’essentiel du temps à tester des cas qui ne seront qu’exceptionnellement exécutés par les utilisateurs alors que les cas métiers les plus fréquents seront peu ou pas testés. Parfois, le désir de vouloir trouver les anomalies conduit à tester des séries de cas particuliers/ exceptionnels au détriment des cas d’utilisation usuels des utilisateurs. On récupère alors une application qui traite très bien les 20% de cas les plus rares alors qu’elle plante sur les 80% de cas les plus couramment utilisés.
  • mal répartir les cas de test et oublier des domaines importants. La formalisation des tests permet de s’assurer que tous les domaines du cahier des charges sont bien couverts.
  • être dans l’incapacité d’expliquer aux équipes de développement les conditions dans lesquelles les dysfonctionnements constatés sont apparus. Il est essentiel pour les développeurs de connaître les caractéristiques précises de survenance des anomalies. Une recette bien formalisée permet de tracer ces éléments dans des fiches dédiées ce qui représente un gain de temps considérable dans le diagnostic de l’origine du problème.
  • refaire plusieurs fois les mêmes cas de recette au sein d’une même session de recette. En effet, lorsque les cas ne sont pas écrits et si la recette dure ne serait ce que quelques heures, il est fort possible que les mêmes cas soient exécutés plusieurs fois. En effet, la personne en charge de la recette ne saura plus forcément si tel ou tel cas précis a été exécuté ou non. Cela a un double inconvénient : perte de temps au détriment d’autres cas qui ne seront probablement pas exécutés.

Dans l’idéal, pour ne pas négliger les phases de recette, qui se trouvent souvent sur le chemin critique, il faut les anticiper suffisamment à l’avance et donc les planifier dès le début du projet. Dans la pratique, il est possible de commencer à préparer la recette dès la fin de la phase de cahier des charges.

Attention toutefois, des arbitrages fonctionnels et des précisions sont apportés lors des phases d’analyse et de conception. Ces éléments ont souvent des impacts sur le descriptif des tests à réaliser. Pour ce qui est du cahier de recette, il est donc préférable d’effectuer l’essentiel de la rédaction pendant la phase de développement.

Par contre les travaux d’organisation de la recette seront à effectuer en amont du développement.

Méthodes agiles : la démarche

Sommaire

  1. Méthodes agiles : les enjeux
  2. Méthodes agiles : la démarche
  3. Méthodes agiles : techniques de mise en œuvre
  4. Méthodes agiles : les principales méthodes agiles
  5. Méthodes agiles : les clefs du succès

Valeurs fondatrices

Les méthodes agiles reposent toutes sur des valeurs qui ont été énoncées dans le Manifeste Agile, un texte écrit et signé par 17 experts reconnus pour leurs apports respectifs aux méthodes de développement d’applications informatiques :

  • Priorité des personnes et des interactions sur les procédures et les outils.
    Une équipe soudée et communicante apporte plus que n’importe quelle procédure ou outil.
  • Priorité d’applications opérationnelles sur une documentation exhaustive.
    L’objectif vital est le bon fonctionnement de l’application. La documentation, bien qu’utile, n’est pas un but en soi.
  • Priorité de la collaboration avec le client sur la négociation de contrat.
    Passé l’accord initial, le client doit avant tout être impliqué dans le développement.
  • Priorité de l’acceptation du changement sur la planification.
    Il est nécessaire d’avoir de la flexibilité dans le planning pour être capable d’absorber les évolutions nécessaires.

Ces 4 valeurs sont à mettre en regard des pratiques fréquemment rencontrées lors de la mise en place de méthodes traditionnelles : priorité aux processus et outils, importance de la documentation, respect du contrat à la lettre, planification rigide.

Les méthodes agiles se caractérisent par les éléments suivants :

  • Délivrer rapidement et très fréquemment des versions opérationnelles, pour favoriser un feed-back client permanent
  • Accueillir favorablement le changement
  • Assurer une coopération forte entre client et développeurs
  • Garder un haut niveau de motivation
  • Le fonctionnement de l’application est le premier indicateur du projet
  • Garder un rythme soutenable
  • Viser l’excellence technique et la simplicité
  • Se remettre en cause régulièrement
Retour en haut