Showing posts with label indicators. Show all posts
Showing posts with label indicators. Show all posts

Monday, August 12, 2013

Indicateurs du début de la fin en DSI 2

Suite au succès du premier article, j'en poste un second sur le même thème : ces signaux faibles qu'un DSI devrait apprendre à reconnaître pour éviter le naufrage ou, souvent, l'accumulation d'inertie qui mène au naufrage.
Aujourd'hui, deux petits nouveaux.


Iceberg n°1 : Le ratage d'un tournant métier. Votre entreprise développe une nouvelle activité, c'est une petite branche de l'activité et représentait à peine un pourcent du chiffre d'affaires hier. Vous n'y avez accordé que peu d'attention. Seulement, aujourd'hui, le marché a changé et cette activité représente 35% du chiffre, plus à venir.
Comme vous n'aviez pas donné suffisamment d'attention à cette activité, les relations avec son directeur sont au plus bas et il demande des changements radicaux. Changement de têtes ou... fournisseur externe.

Icerberg n°2 : La gestion des assets (des actifs). Mettre en place une gestion des actifs sur une flotte donnée (PC, smartphones, imprimantes, voitures, bornes WiFi) permet d'en diminuer le coût de 30% très rapidement, et plus avec le temps. Malheureusement, si la gestion des assets s'encroûte, si elle ne suit plus les évolutions récentes et finit par n'avoir que quelques dizaines de pourcents de données à jour, on va droit à l'échec, là encore.
Les projets de gestion des assets ne sont pas des silos applicatifs mais des projets structurants transversaux et doivent faire l'objet d'une attention extrême à leur démarrage. Il s'agit d'un véritable investissement. Investissez sur une gestion opensource, évolutive, avec le personnel correspondant ou bien sur une solution propriétaire mais de fonctionnalités très largement supérieures à vos besoins. Par contre, ne vous lancez pas dans l'utilisation de solutions intermédiaires propriétaires qui vous empêcheront *absolument* de faire évoluer votre gestion des assets.

Thursday, August 8, 2013

Indicateurs du début de la fin en DSI

Il y a de ces signes qui ne trompent pas, le navire DSI va droit à l'iceberg. Avec le temps, on apprend à en connaître certains. On devrait pourtant les partager davantage. Ci-dessous un petit florilège.

Il y a cet outil réseau, made in DSI, que j'appelle les SOCKS-étoile-étoile. Les SOCKS ou, dans leur implémentation Microsoft, les Winsocks, ont été développés pour permettre d'offrir un traitement de type "proxy" aux protocoles qui n'ont pas été développés pour être proxyfiés. Très belle attention.
Dans la pratique, une DSI a souvent un proxy pour le web et un firewall pour le reste. Le firewall étant lourd à configurer, on n'y rajoute pas souvent des règles et la DSI "installe les SOCKS" à un utilisateur qui a des besoins réseaux inhabituels. N'ayant pas le temps de les configurer, la DSI établit une configuration de base qui autorise tous les protocoles réseau, vers toutes les destinations (ce que j'appelle étoile-étoile ou *:*), avec la promesse que ce ne sera que temporaire. Sauf que le temporaire devient permanent et que les utilisateurs SOCKS-ifiés se multiplient. A ce rythme, en un rien de temps, le proxy et le firewall sont devenus inutiles et les terminaux des vrais nids à virus.

Il y a ceux dont le nom seul évoque l'échec d'une DSI, comme Microsoft Access. Partant d'une très bonne intention, complémenter le service informatique pour les petits problèmes locaux, les utilisateurs développent des "bases" en Access.
Elles sont développées sans les compétences en développement => Elles deviennent in-maintenables, du vrai Write-Only. Elles sont développées loin des cadres de l'informatique de l'entreprise => Elles ne s'intègrent pas aux processus de la DSI, telles la sauvegarde ou la documentation. Dans le meilleur des cas, elles occasionnent des coûts imprévus gigantesques lorsqu'il faut les intégrer dans un cadre plus sérieux, c'est-à-dire les re-développer depuis zéro. Dans le pire des cas, les services en deviennent dépendants et, quand elles craquent car mal développées et non sauvegardées, elles occasionnent des arrêts de travail de ces services.
Certaines grandes entreprises ont même pris l'initiative d'interdire Access dans toute l'entreprise.

Menace plus insidieuse qu'Access, il y a les outils équivalents à Access. Un exemple : FileMaker Pro. On ne s'en méfie pas car il est cher. On se dit donc que ceux qui l'achètent en feront un usage raisonnable. Point du tout : soit il est utilisé à la DSI et il devient un outil comme un autre, soit il est utilisé par des utilisateurs finaux bien-intentionnés et c'est la rebelote d'Access. Pire encore, devrais-je dire, car les vraies compétences sur pareils logiciels sont plus rares et plus chères que celles sur Access.

Un autre outil vicieux est le tableau croisé dynamique d'Excel. Quelle belle fonctionnalité ! Cet outil permet de faire des calculs, des comptes, des sommes sur des tableaux de données. On lui donne les données, on lui dit quels champs compter, sommer, et il se débrouille... en théorie. C'est un outil magnifique pour la recherche, pour l'analyse ponctuelle de données, mais en aucun cas pour la fabrication de chiffres en production. Il est trop complexe, trop lié à sa représentation à l'écran dans Excel, difficile à manipuler. Résultat, trop souvent on obtient un résultat sans être absolument certain que ce soit le bon. « J'obtiens tel nombre d'occurrences du problème X, mais est-ce en comptant les doublons sur les deux tableaux ou sans les compter ? » Un bon outil théorique mais pas pour la prod.

Sur le plan managérial, il y a un indicateur net d'iceberg droit devant : l'externalisation d'un silo applicatif (cloud ou non). Si c'est un petit silo, ce n'est pas très grave, mais s'il est grand et qu'il est vraiment silo, c'est-à-dire que tant l'application que son infrastructure, sa maintenance et ses évolutions sont externalisés, alors il y a vraiment du souci à se faire : la DSI a un concurrent au sein de l'entreprise.

Un autre indice qui devrait mettre la puce à l'oreille quant à un possible iceberg est l'accumulation de tickets non traités concernant une application donnée. Ces tickets peuvent être minimes, bénins voire obsolètes mais ils renvoient une image négative et leurs auteurs s'impatientent, voire se désespèrent. C'est ce genre d'accumulation qui mène une direction à jeter le bébé avec l'eau du bain concernant un système qui marchait, dans l'ensemble, plutôt bien.

Et puis il y a le manque de plan de continuité. Le principal indice, c'est quand tout le monde parle du PCA mais que personne ne sait par où commencer, que chacun prend ses petites initiatives de son côté mais que personne ne sait qui en est responsable.

C'est un tout petit extrait et j'en rajouterai sans doute.