Amber OSby TMM NOW · www.tmm.now
Standard-ProjektstrukturplanDatenstand V3 · gedruckt 10.08.2026
Amber OSSPSP · Regelwerk V3
Anmelden

Arbeitspaket · Nr. 73653

Software/ Formate

Ergebnis: Abgestimmte Softwaren und Schnittstellenlösungen

aktivT2TA
Projektmanagement Services40x Bauwerk - Technische Anlagen

Einordnung

Prozess-Step
Projektmanagement Services
Kostengruppe
40x Bauwerk - Technische Anlagen
VDI 6026
Zielvorgaben/ Randbedingungen (z.B. Raumbuch)
Software
Word
OPUS
Nein
Story Points
0
SPSP-Version
Projektaufsatz
Takt
C

Agentability · Score 72,9

Agent-Assisted · Qualität: vollständig beschrieben

AUTOMATISIERUNGSPOTENZIALDATENVOLLSTÄNDIGKEITSTRUKTURKLARHEITRACI-KLARHEITWISSENSDICHTEKONNEKTIVITÄT100
Flotten-Ø (970 AP)Dieses AP (73653)
AutomatisierungspotenzialØ 61
49
DatenvollständigkeitØ 81
84
StrukturklarheitØ 78
86
RACI-KlarheitØ 85
80
WissensdichteØ 92
100
KonnektivitätØ 40
45

Vergleich V2 → V3: 69,1 72,9

Verantwortung · RACI

Experte
Martin Wachinger
KG-Verantwortung
Martin Wachinger
Fachbereich
Martin Wachinger
RIntegrationsplaner (IP_)
CBIM Manager (BM_)
IBIM Koordinator (BK_), Projektleiter (PL_)

Beziehungsnetz

benötigt 1 · wird benötigt von 2

BENÖTIGT (1)WIRD BENÖTIGT VON (2)736547365725459473653
Alle Kanten als Liste

Benötigt (1)

Wird benötigt von (2)

Beschreibung

Aufgabenbeschreibung

Ziel

  • Jedes Projekt benötigt aufgrund der individuellen Anforderungen eigene Softwarearchitekturen. Diese sollten vom Grundsatz her verstanden werden.
  • Durch den Einsatz unterschiedlicher Software,werden ebenfalls unterschiedliche Formate eingesetzt,die je nach Version Charakteristiken aufweisen.

Beschreibung

  • Die Softwarearchitektur ergibt sich individuell für jedes Projekt
  • Grundsätzlich existieren:
  • BIM-Plattformen: Erstellen das BIM-Modell (bspw. Revit)
  • BIM-Informationsmanagementtools: Erlauben Zugriff auf die Daten,manipulieren diese und generieren Informationen (bspw. DesiteMD)
  • BIM-Werkzeuge: Ergänzen die Funktionen der anderen Tools,sind meist sehr anwendungsspezifisch (bspw. liNear)
  • Die Formate müssen für den Einsatz getestet werden. Es genügt nicht sich auf die Hersteller zu verlassen,da Detailfragen meist unbeantwortet bleiben und erst in der Anwendung Fragestellungen udn Probleme auftauchen.
  • Die projektspezfisiche Softwarearchitektur wird mit Hilfe eines Konformitätstestmodell untersucht und auf Funktionalität überprüft.
  • Das Konformitätstestmodell stellt eine vereinfachte Darstellung des architektonischen Entwurfs dar,anhand dessen alle Projektbeteiligten die Funktionen ihrer eigenen Fachmodelle im überschaubaren Rahmen anwenden und überprüfen. Siehe #73654 
  • Die Entwicklung des Konformitätstestmodells zeigt auf wie die integralen Prozesse zu gestalten sind,indem die Anwendungsgrenzen der Softwares ausgereizt werden. Evtl. müssen in diesem Zusammenhang verschiedene Softwares ausgetauscht werden,da diese keine ausreichenden Funktionalitäten abbilden.
  • Mit Hilfe des Konformitätstestmodells wird nicht nur die Software untersucht,sondern ebenfalls die Formate mit denen die Schnittstellen bedient werden.
  • Die Formatuntersuchung bezieht sich auf die abgespeicherten Daten und Informationen und wie die Softwares diese interpretieren. Ziel ist es eine reibungslose Kommunikation zu gewährleisten.

Standards

typische Eingangsinformationen (Beispiele)

Typische Ergebnisse (Beispiele)

![](/api/v3/attachments/5863/content)

ODER:

![](/api/v3/attachments/5864/content)

Leitfäden/ Checklisten

  • Die Handbücher/ Schulungen/ Foren sind zu Rate zu ziehen.

Arbeitsmittel & Ablage

Ablageort
\\001\_PMX\\020\_PGL

Zuletzt geändert 09.08.2026, 23:30 · Stabile URL /arbeitspakete/73653