Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Les sept « Règles d'Or » de la Production Industrielle


En ces temps troublés de complexité croissante des exploitations informatiques, il est tentant de penser que le cap du gérable est largement dépassé...

Voici quelques règles inspirées du monde de l'industrie pour "remettre sous contrôle" puis améliorer une production informatique.



Les sept « Règles d'Or » de la Production Industrielle
La production de services IT d'une entreprise peut être qualifiée d’industrielle lorsqu’elle est mise sous contrôle et autant que possible automatisée.

Or, l’expérience du terrain montre que lorsqu’on se penche sur une production existante, son état est variable, mais il est rarement idéal.

A partir de notre expérience et de nos études, nous proposons ici une synthèse sous forme de sept « règles d'or » pour l'industrialisation de la production de services IT.

Nous distinguons ici deux catégories de règles : d'une part, les règles obligatoires permettant une mise sous contrôle de la production et, d'autre part, celles permettant éventuellement d’améliorer la production en termes de coût, de qualité et de fiabilité.

LA MISE SOUS CONTRÔLE DE LA PRODUCTION

Dans cette catégorie, on trouve des règles fortes permettant de "reprendre la main". Sans elles, aucun contrôle de la production n'est possible aisément. Le respect de ces règles est obligatoire pour permettre au producteur d’assumer sa responsabilité et indispensable pour mettre en œuvre les règles qui suivent,

Règle 1 : le périmètre de production est connu et délimité

Ce périmètre est celui sur lequel le « producteur » exerce ses missions. Il peut varier en surface selon les clients, se limiter à des moyens techniques réduits ou englober un ensemble beaucoup plus large allant jusqu’à la délivrance d’un service complet à haut contenu fonctionnel.

Sur ce périmètre, l’ensemble des éléments qui concourent à la production sont identifiés. Il s’agit de divers matériels et logiciels (systèmes et sous-systèmes avec leurs niveaux de version/release/patch, code source, exécutables, script, outil, fichiers...) mais aussi - et c’est important - de consignes, de procédures sous forme papier ou électronique,...

Sur ce périmètre le « producteur » exerce sa mission de pilotage opérationnel du service. Par construction en effet, une seule entité assure le pilotage opérationnel du service industriel (« un seul pilote dans l’avion ! »).

Les éléments du périmètre doivent être cohérents et complets. Toute incohérence (ex:niveaux de release non conformes entre système et sous-systèmes) ou tout manque (ex:exécutable sans source, procédures inexistantes) doit être l’objet d’un constat et d’une correction autant que possible.

Les éléments du périmètre sont par définition stables entre deux changements. Le changement prendra pour point de départ l’élément de production connu qui sert donc de référence. Lorsque le changement est achevé, l’élément se trouve dans un autre état qui devient la nouvelle référence.

Le contenu du périmètre est délimité, il est clairement séparé de tout autre environnement ne concourant pas à la même production ou servant une autre finalité (test, probatoire,...).

Le périmètre est protégé par les procédures de gestion de changements (voir plus bas) qui permettent au « producteur » de maîtriser les éléments de production et d’assumer dans le temps sa responsabilité de garant de la production industrielle.

Cela se traduit par des droits d’accès et d’administration isolés et protégés par des outils de sécurité.

Cette protection peut aussi se matérialiser par l'emploi d'outils de transfert entre environnements . Les validations et possibilités de retour arrière sur changement seront prévues.

Règle 2 : chaque élément a un propriétaire et un seul

Il n'y a donc pas d'élément sans propriétaire, ni d’élément à propriétaires multiples.

Le propriétaire est une entité de l’organisation (qui peut être chez le producteur mais aussi ailleurs, selon le découpage effectué).

Assez souvent deux types de propriétaires sont identifiés: les divers gestionnaires de service ou responsables applicatifs pour tout ce qui est de nature fonctionnelle et des entités de type « ingénierie » ou « support technique » pour tout ce qui concerne les moyens techniques de type infrastructure.

Dans le cas de recours à des progiciels (exemple : SAP, Oracle Applications,…) un représentant interne à l’organisation est souhaitable pour porter la responsabilité.

Le propriétaire doit définir ses exigences en termes de production opérationnelle : le niveau de service attendu (sécurité, performance,...), les évolutions, donc les changements à prévoir sur ses objets.

Le propriétaire doit fournir au producteur opérationnel un produit fini complet (y compris consignes,...) de manière à ce que cela puisse être pilotable et puisse "marcher sans lui".

Le propriétaire prévoit et communique les ressources nécessaires, et leur évolution.

Il se conforme aux normes et préconisations négociées régissant ses relations avec le producteur opérationnel.

Le producteur opérationnel s’adresse au propriétaire de l’élément pour toute escalade sur incident ou tout changement concernant cet élément.

Le propriétaire doit résoudre les problèmes qui concernent ses éléments et il est l’initiateur des changements sur ses éléments.

Le propriétaire s’adresse lui-même à divers fournisseurs internes ou externes.

Règle 3 : il existe une gestion des configurations / changements / incidents

On peut ici se référer au vocabulaire de l’ITIL ou autre référentiel. Toutefois, ces référentiels ne disent rien sur les responsabilités qu’il faut donc introduire.

Configuration :

Les éléments de configuration sont les éléments du périmètre de production qui concourent à la production de service et présentent l’une ou l’autre des caractéristiques suivantes:
  • ils sont attachés à un coût (amortissement, maintenance,...)
  • ils sont susceptibles d’être changés,
  • ils sont susceptibles de connaître un incident.

Aucune distinction n’est faite entre des éléments dits techniques et des éléments dits applicatifs. Tous ces éléments concourent ensemble à la production de service. C’est sur les éléments de la configuration que vont porter les changements et les incidents.

Un élément qui n’est pas dans la configuration de la Production ne participe pas à la Production du Service.

Le niveau de finesse de définition des éléments de la configuration peut varier. Normalement l’élément de configuration est la plus petite entité susceptible d’être changée indépendamment des autres.

Un outil de gestion de configuration sera utilisé. La base de données ainsi gérée devra être maintenue. Par expérience c’est difficile. Il existe aussi fort probablement d’autres configurations gérées ailleurs par les « responsables » d’éléments (dans les équipes de type ingénierie par exemple) avec des niveaux de détails et de suivis probablement plus fins. Au besoin, il faudra réaliser des extractions de ces bases vers la base de production. Une entité de type « gestion des changements » peut se voir confier une responsabilité au moins de contrôle de bonne gestion de la base en production.

Incidents :

Tout élément de configuration comporte des spécifications décrivant son comportement attendu « normal ».

Un incident est une occurrence d’écart entre les spécifications d’un élément de configuration et ce qui est constaté. Un incident concerne toujours un élément de la Configuration. Un incident peut ne pas avoir d’effet immédiat sur le service rendu au client, néanmoins l’objectif de la gestion d’incident est de rétablir le service en conformité avec les Conventions de Service.

Le « pilote » de la production doit être capable d’identifier l’incident et de savoir ce qu’il faut faire pour aller vers un rétablissement du service dans un état conforme aux Conventions de Service.

Différent type de workflows sont à prévoir :
  • rapide, en recourrant aux solutions connues (ou remèdes connus, ou erreurs connues,…) pour rétablir vite le service au niveau des opérations ou pilotes,
  • d’escalade pour action vers les entités « propriétaires » ou autres experts lorsque le pilote n’a pas -ou estime ne pas avoir- les moyens de rétablir le service,
  • d’information vers toute entité ayant à savoir ce qui se passe en terme de service au client.

On s’attachera à rendre plus fréquents les flux rapides et plus rares les flux lents. Cela se fait de plusieurs manières (transfert de savoir-faire de l’ingénierie vers la production, documentation d’incidents et de corrections, etc.)

Le flux pour information doit être suffisamment informatif : il ne faut pas perturber l’opérationnel par des questions d’incompréhension.

Changements :

Un changement est un événement prévisible qui, par sa réalisation ou son activation, produit la création, la suppression ou la modification d’un élément de la configuration, ou fait évoluer les relations qui lient des éléments.

L’impact d’un changement s’estime par rapport à la perturbation ou au risque de perturbation qu’il apporte à la production et non par rapport à sa taille (en nombre de programmes ou autres,...) ou à son importance technique.

Un changement est traité par une procédure spécifique qui tient compte des exigences de la production de Service. Cette procédure prévoit des validations.

Les changements se demandent dans un format convenu. Ils sont acceptés, replanifiés ou refusés. Un Comité Changement doit exister et statuer.

L’évaluation d’impact doit être faite avec rigueur. Sur les impacts élevés, une diminution du risque (par prévision du retour arrière par exemple) devra être obligatoirement proposée.

L'AMELIORATION DE LA PRODUCTION

La mise en oeuvre des règles qui suivent permet d’augmenter la rentabilité, la proactivité de la production et de diminuer les risques.

Elle n’est cependant pas systématique car elle nécessite un investissement dont la rentabilité n’est pas forcément obtenue dans le cadre des situations diverses observées.

Il est possible d’y associer le client ou l’utilisateur.

Règle 4 : les éléments sont pilotables

Les éléments de production renseignent sur leur état le pilote opérationnel du service. Celui-ci possède des informations lui permettant de découvrir et de traiter les incidents.

Le pilote opérationnel s'engage à produire un service conforme à ce qui est négocié avec le gestionnaire du service. Concrètement cela signifie que les incidents en exploitation sont traités par le pilote, par application des consignes fournies et l'ouverture procédurée d'incident qui provoque les escalades prévues.

Cela signifie que le pilote a une intelligence du service produit. Intelligence communiquée formellement par le gestionnaire du service.

Face à des éléments non pilotables un effort minimal est à entreprendre pour faire remonter des alertes et définir des consignes. Les actions dans ce domaine sont des projets d’ampleur variable selon le coût, les améliorations attendues et le niveau de risque acceptable. Ces projets font l’objet d’études de retour sur investissement. Il est fortement probable qu’un minimum vital soit à atteindre dans ce domaine.

Il est inconcevable qu’une production puisse être qualifiée d’industrielle et possède encore des éléments non pilotables. L’existence d’éléments non pilotables provoque souvent des dépendances de type astreinte vis - à - vis des propriétaires de ces éléments ou de leur fournisseurs. Cette situation provoque des surcoûts, de la non-qualité et empêche le producteur opérationnel d’assumer sa responsabilité.

Le propriétaire d’un élément doit s’assurer qu’il est pilotable…sans cela il le paie par une escalade du pilotage vers lui avec les charges et astreintes induites.

Règle 5 : un bon niveau d'automatisation est atteint

L’automatisation consiste à pouvoir enchaîner des tâches sans intervention humaine.

En effet, certaines tâches doivent disparaître; il s'agit par exemple des opérations simples répétitives, des opérations qui nécessitent de manière excessive une présence d'opérateur en salle (« message console ») et qui donc sont génératrices de coûts ou encore d’opérations laissant trop de place à l’erreur humaine.

L’obtention d’un bon niveau d’automatisation nécessite souvent un véritable réingéniering de l’exploitation : amélioration des séquences, du parallélisme, suppression d’étapes inutiles, programmation de contrôles...

Les actions dans ce domaine sont des projets d’ampleur variable selon le coût et les améliorations attendues. Ces projets font l’objet d’études de retour sur investissement.

Règle 6 : une normalisation existe

Cette normalisation peut porter sur les choix techniques (type de fichiers ou bases à utiliser, codage de JCL ou de script, paramètres divers, etc...) mais aussi sur les nommages etc...

Chaque cas amène potentiellement sa ou ses normalisations dont certaines sont probablement intéressantes à conserver en l’état.

Les actions dans ce domaine sont des projets d’ampleur variable selon le coût et les améliorations attendues. Ces projets font l’objet d’études de retour sur investissement.

Il conviendra de traiter différemment les situations héritées et les situations pour lesquelles un degré de choix existe (Etude en interne, client en recherche de normes par exemple).

Règle 7 : les produits recommandés sont utilisés

Pour des raisons de diminution de coûts liés par exemple à une mutualisation sur des outils ou des produits connus, il peut être intéressant de faire évoluer tout ou partie d’une exploitation donnée vers telle ou telle cible.

Le passage d’outils « maison » vers des outils standard du marché sera très fortement recommandé.

Il conviendra de traiter différemment les situations héritées et les situations pour lesquelles un degré de choix existe (Etude en interne, client en recherche d’outils par exemple).

Plus que toute autre, les actions dans ce domaine sont des projets d’ampleur variable selon le coût et les améliorations attendues. Ces projets font l’objet d’études de retour sur investissement.

CONCLUSION

Une production "industrielle" est souvent présentée comme un idéal à atteindre dans le monde de l'informatique qui est soumis à forte turbulence. Il est nécessaire pour cela de se donner des règles strictes et de les respecter.

La prise en compte des responsabilités que ces règles induisent introduit progressivement des cercles vertueux d'amélioration. La délimitation claire des responsabilités permet aussi d'améliorer le professionnalisme de chacun qui voit son métier reconnu dans un contexte apaisé.

Enfin on soulignera l'importance de la rapidité de décision et d'exécution dans le cadre des règles pour rester réactif aux demandes de l'usager.
Emmanuel Besluau
Mercredi 1 Février 2012

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Duquesne Research Newsletter