fra

Déplacer vers la gauche ? Non, "Shift Down" pour le succès des services de soutien.

Comment les pratiques de développement de type shift-left peuvent être appliquées avec succès à votre organisation de services et d'assistance à la clientèle.

Le paysage du développement, des outils de développement et des méthodologies a beaucoup changé au cours de la dernière décennie. De plus en plus d'organisations passent de la méthode "waterfall" à un cadre de développement Agile, ainsi qu'aux principes DevOps pour le développement et le support des applications d'entreprise. L'objectif est d'accélérer les cycles de publication, d'améliorer la qualité et d'offrir une meilleure expérience globale à vos clients - les utilisateurs de vos systèmes et applications.

En particulier, une philosophie appelée "shift left" est apparue comme une nouvelle façon d'améliorer la qualité des applications en rapprochant les cycles de test des activités de développement. Il s'est avéré que cette méthode permet de réduire le nombre de défauts constatés en production - et d'économiser des dizaines de milliers de dollars pour les organisations qui l'ont mise en œuvre.

Dans ce livre blanc, nous examinons comment les concepts qui accélèrent l'évolution vers des cadres de développement de type shift-left peuvent être appliqués à votre organisation de service et de support. Nous appelons cela "shift down" car cela implique de placer plus de responsabilités "en bas" de l'organisation ou en amont, si vous voulez - en donnant le plus de pouvoir possible à vos employés de niveau 1, tout en automatisant le libre-service le cas échéant. Nous vous proposons sept bonnes pratiques sur la façon de procéder et vous montrons pourquoi ne pas le faire pourrait être coûteux pour vos résultats.

Les tests de décalage à gauche : une introduction

Commençons par expliquer la philosophie du shift-left dans les tests logiciels. Le glissement vers la gauche signifie que les tests doivent commencer plus tôt dans le cycle de vie du logiciel. Cela s'oppose à l'approche traditionnelle qui consiste à confier les tests à une équipe d'assurance qualité dédiée, à la toute fin du processus de développement. Le raisonnement est simple : plus tôt dans le processus de développement vous pouvez trouver les bogues et les défauts, plus tôt vous pouvez donner un retour d'information à vos développeurs, leur permettant ainsi d'être plus productifs dans leur travail. À l'heure actuelle, plus de quatre organisations de développement sur dix sont officiellement passées à gauche en matière de tests d'applications.

À l'heure actuelle, la majorité des organisations dépendent encore largement du "modèle en cascade", utilisé à la fois dans la gestion de projet et dans le développement de logiciels, dans lequel la collecte des exigences, la conception, le codage et les tests sont effectués de manière essentiellement séquentielle. (voir la figure 1).

Figure 1 : Le cycle de vie du développement logiciel.

La principale difficulté liée à l'utilisation de la méthode de la cascade est que les bogues ou les défauts - qu'ils soient majeurs ou mineurs - ne sont identifiés qu'une fois le développement terminé. Les défauts mineurs ne sont pas forcément rédhibitoires - les développeurs peuvent les corriger rapidement sans perturber les délais de livraison ni ajouter trop de coûts - mais les bogues majeurs sont une toute autre affaire.

Dans ce cas, la mise à disposition du produit au client peut être retardée, et les coûts peuvent augmenter à mesure que d'autres personnes sont amenées à résoudre le problème. La phase de test à la toute fin du cycle de vie du développement logiciel n'est idéale que lorsque votre produit est exempt de tout bogue - mais rêvez si vous espérez encore, au début de chaque initiative de développement de produit, que ce sera le cas.

Avec l'émergence de modèles de développement logiciel plus souples, tels que Agile, les entreprises ont commencé à réaliser que confier les tests à une équipe d'assurance qualité cloisonnée dans le cadre d'une activité ponctuelle était en fait très risqué. Les défauts détectés à ce stade étaient la première cause de retard dans la mise en production et de dépassement des coûts.

Shift-left est né, où les tests sont effectués à chaque phase du développement.
(voir la figure 2).

Figure 2 : Le modèle de test shift-left.

Le virage à gauche signifie essentiellement que les tests doivent être effectués le plus tôt possible (à gauche sur l'axe du cycle de vie) et de façon continue. Les pratiques de virage à gauche impliquent l'intégration de vos tests dans votre processus de développement logiciel et la découverte des bogues plus tôt, lorsqu'ils sont plus faciles et moins coûteux à corriger.

Bien que la pratique soit apparue à la fin des années 1990, le concept de décalage vers la gauche a été formellement nommé par Larry Smith en Dr. Dobbs Journal en 2001, où M. Smith expliquait comment l'intégration du développement et de l'AQ aux niveaux inférieurs de la direction peut élargir votre programme d'essais tout en réduisant les besoins en main-d'œuvre et en équipement. Les tests, le retour d'information et les révisions sont quotidiens dans la pratique de l'équipe gauche. Cela favorise l'agilité et permet à l'équipe de projet d'échelonner ses efforts pour stimuler la productivité.
(voir la figure 3).

Figure 3 : Modèle d'AQ shift-left par rapport au modèle traditionnel.

Lorsque DevOps a fait son apparition en 2007, le shift-left en faisait partie intégrante. DevOps consiste à combiner le développement de logiciels et les opérations informatiques, créant ainsi une propriété plus collective de bout en bout du processus, du cycle de vie du produit et de l'expérience client. L'objectif de DevOps, qui est de raccourcir le cycle de vie du développement logiciel et de fournir une livraison continue et de haute qualité du code, est au cœur de la philosophie shift-left.

Les avantages réels du virage à gauche

De nombreuses recherches ont identifié les avantages du virage à gauche. James Martin, consultant en informatique a constaté que 56% de tous les défauts de logiciels sont trouvés pendant la phase de définition des besoins, 27% pendant la phase de conception et seulement 7% pendant la phase de développement. S.A. Kelkar, de l'Institut indien de technologie de l Analyse et conception de systèmes structurés a vérifié ces chiffres, qui ont été confirmés par la STBC dans le cadre de l'enquête sur la santé des femmes. L'économie des tests. (Voir la figure 4).

Figure 4 : Quand les défauts du logiciel apparaissent.
Source : Rice Consulting

Des recherches menées par l'IBM System Science Institute ont révélé que si les problèmes sont identifiés dès le début du développement, leur résolution coûte environ $80. Mais les mêmes problèmes coûtent $8,000 à résoudre s'ils sont détectés pendant la production - soit 100 fois plus. (voir la figure 5).

Figure 5 : Coût de la détection des défauts dans les différentes phases du cycle de vie du développement logiciel.
Source : Institut des sciences du système IBM

Application du shift-left aux organisations de soutien des services à la clientèle

Maintenant que nous comprenons le concept de shift-left, nous pouvons en appliquer les principes - et en récolter les fruits - à nos organisations de service et de support client en informatique.

Aujourd'hui, les services des équipes d'assistance informatique sont priorisation de la refonte leurs cadres traditionnels d'assistance aux clients avec de nouveaux processus basés sur des cadres de gestion informatique nouveaux et établis, tels que la bibliothèque d'infrastructure informatique (ITIL®) ou les objectifs de contrôle pour l'information et les technologies connexes (COBIT). Principale raison de donner la priorité au soutien informatique aux clients ? Ils constatent que leurs clients se concentrent de plus en plus sur la disponibilité et les performances réelles de plates-formes et d'applications logicielles de plus en plus basées sur le cloud, qui sont sous le contrôle total du fournisseur.

Le défi auquel sont confrontées les organisations d'assistance est qu'un volume croissant d'incidents les place en mode de lutte permanente contre les incendies. Les méthodes proactives, telles que l'analyse des tendances, les actions préventives et les analyses post mortem des problèmes majeurs, sont des moyens efficaces de réduire le nombre de demandes d'assistance. Malheureusement, les fonctions informatiques concentrent souvent la plupart de leurs ressources sur des activités réactives et ignorent les approches proactives, malgré leurs avantages évidents. En conséquence, les incidents récurrents entraînent la frustration des clients et des temps d'arrêt inutiles.

De nombreux parallèles entre le support de service et le développement de logiciels

Tout comme le shift left a été adopté parce que les problèmes de codage sont plus coûteux à résoudre plus ils sont détectés tardivement, les opérations de service sont dans une situation similaire. Prenons l'exemple d'un incident qui a d'abord été traité par un technicien de niveau 1, avant d'être élevé au niveau 2 et, après un certain temps, de nécessiter une conférence téléphonique avec des experts en la matière de niveau 3 avant de pouvoir être résolu. Le coût résultant de chaque ressource n+1 ajoutée peut facilement atteindre des chiffres à 5 et 6 chiffres.

Cette idée de diagnostiquer et de résoudre les problèmes en amont du processus, plutôt que d'attendre qu'un incident majeur se produise, ressemble aux conclusions qui ont conduit à la révolution du shift-left dans le développement. En effet, si l'étude de Ponemon sur les coûts peut être appliquée aux opérations de service, en résolvant les problèmes plus tôt dans le processus, on pourrait économiser jusqu'à 100 fois ce coût.

C'est ce que nous appelons le "déplacement vers le bas".

Pourquoi vers le bas ? Parce que vous déplacez en fait la responsabilité vers le bas de la structure organisationnelle, de sorte que les personnes chargées de l'assistance aux niveaux 1 et 2 disposent de plus de connaissances, de capacités et de responsabilités, et sont habilitées à agir au nom du client.

Les services actuels soutiennent les pratiques

Lorsqu'un client (ou un employé, ou tout autre type d'utilisateur) appelle le support, il reçoit un ingénieur de niveau 1 qui n'a que des compétences et des connaissances minimales. Pour les problèmes un peu plus compliqués - "J'ai des difficultés à accéder à notre système de vente" -, de nombreuses organisations de support de niveau 1 se contentent de saisir les informations de base, tentent d'évaluer la priorité et passent au niveau 2. L'ingénieur de niveau 2, lors d'un second appel, pose des questions plus techniques (souvent centrées sur le produit) et peut (avec un peu de chance) résoudre le problème. Sinon, le problème est à nouveau transmis au niveau 3, où se trouvent les véritables experts en produits.

Même de petits changements peuvent rendre ce processus plus efficace. En déplaçant la responsabilité vers le bas - en formant les employés de niveau 1 à poser quelques questions de diagnostic essentielles concernant les symptômes, l'impact et la déviation réelle des performances, même s'ils ne sont pas des experts en produits - vous pouvez résoudre davantage de problèmes dès le premier point de contact ou, au minimum, fournir de bien meilleures informations au niveau 2 pour une résolution plus rapide, moins de "ping-pong" et, en fin de compte, moins d'escalades.

La formation de votre personnel de niveau 1 à la résolution de problèmes plus complexes que, par exemple, la réinitialisation d'un mot de passe ou d'un routeur et à la fourniture d'une fonctionnalité de triage de base, vous apportera des avantages considérables.

La philosophie du "shift down

L'objectif est de permettre et d'habiliter des ressources moins expérimentées sur le plan technique à résoudre davantage de problèmes plus tôt dans le cycle de vie, tout en assurant une gestion proactive des problèmes afin d'éviter qu'ils ne se reproduisent et, d'une manière générale, en rapprochant les points d'interaction du client afin de réduire les escalades, d'améliorer le taux de réparation dès la première fois, de réduire le coût du service et d'améliorer globalement l'expérience du client.

Un exemple de déplacement vers le bas consiste à intégrer des questions de diagnostic de base dans votre portail d'auto-assistance. Avec un client, nous avons constaté que cette approche a permis d'augmenter la déviation des cas de 35%. Cela permet également à votre organisation de niveau 1 de fonctionner à un niveau plus informé et de commencer le dépannage réel plus tôt dans le processus.

Lorsque vous vous lancez dans un programme de réduction des effectifs, vous devez vous assurer que vous alignez les flux de travail, les rôles et les responsabilités en conséquence, ainsi que votre système de performance pour savoir comment ces ingénieurs sont soutenus et récompensés, y compris les mesures.

Une nouvelle ère pour la gestion des services informatiques

La fonction de gestion des services informatiques (ITSM) est véritablement en pleine transformation.

Une étude réalisée par Forbes Insight et BMC a constaté que la plupart des organisations de services informatiques évoluent au-delà de la simple fourniture de services centrés sur l'informatique. Au contraire, elles sont désormais considérées comme des équipes essentielles qui sont en première ligne pour garantir que l'expérience du client est ce qu'elle devrait être dans la nouvelle ère numérique.

Parmi les autres conclusions clés de cette étude :

- 56% déclarent que le rythme des changements ou des transformations informatiques s'accélère "considérablement".
- Seuls 13% voient l'ITSM conserver la même hiérarchie organisationnelle traditionnelle.
- 36% déclarent que le manque de compétences informatiques adéquates est en tête de liste des défis à relever pour obtenir un excellent support client, suivi de près par les contraintes budgétaires.
- 37% déclarent que la majorité de leur budget informatique total est consacrée à la maintenance et à la gestion courantes.

En résumé : 75% des responsables informatiques reconnaissent que le temps, l'argent et les ressources consacrés à la maintenance et à la gestion informatiques permanentes - qui incluent le support des services informatiques - affectent la compétitivité globale de leur entreprise.

L'amélioration de la qualité et de la rentabilité du support informatique est donc une initiative informatique stratégique, au même titre que le cloud computing, le big data et la mobilité. En effet, une majorité de cadres (56%) indiquent que la gestion des services informatiques est "extrêmement importante" dans les initiatives de cloud computing et de big data de leurs entreprises. Cinquante-quatre pour cent indiquent également que la gestion des services informatiques est "extrêmement importante" pour soutenir leurs efforts en matière d'informatique mobile.

Les sept meilleures pratiques d'un programme de réduction d'effectifs

Pour ceux qui voudraient essayer de passer à la vitesse inférieure, voici sept meilleures pratiques que nous avons rassemblées à partir de notre expérience de travail avec des organisations de services informatiques.

1. Rassembler les données

Pour commencer votre parcours, il est essentiel d'établir une base de référence. Qui contacte votre ligne de front ? Quels types de problèmes signalent-ils ? Quels types de questions ont-ils ? Vous devez rassembler des données sur votre volume d'appels entrants, comme le type d'appel (incident, problème, question, demande, suivi), le type d'appel et les catégories de biens les plus fréquemment remontés, le coût de la prise en charge de ces appels (sans oublier la main-d'œuvre et le temps), et enfin, le niveau de compétence du ou des techniciens qui traitent chaque appel.

Par exemple, vous pouvez apprendre que sur les mille appels que vous recevez en un mois, cinq cents d'entre eux demandent une réinitialisation de mot de passe, deux cent cinquante d'entre eux demandent des solutions relativement peu complexes comme l'octroi d'un accès VPN, et les deux cent cinquante derniers demandent des solutions très complexes comme la détermination de la raison pour laquelle une base de données est en panne. Cela aura un impact sur votre stratégie pour l'avenir.

2. Sélectionner les cibles de grande valeur

Sur la base de l'analyse de vos données, vous chercherez ensuite des cibles de grande valeur à réduire. Quels sont les systèmes ou les actifs qui font l'objet d'une escalade fréquente, dont les délais de résolution sont longs et auxquels sont associés des coûts très élevés ? Quels sont ceux qui font l'objet d'une escalade mais qui sont facilement résolus ? Quels sont ceux qui semblent avoir un impact très faible sur la satisfaction du client ou sur les coûts ?

Ce sont tous des candidats pour le shift down.

Prenons l'exemple précédent de l'identification de niveaux élevés d'appels de réinitialisation de mots de passe. Cela signifierait, entre autres, que la moitié des appels d'assistance pourraient être facilement résolus par l'automatisation, ce qui constitue le mouvement ultime de réduction des effectifs.

Et vous pourriez peut-être aller un peu plus loin. Par exemple, si vous vous rendez compte que la plupart de vos appels à haute complexité proviennent d'Europe, vous pourriez donner à vos clients européens un numéro d'assistance qui renvoie directement à l'assistance de niveau 2. Ainsi, vous ne perdrez pas votre temps ni celui du client, et vous ne perdrez pas d'argent à faire venir un technicien de niveau 1. Ils peuvent se concentrer sur ce qu'ils font le mieux. Et plus vous en savez sur les autres types d'appels, plus vous pouvez les acheminer avec précision. Le thème principal ici (encore une fois) est que vous devez comprendre vos clients et vos modèles d'appels.

3. Responsabiliser les employés de niveau inférieur

Kepner-Tregoe croit qu'il faut permettre aux employés et aux cadres de maîtriser les principes fondamentaux de la résolution efficace des problèmes et de la prise de décision. Nous appelons cela la pensée critique, ou "processus rationnel".
L'approche de la pensée critique de Kepner-Tregoe a apporté des contributions durables à la gestion des entreprises pendant plus de six décennies.

En effet, le mot pensée critique a une signification très spécifique pour Kepner-Tregoe. Il s'agit d'un mode de pensée logique et itératif, guidé par une série de questions, visant à récupérer, organiser et analyser des informations dans le but de parvenir à une conclusion solide.

La conviction de Kepner-Tregoe est qu'un bon travail d'équipe provient de la formation des travailleurs à s'appuyer consciemment sur le même mode de pensée que celui que beaucoup d'entre eux utilisent déjà inconsciemment.

Ils peuvent le faire en répondant à quatre questions fondamentales :

- Qu'est-ce qui se passe ?
- Pourquoi cela s'est-il produit ?
- Quelle est la marche à suivre ?
- Qu'est-ce qui nous attend ?

Faire descendre davantage de savoir-faire technique dans l'organisation a ses limites. La durée de vie des connaissances techniques étant de plus en plus courte, ce n'est tout simplement pas une approche évolutive. Par conséquent, vous devez également former vos ingénieurs, en particulier ceux de première ligne, aux techniques de questionnement appropriées, aux principes fondamentaux de la formulation d'un problème, à la collecte de données de base, au dépannage et à la pensée critique.

Non seulement vous apprenez aux personnes des niveaux inférieurs à poser les questions qu'un technicien plus expérimenté pourrait poser, mais vous leur permettez également de comprendre comment clarifier, vérifier et répondre aux clients dans ces situations.

4. Établir des déclencheurs d'escalade

L'escalade est toujours très importante lors du passage à l'échelon inférieur. Sur la base des données que vous avez recueillies et analysées, vous devez établir des déclencheurs clairs pour savoir quand un problème de client doit être transmis. La raison en est simple : c'est une chose de responsabiliser une équipe, c'en est une autre de la submerger. Votre équipe nouvellement formée doit apprendre à déterminer quand il est temps de lâcher prise et de demander de l'aide.

Le plus souvent, les déclencheurs sont basés sur un paramètre temporel. Si un représentant de niveau 1 a passé une heure sur un problème sans succès, il est peut-être temps de passer au niveau 2. Les déclencheurs peuvent également être basés sur les tentatives de résolution : si vous avez essayé trois fois de résoudre un problème et qu'elles ont toutes échoué, il est probablement temps de passer à l'échelon supérieur. L'escalade peut également être basée sur l'attitude du client : s'il s'énerve contre vous, en utilisant peut-être un langage fort, cela peut être un déclencheur.

5. Testez votre programme d'abaissement

La meilleure pratique suivante consiste à mettre en place des tests A/B dans votre centre de support client. Divisez votre équipe en deux groupes : l'un utilise ses nouvelles techniques d'abaissement de la charge de travail, généralement sur un problème très spécifique, comme la réinitialisation des mots de passe, tandis que l'autre gère les affaires courantes. Quel groupe obtient les meilleurs résultats ?

Pourquoi faire cela ? C'est une bonne pratique des sciences de la gestion. Pour tout bon programme d'entreprise, toute bonne initiative, quel qu'en soit le type, vous devriez suivre Six Sigma, ou un plan qualité similaire pour traiter les projets de la même manière que les entreprises pharmaceutiques traitent les médicaments qu'elles produisent. Avant de mettre en œuvre une nouvelle pratique à l'échelle de l'entreprise, il faut la tester et prouver qu'elle donne les résultats escomptés.

Dans ce cas particulier, ce que vous faites aura un impact direct sur vos clients. Pour donner la priorité aux clients, vous devez vous assurer que tout ce que vous changez améliore réellement leur situation.

6. Quantifier les résultats

Vous devez maintenant mesurer vos résultats. L'équipe cible a-t-elle résolu plus d'appels en moins de temps ? Quel a été le coût du service par actif, par client, par type de demande ? À ce stade, vous souhaitez quantifier les économies réalisées par rapport aux dépenses effectuées, afin de pouvoir calculer le retour sur investissement (ROI).

Armé de ces connaissances, même un gestionnaire de bas niveau qui a mené une expérience sur sa petite équipe de soutien peut aller voir son patron et lui dire : " Regardez ce que nous avons fait dans notre équipe au Canada. Imaginez si nous reproduisions cela dans toute l'Amérique du Nord." Tout à coup, l'ensemble de l'entreprise offre un service d'assistance à la clientèle plus professionnel, et nous avons préparé ce gestionnaire de bas niveau à une carrière réussie.

Dans l'exemple que nous avons utilisé, où 500 appels de support sur 1 000 concernent la réinitialisation de mots de passe, cette analyse du retour sur investissement présente l'avantage supplémentaire de vous indiquer combien vous pouvez investir pour résoudre le problème. Si vous pouvez économiser $2 millions en empêchant 500 appels par jour de vous atteindre en investissant $100 000 dans un outil de réinitialisation de mot de passe, c'est de l'argent bien dépensé.

7. Faites évoluer votre programme

Lorsque vous êtes satisfait des résultats de votre première tentative de déplacement vers le bas, regardez ce que les données vous disent sur les autres déplacements vers le bas que vous pouvez effectuer et sur les autres endroits où appliquer le processus. Recommencez avec les meilleures pratiques 1 ou 2 pour améliorer un autre domaine de votre activité de soutien aux services à la clientèle.

La meilleure mesure de soutien aux services : Satisfaction des clients

En définitive, l'assistance informatique est peut-être la fonction d'entreprise la plus importante de l'ère numérique et des applications basées sur le cloud. Les organisations étant de plus en plus dépendantes de la technologie, le fait qu'elle fonctionne comme il faut, quand il le faut, supplante presque tout le reste. Pour les entreprises de tous types et de tous secteurs - fabrication, automobile, commerce de détail, finances - la gestion des services informatiques peut jouer un rôle essentiel. Chaque interruption de service a un impact direct sur la productivité de l'entreprise et, en fin de compte, sur sa réussite, qu'elle soit définie par la rentabilité, l'efficacité ou la rapidité du service. Les techniques de shift-left développées au cours des 20 dernières années dans le domaine du développement de logiciels peuvent avoir un impact profond lorsqu'elles sont appliquées aux organisations de services informatiques.

Kepner-Tregoe s'est associé à certaines des entreprises les plus grandes et les plus prospères du monde, comme Microsoft, pour améliorer la rapidité de l'assistance, le coût des appels et les niveaux d'expérience des clients.

Shane Chagpar
Consultant en gestion de projet

Shane Chagpar utilise les outils Kepner-Tregoe et les meilleures pratiques du secteur pour concevoir des solutions répondant aux besoins des clients. Supervisant généralement plusieurs projets, Shane est responsable à la fois des performances et des résultats de l'équipe. Au sein de KT, il assure un leadership éclairé au niveau mondial sur la stratégie des services informatiques, la transformation numérique et la gestion des problèmes et des incidents. Il possède également une expertise dans l'amélioration de la qualité, le développement de logiciels et la gestion de produits.

Shane Chagpar (schagpar@kepner-tregoe.com) réside au Canada et met en œuvre des projets au niveau mondial pour Kepner-Tregoe.

Related

Service avec système

Garder le contrôle - Concevoir des tableaux de bord et des mesures pour améliorer la réflexion sous pression

Nous contacter

Pour des demandes de renseignements, des détails ou une proposition !