Business vs IT : l'impossible réconciliation ?

Modification : Samedi 24 Juin 2017 - 19h48 (ajout webcast Pinterest Growth Team)
Modification : Dimanche 25 Juin 2017 - 22h35 (ajout Dual-Track Scrum)

Je suis actuellement en train de vivre une aventure passionnante au sein de l'entreprise que j'ai rejointe, il y a tout juste 1 an.

En route pour l'aventure !

Cette aventure est synonyme de nouveaux défis à relever avec de nouvelles offres et produits (digitaux) à imaginer qui :

1. enthousiasmeront les différents clients que nous servons (ça c'est la dimension Business)
2. s'intégreront avec le reste des offres existantes dans un tout cohérent (ça c'est la dimension IT / Digital [je ne rentrerai pas dans le débat sur cette différenciation dans ce billet...]).

Un chemin semé d'embûches

Les ambitions sont grandes... et les obstacles aussi :

Problème	Description	Moyen de surmonter
Concurrence externe	nombreux concurrents (startups très actives) qui savent réagir vite en étant disruptives	agilité, position dominante
Concurrence interne	offres très complémentaires mais avec des zones de friction	management, redéfinition des offres, offres transverses, …
Organisationnel*	être agile mais pas au sacrifice de la maintenabilité	fédérer les acteurs internes autour d’un projet, architecture performante, maîtrise de la dette technique

(*) je vous recommande la lecture de l'article "Vers une entreprise agile : la sauvegarde des mammouths ou la nécessaire transformation des DSI"

Attardons-nous sur ce dernier problème : l'Organisation et commençons par la fameuse Agilité

Agilité : une main de velours dans... une chape de plomb ? 

En tant qu'ancien consultant, j'ai croisé beaucoup (plusieurs dizaines) d'entreprises et pu voir plusieurs modèles d'organisation. Au cours de ces dernières années, j'ai vu déferler la méthodologie Agile au sein de ces organisations et ça ressemble plutôt à ça :

Source : http://www.commitstrip.com/fr/2017/01/09/that-little-problem-with-agile/

Bref, l'agilité n'est pas facilement embrassée... C'est que les anciens modèles d'organisation ont la vie dure

Pour 1€ symbolique : mon ancienne DSI 1 fois, mon ancienne DSI 2 fois, ... 

Afin de rationaliser l'outil de production IT, on a rassemblé les compétences au sein de DSI (les équipes de "Prod")

Source : "Vers une entreprise agile..."

Toute la difficulté (voire la schizophrénie) des métiers est qu'elles doivent :

1. innover rapidement au risque d'être dépasser de perdre leur avantage concurrentiel
2. respecter des contraintes budgétaires fortes (au risque de perdre un budget parfois serré)

Externalisation : égarement ou vraie solution ?

Une pratique qui se développe : http://www.technologies-methodes-it.com/6-bonnes-raisons-dexternaliser-sa-dsi/

C'est ainsi qu'on a pu voir des sociétés externaliser leur DSI (cession vers des sociétés de services telles que SSII - appelées désormais ESN pour ceux qui ont suivi l'actualité de ces dernières années). Et bien oui, dans certains groupes aux conventions collectives très favorables, un informaticien coûte fort cher comparé à ceux qu'on peut avoir via le Syntec !

J'ai également pu observé un recours très fort aux prestataires de services (toujours les mêmes ESN) avec une montée en gamme par le biais du BPO (Business Process Outsourcing), c'est-à-dire le fait de déléguer une partie de ses processus non critiques à un tiers.

Je suis convaincu que disposer de compétences en interne pour accompagner le Business est un atout majeur. Néanmoins, pour les entreprises qui font le (bon) choix de garder leur DSI, m'est avis qu'il ne faut pas tomber dans le schéma MOA vs MOE, ces 2 entités ne se parlant qu'à coups de spécifications et de SLA.

Et c'est souvent là que ça tiraille un peu : le Business veut pouvoir développer et tester (A/B testing...) de nouvelles fonctionnalités en mode "Quick & Dirty" (ex: Pinterest et sa Growth Team)

Source : UserTesting - Casey Winters Webinar

et la DSI a besoin de pouvoir assurer les correctifs et réintégrer ces nouvelles fonctionnalités quand elles auront été validées.

S'organiser autrement

Les organisations modernes l'ont bien compris en montant leurs projets autour d'équipe "pluri-disciplinaires" rassemblant : métier, UX/UI designer, développeurs, chef de projet, ... et en faisant sauter les barrières entre les équipes que ce soit :

• Scrum : agilité entre métier (MOA) et études (Dev)
• DevOps : agilité entre études (Dev) et équipe de de production (Ops)

Source : "Vers une entreprise agile..."

Mais il est possible d'aller bien plus loin !

Un modèle qui commence à faire du bruit est le Dual-Track Scrum (lire https://www.devbridge.com/articles/how-to-set-up-dual-track-scrum-in-jira) (voir aussi Dual-Track Product Development) où - à l'instar de ce que fait Pinterest dans le webcast ci-dessus) - on distingue 2 phases dans la mise en oeuvre du produit :

1. Discovery
2. Delivery

la première alimentant la seconde via des stories déjà testées auprès des utilisateurs finaux.

Schématiquement :

Source : https://www.devbridge.com/articles/how-to-set-up-dual-track-scrum-in-jira/

Je serais enclin à croire que c'est vers ce modèle qu'il faut s'orienter, et vous ?