Workplace Vs Project De | Help

UI : sélecteurs Workplace / Project dans la navigation et leurs Settings respectifs Public : tous les utilisateurs

Que sont Workplace et Project

BIMWorkplace organise l'information en deux niveaux hiérarchiques :

Workplace
└── Project
    ├── CDE
    ├── Explorer
    ├── Design
    ├── Build
    ├── Management
    └── Insights

Un Workplace est l'espace de niveau supérieur où sont gérés l'organisation du travail, les utilisateurs et les ressources partagées. Un Workplace peut contenir plusieurs Projects.

Un Project est l'espace opérationnel d'un projet de construction. Il appartient toujours à un seul Workplace et contient les membres, les configurations et les données spécifiques à ce projet.

Règle simple : si quelque chose doit être géré ou réutilisé entre plusieurs projets, il a tendance à appartenir au Workplace. S'il appartient à un seul projet, il a tendance à appartenir au Project.

Différence essentielle

	Workplace	Project
Fonction principale	Gouvernance, administration et ressources communes	Travail et informations d'un projet spécifique
Hiérarchie	Niveau supérieur	Existe au sein d'un Workplace
Utilisateurs	Membres du Workplace	Membres affectés au Project
Rôles	Rôles de Workplace	Rôles de Project, attribués séparément dans chaque Project
Exemples de configuration	Subscription, Billing, Companies, Workplace Users, Attributes, Permissions, modèles et crédits	Project Info, Teams, Project Users, Naming Standards, Approval Flows, CDE Configuration et Meetings Policy
Exemples de données	Données administratives et ressources partagées	Models, Views, Topics, documents et dossiers CDE, révisions et autres informations opérationnelles

Workplace ne signifie pas nécessairement "entreprise" ou "contrat"

Un Workplace peut être utilisé pour représenter une organisation, une unité commerciale, un client, un programme, un contrat ou un autre contexte de Collaboration, selon la façon dont l'organisation souhaite structurer le BIMWorkplace.

Par conséquent, il ne faut pas supposer que Workplace = entreprise ou Workplace = contrat.

Project ne signifie pas nécessairement "phase"

Un Project représente le contexte opérationnel d'un projet. Une organisation peut décider de créer des Projects distincts pour des phases, des bâtiments, des lots ou des contrats différents, mais il s'agit d'une décision d'organisation de l'information et non d'une règle de la plateforme.

Relation entre les utilisateurs du Workplace et du Project

L'accès se fait en deux couches :

L'utilisateur appartient au Workplace, où il a un rôle de Workplace et les modules/licences qui lui sont applicables;
Pour travailler dans un Project donné, il doit également être associé à ce projet, avec un rôle de Project propre.

Par conséquent :

Être dans un Workplace ne signifie pas avoir un accès automatique à tous ses Projects;
Le même utilisateur peut avoir des rôles différents dans des Projects différents;
Un utilisateur peut voir le Workplace et ne pas voir un Project donné;
Au sein du Project, l'accès final peut encore dépendre de la licence du module, du rôle de Project et des permissions spécifiques aux objets, tels que les dossiers CDE, les Topics ou les Views.

Voir Rôles et permissions pour le modèle d'autorisation complet.

Comment le contexte fonctionne dans l'interface

La navigation maintient séparément le Workplace actuel et le Project actuel.

Le Workplace est sélectionné en premier.
La liste des Projects affiche alors les Projects disponibles dans ce Workplace.
Le Project est sélectionné.
Les modules commencent à fonctionner dans le contexte de ce Project.

Lors d'un changement de Workplace, le contexte du Project précédent est supprimé avant le chargement des Projects du nouveau Workplace. Cela évite d'afficher des données d'un projet appartenant à un autre Workplace.

Dans la navigation, il existe également des accès séparés à :

Workplace Settings — configurations du Workplace;
Project Settings — configurations du Project actuel.

Où configurer chaque élément

Workplace Settings

Exemples de sections actuellement gérées au niveau du Workplace :

Workplace Information;
Projects;
Companies;
Workplace Users;
Workplace Attributes;
Workplace Permissions;
Project Permissions;
Configurations Template;
Usage & Credits;
Enterprise API;
Billing Information;
Subscription.

Project Permissions apparaît dans Workplace Settings car c'est là que sont définis les rôles de Project disponibles dans le Workplace. L'attribution de ces rôles aux utilisateurs est ensuite effectuée dans le contexte de chaque Project.

Project Settings

Exemples de sections actuellement gérées au niveau du Project :

Project Info;
Teams;
Project Users;
Attributes Library;
Naming Standards;
Approval Flows;
Document Operational Statuses;
CDE Configuration;
Model Reference Remaps;
Configurations;
Meetings Policy.

Exemple pratique

Imaginez un Workplace appelé Hôpital Central avec trois Projects :

Bâtiment Principal;
Parking;
Infrastructures Extérieures.

Dans le Workplace sont gérés, par exemple, les utilisateurs, les entreprises, l'abonnement, les rôles et les ressources communes.

En entrant dans le Project Bâtiment Principal, les Models, Topics, documents CDE, Teams et configurations visualisés sont ceux de ce Project. Changer pour Parking modifie le contexte opérationnel, bien que les deux restent au sein du même Workplace.

Comment décider du bon périmètre

Demandez-vous : "Ceci doit-il s'appliquer à plusieurs Projects ou seulement au Project dans lequel je me trouve ?"

Plusieurs Projects / administration commune → Workplace.
Un Project spécifique → Project.
Préférence exclusivement personnelle → User Settings.

Erreurs courantes

"Je vois le Workplace mais je ne vois pas le Project"

Avoir accès au Workplace n'est pas suffisant. Confirmez si l'utilisateur est associé au Project et si cette association est active.

"J'ai changé de Workplace et je ne vois plus le CDE/Design du projet précédent"

C'est le comportement attendu. Les modules fonctionnent dans le contexte du Project appartenant au Workplace actuellement sélectionné.

"J'ai accès au Project mais je ne peux pas utiliser un module"

L'accès au Project n'accorde pas automatiquement toutes les fonctionnalités. Il faut vérifier la licence/le module disponible pour l'utilisateur, le rôle de Project, les permissions de la fonctionnalité et, le cas échéant, les permissions spécifiques à l'objet.

"Dois-je modifier Workplace Settings ou Project Settings ?"

Utilisez Workplace Settings pour l'administration et les définitions communes. Utilisez Project Settings pour l'équipe, les normes, les workflows et la configuration opérationnelle d'un Project spécifique.

Workplace vs Project