I-1.4. Arrêter

APL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.

■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■

  • Intégrer la solution adhocratique dans le système bureaucratique
  • Redévelopper classiquement
  • Abandonner la solution adhocratique

Intégrer la solution adhocratique dans le système bureaucratique

« L’adhocratie n’a pas pour vocation de se substituer à la bureaucratie mais doit à terme intégrer les solutions élaborées par les équipes ad hoc dans le système bureaucratique. »

Ce principe suppose une appropriation de la solution informatisée donc un engagement de la structure informatique et un transfert de compétences. Autant dire que cela ne se réalise jamais. Il y a d’autres enjeux que les uns privilégient et les responsabilités que les autres ne souhaitent pas assumer.

Redévelopper classiquement

Le but ultime serait de tout redévelopper de façon classique mais sans effet tunnel, en toute sérénité, avec les moyens du moment, par une équipe s’appuyant sur l’application existante faisant office de cahier des charges.

Ce qui a été développé avec des moyens minimalistes sert de référence pour entreprendre un redéploiement plus ambitieux avec des moyens informatiques plus sophistiqués et des compétences adaptées en nombre comme en qualité. L’expérience prouve que ce scénario sans doute idéal n’est malheureusement pas réaliste.

Abandonner la solution adhocratique

L’utilisateur baisse la garde, il ne voit plus l’intérêt d’investir dans la veille technologique et/ou il oublie l’investissement que l’informatisation de sa problématique a nécessité. La situation évolue inexorablement et la solution se dégrade alors très vite. Lorsque l’utilisateur ne se soucie plus de son propre outil de travail, le cycle de vie de son application bascule de l’autre côté de la courbe en cloche de gauss et l’histoire recommence.

Le moment est alors venu pour le développeur de se désengager… et pour le système bureaucratique « Informatique/Entité-métier » de trouver une autre solution à la convenance des deux parties.

La rupture est aussi rapide qu’a été le démarrage.

Anecdote :

Mes développements de plus en plus importants et l’augmentation du nombre de gestionnaires connectés commençaient à dégrader les temps de réponse et donc les conditions de travail des gestionnaires. Par ailleurs, les coûts de maintenance du système et du serveur augmentaient au rythme de leur obsolescence. C’est en quelque sorte une veille technologique imposée par le constructeur pour lui éviter d’avoir à maintenir une compétence sur des versions vieillissantes. En fin d’année budgétaire, un reliquat budgétaire inespéré, me permet d’acquérir un nouveau serveur. Malheureusement le budget disponible ne me permet pas d’acquérir le SGBD. Je mise donc sur le budget de l’année suivante ; ce n’est en principe qu’un différé de quelques mois. Mais l’utilisateur m’affirme qu’il n’a pas le budget alors que l’on est en début d’exercice. Tant pis ! J’attends la prochaine année budgétaire. Mais non, la nomenclature budgétaire a parait-il changé et il n’y aurait plus la ligne budgétaire nécessaire. J’ai bien compris le message, j’approchais de l’âge de la retraite et j’attendais de savoir si je pouvais compter sur le budget espéré pour décider ou non de mon départ. À la grande surprise de tout le monde, j’ai pris ma retraite et mis fin à une aventure qui aura duré 17 ans.

Mes applications ayant été remplacées par d’autres, développées classiquement, il eut été intéressant de comparer les fonctionnalités. Ce que je sais, c’est que désormais une demande d’aménagement, quand elle a une chance d’aboutir nécessite minimum deux ans d’attente quand je réglais le problème par téléphone dans l’instant. Ce que je sais aussi, c’est que les gestionnaires n’en peuvent plus de cliquer, ils cliquent, ils cliquent. Je sais également que les fonctionnalités non prises en compte ont été développées localement. Je sais surtout, que l’excellente ambiance que j’avais su créer a complètement disparu, les gestionnaires ne communiquent plus et s’enferment dans leur bureau.

Ce que j’ai pu faire dans une structure qui ne peut pas être plus rigide, plus administrative que l’administration (la maison des fous disaient Goscinny et Uderzo), qu’est-ce qui empêche le privé de le faire, de le décider, de l’organiser ? En m’intéressant à l’Agile, j’ai découvert lors de la Journée Agile 2011 de Bruxelles un intervenant qui proposait une conférence intitulée « L’adhocratie va-t-elle sauver le monde ? ». Le privé aurait-il enfin compris ?

Description de sa session :

L’élément le plus flexible contrôle le système – et si l’entreprise s’organisait pour injecter dans son ADN (valeurs, vision, attitudes, compétences, …) les ingrédients nécessaires pour constamment être en phase avec un environnement économique, humain, technologique, social… en changement perpétuel…

Comment l’entreprise pourrait être sûre d’avoir cette agilité pour concentrer ses forces sur les sujets du moment qui font du sens pour elle et son écosystème… qui lui permettront de traverser n’importe quelle crise et d’en tirer une force concurrentielle supplémentaire… est-ce un pur fantasme ?

Existe-t-il une configuration d’entreprise qui soit désignée pour fonctionner de manière ad hoc perpétuellement ?

Qui a comme culture d’entreprise la gestion de l’exception ?

Qui plus elle traverse des changements, plus elle se renforce ?

L’adhocratie serait-elle la configuration ultime de l’entreprise agile ?

Est-ce LA structure de la génération Y ?

Ce conférencier a participé à monter une des premières entreprises agiles appelée “adhocratie” en Belgique. Je suis bien sûr allé voir ce qu’il en était. En fait, la démarche de son entreprise était aussi structurée que peut l’être n’importe qu’elle méthode dite agile… Rien à voir avec l’adhocratie. Déception ! Je n’ai pas jugé bon de conserver l’information et je ne la retrouve pas sur internet.

I-1. Les règles de conception

▲ I-1.3. Démarrer
► I-1.4. Arrêter
▼ I-2.1.1. Brainwriting

Aller à la source
Author: APL-AML