fra

Votre service d'exploitation est-il prêt pour DevOps ?

Dans un récent Tout sur l'ITSM podcast à Knowledge 16, on m'a demandé ce que je pensais d'Agile et de DevOps.

Ce n'est un secret pour personne dans le domaine de l'informatique que DevOps est actuellement le sujet le plus brûlant dans la sphère ITSM. Les organisations tentent de faire tomber les barrières entre "Dev" et "Ops" afin d'accélérer l'innovation, permettant le développement et la diffusion continus de nouvelles fonctionnalités et de nouveaux services.

Alors que des entreprises comme Spotify ont montré comment ils ont bâti une nouvelle culture d'ingénierie sur ce nouveau paradigme depuis le début, de nombreuses organisations informatiques traditionnelles ont un défi complètement différent à relever lorsqu'elles essaient de passer de l'ancien "modèle d'usine informatique" à un nouveau modèle de collaboration agile, plus aligné horizontalement.

Le problème ne se situe pas tant du côté du développement que du côté des opérations, où de nombreuses organisations ne disposent toujours pas d'une intégration de base des processus informatiques fondamentaux tels que la gestion des incidents (IM), la gestion des problèmes (PM) et la gestion des changements (CM).

Nous le constatons quotidiennement dans notre travail avec les clients où nous trouvons la GI, la PM et la CM sous différentes directions, avec des priorités différentes et peu d'interfaces pour assurer un bon transfert des données. Ce qui manque souvent, c'est la perspective du processus de bout en bout (client) de trois disciplines qui, dans ce cas, ont pour but ultime de résoudre les problèmes techniques et ceux du client plus rapidement et de façon permanente, tout en maximisant la disponibilité de l'informatique.

Personnellement, je crois que cela a beaucoup à voir avec la façon dont des cadres comme ITIL® ont été, disons, "mal interprétés". Alors que l'un de leurs principaux objectifs était d'instaurer une culture davantage axée sur les processus, de nombreuses organisations les ont pris comme prétexte pour créer des fonctions entières autour des différents processus, ce qui, dans de nombreuses entreprises, a fini par créer des silos qui interagissent rarement les uns avec les autres.

Avec ou sans DevOps, nous devons nous demander quelle valeur nous apportons au client en divisant ces disciplines au lieu de les aligner et de les intégrer dans un but commun, avec pour objectif ultime d'améliorer la disponibilité et l'expérience client. À ce stade, nous pourrions être prêts à passer à DevOps, qui concerne la "gestion horizontale de l'entreprise" et l'alignement d'équipes multidisciplinaires, avec des compétences différentes, autour d'un objectif commun (plutôt que d'une structure).

Cependant, la réintégration de l'aspect opérationnel de l'entreprise ne se limite pas à aligner les organisations et les équipes sur un bout de papier. Changer l'organigramme, en soi, n'aura aucun impact sur les résultats de l'entreprise. Ce réalignement doit aller de pair avec un désencombrement de nos processus, en supprimant les tâches sans valeur ajoutée, en donnant à nos collaborateurs les moyens de travailler dans un éventail plus large de disciplines. Nous devons les récompenser pour leur bon comportement (ne pas limiter leur pensée en les enfermant dans une certaine boîte) et nettoyer notre paysage d'outils pour nous assurer que nous pouvons créer des connaissances significatives et que nous sommes capables d'automatiser des tâches simples et récurrentes.

Ce n'est qu'alors que nous pourrons exploiter la véritable valeur de DevOps.

Image du blog 1
Qu'est-ce qui lie ITSM et ITIL® à Agile et DevOps ?
Image du blog 1
Mesurer la qualité de la gestion des problèmes dans un environnement ITIL, partie 1

Nous sommes experts en :

Nous contacter

Pour tout renseignement, information complémentaire ou un devis