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 dun département informatique Gestion des technologies de linformation – GEST310 Pascale Vande Velde.

Présentations similaires


Présentation au sujet: "Fonctionnement dun département informatique Gestion des technologies de linformation – GEST310 Pascale Vande Velde."— Transcription de la présentation:

1 Fonctionnement dun département informatique Gestion des technologies de linformation – GEST310 Pascale Vande Velde

2 |2|2 Agenda Introduction Activités dun département IT –Gouvernance –Stratégie et planning –Développement –Architecture –Exploitation –Gestion des ressources Enjeux financiers Etude sur la gouvernance

3 |3|3 Quelques clichés..... Comment va-t-on prioritiser mes projets IT ? Pourquoi le département IT na-t-il pas de moyens pour réaliser mes projets ? LIT mimpose ses projets. LIT est un état dans létat. Comme mes projets ont été refusés, jai développé moi-même mes applications en excel/VB Pourquoi mon projet na-t-il pas abouti ?...ou a coûté significativement plus cher et a duré significativement plus longtemps que prévu ? Pourqui nimporte 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 dimplémenter dautres 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 |4|4 Comment adresser ces problèmes ? Comment va-t-on prioritiser mes projets IT ? Pourquoi le département IT na-t-il pas de moyens pour réaliser mes projets ? LIT mimpose ses projets. LIT est un état dans létat. Comme mes projets ont été refusés, jai développé moi-même mes applications en excel/VB –Governance IT Pourquoi mon projet na-t-il pas abouti ?...ou a coûté significativement plus cher et a duré significativement plus longtemps que prévu ? Pourqui nimporte 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 dimplémenter dautres 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 |5|5 Lorganisation dun département IT CIO Développement ProjetsMaintenance ExploitationArchitecture Finance/HR

6 |6|6 Les activités principales dun département IT Gouvernance Gestion des ressources Exploitation Architecture Stratégie & Planning Développement La gestion de projets La gestion deu parc dapplications existants La stratégie et plans IT qui sont alignés sur les besoins métiers de lentreprise Source: Accenture Un management IT qui supporte la vision métiers de lentreprise Une structure de gouvernance qui définit les rôles et responsabilités de lIT et du business et les processus de décision IT Des processus de management et dexécution La définition dune architecture qui permet de rencontrer les besoins de lentreprise Planification et livraison de services dexploitation journaliers Le management des ressources financières et humaines du département

7 |7|7 Gouvernance Définit les rôles et les responsabilités dans les décisions dinvestissements de sorte à aligner la stratégie IT sur la stratégie métiers La gouvernance nest 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 lIT Décisions clés à prendre : –Comment lIT est-il utilisé dans les métiers –Les choix darchitecture (quelles technologies) –Les stratégies dinfrastructure (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 lIT dans le cadre de la gestion de la demande, de la gestion des incidents et de limplémentation de projets –Définissant les processus de : Gestion de la demande Gestion des incidents Implémentation des projets

8 |8|8 Gouvernance - Gestion de la demande Demande –Toute requête pour lévolution ou ladaptation dune application existante –Toute requête pour le développement dune nouvelle application Objectifs –Centraliser les demandes clients –Faciliter lélaboration dun 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 lexpression dun besoin jusquà la signature dun contrat de projet

9 |9|9 Gouvernance - Gestion de la demande Demandes clients –Expression dun besoin formulé par un client et lié à lévolution dune application existante, ou au développement dune 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 | 10 Gouvernance - Gestion de la demande Projects Project CProject BProject A Deliverables Customer demand Demande client 7 Demande client 6 Demande client 5 Request Customer 8 Request Customer 4 Release A1 Version n°1Version n°2Version 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 Request Customer 8 Request Customer 1 Request Customer 2 Request Customer 3 Request Customer 1 Request Customer 2 Request Customer 3 Demande client 7 Demande client 6 Demande client 5 Request Customer 4

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

12 | 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 | 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 daccès Scope –Depuis lexpression dun besoin jusquà la livraison

14 | 14 INCIDENTINCIDENT MANAGEMENTMANAGEMENT Incident report Quality managers Log des incidents Erreurs sur Batch / TP IMMEDIATE MAINTENANCE SYSTEMES CENTRAUX ET SERVEURS USERSUSERS OPERATIONS GESTION PC HELPDESK RESEAUX COORDINATION ET SUIVI DES INCIDENTS MAINTENANCE PAR RELEASE SERVICESERVICE Gouvernance - Gestion des incidents

15 | 15 Gouvernance - Gestion des incidents Nouvelle demande/modification dune demande Analyse de lincident Etude de livraison A fermer ? Oui Non Standard ? Business & functional units Information client Profit centres CLIENTS IT Oui Non Budgété ? Déjà qualifié ? Etude et qualification de la solution 3 Non Inventory check 8 Inventory ? Préparation et installation 10 Commande dachat 9 Oui Non Demande dapprobation 6 Demande approuvée ? Oui Non Oui Non Oui Etude technique de la solution 4 Demande destimation de coûts 5 Estimation de coûts nécessaire ? Non Oui Requête terminée

16 | 16 Demande vs incidents - Problèmes classiques Pas de distinction entre incidents et demandes ou mauvaise distinction Pas de processus de release management pour limplé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 dexploitation Les incidents sont loggés mais pas résolus

17 | 17 Stratégie et planning Maximiser le budget IT réservé à des investissements –Optimiser les coûts dexploitation 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) Sassurer 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 | 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 lobjet 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 dacceptation, donne le sign off pour une mise en production et participe à la refonte de lorganisation, des processus métiers liés à ce projet Les responsables de domaines assurent la cohérence des applications dans leur domaine avec les principes darchitectures globaux; ils sont propriétaires du code source de leurs applications; ils gèrent les configurations de leurs applications et sassurent davoir le nombre adéquat de ressources fonctionnelles et techniques disponibles par application

19 | 19 Développement – fonctionnement du département Demandes Fichier Domaine 3 4 Pre - diagnostic, Allocation Domaine 1 Mainte- nance Mainte- nance Mainte- nance Domaine 2 Program Management Office LIVRAISON TESTS DACCEPTATION PRODUCTION FONCTIONAL DEVELOPMENT ANALYSE PRIORITISATION ALLOCATION Projet 1 Projet 2 Mainte- nance Contraintes Point dentrée Projets Incidents Objets Créés ou modifiés Objets corrigés INTEGRATION GLOBALE INTEGRATION FONCTIONNELLE TESTS D ACCEPTATION Rapports Responsibilité Développement Responsibilité partagée Dev/exploit/métiers Architecture

20 | 20 Spécifications techniques Développement – aperçu du processus de développement Test dintégration UAT Déploiem ent DéveloppementTests unitaires Spécifications fonctionnelles Besoins métiers Besoins réglementaires * User Acceptance Testing Gestion de projet Infrastructure

21 | 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 dun design fonctionnel incomplet Manque de procédures et de documentation pour les tests Pas denvironnement de tests pour gérer plusieurs releases Mauvaise coordination entre léquipe projet et linfrastructure pour la mise à disposition de serveurs et denvironnements de développement, test et production Pas de planning de projet détaillé. La méthodologie de développement nest pas utilisée ou nest 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 dacceptation et le handover organisationnel

22 | 22 Architecture Le département architecture doit veiller à la cohérence globale de larchitecture de la banque, à son coût et à sa capacité dévolution Dans de grandes entreprises, il est commun davoir des architectes par domaine dactivité Les responsables de domaines assurent la cohérence des applications dans leur domaine avec les principes darchitectures globaux. Les architectes et les responsables de domaines définissent ensemble les standards produits. Les architectes doivent sassurer que leur architecture soit rationnelle et ouverte (faciliter lintégration de nouvelles applications)

23 | 23 ResponsabilitésCompétences Assurer la conformité des projets à larchitecture globale Analyser limpact et la contribution des projets à larchitecture 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 Processus Architecture fonctionnelle Architecture technique

24 | 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 nont 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 – lajout de fonctionnalités nécessite beaucoup defforts

25 | 25 Exploitation - Activités Lexploitation est responsable de la gestion de linfrastructure, de la mise en place de nouveaux éléments dinfrastructure, du helpdesk, et de la gestion des relations avec les fournisseurs Gestion des relations clients Fourniture de services Introduction Nouveaux Services Gestion et amélioration Services Gestion des relations avec les fournisseurs Changement aux Services

26 | 26 Exploitation – modèle de fonctionnement Déploiement de services Agit comme interface entre le développement et lexploitation Déploie des solutions, gère les changements techniques Déploiement de services Agit comme interface entre le développement et lexploitation 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 Service control Crée et gère des OLAs Mesure et rapporte la conformité avecles SLAs et les OLAs 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 SLAs et les OLAs 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 | 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 nont 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 dun projet de développement. Ils sont trop peu impliqués dans le planning du projet et il ny 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 linstallation et lexploitation de nouvelles technologies Manque de gestion automatisée (installation de nouveaux serveurs, etc...)

28 | 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 doutsourcing 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 defficacité 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 defficacité

29 | 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 | 30 Fonctionnement financier dun 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 dexploitation et de développement Coûts dexploitation (facturés en fonction de lutilisation) –Amortissements hardware, software de linfrastructure et réseaux –Amortissements software des applications non allouées aux métiers –Coûts du personnel affecté à lexploitation –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 à larchitecture –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 | 31 Enjeux financiers 11% 16% 12% 17% 30-35% 67% 77% 20-25% 40-50% 0% 20% 40% 60% 80% 100% Best Practice Répartition du budget 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 | 32 Enjeux financiers Capability gap Dépenses non discrétionnaires Dépenses discrétionnaires Budget IT Budget Récession Budget souhaité Temps Lorsque les dépenses obligatoires (non discrétionnaires) représentent une trop grande partie du budget IT, lentreprise peut, à certains moments, ne plus être capable dinvestir 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 | 33 Enjeux financiers +43,7% ,7 45,0 23,5 49,0 55,0 120,2 94, Benchmark DiscretionaryNon discretionary 16,4% 34,1% +43,7% ,7 Discretionary = investeringsdossiers Discretionary = Investeringsdossiers + continuiteit - Temps consacré à la maintenance et aux nouveaux développements par léquipe de maintenance -

34 | 34 I. Optimiser la gouvernance Améliorer la contribution de lIT à la valeur de la société Réduction coûts IT 2–5% IV. Optimiser lexploitation 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 % du budget IT 65-75% du budget IT 10-15% 15-21% 25-35% x-y% –10% 5–7% % ++ Mesurer la performance des activités IT Améliorer lefficacité et la flexibilité du sourcing Réduire le coût des applications/infrastructure Réduire le coût des vendors/contractors Améliorer lefficacité 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 dimplémentation Optimiser HR et le knowledge management Clarifier les rôles et les responsabilités Réduire les coûts des vendors/contractors2–6% + ++ Economies observées en % du budget total Valeur indicative de limpact sur les capacités IT Enjeux financiers – Actions

35 | 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 quils pensaient être les points-clés dune bonne gestion IT. Il en est ressorti 3 points : –Standardisation technologique Weve 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. Its become part of the culture. CIO of an investment bank

36 | 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 dinterviews 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 dharmoniser 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 dallocations 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 lemprise sur les décisions IT (besoin dimplémentations rapides, essai de nouveaux produits, etc...) Infrastructure gérée par lIT au niveau de chaque métier avec une recherche dintégration entre métiers Spécialistes IT placés dans les métiers pour faciliter la gestion des besoins IT des métiers

37 | 37 Le framework de gouvernance du CISR

38 | 38 Les styles de gouvernance IT


Télécharger ppt "Fonctionnement dun département informatique Gestion des technologies de linformation – GEST310 Pascale Vande Velde."

Présentations similaires


Annonces Google