Stratégie

Les 8 plus grandes erreurs commises par les DSI

Retrouvez cet article dans le CIO FOCUS n°153 !

Les tops des bonnes pratiques des DSI américains pour éviter les flops

CIO France traduit régulièrement des articles en provenance de son homologue américain mettant en avant des listes de bonnes pratiques. Ce CIO.Focus réalise une compilation de quelques uns de ces articles tirant des leçons des réalisations des DSI/CIO américains.

Découvrir

---

Pour les DSI, les retombées d'une gaffe stratégique peuvent être désastreuses pour eux-mêmes ou pour leur entreprise.

PublicitéTout le monde fait des erreurs. La plupart sont inoffensives, certaines sont embarrassants mais pardonnables, d'autres peuvent nuire à votre carrière, voire à votre entreprise. Certaines des gaffes informatiques les plus courantes comprennent le fait d'être coincé avec un fournisseur, de ne pouvoir se débarrasser de quelqu'un, embaucher ou promouvoir les bonnes personnes, et enfin cacher les problèmes à la direction, jusqu'à ce qu'il soit trop tard pour se rattraper. Voici les plus grandes erreurs que vous êtes susceptible de faire, et comment les éviter ou vous récupérer rapidement.

Erreur n°1 : le fournisseur mal verrouillé

C'est une forme de séduction. Les fournisseurs vous attirent avec des prix bas et des promesses sans fin. Mais une fois qu'ils vous ont fait signer, ils ne vous lâchent plus. « Une fois implantés, ils essaient de s'étendre dans votre environnement », explique Andrew Howard, directeur de la technologie chez Kudelski Security. « Tout commence par de bonnes intentions, mais le fournisseur finit par disposer d'un contrôle significatif sur les actifs informatiques et d'un effet de levier considérable sur les prix. J'ai vu plusieurs responsables informatiques perdre leur emploi sur ce type de mauvaise gestion ».

Andrew Howard reconnaît qu'il y a aussi des avantages. Mis à part les remises sur volume, obtenir plusieurs produits du même fournisseur devrait assurer une meilleure intégration entre eux ainsi qu'une sécurité plus stricte. Et moins de fournisseurs à traiter. Cela peut être idéal pour les petites organisations. Mais quand vous décidez de changer, ne vous attendez pas à ce que le fournisseur vous aide. Andrew Howard se souvient quand il travaillait dans une société de conseil, d'un fournisseur de gestion de workflow qui a essayé d'empêcher sa société de passer à un autre fournisseur en refusant de remettre son code source. Cette exigence, qui figurait dans l'accord de licence de logiciel (SLA) original, a réussi à s'évaporer dans les négociations ultérieures.

« Beaucoup de nos partenaires rencontrent le même genre de problèmes avec les fournisseurs de plateformes cloud. Une fois que vous en avez une, il est difficile de faire passer l'infrastructure chez un concurrent ». Pour cette raison, de nombreux DSI passent par plusieurs fournisseurs de cloud. Les responsables informatiques doivent également travailler plus étroitement avec les achats  pour éviter de devenir trop dépendants d'un seul fournisseur.

Erreur n ° 2 : traiter le cloud comme une extension du centre de données

En février 2016, Best Egg Personal Loans (prêt et réduction de dettes) a migré d'un cloud privé basé sur VMware vers un cloud public fonctionnant sur Amazon Web Services. La société avait passé des mois à planifier, configurer et migrer des services de faible niveau. Tout était prêt à basculer. Mais, deux heures après son lancement, un serveur AWS critique est mort.
« Le réveil fut brutal », explique Brian Conneen, DSI de Best Egg, «la stabilité d'un serveur cloud unique est inférieure à celle d'un serveur ou d'une machine virtuelle gérés en interne.

PublicitéLa disponibilité de 99,999% du cloud provient de la possibilité de provisionner de nouveaux serveurs pour remplacer ceux qui ont échoué. Le crash s'est produit pendant un week-end, et Best Egg a pu effectuer une récupération  sans interruption de service, mais Brian Conneen avait subi une leçon précieuse : vous ne pouvez pas traiter un serveur cloud comme s'il s'agissait d'une autre machine de votre centre de données.

Après cela, la priorité de Best Egg était de s'assurer qu'il était vraiment optimisé pour un environnement cloud, il devait aussi surveiller de près les coûts du cloud. Brian Conneen a également appris que les serveurs sont jetables. Quand ils tombent, vous les jetez. Best Egg a dû construire beaucoup plus de redondance, assigner un pool de serveurs à des systèmes qui ne pouvaient pas se permettre un temps d'arrêt et créer des scripts qui génèrent automatiquement de nouveaux serveurs. Maintenant, lorsque Best Egg publie une nouvelle version du logiciel, il construit simplement de nouveaux serveurs, leur envoie le code et fait défiler les anciens.

« Les avantages du cloud public ne peuvent être atteints que lorsque vous concevez votre infrastructure en fonction des atouts du cloud public », explique-t-il. « La simple migration de vos serveurs vers le cloud ne suffit pas, vous devez également migrer votre réflexion et votre approche ».

Erreur n ° 3 : sur estimer l'analyse de rentabilité

Cela a longtemps fait partie des cerveaux des DSI et même de leur cortex cérébral : pour obtenir une approbation pour une grosse dépense informatique, il faut avoir une solide analyse de rentabilité. Les DSI peuvent donc passer des semaines à rechercher des options, à calculer des hypothèses  et à assembler des powerpoints.

« C'est souvent pour rien », dit Mark Settle, DSI d'Okta, un ISP. « Il y a plusieurs années, j'étais interviewé par CIO et donnait une mini-conférence aux directeurs financiers sur l'importance des analyses de rentabilité. Le directeur financier m'a dit qu'il ne croyait pas aux chiffres issus de mes analyses de rentabilité, et n'approuve les principales initiatives informatiques que lorsque le Pdg lui-même donne son feu vert ».

Les dépenses nécessaires en matière d'infrastructure ou de conformité sont des exceptions, ajoute Mark Settle. Mais gagner la confiance signifie non seulement faire votre travail informatique en toute transparence, mais également travailler en partenariat avec d'autres équipes au sein de l'organisation, en tenant compte de  leurs processus existants et en les améliorant. Faites-le, et les Pdg seront beaucoup plus enclins à écouter vos idées lorsqu'une opportunité stratégique se présente.

« Si vous présentez trop d'analyses où la rentabilité est surestimée, sans que les autres membres du Comex soient prêts à se battre pour vous, vous rendez les choses beaucoup plus difficiles pour vous ».

Erreur n ° 4 : embaucher à un niveau trop bas de compétence

Il faut une équipe pour bâtir une entreprise prospère, mais il suffit d'un employé incompétent pour faire chuter tout le monde. « La plus grande erreur des responsables informatiques est d'embaucher des gens qui ne sont pas plus intelligents et meilleurs qu'eux », explique Derek Johnson, vice-président du développement commercial de la firme de recrutement Stride Search.

Malheureusement, les egos des DSI les empêchent souvent de choisir la bonne personne. Par exemple, il y a trois ans, Stride Search avait identifié l'ingénieur réseau et logiciel idéal pour l'un de ses clients, une startup dans le SaaS. Il était éloquent, charismatique, avait un doctorat en informatique et possédait plusieurs brevets. Tout le monde l'aimait, sauf le CTO de la startup. « L'entrevue téléphonique s'est bien passée, mais l'entrevue en face-à-face a été un désastre absolu », a déclaré M. Johnson. « Le CTO, qui était à la fois cofondateur et responsable de l'embauche, a passé toute l'entrevue à insulter le candidat, mais le reste de l'équipe de direction a voulu faire une offre, mais le CTO a refusé.  Finalement, le candidat est parti travailler pour un concurrent, qui a plus tard écrasé cette start-up, ce qui arrive si souvent que cela pourrait être une parabole ».

Les entreprises peuvent lutter contre ce problème en exigeant qu'aucune personne n'ait le pouvoir d'opposer son veto à une embauche. Pour les postes supérieurs, le conseil d'administration d'une société et les subordonnés du candidat doivent également être impliqués. « Le fameux dicton : un joueur A recrute des joueurs A, alors que les joueurs B embauchent des joueurs C, fonctionne à plein. Il n'y a rien de plus catastrophique pour une organisation que d'engager la mauvaise personne à un poste clé, ou de passer à côté du bon profil ».

Erreur n ° 5 : promouvoir le mauvais candidat interne

Si le fait de ne pas embaucher la bonne personne à l'extérieur est une erreur, la promotion du mauvais candidat interne l'est tout autant. De manière générale, la promotion interne est une excellente politique, note Giancarlo Di Vece, président d'Unosquare, un éditeur de logiciels informatiques. Mais vous devez le faire pour les bonnes raisons.

Les mauvaises ? Promouvoir quelqu'un pour le récompenser d'être un employé loyal. Cela peut mal tourner, surtout si l'employé n'est pas vraiment adapté pour le nouvel emploi. « J'ai vu des directeurs informatiques faire d'un bon développeur un leader technologique, mais ensuite ce  promu est devenu frustré et a fini par abandonner. Vous pensez que vous êtes un bon patron en donnant aux gens l'opportunité de grimper, et vous finissez par les perdre parce que vous les avez éloignés de ce qu'ils aimaient vraiment faire » !

Giancarlo Di Vece dit que cela lui est arrivé il y a environ un an. Il avait embauché un développeur et l'avait mis sur la voie d'une promotion rapide. Bientôt, le développeur a dirigé une équipe de cinq personnes. Tout s'est bien passé pendant trois mois, jusqu'au jour où il est entré dans le bureau de Di Vece et a démissionné. Même si le travail de l'équipe était excellent, le développeur a estimé qu'il avait échoué dans son travail et ne pouvait revenir à l'ancien.

« J'ai perdu une fantastique ressource de programmation en lui fournissant une promotion rapide », depuis lors, Di Vece dit qu'il a mis en place un cadre où les candidats nouvellement promus peuvent fournir et recevoir des commentaires réguliers, et les superviseurs peuvent garder un oeil sur ce qu'ils font pour les aider à réussir. La promotion interne est une bonne philosophie, mais ce n'est pas le bon choix dans tous les cas.

Erreur n ° 6 : appliquer la méthodologie agile aux systèmes de base

Avec l'explosion des services de cloud computing et les demandes croissantes en termes de rapidité, les DSI comprennent qu'une grande partie de l'informatique est hors de leur contrôle. Mais les mêmes mécanismes de prestation souples qui permettent aux entreprises de placer des conteneurs Docker et des micro-services dans le cloud peuvent avoir un impact désastreux sur la base des systèmes informatiques qui sont de la responsabilité du DSI, par exemple : messagerie, téléphonie, ERP et back-office des applications, explique Andrew Howard de Kudelski.

« J'ai vu plus de DSI perdre leur emploi parce qu'ils ne pouvaient pas assurer le fonctionnement de la messagerie, que pour tout autre motif. Les méthodologies agiles vont souvent à l'encontre d'un contrôle des changements rigoureux qui sont  nécessaires pour les systèmes de base. S'ils tombent en panne, les entreprises peuvent perdre de l'argent rapidement ».

Pour atténuer ce problème, les DSI doivent établir de solides limites, permettre des changements agiles sur les systèmes métier et imposant un contrôle des changements plus rigoureux sur les systèmes principaux.

Erreur n ° 7 : dire trop souvent « oui »

Les meilleurs responsables informatiques sont souvent accusés de dire « non » à l'innovation. Mais un problème plus grave survient quand ils ne savent pas comment affronter les gens, et risquent de perdre le contrôle sur la sécurité de leurs systèmes, explique Richard Henderson, stratège mondial en sécurité informatique chez Absolute.

« Combien de fois les informaticiens ou les responsables de la sécurité ont-ils reçu un appel de quelqu'un de haut placé exigeant l'accès à quelque chose de risqué ? À quelle fréquence les unités commerciales déploient-elles un nouvel outil ou un service cloud inédit sans vérification appropriée ni approbation des équipes informatiques ou de sécurité ? »

Selon Richard Henderson, des outils comme le stockage dans le cloud et les solutions en SaaS peuvent offrir d'énormes avantages aux équipes. Mais lorsque les responsables informatiques approuvent systématiquement les demandes exceptionnelles, ils créent de nouveaux angles morts dans leur organisation et, potentiellement, de nouvelles vulnérabilités.

Il est difficile de dire « non » à son PDG, mais vous devez avoir un plan en place pour faire face aux exceptions. Un solide système de gestion des actifs est essentiel, de même qu'un logiciel qui surveille les périphériques d'extrémité et vous alerte lorsque les utilisateurs se connectent à des services cloud communs. « Dire « «  trop souvent, rend impossible le maintien des actifs en conformité, surtout si vous n'êtes pas dans la boucle quand quelqu'un du marketing crée une nouvelle instance AWS. »

Erreur n ° 8 : cacher les problèmes (à son patron)

Quand un grand projet commence à battre de l'aile, beaucoup de responsables informatiques tentent de l'enterrer, espérant le réparer avant que les patrons ne s'en aperçoivent, explique Mark Settle d'Okta. Les choses vont en fait s'aggraver. Au moment où ils finissent par admettre que la nouvelle version du code a amené une interruption de 48 heures, ou qu'ils ont besoin de 4 millions de dollars supplémentaires pour terminer leur projet, ils ont perdu leur crédibilité.

« Plus tôt vous exposerez les mauvaises nouvelles et mieux ce sera. Les mauvaises nouvelles ne s'améliorent jamais d'elles-mêmes et plus tôt les gens commenceront à s'en occuper, et plus vous aurez de chances de récupérer le projet et de revenir sur la bonne voie.  Fournir de mauvaises nouvelles n'est jamais facile, mais ce sera le cas si vous avez établi et maintenu une bonne relation de travail avec votre boss ».

Les DSI doivent créer des occasions de discuter avec le directeur financier et d'autres membres de la direction lorsqu'ils ne sont pas en mode crise. Ce n'est pas toujours facile pour les gens axés sur la technologie, mais ce sont des compétences dont ils ont besoin pour avancer.

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

Article rédigé par

IDG News Service,

Partager cet article