Introduction.
L’exposé qui va suivre présente la
naissance de la gamme GCOS7 durant la période allant du début de son
développement mi-70 jusqu’à la première livraison client en 1974.
Ce projet doit être remis dans le contexte historique des
partenariats – actionnariats successifs de Bull :
- jusqu’en 1964 Bull est un
constructeur indépendant qui finance le développement de ses produits (le Gamma
60 et le Gamma 10 en sont les plus représentatifs) et de son réseau commercial
en France et à l’international (principalement en Europe).
- l’émergence du
marché locatif et le nécessaire renouvellement des gammes de produits imposent
en 1964 une alliance avec General Electric faute de trouver les financements en
France. Dans le même temps, l’état français crée CII. Bull prend alors le nom de
Bull General Electric. Formellement deux structures sont crées : une pour la
distribution des produits dans les territoires alors couverts par Bull, dans
laquelle GE est majoritaire, l’autre pour les études et la fabrication en France
dans laquelle Bull est majoritaire. En dehors des produits cette alliance
marquera profondément la compagnie via la mise en place par GE de processus très
normalisés , dans la finance et la gestion du cycle de vie des produits
notamment. Les réflexions préliminaires sur une nouvelle gamme de produits
« unifiée » furent conduites avec GE.
- en 1970, General Electric
vend son activité informatique à Honeywell qui le remplace donc au capital de
Bull désormais dénommée Honeywell Bull. C’est dans cette configuration que fût
autorisé le projet L64 dont nous allons parler. Je préciserai plus loin les
responsabilités des différentes équipes d’études de ce nouvel ensemble.
- En
1976, le gouvernement français décide de rapprocher CII et Bull et de mettre fin
à la coopération européenne au sein d’Unidata. Ce sera l’occasion pour la gamme
L64 d’accélérer sa montée en niveau de puissance. Bull, renommé
CII-Honeywell-Bull, voit alors l’Etat devenir son actionnaire majoritaire.
-
En 1983, Honeywell se retire à son tour de l’informatique; Bull rachète cette
activité. Il intègre alors le management de l’ensemble des territoires (US,
Italie, UK, Asie) et des lignes de produits jusqu’alors pilotés par Honeywell (
L66, L62, Telecom….). En 19XX Bull reprend son nom d’origine.
-
Origine des principaux systèmes commercialisées dans
chaque période
- avant 1964,comme évoqué précédemment, Bull ne pouvait
seule développer la totalité de l’offre réclamée par la clientèle à laquelle
elle s’adressait. Si les Gamma 3, Gamma 5, Gamma 10 et M40 étaient conçus et
fabriqués par Bull, le Gamma 30, un produit moyen de gamme destiné au marché
très porteur de la gestion pour grosses PME, était commercialisé et assemblé
sous licence RCA. Son successeur technologique, le 140, de la lignée des IBM
360, était encore en développement lorsque fut négocié l’accord avec GE; à noter
que ce produit perdit en 1964 un de ses principaux marchés potentiels, celui de
l’administration, réservé dorénavant à la CII que l’état français venait de créer
de toutes pièces.
Sur la période GE, seul l’entrée de gamme, série GE5x sera
de conception française; le moyen de gamme GE100, sera conçu et fabriqué par la
division Olivetti acquise par GE, le haut de gamme GE400 et le très haut de
gamme GE600 étant conçus et fabriqués par la division GE de Phoenix. Certaines
fabrications seront cependant transférées à Angers tandis que le projet 140 fût
arrêté et sa licence vendue aux Tchèques. Il fallut attendre la définition par
GE d’une nouvelle génération pour que Paris puisse se réinsérer. Cette
génération baptisée NPL visait à unifier des architectures et des gammes
quelques peu disparates face à la « compatibilité » des 360, mise en
avant par IBM.
Honeywell reprit une partie du projet de GE à l’exception du
haut de gamme qui conserva son architecture spécifique et se contenta d’outils
de migration pour reprendre les grands systèmes produits par Honeywell avant la
fusion (le marché du transactionnel ne faisait qu’émerger sur ce segment et il
fallait aller vite). Paris obtint la mission du système moyen de gamme dénommé
L64 ainsi que l’ entrée de gamme laquelle consistait en une évolution du GE5x;
Milan, piloté en direct par les US reçut la mission du bas de gamme successeur
du GE100, le L62; en fait seule cette dernière machine présentait un bon degré
de compatibilité avec l’architecture du L64. En synthèse, jusqu’à la livraison
en volume des L64, fin 74, l’origine des produits resta celle mise en place du
temps de GE
A partir de 1976, le rapprochement avec la CII, apporta une
source de clientèle moyen-haut de gamme, à laquelle il fut décidé de fournir une
voie d’évolution au sein de la ligne L64. Outre l’apport de ce nouveau marché,
cela eut comme effet de bord de réduire à partir de 1980, mais essentiellement
en France, les besoins en L66 pour de nouveaux clients. De même, lors de
l’arrivée ultérieure de systèmes L64 à base de technologie CMOS, le volume de
systèmes importés d’Italie sera en baisse. Par contre de nouveaux systèmes, les
Mini6 firent irruption sur ce marché; importés de Boston- Billerica, ils furent
aussi assemblés à Tour.
La période partant de 76 ne vit pas de changement
profond quant à l’origine des systèmes si ce n’est que chaque grande entité
(US,UK, Italie, Bull) tente de fournir son marché avec ce qu’il conçoit et
fabrique localement. On voit ainsi sur le marché US et UK les L66-DPS8 descendre
en gamme au point de rendre le L64-DPS7 sans intérêt pratique sauf migration des
clients existants.
- Enfin, à partir de 1983, UNIX viendra se rajouter au
catalogue, soit produit par Bull soit d’origine partenaires.
L’organisation opérationnelle sur la période de
développement initiale.
Le groupe Honeywell comportait plusieurs
divisions ; de 1970 à 1973 le tandem de direction de l’ensemble (CEO, COO) était
constitué de MM Binger et Keating, auxquels succéda le tandem Keating-Spencer de
1974 à 1976.
Deux divisions traitaient d’ordinateurs :
- La division
Process Control produisant les minis série 16 et 32 ; elle était dirigée par
E.W. Spencer
- La division Information Systems (HIS) produisant les systèmes
et leurs périphériques (carte, bandes, disques, imprimantes; elle était dirigée
par C.W. Spangle.
Chaque division gérait ses structures géographiques, ses
centres de R&D, ses usines, et ses filiales avec peu ou pas d’intégration
entre divisions excepté pour les périphériques. Pour ce qui est de la division
HIS la ligne hiérarchique était la suivante :
- HIS Grande Bretagne à laquelle
était rattachées l’Irlande, l’Australie et l’Afrique du Sud; Cette entité
comportait un petit centre de R&D, partenaire/concurrent de Boston et
consacré aux télécoms (ils avaient développé et installé avec succès un frontal
à base d’une série 16 pour la ligne H2000); et à des applicatifs de type BOMP
(gestion de production). Ils disposaient d’une petite usine en Écosse.
- HIS
Italie, à laquelle était rattachée la Yougoslavie (un futur bon client L66) et
la Libye ainsi qu’une activité export dans les pays de l’Est Européen. Les
centres de R&D de Milan et de Turin ainsi que leurs usines produisaient les
G100, des imprimantes et des bandes.
- HIS North American Opération qui
comportait les centres de R&D de Boston et de Phoenix et leurs usines. ainsi
que les territoires des US, du Canada, du Mexique, de l’Asie,
- Enfin CII-HB
dont le PDG était J.P. Brulé. L’organisation de cette dernière entité était la
suivante :
Un réseau de distribution couvrant la totalité de l’Europe hors
Italie, la plupart des pays d’Afrique francophone, l’Amérique du sud., et une
structure grand export pour les autres pays. Ce réseau représentait une grande
valeur tant par son parc installé que par la capacité des équipes à distribuer
des produits. Honeywell ne disposait pas d’un tel réseau et trouvait là une
opportunité de premier choix.
Des départements de R&D en charge de
concevoir et de livrer au réseau de HB et aux 3 autres entités, UK, Italie, NAO,
des produits pour lesquels ils sont missionnés par HIS; ce sont
Le
département périphérique de Belfort qui produisait essentiellement des
imprimantes à cette époque,
Le département Petits systèmes de Gambetta qui
concevait le GE5x puis le L61; il était dirigé par Claude.Bouvier
Enfin le
département systèmes moyens, dirigé par Marc Bourin. Il était en charge du
système L64. Dans cette phase allant de 1970 à 1974, l’organisation et les
effectifs (en pointe) ont été les suivants :
- direction du projet et
Intégration : J.P. Hardy / E.J. Dieterich , 15 pers
- Architecture et logique
: G. Lepicard ; 123 pers max.
- Logiciel et CAO : T. Chain / J. Becker ; 367
pers max.
- Technologie et Matériels : C. Joly ; 234 pers max.
-
Marketting : J. Fourot / A. Lesseur ; 130 pers max.
- Qualification &
ateliers : R. Hamy / R. Sery ; 298 pers max.
Le mode de fonctionnement:
Dans la quasi-totalité de
ses divisions, GE avait adopté au niveau mondial un mode de fonctionnement par
projet. La responsabilité de chaque projet était assignée à une organisation
sous forme de MISSION. HIS reprit cette approche ; ainsi une dizaine de missions
majeures furent ainsi identifiées et assignées à des responsables et des entités
dûment répertoriées. Pour ce qui concerne les systèmes, la répartition fût la
suivante :
- Grands systèmes L66 NAO centré sur Phoenix
- Moyens systèmes
L64 CHB - France , Marc Bourin
- Petits systèmes L62 HIS-Italy
- Systèmes
d’entrée L61 CHB - France, Claude Bouvier
La mission Systèmes moyens :
Il n’allait pas de
soi que cette mission fût attribuée à CHB. En fait le responsable études de
Boston, Mr Dunkle poussait à un partenariat entre Boston (Waltham et Billerica)
et Paris selon lequel Paris devait agir en tant que sous traitant selon des
modalités de contrôle très strictes, allant même jusqu’à une allocation des
tâches non par domaine technique mais selon les contraintes de charges, semaine
par semaine.
La contre proposition de CHB supposait un leadership de CHB mais
en confiant à Boston certains domaines substantiel et bien identifiés tels que
les contrôleurs de périphériques bandes et disques, le compilateur Cobol,
l’émulateur H200, la base de données IDS. CHB assurait dans ce schéma les
développements de l’unité centrale, du contrôleur de périphériques lents et des
télécoms, du système d’exploitation, de l’émulateur G100 et de l’intégration du
tout, ce qui était indispensable pour piloter techniquement la
mission.
L’état major de HIS arbitra en notre faveur en grande partie grâce
au plus grand réalisme de notre proposition. La responsabilité fût confiée à
Marc Bourin. Celle-ci s’exerçait au niveau mondial et recouvrait pour
l’essentiel les aspects suivants :
- Conduire les développements : bien sur
cela recouvre la directions des équipes de CHB et de Boston. Mais pour ces
dernières cela implique aussi de négocier en permanence que les ressources sont
bien présentes et du niveau requis, ceci représenta un défit permanent.
-
Délivrer aux clients selon le niveau de qualité et de fiabilité requis et mettre
en place les correctifs tant avant livraison que lors de la présence en parc.
Cet aspect recouvre la préparation des filiales de distribution afin qu’elles
soit prêtes pour vendre, démontrer, installer et supporter le produit ce qui
explique les effectifs marketing présentés plus haut.
- Enfin, Assurer un
reporting consolidé sur l’ensemble des fonctions et des tâches du programme et
mettre en place les actions correctives adéquates afin de maintenir le programme
dans le cadre économique et technique qui ont été documentés lorsque le
programme a été autorisé :
° Dépenses d’études, de marketing,…
° Plans de
fabrication, de commercialisation, de maintenance,
° Calendrier de
développement, d’annonce, de livraisons,
° Organisation de revues
indépendantes et contradictoires, les fameuses IPR et CDR,
° États des
revenus de ventes, locations, logiciels, maintenance,
A noter que bon nombre
de ces actions impliquait un fort niveau de négociation avec les entités qui
dépendait de structures hiérarchiques situées hors du département études; par
exemple les réseaux commerciaux, les usines, les autres entités de HIS (UK,
Italie, NAO).
Les avantages présentés par ce mode de fonctionnement étaient
principalement :
° Une responsabilité visible, peu diluée, à la différence
d’un pilotage via des comités
° La possibilité de réagir rapidement,
En
contrepartie quelques inconvénients restent bien présents :
°La nécessité de
négocier en permanence sur les ressources hors juridiction,
° Le fait de
veiller à l’adéquation des ressources en dollars et en qualité,
° Le peu de
prise sur la commercialisation par les réseaux de distribution.
Le département des Systèmes moyens en
1970.
Lorsque la mission nous fut affectée, le département présentait les
caractéristiques suivantes :
Nous partions d’une bonne expérience des
développements matériels acquise notamment avec la 140, et d’une relative
inexpérience des développements logiciels. Cette dernière était compensée par un
grand enthousiasme et par la jeunesse des équipes, la motivation de ces
dernières étant très orientée concepts.
Le poids des outils de développement,
les processus de création de versions de logiciels, nous étaient mal connus et
n’avaient jamais été expérimentés par les équipes.
D’autre part nous avions
une solide expérience de livraison à des clients et du support à ces clients au
travers de nombreuses filiales. Cela avait été appris sur les gammes de produits
commercialisées jusqu’alors (GE400, GE600, Gamma 30, GE100, …)
Notre plan de marche tel que validé au travers de la mission était le suivant : annonce du système en Avril 1973 pour des premières livraisons fin 73.
Plus de détails sur le partage des responsabilités en
logiciel :
La répartition visait à tirer le meilleur parti des savoir
faire de chacun et concernant Paris il s’agissait en outre de tenir en main
directement les composants clés de la livraison initiale et de l’intégration. On
verra plus tard que cette répartition évoluera au profit de Paris, après que le
mode natif ait été délivré en clientèle (1975).
- Étaient développés à Paris
: Le Superviseur, les méthodes d’accès séquentiel et librairies (servant à
stocker les exécutables et leur source), le Macro générateur, le langage de
développement MLP (une sorte de macro assembleur évolué), le compilateur Fortran
et l’émulateur G100. On verra plus loin que cet émulateur était à la base des
premières livraisons en Europe hors UK.
- Étaient développés par Boston : les
outils de développement sous Multics, Le compilateur PL1-HPL (langage dans
lequel était développé l’essentiel des logiciels et qui était sensé être commun
aux L64 et L66), l’assembleur, le séquentiel indexé CKD compatible avec le
format IBM, un jeu de méthodes d’accès compatibles avec les H200, la base de
données IDS2 selon une définition semblable à celle délivrée sur le L66, les
télécommunications sous Cobol , le Cobol et l’émulation H200 ( cette gamme
représentait le cœur du business de Honeywell). On verra plus loin que ce
produit était à la base des premières livraisons à effectuer sur les territoires
de NAO et de UK. A noter qu’un émulateur 360 fut mené jusqu’à l’état de
prototype, mais qu’il fut abandonné parce que la cible en était par trop
évolutive.
Les développements étaient réalisés sur des systèmes Multics, d’abord au MIT puis progressivement investis à Boston puis à Paris.
Plus de détails sur le partage de responsabilité en
matériel:
Comme en logiciel, le partage visait à utiliser les compétences
là où elles existaient et plus particulièrement de réaliser sur Paris les
éléments indispensables à la maîtrise du système et de son intégration. Ainsi
:
- Étaient développés à Paris : l’unité centrale et sa mémoire, le
contrôleur d’unités lentes URC (imprimantes, cartes, cassette, communications
intégrées), l’émulateur G100 les versions du micro logiciel et l’intégration du
système.
- Étaient développé par Boston : le sous système disque, le sous
système bande et l’ensemble matériel et micro logiciel de l’émulateur H200. Les
sous systèmes constituaient des ensembles complexes du fait du haut degré de
compatibilité qu’ils offraient avec le monde IBM et les H200 (interchangeabilité
des media et de data).
Chaque entité développait les tests et diagnostics des matériels de sa responsabilité. Ceux-ci étaient ensuite intégrés à Paris sous un environnement développé dans l’URC.
Évolution des effectifs affectés au
projet:
Comme on le voit dans le tableau ci-dessus l’effectif doubla
globalement dans les deux premières années. Certaines unités durent même
quadrupler en deux ans; ce fut le cas de la direction logiciel. Cette croissance
représenta peut être la plus grande difficulté du projet, d’autant plus que tant
en France qu’aux US, la demande en ingénieurs, notamment logiciel, était très
forte. D’autres compagnies recrutaient, telles que la CII, sur le marché comme
dans nos effectifs. Beaucoup
d’énergie a été consacrée à constituer des équipes, à les former sur le projet,
à les motiver et à développer le savoir faire pratique de jeunes ingénieurs
frais émoulus des options informatiques des écoles et universités. On eut même
recours à des recyclage de filières souffrant de manque de débouchés par le
biais de formations accélérées délivrées par ces écoles avec l’aide de nos
ingénieurs les plus expérimentés.
Certaines équipes furent renforcées par des
personnels issus des filiales; outre ce renfort, leur présence permettait de les
former aux spécificités du produit qu’ils auraient à démontrer, supporter,
dépanner. Ils furent ensuite re-transférés dans leurs unité d’origine.
Enfin
il ne faut pas oublier que la formidable productivité d’une équipe somme toute
pas si imposante fût démultipliée par l’attrait d’un tel projet. La motivation
était à la hauteur de l’enjeu et elle ne faillit jamais; rares furent les jours
et les heures durant lesquels les équipes et les moyens de développement
s’arrêtèrent durant ces cinq années.
A noter que selon les périodes, de quinze à vingt ingénieurs de NEC ont été présents dans nos équipes. Des accords de licence avaient en effet été passées avec ce partenaire de Honeywell. On verra plus loin que ces ingénieurs furent suffisamment efficaces pour livrer avant nous un système pilote en clientèle.
Les coûts de développement sous le contrôle de la
mission.
Le tableau ci-dessus décrit la répartition des coûts de
développement entre Boston et Paris ; ils sont exprimés en dollars courant soit
approximativement 0,76 euros.
Comme on le voit le coût de R&D avant
livraison pilote de la première version du mode natif (R1) voisine les 100
millions d’euros auxquels il convient d’ajouter les investissements industriels
et les coûts de préparation dans les filiales. Sur cette somme 53 millions ont
été affectés aux études du matériel.
La répartition est de deux tiers pour
Paris contre un tiers pour Boston, sachant qu’en 1972 le projets de haut et très
haut de gamme P8 et P9 furent repensés et le P8, affecté à Boston, fût
abandonné.
Dans ces coûts sont inclus les investissements en ordinateurs
destinés aux équipes développement des matériels et des logiciels. Leur
affectation est décrite dans le tableau ci-dessous.
Enfin le tableau XXX
récapitule le volume de code produit sur la période; la première version du mode
natif (R1) aura coûté 47 millions d’euros pour un volume de code de 617 mille
lignes produites par 650 années / homme.
Ces montants d’investissements
peuvent être réduits de 11 millions chacun si l’on veut évaluer les dépenses de
R&D encourues avant que n’arrivent les premiers revenus liés aux livraisons
des premiers systèmes sous émulation. Nous reviendrons plus loin sur ces
chiffres et l’impact de décalage des plans de réalisation.
Le volume de code logiciel:
Le tableau ci-dessus
récapitule le volume de code produit pour chaque version de logiciel avant que
le code induit par la prise en compte des options haut de gamme du système de
convergence CHB plus CII.
On notera plusieurs phénomènes :
- le volume de
la première version du mode natif (R1) représentait plus du double des versions
d’émulation GA-GB. Cela explique qu’il fût nécessaire de procéder à une
intégration progressive plutôt qu’en big-bang. Petit à petit se définirent des
bloc d’intégration suffisamment indépendants pour permettre un certain niveau de
parallélisme entre les équipes techniques. Disons que la maturité en la matière
fût atteinte avec la version R3.
- à lui seul l’effort en outils de
développement représentait la moitié du code de la première version native,
-
certains produits ont été récrits d’où un volume net fin 78 inférieur au total
du code produit,
Un certain nombre de statistiques furent établies à cette
époque,; elles montraient quelques lois empiriques quant à la vitesse
d’intégration, au nombre d’erreur par millier de lignes, …Peu d’information
circulait alors dans la profession en matière d’ingénierie du logiciel. Dans les
années 80 nous avons découvert que les concurrents avaient encore un peu
d’avance sur nous qui étions partis d’une feuille blanche. Les mesures
correctrices furent alors mises en place.
Enfin on se rendra compte plus tard
de la solidité des concepts d’architecture; le système d’exploitation a pu
évoluer sans refonte majeur vers le haut de gamme comme vers le bas de gamme,
incorporer les composants transactionnels et interactifs sur des configurations
à plusieurs milliers de terminaux, aujourd’hui s’insérer dans Internet ou
inclure des processeurs spécialisés fonctionnant par exemple sous UNIX.
L’overhead initial lié à l’architecture fut rapidement compensé par la rapidité
avec laquelle la technologie évolua. (tailles mémoires notamment).
Les étapes de développement du matériel.
Le
calendrier des principales étapes qui est décrit ici, est celui constaté et non
celui du plan initial. En effet, ainsi que nous le décrirons plus loin, le
projet prit environ un an de retard par rapport au plan présenté en début 1970
lors de la définition de la mission. Il faut dire à ce sujet que la demande du
marché ne faisait que croître en termes fonctionnels, sous la pression de la
concurrence, et que nous avions été optimistes quant aux calendriers de
développement , plus particulièrement logiciel ( voir aspect recrutement
mentionné plus haut, entre autres raisons).
Les principes de développement
étaient les suivants :
Nous achetions des circuits électroniques
correspondant à des fonctions, ou bien nous les assemblions pour constituer ces
fonctions. Ces circuits étaient ensuite implantés sur des plaques lesquelles
étaient reliées entre elles par un back panel. Une fois l’ensemble des plaques
disponible, les ateliers d’étude construisait le prototype puis le mettait au
point.
La mise au point donnait lieu à un certain nombre d’itérations sur les
phases amont, jusqu’à ce que les tests machine puisse valider toutes les
fonctions du système telles qu’elles avaient été spécifiées dans les documents
de référence tels que le BL011.
Le premier système produit par l’atelier des
études fut ainsi remis aux équipes du logiciel en Octobre 1972.
Un premier
dossier de fabrication fut simultanément remis à l’usine d’Angers laquelle
sortit son premier exemplaire fin 72. Ainsi que nous l’avons vu plus haut ces
premiers système furent destinés aux équipes d’études tant logiciels que
matériels; par exemple il fallait mettre au point les contrôleurs d’entée sortie
et la connexion des divers périphériques ; coté logiciel les composants du
superviseur ne pouvaient guère avancer sans la disponibilité de ces
prototypes.
Après quelques mois de stabilisation, un dossier de fabrication
fût transmis à l’usine de Brighton aux US, afin de lancer la fabrication seconde
source. Cette démarche était relativement générale dans le groupe Honeywell afin
de sécuriser les capacité à délivrer sur les principaux marchés; et compte tenu
de l’importance aux US du parc H200-2000, les volumes destiné à NAO étaient
élevés, du moins dans le plan initial.
La mise au point se poursuivit
jusqu’en 3T74; bien sur les années 73 et 74 furent à dominante logiciel, et la
premier système destiné aux clients fut délivré par Angers en Octobre 1974. Ce
client était la SEB implanté près de Dijon, ou il succédait à un GE100.
L’émulateur de cette machine qui constituait l’essentiel de la première version
du logiciel (dénommée GA), y donna pleine satisfaction.
Pour plus de détail
sur ces phases, voir les présentations spécifiques qui seront effectuées lors
des sessions dédiées au matériel et au logiciel.
Une étape critique en 74 : des doutes sérieux sur le
projet:
Comme indiqué précédemment, le projet faisait régulièrement
l’objet d’évaluations « indépendantes »; leurs résultats (findings et
projets de réactions) étaient débattus au plus haut niveau de la division IS.
Ainsi, en 1974 plusieurs zones de risques très élevées se confirmèrent : gros
retards dans la fourniture du logiciel, incertitudes sur les performances, forte
dégradation du bilan financier du projet.
Ces constats conduisait à des
décisions fort difficiles, parmi un large éventail de possibilités, dont l’arrêt
du programme ou le transfert de la mission à d’autres unités. Boston dont la
mission sur le P8 avait été arrêtée en fin 72. Je reviens sur ce point dans le
paragraphe suivant
En fait le risque majeur tournait autour du logiciel et ce
risque à lui seul conduisait à la détérioration du bilan financier. Il y avait à
cela plusieurs raisons
- les processus de développement étaient plus lourds
que prévus; nous manquions de savoir faire dans la construction de versions
suffisamment stables pour permettre les développements par incrément et leur
distribution des deux cotés de l’Atlantique. Nous avions sous estimé à la fois
l’effort nécessaire et du fait des difficultés à recruter, sur estimé notre
productivité : l’enthousiasme ne suffisait pas à combler l’écart.
- le
contenu fonctionnel des composants ne faisaient pas l’objet d’un consensus et la
cible n’était pas stable. En fait il y avait deux lignes directrices qui
s’opposaient : l’une ciblait un équivalent fonctionnel du DOS IBM; l’autre
visait plus haut vers l’IBM OS/MVS (cible de l’ex P8 et du P9). En conséquence
certains produits étaient surdimensionnés dans leurs concepts de base, ce qui
conduisait à une consommation de puissance excessive pour les modèles bas de
gamme. Le graphique ci-dessous donne une image du niveau fonctionnel de systèmes
repris, des systèmes concurrents et des options en compétition.
- le temps
passant la demande du réseau commercial en Europe et aux US évoluait aussi;
ainsi l’exigence d’un mode transactionnel et d’une offre télecommunication (hard
et soft) s’imposa dès 1973. Il fallut dégager les ressources
nécessaires.
Les risques révélés en 1974 conduisirent à
plusieurs arbitrages très importants :
Le premier arbitrage consista à viser
un peu d’abord au dessus du DOS puis de procéder par étapes. En fait le niveau
OS/MVS ne fut vraiment approché qu’au milieu des années 80; les premières
versions du mode natif furent recentrées sur un niveau DOS.
Le second
arbitrage consista à donner une priorité absolue au remplacement des G100 et
H200 dont la compétitivité commerciale touchait à sa fin : ce fut le rôle des
versions sous émulations :
- GA, GB pour les G100, basées sur le Superviseur
du futur mode natif,
- et HA pour les H200, basé sur un superviseur de
travail développé à Boston pour les besoin de mise au point des produits sous
leur responsabilité en attendant que Paris puisse livrer un Superviseur natif
stable.
- La mise sur le marché se ferait en deux temps : remplacement du
matériel en parc sans toucher aux applications du client, puis un an plus tard
mise à disposition des logiciels en mode natif (compilateur, méthodes d’accès,
télécommunications..) lequel permettrait aux clients de développer de nouvelles
applications. Seule cette dernière version donnait une capacité à adresser de
nouveaux clients.
De cette manière, les solutions aux difficultés
inventoriées purent être étalées dans le temps et être mise sous
contrôle.
Relations avec les associés de NAO.
Comme
indiqué plus haut, les développements avaient été répartis entre Boston et
Paris. Les échanges étaient denses tant au niveau technique qu’au niveau
pilotage. Avec l’apparition des décalages entre la réalité et les plans, un
« renfort » dans
l’équipe de J.P. Hardy fut désigné par la Division HIS :Mr. Ernie
Dieterich.
Ses premières interventions eurent lieu dès la préparation des
versions d’émulation GA-GB, après qu’un premier arbitrage leur ait donné la
priorité absolue. Il put alors constater que le calendrier avait été repris en
main, au moins pour cette partie du projet.
Par contre le calendrier du mode
natif restait à risque en terme de délai et de contenu. Ce fut l’occasion pour
Boston de proposer un plan alternatif basé sur le matériel du L64, mais
utilisant deux solutions en terme de logiciel :
- pour les clients
d’origine H200- 2000, les développements de l’OS2000 seraient poursuivis et le
résultat serait intégré sous le superviseur 4A Back-up que BCO avaient développé
« en attendant l’arrivée du superviseur natif de Paris »,
- pour
les clients d’origine G100, un GCOS 64 simplifié serait développé à la suite des
version émulation initiales.
- une convergence des deux voies techniques
aurait lieu fin 76.
Une équipe d’évaluation du scénario 4A Back-up fut
envoyée aux USA à partir de la semaine du 16 décembre 1974. Elle était pilotée
par Alain Lesseur,en charge du product planning, et comportait Marcel Lemasson ,
responsable de l’intégration du logiciel, Claude Rolland, responsable du
développement du superviseur, Philippe de Rivet, responsable des mesures de
performances, et Lucien Nègre responsable du contrôle des plans.
Les équipes
d’évaluation travaillèrent jusqu’à fin Janvier 75 et les recommandations furent
présentées le 5 Février par Ernie Dieterich au comité de direction exceptionnel
suivant :
- C.W. Spangle directeur de la division Information Systems
-
R.F. Anderson
- Ugo Gagliardi
- Lee Sheehan
- Marc Bourin et Michel
Rocher
Ernie Dieterich recommanda de poursuivre le plan simplifié proposé par
Paris, ce qui fut entériné, et la recommandation finale fut validée au niveau du
comité de direction de Honeywell group à Minneapolis ( Mr. Renier).
Cet épisode reflète, à l’occasion d’un aléa réel du projet, combien le partenariat pouvait tourner à la concurrence et combien le leadership sur la mission pouvait à tout moment être remis en question.
Relations avec nos associés de NEC
Comme indiqué plus haut NEC
était un partenaire de longue date de Honeywell dont il commercialisait la gamme
H200-2000; il était aussi partenaire de GE par héritage de l’activité
informatique de Mitsubishi; il avait en parc un certain nombre de GE600. NEC
avait donc acheté la licence des P7 et P9 qui allait devenir les ACOS4 et ACOS6
respectivement. Une équipe d’interface résidait à Paris ; elle envoyait
régulièrement les composants que nous avions intégrés afin de constituer la
version nipponisée. Ils travaillaient de même avec Boston notamment sur
l’émulateur H200, mais aussi comme nous
le découvrirons plus tard sur le scénario 4A Back-up, ce qui s’explique,
compte tenu de l’origine de leur business.
Eux-mêmes développaient certains
composants; par exemple ils connectaient leurs propres périphériques, notamment
les disques, qu’il produisaient. De même en logiciel, ils développaient leurs
propres compilateurs. Cette
activité était significativement supportée par le MITI et NEC soignait
particulièrement la visibilité de sa valeur ajoutée auprès de cet
organisme.
Nous eûmes l’occasion d’en voir les effets au moins à deux
reprises sur cette période (il y en aura bien d’autres plus tard).
- Un scoop
dans la presse japonaise : NEC livre le L64 avant CII-HB :
Face à cette
nouvelle, nous organisons une mission à Tokyo, pour découvrir que deux systèmes
avaient été installés à l’université de Osaka, où une équipe de techniciens y
terminaient la mise au point. Il n’empêche que cela faisait désordre et dans le
contexte de compétition avec BCO, nous avions là un challenger de plus, et qui
tenait à démontrer qu’il était le meilleur.
- Proposition de NEC de nous
vendre le compilateur Cobol
Cet évènement se déroula en 1975, de façon
concomitante à l’analyse 4A Back-up.
La proposition était en fait plus
politique que technique et elle n’alla pas à son terme, surtout parce qu’il nous
semblait difficile d’intégrer un troisième centre de développement alors que se
profilait déjà un rapprochement avec la CII. Cependant nous avons acquis une
bibliothèque de test du Cobol, qui nous fut fort utile, car absente de nos plans ainsi que quelques
améliorations du macro assembleur MLP et du tri. NEC prit alors grand soin de
communiquer sur ce succès dans la presse économique et technique.
Ces deux
épisodes montrent combien notre leadership pouvait être contesté lorsque nous ne
tenions pas nos échéances.
Nous aurons l’occasion par la suite de voir que l’investissement de NEC sur la gamme ACOS4
était véritablement stratégique : ils avaient en fait décidé d’en faire leur
gamme principale et de la monter en gamme. Dans le ciblage ils avaient choisi le
MVS et commercialement, leurs commerciaux poussaient le L64 et non le L66. Nous
les retrouverons sur ce terrain une dizaine d’année plus tard.
Le tableau ci-dessus résume de façon simplifiée
l’évolution des plans/
- l’annonce des systèmes a été décalée de 1 an
- le
contenu de l’offre prévue dans le plan initial a été répartie sur 3 ans, et la
disponibilité initiale réduite au simple mode émulation
Conséquences : la
courbe des dépenses se creuse de 23 millions d’euros par an, la courbe des
revenus se décale d’un an et compte tenu de la restriction au mode émulé(qui
oblige à travailler sur parc pendant pratiquement 2 ans) la montée des revenus
est largement inférieure aux attentes initiales.
Ceci est résumé par la
figure 31 ci-dessous. On peut comprendre que le degré de surveillance du projet
se soit accru dès 1973.
L’introduction et les premiers résultats.
Comme
indiqué précédemment, la difficulté de l’introduction d’un tel système ne
présentait pas que des défis techniques pour les équipes d’étude et de
fabrication.
Il convenait de préparer toutes les structures des filiales qui
auraient à travailler avec ce système : les vendeurs, les technico-commerciaux,
la maintenance, les formateurs des clients, …
Il convenait aussi de bien
sélectionner les premiers clients afin qu’ils puissent constituer rapidement des
références tout en validant une dernière fois la bonne marche des différentes
configurations logiciel et matériel, dans un cadre réel et sans risque pour les
clients pilotes.
Enfin il fallait tenir compte des capacité de montée en
charge des usines, pour livrer en qualité.
Le tableau ci-dessus montre
comment cela s’est traduit :
- 21 livraisons furent effectuées dans les neuf
premiers mois, réparties dans 9 filiales de toutes les entités (NAO, UK, Italie
et CHB) plus quelques systèmes chez NEC, 2/3 étant d’origine G100 et 1/3
d’origine H200.
- 175 commandes prises dans les six premiers mois, dès que
les résultats sur les premiers clients furent connus : cela traduit bien que les
attentes de nos clients étaient fortes et qu’elles étaient satisfaites ; le
niveau de prise de commandes en 1975 le confirma : 215.
Les réactions des premiers clients
Les volumes
de commandes présentés plus haut démontrent combien l’opinion des premiers
clients fût globalement positive :
- Les application G100 et H200
fonctionnaient parfaitement et sans changement; aucun besoin de recompilation,
reprise des données sans difficulté particulière.
- Les performances étaient
conformes à ce que nous avions vendu : plus 30% en performances pour un prix
inférieur de 30% à celui du système remplacé.
- Le silence de fonctionnement
de nouvelles imprimantes à bande fabriquées par Belfort faisait
l’unanimité.
Cependant, quelque défauts furent mis en évidence auxquels
il fallut remédier aussi vite que possible :
- l’imprimante était plus
sensible à la qualité du papier que l’ancienne génération; les clients n’avaient
pas été alertés et avaient des stocks.
- Une qualité insuffisante des
connecteurs perturbait les sous-systèmes bandes et disques; un plan
d’amélioration dut être déclenché en liaison avec Boston qui en était le
concepteur; NAO rencontrant les mêmes difficultés, cela accéléra les
choses.
- Le temps d’initialisation du Système était vraiment très long; cela
venait d’options trop ouvertes qui n’avaient pas d’utilité évidente dans le
contexte restreint du fonctionnement sous émulation; il en était de même pour
les procédures de reprise lorsqu’un incident système survenait , ce qui
malheureusement est toujours trop fréquent en début de vie d’un produit. Ces
deux sujets ont mis quelques temps à être corrigés.
- Enfin, nous avions du
mal à délivrer les pièces détachées dans les délais requis; la courbe
d’apprentissage des équipes entraînant aussi une demande d’échanges plus élevée
que normale.
Tout cela était pisté par les équipes de lancement et donnait lieu à des plans d’action surveillés de près par toutes les équipes de développement. Mais la vision globale contribua à renforcer l’enthousiasme de ceux qui en parallèle travaillaient sur le versions à venir : le Mode Natif
L’évolution du Logiciel.
Les arbitrages de 1974
avaient conduit à étaler dans le temps l’arrivée du logiciel en mode natif dont
les fonctionnalités permettaient seules aux clients de réaliser les applications
nouvelles dont ils avaient besoin tout en obtenant des performances encore
améliorées et en phase avec le marché.
C’est en fin 75 que ce mode natif fit
son apparition : une voie d’exécution venait s’ajouter aux voies en émulation;
elle permettait essentiellement aux programmeurs des clients de développer et de
tester leur nouvelles applications;
Le mode natif en multi-programmation et
comportant la première version du moniteur transactionnel TDS ainsi qu’une
nouvelle génération de fichiers plus
adaptée à cet environnement (UFAS) fut mise en clientèle en 1976.
Ce
fût la véritable version de convergence pour les clients issus du G100 comme du
H200. L’excellence du TDS, similaire au
moniteur existant sur le L66, mais disposant d’atouts déterminants liés à
l’architecture du L64 en firent rapidement un très bon outil de pénétration hors
de notre parc. Le graphique suivant montre ainsi la progression régulière du
volume de ce parc.
Chaque année furent ajoutée de nouvelles fonction
logicielles (base de données, mode interactif, performances, outils de reprise
de parcs concurrents…) et matérielles (nouveaux modèles, périphériques,
télécommunication..).Entre temps, l’ensemble des développements pris en charge
par HIS-BCO furent ramenés sur Paris qui avait retrouvé sa
crédibilité.
Ainsi, lorsque survint la fusion entre CHB et CII, la
compétitivité de l’offre et de l’architecture de l’ensemble matériel et logiciel
du L64, permit de retenir cette gamme comme gamme de convergence. La conception
de systèmes plus puissants fut entreprise, et l’extension du GCOS vers des
fonction plus proches du MVS fut
relancée.
Le plan d' avril 1975 :mise à jour des données
financières
Les arbitrages techniques de début 74 avaient donné lieu à
l’élaboration d’un nouveau plan financier pour tenir compte des nouvelles
charges de R&D en regard du décalage du plan de revenus.
Un an plus tard
se tint une nouvelle revue du projet, alors que les plans semblaient stabilisés.
Un nouveau bilan financier fût établi en regard d’un plan de sortie des produits
en cours de développement ( c(est à dire en dehors des hypothèses liées au
rapprochement CHB-CII).
Bien sur un tel plan restait assez théorique au delà
de 3-4 ans puisque l’anticipation des efforts nécessité pour rester compétitif
n’est pas une science exacte. Le tableau suivant résume ce plan :
La réalité fut sensiblement différente puisque la gamme
évolua plus vite en haut de gamme (effet CII). On peut simplement noter que le
revenue directement généré par cette gamme dépassa le milliard de dollars en
88.
Certains peuvent être surpris par l’ampleur des coûts de distribution; il
est important de savoir que la commercialisation de tels systèmes implique
beaucoup de métiers dans les réseaux commerciaux :
- Capacités de
démonstration dans la plupart des filiales ou dans quelques pays aisément
accessibles par les prospects : cela veut dire investir des systèmes, localiser
des démonstrations en fonction des cibles de marché, réaliser des benchmark,
…
- Former les différents personnels de l’interne et ceux des clients,
-
produire les documentations commerciales, les documentations techniques , les
documents d’annonce , très souvent dans la langue du pays,
- constituer des
offres applicatives spécifiques d’un certain nombre de métiers et secteurs
économiques clients sur lesquels les réseaux focalisent leur prospection;
entretenir la compétitivité de ces offres au travers de partenariats avec des
producteurs externes qui sont partiellement financés sous une forme ou sous une
autre,
- Mettre en place des équipes de support central à ces différents
métiers, afin de traiter les cas les plus délicats et de véhiculer le savoir
faire,
- Enfin, et ce n’est pas le moindre effort, la maintenance des
matériels et logiciels en clientèle, bien qu’elle s’accompagne de revenus,
nécessite nombre d’investissements en hommes, en pièces détachées, en outils et
méthodes ainsi qu’ en logistique.
Tous comptes faits, les coûts de distribution représentent
entre deux et trois fois les coûts de R&D.
Traduits en terme de cash-flow
cumulé, la révision du plan décidée début 74 et contrôlée un an plus tard montre
un décalage d’un an du point d’équilibre. Le lancement du projet haut de gamme
nous empêche aujourd’hui de mesurer la pertinence de cette prévision puisque de
nouveaux investissements R&D furent décidés qui ont généré de nouveaux
revenus à partir de 1977 pour les premiers
