Blog

Blog

Aide au pilotage de projets

AMJ GROUPE peut apporter son assistance à la maîtrise d’œuvre ou à la maîtrise d’ouvrage dans le domaine du suivi et pilotage de projets.

Dans ce cadre, AMJ GROUPE peut participer à l’organisation et mise en place de la structure de suivi et pilotage, ainsi qu’à l’élaboration du plan d’assurance qualité du projet ainsi que des plannings et budgets prévisionnels.

Ensuite, AMJ GROUPE peut assurer l’organisation des points d’avancement ce qui comporte notamment la préparation des ordres du jour, l’animation des réunions et la rédaction des comptes rendus de réunion.

AMJ GROUPE peut également préparer les éléments nécessaires aux comités de pilotage du projet et en assurer l’animation si besoin.

Au fil de l’avancement du projet, AMJ GROUPE peut prendre en charge la tenue du planning ainsi que le suivi de tout ou partie du budget du projet.

Enfin, AMJ GROUPE peut élaborer les différents reportings de suivi d’avancement, de suivi des charges, faits marquants, risques,….

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).

Comment trouver un prestataire au meilleur prix ?

Comment choisir un prestataire de développement ou de maintenance d’applications au forfait. Bien sûr nous possédons tous des processus de sélection de prestataires avec des grilles d’évaluation bien précises. Cependant, il est clair qu’avec l’expérience, les prestataires se sont habitués à répondre aux exigences toujours plus élevées en matière d’appels d’offres.

Aujourd’hui, dans un marché devenu extrêmement concurrentiel, force est de constater que certains prestataires pratiquent des prix particulièrement bas avec des offres particulièrement bien construites, ce qui dans toutes les grilles de sélection permet généralement d’être retenu à tous les coups.  La meilleure qualité au plus bas prix ! Qui résisterait à une telle proposition ?

Malheureusement, il n’y a pas de miracle et il est impossible d’obtenir le top de la qualité avec le prix le plus bas. La qualité, cela à toujours un coût minimum.

Ce type d’offre présage généralement de conflits ultérieurs importants entre le commanditaire et son fournisseur. En effet, d’une manière ou d’une autre, le prestataire retenu va chercher par tous les moyens à rattraper l’écart qui existe entre le prix qu’il a pratiqué et le niveau de qualité qu’il a promis. A titre d’exemple, j’ai encore récemment vu des prestataires de maintenance réduire au maximum leurs coûts de maintenance corrective et leurs coûts unitaires de maintenance évolutive mais multiplier par trois leurs estimations de charges de développement après avoir été retenus.

Bien entendu, il ne s’agissait pas de la maintenance du logiciel de gestion commerciale de la PME du coin de la rue. Il s’agissait d’un contrat de maintenance de plusieurs applications au sein d’un grand groupe international.

Ceci n’est qu’un exemple, et les astuces et moyens des prestataires pour se rattraper sont légion.

D’autres prestataires n’hésitent pas à promettre des livraisons dans des délais qui sont tout simplement irréalisables. Là également, les conflits sont souvent nombreux et les déceptions importantes…

C’est la raison pour laquelle, AMJ-groupe procède systématiquement à une estimation des charges et délais. Cela permet en effet de déterminer ce qui semble être un coût raisonnable dans un délai réaliste. De plus, AMJ-groupe possède ses grilles spécifiques d’évaluation qui tiennent compte de ces éléments.

Enfin, dès l’appel d’offres, AMJ-groupe intègre des critères de qualité de la prestation attendue ainsi que des éléments de pilotage et de contrôle.

Un référentiel d’audit, pour quoi faire ?

Lors de mes différentes missions de conseil, il m’arrive souvent de prendre connaissance de divers rapports d’audit. Force est de constater que peu de rapports répondent réellement à ce que l’on pourrait qualifier de « Rapport d’audit ». En effet, la technique de l’audit informatique relève d’une démarche très précise. De nombreuses personnes confondent souvent diagnostic et audit voire même audit et rédaction de cahier des charges.

Le succès d’une mission d’audit dépend du respect d’un certain nombre de points. Parmi ces points, il en existe un en particulier qui me semble essentiel, à savoir le référentiel d’audit.

En effet, dans le cadre d’une mission d’audit, il est notamment nécessaire d’examiner et de contrôler la mise en œuvre de procédures qu’elles soient internes ou externes, ou le respect de normes.

Dans la pratique, l’expérience montre que les procédures sont souvent incomplètes et parfois mêmes inexistantes.

L’auditeur est aussi parfois amené à détecter l’origine d’un problème connu et à fournir des recommandations.

Dans tous les cas, l’auditeur doit être en mesure d’indiquer les procédures qui devraient exister et être appliquées afin de permettre d’améliorer la situation existante.

Le premier réflexe naturel de l’auditeur est de se baser sur son expérience et le bon sens afin de déterminer ce qui devrait exister.

Bien entendu, le réflexe de l’audité sera de démontrer qu’il travaille bien et que les propositions avancées par l’auditeur ne sont pas fondées et sont donc inutiles ou ne sont pas les bonnes.

L’informatique est un monde d’ingénierie dont les différents aspects sont régis par des règles bien spécifiques. Il est toujours possible de ne pas respecter certaines des règles. Par exemple : il est possible de mener a bien un projet informatique sans tenir de planning. Il est aussi possible de développer une application informatique qui fonctionne sans respecter aucune norme de codage. Avec un peu de chance, il se peut que les travaux se déroulent correctement.

Moins on se repose sur des règles et procédures plus les risques de problèmes et d’échecs sont importants.

Evidemment, plus on souhaite que les travaux se déroulent correctement, plus il est nécessaire de se conformer aux règles de l’art.

Si l’expérience et le bon sens sont bien évidemment des éléments importants dans les missions d’audit, ils sont loin d’être suffisants et c’est ici qu’intervient la notion de référentiel d’audit.

Un référentiel d’audit correspond à un recueil de règles, procédures et/ou bonnes pratiques reconnues au plan international et sur lequel l’auditeur pourra s’appuyer pour formuler ses recommandations. Dans le domaine de l’informatique, il en existe notamment deux qui sont particulièrement répandus, à savoir COBIT et ITIL.

Pour certains domaines informatiques bien spécifiques, il est également possible de s’appuyer sur des référentiels plus ciblés tels que par exemple l’ISO/CEI 27000 pour la sécurité de l’information.

Ces éléments permettent ainsi à l’auditeur de renforcer considérablement la pertinence de ses recommandations.

Maintenant, il est clair qu’il ne s’agit pas de prendre l’état de l’art pour le recommander au client. Il existe différents degrés de mise en œuvre que l’auditeur expérimenté saura déterminer de façon pertinente par rapport au contexte de son client.

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.

Retour en haut