La transformation est une fonction, pas un projet

La plupart des organisations font évoluer leurs systèmes de la même manière. Quelqu'un défend l'idée d'un projet. Un budget est approuvé, une équipe est constituée, un fournisseur est choisi et une date de mise en service est inscrite au calendrier. L'équipe travaille dur, le système est mis en service et le projet se clôt. Les personnes qui comprenaient le travail passent à autre chose.

Puis l'organisation continue de changer. Une nouvelle gamme de produits exige une nouvelle étape d'approbation. Une réglementation modifie ce qui doit être consigné. Deux équipes fusionnent, mais pas leurs tableurs. Rien de tout cela n'attend le prochain projet, et pourtant la capacité d'y répondre est partie avec le précédent.

C'est ce schéma qui se cache derrière une bonne part des frustrations liées à la technologie. Le problème, ce n'est presque jamais que le dernier projet ait échoué. C'est que le modèle du projet traite le changement comme un événement, alors que pour la plupart des organisations, le changement est une condition permanente.

Pourquoi le modèle du projet continue de décevoir

Le modèle du projet a été pensé pour un travail qui a un début et une fin nets : construire un entrepôt, déménager des bureaux, installer une machine. Ces choses sont terminées une fois qu'elles sont terminées. Le logiciel qui fait tourner une activité n'est jamais terminé en ce sens. Il se trouve au milieu du travail, et le travail ne s'arrête pas.

Quand un système est livré sous forme de projet, trois choses ont tendance à se produire une fois le projet clos.

• Le savoir se disperse. Les raisons derrière la conception, les cas particuliers découverts par l'équipe, les compromis consentis : l'essentiel vivait dans des personnes et des réunions. Quand l'équipe se sépare, l'organisation garde le système mais perd la compréhension qu'elle en avait.
• Les petits changements s'accumulent. Chaque demande est trop petite pour justifier un nouveau projet, alors elle attend. Pendant ce temps, les gens contournent le manque avec un tableur, un message ou une vérification manuelle.
• Le système s'éloigne du travail. Mois après mois, la façon dont l'organisation fonctionne réellement s'écarte de la façon dont le système s'attend à ce qu'elle fonctionne. Le projet suivant commence alors par redécouvrir ce que le précédent savait déjà.

Rien de tout cela n'est la faute de qui que ce soit. C'est ce que le modèle produit.

À quoi ressemble une fonction

Les organisations savent déjà gérer un travail qui ne s'arrête jamais. La finance ne clôture pas les comptes une fois pour toutes avant de se dissoudre. Le service juridique ne cesse pas de relire les contrats après le premier. Ce sont des fonctions : des responsabilités permanentes, portées par des personnes qui restent, avec la mémoire de ce qui précède et une capacité stable à traiter ce qui suit.

La transformation peut fonctionner de la même manière. La traiter comme une fonction signifie quelques choses concrètes.

• Quelqu'un en est responsable en continu. Il existe un responsable nommé, qui répond de la façon dont les systèmes de l'organisation évoluent, et pas seulement de la prochaine initiative.
• La capacité est stable. Au lieu de constituer une équipe pour chaque projet puis de la dissoudre, une capacité continue passe d'un besoin au suivant à mesure que les priorités changent.
• La mémoire est conservée. Les décisions, le contexte et les contraintes sont consignés là où la personne suivante pourra les trouver. Personne n'a à reconstituer pourquoi le circuit d'approbation fonctionne comme il fonctionne.
• Le changement est continu. Le cycle qui consiste à comprendre un besoin, façonner une réponse, la construire, la vérifier, la déployer et la faire évoluer se répète encore et encore, au rythme dont l'organisation a besoin.

Trois changements dans la pratique

Passer des projets à une fonction relève moins des organigrammes que des habitudes. D'après notre expérience, le changement se voit à trois endroits.

Des livrables à la capacité

Un projet se décrit par ce qu'il livrera. Une fonction se décrit par ce qu'elle peut prendre en charge. La question passe de « combien coûtera la construction de ceci » à « sur quoi notre capacité devrait-elle travailler ensuite ». Il devient alors possible de régler les petites choses qui n'ont jamais justifié un projet, et de changer de direction sans lancer un nouvel appel d'offres.

De la passation à la continuité

Dans le modèle du projet, le moment le plus risqué est la passation : des personnes qui ont conçu le système à celles qui l'exploitent, ou d'un fournisseur au suivant. Une fonction supprime la plupart des passations, parce que la même équipe porte le travail de la première conversation jusqu'à l'exploitation, et inversement. Ce qu'elle ne peut pas supprimer, elle le consigne.

Des grandes livraisons à l'évolution régulière

Quand le changement coûte cher à lancer, les organisations le mettent de côté et le livrent par gros lots. Les gros lots sont plus difficiles à tester, plus difficiles à expliquer et plus difficiles à annuler. Une fonction permanente peut apporter des changements par petites étapes, chacune comprise, vérifiée et expliquée aux personnes qu'elle touche.

Ce que cela demande aux dirigeants

Une fonction ne se passe pas de pilotage. Elle demande aux dirigeants de trancher délibérément quelques questions.

D'abord, qui est responsable de l'évolution des systèmes de l'organisation, et comment cette personne est soutenue. Ensuite, comment la capacité continue est fixée et revue, pour qu'elle reste proportionnée à l'ambition. Enfin, comment les priorités sont choisies, parce qu'une capacité qui peut tout prendre en charge se verra demander de tout prendre en charge.

Elle demande aussi une patience d'un genre particulier. Les bénéfices d'une fonction sont cumulatifs. Ils viennent d'un savoir qui reste, de problèmes réglés pendant qu'ils sont encore petits, et de systèmes qui continuent de correspondre au travail. Ils se voient plus facilement sur une année que sur un trimestre.

La place de Croo

Nous avons bâti Croo autour de cette idée. Votre Croo est une équipe qui reste aux côtés de l'organisation : une personne dans la pièce qui connaît vos opérations et, derrière elle, les disciplines que le travail exige, des processus et de l'architecture à l'ingénierie logicielle, à la finance et à la gouvernance. La Factory donne à cette équipe une mémoire partagée et un système de production, pour que chaque changement s'appuie sur le précédent au lieu de repartir de zéro.

La relation repose sur une capacité continue plutôt que sur une succession de projets. Ce n'est pas une licence logicielle et ce n'est pas une mission ponctuelle. C'est une façon de faire de la transformation quelque chose que l'organisation porte en continu, sans avoir à bâtir tout un service à elle.

Les projets garderont leur place. Certains changements sont assez importants pour mériter un nom, un plan et une date. Mais quand le projet se termine, la fonction ne devrait pas s'arrêter. L'organisation continuera de changer. Sa capacité à changer devrait rester.