Workplace Vs Project En | Help

UI: Workplace / Project-Selektoren in der Navigation und die entsprechenden Settings
Zielgruppe: alle Nutzer

Was sind Workplace und Project?

BIMWorkplace organisiert Informationen in zwei hierarchischen Ebenen:

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

Ein Workplace ist der übergeordnete Bereich, in dem die Arbeitsorganisation, Nutzer und freigegebene Ressourcen verwaltet werden. Ein Workplace kann mehrere Projects enthalten.

Ein Project ist der operative Bereich eines Bauprojekts. Es gehört immer zu einem einzigen Workplace und enthält die spezifischen Mitglieder, Konfigurationen und Daten dieses Projekts.

Einfache Regel: Wenn etwas über mehrere Projekte hinweg verwaltet oder wiederverwendet werden soll, gehört es tendenziell zum Workplace. Gehört es nur zu einem Projekt, gehört es tendenziell zum Project.

Wesentlicher Unterschied

	Workplace	Project
Hauptfunktion	Governance, Administration und gemeinsame Ressourcen	Arbeit und Informationen eines spezifischen Projekts
Hierarchie	Übergeordnete Ebene	Existiert innerhalb eines Workplace
Nutzer	Mitglieder des Workplace	Mitglieder, die dem Project zugewiesen sind
Rollen	Workplace-Rollen	Project-Rollen, separat in jedem Project zugewiesen
Konfigurationsbeispiele	Subscription, Billing, Companies, Workplace Users, Attributes, Permissions, Templates und Credits	Project Info, Teams, Project Users, Naming Standards, Approval Flows, CDE Configuration und Meetings Policy
Datenbeispiele	Administrative Daten und freigegebene Ressourcen	Models, Views, Topics, CDE-Dokumente und -Ordner, Reviews und weitere operative Informationen

Workplace bedeutet nicht unbedingt „Unternehmen“ oder „Vertrag“

Ein Workplace kann verwendet werden, um eine Organisation, Geschäftseinheit, einen Kunden, ein Programm, einen Vertrag oder einen anderen Kollaborationskontext darzustellen, je nachdem, wie die Organisation BIMWorkplace strukturieren möchte.

Daher sollte man nicht davon ausgehen, dass Workplace = Unternehmen oder Workplace = Vertrag.

Project bedeutet nicht unbedingt „Phase“

Ein Project repräsentiert den operativen Kontext eines Projekts. Eine Organisation kann entscheiden, separate Projects für Phasen, Gebäude, Lose oder verschiedene Verträge zu erstellen, aber dies ist eine Entscheidung der Informationsorganisation und keine Plattformregel.

Beziehung zwischen Workplace- und Project-Nutzern

Der Zugriff erfolgt in zwei Ebenen:

der Nutzer gehört zum Workplace, wo er eine Workplace-Rolle und die für ihn zutreffenden Module/Lizenzen hat;
um in einem bestimmten Project zu arbeiten, muss er auch diesem Projekt zugeordnet sein, mit einer eigenen Project-Rolle.

Folglich:

im Workplace zu sein, bedeutet nicht, automatisch Zugang zu allen seinen Projects zu haben;
derselbe Nutzer kann unterschiedliche Rollen in verschiedenen Projects haben;
ein Nutzer kann den Workplace sehen, aber ein bestimmtes Project nicht sehen;
innerhalb des Project kann der endgültige Zugriff weiterhin von der Modullizenz, der Project-Rolle und spezifischen Objektberechtigungen, wie CDE-Ordnern, Topics oder Views, abhängen.

Siehe Roles and permissions für das vollständige Autorisierungsmodell.

Wie der Kontext in der Oberfläche funktioniert

Die Navigation verwaltet den aktuellen Workplace und das aktuelle Project separat.

Zuerst wird der Workplace ausgewählt.
Die Liste der Projects zeigt dann die in diesem Workplace verfügbaren Projects an.
Das Project wird ausgewählt.
Die Module arbeiten dann im Kontext dieses Projects.

Beim Wechsel des Workplace wird der Kontext des vorherigen Project entfernt, bevor die Projects des neuen Workplace geladen werden. Dies verhindert, dass Daten eines Projekts angezeigt werden, das zu einem anderen Workplace gehört.

In der Navigation gibt es auch separate Zugriffe auf:

Workplace Settings — Workplace-Einstellungen;
Project Settings — Einstellungen des aktuellen Project.

Wo was konfiguriert wird

Workplace Settings

Beispiele für derzeit auf Workplace-Ebene verwaltete Bereiche:

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

Project Permissions erscheint in den Workplace Settings, da dort die im Workplace verfügbaren Project-Rollen definiert werden. Die Zuweisung dieser Rollen an Nutzer erfolgt dann im Kontext jedes Project.

Project Settings

Beispiele für derzeit auf Project-Ebene verwaltete Bereiche:

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

Praktisches Beispiel

Stellen Sie sich einen Workplace namens Hospital Central mit drei Projects vor:

Hauptgebäude;
Parkhaus;
Außenanlagen.

Im Workplace werden beispielsweise Nutzer, Unternehmen, Abonnements, Rollen und gemeinsame Ressourcen verwaltet.

Beim Betreten des Project Hauptgebäude sind die angezeigten Models, Topics, CDE-Dokumente, Teams und Konfigurationen die dieses Project. Der Wechsel zu Parkhaus ändert den operativen Kontext, obwohl beide weiterhin innerhalb desselben Workplace verbleiben.

Wie man den richtigen Umfang entscheidet

Fragen Sie: „Sollte dies für mehrere Projects oder nur für das Project gelten, in dem ich mich befinde?“

Mehrere Projects / gemeinsame Administration → Workplace.
Ein spezifisches Project → Project.
Ausschließlich persönliche Präferenz → User Settings.

Häufige Fehler

„Ich sehe den Workplace, aber nicht das Project.“

Zugang zum Workplace allein ist nicht ausreichend. Überprüfen Sie, ob der Nutzer dem Project zugeordnet ist und ob diese Zuordnung aktiv ist.

„Ich habe den Workplace gewechselt und sehe das CDE/Design des vorherigen Projekts nicht mehr.“

Dies ist das erwartete Verhalten. Die Module arbeiten im Kontext des Project, das dem aktuell ausgewählten Workplace gehört.

„Ich habe Zugang zum Project, kann aber ein Modul nicht nutzen.“

Der Zugang zum Project gewährt nicht automatisch alle Funktionalitäten. Es sollten die für den Nutzer verfügbare Lizenz/das Modul, die Project-Rolle, die Funktionsberechtigungen und gegebenenfalls spezifische Objektberechtigungen überprüft werden.

„Soll ich Workplace Settings oder Project Settings ändern?“

Verwenden Sie Workplace Settings für Administration und gemeinsame Einstellungen. Verwenden Sie Project Settings für Team, Standards, Workflows und die operative Konfiguration eines spezifischen Project.

Workplace vs. Projekt