Goldratt on IT (épisode 1)

Eliyahu Goldratt, le père de la Théorie Des Contraintes, auteur du best seller « Le BUT », nous fait l’honneur de venir en France participer à l’université du SI.

Quel est son point de vue sur l’IT ?

« La technologie peut apporter des bénéfices si et seulement si elle diminue une limitation ».

Etes vous d’accord avec cette phrase ?

« Prenez tout votre temps pour répondre car elle est d’une logique imparable et ses conséquences sont révolutionnaires ».

Si vous planifiez de perdre quelques heures dans les transports d’ici les semaines qui viennent alors je vous recommande d’écouter sur votre ipod son audio book « Beyond the Goal » disponible sur audible.com.

Il y discourt avec clarté, ferveur et humour de cette condition nécessaire et suffisante pour que la technologie serve l’entreprise.

Cette condition amène, démontre-t-il, à poser 3 questions face à une nouvelle technologie :

  • Quelle est sa force, qu’apporte-t-elle de nouveau ?
  • Pour une entreprise qui souhaite la mettre en place, quelle limitation de ses performances permet-elle de diminuer ?
  • Quelles sont les règles, tacites ou explicites, qui permettent à cette entreprise de vivre avec cette limitation ?

La troisième question est cruciale car si ces règles ne sont pas changées alors la technologie n’apportera pas les bénéfices promis.

Par exemple, il y a 20 ans une petite usine de fabrication de 300 personnes vit apparaître le calculateur informatique. Il offrait de calculer instantanément l’approvisionnement net à partir d’un plan de vente alors que cette tâche fastidieuse occupait 10 personnes pendant 2 jours et n’était effectuée du coup qu’une fois par mois.

Qu’a fait cette entreprise ? Elle s’est mise à calculer son approvisionnement net instantanément. une fois par mois.

Reprenons les 3 questions que posent Goldratt.

La force du calculateur est de pouvoir effectuer sans erreurs des calculs dépendants à une vitesse fulgurante.

La limitation qu’elle permet de lever pour cette entreprise est le temps qu’elle passe à calculer l’approvisionnement net.

La règle que suivait cette entreprise pour vivre avec cette limitation est de n’effectuer ce calcul qu’une fois par mois, sinon celui-ci mobiliserait tellement de personnes que la production en souffrirait.

En conservant cette règle, l’entreprise est passée à coté des bénéfices financiers énormes qui l’attendaient si, avant que ses concurrents ne le fassent, elle s’était mise à provisionner au fil des commandes : réduction drastique des stocks et des temps de livraison, sécurisation des ventes et adaptation à l’évolution du marché.

Il y a 20 ans, quand le calcul informatique est apparu, 90% des entreprises n’ont pas répondu pas à la 3ème question de Goldratt et l’industrie tout entière n’a pas récolté les bénéfices financiers promis par cette révolutionnaire technologie.

A nous maintenant : que pensez-vous de faire l’exercice de répondre à ces 3 questions pour les technologies que nous connaissons ?

Mon exemple : HIBERNATE.

La force d’HIBERNATE est de gérer automatiquement le mapping objet / relationnel.

La limitation que permet de lever cette technologie est l’obligation de concevoir le modèle physique relationnel des données persistentes.

La règle que j’ai vue employée pour vivre avec cette limitation est la croyance que le modèle métier ne s’exprime que sous cette forme technique adhérente à la base de données.

J’en rencontré peu d’organisations qui ont fait le deuil de cette règle pour modéliser leur métier sous forme d’objet JAVA. Au contraire d’apporter des bénéfices, l’emploi d’HIBERNATE nécessite alors le maintien manuel de la cohérence entre le modèle physique, le modèle objet et les fichiers qui configurent le mapping objet / relationnel..

A vous.

– Olivier

5 commentaires sur “Goldratt on IT (épisode 1)”

  • Le lien vers audible semble ne pas fonctionner

  • c'est corrigé, merci !

  • Olivier,

    vous n'allez pas jusqu'au bout de votre raisonnement. Si effectivement, dans un contexte précis, on pouvait se passer de modélisation classique pour 'laisser' la magie HIBERNATE opérer seule, alors cela impliquerait nécessairement que TOUTES les applications présentes et futures accédant à cette base devraient 1: être écrites en Java, 2: utiliser HIBERNATE. Alors, pour reprendre un des leit motiv de Goldratt, est-on sûr que HIBERNATE est bien un but - en soi ?
    Quelle est le but ? probablement d'augmenter le ratio Valeur de l'application / coût de développement et de support.
    Dans notre exemple, nous portons notre attention sur la minimisation du dénominateur: poussons votre idée au bout; si nous faisons abstraction de la base relationnelle, alors supprimons la.
    Et HIBERNATE de n'être plus qu'un moyen.
    Je vous invite à lire ce post qui reprend et détaille cette idée: privatelab.blogspot.com/2...

    Cordialement,
    Laurent.

  • Oui Laurent, Hibernate n'est pas le but, c'est une opportunité d'augmenter le ratio valeur / cout de l'application comme tu l'indiques.
    Il souffre d'une limite qui est l'accumulation de couches que tu soulignes dans ton post. On voit bien que la prochaine innovation technologique qui cherche à simplifier le développement et sécuriser l'exploitation (le but), pour augmenter les performances (ratio valeur/cout) sont les serveurs d'application en grille, qui intègrent nativement le stockage distribué de leurs objets (<teasing>Venez à l'université du SI, il y a des sessions sur le sujet !</teasing>). Pour intégrer ces technologies au reste du SI, il faudra que nous fassions fi de la règle tacite : SGBDR = unique possibilité de stocker des données de manière performante et sécurisée.... La dialectique Goldratt nous aide à avancer vers le but !

  • Laurent,

    > Si effectivement, dans un contexte précis, on pouvait se passer de modélisation classique pour 'laisser' la magie HIBERNATE opérer seule, alors cela impliquerait nécessairement que TOUTES les applications présentes et futures accédant à cette base devraient 1: être écrites en Java, 2: utiliser HIBERNATE.

    Il me semble entendre justement dans votre phrase une invocation de cette règle limitante 'le schéma de persistence est le modèle métier'.

    Pour quelle raison plusieurs applications partageraient un même schéma de persistence ?

    Si le modèle métier est exprimé en objet (POJO) la communication inter applications s'exprime simplement à se niveau.

    Du coup de réalise qu'une autre règle permet de vivre avec la limitation que permet de lever HIBERNATE : 'l'intégration entre application se fait par la donnée.'

    Qu'en pensez-vous ?

    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha