Aller directement à la fin des métadonnées
Aller au début des métadonnées

Vous regardez une version antérieure (v. /wiki/spaces/UDI112/pages/11220975659/Principes+et+concepts) de cette page.

afficher les différences afficher l'historique de la page

Vous regardez la version actuelle de cette page. (v. 1) Actuel »

Référentiels de la gestion de projet

Le « Project Management Institute »

Créé en 1969 aux Etats-Unis, c'est la première association à but non lucratif à définir un référentiel en matière de gestion de projet, à recenser les bonnes pratiques et à publier un guide.
5 fondateurs sont à l'origine du PMI qui réunit théoriciens et praticiens de la gestion de projet. Leur première publication est un rapport qui sort en 1983 et qui identifie et recense les bonnes pratiques.
Il publie finalement un guide « le PMBOK » Project Management Body of Knowledge dont la première version date de 1987.

Le PMBOK est normalisé par le IEEE « Institut of Electrical and Electronics Engineers » et est un standard de l'ANSI « American National Standards Institute ».

Une orientation « processus »

Tout en favorisant l'usage d'un champ lexical partagé, le PMBOK identifie 5 groupes de processus qui composent la gestion de projet :

  1. Processus de démarrage

  2. Processus de planification

  3. Processus d'exécution

  4. Processus de surveillance et de maîtrise

  5. Processus de clôture

L'aitiographie

Ce terme est évoqué dans les normes NF X50-109 Décembre 1991 : Management de projet - Recommandations pour l'analyse et la modélisation graphique d'actions et son utilisation pour une meilleure communication entre les acteurs d'un projet. Il ne semble pas référencé dans le dictionnaire mais il a pour vocation de mettre en lumière une démarche structurante, se définissant comme "technique de schématisation pour représenter graphiquement les actions, selon leurs constituants, leurs moyens, et leurs produits, quelle que soit la complexité de leurs interactions".
norme X50-109 Décembre 1991 : Management de projet - Recommandations pour l'analyse et la modélisation graphique d'actions et son utilisation pour une meilleure communication entre les acteurs d'un projet –

Affaire ou projet ?

L'étymologie du mot projet :
[…vient du latin, des racines de « pro » qui signifie en avant et « jacere » qui signifie jeter…]
La norme ISO 10006 définit un projet comme :
[…« un processus unique qui consiste en un ensemble d'activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans le but d'atteindre un objectif conforme à des exigences spécifiques, incluant les contraintes de délais, de coûts et de ressource »…]
Nous pouvons retenir que le projet implique une certaines pensée abstraite nécessaire pour conceptualiser des objectifs.
L'étymologie du mot affaire :
[…vient de « à » et « faire »…]
Le mot affaire n'est pas définit dans un référentiel ISO, mais voici quelques usages courants :

  • Chose dont on doit s'occuper, à faire

  • Ce qui est le sujet de quelque occupation

  • Ce qui est sujet de quelques préoccupations

  • toutes les choses qu'on a à discuter, à démêler avec quelqu'un dans le commerce de la vie.

  • Convention ; marché ; traité ; transaction commerciale ; entreprise d'industrie ; spéculation financière.

  • Cas traité par la justice

  • Effets personnels

Est aussi un terme général que l'on substitue souvent dans le langage ordinaire à des termes propres et particuliers. Il s'emploie ainsi dans des significations très diverses et quelquefois dans des sens opposés qu'il est impossible d'indiquer tous.
Nous pouvons retenir que l'affaire est plus objective, en lien avec davantage de matérialité, aux choses.
Ainsi, l'utilisation du mot projet ou affaire dans l'entreprise se joue sur une nuance qui pourrait par réduction, être le degré d'incertitude : l'incertitude est décroissante avec la matérialité et la répétition des évènements.



Première illustration d'une catégorisation projets-affaire dans une approche « cycle de vie » d'un produit, d'un service ou d'une entreprise :

Le second facteur d'incertitude, toujours lié au savoir, est lié à la fréquence de confrontation à différentes situations : cela peut se traduire dans le métier de l'entreprise et du type de projet rencontré.
Ainsi, il serait possible interpréter la gestion à l'affaire comme une gestion de projet s'intégrant dans la posture de la relation commerciale, que ce soit du côté de la vente ou de l'acquisition. Ainsi, un projet réalisé en interne garderait sa terminologie de projet. Un projet acheté prendrait alors la terminologie d'affaire. En regardant cela sous l'angle du cycle d'exploitation ou hors exploitation, on peut proposer le tableau suivant :

Les enjeux de la gestion à l'affaire

Une lecture transverse

L'affaire concerne plusieurs modes d'organisation, sur l'ensemble de la chaine de valeur et voit intervenir de multiples acteurs et de multiples solutions informatiques :

Dans une approche CODP, le positionnement projet / affaire pourrait ainsi se dessiner comme suit :

En synthèse, une affaire dure quelques jours à quelques années et voit intervenir beaucoup d'acteurs internes et externes. La gestion à l'affaire est une coordination d'activités, mobilisant des compétences multiples et des ressources matérielles, financières, et informationnelles variées.

Les enjeux

Les dysfonctionnements souvent identifiés

La planification d'affaires

De manière générale, la planification est une discipline qui se décompose sur plusieurs étages :

  • Une planification stratégique consistant à identifier des jalons clés et à estimer globalement des coûts. La granularité est importante (+/- 30%).

  • Une planification opérationnelle qui consistera à positionner des tâches de lots de travaux les unes par rapport dans le temps, selon leur durée et leur relation les unes par rapport aux autres et à affiner les budgets. La granularité est plus faible (+/- 10%).

  • L'affectation des ressources permet d'assurer la faisabilité des lots de travaux en contrôlant les surexploitations des collaborateurs et des matériels.

  • Le pilotage consiste à suivre et à s'assurer de l'atteinte des objectifs et ce en matière de délais et de coûts.

Planifier nécessitera donc une identification des buts à atteindre ou encore des livrables, des moyens financiers alloués, de définir les activités à accomplir, les tâches à réaliser et d'en estimer les durées et les ressources en vue d'un calendrier à tenir. Pour réaliser cette planification, la structuration de l'affaire/projet est le préalable : pour ce faire, les bonnes pratiques invitent à opérer un découpage cohérent. Ce découpage prend la forme d'arborescences qui représent les réponses aux questions de mise en œuvre du projet.

Les arborescences d'un projet

Parmi les bonnes pratiques, la décomposition arborescente est une des plus conséquente : l'expression anglo-saxonne « Breakdown structure » est très rependue.
Le concept de « breakdown structure » a été développé par le département américain de la Défense (United States Department of Defense), pour piloter la mise au point du programme de missile Polaris en 1957 dans la Marine. Même si le terme n'était à l'époque pas employé, il constitue la première application d'une décomposition hiérarchique axée sur les tâches et activités à produire pour atteindre les livrables (résultats) voulus. C'est en 1962 que la NASA et l'industrie aéronautique publient un article qui décrit l'approche « breakdown structure ». En 1968, le département américain de la Défense publie une notice définissant l'utilisation de cette méthode de projet dans l'industrie aéronautique. En 1987, le Project Management Institute a repris ce concept pour le généraliser à l'ensemble des industries dans son ouvrage de référence "Project Management Body of Knowledge" (PMBOK).
En fait, les arborescences doivent répondre à plusieurs questions dont les principales sont les quatre suivantes :

  1. Quoi faire => PBS (Product Breakdown Structure)

  2. Comment faire => WBS (Work Breakdown Structure)

  3. Qui doit le faire => OBS (Organization Breakdown Structure)

  4. Pour combien => CBS (Cost Breakdown Structure)

On retrouve d'autres travaux dans différentes méthodes de gestion de projet, mais toutes exploitent l'idée générique d'une structuration arborescente ou encore de découpage en Breakdown Structure jusqu'à une granularité saisissable, organisable, planifiable.
Selon la phase du projet, ces arborescences prennent tout leur sens
Par exemple, pour qualifier et explorer le projet, on parlera aussi des :

  • FBS => Functions Breakdown Structure => découpage en fonction qui doivent être assurée ?

  • SBS => System Breakdown Structure => quelle serait l'architecture du système ?

  • GBS ou ZBS => Geographic ou Zone Breakdown Structure => les lieux concernés par le projet ?

  • ABS => Activity Breakdown Structure

Selon le projet, toutes les arborescences ne sont pas indispensables, même si toutes ont vocation à être reliées entre-elles !
L'une d'entre elle reste toutefois centrale dans la structuration de l'affaire : la WBS.

Introduction à l'exploitation de la GDAI de Divalto infinity

La structuration des arborescences est un enjeu majeur de la planification, du suivi et de l'appréhension de l'affaire.
La GDAI de Divalto infinity permet d'exploiter ces notions fondamentales de structures arborescentes en les prolongeant avec les fonctionnalités déjà connues de l'ERP :

  • Lien avec la base article pour les approvisionnements et le CBN ;

  • Lien avec la gestion commerciale pour piloter les différentes typologies de flux ;

  • Lien avec la CRM pour disposer de l'imputation d'évènements ;

  • Exploitation des fichiers joints dans une optique de partage documentaire ;

  • Lien avec la gestion de production pour exploiter les données techniques et piloter les OFs ;

  • Nouvelle présentation arborescente des informations ;

  • Nouveau Gantt pour projeter les éléments et les activités sur un mode Diagramme ;

  • Un CBA pour assister à la gestion des approvisionnements et des réservations perfectionnant ainsi l'outil de supervision des réservations ;

  • Une nouvelle approche budgétaire qui devient le point d'appui des offres et de la facturation et référentiel du contrôle de gestion ;

  • Des nouveaux écrans dédiés à la saisie des temps et leur supervision ;

  • Des traitements dédiés aux déclarations du « reste à faire » ;

  • Des fonctionnalités d'exploitation et de génération de données techniques propres ;

  • Des nouveaux KPI standards.

Tous les liens avec les fonctions traditionnelles de l'ERP sont accessibles à partir les éléments des arborescences.
Toutefois, le GDAI s'appuie sur les affaires existantes et les deux modes d'exploitation peuvent cohabiter sur certains périmètres :

  • le zoom affaire avec les données structurantes de l'affaire est commun ;

  • les collaborateurs, les activités, le code affaire présent partout dans l'ERP par exemple sont exploités en commun ;

  • les tableaux de bord avec les chiffres clés ont été perfectionnés pour tenir compte des données singulières à la GDAI ;

  • Le paramétrage dossier se voit renforcé d'un onglet dédié GDAI.

Principes généraux et limites de la GDAI

L'affaire se caractérise aussi par son unicité ou quasi-unicité. Ainsi certains réflexes issus des modes d'organisations impliquant des volumes plus importants, ne sont plus efficients. Notamment la codification d'articles Produits-fini…et donc l'exploitation des fonctionnalités logistiques usuelles de Divalto infinity.
La GDAI ne présente pas les fonctionnalités suivantes à ce jour :

  • Pas de pilotage de trésorerie à l'affaire ;

    • Pas d'analyse de la facturation potentielle

    • Pas de visualisation à date des flux

  • Pas de configurateur au sens stricte du terme ;

    • Pas de spécification de règles métiers

  • Pas d'éléments d'arborescence géré par l'inter-compagnie ;

    • Pas de découpage d'une WBS par dossier ou établissement

    • Pas de flux automatisé pour ce type de découpage

  • Pas de sous-traitance dédiée autre que celle des OFs ;

  • Pas de lien automatique avec la GRM/Gestion de la qualité/contrôle

    • Pas de remonté ou d'accès direct de ces modules

      • Interventions d'un ordre de maintenance

      • Constats qualité

  • Pas de fonctionnalités purement axées SAV

    • Pas de génération de contrat à partir d'une affaire

    • Pas de lien de nomenclatures dédiés SAV

  • Pas d'exploitation avec des outils de mobilité

    • A noter toutefois une saisie des temps à partir de weavy

    • Pas de saisie des temps en mobilité pour chantier

  • Pas de génération automatique d'écritures d'encours en comptabilité

    • Pas de reconnaissance de CA

    • Pas de redescente d'écriture comptable dans les outils de synthèse ou de récapitulatif budgétaire

  • Pas de tarifs :

    • pour les matériels

      • Pas de fonctionnalité native de gestion des locations

      • Pas de déclaration des temps sur matériel

    • Pour les activités

      • Pas de tarifs d'activités par client

  • Pas d'outil graphique d'association des ressources aux activités

    • Pas de lien standard avec MS project ou un autre outil de planification

    • Pas de moteur de lissage automatique

    • Pas de d'ordonnancement fin des tâches des collaborateurs

  • Pas d'outil de répartition des besoins et des activités d'une arborescence vers une autre

  • Pas d'outil pour la facturation « compteur »







  • Aucune étiquette