Migration de ce blog
Suite à la création de ma société Auris Solutions, ce blog s'est modernisé
et a migré.Cliquez ici pour aller sur le nouveau site.
juin 2009
Suite à la création de ma société Auris Solutions, ce blog s'est modernisé
et a migré.Cliquez ici pour aller sur le nouveau site.
3 février 2009
Echange avec un e-lecteur
Mail : "Bonjour,
J'avoue que ma méthode peut paraitre assez maladroite, je me permets de vous contacter car je souhaiterais
profiter de votre expérience et vécu. En promenant sur le net avec en tête mon avenir professionel je suis tombé
sur votre site.
J'avoue être un peu "perdu" . Jusqu'a présent mon parcours professionnel est accès technique (sécurité réseau), environnement de production, gestion d'un petite équipe, et plus en plus de mise en place de procédure de support, logigrame etc...
Cette partie m'interesse particulièrement et je pense qu'ITIL V3 pourait me permettre de développer et me spécialiser vers ce domaine/métier.Cependant je ne suis pas sur qu'elle soit la plus adaptée à mon besoin. Pour faire plus simple je souhaiterais quitter progressivement le monde technique pour le monde "business" Que mon conseilleriez vous? qu'elle est selon vous le domaine porteur? Merci d'avance du temps que vous pourriez me consacrer.
Nicolas "
Réponse : Avec l'âge, l'évolution consistant à passer d'un métier très technique vers un métier plus orienté manager est classique, voire normale et cela se fait souvent via la conduite d'un projet et d'équipes de plus en plus importantes. Concernant votre demande, je crois que vous avez quand même 2 orientations possibles :
J'avoue être un peu "perdu" . Jusqu'a présent mon parcours professionnel est accès technique (sécurité réseau), environnement de production, gestion d'un petite équipe, et plus en plus de mise en place de procédure de support, logigrame etc...
Cette partie m'interesse particulièrement et je pense qu'ITIL V3 pourait me permettre de développer et me spécialiser vers ce domaine/métier.Cependant je ne suis pas sur qu'elle soit la plus adaptée à mon besoin. Pour faire plus simple je souhaiterais quitter progressivement le monde technique pour le monde "business" Que mon conseilleriez vous? qu'elle est selon vous le domaine porteur? Merci d'avance du temps que vous pourriez me consacrer.
Nicolas "
Réponse : Avec l'âge, l'évolution consistant à passer d'un métier très technique vers un métier plus orienté manager est classique, voire normale et cela se fait souvent via la conduite d'un projet et d'équipes de plus en plus importantes. Concernant votre demande, je crois que vous avez quand même 2 orientations possibles :
- soit vous restez dans un cadre de management d'équipes techniques et dans ce cas renforcer vos connaissances et compétences en ITIL, bien qu'utiles, ne sera pas fondamentale (mieux vaut alors chercher à renforcer vos compétences de manager)
- soit vous évoluez vers un métier d'audit / conseil et dans ce cadre ITIL peut vous donner une grille de décodage des DSI et de leurs relations avec les directions métiers de l'entreprise.
17 décembre 2008
Nouveau site DSI
Juste une petite mise à jour pour vous communiquer l'adresse d'un nouveau site dédié aux DSI : Le blog ANDSI.
20 Septembre 2007
Echange avec un e-lecteur
Mail : "Responsable informatique et administrateur réseau pendant 9 ans, j'ai aujourd’hui choisi le métier du consulting.
Ainsi depuis quelques mois, je suis consultant junior auprès des revendeurs informatiques. En effet ces derniers, comme vous le savez, sont aujourd'hui conscients de la nécessité d'allier le service à la vente de matériel informatique. C'est pourquoi, ils doivent proposer des solutions packagés à leurs clients. C'est la que nous intervenons en rédigeant les supports d'aide à la vente et marketing. Nous leur proposons également un accompagnement.
J'imagine très aisément que votre temps est précieux et je ne serai pas surpris si vous ne pouvez donner suite à ma requête.
Toutefois, je souhaiterai quelques conseils, fruit de votre expérience, pour réussir dans cette profession.
Merci dans tous les cas pour votre attention.
Cordialement.
Abdel."
Réponse : Difficile de vous donner des conseils tant les situations peuvent être variées.
Je me limiterais à celui-ci : le client attend toujours quelque chose, mais sait rarement dire ce qu'il attend vraiment (sinon, il saurait probablement résoudre son problème). Il est donc nécessaire d'une part de le faire parler sur sa demande initiale (cela le soulage et cela doit permettre de reformuler les choses pour faire un premier tri) mais surtout de comprendre ou de deviner ce qui est vraiment son problème, problème qui n'est pas nécessairement technique (un "mon informatique marche mal" peu en faite cacher, "mon organisation humaine a des problèmes", "mes processus d'entreprise sont inadaptés à ce que je fais", "ma technologie n'est pas la bonne", etc).
Tout l'art du consultant est alors de répondre formellement à sa demande initiale (celle qui a reçu le budget de la mission) et foncièrement aux vrais problèmes.
Ainsi depuis quelques mois, je suis consultant junior auprès des revendeurs informatiques. En effet ces derniers, comme vous le savez, sont aujourd'hui conscients de la nécessité d'allier le service à la vente de matériel informatique. C'est pourquoi, ils doivent proposer des solutions packagés à leurs clients. C'est la que nous intervenons en rédigeant les supports d'aide à la vente et marketing. Nous leur proposons également un accompagnement.
J'imagine très aisément que votre temps est précieux et je ne serai pas surpris si vous ne pouvez donner suite à ma requête.
Toutefois, je souhaiterai quelques conseils, fruit de votre expérience, pour réussir dans cette profession.
Merci dans tous les cas pour votre attention.
Cordialement.
Abdel."
Réponse : Difficile de vous donner des conseils tant les situations peuvent être variées.
Je me limiterais à celui-ci : le client attend toujours quelque chose, mais sait rarement dire ce qu'il attend vraiment (sinon, il saurait probablement résoudre son problème). Il est donc nécessaire d'une part de le faire parler sur sa demande initiale (cela le soulage et cela doit permettre de reformuler les choses pour faire un premier tri) mais surtout de comprendre ou de deviner ce qui est vraiment son problème, problème qui n'est pas nécessairement technique (un "mon informatique marche mal" peu en faite cacher, "mon organisation humaine a des problèmes", "mes processus d'entreprise sont inadaptés à ce que je fais", "ma technologie n'est pas la bonne", etc).
Tout l'art du consultant est alors de répondre formellement à sa demande initiale (celle qui a reçu le budget de la mission) et foncièrement aux vrais problèmes.
31 mai 2007
Offres d'emploi en Informatique (ingenierie, audit, consulting)
BV Associates est une SSII-PME créée en 1991 par Jean-Philippe BOUZON et Francois VILMANT. C'est un cabinet d'audit, de consulting et d'ingénierie
qui a pour mission d'accompagner les Entreprises dans l'industrialisation des processus métiers de leur Production Informatique.
Dans le cadre de son développement, notre société recrute au niveau BAC+5 des :
BVA-RIS-WEB-05.2007
Détails des profils recherchés :
-> Ingénieur Consultant Senior, Ingénieur Consultant Confirmé
Mots-clés :
INGENIEUR CONSULTANT PRODUCTION INFORMATIQUE DSI BANQUE ASSURANCE INDUSTRIE
http://www.bvassociates.fr
Secteur : High Tech
Type de contrat : CDI
Rémunération : A négocier
Dans le cadre de son développement, notre société recrute au niveau BAC+5 des :
BVA-RIS-WEB-05.2007
Détails des profils recherchés :
-> Ingénieur Consultant Senior, Ingénieur Consultant Confirmé
- Audits techniques
- Elaboration et suivi des offres de service
- Réalisation des tableaux de bord
- Pilotage des projets d'intégration et de mise en production
- Conception et mise en œuvre d'architecture de production
- Conception et mise en applications des normes et méthodes
- Responsable des livrables techniques et documentaires
- Communication et transfert de savoir-faire
- Aide à la conception de l'architecture de production
- Conception et réalisation des procédures d'exploitation des composants génériques
- Intégration et mises en production
- Support à la production
- Analyse des risques et proposition de solutions techniques
- Rédaction des documentations techniques
- Conception et réalisation des procédures d'exploitation des composants génériques
- Réalisation des tests techniques de validation
- Validation des procédures jusqu'à la mise en production
- Aide aux mises en production
- Rédaction des documentations techniques
Mots-clés :
INGENIEUR CONSULTANT PRODUCTION INFORMATIQUE DSI BANQUE ASSURANCE INDUSTRIE
http://www.bvassociates.fr
Secteur : High Tech
Type de contrat : CDI
Rémunération : A négocier
Des petits PRA pour garantir le SI ?
Comme je change régulièrement de mission, j'ai régulièrement l'occasion de voir des mises en oeuvre de Plan de Reprise d'Activité, soit
comme acteur, soit comme spectateur attentif.
Deux tendances se dégagent pour mener à bien un projet PRA :
Ce genre d'approche est typique d'un projet de techniciens et il a l'avantage d'apparaître comme simple : "on dispose de machines et de composants logiciels, sauvegardons-le et sachons les restaurer, nous aurons un PRA".
Lorsque l'application est bien isolée du reste du SI (pas de mutualisation et pas de flux de donnés), cette approche est effectivement simple à mettre en oeuvre et elle aboutit au succès de l'objectif premier qui est de restaurer ce qui est nécessaire à la production du service informatique.
Cette approche pose cependant des problèmes dans le cas de mutualisation (des applications appartenant à plusieurs maîtrises d'ouvrage peuvent poser des problèmes d'écrasement lors de restaurations successives non contrôlées). Ensuite, en cas de restauration, il est nécessaire de ne pas perdre les flux de données qui transitaient au moment du crash, ni de les réinjecter plusieurs fois à la restauration. Seule une vue globale cohérente du SI permet de gérer cet aspect.
Un PRA réellement vu comme un Plan de Reprise d'Activité, c'est à dire centré sur la restauration des services
Cette approche, peu courante, nécessite d'auditer les différents métiers de l'entreprise et il aboutit parfois à des résultats surprenants.
Tout d'abord, la production informatique en vient souvent à "redécouvrir" ce qu'elle produit ; en effet, le service de production doit trop souvent porter son attention sur ce qui dysfonctionne ce qui provoque une déformation entre ce qui est important pour le métier de l'entreprise, et ce qu'il est urgent de rétablir dans un service nominal. Lors d'une de mes missions PRA, l'informatique a eu la "surprise" de découvrir qu'une application simple qui ne posait jamais de problème était en fait l'application dont dépendait tout le fonctionnement de l'entreprise.
Le deuxième bénéfice de cette approche est de faire apparaître une priorisation des restaurations en fonction d'un calendrier : en fonction de la date du sinistre, on ne va pas restaurer les applications dans le même ordre, chose qu'il est très important de savoir si les restaurations doivent durer plus de 24h (ce qui est rapidement le cas si le SI devient important).
Dernier élément qui a son importance, tous les PRA que j'ai vu avoir des difficultés d'aboutissement étaient des PRA techniques et le meilleur PRA (en terme de respect des délais et de qualité finale) était un PRA centré sur les services.
Deux tendances se dégagent pour mener à bien un projet PRA :
- conduire le projet en prenant l'architecture comme fil conducteur
- conduire le projet en prenant le service à restaurer comme fil conducteur
Ce genre d'approche est typique d'un projet de techniciens et il a l'avantage d'apparaître comme simple : "on dispose de machines et de composants logiciels, sauvegardons-le et sachons les restaurer, nous aurons un PRA".
Lorsque l'application est bien isolée du reste du SI (pas de mutualisation et pas de flux de donnés), cette approche est effectivement simple à mettre en oeuvre et elle aboutit au succès de l'objectif premier qui est de restaurer ce qui est nécessaire à la production du service informatique.
Cette approche pose cependant des problèmes dans le cas de mutualisation (des applications appartenant à plusieurs maîtrises d'ouvrage peuvent poser des problèmes d'écrasement lors de restaurations successives non contrôlées). Ensuite, en cas de restauration, il est nécessaire de ne pas perdre les flux de données qui transitaient au moment du crash, ni de les réinjecter plusieurs fois à la restauration. Seule une vue globale cohérente du SI permet de gérer cet aspect.
Un PRA réellement vu comme un Plan de Reprise d'Activité, c'est à dire centré sur la restauration des services
Cette approche, peu courante, nécessite d'auditer les différents métiers de l'entreprise et il aboutit parfois à des résultats surprenants.
Tout d'abord, la production informatique en vient souvent à "redécouvrir" ce qu'elle produit ; en effet, le service de production doit trop souvent porter son attention sur ce qui dysfonctionne ce qui provoque une déformation entre ce qui est important pour le métier de l'entreprise, et ce qu'il est urgent de rétablir dans un service nominal. Lors d'une de mes missions PRA, l'informatique a eu la "surprise" de découvrir qu'une application simple qui ne posait jamais de problème était en fait l'application dont dépendait tout le fonctionnement de l'entreprise.
Le deuxième bénéfice de cette approche est de faire apparaître une priorisation des restaurations en fonction d'un calendrier : en fonction de la date du sinistre, on ne va pas restaurer les applications dans le même ordre, chose qu'il est très important de savoir si les restaurations doivent durer plus de 24h (ce qui est rapidement le cas si le SI devient important).
Dernier élément qui a son importance, tous les PRA que j'ai vu avoir des difficultés d'aboutissement étaient des PRA techniques et le meilleur PRA (en terme de respect des délais et de qualité finale) était un PRA centré sur les services.
Question d’internaute
Najd : « Je suis un chercheur inscrit en thèse, je veux savoir si possible les différents axes a développer sur ITIL. »
Voici quelques remarques générales sur le sujet.
Dans une DSI moderne, on peut faire la distinction entre trois composantes structurelles :
- les processus d'entreprise
- l'organisation
- la technologie de l'information.
ITIL ne s'attaque qu'aux processus d'entreprise, et encore à seulement deux en détail : la production des services et le support aux services. Première question : peut-on travailler sur les processus indépendamment de l'organisation en place :
- de sa culture (a-t-on l’habitude de travailler avec la sous-traitance ou est-on adepte du « faisons tout nous même », a-t-on une culture du secret ou au contraire de la transparence, ). Ceci a bien évidemment un impact sur les relations clients / fournisseurs mises en avant par ITIL (dans un contexte de secret, on va chercher à minimiser l’échange d’information entre clients et fournisseurs par exemple, ce qui en soit est un frein à l’accomplissement de la production des services).
- de ses contraintes historiques ou sociales (par exemple, dans certaines entreprises, des choix d’architecture technique sont faits pour des raisons syndicales liées à des relations sociales) ?
Ces exemples ne sont pas exhaustifs et illustrent le fait qu’une analyse en terme de processus n’est pas forcément le premier point à traiter. Quels sont les critères qui permettraient d’identifier les priorités ?
Même dans le cas où l’on pourrait s’abstraire des contraintes existantes, comment décliner une réflexion sur les processus en terme de livrables et de normes et standard devant découler sur la mise en place d’une organisation et l'utilisation d'outils de production ? Comment une organisation peut-elle avoir connaissance et se fondre harmonieusement dans un découpage de l’entreprise en processus ? Quels sont les outils de management qui lient les processus aux hommes ? Quels sont les outils de gouvernance qui remontent les résultats et permettent de qualifier le service produit en regard de ce qui était initialement prévu ?
Enfin, ITIL suppose implicitement qu'une entreprise n'a qu'un type de découpage en processus or on constate, particulièrement avec les grands groupes ou les GIE, que toute l'entreprise ne vit pas au même rythme (par exemple, la tenue des comptes bancaires du client lambda n'a rien à voir en terme de rythme de vie et d’enjeux financiers avec l'asset management).
ITIL, en tant que catalogue de bonnes pratiques, est loin d’être une réflexion théorique scientifiquement limpide. Elle laisse encore aujourd’hui beaucoup de place à l’intuition et au savoir-faire des consultants des DSI.
Voici quelques remarques générales sur le sujet.
Dans une DSI moderne, on peut faire la distinction entre trois composantes structurelles :
- les processus d'entreprise
- l'organisation
- la technologie de l'information.
ITIL ne s'attaque qu'aux processus d'entreprise, et encore à seulement deux en détail : la production des services et le support aux services. Première question : peut-on travailler sur les processus indépendamment de l'organisation en place :
- de sa culture (a-t-on l’habitude de travailler avec la sous-traitance ou est-on adepte du « faisons tout nous même », a-t-on une culture du secret ou au contraire de la transparence, ). Ceci a bien évidemment un impact sur les relations clients / fournisseurs mises en avant par ITIL (dans un contexte de secret, on va chercher à minimiser l’échange d’information entre clients et fournisseurs par exemple, ce qui en soit est un frein à l’accomplissement de la production des services).
- de ses contraintes historiques ou sociales (par exemple, dans certaines entreprises, des choix d’architecture technique sont faits pour des raisons syndicales liées à des relations sociales) ?
Ces exemples ne sont pas exhaustifs et illustrent le fait qu’une analyse en terme de processus n’est pas forcément le premier point à traiter. Quels sont les critères qui permettraient d’identifier les priorités ?
Même dans le cas où l’on pourrait s’abstraire des contraintes existantes, comment décliner une réflexion sur les processus en terme de livrables et de normes et standard devant découler sur la mise en place d’une organisation et l'utilisation d'outils de production ? Comment une organisation peut-elle avoir connaissance et se fondre harmonieusement dans un découpage de l’entreprise en processus ? Quels sont les outils de management qui lient les processus aux hommes ? Quels sont les outils de gouvernance qui remontent les résultats et permettent de qualifier le service produit en regard de ce qui était initialement prévu ?
Enfin, ITIL suppose implicitement qu'une entreprise n'a qu'un type de découpage en processus or on constate, particulièrement avec les grands groupes ou les GIE, que toute l'entreprise ne vit pas au même rythme (par exemple, la tenue des comptes bancaires du client lambda n'a rien à voir en terme de rythme de vie et d’enjeux financiers avec l'asset management).
ITIL, en tant que catalogue de bonnes pratiques, est loin d’être une réflexion théorique scientifiquement limpide. Elle laisse encore aujourd’hui beaucoup de place à l’intuition et au savoir-faire des consultants des DSI.
12 octobre 2006
Swanson's unwritten rule of management n°2 : "il est plus facile de s'engager que de se dégager"
Les DSI travaillent beaucoup en mode projet, ce qui est très bon pour la motivation des équipes. Hélas, même si c'est inévitable, tous
les projets n'aboutissent pas, soit qu'ils ait été mal budgétisés, mal conduits, mal qualifiés ou qu'ils ne correspondent plus aux objectifs
prioritaires assignés à la DSI.
Or, l'expérience montre que les informaticiens sont généralement immatures lorsqu'il s'agit de prévoir et de communiquer sur un projet en train d'échouer. Pourtant, on sait tout à fait faire des analyses de risques et des corrélations avec des remontés d'alertes. On sait également voir qu'un service produit n'est pas, ou ne sera pas à la hauteur du service initialement demandé.
Pourquoi alors le flux d'information est-il défaillant ?
Sans doute en partie parce que les informaticiens ne renoncent jamais à l'espoir "d'y arriver" et que l'informatique permet généralement d'obtenir un "truc qui marche". Hélas, le "truc qui marche" n'a pas grand chose avec un service informatique à rendre. La mauvaise perception du service à rendre au profit d'une perception exagérée de l'importance de la technique ne favorise pas la remontée d'alertes auprès du middle management.
Le middle management est lui généralement focalisé sur le budget et les délais. Il a donc toutes les chances de communiquer sur un problème de dépassement de budget ou de délai, mais n'anticipera pas l'échec en terme d'impossibilité de rendre le service attendu. Il m'est arrivé une fois d'avoir à faire une remontée d'alertes sur un choix d'architecture erroné. Bien qu'ayant décrit les incidents induits, il s'est avéré impossible de rendre concret le problème avant qu'il ne se produise (probabilité n'est pas réalité). Il ne restait plus qu'une solution : diminuer préventivement le risque et mettre en attente les solutions résolvant le problème (qui se produisit effectivement deux fois avant la décision d'abandonner définitivement "le truc qui marche"). Ici, le soucis vient de l'extrême difficulté de traduire une analyse de risques informatiques en une analyse de risques métiers ; le passage maîtrise d'ouvrage / maîtrise d'oeuvre est habituellement difficile, la remontée inverse s'avère "acrobatique".
Enfin, dernier maillon, le DSI lui-même dont l'avis compte finalement relativement peu devant les injonctions métiers qui présupposent toujours que tout est possible. L'exemple de la bulle internet est significative de cette difficulté : avec le e-commerce, la DSI devenait centre de profit, producteur du service mais aussi premier utilisateur métier de ce service (le service commercial étant remplacé de fait par la technologie internet). Or, combien de DSI ont expliqué qu'avec cette technologie, ils se plaçaient en concurrence directe avec le service commercial en place (risque métier "structurel"), combien ont remonté l'inadaptation du produit fourni avec l'univers spécifique internet, combien ont remonté l'immaturité des solutions ?
Au final, tous les acteurs de la DSI ont effectivement beaucoup de facilité à s'engager (ou être engagé) dans un projet, mais finalement peu ont réellement la possibilité de peser sur la décision d'un désengagement nécessaire.
Or, l'expérience montre que les informaticiens sont généralement immatures lorsqu'il s'agit de prévoir et de communiquer sur un projet en train d'échouer. Pourtant, on sait tout à fait faire des analyses de risques et des corrélations avec des remontés d'alertes. On sait également voir qu'un service produit n'est pas, ou ne sera pas à la hauteur du service initialement demandé.
Pourquoi alors le flux d'information est-il défaillant ?
Sans doute en partie parce que les informaticiens ne renoncent jamais à l'espoir "d'y arriver" et que l'informatique permet généralement d'obtenir un "truc qui marche". Hélas, le "truc qui marche" n'a pas grand chose avec un service informatique à rendre. La mauvaise perception du service à rendre au profit d'une perception exagérée de l'importance de la technique ne favorise pas la remontée d'alertes auprès du middle management.
Le middle management est lui généralement focalisé sur le budget et les délais. Il a donc toutes les chances de communiquer sur un problème de dépassement de budget ou de délai, mais n'anticipera pas l'échec en terme d'impossibilité de rendre le service attendu. Il m'est arrivé une fois d'avoir à faire une remontée d'alertes sur un choix d'architecture erroné. Bien qu'ayant décrit les incidents induits, il s'est avéré impossible de rendre concret le problème avant qu'il ne se produise (probabilité n'est pas réalité). Il ne restait plus qu'une solution : diminuer préventivement le risque et mettre en attente les solutions résolvant le problème (qui se produisit effectivement deux fois avant la décision d'abandonner définitivement "le truc qui marche"). Ici, le soucis vient de l'extrême difficulté de traduire une analyse de risques informatiques en une analyse de risques métiers ; le passage maîtrise d'ouvrage / maîtrise d'oeuvre est habituellement difficile, la remontée inverse s'avère "acrobatique".
Enfin, dernier maillon, le DSI lui-même dont l'avis compte finalement relativement peu devant les injonctions métiers qui présupposent toujours que tout est possible. L'exemple de la bulle internet est significative de cette difficulté : avec le e-commerce, la DSI devenait centre de profit, producteur du service mais aussi premier utilisateur métier de ce service (le service commercial étant remplacé de fait par la technologie internet). Or, combien de DSI ont expliqué qu'avec cette technologie, ils se plaçaient en concurrence directe avec le service commercial en place (risque métier "structurel"), combien ont remonté l'inadaptation du produit fourni avec l'univers spécifique internet, combien ont remonté l'immaturité des solutions ?
Au final, tous les acteurs de la DSI ont effectivement beaucoup de facilité à s'engager (ou être engagé) dans un projet, mais finalement peu ont réellement la possibilité de peser sur la décision d'un désengagement nécessaire.
12 septembre 2006
Retour sur la dernière décennie
Cela va bientôt faire 10 ans que je fais de la prestation et du consulting. Un bail !
En 10 ans, j'ai vécu un cycle économique pour l'informatique, une vraie révolution et un paquet de modes aussitôt nées, aussitôt oubliées.
Le cycle économique a démarré vers 1997 avec un réveil de la demande en services informatiques. Cette hausse fut soutenue l'année suivante par la préparation aux échanges inter-bancaires en euro au 1er janvier 99, puis dans la foulée, par le passage à l'an 2000. Ces deux événements ont eu une conséquence non négligeable : pour la première fois dans des domaines non vitaux, un projet d'envergure aboutissait à une livraison correcte du service à la date fixée. Ce résultat favorable et les investissements qui avaient été consentis préparèrent le terrain à la révolution du n-tiers sur technologie internet. Un climat favorable attira les investissements, les technologies internets (n-tiers, http, serveurs d'application web, java) arrivèrent à un état proche de la maturité, ce qui suffit à convaincre les maîtrises d'ouvrage de se lancer dans la révolution internet.
La révolution eut bien lieu, elle permit de montrer la réalité de la faisabilité technologique, mais elle oublia un élément sur son passage : les applications métiers tardèrent trop, personne ne sachant trop comment faire du business avec ce nouvel outil. La bulle financière éclata, aidée qui plus est par les circonstances mondiales : trop vite convaincu, trop vite déçu.
Quelques années plus tard, qu'en reste-t-il ? Finalement, le succès technologique a rencontré ses besoins métiers, et au passage, l'univers informatique de 1997 s'est profondément modifié : à son tour, l'informatique connaît une concentration industrielle rapide et forte, au point que les petits acteurs ne semblent plus avoir un avenir radieux devant eux : fini le modèle de la startup née au fond du garage, le marché veut d'abord sourire aux poids lourds tels Microsoft, Oracle ou Cap Gemini. L'informatique devient industrielle, et il ne semble plus lui manquer qu'une réflexion méthodologique applicable pour y parvenir vraiment.
En 10 ans, j'ai vécu un cycle économique pour l'informatique, une vraie révolution et un paquet de modes aussitôt nées, aussitôt oubliées.
Le cycle économique a démarré vers 1997 avec un réveil de la demande en services informatiques. Cette hausse fut soutenue l'année suivante par la préparation aux échanges inter-bancaires en euro au 1er janvier 99, puis dans la foulée, par le passage à l'an 2000. Ces deux événements ont eu une conséquence non négligeable : pour la première fois dans des domaines non vitaux, un projet d'envergure aboutissait à une livraison correcte du service à la date fixée. Ce résultat favorable et les investissements qui avaient été consentis préparèrent le terrain à la révolution du n-tiers sur technologie internet. Un climat favorable attira les investissements, les technologies internets (n-tiers, http, serveurs d'application web, java) arrivèrent à un état proche de la maturité, ce qui suffit à convaincre les maîtrises d'ouvrage de se lancer dans la révolution internet.
La révolution eut bien lieu, elle permit de montrer la réalité de la faisabilité technologique, mais elle oublia un élément sur son passage : les applications métiers tardèrent trop, personne ne sachant trop comment faire du business avec ce nouvel outil. La bulle financière éclata, aidée qui plus est par les circonstances mondiales : trop vite convaincu, trop vite déçu.
Quelques années plus tard, qu'en reste-t-il ? Finalement, le succès technologique a rencontré ses besoins métiers, et au passage, l'univers informatique de 1997 s'est profondément modifié : à son tour, l'informatique connaît une concentration industrielle rapide et forte, au point que les petits acteurs ne semblent plus avoir un avenir radieux devant eux : fini le modèle de la startup née au fond du garage, le marché veut d'abord sourire aux poids lourds tels Microsoft, Oracle ou Cap Gemini. L'informatique devient industrielle, et il ne semble plus lui manquer qu'une réflexion méthodologique applicable pour y parvenir vraiment.
22 juillet 2006
Les blogs peuvent-ils être utiles pour le management de la DSI ?
Il y a un peu plus d'un an, je me suis mis au blog (j'en ai créé deux et j'interviens sur plusieurs) avec à l'origine deux idées en tête
:
- savoir comment cela marche
- savoir ce que l'on peut en faire professionnellement, comme outil de management ou de direction de projet.
Pour le "comment cela marche", c'est techniquement à la portée d'un ingénieur système standard pour l'infrastructure, et pour la gestion courante des posts, ce n'est guère plus compliqué qu'un traitement de texte classique. Pas d'obstacles techniques donc.
Professionnellement, les blogs libèrent la parole d'acteurs qui sont habituellement peu à l'aise au sein des réunions classiques : ils peuvent être vraiment utiles pour enrichir la réflexion et la maturation d'un projet. Ensuite, n'étant ni vraiment temps réel, ni décalés dans le temps, ils permettent à la fois de réagir rapidement tout en se donnant la possibilité de réflexion. Ils obligent également à être synthétiques (les longues argumentations sont rarement lues et leurs auteurs passent rapidement pour des raseurs pédants). Ils permettent également une traçabilité indiscutable et un excellent suivi de l'historique.
Pourtant, ils ne sont que très rarement utilisés comme moyens de management et surtout, un blog managérial me semble receler un vrai danger : il expose les acteurs sous un jour très différent de la hiérarchie en place. Un obscure collaborateur que personne ne remarque, peut parfaitement, par sa maîtrise de l'outil et la pertinence de ses propos, prendre le leadership du blog. Situation difficile...
En conclusion, j'ai pu constaté que le blog a vraiment une utilité pour l'échange et la diffusion de connaissance au sein d'un groupe, mais que pour être utilisé, le manager du groupe doit parfaitement maîtriser son propos et en fait, être un vrai manager. Mais cela est un autre propos...
- savoir comment cela marche
- savoir ce que l'on peut en faire professionnellement, comme outil de management ou de direction de projet.
Pour le "comment cela marche", c'est techniquement à la portée d'un ingénieur système standard pour l'infrastructure, et pour la gestion courante des posts, ce n'est guère plus compliqué qu'un traitement de texte classique. Pas d'obstacles techniques donc.
Professionnellement, les blogs libèrent la parole d'acteurs qui sont habituellement peu à l'aise au sein des réunions classiques : ils peuvent être vraiment utiles pour enrichir la réflexion et la maturation d'un projet. Ensuite, n'étant ni vraiment temps réel, ni décalés dans le temps, ils permettent à la fois de réagir rapidement tout en se donnant la possibilité de réflexion. Ils obligent également à être synthétiques (les longues argumentations sont rarement lues et leurs auteurs passent rapidement pour des raseurs pédants). Ils permettent également une traçabilité indiscutable et un excellent suivi de l'historique.
Pourtant, ils ne sont que très rarement utilisés comme moyens de management et surtout, un blog managérial me semble receler un vrai danger : il expose les acteurs sous un jour très différent de la hiérarchie en place. Un obscure collaborateur que personne ne remarque, peut parfaitement, par sa maîtrise de l'outil et la pertinence de ses propos, prendre le leadership du blog. Situation difficile...
En conclusion, j'ai pu constaté que le blog a vraiment une utilité pour l'échange et la diffusion de connaissance au sein d'un groupe, mais que pour être utilisé, le manager du groupe doit parfaitement maîtriser son propos et en fait, être un vrai manager. Mais cela est un autre propos...
10 mai 2006
Configurons, configurons !
Je travaille actuellement dans un contexte de fusion d'entreprises, moment idéal pour partir du bon pied, et en particulier se donner quelques bases
méthodologiques.
Fort de ce constat, la fusion se fait avec une bonne dose d'ITIL, au niveau du top et du middle management au moins (au niveau des ingénieurs et techniciens, ITIL est surtout un concept à la mode).
En plus de l'aspect méthodologiques, deux éléments techniques vont bientôt arriver : le logiciel de gestion de ticket d'incidents (concept qui existe depuis bien longtemps), et la base de données de gestion des configurations (qui aurait pu continuer à s'appeler gestion de parc informatique, à quelques nuances près).
L'idée de base de données reflétant précisément l'état des machines et des composants logiciels est très pertinente, mais la structure classique de la base de données me semble, à l'usage, très inadaptée.
Le problème principal est le rafraîchissement de la base : comment être sûr que ce qui est déclaré correspond bien à quelque chose d'installé et d'utilisé, et comment dans le cycle de mise en production ou de gestion des changements, va-t-on pouvoir maintenir une traçabilité suffisante entre les services internes de l'entreprises et les intervenants extérieurs (dont les éditeurs) ?
La seule solution réaliste au premier problème, est de doter chaque composant d'un service standard de production qui remonte dynamiquement à la CMDB sa configuration et sa date de dernière utilisation (a minima). Cette proactivité du SI doit être complétée par un contrôle automatique de la CMDB qui cherchera à détecter une absence soudaine de remontée de configuration.
Ce service standard sur la remontée de configuration est relativement facile à mettre au catalogue des services de production.
L'autre aspect (traçabilité des changements) est plus un problème d'organisation et de processus que de technique. Techniquement, il ne nécessite que la création d'un identifiant unique lié à l’existence d'une instance de composant, mais dans la pratique, il est extrêmement difficile d'imposer à chaque intervenant l'utilisation de cet identifiant, en particulier dès que le traitement part chez un éditeur par exemple, ce qui est le cas par exemple des clés logicielles qui pour une même instance de composant, peuvent évoluer et service à plusieurs projets internes.
Deux choses sont donc à retenir : c'est le SI qui détient la vérité de ce qui tourne, pas la CMDB, et la traçabilité de l'évolution des configurations est d'abord une question d'organisation.
Fort de ce constat, la fusion se fait avec une bonne dose d'ITIL, au niveau du top et du middle management au moins (au niveau des ingénieurs et techniciens, ITIL est surtout un concept à la mode).
En plus de l'aspect méthodologiques, deux éléments techniques vont bientôt arriver : le logiciel de gestion de ticket d'incidents (concept qui existe depuis bien longtemps), et la base de données de gestion des configurations (qui aurait pu continuer à s'appeler gestion de parc informatique, à quelques nuances près).
L'idée de base de données reflétant précisément l'état des machines et des composants logiciels est très pertinente, mais la structure classique de la base de données me semble, à l'usage, très inadaptée.
Le problème principal est le rafraîchissement de la base : comment être sûr que ce qui est déclaré correspond bien à quelque chose d'installé et d'utilisé, et comment dans le cycle de mise en production ou de gestion des changements, va-t-on pouvoir maintenir une traçabilité suffisante entre les services internes de l'entreprises et les intervenants extérieurs (dont les éditeurs) ?
La seule solution réaliste au premier problème, est de doter chaque composant d'un service standard de production qui remonte dynamiquement à la CMDB sa configuration et sa date de dernière utilisation (a minima). Cette proactivité du SI doit être complétée par un contrôle automatique de la CMDB qui cherchera à détecter une absence soudaine de remontée de configuration.
Ce service standard sur la remontée de configuration est relativement facile à mettre au catalogue des services de production.
L'autre aspect (traçabilité des changements) est plus un problème d'organisation et de processus que de technique. Techniquement, il ne nécessite que la création d'un identifiant unique lié à l’existence d'une instance de composant, mais dans la pratique, il est extrêmement difficile d'imposer à chaque intervenant l'utilisation de cet identifiant, en particulier dès que le traitement part chez un éditeur par exemple, ce qui est le cas par exemple des clés logicielles qui pour une même instance de composant, peuvent évoluer et service à plusieurs projets internes.
Deux choses sont donc à retenir : c'est le SI qui détient la vérité de ce qui tourne, pas la CMDB, et la traçabilité de l'évolution des configurations est d'abord une question d'organisation.
22 février 2006
Les théories qui pédalent dans le vide
Comme je suis consultant dans une petite société, mon travail ne se cantonne pas à une collection d'audits / conseils mais je suis également
amené régulièrement à assister quelques responsables d'équipe en perdition, voire à replonger dans la technique, me rappelant ainsi de vieux
souvenirs d'ingénieur.
L'avantage d'une telle situation est de pouvoir balayer tout le spectre de l'organisation d'une entreprise, du marmiton au chef étoilé.
Et dans toutes ces sociétés, je suis amené à faire le même constat : il existe une coupure nette et flagrante entre la vision stratégique et les modèles utilisés au niveau du DSI et le travail des équipes techniques.
Du côté DSI, il arrive toujours un moment où la réflexion butte sur une espèce de grand vide et l'on s'attend invariablement à attendre que le chef de projet de service lâche un "et comment on met cela en oeuvre maintenant ?".
Et invariablement, on se met également à attendre que les responsables des équipes concernées répondent en écho "mais qu'est-ce qu'il raconte ? Qu'est-ce qu'il veut ?".
Le résultat est garanti : notre penseur se réfugiera dans l'abstraction et nos techniciens dans la technique, secourus en cela par l'urgence du moment. Au mieux, la situation en restera sur un statut quo non satisfaisant, au pire ce sera la crise.
Et à mon tour, j'ai envie de crier à tout ce petit monde que décliner une orientation stratégique en modèle procédural, lui même lié clairement et simplement à une organisation, des objectifs d'équipe, des outils et des éléments de gouvernance est simple, sinon simplissime ! Il ne manque plus alors qu'une touche pertinente de management et les neurones du cerveau droit de l'entreprise seront en mesure d'échanger avec ceux du cerveau gauche !
Je n'aurai qu'un conseil : soyez humble dans la mise en oeuvre progressive de la stratégie, opiniâtre et clair dans votre tête ! Tout sera alors beaucoup plus facile.
Quant aux théories et méthodologies du moment, prenez-les pour ce qu'elles sont : une bonne base culturelle, sans plus.
L'avantage d'une telle situation est de pouvoir balayer tout le spectre de l'organisation d'une entreprise, du marmiton au chef étoilé.
Et dans toutes ces sociétés, je suis amené à faire le même constat : il existe une coupure nette et flagrante entre la vision stratégique et les modèles utilisés au niveau du DSI et le travail des équipes techniques.
Du côté DSI, il arrive toujours un moment où la réflexion butte sur une espèce de grand vide et l'on s'attend invariablement à attendre que le chef de projet de service lâche un "et comment on met cela en oeuvre maintenant ?".
Et invariablement, on se met également à attendre que les responsables des équipes concernées répondent en écho "mais qu'est-ce qu'il raconte ? Qu'est-ce qu'il veut ?".
Le résultat est garanti : notre penseur se réfugiera dans l'abstraction et nos techniciens dans la technique, secourus en cela par l'urgence du moment. Au mieux, la situation en restera sur un statut quo non satisfaisant, au pire ce sera la crise.
Et à mon tour, j'ai envie de crier à tout ce petit monde que décliner une orientation stratégique en modèle procédural, lui même lié clairement et simplement à une organisation, des objectifs d'équipe, des outils et des éléments de gouvernance est simple, sinon simplissime ! Il ne manque plus alors qu'une touche pertinente de management et les neurones du cerveau droit de l'entreprise seront en mesure d'échanger avec ceux du cerveau gauche !
Je n'aurai qu'un conseil : soyez humble dans la mise en oeuvre progressive de la stratégie, opiniâtre et clair dans votre tête ! Tout sera alors beaucoup plus facile.
Quant aux théories et méthodologies du moment, prenez-les pour ce qu'elles sont : une bonne base culturelle, sans plus.
13 janvier 2006
Processus, le gros mot du jour
J'ai été étonné, à de nombreuses reprises, par la réaction de directeurs alors que j'essayais d'aborder leur problème par
le biais des processus.
La réaction est presque toujours la même : la personne prend un peu de recul avec un air étonné, presque effrayé, et me gratifie d'un "non, non, on ne va pas se lancer la-dedans". Eh oui, forcément, il y a déjà dans l'entreprise quelqu'un de savant qui s'occupe de ces choses là !
Voila qui est fort dommage, et pour plusieurs raisons.
D'abord parce que le "monsieur fort savant", ne s'occupe certainement pas des processus touchant au métier de l'informatique, mais plutôt des processus métiers de toute l'entreprise. Le champ est suffisamment large pour qu'il n'aille probablement jamais voir en détail les processus DSI.
Dommage ensuite, car toutes les méthodes qui s'attaquent un tant soit peu aux problèmes de la DSI et à la gouvernance (CobIT, ITIL, ABM, ...) utilisent comme support les processus, peu ou prou.
Dommage enfin, car en restant à un niveau relativement global, on se dote d'un outil d'analyse qui reste compréhensible même pour le béotien, qui permet de mettre en correspondance les objectifs métiers de l'entreprise avec ceux de la DSI, de rendre cohérente l'organisation vis à vis des objectifs de la DSI, de se doter d'une métrologie sur des objectifs définis, et au final, de donner un sens au mot gouvernance.
Excusez du peu !
La réaction est presque toujours la même : la personne prend un peu de recul avec un air étonné, presque effrayé, et me gratifie d'un "non, non, on ne va pas se lancer la-dedans". Eh oui, forcément, il y a déjà dans l'entreprise quelqu'un de savant qui s'occupe de ces choses là !
Voila qui est fort dommage, et pour plusieurs raisons.
D'abord parce que le "monsieur fort savant", ne s'occupe certainement pas des processus touchant au métier de l'informatique, mais plutôt des processus métiers de toute l'entreprise. Le champ est suffisamment large pour qu'il n'aille probablement jamais voir en détail les processus DSI.
Dommage ensuite, car toutes les méthodes qui s'attaquent un tant soit peu aux problèmes de la DSI et à la gouvernance (CobIT, ITIL, ABM, ...) utilisent comme support les processus, peu ou prou.
Dommage enfin, car en restant à un niveau relativement global, on se dote d'un outil d'analyse qui reste compréhensible même pour le béotien, qui permet de mettre en correspondance les objectifs métiers de l'entreprise avec ceux de la DSI, de rendre cohérente l'organisation vis à vis des objectifs de la DSI, de se doter d'une métrologie sur des objectifs définis, et au final, de donner un sens au mot gouvernance.
Excusez du peu !
6 décembre 2005
La gestion aléatoire du changement
L'informatique est friande de changement ; l'humain y est réfractaire par nature.
Petite ou grande entreprise, je n'en connais pas une seule qui n'ait pas un projet informatique sur le feu, même parmi celles dont le métier est par nature cyclique et stable, comme l'immobilier locatif par exemple. Les motivations sont diverses, tant internes qu'externes.
Côté externe, on trouve l'incroyable capacité de conviction du service marketing des éditeurs qui réussissent à convaincre, ou à contraindre, le plus conservateur des responsables informatiques. Qu'il s'agisse d'opérations de séduction sur les fonctionnalités réelles ou supposées du nouveau produit, ou la menace d'un arrêt effectif du support de votre logiciel (support que vous continuerez à payer mais qui répondra à la moindre de vos questions par un "il faut passer les mises à jour monsieur !"), on ne peux résister longtemps à remplacer l'actuelle version de votre application (que vous aviez eu tant de mal à stabiliser) par une nouvelle version pleine de promesses et de menaces... L'informatique est ainsi : une fuite en avant technologique qui fait payer les progrès, réels, au prix des désagréments des utilisateurs.
Mais les éditeurs ne sont pas seuls en cause, loin de là. Les informaticiens sont des technophiles invétérés, toujours inquiets de ne pas être à la pointe de leur technologie fétiche. Je dis bien "leur", car cette technophilie est très restrictive et il est a priori hors de question de faire adopter la techonologie du voisin. Imposer un tel changement revient à entrer dans une phase de crise interne que peu de managers sont prêts à gérer. Après tout, quel que soit le choix technique, on finit toujours par avoir un résultat à peu près acceptable (c'est à dire que l'utilisateur finit par se faire une raison...). Alors à quoi bon ?
A quoi bon ? Et bien pour le DSI, cela est bon à mettre en conformité les outils informatiques avec les moyens humains, les processus d'entreprise et au final, les orientations stratégiques de celles-ci. L'outil et l'organisation n'ont de sens que parce qu'ils permettent de produire le service informatique nécessaire aux métiers de l'entreprise, alors oui cela est bon. Face à cette instabilité technique et à ces réticences quasi systématiques, on rencontre régulièrement trois options :
Petite ou grande entreprise, je n'en connais pas une seule qui n'ait pas un projet informatique sur le feu, même parmi celles dont le métier est par nature cyclique et stable, comme l'immobilier locatif par exemple. Les motivations sont diverses, tant internes qu'externes.
Côté externe, on trouve l'incroyable capacité de conviction du service marketing des éditeurs qui réussissent à convaincre, ou à contraindre, le plus conservateur des responsables informatiques. Qu'il s'agisse d'opérations de séduction sur les fonctionnalités réelles ou supposées du nouveau produit, ou la menace d'un arrêt effectif du support de votre logiciel (support que vous continuerez à payer mais qui répondra à la moindre de vos questions par un "il faut passer les mises à jour monsieur !"), on ne peux résister longtemps à remplacer l'actuelle version de votre application (que vous aviez eu tant de mal à stabiliser) par une nouvelle version pleine de promesses et de menaces... L'informatique est ainsi : une fuite en avant technologique qui fait payer les progrès, réels, au prix des désagréments des utilisateurs.
Mais les éditeurs ne sont pas seuls en cause, loin de là. Les informaticiens sont des technophiles invétérés, toujours inquiets de ne pas être à la pointe de leur technologie fétiche. Je dis bien "leur", car cette technophilie est très restrictive et il est a priori hors de question de faire adopter la techonologie du voisin. Imposer un tel changement revient à entrer dans une phase de crise interne que peu de managers sont prêts à gérer. Après tout, quel que soit le choix technique, on finit toujours par avoir un résultat à peu près acceptable (c'est à dire que l'utilisateur finit par se faire une raison...). Alors à quoi bon ?
A quoi bon ? Et bien pour le DSI, cela est bon à mettre en conformité les outils informatiques avec les moyens humains, les processus d'entreprise et au final, les orientations stratégiques de celles-ci. L'outil et l'organisation n'ont de sens que parce qu'ils permettent de produire le service informatique nécessaire aux métiers de l'entreprise, alors oui cela est bon. Face à cette instabilité technique et à ces réticences quasi systématiques, on rencontre régulièrement trois options :
- se contenter de ne gérer que les dysfonctionnements les plus handicapants et se contenter d'un service rendu très moyen
- se lancer cycliquement dans un jeu de chaises musicales au niveau du middle management rendu responsable de ces dysfonctionnements, en espérant qu'il émerge quelque chose de constructif du bouleversement des relations intra-entreprises (espoir souvent largement déçu puisque, comme le dit l'adage "plus cela change, moins cela change")
- se lancer dans un dirigisme normatif et technique au risque de traumatiser des équipes qui, n'adhérant pas aux choix, vont sans doute entrer en résistance passive (a minima), se démobiliser voire déserter.
12 novembre 2005
Année charnière ?
La pyramide des âges étant ce qu'elle est, il n'aura échappé à personne que 2006 marquera une très forte montée en
puissance en ce qui concerne les départs en retraite. Le phénomène de ces départs a longtemps été marginal en informatique, domaine industriel
créé de toute pièce dans les années 70 et caractérisé par un fort taux de personnel jeune et qualifié.
Les directions informatiques créés un peu plus tard pour essayer de rationnaliser ce secteur aussi dynamique qu'instable, vont être, encore plus que l'ingénierie ou le middle management, touchées par ces départs en retraite ; en effet, le poste de DI ou de DSI est le plus souvent l'aboutissement d'une carrière, et jusqu'à présent, il était rare d'en rencontrer un qui ait moins de 40 ans.
Ce renouvellement va donc non seulement rajeunir la population, mais est aussi très probablement le bon moment pour achever la mutation industrielle du secteur, encore très marqué par le charisme de personnages autodidactes haut en couleur, mais finalement très rarement de "vrais" informaticiens, c'est à dire formés spécifiquement à cela dans des écoles d'ingénieur ou à l'université.
L'un des éternels problèmes du recrutement d'un DSI est de choisir entre un homme du "métier de l'entreprise" et un homme du "métier de l'informatique". Ce choix était jusqu'à présent un peu biaisé dans le sens ou les vrais hommes du métier de l'informatique étaient finalement très rares. Mais le DSI étant un véritable pivot pour son entreprise, cette question est très importante et conditionne en grande partie le succès de sa future mission. Or, d'expérience, il s'avère plus aisé pour un informaticien de formation ayant été préparé correctement au management et au monde de l'entreprise, de se glisser dans les fonctions d'un DSI, que pour un non informaticien de se faire comprendre et respecter par des troupes promptes à défendre leur "art". Qui plus est, le management de caporal est généralement une catastrophe dans cette population.
L'arrivée de ces futurs "jeunes" DSI sera l'occasion de finir la mutation de l'informatique qui a commencé, pour les éditeurs et les SSII, avec la révolution internet mais qui tarde encore à entrer dans les sociétés utilisatrices. J'en veux pour preuve ces successions interminables de modes qui nous vendent à répétition nouvelles méthodologies, technologies révolutionnaires et chantent les louanges du services à rendre au client. Dans un secteur mature (comme l'automobile par exemple), on a depuis longtemps dépassé ces modes parce cela est effectivement entré dans la réalité des entreprises.
On peut donc estimer sans grand risque de se tromper, que les nouveaux DSI seront donc des informaticiens de formation, capables par leur expérience de mobiliser effectivement et rationnellement leur département au service du métier de leur entreprises, capable de transformer leurs équipes d'artisans (au bon sens du terme) en professionnels tout aussi compétents, mais tournés vers l'avenir tracé par l'entreprise au lieu de leur habituel nombrilisme technophile.
Les directions informatiques créés un peu plus tard pour essayer de rationnaliser ce secteur aussi dynamique qu'instable, vont être, encore plus que l'ingénierie ou le middle management, touchées par ces départs en retraite ; en effet, le poste de DI ou de DSI est le plus souvent l'aboutissement d'une carrière, et jusqu'à présent, il était rare d'en rencontrer un qui ait moins de 40 ans.
Ce renouvellement va donc non seulement rajeunir la population, mais est aussi très probablement le bon moment pour achever la mutation industrielle du secteur, encore très marqué par le charisme de personnages autodidactes haut en couleur, mais finalement très rarement de "vrais" informaticiens, c'est à dire formés spécifiquement à cela dans des écoles d'ingénieur ou à l'université.
L'un des éternels problèmes du recrutement d'un DSI est de choisir entre un homme du "métier de l'entreprise" et un homme du "métier de l'informatique". Ce choix était jusqu'à présent un peu biaisé dans le sens ou les vrais hommes du métier de l'informatique étaient finalement très rares. Mais le DSI étant un véritable pivot pour son entreprise, cette question est très importante et conditionne en grande partie le succès de sa future mission. Or, d'expérience, il s'avère plus aisé pour un informaticien de formation ayant été préparé correctement au management et au monde de l'entreprise, de se glisser dans les fonctions d'un DSI, que pour un non informaticien de se faire comprendre et respecter par des troupes promptes à défendre leur "art". Qui plus est, le management de caporal est généralement une catastrophe dans cette population.
L'arrivée de ces futurs "jeunes" DSI sera l'occasion de finir la mutation de l'informatique qui a commencé, pour les éditeurs et les SSII, avec la révolution internet mais qui tarde encore à entrer dans les sociétés utilisatrices. J'en veux pour preuve ces successions interminables de modes qui nous vendent à répétition nouvelles méthodologies, technologies révolutionnaires et chantent les louanges du services à rendre au client. Dans un secteur mature (comme l'automobile par exemple), on a depuis longtemps dépassé ces modes parce cela est effectivement entré dans la réalité des entreprises.
On peut donc estimer sans grand risque de se tromper, que les nouveaux DSI seront donc des informaticiens de formation, capables par leur expérience de mobiliser effectivement et rationnellement leur département au service du métier de leur entreprises, capable de transformer leurs équipes d'artisans (au bon sens du terme) en professionnels tout aussi compétents, mais tournés vers l'avenir tracé par l'entreprise au lieu de leur habituel nombrilisme technophile.
26 octobre 2005
La gouvernance, une nécessité, presque une réalité
La gouvernance ne serait-elle que le concept marketing du moment ?
Oui si l'on en juge par la pile de papier produite sur la question, mais non s'il l'on examine la question par le biais des besoins des entreprises en général et des DSI en particulier.
Examinons les besoins tout d'abord. Le plus évident prend sans doute la forme du directeur financier qui vient voir le DSI pour lui répéter avec obstination que "l'informatique ça coûte trop cher". Or s'il est à peu près facile de dire combien cela coûte effectivement, il est beaucoup plus complexe de dire pourquoi cela coûte autant et plus encore si l'argent utilisé est bien utilisé. Un DSI se retrouve trop souvent à justifier son budget par ses investissements en matériel/logiciel ou ses coûts de fonctionnement. Or dans les faits, on s'en moque ! Le seul argument qui vaille est le coût face au service rendu, ce qui renvoie à la définition de ce service (SLA) et, on y arrive, à une métrologie capable de savoir dans quel état est ce service en regard du SLA.
La définition du service et de la métrologie associée est également fondamentale dans la mise en oeuvre informatique de la stratégie de l'entreprise (deuxième pilier de la gouvernance). Si le DSI n'est pas en mesure de rattacher un service informatique clairement identifié à un projet d'entreprise, il lui est bien difficile là aussi, de justifier ou de prioriser l'affectation des crédits alloués.
Enfin, dernier pilier, l'adapation du système d'information devrait lui aussi toujours être la conséquence d'informations fournies par cette gouvernance. Or cette conséquence se résume encore trop souvent à une sirène d'alarme aussi tardive que désespérée : le SI est à genoux, il faut faire quelque chose ! Le quelque chose sera souvent lié au niveau d'alarme : de l'adaptation des outils techniques si ne n'est pas trop grave à la réorganisation voire le reengeniering si la DSI est dans un état désespéré.
La gouvernance est donc le résultat d'un triptyque : définition stratégique, métrologie et adaptions. Elle ne peut se mettre en place qu'avec une définition claire des objectifs de l'informatique en regard de ceux de l'entreprise, avec une normalisation associée à une déclinaison technique rigoureuse et enfin une définition claire des processus d'entreprise, décliné la aussi rigoureusement en une organisation dotée des outils pertinents.
Tout ceci semble une définition de bon sens et pourrait effectivement faire passer le bruit médiatique autour de la gouvernance comme une agitation très marketing si cette définition était largement mise en pratique dans les entreprises. Force est de constater qu'il reste du travail à faire.
Oui si l'on en juge par la pile de papier produite sur la question, mais non s'il l'on examine la question par le biais des besoins des entreprises en général et des DSI en particulier.
Examinons les besoins tout d'abord. Le plus évident prend sans doute la forme du directeur financier qui vient voir le DSI pour lui répéter avec obstination que "l'informatique ça coûte trop cher". Or s'il est à peu près facile de dire combien cela coûte effectivement, il est beaucoup plus complexe de dire pourquoi cela coûte autant et plus encore si l'argent utilisé est bien utilisé. Un DSI se retrouve trop souvent à justifier son budget par ses investissements en matériel/logiciel ou ses coûts de fonctionnement. Or dans les faits, on s'en moque ! Le seul argument qui vaille est le coût face au service rendu, ce qui renvoie à la définition de ce service (SLA) et, on y arrive, à une métrologie capable de savoir dans quel état est ce service en regard du SLA.
La définition du service et de la métrologie associée est également fondamentale dans la mise en oeuvre informatique de la stratégie de l'entreprise (deuxième pilier de la gouvernance). Si le DSI n'est pas en mesure de rattacher un service informatique clairement identifié à un projet d'entreprise, il lui est bien difficile là aussi, de justifier ou de prioriser l'affectation des crédits alloués.
Enfin, dernier pilier, l'adapation du système d'information devrait lui aussi toujours être la conséquence d'informations fournies par cette gouvernance. Or cette conséquence se résume encore trop souvent à une sirène d'alarme aussi tardive que désespérée : le SI est à genoux, il faut faire quelque chose ! Le quelque chose sera souvent lié au niveau d'alarme : de l'adaptation des outils techniques si ne n'est pas trop grave à la réorganisation voire le reengeniering si la DSI est dans un état désespéré.
La gouvernance est donc le résultat d'un triptyque : définition stratégique, métrologie et adaptions. Elle ne peut se mettre en place qu'avec une définition claire des objectifs de l'informatique en regard de ceux de l'entreprise, avec une normalisation associée à une déclinaison technique rigoureuse et enfin une définition claire des processus d'entreprise, décliné la aussi rigoureusement en une organisation dotée des outils pertinents.
Tout ceci semble une définition de bon sens et pourrait effectivement faire passer le bruit médiatique autour de la gouvernance comme une agitation très marketing si cette définition était largement mise en pratique dans les entreprises. Force est de constater qu'il reste du travail à faire.
21 juillet 2005
La DSI, une équation à trois variables
Mes activités m'amènent régulièrement à aborder les mêmes sujets au sein des DSI, mais avec des
périmètres variables. Or le périmètre d'action définit généralement l'optimum de ce qui peut être amélioré. Les
symptômes qui déclenchent mon intervention conditionnent très souvent ce périmètre : dysfonctionnement organisationnel, architecture technique instable,
service produit de qualité insuffisante.
Le problème de départ apparaît souvent comme un spaghetti s'agitant au dessus d'un plat dont la complexité semble inextricable. Une DSI, ce n'est cependant pas un plat de spaghetti, mais bien un ensemble cohérent composé de processus métiers avec des objectifs clairs, d'une organisation apte à réaliser ces objectifs et enfin des outils dédiés à chaque équipe dans le cadre de la réalisation de ces objectifs.
Oui, mais voila, par habitude, manque de vision à long terme ou contrainte de l'urgence, cette vision cartésienne relativement simple est mise de côté et l'on voit alors des équipes se donner des objectifs qui n'ont pas forcément grand chose à voir avec les processus (ce qui va se traduire par une perte de l'importance du métier de l'entreprise au profit du métier de l'informatique), ou encore des choix techniques faits en fonction des préférences du gourou du moment (ce qui va se traduire par une perte de gouvernance, une fragilisation de la mutualisation des compétences et, dans le pire des cas, l'impossibilité de produire le service demandé au profit d'un service supposé).
Avec le temps, ces dérives finissent par dérégler et fragiliser tous les éléments de la DSI qui rentre alors parfois dans une crise aiguë. Traiter un seul des aspects (processus, organisation ou technique) permet des améliorations mais n'arrive en aucun cas à assainir de façon durable la DSI. Il est alors de la responsabilité du directeur informatique d'aller au fond des choses et de réussir à conjuguer aspects méthodologiques (tel ITIL qui gèrent très bien les aspects processus / organisation) avec leur déclinaison technique, et ceci en phase avec les compétences disponibles et les objectifs métiers de l'entreprise.
Le DSI est donc un pilote qui dispose de manettes s'appelant processus, organisation et technologie et qui doit donner des garanties à tous les passagers de l'entreprise.
Le problème de départ apparaît souvent comme un spaghetti s'agitant au dessus d'un plat dont la complexité semble inextricable. Une DSI, ce n'est cependant pas un plat de spaghetti, mais bien un ensemble cohérent composé de processus métiers avec des objectifs clairs, d'une organisation apte à réaliser ces objectifs et enfin des outils dédiés à chaque équipe dans le cadre de la réalisation de ces objectifs.
Oui, mais voila, par habitude, manque de vision à long terme ou contrainte de l'urgence, cette vision cartésienne relativement simple est mise de côté et l'on voit alors des équipes se donner des objectifs qui n'ont pas forcément grand chose à voir avec les processus (ce qui va se traduire par une perte de l'importance du métier de l'entreprise au profit du métier de l'informatique), ou encore des choix techniques faits en fonction des préférences du gourou du moment (ce qui va se traduire par une perte de gouvernance, une fragilisation de la mutualisation des compétences et, dans le pire des cas, l'impossibilité de produire le service demandé au profit d'un service supposé).
Avec le temps, ces dérives finissent par dérégler et fragiliser tous les éléments de la DSI qui rentre alors parfois dans une crise aiguë. Traiter un seul des aspects (processus, organisation ou technique) permet des améliorations mais n'arrive en aucun cas à assainir de façon durable la DSI. Il est alors de la responsabilité du directeur informatique d'aller au fond des choses et de réussir à conjuguer aspects méthodologiques (tel ITIL qui gèrent très bien les aspects processus / organisation) avec leur déclinaison technique, et ceci en phase avec les compétences disponibles et les objectifs métiers de l'entreprise.
Le DSI est donc un pilote qui dispose de manettes s'appelant processus, organisation et technologie et qui doit donner des garanties à tous les passagers de l'entreprise.
21 juillet 2005
Idées reçues
Les informaticiens ont un vrai savoir-faire lorsqu'il s'agit de rendre mystérieux leur art et même de faire participer à ce mystère des
non-informaticiens qui y ont tout à y perdre.
Quel directeur ne s'est pas retrouvé un jour confronté aux explications détaillées des mérites comparés de l'architecture client/serveur et du 3-tiers, ou de la nécessité de financer la migration à la technologie qui allait enfin résoudre les déficiences récurrentes du service informatique demandé, détails à l'appui ?
Et dans de telles situation, le DSI est censé jouer le rôle de l'accrobate entre ses techniciens qui se désintéressent du métier de l'entreprise et des utilisateurs qui ont tout à gagner en se désinterressant des technologies utilisées dans le système d'information.
Mais voilà, à la différence de la comptabilité ou de l'alimentation électrique de l'entreprise, l'informatique fascine par sa capacité à générer des nouveautés à un rythme soutenu, par son marketing efficace, par son côté "tu passes par un vieux croûton si tu n'es pas au courant du dernier concept de neurotique injective logicielle".
Tout ceci est bien dommage car la technologie retenue, à de rares erreurs près, n'a qu'un poids marginal dans la qualité du service produit. Un peu de prudence, des conseils pertinents et la référence constante au service métier à produire et non à la technique suffisent à éviter de s'engager sur des impasses technologiques ; trop accaparés par le "bruit technologique", les DSI passent souvent à côté des véritables problèmes qui hypothèquent le bon fonctionnement du SI. La technique est secondaire, voici pour la première idée reçue.
Comment clarifier la situation ? D'abord en prenant du recul par rapport aux urgences apparentes (des incidents récurrents sur un élément mineur du SI ou un projet structurel qui "s'éternise" amènent souvent à monopoliser des moyens qui seraient plus utiles ailleurs). Un bon moyen pour prendre ce recul, et de d'auditer l'organisation, équipe par équipe, pour comprendre ce qui se passerait en cas d'absence totale (quel rôle occupe l'équipe au sein des processus d'entreprise, quels moyens lui sont nécessaires).
Que se passerait-il pour votre entreprise si la hotline client n'avait plus accès à ses informations, si vos pilotes d'exploitations n'étaient plus là pour déclencher les traitements batchs de la nuit ? Il y a fort à parier que dans un délai de quelques minutes, quelques heures au plus, l'impact sur le business de l'entreprise serait catastrophique. Pourtant, ce qui mobilise le plus d'énergie et de crédit, ce sont sans doute les projets en cours de développement, cœur culturellement noble du métier. Ici, l'absence des équipes nobles n'impacterait l'entreprise que plusieurs semaines ou mois plus tard, l'urgence n'est pas celle qui paraît...
Il est assez intéressant de constater, qu'en terme de service informatique rendu, ce sont les sans grades de la DSI qui tiennent le rôle principal. Voici pour une deuxième idée reçue.
Enfin, pour en finir provisoirement avec les idées reçues, pourquoi certains services rendus par le système d'information posent-ils systématiquement des problèmes alors même que l'on a affecté plus de personnels compétents et de nouveaux outils ? Il n'y a évidemment pas de réponses universellement applicables mais le constat le plus généralement fait est un dysfonctionnement structurel de la DSI : on affecte des tâches aux mauvais professionnels parce que le service à rendre n'est pas réellement sorti de sa phase projet (les études développements sont trop souvent en charge de tâches de production, ce qui non seulement n'est pas leur métier, mais plus encore que la logique de production est incompatible avec ce métier). Aucun service informatique ne peut être produit de façon stable et optimale par des équipes de développement.
Quel directeur ne s'est pas retrouvé un jour confronté aux explications détaillées des mérites comparés de l'architecture client/serveur et du 3-tiers, ou de la nécessité de financer la migration à la technologie qui allait enfin résoudre les déficiences récurrentes du service informatique demandé, détails à l'appui ?
Et dans de telles situation, le DSI est censé jouer le rôle de l'accrobate entre ses techniciens qui se désintéressent du métier de l'entreprise et des utilisateurs qui ont tout à gagner en se désinterressant des technologies utilisées dans le système d'information.
Mais voilà, à la différence de la comptabilité ou de l'alimentation électrique de l'entreprise, l'informatique fascine par sa capacité à générer des nouveautés à un rythme soutenu, par son marketing efficace, par son côté "tu passes par un vieux croûton si tu n'es pas au courant du dernier concept de neurotique injective logicielle".
Tout ceci est bien dommage car la technologie retenue, à de rares erreurs près, n'a qu'un poids marginal dans la qualité du service produit. Un peu de prudence, des conseils pertinents et la référence constante au service métier à produire et non à la technique suffisent à éviter de s'engager sur des impasses technologiques ; trop accaparés par le "bruit technologique", les DSI passent souvent à côté des véritables problèmes qui hypothèquent le bon fonctionnement du SI. La technique est secondaire, voici pour la première idée reçue.
Comment clarifier la situation ? D'abord en prenant du recul par rapport aux urgences apparentes (des incidents récurrents sur un élément mineur du SI ou un projet structurel qui "s'éternise" amènent souvent à monopoliser des moyens qui seraient plus utiles ailleurs). Un bon moyen pour prendre ce recul, et de d'auditer l'organisation, équipe par équipe, pour comprendre ce qui se passerait en cas d'absence totale (quel rôle occupe l'équipe au sein des processus d'entreprise, quels moyens lui sont nécessaires).
Que se passerait-il pour votre entreprise si la hotline client n'avait plus accès à ses informations, si vos pilotes d'exploitations n'étaient plus là pour déclencher les traitements batchs de la nuit ? Il y a fort à parier que dans un délai de quelques minutes, quelques heures au plus, l'impact sur le business de l'entreprise serait catastrophique. Pourtant, ce qui mobilise le plus d'énergie et de crédit, ce sont sans doute les projets en cours de développement, cœur culturellement noble du métier. Ici, l'absence des équipes nobles n'impacterait l'entreprise que plusieurs semaines ou mois plus tard, l'urgence n'est pas celle qui paraît...
Il est assez intéressant de constater, qu'en terme de service informatique rendu, ce sont les sans grades de la DSI qui tiennent le rôle principal. Voici pour une deuxième idée reçue.
Enfin, pour en finir provisoirement avec les idées reçues, pourquoi certains services rendus par le système d'information posent-ils systématiquement des problèmes alors même que l'on a affecté plus de personnels compétents et de nouveaux outils ? Il n'y a évidemment pas de réponses universellement applicables mais le constat le plus généralement fait est un dysfonctionnement structurel de la DSI : on affecte des tâches aux mauvais professionnels parce que le service à rendre n'est pas réellement sorti de sa phase projet (les études développements sont trop souvent en charge de tâches de production, ce qui non seulement n'est pas leur métier, mais plus encore que la logique de production est incompatible avec ce métier). Aucun service informatique ne peut être produit de façon stable et optimale par des équipes de développement.
8 juillet 2005
Performant, à la mode et... contre-productif
Cela fleurit comme les crochus à la fin de l'hiver. La technologie qui va sauver votre système d'information c'est le cluster. Et oui, cher DSI, ces
machines (qui existent depuis longtemps), vous promettent performance, sécurité et même une reprise automatique sur incident grace aux mécanismes de
basculement. A vrai dire, c'est, n'en doutons pas, la quasi fin des fâcheuses interruptions de service.
Vous savez quoi : c'est idiot !
Laissons de côté notre rêve de ne plus être dérangé par les pannes et regardons les choses objectivement.
D'abord, il faut bien comprendre que le cluster est une idée qui fonctionne réellement. Le premier problème qui se pose est le coût de mise au point d'une exploitation stable. Il faut en permanence des spécialistes capables de régler finement la machine et son application. Dans le cas contraire, la sanction est immédiate : un cluster totalement automatisé va passer une partie de ses journées à basculer. Et le remède est parfois désespéré : les équipes risquent de diminuer la surveillance des composants pour obtenir plus de stabilité, diminuant ainsi la détection de vraies pannes possibles. On se retrouve ainsi avec un investissement coûteux qui offre les mêmes possibilités qu'un serveur classique moyennement intégré. ROI en berne !
Mais le vrai problème de fond est détectable en se focalisant sur le service à rendre.
Deux types de panne sont à attendre : la bogue logicielle et la panne machine. Basculer en cas de panne machine est évidement la seule chose à faire pour rétablir le service. Cependant, un serveur de spare (machine de réserve) prêt à l'emploi et configuré à l'égal de la production fera l'affaire. Il ne reste plus qu'à régler le problème des données, ce qui est relativement facile à faire (même si la gestion des sauvegardes/restaurations est souvent abordée de façon non rationnelle). Cependant, et même en étant très prudent, une panne hardware a une probabilité faible de se produire (aller, disons une fois sur les quatre premières années de vie), et surtout, cette probabilité est très inférieure aux basculements intempestifs ou problèmes non stabilisés de redémarrage. La sécurité du cluster va en général générer plus d'arrêts de service qu'un système "moins sécurisé" !
Basculer en cas de panne logicielle est par contre totalement inutile puisque le basculement ne réglant pas le problème, cela se reproduira (et on aura alors perdu du temps à basculer sans s'attaquer au vrai incident). La aussi, il y a plus d'inconvénients, en terme d'arrêt de service, avec un cluster que sans.
Quelle est la leçon à retenir ? D'abord que les clusters apportent d'excellentes idées, comme l'automatisation des statuts et des arrêts / démarrages et ensuite qu'une bonne idée technique qui fonctionne ne donne pas forcément un résultat optimal pour le contrat de service. Dans un grand nombre de cas, un cluster n'améliorera pas la disponibilité du service.
Et pour la DSI, seul le service produit est important.
Vous savez quoi : c'est idiot !
Laissons de côté notre rêve de ne plus être dérangé par les pannes et regardons les choses objectivement.
D'abord, il faut bien comprendre que le cluster est une idée qui fonctionne réellement. Le premier problème qui se pose est le coût de mise au point d'une exploitation stable. Il faut en permanence des spécialistes capables de régler finement la machine et son application. Dans le cas contraire, la sanction est immédiate : un cluster totalement automatisé va passer une partie de ses journées à basculer. Et le remède est parfois désespéré : les équipes risquent de diminuer la surveillance des composants pour obtenir plus de stabilité, diminuant ainsi la détection de vraies pannes possibles. On se retrouve ainsi avec un investissement coûteux qui offre les mêmes possibilités qu'un serveur classique moyennement intégré. ROI en berne !
Mais le vrai problème de fond est détectable en se focalisant sur le service à rendre.
Deux types de panne sont à attendre : la bogue logicielle et la panne machine. Basculer en cas de panne machine est évidement la seule chose à faire pour rétablir le service. Cependant, un serveur de spare (machine de réserve) prêt à l'emploi et configuré à l'égal de la production fera l'affaire. Il ne reste plus qu'à régler le problème des données, ce qui est relativement facile à faire (même si la gestion des sauvegardes/restaurations est souvent abordée de façon non rationnelle). Cependant, et même en étant très prudent, une panne hardware a une probabilité faible de se produire (aller, disons une fois sur les quatre premières années de vie), et surtout, cette probabilité est très inférieure aux basculements intempestifs ou problèmes non stabilisés de redémarrage. La sécurité du cluster va en général générer plus d'arrêts de service qu'un système "moins sécurisé" !
Basculer en cas de panne logicielle est par contre totalement inutile puisque le basculement ne réglant pas le problème, cela se reproduira (et on aura alors perdu du temps à basculer sans s'attaquer au vrai incident). La aussi, il y a plus d'inconvénients, en terme d'arrêt de service, avec un cluster que sans.
Quelle est la leçon à retenir ? D'abord que les clusters apportent d'excellentes idées, comme l'automatisation des statuts et des arrêts / démarrages et ensuite qu'une bonne idée technique qui fonctionne ne donne pas forcément un résultat optimal pour le contrat de service. Dans un grand nombre de cas, un cluster n'améliorera pas la disponibilité du service.
Et pour la DSI, seul le service produit est important.
Liens
Mon profil viadeo
-
Rejoindre mon réseau de connaissances
-
Mon adresse de syndication :
Articles
- Echange avec un e-lecteur
- Offre d'emploi en informatique
- Des petits PRA pour garantir le SI ?
- Question d'internaute
- Swanson's unwritten rule of management n°2 : "il est plus facile de s'engager que de se dégager"
- Retour sur la dernière décennie
- Les blogs peuvent-ils être utiles pour le management de la DSI ?
- Configurons, configurons !
- Les théories qui pédalent dans le vide
- Processus, le gros mot du jour
- La gestion aléatoire du changement
- 2006 : année charnière ?
- La gouvernance, une nécessité, presque une réalité
- La DSI, une équation à trois variables
- Performant, à la mode et... contre-productif
- Idées reçues