DÉLÉGATION GÉNÉRALE POUR LARMEMENTÉTAT-MAJOR DES ARMÉES Ecole Système de Systèmes Urbanisation de systèmes dinformation et alignement stratégique Tutoriel.

Présentation au sujet: "DÉLÉGATION GÉNÉRALE POUR LARMEMENTÉTAT-MAJOR DES ARMÉES Ecole Système de Systèmes Urbanisation de systèmes dinformation et alignement stratégique Tutoriel."— Transcription de la présentation:

1 DÉLÉGATION GÉNÉRALE POUR LARMEMENTÉTAT-MAJOR DES ARMÉES Ecole Système de Systèmes Urbanisation de systèmes dinformation et alignement stratégique Tutoriel 2.1 : Urbanisation de systèmes dinformation et alignement stratégique

2 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°2 MINISTÈRE DE LA DÉFENSE Intervenant Daniel KROB Directeur de recherche au CNRS Professeur à lEcole Polytechnique Responsable de la chaire Ecole Polytechnique – Thales « Ingénierie des systèmes complexes » Directeur du master « Ingénierie des systèmes industriels complexes » (Ecole Polytechnique, INSTN, Université Paris Sud)

3 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°3 MINISTÈRE DE LA DÉFENSE Table des matières Le contexte La couche fonctionnelle et métier Un état des lieux inquiétant ! Comment garantir la réussite dun déploiement logiciel ? La vision systémique du système dinformation La problématique de lalignement stratégique Quels objectifs pour quels tests ? La démarche darchitecture collaborative Rappels darchitecture système Les deux systèmes en jeu Vers une démarche darchitecture intégrée Eléments de conclusion

4 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°4 MINISTÈRE DE LA DÉFENSE Le contexte : la couche informatique haute Langages Logiciels fonctionnels & métiers Langage machine Assembleur FORTRAN Pascal C Langages impératifs Langages orienté-objets Langages structurés BasicC++Java Langages de scripts PerlPHP PythonVisual Basic CAML Langages fonctionnels Traitement de texte Tableur Logiciel métier Progiciel Technologies dintégration ASP Open source Applications de gestion Cobol Bureautique Langages bas niveau Applications métiers LISP Gestion des données Bases de données hiérarchiques Bases de données relationnelles Annuaires Entrepôts de données Fichiers XML Systèmes de fichiers MySQL Oracle DB2 SQL Server Logiciel de base Compilateur VM/CMS Système dexploitation UnixMS DOS Internet Applications réseaux Windows Web Apache UML Sécurité Voix sur IP Vérification Modélisation

5 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°5 MINISTÈRE DE LA DÉFENSE Un état des lieux qui reste inquiétant … Succès = projet terminé en respectant le cahier des charges techniques et sans dépassement de temps / budget Mitigé = projet terminé sans respect du cahier des charges techniques et avec dépassement de temps / budget Echec = projet arrêté avant la fin prévue ou jamais mis en service Létude Chaos du Standish Group 71 % : projets de développement 36 % : développement propriétaire traditionnel 19 % : développement propriétaire orienté objet 16 % : stratégie mixte (développement + logiciel) 29 % : intégration de progiciels 4 % : achat dun progiciel sans modification 13 % : paramétrage léger dun progiciel 6 % : assemblage de composants achetés 6 % : paramétrage lourd dun progiciel Nombre de projets étudiés : 8.500 / 13.500 projets – tous les 2 ans depuis 1994 45 % : grands comptes – 35 % : ME – 25 % : PE 60 % : USA – 25 % : Europe – 15% : reste du monde La seule étude dans la durée sur léchec informatique existant au monde !

6 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°6 MINISTÈRE DE LA DÉFENSE … même sil semble sêtre amélioré ! … même sil semble sêtre amélioré ! G$ Estimation des pertes de léconomie américaine dans les projets informatiques Valeurs moyennes des dépassements de temps et de budget et du niveau de fonctions réalisées des projets étudiés La situation semble saméliorer au cours du temps … … mais ne mesure-t-on simplement pas le fait que les ambitions des entreprises et les métriques des responsables informatiques se sont adaptées ? Dépenses globales USA : 250 /300 G$ Sources : The Chaos Study – Standish Group – 1994/2004

7 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°7 MINISTÈRE DE LA DÉFENSE Sans doute de vrais problèmes de fond ! Source : Cale Jones – Patterns of Software Systems Failure and Success – 1996 La vision purement technique : le développement logiciel reste une activité industrielle extrêmement difficile ! Source : Craig Mundie – CTO Microsoft – 2005 Les grands projets dingénierie logicielle font désormais aussi partie des projets industriels les plus complexes au monde ! Respect des délais en matière dingénierie logicielle Développement intra-entreprise Développement externalisé Edition de logiciels Nombre de lignes de codes Même coût que le Stade de France ou quun gratte-ciel de 50 étages, mais tient sur un CD ROM !

8 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°8 MINISTÈRE DE LA DÉFENSE Les catégories de problèmes en pratique Le syndrome de Socrate Catégorie : des projets très stratégiques, mais pas assez « technos » Problème typique : oublier des contraintes techniques incontournables Cas décole : de nombreux projets dentrepôt de données Le syndrome du Concorde Catégorie : des projets trop « technos » et pas assez « business » Problème typique : piloter le projet par linnovation industrielle Cas décole : le système de gestion des bagages de laéroport de Denver Le syndrome dAsperger Catégorie : des projets très stratégiques et trop technos (avec 2 pilotes) Problème typique : déconnecter la stratégie de la réalité de lentreprise Cas décole : les projets ERP corporate … In medio stat virtu ! Un projet qui réussit sait gérer léquilibre entre stratégie, business et technologie le système de réservation de la SNCF Intelligence et autisme !

9 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°9 MINISTÈRE DE LA DÉFENSE Table des matières Le contexte La couche fonctionnelle et métier Un état des lieux inquiétant ! Comment garantir la réussite dun déploiement logiciel ? La vision systémique du système dinformation La problématique de lalignement stratégique Quels objectifs pour quels tests ? La démarche darchitecture collaborative Rappels darchitecture système Les deux systèmes en jeu Vers une démarche darchitecture intégrée Eléments de conclusion

10 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°10 MINISTÈRE DE LA DÉFENSE Vision systémique & système dinformation Logiciel applications Matériel serveurs Organisation processus métiers DG : stratégie DSI : stratégie SI Système technique Le système dinformation : un système technique couplé à une organisation métier Organisation métiers Organisation métier Système dinformation Enjeux stratégiques Propositions de mise en oeuvre Processus dentreprise Systèmes techniques

11 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°11 MINISTÈRE DE LA DÉFENSE Le problème de lalignement stratégique Processus réel « Réalité opérationnelle » (portée ou non par le SI) Stratégie Besoins stratégiques et métiers ? ? Modèle informatique Abstraction de la réalité servant à la mise en œuvre dun système dinformation ?? Systèmes techniques Réalité technique du système dinformation ?? Tout manque dalignement est fatal à un projet informatique

12 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°12 MINISTÈRE DE LA DÉFENSE Quels objectifs pour quels tests ? Maintenance Analyse Test Architecture Développt Répartitions usuelles des temps au niveau technique Les interactions à éviter ! Le cycle classique (en V) de réalisation dun projet informatique : est il adapté à lenjeu ? Analyse (conception fonctionnelle) Analyse de besoins Spécifications fonctionnelles Architecture (conception technique) Développement Tests Tests unitaires Tests de mise en service Tests dexploitation Tests fonctionnels Architecture logicielle Architecture technologique Architecture systèmes Spécifications techniques Etape technique Interactions utilisateurs Codage Intégration logicielle Tests techniques Tests dintégration La demande Les besoins des clients et des utilisateurs finaux Le livrable Une application informatique qualifiée opérationnellement Le seul enjeu réel : comment assurer cet alignement ?

13 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°13 MINISTÈRE DE LA DÉFENSE Table des matières Le contexte La couche fonctionnelle et métier Un état des lieux inquiétant ! Comment garantir la réussite dun déploiement logiciel ? La vision systémique du système dinformation La problématique de lalignement stratégique Quels objectifs pour quels tests ? La démarche darchitecture collaborative Rappels darchitecture système Les deux systèmes en jeu Vers une démarche darchitecture intégrée Eléments de conclusion

14 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°14 MINISTÈRE DE LA DÉFENSE Rappels darchitecture système Contraintes externes Produit Référentiel de la solution Conception Exigences Réalité 1 2 4 ? ? Bénéfices attendus Contraintes & besoins des clients Coûts de réalisation Mise à disposition des clients Référentiel du besoin Inputs Eléments de priorisation Spécifications 3 Lexigence est linterface entre le référentiel du marché dun produit (clients, concurrence, environnement, etc.) et le référentiel de lingénieur

15 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°15 MINISTÈRE DE LA DÉFENSE Les systèmes en jeu : technique & organisation Les besoins métiers ne peuvent pas être définis de façon cohérente sans la collaboration active de toutes leurs parties prenantes Parties prenantes des règles et des processus Règles stratégiques MKG2 Processus métiers Processus IT Créer un nouveau produit Rôles & responsabilités Proposer un produit Valider un produit Règles structurantes de processus métiers …. Directeur général Règles et processus DSI Resp.SI Directeur commercial Directeur production DAF …. Stratégie Métiers & opérations Système dinformation Interdépendances stratégie, métiers & IT … … interfaces organisationnelles ( )

16 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°16 MINISTÈRE DE LA DÉFENSE Le système humain : les parties prenantes « Chemin du terrain » Route A Route B Les parties prenantes dun projet informatique, i.e. lensemble des acteurs de terrain qui sont impactés par le projet, sont les pierres angulaires de la réussite du projet : ce sont eux qui vont le faire réussir ou échouer selon que leurs besoins opérationnels sont ou non bien capturés par le système technique sous-jacent. Il faut donc piloter un projet informatique par des leviers dédiés à sa dimension humaine : sens, bénéfice, légitimité, respect, urgence, etc. La capacité de contournement de lhomme est sans limites … … connaître le périmètre humain dun projet informatique est donc crucial pour pouvoir le piloter efficacement ! Système dinformation Canaux entrants Interfaces système dinformation Interfaces organisationnelles Conseillers clientèle Distribution directe Distribution indirecte Commission- nement Etudes Opérations marketing Marketing Frontal client forfait Frontal client hors forfait Back office SI Bénéfices clients Internet Pilotage métier Canaux sortants Valorisation des besoins

17 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°17 MINISTÈRE DE LA DÉFENSE Le système technique : des modèles au code Documentation technique Génération automatique de la documentation technique Le grand mouvement de fond actuel : lévolution vers une ingénierie technique dirigée par les modèles Génération automatique de code et vérification formelle Modèles (besoins & exigences, contextes & scénarios opérationnels, fonctions & fonctionnements, composants & organes, données, etc.) Bug dans une ligne de code C Oublier en cours de route à quoi et à qui va servir la globalité du code !

18 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°18 MINISTÈRE DE LA DÉFENSE Comment intégrer les deux systèmes ? (1) Règles structurantes des processus métiers Exigences IT 1 Règles définies par les opérationnels Une proposition à plus 75 % de succès doit être prise en compte par les achats. Règle IT induite (DSI) Le système dinformation doit être paramétriser pour pouvoir générer automatiquement une réservation dans les stocks dès que le taux de succès dune proposition commerciale est plus de 75% Règles métiers Golden rules 1 I.e. celles qui concernent le système dinformation, stricto sensu. Golden rules définis par les directeurs Notre organisation de vente doit intégrer les usages commerciaux asiatiques. Vision & stratégie Règles définies par les managers Les vendeurs sont responsables des achats » Rôles & responsabilités Une architecture de besoins intégrée avec une architecture humaine (rôles) Objectifs stratégiques définis par le DG Nous allons nous développer sur les marchés asiatiques

19 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°19 MINISTÈRE DE LA DÉFENSE Comment intégrer les deux systèmes ? (2) Objectifs stratégiques définis par le DG Nous allons nous développer sur les marchés asiatiques Règles définies par les opérationnels Une proposition à plus 75 % de succès doit être prise en compte par les achats. Règle IT induite (DSI) Le système dinformation doit être paramétriser pour pouvoir générer automatiquement une réservation dans les stocks dès que le taux de succès dune proposition commerciale est plus de 75% Golden rules définis par les directeurs Notre organisation de vente doit intégrer les usages commerciaux asiatiques. Règles définies par les managers Les vendeurs sont responsables des achats » Une architecture dobjets métiers intégrée avec une architecture humaine (rôles) Taux de succès RéservationStocks Proposition commerciale VendeursAchats Organisation des ventes Marché asiatique Modèle de données métiers

20 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°20 MINISTÈRE DE LA DÉFENSE Loutil clef : larchitecture collaborative Convergence sur des règles (exigences organisationnelles) Convergence sur un glossaire (objets métiers) Les acteurs impactés Quelques exemples de visions métiers partagées dont on peut ensuite dériver des éléments plus techniques alignés avec les besoins clients Un des ingrédients clefs pour garantir lalignement stratégique en pratique …

21 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°21 MINISTÈRE DE LA DÉFENSE Et si on rêvait un peu : qui a dit agilité ? Fuir loptimum local & rechercher le global Peu utile : « tous les cahiers des charges doivent être validés », « tout le code doit être testé », « des lots de moins de 600 j/h »,... Utile : vous, équipe, êtes responsables de cet actif, avec son passif et son TCO Prime à la simplicité, à la frugalité, à la décroissance de la complexité, … Sortir de la traditionnelle cascade pour piloter par les risques Passer du contrat au vivre ensemble Décloisonner les structures MOA & MOE pour privilégier le point de vue de larchitecture et des architectes Substituer les charges documentaires au profit dun actif partagé de tests automatisés

22 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°22 MINISTÈRE DE LA DÉFENSE Table des matières Le contexte La couche fonctionnelle et métier Un état des lieux inquiétant ! Comment garantir la réussite dun déploiement logiciel ? La vision systémique du système dinformation La problématique de lalignement stratégique Quels objectifs pour quels tests ? La démarche darchitecture collaborative Rappels darchitecture système Les deux systèmes en jeu Vers une démarche darchitecture intégrée Eléments de conclusion

23 Ecole Système de Systèmes – Tutoriel 2.1Avril 2008Diapositive N°23 MINISTÈRE DE LA DÉFENSE Quelques éléments de conclusion Les problèmes techniques existent bien sûr en informatique … Qualité du logiciel (« zéro bug ») Garantie du temps réel et gestion de la distribution Interopérabilité des systèmes techniques Sécurité des infrastructures informatiques … mais on ne peut les traiter que si les problèmes de fond sont résolus A quoi va servir et qui va utiliser opérationnellement lapplication logicielle dont jai la responsabilité technique ? Est ce que mon application va faciliter le travail de ses utilisateurs (création de valeur, amélioration de processus, etc.) ? La réussite des projets informatiques repose donc de façon cruciale par lintégration du terrain réel (clients & utilisateurs finaux) – et pas dun terrain virtuel résultant de délégations par non implication – le plus en amont possible dans les phases de conception de ces projets