Projets

Les 6 projets informatiques les plus redoutés par les DSI

Pour Dan Coleby, directeur des performances commerciales et du conseil pour IT Lab, le pire reste l'ERP

Les projets que redoutent la plupart des DSI sont des tâches ingrates qui suscitent peu de reconnaissance ou de respect.

PublicitéLa gestion des correctifs n'est pas glamour, mais reste essentielle pour éviter à votre organisation de subir une violation de sécurité massive. Les projets de migration dans le cloud ne sont guère sexy, mais utiliser des serveurs de messagerie interne en 2018 c'est comme utiliser des téléphones à cadran. Les mises en oeuvre et les mises à niveau d'ERP ont constitué la majorité des échecs de projets informatiques depuis plus d'une décennie, mais la plupart des grandes entreprises ne peuvent pas survivre sans un système ERP.

La technologie n'est presque jamais la cause de ces projets informatiques qui tournent mal. Le plus souvent, les initiatives technologiques tombent à plat en raison d'attentes irréalistes, d'un manque de projection adéquate, d'affrontements culturels, de la procrastination ou d'un manque de soutien au plus haut niveau. Les solutions à de tels projets sont généralement simples, mais le diable est dans les détails.

1. D'énormes correctifs de dernière minute

Patcher est l'une de ces tâches essentielles que presque tous les professionnels de l'informatique veulent éviter. Mais si vous les gardez trop longtemps, ou si vous ne vous assurez pas que toutes vos machines sont à jour, votre organisation pourrait finir comme Equifax.

« Nous sommes constamment aux prises avec de grands projets où les correctifs n'ont pas été mis en place depuis des mois ou des années », explique Oli Thordarson, PDG du fournisseur de services informatiques Alvaka Networks. « Parfois, il peut y avoir des centaines de serveurs de production, ainsi que des serveurs de développement et de test. Sachant que si quelque chose ne va pas, Internet peut le savoir, répandre l'information et infliger des dégâts à votre marque. C'est pourquoi le personnel interne tarde parfois à patcher, jusqu'à ce la direction se penche sur la situation et se rende compte que c'est accablant. »

Il y a quelques années, Alvaka faisait un gros travail de correction Windows pour un service de police d'une ville, explique Oli Thordarson. « Tout s'est bien passé pour les ordinateurs de bureau en général, moins pour ceux du chef de la police, des capitaines et des lieutenants, qui n'étaient pas contents du tout. Les hauts gradés des services de police ne sont pas des gens timides. Ils nous appellent dès qu'ils ne peuvent pas se connecter ou faire ce qu'ils devaient faire. »

Il s'avère qu'ils utilisaient des machines légèrement différentes avec des applications tierces qui provoquaient un conflit. L'équipe de Oli Thordarson a été capable de restaurer les correctifs, d'isoler le problème et de les réparer en 30 minutes environ.
Les pires projets sont ceux où les systèmes ont été négligés pendant des années, ajoute Untar Gardarsson, directeur technique d'Alvaka. « Le moment le plus délicat, c'est quand j'ai patché quelque chose et que les serveurs prennent un temps anormalement long à revenir, ou ne reviennent pas du tout. Dans certains cas, je peux aller dans la console de récupération de la machine virtuelle et regarder le serveur. Dans d'autres environnements, tout ce que je peux faire, c'est réparer et prier.»

Publicité« Pour chaque tâche de correctif que je fais, j'ai un plan qui prend en compte tout, depuis les sauvegardes normales et les instantanés supplémentaires jusqu'à la notification des personnes et l'arrêt des services », explique-t-il. « Certains systèmes sont très compliqués et il existe un processus très spécifique pour les mettre hors ligne: il est essentiel de se préparer et de réfléchir à tous les scénarios possibles. »

2. La grande migration des messageries vers le cloud

Passer à une solution de courrier électronique sur le cloud semble simple. Mike Meikle, PDG de SecureHIM, un cabinet de conseil spécialisé dans la sécurité informatique, dévoile les dessous du problème. D'une part, les utilisateurs sont des accapareurs, dit Mike Meikle. Ils ont des masses de messages qu'ils auraient dû supprimer il y a des années, donc le volume de données est décourageant. D'autre part, si vous partez d'un système hérité comme Lotus Notes, vous aurez beaucoup de conversion de données au menu. Et certaines informations contenues dans ces messages sont très sensibles et réglementées. Vous devez donc vous assurer que vous respectez les réglementations HIPAA, GDPR, SOX ou autres.

Et bien sûr, vous avez affaire à un système sur lequel les gens comptent pratiquement 24 heures sur 24 et 7 jours sur 7 pour communiquer, planifier, réserver des salles de réunion, etc. Les organisations veulent à la fois une technologie de pointe et une plus grande efficacité. Voici comment les solutions informatiques intelligentes sont capables de fournir les deux. Mike Meikle dit qu'il a travaillé dans des entreprises où la migration vers le cloud a pris plus d'un an et a nécessité beaucoup de main-d'oeuvre.

« Puisque le courrier électronique est omniprésent, si la migration tombe, la DSI est immédiatement en cause. Même à l'ère de Slack et d'autres applications de chat en équipe, la migration des e-mails est l'un de ces projets que les services informatiques redoutent le plus.»

3. Une conformité impossible à mettre en oeuvre

Il existe deux types de projets informatiques : ceux qui bénéficient d'un parrainage fort de la part de la direction, car ils sont stratégiques pour le succès de l'organisation, et tous les autres. Mais la catégorie la plus préoccupante est celle où les salariés doivent être traînés de manière directives vers la conformité, avec peu de soutien de la hiérarchie. « Les projets axés sur la réglementation qui sont commandés par la haute direction, mais ne reçoivent pas leur appui, sont les pires », affirme le directeur d'une société de services informatiques qui a demandé à rester anonyme pour éviter d'être identifié par ses anciens collègues.

Jusqu'à il y a environ un an, cet interlocuteur était vice-président de la technologie pour une grande institution financière de la côte Ouest des Etats-Unis. Quand il a rejoint l'entreprise, elle était déjà dans le collimateur des régulateurs, en partie à cause d'un plan de reprise après sinistre inadéquat. Les actionnaires activistes poussaient l'institution à réagir vite, tandis que la haute direction était derrière le projet, les directeurs de département avaient leurs propres priorités.

Ces directeurs de département n'ont pas participé. Ils n'ont pas réussi à soumettre leurs exigences en matière de basculement ou de récupération, ni à identifier les données et les applications stratégiques. Ils n'ont pas participé à des tests préliminaires ou avancés. Ils ont ignoré les emails du vice-président chargé de la technologie Parce que les demandes provenaient de l'IT, les chefs de service se sentaient à l'aise pour les reléguer en fin de liste de leurs priorités et les commanditaires du projet n'ont rien fait pour intercéder au nom du vice-président.

« J'ai alerté à maintes reprises le DSI ... je n'ai pas encore reçu de réponse. Le projet a donc progressé et les risques n'ont été ni acceptés ni reconnus ».

4. L'ERP, proche du désastre

Aucun type de projet n'a inspiré plus d'angoisse ou provoqué plus de brûlures d'estomac que la mise en oeuvre d'un nouveau système ERP. Avoir à interfacer l'ERP avec du matériel existant est toujours périlleux, il faut se jeter dans des affres linguistiques et culturelles infinies, une recette certaine pour aboutir à un désastre, note Dan Coleby, directeur des performances commerciales et du conseil pour IT Lab, une société de services technologiques basée au Royaume-Uni.

Au milieu des années 2000, lorsque Dan Coleby travaillait pour l'un des quatre grands cabinets d'études , il a été appelé pour aider la branche japonaise d'une grande multinationale à déployer son système ERP mondial. Au moment de son arrivée, le projet existait depuis plus de deux ans et dépassait considérablement le budget, en partie parce que le matériel était vraiment ancien.

« L'un de ces systèmes était si vieux que nous avons dû emprunter une source d'alimentation à une exposition du National Computer Museum de Tokyo au cas où celle-ci aurait échoué. Nous n'avions que 8 heures par jour pour rafraîchir le système ERP avec de nouvelles données, mais l'interface a pris 20 heures avant de fonctionner, ce qui la rend parfaitement inutile. Les plus gros obstacles n'étaient pas technologiques, ils étaient personnels et politiques ». Dan Coleby a dû trouver comment rendre le système opérationnel sans que personne ne perde la face.

« Je n'avais pas le droit de remettre en question l'architecture, la stratégie ou l'approche globale de la technologie de l'entreprise », explique-t-il. « J'ai fini par persuader les Japonais de modifier leurs processus métier afin qu'ils utilisent moins d'informations, j'ai supprimé environ 90% des données pour que le système fonctionne en moins de 8 heures. »

5. Transformer un projet difficile en un projet infernal

Qu'il s'agisse d'un excès d'optimisme, d'un désir d'impressionner le patron ou d'une incapacité à bien planifier les projets, une sous-estimation du temps et des efforts requis pour présenter une demande peut transformer un projet difficile en un projet infernal. « Vous avez des gens très optimistes quant à ce qu'ils peuvent livrer dans un court laps de temps, en particulier dans les entreprises en évolution rapide », explique Alan Zucker, directeur fondateur de Project Management Essentials.

À la fin des années 1990, il travaillait comme chef de projet dans le département comptabilité d'une entreprise de télécommunications. L'opérateur facturait plus de 1 milliard de dollars par mois et utilisait des centaines de feuilles de calcul et de bases de données reliées entre elles pour suivre le tout. La solution consistait à créer une application unique pour fermer les livres chaque mois, en utilisant Sybase avec une interface Power Builder.

Après une réorganisation de l'entreprise, la responsabilité du projet revient au groupe d'Alan Zucker. « Le groupe informatique a eu une idée très élégante, qui consistait à tout charger dans une base de données et à laisser les responsables de la comptabilité établir leurs propres règles métier », explique-t-il. Mais ils avaient promis de livrer l'application dans neuf mois. Lorsque Dan Zucker a hérité du projet, quatre mois plus tard, pas une seule ligne de code n'avait été écrite. Le groupe informatique collectait toujours les besoins des utilisateurs. Et ils découvraient que le travail était beaucoup plus compliqué que prévu.

C'est alors que tout a dégénéré. « Mon homologue dans l'organisation informatique a commencé à être très défensif. Il écrivait de longs courriels, de vraies enquêtes de police. « À cette date, à ce moment-là, untel a dit ceci ...» et ainsi de suite. C'était l'escalade, il n'y avait tout simplement pas de conversations constructives à avoir.

Le responsable informatique a été affecté sur un autre poste et Dan Zucker a obtenu un nouveau partenaire et un calendrier plus indulgent pour que le projet progresse. L'application a finalement été un succès, mais il a fallu deux autres années avant qu'elle ne soit terminée.

6. Le pouvoir politique du DSI est-il suffisant ?

Vous avez peut-être standardisé votre organisation sur Android, mais vous devrez retirer l'iPhone des mains du PDG. Ou peut-être surveiller un directeur qui a l'oreille du Comex et demande une solution personnalisée pour son département. Dans le scénario idéal, les demandes de projets sont évaluées par rapport aux plans stratégiques et jugées nécessaires pour que l'entreprise atteigne des objectifs spécifiques avant d'être approuvés et budgétisés.

« La plupart des organisations ne fonctionnent pas comme ça, explique Dan Meikle. Dans la plupart des cas, c'est celui qui a le plus de pouvoir politique qui gagne ». Il dit même que les entreprises les plus fermées peuvent être victimes des caprices de ceux qui exercent le plus d'influence. Dans de nombreux cas, cela arrive parce que le DSI n'a pas de pouvoir politique suffisant.

« Quand les choses se corsent, elles se replient. Vous avez donc besoin de la suite logicielle dans votre camp pour gérer efficacement les projets informatiques et le flux de travail », ajoute-t-il. « Si ce n'est pas le cas, vous devrez financer tous les caprices de votre budget informatique, laissant des miettes pour des projets moins glamour mais critiques comme l'infrastructure et le réseau ».

Dan Tynan / IDG News Service (adapté par Didier Barathon)