Duquesne Group Duquesne Group

English version
Blog des experts

Les avis et les commentaires exprimés dans les blogs sont ceux des experts individuels. Ils ne représentent pas nécessairement l'opinion du cabinet. Contactez-nous pour en savoir +
French version
Blogs

In these blogs, individual experts freely express their own opinions and comments. They do not necessarily reflect the opinion of the firm. Contact us to find out more


A nouvelles pannes, nouvelle approche !


Dans le monde du service nous expérimentons de plus en plus comme usager des pannes fréquentes de durées variables. Il suffit de prendre le métro ou d’avoir une box chez soi pour en faire l’expérience.

En usine, la mondialisation et les réseaux ont créé des dépendances intercontinentales qui importent aussi les pannes.

Toutes ces interruptions dues la plupart à des « éléments informatiques » changent complètement les approches traditionnelles de prévention et résolution. Voici quelques réflexions sur le sujet.



Photo EBesluau
Photo EBesluau

Un paysage bouleversé

Dans un récent colloque, un ancien président d’opérateur téléphonique annonçait « avant, nous avions une grosse panne tous les quatorze ans…maintenant nous avons quatorze pannes par an. »

Les systèmes de production sont devenus de plus en plus complexes et reposent sur des éléments informatiques de plus en plus nombreux et interdépendants dans une logique qui n’apparaît pas en première analyse.

Prenons quelques exemples tous vécus :

  • Hier soir votre émission de télévision préférée a été très fortement perturbée, l’image se figeait et se découpait en carrés inesthétiques. Le son était haché et incompréhensible. Vous avez mis fin à la torture au bout de deux minutes. Il y avait probablement une panne d’un ordinateur serveur parmi les nombreux utilisés pour rendre le service. Votre box elle-même est un ordinateur, votre opérateur réseau recourt à de nombreux serveurs de traitement d’image, de stockage intermédiaire, de conversion de formats, etc. La chaîne est longue et les candidats au maillon faible nombreux !

  • Votre prochain métro est "annoncé dans une minute, le suivant dans quatre minutes" et pourtant cela fait cinq minutes que vous attendez. Votre train régional roule au ralenti et le conducteur vous annonce que tous les feux sont à l’orange et qu’on essaie de comprendre pourquoi. La signalisation est pilotée par informatique, les annonces aux passagers aussi, les ordonnancements de circulation idem. Où se situe réellement le problème ? Qui peut d'ailleurs le savoir ?

  • Une usine située en Chine produit des matériels pour un fabricant français. Dans certaines situations, cette usine a besoin de consulter des descriptifs techniques (type ‘bill of material’) dans leur toute dernière version. Or ceux-ci résident sur SAP dans un serveur situé en France. Ce serveur n’est pas particulièrement l’objet d’attention. Il en va de même de ce serveur situé en usine celui-là et qui traçe précisément toute l’activité et les ordonnancements faits. Sans cette traçabilité, il faut tout arrêter et repartir d’un point propre qui oblige à jeter des en-cours suspects. Panne en France : arrêt en Chine. Retard de livraison au Brésil...

  • On pourrait aussi prendre des exemples dans l’automobile où un dysfonctionnement logiciel généré par un i-phone connecté, empêche de passer la marche-arrière ou laisse l’essuie-glace arrière en marche permanente (authentiquement vécu). Combien de lignes de code dans une automobile moderne ? 200 000 ?

Ces exemples issus du monde réel sont typiques de l’évolution générale de la société vers le tout informatique.

Les conséquences sont très importantes à analyser si l’on vise la continuité d’activité.

Qu'est-ce que cela change ? Vision avant/après

Ou le jeu des sept différences…entre autrefois et maintenant que l’informatique est partout.

1 – Avant, la panne avait des causes physiques détectables assez facilement.
Maintenant, à ces causes physiques qui demeurent, il faut ajouter des causes logiques (ou dues au logiciel) qui sont beaucoup plus difficile à détecter et identifier. Le service s’interrompt sans que l’on puisse ‘identifier une panne’. Il se dégrade sans que l'on sache d'où cela vient.

2 – Avant, quand un élément était en panne, on savait assez bien le réparer. Par échange standard ou par une opération assez simple avec des pièces de rechange, la réparation était en général efficace pour redémarrer. La réparabilité était un critère de disponibilité. Maintenant, une panne ou un ralentissement sur un serveur nécessite d’investiguer beaucoup plus. La panne peut d’ailleurs disparaître sans que l’on sache exactement à quoi elle est due (après un simple re-boot).

3 - Avant, l’opérateur du service était proche de la cause de la panne et de sa résolution. Un commutateur présent dans ses locaux était défaillant, un outil trop usé ou cassé, sous ses yeux... Maintenant, le conducteur de métro qui voit tous les feux au rouge n’a aucun moyen de savoir qu’il s’agit d’une mise en sécurité due à panne logicielle sur un serveur à 20 km, dont il ignore jusqu’à l’existence.

4 – Avant, la réparation réparait réellement. L’élément défectueux re-marchait, la production était relancée là où elle s’était arrêtée ou presque. Maintenant une réparation logicielle sur un serveur peut s’avérer problématique et avoir des conséquences indirectes provoquant le dysfonctionnement d’autres services connexes. Et cela longtemps après la panne.

5 - Avant, le lien entre élément en panne et service arrêté était direct et connu. Le constat étant évident à faire. Aujourd’hui, l’arrêt en heure non ouvrable de votre SAP en France empêche votre usine de Chine d’accèder aux ‘bills of material’ : vous ne le découvrez que quand vous tombez dessus ! Votre routeur en salle est arrêté… vous ne savez qui est impacté que parce que le help desk reçoit des appels d’utilisateurs mécontents. Même si cette pratique est "répréhensible", elle est très courante hélas.

6 - Avant, il suffisait de prévoir la panne machine pour assurer une disponibilité de service. L’approche bottom-up était possible. Analyser les machines nécessaires à la production et améliorer leur fiabilité, permettait d’améliorer la disponibilité du service ou de la production. Aujourd’hui, la méthode bottom-up oblige à analyser trop d’éléments dont certains ne sont pas de notre ressort. Une approche top-down s’impose à partir des services prioritaires. On part de ces services prioritaires et on essaie de savoir sur quoi ils s'appuient.

7 - Avant, la compétence pour réparer était assez proche de la compétence pour opérer, géographiquement et techniquement. L’opérateur en usine pouvait avec la supervision du contremaître changer un outil. Mon garagiste changer une courroie. Aujourd’hui pour ‘réparer’ des éléments informatiques il faut télécharger la nouvelle version du logiciel de traçabilité en usine (la Chine demande à la France de la télécharger à partir de l’Inde où la dernière version est créée). Mon garagiste ne peut pas réparer ce matin car sa box adsl est en panne…et il n’a plus accès au cloud du constructeur. Je dois repasser cet après-midi pour une mise à jour à partir du site du constructeur automobile ; avec ma clé de contact et mon code.

Toutes ces différences campent un nouveau décor largement mis en place à ce jour.

Quel effet sur les PCA ?

Pour élaborer un PCA, une approche traditionnelle consiste à envisager les pannes des éléments de production de biens ou de service.

Or, on l'a vu, il est devenu très difficile d’analyser les moyens de production de biens et de services : ils sont désormais très nombreux, leurs interactions sont complexes et ils ne sont pas tous gérés en interne, ni identifiés comme importants dans la production.

Les approches bottom-up d’analyse des pannes de toute la production pour améliorer la continuité d’activité ont donc des limites dans ce nouveau paysage : elles se heurtent à la complexité et sont limitées en périmètre. Elles risquent de durer longtemps, d'analyser des éléments peu utiles et d'en oublier qui sont importants. Il faut compléter cela par une approche descendante.

Les approches top-down en effet, en se focalisant sur les activités prioritaires et importantes et en « zoomant » sur leurs moyens tous azimuts peuvent aider :

  • A se focaliser sur les activités importantes prioritaires et uniquement sur elles
  • Pour ces activités, à découvrir finement les moyens sur lesquelles elles reposent (internes, externes, informatiques, réseaux, cloud, etc.)
  • Sur tous ces moyens réaliser des analyses de risques et déterminer ce qui nécessite traitement.


Cette approche top-down existe déjà, c’est le BIA (Business Impact Analysis). Elle permet de se focaliser vite sur les éléments importants pour le service et de travailler de manière ciblée sur leur disponibilité.

Cela est est devenu indispensable pour compléter les analyses de risques bottom-up dans le monde actuel. Cet approche métier qui consiste à partir du service "vécu par le client" et à descendre sur les moyens et l'organisation nécessaire est à faire et refaire.

On peut consulter notre site pour diverses recommandations sur le sujet.


Emmanuel Besluau
Lundi 16 Juin 2014

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


Articles du même auteur :

Halte aux PCA bidons ! - 19/01/2014

1 2