La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Fonctionnement d’un département informatique

Présentations similaires


Présentation au sujet: "Fonctionnement d’un département informatique"— Transcription de la présentation:

1 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 Enjeux financiers
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

6 Les activités principales d’un département IT
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 Gouvernance La gestion de projets La gestion deu parc d’applications existants Stratégie & Planning Développement La définition d’une architecture qui permet de rencontrer les besoins de l’entreprise Architecture Exploitation Le management des ressources financières et humaines du département Gestion des ressources 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

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
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
Customer demand Demande client 7 Demande client 6 Demande client 5 Request Customer 1 Request Customer 2 Request Customer 3 Request Customer 4 Request Customer 8 Similar requests Projects Project A Project B Project C Request Customer 1 Demande client 7 Demande client 6 Request Customer 8 Demande client 5 Request Customer 2 Request Customer 4 Project contract Project contract Project contract Request Customer 3 Release A1 Release A2 Release B1 Release B2 Release B3 Release C1 Deliverables Version n°1 Version n°2 Version n°3 Version n°4 Waiting placement in a version Release A1 Release B1 Release B2 Release A2 Release C1

11 Gouvernance - Gestion de la demande
CLIENTS Nouvelle demande/modification d’une demande 1 Métiers Approbation du business case 2 Autres processus Oui A compléter IT Non Qualification de la demande (type, risque), groupement des demandes si nécessaire, et allocation pour évaluation 3 Elevé Moyen Risque ? Evaluation Evaluation additionnelle 4 5 Faible Rapport d’évaluation Proposition de release 6 Décision Comité demande 7 Approuvé ? Non A escaler ? Non Information domain committee Oui pour arbitrer ou pour approuver Décision domain committee 8 Modifier requête + info client End Non Approuvé ? Modifier requête + info customer A escaler Non Oui Inclus dans le macro planning 10 Décision Comité IT 9 A Non Accepté? Oui

12 Gouvernance - Gestion de la demande
Autres processus 11 Préparer les spécifications fonctionnelles Yes A valider avec client ? Validation des spécifications fonctionnelles 12 Non Approbation des spécifications 13 Non Approuvé ? Oui Pré étude requise ? Oui Préparer une pré étude 14 Non Préparer un contrat de projet 15

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 Gouvernance - Gestion des incidents
Incident report Erreurs sur Batch / TP HELPDESK M A N G E T Log des incidents I N C D E T S E R VI C US E R S ‘IMMEDIATE’ MAINTENANCE SYSTEMES CENTRAUX ET SERVEURS GESTION PC OPERATIONS RESEAUX COORDINATION ET SUIVI DES INCIDENTS Quality managers MAINTENANCE PAR RELEASE

15 Gouvernance - Gestion des incidents
CLIENTS Nouvelle demande/modification d’une demande 1 Business & functional units Analyse de l’incident 2 Oui A fermer ? Profit centres Non IT Non Non Standard? Déjà qualifié ? Oui Oui Etude et qualification de la solution 3 4 Etude technique de la solution Oui Estimation de coûts nécessaire ? Demande d’estimation de coûts 5 Non Non Demande d’approbation Budgété ? 6 Oui Demande approuvée ? Oui Non Information client Etude de livraison 7 Inventory check 8 Non Inventory ? Commande d’achat 9 Oui Préparation et installation 10 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
Program Management Office Architecture Demandes Domaine Domaine Domaine Domaine 1 2 3 4 INTEGRATION Projet 1 GLOBALE FONCTIONAL DEVELOPMENT Objets Fichier Créés ou INTEGRATION FONCTIONNELLE TESTS D’ ACCEPTATION Point d’entrée Projets Projet 2 modifiés PRODUCTION Contraintes ANALYSE Pre PRIORITISATION Fichier - Mainte - Mainte - Mainte - Mainte - Objets LIVRAISON TESTS D’ACCEPTATION nance nance nance nance corrigés ALLOCATION Allocation diagnostic, Rapports Rapports Rapports Rapports Incidents Responsibilité Développement Responsibilité partagée Dev/exploit/métiers

20 Développement – aperçu du processus de développement
Besoins métiers Spécifications fonctionnelles Spécifications techniques Développement Tests unitaires Test d’intégration UAT Déploiement Besoins réglementaires Infrastructure Gestion de projet * User Acceptance Testing

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 Architecture fonctionnelle Architecture technique
Processus Architecture technique 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

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 Introduction Nouveaux Services Changement aux Services Gestion et amélioration Services Fourniture de services Gestion des relations avec les fournisseurs

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 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 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 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 Discrétionnaire (nouveaux développements)
100% 12% 17% Développer de nouvelles fonctionnalités Discrétionnaire (nouveaux développements) 11% 80% 40-50% 16% 60% Maintenir applications existantes Répartition du budget IT 20-25% Non-Discrétionnaire(Maintenance + Exploitation) 40% 77% 67% Opérer les applications existantes 20% 30-35% 0% 2000 2001 Best Practice

32 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, à 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 Dépenses non discrétionnaires Temps Récession Budget souhaité Capability gap Budget Temps

33 Enjeux financiers +43,7% +43,7% 45,0 23,5 49,0 55,0 120,2 94,7 20 40
20 40 60 80 100 120 140 160 Benchmark Discretionary Non discretionary 16,4% 34,1% +43,7% 143,7 Discretionary = investeringsdossiers Investeringsdossiers + continuiteit Enjeux financiers 143,7 +43,7% - Temps consacré à la maintenance et aux nouveaux développements par l’équipe de maintenance - 100

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

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


Télécharger ppt "Fonctionnement d’un département informatique"

Présentations similaires


Annonces Google