Sup'Foucher Management des systèmes d'information Manuel utilisateur

L M D

COLLECTION

Expertise comptable

DSCG 5

Management des systèmes d'information

Manuel & applications

4

e

ÉDITION

Sous la direction d’Alain Burlaud

Philippe Germak

Jean-Pierre Marca

Sup’FOUCHER

« Le photocopillage, c’est l’usage abusif et collectif de la photocopie sans autorisation des auteurs et des éditeurs.

Largement répandu dans les établissements d’enseignement, le photocopillage menace l’avenir du livre, car il met en danger son équilibre économique. Il prive les auteurs d’une juste rémunération.

En dehors de l’usage privé du copiste, toute reproduction totale ou partielle de cet ouvrage est interdite. »

ISBN 978-2-216-12122-9 (nouvelle édition)

ISBN 978-2-216-10575-5 (première édition)

Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit, des pages publiées dans le présent ouvrage, faite sans autorisation de l’éditeur ou du Centre français du Droit de copie (20, rue des Grands-Augustins, 75006 Paris), est illicite et constitue une contrefaçon. Seules sont autorisées, d’une part, les reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective, et, d’autre part, les analyses et courtes citations justifiées par le caractère scientifique ou d’information de l’œuvre dans laquelle elles sont incorporées (loi du 1 er

juillet 1992 - art. 40 et 41 et Code pénal - art. 425).

© Éditions Foucher – 11, rue Paul Bert, 92240 Malakoff – 2012

GRP : expertise JOB : manag⊕syst⊕infor DIV : 06⊕f0020⊕som p. 1 folio : 9 --- 6/9/012 --- 10H23

[

S o m m a i r e

Á Préface

..................................................................................................

Á Mode d’emploi .....................................................................................

Á Programme

.........................................................................................

7

Chapitre 1 e

Introduction ............................................................

Chapitre 2 e

Gouvernance des SI ...............................................

11

21

Chapitre 3 e

Étude de cas sur l’alignement stratégique et sur la définition d’une architecture ................

Chapitre 4 e

La conduite des projets ........................................

65

79

Chapitre 5 e

Étude de cas sur la conduite de projet ..............

171

Chapitre 6 e

Dimension fonctionnelle des SI et progiciels de gestion intégrés ................................................

185

Chapitre 7 e

Étude de cas sur les progiciels intégrés ............

293

Chapitre 8 e

Gestion de la performance informatique ...........

305

Chapitre 9 e

Étude de cas sur la performance informatique .

357

Chapitre 10 e

Architectures et sécurité des systèmes d’information ...............................

359

Chapitre 11 e

L’auditeur en environnement informatique .....

453

Chapitre 12 e

Étude de cas de synthèse ..................................

467

Chapitre 13 e

Corrigé type pour l’étude de cas de synthèse .

487

3

5

Á Index .......................................................................................................

493

Á Table des matières

............................................................................

499

9

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 81 folio : 265 --- 5/9/012 --- 8H51

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

Les progiciels de type « Supply chain management » interviennent au niveau de l’optimisation de la chaîne logistique complète, de la coordination avec les fournisseurs, de l’ordonnancement de la production et de la planification de la distribution.

E.

Architecture d’un progiciel de management de la chaîne logistique

Le schéma de la Figure 6.31 montre l’architecture type d’un tel progiciel.

Pilotage du réseau logistique

Supply Chain Command and Control

Prévision des ventes et planification de la demande

Demand Planning

Gestion du disponible global

Avaible to promise

Planification et ordonnancement de la production

Advanced Planning and Scheduling system

E.R.P

Prise de commandes – Gestion production – stocks

Planification du réseau logistique

Supply Network

Planning

Figure 6.31

e

Architecture progiciel de « Supply chain management »

Prévoir c’est considérer un événement futur comme probable. Prévoir implique une phase de description, une phase d’explication et une phase de prévision proprement dite. Décrire suppose de définir les variables économiques, de les décomposer et de les comparer. Expliquer conduit à rechercher l’enchaînement des causes et des effets. Prévoir implique de modéliser en se fondant sur des hypothèses vraisemblables.

Planifier, c’est faire en sorte qu’un futur proche soit certain. Les prévisions ayant permis la définition d’un cadre, il est alors possible de passer à la phase de planification. Planifier, c’est organiser selon un plan, c’est-à-dire selon une suite ordonnée d’opérations, destinée à atteindre un objectif fixé. Cette planification a pour objectifs l’optimisation de la répartition des ressources disponibles entre les diverses activités ainsi que la recherche de la meilleure utilisation des moyens ainsi affectés à un programme donné.

Le module « Prévision des ventes et planification de la demande » gère le démarrage du processus en supportant les prévisions faites par les commerciaux – optimistes

265

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 82 folio : 266 --- 5/9/012 --- 8H47

266

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

par nature – et consolidant les programmes établis par les planificateurs – pessimistes par vocation – à partir de ces prévisions.

Le module « Planification et ordonnancement de la production » est le cœur du système.

C’est lui qui contient le moteur de programmation qui est en charge de réactualiser les plannings et d’ordonnancer les ressources de production, sur la base des capacités effectives – et non infinies – et à la lumière des événements notifiés en temps réel par le réseau. Ce moteur s’appuie sur une bibliothèque d’algorithmes d’optimisation.

Le module « Planification du réseau logistique » gère les flux de produits au travers du réseau logistique. Il permet l’élaboration de plans tactiques (plans matières, plans d’achats, plans de réapprovisionnement, plans de transport) et la prise de décisions qui tiennent compte de la situation sur l’ensemble de la chaîne. Il assure le rééquilibrage des lots de chargement et l’optimisation du réseau en phase d’exécution.

Le module « Gestion du disponible global » (« Available to promise – ATP ») permet le contrôle de la disponibilité globale des produits finis sur l’ensemble de la chaîne et assure l’interface entre les systèmes de gestion opérationnels du PGI/ERP (Achats, production et ventes) et les autres modules de l’outil de management de la chaîne logistique.

Dans la phase de Prévision/Planification, les besoins bruts exprimés par le module

« Prévision des ventes et planification de la demande » sont communiqués au module

« Planification du réseau logistique » qui les transforme en un besoin net contraint, en tenant compte des ressources disponibles sur l’ensemble de la chaîne. Ce besoin net est communiqué au module « Planification et ordonnancement de la production » qui va élaborer le Plan Directeur de Production.

Ce plan est lui-même renvoyé au module « Planification du réseau logistique » pour qu’il puisse élaborer les plans de mise à disposition des produits finis.

Tous ces plans vont servir de référentiels pendant le cycle opérationnel et pourront

être réajustés en fonction des événements, selon la fréquence et sur la base de critères de décision paramétrés par les utilisateurs.

Dès qu’une demande d’ordre de livraison est présentée au système de gestion des ventes du PGI/ERP, celui-ci élabore une requête pour le module de gestion du disponible de l’outil « supply chain ». Ce dernier analyse si cette demande peut être satisfaite dans le cadre du stock existant ou du plan défini pour le court terme.

Si ce n’est pas le cas, la demande exige de modifier les programmes de fabrication.

L’ordre passe alors dans le module « Planification et ordonnancement de la production » et une date de livraison est fixée, qui tient compte de toutes les contraintes envisageables.

Les résultats sont ensuite communiqués au système de gestion des ventes du progiciel intégré.

Le pilotage de l’ensemble est assuré par le module « Pilotage du réseau logistique » qui regroupe les tableaux de bord et permet de modéliser, de contrôler et de naviguer

à travers toute la chaîne logistique.

L’ensemble est complété par des outils de représentation graphique de la chaîne et des outils d’interfaçage avec le système décisionnel.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 83 folio : 267 --- 5/9/012 --- 8H52

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

F.

Les acteurs du marché

Les promoteurs des progiciels de gestion de la chaîne logistique sont des sociétés comme Chesapeake, i2, Manugistics, Numetrix, Red Pepper.

Les pionniers ont été rapidement menacés par les géants du progiciel intégré de type

PGI/ERP qui ont souhaité être présents sur le marché naissant de la chaîne logistique.

Avant d’être repris par Peoplesoft, J.-D. Edwards avait acquis Numetrix. SAP a développé sa propre ligne de produit APO (Advanced Planner and Optimizer) devenue depuis mySAP.SCM.

Sur le terrain, les différences se mesurent sur les plans techniques et stratégiques.

C’est pourquoi les éditeurs prennent un soin extrême à choisir leurs alliances avec cabinets de conseil, intégrateurs et SSII.

Accroître la fiabilité des processus tout au long de la chaîne logistique implique l’élimination des dysfonctionnements générateurs de retards et des précautions génératrices de stocks. Ceci implique aussi une diminution sensible des retours clients.

Dès lors s’engage un cercle vertueux qui permet d’améliorer les délais, la sécurité et de réduire les coûts tout au long de la chaîne qui part du premier fournisseur et qui aboutit au consommateur.

G. Un réseau plus complexe qu’il n’y parait

1. Retour sur le concept de place de marché

Les premiers projets ont travaillé sur une base réduite, n • 1, 1 • p ou 1 • 1 •

1 ainsi que le montre la Figure 6.32. Cette figure montre aussi les champs respectifs de ce que les Anglo-saxons appellent le « Business to Business », dont nous avons retenu l’acronyme B2B et le champ du « Business to Consumer », dont nous avons retenu l’acronyme B2C.

35

35 Nous avons vu dans la Section 8 du Chapitre 2 les architectures techniques dédiées aux fonctions B2B et B2C.

267

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 84 folio : 268 --- 5/9/012 --- 8H52

268

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fournisseurs

Fournisseurs

Définition stratégie

Gestion des ressources humaines

Gestions des actifs

Gestion des achats

Gestion de la production

Marketing opérationnel et gestion des ventes

Gestion de la distribution

Gestion des flux financiers

Entreprise

Définition stratégie

Gestion des ressources humaines

Gestions des actifs

Gestion des achats

Gestion de la production

Marketing opérationnel et gestion des ventes

Gestion de la distribution

Gestion des flux financiers

Entreprise

Clients-Distributeurs

Définition stratégie

Gestion des ressources humaines

Gestions des actifs

Gestion des achats

Gestion de la production

Marketing opérationnel et gestion des ventes

Gestion de la distribution

Gestion des flux financiers

Distributeurs Consommateurs

B2C : champ de la gestion de la relation client

B2B : Champ de la gestion de la chaîne logistique

(Management de la Supply Chain)

L'industriel recherche aussi le contact avec le consommateur

Figure 6.32

e

Les champs de B2B et celui du B2C

Le système de gestion des ventes et de la distribution va devoir mettre en ligne des sous-systèmes dédiés à deux populations bien différentes : le client distributeur (dans le champ du B2B) et le client consommateur (dans le champ B2C). La chaîne logistique se situe clairement dans le champ du B2B. Nous verrons que la Gestion de la Relation Client pourra se situer dans le champ du B2B comme dans celui du

B2C.

La relation d’exclusivité absolue comme celle qui liait autrefois Citroën à Michelin n’est plus de mise. Un équipementier automobile n’est plus la seule source d’approvisionnement pour une pièce donnée d’un modèle particulier de voiture d’un constructeur.

On voit ainsi se tisser une gigantesque toile d’araignée puisque les constructeurs ont plusieurs modèles, que chaque modèle intègre plusieurs équipements et que ces

équipements sont fournis par plusieurs fournisseurs. En aval, les canaux de distribution peuvent être aussi variés : concessionnaires exclusifs, grandes surfaces, marchés publics d’équipement, exportateurs non exclusifs, etc.

Cette toile d’araignée des chaînes logistiques ne véhicule donc pas que de la coordination et de la complémentarité. Elle véhicule aussi de la concurrence et de la compétition.

De plus, dans une structure complètement maillée comme celle représentée dans la Figure 6.33, chaque entité doit mettre en place de multiples interfaces avec des partenaires qui ne sont pas obligatoirement équipés des mêmes systèmes, respectant les mêmes standards.

La taille et la complexité de cette toile d’araignée varient considérablement selon les secteurs d’activité.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 85 folio : 269 --- 5/9/012 --- 8H47

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

Fournisseurs Entreprise Distributeurs

De multiples interfaces

à gérer vers les clients

De multiples interfaces

à gérer en provenance des fournisseurs

Nécessité de respecter les confidentialités entre acteurs du même rang

Figure 6.33

e

La structure maillée des chaînes logistiques

Dans le secteur des biens de consommation courante il est vrai qu’un nombre limité de grandes chaînes de distribution est alimenté par un nombre limité de grands industriels qui ont eux-mêmes un nombre limité de fournisseurs pour les produits de base et le packaging.

La concurrence est féroce mais les règles de la chaîne logistique peuvent s’appliquer avec une bonne lisibilité.

C’est beaucoup plus difficile lorsque l’un des niveaux comporte un très grand nombre de petits acteurs, comme c’est le cas pour un brasseur qui s’adresse à un vaste réseau de très petits distributeurs comme les bars, cafés et restaurants. C’est aussi le cas pour un grand de l’industrie laitière qui collecte au sein d’un très vaste réseau de producteurs et de coopératives.

Pour éviter à chaque acteur de multiplier les interfaces et pour assurer la neutralité et la confidentialité des échanges dans ce contexte de collaboration-concurrence il faut casser ce maillage n-p (chaque industriel travaille avec n fournisseurs et p clients) et le ramener à un ensemble de relations 1-2. Les échanges se feront au travers de plates-formes d’intermédiation qui relieront chaque industriel à ses n fournisseurs et

à ses p clients, mais par le biais de 2 connexions seulement.

Ces plates-formes d’intermédiation sont les places de marché électroniques

(electronic marketplace). Nous retrouvons ainsi d’un point de vue fonctionnel un concept que nous avons introduit d’un point de vue architectural dans le § 8.J.3.c

du Chapitre 2.

269

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 86 folio : 270 --- 5/9/012 --- 8H52

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fournisseurs Entreprise Distributeurs Consommateurs

B 2B B 2 C

Figure 6.34

e

Le rôle d’intermédiation des places de marché

L’intégration verticale avait conduit aux PGI/ERP. L’exigence d’un nouveau système d’information pour supporter l’intégration horizontale le long de la chaîne logistique a conduit à une nouvelle gamme de logiciels intégrés et, du fait du maillage, au concept de place de marché électronique qui joue le rôle de plate-forme d’intermédiation.

2. Réalisation de places de marché

De multiples projets ont été lancés en 2000 (4 000 recensés par Accenture) mais le bilan s’est traduit par une multitude d’échecs (Markets, Industry Suppliers, Tabadol,

B2Build, Business village, etc.) et par des pertes records pour les pionniers Ariba et

CommerceOne.

Le concept a été reformaté par les grands acteurs de l’industrie sous forme d’une plateforme mutualisée d’achet (e-procurement). C’est le cas de CPGMarket

36

, construite sur l’initiative de Danone, Nestlé et Henkel ; de Transora avec Coca et Pepsi,

Procter et Unilever ; de Covisint avec DaimlerChrysler, Ford, General Motors,

Renault-Nissan et PSA Peugeot Citroën ; d’Elemica avec les 22 acteurs principaux de l’industrie chimique.

C’est aussi parfois sous la forme d’un extranet privé comme c’est le cas pour General

Motors et ses 3 000 fournisseurs (GMSupplyPower).

L’alliance sur ce point précis de grands acteurs de l’industrie connus pour se combattre avec acharnement près des gondoles des distributeurs (Danone avec

Nestlé, Pepsi avec Coca, Procter & Gamble avec Unilever) est un gage de neutralité et de transparence propre à rassurer les autres acteurs.

Ces places de marché ont eu une montée en charge plus lente que l’espéraient leurs promoteurs, mais que le déploiement a exigé de déployer d’intenses efforts d’intégration combinant progiciels et développements spécifiques.

270

36 CPGMarket peut être traduit par marché des produits de grande consommation (CPG = Consumer Packaged Goods).

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 87 folio : 271 --- 5/9/012 --- 8H52

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

Ces plates-formes ont engendré le concept d’« e-Supply Chain », qui a pour ambition de rendre plus efficients les échanges de données entre fournisseurs et industriels, afin de permettre une amélioration des performances dans le cadre du management des inventaires, de la gestion des approvisionnements et de l’optimisation des transports.

Des processus et des protocoles standards sont proposés par la place de marché pour répondre aux attentes des différents acteurs. Les acheteurs en espèrent un large panel de fournisseurs, l’opportunité de créer un prix historique, une meilleure connaissance de la structure des coûts des fournisseurs, la réactivité face aux changements du marché et des facilités de consolidation

Ces places de marché constituent une étonnante réalité économique mais certains cabinets annonçaient qu’elles représenteraient plus de 50 % du commerce interentreprises en 2005, alors qu’elles ne représentent aujourd’hui qu’une proportion bien moindre.

Cette histoire démontre bien ce que valent les prédictions des soi-disant experts auto-proclamés. Mais, si les choses ne se réalisent pas comme prévu, elles n’en

évoluent pas moins vers des situations nouvelles. Les experts avaient prévu il y a

25 ans que les réseaux transporteraient des livres électroniques, mais qui avait prévu qu’ils transporteraient des millions de commandes pour des livres papiers ? Il y a

10 ans on croyait que le commerce électronique toucherait exclusivement le marché des véhicules d’occasion, mais qui aurait imaginé que 50 % des acheteurs de voitures neuves allaient fait leur choix sur le réseau avant d’entrer chez le concessionnaire ?

q

Quel avenir pour ces places de marché ?

Aujourd’hui CpgMarket a disparu après avoir été repris par Accenture en 2005.

Transora a fusionné dans 1SYNC qui ne se présente plus comme une place de marché mais comme un réseau global de synchronisation des données optimisant l’efficacité des chaînes d’approvisionnement. Les prestations offertes par 1SYNC permettent d’éliminer les coûts liés aux échanges de données erronées, d’augmenter l’efficacité de la supply chain et de favoriser l’avancement de standards tels EPC (Electronic

Product Code).

Mais le concept est loin d’être mort : le première place de marché au monde est www.alibaba.com qui réalise 300 M$ de transactions chaque jour.

Fondée en 1999 à Hangzhou, en Chine, Alibaba.com opère sur trois marchés : une plate-forme de commerce international (www.alibaba.com) pour les importateurs

(600 000 entreprises américaines inscrites) et les exportateurs ; une plate-forme locale (www.1688.com) pour le commerce intérieur en Chine et une plate-forme

(www.aliexpress.com) orientée pour les acheteurs qui cherchent une expédition rapide de petites quantités de marchandises. Ensemble, ces marchés forment une communauté de plus de 79,7 millions d’utilisateurs enregistrés dans plus de 240 pays.

Autres places de marché du même type : www.bridgat.com, www.china.cn.

Enfin, pour terminer de boucler la boucle, notons que SAP a annoncé, le 22 mai 2012, le rachat d’Ariba (inventeur de concept) pour 4,3 milliards de dollars.

271

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 88 folio : 272 --- 5/9/012 --- 8H53

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H. Pour une chaîne logistique optimisée

En recherchant les synergies entre les différents acteurs, le management de la chaîne logistique est une clef pour réduire des stocks, améliorer les rendements, réduire les gaspillages et l’obsolescence, diminuer les coûts et augmenter le chiffre d’affaires.

Les organisations qui réussissent la mise en place d’un tel dispositif peuvent en attendre un « pay back » de 6 mois à deux ans. Nous verrons le concept de pay back dans le Chapitre 8. Les exemples de Coca-cola, Dell et WallMart sont les plus souvent cités.

Toutes les études montrent les facteurs clefs pour la réussite :

– réduction de la longueur de la chaîne logistique ;

– planification et réalisation basées sur une collaboration étroite avec les partenaires ;

– processus de conception basé sur la réactivité.

La sécurité reposait sur des stocks de ressources (personnel, délais confortables

(ressource temps), stocks de matières, stocks de produits, etc.). Elle va désormais reposer sur des flux d’information.

Mais cette intégration horizontale, bien que virtuelle, pose elle-même de nombreuses questions, essentiellement tournées vers l’animation d’un processus permanent d’amélioration du partenariat entre les acteurs pour que celui-ci atteigne le seuil critique créateur de synergie et pour renforcer les bases de la confiance mutuelle sur lesquelles repose le travail en partenariat. Cette évolution doit être soigneusement préparée par un important effort d’information, de formation et d’accompagnement.

La réussite relative des plates-formes B2B et le délai nécessaire au succès des plateformes B2C démontrent bien l’importance d’une certaine maturation. Les procédures EDI, malgré leurs limites, avaient bien préparé le terrain aux échanges

électroniques entre les organisations. Pour la majorité des individus en situation de consommateur, la transition était trop brutale. Seule une minorité familière des technologies de l’information a franchi immédiatement le pas. La mauvaise qualité du service logistique fourni par nombre de plates-formes a été aussi un facteur déterminant dans les échecs.

Le secteur a acquis aujourd’hui (2009-2012) cette maturité qui explique ses forts taux de croissance. Au premier trimestre 2009

37

, malgré la crise, le total des dépenses en ligne avait progressé de 28 % sur un an, pour 36 % d’achats en ligne de plus. C’est sur le panier moyen (baisse de 5,4 %) que l’effet la crise s’était fait sentir. Les ventes en ligne en France ont atteint en 2011 un volume de 37,7 milliards d’euros, soit 22 % de plus qu’en 2010.

À l’extrémité de la chaîne, le management de la « supply chain » cède la place

à la « Gestion de la Relation Client ». Quelle rupture justifie l’apparition d’un concept nouveau ?

272

37 Source : Journal du Net Avril 2009.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 89 folio : 273 --- 5/9/012 --- 8H53

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

I.

Gestion de la Relation Client

Les fichiers qui résultent de l’accumulation et de l’archivage de multiples données sur les clients, qu’ils soient consommateurs ou distributeurs, constituent une mine d’informations dans laquelle les spécialistes du marketing peuvent trouver de nombreuses pépites.

Ces données sont multidimensionnelles (client, zone de vente, produit, canal de distribution, période). Elles sont multi-sources (interne, terrain, administration des ventes, logistique, finance, enquêtes consommateurs,...). Elles sont multi-statuts

(prévisions, objectifs, réel). Elles sont multimédias et multi-supports (échanges de courriers, fax, commandes, factures, relances, règlements, avoirs, contentieux, appels téléphoniques, mails, forum, navigation web). Enfin, elles sont multiformes

(quantitative, qualitative).

Sur ces données, les spécialistes du marketing doivent être capables : e de faire des zooms (drill down) ; e de faire des analyses ; e de rechercher des corrélations ; e de faire des manipulations faciles.

Si l’analyse est de la responsabilité de l’informatique décisionnelle, c’est l’enjeu de la Gestion de la Relation Client (Customer Relationship Management) de pouvoir collecter ces données, malgré la diversité des sources et des supports, de les réaffecter à un client donné. Le problème de périmètre surgit d’ailleurs souvent dès qu’il s’agit de fournir les outils d’analyse pour en tirer parti : DSS ou CRM ?

Le champ de la GRC couvre aussi : e le marketing (Analyse des marchés et des comportements clientèles, opérations ciblées) ; e l’avant-vente : support du démarchage des prospects ; e la gestion des forces de ventes (SFA pour « Sales Forces Automation ») : gestion des prises de contact, des rendez-vous, des relances, aide à l’élaboration de propositions commerciales, gestion proactive des clients, réactivité et efficacité sur le terrain) ; e la R&D et la production (Recherche et fourniture de produits et services bien adaptés aux attentes des clients) ; e le SAV/support clients (Retours des sollicitations clients, interventions sur sites) ; e le « Helpdesk » (Sollicitations clients et traçabilité des suites données) ; e l’Assurance Qualité (Pilotage d’indicateurs pertinents).

L’objet de la GRC est d’améliorer l’écoute du client afin de mieux répondre à ses besoins et de le fidéliser. Un projet de GRC consiste donc à permettre à chaque secteur de l’entreprise d’accéder au système d’information pour tout ce qui concerne la connaissance du client.

La mise en place de solutions de GRC dans une entreprise ne consiste pas uniquement à déployer un progiciel, mais à faire évoluer l’organisation de l’entreprise tout entière. Ici encore le sous projet de conduite de changement a une importance

273

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 90 folio : 274 --- 5/9/012 --- 8H52

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

capitale. La mise en place d’une stratégie de CRM/GRC impose de faire évoluer les structures, les compétences et les comportements.

La GRC a donc de multiples facettes, ce qui a parfois brouillé les pistes et conduit

à bien des échecs. Nombre d’entreprises ont été amenés à différer leur projet. Une tendance sensible à la reprise a été enregistrée dès 2005 mais la crise de la fin de la décennie risque de la mettre à mal.

La Gestion de la Relation Client (Customer Relationship Management) couvre tous les aspects des relations avec les clients d’une organisation : outils des forces de vente, centres de contact, techniques de personnalisation appliquées à l’interaction avec un site web, exploitation des bases de données marketing, etc.

[

8

q

Le cycle de vie des PGI/

ERP

A. Les étapes

Le cycle de vie d’un projet PGI/ERP se présente comme tout cycle de vie d’un projet

SI. Nous avons présenté ce cycle de vie dans la Section 2 du Chapitre 4 et avons d’ailleurs souvent choisi des contextes de déploiement de progiciel intégré pour nos exemples et exercices.

Rappelons les étapes du cycle de vie d’un projet SI : e identification et faisabilité ; e analyse des scénarios et choix fondamentaux ; e

étude de la solution détaillée ; e réalisation ; e déploiement ; e exploitation et maintenance (avec une phase d’évaluation qui vient clôturer le projet en tant que tel).

Les éditeurs proposent des découpages qui se rapportent peu ou prou à ce séquencement. À titre d’exemple, voici celui proposé par J.-D. Edwards.

274

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 91 folio : 275 --- 5/9/012 --- 8H53

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

Formation de l’équipe de projet

2

Atelier pilote

4

Nouvelle version

8

Lancement

1

Finalisation formation des utilisateurs

6

Démarrage

7

Analyse des besoins

3

Réalisation technique

5

Bilan périodique

9

Figure 6.35

e

Cycle de vie d’un projet PGI/ ERP (D’après Oracle/J.-D. Edwards)

L’importance du projet PGI/ERP pour l’entreprise impose cependant quelques caractéristiques très fortes que nous allons recenser.

B. Le contrat

Il faut apporter une attention particulière au contrat qui lie les parties : client, éditeur, intégrateur.

Le contrat doit prévenir les dérapages, préparer les remèdes au cas où ces dérapages surviendraient malgré tout, les réparations s’ils ont causé des dégâts.

Il faut dissocier deux contrats : l’un pour l’étude préalable et le déploiement de la solution standard, l’autre pour les ajouts spécifiques – si elles s’avèrent vraiment nécessaires.

C. L’infrastructure

Lors du choix du progiciel, il faut vérifier la compatibilité avec l’infrastructure en place.

Il est parfois nécessaire de procéder à de nouveaux investissements, voire d’intégrer de nouveaux standards, mais il faut éviter d’avoir recours à des techniques mal maîtrisées (Nouvelles plates-formes, nouveaux outils de développement, nouveaux

Systèmes de Gestion de Bases de Données). Si on ne peut éviter le recours à ces techniques, il faut apprendre à les maîtriser dans le cadre d’un projet plus petit et moins stratégique.

Il faut tester en charge réelle et, généralement, plutôt sur-dimensionner car les

PGI/ERP sont gourmands.

Il faut se rappeler que les performances baissent avec le remplissage des bases de données et il faut anticiper un « upgrade

38 réponse au démarrage.

» pour garantir d’excellents temps de

38 Augmentation des capacités de traitement, de stockage et de communication.

275

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 92 folio : 276 --- 5/9/012 --- 8H53

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D. Les risques

Les principaux risques identifiables dans le cours de ce cycle de vie sont :

– dépasser le budget ;

– dépasser les délais ;

– ne pas atteindre les objectifs fixés ;

– ne pas aboutir.

Les statistiques publiées avant 2000 faisaient état de chiffres calamiteux (Dépassement du budget dans plus de 50 % des cas, avec une moyenne de dépassement de près de 200 %, dépassement des délais quasi systématique, échec du projet dans

35 % des cas), mais la perspective de l’an 2000 avait engendré beaucoup de précipitation et beaucoup de projets avaient été lancés sans réelle préparation.

Désormais le cycle de vie est mieux maîtrisé.

Les projets PGI/ERP sont très significatifs à cet égard. Une étude parue en 2001

(Robbins-Gioia), concernant 232 projets, fait état d’un taux d’échec de 51 %. Les causes d’échec sont variées mais on retrouve systématiquement le facteur humain : e incapacité à formuler de manière claire les enjeux, objectifs et besoins à satisfaire ; e sous-estimation de la complexité du projet ; e sous-estimation de la taille du projet ; e absence de réflexion sur l’impact du logiciel sur les processus ; e mauvaise estimation des ressources, du temps et du budget nécessaires ; e trop faible engagement du management général de l’entreprise ; e sous-estimation du besoin de formation et d’accompagnement des utilisateurs ; e résistance au changement ; e attentes peu réalistes sur les bénéfices et le ROI ; e mauvais management des équipes ; e manque de communication.

Cette caractéristique vaut aussi pour la démarche d’évaluation des coûts et des gains.

Les coûts véritablement informatiques sont aisés à comptabiliser. Les coûts liés au temps passé dans des réunions, à évangéliser et assister les utilisateurs sont plus difficiles à identifier. Un des intérêts de l’externalisation est de rendre ces coûts plus aisément discernables car ils s’inscrivent dans une relation client-fournisseur.

276

E.

Les facteurs clefs de succès

L’expérience a permis d’identifier les points clefs de succès d’un projet PGI/ERP.

Nous retrouvons bien évidemment les facteurs recensés dans le Chapitre 4, auxquels s’ajoutent quelques points spécifiques à la nature intégrée du progiciel.

1. Définir les enjeux.

2. Impliquer le Management.

3. Créer une équipe de projet dédiée et motivée.

4. Ne pas faire de cahier des charges.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 93 folio : 277 --- 5/9/012 --- 8H53

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

5. Travailler par processus.

6. Rester standard, sauf raison sérieuse.

7. Prototyper.

8. Planifier avec soin.

9. Accompagner le changement.

10. Savoir s’arrêter.

1. Définir les enjeux

La mise en place d’un PGI/ERP s’inscrit dans un projet d’ensemble qui poursuit un ensemble d’objectifs stratégiques : e améliorer le service client ; e accroître la performance des achats ; e raccourcir les délais logistiques ; e réduire les coûts administratifs ; e faciliter la communication interne ; e favoriser l’innovation ; e faciliter l’accès à l’information pour la prise de décision.

Les finalités du projet doivent être exprimées en termes clairs, bien connus, bien compris et souvent répétés. Une communication spécifique du projet est souhaitable pour faire adhérer l’ensemble de l’organisation au projet.

Le succès du projet ne peut donc normalement se vérifier qu’après le démarrage.

Même si les enjeux sont clairs, tous les participants vont provoquer des dérives.

Les utilisateurs vont chercher à reproduire l’existant et vont demander des améliorations de confort. Les informaticiens vont chercher un démarrage rapide et seront tentés par le sur-mesure. Les consultants vont essayer de faire durer leurs prestations.

Une fois définis les enjeux, il faut les traduire en objectifs concrets facilement mesurables. Par exemple : e monter à 98 % le niveau de service de la distribution ; e ramener à 2 jours le délai de livraison moyen des matières premières ; e limiter à 4 jours le stock de produits finis dans l’entreprise ; e ramener le délai de clôture à 5 jours ouvrés ; e réduire de 50 % le temps passé dans les déplacements ; e ramener à 6 mois le délai entre le lancement d’un projet de développement et la mise du produit sur le marché.

2. Le management doit s’impliquer

La Direction Générale doit participer au Comité de Pilotage pour s’assurer qu’on obtiendra bien les bénéfices attendus. Elle doit prendre les décisions en fonction des enjeux (« Piloter par les enjeux »), écarter les spécifiques non reliés aux enjeux, différer les aménagements accessoires, s’assurer de l’implication de l’encadrement et prendre les décisions d’organisation qui s’imposent.

277

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 94 folio : 278 --- 5/9/012 --- 8H53

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Créer une équipe de projet motivée

Nous avons insisté sur les compétences de l’équipe projet et, en particulier, sur le choix du directeur de projet. Celui-ci est un utilisateur (pas un informaticien ni un prestataire). Il doit être disponible à temps plein. Sa légitimité doit être suffisante

(Il faut éviter de prendre M. ou Mme X, simplement parce qu’il – ou elle – est disponible). Il doit être personnellement intéressé au succès du projet et savoir sur quoi il va être jugé. Il doit avoir la confiance du Comité de Pilotage et de son président agissant en tant que sponsor du projet (cf. § 1.F.2 du Chapitre 4).

Enfin, exigence souvent oubliée, son avenir après le projet doit être clair.

4. Ne pas faire de cahier des charges

Cette recommandation peut sembler paradoxale, mais un cahier des charges décrit en général l’existant. Il n’est utile que si on a décidé un développement spécifique.

La mise en place d’un PGI/ERP consiste surtout à rechercher les meilleures options et les meilleurs paramètres pour satisfaire les besoins.

Plutôt que de rédiger un cahier des charges il faut dresser un tableau des critères de choix. Vous trouverez dans l’ouvrage complémentaire « Le meilleur du DSCG 5 » une étude de cas complète (SiFoud) qui inclut un exercice sur la constitution d’un tableau de critères et sur la sélection d’un PGI/ERP.

5. Travailler par processus

Un projet PGI/ERP est plus qu’un ensemble de projets cloisonnés. Il permet de rationaliser des processus transversaux dans l’entreprise en s’inspirant des meilleures pratiques de la profession.

Il vaut mieux faire l’analyse des processus avant l’implantation plutôt que pendant l’implantation.

6. Rester standard, sauf raison sérieuse

Les développements spécifiques autour des PGI/ERP rendent difficiles les changements de version et gênent la mise en œuvre des nouveaux modules. Il vaut mieux utiliser les fonctions standards, quitte à modifier les procédures de travail.

Si le système existant offre des services qui manquent dans le PGI/ERP et qui donnent un avantage stratégique à l’entreprise, il faut les développer.

Il faut essayer de ne pas modifier la base de données et les fonctions interactives.

7. Prototyper

Mettre très vite l’utilisateur face au produit évite « l’effet tunnel », démystifie le produit et permet de réfléchir en termes d’options et paramètres disponibles.

On peut ainsi commencer très vite les tests sur des données pertinentes.

278

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 95 folio : 279 --- 5/9/012 --- 8H53

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

8. Planifier avec soin

La mise en place d’un PGI/ERP est un projet long et complexe. Les dépassements coûtent cher. S’ils dépassent leurs délais, c’est souvent par manque de planification.

Certains aspects sont souvent oubliés ou sous-dimensionnés, comme la reprise des données des applications existantes, l’interfaçage provisoire avec l’existant lors des mises en place progressives, l’effet des congés, des fins de mois, des clôtures, des budgets...

Il faut investir dans des méthodes et outils de planification et on doit commencer très vite des tests sur des données réelles.

9. Accompagner le changement

Adopter un PGI/ERP oblige à des changements organisationnels et humains. Les utilisateurs doivent adopter des procédures de travail différentes et parfois changer de vocabulaire. Les managers doivent modifier l’organisation des services. Il faut donc s’attendre à une résistance au changement. Nous avons évoqué dans le § 4.B

du Chapitre 4 consacré à la conduite de projet comment s’appuyer sur les synergies et comment faire face à ces antagonismes.

La mise en place d’un progiciel intégré engendre un travail supplémentaire important pour tous les utilisateurs concernés (formations, réunions, paramétrage, initialisation des fichiers, participation aux ateliers-pilotes, tests de jeux d’essai, etc.)

10. Savoir arrêter le projet et passer en production

Il faut résoudre les pannes de jeunesse du nouveau système. Il faut arrêter le projet et passer en production pendant plusieurs mois avant d’entreprendre une vague de retouches car les retouches qui s’enchaînent engendrent une instabilité permanente.

Il est souvent constaté que beaucoup de demandes de modifications disparaissent spontanément avec une utilisation du produit.

F.

Les coûts d’un PGI/ ERP

Beaucoup de chiffres contradictoires sont publiés concernant le coût du déploiement d’un progiciel intégré. Les revues professionnelles ont décrit des grands projets pharaoniques qui atteignaient plusieurs dizaines de millions d’euros alors que le discours « marketing » des acteurs du marché se voulait rassurant. Le paysage est brouillé parce qu’on rencontre en fait des contextes très différents selon les entreprises.

Il faut ajouter à la dépense logicielle (la seule dont font état les éditeurs) la mise à jour matérielle, l’intervention de consultants externes, le paramétrage et la personnalisation du progiciel, la formation et l’accompagnement des utilisateurs ainsi que divers coûts internes.

Tentons d’identifier quelques ratios acceptables, en ce qui concerne le coût par utilisateur, puis en ce qui concerne la répartition des natures de coûts.

279

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 96 folio : 280 --- 5/9/012 --- 8H54

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

280

L’effet d’échelle semble jouer à l’envers à propos du coût par utilisateur : e

15 000 à 30 000 A dans les grands comptes (Exemple Nestlé USA avec le Projet

Best, Nestlé Monde avec Globe, Danone avec Themis, Total avec Unitop) ; e

3 500 à 15 000 A dans les « grosses » PME ; e

2 000 à 3 500 A dans les PME de moins de 100 salariés.

Pourquoi le déploiement s’avère-t-il très coûteux dans les grandes structures ?

La première cause est mécanique : la durée des projets est de 6 à 24 mois dans les organisations importantes alors qu’elle varie entre 2 à 6 mois dans les petites structures.

Ces projets ont été caractérisés par l’importance du consulting, le volume du temps passé en réunions internes (avec le surcoût équipes multiculturelles) et le poids de l’accompagnement. Pour ces grands comptes, le déploiement de l’ERP a été la prétexte à une profonde mutation qui, par ailleurs, avait souvent été mal anticipée.

Le coût normal de déploiement d’un progiciel dans ce type de structure était de 2 000

à 8 000 A par utilisateur.

En qui concerne la répartition des natures de coûts, on peut prendre pour base de départ la règle dite des « quatre quarts » dont les intitulés manquent de précision mais qui a le mérite d’être simple à mémoriser et qui, compte tenu du degré d’incertitude caractéristique de ce domaine, n’est pas trop éloignée de la réalité.

e

Licences logicielles : 25 % ; e

Infrastructure matérielle, logiciel, projet : 25 % ; e

Projet fonctionnel : 25 % ; e

Support et opérations : 25 %.

Certaines études récentes affinent ces proportions et proposent la partition suivante, qui intéresse le projet de conception et de déploiement, indépendamment des tâches d’exploitation et de maintenance : e

Pilotage et gestion de projet : 10 % ; e

Licences logicielles : 20 % ; e

Adaptation infrastructure matériel : 20 % ; e

Paramétrage et mise en place fonctionnelle : 30 % ; e

Formation, support et accompagnement des utilisateurs : 20 %.

Le PGI/ERP ne cesse pas d’être source de coût une fois le projet de déploiement terminé, même si, pendant la phase de maturité de son cycle de vie (exploitation et maintenance), on peut espérer qu’il rapporte plus qu’il ne coûte. Pendant cette phase, outre les coûts de production, il ne faut pas oublier les charges associées au contrat de maintenance qui représentent souvent près de 20 % du prix avant remise.

G. Evaluation d’un PGI/ ERP

Il est indispensable de capitaliser la connaissance au sein d’un centre de compétences qui apporte son soutien aux utilisateurs.

Le bilan à chaud est souvent décevant : mauvaises performances, exceptions mal traitées, rejet des utilisateurs, etc. Il est d’autant plus décevant que la préparation a été trop sommaire.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 97 folio : 281 --- 5/9/012 --- 8H53

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

Une période critique est la fin du déploiement. Il ne faut surtout pas démanteler le centre de compétences à cet instant. Il doit permettre de bien gérer les trois phases de stabilisation, de synthèse et de synergie. On peut alors procéder à un bilan à froid : un PGI/ERP ne fournit des bénéfices qu’à moyen terme et s’avère très rentable lorsqu’on intègre par croissance externe d’autres entités.

Un PGI/ERP fournit souvent des avantages inattendus.

H. PGI/ ERP et PME/PMI

Du côté de la demande, les PME/PMI ont des objectifs semblables à ceux des grosses entreprises : accélérer les flux, éviter les ressaisies, réduire les coûts d’intégration.

Elles ne peuvent se permettre une construction « sur mesure ». Elles doivent opter pour le « prêt-à-porter », en s’adaptant aux règles portées par le progiciel.

Un grand nombre des PME françaises sont adossées à un grand groupe, qui a lui même opté pour un PGI/ERP et fait pression pour que les systèmes d’information soient compatibles.

Du côté de l’offre, les éditeurs sont contraints d’étendre leur marché en dehors de celui, saturé, des grands comptes, mais ils ne peuvent contraindre ce nouveau segment de clientèle au réglage de centaines de paramètres.

Les éditeurs de PGI se spécialisent et adoptent alors une stratégie d’intégration verticale par marché. Le paramétrage devient alors plus facile du fait du verrouillage d’un grand nombre de paramètres dans le cadre d’une logique métier.

Voici l’exemple de découpage sectoriel de SAP All in One : e

Boisson ; e cosmétique ; e bâtiments et travaux publics ; e services ; e distribution ; e automobile ; e produits de grande consommation alimentaires ; e produits de grande consommation non alimentaires ; e industrie discrète.

Cette tendance est partagée par les autres éditeurs Peoplesoft-JDE-Oracle, Microsoft

Navision, Sage-Adonix, Intentia-Lawson-Infor.

Exercice

Accédez aux sites de ces éditeurs et comparez les segmentations métiers de leurs offres pour PME.

Les solutions des exercices sont sur le site www.expertisecomptable-foucher.com

L’implantation coïncide avec un nécessaire effort de structuration et de formalisation des processus. Les PME/PMI ne doivent pas prendre le rôle de maître d’œuvre parce qu’elles n’en ont pas les compétences, mais elles ne doivent pas abandonner la

281

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 98 folio : 282 --- 5/9/012 --- 8H54

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

responsabilité de maître d’ouvrage – tâche aussi difficile – si elles veulent garder la maîtrise du projet.

Pour conclure, nous pouvons rapporter une analyse des coûts d’investissement et d’exploitation relatifs au déploiement d’un ERP par une PME du secteur du bâtiment

39

, réunissant 150 collaborateurs et effectuant un chiffre d’affaires de 17 MA.

Le déploiement concerne 35 postes de travail dont 20 sont utilisés simultanément.

Le petit tableau des ratios que nous avons construit à la fin est particulièrement intéressant.

Il met en évidence un ratio coût exploitation ERP/C.A. de 0,3 %, parfaitement cohérent avec le fait que l’ERP ne couvre pas tous les besoins informatiques de l’entreprise – il faut rajouter toutes les applications métiers liés à la gestion technique des chantiers –, et avec les ratios de la profession (Budget informatique = 0,6 % du C.A.).

Il confirme le ratio de 20 % des coûts de maintenance du logiciel par rapport au coût de licence.

Il propose un coût par utilisateur de 4 200 A qui s’inscrit bien dans la fourchette

3 500-15 000 des PME de plus de 100 personnes.

Il propose une répartition des coûts d’investissement relativement en phase avec ceux proposés plus haut.

Budget Investissement

Assistance à maîtrise d’ouvrage

Système et réseau

Licence progiciel

Paramétrage, développement

Formation

Prestations diverses

37 000

30 000

42 500

6 000

20 500

11 000

Total investissement 147 000

25 %

20 %

29 %

4 %

14 %

7 %

Budget annuel de fonctionnement

Maintenance systèmes et réseaux

Renouvellement systèmes et réseau

Maintenance progiciel

Maintenance périphérique

Échange de données, Internet

Surcoût par rapport au budget annuel avant ERP

13 500

5 000

8 500

11 500

11 500

Total fonctionnement 50 000

32 %

Ratio budget fonctionnement/CA

Ratio maintenance/licence

Coût investissement/salarié

Coût investissement/utilisateur

Coût investissement/utilisateur actif

0,29 %

20,00 %

980

4 200

7 350

282

39

Cet exemple, ainsi que l’exemple Nestlé qui suit, sont repris de « Dimension économique des systèmes d’information », de

J.-P. Marca, chez Hermès Science Publications – Londres, d’après une source Delta SI.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 99 folio : 283 --- 5/9/012 --- 8H54

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

I.

L’histoire d’un grand projet : Nestlé

Au milieu de la décennie 1990, Nestlé SA est un conglomérat d’entreprises indépendantes en matière de gestion opérationnelle. En 1997, une étude démontre que ces entreprises paient 29 prix différents pour la même vanille, fournie par le même producteur.

En Juin 2000, Nestlé SA signe un contrat de 200 millions de dollars avec SAP et un contrat additionnel de 80 millions de dollars avec divers prestataires pour le conseil, le déploiement et la maintenance du nouveau système d’information. Ce système s’appuie sur une nouvelle infrastructure de type datacenter d’une valeur de

500 millions de $.

Nestlé compte sur le nouveau système d’information, bâti autour d’un PGI/ERP, pour uniformiser les règles de gestion au sein de 200 sociétés réparties sur 80 pays.

Ces sociétés emploient 225 000 employés, pilotent 479 usines et engendrent un chiffre d’affaires de 53,6 milliards d’euros.

Lorsque Nestlé lance Globe, il peut s’appuyer sur le bilan d’un projet lancé en 1997 par la filiale américaine : le projet Best (Business Excellence through Systems

Technology). Cette filiale 15 500 employés et fait un chiffre d’affaires de 8,5 Md $.

Lorsqu’il atteindra son terme dans le premier trimestre 2003, le projet Best aura englouti 6 années d’effort et plus de 200 millions de dollars. C’est l’équivalent du contrat signé avec SAP pour le projet global – ce qui montre bien que le contrat logiciel ne représente qu’une partie du coût du projet –, mais c’est un montant qui ne représente après tout que 2,5 % du CA annuel de la filiale américaine, soit 0,4 % par an pendant le cycle de déploiement. Le projet revient à 12 900 $ par employé.

Le déploiement de Best aurait pu cependant coûter moins d’efforts, moins de larmes et moins d’argent. La filiale reconnaît des mauvais choix et des erreurs coûteuses dont le Groupe devra tirer les leçons.

La première difficulté réside dans l’articulation ERP – Supply Chain. C’est un problème classique car il constitue un critère déterminant dans l’atteinte des objectifs

économiques. À l’époque où Nestlé USA fait son choix – 1997 –, la solution de management de supply chain de SAP, APO (Advance Planner and Optimizer) n’est pas mature. Il faut donc recourir à une offre tierce et on mesure mal, à l’époque, la répartition des tâches de gestion de la demande et du disponible entre les modules du PGI/ERP et ceux de l’outil de management de la chaîne logistique.

La deuxième difficulté naît du manque de clarté sur les objectifs du projet. Celui-ci est apparu aux yeux de nombreux utilisateurs comme la solution au problème du passage à l’an 2000. Le recours à un progiciel résolvait implicitement cette difficulté mais la confusion dressait artificiellement une contrainte de planning qui n’avait pas lieu d’être.

Une fois passé ce cap, alors que le déploiement est loin d’être terminé, un sentiment d’échec s’installe, qui ne fait qu’exacerber le principal obstacle à la réussite du projet.

Le déploiement est sérieusement menacé.

La difficulté majeure d’un tel projet (et la règle est valable pour toutes les entreprises internationales) est que le déploiement d’un ERP est toujours le prétexte idéal pour

283

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 100 folio : 284 --- 5/9/012 --- 8H54

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

réaliser le grand rêve des sièges sociaux, à savoir uniformiser au sein d’un corpus de règles unique les pratiques d’une multitude de filiales et de départements jusqu’ici indépendants. Une telle mutation ne peut qu’engendrer des résistances et s’opérer dans la douleur. Jeri Dunn, le VP et CIO

40 de Nestlé USA, a reconnu rétrospectivement que les responsables avaient largement sous-estimé les difficultés impliquées par le changement de culture au niveau local et par le bouleversement de processus de gestion établis de longue date.

[

9

q

Bilan de l’intégration

A. Aspects positifs et aspects critiquables

Cet engagement vers l’intégration sur la base de la trilogie (ERP/SCM/CRM –

PGI/GCL/GRC en français –) a-t-il tenu ses promesses ? La réponse est mitigée.

Pourquoi ?

En ce qui concerne les aspects positifs, nous pouvons recenser l’unification des outils et des processus, la facilitation de la consolidation pour toutes les entreprises qui souffraient de l’hétérogénéité des systèmes de gestion ;

Nous pouvons aussi citer l’identification et la diffusion de « bonnes pratiques » de gestion (les fameuses « best practices »).

Parmi les aspects critiquables : e nivellement « par le bas » qui a conduit à la disparition sur certains sites d’outils métiers spécifiques dont les utilisateurs appréciaient l’adéquation et qu’ils s’étaient appropriés ; e mauvaise adaptation à l’e-business ; e complexité plus grande du réseau interentreprises ; e apparition de nouveaux besoins ; e architecture encore trop marquée par un découpage en fonctions plutôt qu’en processus ; e prise en compte un peu lente des technologies web.

Cette automatisation des flux entre acteurs économiques, qui constitue ce qu’on appelle aujourd’hui l’e-business, n’est pas l’apanage d’un secteur particulier d’une

économie. Elle concerne toutes les entreprises, en particulier les grandes entreprises traditionnelles qui ont su repenser l’architecture de leur SI.

Une « entreprise globale » de la fin de la décennie a 30 à 50 applications majeures et continue à dépenser 25 à 40 % de son budget SI pour définir une cohérence entre ces applications : le PGI/ERP ne couvre pas tous les besoins.

Les exigences de cohérence sont plus fortes encore avec les vagues de fusions et acquisitions, avec les phénomènes de délocalisation.

Comment assurer la cohérence ? Est-ce en poursuivant l’intégration sur le mode ERP ou avec d’autres moyens ?

284

40 Nous vous rappelons que le CIO (Chjef Information Officer) est l’équivalent du DSI (cf. 2.C.3).

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 101 folio : 285 --- 5/9/012 --- 8H54

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

Les éditeurs de PGI/ERP ont su s’adapter en intégrant les technologies web

(Peoplesoft) et en mettant l’accent sur les processus transversaux (SAP).

Les architectures de la chaîne logistique ont su évoluer vers les places de marché.

La répartition des tâches entre PGI/ERP et Gestion de la Chaîne Logistique est mieux gérée. Ces outils développent des composants « front-office » en s’interfaçant avec les outils CRM et « Centres de Contacts », – ex. Centres d’Appels – ou en intégrant directement des fonctions de ce type (configuration produit, forces de ventes, marketing opérationnel, marketing comportemental).

B. Le PGI est-il au cœur des systèmes d’information ?

Oui, encore aujourd’hui : e parce que les investissements ont été (et restent encore) colossaux et qu’il faut les digérer ; e parce que le besoin d’optimisation des processus internes reste prioritaire par rapport aux besoins d’échanges avec les partenaires qui restent couverts en majorité par les procédures classiques de l’EDI ; e parce que les axes d’évolution que nous avons évoqué en divers points de l’ouvrage

(places de marché, développement du font-office avec la GRC/CRM, intégration des fonctionnalités et technologies web 2.0, architectures AOS-ESB) sont complexes à maîtriser et encore trop peu matures.

Mais ce sont des tendances qu’il ne faut pas ignorer car elles permettront à terme

– mais moins vite que certains l’imaginent aujourd’hui – d’imbriquer plus aisément les meilleures briques logicielles (dont peut-être certains modules des PGI/ERP) dans un tout cohérent.

C. Quel impact pour la profession comptable

La logique du PGI/ERP est en accord avec la logique événementielle et multidimensionnelle du processus comptable : e intégration des étapes du cycle d’exploitation (achats, fabrication, expéditions, facturations, paiement...) pour aboutir à la comptabilisation automatique des

écritures traduisant les événements de la vie de l’entreprise ; e lien entre comptabilité financière et comptabilité de gestion à partir de la même source d’information ; e simplification des opérations de collecte par une saisie unique des événements décrits dans toutes leurs dimensions.

Le déploiement d’un PGI/ERP apporte de multiples avantages à la profession comptable : e

élimination des tâches sans valeur ajoutée (ressaisie d’informations et contrôle d’interface entre le système comptable et les systèmes opérationnels) ; e réduction des erreurs de saisie et information plus fiable ; e contrôle continu en place d’une intégration comptable par interface en fin de période, juste avant la clôture de comptes ;

285

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 102 folio : 286 --- 5/9/012 --- 8H55

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

e facilitation des tâches de contrôle de l’information financière ; e intégration de toutes les données de gestion au sein de bases communes, cohérentes et partagées par tous les modules fonctionnels ; e gestion des risques client plus réactive ; e

reporting financier et pilotage de la performance plus efficace.

Mais elle est aussi porteuse de risques : e l’automatisation et l’intégration permettent à tout moment et dans un délai très court, « de modifier, supprimer, créer, sélectionner ou reconstituer un volume important

d’informations, voire l’intégralité d’une comptabilité » (CNC 1992) ; e cette menace conduit au nécessaire développement d’un système de contrôle fiable qui assure que l’organisation reste conforme à l’architecture du système intégré

(développement de l’audit interne et de guides de procédures) ; e une absence de formation et d’accompagnement des acteurs peut annihiler l’ensemble des objectifs du projet PGI/ERP et induire des effets néfastes pour l’organisation ; e la définition du projet doit être particulièrement précise pour éviter les conflits interpersonnels et les conflits de contenu ; e un risque fournisseur (l’éditeur du PGI/ERP) plus critique.

Le Conseil Supérieur de l’Ordre des Experts-Comptables a défini 9 critères pour assurer la qualité de l’information comptable. Chacun de ces critères est impacté par le déploiement d’un PGI/ERP ainsi que le démontre le tableau suivant :

Critère

Pertinence

Fiabilité

Délai

Clarté

Flexibilité

Verifiabilité

Conformité

Neutralité

Comparabilité

Impact PGI

Oui si les règles de gestion et les codes clefs sont bien définis au départ

Reportée vers les opérationnels qui saisissent les informations de base

Plus rapide si les utilisateurs se sont approprié l’outil

Forme du reporting choisie par les utilisateurs

Oui mais dans un cadre restreint les paramètres choisis à l’initialisation

Disponibilité des outils de reporting et d’analyse

Lié à la capacité d’auditabilité offerte par le produit

Oui si les règles de gestion sont bien définies

Aisé si les fonctionnels maîtrisent les outils décisionnels associés

Les PGI/ERP restent encore aujourd’hui au cœur des systèmes d’information, complétés par les outils de gestion de la Chaîne Logistique et de la Relation

Client. Ils ont profondément modifié les pratiques comptables.

286

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 103 folio : 287 --- 5/9/012 --- 8H56

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

[

10

q

Tendances

A. Architectures

Nous verrons au Chapitre 10 l’évolution des architectures qui met en concurrence plusieurs formes d’intégration : intégration applicative, intégration via EAI/ESB, intégration via BPM.

L’architecture des PGI/ERP du marché démontre bien cette évolution. La poursuite de l’intégration applicative a conduit à étendre les fonctionnalités des progiciels pour prendre en charge les processus de la Gestion de la Chaîne Logistique – GCL –, ceux de la Gestion de la Relation Client – GRC –, ainsi que de nouveaux processus dans le champ de la gestion du Cycle de Vie des Produits (PLM pour Product Life Cycle

Management), de la gestion de la Relation Fournisseur (SRM pour Supplier Relationship

Management) ou de la gestion des documents (Enterprise Content Management).

L’architecture du logiciel J.-D. Edwards, aujourd’hui intégré dans l’offre Oracle, démontre bien cette tendance (Comparez avec la liste des fonctions présentées dans le § 6.C de ce chapitre) : e

Management du cycle de vie des actifs :

– gestion des actifs du bilan (Capital Asset Management),

– maintenance préventive des équipements (Condition-Based Maintenance),

– analyse des coûts (Equipment Cost Analysis),

– affectation des ressources (Resource Assignments),

– prévisions d’investissements immobiliers (Advanced Real Estate Forecasting),

– analyse des coûts du parc immobilier (Real Estate Analytics),

– gestion des Actifs immobiliers (Real Estate) ; e

Gestion de la Relation Client :

– détermination des prix (Advanced Pricing),

– création de scripts pour les réponses aux sollicitations clients (Branch Scripting),

– gestion des cas clients (Case Management),

– personnalisation du service client (Customer Self-service),

– planification de la demande (Demand Scheduling Execution),

– outils pour les vendeurs nomades (Mobile Sales),

– gestion des contacts via divers canaux (Multichannel Interaction Manager),

– outils informatisés pour les forces de vente (Sales Force Automation),

– traitement des commandes (Sales Order Management),

– gestion des niveaux de service (Service Management),

– conseil en solutions (Solution Advisor) ; e

Gestion Financière :

– gestion des comptes fournisseurs (Accounts Payable),

– gestion des comptes clients (Accounts Receivable),

– compabilité analytique (Advanced Cost Accounting),

– comptabilité des dépenses (Expense Management),

287

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 104 folio : 288 --- 5/9/012 --- 8H58

288

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

– gestion des immobilisations (Fixed Asset Accounting),

– comptabilité générale (General Ledger) ; e

Gestion du Capital Humain :

– interface avec les progiciels de paie nationaux (Interface with national Payroll),

– personnalisation du service aux collaborateurs (Employee Self-service),

– recrutement par Internet (eRecruit Human Resources Management),

– personnalisation du service aux décideurs (Manager Self-service),

– suivi d’activité (Time and Labor) ; e

Gestion de la Chaîne Logistique :

– gestion des commandes (Customer Order Management),

– spécificités industries agroalimentaires (Food and Beverage Producers),

– logistique de production (Logistics Manufacturing),

– SCP (Supply Chain Planning) ; e

Achats :

– espace acheteur (Buyer Workspace),

– recherche de fournisseurs (Operational Sourcing),

– gestion des achats et des approvisionnements (Procurement and Subcontract

Management),

– personnalisation du service aux fournisseurs (Supplier Self-service).

Même tendance chez SAP où le sigle R/3 disparaît. Une offre globale SAP Business

Suite regroupe MySAP.ERP (la composante PGI), MySAP.SCM (la composante

Chaîne Logistique), MySAP.CRM (la composante Gestion de la Relation Client) et d’autres modules.

La communication inter-applications est assurée par Netweaver, présentée comme une plate-forme d’intégration. Celle-ci permet de mettre en place une architecture de services d’entreprise (ESA), le schéma directeur de SAP pour toutes les solutions orientées web services. Il devient ainsi possible de communiquer avec des offres tierces ou avec des solutions spécifiques développées par l’entreprise.

Allons-nous alors vers le concept de PGD (Programme de Gestion Désintégrée) ?

Ce n’est peut être pas qu’un gag ! Ecoutons Christophe Raymond, Directeur

Technique de l’éditeur Cegid :

« L’ERP du futur devra donc mettre en œuvre trois dimensions : opérationnelle, pour répondre aux exigences de gouvernance ; décisionnelle, pour que les dirigeants puissent prendre les bonnes décisions pour l’avenir ; collaborative, afin d’accentuer les liens avec l’écosystème.

L’orchestration de ces trois dimensions suppose la désagrégation de l’ERP traditionnel et le recours à la notion de « service ».

Modulaire et basé sur une architecture orientée services (SOA), l’ERP nouvelle génération selon Cegid est flexible, simple à installer et son coût total de possession

(TCO) réduit. Grâce à des capacités élevées d’intégration, il se compose, se décompose et se recompose à l’infini. » Cette désintégration n’a bien sûr qu’un but, permettre l’intégration par BPM (Business Process Management) au niveau du poste de travail, telle que nous la définirons au Chapitre 10.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 105 folio : 289 --- 5/9/012 --- 8H58

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

B. Modes de fourniture

1. de l’

ASP au SaaS

Le mode FAH/ASP (Fournisseur d’Applications Hébergées/Application Service

Provider), qui a évolué récemment en SaaS

41

(Offre Software as a Service combinant mode hébergé, tarification à l’abonnement et accès 100 % web), avec l’émergence du Cloud permet à des utilisateurs d’accéder à un PGI/ERP à travers un réseau IP, au moyen d’un navigateur jouant le rôle de client sur le poste de travail.

Le progiciel doit délivrer ses résultats sous forme de pages web (architecture

web-computing).

Le prestataire qui souhaite fournir des services de bout en bout (edge-to-edge) au travers de multiples couches réseau doit maîtriser des architectures complexes et des technologies pointues.

Il doit intégrer sur ses plates-formes des équipements matériels (serveurs, routeurs, commutateurs), des logiciels et des services de support, et exploiter le tout dans le respect des indicateurs de performances (KPI pour Key Performance Indicators) exigés par les clients en matière de qualité (QOS pour Quality Of Service) et de sécurité.

Être prestataire SaaS consiste à fournir des services applicatifs au travers d’un réseau

IP. Ceci implique : e

La conception du service (en sélectionnant diverses solutions parmi les offres des

éditeurs, voire en devenant éditeur) ; e

L’hébergement : Un prestataire SaaS est hébergeur : il gère les mises à niveau, la sécurité système, le support technique et d’autres services à partir d’un site distant des locaux des utilisateurs.

e

L’exploitation du service sur les serveurs et le support aux utilisateurs (métier classique d’infogérance. Le prestataire charge les données de l’utilisateur et la logique métier de son « business » dans une application packagée, puis personnalisée dans le champ de la flexibilité des paramètres du logiciel. Il exploite l’ensemble au sein un centre d’opération éloigné (DataCenter) e

La diffusion à travers le réseau (métier d’opérateur).

Les réticences du marché s’effacent à la vue de la réussite du pionnier Salesforce.com.

Le cabinet Gartner prédit à ce modèle, qui séduit les fournisseurs par son caractère récurrent, une croissance à deux chiffres au cours des prochaines années.

En proposant à leurs clients, en mode SaaS, un socle commun d’applications avec tout un panel de modules ERP étendu (CRM, Supply chain, décisionnel) qui peuvent

être exploités avec des intégrations par processus, en fonction des besoins, à un coût n’excédant pas 150 A par utilisateur et par mois, les éditeurs vont bouleverser le modèle économique habituel de l’ERP.

41 Nous repositionnerons l’offre SaaS par rapport aux autres offres du mode « cloud » dans le § 1.M du Chapitre 10.

289

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 106 folio : 290 --- 5/9/012 --- 9H14

290

Management des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. L’effet web 2.0

Encore jugés futuristes et peu assimilés par les entreprises, les principes du web 2.0

(assurant l’interactivité du web et la transformation d’internautes passifs en acteurs) devraient favoriser la multiplication des réseaux sociaux, nouvel avatar du collaboratif (pour le grand public, le phénomène Facebook a marqué 2007). Du côté des entreprises, c’est probablement dans le domaine de la gestion des RH ou de la relation commerciale qu’ils devraient s’imposer au sein des ERP nouvelle génération.

Comment concilier deux visions aussi opposées que l’informatique structurelle autour de l’ERP et l’informatique collaborative autour du web 2.0 ?

L’ERP structure le travail, impose des processus formalisés, force la discipline de travail selon une approche « top down ». Le web 2.0 vise à faire apparaître une intelligence collective en stimulant la créativité et l’interactivité des utilisateurs.

Si l’on considère que l’hémisphère gauche du cerveau décompose les problèmes et analyse, alors que le droit s’intéresse au tout et innove, on peut alors établir la relation : cerveau de gauche = ERP alors que cerveau de droite = Web 2.0

Le grand challenge des années 2010-2020 sera de concilier les deux approches et de tirer de chacune ce qu’elle a de meilleur.

Les outils ou modules GRC/CRM sont en avance sur ce point. On note déjà le couplage de la GRC avec la messagerie, l’intégration de certaines techniques issues des centres d’appels, telles que le lancement automatique ou les enregistrements des communications, puis leur indexation, l’ouverture des outils GRC vers les plates-formes applicatives : Oracle-Siebel-CRM vers Microsoft Sharepoint, le développement de Chatter (panoplie d’outils type Facebook et Twitter) dans

SalesForce.com.

C. Mobilité

1. Pourquoi la mobilité ?

Il y a trois motivations pour développer des solutions nomades : e

Tirer avantage du mode interactif dans un plus grand nombre de situations ; e

Homogénéiser ou sécuriser les processus pour qu’il n’y ait plus d’interruption dans la chaîne de traitement ; e

Engendrer de nouveaux revenus.

Nous allons progressivement passer d’une logique où la mobilité est l’exception vers une approche où le nomadisme est la normalité.

Les solutions technologiques ne manquent pas. Le frein a souvent été le facteur humain (d’où l’importance de la conduite du changement).

Il a fallu dix ans pour diffuser la technologie Blackberry, née en 1998 au Canada, alors qu’une étude Ipsos avait démontré que l’utilisation de cette technologie ou d’une technologie voisine, dans différents segments de métiers et à différents niveaux hiérarchiques, engendrait un gain de près d’une heure par jour.

GRP : expertise JOB : manag⊕syst⊕infor DIV : 12⊕f0020⊕Chap06 p. 107 folio : 291 --- 6/9/012 --- 19H44

. . . . . . . . . . . . . . . . . . . . .

Chapitre 6. Dimension fonctionnelle des SI et progiciels de gestion intégrés q

L’évolution vient des nouvelles générations (la fameuse génération Y) et des usages

« Grand Public ». Cette tendance pousse à l’usage des outils personnels dans le périmètre professionnel. C’est le fameux BYOD (« Bring Your Own Device ») qui ravit les directeurs financiers (moins d’investissements) mais effraie les DSI (Risque pesant sur la sécurité des SI et la cohérence du parc).

Le tableau suivant démontre comment on passe des nouveaux usages aux applications.

Scénario d’utilisation

Utilisation à plein temps pour ceux dont la fonction exige le nomadisme (commerciaux, inspecteurs de maintenance)

Utilisation occasionnelle pour les managers qui voyagent

épisodiquement

Travail à la maison

Continuité des affaires (depuis l’indisponibilité temporaire d’un salarié jusqu’à la catastrophe paralysant l’entreprise)

Nouveau service à l’intention des clients

Terminal adapté

Ordinateur portable, téléphone et/ou PDA fournis par l’entreprise

Application typique

Accès permanent aux applications de gestion

(messagerie électronique, intranet, extranet, VOIP, visioconférence)

Messagerie électronique, intranet et quelques applications

Outil du même type que ci-dessus fourni par l’entreprise, outil personnel ou terminal public

Outil personnel

Tout moyen de communication encore disponible

Toute innovation envisageable

Messagerie électronique, préparation et révision d’un rapport

Permettre l’accès aux applications vitales pour garder les processus de gestion et les processus métiers opérationnels

Toute innovation envisageable

2. Les solutions

Autre problème soulevé par les terminaux mobiles, la disparité des systèmes d’exploitation. Le monopole de Microsoft sur les ordinateurs personnels type PC avait l’avantage de la quasi universalité de windows sur les postes de travail.

Une étude Gartner de 2008 avait prévu pour 2012 le « Top 5 » suivant : e

Symbian (203 millions d’appareils) ; e

Android (76 millions) ; e iPhone (71,5 millions) ; e

Windows Mobile (66,8 millions) ; e

RIM OS (65,25 millions).

Il semble aujourd’hui que ce « Top 5 » se réduise en fait à un podium réunissant

Android, iPhone et Windows Mobile.

3. La réalité augmentée

Parmi les couples (usages, technologies) rendus possibles par le développement des terminaux mobiles, la réalité augmentée place l’internaute au centre de l’application en l’impliquant via la caméra de son « smart phone ». Il peut détecter les offres immobilières en effectuant un panoramique sur un groupe d’immeubles (Application

Layar de SPRXMobile), voir l’effet d’une nouvelle paire de lunettes sur sa physionomie (Application Virtual Mirror de Fitting-box) ou d’un nouveau meuble dans son salon (Application Previznet).

291

GRP : expertise JOB : manag⊕syst⊕infor DIV : 21⊕f0020⊕tdm p. 1 folio : 499 --- 5/9/012 --- 18H56

[

T a b l e d e s m a t i è r e s

]

Préface

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

Mode d’emploi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

Programme

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Sommaire

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

Chapitre 1

e

Introduction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

[

1 q

Le métier, l’outil et le système

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

A.

Le nouveau contexte

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

B.

L’outil informatique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

C.

Un outil pour quel métier ?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

D.

Un outil pour les comptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

E.

Un outil comptable intégré dans un ensemble plus vaste

. . . . . . . . . . . . . . .

16

[

2 q

Les thèmes abordés

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

A.

Gouvernance des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

B.

La gestion des projets de systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . .

17

C.

Les progiciels de gestion intégrés

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

D.

Gestion de la performance informatique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

E.

Architectures et sécurité des systèmes d’information

F.

L’auditeur en environnement informatique

. . . . . . . . . . . . . . . . . . .

18

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

Chapitre 2

e

Gouvernance des SI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

[

1 q

Comprendre le Système d’Information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

A.

Les outils : postes de travail, serveurs et réseaux

. . . . . . . . . . . . . . . . . . . . . . . .

22

B.

Au-delà des outils : les services

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

C.

Au-delà des services, les systèmes ?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

D.

Assister le système de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

[

2 q

Position de la fonction informatique au sein de l’organisation

. . . . . . . . . . .

30

A.

Manager les systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

B.

Une action permanente tout au long du cycle de vie

C.

Pilotage de la fonction SI

. . . . . . . . . . . . . . . . . . . . .

32

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

[

3 q

Du management à la gouvernance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

A.

Le concept de gouvernance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

B.

Plan d’action pour mettre en place une gouvernance des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

[

4 q

Définir la stratégie SI et l’aligner sur la stratégie de l’organisation . . .

42

A.

Une stratégie SI en cohérence avec la stratégie de l’entreprise

. . . . .

42

B.

Interrelations

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

C.

Les systèmes et les technologies de l’information savent-ils répondre à l’évolution des doctrines stratégiques ?

. . . . . . . . . . . . . . . . . . . . . .

44

D.

Les systèmes et les technologies de l’information savent-ils répondre aux enjeux stratégiques ?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

[

5 q

Le Schéma Directeur des Systèmes d’Information (SDSI) . . . . . . . . . . . . . . . . .

47

A.

Pourquoi un SDSI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

B.

Les objectifs du Schéma Directeur des Systèmes d’Information

C.

Équilibre entre les objectifs et les moyens

. . . . . .

48

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

D.

Coordination des applications

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

E.

Prévision et programmation

F.

Le plan opérationnel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

499

GRP : expertise JOB : manag⊕syst⊕infor DIV : 21⊕f0020⊕tdm p. 2 folio : 500 --- 6/9/012 --- 12H44

[

6 q

La DSI de demain face à ses clients

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

[

7 q

Urbanisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

A.

Le principe fondateur de l’urbanisation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

B.

Concepts clefs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

C.

Un exemple d’urbanisation du SI d’une banque

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

Chapitre 3

e

Étude de cas sur l’alignement stratégique et sur la définition d’une architecture

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

[

1 q

Présentation de l’entreprise

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

A.

Introduction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

B.

Le concept

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

C.

Nos atouts

D.

Nos valeurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

E.

Les chiffres significatifs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

[

2 q

Le nouveau SI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

A.

Le contexte

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

B.

La refonte des applications de gestion et la démarche d’intégration

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

C.

La supply chain

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

D.

Gérer les règlements et fidéliser les clients

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

E.

L’informatique décisionnelle

F.

Les solutions de mobilité

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

500

Chapitre 4

e

La conduite des projets

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

[

1 q

Enjeux des projets SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

A.

Qu’est-ce qu’un projet « système d’information » ?

. . . . . . . . . . . . . . . . . . . . . . . .

80

B.

Exigences de la conduite d’un projet (spécification de management)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

C.

Quelques définitions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

D.

L’apport des normes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

E.

Méthodologie de conduite de projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

F.

Acteurs et organisations

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

[

2 q

Le cycle de vie d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

96

A.

Le processus « Conduite d’un projet » : identification des étapes d’un projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

96

B.

Les éléments transversaux

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

C.

Les trois éléments clefs du pilotage

D.

Pilotage opérationnel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

100

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

106

[

3 q

La gestion des risques

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

112

A.

Nature des risques dans un projet SI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

112

B.

Typologies des risques

C.

Gérer le risque projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

112

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

114

D.

L’analyse quantitative du risque

E.

L’analyse qualitative du risque

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

114

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

115

F.

Maîtriser le risque projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

116

[

4 q

Conduite du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

117

A.

Principes de la conduite du changement

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

117

B.

Le projet latéral

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

119

C.

Communication

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

121

[

5 q

Les outils de la conduite de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122

A.

Les outils de pilotage

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122

B.

Les outils de modélisation : modélisation des processus

C.

Les outils de modélisation : modélisation des données

. . . . . . . . . . . . . . . .

125

. . . . . . . . . . . . . . . . . .

151

D.

Outils collaboratifs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

153

[

6 q

Les bonnes pratiques de la conduite de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

154

A.

Bonnes pratiques pour l’étape no 1 : Identification et faisabilité

. . . . . .

154

B.

Bonnes pratiques pour l’étape no 2 : Analyse des scénarios

. . . . . . . . . . .

157

GRP : expertise JOB : manag⊕syst⊕infor DIV : 21⊕f0020⊕tdm p. 3 folio : 501 --- 6/9/012 --- 12H44

Table des matières

C.

Bonnes pratiques pour l’étape no 3 : Solution détaillée

D.

Bonnes pratiques pour l’étape no 4 : Réalisation

. . . . . . . . . . . . . . . . . .

159

. . . . . . . . . . . . . . . . . . . . . . . . . . .

160

E.

Bonnes pratiques pour l’étape no 5 : Déploiement

. . . . . . . . . . . . . . . . . . . . . . . . .

160

F.

Bonnes pratiques pour l’étape no 6 : Évaluation

G.

Bonnes pratiques pour les actions transversales

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

161

. . . . . . . . . . . . . . . . . . . . . . . . . .

161

[

7 q

Les facteurs clefs de succès

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

164

A.

Au lancement du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

164

B.

Lors de l’organisation du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

164

C.

Lors de la planification du projet

D.

Lors de la réalisation du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165

E.

Lors du déploiement du projet

F.

Lors de l’évaluation du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165

[

8 q

Le processus « Gestion des projets » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

166

A.

Conduite d’un projet et gestion des projets

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

166

B.

Les enjeux de la gestion des projets

C.

Où l’on retrouve l’urbanisation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

168

[

9 q

Exemples de projets de migration dans le secteur bancaire

. . . . . . . . . . . . . .

169

Chapitre 5

e

Étude de cas sur la conduite de projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

171

[

1 q

Présentation de l’entreprise

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

172

A.

Son marché

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

172

B.

Ses métiers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

173

C.

Ses valeurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

176

D.

Les chiffres significatifs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

176

E.

Organisation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

176

F.

Ses certifications

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

177

[

2 q

Le SI d’AERO-BREIZH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

177

A.

Situation actuelle

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

177

B.

Le futur SI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

C.

La contribution du SI à la nouvelle stratégie

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179

Chapitre 6

e

Dimension fonctionnelle des SI et progiciels de gestion intégrés

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

[

1 q

Dimension fonctionnelle du système d’information :hiérarchisation des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

186

A.

Les technologies n’ont de sens qu’au service des usages

. . . . . . . . . . . . . .

186

B.

Répondre aux besoins de l’entreprise : l’informatique structurelle

. . .

187

C.

Répondre aux besoins individuels : l’informatique personnelle

. . . . . . . . .

188

D.

Répondre aux besoins du groupe de travail : l’informatique collaborative (ou coopérative)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

189

E.

Répondre aux besoins de l’entreprise étendue

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

190

F.

Supporter la prise de décision : l’informatique décisionnelle

G.

Répondre à des attentes universelles

. . . . . . . . . . .

191

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

192

H.

Récapitulation des besoins

I.

Notre dernière trajectoire

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

193

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

194

[

2 q

L’informatique décisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

196

A.

Définitions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

196

B.

Rôle de l’entrepôt de données

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197

C.

Les données de l’entrepôt

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

198

D.

Les traitements de l’entrepôt de données

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

200

E.

Application au domaine du marketing

F.

Tendances

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

203

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206

G.

Les acteurs de l’informatique décisionnelle

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206

[

3 q

L’informatique collaborative

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

A.

Enjeux

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

B.

Usages et outils

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

C.

Construire l’informatique collaborative

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

210

501

GRP : expertise JOB : manag⊕syst⊕infor DIV : 21⊕f0020⊕tdm p. 4 folio : 502 --- 6/9/012 --- 12H44

D.

Une nouvelle dimension de l’informatique collaborative : le web 2.0

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

215

[

4 q

L’informatique structurelle et l’intégration des systèmes de gestion

.

218

A.

Modélisation du SI : une vision statique pour le découpage en systèmes de gestion

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

218

B.

Modélisation du SI : une vision dynamique pour identifier les processus

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

229

C.

Les solutions de l’informatique structurelle : des logiciels spécifiques aux PGI/ ERP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

240

[

5 q

La démarche « Best of Breed » : le cas des progiciels comptables

. . . . .

242

A.

Informatisation du SG des flux financiers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

242

B.

Progiciels comptables

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

243

C.

Autres progiciels de l’informatique structurelle

D.

Progiciels métiers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

249

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

250

[

6 q

La démarche d’intégration : les PGI/ ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

250

A.

Une intégration par étapes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

250

B.

La solution PGI/ ERP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

254

C.

L’exemple JDE

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

255

D.

Un autre exemple : SAP R/3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

256

E.

Modèle d’entreprise

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

257

F.

Avantages des PGI/ ERP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

259

G.

Inconvénients des PGI/ ERP

H.

Les acteurs du marché

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

259

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

259

[

7 q

L’intégration horizontale : les enjeux de la chaîne logistique et de la relation client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

260

A.

L’émergence d’un nouveau besoin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

260

B.

Le management de la chaîne logistique

C.

Visualisation de la chaîne logistique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

261

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

262

D.

Un progiciel pour une optimisation complète de la chaîne logistique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

264

E.

Architecture d’un progiciel de management de la chaîne logistique

F.

Les acteurs du marché

.

265

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

267

G.

Un réseau plus complexe qu’il n’y parait

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

267

H.

Pour une chaîne logistique optimisée

I.

Gestion de la Relation Client

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

272

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

273

[

8 q

Le cycle de vie des PGI/ ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

274

A.

Les étapes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

274

B.

Le contrat

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

275

C.

L’infrastructure

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

275

D.

Les risques

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

276

E.

Les facteurs clefs de succès

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

276

F.

Les coûts d’un PGI/ ERP

G.

Evaluation d’un PGI/ ERP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

279

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

280

H.

PGI/

ERP et PME/PMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

281

I.

L’histoire d’un grand projet : Nestlé

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

283

[

9 q

Bilan de l’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

284

A.

Aspects positifs et aspects critiquables

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

284

B.

Le PGI est-il au cœur des systèmes d’information ?

. . . . . . . . . . . . . . . . . . . . . .

285

C.

Quel impact pour la profession comptable

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

285

[

10 q

Tendances

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

287

A.

Architectures

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

287

B.

Modes de fourniture

C.

Mobilité

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

289

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

290

502

Chapitre 7

e

Étude de cas sur les progiciels intégrés

. . . . . . . . . . . . . . . . . . . . . . . . . . .

293

[

1 q

Annexe 1 : Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

296

A.

Son marché

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

296

B.

Ses métiers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

296

GRP : expertise JOB : manag⊕syst⊕infor DIV : 21⊕f0020⊕tdm p. 5 folio : 503 --- 6/9/012 --- 12H44

Table des matières

C.

Sa stratégie

D.

Ses valeurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

296

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

297

E.

Ses chiffres significatifs

H.

Le futur S.I.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

297

F.

Son organisation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

298

G.

Le système d’information actuel de EH&R

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

298

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

298

Chapitre 8

e

Gestion de la performance informatique

. . . . . . . . . . . . . . . . . . . . . . . . . .

305

[

1 q

Définition d’indicateurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

306

A.

Le rôle des indicateurs dans l’évolution des pratiques de management

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

306

B.

Les indicateurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

308

C.

Difficultés potentielles et facteurs de succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

309

[

2 q

Infogérance et contrat de service

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

310

A.

L’infogérance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

310

B.

Le marché de l’infogérance

E.

Contrats de services

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

312

C.

Les facteurs clefs de succès

D.

Un DSI devenu acheteur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

314

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

314

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

316

[

3 q

Les coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

317

A.

Les coûts du matériel informatique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

317

B.

Les coûts de développement, de production et de maintenance

C.

Les coûts cachés

. . . . . .

318

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

320

D.

Mesurer les coûts

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

322

[

4 q

Les budgets informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

324

A.

Tendances

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

324

B.

Cas de l’Administration publique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

326

C.

Cas des entreprises industrielles

D.

Cas des établissement financiers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

327

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

328

[

5 q

Évaluation des projets informatiques : le critère financier . . . . . . . . . . . . . . . . .

330

A.

Économie d’un projet « Système d’information »

. . . . . . . . . . . . . . . . . . . . . . . . . . .

330

B.

La mesure de la rentabilité d’un projet SI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

331

C.

Déterminer les gains

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

335

D.

Vers l’approche « Valeur » : une nouvelle vision de la décision d’investissement

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

337

E.

Exemple de calcul du TIR d’un projet

F.

Exemple de calcul basé sur la valeur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

341

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

344

[

6 q

Autres critères d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

347

A.

Des modèles permettant de mesurer la performance sur les critères autres que financiers

B.

Le référentiel Itil

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

347

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

348

C.

Le référentiel CobiT

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

350

Chapitre 9

e

Étude de cas sur la performance informatique

. . . . . . . . . . . . . . . .

357

Chapitre 10

e

Architectures et sécurité des systèmes d’information

. . . .

359

[

1 q

Architectures des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

360

A.

Des technologies aux architectures

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

360

B.

Au sein d’une architecture cohérente

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

366

C.

Technologies de base pour traiter l’information et architectures de machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

369

D.

Technologies de base pour stocker l’information

. . . . . . . . . . . . . . . . . . . . . . . . . . .

373

E.

Évolution des architectures de systèmes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

377

F.

Évolution des architectures de réseau

G.

Évolution des architectures de données

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

380

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

391

H.

Évolution des architectures de traitement

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

394

I.

Évolution des architectures globales

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

399

J.

Composants des architectures globales 2010

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

406

503

GRP : expertise JOB : manag⊕syst⊕infor DIV : 21⊕f0020⊕tdm p. 6 folio : 504 --- 5/9/012 --- 18H56

K.

L’intégration au niveau du poste de travail

L.

Une architecture devenue très complexe

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

419

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

421

M.

Perspectives 2010-2020

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

423

[

2 q

La sécurité des systèmes d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

425

A.

Les actifs à protéger

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

426

B.

Les risques à évaluer

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

427

C.

Les menaces à identifier

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

431

D.

Les politiques de sécurité à mettre en œuvre

E.

Mettre en place une architecture de confiance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

433

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

437

F.

Surveillance et prévention

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

440

Chapitre 11

e

L’auditeur en environnement informatique

. . . . . . . . . . . . . . . . . . . . . . .

453

[

1 q

Audit des systèmes d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

454

A.

Deux modes d’action

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

454

B.

Audit par le SI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

454

C.

Audit de la fonction informatique : le modèle CobiT

. . . . . . . . . . . . . . . . . . . . . . . .

455

[

2 q

Un audit peut se situer dans des contextes très différents . . . . . . . . . . . . . . .

456

A.

L’audit externe

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

457

B.

L’audit interne

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

457

[

3 q

Le cadre légal et normatif

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

458

[

4 q

Les outils de l’auditeur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

460

A.

Les logiciels de conduite de la mission

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

460

B.

Les outils de contrôle spécifiques

C.

Les outils d’analyse de données

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

461

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

461

[

5 q

Le déroulement de la mission

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

463

A.

L’enquête préalable

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

464

B.

L’audit du système d’information

C.

Le rapport d’audit

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

464

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

465

504

Chapitre 12

e

Étude de cas de synthèse

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

467

[

1 q

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

468

[

2 q

Présentation de l’établissement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

469

A.

Le CHU

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

469

B.

Les métiers du CHU

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

470

C.

Le besoin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

470

[

3 q

Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

471

A.

Accréditation et évaluation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

471

B.

Une nouvelle organisation des services

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

472

C.

Les Plans Hôpital 2012

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

472

D.

La mise en place d’un PGI/ERP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

473

[

4 q

Le nouveau système d’information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

474

A.

Des exigences spécifiques

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

474

B.

Le système d’information de l’hôpital

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

474

C.

Conception du Système d’Information de l’hôpital

. . . . . . . . . . . . . . . . . . . . . . . . . .

475

D.

Identification et mouvement des malades

E.

Strate des fonctions cliniques

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

476

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

476

F.

Structures dédiées à l’information médicale

G.

Ressources

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

477

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

477

[

5 q

Exigences particulières

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

478

A.

Intranet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

478

B.

Imagerie

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

479

[

6 q

Les projets des réseaux de santé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

482

Chapitre 13

e

Corrigé type pour l’étude de cas de synthèse

A.

Plan

. . . . . . . . . . . . . . . . . .

487

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

488

B.

Rappel du contexte

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

488

GRP : expertise JOB : manag⊕syst⊕infor DIV : 21⊕f0020⊕tdm p. 7 folio : 505 --- 5/9/012 --- 18H56

Table des matières

C.

Enjeux

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

488

D.

Description du projet MediSys

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

489

E.

Objectifs clefs du projet MediSys

H.

Facteurs clefs de succès

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

489

F.

Description du projet MediNet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

490

G.

Objectifs clefs du projet MediNet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

490

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

490

I.

Risques principaux

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

491

J.

Indicateurs à mettre en place

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

491

K.

Étude économique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

492

L.

Conclusion : faut-il lancer ces projets ?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

492

Index

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

493

505