Fonctionnement d’un département informatique

Gestion des technologies de l’information – GEST310

Pascale Vande Velde

|2

Agenda

• Introduction• Activités d’un département IT

– Gouvernance– Stratégie et planning– Développement– Architecture– Exploitation– Gestion des ressources

• Enjeux financiers• Etude sur la gouvernance

|3

Quelques clichés.....

• Comment va-t-on prioritiser mes projets IT ?• Pourquoi le département IT n’a-t-il pas de moyens pour réaliser mes projets ?• L’IT m’impose ses projets. L’IT est un état dans l’état.• Comme mes projets ont été refusés, j’ai développé moi-même mes applications

en excel/VB• Pourquoi mon projet n’a-t-il pas abouti ? ...ou a coûté significativement plus cher

et a duré significativement plus longtemps que prévu ?• Pourqui n’importe quel petit développement coûte toujours plusieurs années

hommes ?• Le helpdesk ne sait jamais répondre à mes questions...• Mon PC ne marche pas et le réseau tombe toujours en panne....• Le département IT refuse systématiquement d’implémenter d’autres

applications que des applications propriétaires (mainframe). Réaliser ce que je veux faire sur une application propriétaire coûtera trop cher ?

• Il a fallu plusieurs heures avant que le système de paiements soit rétabli. Je suis sortie sans rien du magasin

|4

Comment adresser ces problèmes ?

• Comment va-t-on prioritiser mes projets IT ?• Pourquoi le département IT n’a-t-il pas de moyens pour réaliser mes projets ?• L’IT m’impose ses projets. L’IT est un état dans l’état.• Comme mes projets ont été refusés, j’ai développé moi-même mes applications

en excel/VB– Governance IT

• Pourquoi mon projet n’a-t-il pas abouti ? ...ou a coûté significativement plus cher et a duré significativement plus longtemps que prévu ?

• Pourqui n’importe quel petit développement coûte toujours plusieurs années hommes ?

– Gestion de projets IT• Le helpdesk ne sait jamais répondre à mes questions...• Mon PC ne marche pas et le réseau tombe toujours en panne....• Il a fallu plusieurs heures avant que le système de paiements soit rétabli. Je suis

sortie sans rien du magasin– Exploitation

• Le département IT refuse systématiquement d’implémenter d’autres applications que des applications propriétaires (mainframe). Réaliser ce que je veux faire sur une application propriétaire coûtera trop cher ?

– Architecture

|5

L’organisation d’un département IT

CIO

Développement Exploitation Architecture

Projets Maintenance

Finance/HR

|6

Les activités principales d’un département IT

Gouvernance

Gestion des ressources

Exploitation

Architecture

Stratégie & Planning

Développement

La gestion de projets

La gestion deu parc d’applications existants

La stratégie et plans IT qui sont alignés sur les besoins métiers de l’entreprise

Source: Accenture

Un management IT qui supporte la vision métiers de l’entreprise

Une structure de gouvernance qui définit les rôles et responsabilités de l’IT et du business et les processus de décision IT

Des processus de management et d’exécution

La définition d’une architecture qui permet de rencontrer les besoins de l’entreprise

Planification et livraison de services d’exploitation journaliers

Le management des ressources financières et humaines du département

|7

Gouvernance

• Définit les rôles et les responsabilités dans les décisions d’investissements de sorte à aligner la stratégie IT sur la stratégie métiers

• La gouvernance n’est pas le modèle pour gérer le département IT mais bien le modèle via lequel les métiers gérent leur utilisation de l’IT

• Décisions clés à prendre :– Comment l’IT est-il utilisé dans les métiers– Les choix d’architecture (quelles technologies)– Les stratégies d’infrastructure (niveau de standardisation, insourcing/outsourcing,

etc....)– Les besoins métiers– Niveaux et prioritisation des investissements

• Outils de gouvernance : chartre IT– Définissant les rôles et responsabilités des métiers et de l’IT dans le cadre de la

gestion de la demande, de la gestion des incidents et de l’implémentation de projets– Définissant les processus de :

• Gestion de la demande• Gestion des incidents• Implémentation des projets

|8

Gouvernance - Gestion de la demande

• Demande– Toute requête pour l’évolution ou l’adaptation d’une application

existante– Toute requête pour le développement d’une nouvelle application

• Objectifs– Centraliser les demandes clients– Faciliter l’élaboration d’un planning des activités de développement et

le planning budgétaire– Analyser les demandes et conseiller le client sur ses besoins– Suivre l’évolution des demandes– Communiquer et rapporter le statut de ces demandes aux clients

• Scope– Depuis l’expression d’un besoin jusqu’à la signature d’un contrat de

projet

|9

Gouvernance - Gestion de la demande

• Demandes clients– Expression d’un besoin formulé par un client et lié à l’évolution d’une

application existante, ou au développement d’une nouvelle application ou bien une demande d’évolution technique

• Projet– Un projet groupe plusieurs demandes clients qui rencontrent un même

objectif métier ou technique et ont des caractéristiques communes (fonctionnelles, techniques, organisationnelles ou administratives)

• Release (lot)– Tout projet est divisé en releases. Le groupement de projets en

releases permet de tenir compte de contraintes de développement• Version

– Une version est un ensemble de développement (un produit fini) visant à être mis en production à une date donnée. Une version peut inclure une release ou plusieurs releases de plusieurs projets

|10

Gouvernance - Gestion de la demande

Projects

Project CProject BProject A

Deliverables

Customer demandDemande client 7Demande client 6Demande client 5 Request

Customer 8Request

Customer 4

Release A1

Version n°1 Version n°2 Version n°3

Project contract

Project contract

Project contract

Similar requests

Version n°4

Release A2

Release B1

Release B2

Release B3

Release C1

Release A1

Release B1

Release B2

Release A2

Release C1

Waiting placement in a version

RequestCustomer 8

RequestCustomer 1

RequestCustomer 2

RequestCustomer 3

RequestCustomer 1

RequestCustomer 2

RequestCustomer 3

Demande client 7Demande client 6Demande client 5RequestCustomer 4

|11

Nouvelle demande/modification d’une demande1

Métiers

IT

CLIENTSApprobation du business case2

A compléterOui

Non

Qualification de la demande (type, risque), groupement des demandes si nécessaire, et allocation pour évaluation

3

Risque ?Elevé

Evaluation Evaluation additionnelle4 5

Faible

Moyen

Rapport d’évaluation

Décision Comité demande7

Approuvé ? Non

A escaler ?

Approuvé ? Non

Oui pour arbitrer ou pour approuver

Décision domain committee8

9

Non

A

Proposition de release 6

Autres processus

Information domain committee

Modifier requête + info customer

Modifier requête + info clientEnd

A escaler

Décision Comité IT

Non

Oui

Accepté? Non Oui

Inclus dans le macro planning10

Gouvernance - Gestion de la demande

|12

A

Préparer les spécifications fonctionnelles

Validation des spécifications fonctionnelles

11

Approbation des spécifications

12

Approuvé ? Non

Oui

Préparer une pré étude

13

Préparer un contrat de projet

14

A valider avec client ?

Yes

Non

Pré étude requise ?

Oui

Non

15

Autres processus

Gouvernance - Gestion de la demande

|13

Gouvernance - Gestion des incidents

• Objectifs– Centraliser les demandes clients– Fixer et suivre un planning pour les requêtes de type incidents– Suivre l’évolution des demandes– Communiquer et rapporter le statut de ces demandes aux clients

• Incident– Requêtes de hardware ou de software– Requêtes de modifications de configuration de desktop– Requêtes d’accès

• Scope– Depuis l’expression d’un besoin jusqu’à la livraison

|14

INCIDENT

MANAGEMENT

Incident report

Quality managers

Log des incidents

Erreurs sur Batch / TP

‘IMMEDIATE’ MAINTENANCE

SYSTEMES CENTRAUX ET

SERVEURS

USERS OPERATIONSGESTION PC

HELPDESK

RESEAUX

COORDINATION ET SUIVI DES INCIDENTS

MAINTENANCE PAR RELEASE

SERVICE

Gouvernance - Gestion des incidents

|15

Gouvernance - Gestion des incidents

Nouvelle demande/modification d’une demande

Analyse de l’incident

Etude de livraison

A fermer ? Oui

Non

Standard?

1

2

7

Business & functional units

Information client

Profit centres

CLIENTS

IT

Oui

Non

Budgété ?

Déjà qualifié ?

Etude et qualification de la solution3

Non

Inventory check8

Inventory ?

Préparation et installation10

Commande d’achat9

Oui

Non

Demande d’approbation6

Demande approuvée

?

Oui

Non

Oui

Non

Oui

Etude technique de la solution4

Demande d’estimation de coûts5

Estimation de coûts

nécessaire ?

Non

Oui

Requête terminée

|16

Demande vs incidents - Problèmes classiques• Pas de distinction entre incidents et demandes ou mauvaise distinction• Pas de processus de release management pour l’implémentation de

demandes• Les releases sont trop peu nombreuses et trop éloignées dans le temps• Toutes les demandes arrivent au demand committee sans avoir été

prioritiées au sein des métiers• Le business case est non pertinent• On passe trop de temps à réaliser des pré études peu utiles• Le processus de qualification des demandes prend trop de temps (par

ex. 6 mois à 1 an)• Le helpdesk est peu qualifié et renvoie tous les incidents vers les

activités de développement ou d’exploitation• Les incidents sont loggés mais pas résolus

|17

Stratégie et planning

• Maximiser le budget IT réservé à des investissements– Optimiser les coûts d’exploitation sous contraintes de sécurité et de

disponibilité– Optimiser les coûts de développement

• Conception• Exécution de projets

• Aligner la stratégie IT sur les stratégies métiers (“alignment”)• S’assurer que les besoins métiers futurs pourront être rencontrés

(“enablement”)• Mettre en place les processus adéquats :

– Elaboration de plans long terme et budgets– Suivi et allocation des coûts– Suivi des projets

|18

Développement

• Objectifs– Implémenter les nouvelles demandes et résoudre incidents de manière efficace, dans le

respect des principes architecturaux définis par le département architecture– Gérer les grands domaines applicatifs

• Les livraisons se font dans le cadre de releases sachant que les projets et les incidents font l’objet de releases distinctes

• Les activités de développement sont basées sur des processus prédéfinis, des rôles et responsabilités prédifinis et visent à assurer une livraison à un moment fixé préalablement. On distingue les processus de développement et de gestion de projet & programme

• Tout projet doit être idéalement cogéré avec le métier impliqué. Le métier est le propriétaire du business case, participe aux spécifications fonctionnelles, réalise les tests d’acceptation, donne le sign off pour une mise en production et participe à la refonte de l’organisation, des processus métiers liés à ce projet

• Les responsables de domaines assurent la cohérence des applications dans leur domaine avec les principes d’architectures globaux; ils sont propriétaires du code source de leurs applications; ils gèrent les configurations de leurs applications et s’assurent d’avoir le nombre adéquat de ressources fonctionnelles et techniques disponibles par application

|19

Développement – fonctionnement du département

Demandes

Fichier

Fichier

Domaine 3

Domaine 4

Pre -

diagnostic, A

llocation

Domaine 1

Mainte-nance

Mainte-nance

Mainte-nance

Domaine 2

Program Management Office

LIVRAISON TESTS D’ACCEPTATION

PR

OD

UC

TIO

N

FONCTIONALDEVELOPMENT

ANALYSEPRIORITISATION

ALLOCATION

Projet 1Projet 2

Mainte-nance

Contraintes

Point d’entrée

Projets

Incidents

Objets Créés oumodifiés

Objets corrigés

INTEGRATIONGLOBALE

INTEGRATION FONCTIONNELLE

TESTS D’ ACCEPTATION

Rapports Rapports Rapports Rapports

ResponsibilitéDéveloppement

Responsibilité partagée Dev/exploit/métiers

Architecture

|20

Spécifications techniques

Développement – aperçu du processus de développement

Test d’intégration

UAT DéploiementDéveloppement Tests unitairesSpécifications fonctionnelles

Besoins métiers

Besoins réglementaires

* User Acceptance Testing

Gestion de projet

Infrastructure

|21

Développement – Problèmes classiques

• Les tests révèlent des carences dans le design fonctionnel• Le design technique a été réalisé sur base d’un design fonctionnel

incomplet• Manque de procédures et de documentation pour les tests • Pas d’environnement de tests pour gérer plusieurs releases• Mauvaise coordination entre l’équipe projet et l’infrastructure pour la mise

à disposition de serveurs et d’environnements de développement, test et production

• Pas de planning de projet détaillé. La méthodologie de développement n’est pas utilisée ou n’est pas documentée

• La méthodologie ne définit pas de delivrables (produits finis)• Les ressources sont réparties entre plusieurs projets• Le projet ne dispose pas de ressources métiers pour effectuer les tests

d’acceptation et le handover organisationnel

|22

Architecture

• Le département architecture doit veiller à la cohérence globale de l’architecture de la banque, à son coût et à sa capacité d’évolution

• Dans de grandes entreprises, il est commun d’avoir des architectes par domaine d’activité

• Les responsables de domaines assurent la cohérence des applications dans leur domaine avec les principes d’architectures globaux. Les architectes et les responsables de domaines définissent ensemble les standards produits.

• Les architectes doivent s’assurer que leur architecture soit rationnelle et ouverte (faciliter l’intégration de nouvelles applications)

|23

Responsabilités Compétences

• Assurer la conformité des projets à l’architecture globale

• Analyser l’impact et la contribution des projets à l’architecture

• Recommender une gouvernance appropriée pour les projets

• Fournir une guidance architecturale

• Recommender les méthodes,outils et techniques de développement

• Revoir les stratégies et plans de test

• Compétences fonctionnelles et techniques étendues

• Equilibre entre vision et pragmatisme

• Capacité de traduire la vision en architecture

• Innovant et créatif

• Bonne communication et esprit d’équipe

ProcessusArchitecture fonctionnelle Architecture technique

|24

Architecture – Problèmes classiques

• Architecture complexe :– Cohabitation de plusieurs types de serveurs (IBM, HP, Sun,....)– Cohabitation de plusieurs protocoles de communication– Cohabitation de plusieurs technologies réseuax (ethernet, token

ring,....)• Surcapacité en MIPS• Surcoût des MIPS (prédominance des systèmes legacy)• Plate-formes résultant de fusions n’ont pas été intégrées (par ex

cohabitation de 2 environnements Lotus Notes ne permettant pas de fixer des réunions entre les 2 entités fusionnées)

• Systèmes legacy monolithiques – l’ajout de fonctionnalités nécessite beaucoup d’efforts

|25

Exploitation - Activités

• L’exploitation est responsable de la gestion de l’infrastructure, de la mise en place de nouveaux éléments d’infrastructure, du helpdesk, et de la gestion des relations avec les fournisseurs

Gestion des relations clients

Fourniture de services

IntroductionNouveauxServices

Gestion et amélioration

Services

Gestion des relations avec les fournisseurs

Changement aux

Services

|26

Exploitation – modèle de fonctionnement

Déploiement de services Agit comme interface entre le développement et

l’exploitation Déploie des solutions, gère les changements

techniques

Déploiement de services Agit comme interface entre le développement et

l’exploitation Déploie des solutions, gère les changements

techniques

Service operations Gère le hardware, les réseaux, la sécurité et les

systèmes Gère les actifs Gère la contingence Traite les problèmes réseaux et systèmes

Service operations Gère le hardware, les réseaux, la sécurité et les

systèmes Gère les actifs Gère la contingence Traite les problèmes réseaux et systèmes

OLAs

Service Control

Service Operations

Service Managers

Ser

vice

A

Ser

vice

B

Ser

vice

C

Ser

vice

D

Dom

ain

1

Dom

ain

2

Dom

ain

3

Dom

ain

4

Cus

tom

ers

Use

rs

Service Deployment

SLAsOLAs S

uppl

iers

OLAs

Service Control

Service Operations

Service Managers

Ser

vice

A

Ser

vice

B

Ser

vice

C

Ser

vice

D

Service Managers

Ser

vice

A

Ser

vice

B

Ser

vice

C

Ser

vice

D

Dom

ain

1

Dom

ain

2

Dom

ain

3

Dom

ain

4

Cus

tom

ers

Use

rs

Service Deployment

SLAsOLAs S

uppl

iers

Service control Crée et gère des OLAs Mesure et rapporte la conformité avecles SLA’s et

les OLA’s Prioritise et contrôle les change requests Gère les fournisseurs de services

Service control Crée et gère des OLAs Mesure et rapporte la conformité avecles SLA’s et

les OLA’s Prioritise et contrôle les change requests Gère les fournisseurs de services

Service managers Gère les relations clients, crée et gère les SLAs Traite les demandes des utilisateurs Traite et résoud les incidents

Service managers Gère les relations clients, crée et gère les SLAs Traite les demandes des utilisateurs Traite et résoud les incidents

|27

Exploitation – Problèmes classiques

• Les SLAs avec les métiers ne sont pas réellement orientés clients et services; les prix sont peu transparents

• Les métiers n’ont pas un point de contact au sein du département• Peu de systèmes de monitoring, peu de mesures de performances, peu de

reporting• En général, les aspects infrastructure sont le facteur de dérapage d’un

projet de développement. Ils sont trop peu impliqués dans le planning du projet et il n’y a pas de personne dédiée au projet pour mettre en place cette infrastructure

• Le helpdesk accumule les demandes sans les traiter• Trop peu de personnel qualifié pour assurer l’installation et l’exploitation

de nouvelles technologies• Manque de gestion automatisée (installation de nouveaux serveurs, etc...)

|28

Gestion des ressources

• Les ressources incluent en général :– Des ressources internes– Des ressources externes (contractors)– Des ressources externes dans le cadre de développement offshore ou

dans le cadre d’outsourcing• Les ressources-clés doivent idéalement être internes• Les ressources internes doivent pouvoir être chargées sur des

projets à des prix concurrentiels et atteindre des niveaux d’efficacité similaires à ceux des ressources externes

• Etant donné l’évolution extrêmement rapide des technologies, des programmes de trainings adaptés doivent être mis en place pour maintenir le personnel à niveau

• La planification des ressources sur des projets ou des activités doit être soigneusement organisée afin d’éviter des pertes d’efficacité

|29

Gestion des ressources – Problèmes classiques

• Les resssources sont refacturées très cher aux métiers et sont trop peu efficaces dans leur travail

• Manque de capacités de gestion de projet en interne• Les compétences des ressources internes sont orientées systèmes

legacy. Peu de compétences dans des nouvelles technologies• Peu de transfert de connaissances (entre externes et internes,

entre seniors et juniors)• Beaucoup de contractors restent à demeure comme indépendents• Peu de systèmes de récompense, de performance• Pas ou peu de plans de trainings

|30

Fonctionnement financier d’un département IT• Le département IT est un département de support (coûts ventilés aux

différents métiers)• On distingue les coûts d’exploitation et de développement• Coûts d’exploitation (facturés en fonction de l’utilisation)

– Amortissements hardware, software de l’infrastructure et réseaux– Amortissements software des applications non allouées aux métiers– Coûts du personnel affecté à l’exploitation– Coûts divers (télécoms, surface, etc...)

• Coûts de développement (facturés par projet, demande)– Coûts du personnel affecté au développement (jours-hommes, 200 jours/an)– Coûts du personnel affecté aux domaines applicatifs et à l’architecture– Amortissements software des outils de développement

• Les grands projets architecturaux sont, en général, supportés au niveau corporate et non par les métiers

|31

Enjeux financiers

11%

16%

12% 17%

30-35%

67%77%

20-25%

40-50%

0%

20%

40%

60%

80%

100%

2000 2001 Best Practice

Rép

arti

tio

n d

u b

ud

get

IT Développer de nouvelles fonctionnalités

Maintenir applications existantes

Opérer les applications existantes

Discrétionnaire(nouveaux

développements)

Non-Discrétionnaire(Maintenance + Exploitation)

|32

Enjeux financiers

Capability gap

Dépenses non discrétionnaires

Dépenses discrétionnaires

Budget IT

Budget

Récession

Budget souhaité

Temps

Temps

• Lorsque les dépenses obligatoires (non discrétionnaires) représentent une trop grande partie du budget IT, l’entreprise peut, à certains moments, ne plus être capable d’investir dans de nouvelles fonctionnalités (lancement de produits, ...)

• Par ailleurs, avoir peu de marge de manoeuvre pour des dépenses discrétionnaires rend le processus de prioritisation des développements douloureux

|33

Enjeux financiers

30,5

66,715,1

15,254,4

61,8

0

20

40

60

80

100

120

140

160

Depository bank average X

Internal staff Contractors Hardware/software costs

+43,7%100

143,7

45,023,5

49,0

55,0120,2

94,7

0

20

40

60

80

100

120

140

160

Benchmark

Discretionary Non discretionary

16,4%34,1%

+43,7%100

143,7 143,7

Discretionary = investeringsdossiers

Discretionary = Investeringsdossiers

+ continuiteit

- Temps consacré à la maintenance et aux nouveaux développements par l’équipe de maintenance -

43%49%

74,7%

25,3%

0%

10%

20%

30%

40%

50%

60%

70%

80%

Development Maintenance

X Industry average

|34

I. Optimiser la gouvernance

Améliorer la contribution de l’IT à la valeur de la société

Réduction coûts IT

2–5%

IV. Optimiser l’exploitation

Réduction coûts IT

12-16%

II. Optimiser le développement

Réduction coûts IT

8-12%

Optimiser les dépenses discr

Optimiser les dépenses non discr

III. Optimiser gestion ressources

Réduction coûts IT

3-7%

Améliorer capacités +++

Améliorer capacités ++

Améliorer capacités ++

Améliorer capacités +

25-35% du budget IT

65-75% du budget IT

10-15%

15-21%

25-35%

x-y%

+++

++

+

7–10%

5–7%

++

++++

+

+++

2-5%

++

Mesurer la performance des activités IT

Améliorer l’efficacité et la flexibilité du sourcing

Réduire le coût des applications/infrastructure

Réduire le coût des vendors/contractors

Améliorer l’efficacité opérationnelle, la robustesse

Etre plus orienté clients

Minimiser les arrêts liés à des changements de services

Améliorer la gestion de la demande et les SLAs

Mener une stratégie alignée sur les besoins métiers

1–2%Réduire les frais administratifs

Eviter les projets à faible ou sans valeur ajoutée

1–3%Réduire le coût des applications/infrastructure

Améliorer la qualité et la prévisibilité du dev

+Améliorer la réactivité et le speed to market

7–11%Réduire le coût des ressources (int + ext)

++Améliorer les capacités d’implémentation

Optimiser HR et le knowledge management

Clarifier les rôles et les responsabilités

Réduire les coûts des vendors/contractors 2–6%

+

++

Economies observées en % du budget total

Valeur indicative de l’impact sur les capacités IT

Enjeux financiers – Actions

|35

Etude sur les best practices en matière de IT management

• Etude réalisée en 2002 par le Centre for Information Research, faisant partie de MIT Sloan School of Management

• 30 CIOs ont été interviewés sur ce qu’ils pensaient être les points-clés d’une bonne gestion IT. Il en est ressorti 3 points :

– Standardisation technologique• “ We’ve centralized to achieve higher levels of specialization in technology and in project management, to

attract and retain skilled technical people, as well as to rationalize and standardize infrastructure and development tools. We get faster delivery from all these together.” CIO of an insurance company

– Gestion disciplinée de projets• “ We are getting the business to take ownership of projects – for the new GL system, the owner is an

accountant, who knows what needs to change and can make things work. We have business staff on projects full time.” CIO of an healthcare company

– Clarification de la valeur apportée par un projet post implémentation• “Post implementation reviews are built into the development process. One to two weeks after deployment,

the project manageris responsible for a 15-20 pages report detailing what went right and what went wrong and proposing suggestions for improvement. Everyone on the project team and other stakeholders reads this and discusses the key points. It’s become part of the culture.” CIO of an investment bank

|36

Etude sur la gouvernance

• Etude réalisée en 2003 par le Centre for Information Systems Research, faisant partie de MIT Sloan School of Management – 256 entreprises ont été interrogées

• Le CISR a développé sur base d’interviews et de données quantitatives un framework pour la gouvernance IT basé sur 3 éléments-clés :

– Objectifs métiers– Styles de gouvernance IT– Les objectifs de performance métiers

• Il est nécessaire d’harmoniser objectifs métiers, styles de gouvernance et objectifs de performance

– Les entreprises focalisées sur la génération de profit (profit leaders) auront tendance à avoir une approche de gouvernance centralisée :

• Organisation IT centralisée, architecture standardisée • Transparence des mécanismes d’allocations de coûts• Standardisation des besoins métiers

– Les entreprises focalisées sur la croissance auront tendance à avoir un style de gouvernance féodal ou monarchique métiers :

• Les métiers ont l’emprise sur les décisions IT (besoin d’implémentations rapides, essai de nouveaux produits, etc...)

• Infrastructure gérée par l’IT au niveau de chaque métier avec une recherche d’intégration entre métiers• Spécialistes IT placés dans les métiers pour faciliter la gestion des besoins IT des métiers

|37

Le framework de gouvernance du CISR

|38

Les styles de gouvernance IT