Méthodologie Projets (MPRO)
La démarche Projets a été mise en place par le Centre informatique en 2016 sous la responsabilité du PMO (Project management office).
La Méthodologie Projets (MPRO) est appliquée dans le cadre des projets soumis au <COPRO>, développée par la Division des Solutions Métiers (DSM), basée sur HERMES, et en place depuis octobre 2018.
- Bienvenue dans un projet du CI
- Standards des projets du Ci
- Intervenants UNIL dans les projets
- Liste des meetings
- Membre COPIL
- Membre de COMOP
- Intervenant au projet
- Technical Product Owner
- Terminologie et Acronymes
- FAQ
Bienvenue dans un projet du CI
Cette documentation est adressée à toute personne impliquée dans un projet IT du Centre Informatique (DSM) : membres du CI, métiers, externes, ... Elle a pour objectif de fournir les informations nécessaires et suffisantes en fonction de son implication au projet :
Standards des projets du Ci
Afin d’assurer une bonne stratégie de communication, et l’alignement des parties prenantes à cette stratégie de communication, la réalisation d’une documentation autour des standards de communication dans les projets est nécessaire.
De plus, ces informations étant communes à tous les projets, il a été défini qu’une documentation générale serait plus optimale que d’autres solutions.
Cela permettra un alignement de tous les acteurs en présence sur les termes de gestion de projets et d’informatiques réusités ainsi que pour les séances types dans les projets.
Qu’est-ce qu’un projet ?
Wikipedia: « ensemble de tâches interdépendantes à exécuter sur une période déterminée et dans les limites d'un certain coût, qualité et d'autres limitations. »
La gestion de projet a pour objectif de réaliser le projet en respectant le principe « le triangle d’or » (Coûts, Qualité, Délais).
A l’UNIL, les projets sont définis comme :
Un « projet » est un ensemble unique d'activités menées sur une période temporaire qui fournissent un produit, un service ou un résultat unique qui soutiendra la stratégie de l'entreprise.
Un « projet » peut être un projet, un programme (un ensemble de projets interdépendants) ou un portefeuille de projet (un ensemble de projets ou programmes pouvant être interdépendants)
Un projet s’oppose à un processus par nature.
Wikipedia: « Un processus est une série ou un ensemble d’activités qui interagissent pour produire un résultat ; elle peut survenir une seule fois ou être récurrente ou périodique. »
Le cœur de la notion d’un processus est la capacité à répéter les activités pour obtenir le même résultat. Certaines méthodologies de gestion de projet essayent d’optimiser la gestion de projet par le biais de processus ou scénario de gestion comme le fait la méthodologie HERMES choisie à l’UNIL.
A quoi servent les projets ?
Les projets servent à accompagner et soutenir les changements effectués dans l’institution :
Figure 1 : extraite du PMBOK Figure 1-1. Organizational State Transition via a Project
La nature de ces changements peut être variée :
- · Une modification d’une solution informatique existante ;
- · La mise en place d’une nouvelle solution informatique ;
- · La réalisation d’un produit à commercialiser (Un nouvel enseignement) ;
- · La modification d’organisation d’une sous-entité du groupe ;
- · Et beaucoup d’autres changements de nature unique.
Afin d’assurer la bonne réalisation de ces changements ainsi que le bon usage de ces modifications, voici la nature organisationnelle mise en place :
Figure 2 : extraite du PMBOK Figure 1-4. Organizational Project Management
A l’UNIL, cette structure se retrouve de la manière suivante :
- · La stratégie est gérée par la directive 6.10 (en cours de rédaction)
- · Le Portfolio est géré avant le projet, dans la phase de Pré-initialisation.
- · Les projets et programmes sont les phases du projet dictées par Hermès.
- · Les opérations correspondent à la maintenance pouvant amener de petites corrections sans suivi ou de grosses corrections se faisant par le biais de projets ou missions.
Canaux & Moyens de communication
Les canaux et moyens de communication sont divisés en 3 types :
· Push : ou « poussé » en français, les informations mises à disposition des utilisateurs comme un courrier.
· Pull : ou « tiré » en français, les informations que les utilisateurs doivent aller consulter sans en avoir été notifiés, comme un site Web.
· Interactif : les informations mises à disposition des utilisateurs lors d’un échange comme une réunion
La nature, l’impact et les besoins de récepteur de la communication définiront ensemble le type de communication approprié. Ces spécificités seront traitées, le cas échéant, dans le plan de communication du projet.
Note : Dans le cas des communications interactives, il est fortement conseillé de bien faire un accusé de réception du message discuté car nous avons tous des filtres propres à notre expérience de vie qui sont représentés sur ce diagramme par le « Noise » ou « bruit » dans la communication.
Ce quittancement peut être fait en rephrasant l’interlocuteur à l’instant T, ou en demandant un retour sur le PV de séance, ou d’autres méthodes afin d’assurer que nos filtres respectifs n’entrent pas en conflit créant 2 perceptions différentes.
De plus les communications se divisent aussi en 3 niveaux comme indiqué sur la pyramide.
La vision « simplifiée » de ces niveaux pour la gestion de projet est la suivante :
· Stratégique : COPRO
· Tactique : COPIL
· Opérationnel : COMOP
Les Rapports
Les rapports sont communiqués en « push mode », « mode poussé », afin d’assurer que l’information a bien été transmise.
Note : Par défaut, ces rapports, avec les organisations décrites dans ce document, ne nécessitent pas cet effort. Le « pull mode », « mode tiré/consulté », devrait suffire.
Résultat |
Type |
Fréquence |
Responsable |
Destinataire |
Délai |
Rapport d’état du projet ou Newsletter (hors Flash report dans Orchestra) |
Courriel avec du contenue ou une pièce jointe |
Entre Hebdomadaire à Mensuelle |
Chef de projet |
Mandant |
Premier jour ouvrable du mois |
Rapport de phase (Conception) |
Courriel ou COPIL |
Fin de la phase conception |
Chef de projet |
Mandant |
Voir planification |
Procès-Verbal de Tests |
Courriel avec la pièce jointe ou COPIL/COMOP |
Fin des Tests |
QA |
Chef de projet & exploitation |
Voir planification |
Rapport de phase (Réalisation) |
Courriel ou COPIL |
Fin de la phase réalisation |
Chef de projet |
Mandant |
Voir planification |
Évaluation finale du projet |
Courriel avec la pièce jointe |
Fin du projet |
Chef de projet |
Mandant |
Voir planification |
Mesures de communication additionnelles
Les outils informatiques suivants sont utilisés à l’UNIL de manière transverse :
Afin de délivrer le meilleur service aux participants du projet, nous définissions ici des procédures de communication additionnelles afin d’assurer le meilleur engagement des participants tout au long du projet :
Déclencheur |
Nom |
Description |
Participants |
Besoin métier ou management pour une fréquence ou jalon projet |
Newsletter |
Une communication qui peut être soit un courriel soit une notification dans les canaux Teams. Cette information donne un statut du sujet qui permet de garder les acteurs engagés, par exemple lors de la publication d’un document projet. |
CPR & COMOP en support |
Besoin métier |
Formation |
Selon le cas, cela peut être une formation sur le produit ou le cas échéant sur l’organisation définie voir une méthodologie utilisée. |
Métier & CPR ou BA en support |
Besoin métier |
Démo du produit |
Dans une optique de formation légère ou d’engagement et de revue du produit en cours de construction/livraison. |
Dev ou BA ou CPR selon le produit |
Contraintes d’optimisations |
Tests |
Assurer la qualité du produit ou service livré, tout en engageant le métier ce qui permet d’inclure une formation et une habitude au nouveau produit. |
QA & métier & CPR en support |
Revue pour amélioration |
Rétrospective |
Assurer la qualité des prochains projets, sur la base des analyses des expériences du projet qui vient de se finir. |
RETEX (REtour d'Expérience) |
La documentation projet
La manière dont un projet doit être documenté est spécifié dans la méthodologie Hermès. A l’UNIL, notre variante d’HERMES est la DPRO (démarche projet). C’est la MPRO (méthodologie projet) qui définit la documentation projet qui doit être réalisé pendant le projet.
De plus, il existe des modèles de documents projets préremplis.
Le déroulement d’un projet (vue Hermès)
Le déroulement d’un projet (vue PMI compatible avec Hermès et la MPRO UNIL)
Le résumé de cette vue « processus projet » est :
- 1. en 1er lieux définir le périmètre d’objectifs de manière claire
- 2. pour obtenir les activités à réaliser
- 3. séquencer ces activités,
- 4. estimer la charge de chacune des actions
- 5. ce qui donnera un planning avec les dates possibles de livraison
Note : Toutes les autres approches peuvent permettre de confirmer ou d’infirmer cette approche mais elles ne donnent en aucun cas un résultat aussi précis.
Intervenants UNIL dans les projets
L’objectif est de faciliter la compréhension de chacun des responsabilités pour son ou ses rôles dans les projets.
Ces informations complètent celles présentées à la page de bienvenue.
Titres des rôles dans un projet
Cette section donne les acronymes et les titres usités à l’UNIL et sur le marché.
Les rôles projet des intervenants sont définis par Hermès 5.1 et Hermès 2022.
Les rôles programmes des intervenants sont définis par Hermès 5.1 et Hermès 2022.
Ces descriptions des rôles contiennent également les organigrammes standards.
Note : Ce tableau ne fait donc que grouper les acronymes et les titres complet, sans dupliquer les informations déjà disponibles dans la méthodologie Hermès ou d’autres standards disponibles en ligne.
Abréviation |
Titre complet |
Commentaire |
PMO |
Project Management Office(r) ou Portfolio (of project) Management Office(r) |
Hors Hermès Responsable d’assurer le suivi du portfolio via des KPI (résultat) sur la base des bonnes pratiques mises en place (cœur du métier).
|
RSI |
Répondant du Système d’Information |
|
RM |
Responsable métier |
|
MAN |
Mandant |
Rôle Hermès et projet sous d’autres noms type Sponsor |
MAND |
Mandant Délégué |
UNIL spécifique |
CPR ou CdP |
Chef de projet |
Rôle Hermès et marché L’UNIL utilise l’abréviation CPR et le marché CdP. |
RAP |
Responsable applicatif |
UNIL |
CPO |
Chef de Pôle |
UNIL / marché |
GQR |
Gestionnaire de la qualité et des risques |
|
SCPR |
Chef de sous-projet |
Rôle Hermès et marché |
AP |
Assistance de projet |
Rôle Hermès et marché |
DEV |
Développeur |
Rôle Hermès et marché |
PE |
Prestataire externe |
Rôle marché |
QA |
Analyste Qualité / Responsable de Test / Testeur |
Rôle Hermès et marché |
BA |
Business Analyst ou Analyste métiers |
Rôle Hermès et marché |
TPO |
Technical Product Owner |
UNIL. Responsable technique pour les divers produits et/ou applications du Ci (Exploitant) |
AQ |
Analyste Qualité |
Rôle marché |
ARCHI-E |
Architecte d’Entreprise assurant la cohérence du SI |
Rôle marché |
ARCHI-S |
Architecte de solution assurant la cohérence de l’application |
Rôle marché |
MANG |
Mandant du programme |
Rôle Hermès et marché |
CPG |
Chef de programme |
Rôle Hermès et marché |
EP |
Équipe de projet |
Rôle marché |
PAT |
Personnel Administratif et Technique |
UNIL |
CISO |
Chief Information Security Officer |
UNIL et marché |
CMO |
Change management Office(r) |
UNIL et marché |
CM |
Change Manager |
UNIL et marché |
EXP |
Expert Métiers |
UNIL et marché |
BA |
Business Analyst ( |
UNIL et marché |
RACI Projet
Ce RASCI (Responsible, Accountable, Support, Consulted, Informed) se base sur les responsabilités des rôles décris par Hermès et les rôles internes de l’UNIL et sur le processus projet UNIL.
Note : Cette matrice ci-dessous est une vue plus haut niveau complète, donc moins exhaustive et moins exacte, que la vue détaillée mise en place dans la MPRO UNIL. Les colonnes de pré-initialisation et de maintenances (en vert) ne sont pas dans le cycle de vie d’un projet Hermès.
Rôles du projet |
Pre-Initialisation |
Phases du projet |
PLM / Maintenance |
|||
Initialisation |
Conception |
Réalisation |
Déploiement |
|||
PMO |
R |
R (COMINI) & I (Reste) |
I |
I |
I |
R (RETEX), R (Missions) & I (Reste) |
RSI |
C |
I |
I |
I |
I |
I |
RM |
|
R |
C |
I |
I |
|
MAN |
I |
A |
A |
A |
A |
R |
CPR |
S |
R (Sauf COMINI) |
R |
R |
R |
C (RETEX) |
RAP |
C |
C |
C |
I |
I |
C |
CPO |
A |
I |
I |
I |
I |
I |
GQR |
I |
A |
A |
A |
A |
|
SCPR |
I |
R |
R |
R |
R |
|
AP |
|
S |
S |
S |
S |
|
DEV |
|
I |
I |
R |
R |
|
PE |
|
I |
I |
R |
R |
A |
QA |
|
S |
C |
R |
C |
|
BA |
I |
S |
R |
C |
I |
|
TPO |
|
I |
I |
|
I |
C/A |
AQ |
|
C |
C |
C |
C |
|
ARCHI-E |
C |
R |
R |
S |
S |
C |
ARCHI-S |
C |
R |
R |
S |
S |
C |
MANG |
I |
A |
A |
A |
A |
|
CPG |
S |
R |
R |
R |
R |
|
EP |
I |
R |
C |
R |
R |
|
PAT |
S |
S |
S |
S |
S |
I/C |
CISO |
I |
C |
C |
I |
C |
|
CMO |
I |
C |
C |
I |
I |
|
CM |
|
C |
C |
R |
R |
|
RACI
RACI Programme
Ce RASCI (Responsible, Accountable, Support, Consulted, Informed) se base sur les responsabilités des rôles décris par Hermès et les rôles internes de l’UNIL et sur le processus programme UNIL.
|
Phases du programme |
|||
Rôles du projet |
Pre-Initialisation |
Initialisation |
Exécution |
Clôture |
PMO |
C |
I |
I |
I |
RSI |
R |
I |
I |
I |
RM |
|
R |
I |
I |
MAN |
I |
A |
A |
A |
CPR |
S |
R |
R |
R |
RAP |
C |
C |
I |
I |
CPO |
A |
I |
I |
I |
GQR |
I |
A |
A |
A |
SCPR |
I |
R |
R |
R |
AP |
|
S |
S |
S |
DEV |
|
I |
R |
R |
PE |
|
I |
R |
R |
QA |
|
S |
R |
C |
BA |
I |
S |
C |
I |
TPO |
|
I |
|
I |
AQ |
|
C |
C |
C |
ARCHI-E |
C |
R |
S |
S |
ARCHI-S |
C |
R |
S |
S |
MANG |
I |
A |
A |
A |
CPG |
S |
R |
R |
R |
EP |
I |
R |
R |
R |
PAT |
S |
S |
S |
S |
CISO |
I |
C |
I |
C |
CMO |
|
C |
I |
I |
CM |
|
C |
R |
R |
Liste des meetings
COMINI & COPIL pour les libérations de phases
En clôture de la préparation du projet, un COMINI (Comité d'initialisation) est mis en place, en guise de « coordination interne CI », pour l’alignement des membres CI (CISO, chefs de pôles, etc.). Pour les autres phases du projet, c’est le COPIL (Comité de pilotage) qui sert à la validation des fins de phases et la libération des phases suivantes.
Le « Kick-off » est la séance d’engagement de l’équipe projet (tous horizons). Plusieurs formats de ce « kick-off » peuvent être définis selon les besoins ou la complexité.
COPIL intermédiaire
Un COPIL intermédiaire (Comité de pilotage intermédiaire) est une réunion ou un comité qui intervient à un stade spécifique d’un projet ou d’un programme. Il a pour objectif de faire le point sur l’avancement du projet ou du programme. Il permet de vérifier si les jalons et les étapes prévues sont respectés et d’ajuster la stratégie si nécessaire.
L’ordre du jour du COPIL intermédiaire comprend souvent des points tels que l’état d’avancement, les risques et les problèmes identifiés, les décisions à prendre et les actions à entreprendre.
Clôture du projet
Lors de la clôture du projet, la fiche de registre pour la LPD doit être livré avec les autres documents de type exploitation.
NOTE : Le registre va remplacer les FRAT sur le long terme
RETEX pour la clôture complète
Le RETEX est géré par la PMO afin d’obtenir les retours d’expériences sur le projet. C’est une activité « post-mortem » après la clôture du projet.
Le CPR à un rôle important de partage de ses expériences avec l’équipe défini par la PMO lors de cette séance.
Membre COPIL
Bienvenue dans le COMité de PILotage du projet (COPIL)
Cette documentation est une introduction au rôle de membre du COPIL sous la forme de questions/réponses. Des liens sont proposés afin d'approfondir certains concepts de la méthode.
Pour toute information supplémentaire, contactez le Chef de Projet. Bon pilotage de projet !
Comment est structuré le COPIL ?
Le COPIL est composé généralement de 3 à 5 personnes dont :
- du mandant qui dirige le comité
- du chef de projet qui est responsable de la conduite du projet. Il représente le comité opérationnel (COMOP)
- d'un représentant du Centre Informatique (chef de service / division) qui veille à l'alignement technologique du projet (et financier dans le cas où le CI sponsorise le projet)
Le mandant peut également faire appel à des spécialistes, dont le référent métier, de manière permanente ou ponctuelle.
+ sur l'organisation du projet
Quand intervient le COPIL ?
Le COPIL se réunit lors de séances :
- ordinaires, ce sont des jalons décisionnels du projet dont les passages de phases. Ces décisions se basent sur les résultats et la planification fournis par le COMOP.
- extraordinaires, lors d'événements spécifiques au projet (adjudication d'un appel d'offre, choix d'une variante, ...) ou inattendus (changement de périmètre, planning, ...). Ces décisions se basent sur une analyse préalable et une proposition de choix/solutions fournis par le COMOP, des spécialistes, ...
+ sur le déroulement d'un projet
Au démarrage du projet, le COPIL se réunit une première fois pour déterminer les objectifs de la phase l'initialisation et libérer les ressources nécessaires.
Quelles sont les responsabilités du COPIL ?
Le COPIL prend les décisions de pilotage du projet sur la base :
- des résultats et de l'atteinte des objectifs dans le respect des coûts et des délais fixés
- de l'alignement avec la stratégie de l'institution (métier, technologique, légale, ...)
- des ressources à disposition du projet (finances, personnel, infrastructure)
+ sur le rôle de membre du COPIL tel que défini dans Hermes
Membre de COMOP
Bienvenue dans le COMité OPérationnel du projet (COMOP)
Cette documentation est une introduction au rôle de membre de COMOP sous la forme de questions/réponses. Des liens sont proposés afin d'approfondir certains concepts de la méthode.
Pour toute information supplémentaire, contactez le Chef de Projet. Bon projet !
Comment est structuré le projet ?
Le projet est structuré en phases : initialisation, conception, réalisation, déploiement.
Lors de chaque phases, le COMOP produit et évalue les résultats prévus puis planifie les résultats de la phase suivante. En fin de phase, le Chef de Projet fait valider les résultats et la planification par le COPIL.
+ sur le déroulement d'un projet
+ sur l'organisation du projet
Le COMOP réalise périodiquement des séances d'avancement portant le même nom.
Quel est mon rôle ?
Le membre du COMOP est un expert d'un domaine technique ou métier et agit comme référent pour ce domaine.
Le COMOP est responsable de la production et de l'évaluation des résultats du projet.
+ sur les rôles principaux du COMOP et leur tâches
La composition du COMOP peut varier durant le projet. Par exemple il est fréquent que le COMOP soit constitué principalement de Référents Métiers durant la phase d'initialisation.
Quelles sont mes tâches ?
Les tâches du COMOP varient en fonction de l'avancement du projet et incluent :
- l'analyse : besoins métiers/techniques, variantes de solutions, changements et risques, ...
- la production des résultats : documentation métier/technique, systèmes IT, ...
- l'accompagnement : tests, support aux utilisateurs et formations, communication interne/externe au projet, ...
+ sur les résultats d'un projet
Le COMOP peut faire appel à des intervenants pour réaliser des tâches spécifiques. Il en garde cependant la responsabilité en terme d'estimation, de coûts et de qualité.
Quelles sont mes responsabilités ?
Le COMOP est responsable de l'estimation et de la qualité des résultats. Que ces tâches soient réalisées directement ou déléguées.
+ sur l'estimation et planification du projet
Intervenant au projet
Cette documentation est une introduction au rôle d'intervenant d'un projet IT sous la forme de questions/réponses. Des liens sont proposés afin d'approfondir certains concepts de la méthode.
Pour toute information supplémentaire, contactez le Chef de Projet.
Quel est le rôle de l'intervenant dans un projet ?
L'intervenant est un spécialiste qui réalise une tâche spécifique dans le cadre d'un projet.
La nature de son intervention varie selon la phase du projet :
- Initialisation / Conception : analyse métier ou technique, architecture du système, proof-of-concept (POC) / prototypage
- Réalisation : développement, intégration
- Déploiement : formation, support
+ sur le déroulement d'un projet
Comment se déroule une intervention ?
Une intervention se déroule de la manière suivante :
- Un accord est passé entre l'intervenant et l'équipe projet (le COMOP) qui spécifie notamment le périmètre et le délai de réalisation
- L'intervenant réalise la tâche définie sous la supervision d'un membre du COMOP
- Le résultat de l'intervention est validé par le COMOP puis l'accord prend fin
+ sur l'organisation du projet
L'intervenant peut-être externe à l'UNIL. Auquel cas une offre précède l'accord d'achat de la prestation. Le processus suivi est celui des marchés publiques de l'état de Vaud
Technical Product Owner
Cette documentation est une introduction au rôle de Technical Product Owner (TPO). Des liens sont proposés afin d'approfondir certains concepts de la méthode.
Pour toute information supplémentaire, contactez le Chef de Projet.
Quel est le rôle du Technical Product Owner ?
Le Technical Product Owner est responsable de la mise en place de l'exploitation d'une solution du marché. Il assure l'intégration technique, la mise en oeuvre du support opérationnel et de l'exploitation pendant les différentes phases du projet et pour la future exploitation de la solution.
A ce titre, ses responsabilités sont :
- Participer à l’élaboration des résultats du projet dans le respect des délais et des coûts fixés.
- Transmettre les exigences de l’exploitant.
- Assurer sa monté en compétences techniques sur la solution.
- Définir l’architecture technique OU valider l’architecture technique proposée par le producteur (prestataire) ainsi que la réception de la solution.
Comment est impliqué le TPO dans le cadre des projets ?
Il y a 3 scénarios d'implication du TPO dans les projets. Chaque scénario présente le degré de responsabilité vis à vis des livrables d'exploitation du projet sous la forme d'une matrice RACI : Réalisation / Approbateur (valide) / Consulté / Informé.
Scénario 1 : implémentation d'une nouvelle solution
Initialisation | Conception | Réalisation | Déploiement |
Allocation et assignation du TPO (I) |
Elaboration des offres (C) Architecture du système* (C) Concept d'exploitation (A, R) Plan de formation (C) |
Pré-réception (R) Manuel d'exploitation (A, R) |
Mise en service (R) Réception (R) |
* L'architecture du système est approuvée par le Comité de Pilotage (COPIL) en présence d'un représentant du Centre Informatique.
Le chef de projet doit s'assurer de l'allocation d'une ressource en tant que TPO avant la libération du projet (fin de phase d'initialisation). Puis d'accompagner le TPO dans l'élaboration des résultats et dans sa monté en compétence sur la solution.
Note : la charge théorique d'un TPO dans un projet est d'environ 20%. Cette charge peut être réévaluée à chaque fin de phase pour la suivante.
Scénario 2 : évolution d'une solution
Initialisation | Conception | Réalisation | Déploiement |
Etude – exigences d’exploitation (A, C) |
Elaboration des offres (C) |
Pré-réception (R) Manuel d'exploitation (A, R) |
Mise en service (R) Réception (R) |
Scénario 3 : projet technique
Le TPO initie des projets techniques dans le cadre de l'évolution et la maintenance de la solution. Ces projets suivent la méthode simplifiée : mission. Le TPO prend alors le rôle de chef de mission.
Initialisation | Mise en oeuvre | Clôture |
Mandat de mission (A, R) Demande d’achat (A, R) |
Manuel d’exploitation (A, R) |
Appréciation finale de la mission (A, R) |
Comment sont partagés les responsabilités pour l'exploitation de la solution ?
Côté métier un Product Owner (PO), probablement le référent métier durant le projet, est responsable de l’utilisation de l’outil par les utilisateurs ainsi que de son évolution dans le but de répondre aux nouveaux besoins métier. Côté CI, le TPO est responsable du fonctionnement technique de la solution : disponibilité, sécurité/backups, mises à jour, facturation, licences.
Les détails de l'organisation et des processus de l'exploitation sont indiqués dans le concept et le manuel d'exploitation.
Terminologie et Acronymes
Ce chapitre va rappeler les définitions du vocabulaire et des acronymes afin d’avoir un référentiel commun accessible à tous.
Cela permettra dans le temps de lisser des abus de langages éventuels, ainsi que d’aligner la terminologie sur les standards des marchés publiques.
Note : Dans le cas de nouvelles incompréhensions, il faudra mettre à jour ce contenu avec chaque terme dont l’utilisation n’est pas alignée avec la définition du marché afin d’avoir un référentiel UNIL adapté aux besoins internes et en accord les usages des fournisseurs externes.
La terminologie SAP standard est déjà documentée en ligne, pour des raisons d’efficacité, nous ne gardons ce lien comme référence : https://www.system-overload.org/sap/modules.html
Réf. |
Acronyme |
Signification |
Définition |
0 |
HERMES |
Méthode HERMES |
Méthode de gestion de projet suisse. Cette méthode est une copie partielle de la méthode anglaise Prince2. Hermès est principalement utilisé dans les organisations étatiques Suisse. |
1 |
SDP, OTP ou WBS |
organigramme des tâches du projet ou Work Breakdown Structure |
En français, un WBS est la « Structure de répartition du travail ». C’est un organigramme des activités du projet trié par thèmes et/ou départements. La méthode Hermès définis plusieurs scénarios standards qui sont des WBS séquencés. |
2 |
Planning VS Schedule (EN) |
Plan(nification) VS Planning (FR) |
En Français, le « Planning » (organisation/emploi du temps) et le « Schedule » (calendrier/planning) sont le même mot : « planning ». Définitions françaises du mot Planning : · Organisation d'un plan de travail, emploi du temps, programme de travail. · Dans une entreprise, une administration, service chargé d'ordonnancer et de lancer un travail. · Tableau représentant la prévision d'emploi d'un ensemble de personnels ou de machines.
Les différences de signification : · Le « Planning », ou Plan(ning), répond aux questions « quoi ? » et « comment ? ». · Le « Schedule », ou Planning, répond aux questions « qui ? » et « quand ? » |
3 |
KPI |
Key Process Indicator |
Un KPI, ou indicateur de processus clef, est une valeur définie permettant de mesurer une performance et de suivre son évolution dans le temps. Par exemple, l’agilité SCRUM utilisera les points poker assignés aux sujets du Sprint pour mesurer la performance d’une période de réalisation. |
4 |
ROI |
Return on Investment |
Le ROI, retour sur investissement en français, est la valeur attendue des résultats d’un projet. C’est une notion financière qui se veut être calculable. Définition de ROI d’une source Web : « La formule générale du retour sur investissement est : (gains – coûts de l’investissement) / coûts de l’investissement. Dans les faits, le ROI n’est pas toujours calculable directement car certains gains ne sont pas facilement mesurables. Certaines données détaillées ne sont pas (encore) récoltées voir non récoltables. Par exemple : · - Un gain de qualité du logiciel amenant moins de demandes de modification des utilisateurs ; · - Un gain de qualité avec du monitoring assurant une proactivité à maintenir les sites en ligne ; · - Une nouvelle interface graphique plus intuitive réduisant le nombre de demandes de support ; · - Une meilleur communication grâce à un alignement faisant gagner du temps lors des diverses séances ; · - Une page web qui charge plus vite ou une structure des données plus intuitive afin de conserver l’attention des utilisateurs ; - Ou simplement que la perception de différentes personnes permet de ne pas percevoir de ROI sur certains sujets comme la qualité. Ce ROI est défini par le demandeur dans la fiche DESI décrivant la demande de projet sous l’appellation « Valeur ajoutée ». Pour les cas non mesurables, il faut trouver un autre KPI afin de mesurer le gain ou la différence avant la livraison. |
5 |
CSF |
Critical Success Factors |
Les CSF, facteurs critiques de succès, sont les besoins « minimaux » attendu par le demandeur. Ils constituent le cahier des charges minimum. |
6 |
MVS |
Minimum Viable Solution |
Une solution minimale viable est la solution la plus simple (et la moins coûteuse) qui contient néanmoins tous les composants de base identifiés comme nécessaires et peut donc être pilotée efficacement. C’est l’appellation logicielle d’un MVP. |
7 |
MVP |
Minimum Viable Product |
Le MVP est le produit viable minimum. En termes de réalisation, cela signifie que les fonctions minimums à rendre le produit viable sont livrées. Cette notion est clef car elle permet une organisation itérative dans les projets et les maintenances. L’organisation itérative permet de livrer le plus rapidement possible une valeur ajoutée aux utilisateurs. Le MVP est très rarement un « produit final ». Le plus souvent, c’est le produit remplissant uniquement les CSF de la demande initiale ainsi que les contraintes annexes comme la sécurité. Pour donner un exemple plus concret et visuel, le MVP d’une voiture correspond à l’intégrations des pièces du châssis, des roues et du moteurs permettant aux véhicules de fonctionner techniquement selon la demande initiale. Pour autant, ce produit ne peut pas être commercialisé car il ne répond pas aux contraintes additionnelles comme les législations en place par exemple. Pour un logiciel informatique, le MVP serait le site et les fonctions métiers du site. Certaines fonctions de sécurité et d’intégration dans le Système d’information sont à ce stade encore manquant. Le MVP se différencie d’un PoC étant donné que sa réponse est pleine et entières vis-à-vis des critères minimaux de bon fonctionnement. |
8 |
DoR |
Definition of Ready |
Le DoR, définition de prêt (à réaliser), est une liste de vérification des besoins nécessaires à commencer une tâche. Cela assure de ne pas démarrer sans les conditions nécessaires à la réalisation d’une tâche ou activité. |
9 |
DoD |
Definition of Done |
Le DoD, définition de fait (ou réalisé), est une liste de vérification des CSF ou résultats attendus de l’activité. Cela permet d’assurer que l’activité a été réalisée sans oublier de détails importants à la qualité de la livraison. |
10 |
BDD |
Business Driven Development |
Le BDD, développement orienté métier, est un concept de développement informatique ou la réalisation se tourne vers la satisfaction des besoins du métier. L’approche Hermès assigne le métier au rôle de mandant afin d’assurer la satisfaction du métier ; Hermès est donc aligné avec le BDD. |
11 |
TDD |
Test Driven Development |
Le TDD, développement orienté tests, est un concept de développement informatique ou la réalisation se tourne vers la satisfaction des besoins de qualité du livrable en définissant non pas des spécifications métiers mais directement les cas de tests des résultats attendus. Note : Le TDD est totalement compatible avec le BDD. Le TDD permet d’optimiser la charge administrative de la gestion de projet en orientant les spécifications vers la validation des livrables par des tests. Note d’optimisation : Des spécifications métiers de grande qualité vont définir les attentes en incluant les informations de vérifications de ces attentes avec des cas de tests ou des DoD. |
12 |
DDD |
Domain-Driven Design |
Le DDD, conception pilotée ou orientée par le domaine en français, est une technique de conception de logiciel que l’on peut résumer à architecturer la solution afin de représenter le métier et ses processus plutôt que de coder les fonctions du métier dans un bloc. C’est une forme de modularité qui nécessite une architecture technique. |
13 |
QA |
Quality Assurance |
Le QA, assurance qualité, est une notion pour englober l’ensemble des efforts à faire pour assurer la qualité d’un produit ou d’un service : tests, DoD, monitoring ou tout autre mesure. Dans un projet Hermès, le QA se limite aux vérifications de qualité (QC) définis dans le projet, par exemple sur la base des CSF ou des attentes définies par des contraintes extérieures ou internes au projet, du point du vue d’un chef de projet. Un rôle de Gestionnaire de la qualité et des risques a la charge de la qualité transverse du projet. Pour avoir plus de détails, voir le concept de plan de qualité. |
14 |
Sprint |
|
Un Sprint est une unité de temps de réalisation qui se situe entre 1 et 4 semaines. Cette unité soutient la notion de réalisation itérative tout en permettant un contrôle régulier des niveaux d’avancement dans les tâches à faire. Note : Les équipes de développement en interne utilisent des Sprints d’une valeur de 2 semaines. Le pôle projet en interne utilise des Sprints d’une valeur de 1 semaine. |
15 |
RAM (RASCI et RACI ou DACI) |
Responsibility Assignment Matrix |
Le RAM (Responsibility Assignment Matrix) est une matrice d’assignation des rôles et responsabilité de chacun Le RAM est le nom général. Les nom, RASCI et RACI, sont les noms issus des rôles assignés : Note : Il est envisageable d’enrichir cette matrice avec d’autres rôles à préciser. La matrice DACI propose une autre organisation comparable mais moins « populaire/usité » : Pour la comparaison : · Driver = Responsible · Approver = Accountable · Contributor = Support & Consulted · Informed = Informed |
16 |
SPOC |
Single Point of Contact |
Le SPOC est le point d’entrée des communications et demandes selon le contexte. C’est l’entité à charge de trier, filtrer et rediriger les sujets aux bonnes personnes. Le PMO est le SPOC pour les demandes de nouveaux projets. |
17 |
PLM |
Product Lifecycle Management |
La gestion du cycle de vie d’un produit est un cycle en boucle fermé pour la gestion d’un produit. Il part de l’idée en passant par sa conception, sa réalisation, sa mise en service, son support et sa retraite (ou remplacement) qui retombe ensuite sur l’idée. Cette approche intègre la maintenance et le support nécessaire à l’exploitation de la solution à l’inverse du projet qui lui livre des informations à cette phase de maintenance sans être une partie prenante active au bon fonctionnement de cette phase cruciale qui correspond au début de la vérification du ROI du produit réalisé pendant le projet. |
18 |
UaT |
User at Test |
La notion d’UAT signifie qu’aucun produit ne peut être considéré comme validé tant que les utilisateurs finaux n’ont pas fait eux-mêmes les tests d’acceptation du produit et validé par eux même. Le rôle des testeurs est donc d’assurer la qualité du produit avant le passage du métier afin de garder des coûts de qualité maitrisés par l’entité. |
19 |
PBS |
Product Breakdown Structure |
En français un PBS est la « Structure de répartition (des fonctions) du produit ». C’est un organigramme des fonctions du produit trié par thèmes et/ou modules. C’est comparable à un WBS mais sur une vue du produit ou service. |
20 |
ITSM |
Information Technology Service Management |
L’ITSM, la gestion du service IT, représente les bonnes pratiques de gestion d’un département IT. La méthodologie ITIL décrit ces bonnes pratiques en s’orientant sur la maintenance, la qualité du service et l’intégration des projets. ISO-9001 :2015 propose une vue compatible incluant les projets. |
21 |
ITIL |
Information Technology Infrastructure Library |
ITIL est un ensemble de bonnes pratiques conçues pour aider une organisation à tirer une valeur optimale de l'informatique (projets, maintenances et opérations) en alignant les services informatiques sur la stratégie métier. |
22 |
DRP |
Disaster Recovery Plan |
Le DRP, ou plan de secours en français, est le plan de gestion mis en place en cas désastre. Ce plan peut posséder plusieurs scénarii comme la méthodologie HERMES. |
23 |
BCP |
Business Continuity Plan |
Le BCP, ou plan de continuité métier ou des opérations, est le plan de secours utilisé en cas d’évènements non planifiés impactant les services aux utilisateurs finaux. |
24 |
SWOT |
Strength, Weakness, Opportunity & Threat |
Le SWOT est une matrice d’analyse des risques classant les risques selon leurs impacts comme le nom de la méthode le donne : force, faiblesse, opportunités, menaces. |
25 |
MoSCoW |
Must, Should, Could & Would |
La méthode de MoSCoW est une méthode de priorisation selon l’importance : · Must : doit être · Should: devrait être · Could: pourrait être · Would: ne sera pas |
26 |
KISS |
Keep, Improve, Start & Stop |
La méthode KISS permet de prioriser les sujets selon les critères : garder, améliorer, démarrer ou arrêter Note : la matrice KISS est très proche d’une matrice MoSCoW. |
27 |
KISS! |
Keep It Simple, Stupid! |
Le principe de KISS! Est de garder les choses assez simples pour : · Que tout le monde ait accès à l’information (documentation) · Que les sujets soient facilement maintenables (développement) o Eviter de produire de gros blocs logiciels ayant une sur-inflation de fonctionnalités qui pourraient être plusieurs solutions o Eviter de produire des solutions dont seul quelques élus pourront faire la maintenance |
28 |
CRUDE |
Create, Update & Delete |
Un CRUDE est un terme technique signifiant que des opérations sont faites sur les données en base de données. C’est un terme le plus souvent utilisé en BA ou en QA pour définir l’action à développer ou à tester. |
29 |
BDD ou DB |
Base de données ou Data Base en anglais |
Lieu de stockage des données dans un format technique utilisé par les applications. |
30 |
CMS |
Content Management System |
Un gestionnaire de contenu permet de pouvoir facilement créer, éditer, collaborer et publier du contenu digital. |
31 |
ERP |
Enterprise Resources Planning |
Un ERP est un applicatif qui permet de suivre et automatiser les processus de l’entreprise. Pour la gestion de projet, Orchestra est qualifiable d’ERP. |
32 |
Baseline |
Ligne de base |
Cette ligne est une représentation des contraintes initiales du projet (plan et planning) servant de référence afin de pouvoir adapter le pilotage du projet et de rester dans les plans tels que définis, tout en vérifiant que le projet reste dans les marges définies selon son avancement. |
33 |
RT(F)M |
Read The (Fucking) Manuel |
Initialement c’est une boutade de développeur, mais le terme se généralise facilement dans des équipes CI quand les sujets sont bien documentés. |
34 |
Kanban |
Tableau de suivi |
C’est une manière de suivre les activités d’un WBS ainsi que leur statut. Ces activités sont découpées selon leur niveau : · Epic : c’est le niveau le plus haut. Il peut contenir tous les types de cartes. Il est conseiller de ne pas y imbriquer trop d’autres Epics selon le principe KISS ! · User Story : C’est le niveau qui décrit les cas d’utilisations, cela correspond au diagramme UML « Use-Case ». Une user Story ne devrait contenir que des Features et des Tasks · Feature: C’est la fonction à réaliser, elle peut contenir des Tasks. · Task: C’est une action simple à réaliser comme par exemple préparer une base de données. |
35 |
Backlog |
Liste des tâches |
Une liste ordonnée et hiérarchisée des caractéristiques du produit souhaitées par le client et les missions à réaliser par l’équipe. |
36 |
Burn Up/Down chart(s) |
Diagrammes de consommation |
Ce sont 2 représentations de la charge de travail : |
37 |
Release |
Version |
Une Release est une nouvelle version du logiciel apportant ses corrections, modifications ou améliorations. |
38 |
SIPD |
Sûreté de l'information et protection des données |
Ce concept vient de la méthodologie Hermès. Il reprend les notions de DRP voir BCP (CISO UNIL) tout en y intégrant les notions de sécurité. Note : Cette approche groupée reste difficile à appréhendez pour les novices en matières d’ITSM. |
39 |
Agile |
Méthode agile
|
L’agilité est une approche d’organisation d’une équipe de développement centrée sur l'humain et la communication. Ce qui signifie que cette méthodologie possède une dépendance clef à l’application de ses valeurs. Note : Beaucoup des pères fondateurs ont renié le manifeste agile du fait des travers liés aux manques d’applications des valeurs dans les entités. |
40 |
Projet |
|
Un projet est un « one-off » qui possède un début et une fin. Il est unique. Sur deux projets similaires en tout, le 2e est un processus. Dans le cas de différences, le 2e est une variante donc un projet. Note : les scénario Hermès sont des tentatives de conversion de projet « similaires » en processus. Or selon les caractérisations Hermès actuelles, ou les définitions internes, ces scénarios sont au mieux des optimisations pour la gestion de projet. Note : Une optimisation efficace marché est de transformer l’ITSM afin d’avoir les processus nécessaires pour la partie « Run », et de la compléter des cas d’usages de « Build ». Le traitement de la demande suit un processus, la réalisation de la demande elle suit un mode de gestion de projet adapté (Scénario Mission par exemple). |
41 |
Processus |
|
Un processus est une activité répétitive qui est documentée et facile à reproduite et enseigner. Un processus doit pouvoir faire référence au terme « RTFM ». |
42 |
QC |
Quality Control |
Le contrôle qualité est la partie réalisation du QA. Il est donc théoriquement impossible de faire un QC « de qualité » sans avoir fait un QA. Note : le concept de test générique est un QA pour un scénario du type « de développement IT » dans Hermès. |
43 |
MTBF |
Mean Time Between Failure |
« MTBF est le temps écoulé prévu entre les pannes inhérentes d'un système mécanique ou électronique pendant le fonctionnement normal du système. Le MTBF peut être calculé comme la moyenne arithmétique (moyenne) du temps entre les pannes d'un système. Le terme est utilisé pour les systèmes réparables, tandis que le temps moyen jusqu'à panne (MTTF) désigne le temps prévu jusqu'à panne pour un système non réparable. » (Source Wiki) |
44 |
MTTR (1) |
Mean Time To Recovery Repair |
« Le temps moyen de réparation (MTTR (1)) est une mesure de base de la maintenabilité des éléments réparables. Il représente le temps moyen nécessaire pour réparer un composant ou un appareil défaillant. » (Source Wiki) |
45 |
MTTR (2) |
Mean Time To Recovery |
« Le temps moyen de récupération (MTTR (2)) est le temps moyen qu'il faudra à un appareil » ou service « pour se remettre d'une panne. Les exemples de tels dispositifs vont des fusibles à réarmement automatique (dont le MTTR serait très court, probablement quelques secondes), à des systèmes entiers qui doivent être réparés ou remplacés. » comme des applications informatiques (Source Wiki) |
46 |
6 s |
Six Sigma |
« 6 Sigma est une marque déposée de Motorola désignant une méthode structurée de management visant à une amélioration de la qualité et de l'efficacité des processus » (Source Wiki) |
47 |
DPRO |
Directive Projet |
La DPRO est pilotée par la PMO et formalisée à l’aide des directives CI-UNIL. La DPRO formalise l’utilisation d’Hermès comme méthode de projet. |
48 |
MPRO |
Méthode projet |
La MPRO est pilotée par l’équipe DSM-PRO, dans le respect de la DPRO, avec comme objectifs principaux d’augmenter la qualité dans la gestion de projet et de réduire les investissements temporels des chefs de projets dans des tâches répétitives par la mise en place et utilisation de standards de gestion communs. Hermès utilise la notion de scénarii pour trier ces standardisations pour les projets. Note : La MPRO peut aussi être améliorer par le biais de standards plus orientés pour les besoins de l’organisation permanente ; par exemple la manière de mettre en place ou de communiquer avec les outils des projets. |
49 |
PoC ou POC |
Proof of Concept |
Le PoC, « preuve de concept » traduit, ou en français un « prototype », est la maquette permettant de vérifier la viabilité d’une demande. Cette notion permet de découvrir les difficultés, possibilités ou limitations techniques liées à une idée. En informatique, la maquette réalisée sera peu fonctionnelle mais permettra aux équipes de valider la capacité de réalisation et le rendu final à moindre coût que le projet partiel voir entier. |
50 |
EPT, ETP ou FTE |
Equivalent Temps Plein ou Full Time Equivalent |
Cette notion correspond à une charge de travail à 100% selon les normes contractuelles du Fort défini. Pour l’UNIL c’est le Canton de Vaud avec 42h par semaine comme ETP. |
51 |
BPM(N) |
Business Process Model (and Notation) |
C'est-à-dire « modèle de procédé d'affaire et notation », est une méthode de modélisation de processus d'affaires pour décrire les chaînes de valeur et les activités métier d'une organisation sous forme d'une représentation graphique |
52 |
PM |
Project Management |
Management de Projet |
53 |
PV |
Procès-Verbal |
Le compte rendu officiel de la séance est appelé PV. |
54 |
SI ou IS |
Système d’information ou Information System |
Cette notion défini l’ensemble des produits et services nécessaires à la gestion des informations. De nos jours, cela représente la liste des biens et services gérer et fourni par le CI à ses utilisateurs. |
55 |
URL |
Uniform Resource Locator |
Adresse Web (ex. https://www.unil.ch) |
56 |
N/A |
Not Applicable |
Cette notion est utilisée dans la documentation pour qualifier l’inutilité d’un sujet. |
57 |
O(S)FA |
One (Size) Fits All |
C’est une notion d’industrialisation disant qu’un seul produit ou service peut répondre aux besoins de tous. |
58 |
DMS ou GED |
Document Management System ou Gestion Electronique de Document |
Un DMS, ou une GED, est un système informatique proposant un ensemble de fonctions liées à la gestion des documents. De manières non exhaustive, les principales fonctions sont : · Gestion des versions · Processus de validation d’un document · Processus de publication d’un document |
59 |
IHM |
Interface Homme (ou Humain) Machine |
L’IHM est l’ensemble des composant visuels ou autre qui permettent l’interaction entre l’utilisateur et la machine (PC) |
60 |
PC |
Personal computer |
En français, c’est un ordinateur. |
61 |
OS |
Operating System |
L’OS est l’ensemble des composants logiciels permettant l’interaction avec l’ordinateur. Les OS connus sont : Windows, MacOS, Android |
62 |
Projet (simple) |
|
Voir la définition d’un projet (Ref 41) pour le côté général.
Un projet simple est un projet dont les liens entre les activités / tâches est de nature simple :
|
63 |
Projet (Complexe) |
|
Voir la définition d’un projet (Ref 41) pour le côté général et d’un projet simple (Ref 63) pour les cas simples.
Un projet complexe est un projet dont les liens entre les activités est de nature complexe :
Note : dans le cas où ces liens fort n'existent que de manière sporadique, nous parlons d’un projet simple. |
64 |
Programme (pour les projets) |
|
Un programme est un projet constitué de plusieurs projets. Voir la définition d’un projet (Ref 41) pour le côté général. |
65 |
Programme (simple) |
|
Voir la définition d’un programme (Ref 65) pour le côté général et d’un projet simple (Ref 63) pour les cas simples. La définition du programme simple est celle d’un projet simple où le mot « activités / tâches » pour le projet devient « sous-projet » pour le programme.
Un programme simple est un projet dont les liens entre les sous-projets est de nature simple : · Fin-début · Début-début · Fin-Fin · Début-fin |
66 |
Programme (Complexe) |
|
Voir la définition d’un programme (Ref 65) pour le côté général et d’un programme simple (Ref 64) pour les cas simples. La définition du programme complexe est celle d’un projet complexe où le mot « activités / tâches » pour le projet devient « sous-projet » pour le programme.
Un programme complexe est un projet dont les liens entre les sous-projets est de nature complexe : · Dépendances nécessaires entre les sous-projets en cours de réalisation · Ces dépendances peuvent être entre des de nature simple entre les activités / tâches des sous-projets
Note : ces dépendances peuvent être matérialisées avec des dépendances entre des releases des sous-projets par exemple. |
67 |
PDS |
Point De Situation |
C’est une séance pour faire l’état de l’art, entre plusieurs acteurs, de l’évolution d’une situation |
68 |
SAP ACTIVATE |
|
C’est la méthodologie de projet de SAP |
69 |
BP (SAP) |
Business Partner |
C’est une notion de base de SAP. Toutes les actions SAP sont liées à des BP qui endossent un rôle dans les processus financiers. |
69 bis |
BP (générique) |
Best Practice |
L’ensemble des expériences faites et documentées au format d’un processus. Note : Dans SAP, c’est implémenté au travers d’un scope item |
70 |
HANA |
High performance ANalytic Applicance |
Une « Appliance » de SAP, une combinaison hardware et software, optimisée pour tirer parti des technologies les plus récentes en matière de processeurs multicœurs et de mémoire vive. |
71 |
ECC |
ERP Central Component |
Version de SAP actuelle basée sur le système SAP R/3. |
72 |
PSM-FM |
Public Sector Management - Funds Management |
Module SAP de gestion des processus budgétaires et de l’exécution budgétaire dans S/4HANA faisant partie de l’industrie secteur public. |
73 |
PS |
Project System |
Module SAP concernant la gestion des projets dans SAP ; il permet d'effectuer les actions fonctionnelles suivantes : Structuration des projets. Suivi de coûts et budgets. Planning et calendrier. |
74 |
EC-PCA |
Entreprise Controlling - Profit Center Accounting |
Module SAP de la Comptabilité des Centres de Profits. |
75 |
HCM |
Human Capital Management |
Module et ensemble de solution SAP couvrant les processus HR dans les solutions ECC et S/4 comme l’administration HR, le traitement des salaires, la gestion des temps et absences, etc.
|
76 |
LoB |
Line of Business |
Regroupement de fonctionnalités proposé par SAP dans S/4HANA afin de couvrir une famille de processus ou un domaine d’entreprise.
|
77 |
SAC |
SAP Analytics Cloud |
Solution cloud proposée par SAP pour gérer les processus de planification budgétaire et le reporting
|
78 |
WRICEF |
Workflow Reporting Interface Conversion Enhancement Form |
Correspond à la typologie du développement envisagé dans un domaine : - Workflow (processus et étapes d’acceptation, validation) - Reporting (tous éléments de restitution) - Interface (scénario d’intégration avec d’autres applicatifs comme SYLVIA p.ex.) - Conversion (tout programme effectuer dans le cadre des reprises de données) - Enhancement (programme couvrant une fonctionnalité particulière non standard) - Form (formulaire, ou tout document/correspondance devant être généré et imprimé depuis SAP
|
79 |
SCI |
Système de Contrôle Interne |
|
80 |
SAP |
Systems, Applications and Products |
Par abus de langage le nom utilisé pour désigner un progiciel de gestion intégré développé et commercialisé par l'éditeur de ce produit (SAP AG) |
81 |
LPD |
Loi sur la protection des données |
|
82 |
nLPD |
Nouvelle Loi sur la protection des données |
|
83 |
CCP |
Comité de coordination des projets |
Organisation de projet |
84 |
Ci |
Centre Informatique UNIL |
Organisation Permanente |
85 |
DESI |
Demande d’Evolution du Système d’Information |
Document initial pour la demande de création du projet |
86 |
DEV-INT |
Pôle Développement et Intégration |
|
87 |
DSM |
Division des développements des Solutions Métiers |
|
88 |
FRAT |
Fiche de Registre des Activités de Traitement |
|
89 |
MPRO |
Méthodologie Projets |
Organisation de projet |
90 |
OJ |
Ordre du Jour |
|
91 |
PAT |
Personnel Administratif & Technique |
|
92 |
PPRO |
Pôle Projets |
|
93 |
RGPD |
Règlement Général sur la Protection des Données |
|
94 |
SI ACAD |
Système d’Information Académique |
|
95 |
SI UNIL |
Système d’information de l’UNIL |
|
96 |
TransNum |
Initiative Transition numérique |
|
97 |
UNIL |
Université de Lausanne |
|
98 |
DSM |
Division des Solutions Metiers |
|
99 |
RDP |
Revue de projets |
|
100 |
PDI |
Plan directeur informatique |
|
101 |
SDM |
Schéma directeur métier |
|
102 |
RGE |
Règlement Général des études |
|
103 |
SLCM |
Student Life Cycle Management |
|
104 |
BaS ou SBX |
Bac à Sable ou SandBoX |
C'est un environnement technique de notre plateforme SAP qui tient principalement un rôle d'un environnement de post-production pour des raisons de sécurité, mais au besoin, il peut tenir un rôle de pré-production pour tester les paquets de release à déployer ou de test de dev pour régler des conflits de version des composants SAP |
105 |
SPO |
|
C'est une procédure de gestion des versions de SAP qui inclus une analyse d'impacts et d'autres standards de qualité. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FAQ
Qu'est ce que la MPRO ?
La Méthodologie de Projets (MPRO) est la méthode choisie par le Centre Informatique (Division Solutions Métiers - DSM) pour conduire les projets métiers et techniques.
Cette méthode est basée sur la méthodologie de la Confédération Suisse : Hermes et a été adaptée aux besoins et pratiques de l'UNIL.
+ sur le déroulement d'un projet
Une documentation plus détaillée de la méthode est à disposition des Chefs de Projets. Pour plus d'informations, merci de s'adresser à fabrice.douchant@unil.ch.
Comment se déroule un projet ?
Cycle de vie du projet
La méthode de gestion de projet HERMES utilise un modèle de phases qui permet une approche classique ou agile. Le modèle de phases proprement dit repose sur le cycle de vie du projet. Il crée les conditions requises pour que toutes les parties prenantes comprennent le déroulement du projet de la même manière. Les phases déterminent la structure du projet.
La figure ci-dessous montre le cycle de vie d'un projet HERMES.
Source : HERMES>Gestion du projet 2022>Comprendre>Phases
Objectifs principaux
Les projets se composent de 4 phases dont voici les objectifs principaux :
A chaque fin de phase, le COPIL se réunit pour valider :
- La clôture de la phase actuelle : l'ensemble des résultats développés durant la phase.
- La planification de la phase suivante : les résultats proposés et estimés par le COMOP.
Une phase peut contenir d'autres jalons décisionnels, par exemple pour la validation d'un POC, de l'achat d'une solution, ...
Comment est défini le contenu (périmètre) du projet ?
Le périmètre du projet délimite ce qui est attendu de la solution et ce qui ne l'est pas.
La définition du périmètre est une activité primordiale qui s'affine tout au long du projet. Voici les grandes étapes :
Le périmètre du projet doit aborder toutes les "thématiques" (modules) ci-dessous :
Le périmètre peut amener à évoluer suite à une opportunité, une contrainte technique ou métier, un changement de stratégie, ... Les changements sont alors analysés par le COMOP (pertinence, faisabilité métier/technique, impacts coûts/délais). Selon l'impact, le changement est escaladé au COPIL pour être validé.
Quels sont les principaux rôles associés à l'exécution d'un projet ?
Parmi les rôles qui participent à l'exécution du projet, voici les 4 principaux :
Référent Métier (RM)
C'est l'expert d'un domaine métier/service (RH, communication, ...). Il est également le représentant des autres membres de son domaine au niveau des connaissances, des besoins et des décisions.
A noter que le projet peut être transverse sur plusieurs domaines métiers avec chacun son RM.
Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :
Spécialiste IT (développeur, intégrateur)
C'est l'expert d'un domaine ou système IT. Il est responsable du développement et de l'intégration de ce système. Il peut être interne ou externe (prestataire) à l'UNIL selon si le système est développé ou acheté.
A noter que la solution du projet peut-être constituée de plusieurs systèmes avec chacun son Spécialiste.
Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :
Technical Product Owner (TPO)
C'est l'exploitant technique de la future solution. Il est le référent technique une fois la solution déployée. Il peut être également le Spécialiste IT si la solution est développée à l'UNIL.
Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :
Chef de projet / Business Analyste (BA)
C'est le responsable de la conduite du projet et de l'atteinte des résultats et objectifs du projet. Il coordonne le COMOP et le représente aux séances de COPIL. En tant que business analyste, il fait le lien entre la partie métier et technique et participe au recueil et à l'analyse des besoins du projet.
Ci-dessous les principales tâches et le niveau d'implication attendu (faible, moyenne et forte) durant le déroulement du projet :
Comment est organisé un projet ?
Il y a 3 types d'acteurs au sein d'un projet :
- Membre de Comité de Pilotage (COPIL) : membre du pilotage d'un projet (chef-fe de service, membre de la direction, ...)
- Membre de Comité Opérationnel (COMOP) : référent et spécialiste technique ou métier impliqué dans toute la durée du projet (ou une grande partie)
- Intervenant : personne impliquée pour une tâche spécifique dans le cadre d'un projet
Le COPIL et le COMOP forment les organes décisionnels pour le pilotage et respectivement l'execution d'un projet :
Quels sont les résultats du projet ?
Les résultats qu'un projet produit dépendent de son périmètre. Il existe 2 catégories de résultats :
- le système : le produit informatique qui sera déployé pour les utilisateurs
- les livrables : la documentation technique/métier, les analyses (étude, concepts, ...) et les documents propres au projet (mandats, appels d'offres/accords, ...)
Bien que le but d'un projet informatique soit la mise en oeuvre et le déploiement d'un système (produit) informatique, le projet couvre également d'autres aspects : migration, exploitation, organisations, ...
Comment est planifié un projet ?
La planification du projet permet de coordonner les tâches, d'assurer la disponibilité des ressources et de prendre des décisions.
La planification repose sur l'estimation des tâches à réaliser et s'articule autour de 3 concepts :
- L'effort : le temps de réalisation d'une tâche (jour / personne)
- L'allocation : la disponibilité de la personne qui réalise la tâche (%)
- Le délai : l'échéance de la tâche
Une marge est souvent ajoutée à l'estimation. Elle dépend notamment de l'expérience de la personne et du degré d'inconnu de la tâche.
Le Chef de Projet suit et fait évoluer la planification régulièrement sur la base des informations fournies par le COMOP.
Le responsable d'une tâche (technique ou métier) doit communiquer au COMOP tous les risques ou problèmes identifiés afin de de limiter leurs impacts sur le planning.