Make IT Strategic - Blog notes en français

Dans la boîte à outils du consultant en amélioration de processus, de l’urbaniste de SI, de l’ingénieur qualité ou du chef de projet informatique, on trouve le diagramme d’Ishikawa aussi connu sous le nom de diagramme de causes et effet (cause-and-effect diagram en anglais) ou diagramme en arêtes de poisson (fishbone diagram). Cet article a pour but de présenter l’intérêt de cet outil graphique.

Présentons d’abord le Docteur Kaoru Ishikawa (1915 - 1989), créateur éponyme en 1982 du diagramme de causes et effet. Il est le fils d’Ichiro Ishikawa, patron entre 1950 et 1968 du Nippon Keidanren, principal syndicat patronal au Japon, l’équivalent du MEDEF en France. Kaoru Ishikawa a démarré sa carrière comme ingénieur chimiste puis a repris ses études pour se diriger vers la recherche sur le contrôle de qualité. Il a obtenu son doctorat en 1960. Il est aujourd’hui considéré comme un gourou de la qualité. Il est connu comme un des artisans, avec William Edwards Deming notamment, du concept de Total Quality Management (TQM). Un des objectifs d’Ishikawa était de lutter contre une mauvaise réputation concernant la qualité dont souffraient les produits japonais après la seconde guerre mondiale.

Le diagramme d’Ishikawa recense les causes aboutissant à un effet. La flèche horizontale est l’épine dorsale. Elle se termine par l’effet attendu.

Des flèches obliques, sortes d’arêtes de poissons reliées à l’épine dorsale, groupent les causes en catégories.

Il existe des catégories standards célèbres adaptées à certaines problématiques ou certaines industries :

• les 5M : Matières premières, Matériel (les machines-outils, matériel informatique, logiciels, les locaux), Méthodes (les modes opératoires), Main-d’œuvre (les ressources humaines) et Milieu (l’environnement, le positionnement, le contexte)
• les 6M : 5M et Mesures
• les 7M : 5M, Management et Moyens financiers (plus adaptées aux services)
• les 8P : en anglais : Price, Promotion, People, Processes, Place, Policies (règles), Procedures et Product (ou service)
• les 4S : en anglais : Surroundings (environnement), Suppliers (fournisseurs), Systems, Skills (compétences)

Ci-dessous, un diagramme d’Ishikawa avec les 5M :

Aux flèches des catégories viennent se greffer les causes et les sous-causes :

La première application du diagramme d’Ishikawa est l’analyse de causes racines (Root Cause Analysis [RCA]). L’objectif est de trouver les causes d’un problème, un dysfonctionnement par exemple. CMMI Niveau 5 consacre un Process Area pour cette activité : Causal Analysis and Resolution (CAR). ITIL traite du sujet dans la gestion des problèmes (Problem Management).

On peut ensuite agir sur les causes pour diminuer la probabilité de subir l’effet. Dans l’exemple ci-dessus, il va s’agir notamment d’augmenter le stock de pièces détachées, remplacer le matériel le plus ancien… et acheter une climatisation.

A l’inverse, on peut également utiliser le diagramme d’Ishikawa pour modéliser les objectifs stratégiques d’une entreprise ou d’une DSI par exemple dans le cadre d’une démarche d’urbanisation ou d’amélioration des processus. On ne cherche plus alors à éviter l’effet mais au contraire à en favoriser l’apparition (exemple : augmenter le chiffre d’affaires).

A noter : Visio propose un modèle pour réaliser facilement des diagrammes d’Ishikawa.

Références :

1. Diagramme de causes et effets, Wikipédia (Français)
2. Kaoru Ishikawa, Wikipédia (Français)
3. Kaoru Ishikawa, Wikipedia (English)
4. Ishikawa diagram, Wikipedia (English)
5. Comment le Japon est passé au premier rang de l’économie mondiale, Céphale, AgoraVox, 5 septembre 2007
6. Root Cause Analysis (Analyse de Cause Racine), 12manage
7. Experiences in Root Cause Analysis and Defect Prevention Methods, Kelly L. Lanier, Raytheon, 2003

Dans le cadre du Blog Day 2007 qui a lieu aujourd’hui le 31/08, nous vous proposons de découvrir 5 blogs que nous apprécions particulièrement.

Serge Baccou vous propose la lecture des blogs suivants :

• Ingénierie logicielle - La chronique d’Olivier Rafal : Olivier Rafal est rédacteur en chef du site LeMondeInformatique.fr. Il anime et organise le SOA Forum.
• Joel on software, un développeur de New York qui blogue depuis 2000 sur l’ingénierie logicielle, la gestion de projet et Internet.
• J2EE, Agilité et SOA : Le blog de Xebia France : Xebia est un groupe d’experts, exclusivement dédié aux technologies J2EE.

Arnaud Bonneville vous propose la lecture des blogs suivants :

• Louis Naugès, Réussir ses Services d’Information Web 2.0 : Louis Naugès centre ses posts sur l’actualité des grands acteurs du web. Décrivant les nouvelles architectures 2.0, comparant les solutions SaaS (Software As A Service) aux solutions 1.0 “ancienne génération” utilisant des clients lourds, il rend les DSI attentifs aux conséquences de choix technologiques qu’ils pourraient faire dans le domaine de l’utilisation des technologies 2.0 dans l’entreprise.
• Serge Thorn’s IT Blog : Serge Thorn est l’un des Gourous de l’IT Governance. Régulièrement présent aux forums ITIL et itSMF, il a axé sur son blog sur des sujets liés à l’IT Service Management et ITIL, CMMi et COBIT. Il traite également d’architecture et de SOA.

Dans le langage courant, le mot “urbanisation” vient du latin urbs, qui désigne la Cité, la ville. L’urbanisation représente donc l’action d’urbaniser, c’est-à-dire d’organiser le développement des villes.

En informatique, c’est à priori Elisabeth Heurgon qui a utilisé pour la première fois le concept d’Urbanisation du Système d’Information en 1989 lors d’un exposé du colloques de Cerisy intitulé Les nouveaux rapports entre l’informatique et l’entreprise. Elle était à l’époque Responsable des Systèmes d’Information de la RATP.

Mais le concept a surtout été rendu populaire par l’ouvrage Urbanisation des systèmes d’information de Jacques Sassoon. L’ouvrage est malheureusement épuisé (j’ai tout de même eu la chance de pouvoir le lire mais j’ai du le rendre à son propriétaire). Il définit les concepts de zones, de quartiers, de blocs et édicte les grandes règles à respecter pour mener à bien l’urbanisation de son SI. Le tout est illustré par un exemple issu du monde bancaire, un domaine que Jacques Sasoon connaît bien puisqu’il y a exercé des responsabilités au Crédit Agricole puis à la Société Générale.

Mais comment définir le concept d’urbanisation du SI ? Pour le Club Urba-EA (EA pour Enterprise Architecture) l’urbanisation est une approche top-down ayant pour objectifs de faciliter l’évolutivité et l’adéquation des SI vis-à-vis des processus, de mettre en évidence les fonctions transverses ou communes, les partager et de renforcer la cohérence du SI.

Pour faire simple, l’urbanisation consiste à voir le SI comme des quartiers relativement indépendants reliés par des voies de communication aujourd’hui possibles par les technologies d’EAI. Une des premières démarches d’urbanisme consiste à établir une cartographie du SI. C’est aussi à l’urbaniste d’établir les règles d’urbanisme et d’accorder les “permis".

Pour poursuite la découverte de l’urbanisation au sens informatique, je vous recommande la lecture des documents suivants :

• Urbanisation (informatique), Wikipedia
• Urbanisme informatique - Définition
• Réussir l’urbanisation du système d’information, interview d’Yves Caseau, auteur d’Urbanisation et BPM : Point de vue d’un DSI, paru en 2005 aux éditions Dunod (épuisé)
• Urbanisme et Enterprise Architecture par le Club Urba-EA
• L’apport historique de l’urbanisme des villes pour
  l’urbanisme des systèmes d’information, Isabelle Contini, Colloque Urbanisation des Systèmes d’Information du 24 Juin 2002
  IAE Université Paris 1 Panthéon Sorbonne
• L’apport de l’ingénierie des besoins à l’ingénierie de
  l’urbanisme des systèmes d’information (USI), Isabelle Contini,24 juin 2002

Bienvenue sur ce blog intitulé “make IT strategic” ce que l’on pourrait traduire en français par “rendre l’informatique stratégique". Ce blog est destiné aux décideurs informatiques (DSI, urbanistes, directeurs des études, directeurs de projets, responsables informatiques, etc.). Il est animé par Serge Baccou et Arnaud Bonneville, directeurs associés et consultants principaux de Baccou Bonneville Consultants. Bonne lecture et n’hésitez et nous laisser des commentaires.