Un e-commerce pionnier

Les premiers à avoir dû rendre compatibles robustesse et agilité sont sans aucun doute les acteurs du e-commerce. Ils ont dû pour cela résoudre trois difficultés majeures :

1. Le business demande un time to market au jour le jour
2. Le succès fait accroître le besoin en puissance de façon exponentielle (comme le montre la  vente sur internet)
3. Le digital rend les architectures systèmes de plus en plus complexes et hétérogènes (il suffit de regarder l’exemple du transport aérien)

Agile robustesse, impossible équation ?

Observons leur exemple pour voir comment ils ont su répondre à la problématique du  « tout digital », allant parfois à l’encontre de certaines certitudes.

Conviction°1 : adapter la proximité MOA-MOE

L’organisation globale des entreprises doit tenir compte de l’agilité du SI sachant qu’il faut distinguer trois cas « types » : SI « classique », SI « ERP » et SI « multi-canal ». Pour le dire simplement : plus le besoin en agilité est fort plus les acteurs métiers et IT doivent être proches. L’organisation en mille-feuille, de par son manque cruel d’agilité et de par la multiplicité des acteurs qui la composent, souffre par définition d’inertie. Il ne faut pas d’ailleurs se limiter à rapprocher uniquement  les équipes MOE et les équipes MOA : il est nécessaire que les acteurs de la mise en production acquièrent une vraie sensibilité « métier ».

Conviction°2 : nommer un responsable système de bout en bout

La multi-canalité et le « tout digital » ont mis en évidence la difficulté de garantir une vision complète et maîtrisée du SI par des équipes organisées par technologies ou domaines fonctionnels. Cependant, la notion ou le rôle d’un responsable « système » (de bout en bout) est encore peu fréquent et incompatible avec les organisations en place. Il s’avère que ce manque de vision et de responsabilité transverse est l’une des causes majeures des difficultés et des coûts de mise en production. Pour pallier à ces difficultés, les entreprises mettent en place des batteries de tests de non-régression générant des coûts récurrents importants. Par souci d’agilité, il faut adapter ces tests en permanence et en raison de la complexité des chaînes de liaison, il est difficile de disposer des tests complets et pertinents.

Conviction°3 : recruter des profils plus qualifiés

Le recrutement de talents pour la filière SI se limite encore trop souvent aux « études », réputées plus créatives. Mais cette stratégie a ses limites. En effet, la crise a imposé un gel des embauches, ce qui a conduit à un vieillissement des équipes et donc à une perte progressive de connaissance sur les nouvelles technologies, les nouveaux usages et les nouvelles méthodes de travail. Par ailleurs, la complexité des architectures nécessite aujourd’hui, notamment dans les activités historiquement considérés comme « techniques », moins de valeur créative ce qui a conduit à une réelle perte d’attractivité. Pourtant, la mise en production ne doit plus être considérée comme un simple geste technique mais comme clé de voûte de la qualité du système entier ! Elle nécessite des compétences fortes et transverses.

Conviction°4 : partager les risques entre Métiers et DSI

L’entreprise a aujourd’hui besoin d’accroître sa capacité de gestion de risque. Les trois points évoqués précédemment sont des conditions nécessaires pour améliorer la situation et enfin trouver des gains escomptés dans la durée. Mais le partage des risques entre les acteurs métiers et  les acteurs IT en fonction des enjeux business permet de tirer profit des investissements à réaliser. Bien entendu ceci passe par la mise en place d’un pilotage fondé sur des indicateurs pertinents. La question du coût de mise en production est relative et doit être directement reliée à l’impact métier… soit la prise de risque associée.

Bien sûr, les grandes entreprises ne peuvent pas pleinement se comparer à ces acteurs du e-commerce qui, pionniers en la matière, ont été privilégiés par la petitesse de leur structure et par l’unique objectif qu’ils suivaient de mener à bien leur business naissant. Mais les grandes sociétés ont tout de même beaucoup à apprendre d’eux. À chacun de trouver sa recette pour conjuguer succès rapides et une stratégie moyen terme.

Cet article Une mise en production agile et robuste, et si l’équation était finalement possible ? (2ème partie) est apparu en premier sur RiskInsight.

Dans un contexte économique difficile, accroître la fiabilité de la mise en production des applications représente un gisement d’économies souvent inexploité » annonce Pierre Audoin Consultants en septembre 2013, suite à l’enquête menée auprès de 50 entreprises et administrations. Face à cette préoccupation majeure des DSI qu’est la maîtrise des coûts, l’enquête fait ressortir un certain fatalisme de la part des entreprises interrogées par rapport à la qualité et in fine au coût engendré par ces opérations fréquentes et parfois complexes. Le cabinet PAC fait preuve dans ce document d’une vision claire de la frontière existante entre les études build et la production run, même si cela n’est qu’une partie du problème global. Il apporte aussi quelques pistes clés pour améliorer à la fois la préparation et l’exécution des mises en production, mettant en avant des bonnes pratiques sur l’outillage et en particulier sur le référentiel ITIL. Des pistes intéressantes que nous avons souhaité creuser davantage. Mais pour ce faire, il est avant tout nécessaire de faire un vrai retour en arrière sur la chaîne de valeur informatique. Nos recommandations feront quant à elles l’objet d’un prochain article.

Retour sur les 1^ères organisations informatiques

Retournons 30 ans en arrière ! À cette période, les organisations informatiques se sont  structurées en fonction de la chaîne de valeur de l’informatique de l’époque. Il s’agissait des applications « métiers » implémentées sur des systèmes centraux plutôt monolithiques et développées sur des spécifications répondant aux exigences « métiers » particulières à chaque entreprise. La réalisation de ces applications, leur maintenance et leur exploitation étaient organisées d’une façon séquentielle. Les cycles d’adaptation et d’évolution étaient assez longs. Le cœur du SI concernait le « produit », l’utilisateur accédait par un terminal « passif ».

La grande stabilité des applications et le côté « monolithique »  des architectures centrales rendaient des opérations de mise en production assez simples, voire « mécaniques » et par conséquent plutôt fiables. Nous avons pu constater que la chaîne de valeur IT était alors naturellement industrialisée, sans qu’un effort particulier n’ait dû être fait. Par ailleurs, le faible nombre de fournisseurs et la prédominance d’IBM a largement facilité la tâche à l’époque.

ITIL : une solution pas forcément miraculeuse

Il est intéressant de rappeler que l’arrivée d’ITIL dans les années 80/90 coïncide avec l’émergence des architectures distribuées, rendant les mises en production plus complexes et faisant naître par la même occasion le besoin d’une formalisation des processus, pour retrouver une robustesse comparable. Toutefois la mise en production était alors restée une activité « technique » et par conséquent prise en compte par les techniciens de la production informatique. Ces activités étaient très loin des préoccupations des acteurs métiers… et les organisations IT et leur fonctionnement n’ont pas été mises en cause pendant longtemps.

Bien que proposée comme une solution clé par l’enquête PAC, la mise en place d’ITIL « pur(e) et simple », voire son implémentation « doctrinaire », peut aujourd’hui se révéler contreproductive car elle ne répond plus aux exigences d’agilité et de robustesse. En effet, la crise de 2008 et ses conséquences économiques ont mis à l’ordre du jour la question de l’efficacité de la mise en production.

Quelle réalité aujourd’hui ?

La généralisation des architectures « composites », l’arrivée de la « multi-canalité » et l’explosion du digital changent profondément la donne et mettent en cause les paradigmes du passé. Il faut l’avouer, les conséquences à venir dépassent largement le domaine des « bonnes pratiques » de la production informatique. Aussi, fort de cette compréhension du passé, LA question à laquelle il faut se soumettre est celle qui permet de trouver le meilleur équilibre entre l’agilité et la robustesse du SI. Pour le savoir, rendez-vous dans quelques jours pour une autre chronique.

Cet article À l’ère du « tout digital », la mise en production (re)devient un enjeu d’agilité et de robustesse (Partie 1) est apparu en premier sur RiskInsight.