SlideShare une entreprise Scribd logo
Quelle métrique
pour fédérer
Dev & Ops ?
Think Tank Automic
Livre Blanc
DevOps : Retours d’expérience et
bonnes pratiques issus du Think
Tank Automic
Livre Blanc
Follow Us2
Quelle métrique pour fédérer
Dev & Ops ?
DevOps : Retours d’expérience et bonnes pratiques issus du Think
Tank Automic
Texte établi par
Gérald Audenis
François Bazenet
Eric Bouvet
Thierry Falque-Vert
Charlotte Gondre
José Mauricio
Jérôme Meyer
Frédéric Poulain
Alexandra Sommer
Rédaction
Alexandra Sommer
Graphisme
Emilie Daboussy
Produit par
Automic
Tour Pacific
11, cours Valmy
92800 Puteaux
France
Copyright © 2016 Automic Software S.A.S. Tous droits réservés. La copie, photocopie, reproduction,
traduction ou conversion de ce livre blanc sous quelque forme que ce soit, mécanique ou électronique,
est interdite sans autorisation préalable obtenue par écrit auprès de Automic Software S.A.S.
Livre Blanc
TABLE DES MATIÈRES
Préface 4
Chapitre 1 : Un indicateur mutant pour fédérer Dev & Ops  8
Chapitre 2 : Le TRS, un KPI sans équivalent dans l’informatique  12
Chapitre 3 : Implémentation du TRS en environnement DevOps  15
Etape 1 : Intention  16
Etape 2 : Identification du périmètre d’application  16
Etape 3 : Implication  17
Etape 4 : Partage du vocabulaire  18
Etape 5 : Etat des lieux du système de mesure  19
Etape 6 : Collecte des points de mesure  21
Etape 7 : Premières mesures  22
Etape 8 : Analyse des gaspillages  22
Atelier Arbre des Gaspillages  23
Atelier TIMWOOD  26
Etape 9 : Système de pilotage  28
Etape 10 : Industrialisation  29
A propos du Think Tank Automic  31
Livre Blanc
Follow Us4
Préface
DevOps est né en 2009 après qu’un administrateur système (sysadmin) du nom
de Patrick Debois a fait le constat que l’Agile, pour être pleinement efficace, devait
nécessairement embarquer toute les équipes de la DSI : Dev (développement) et
Ops (opérations). Le mouvement DevOps a connu par la suite un essor rapide en
rassemblant sous sa bannière un ensemble de technologies et de pratiques permettant
des mises en production plus petites, plus fréquentes et moins risquées. En 2010, les
valeurs essentielles de DevOps étaient résumées sous forme d’un acronyme : CAMS
pour Culture, Automatisation, Mesure et Partage (Sharing, en anglais).
La mesure est ainsi, depuis ses débuts, l’un des piliers de DevOps*. C’est aussi l’un
de ses territoires les moins explorés et les moins documentés. Le présent Livre Blanc
cherche à répondre à une question simple : Comment mettre en place une mesure
adaptée à DevOps, qui facilite le rapprochement entre équipes Dev et Ops et qui offre
une vision objective et utile de la performance ?
Nous espérons que la réponse que nous proposons ici de manière très concrète
retiendra votre attention et vous donnera envie de la mettre en pratique. Dans tous les
cas, cette réponse n’aurait pas pu voir le jour sans un certain nombre de rencontres,
incarnées par des personnes que nous tenons à remercier chaleureusement :
•	Rencontreavecl’industrie,toujoursàlapointeenmatièredeperformance,enlapersonne
de Christian Hohmann, expert en Lean Manufacturing de réputation internationale,
•	Rencontre avec des managers de production informatique visionnaires, avec qui
nous avons transposé depuis 2010 les standards de performance industrielle à la
productioninformatique.C’estleurtravaildetouslesjours,dansleursorganisations,
qui a permis d’apporter une réponse pratique tant sur le « quoi » de la mesure que
sur le « comment » de sa mise en œuvre.
•	Rencontre avec des managers de développement informatique, de la même étoffe,
qui ont permis depuis 2014 d’établir une vision de bout en bout de la performance
de la DSI tout en apportant une diversité bienvenue dans les approches.
En 2015, comme chaque année depuis 2010, ces rencontres ont eu lieu dans le cadre de
la communauté du Think Tank Automic, dédiée à la mesure de la performance.
*Dans son enquête 2015 « Adoption et Enjeux de DevOps en France », IDC indique que la définition
d’indicateurs communs pour Dev et Ops est un critère clé de succès pour 69% des organisations en
cours d’adoption de DevOps.
Livre Blanc
Follow Us5
Nous tenons à remercier de tout cœur tous les managers qui y ont participé pour leur
engagement, leur esprit de partage, leurs idées et leur capacité hors norme à les mettre
en pratique et sommes très reconnaissants d’avoir pu travailler cette année avec :
•	François BAZENET, CAISSE DES DEPOTS
•	Patrice BENOIT, CCI PARIS ILE DE FRANCE
•	Nicolas BOGUCKI, INSTITUT NATIONAL DE L’AUDIOVISUEL
•	Pierre-Yves BOUCHARD, ANTEMETA
•	Eric BOUVET, ARKEMA
•	Didier CANITROT, EULER HERMES
•	Cyrille CARTIER, ANTEMETA
•	François GILLES, RECTORAT DE VERSAILLES
•	Geneviève GLEIZES, CCI PARIS ILE DE FRANCE
•	Charlotte GONDRE, RECTORAT DE VERSAILLES
•	Gilles LAVIGNE, POLE EMPLOI
•	José MAURICIO, BRED
•	Frédéric POULAIN, EDENRED FRANCE
•	Olivier SOULABAILLE, SECURITAS
•	Etienne TAROT, LACTALIS
Merci tout particulièrement à Charlotte Gondre et Eric Bouvet pour l’animation des
groupes de travail DevOps et ITIL dont les travaux, loin de s’opposer, se sont nourris
mutuellement dans l’intérêt de tous.
Un grand merci également à tous ceux qui ont participé à la rédaction des publications
antérieures du Think Tank Automic. L’expérimentation d’un indicateur synthétique en
environnement DevOps n’aurait pas pu être aussi rapide sans s’appuyer notamment sur
le “guide pratique d’implémentation du Taux de Rendement Synthétique (TRS)”, paru
en 2015. Nous en reprenons ici les éléments indispensables pour que le lecteur n’ait pas
besoin de s’y référer.
Merci, enfin, aux équipes Automic qui ont, année après année, œuvré à rendre toutes
ces rencontres passionnantes, productives et conviviales. Merci à Jérôme Meyer et à
Michel Enkiri pour la coordination métronomique des groupes de travail. Merci à Gérald
Audenis, Thierry Falque-Vert et Nathan Srour pour l’animation experte des sessions
de travail et ateliers. Merci à Alexandra Sommer pour l’organisation irréprochable des
événements et la mise en forme impeccable des publications.
Livre Blanc
Follow Us6
LES MEMBRES DU THINK TANK TÉMOIGNENT...
« Membre du Think Tank depuis plusieurs années, j’ai pu bénéficier dans mon quotidien
del’immensetravaildegroupetournantautourdel’idéequ’ilestpossibledansl’ITcomme
dans l’Industrie d’identifier la Performance de notre activité et de nos organisations.
Trouver un moyen de Mesurer a été la toute première étape complétée avec succès
par l’équipe initiale. Mais elle s’est rapidement complétée grâce à l’arrivée de nouveaux
membres par la phase d’identification des gaspillages puis enfin par la phase de
correction pour boucler par une nouvelle campagne de mesure… La roue de Deming
avait fait un premier tour, il ne s’agissait plus que de consolider pour progresser et ce fut
la rédaction des Livres Blancs. Encore bravo à tous et surtout un grand MERCI ! »
Pierre-Yves Bouchard – Directeur de Production Cloud - ANTEMETA
« J’ai participé aux travaux du Think Tank dès sa création en 2010. Débattre sur
l’intérêt de transposer à l’Informatique un indicateur de performance issu de l’Industrie
fut passionnant. Expérimenter puis industrialiser la démarche sur le Service Desk et
des processus clefs (gestion des mises en production, gestion des événements) pour
piloter la performance, parfois dans un contexte international, le fut encore davantage.
Aujourd’hui, les entreprises et les administrations disposent, au travers des livres
blancs, d’une méthodologie et des retours d’expérience documentés. De quoi faciliter
l’adoption et accélérer la mise en œuvre en quelques semaines seulement, alors que
plusieurs mois étaient requis lors des premières expérimentations. »
Eric Bouvet, Responsable IT Operations - ARKEMA
« Le groupe de travail DevOps est une bonne illustration de l’intelligence collective. Les
échanges sympathiques et riches nous ont permis de mieux penser nos processus de
travail transverse, de les améliorer et de s’initier aux indicateurs synthétiques. Thanks
Think Tank ! »
Geneviève Gleizes, Responsable technologies transverses et Développement Web
DPMA - DPSI - CCI PARIS ILE DE FRANCE
« En appliquant simplement la méthode et grâce aux échanges avec les participants, j’ai pu
mettre en place rapidement un indicateur pertinent pour mesurer la performance de notre
nouvelle chaine de déploiement pour une application stratégique, dans un esprit DevOps. »
Frédéric Poulain, Responsable Système & Réseaux - EDENRED
« Un partage très riche et unique d’expériences avec nos pairs actuels (OPS) et futurs
(DEV). Des échanges constructifs en toute transparence intégrant les besoins et
contraintes de chacun. Et du concret, un indicateur de référence pour mesurer l’impact
de la mise en œuvre de DevOps en terme de valeur Business. »
Didier Canitrot, Head of GIP Process and Service Design - EULER HERMES
Livre Blanc
Follow Us7
« La direction des systèmes d’information de Météo France est soumis à des contraintes
de marché et d’adaptation aux normes qui nécessitent des mises en production rapides
et sûres. La mise en oeuvre d’indicateurs de bout en bout, caractéristique du DevOps
est en cours. C’est en suite des réunions et présentations du Think Tank Automic que
ces idées on pris de la substance et sont devenues plus concrètes. »
Daniel Dure, Directeur des Systèmes d’Information - METEO FRANCE
« Nouveau Think Tank, nouvelles rencontres et toujours des résultats à forte valeur
ajoutée. Le partage des réussites et des difficultés de chacun permet au groupe de
progresser … Besoin d’un TRS pour mesurer ces progrès ? »
Gilles LAVIGNE, Directeur Adjoint des Opérations - POLE EMPLOI
« Travailler à définir, puis à évaluer, des points de mesures de qualité, de disponibilité et
de performance d’une chaine de production logicielle en mode « DevOps » a permis de
confronter la théorie d’un modèle synthétique, celui du TRS, à la réalité opérationnelle.
Le résultat a dépassé nos attentes . Il s’avère en effet qu’une définition et une analyse
concertée des mesures favorisent la cohésion des équipes DEV (Etudes) et OPS
(Exploitation). Ceci contribue à rendre de fait les équipes acteurs de la conduite du
changement DevOps et à en mesurer de façon factuelle les gains pour servir l’objectif
premier de la DSI à savoir la satisfaction des clients. »
Charlotte Gondre, Chef du Service Etudes & Développement - RECTORAT DE VERSAILLES
Livre Blanc
Follow Us8
Chapitre 1 : Un indicateur mutant
pour fédérer Dev & Ops
Une affaire non résolue : DevOps & la mesure
DevOps a connu un essor fulgurant depuis son apparition au tournant des années
2010. En l’espace de cinq ans, près d’un tiers des organisations informatiques se sont
lancées dans l’aventure DevOps, au moins sur un pilote. Le principal moteur de cette
transformation est l’ambition affichée de réduire le délai entre l’expression d’une idée et
son activation en environnement de production (Time to Production).
Mais au fait, quel est aujourd’hui votre Time to Production ? De combien s’est-il amélioré ?
La question peut sembler provocatrice à l’heure où la Mesure est affichée comme l’un
des quatre piliers de DevOps. Pourtant, l’expérience montre que la pression continuelle
portée sur la livraison de projets toujours plus urgents empêche les organisations
de réfléchir à leur système de mesure et de répondre à ces questions basiques. Le
développement enchaine les sprints et puis, un beau jour, les features finissent bien par
arriver en production. Mais quand ? Avec quel impact ? Et à quel prix ?
La mesure dans DevOps est bel et bien une affaire non résolue. Il suffit d’évoquer la
question avec des personnes confrontées au sujet pour que reviennent les questions
suivantes :
•	Comment contrôler le fonctionnement et mesurer les progrès d’une chaîne de
delivery Agile ?
•	Comment mesurer la Performance de bout en bout plutôt que celles des Dev et
des Ops en silo ?
•	Comment éviter les indicateurs toujours verts qui masquent les problèmes (l’effet
“Dev-Oups”) ?
•	CommentamenerDevetOpsàmieuxprendreencompteleurscontraintesrespectives?
•	Comment gagner en lisibilité et ne pas se laisser submerger par une information
surabondante (Dashboard Everything) ?
La vérité est ailleurs : Un standard industriel, le TRS
Les mesures existantes apparaissent inopérantes pour fédérer Dev et Ops car elles
sont en décalage profond avec les enjeux collaboratifs de DevOps. Les KPIs reflètent
le cloisonnement des organisations. Les Opérations ne se retrouvent pas dans les
métriquesAgiles.LesEtudesneseretrouventpasdanslesSLAs.Lesoutilsfonctionnent
« en silo » et ne permettent pas une vision de bout en bout.
Livre Blanc
Follow Us9
Il fallait donc chercher la vérité ailleurs que dans l’informatique. En l’occurrence, nous
avons trouvé l’inspiration dans l’industrie, confrontée depuis des décennies aux enjeux
d’agilité et de fiabilité au point d’avoir établi un standard de mesure de la performance :
le Taux de Rendement Synthétique (TRS). Largement répandu dans les environnements
industriels, cet indicateur n’est pas un indicateur de plus mais bien la clé de lecture
principale de la performance pour les directeurs d’usine.
Notre démarche a simplement consisté à appliquer ce standard industriel à un nouveau
type d’usine : la digital factory. Nous avons voulu transposer le TRS en environnement
DevOps et valider sa pertinence en environnement réel. Nous avons voulu en faire un
indicateur commun qui permette de gagner en lisibilité et de piloter la Performance
globale de la chaîne de delivery de la DSI, plutôt que les performances locales au niveau
des Dev et des Ops. Nous avons voulu également nous inspirer des méthodes d’analyse
et d’amélioration continue qui sont utilisées dans le sillage du TRS comme l’arbre des
gaspillages ou la méthode TIMWOOD.
Des résultats concrets : Bonnes pratiques & Retours d’expérience
Les résultats présentés dans ce Livre Blanc sont le fruit d’un travail d’équipe. Pour
garantir des résultats concrets, chaque membre du Think Tank Automic s’est engagé
personnellement à produire une mesure dans son propre environnement. L’approche
communautaire et collaborative a fait le reste : le fait d’avancer de concert et de
confronter l’expérience de chacun à chaque étape a permis d’aller plus vite et d’aborder
la mise en œuvre avec confiance.
Dans un premier temps, le groupe a convergé sur la définition d’un TRS transposé à la
chaine de delivery logiciel. Cette définition est intervenue à deux niveaux. Le niveau
général définit ce qui doit être mesuré (le quoi). Le niveau détaillé propose différents
indicateurs permettant de le mesurer (le comment). Il existe en effet différents moyens
de mesurer le TRS selon la capacité d’une organisation à produire certaines mesures.
Certaines mesures, plus simples, sont suffisantes dans une première approche et
permettent de franchir un premier pas significatif en matière de pilotage. Cette
définition flexible a permis de construire une boite à outils générique adaptable aux
contextes des différents membres.
Dans un second temps, le groupe a mesuré le TRS à partir de cette définition. Les
premiers résultats ont été suivis mensuellement. Ils ont permis de valider la pertinence
de la mesure et son intérêt tant pour l’identification de pistes d’amélioration que pour
sa capacité à fédérer équipes Etudes et Production. Des ateliers spécifiques ont été
conduits durant cette phase pour rentrer dans l’analyse des gaspillages et identifier
des plans de remédiation. Les retours d’expérience ont été partagés entre membres
Livre Blanc
Follow Us10
que ce soit pour l’adoption ou pour l’usage du TRS.
En fin d’année, les membres sont revenus sur les bonnes pratiques qu’ils souhaitaient
partager suite à leur propre expérience de la mise en place du TRS. Ces conseils sont
présentés dans le tableau ci-dessous.
Les enseignements : La mesure est un outil collaboratif très efficace
Au-delà des résultats détaillés dans les chapitres suivants, il est ressorti de cette
année de travail en communauté que la mesure était un outil collaboratif extrêmement
puissant.
La mesure aide à fédérer et à faire adhérer. On réduit trop souvent DevOps à
l’automatisation et à la technologie et on oublie par la même occasion la dimension
du partage qui est essentielle. A la base DevOps est une question de culture, de
communication, de confiance, de collaboration. Au sein des organisations qui l’ont
mis en place, la mesure a amené Dev et Ops à travailler ensemble sur des indicateurs
communs et a contribué à transformer la culture. La volonté de s’améliorer ensemble
en est ressortie renforcée.
Expérimentation du TRS : Bonnes pratiques
1 Assimiler la méthode
•	 Avoir une vision claire du TRS et une bonne compréhension du
modèle
•	 Développer une certaine curiosité
•	 Partager les retours d’expérience à travers des Think Tank par
exemple
2 Procéder par étape
•	 Cibler et définir un périmètre d’application restreint et maîtrisé
•	 Se remettre en cause continuellement
•	 Ne pas hésiter à adapter le périmètre ou les définitions au fur et à
mesure que l’on comprend mieux le modèle
3 Partager / Impliquer
•	 Communiquer autour du TRS, privilégier la collaboration et le
partage des besoins
•	 Partager les mesures et en conséquence les processus
•	 Réfléchir aux modalités d’analyse des écarts en impliquant les
équipes
4 Démontrer la valeur
•	 Impliquer les acteurs du terrain
•	 Proposer des plans d’actions pragmatiques et priorisés
•	 Capitaliser sur les quick-wins
5 Pérenniser
•	 Penser à la gestion du cycle de vie du TRS et son maintien en
condition opérationnelle
•	 Penser à revoir et à réactualiser les objectifs et critères de mesure
•	 Inscrire l’ensemble des indicateurs dans les standards
Livre Blanc
Follow Us11
Un moyen pratique d’établir un dialogue. La Mesure ne doit pas être imposée mais
présentée comme un moyen d’établir un dialogue. La Mesure ne doit pas être un projet
uniquement Dev ou uniquement Ops mais être conçue de façon concertée. La Mesure
ne doit pas se focaliser sur le chiffre mais apporter une discussion entre équipes. Les
membres du Think Tank ont construit leur TRS ensemble, avec leurs équipes dans une
approche résolument Bottom-up.
Le TRS permet d’aller vite à l’essentiel. Tout le monde veut mesurer mais rares sont
ceux qui prennent le temps de mettre les mesures en place. Le TRS présente l’intérêt
de pouvoir être implémenté rapidement, quitte à ce que la mesure soit embryonnaire
dans un premier temps. Le cadre de définition général permet d’aller vite sans rien
oublier d’essentiel. La valeur vient ensuite en marchant : On commence avec ce qu’on
sait faire et on progresse au fur et à mesure. Les résultats sont apparus comme très
pertinents même à partir de mesures partielles. Par ailleurs, la méthode en 10 étapes
présentée au Chapitre 3 est une aide précieuse pour avancer pas à pas et franchir des
étapes clairement identifiées.
Cultiver un état d’esprit collaboratif. L’avantage des mesures, c’est qu’elles sont
factuelles, objectives, transparentes, honnêtes et partagées. Pour en tirer le meilleur
parti, il faut se mettre en position d’écoute de l’autre et accepter que l’on ait des choses
à améliorer. Par ailleurs, la discussion sur les mesures à mettre en place nécessite de
s’écouter pour se comprendre : Dev et Ops ne mettent pas toujours la même chose
derrière un même terme. Du point de vue du manager, il importera d’être bienveillant et
de ne pas mettre en place la mesure dans un objectif de sanction. Compte-tenu que le
TRS est un indicateur de progrès, sa valeur est par définition non optimale (c’est-à-dire
loin de 100% !) et il est recommandé de s’axer sur la variation de l’indicateur, et non sur
sa valeur absolue. En tout état de cause, la communication est clé !
L’essayer c’est l’adopter ! Dans un premier temps, le principe d’un indicateur unique
permettant de mesurer la « performance de DevOps » a laissé certains membres
dubitatifs. Les mêmes sont aujourd’hui les premiers convaincus que « ça marche ».
La mesure leur a en effet permis de cimenter une culture de collaboration. Ils ont pu
constater que la recherche de l’amélioration continue est bel et bien partagée par
les équipes Ops & Dev. A partir du moment où ils se sont mis d’accord pour définir
des indicateurs factuels et objectifs et les analyser ensemble, le dialogue s’est établi
ainsi que la confiance. Du point de vue des managers, la valeur la plus importante a
été trouvée dans le travail mené en commun avec les équipes. Le TRS est un moyen
efficace d’y parvenir en un temps record !
Livre Blanc
Follow Us12
Chapitre 2 : Le TRS, un KPI sans
équivalent dans l’informatique
Plusieurs années d’expérimentation dans le cadre des activités du Think Tank Automic
ont permis de révèler que deux indicateurs standards en environnements industriels
apportaient une réponse pratique efficace aux besoins de partage et de pilotage des
organisations informatiques :
•		Le Taux de Rendement Synthétique (TRS), qui mesure la performance d’une 	
unité de production,
•		Le Taux de Rendement Global (TRG), qui intégre la charge effective de ce 	
moyen de production.
Ces indicateurs présentent plusieurs caractéristiques originales en environnement
informatique :
•		Lisibilité : Ce sont des indicateurs synthétiques, obtenus par la multiplication
d’autres indicateurs, permettant de suivre en un coup d’œil l’évolution de la
performance. Cela permet de mieux partager objectifs et résultats avec les clients,
les équipes de la DSI ou la Direction Générale.
•		Amélioration : Ce sont des indicateurs de progrès, qui n’ont pas vocation à
atteindre 99,9% ou 100%. Des taux de 60% ou 70% sont fréquents, même en
fonctionnement normal. Cela permet d’analyser les dysfonctionnements et de
constater les améliorations.
•		Bout-en-bout : Ce sont des indicateurs composites qui intègrent d’une part la
qualité de la production (vue client) et d’autre part l’efficacité du processus (vue
fournisseur). Cela permet un pilotage équilibré et une implication de l’ensemble
des équipes.
Qu’est-ce que le TRS ?
L’Industrie recourt habituellement pour le pilotage de sa Performance au Taux de
Rendement Synthétique (TRS) correspondant en anglais à l’Overall Equipment
Effectiveness (OEE). Cet Indicateur Clé de Performance permet d’évaluer sur un
axe unique l’efficacité opérationnelle, les objectifs de Performance et le résultat des
initiatives de productivité.
Livre Blanc
Follow Us13
Il s’agit d’un indicateur sans grandeur, consistant en la multiplication de trois taux :
•	Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée),
•	Le Taux de Performance « Tp » (variant en fonction des cadences),
•	Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le
nombre de pièces produites).
Le TRS peut donc être défini comme suit : TRS = Td * Tp * Tq
Qu’est-ce que le TRG ?
L’industrie recourt également au Taux de Rendement Global (TRG) pour piloter sa
performance, correspondant en anglais à l’acronyme TEEP, Total Effective Equipment
Performance. Cet indicateur dont les caratéristiques sont similaires à celles du TRS,
consiste en la multiplication de quatre taux :
•	Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée),
•	Le Taux de Performance « Tp » (variant en fonction des cadences),
•	Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le
nombre de pièces produites),
•	Le Taux de Charge « Tc » (mesure de la charge productive réelle, ratio entre temps
requis et temps d’ouverture).
Le TRG peut donc être défini comme suit : TRG = Td * Tp * Tq * Tc
Apport du TRS à la DSI
L’apport principal de cette approche industrielle est de fournir un système de pilotage
permettant d’appréhender globalement la performance au travers d’un indicateur
synthétique.
L’identification d’un indicateur unique de performance, différencié des indicateurs de
gouvernance existants est jugée comme un apport déterminant au management des
directions informatiques :
•	En termes de gouvernance et de communication externe avec les clients, la DSI et
la Direction Générale,
•	Entermesdepilotageetdedécisioninternevisantàl’améliorationdelaproductivité,
•	En termes de benchmark et de possibilité de se comparer en interne dans le temps,
voire en externe.
Le TRS apporte une aide particulièrement pertinente pour les DSI qui mettent en
œuvre une démarche collaborative DevOps, par l’adoption d’un indicateur commun
entre équipes Etudes et Production habituées à travailler chacune de leur côté en silos
en matière de méthodes, d’outils et de mesure de la performance.
Livre Blanc
Follow Us14
Application du TRS à la Digital Factory
Le principe du TRS s’inscrit de manière naturelle en environnement DevOps. En premier
lieu, la mesure est un pilier du mouvement DevOps. En second lieu, le concept de Digital
Factory rejoint la dimension industrielle propre au TRS. Enfin, avec le TRS, l’accent est
mis sur la chaine de delivery logiciel et sur la capacité de la DSI, comme moyen de
production, à allier vélocité et fiabilité.
Plusieurs approches ont été envisagées pour transposer le TRS en environnement
DevOps selon que l’on considère la chaine de delivery logiciel de manière globale ou
par segments. Les travaux du Think Tank Automic présentés dans le cadre de ce livre
blanc, se sont intéressés à l’approche de bout-en-bout du processus (TRS end-to-end)
depuis la validation des demandes (Plan) jusqu’à l’activation du service en production
(Operate).
Il est à noter que d’autres travaux complémentaires ont été menés par Automic pour
mesurer le TRS uniquement sur la partie aval de ce processus (TRS release pipeline).
La méthode pourrait également être appliquée à d’autres segments (gestion des
demandes, synchronisation SPRINT / RELEASE) si ces derniers répondent à des enjeux
et des contraintes prioritaires des organisations.
Plan Code Build Test Release Deploy Operate
TRS
Gestion des demandes
TRS
Synchronisation SCRUM/RELEASE
TRS
Release Pipeline
TRS
end-to-end
Livre Blanc
Follow Us15
Chapitre 3 : Implémentation du
TRS en environnement DevOps
La méthode proposée ci-après est issue des premiers cas de mise en œuvre du
TRS. Cette méthode est la capitalisation de retours d’expérience et non un exercice
théorique : à mesure que les membres pionniers trouvaient les moyens d’appliquer le
TRS dans leurs environnements propres, les bonnes pratiques étaient communiquées
au sein de la communauté du Think Tank et des jalons étaient posés pour permettre aux
autres membres de suivre leur trace. En passant par les mêmes étapes, ces membres
ont permis de challenger la méthode et de l’améliorer.
Progressivement, une méthodologie s’est dégagée avec l’objectif affiché de multiplier
les cas d’adoption sur un même périmètre, et d’accélérer le temps de mise en
application. En définitive, l’application de la méthode a permis de constater un gain de
temps important dans la mise en œuvre en évitant pièges et fausses pistes pour aller
droit à l’essentiel.
Cette méthodologie est organisée en 10 étapes, permettant de suivre la progression
des membres de 1 à 10 et d’identifier les blocages. Elle s’est enrichie des feedbacks
des différents groupes de travail pour aboutir à un consensus dans l’identification des
étapes, leur contenu et leur ordre.
Les étapes sont présentées succintement dans le tableau ci-dessous et décrites dans
la suite du document.
Méthode d’adoption du TRS en 10 étapes
Etape 1 Intention
Identifier le besoin d’amélioration de la performance justifiant la
mise en place d’une approche « TRS »
Etape 2
Identification du périmètre
d’application
Identifier précisément le périmètre d’application du TRS et
partager si nécessaire le périmètre en plusieurs lots
Etape 3 Implication
Assurer le bon niveau de sponsorat et mobiliser les parties
prenantes
Etape 4 Partage du vocabulaire
S’assurer que le vocabulaire est compris et partagé pour chacune
des composantes du TRS (disponibilité, performance, qualité)
appliqué au périmètre choisi
Etape 5
Etat des lieux des systèmes
de mesure
Identifier l’aptitude du système de mesure à remonter les
éléments entrant dans le calcul du TRS
Etape 6
Collecte des points de
mesure
Mettre en place les moyens de mesure du TRS à partir de
l’outillage existant
Etape 7 Premières Mesures Produire une première mesure du TRS sur le périmètre choisi
Etape 8 Analyse des gaspillages
Analyser les écarts de performance à partir du TRS et utiliser
l’arbre de gaspillage pour en identifier les causes
Etape 9 Systèmes de Pilotage
Inscrire le pilotage de la performance opérationnelle dans une
démarche d’amélioration continue
Etape 10 Industrialisation
Mettre en place l’organisation et l’outillage permettant de
pérenniser la mesure
Livre Blanc
Follow Us16
La méthode proposée n’est pas un cadre normatif, chaque nouvel adoptant pouvant
adapterladémarcheàsoncontexte,àsesspécificités,ainsiqu’àsonsystèmedemesure.
Nous pensons toutefois que les modèles présentés vous permettront de gagner du
temps et que l’application des mêmes principes pourra faciliter la comparaison entre
les organisations adoptant le TRS.
Etape 1 : Intention
La première étape consiste à apporter des éléments de réponse à la question suivante :
Quel objectif recherchez-vous dans la mise en place d’un TRS ?
On cherche ici à identifier et à valider les enjeux opérationnels ou transformationnels
qui seront facilités par cet indicateur. Attention ! On parle bien ici de l’objectif recherché
dans la mise en place du TRS et non de l’objectif recherché dans la mise en place de
DevOps.
Les objectifs suivants sont généralement à l’origine de la mise en place du TRS en
environnement DevOps :
•	Partager un indicateur commun entre Dev et Ops,
•	Partager de bout-en-bout une même vision de la performance de la chaine de
delivery logiciel,
•	Partager des objectifs communs d’amélioration globale,
•	Mesurer la performance dans ses différentes dimensions sans la réduire au Time-
to-Market,
•	Faciliter l’analyse de la performance et l’identification de leviers d’amélioration
continue,
•	Facilier la gouvernance d’un programme de mise en œuvre de DevOps,
•	Obtenir une valeur de référence (baseline) et valoriser les bénéfices d’un pilote
DevOps,
•	Améliorer la satisfaction client et l’efficience de l’organisation,
•	Benchmarker les résultats obtenus en interne ou avec des pairs.
Etape 2 : Identification du périmètre
d’application
A cette étape, il s’agit d’identifier le périmètre pour lequel on mesurera le TRS.
Afin de progresser efficacement, il est conseillé de partager le périmètre d’application
en plusieurs lots.
Livre Blanc
Follow Us17
Ces lots peuvent être a minima :
•	Un lot « pilote » correspondant à un périmètre restreint, qui permettra de tester
la méthode,
•	Un deuxième lot qui peut être le périmètre cible, et où l’on passera en mode
« industriel » avec potentiellement, un outillage plus performant.
Le domaine des applications et portails web a été le pilote le plus fréquemment choisi
pour l’implémentation du TRS en environnement DevOps. Le TRS a pu également être
généralisé sur l’ensemble des domaines applicatifs dans le cadre d’un programme de
transformation DevOps.
Etape 3 : Implication
Il s’agit à ce stade de s’assurer du bon niveau de sponsorat et de mobiliser les parties
prenantes. Le niveau d’implication dépendra bien entendu de l’approche adoptée
(expérimentation par un opérationnel, déploiement par une entité transverse) et de
l’avancement du projet.
Dans un premier temps, il convient de s’assurer d’avoir :
•	Identifié le niveau de sponsorat,
•	Justifié de l’approche et de l’investissement,
•	Obtenu validation de la démarche.
Il est fondamental d’impliquer les Etudes et la Production dès le début. Constituer un
binôme avec un manager Dev et un manager Ops en co-responsabilité du sujet s’est
révélé être très efficace pour conduire le changement. Le sujet peut également être
porté uniquement par un responsable Dev ou un responsable Ops à condition de s’être
assuré du soutien de l’autre partie prenante. La présentation de la présente méthode en
10 étapes lors de sessions d’information a permis de familiariser les organisations avec
le concept et d’accélérer son appropriation.
Par ailleurs, il faut s’assurer que les personnes amenées à mettre en place le TRS et les
leviers d’amélioration associés sont disponibles a minima. Le nombre de personnes à
impliquer est fonction :
•	Du périmètre d’application (cf. Etape 2),
•	De la difficulté à mesurer,
•	Du niveau d’industrialisation souhaité pour la mesure,
•	Du temps dont on dispose pour mettre en place la mesure.
Livre Blanc
Follow Us18
Etape 4 : Partage du vocabulaire
Avant de commencer à définir et mesurer les différents taux du TRS et du TRG, Il
faut s’assurer que le vocabulaire est bien compris et partagé pour chacune des trois
composantes de l’indicateur de TRS (Disponibilité, Performance, Qualité) et chacune
des quatre composantes de l’indicateur de TRG (Charge, Disponibilité, Performance,
Qualité).
Ces notions sont ici utilisées dans leur définition industrielle. L’application à DevOps du
TRS et/ou du TRG nécessite de s’accorder sur ce que sont la Charge, la Disponibilité
et la Performance de la chaine de delivery elle-même (l’efficacité opérationnelle des
activités) et ce qu’est la Qualité en bout de cette chaine de production (ce qui est
produit).
Une traduction de ce vocabulaire industriel appliqué à la chaine de delivery logiciel est
proposée ci-dessous :
•	Charge : Utilisation efficiente des ressources,
•	Disponibilité : Disponibilité de la plateforme ou des environnements à chaque étape,
•	Performance : Ponctualité des Mises en Service par rapport à la date prévue,
•	Qualité : Niveau de qualité d’expérience utilisateur et de respect des exigences
non-fonctionnelles des packages livrés en production.
Le schéma ci-dessous associe les différentes composantes du TRS et du TRG aux
différentes étapes d’une chaine de delivery logiciel et aux différents niveaux d’activités
(applicatif, plateforme, infrastructure) qui y contribuent. La qualité apparait bien
comme la qualité du produit en bout de chaine. A l’inverse, la Charge, la Disponibilité et
la Performance mesurent l’efficacité de l’ensemble de la chaine à un niveau d’activité
donné.
Agile Coding Cont. Integration Cont. Delivery Cont. Deployment
Application-
level
Activities
Performance
Plateform-
level
Activities
Disponibilité
Infra-
level
Activities
Charge
Qualité
Livre Blanc
Follow Us19
Ce sont ces définitions qu’il convient de partager avec les équipes Etudes et Production.
IlnefautpasconfondrecesnotionsaveclesnotionshabituellesdeCharge,Disponibilité,
Performance et Qualité telles qu’elles sont utilisées dans l’informatique. Au contraire, il
faut regarder ces notions avec un regard neuf et définir quels critères représentent le
mieux, dans son environnement DevOps propre, les différents axes constitutifs du TRS
et/ou du TRG.
Etape 5 : Etat des lieux du système de mesure
Cette étape identifie l’aptitude du système de mesure à remonter les éléments entrant
dans la mesure du TRS. La réponse à cette question doit tenir compte de la capacité à
mesurer simplement ces différentes composantes.
Pour cela, chaque organisation peut s’appuyer sur la check-list présentée dans la figure
ci-dessous. Cette check-list est un outil permettant de choisir parmi dix indicateurs
proposés les mesures qui sont les plus pertinentes et les plus faciles à obtenir dans un
contexte donné. Dans un premier temps, il suffit de cocher au moins un indicateur par
composant. Le taux de Charge n’est utile que pour les organisations souhaitant mesurer
le TRG. Le taux de Qualité sera d’autant plus équilibré qu’il associera un indicateur
correspondant aux exigences non fonctionnelles et un indicateur correspondant à
l’expérience utilisateur.
Taux de
Performance
Taux de
Disponibilité
Taux de
Charge
Taux de
Qualité TRG
Taux de
Performance
Taux de
Disponibilité
Taux de
Qualité TRS
Utilisation
efficiente des
ressources
C1 - Taux
d’utilisation des
ressources /
plateformes
Exigeances non
fonctionnelles
Q1 - Qualité du
code
Q2 - Préparation
de la MEP
Expérience
utilisateur
Q3 - Performance
applicative
ressentie par
l’utilisateur
Q4 - Incidents
suite à MEP
Disponibilité de la
plateforme à
chaque étape
D1 - Rapidité de
mise à
disposition des
environnements
D2 - Disponibilité
des
environnements
Ponctualité des
Mises en
Production
PA - Respect des
dates de MEP
P2 - Cadence des
MEP par
rapports aux
spints
P3 - Profondeur
des décalages de
date de livraison
Livre Blanc
Follow Us20
Un bref descriptif des indicateurs de la check-list est présenté dans le tableau ci-
dessous :
Une fois les indicateurs choisis dans la check-list, les questions suivantes doivent être
considérées :
•	 Pouvez-vous mesurer chacun des taux définis ?
•	 Quels sont les points de mesure ?
Indicateurs de la check-list Descriptif
C1. Taux d’utilisation des ressources /
plateformes
Mesurer le taux d’utilisation des ressources pour valider le bon
dimensionnement des ressources des environnements de la
chaine de production DevOps.
D1. Rapidité de mise à disposition des
environnements
Mesurer le taux des demandes d’environnement traitées en
respectant l’accord de service. L’enjeu est d’accélérer les temps
de déploiement des environnements et de réduire le délai de
prise en charge des demandes d’environnement.
D2. Disponibilité des environnements
Mesurer le taux de disponibilité des environnements, obtenu en
divisant la durée durant laquelle l’environnement est opérationnel
par la durée totale durant laquelle on a exprimé un souhait qu’il le
soit (hors plage de maintenance convenue au préalable).
P1. Respect des dates de MEP
Mesurer le nombre de MEP à date prévue par rapport au nombre
total de MEP pour valider la capacité de l’organisation DevOps à
accélérer le Time to Market.
P2. Cadence des MEP par rapport aux
sprints
Mesurer la capacité des organisations à synchroniser SPRINT et
RELEASE en suivant le rapport du nombre de MEP / nombre de
Sprints.
P3. Profondeur des décalages de date de
livraison
Identifier les écarts de livraison en nombre de jours par rapport à
la date de livraison initialement prévue.
Q1. Qualité du code
Evaluer la qualité du code pour pouvoir mesurer la dette
technique en s’appuyant sur la méthode SQALE.
Q2. Préparation de la MEP
Mesurer la qualité de la préparation des MEP selon 4 axes :
- l’anticipation des besoins d’infrastructures,
- l’anticipation des besoins d’exploitation,
- la bonne mise en place d’un PCA et/ou PRA,
- la bonne mise en place de la supervision.
Q3. Performance applicative ressentie
par l’utilisateur
Evaluer la performance applicative ressentie par l’utilisateur -
Mesure de la satisfaction de l’utilisateur en fonction des temps
de réponse d’un ensemble de requêtes sur une période de temps
donnée (cf. Application Performance Indexer - http://www.apdex.
org).
Q4. Incidents suite à MEP
Mesurer l’impact des MEP sur la qualité de service en suivant le
rapport du nombre d’incidents post MEP / nombre d’incidents
moyen.
Livre Blanc
Follow Us21
•	 Où se trouve la donnée relative à ces points de mesure (solution/outil, …) ?
•	 Quelle est la fiabilité de cette donnée ? Dispose-t-on de suffisamment de points
de mesure ?
•	 Quelle est la fréquence de mise à jour de cette donnée ? Quelle en sera la
fréquence de mesure ?
•	 Par quel moyen de collecte (automatique, manuelle, …) pouvez-vous récupérer
cette donnée ?
•	 Quelle équipe / personne en a la responsabilité ?
Le tableau ci-dessous présente un modèle simple qui peut être utilisé pour présenter
les réponses à ces questions.
Etape 6 : Collecte des points de mesure
Dans cette étape, les moyens de mesure du TRS sont mis en place : paramétrage de
nouveaux rapports, mise en place de traçabilité, etc.
Compte tenu des contraintes liées au système de Mesure, il est in fine nécessaire
d’identifier,pourchaquecomposant,lesdonnéesetlesformulesdecalculcorrespondant
au mieux à la définition de celui-ci.
Les discussions communes entre Dev et Ops sur les points de mesure sont un bon
moyen de constater les manques et les doublons, les erreurs et les opportunités.
Dans un premier temps, une mesure en première approximation s’avère généralement
suffisante.
QUALITE PERFORMANCE DISPONIBILITE
Mon TRS
Taux de Qualité : Nombre
d’incidents en période de
Vérification de Service
Régulier (VSR) post MEP
Taux de MEP à date prévue
Taux de Disponibilité des
environnements de Dev /
Recette
Données
Nombre de tickets > au
nombre de tickets moyen sur
2 jours après les MEP
Nombre de MEP planifiées
réalisées à date / mois
Durée d’indisponibilité /
mois
Acteurs Equipe Support (Outil ITSM) Equipe Dev (Outil ALM) Equipe Ops (Supervision)
Livre Blanc
Follow Us22
Etape 7 : Premières mesures
Une première mesure du TRS est produite.
Dans un premier temps, une mesure permettant une première approximation des
indicateurs peut suffire. Ce qui importe, c’est de fédérer les personnes autour d’une
démarche et de progressivement affiner et automatiser la mesure (cf. étapes suivantes).
Nouspréconisonsdoncdecommencerlecalculetl’analyseduTRSmêmesitouteslesdonnées
ne sont pas disponibles, ou qu’elles n’ont pas encore le « niveau de précision » souhaité.
Dans certains cas, des données sur les derniers mois ou les dernières semaines sont
disponibles dans les systèmes de mesure. Dans ce cas, calculez le TRS a posteriori
sur les derniers jours / semaines / mois afin de voir si le TRS est stable ou s’il varie en
fonction de la période.
Etape 8 : Analyse des gaspillages
Le but ultime du TRS n’est pas de mesurer mais bien d’analyser la performance et de
rentrer dans une démarche d’amélioration continue.
L’atelier « arbre des gaspillages » présenté ci-après est une manière pragmatique
d’initier un telle analyse en trois phases :
•	Identifier les gaspillages, c’est-à-dire les causes de défaillance potentielles des
Taux élémentaires du TRS : Performance, Disponibilité, Qualité,
•	Identifier les leviers d’amélioration, c’est-à-dire les moyens d’action potentiels qui
permettent d’agir sur les causes des gaspillages,
•	Identifier les indicateurs d’amélioration, c’est-à-dire les moyens de contrôle qui
permettent de s’assurer que nous avons bien agi sur les causes au moyen des leviers.
Une fois l’analyse terminée, des actions d’amélioration (leviers) seront implémentées, et
leur effet sur les activités sera contrôlé / mesuré.
L’atelier « TIMWOOD » est une approche complémentaire à l’atelier « arbre de gaspillages
» en ce qui concerne la première phase d’identification des gaspillages.
MOIS TAUX DE QUALITE
TAUX DE
DISPONIBILITE
TAUX DE
PERFORMANCE
TRS
Avril 90% 80% 81,25% 58,5%
Mai 95% 90% 87,65% 74,94%
Juin 95% 85% 97,65% 78,85%
Livre Blanc
Follow Us23
Atelier Arbre des Gaspillages
L’arbredesgaspillagesestunebonnepratiqueissuedumondeindustriel.Lesgaspillages
sont pré-cartographiés, et associés a priori à chaque dimension du TRS. L’arbre facilite
l’identification des gaspillages et l’exhaustivité de l’identification. Il permet d’analyser le
travail et de comprendre les obstacles qui empêchent d’accomplir le travail au rythme
voulu.
TRS Disponibilité
Qualité
Performance
Composant
Savoir-faire
Synchronisation
Planning / Ordonnancement
Capacité
Pannes Techniques
Attentes
Arrêts (humain)
Approvisionnements
Méthode
Procédures
Surconsommation
Productivité
Rapidité
Facteur humain
Livre Blanc
Follow Us24
La réussite d’ateliers d’amélioration s’appuyant sur l’arbre des gaspillages repose
principalement sur les participants et l’interactivité des échanges. Ces ateliers
d’amélioration ont une durée de deux heures et ont pour but :
•	D’impliquer les acteurs et de les sensibiliser au calcul de l’indicateur et à son
utilisation,
•	De définir le système de mesure qui permet de calculer cet indicateur et de mettre
en place les premières mesures,
•	D’identifier les gaspillages et les leviers d’amélioration,
•	De suivre la mise en place des leviers d’amélioration et l’évolution du TRS dans le
temps.
L’atelier d’amélioration est piloté par le responsable de la mise en place du TRS. Les
participants à l’Atelier sont les personnes qui mesurent le TRS, accompagnées de deux
ou trois personnes qui travaillent sur le processus mais qui ne mesurent pas. Elles n’ont,
de ce fait, pas été associées préalablement à la démarche. Ces deux ou trois personnes
vont donc avoir un angle d’approche légèrement décalé par rapport au reste du groupe,
ce qui peut être bénéfique dans l’apport de solutions. Le déroulement type d’un atelier
d’amélioration est décrit ci-après.
Livre Blanc
Follow Us25
Déroulement type d'un atelier d'amélioration
2nde
identification des gaspillages
(avec l’arbre des gaspillages)
Objectif  : Utiliser l’arbre des gaspillages IT pour 
consolider la liste des gaspillages identifiés
Corréler les gaspillages identifiés pendant l’Atelier
avec les natures de gaspillages présentés sur
l’arbre
Susciter de nouvelles propositions
Partage des premières mesures
Objectif  : Partager une vision objective de la
Performance (factualiser)
Présenter le TRS global, accompagné des Taux
obtenus pour la Disponibilité, la Qualité, et la
Performance
Rappeler les grands principes de base appliqués
pour le calcul de ces trois taux afin que les
participants qui ne mesurent pas comprennent ce
que représentent ces résultats.
Introduction
Objectif : Rappeler l’enjeu de l’Atelier
Les difficultés perçues sur le processus,
L’intérêt de mettre en place un TRS et les gains
escomptés,
L’intérêt de définir collégialement les gaspillages et
les améliorations, en associant les acteurs du
processus
1ère
Identification des gaspillages
(sans l’arbre des gaspillages)
Objectif  : Apporter des réponses par le biais
d’échanges interactifs, où chacun s’exprime
librement par rapport à son expérience.
Commencer par l’axe dont le taux est le plus en
retrait (la Qualité par exemple). Quelles sont les
raisons pour lesquelles la Qualité est insuffisante ? 
Continuer axe par axe en suivant cet ordre de
priorité
Parmi les réponses apportées, certaines peuvent
concerner un autre axe. Peu importe, la proposition
est notée pour être abordée un peu plus tard,
lorsque l’axe en question sera étudié.
Identifier les leviers d’amélioration
Objectif : Définir un plan d’actions prioritaires
Identifier une ou plusieurs actions pour chaque
gaspillage
Répertorier les quick-wins en fonction de la
complexité de mise en œuvre de chaque action et
de la plus-value apportée
Proposer un premier plan d’amélioration (la
finalisation et la mise en œuvre nécessiteront des
réunions complémentaires)
Livre Blanc
Follow Us26
Atelier TIMWOOD
Une approche alternative consiste à organiser un atelier d’identification des
gaspillages en s’appuyant sur la méthode TIMWOOD, issue du Lean Management.
Le Lean Management suggère en effet, pour optimiser les processus de l’entreprise
et créer efficacement de la valeur, d’identifier systèmatiquement toutes les sources
de gaspillages afin de les éliminer ou les réduire. L’industrie distingue sept types de
gaspillages appelés Muda. L’acronyme TIMWOOD correspond en anglais aux initiales
de ces sept gaspillages.
Cette méthode a été appliquée par les membres du Think Tank pour identifier les
gaspillages au sein du flux DevOps “Idea to Production”. Le résultat de l’atelier est
illustré en page suivante.
TIMWOOD
Transportation
Fait référence aux déplacements des produits finis ou semi-finis soumis à des
risques de détériorations, de pertes, de délais supplémentaires et de charges de
travail supplémentaires.
Inventories
Fait référence aux stockages intermédiaires et aux inventaires effectués en
cours de processus. Ceux-ci ne contribuent pas à la transformation du produit
et générent des surcoûts n’apportant aucune valeur ajoutée.
Motion
Fait référence aux déplacements inutiles des moyens humains et matériels
en cours du processus de fabrication et qui peuvent avoir des impacts de
détérioration, d’usure et de sécurité inutiles.
Waiting
Fait référence au temps d’attente de l’activité ou de la tâche suivante pour les
produits ou services qui ne sont pas en cours de transport, de fabrication ou de
transformation dans leur processus.
Over-production
Fait référence à la surproduction de produits fabriqués par rapport à la demande
/ commandes clients.
Over-processing
Fait référence aux activités et tâches inutiles et/ou qui n’apportent pas de
valeur ajoutée au client ainsi qu’aux outils d’utilisation (logiciels, procédures,
instructions de travail) qui sont trop précis, trop complexes, ou plus coûteux
que nécessaire.
Defects
Chaque fois que des défauts et rejets des produits finis et semi-finis arrivent, des
coûts supplémentaires sont supportés pour retravailler les produits, détruire les
défectueux, reprogrammer la production, ...
Livre Blanc
Follow Us27
Le Lean Management suggère, pour créer efficacement de la valeur, d’identifier les sources de gaspillages et de les
éliminer ou les réduire afin d’optimiser les processus de l’entreprise. L’industrie distingue 7 types de gaspillages issus
de la méthode Lean et appelés Muda qui peuvent être transposés en DevOps selon le moyen mnémotechnique
TIMWOOD.
• Incapacité du modèle de transport des packages applicatifs à atteindre les
objectifs de volumétrie, fréquence, délai et productivité
• Inaptitude de fournisseurs de code (ex. TMA) à s’aligner sur les objectifs
• Hétérogénéité des outils et procédures utilisées, nombreuses tâches manuelles
• Surcapacité des environnements hors production
• Environnements créés mais non utilisés ou non décommissionnés
• Environnement de développement ou de tests surdimensionnés
• Doublonnement et non fiabilité des référentiels nécessaires au fonctionnement
de la chaine d’automatisation
• Chaqueoutil,chaqueéquipedelachaînededéploiementpossèdesonréférentielpropre
• Les référentiels des versions applicatives et des infrastructures ne sont pas à jour
• Hétérogénéité des pratiques agiles des équipes de développement impliquant
une perte d’efficacité aux interfaces avec la production et les métiers
• Impossibilité pour les équipes Ops d’industrialiser leurs activités
• MOA et Métiers en décalage avec ces pratiques
• Réalisation de tâches humaines répétitives et systèmatiques
• Tests (non regression, performance, techniques)
• Déploiementsapplicatifs,miseàdispositiondesenvironnements
• Mobilisationexcessivedescontributeursparmanquedecapitalisationdel’information
• Allers-retours entre équipes de développement et métiers pour qualifier le besoin
• Réunions d’analyse d’impact et de validation
• Mauvaise priorisation : les fonctionnalités à forte valeur ajoutée attendent la fin du
développement des stories moins critiques
• Membresducomitédepriorisationnonreprésentatifs,manquedeconnaissancedumétier
• Retard dans la mise à disposition d’environnements de recette ou de production
• Manque d’anticipation, de communication et d’automatisation du provisionning
• Fonctionnalités validées en attente de mise en production
• Les packages attendent une fenêtre de livraison
• Un ou plusieurs incidents en cours bloquent toute mise en production
• Blocage de l’ensemble d’une mise en production en raison d’éléments défectueux
• Manque de réactivité aux étapes clés du cycle de développement
• Sprint reviews, recette fonctionnelle, validation
• Manque de disponibilité des équipes métiers, des experts, du management
• Fréquence de livraison non alignée avec les besoins réels du métier
• Livraison applicative trop fréquente sans valeur pour le métier
• Fréquence de livraison trop basse impactant le business des métiers
• Gestion des changements et gestion des projets trop bureaucratiques
• Automatisation locale n’améliorant pas la performance de bout-en-bout
• Automatisation avancée de l’intégration continue alors que la contrainte est sur
les tests ou le déploiement
• Mise à disposition de fonctionnalités non demandées
• Miseàdispositiondefonctionnalitésdemandéesnecorrespondantpasàunbesoinréel
• Rédaction de documentations utilisateur qui ne sont pas lues
• Blocage de production avec impact sur les clients finaux
• Régression majeure non identifiée lors de l’analyse d’impact du changement
• Erreur manuelle lors du déploiement
• Régressionsfonctionnellesdansl’applicationmiseàjouroudanslessystèmesconnexes
• Introduction d’une dette technique générant un surcoût de maintenance
• Non respect des exigences non fonctionnelles
T ransportation
M otion
O verprocessing
I nventories
W aiting
O verproduction
D efects
Lean IT : Cartographie des Gaspillages
DevOps
automic.com
Livre Blanc
Follow Us28
Etape 9 : Système de pilotage
Il convient à ce stade de définir et mettre en place les modalités et les instances de
gouvernance associées au TRS :
•	Répondant à l’intention initiale de pilotage de la Performance (cf. Etape 1),
•	Conforme à la culture de pilotage de l’organisation.
Cette étape vise à s’assurer qu’un certain nombre de préalables sont rassemblés pour
que l’analyse de cause s’inscrive dans une boucle d’amélioration continue efficace :
•	Inscrire la démarche dans un cadre de pilotage de la Performance,
•	Identifier un sponsor et mobiliser les ressources nécessaires,
•	Partager le vocabulaire et former les contributeurs de la démarche aux nouveaux
concepts,
•	Communiquer sur les modalités de mise en œuvre et les résultats attendus.
Le sponsor de l’initiative devra clairement établir la cible de l’amélioration de la
Performance attendue ainsi que le périmètre des acteurs et contributeurs concernés
(organisation interne, infogérants, tiers identifiés, etc.).
La conduite du changement peut s’effectuer à travers des séances de sensibilisation à
la démarche, des formations à partir de cas concrets. Le mode de pilotage ciblé est à
expliciter versus une démarche classique selon les objectifs poursuivis : partage d’un
objectif d’amélioration continue commun, mesure de l’efficacité opérationnelle, etc.
Des objectifs peuvent être également fixés aux contributeurs de la démarche en
terme d’amélioration du TRS et ce afin de renforcer l’intégration de ces pratiques
dans les activités courantes. Différentes modalités de pilotage sont présentées ci-
après au travers de différents cas. Ces cas illustrent différentes orientations que peut
recouvrer le pilotage de la Performance à travers l’utilisation du TRS. Par ces différents
exemples, on constate que le TRS peut être utile dans le pilotage d’une ou plusieurs
entités opérationnelles, d’un ou plusieurs fournisseurs, d’un ou plusieurs streams. Le
point commun à ces différents systèmes est d’inscrire le pilotage de la Performance
opérationnelle dans une démarche d’amélioration continue.
Livre Blanc
Follow Us29
Etape 10 : Industrialisation
L’Industrialisation consiste à mettre en place l’organisation et l’outillage adapté à la
collecte et au traitement des données.
Elle se justifie :
•		Lors d’une extension de périmètre : passage du périmètre pilote au périmètre cible,
•	Et/ou si la pérennisation de la mesure a été actée, l’objectif étant d’inscrire le TRS
dans une gouvernance ad hoc ou préexistante.
L’organisation comprend :
(1) Un responsable du TRS, clairement identifié dont la mission est de :
•	Veiller à la réalisation des mesures selon la fréquence convenue et à la publication
du tableau de bord,
•	Animer l’identification de leviers potentiellement nécessaires en cas de dérive du
TRS,
Intention initiale Culture de pilotage
Cas 1 :
Atelier d’Amélioration
Améliorer l’efficacité opérationnelle
d’un projet pilote DevOps incluant Dev
et Ops
Culture de l’amélioration continue
encourageant la prise d’initiative
Cas 2 :
Organisation en
domaines applicatifs
Améliorer le pilotage des différents
domaines en utilisant des indicateurs
de progrès
Gouvernance centralisée en charge du
pilotage de la performance
Cas 3 :
Programme de
transformation
Fédérer les différents streams d’un
programme de transformation DevOps
autour d’objectifs de progrès partagés
Revues individuelles des objectifs des
streams mais difficulté à démontrer
l’efficience globale de la démarche
Cas 4 :
Relation avec les sous-
traitants et partenaires
Piloter les actions d’amélioration
des fournisseurs en mesurant leur
contribution à la performance
d’ensemble
Comités stratégiques et comités de
pilotage sur la base d’engagements
contractuels
Livre Blanc
Follow Us30
•	Contrôler l’application des leviers d’amélioration définis,
•	Exprimer les éventuels besoins liés à un outillage plus automatisé pour la mesure.
(2) Une ou plusieurs équipes impliquées dans la mesure (collecte et traitement),
l’analyse et l’arbitrage.
L’outillage adapté à la collecte et au traitement des données peut s’appuyer sur :
•	Les systèmes de métrologie existants (ex. BI),
•	Les systèmes de métrologie propres à des outils spécifiques au périmètre
cible (ex. APM, Qualité de Code, Release Automation, Orchestration, IT Service
Management, etc...),
•	Les outillages internes à une entreprise basés sur des tableurs ou des bases de
données.
Le tableau ci-dessous propose une typologie d’outils sources permettant de recueillir
les données nécessaires au calcul du TRS et du TRG :
Pour terminer, le TRS peut être utilisé à des fins de benchmark. Dans ce cas précis,
l’industrialisation doit prévoir de normaliser les mesures et d’obtenir des valeurs qui
pourront être comparées entre pairs. L’usage d’outils partagés peut faciliter cette
démarche.
CHARGE DISPONIBILITE PERFORMANCE QUALITE
• Capacity Management
• Performance
Management
• Monitoring
• Service Request
Management
• Orchestration
• Release Management
• Release Automation
• Incident Management
• Code Quality
• Application Performance
Management
Livre Blanc
Follow Us31
A propos du Think Tank Automic
Créé en 2010, le Think Tank Automic est un groupe de réflexion constitué d’une
vingtaine de décideurs informatiques issus de différents secteurs d’activités, privés ou
publics, et consacré au pilotage de la performance.
En 2011, le Think Tank Automic met l’accent sur un indicateur innovant issu des
méthodes industrielles : le Taux de Rendement Synthétique (TRS).
En 2012, les membres passent de la théorie à la pratique et appliquent le TRS dans
leurs organisations : mesure et pilotage, normalisation des concepts et identification
de nouveaux besoins.
En 2013 et 2014, le Think Tank étend la communauté d’adoption de l’approche TRS
et propose un guide pratique d’implémentation du TRS incluant fiches pratiques et
méthodologie.
En 2015 et 2016, le groupe propose de mobiliser les équipes Etudes et Production
autour d’un même objectif en transposant à DevOps le Taux de Rendement Synthétique
(TRS). Le résultat de ces travaux est présenté dans ce nouveau guide “Quelle métrique
pour fédérer Dev & Ops ?”.
Pour plus d’information ou démonstration des solutions Automic, visitez notre site www.automic.com
Automic, leader de l’Automatisation des processus d’entreprise, aide les organisations à gagner en
compétitivité en automatisant leur informatique d’entreprise, de l’hébergement sur site au Cloud, en
passant par le Big Data et l’Internet des Objets. Avec ses bureaux dans le monde entier, le groupe
soutient les activités de 2 600 clients parmi lesquels Bosch, Netflix, eBay, AMC Theatres, Carphone
Warehouse, ExxonMobil, BT Global Services, Société Générale, NHS SBS, General Electric et Swisscom.
Automic est une société privée détenue par EQT. Pour plus d’informations : http://www.automic.com/fr
A propos d’Automic Institute
Automic Institute a pour mission de promouvoir l’expertise du groupe Automic en
s’appuyant sur l’ensemble des savoirs de l’entreprise pour partager convictions,
connaissances et expériences en Management des Opérations Informatiques.
•	Les Publications alimentent la communauté des managers des Opérations
Informatiques en faits et en opinions,
•	Les Communautés et Think Tank sont des réunions de décideurs informatiques
décidés à faire émerger les idées qui seront la réalité de demain en matière de
Management des Opérations Informatiques,
•	Les Trivial Pursuit™ Edition IT sont des outils pédagogiques innovants pour
sensibiliser les équipes informatiques : Lean IT, Cloud, Management de Projet,
ITIL®, …
Contacter Automic
Automic
Tour Pacific
11, cours Valmy
92800 Puteaux, France
Web
www.automic.com

Contenu connexe

Tendances

Scrum is not enough
Scrum is not enoughScrum is not enough
Scrum is not enough
Christophe Keromen
 
Levez vous les managers !
Levez vous les managers !Levez vous les managers !
Levez vous les managers !
Christophe Keromen
 
L'Agile et la culture d'entreprise
L'Agile et la culture d'entrepriseL'Agile et la culture d'entreprise
L'Agile et la culture d'entreprise
Etienne Laverdière
 
Conduite du changement, le grand tabou
Conduite du changement, le grand tabouConduite du changement, le grand tabou
Conduite du changement, le grand tabou
Microsoft Ideas
 
Program management-agile
Program management-agileProgram management-agile
Program management-agile
Basile du Plessis
 
Agile 91
Agile 91Agile 91
Conquérir le terrain de l'innovation pour une DSI centrale - ISlean consulting
Conquérir le terrain de l'innovation pour une DSI centrale - ISlean consultingConquérir le terrain de l'innovation pour une DSI centrale - ISlean consulting
Conquérir le terrain de l'innovation pour une DSI centrale - ISlean consulting
Louis-Alexandre Louvet
 
Agile culture-sd2015-v4-finale
Agile culture-sd2015-v4-finaleAgile culture-sd2015-v4-finale
Agile culture-sd2015-v4-finale
Etienne Laverdière
 
Portail 2.0 & conduite du changement : les 10 clés pour réussir
Portail 2.0 & conduite du changement : les 10 clés pour réussirPortail 2.0 & conduite du changement : les 10 clés pour réussir
Portail 2.0 & conduite du changement : les 10 clés pour réussir
PhilippeC
 
Petit-déjeuner OCTO Management 3.0 - Le Book
Petit-déjeuner OCTO Management 3.0 - Le BookPetit-déjeuner OCTO Management 3.0 - Le Book
Petit-déjeuner OCTO Management 3.0 - Le Book
OCTO Technology
 
Feeback scrumday2015
Feeback scrumday2015Feeback scrumday2015
Feeback scrumday2015
SAGNON Joel
 
Cap sur les bénéfices ou la transformation agile d'entreprise
Cap sur les bénéfices ou la transformation agile d'entrepriseCap sur les bénéfices ou la transformation agile d'entreprise
Cap sur les bénéfices ou la transformation agile d'entreprise
Pierre Bergé
 
De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...
De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...
De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...
Agile En Seine
 
Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...
Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...
Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...
Agile Montréal
 
(R)evolution vers une entreprise agile
(R)evolution vers une entreprise agile(R)evolution vers une entreprise agile
(R)evolution vers une entreprise agile
Jérôme Urvoas
 
Gestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courteGestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courte
CGI Québec Formation
 
Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...
Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...
Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...
Agile Montréal
 
Qu'est ce que l'entreprise agile ?
Qu'est ce que l'entreprise agile ?Qu'est ce que l'entreprise agile ?
Qu'est ce que l'entreprise agile ?
Franck Beulé
 
Le contrat agile ce n'est pas si simple que ça
Le contrat agile ce n'est pas si simple que çaLe contrat agile ce n'est pas si simple que ça
Le contrat agile ce n'est pas si simple que ça
Franck Beulé
 

Tendances (20)

Scrum is not enough
Scrum is not enoughScrum is not enough
Scrum is not enough
 
Levez vous les managers !
Levez vous les managers !Levez vous les managers !
Levez vous les managers !
 
Agile@scale
Agile@scaleAgile@scale
Agile@scale
 
L'Agile et la culture d'entreprise
L'Agile et la culture d'entrepriseL'Agile et la culture d'entreprise
L'Agile et la culture d'entreprise
 
Conduite du changement, le grand tabou
Conduite du changement, le grand tabouConduite du changement, le grand tabou
Conduite du changement, le grand tabou
 
Program management-agile
Program management-agileProgram management-agile
Program management-agile
 
Agile 91
Agile 91Agile 91
Agile 91
 
Conquérir le terrain de l'innovation pour une DSI centrale - ISlean consulting
Conquérir le terrain de l'innovation pour une DSI centrale - ISlean consultingConquérir le terrain de l'innovation pour une DSI centrale - ISlean consulting
Conquérir le terrain de l'innovation pour une DSI centrale - ISlean consulting
 
Agile culture-sd2015-v4-finale
Agile culture-sd2015-v4-finaleAgile culture-sd2015-v4-finale
Agile culture-sd2015-v4-finale
 
Portail 2.0 & conduite du changement : les 10 clés pour réussir
Portail 2.0 & conduite du changement : les 10 clés pour réussirPortail 2.0 & conduite du changement : les 10 clés pour réussir
Portail 2.0 & conduite du changement : les 10 clés pour réussir
 
Petit-déjeuner OCTO Management 3.0 - Le Book
Petit-déjeuner OCTO Management 3.0 - Le BookPetit-déjeuner OCTO Management 3.0 - Le Book
Petit-déjeuner OCTO Management 3.0 - Le Book
 
Feeback scrumday2015
Feeback scrumday2015Feeback scrumday2015
Feeback scrumday2015
 
Cap sur les bénéfices ou la transformation agile d'entreprise
Cap sur les bénéfices ou la transformation agile d'entrepriseCap sur les bénéfices ou la transformation agile d'entreprise
Cap sur les bénéfices ou la transformation agile d'entreprise
 
De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...
De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...
De l'Agile au Lean, une véritable transformation d'entreprise @Michelin - Mat...
 
Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...
Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...
Tout est lié! Processus, UX, DevOps, Architecture, BDD, QA, Lean...
 
(R)evolution vers une entreprise agile
(R)evolution vers une entreprise agile(R)evolution vers une entreprise agile
(R)evolution vers une entreprise agile
 
Gestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courteGestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courte
 
Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...
Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...
Lean Change Management en grande entreprise, faites l’Évolution, pas la Révol...
 
Qu'est ce que l'entreprise agile ?
Qu'est ce que l'entreprise agile ?Qu'est ce que l'entreprise agile ?
Qu'est ce que l'entreprise agile ?
 
Le contrat agile ce n'est pas si simple que ça
Le contrat agile ce n'est pas si simple que çaLe contrat agile ce n'est pas si simple que ça
Le contrat agile ce n'est pas si simple que ça
 

En vedette

Prece a nossa senhora
Prece a nossa senhoraPrece a nossa senhora
Prece a nossa senhora
Luzia Gabriele
 
09-18-16, 1 Peter 2;1-10, Building Our Faith
09-18-16, 1 Peter 2;1-10, Building Our Faith09-18-16, 1 Peter 2;1-10, Building Our Faith
09-18-16, 1 Peter 2;1-10, Building Our Faith
First Baptist Church Jackson
 
Exterior view of center of modern dentistry rancho cucamonga ca
Exterior view of center of modern dentistry rancho cucamonga caExterior view of center of modern dentistry rancho cucamonga ca
Exterior view of center of modern dentistry rancho cucamonga ca
Center of Modern Dentistry
 
Bachelor Certificate
Bachelor CertificateBachelor Certificate
Bachelor CertificateHammam Kaaki
 
Amarelo encantado
Amarelo encantadoAmarelo encantado
Amarelo encantado
Luzia Gabriele
 
Calendario Viernes 15 Enero 2016
Calendario Viernes 15 Enero 2016Calendario Viernes 15 Enero 2016
Calendario Viernes 15 Enero 2016
Concientización Turismo Paraná
 
El golden retriever tiene un caracter migable
El golden retriever tiene un caracter migableEl golden retriever tiene un caracter migable
El golden retriever tiene un caracter migable
lalofernandez69
 
Fundamentals of asset class investing
Fundamentals of asset class investingFundamentals of asset class investing
Fundamentals of asset class investing
Better Financial Education
 
Concepción del hombre y cuestionamiento sobre el ser
Concepción del hombre y cuestionamiento sobre el serConcepción del hombre y cuestionamiento sobre el ser
Concepción del hombre y cuestionamiento sobre el ser
Cristhianan
 

En vedette (9)

Prece a nossa senhora
Prece a nossa senhoraPrece a nossa senhora
Prece a nossa senhora
 
09-18-16, 1 Peter 2;1-10, Building Our Faith
09-18-16, 1 Peter 2;1-10, Building Our Faith09-18-16, 1 Peter 2;1-10, Building Our Faith
09-18-16, 1 Peter 2;1-10, Building Our Faith
 
Exterior view of center of modern dentistry rancho cucamonga ca
Exterior view of center of modern dentistry rancho cucamonga caExterior view of center of modern dentistry rancho cucamonga ca
Exterior view of center of modern dentistry rancho cucamonga ca
 
Bachelor Certificate
Bachelor CertificateBachelor Certificate
Bachelor Certificate
 
Amarelo encantado
Amarelo encantadoAmarelo encantado
Amarelo encantado
 
Calendario Viernes 15 Enero 2016
Calendario Viernes 15 Enero 2016Calendario Viernes 15 Enero 2016
Calendario Viernes 15 Enero 2016
 
El golden retriever tiene un caracter migable
El golden retriever tiene un caracter migableEl golden retriever tiene un caracter migable
El golden retriever tiene un caracter migable
 
Fundamentals of asset class investing
Fundamentals of asset class investingFundamentals of asset class investing
Fundamentals of asset class investing
 
Concepción del hombre y cuestionamiento sobre el ser
Concepción del hombre y cuestionamiento sobre el serConcepción del hombre y cuestionamiento sobre el ser
Concepción del hombre y cuestionamiento sobre el ser
 

Similaire à Quelle métrique pour fédérer Dev & Ops ?

Mise en place et utilisation d'une plateforme de travail collaboratif par Int...
Mise en place et utilisation d'une plateforme de travail collaboratif par Int...Mise en place et utilisation d'une plateforme de travail collaboratif par Int...
Mise en place et utilisation d'une plateforme de travail collaboratif par Int...
CYB@RDECHE
 
La DSI plateforme : DevOps, Agilité et Cloud
La DSI plateforme : DevOps, Agilité et CloudLa DSI plateforme : DevOps, Agilité et Cloud
La DSI plateforme : DevOps, Agilité et Cloud
Devoteam Revolve
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Sébastien Bourguignon
 
DevOps au coeur de la transformation digitale
DevOps au coeur de la transformation digitaleDevOps au coeur de la transformation digitale
DevOps au coeur de la transformation digitale
Samuel Metias
 
Gimsi business-intelligence
Gimsi business-intelligenceGimsi business-intelligence
Gimsi business-intelligence
nodesway
 
Favoriser la collaboration en entreprise 02-2018
Favoriser la collaboration en entreprise   02-2018Favoriser la collaboration en entreprise   02-2018
Favoriser la collaboration en entreprise 02-2018
Philippe Ouellette
 
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise AgileBrochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
OCTO Technology Suisse
 
20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOps20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOps
IBM France Lab
 
DEVOPS
DEVOPSDEVOPS
DEVOPS
TayssirLimem
 
10.ans.dans.le.retro
10.ans.dans.le.retro10.ans.dans.le.retro
10.ans.dans.le.retro
matbarbereau
 
Vincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops SherbrookeVincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops Sherbrooke
Vincent Biret
 
DU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLABDU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLAB
TREEPTIK
 
BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...
BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...
BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...
Xavier Gendron BeWe
 
DevOps-Infographie-Quadran.pdf
DevOps-Infographie-Quadran.pdfDevOps-Infographie-Quadran.pdf
DevOps-Infographie-Quadran.pdf
Ameur BENTOUTA
 
Intranet 2.0 quelques idées
Intranet 2.0 quelques idéesIntranet 2.0 quelques idées
Intranet 2.0 quelques idées
Comunited
 
Biz talk summit devops - continuous delivery
Biz talk summit   devops - continuous deliveryBiz talk summit   devops - continuous delivery
Biz talk summit devops - continuous delivery
Radoine Douhou
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche Devops
Romain Chalumeau
 
Pourquoi les solutions de collaboration déçoivent parfois les attentes
Pourquoi les solutions de collaboration déçoivent parfois les attentesPourquoi les solutions de collaboration déçoivent parfois les attentes
Pourquoi les solutions de collaboration déçoivent parfois les attentes
Softchoice Corporation
 
devops.pdf
devops.pdfdevops.pdf
devops.pdf
qsdqsd4
 

Similaire à Quelle métrique pour fédérer Dev & Ops ? (20)

Mise en place et utilisation d'une plateforme de travail collaboratif par Int...
Mise en place et utilisation d'une plateforme de travail collaboratif par Int...Mise en place et utilisation d'une plateforme de travail collaboratif par Int...
Mise en place et utilisation d'une plateforme de travail collaboratif par Int...
 
La DSI plateforme : DevOps, Agilité et Cloud
La DSI plateforme : DevOps, Agilité et CloudLa DSI plateforme : DevOps, Agilité et Cloud
La DSI plateforme : DevOps, Agilité et Cloud
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
 
DevOps au coeur de la transformation digitale
DevOps au coeur de la transformation digitaleDevOps au coeur de la transformation digitale
DevOps au coeur de la transformation digitale
 
Gimsi business-intelligence
Gimsi business-intelligenceGimsi business-intelligence
Gimsi business-intelligence
 
Gimsi
GimsiGimsi
Gimsi
 
Favoriser la collaboration en entreprise 02-2018
Favoriser la collaboration en entreprise   02-2018Favoriser la collaboration en entreprise   02-2018
Favoriser la collaboration en entreprise 02-2018
 
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise AgileBrochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
 
20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOps20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOps
 
DEVOPS
DEVOPSDEVOPS
DEVOPS
 
10.ans.dans.le.retro
10.ans.dans.le.retro10.ans.dans.le.retro
10.ans.dans.le.retro
 
Vincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops SherbrookeVincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops Sherbrooke
 
DU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLABDU DEVOPS AU FASTLAB
DU DEVOPS AU FASTLAB
 
BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...
BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...
BeWe - Place de la Communication - 180214 : "L'entreprise Collaborative et So...
 
DevOps-Infographie-Quadran.pdf
DevOps-Infographie-Quadran.pdfDevOps-Infographie-Quadran.pdf
DevOps-Infographie-Quadran.pdf
 
Intranet 2.0 quelques idées
Intranet 2.0 quelques idéesIntranet 2.0 quelques idées
Intranet 2.0 quelques idées
 
Biz talk summit devops - continuous delivery
Biz talk summit   devops - continuous deliveryBiz talk summit   devops - continuous delivery
Biz talk summit devops - continuous delivery
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche Devops
 
Pourquoi les solutions de collaboration déçoivent parfois les attentes
Pourquoi les solutions de collaboration déçoivent parfois les attentesPourquoi les solutions de collaboration déçoivent parfois les attentes
Pourquoi les solutions de collaboration déçoivent parfois les attentes
 
devops.pdf
devops.pdfdevops.pdf
devops.pdf
 

Plus de Jacky Galicher

révolution numérique : Comment le DSI markète son offre ?
révolution numérique : Comment le DSI markète son offre ?révolution numérique : Comment le DSI markète son offre ?
révolution numérique : Comment le DSI markète son offre ?
Jacky Galicher
 
Itfb 2233 p10_marketing dsi
Itfb 2233 p10_marketing dsiItfb 2233 p10_marketing dsi
Itfb 2233 p10_marketing dsi
Jacky Galicher
 
Aef 583814
Aef 583814Aef 583814
Aef 583814
Jacky Galicher
 
Quel marketing pour la dsi
Quel marketing pour la dsiQuel marketing pour la dsi
Quel marketing pour la dsi
Jacky Galicher
 
Données personnelles des élèves
Données personnelles des élèvesDonnées personnelles des élèves
Données personnelles des élèves
Jacky Galicher
 
Piloter la Performance des Opérations Informatiques
Piloter la Performance des Opérations Informatiques Piloter la Performance des Opérations Informatiques
Piloter la Performance des Opérations Informatiques
Jacky Galicher
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
Jacky Galicher
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
Jacky Galicher
 
Bien-être au travail
Bien-être au travail Bien-être au travail
Bien-être au travail
Jacky Galicher
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
Jacky Galicher
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
Jacky Galicher
 
Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ? Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ?
Jacky Galicher
 
Presentation confiance numerique clichy
Presentation confiance numerique clichyPresentation confiance numerique clichy
Presentation confiance numerique clichy
Jacky Galicher
 
Agilité, efficience et qualité à l'Académie de Versailles
Agilité, efficience et qualité à l'Académie de VersaillesAgilité, efficience et qualité à l'Académie de Versailles
Agilité, efficience et qualité à l'Académie de Versailles
Jacky Galicher
 
Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...
Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...
Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...
Jacky Galicher
 
Mettez des millennials dans votre DSI
Mettez des millennials dans votre DSIMettez des millennials dans votre DSI
Mettez des millennials dans votre DSI
Jacky Galicher
 
Stratégie devops-article-cio-dsi de versailles-5-juillet-2016
Stratégie devops-article-cio-dsi de versailles-5-juillet-2016 Stratégie devops-article-cio-dsi de versailles-5-juillet-2016
Stratégie devops-article-cio-dsi de versailles-5-juillet-2016
Jacky Galicher
 
Chargé mission de modernisation
Chargé mission de modernisationChargé mission de modernisation
Chargé mission de modernisation
Jacky Galicher
 
Protection des mineurs, sécurité des données
Protection des mineurs, sécurité des donnéesProtection des mineurs, sécurité des données
Protection des mineurs, sécurité des données
Jacky Galicher
 
Passion
PassionPassion

Plus de Jacky Galicher (20)

révolution numérique : Comment le DSI markète son offre ?
révolution numérique : Comment le DSI markète son offre ?révolution numérique : Comment le DSI markète son offre ?
révolution numérique : Comment le DSI markète son offre ?
 
Itfb 2233 p10_marketing dsi
Itfb 2233 p10_marketing dsiItfb 2233 p10_marketing dsi
Itfb 2233 p10_marketing dsi
 
Aef 583814
Aef 583814Aef 583814
Aef 583814
 
Quel marketing pour la dsi
Quel marketing pour la dsiQuel marketing pour la dsi
Quel marketing pour la dsi
 
Données personnelles des élèves
Données personnelles des élèvesDonnées personnelles des élèves
Données personnelles des élèves
 
Piloter la Performance des Opérations Informatiques
Piloter la Performance des Opérations Informatiques Piloter la Performance des Opérations Informatiques
Piloter la Performance des Opérations Informatiques
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
 
Bien-être au travail
Bien-être au travail Bien-être au travail
Bien-être au travail
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
 
Bien info janvier 2017
Bien info janvier 2017Bien info janvier 2017
Bien info janvier 2017
 
Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ? Quelle métrique pour fédérer Dev & Ops ?
Quelle métrique pour fédérer Dev & Ops ?
 
Presentation confiance numerique clichy
Presentation confiance numerique clichyPresentation confiance numerique clichy
Presentation confiance numerique clichy
 
Agilité, efficience et qualité à l'Académie de Versailles
Agilité, efficience et qualité à l'Académie de VersaillesAgilité, efficience et qualité à l'Académie de Versailles
Agilité, efficience et qualité à l'Académie de Versailles
 
Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...
Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...
Numérique : Daniel Filâtre appelle les corps d’encadrement à adopter un espri...
 
Mettez des millennials dans votre DSI
Mettez des millennials dans votre DSIMettez des millennials dans votre DSI
Mettez des millennials dans votre DSI
 
Stratégie devops-article-cio-dsi de versailles-5-juillet-2016
Stratégie devops-article-cio-dsi de versailles-5-juillet-2016 Stratégie devops-article-cio-dsi de versailles-5-juillet-2016
Stratégie devops-article-cio-dsi de versailles-5-juillet-2016
 
Chargé mission de modernisation
Chargé mission de modernisationChargé mission de modernisation
Chargé mission de modernisation
 
Protection des mineurs, sécurité des données
Protection des mineurs, sécurité des donnéesProtection des mineurs, sécurité des données
Protection des mineurs, sécurité des données
 
Passion
PassionPassion
Passion
 

Dernier

Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La JeunesseConseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Oscar Smith
 
Iris van Herpen. pptx
Iris            van        Herpen.     pptxIris            van        Herpen.     pptx
Iris van Herpen. pptx
Txaruka
 
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupeCours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
Yuma91
 
Edito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdfEdito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdf
WarlockeTamagafk
 
Système de gestion des fichiers de amine
Système de gestion des fichiers de amineSystème de gestion des fichiers de amine
Système de gestion des fichiers de amine
sewawillis
 
Iris et les hommes.pptx
Iris      et         les      hommes.pptxIris      et         les      hommes.pptx
Iris et les hommes.pptx
Txaruka
 
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
SYLLABUS DU COURS  MARKETING DTS 1-2.pdfSYLLABUS DU COURS  MARKETING DTS 1-2.pdf
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
Moukagni Evrard
 
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
mrelmejri
 
Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024
Friends of African Village Libraries
 
Iris van Herpen. pptx
Iris         van         Herpen.      pptxIris         van         Herpen.      pptx
Iris van Herpen. pptx
Txaruka
 
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
cristionobedi
 
Mémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et auditMémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et audit
MelDjobo
 

Dernier (12)

Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La JeunesseConseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
 
Iris van Herpen. pptx
Iris            van        Herpen.     pptxIris            van        Herpen.     pptx
Iris van Herpen. pptx
 
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupeCours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
 
Edito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdfEdito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdf
 
Système de gestion des fichiers de amine
Système de gestion des fichiers de amineSystème de gestion des fichiers de amine
Système de gestion des fichiers de amine
 
Iris et les hommes.pptx
Iris      et         les      hommes.pptxIris      et         les      hommes.pptx
Iris et les hommes.pptx
 
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
SYLLABUS DU COURS  MARKETING DTS 1-2.pdfSYLLABUS DU COURS  MARKETING DTS 1-2.pdf
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
 
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
 
Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024
 
Iris van Herpen. pptx
Iris         van         Herpen.      pptxIris         van         Herpen.      pptx
Iris van Herpen. pptx
 
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
 
Mémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et auditMémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et audit
 

Quelle métrique pour fédérer Dev & Ops ?

  • 1. Quelle métrique pour fédérer Dev & Ops ? Think Tank Automic Livre Blanc DevOps : Retours d’expérience et bonnes pratiques issus du Think Tank Automic
  • 2. Livre Blanc Follow Us2 Quelle métrique pour fédérer Dev & Ops ? DevOps : Retours d’expérience et bonnes pratiques issus du Think Tank Automic Texte établi par Gérald Audenis François Bazenet Eric Bouvet Thierry Falque-Vert Charlotte Gondre José Mauricio Jérôme Meyer Frédéric Poulain Alexandra Sommer Rédaction Alexandra Sommer Graphisme Emilie Daboussy Produit par Automic Tour Pacific 11, cours Valmy 92800 Puteaux France Copyright © 2016 Automic Software S.A.S. Tous droits réservés. La copie, photocopie, reproduction, traduction ou conversion de ce livre blanc sous quelque forme que ce soit, mécanique ou électronique, est interdite sans autorisation préalable obtenue par écrit auprès de Automic Software S.A.S.
  • 3. Livre Blanc TABLE DES MATIÈRES Préface 4 Chapitre 1 : Un indicateur mutant pour fédérer Dev & Ops  8 Chapitre 2 : Le TRS, un KPI sans équivalent dans l’informatique  12 Chapitre 3 : Implémentation du TRS en environnement DevOps  15 Etape 1 : Intention  16 Etape 2 : Identification du périmètre d’application  16 Etape 3 : Implication  17 Etape 4 : Partage du vocabulaire  18 Etape 5 : Etat des lieux du système de mesure  19 Etape 6 : Collecte des points de mesure  21 Etape 7 : Premières mesures  22 Etape 8 : Analyse des gaspillages  22 Atelier Arbre des Gaspillages  23 Atelier TIMWOOD  26 Etape 9 : Système de pilotage  28 Etape 10 : Industrialisation  29 A propos du Think Tank Automic  31
  • 4. Livre Blanc Follow Us4 Préface DevOps est né en 2009 après qu’un administrateur système (sysadmin) du nom de Patrick Debois a fait le constat que l’Agile, pour être pleinement efficace, devait nécessairement embarquer toute les équipes de la DSI : Dev (développement) et Ops (opérations). Le mouvement DevOps a connu par la suite un essor rapide en rassemblant sous sa bannière un ensemble de technologies et de pratiques permettant des mises en production plus petites, plus fréquentes et moins risquées. En 2010, les valeurs essentielles de DevOps étaient résumées sous forme d’un acronyme : CAMS pour Culture, Automatisation, Mesure et Partage (Sharing, en anglais). La mesure est ainsi, depuis ses débuts, l’un des piliers de DevOps*. C’est aussi l’un de ses territoires les moins explorés et les moins documentés. Le présent Livre Blanc cherche à répondre à une question simple : Comment mettre en place une mesure adaptée à DevOps, qui facilite le rapprochement entre équipes Dev et Ops et qui offre une vision objective et utile de la performance ? Nous espérons que la réponse que nous proposons ici de manière très concrète retiendra votre attention et vous donnera envie de la mettre en pratique. Dans tous les cas, cette réponse n’aurait pas pu voir le jour sans un certain nombre de rencontres, incarnées par des personnes que nous tenons à remercier chaleureusement : • Rencontreavecl’industrie,toujoursàlapointeenmatièredeperformance,enlapersonne de Christian Hohmann, expert en Lean Manufacturing de réputation internationale, • Rencontre avec des managers de production informatique visionnaires, avec qui nous avons transposé depuis 2010 les standards de performance industrielle à la productioninformatique.C’estleurtravaildetouslesjours,dansleursorganisations, qui a permis d’apporter une réponse pratique tant sur le « quoi » de la mesure que sur le « comment » de sa mise en œuvre. • Rencontre avec des managers de développement informatique, de la même étoffe, qui ont permis depuis 2014 d’établir une vision de bout en bout de la performance de la DSI tout en apportant une diversité bienvenue dans les approches. En 2015, comme chaque année depuis 2010, ces rencontres ont eu lieu dans le cadre de la communauté du Think Tank Automic, dédiée à la mesure de la performance. *Dans son enquête 2015 « Adoption et Enjeux de DevOps en France », IDC indique que la définition d’indicateurs communs pour Dev et Ops est un critère clé de succès pour 69% des organisations en cours d’adoption de DevOps.
  • 5. Livre Blanc Follow Us5 Nous tenons à remercier de tout cœur tous les managers qui y ont participé pour leur engagement, leur esprit de partage, leurs idées et leur capacité hors norme à les mettre en pratique et sommes très reconnaissants d’avoir pu travailler cette année avec : • François BAZENET, CAISSE DES DEPOTS • Patrice BENOIT, CCI PARIS ILE DE FRANCE • Nicolas BOGUCKI, INSTITUT NATIONAL DE L’AUDIOVISUEL • Pierre-Yves BOUCHARD, ANTEMETA • Eric BOUVET, ARKEMA • Didier CANITROT, EULER HERMES • Cyrille CARTIER, ANTEMETA • François GILLES, RECTORAT DE VERSAILLES • Geneviève GLEIZES, CCI PARIS ILE DE FRANCE • Charlotte GONDRE, RECTORAT DE VERSAILLES • Gilles LAVIGNE, POLE EMPLOI • José MAURICIO, BRED • Frédéric POULAIN, EDENRED FRANCE • Olivier SOULABAILLE, SECURITAS • Etienne TAROT, LACTALIS Merci tout particulièrement à Charlotte Gondre et Eric Bouvet pour l’animation des groupes de travail DevOps et ITIL dont les travaux, loin de s’opposer, se sont nourris mutuellement dans l’intérêt de tous. Un grand merci également à tous ceux qui ont participé à la rédaction des publications antérieures du Think Tank Automic. L’expérimentation d’un indicateur synthétique en environnement DevOps n’aurait pas pu être aussi rapide sans s’appuyer notamment sur le “guide pratique d’implémentation du Taux de Rendement Synthétique (TRS)”, paru en 2015. Nous en reprenons ici les éléments indispensables pour que le lecteur n’ait pas besoin de s’y référer. Merci, enfin, aux équipes Automic qui ont, année après année, œuvré à rendre toutes ces rencontres passionnantes, productives et conviviales. Merci à Jérôme Meyer et à Michel Enkiri pour la coordination métronomique des groupes de travail. Merci à Gérald Audenis, Thierry Falque-Vert et Nathan Srour pour l’animation experte des sessions de travail et ateliers. Merci à Alexandra Sommer pour l’organisation irréprochable des événements et la mise en forme impeccable des publications.
  • 6. Livre Blanc Follow Us6 LES MEMBRES DU THINK TANK TÉMOIGNENT... « Membre du Think Tank depuis plusieurs années, j’ai pu bénéficier dans mon quotidien del’immensetravaildegroupetournantautourdel’idéequ’ilestpossibledansl’ITcomme dans l’Industrie d’identifier la Performance de notre activité et de nos organisations. Trouver un moyen de Mesurer a été la toute première étape complétée avec succès par l’équipe initiale. Mais elle s’est rapidement complétée grâce à l’arrivée de nouveaux membres par la phase d’identification des gaspillages puis enfin par la phase de correction pour boucler par une nouvelle campagne de mesure… La roue de Deming avait fait un premier tour, il ne s’agissait plus que de consolider pour progresser et ce fut la rédaction des Livres Blancs. Encore bravo à tous et surtout un grand MERCI ! » Pierre-Yves Bouchard – Directeur de Production Cloud - ANTEMETA « J’ai participé aux travaux du Think Tank dès sa création en 2010. Débattre sur l’intérêt de transposer à l’Informatique un indicateur de performance issu de l’Industrie fut passionnant. Expérimenter puis industrialiser la démarche sur le Service Desk et des processus clefs (gestion des mises en production, gestion des événements) pour piloter la performance, parfois dans un contexte international, le fut encore davantage. Aujourd’hui, les entreprises et les administrations disposent, au travers des livres blancs, d’une méthodologie et des retours d’expérience documentés. De quoi faciliter l’adoption et accélérer la mise en œuvre en quelques semaines seulement, alors que plusieurs mois étaient requis lors des premières expérimentations. » Eric Bouvet, Responsable IT Operations - ARKEMA « Le groupe de travail DevOps est une bonne illustration de l’intelligence collective. Les échanges sympathiques et riches nous ont permis de mieux penser nos processus de travail transverse, de les améliorer et de s’initier aux indicateurs synthétiques. Thanks Think Tank ! » Geneviève Gleizes, Responsable technologies transverses et Développement Web DPMA - DPSI - CCI PARIS ILE DE FRANCE « En appliquant simplement la méthode et grâce aux échanges avec les participants, j’ai pu mettre en place rapidement un indicateur pertinent pour mesurer la performance de notre nouvelle chaine de déploiement pour une application stratégique, dans un esprit DevOps. » Frédéric Poulain, Responsable Système & Réseaux - EDENRED « Un partage très riche et unique d’expériences avec nos pairs actuels (OPS) et futurs (DEV). Des échanges constructifs en toute transparence intégrant les besoins et contraintes de chacun. Et du concret, un indicateur de référence pour mesurer l’impact de la mise en œuvre de DevOps en terme de valeur Business. » Didier Canitrot, Head of GIP Process and Service Design - EULER HERMES
  • 7. Livre Blanc Follow Us7 « La direction des systèmes d’information de Météo France est soumis à des contraintes de marché et d’adaptation aux normes qui nécessitent des mises en production rapides et sûres. La mise en oeuvre d’indicateurs de bout en bout, caractéristique du DevOps est en cours. C’est en suite des réunions et présentations du Think Tank Automic que ces idées on pris de la substance et sont devenues plus concrètes. » Daniel Dure, Directeur des Systèmes d’Information - METEO FRANCE « Nouveau Think Tank, nouvelles rencontres et toujours des résultats à forte valeur ajoutée. Le partage des réussites et des difficultés de chacun permet au groupe de progresser … Besoin d’un TRS pour mesurer ces progrès ? » Gilles LAVIGNE, Directeur Adjoint des Opérations - POLE EMPLOI « Travailler à définir, puis à évaluer, des points de mesures de qualité, de disponibilité et de performance d’une chaine de production logicielle en mode « DevOps » a permis de confronter la théorie d’un modèle synthétique, celui du TRS, à la réalité opérationnelle. Le résultat a dépassé nos attentes . Il s’avère en effet qu’une définition et une analyse concertée des mesures favorisent la cohésion des équipes DEV (Etudes) et OPS (Exploitation). Ceci contribue à rendre de fait les équipes acteurs de la conduite du changement DevOps et à en mesurer de façon factuelle les gains pour servir l’objectif premier de la DSI à savoir la satisfaction des clients. » Charlotte Gondre, Chef du Service Etudes & Développement - RECTORAT DE VERSAILLES
  • 8. Livre Blanc Follow Us8 Chapitre 1 : Un indicateur mutant pour fédérer Dev & Ops Une affaire non résolue : DevOps & la mesure DevOps a connu un essor fulgurant depuis son apparition au tournant des années 2010. En l’espace de cinq ans, près d’un tiers des organisations informatiques se sont lancées dans l’aventure DevOps, au moins sur un pilote. Le principal moteur de cette transformation est l’ambition affichée de réduire le délai entre l’expression d’une idée et son activation en environnement de production (Time to Production). Mais au fait, quel est aujourd’hui votre Time to Production ? De combien s’est-il amélioré ? La question peut sembler provocatrice à l’heure où la Mesure est affichée comme l’un des quatre piliers de DevOps. Pourtant, l’expérience montre que la pression continuelle portée sur la livraison de projets toujours plus urgents empêche les organisations de réfléchir à leur système de mesure et de répondre à ces questions basiques. Le développement enchaine les sprints et puis, un beau jour, les features finissent bien par arriver en production. Mais quand ? Avec quel impact ? Et à quel prix ? La mesure dans DevOps est bel et bien une affaire non résolue. Il suffit d’évoquer la question avec des personnes confrontées au sujet pour que reviennent les questions suivantes : • Comment contrôler le fonctionnement et mesurer les progrès d’une chaîne de delivery Agile ? • Comment mesurer la Performance de bout en bout plutôt que celles des Dev et des Ops en silo ? • Comment éviter les indicateurs toujours verts qui masquent les problèmes (l’effet “Dev-Oups”) ? • CommentamenerDevetOpsàmieuxprendreencompteleurscontraintesrespectives? • Comment gagner en lisibilité et ne pas se laisser submerger par une information surabondante (Dashboard Everything) ? La vérité est ailleurs : Un standard industriel, le TRS Les mesures existantes apparaissent inopérantes pour fédérer Dev et Ops car elles sont en décalage profond avec les enjeux collaboratifs de DevOps. Les KPIs reflètent le cloisonnement des organisations. Les Opérations ne se retrouvent pas dans les métriquesAgiles.LesEtudesneseretrouventpasdanslesSLAs.Lesoutilsfonctionnent « en silo » et ne permettent pas une vision de bout en bout.
  • 9. Livre Blanc Follow Us9 Il fallait donc chercher la vérité ailleurs que dans l’informatique. En l’occurrence, nous avons trouvé l’inspiration dans l’industrie, confrontée depuis des décennies aux enjeux d’agilité et de fiabilité au point d’avoir établi un standard de mesure de la performance : le Taux de Rendement Synthétique (TRS). Largement répandu dans les environnements industriels, cet indicateur n’est pas un indicateur de plus mais bien la clé de lecture principale de la performance pour les directeurs d’usine. Notre démarche a simplement consisté à appliquer ce standard industriel à un nouveau type d’usine : la digital factory. Nous avons voulu transposer le TRS en environnement DevOps et valider sa pertinence en environnement réel. Nous avons voulu en faire un indicateur commun qui permette de gagner en lisibilité et de piloter la Performance globale de la chaîne de delivery de la DSI, plutôt que les performances locales au niveau des Dev et des Ops. Nous avons voulu également nous inspirer des méthodes d’analyse et d’amélioration continue qui sont utilisées dans le sillage du TRS comme l’arbre des gaspillages ou la méthode TIMWOOD. Des résultats concrets : Bonnes pratiques & Retours d’expérience Les résultats présentés dans ce Livre Blanc sont le fruit d’un travail d’équipe. Pour garantir des résultats concrets, chaque membre du Think Tank Automic s’est engagé personnellement à produire une mesure dans son propre environnement. L’approche communautaire et collaborative a fait le reste : le fait d’avancer de concert et de confronter l’expérience de chacun à chaque étape a permis d’aller plus vite et d’aborder la mise en œuvre avec confiance. Dans un premier temps, le groupe a convergé sur la définition d’un TRS transposé à la chaine de delivery logiciel. Cette définition est intervenue à deux niveaux. Le niveau général définit ce qui doit être mesuré (le quoi). Le niveau détaillé propose différents indicateurs permettant de le mesurer (le comment). Il existe en effet différents moyens de mesurer le TRS selon la capacité d’une organisation à produire certaines mesures. Certaines mesures, plus simples, sont suffisantes dans une première approche et permettent de franchir un premier pas significatif en matière de pilotage. Cette définition flexible a permis de construire une boite à outils générique adaptable aux contextes des différents membres. Dans un second temps, le groupe a mesuré le TRS à partir de cette définition. Les premiers résultats ont été suivis mensuellement. Ils ont permis de valider la pertinence de la mesure et son intérêt tant pour l’identification de pistes d’amélioration que pour sa capacité à fédérer équipes Etudes et Production. Des ateliers spécifiques ont été conduits durant cette phase pour rentrer dans l’analyse des gaspillages et identifier des plans de remédiation. Les retours d’expérience ont été partagés entre membres
  • 10. Livre Blanc Follow Us10 que ce soit pour l’adoption ou pour l’usage du TRS. En fin d’année, les membres sont revenus sur les bonnes pratiques qu’ils souhaitaient partager suite à leur propre expérience de la mise en place du TRS. Ces conseils sont présentés dans le tableau ci-dessous. Les enseignements : La mesure est un outil collaboratif très efficace Au-delà des résultats détaillés dans les chapitres suivants, il est ressorti de cette année de travail en communauté que la mesure était un outil collaboratif extrêmement puissant. La mesure aide à fédérer et à faire adhérer. On réduit trop souvent DevOps à l’automatisation et à la technologie et on oublie par la même occasion la dimension du partage qui est essentielle. A la base DevOps est une question de culture, de communication, de confiance, de collaboration. Au sein des organisations qui l’ont mis en place, la mesure a amené Dev et Ops à travailler ensemble sur des indicateurs communs et a contribué à transformer la culture. La volonté de s’améliorer ensemble en est ressortie renforcée. Expérimentation du TRS : Bonnes pratiques 1 Assimiler la méthode • Avoir une vision claire du TRS et une bonne compréhension du modèle • Développer une certaine curiosité • Partager les retours d’expérience à travers des Think Tank par exemple 2 Procéder par étape • Cibler et définir un périmètre d’application restreint et maîtrisé • Se remettre en cause continuellement • Ne pas hésiter à adapter le périmètre ou les définitions au fur et à mesure que l’on comprend mieux le modèle 3 Partager / Impliquer • Communiquer autour du TRS, privilégier la collaboration et le partage des besoins • Partager les mesures et en conséquence les processus • Réfléchir aux modalités d’analyse des écarts en impliquant les équipes 4 Démontrer la valeur • Impliquer les acteurs du terrain • Proposer des plans d’actions pragmatiques et priorisés • Capitaliser sur les quick-wins 5 Pérenniser • Penser à la gestion du cycle de vie du TRS et son maintien en condition opérationnelle • Penser à revoir et à réactualiser les objectifs et critères de mesure • Inscrire l’ensemble des indicateurs dans les standards
  • 11. Livre Blanc Follow Us11 Un moyen pratique d’établir un dialogue. La Mesure ne doit pas être imposée mais présentée comme un moyen d’établir un dialogue. La Mesure ne doit pas être un projet uniquement Dev ou uniquement Ops mais être conçue de façon concertée. La Mesure ne doit pas se focaliser sur le chiffre mais apporter une discussion entre équipes. Les membres du Think Tank ont construit leur TRS ensemble, avec leurs équipes dans une approche résolument Bottom-up. Le TRS permet d’aller vite à l’essentiel. Tout le monde veut mesurer mais rares sont ceux qui prennent le temps de mettre les mesures en place. Le TRS présente l’intérêt de pouvoir être implémenté rapidement, quitte à ce que la mesure soit embryonnaire dans un premier temps. Le cadre de définition général permet d’aller vite sans rien oublier d’essentiel. La valeur vient ensuite en marchant : On commence avec ce qu’on sait faire et on progresse au fur et à mesure. Les résultats sont apparus comme très pertinents même à partir de mesures partielles. Par ailleurs, la méthode en 10 étapes présentée au Chapitre 3 est une aide précieuse pour avancer pas à pas et franchir des étapes clairement identifiées. Cultiver un état d’esprit collaboratif. L’avantage des mesures, c’est qu’elles sont factuelles, objectives, transparentes, honnêtes et partagées. Pour en tirer le meilleur parti, il faut se mettre en position d’écoute de l’autre et accepter que l’on ait des choses à améliorer. Par ailleurs, la discussion sur les mesures à mettre en place nécessite de s’écouter pour se comprendre : Dev et Ops ne mettent pas toujours la même chose derrière un même terme. Du point de vue du manager, il importera d’être bienveillant et de ne pas mettre en place la mesure dans un objectif de sanction. Compte-tenu que le TRS est un indicateur de progrès, sa valeur est par définition non optimale (c’est-à-dire loin de 100% !) et il est recommandé de s’axer sur la variation de l’indicateur, et non sur sa valeur absolue. En tout état de cause, la communication est clé ! L’essayer c’est l’adopter ! Dans un premier temps, le principe d’un indicateur unique permettant de mesurer la « performance de DevOps » a laissé certains membres dubitatifs. Les mêmes sont aujourd’hui les premiers convaincus que « ça marche ». La mesure leur a en effet permis de cimenter une culture de collaboration. Ils ont pu constater que la recherche de l’amélioration continue est bel et bien partagée par les équipes Ops & Dev. A partir du moment où ils se sont mis d’accord pour définir des indicateurs factuels et objectifs et les analyser ensemble, le dialogue s’est établi ainsi que la confiance. Du point de vue des managers, la valeur la plus importante a été trouvée dans le travail mené en commun avec les équipes. Le TRS est un moyen efficace d’y parvenir en un temps record !
  • 12. Livre Blanc Follow Us12 Chapitre 2 : Le TRS, un KPI sans équivalent dans l’informatique Plusieurs années d’expérimentation dans le cadre des activités du Think Tank Automic ont permis de révèler que deux indicateurs standards en environnements industriels apportaient une réponse pratique efficace aux besoins de partage et de pilotage des organisations informatiques : • Le Taux de Rendement Synthétique (TRS), qui mesure la performance d’une unité de production, • Le Taux de Rendement Global (TRG), qui intégre la charge effective de ce moyen de production. Ces indicateurs présentent plusieurs caractéristiques originales en environnement informatique : • Lisibilité : Ce sont des indicateurs synthétiques, obtenus par la multiplication d’autres indicateurs, permettant de suivre en un coup d’œil l’évolution de la performance. Cela permet de mieux partager objectifs et résultats avec les clients, les équipes de la DSI ou la Direction Générale. • Amélioration : Ce sont des indicateurs de progrès, qui n’ont pas vocation à atteindre 99,9% ou 100%. Des taux de 60% ou 70% sont fréquents, même en fonctionnement normal. Cela permet d’analyser les dysfonctionnements et de constater les améliorations. • Bout-en-bout : Ce sont des indicateurs composites qui intègrent d’une part la qualité de la production (vue client) et d’autre part l’efficacité du processus (vue fournisseur). Cela permet un pilotage équilibré et une implication de l’ensemble des équipes. Qu’est-ce que le TRS ? L’Industrie recourt habituellement pour le pilotage de sa Performance au Taux de Rendement Synthétique (TRS) correspondant en anglais à l’Overall Equipment Effectiveness (OEE). Cet Indicateur Clé de Performance permet d’évaluer sur un axe unique l’efficacité opérationnelle, les objectifs de Performance et le résultat des initiatives de productivité.
  • 13. Livre Blanc Follow Us13 Il s’agit d’un indicateur sans grandeur, consistant en la multiplication de trois taux : • Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée), • Le Taux de Performance « Tp » (variant en fonction des cadences), • Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le nombre de pièces produites). Le TRS peut donc être défini comme suit : TRS = Td * Tp * Tq Qu’est-ce que le TRG ? L’industrie recourt également au Taux de Rendement Global (TRG) pour piloter sa performance, correspondant en anglais à l’acronyme TEEP, Total Effective Equipment Performance. Cet indicateur dont les caratéristiques sont similaires à celles du TRS, consiste en la multiplication de quatre taux : • Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée), • Le Taux de Performance « Tp » (variant en fonction des cadences), • Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le nombre de pièces produites), • Le Taux de Charge « Tc » (mesure de la charge productive réelle, ratio entre temps requis et temps d’ouverture). Le TRG peut donc être défini comme suit : TRG = Td * Tp * Tq * Tc Apport du TRS à la DSI L’apport principal de cette approche industrielle est de fournir un système de pilotage permettant d’appréhender globalement la performance au travers d’un indicateur synthétique. L’identification d’un indicateur unique de performance, différencié des indicateurs de gouvernance existants est jugée comme un apport déterminant au management des directions informatiques : • En termes de gouvernance et de communication externe avec les clients, la DSI et la Direction Générale, • Entermesdepilotageetdedécisioninternevisantàl’améliorationdelaproductivité, • En termes de benchmark et de possibilité de se comparer en interne dans le temps, voire en externe. Le TRS apporte une aide particulièrement pertinente pour les DSI qui mettent en œuvre une démarche collaborative DevOps, par l’adoption d’un indicateur commun entre équipes Etudes et Production habituées à travailler chacune de leur côté en silos en matière de méthodes, d’outils et de mesure de la performance.
  • 14. Livre Blanc Follow Us14 Application du TRS à la Digital Factory Le principe du TRS s’inscrit de manière naturelle en environnement DevOps. En premier lieu, la mesure est un pilier du mouvement DevOps. En second lieu, le concept de Digital Factory rejoint la dimension industrielle propre au TRS. Enfin, avec le TRS, l’accent est mis sur la chaine de delivery logiciel et sur la capacité de la DSI, comme moyen de production, à allier vélocité et fiabilité. Plusieurs approches ont été envisagées pour transposer le TRS en environnement DevOps selon que l’on considère la chaine de delivery logiciel de manière globale ou par segments. Les travaux du Think Tank Automic présentés dans le cadre de ce livre blanc, se sont intéressés à l’approche de bout-en-bout du processus (TRS end-to-end) depuis la validation des demandes (Plan) jusqu’à l’activation du service en production (Operate). Il est à noter que d’autres travaux complémentaires ont été menés par Automic pour mesurer le TRS uniquement sur la partie aval de ce processus (TRS release pipeline). La méthode pourrait également être appliquée à d’autres segments (gestion des demandes, synchronisation SPRINT / RELEASE) si ces derniers répondent à des enjeux et des contraintes prioritaires des organisations. Plan Code Build Test Release Deploy Operate TRS Gestion des demandes TRS Synchronisation SCRUM/RELEASE TRS Release Pipeline TRS end-to-end
  • 15. Livre Blanc Follow Us15 Chapitre 3 : Implémentation du TRS en environnement DevOps La méthode proposée ci-après est issue des premiers cas de mise en œuvre du TRS. Cette méthode est la capitalisation de retours d’expérience et non un exercice théorique : à mesure que les membres pionniers trouvaient les moyens d’appliquer le TRS dans leurs environnements propres, les bonnes pratiques étaient communiquées au sein de la communauté du Think Tank et des jalons étaient posés pour permettre aux autres membres de suivre leur trace. En passant par les mêmes étapes, ces membres ont permis de challenger la méthode et de l’améliorer. Progressivement, une méthodologie s’est dégagée avec l’objectif affiché de multiplier les cas d’adoption sur un même périmètre, et d’accélérer le temps de mise en application. En définitive, l’application de la méthode a permis de constater un gain de temps important dans la mise en œuvre en évitant pièges et fausses pistes pour aller droit à l’essentiel. Cette méthodologie est organisée en 10 étapes, permettant de suivre la progression des membres de 1 à 10 et d’identifier les blocages. Elle s’est enrichie des feedbacks des différents groupes de travail pour aboutir à un consensus dans l’identification des étapes, leur contenu et leur ordre. Les étapes sont présentées succintement dans le tableau ci-dessous et décrites dans la suite du document. Méthode d’adoption du TRS en 10 étapes Etape 1 Intention Identifier le besoin d’amélioration de la performance justifiant la mise en place d’une approche « TRS » Etape 2 Identification du périmètre d’application Identifier précisément le périmètre d’application du TRS et partager si nécessaire le périmètre en plusieurs lots Etape 3 Implication Assurer le bon niveau de sponsorat et mobiliser les parties prenantes Etape 4 Partage du vocabulaire S’assurer que le vocabulaire est compris et partagé pour chacune des composantes du TRS (disponibilité, performance, qualité) appliqué au périmètre choisi Etape 5 Etat des lieux des systèmes de mesure Identifier l’aptitude du système de mesure à remonter les éléments entrant dans le calcul du TRS Etape 6 Collecte des points de mesure Mettre en place les moyens de mesure du TRS à partir de l’outillage existant Etape 7 Premières Mesures Produire une première mesure du TRS sur le périmètre choisi Etape 8 Analyse des gaspillages Analyser les écarts de performance à partir du TRS et utiliser l’arbre de gaspillage pour en identifier les causes Etape 9 Systèmes de Pilotage Inscrire le pilotage de la performance opérationnelle dans une démarche d’amélioration continue Etape 10 Industrialisation Mettre en place l’organisation et l’outillage permettant de pérenniser la mesure
  • 16. Livre Blanc Follow Us16 La méthode proposée n’est pas un cadre normatif, chaque nouvel adoptant pouvant adapterladémarcheàsoncontexte,àsesspécificités,ainsiqu’àsonsystèmedemesure. Nous pensons toutefois que les modèles présentés vous permettront de gagner du temps et que l’application des mêmes principes pourra faciliter la comparaison entre les organisations adoptant le TRS. Etape 1 : Intention La première étape consiste à apporter des éléments de réponse à la question suivante : Quel objectif recherchez-vous dans la mise en place d’un TRS ? On cherche ici à identifier et à valider les enjeux opérationnels ou transformationnels qui seront facilités par cet indicateur. Attention ! On parle bien ici de l’objectif recherché dans la mise en place du TRS et non de l’objectif recherché dans la mise en place de DevOps. Les objectifs suivants sont généralement à l’origine de la mise en place du TRS en environnement DevOps : • Partager un indicateur commun entre Dev et Ops, • Partager de bout-en-bout une même vision de la performance de la chaine de delivery logiciel, • Partager des objectifs communs d’amélioration globale, • Mesurer la performance dans ses différentes dimensions sans la réduire au Time- to-Market, • Faciliter l’analyse de la performance et l’identification de leviers d’amélioration continue, • Facilier la gouvernance d’un programme de mise en œuvre de DevOps, • Obtenir une valeur de référence (baseline) et valoriser les bénéfices d’un pilote DevOps, • Améliorer la satisfaction client et l’efficience de l’organisation, • Benchmarker les résultats obtenus en interne ou avec des pairs. Etape 2 : Identification du périmètre d’application A cette étape, il s’agit d’identifier le périmètre pour lequel on mesurera le TRS. Afin de progresser efficacement, il est conseillé de partager le périmètre d’application en plusieurs lots.
  • 17. Livre Blanc Follow Us17 Ces lots peuvent être a minima : • Un lot « pilote » correspondant à un périmètre restreint, qui permettra de tester la méthode, • Un deuxième lot qui peut être le périmètre cible, et où l’on passera en mode « industriel » avec potentiellement, un outillage plus performant. Le domaine des applications et portails web a été le pilote le plus fréquemment choisi pour l’implémentation du TRS en environnement DevOps. Le TRS a pu également être généralisé sur l’ensemble des domaines applicatifs dans le cadre d’un programme de transformation DevOps. Etape 3 : Implication Il s’agit à ce stade de s’assurer du bon niveau de sponsorat et de mobiliser les parties prenantes. Le niveau d’implication dépendra bien entendu de l’approche adoptée (expérimentation par un opérationnel, déploiement par une entité transverse) et de l’avancement du projet. Dans un premier temps, il convient de s’assurer d’avoir : • Identifié le niveau de sponsorat, • Justifié de l’approche et de l’investissement, • Obtenu validation de la démarche. Il est fondamental d’impliquer les Etudes et la Production dès le début. Constituer un binôme avec un manager Dev et un manager Ops en co-responsabilité du sujet s’est révélé être très efficace pour conduire le changement. Le sujet peut également être porté uniquement par un responsable Dev ou un responsable Ops à condition de s’être assuré du soutien de l’autre partie prenante. La présentation de la présente méthode en 10 étapes lors de sessions d’information a permis de familiariser les organisations avec le concept et d’accélérer son appropriation. Par ailleurs, il faut s’assurer que les personnes amenées à mettre en place le TRS et les leviers d’amélioration associés sont disponibles a minima. Le nombre de personnes à impliquer est fonction : • Du périmètre d’application (cf. Etape 2), • De la difficulté à mesurer, • Du niveau d’industrialisation souhaité pour la mesure, • Du temps dont on dispose pour mettre en place la mesure.
  • 18. Livre Blanc Follow Us18 Etape 4 : Partage du vocabulaire Avant de commencer à définir et mesurer les différents taux du TRS et du TRG, Il faut s’assurer que le vocabulaire est bien compris et partagé pour chacune des trois composantes de l’indicateur de TRS (Disponibilité, Performance, Qualité) et chacune des quatre composantes de l’indicateur de TRG (Charge, Disponibilité, Performance, Qualité). Ces notions sont ici utilisées dans leur définition industrielle. L’application à DevOps du TRS et/ou du TRG nécessite de s’accorder sur ce que sont la Charge, la Disponibilité et la Performance de la chaine de delivery elle-même (l’efficacité opérationnelle des activités) et ce qu’est la Qualité en bout de cette chaine de production (ce qui est produit). Une traduction de ce vocabulaire industriel appliqué à la chaine de delivery logiciel est proposée ci-dessous : • Charge : Utilisation efficiente des ressources, • Disponibilité : Disponibilité de la plateforme ou des environnements à chaque étape, • Performance : Ponctualité des Mises en Service par rapport à la date prévue, • Qualité : Niveau de qualité d’expérience utilisateur et de respect des exigences non-fonctionnelles des packages livrés en production. Le schéma ci-dessous associe les différentes composantes du TRS et du TRG aux différentes étapes d’une chaine de delivery logiciel et aux différents niveaux d’activités (applicatif, plateforme, infrastructure) qui y contribuent. La qualité apparait bien comme la qualité du produit en bout de chaine. A l’inverse, la Charge, la Disponibilité et la Performance mesurent l’efficacité de l’ensemble de la chaine à un niveau d’activité donné. Agile Coding Cont. Integration Cont. Delivery Cont. Deployment Application- level Activities Performance Plateform- level Activities Disponibilité Infra- level Activities Charge Qualité
  • 19. Livre Blanc Follow Us19 Ce sont ces définitions qu’il convient de partager avec les équipes Etudes et Production. IlnefautpasconfondrecesnotionsaveclesnotionshabituellesdeCharge,Disponibilité, Performance et Qualité telles qu’elles sont utilisées dans l’informatique. Au contraire, il faut regarder ces notions avec un regard neuf et définir quels critères représentent le mieux, dans son environnement DevOps propre, les différents axes constitutifs du TRS et/ou du TRG. Etape 5 : Etat des lieux du système de mesure Cette étape identifie l’aptitude du système de mesure à remonter les éléments entrant dans la mesure du TRS. La réponse à cette question doit tenir compte de la capacité à mesurer simplement ces différentes composantes. Pour cela, chaque organisation peut s’appuyer sur la check-list présentée dans la figure ci-dessous. Cette check-list est un outil permettant de choisir parmi dix indicateurs proposés les mesures qui sont les plus pertinentes et les plus faciles à obtenir dans un contexte donné. Dans un premier temps, il suffit de cocher au moins un indicateur par composant. Le taux de Charge n’est utile que pour les organisations souhaitant mesurer le TRG. Le taux de Qualité sera d’autant plus équilibré qu’il associera un indicateur correspondant aux exigences non fonctionnelles et un indicateur correspondant à l’expérience utilisateur. Taux de Performance Taux de Disponibilité Taux de Charge Taux de Qualité TRG Taux de Performance Taux de Disponibilité Taux de Qualité TRS Utilisation efficiente des ressources C1 - Taux d’utilisation des ressources / plateformes Exigeances non fonctionnelles Q1 - Qualité du code Q2 - Préparation de la MEP Expérience utilisateur Q3 - Performance applicative ressentie par l’utilisateur Q4 - Incidents suite à MEP Disponibilité de la plateforme à chaque étape D1 - Rapidité de mise à disposition des environnements D2 - Disponibilité des environnements Ponctualité des Mises en Production PA - Respect des dates de MEP P2 - Cadence des MEP par rapports aux spints P3 - Profondeur des décalages de date de livraison
  • 20. Livre Blanc Follow Us20 Un bref descriptif des indicateurs de la check-list est présenté dans le tableau ci- dessous : Une fois les indicateurs choisis dans la check-list, les questions suivantes doivent être considérées : • Pouvez-vous mesurer chacun des taux définis ? • Quels sont les points de mesure ? Indicateurs de la check-list Descriptif C1. Taux d’utilisation des ressources / plateformes Mesurer le taux d’utilisation des ressources pour valider le bon dimensionnement des ressources des environnements de la chaine de production DevOps. D1. Rapidité de mise à disposition des environnements Mesurer le taux des demandes d’environnement traitées en respectant l’accord de service. L’enjeu est d’accélérer les temps de déploiement des environnements et de réduire le délai de prise en charge des demandes d’environnement. D2. Disponibilité des environnements Mesurer le taux de disponibilité des environnements, obtenu en divisant la durée durant laquelle l’environnement est opérationnel par la durée totale durant laquelle on a exprimé un souhait qu’il le soit (hors plage de maintenance convenue au préalable). P1. Respect des dates de MEP Mesurer le nombre de MEP à date prévue par rapport au nombre total de MEP pour valider la capacité de l’organisation DevOps à accélérer le Time to Market. P2. Cadence des MEP par rapport aux sprints Mesurer la capacité des organisations à synchroniser SPRINT et RELEASE en suivant le rapport du nombre de MEP / nombre de Sprints. P3. Profondeur des décalages de date de livraison Identifier les écarts de livraison en nombre de jours par rapport à la date de livraison initialement prévue. Q1. Qualité du code Evaluer la qualité du code pour pouvoir mesurer la dette technique en s’appuyant sur la méthode SQALE. Q2. Préparation de la MEP Mesurer la qualité de la préparation des MEP selon 4 axes : - l’anticipation des besoins d’infrastructures, - l’anticipation des besoins d’exploitation, - la bonne mise en place d’un PCA et/ou PRA, - la bonne mise en place de la supervision. Q3. Performance applicative ressentie par l’utilisateur Evaluer la performance applicative ressentie par l’utilisateur - Mesure de la satisfaction de l’utilisateur en fonction des temps de réponse d’un ensemble de requêtes sur une période de temps donnée (cf. Application Performance Indexer - http://www.apdex. org). Q4. Incidents suite à MEP Mesurer l’impact des MEP sur la qualité de service en suivant le rapport du nombre d’incidents post MEP / nombre d’incidents moyen.
  • 21. Livre Blanc Follow Us21 • Où se trouve la donnée relative à ces points de mesure (solution/outil, …) ? • Quelle est la fiabilité de cette donnée ? Dispose-t-on de suffisamment de points de mesure ? • Quelle est la fréquence de mise à jour de cette donnée ? Quelle en sera la fréquence de mesure ? • Par quel moyen de collecte (automatique, manuelle, …) pouvez-vous récupérer cette donnée ? • Quelle équipe / personne en a la responsabilité ? Le tableau ci-dessous présente un modèle simple qui peut être utilisé pour présenter les réponses à ces questions. Etape 6 : Collecte des points de mesure Dans cette étape, les moyens de mesure du TRS sont mis en place : paramétrage de nouveaux rapports, mise en place de traçabilité, etc. Compte tenu des contraintes liées au système de Mesure, il est in fine nécessaire d’identifier,pourchaquecomposant,lesdonnéesetlesformulesdecalculcorrespondant au mieux à la définition de celui-ci. Les discussions communes entre Dev et Ops sur les points de mesure sont un bon moyen de constater les manques et les doublons, les erreurs et les opportunités. Dans un premier temps, une mesure en première approximation s’avère généralement suffisante. QUALITE PERFORMANCE DISPONIBILITE Mon TRS Taux de Qualité : Nombre d’incidents en période de Vérification de Service Régulier (VSR) post MEP Taux de MEP à date prévue Taux de Disponibilité des environnements de Dev / Recette Données Nombre de tickets > au nombre de tickets moyen sur 2 jours après les MEP Nombre de MEP planifiées réalisées à date / mois Durée d’indisponibilité / mois Acteurs Equipe Support (Outil ITSM) Equipe Dev (Outil ALM) Equipe Ops (Supervision)
  • 22. Livre Blanc Follow Us22 Etape 7 : Premières mesures Une première mesure du TRS est produite. Dans un premier temps, une mesure permettant une première approximation des indicateurs peut suffire. Ce qui importe, c’est de fédérer les personnes autour d’une démarche et de progressivement affiner et automatiser la mesure (cf. étapes suivantes). Nouspréconisonsdoncdecommencerlecalculetl’analyseduTRSmêmesitouteslesdonnées ne sont pas disponibles, ou qu’elles n’ont pas encore le « niveau de précision » souhaité. Dans certains cas, des données sur les derniers mois ou les dernières semaines sont disponibles dans les systèmes de mesure. Dans ce cas, calculez le TRS a posteriori sur les derniers jours / semaines / mois afin de voir si le TRS est stable ou s’il varie en fonction de la période. Etape 8 : Analyse des gaspillages Le but ultime du TRS n’est pas de mesurer mais bien d’analyser la performance et de rentrer dans une démarche d’amélioration continue. L’atelier « arbre des gaspillages » présenté ci-après est une manière pragmatique d’initier un telle analyse en trois phases : • Identifier les gaspillages, c’est-à-dire les causes de défaillance potentielles des Taux élémentaires du TRS : Performance, Disponibilité, Qualité, • Identifier les leviers d’amélioration, c’est-à-dire les moyens d’action potentiels qui permettent d’agir sur les causes des gaspillages, • Identifier les indicateurs d’amélioration, c’est-à-dire les moyens de contrôle qui permettent de s’assurer que nous avons bien agi sur les causes au moyen des leviers. Une fois l’analyse terminée, des actions d’amélioration (leviers) seront implémentées, et leur effet sur les activités sera contrôlé / mesuré. L’atelier « TIMWOOD » est une approche complémentaire à l’atelier « arbre de gaspillages » en ce qui concerne la première phase d’identification des gaspillages. MOIS TAUX DE QUALITE TAUX DE DISPONIBILITE TAUX DE PERFORMANCE TRS Avril 90% 80% 81,25% 58,5% Mai 95% 90% 87,65% 74,94% Juin 95% 85% 97,65% 78,85%
  • 23. Livre Blanc Follow Us23 Atelier Arbre des Gaspillages L’arbredesgaspillagesestunebonnepratiqueissuedumondeindustriel.Lesgaspillages sont pré-cartographiés, et associés a priori à chaque dimension du TRS. L’arbre facilite l’identification des gaspillages et l’exhaustivité de l’identification. Il permet d’analyser le travail et de comprendre les obstacles qui empêchent d’accomplir le travail au rythme voulu. TRS Disponibilité Qualité Performance Composant Savoir-faire Synchronisation Planning / Ordonnancement Capacité Pannes Techniques Attentes Arrêts (humain) Approvisionnements Méthode Procédures Surconsommation Productivité Rapidité Facteur humain
  • 24. Livre Blanc Follow Us24 La réussite d’ateliers d’amélioration s’appuyant sur l’arbre des gaspillages repose principalement sur les participants et l’interactivité des échanges. Ces ateliers d’amélioration ont une durée de deux heures et ont pour but : • D’impliquer les acteurs et de les sensibiliser au calcul de l’indicateur et à son utilisation, • De définir le système de mesure qui permet de calculer cet indicateur et de mettre en place les premières mesures, • D’identifier les gaspillages et les leviers d’amélioration, • De suivre la mise en place des leviers d’amélioration et l’évolution du TRS dans le temps. L’atelier d’amélioration est piloté par le responsable de la mise en place du TRS. Les participants à l’Atelier sont les personnes qui mesurent le TRS, accompagnées de deux ou trois personnes qui travaillent sur le processus mais qui ne mesurent pas. Elles n’ont, de ce fait, pas été associées préalablement à la démarche. Ces deux ou trois personnes vont donc avoir un angle d’approche légèrement décalé par rapport au reste du groupe, ce qui peut être bénéfique dans l’apport de solutions. Le déroulement type d’un atelier d’amélioration est décrit ci-après.
  • 25. Livre Blanc Follow Us25 Déroulement type d'un atelier d'amélioration 2nde identification des gaspillages (avec l’arbre des gaspillages) Objectif  : Utiliser l’arbre des gaspillages IT pour  consolider la liste des gaspillages identifiés Corréler les gaspillages identifiés pendant l’Atelier avec les natures de gaspillages présentés sur l’arbre Susciter de nouvelles propositions Partage des premières mesures Objectif  : Partager une vision objective de la Performance (factualiser) Présenter le TRS global, accompagné des Taux obtenus pour la Disponibilité, la Qualité, et la Performance Rappeler les grands principes de base appliqués pour le calcul de ces trois taux afin que les participants qui ne mesurent pas comprennent ce que représentent ces résultats. Introduction Objectif : Rappeler l’enjeu de l’Atelier Les difficultés perçues sur le processus, L’intérêt de mettre en place un TRS et les gains escomptés, L’intérêt de définir collégialement les gaspillages et les améliorations, en associant les acteurs du processus 1ère Identification des gaspillages (sans l’arbre des gaspillages) Objectif  : Apporter des réponses par le biais d’échanges interactifs, où chacun s’exprime librement par rapport à son expérience. Commencer par l’axe dont le taux est le plus en retrait (la Qualité par exemple). Quelles sont les raisons pour lesquelles la Qualité est insuffisante ?  Continuer axe par axe en suivant cet ordre de priorité Parmi les réponses apportées, certaines peuvent concerner un autre axe. Peu importe, la proposition est notée pour être abordée un peu plus tard, lorsque l’axe en question sera étudié. Identifier les leviers d’amélioration Objectif : Définir un plan d’actions prioritaires Identifier une ou plusieurs actions pour chaque gaspillage Répertorier les quick-wins en fonction de la complexité de mise en œuvre de chaque action et de la plus-value apportée Proposer un premier plan d’amélioration (la finalisation et la mise en œuvre nécessiteront des réunions complémentaires)
  • 26. Livre Blanc Follow Us26 Atelier TIMWOOD Une approche alternative consiste à organiser un atelier d’identification des gaspillages en s’appuyant sur la méthode TIMWOOD, issue du Lean Management. Le Lean Management suggère en effet, pour optimiser les processus de l’entreprise et créer efficacement de la valeur, d’identifier systèmatiquement toutes les sources de gaspillages afin de les éliminer ou les réduire. L’industrie distingue sept types de gaspillages appelés Muda. L’acronyme TIMWOOD correspond en anglais aux initiales de ces sept gaspillages. Cette méthode a été appliquée par les membres du Think Tank pour identifier les gaspillages au sein du flux DevOps “Idea to Production”. Le résultat de l’atelier est illustré en page suivante. TIMWOOD Transportation Fait référence aux déplacements des produits finis ou semi-finis soumis à des risques de détériorations, de pertes, de délais supplémentaires et de charges de travail supplémentaires. Inventories Fait référence aux stockages intermédiaires et aux inventaires effectués en cours de processus. Ceux-ci ne contribuent pas à la transformation du produit et générent des surcoûts n’apportant aucune valeur ajoutée. Motion Fait référence aux déplacements inutiles des moyens humains et matériels en cours du processus de fabrication et qui peuvent avoir des impacts de détérioration, d’usure et de sécurité inutiles. Waiting Fait référence au temps d’attente de l’activité ou de la tâche suivante pour les produits ou services qui ne sont pas en cours de transport, de fabrication ou de transformation dans leur processus. Over-production Fait référence à la surproduction de produits fabriqués par rapport à la demande / commandes clients. Over-processing Fait référence aux activités et tâches inutiles et/ou qui n’apportent pas de valeur ajoutée au client ainsi qu’aux outils d’utilisation (logiciels, procédures, instructions de travail) qui sont trop précis, trop complexes, ou plus coûteux que nécessaire. Defects Chaque fois que des défauts et rejets des produits finis et semi-finis arrivent, des coûts supplémentaires sont supportés pour retravailler les produits, détruire les défectueux, reprogrammer la production, ...
  • 27. Livre Blanc Follow Us27 Le Lean Management suggère, pour créer efficacement de la valeur, d’identifier les sources de gaspillages et de les éliminer ou les réduire afin d’optimiser les processus de l’entreprise. L’industrie distingue 7 types de gaspillages issus de la méthode Lean et appelés Muda qui peuvent être transposés en DevOps selon le moyen mnémotechnique TIMWOOD. • Incapacité du modèle de transport des packages applicatifs à atteindre les objectifs de volumétrie, fréquence, délai et productivité • Inaptitude de fournisseurs de code (ex. TMA) à s’aligner sur les objectifs • Hétérogénéité des outils et procédures utilisées, nombreuses tâches manuelles • Surcapacité des environnements hors production • Environnements créés mais non utilisés ou non décommissionnés • Environnement de développement ou de tests surdimensionnés • Doublonnement et non fiabilité des référentiels nécessaires au fonctionnement de la chaine d’automatisation • Chaqueoutil,chaqueéquipedelachaînededéploiementpossèdesonréférentielpropre • Les référentiels des versions applicatives et des infrastructures ne sont pas à jour • Hétérogénéité des pratiques agiles des équipes de développement impliquant une perte d’efficacité aux interfaces avec la production et les métiers • Impossibilité pour les équipes Ops d’industrialiser leurs activités • MOA et Métiers en décalage avec ces pratiques • Réalisation de tâches humaines répétitives et systèmatiques • Tests (non regression, performance, techniques) • Déploiementsapplicatifs,miseàdispositiondesenvironnements • Mobilisationexcessivedescontributeursparmanquedecapitalisationdel’information • Allers-retours entre équipes de développement et métiers pour qualifier le besoin • Réunions d’analyse d’impact et de validation • Mauvaise priorisation : les fonctionnalités à forte valeur ajoutée attendent la fin du développement des stories moins critiques • Membresducomitédepriorisationnonreprésentatifs,manquedeconnaissancedumétier • Retard dans la mise à disposition d’environnements de recette ou de production • Manque d’anticipation, de communication et d’automatisation du provisionning • Fonctionnalités validées en attente de mise en production • Les packages attendent une fenêtre de livraison • Un ou plusieurs incidents en cours bloquent toute mise en production • Blocage de l’ensemble d’une mise en production en raison d’éléments défectueux • Manque de réactivité aux étapes clés du cycle de développement • Sprint reviews, recette fonctionnelle, validation • Manque de disponibilité des équipes métiers, des experts, du management • Fréquence de livraison non alignée avec les besoins réels du métier • Livraison applicative trop fréquente sans valeur pour le métier • Fréquence de livraison trop basse impactant le business des métiers • Gestion des changements et gestion des projets trop bureaucratiques • Automatisation locale n’améliorant pas la performance de bout-en-bout • Automatisation avancée de l’intégration continue alors que la contrainte est sur les tests ou le déploiement • Mise à disposition de fonctionnalités non demandées • Miseàdispositiondefonctionnalitésdemandéesnecorrespondantpasàunbesoinréel • Rédaction de documentations utilisateur qui ne sont pas lues • Blocage de production avec impact sur les clients finaux • Régression majeure non identifiée lors de l’analyse d’impact du changement • Erreur manuelle lors du déploiement • Régressionsfonctionnellesdansl’applicationmiseàjouroudanslessystèmesconnexes • Introduction d’une dette technique générant un surcoût de maintenance • Non respect des exigences non fonctionnelles T ransportation M otion O verprocessing I nventories W aiting O verproduction D efects Lean IT : Cartographie des Gaspillages DevOps automic.com
  • 28. Livre Blanc Follow Us28 Etape 9 : Système de pilotage Il convient à ce stade de définir et mettre en place les modalités et les instances de gouvernance associées au TRS : • Répondant à l’intention initiale de pilotage de la Performance (cf. Etape 1), • Conforme à la culture de pilotage de l’organisation. Cette étape vise à s’assurer qu’un certain nombre de préalables sont rassemblés pour que l’analyse de cause s’inscrive dans une boucle d’amélioration continue efficace : • Inscrire la démarche dans un cadre de pilotage de la Performance, • Identifier un sponsor et mobiliser les ressources nécessaires, • Partager le vocabulaire et former les contributeurs de la démarche aux nouveaux concepts, • Communiquer sur les modalités de mise en œuvre et les résultats attendus. Le sponsor de l’initiative devra clairement établir la cible de l’amélioration de la Performance attendue ainsi que le périmètre des acteurs et contributeurs concernés (organisation interne, infogérants, tiers identifiés, etc.). La conduite du changement peut s’effectuer à travers des séances de sensibilisation à la démarche, des formations à partir de cas concrets. Le mode de pilotage ciblé est à expliciter versus une démarche classique selon les objectifs poursuivis : partage d’un objectif d’amélioration continue commun, mesure de l’efficacité opérationnelle, etc. Des objectifs peuvent être également fixés aux contributeurs de la démarche en terme d’amélioration du TRS et ce afin de renforcer l’intégration de ces pratiques dans les activités courantes. Différentes modalités de pilotage sont présentées ci- après au travers de différents cas. Ces cas illustrent différentes orientations que peut recouvrer le pilotage de la Performance à travers l’utilisation du TRS. Par ces différents exemples, on constate que le TRS peut être utile dans le pilotage d’une ou plusieurs entités opérationnelles, d’un ou plusieurs fournisseurs, d’un ou plusieurs streams. Le point commun à ces différents systèmes est d’inscrire le pilotage de la Performance opérationnelle dans une démarche d’amélioration continue.
  • 29. Livre Blanc Follow Us29 Etape 10 : Industrialisation L’Industrialisation consiste à mettre en place l’organisation et l’outillage adapté à la collecte et au traitement des données. Elle se justifie : • Lors d’une extension de périmètre : passage du périmètre pilote au périmètre cible, • Et/ou si la pérennisation de la mesure a été actée, l’objectif étant d’inscrire le TRS dans une gouvernance ad hoc ou préexistante. L’organisation comprend : (1) Un responsable du TRS, clairement identifié dont la mission est de : • Veiller à la réalisation des mesures selon la fréquence convenue et à la publication du tableau de bord, • Animer l’identification de leviers potentiellement nécessaires en cas de dérive du TRS, Intention initiale Culture de pilotage Cas 1 : Atelier d’Amélioration Améliorer l’efficacité opérationnelle d’un projet pilote DevOps incluant Dev et Ops Culture de l’amélioration continue encourageant la prise d’initiative Cas 2 : Organisation en domaines applicatifs Améliorer le pilotage des différents domaines en utilisant des indicateurs de progrès Gouvernance centralisée en charge du pilotage de la performance Cas 3 : Programme de transformation Fédérer les différents streams d’un programme de transformation DevOps autour d’objectifs de progrès partagés Revues individuelles des objectifs des streams mais difficulté à démontrer l’efficience globale de la démarche Cas 4 : Relation avec les sous- traitants et partenaires Piloter les actions d’amélioration des fournisseurs en mesurant leur contribution à la performance d’ensemble Comités stratégiques et comités de pilotage sur la base d’engagements contractuels
  • 30. Livre Blanc Follow Us30 • Contrôler l’application des leviers d’amélioration définis, • Exprimer les éventuels besoins liés à un outillage plus automatisé pour la mesure. (2) Une ou plusieurs équipes impliquées dans la mesure (collecte et traitement), l’analyse et l’arbitrage. L’outillage adapté à la collecte et au traitement des données peut s’appuyer sur : • Les systèmes de métrologie existants (ex. BI), • Les systèmes de métrologie propres à des outils spécifiques au périmètre cible (ex. APM, Qualité de Code, Release Automation, Orchestration, IT Service Management, etc...), • Les outillages internes à une entreprise basés sur des tableurs ou des bases de données. Le tableau ci-dessous propose une typologie d’outils sources permettant de recueillir les données nécessaires au calcul du TRS et du TRG : Pour terminer, le TRS peut être utilisé à des fins de benchmark. Dans ce cas précis, l’industrialisation doit prévoir de normaliser les mesures et d’obtenir des valeurs qui pourront être comparées entre pairs. L’usage d’outils partagés peut faciliter cette démarche. CHARGE DISPONIBILITE PERFORMANCE QUALITE • Capacity Management • Performance Management • Monitoring • Service Request Management • Orchestration • Release Management • Release Automation • Incident Management • Code Quality • Application Performance Management
  • 31. Livre Blanc Follow Us31 A propos du Think Tank Automic Créé en 2010, le Think Tank Automic est un groupe de réflexion constitué d’une vingtaine de décideurs informatiques issus de différents secteurs d’activités, privés ou publics, et consacré au pilotage de la performance. En 2011, le Think Tank Automic met l’accent sur un indicateur innovant issu des méthodes industrielles : le Taux de Rendement Synthétique (TRS). En 2012, les membres passent de la théorie à la pratique et appliquent le TRS dans leurs organisations : mesure et pilotage, normalisation des concepts et identification de nouveaux besoins. En 2013 et 2014, le Think Tank étend la communauté d’adoption de l’approche TRS et propose un guide pratique d’implémentation du TRS incluant fiches pratiques et méthodologie. En 2015 et 2016, le groupe propose de mobiliser les équipes Etudes et Production autour d’un même objectif en transposant à DevOps le Taux de Rendement Synthétique (TRS). Le résultat de ces travaux est présenté dans ce nouveau guide “Quelle métrique pour fédérer Dev & Ops ?”.
  • 32. Pour plus d’information ou démonstration des solutions Automic, visitez notre site www.automic.com Automic, leader de l’Automatisation des processus d’entreprise, aide les organisations à gagner en compétitivité en automatisant leur informatique d’entreprise, de l’hébergement sur site au Cloud, en passant par le Big Data et l’Internet des Objets. Avec ses bureaux dans le monde entier, le groupe soutient les activités de 2 600 clients parmi lesquels Bosch, Netflix, eBay, AMC Theatres, Carphone Warehouse, ExxonMobil, BT Global Services, Société Générale, NHS SBS, General Electric et Swisscom. Automic est une société privée détenue par EQT. Pour plus d’informations : http://www.automic.com/fr A propos d’Automic Institute Automic Institute a pour mission de promouvoir l’expertise du groupe Automic en s’appuyant sur l’ensemble des savoirs de l’entreprise pour partager convictions, connaissances et expériences en Management des Opérations Informatiques. • Les Publications alimentent la communauté des managers des Opérations Informatiques en faits et en opinions, • Les Communautés et Think Tank sont des réunions de décideurs informatiques décidés à faire émerger les idées qui seront la réalité de demain en matière de Management des Opérations Informatiques, • Les Trivial Pursuit™ Edition IT sont des outils pédagogiques innovants pour sensibiliser les équipes informatiques : Lean IT, Cloud, Management de Projet, ITIL®, … Contacter Automic Automic Tour Pacific 11, cours Valmy 92800 Puteaux, France Web www.automic.com