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.

La nécessité d’avoir les mêmes priorités

Les DSI, et notamment leurs équipes de production informatique, se sont fortement industrialisées : des processus visant à maîtriser les changements sur la production existent et sont bien connus. De la même façon,  les entités d’étude et développement ont pu mettre en place des méthodes de gestion des évolutions fonctionnelles sur le patrimoine applicatif.

Il existe en revanche peu de cas où la chaîne est maîtrisée de bout en bout, du métier jusqu’à la production informatique. Cette vision d’ensemble est pourtant nécessaire.

Pour le métier, il s’agit d’être en capacité de prioriser et d’arbitrer ses besoins d’évolution, en fonction de la capacité de la DSI à y répondre, dans un souci d’efficacité économique. Pour la DSI, l’objectif est d’anticiper au mieux la demande, pour fournir un service de qualité. Un travail d’écoute est donc indispensable entre métiers et DSI.

Partager les mêmes règles d’évolution

Faire évoluer son SI consiste à faire cohabiter plusieurs natures d’évolutions, qui comportent chacune ses propres exigences (méthode, urgence…) : les évolutions fonctionnelles,  applicatives ou techniques, les projets métiers, les correctifs…

Par exemple, les « projets » voient leur planning défini  longtemps en avance, contrairement aux « évolutions fonctionnelles », plutôt traitées au fil de l’eau.

Répondre à ces multiples sollicitations peut rapidement devenir complexe ; par ailleurs, un manque de pilotage de la demande peut être rapidement générateur de coût, par exemple en cas d’évolutions successives d’un même composant du SI.

Il est donc nécessaire de définir un cadre d’évolution du SI et de rythmer celui-ci. L’objectif est de pouvoir regrouper les « évolutions » dans des changements communs et déterminés à l’avance. La fréquence sera bien entendu à adapter en fonction de la nature de ces changements et de leur niveau d’urgence :

• De 2 à 4 changements majeurs par an : destinés à intégrer les évolutions les plus impactantes dont le niveau de risque sur la qualité de service et le niveau de préparation peuvent être élevés ;
• Des changements mensuels : pour les évolutions à impact restreint ;
• Des changements hebdomadaires, voire quotidiens : évolutions maîtrisées, présentant peu de risque.

Ces regroupements pourront intégrer des changements liés à des projets, des évolutions fonctionnelles, voire des correctifs non bloquants. En revanche, l’intégration des changements applicatifs avec des changements techniques reste peu pratiquée.

Par ailleurs, il convient d’adapter ce rythme à la nature du SI (centralisé ou non), aux exigences d’agilité du métier et à la maturité du SI.

Des calendriers à partager

La mise en place de tels regroupements nécessite un travail conjoint entre la DSI et les métiers, car les calendriers doivent être négociés en amont avec ces derniers. Par ailleurs, il est nécessaire de définir certaines dérogations (résolution d’incident, prise en compte d’un besoin stratégique, etc.), mais celles-ci doivent être soigneusement pilotées.

Le niveau de regroupement doit cependant être considéré avec prudence. Il reste nécessaire de maîtriser l’impact des évolutions : un regroupement trop important peut générer des incidents complexes à résoudre.

La gestion des ressources peut elle aussi devenir problématique, avec des pics de charge complexes à gérer.

Vers plus de sérénité entre les métiers et la DSI ?

Finalement, ce travail de structuration des évolutions amène plus de sérénité dans le travail des équipes (réduction du travail dans l’urgence) et permet également de dégager des optimisations économiques (limitation d’actes redondances, mutualisation de certaines opérations de tests).

Comme l’a dit André Maurois, « La sérénité est une conquête ». Celle des directions métiers et des DSI sur les prochaines années pour mieux travailler ensemble.

Cet article L’évolution du SI : l’art de faire danser métiers et DSI sur le même rythme est apparu en premier sur RiskInsight.