Est ce que "Messagerie" est un service distinct du service "Environnement client" ?

Pour cette question, pas de réponse franche. En effet, cela va dépendre de l'approche choisie de l'entreprise. Pour ma part, je serai plutôt rétissant de le proposer dans un Business service indépendant.

J'aurai tendance à l'intégrer comme un service technique qui supporte le Business Service "Environnement client". En effet, la messagerie est une clé de voute de l'infrastructure. Mais cel n'est pas une application métier en temps que tel sinon une application bureautique.

Voici les raisons qui justifie ce choix :

1. L'ensemble des utilisateurs de l'IT ont un accès à la messagerie (il est rare de fournir un acces au système d'information sans fournir une adresse e-mail)
2. Ce service doit être géré au même titre que l'image fournie sur le poste (contenant le système d'exploitation), ou le réseau, également indispensable pour l'utilisateur.
   Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Est-ce que les Business Services sont dans la CMDB ?

Les Business sont dans deux référentiels :

• Le catalogue de service : en effet, ils peuvent être commandé par un ou plusieurs utilisateurs. Ce sont donc intégralement des éléments du catalogue
• La CMDB : comme tout élément décrivant l'infrastructure informatique, on doit les retrouver dans la base des configurations afin de pouvoir leur rattacher les utilisateurs qui les consomment, les éléments logiciels et matériels sur lequel repose le service.
  Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Est-ce qu'un Workaround génère toujours une erreur connue ?

Dernièrement, la question s'est posée lors de la configuration du processus de problème. En effet, il était nécessaire de savoir si le renseignement d'un workaround (solution de contournement) devait obligatoirement définir le problème comme une Known error (erreur connue).

En fait, tout réside dans l'adverbe. En effet, dans de très nombreux cas, un workaround sera trouvé lorsque l'origine du problème aura été défini et donc l'un devient la conséquence de l'autre. Mais cela n'est pas obligatoire.

Dans de nombreux cas, un workaround sera trouvé sans qu'on puisse déterminer l'origine. En voici quelques exemples :

• ordinateur plante régulièrement, je reboot. On n'a bien un workaround mais on ne sais pas pour autant la raison du plantage.
• un batch plante une fois sur 10. Relancer le batch si tous les tests ne sont pas valides. Même chose, on a bien un workaround mais on ne sait toujours pas pourquoi il lui arrive de planter.
   

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Comment mettre en place le PIR du processus de change ?

Pour rappel, le PIR correspond au Post Implementation Revivew. A chaque début de CAB, il doit être pris 10 minutes afin d'étudier les changes réalisés 3 ou 4 semaines plutôt. Il suffit alors de répondre à quelques questions dessus tel que :

• Réalisé dans les délais annoncés ?
• Utilisateurs impactés ?
• Incident généré depuis le change ?
• Dysfonctionnement résolu ?
• Autres remarques ?

Des statistiques issues de ces résultats servent alors au pilotage de ce processus et de s'assurer qu'il répond au besoin premier : permettre de modifier l'infrastructure en maîtrisant les impacts aussi bien techniques que des utilisateurs.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Pourquoi plusieurs processus suivant le type de changement ?

Dans la mise en place du processus de changement, il arrive qu'on ne mette en place qu'un processus de changement quelque soit son type. Pour rappel, un changement peut être majeur, significatif, normal ou urgent.
Dans de nombreux cas, le change urgent reste relativement indépendant des autres car il est souvent traité hors outil, pour son caractère urgent,

Pour les autres types, il est conseillé de mettre en place des processus différents, notamment pour la validation du CAB (change Advisory Board). En effet, mettre en place un processus qui répond au processus majeur sera lourd et cher pour les changes normaux. De l'autre, un procesuss simple risque de décider des changes significatifs sans avoir pris en considération tous les paramètres.

C'est pourquoi, un unique processus peut faciliter la mise en place de ce processus, mais il est nécessaire rapidement de déployer tous les cas adaptés à chaque type.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

A quoi sert le PIR du processus de change ?

Pour rappel, le PIR correspond au Post Implementation Review. Il s'agit après chaque change de faire un bilan. Cela doit se faire , que le change est réussi ou non.

En effet, si le change a bien fonctionné, il est nécessaire de savoir si le dysfonctionnement a bien été résolu. Un change qui se passe bien ne corrige malheureusement pas toujours un dysfonctionnement ! Simplement parce qu'un change qui se passe bien correspond au fait que l'infrastructure fonctionne toujours après mais peut-être que cela n'a servit à rien.

Si le change s'est mal passé, il est plus courant de mettre en place ce bilan. Il s'agit de comprendre l'origine des difficultés rencontrés. Il ne s'agit pas évidemment de trouver le coupable mais de trouver ou le processus a failli : CMDB pas à jour (et donc impact sur l'infrastructure non prévu), représentant du CAB absent (revoir la sélection des opérateurs du CAB).

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Comment optimiser les resets de mot de passe sans donner tous les droits au Service Desk ?

De nombreux incidents concernent des Reset de mot de passe ou des demandes de droits. Ces incidents et request doivent être traités par le Service Desk. Cela permet d'être réactif vis-à-vis des utilisateurs et la procédure répétitive ne nécessite pas de grandes connaissances pour répondre au besoin. Et pourtant, il arrive souvent que cela soit traité, pour un certain nombre d'application au moins, par un opérateur de niveau 3. Cela est souvent dû à l'application elle-même car la gestion des droits se fait dans les fonctions d'administrations et donner cet accès aux opérateurs du Service Desk ne correspond au critère de sécurité.

Pour répondre à cette difficultés, deux solutions peuvent être envisagées :

1. Mettre en place une gestion centralisé des accès : une application dans lequel un opérateur du Service desk va chercher un utilisateur et voir la liste des applications et lier l'un à l'autre. Dans un environnement Single Sign On (login/mot de passe unifié), c'est la meilleur solution mais cela nécessite un travail technique important.
2. Mettre en place une équipe de gestion des droits. Tous les besoins d'accès et de reset sont transférés dans une même équipe. Cette dernière va pouvoir se connecter dans les applications et faire les manipulations nécessaires. Cette équipe peut alors être constitués de spécialistes applicatifs tournants.

Dans tous les cas, il est nécessaire que ces cas n'arrive pas au niveau 3 car le coût de traitement peut être important et le temps de traitement long pour l'utilisateur.

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...