You are not logged in.
Pages: 1
Bonjour,
Il y a déjà eu plusieurs sujets sur les lieux, mais avec le multi-entité, le choix de l'organisation n'est pas simple.
En tant que chef de projet sur la gestion de parc, je suis chargé de mettre en place la solution OCS/GLPI. Mon entreprise a une configuration complexe tant sur son organisation territoriale, que structurelle et découpage du parc informatique.
Je teste la version GLPI 0.72 RC2 avec le plugin data_injection.
j'ai une entreprise avec une implantation territoriale Métropole et Outre-Mer. La Métropole est découpé en région (7 régions) et service centraux (Toulouse Paris). Les régions ont un service informatique dédié. Les services centraux ont une organisation sur plusieurs bâtiments, plusieurs services répartis dans les différents bâtiments, plusieurs équipes informatiques responsables chacune d'une partie de ses services. Il n'y a pas de concordance entre bâtiment et domaine de responsabilité d'une équipe informatique sur le parc qu'elle gère. (Je m'explique: une équipe informatique peut gérer un parc réparti sur plusieurs bâtiments; un bâtiment n'est pas dédié à une équipe mais peut contenir des morceaux de parc d'une autre équipe).
J'ai essayé d'organiser mon parc avec:
1- un entité par région : les lieux de la région sont tous dans cette entité
2- une entité par équipe informatique en service central. Problème, les même lieux (bâtiments, bureaux peuvent êtres présents dans plusieurs entités)
Ex:
EntitéRacine_NomEntreprise
Entité1_Region1
Lieux11
Lieux12
Entité2_Region2
Entité3_Region3
Entité4_Region4
Entité5_Toulouse_Equipe1
Batiment1 (le batiment1 est à la fois dans Entité5 et 6)
Bureau11
Entité6_Toulouse_Equipe2
Batiment1
Bureau12
Entité7_Paris_Equipe3
Batiment2
Bureau21
Cette organisation me semblait judicieuse pour:
1- isoler les parcs en fonction des périmètres de responsabilités des équipes informatique
2- Avoir un serveur OCS par équipe informatique (récupération uniquement du parc géré)
3- Import du serveur OCS dédié dans la bonne entité
Note: j'utilise le champs Groupe pour définir le service (au sens organigramme hiérarchique d'une entreprise: )
Cette organisation me pose les problèmes suivants:
1- Les lieux des services centraux doivent êtres dupliqués dans plusieurs entités
2- Un service central peut commander du matériel de façon globale pour plusieurs régions et sera dispatché dans les parcs informatiques locaux (Comment gérer la livraison, et le transfert d'un parc central vers les parc régionaux)
3- Une équipe informatique centrale peut avoir des responsabilité sur Paris et Toulouse (entités différentes et lieux différents)
Questions:
1- mon choix de gestion en entité est-il judicieux?
2- faut-il utiliser un seul serveur OCS avec utilisation du TAG pour l'affectation par lieux?
3- Y a t-il une autre organisation envisageable?
4- Peut-on avoir une liste des tous les lieux de l'entreprise visible dans toutes les entités?
Merci pour votre aide.
Cordialement, BMO
BMO - Toulouse
En production sur 1 Serveur Centos 5.3 - GLPI 0.72.4 - OCS 1.3.3
7000 machines - TAG pour liaison Entités (20) - connexion LDAP (AD & OpenLDAP)
En développement sur 1 Serveur Centos 5.3 - GLPI 0.78.2 - OCS 1.3.3
Offline
A mon avis, l'entité doit être utilisé pour un domaine d'habilitation.
Ensuite il est possible d'avoir un droit sur plusieurs entitiés, soit
- par un droit récursif sur l'entité mère
- par un droit individuel sur chaque entité
Donc avec un découpage du genre
- région 1
- batiment 1
- secteur 1
- secteur 2
- batiment 2
- secteur 2
- secteur 3
Il est tout à fait possible d'avoir un droit sur les différentes implantations du secteur 2 :
+ région 1 > batiment 1 > secteur 2
+ région 1 > batiment 2 > secteur 2
Donc après il faudra jouer avec les TAG pour qu'un nouvelle machine arrive dans la bonne entité (le tag ne permet pas d'affecter un lieu)
Ensuite, je ne suis pas persuader de l'utilité de multiplier les serveurs OCS, sauf si les équipes ont besoin d'accéder à la console pour le déploiement.
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Pages: 1