Passer au contenu principal

Annexe 1: 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. 

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

Les acronymes des titres et rôles sont disponible dans la page associée: Intervenants UNIL dans les projets

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 ? ».
Des livrables possibles sont un scénario Hermès, un diagramme BPMN des activités du projet ou un diagramme de PERT construit sur la base du WBS

·         Le « Schedule », ou Planning, répond aux questions « qui ? » et « quand ? »
Des livrables possibles sont un plan d’action ou un diagramme de GANTT construit sur la base du « Planning » avec les estimations des durées des tâches.


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.
La durée de rentabilité est le temps nécessaire pour que la mise de départ puisse être récupérée (retour sur investissement égal à zéro). »

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.

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

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.

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 :

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.

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 :
consommée (Down) par l’équipe ou à consommer (Up) sur le Sprint

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

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.

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.

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.  

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.

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.

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 :

  • Fin-début
  • Début-début
  • Fin-Fin
  • Début-fin

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 :

  • Dépendances nécessaires entre les tâches en cours de réalisation

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

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.

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

DCSR

Division calcul et soutien à la recherche 

 

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

106

Grooming

 

 

107

Sprint Planning

 

Séance de planning pour les activités qui seront réalisées pendant la durée du Sprint

108

Sprint Review 

 

Séance de revue des activités réellement réalisées pendant la durée du Sprint

109

(Daily) SuM

(Daily) Stand-up Meeting 

Séance de suivi (quotidienne), de la méthode Agile SCRUM, qui selon la méthodologie se passe debout afin de forcer les participants à aller à l'essentiel. le plus vite possible

110

Sprint Retrospective 

 

 Séance d'analyse afin de pouvoir tirer les expériences sur la période de temps écoulée, cette séance liste le bon, le moins bon et les actions d'amélioration à mettre en place

111

Backlog Review / Refinement


C'est une activité, qui peut se faire dans une séance, de revue et priorisation des sujets ouverts du Backlog.

112

DoS

Definition of Small

La définition de petit est une notion qui adapte le périmètre de l'activité à la période de temps allouée pour sa réalisation, ou Sprint.

113

Agile SCRUM


C'est l'une des méthodologies Lean, elle est adaptée à la gestion d'une équipe de développement pour un backlog

114

Agile SAFe

Scaled Agile Framework

C'est l'une des méthodologies Lean, elle est adaptée à la gestion d'un portefeuille de projet

115

Lean


Lean est l'une des méthodologies de gestion, notamment pour les projets. C'est la méthodologie mère des différentes méthodologie Agiles.

116

IceBox


"la boite à glaçon", c'est un terme anglais américain signifiant "en attente".

C'est la seule exception de traduction qui sera traité dans cette liste. 

117

HPC

High Performance Computing

Le calcul haute performance (HPC) permet de traiter les données et d'effectuer des calculs complexes à des vitesses élevées.

118

Dev Full-stack


"Un développeur Full Stack est quelqu'un de familier avec toute la stack technique et qui a les compétences pour faciliter le travail de ses collaborateurs".

Cela signifie réellement que le développeur connait les technologies avec lesquels il travaille et ne représente pas une surcharge pour ses collaborateurs techniques.
En Français, ces acteurs portent le nom d'architectes voir de directeurs techniques.
 

119

SRE

Site Reliability Engineering

La SRE est la mise en œuvre pratique de DevOps

120

DevOps

Development & Operations

"DevOps repose sur une culture de la collaboration entre développeurs et équipes opérationnelles, qui partagent les responsabilités et combinent le travail. Il améliore l'efficacité des équipes et permet d'accélérer les transferts de tâches et la création de code conçu pour un environnement d'exécution spécifique."

121


Matrice d'Eisenhower

Cette matrice est similaire aux méthodes MoSCoW & KISS, elle sert à la priorisation des activités selon des critères d'urgence et d'importance:

  • Une tâche est urgente quand celle-ci doit être traitée le plus rapidement possible.
  • Une tâche est importante quand celle-ci contribue à la réalisation de vos objectifs à court, moyen ou long terme.

Ce qui nous donne la matrice de 2 par 2 suivante:

  • Urgent et important : Ce sont les tâches que vous devez traiter le plus rapidement possible.
  • Important et non urgent : Ce sont les tâches que vous planifiez dans votre calendrier
  • Urgent mais non important : Ce sont les tâches que vous déléguez
  • Ni urgent ni important : Ce sont les tâches que vous éliminez ou limitez

122

ABCDE

Méthode ABCDE

Cette méthode est similaire aux méthodes MoSCoW, KISS et à la matrice d’Eisenhower, les tâches sont triées sur la base de paramètre d'importance, optionnalités, délégation et élimination:

  • A = Les Tâches très importantes :  sont celles que vous devez absolument faire. Ne pas les faire peut avoir de graves conséquences.
  • B = Les Tâches importantes : sont celles que vous devez faire, une fois que vous avez accompli les tâches très importantes. Ne pas les accomplir n’aura que des conséquences mineures.
  • C = Les Tâches optionnelles : correspondent aux tâches que vous pouvez faire si et seulement si les tâches de la catégorie A et B sont terminées. Ne pas les faire, n’a pas vraiment de conséquences négatives.
  • D = Les Tâches à déléguer : sont celles que vous transférez à d’autres personnes pour vous libérer du temps. 

La délégation est un art comme d'autres sujet, il ne sera pas aborder dans cette liste.

  • E = Les Tâches à éliminer : sont toutes les tâches que vous devez éliminer de votre to-do list, soit parce qu’elles ne vous sont d’aucune utilité ou parce qu’elles ne sont plus pertinentes.

Pour bien appliquer cette méthode, veillez à avoir relativement peu de tâches dans les catégories A et B en comparaison des catégories C, D et E. 

123

RICE

RICE Scoring

Cette méthode est similaire aux autres mais sur la base des paramètres Reach, Impact, Confidence et Effort.

  • Reach: une estimation du nombre de personnes que votre initiative atteindra dans un laps de temps donné. C'est un paramètre centré sur les utilisateurs finaux.
  • Impact: la manière dont les personnes atteintes seront affectées en tant qu'individus. On défini cela sur une échelle:
    • 3 = impact massif
    • 2 = impact élevé
    • 1 = impact moyen
    • 0,5 = impact faible
    • 0,25 = impact minimal
  • Confidence: un indice de confiance en pourcentage que l'objectif est atteignable, idéalement sur des données d'expériences passées, sinon sur une sentiment de confiance. Supérieur à 80% est une confiance élevée alors qu'inférieur à 50% est un "moon shot", les priorités sont ailleurs.
  • Effort: C'est l'estimation de la charge de travail en jour homme; cela informe indirectement sur la complexité de la tâche.

Le Score est alors calculé: (Reach x Impact x Confidence) / Effort

124

Kano

Kano Model

Ce modèle porte le nom de son créateur Noriaki Kano.

Ce modèle va permettre de trier les qualités des fonctionnalités (attractivité, proportionnalité et nécessité) sur 2 axes (satisfaction et présence de la fonction).

Afin de comprendre le modèle, il faut clarifier les définitions:

  • attractivité: représente les caractéristiques que les clients/utilisateurs percevront comme allant au-delà de leurs attentes et étant différenciateurs des concurents.
  • proportionnalité: classe les fonctionnalités qui, plus elles seront développées et abouties, plus elles généreront de la satisfaction
  • nécessité (obligatoire): Représente sans surprise le minimum attendu par les clients pour résoudre leurs problèmes. Sans elles, le produit leur est pratiquement inutile.

Un tel modèle se comprends mieux dans sa représentation graphique:

image.png

Et se prépare sur la base d'une liste de fonctions trié dans une matrice:

image.png

Les autres méthodes sont plus faciles à l'utilisation.

125

Priorisation

Priorisation (des tâches)

L'action "d'Accorder une importance préférentielle à quelque chose ou à quelqu'un".

Il existe plusieurs moyen d'effectuer cette action. Cette liste référence des méthodes préférées de par leur aspects tangibles. Ce référencement est non exhaustif, une recherche google vous permettra d'en trouver d'autres.

 

Les méthodes peuvent être adaptée ou combinée selon le besoin. Dans le cas d'un projet nécessitant une priorisation spécifique ou retravaillé depuis les méthodes, merci de vous référer au chef de projet qui lui même se réfèrera au PMO en cas de besoin.

 

126

BaU

"Business as Usual"

Signifie que l'activité est vue comme régulière et une tâche quotidienne qui ne nécessite plus de suivie spécifique comme au travers d'une gestion de projet par exemple.