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

DÉLÉGATION GÉNÉRALE POUR L’ARMEMENTÉTAT-MAJOR DES ARMÉES

Ecole Système de SystèmesEcole Système de Systèmes

Tutoriel 2.1 : Urbanisation de systèmes d’information Urbanisation de systèmes d’information et alignement stratégiqueet alignement stratégique

Ecole Système de Systèmes – Tutoriel 2.1 Avril 2008 Diapositive N°2MINISTÈRE DE LA DÉFENSE

IntervenantIntervenant

Daniel KROB

Directeur de recherche au CNRS

Professeur à l’Ecole 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)


Table des matières Table des matières

• Le contexte

• La couche fonctionnelle et métier

• Un état des lieux inquiétant !

• Comment garantir la réussite d’un déploiement logiciel ?

• La vision systémique du système d’information

• La problématique de l’alignement stratégique

• Quels objectifs pour quels tests ?

• La démarche d’architecture collaborative

• Rappels d’architecture système

• Les deux systèmes en jeu

• Vers une démarche d’architecture intégrée

• Eléments de conclusion


Le contexte : la couche informatique haute Le contexte : la couche informatique haute

Langages

Logicielsfonctionnels& métiers

Langage machine

AssembleurFORTRAN

Pascal C

Langages impératifs Langages orienté-objets

Langages structurés

Basic C++ Java

Langages de scripts

Perl PHP

PythonVisual Basic

CAML

Langages fonctionnels

Traitement de texte

TableurLogicielmétier Progiciel

Technologiesd’intégration

ASPOpen source

Applicationsde gestion

Cobol

Bureautique

Langages bas niveau

Applications métiers

LISP

Gestiondes données

Bases de données hiérarchiques

Bases de donnéesrelationnelles

Annuaires

Entrepôts de données

Fichiers

XML

Systèmes defichiers

MySQL

Oracle

DB2

SQL Server

Logiciel de base

CompilateurVM/CMS

Système d’exploitation

Unix MS DOS

Internet

Applications réseaux

Windows

Web

Apache

UML

Sécurité

Voix sur IP

Vérification Modélisation


Un état des lieux qui reste inquiétant … Un état des lieux qui reste inquiétant …

Echecs

Mitigés

Succès

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1994 1996 1998 2000 2002 2004

Succès

Mitigés

Echecs

• 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 d’un progiciel sans modification 13 % : paramétrage léger d’un progiciel 6 % : assemblage de composants achetés 6 % : paramétrage lourd d’un 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 !


… … même s’il semble s’être amélioré !même s’il semble s’être amélioré !

0

20

40

60

80

100

120

140

160

1994 1998 2002

Pertes globales

Dépassements

Pertes sèches

G$

Estimation des pertes de l’économie américaine dans les projets informatiques

0%

50%

100%

150%

200%

250%

1994 1998 2000 2002

Dépassementsde temps

Dépassementsde budget

Fonctionnalitésréalisées

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 s’amé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épensesglobales USA :

250 /300 G$

Sources : The Chaos Study – Standish Group – 1994/2004


Sans doute de vrais problèmes de fond ! 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 logicielreste une activité industrielle extrêmement difficile !

Source : Craig Mundie – CTO Microsoft – 2005

Les grands projets d’ingénierie logicielle font désormais aussi

partie des projets industriels les plus

complexes au monde !

Respect des délais en matière d’ingé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 qu’un gratte-ciel de 50 étages,

mais tient sur un CD ROM !

Arrêté

En retard

A l'heure

En avance

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

100 1K 10 K 100 K 1 M 10 M

En avance

A l'heure

En retard

Arrêté


Les catégories de problèmes en pratique 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 d’entrepô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 l’innovation industrielle • Cas d’école : le système de gestion des bagages de l’aéroport de Denver

• Le syndrome d’Asperger• 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 l’entreprise• 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 !



• Le contexte













Vision systémique & système d’informationVision systémique & système d’information

Logicielapplications

Matérielserveurs

Organisationprocessus métiers

DG : stratégie

DSI : stratégie SI

Système technique

Le système d’information : un système technique couplé à une organisation métier

Organisationmétiers

Organisation métier

Système d’information

Enjeux stratégiques

Propositions de mise en oeuvre

Processusd’entreprise

Systèmestechniques


Le problème de l’alignement stratégique Le problème de l’alignement stratégique

Processus réel« Réalité opérationnelle » (portée ou non par le SI)

StratégieBesoins stratégiques et métiers

? ?

Modèle informatiqueAbstraction de la réalité servant à la mise en

œuvre d’un système d’information

? ?

Systèmes techniquesRéalité technique du système d’information

? ?

Tout manque d’alignement est fatal à un projet informatique


Quels objectifs pour quels tests ? Quels objectifs pour quels tests ?

Création

CréationMaintenance

AnalyseArchitectureDéveloppementTest

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 d’un projet informatique : est il adapté à l’enjeu ?

Analyse (conception fonctionnelle)

• Analyse de besoins

Spécifications fonctionnelles

Architecture(conception technique) Développement

Tests

• Tests unitaires

• Tests de mise en service• Tests d’exploitation

• Tests fonctionnels• Architecture logicielle • Architecture technologique• Architecture systèmes

Spécifications techniques

Etape technique

Interactionsutilisateurs

• Codage

Intégration logicielle

• Tests techniques• Tests d’inté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 ?



• Le contexte













Rappels d’architecture systèmeRappels d’architecture système

Contraintes externes

Produit

Référentiel de la solution

ConceptionExigences

Réalité

1

2

4

? ?

Bénéfices attendusContraintes & besoins des clients

Coûts de réalisationMise à disposition des clients

Référentiel du besoin

Inputs

Eléments de priorisation

Spécifications

3

L’exigence est l’interface entre le référentiel du marché d’un produit (clients, concurrence, environnement, etc.) et le référentiel de l’ingénieur


Les systèmes en jeu : Les systèmes en jeu : technique & organisationtechnique & organisation

Les besoins métiers ne peuvent pas être définis de façon cohérente sansla collaboration active de toutes leurs parties prenantes

Parties prenantes des règles et des processus

Règlesstratégiques

MKG2

Launch interface INT116

Check Price List in Oracle

Place order with this Price List

Verify correct application of

Price

Verify correct NOT application

of Price

Oracle

Launch Interface INT14/3/6

Processus métiers

Processus IT

Créer un nouveau produit

Rôles & responsabilités

Proposer un produit

Valider unproduit

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èmed’information

Interdépendances stratégie, métiers & IT … … interfaces organisationnelles ( )


Le système humain : les parties prenantesLe système humain : les parties prenantes

« Chemin du terrain »

Route A

Route B

Les parties prenantes d’un projet informatique, i.e. l’ensemble 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 l’homme est sans limites …

… connaître le périmètre humain d’un projet informatique est donc crucial pour pouvoir le piloter efficacement !

Système d’information

Canaux entrants

Interfaces système d’informationInterfaces organisationnelles

Conseillers clientèle

Distributiondirecte

Distributionindirecte

Commission-nement

Etudes

Opérationsmarketing

Marketing

Frontal client forfait

Frontal client hors forfait

Back officeSI

Bénéfices clients

Internet

Internet

Pilotage métier

Canaux sortants

Valorisation des besoins


Le système technique : des modèles au codeLe 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

COublier en cours de route à quoi et à qui

va servir la globalité du code !


Comment intégrer les deux systèmes ? (1)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 d’information doit être paramétriser pour pouvoir générer

automatiquement une réservation dans les stocks dès que le taux de succès d’une

proposition commerciale est plus de 75%”

Règles métiers

Golden rules

1 I.e. celles qui concernent le système d’information, 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”


Comment intégrer les deux systèmes ? (2)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 d’information doit être paramétriser pour pouvoir générer

automatiquement une réservation dans les stocks dès que le taux de succès d’une

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 d’objets métiers intégrée avec une

architecture humaine (rôles)

•Taux de succès

•Réservation •Stocks

•Proposition commerciale

•Vendeurs •Achats

•Organisation des ventes

•Marché asiatique

Modèle de données métiers


L’outil clef : l’architecture collaborativeL’outil clef : l’architecture 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 l’alignement stratégique en pratique …


Et si on rêvait un peu : qui a dit agilité ?Et si on rêvait un peu : qui a dit agilité ?

Fuir l’optimum 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 l’architecture et des architectes

• Substituer les charges documentaires au profit d’un actif partagé de tests automatisés



• Le contexte













Quelques éléments de conclusion 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 l’application logicielle dont j’ai 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 l’intégration du terrain réel (clients & utilisateurs finaux) – et pas d’un

terrain virtuel résultant de délégations par non implication – le plus en amont possible dans les phases de conception de ces projets

Documents

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