Make IT Strategic

When rationalizing IT support activity, the main focus is often put on the help desk. Therefore, companies organized in small, individual support teams are lead to structure their IT support by putting in place a more formal and standard IT support structure. The first level of this structured support team is the help desk. Dedicating teams to take user calls to troubleshoot incidents or deliver IT services is a best practice implemented by most mid-size and large companies today. Structuring a unique Service Desk using ITIL best practices to manage calls and incidents is an efficient manner to provide consistent IT support to the entire end user community.

Once the help desk has been setup, companies usually tend to optimize their teams and level resources to optimize IT productivity and limit support costs. The trend in the past ten was to outsource first level support to low-cost countries such as India, Maghreb countries or East-European countries.

But how do end users experience this transition from local teams to structured help desks, then to outsourced platforms? The main issue of Help Desk managers is to put the right balance between cost and quality. I will describe further in this post a proposed project approach to deal with quality issues at the Help Desk.

Step 1 - which quality issues?

What do we mean exactly by quality issues? This is the first topic to deal with. If the Service Desk was structured using ITIL best practices, Help Desk performance is likely to be challenged against Service Level Agreements signed with the customers – business units, departements, etc. But even if formal SLAs have been implemented, such as 95% of low priority incidents resolved in less than 10 hours, reaching formal SLA objectives is not synonym of quality. For instance, this latter SLA could be reached, but 20% of the calls may be closed without being properly solved, requiring end users to open new tickets. Another example: users may complain about poor communication skills of the help desk agent they were in touch with: bad accent, no customer focus, no empathy… Therefore, one essential factor to take into account, in addition to formal SLA objectives, is the measure of end user satisfaction.

Identifying root causes of quality issues is a complex exercise, and must take into account interviews with help desk leaders, customer representatives but most of all end users who are facing the help desk. An Ishikawa cause-effect diagram may be used to represent all possible reasons for low quality and track root causes.

Step 2 - identify most relevant improvements

Depending on the root causes identified at the previous step, you may focus on actions to improve agent skills, or improve user experience with help desk. For this purpose, you may settle workshops with Help Desk managers and end user focus groups, in order to assess what improvements will bring the best results to improve help desk quality, based on the root cause they’re supposed to mitigate. I strongly highlight the importance of challenging the possible candidate initiatives with end users from the “real world", and asking to users if implementing those will have a positive effect on their satisfaction and experience with Help Desk.

Analysts have put a strong correlation between user satisfaction and the First Contact Resolution rate (FCR). This rate expresses all possible ways for users to resolve their issues during their first contact to IT, whichever techniques are used: phone, web, self-service tools, chat, etc. This latter KPI may not be expressed as such by end users, but may have a real positive impact on perceived end user satisfaction.

Step 3 - define relevant metrics to measure improvements effectiveness

Before starting to implement the most appropriate countermeasures to improve Help Desk quality, I strongly advise you to think about the evidences that you’ll need to show in order to prove that such measures were effective. Let’s assume that one of the root causes identified was linked to improving communication and empathy skills of help desk agents, and that you have decided to run a series of trainings to work on that specific topic. How will you measure the effectiveness of this action? Thinking on KPIs before implementing the action may avoid you spending money on actions and keep your management dissatisfied as you’re not able to show the benefits of them. So ask you the right questions: is the KPI a good reflect of the improvement I am about to implement? Can I measure this KPI? Is this KPI valid for IT Management and/or end users?

Step 4 - implement improvements

This is a standard change management activity, so I will not detail this part too much. The only thing I will stress is the importance of communication in those activities, both towards the end users and the IT Community. Improving organizations requires a strong Organizational Change Management focus and the main role of the project manager, besides the formal PM techniques to track costs, time and quality, will reside in his/her ability to be a powerful communicator and agent of change between the various stakeholders.

Step 5 - measure success

As we have defined the KPIs on step 3, and taken their implementation into account during the implementation phase, this step has to be run possibly BEFORE, DURING and AFTER the changes have been implemented, so that we can show some progress, and depending on the results, possibly launch additional actions to improve results.

Step 6 - start again!

Do steps 1 to 5 look familiar to you? Maybe you’ve already seen that somewhere, for instance in a well-proven technique of continuous improvement: the PDCA model - Plan-Do-Check-Act, or Deming wheel! Indeed, implementing one-shot actions to improve Help Desk quality is not sufficient. It’s fundamental to measure Help Desk quality in a regular manner, by evaluating Help Desk KPIs and end user satisfaction to track possible degradations of quality. Help desks are facing very important turnover rates, that’s even recommended in ITIL best practices to motivate help desk agents by promoting them to level 2-3 support technicians, or moving them to other silos in the Data Centers or Network teams. For this reason, the agents that were involved in your initial improvement plan are not likely to stay for a long time at their place, but may be replaced by new agents, frequently young people with less experience.

So… do we need to start the stuff another time again? Maybe an appropriate way for doing it is to settle Continous Improvement cycles, as described in ITIL v3 Best Practices, and appoint an Help Desk Quality manager who will be in charge of running those plans in a continuous manner.

References:

1. Deming Wheel - PDCA, Wikipedia

La matrice RACI ou sa variante RASCI (aussi connu sous le nom de Responsability Assignement Matrix, RAM) permet de définir les rôles et responsabilités dans un service ou sur un projet. Mais il faut prendre garde à bien comprendre l’acronyme car la traduction de l’anglais au français peut conduire à des erreurs. On trouve la définition de RACI dans le PMBok (Project Management Body of Knowledge) du PMI (Project Management Institute).

L’acronyme RACI signifie :

• R : Responsible : Réalise : Réalise l’activité. Il peut y avoir plusieurs R.
• A : Accountable : Autorité : A l’autorité pour approuver le travail de R. Il n’y a qu’un seul A. En général, il y a un rapport hiérarchique entre A et R (A est le manager de R).
• C : Consulted : Consulté : Est consulté par R. La communication entre R et C est bidirectionnelle. Il peut y avoir plusieurs C.
• I : Informed : Informé : Est uniquement informé des travaux de R. Il peut y avoir plusieurs I.

L’acronyme RASCI rajoute le rôle suivant au RACI :

• S : Supportive : En support : Apporte des ressources supplémentaires pour conduire le travail de R. Il peut y avoir plusieurs S.

La confusion peut venir des rôles R et A qui sont souvent inversés dans certaines traductions françaises car le terme Responsible n’est pas équivalent de Responsable en français et le terme Accountable est difficile à traduire. A ne doit pas être associé à Approbateur car le terme peut donner lieu à des confusions.

La matrice RACI ou RASCI présente des activités en ligne et des rôles en colonne comme dans l’exemple ci-dessous. Dans chaque cellule du tableau, on indique la responsabilité du rôle pour l’activité en utilisant les lettres du RACI ou du RASCI. Pour plus de pérennité, il est conseillé d’utiliser des libellés génériques de fonction pour qualifier les rôles plutôt que des noms de personnes.

Le RACI peut être utilisé pour établir les responsabilités dans un projet, une DSI, une entreprise. Dans un modèle de document, il peut aussi indiquer qui doit rédiger ( R ) ou valider ( C ) telle ou telle partie. Il n’y a qu’une seule personne qui valide l’ensemble du document ( A ). Dans tous les cas, le RACI est l’outil idéal pour clarifier “qui fait quoi".

Références :

1. RACI, Wikipédia (Français)
2. Responsibility Assignment Matrix (RAM), Wikipédia (Anglais)
3. RACI, 12manage

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

Lien: http://blog1.lemondeinformatique.fr/

Olivier Rafal est rédacteur en chef du site LeMondeInformatique.fr. Chaque année, il anime et organise le SOA Forum.

Lien: http://www.g9plus.org

G9+ est un club Informatique, Télécoms et Multimédia constitués par les anciens élèves de grands établissements de l’enseignement supérieur français comme l’ENST Bretagne, HEC multimédia et Système d’Information, Mines Informatique, Ponts Telecom Informatique, Supélec Informatique et télécoms, X Informatique, etc.

Lien: http://www.g9plus.org/interface/SommaireSSII150307.htm

Dans le cadre d’un cycle “Spécial Prospective Economie des TICS", l’association G9Plus a organisé en mars 2007 une conférence intitulée “Quel avenir pour les SSII à horizon 2010-2015 ?”. La conférence traite de la physionomie des SSII dans quelques années sous l’influence de l’Open Source et des modèles ASP (Application Service Provider) et SaaS (Software as a Service). Elle aborde également la modification probable du rôle du DSI et de la montée de l’offshore en Inde. Pour plus d’informations, on peut lire la version courte ou la version longue du compte-rendu de la conférence.

Lien: http://www.lemondeinformatique.fr/videos/lire-quel-avenir-pour-l-edition-de-logiciels-en-france-webcasts-143.html

Quel avenir pour l’édition de logiciels en France à horizon 2010 - 2015 ? Telle est la question posée à différents intervenants lors d’une conférence du G9+.

Le G9+ est un club Informatique, Télécoms et Multimédia constitués par les anciens élèves de grands établissements de l’enseignement supérieur français comme l’ENST Bretagne, HEC multimédia et Système d’Information, Mines Informatique, Ponts Telecom Informatique, Supélec Informatique et télécoms, X Informatique, etc.

Olivier Rafal, journaliste au Monde Informatique a réalisé un webcast sur cette conférence. Dans ce webcast, Jean-François Perret, Président du Directoire de Pierre Audoin Consultants nous rappelle que dans le Top 200 des premiers éditeurs de logiciels en Europe en chiffre d’affaires, 70% sont américains, 12% sont allemands (avec un poids important pour SAP) et 5% sont anglais ou français. Les handicaps français dans l’édition de logiciels sont selon lui une faiblesse sur le marketing et un accès encore trop faible aux financements.

A ces faiblesses, on peut rajouter la taille des acteurs : seule une vingtaine d’éditeurs Français dépassaient les 20 millions d’euros de chiffre d’affaires en Europe. L’AFDEL, l’Agence Française des Editeurs de Logiciels a publié fin juin 2007 l’Indice PAC / AFDEL. Dans le Top 150 des éditeurs de logiciels en France en chiffre d’affaires, seuls 6 acteurs sont présent dans les 20 premières places : Cegid, Dassault Systèmes, Business Objects, Sopra Group, GFI Informatique et Cegedim.

Lien: http://www.sugarcrm.com

Baccou Bonneville Consultants a lancé une démarche d’analyse des principaux outils d’entreprise OpenSource, qui peuvent devenir une véritable alternative aux solutions leader du marche.

Notre recherche d’outils d’entreprise OpenSource a ciblé deux domaines :

• Les outils de CRM (Customer Relationship Management, Gestion de la Relation Client)
• Les outils d’ERP (Enterprise Resource Planning, Progiciel de Gestion Intégré)

Nous allons consacrer une série d’articles à l’évaluation des différents produits OpenSource que nous avons pu tester, en dressant un tableau de leurs principales forces et faiblesses.

Le premier outil que nous évaluons en ce moment, et que nous allons vous présenter dans ce post, est un outil de CRM, SugarCRM.
Les premiers tests que nous avons effectués sont tout à fait concluants, et SugarCRM n’a rien à envier à d’autres outils payants tels que les ERP Oracle (Siebel, Peoplesoft…) pour ne citer qu’eux. Ce type d’outil permet à des entreprises de petite et moyenne taille de se doter d’un outil commercial efficace prêt à l’emploi, pour lequel le temps de prise en main est très court.

Lire la suite »

Link: http://sergethorn.blogspot.com/

Serge Thorn’s IT blog is related to many IT Governance domains such as Service Management and ITIL, Enterprise Architecture and SOA, CMMi, COBIT, TOGAF, Innovation, organisations supporting these frameworks such as itSMF and the Open Group.

Lien: http://nauges.typepad.com/

Sur son blog, 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.

Louis Naugès est Président-Fondateur de Microcost.

Link: http://www.joelonsoftware.com

Joel Spolsky is a software developer in New York City. His blog is called Joel on Software. It talks about software development, management, business and the Internet since 2000. Joel has created his own company, Fog Creek Software in September, 2000. This software company created Fogbugz, a project management software and some other software.

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

Welcome to this new blog intended for IT decision-makers (CIO, IT / IS project directors, etc.). This blog will be animated by Serge Baccou and Arnaud Bonneville, co-CEOs and principal consultants from Baccou Bonneville Consultants.

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.