Fonctionnement d’un département

informatique
Gestion des technologies de l’information –
GEST310

Pascale Vande Velde

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

|2
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

|3
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

|4
L’organisation d’un département IT

CIO

Finance/HR

Développement Exploitation Architecture

Projets Maintenance

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

 Un management IT qui  La gestion de projets

supporte la vision Gouvernance
 La gestion deu parc
métiers de l’entreprise
d’applications existants
 Une structure de
gouvernance qui définit
les rôles et Stratégie &
responsabilités de l’IT et Développement
du business et les
Planning  La définition d’une
processus de décision architecture qui permet
IT de rencontrer les
besoins de l’entreprise
 Des processus de
management et Architecture
d’exécution
Exploitation
 Le management des ressources
Gestion des ressources financières et humaines du
département

 La stratégie et plans IT qui sont alignés sur

les besoins métiers de l’entreprise  Planification et livraison de services
d’exploitation journaliers

Source: Accenture
|6
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

|7
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

|8
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

|9
 Gouvernance - Gestion de la demande
Customer demand
Demande client 7
Request Request Request Demande
Demande client56
Requestclient Request
Customer 1 Customer 2 Customer 3 Customer 4 Customer 8
Similar requests

Projects
Project A Project B Project C
Request
Customer 1
Demandeclient
client67 Request
Request Demande
Demande
Requestclient 5 Customer 8
Customer 2 Customer 4
Project Project Project
contract Request contract contract
Customer 3

Release Release Release Release Release Release

A1 A2 B1 B2 B3 C1

Deliverables
Version n°1 Version n°2 Version n°3 Version n°4
Waiting
placement in a
Release Release Release version
Release Release
A1 B1 B2 A2 C1

|10
 Gouvernance - Gestion de la demande
1 Nouvelle demande/modification d’une demande
CLIENTS
Métiers 2 Approbation du business case
Autres processus
Oui
IT A compléter

Non

3 Qualification de la demande (type, risque), groupement

des demandes si nécessaire, et allocation pour évaluation

Elevé Moyen
Risque ?

4 Evaluation 5 Evaluation additionnelle

Faible
Rapport d’évaluation
6 Proposition de release

7 Décision Comité demande

Approuvé ?
Non

Non
A escaler ? Information domain committee
Oui pour arbitrer ou pour
approuver
8 Décision domain committee
Modifier requête + info client Non
End Approuvé ?
Modifier requête + info customer

A escaler
Non
10 Inclus dans le macro planning
Oui
9 Décision Comité IT
Non
Accepté?
Oui A
|11
Gouvernance - Gestion de la demande
A Autres processus

11 Préparer les spécifications

fonctionnelles

Yes
A valider 12 Validation des spécifications fonctionnelles
avec client ?

Non

13 Approbation des spécifications

Non
Approuvé ?

Oui

Pré étude Oui

14 Préparer une pré étude
requise ?

Non

15 Préparer un contrat de projet

|12
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

|13
 Gouvernance - Gestion des incidents

Incident report Erreurs sur Batch / TP

HELPDESK

M Log des incidents

I A
N S
U N E
C A
S I R
E G V
D E
R E I
M C
‘IMMEDIATE’
SYSTEMES
S N E GESTION PC OPERATIONS MAINTENANCE
CENTRAUX ET RESEAUX
T E SERVEURS
N
T

COORDINATION ET SUIVI DES INCIDENTS

Quality managers
MAINTENANCE PAR
RELEASE

|14
 Gouvernance - Gestion des incidents

1 Nouvelle demande/modification d’une demande

CLIENTS
Business & functional 2 Analyse de l’incident
units
Oui
Profit centres A fermer ?

IT Non
Standard Non Déjà Non
? qualifié ?
Oui
Oui
3 Etude et qualification de la solution

4 Etude technique de la solution

Estimation
de coûts Oui
5 Demande d’estimation de coûts
nécessaire
?
Non
Non Budgété
6 Demande d’approbation
?
Demande Oui
Oui
approuvée
?
Non
Information client
7 Etude de livraison

8 Inventory check

Inventory Non
9 Commande d’achat
?
Oui

10 Préparation et installation

Requête terminée
|15
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

|16
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

|17
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

|18
 Développement – fonctionnement du
département
Program Management Office
Architecture
Demandes
Domaine Domaine Domaine Domaine
1 2 3 4 INTEGRATION

Projet 1
GLOBALE
Point d’entrée

FONCTIONAL Objets
Projets

DEVELOPMENT Fichier Créés ou INTEGRATION

Projet 2

PRODUCTION
modifiés FONCTIONNELLE
TESTS D’ ACCEPTATION

Contraintes
Pre- diagnostic,

ANALYSE
Mainte- Mainte- Mainte- Mainte- Objets LIVRAISON
Allocation

PRIORITISATION Fichier nance nance nance nance corrigés TESTS D’ACCEPTATION

ALLOCATION

Rapports Rapports Rapports Rapports

Incidents
Responsibilité Responsibilité partagée
Développement Dev/exploit/métiers

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

Besoins métiers
Spécifications Spécifications Test
Développement Tests unitaires UAT Déploiement
Besoins fonctionnelles techniques d’intégration
réglementaires

Infrastructure

Gestion de projet

* User Acceptance Testing

|20
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

|21
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)

|22
 Architecture
Processus fonctionnelle Architecture technique

Responsabilités Compétences

• Assurer la conformité des projets à • Compétences fonctionnelles et techniques

l’architecture globale étendues
• Analyser l’impact et la contribution des • Equilibre entre vision et pragmatisme
projets à l’architecture
• Capacité de traduire la vision en architecture
• Recommender une gouvernance appropriée
pour les projets • Innovant et créatif

• Fournir une guidance architecturale • Bonne communication et esprit d’équipe

• Recommender les méthodes,outils et

techniques de développement
• Revoir les stratégies et plans de test

|23
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

|24
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

Introduction Changement Gestion et

Nouveaux aux amélioration
Services Services Services

Fourniture de services

Gestion des relations avec les fournisseurs

|25
 Exploitation – modèle de fonctionnement
Déploiement de services
 Agit comme interface entre le développement et
Service l’exploitation
Deployment  Déploie des solutions, gère les changements
techniques

Service control
Customers

 Crée et gère des OLAs

Service Service
 Mesure et rapporte la conformité avecles SLA’s et

Suppliers
Managers Operations
Service les OLA’s
SLAs Control
Service C

Service D
Service A

Domain 2
Service B

Domain 1

Domain 3

Domain 4

OLAs OLAs  Prioritise et contrôle les change requests

Users

 Gère les fournisseurs de services

Service operations
 Gère le hardware, les réseaux, la sécurité et les
systèmes
 Gère les actifs
Service managers
 Gère la contingence
 Gère les relations clients, crée et gère les SLAs
 Traite les problèmes réseaux et systèmes
 Traite les demandes des utilisateurs
 Traite et résoud les incidents

|26
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...)

|27
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é

|28
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

|29
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

|30
 Enjeux financiers

100%
12%
17%
Répartition du budget IT

11% Développer de Discrétionnaire

80% 40-50% nouvelles
16% (nouveaux
fonctionnalités
développements)
60% Maintenir
applications
20-25% existantes Non-
40% 77% Discrétionnaire
67% Opérer les (Maintenance +
applications Exploitation)
20% 30-35% existantes

0%
2000 2001 Best Practice

|31
Enjeux financiers
Budget IT
Dépenses discrétionnaires
• Lorsque les dépenses
obligatoires (non
discrétionnaires) représentent
une trop grande partie du
budget IT, l’entreprise peut, à Dépenses non discrétionnaires
certains moments, ne plus être
capable d’investir dans de
nouvelles fonctionnalités
(lancement de produits, ...) Temps
• Par ailleurs, avoir peu de marge Récession
de manoeuvre pour des Budget souhaité
dépenses discrétionnaires rend
le processus de prioritisation des
développements douloureux Capability gap

Budget

Temps

|32
 160
143,7 143,7
140
120
+43,7%
100
100 94,7
80 120,2
55,0
60

Enjeux financiers 40
20 45,0
23,5
49,0 34,1%
16,4%
0
Benchmark Discretionary = Discretionary =
investeringsdossiers Investeringsdossiers
+ continuiteit
Discretionary Non discretionary
160
143,7
140 +43,7% - Temps consacré à la maintenance et aux nouveaux
120 développements par l’équipe de maintenance -
100 61,8
100
80% 74,7%
80 15,2
54,4 70%
60
60%
49%
40 15,1 50%
66,7 43%
20 30,5 40%
0 30% 25,3%
Depository bank average X 20%
10%
Internal staff Contractors Hardware/software costs
0%
Development Maintenance

X Industry average

|33
 Enjeux financiers – Actions

Réduction Eviter les projets à faible ou sans valeur ajoutée 2-5%

2–5%
coûts IT
I. Optimiser la
25-35% du budget gouvernance Mener une stratégie alignée sur les besoins métiers +++
IT Améliorer
capacités +++ Clarifier les rôles et les responsabilités ++
Optimiser les
dépenses discr 10-15% Mesurer la performance des activités IT ++
Réduction Réduire le coût des ressources (int + ext) 7–11%
8-12%
coûts IT
Réduire le coût des applications/infrastructure 1–3%
II. Optimiser le
développement Améliorer la qualité et la prévisibilité du dev ++
Améliorer la Améliorer
contribution de capacités ++ Améliorer les capacités d’implémentation ++
25-35%
l’IT à la valeur
de la société
Améliorer la réactivité et le speed to market +
Réduire les coûts des vendors/contractors 2–6%
Réduction
3-7%
III. Optimiser gestion coûts IT Réduire les frais administratifs 1–2%
65-75% du ressources
budget IT Améliorer Améliorer l’efficacité et la flexibilité du sourcing +
capacités +
Optimiser les Optimiser HR et le knowledge management +
dépenses non discr 15-21%
Réduction Réduire le coût des applications/infrastructure 7–10%
12-16%
coûts IT Réduire le coût des vendors/contractors 5–7%
IV. Optimiser
x-y% Economies observées en
% du budget total
l’exploitation Améliorer l’efficacité opérationnelle, la robustesse ++
Minimiser les arrêts liés à des changements de
Améliorer services ++
++
+++ Valeur indicative de l’impact sur les capacités IT capacités Etre plus orienté clients ++
Améliorer la gestion de la demande et les SLAs +

|34
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

|35
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

|36
Le framework de gouvernance du CISR

|37
Les styles de gouvernance IT

|38