Technique
ITIL, kesako ? Ce qu’est ITIL et ce qu’il n’est pas
ITIL signifie « Information Technology Infrastructure Library »,
il s’agit d’une « bibliothèque » des métiers de l’infrastructure
IT. Bibliothèque s’entend au sens de « conservation de la
documentation sur les métiers de l’Infrastructure ». Les objectifs
d’ITIL visent à documenter certaines des « meilleures pratiques »
en matière de gestion des services informatiques, afin de
constituer un standard de fait. ITIL concerne les activités liées
au support, à la production et à la maintenance. Il permet aux
DSI de contractualiser avec les métiers sur le « bon » service
(efficace, rentable, aligné sur les objectifs business…) et de le
réaliser. ITIL a pour ambition d’apporter une forte valeur ajoutée
à la DSI et à l’entreprise.
Historique et acteurs autour d’ITIL
ITIL a été créé dans les années 80, en Grande-Bretagne,
par la Central Computer & Telecommunications Agency, une
agence du gouvernement britannique, avec pour objectif
de recenser les bonnes pratiques en matière de gestion des
infrastructures IT. Aujourd’hui, ITIL est devenu la propriété de
l’OGC (Office Government of Commerce). Dans les années 90,
ITIL s’est répandu et consolidé, principalement en Grande-
Bretagne, avec constitution du forum utilisateur ITSMF (IT
Service Management Forum), développements sous l’impulsion
de la mise en concurrence systématique des services internes
de l’administration britannique. En 2007, des mises à jour ont
amené la sortie de la V3 d’ITIL.
Comment réussir avec ITIL ?
Les principaux acteurs sont :
l’OGC (Office Government of Commerce), l’Office public
britannique du Commerce, qui vise à travailler avec le secteur
public comme catalyseur pour améliorer l’efficacité dans la
livraison des programmes et des projets. ITIL® et IT Infrastructure
Library® sont des marques déposées de l’OGC.
On assiste depuis 10 ans à une montée en puissance d’ITIL. En 2004, moins de 30 % des DSI interrogées avaient ITSMF est un groupe d’utilisateurs, indépendant, et à but
non lucratif. ITSMF est le seul forum reconnu autour d’ITIL.
entendu parler d’ITIL, en 2007 la notoriété était de 87 % dans les DSI, et aujourd’hui toutes les DSI en ont entendu Il appartient et est animé par ses membres.
EXIN aux Pays-Bas, et ISEB (Information Systems Examination
parler, sans que cette notoriété ait toujours débouché sur des actions concrètes de mise en œuvre. De multiples Board) en Grande-Bretagne sont des contributeurs officiels, en
charge de travaux de certification ITIL, organismes accrédités
opinions se font entendre à propos d’ITIL, on entend parler d’échecs coûteux où des démarches ITIL se sont enlisées, pour délivrer, après examen, les certifications.
Des acteurs privés (éditeurs, SSII, sociétés de conseil)
où des projets se sont avérés lourds, complexes, mal acceptés dans les DSI, et finalement inefficaces. fournissent des logiciels, des services de conseil, et de
formation.
Cet article tentera de montrer comment des incompréhensions à propos de la véritable nature d’ITIL peuvent amener
à des utilisations inappropriées, des actions infructueuses, ressenties comme des échecs, quand elles contrarient la
qualité et la richesse d’ITIL par un usage inadéquat. Avant tout, il s’avère indispensable d’expliquer concrètement ce
qu’est ITIL, et surtout ce qu’ITIL n’est pas. Quelques recommandations seront détaillées pour favoriser des mises en
œuvre réussies.
16 IT-expert n°84 - mars/avril 2010
Au-delà d’une présentation de ce qu’est ITIL, il est également
important de préciser, en quelque sorte « en creux », ce qu’ITIL
n’a jamais prétendu être.
ITIL s’appuie sur les processus
ITIL traite les questions d’organisation par l’angle des processus.
Points communs aux approches processus, elles recherchent
traditionnellement à identifier les « clients » de chaque processus
(qui dit « client », dit qu’il a des objectifs, des attentes, des
besoins), ces approches raisonnent en processus et sous-
processus, activités et tâches (avec des vocabulaires variables
selon les différentes approches).
En conséquence, ITIL ne traite pas les questions d’organisation
par l’angle des structures organisationnelles (services,
départements, organigrammes…). ITIL ne traite pas non plus
(jamais, nulle part dans la bibliothèque ITIL) la question de
trancher quel « acteur » doit être en charge de telles activités ou
opérations ou tâches. Comme toutes les approches processus,
ITIL est transverse aux organisations. Il ne faut pas s’attendre
à une aide d’ITIL sur la question de décider sur ces points. La
réponse à ces questions doit être prise en charge par l’entreprise
elle-même. En effet, les réponses ne tomberont pas toutes faites
de la lecture de cette bibliothèque ITIL des bonnes pratiques.
Un des intérêts majeurs du raisonnement par processus (plutôt
que par organisations) tient dans la possibilité d’aller au-delà
des problèmes liés à l’organisation en place, et de donner envie
aux opérationnels de travailler ensemble à la réussite d’un
processus pour lequel chacun trouvera une motivation à son
bon fonctionnement. En conséquence, dans le cours de toute
méthodologie de mise en place d’ITIL, il s’avère indispensable
de disposer des points d’appui, des structures et des espaces
nécessaires (comités pour validation des décisions…) pour
progresser sur le traitement de ces questions, dont ITIL fait le
choix (pertinent) que la réponse ne soit pas toute faite.
Un recueil des meilleures pratiques,
pas une norme
ITIL recense et décrit de façon détaillée la compilation des
meilleures pratiques, afin qu’elles soient réutilisables, pour
éviter de réinventer les éléments qui sont présents dans la
bibliothèque. A contrario, ITIL ne prétend pas normaliser des
fonctionnements, interdire de procéder d’une manière ou d’une
autre. ITIL ne fixe pas de fonctionnement figé, il se cantonne
au rôle de collection (bibliothèque) d’éléments. Ces éléments
découlent de l’expérience accumulée et reflètent des pratiques
collégialement jugées bonnes par des promoteurs d’ITIL. Et qu’il
est donc bon de partager pour ne pas les réinventer, surtout
lorsqu’ils sont éprouvés depuis des années dans de nombreux
organismes.
IT-expert n°84 - mars/avril 2010 17

ITIL n’est pas exhaustif, loin de là ! Dans des expériences réussies
de mise en place de principes ITIL on observe fréquemment des
actions qui vont au-delà de ce que la bibliothèque commune
propose. Cela ne retire aucun mérite à cette bibliothèque qui
n’a pas pour vocation d’imposer son contenu , mais d’éviter de
réinventer de multiples éléments qui y sont déjà présents.
Fournir des services en soulignant les relations
avec les clients
La bibliothèque ITIL est décomposée selon des processus. La
philosophie de la présentation consiste à toujours repartir des
notions de service au client, d’aligner les processus par rapport
aux résultats attendus, aux attentes, aux besoins et objectifs des
clients du processus. À titre d’illustration, dans chaque chapitre
ITIL on trouve des listes d’indicateurs clés de performance
(Key Performance Indicators KPI), dont la liste s’avère souvent
précieuse. Parmi la liste de KPI dans la bibliothèque, plusieurs
indicateurs sont déjà identifiés à l’intérieur de l’entreprise. Souvent,
ils sont déjà mesurés ou bien déjà identifiés comme importants à
calculer (par ex. pour une entreprise X le pourcentage d’incidents
résolus dans les temps contractuels), les voir dans la liste des
KPI ITIL conforte l’entreprise X sur la réalité de leur importance
pour de nombreuses entreprises de tous les pays. Pour d’autres
indicateurs, l’entreprise X n’avait pas imaginé les calculer : pour un
indicateur qui ne semble pas avoir d’intérêt (par ex. coût moyen
de traitement d’un Incident), l’entreprise X en trouve un autre
qui résulte d’un angle de vue particulier, auquel elle n’avait pas
pensé auparavant (par ex. pourcentage d’Incidents fermés par le
centre de services sans support extérieur), et dont la mesure va
lui permettre de mieux perfectionner son service rendu.
ITIL contribue à une démarche qualité
ITIL est en phase avec les démarches qualité, avec les
représentations processus telles qu’on les trouve dans Six Sigma
(par exemple, la bibliothèque ITIL reprend à son compte un schéma
très proche de celui du SIPOC de Six Sigma pour Supplier-Input-
Processus-Output-Client). Comme ces démarches qualité en
général, ITIL contient également les processus d’amélioration
continue. À l’opposé d’autres démarches qualité et d’amélioration
continue, qui sont volontairement conçues pour être adaptables
dans de très nombreux cas de figure et qui héritent d’emblée, par
construction, d’un fort niveau d’abstraction. ITIL est centré sur
les services de l’infrastructure de l’IT, et la bibliothèque fourmille
d’exemples dont l’application concrète se révèle pragmatique
et immédiate.
Mieux communiquer avec un langage commun
ITIL apporte de nombreux éléments concrets dans sa bibliothèque
et les nomme, ce qui induit un vocabulaire cohérent pour tous
18 IT-expert n°84 - mars/avril 2010
dans l’entreprise. Et, pendant certaines phases de réflexion ou
durant au cours de la transformation, l’entreprise adoptera les
concepts induits par le vocabulaire, et parfois le vocabulaire
induit par ITIL. Ce vocabulaire commun est un facteur facilitant
l’intégration de contributeurs qui proviennent de différents
horizons. ITIL induit des concepts précis, pas toujours en
phase avec le vocabulaire employé au jour le jour dans une
entreprise. Par exemple, ITIL distingue clairement la notion
d’incident de la notion de problème. Dans certains cas, il faut faire
rejoindre les concepts d’ITIL et les concepts de l’entreprise. Les
concepts d’ITIL résultent d’une manière de voir les processus
de service, vision partagée de façon consensuelle par de
multiples organisations, et dans laquelle la vision du service
est fermement implantée. Les concepts employés dans une
entreprise proviennent souvent de processus résultant de
l’empilement au fil des années de modes de fonctionnement.
Cela peut aider à se poser plusieurs questions. Par exemple
aujourd’hui une entreprise A utilise 3 notions, celles de « dossiers
client », « dossiers back-office » et « dossiers correctifs ». Alors,
laquelle correspond réellement à la notion d’incident, ou à la
notion de problème ? Laquelle est à cheval entre les deux ?
Quelles modifications trouvera l’entreprise A pour clarifier
et fluidifier sa manière de prendre en charge les incidents et
problèmes ? Etc.
Pas une démarche uniforme,
ni une méthodologie toute faite
Il ne suffit pas de décréter que l’on va mettre en œuvre ITIL, pour
se doter d’une méthode ou une démarche. Avant de mettre en
œuvre ITIL dans une organisation, il lui faut définir proprement
quels objectifs concrets elle cherche à atteindre (cela peut être
de réparer un processus qui semble « cassé », d’améliorer tel
niveau de service, de mobiliser les équipes autour de la résolution
de difficultés liées à un processus, de gagner en efficacité sur
un sujet…). Ensuite, il convient de déterminer les meilleures
démarches à mettre en place (ampleur des moyens, délais…)
pour atteindre ces objectifs. Certains passages d’ITIL abordent
ces questions, mais on observe souvent que les opérationnels
survolent ces passages d’ITIL qui ne leur sont pas forcément
destinés, mais intéressent plutôt les décideurs. Malgré leur
pertinence, les lignes générales de ces chapitres ne sont pas
toujours applicables. Elles mélangent du bon sens (fixer des
objectifs, mettre en place les moyens de mesurer leur atteinte…)
des notions un peu abstraites (créer une vision...), et des éléments
qui résultent de l’effet collection ou bibliothèque (Business Case,
métriques, Balanced Score Card, techniques pour la conduite
du changement…). Bien qu’intéressants, ces éléments ne sont
pas toujours pertinents. Inutile donc de « dérouler un rouleau
compresseur ITIL ». Comment réussir l’implémentation d’ITIL ? En
prenant du temps et du recul pour décrire ses propres objectifs,
atteignables compte tenu de sa situation de départ, et d’en
déduire le meilleur chemin. Le facteur clé de succès pour un
décideur réside dans cette préparation.
Technique
Comment se présente ITIL ?
ITIL v2 était constitué de 8 ouvrages pour décrire les processus alignant les services fournis avec le
besoin du business. Depuis la v3 des modifications ont été apportées et concernent : la structure
générale, l’introduction de nouveaux outils pour aider à l’implémentation et à la mesure des gains,
et l’introduction de nouveaux outils au niveau stratégique pour aider à promouvoir ITIL auprès des
responsables métiers en terme d’apport à la chaîne de valeur.
Les 5 ouvrages « cœur » du noyau ITIL v3 sont : Stratégie des Services (Service Strategy), Conception
des Services (Service Design); Transition des Services (Service Transition); Exploitation des Services
(Service Operation); Amélioration Continue des Services (Continual Service Improvement). Ces cinq
manuels de référence présentant les constituants de base de l’ITSM, selon l’approche du cycle de vie
des services. Une documentation complémentaire propose des cas particuliers ou des exemples, des
produits à valeur ajoutée, tels que des modèles et des schémas de flux de production.
Objectif : inscrire ITIL V3 dans la dynamique d’amélioration continue et surtout énoncer des conseils
pertinents pour des cas bien particuliers. De plus, l’efficacité opérationnelle se trouve au cœur de
cette nouvelle version. Dans ce sens, ITIL v3 fournit nombre d’éléments avisés : des conseils pour
être en conformité avec les diverses normes et réglementations en vigueur, des directives par secteur
d’activité et rubrique, de nouvelles rubriques concernant les stratégies de gestion des services (services
partagés, cosourcing et externalisation), un système de connaissance très développé favorisant la
gestion proactive des services.
ITIL contient 23 processus (dont 3 sont en cours de description) dans ITIL V3 :
• Stratégie des services : Gestion de la demande, Gestion financière, Gestion du portefeuille des
services
• Conception des services : Gestion du catalogue, Gestion des niveaux de services, Gestion des
fournisseurs, Gestion de la disponibilité, Gestion de la continuité, Gestion de la capacité, Gestion
de la sécurité de l’information
• Transition des services : Gestion des actifs et des configurations , Gestion des changements, Gestion
des mises en production et des déploiements, Gestion de la connaissance, Gestion de l’évaluation
(non décrit) , Gestion des tests et validations (non décrit)
• Exploitation des services : Gestion des événements, Gestion des incidents, Gestion des problèmes,
Gestion de l’exécution des requêtes, Gestion des accès
• Amélioration continue des services : Gestion de l’amélioration continue des services, Gestion du
reporting.
Le sommaire type des données rassemblées à propos d’un processus, à l’intérieur de la bibliothèque
ITIL, rassemble les éléments suivants : Objectifs ; Périmètre ; Concepts de base ; Bénéfices/difficultés,
coûts ; Activités ; Rôle/responsabilités ; Métrologie, Indicateurs et tableaux de bord ; Outils ; Synthèse
et préconisations.
Les objectifs du processus permettent de cadrer le processus, le cadrage est précisé avec l’aide du
périmètre. Le paragraphe sur le périmètre fixe les limites du processus tels que vu par ITIL, et précise les
concepts, et fait la correspondance entre ITIL et la manière de s’y prendre au jour le jour dans telle ou telle
organisation. Les concepts de base permettent de clarifier des notions et du vocabulaire. Les Bénéfices /
Difficultés coûts servent à fournir une liste très opérationnelle d’axes de réflexion sur les enjeux objectifs
et résultats du processus tel qu’il a été cerné, et peuvent donner lieu à implantation concrète parmi les
indicateurs. Les activités permettent de suivre une décomposition logique (plutôt que normative ou
organisationnelle), telle que vue par la bibliothèque ITIL, des différentes activités à exercer à l’intérieur du
processus. Les rôles et responsabilités sont identifiés de manière générique, sans jamais qu’ITIL se mêle
de normaliser et de fixer à quel acteur au sein de l’entreprise devrait revenir telle ou telle responsabilité.
Le paragraphe sur la métrologie, les indicateurs et les tableaux de bord est rempli d’outils dans lesquels
l’entreprise peut piocher pour sa propre utilisation ; les outils sont un catalogue d’idées d’outils dont
l’implantation de certains peut se révéler astucieuse ; la synthèse et les préconisations permettent de
redonner plus de sens à la lecture des différents éléments épars du chapitre.
ITIL indique : les bénéfices et les problèmes possibles, le «comment faire en cible», mais pas le
«comment implémenter».
IT-expert n°84 - mars/avril 2010 19
 Technique

Les éditeurs et le marché des outils ITIL

De nombreux outils progiciels sont présents sur le marché ITIL. Ces outils se sont bâtis pour apporter des solutions « d’informatisation »
de différents processus de l’entreprise, sur le domaine fonctionnel des services de la gestion des infrastructures : gestion du patrimoine
informatique et des inventaires, gestion des incidents et problèmes, gestion actions (interventions…) etc. Ces outils font état d’une
conformité avec ITIL. Celle-ci apporte une certaine garantie que des grands concepts issus du consensus sur la manière de voir et
la manière de faire sont pris en compte, et aussi une certaine garantie que les éléments présents dans la bibliothèque initialement
générée par ITIL sont présents.

En revanche, l’entreprise qui s’en remet au choix d’un outil informatique dit « ITIL » ne doit pas oublier que, comme dans tout projet,
même progiciel, l’adoption d’un outil même « ITIL compliant » ne résout pas à lui seul des questions d’organisation. L’entreprise doit
participer activement aux spécifications de paramétrage, qui l’obligent à répondre à des questions qu’il faut avoir clarifiées, et comme
pour tout projet informatique, l’outil est au service du processus et non le contraire. L’entreprise doit apporter sa participation à la recette
de l’outil paramétré, et vérifier que les données inventoriées sont accessibles, que les processus peuvent être suivis comme prévu

D’autres quick wins ont été identifiés dans différentes situations

Les quick wins autour d’ITIL
ITIL permet des quick wins. Des exemples de gains rapides
sont nombreux, liés de façon très directe ou indirecte à ITIL.
Toutefois, ces gains rapides n’apparaissent souvent qu’après
une mise en place de quelques semaines dans une grande
organisation. En effet, l’organisation doit généralement amender
un outil informatique existant (validation de spécifications,
mise en production…) ou modifier ses processus opérationnels
(planifier, communiquer sur le changement…).
Parmi des gains rapides constatés sur le terrain :
• travailler sur l’attribution automatisée des incidents. Une
matrice d’assignation peut être mise au point, de façon plus
ou moins automatisée. Certaines entreprises ont poussé
très loin cette automatisation, au risque de répartir certains
incidents de façon erronée. Pour d’autres, la matrice a un
rôle d’appui, d’indicateur. Avancer dans cette voie est utile
dans le cas où l’analyse des processus révèle des difficultés
liées à l’étape d’assignation ;
• mettre en place une matrice de priorisation des incidents.
Cette matrice peut déterminer la priorité en combinant l’impact
attendu, l’urgence… ;
• simplifier et regrouper les processus de Gestion de Confi-
guration et de Gestion des Mises en Production (GMEP) ;
• soulever systématiquement certaines questions avant
chaque mise en production, comme clarifier la nature de
l’indisponibilité, clarifier la procédure de retour arrière,
identifier les jalons dans le cours de la MEP pour décider
des retours-arrière... ;
• séparer plus nettement les modalités de gestion des incidents
et des problèmes (GI et GP) et octroyer du temps sur des
tâches de résolution des problèmes ;
• alléger toutes les gestions de demandes très régulières
(réinitialisation des mots de passe, changements
d’habilitations…) et le cas échéant les sortir des circuits de
gestion des incidents ;
• aviser systématiquement les équipes de la hotline de chacune
des mises en production à venir ;
• …
d’aide à la mise en œuvre d’ITIL. Ceux évoqués ci-dessus
ne résultent pas tous de la simple lecture et application des
informations qui se trouvent dans la bibliothèque ITIL. Et ne
sont pas forcément pertinents pour toutes les situations. Il
est important d’impliquer les opérationnels pour identifier ces
actions de modifications. Mettre en avant les quick wins ne doit
pas faire perdre de vue des actions de fond, mais dont la mise
en œuvre est également parfois la seule de nature à apporter
de profondes modifications indispensables.
Écueils fréquents
dans la mise en œuvre d’ITIL
La mise en place d’ITIL n’est pas toujours aisée. Contrairement aux
opinions parfois entendues, il ne suffit pas de s’en remettre à des
« experts ITIL » pour résoudre les problèmes de l’entreprise : ITIL
n’impose ni démarche claire, ni objectifs, ni phasage, ni instances
d’étude et de décision. Au mieux, il rappelle des recommandations,
comme cadrer, phaser, étudier… L’entreprise qui utilise ITIL ne
doit pas attendre qu’il prenne des décisions à sa place. Il lui
reste à être au clair sur les objectifs qu’elle attache à la mise en
œuvre d’ITIL, à identifier les structures qui vont devoir travailler
sur la mise en œuvre, et à prendre les décisions appropriées. ITIL
reste un instrument, propose des éléments pour éviter de tout
réinventer et fournit de la matière pour aider l’entreprise à résoudre
ses problèmes. Cependant, cette bibliothèque n’identifie pas les
problèmes, et ne les résout pas.
Conclusion
ITL présente de nombreux apports bénéfiques : il s’agit d’un
vivier de bonnes pratiques avec des concepts de bon sens, il
présente une organisation claire des processus de production
et des relations entre ces processus, il facilite le dialogue en
établissant un langage commun (interne DSI, métier, fournisseurs,
éditeurs d’outils pour la DSI), c’est une source d’améliorations
à la fois à court terme et à long terme.
ITIL présente aussi quelques limites, qui découlent pour partie de
la construction de l’approche : son contenu relativement dense
et détaillé est plutôt destiné aux opérationnels. Néanmoins,
un apprentissage est nécessaire pour « entrer » dans cette
documentation. Les préconisations ne sont pas toujours très
claires, et restent souvent à décliner par l’entreprise qui définira
ses priorités de mise en œuvre.
Il est utile de passer par des quick wins adaptés de manière
fine et pertinente à l’entreprise, « découverts » et adoptés par
les opérationnels eux-mêmes. Les quick wins peuvent découler
d’emprunts directs à la bibliothèque ITIL dans le texte, ou en
découler plus ou moins indirectement. Dans les deux cas,
l’entreprise tâchera de les relier à ITIL. La démarche mène au
succès lorsque les quick wins mis en œuvre sont associés à
ITIL, et lorsqu’on en attribue la paternité aux opérationnels de
la production. Cela favorise leur intérêt et leur appropriation du
contenu. Une manière aussi de convaincre les opérationnels du
bon usage et du caractère pragmatique, concret, et utilisable
d’ITIL. Par la suite, ils seront alors disposés à poursuivre sur
d’autres chantiers d’évolution ou d’autres procédures de
fonctionnement, dans le même état d’esprit…
Parmi les recommandations concrètes pour une méthode de
mise en place, il faut veiller à rester pragmatique, à procéder
par étapes, avec des objectifs d’amélioration bien définis et
bien délimités, à partir des problèmes réellement posés sur le
terrain et à résoudre. L’entreprise doit agir en priorité là où « ça
fait mal », là où il y aura des gains, pour assurer le succès par
l’adhésion des opérationnels. Enfin, mieux vaut déployer un
savoir-faire soutenu par un outil. Sans pour autant attendre que
l’outil soit seul porteur du savoir-faire de l’entreprise. Un projet
ITIL réussi est porté et mené par les opérationnels.
Pour éviter déconvenues et déceptions, mieux vaut éviter
d’utiliser ITIL comme une norme. Au contraire, les décisions
de management appartiennent aux opérateurs de l’entreprise,
elles ne seront pas dictées par une norme plaquée de l’extérieur.
Mieux vaut aussi éviter d’appliquer la totalité d’ITIL comme un
rouleau compresseur, et -au contraire- délimiter des objectifs
et un périmètre atteignables, et piocher dans la bibliothèque
ce qui est applicable et pertinent.
ITIL est un outil qui ne dicte pas les objectifs, ni les choix
d’organisation cible, et qui n’impose pas strictement la
démarche d’implémentation. Il nécessite de mobiliser les
acteurs nécessaires, internes ou externes, qui ont suffisamment
de connaissances sur ITIL pour savoir en exploiter sa matière
avec un bon état d’esprit pour réussir. n
Hugues Dieuzeide ,
Directeur Associé
Hugues DIEUZEIDE intervient notamment auprès de DSI pour aider à mettre en
œuvre des transformations. Il s’est appuyé à plusieurs reprises sur la bibliothèque
ITIL lors de ces opérations de transformation de processus de la DSI.
ORESYS est une société de conseil en organisation et en S.I., de 250 consultants,
à Paris, Lyon et Bruxelles, spécialisée dans les projets de transformation. ORESYS
aide ses clients à piloter leurs activités, améliorer leur performance et mettre en
œuvre leurs projets de transformation. ORESYS intervient sur toutes les dimensions :
métiers, organisation, processus, système d’information, accompagnement du
changement. ORESYS intervient de manière soutenue pour aider les DSI à transformer
leur organisation et leurs processus, ou à transformer l’entreprise.
Site web : www.oresys.eu

20 IT-expert n°84 - mars/avril 2010 IT-expert n°84 - mars/avril 2010 21