I had done a special bibliographic file. .
Brève histoire des méthodes
Voir mon grand texte "Siècle", surtout avec les notes de Watier.
Avant la guerre et jusqu’à 1970, essentiellement les oganisateurs. Taylor, Gilbreth, Fayolle, Rimailho, Ponthière et le Cnof, puis Paul Planus, la CGO, le Scom
1967 environ. Corig, puis Warnier
1975 environ, après des réflexions menées par Le Moigne, puis Tardieu, Rochfeld. Essai d’européanisation avec Eurométhode, je crois. Merise. IBM copie avec Axial.
En parallèle, rechrche sur des méthodes différentes, notamment pour le dialogue avec les utilisateurs (Ossad, travaux anglais de Land/Mumford, allemands avec Briefs). Méthodes en spirale, méthodes inspirées de la qualité.
La saga Inforsid.
1980 et après : les objets, mouvement venant au départ de la programmation, avec une montée dprogressive : programmation strucurée, typage, Ada, puis C++, Eiffel et enfin Java, qui ne sont pas des méthodes, mais sont tout de même assez structurants, et visent précisément l’objectif de réutilisation (une obsession chez Bertrand Meyer, en particulier). Et pourquoi dis-tu qu’UML n’est pas une méthode ?
1995 et après. Déferlement d’Internet qui modifie en profondeur aussi bien la façon de développer que de concevoir et de faire évoluer les systèmes. Il n’y a pas au départ de méthode à proprement parler. D’autant plus que la construction d’une petite vitrine sur le web, voire d’un serveur déjà un peu étoffé comme celui du Club, peut se faire de manière totalement artisanale avec Word.
La qualité, le CMMb, les points de fonction. Essais de métrique.
Il serait intéressant de voir où on en est fin 99 dans les firmes spécialisées.
2002. Parution du bouquin de Scheer
Sur l’usure des systèmes,
Ce que tu m'as dit sur le PU rejoint ce que m'a dit Lapassat (DSI de la Générale de Eaux) : Hipo a de graves faiblesses théoriques, mais se vend bien plus que toutes les méthodes à la française (je cite de mémoire).
Je me pose la question : il ne sert peut-être à rien de faire un travail théorique et individuel sur les méthodes. La matière est dificile du fait même de sa généralité. Par un de ces versants, elle rejoint des questions métaphysiques sur la réalité profonde d de l'être humain. Par un autre, elle doit prendre en compte toute la technologie et son déferlement. Par un autre, enfn, elle doit rejoindre la pratique des entreprises et autres institutions dans toute la diversité de leurs métiers.
La force du PU, ne serait-ce pas d'avoir réussi à se regrouper à se vendre, contrairement aux méthodes européennes qui, malgré les effort de Merise puis d'Eurométhodes, ont fini par céder, peut-être plus à la pression américaine qu'à leurs autoflagellations...
Dans cette optique, le plus urgent ne serait pas de poursuivre la réflexion, mais d'unir les forces. Par exemple :
- regrouper, faire communiquer les équipes françaises et européennes qui travaillent sur ce genre de questions
- devenir compétents sur le PU et l'enrichir de notre culture
Le problème est que nous aimons tous mieux (Saccone comme les autres), spéculer et essayer de nous faire un nom sur des idées abstraites que vendre, faire communiquer, et gagner de l'argent. Au fond, cela serait encore plus utile. Pour une part, les Américains ont raison.
Bonsoir Pierre,
Voici un texte pris sur le site http://www.supply-chain.org/ ainsi que
ma présentation à l'ADELI.
Il ne faut pas confondre processus de développement d'application informatique dont Rational Unified Process (RUP) est l'exemple le plus actuel avec "business process" (BP) ou processus d'entreprise ou d'affaire. Je ne t'ai jamais parlé d'UP moi-même.
Ce n'est pas parce que le RUP ne mérite pas d'attention au moment de réaliser des implémentations techniques. C'est parce que la corrélation entre RUP et BP est, à mon avis tout autant qu'avec Merise ou autres "méthodes de conception" (terme que je récuse d'ailleurs), sous-estimée pour choisir les chaînes d'activités à soutenir.
C'est de cette corrélation que flexibilité et réutilisation peuvent réellement découler alors que le RUP s'intéresse trop exclusivement aux "traitements informatiques" qui ne représentent pas d'enjeu en eux-mêmes. Ce n'est pas la technologie Objet qui change quoi que ce soit sur ce sujet.
Modéliser des processus, c'est s'intéresser aux cas pratiques de prise de décision ou d'opération pour en saisir la finalité, les jalons mesurables, etc. ; ce n'est pas travailler sur une méthodologie (informatique). Je ne renie pas, par contre, que le travail pratique fasse naître des formulations ou recommandations d'ordre méthodologique. Je te joins quatre fichiers d'une page qui sont autant d'esquisses d'un prochain (premier) article que je prépare avec un responsable Qualité de Sagem. Ton avis m'intéresse.
Gérard SACCONE GLS Conseil www.gls-conseil.fr
Lettre du Workflow et du Groupware 8, rue de Varenne75007 PARIS 01 42 22 44 00 06 61 74 44 00 gsaccone@gls-conseil.fr
SCOR5.0OverviewBooklet.pdf
Bien en phase avec les préoccupations de communautés comme
le Cigref, par exemple.
- Pour que ce soit vraiment utile, il faudrait aller plus
loin sur les phases de liaison entre la modélisation en général
et la liaison avec les applications informatiques (ERP,
composants).
Sinon, on va continuer à avoir d'un côté des "organisateurs"
(genre Scor) et des informaticiens (vendeurs de produits
logiciels, d'ASP, d'infogérance ou d'équipes de
développement internes).
Dans cette optique, je trouve fâcheuse ton opposition
documents/processus contre données/traitement, qui conduit tout droit
à des guerres de religion d'un autre âge. En revanche, les
expressions entre parenthèses de tes slides (pages 4 et 5) est
constructive. Je tendrais à reformuler dans le genre :
- il faut maintenant s'intéresser aux structures
chronologiques... et plus seulement aux structures algorithmiques
-... à des
définitions de données évolutives et susceptibles de partage (plutôt que
"échangeables"), à un niveau sémantiqu
supérier à celui des nomenclatures statiques et spécifiques
Tu as peut-être d'autres documents qui font la liaison avec la phase suivante, le
développement et l'intégration des
applications informatiques. Tu l'évoques, certes, mais tu ne
dis pas vraiment comment embrayer dessus.
L'EAI évolue dans un sens qui devrait tout à fait te
convenir. Le passage des architectures "intégrées", monolitiques, au
MOM et les travaux de type EBXML vont dans ton sens (et
c'est vrai qu'XML a un caracère "document"). Tu sais sûremnet tout
cela, mais tu n'en parles pas, au moins dans ces documents.
Scor non plus.
Un danger serait, comme Le Moigne, de se perdre dans la
théologie des modèles. C'est un puits sans fond. Il est difficile
de renoncer à ses fascinations (j'y cède moi aussi à mes
heures de loisir, car peut-on se passer de philosophie... ?), mais
dans la pratique, c'est plus de l'extasy que de la vitamine
C.
J'essaie, à l'Asti, de renouer des liens entre les DSI et
les chercheurs. Le fossé est béant, mais des travaux comme les
tiens nourrissent l'espérance.
Quelle est la puissance de la "commission
processus" de l'Adeli ? Peut-on la soutenir ? Peut-on y attirer (si ce
n'est déjà
fait) les énergies d'un Ménager (IDS-Scheer) ou d'un
Doumeingts (Toulouse)... . Peut-être aussi à l'Afai, voire (??) l'Afaq
Specification : a statement of what is required saying as little as possible.
Nirem Nissankie; Formal Specification. Springer 1999
redondance formel/récit (Soulier, Volle)
AMU
dans certains cas, le client connaît l'algorithme
aspects contractuels
use case du PU
démarche en escargot
phases successives
REEL PERCU
Représentation que le système de décision se construit pour son usage, en se repérant par rapport à ses finalités, de l'activité de l'organisation au sein de son environnemnet... est exprimée en langage courant. Tardieu 1/36
Concrètement, il se traduit par une liste d'informations élémentaires
(appelés aussi données, caractéristiques, data, items,
rubriques), complétée par une liste de contraintes d'intégrité
qui en précisent le sens, ainsi que des règles de gestion. Tardieu
1/67
Le réel perçu machinable contient toutes les informations élémentaires,
que l'on veut mémoriser, sous une forme "machinable".
- la liste de propriétés doit être propre ou épurée
- vocabulaire et orthographe normalisés
- codification déterminée ou esquissée plus les contraintes
d'intégrité et les règles de gestion
Tardieu/Nanci/Pascot. Conception d'un système d'information page 68
Sur l'interview de Mélèse
Un message de Braunschweig, et ma répon
Au risque de te décevoir, je fais partie des 1% qui ne tombent pas dans
le panneau de la la mer.
Haton m'a dit la même chose. Mais vous êtes un peu des pros
de ce genre de choses.
En fait c'est toi qui avait fait l'interview de Melese? A cette période
je n'étais pas encore tombé dans la dynamique des systèmes,
seulement un ou deux ans plus tard... mais je reconnais bien les idées
de l'époque.
<<Oui. Je m'en rappelle très bien. J'étais très fier
notamment de lui avoir suggéré l'idée de l'analyse de systèmes
comme une sorte de psychanalyse.
Quant à comparer les idées de l'époque avec celles d'aujourd'hui,
c'est à la fois très semblable et très différent.
Le "business reengineering" de Hammer et Champy ne disait pas grand
chose de plus.
En revanche, on peut verser de vraies larmes sur les espoirs qu'avait fait naître
la croissance, sur l'idée que les partenaires sociaux, dans la ligne
du rapport Sudreau, parviendraient vraiment à une sorte de co-gestion.
Giscard incarnait bien ces vues fines, à la fois réalistes et
généreuses. Mais il n'avait pas le coeur d'un de Gaulle. Et ce
n'est pas de sa faute si le choc pétrolier est arrivé à
ce moment là.
Par rapport à ces espoirs, nous vivons aujourd'hui dans un monde de sauvages.
Ayant été depuis aussi bien (petit) patron (de 1980 à 1885)
que délégué syndical (et secrétaire du comité
d'entreprise, de 1987 à 1989), j'ai pu constater à quel point
il faudrait changer les hommes pour parvenir une telle cogestion. Ni les patrons
ni les salariés ne sont prêts à faire les efforts nécessaires.
Et moins encore les syndicats, qu'ils soient patronaux ou de salariés.
Il y a tout de même eu de magnifiques réussites des coopératives
(ouvrières ou pas). En particulier une boite (grenobloise, il me semble)
dont j'ai oublié le nom et qui a finalement dû céder sous
la pression de concurrents mieux adaptés à un monde dominé
par la Bourse. Et on a préférer oublier ce modèle (qui
n'a pas tout à fait disparu, je crois).
Ce genre de solution synthétique est aujourd'hui aussi impensable économiquement
que, sur le plan religieux, le catholicisme à la Vatican II. Sans doute
pour les mêmes raisons : notre cerveau et nos analyses de systèmes
n'ont pas atteint le niveau suffisant pour gérer des organismes aussi
complexes.
Peut-être que nos successeurs les post-humains y arriveront
Réflexions après l'envoi de ma réponse.
Pourquoi l'échec ?
En partie parce que ces rêves étaient franco-français.
Démocratie française. Nora-Minc.
Mais en même temps, la guerre froide et la consommation pétrolière
montante;
Puis le Club de Rome.
Les contradictions du catholicisme. Renoncement à la doctrine sociale
(bien que sur ce point, Jean-Paul II courageux).