Projektspezifisches Informationsmanagement
Konzeption einer projektübergreifenden
Informations- und Kommunikationsplattform
für die Projektbeteiligten
Diplomarbeit
Vorgelegt von
cand.-Ing. Alen Vaclavek
Matr.Nr. 1555057
Tag der Einreichung: 21. Mai 1999
Referent: Prof. Dr. Dipl.-Ing. Mayer
Dipl.-Ing. Bocklitz
Institut für Geotechnik und Baubetrieb
Lehrstuhl für Tunnelbau und Baubetriebslehre
der Technischen Universität München
Inhaltsverzeichnis II
1 Einleitung......................................................................................... 11.1 Hintergrund und Motivation.......................................................................... 1
1.2 Problembeschreibung .................................................................................. 2
1.3 Übersicht...................................................................................................... 2
2 Die IuK-Problematik im Bauwesen................................................. 42.1 Zunahme der allgemeinen Komplexität........................................................ 5
2.2 Erweiterer Planungshorizont........................................................................ 6
2.3 Zersplitterung der Zuständigkeiten .............................................................. 7
2.4 Vermehrte Auslandsprojekte........................................................................ 9
2.5 Erhöhter Wettbewerbsdruck ...................................................................... 10
2.5.1 Beschleunigung des Informationsflusses ...................................... 12
2.5.2 Verbesserte Informationsbereitstellung......................................... 12
2.6 Information als Produktionsfaktor .............................................................. 13
3 Anforderungsanalyse.................................................................... 153.1 Ziele der projektübergreifenden IuK-Unterstützung ................................... 15
3.2 Anforderungskatalog.................................................................................. 18
3.2.1 Systemanforderungen................................................................... 18
3.2.2 Projektsteuerung ........................................................................... 19
3.2.3 Benutzerschnittstelle ..................................................................... 20
4 Elemente einer projektübergreifenden IuK-Plattform................. 214.1 Internettechnologien als Grundlage für einen offenen
Informationsaustausch............................................................................... 21
4.1.1 Offene Standards .......................................................................... 21
4.1.2 Protokolle ...................................................................................... 22
4.1.3 Intranet .......................................................................................... 23
4.1.4 Groupware .................................................................................... 25
4.1.5 Verteilte Hypertextsysteme ........................................................... 26
4.1.6 Elektronische Post-Systeme ......................................................... 27
4.1.7 Bulletin Board-Systeme................................................................. 28
4.2 Lotus Notes/Domino als Integrationsplattform ........................................... 28
4.2.1 Interner Aufbau ............................................................................. 29
Inhaltsverzeichnis II
4.2.2 Dokumentenorientierung............................................................... 30
4.2.3 Replikationsfunktionalität............................................................... 30
4.2.4 E-Mail-Funktionalität ..................................................................... 31
4.2.5 Workflow-Funktionalität ................................................................. 32
4.2.5.1 Send oder Push-Modell: ..................................................32
4.2.5.2 Share-Modell: ..................................................................32
4.2.6 Sicherheitsaspekte........................................................................ 33
4.2.7 Grundlegende Funktionen von Notes............................................ 34
4.2.8 Plattformunabhängigkeit................................................................ 35
4.2.9 Anpassungsmöglichkeiten............................................................. 36
4.2.10 Masken.......................................................................................... 37
4.2.11 Beurteilung .................................................................................... 38
5 Bauspezifische Problemfelder ..................................................... 395.1 Informationsflußgerechte Datenstrukturierung........................................... 39
5.1.1 Zeitpunkt ....................................................................................... 40
5.1.2 Tätigkeitsschwerpunkte................................................................. 42
5.1.3 Informationelle Beziehungen der Projektbeteiligten ...................... 43
5.1.4 Informationsart und -bezugsort ..................................................... 45
5.1.4.1 Zeichnungen der Objektplanung .....................................45
5.1.4.2 Zeichnungen der Tragwerksplanung ...............................45
5.1.5 Projektunabhängige Informationen ............................................... 49
5.1.6 Gesamtbetrachtung....................................................................... 49
5.1.6.1 Planmanagement ............................................................50
5.2 Schnittstellenproblematik ........................................................................... 51
5.2.1 Arten von Industriestandards: ....................................................... 53
5.2.1.1 De Facto-Standards ........................................................53
5.2.1.2 De Jure-Standards ..........................................................53
5.2.2 DXF............................................................................................... 54
5.2.2.1 Kommunikation................................................................54
5.2.2.2 Information ......................................................................54
5.2.2.3 Probeweiser Austausch...................................................55
5.2.2.4 Probleme analysieren......................................................55
5.2.2.5 Nicht nur auf die Technik verlassen ................................55
5.2.3 CAE-Bauwerksmodell ................................................................... 56
Inhaltsverzeichnis II
5.2.4 STEP............................................................................................. 56
5.2.5 GAEB ............................................................................................ 57
5.2.5.1 STLB-Bau – Dynamische Baudaten................................58
5.2.5.2 GAEB 2000 .....................................................................59
5.2.6 REB............................................................................................... 61
5.2.7 ISYBAU......................................................................................... 61
5.2.8 UN/ EDIFACT................................................................................ 62
5.2.9 ICIS ............................................................................................... 62
6 Schluß ............................................................................................ 636.1 Erkenntnisse .............................................................................................. 63
6.2 Ausblick auf zukünftige Entwicklungen ...................................................... 64
7 Anhang........................................................................................... 657.1 DXF-Formblatt ........................................................................................... 65
7.2 Abbildungsverzeichnis ............................................................................... 70
7.3 Literaturverzeichnis.................................................................................... 71
Erklärung............................................................................................. 75
Einleitung 1
1 Einleitung
Wer die Geschichte ignoriert,
ist dazu verdammt, sie zu wiederholen.
Santayana
1.1 Hintergrund und Motivation
Kommunikation wird heute als Übertragung und Verarbeitung von Informationen
verstanden. Erst sie ermöglicht ein vielfältiges Zusammenwirken von Menschen in
allen Bereichen des gesellschaftlichen Zusammenwirkens.
Das globale Netz der Kommunikationspartner in unserer Arbeitswelt vermascht
sich immer enger. Die Mittel der technischen Kommunikation werden so entwickelt
und gebaut, daß Zeichen und Daten in großen Mengen schnell, zuverlässig und
vor allem wirtschaftlich übertragen und verarbeitet werden können. Die
Informationsverarbeitung im Bauwesen (Ausführung und Planung) hat jedoch mit
der allgemeinen Entwicklung der Kommunikationstechnologie in den letzten
Jahren nicht Schritt gehalten. Zur Zeit wächst die Nachfrage nach bauspezifischen
Informationssystemen stetig. Hieraus ergibt sich eine neue Herausforderung an
die Bauinformatik, Informationssysteme für das gesamte (Projektumfeld) zu
planen, zu entwerfen und zu realisieren.
Zu den Aufgabenbereichen der „Bau-Informationssysteme“ gehören neben den
administrativen Aufgaben der Organisation auch die Unterstützung der Bauleitung
vor Ort durch die gezielte Bereitstellung relevanter Daten sowie eine
Unterstützung der Kommunikation und Kooperation zwischen den Baubeteiligten.
Dabei bedarf es bauspezifischer, projektumfassender Informationssysteme und
Fachkonzepte, die flexibel und auf breiter Ebene angewendet werden könnten.
Einleitung 2
1.2 Problembeschreibung
Integrale Planung im Bauwesen erfordert intensive Kommunikation aller
Beteiligten. Dies bedeutet, daß die Anforderungen, über das eigene Fachgebiet
hinaus denken und kommunizieren zu können, stetig wachsen. Kernproblem der
derzeitigen Informationsverarbeitung im Baumanagement sind die explodierenden
Datenströme, die bei der Realisierung von komplexen Bauprojekten erzeugt,
bearbeitet und zwischen den Projektbeteiligten bewegt werden müßen. Dies
resultiert u.a. aus einer zunehmenden Komplexität des Bauablaufs, einem
erweiterten Planungshorizont durch eine ganzheitliche, lebenszyklus-umfassende
Betrachtungsweise des Bauprozesses, zunehmender Zersplitterung/Verflechtung
der Zuständigkeiten und nicht zuletzt aus der wachsenden Menge der pro
Bauwerk aufgenommenen Daten.
Eine zukunftsweisende Datenverarbeitung, und hiermit eine unkomplizierte
Handhabung und Verfügbarkeit von relevanten Informationen, ist heute fest mit
den Möglichkeiten der modernen Telekommunikation verbunden, so daß hierdurch
ein Informationsverbund unternehmensinterner, als auch externer
projektübergreifender Daten auf unterschiedlichen Rechnern an getrennten
Standorten entsteht. So kann z.B. die Vermeidung von Medienbrüchen durch den
direkten Datenaustausch auf elektronischem Weg zu einer Vereinfachung und
Beschleunigung der Abläufe im Baugeschehen führen. Zum anderen verlieren
durch die ständige Verfügbarkeit aller relevanten Informationen sowohl zeitliche
Restriktionen als auch räumliche Entfernungen ihre Bedeutung.
1.3 Übersicht
Die vorliegende Arbeit versucht, dem Leser die Grundkonzepte der Informations-
und Kommunikations1 -Problematik im Bauwesen aufzuzeigen. Soweit als möglich
bleiben die technischen Spezialbegriffe der Informatik ausgespart. Vielmehr soll
versucht werden, eine allgemeine Einführung in die Problematik aus
konzeptionaler Sicht zu geben.
1 im folgenden, der kürzeren Schreibweise wegen, als „IuK“ bezeichnet
Einleitung 3
Zunächst sollen die Gründe für die Notwendigkeit einer verbesserten IuK-
Unterstützung aufgezeigt werden. Die hochgradig kooperative Arbeitsweise im
Bauwesen stellt dazu die entscheidende Triebfeder dar.
Aufbauend auf den speziellen Eigenheiten und Anforderungen des Bauwesens
soll eine Einführung in die technischen Lösungsmöglichkeiten mittels der Internet-
Technologie gegeben werden, welche durch ihr offenes Konzept in der Lage ist,
eine Basis für den Informationsaustausch zwischen allen Projektbeteiligten zu
bilden.
Eine optimale Unterstützung von kooperativen Prozessen und die Voraussetzung,
Partner mit verschiedensten EDV-Konstellationen datentechnisch zu vereinen,
bedarf einer ausgereiften, flexiblen und anpassungsfähigen Integrationsplattform.
Die Groupware Lotus Notes ist genau für diesen Zweck entwickelt worden und soll
beispielhaft für das Groupware-Konzept erläutert werden.
Eine Betrachtung der komplexen Informationsflüsse im Bauwesen bildet die
Grundlage einer optimierten Datenstruktur für die Zusammenarbeit der
Projektbeteiligten und ihre Einbindung in ein organisatorisches Konzept.
Für die praktische Zusammenarbeit zwischen den einzelnen organisatorischen
Einheiten bildet der Datenaustausch unterschiedlichster Spezial-Software durch
das Fehlen leistungsfähiger Austausch-Schnittstellen eines der größten Probleme.
Mit einer Beschreibung wichtiger Software-Schnittstellen und –Standards möchte
ich zum Ende meiner Diplomarbeit auf die Tatsache hinweisen, daß – im Sinne
eines offenen Informationsaustausches – proprietäre Einzellösungen in der
Informations- und Kommunikationstechnik zur Computerwelt von gestern gehören.
Die IuK-Problematik im Bauwesen 4
2 Die IuK-Problematik im Bauwesen
Bauprojekte zeichnen sich durch hohe Individualität aus. Standorte wechseln
ebenso wie die Zusammensetzung der Projektteams, die aus Mitarbeitern der
Bauunternehmen, Planern und Projektsteuerern sowie weiterer Partner bestehen.
Diese können über die ganze Welt verteilt sein, wodurch eine gesicherte und
effiziente Kommunikation und der Erfahrungsaustausch zu einem besonderen
Erfolgsfaktor wird.
Für die Planung von Bauvorhaben existieren zahlreiche Programme für CAD und
Statik, die untereinander aber nur ansatzweise kompatibel sind. Medienbrüche bei
der Übermittlung von Daten zwischen Planern, Prüfern, Projektsteuerern und
Ausführenden sind an der Tagesordnung. Aber selbst bei einheitlicher
Softwareumgebung werden Unterlagen weitgehend per Papier verteilt, da es an
der notwendigen Kommunikationsstruktur mangelt.
Kommunikation, gemeinsame Informationsbasen und die Einbeziehung aller
Beteiligten an Bauprojekten ist daher eine wesentliche Voraussetzung, um die
Effektivität zu erhöhen und Kosten zu sparen.
Mit zunehmender Einbindung von unterschiedlichen Beteiligten nimmt sowohl die
Arbeits- als auch die Organisationskomplexität zu.
Andere Einsatzmöglichkeiten für eine IuK-Plattform ergeben sich aus der
Notwendigkeit, Daten aus einzelnen Bauprojekten zu sammeln und zu verdichten,
um den Entscheidungsträgern Grundlagen für das Controlling ihrer
Verantwortungsbereiche zur Verfügung zu stellen.
Weitere wichtige Themen in Bezug auf Kommunikation und Information sind
Wissensmanagement in Form von „Knowledge-Bases“, die innerhalb einer
weltweit tätigen Baufirma Kompetenzen und technische Projektdetails zur
Verfügung stellen.
Im folgenden möchte ich nun näher auf die spezielle Problematik des Bauwesens
eingehen, die eine bessere IuK-Unterstützung für das Zusammenwirken aller am
Bau Beteiligten notwendig macht.
Die IuK-Problematik im Bauwesen 5
2.1 Zunahme der allgemeinen Komplexität
Das Bauwesen zeichnet sich traditionell durch eine äußerst arbeitsteilige
Ausprägung aus. Phasen intensiver Zusammenarbeit zwischen
unterschiedlichsten wirtschaftlich selbständigen Partnern stehen im Kontrast zu
häufigem Partnerwechsel.
Planung als informationsverarbeitender Prozeß bedarf insbesondere in den
Kommunen des Zusammenwirkens einer Vielzahl von Akteuren. An
Bebauungsplanverfahren sind eine Vielzahl an Gremien und Trägern öffentlicher
Belange regelmäßig beteiligt.
Neue Entwicklungen, von Spezial-Bauverfahren über technische
Gebäudesimulation bis hin zu virtuellen 3D-Modellierungen zur
„Erfahrbarmachung“ des noch zu errichtenden Objekts und Beurteilung
verschiedenster Planungsalternativen, sind Auslöser für eine Zunahme der am
Projekt beteiligten Fachleute und einer engen Verzahnung verschiedenster
Fachbereiche. Die zu handhabende Informationsmenge sowie die
Interdisziplinarität von Aufgaben wächst dadurch exponentiell.
Die Planung solch komplexer Bauobjekte ist nur noch unter Zuhilfenahme
leistungsstarker Rechner und Rechner-Netzwerke zu bewältigen, die die
Zusammenarbeit der Planungsbeteiligten und deren Informationsaustausch
koordinieren.
Die zunehmende Komplexität der wechselseitigen Abhängigkeiten und
Rahmenbedingungen macht es notwendig, die Übersicht und Kontrolle über das
Gesamtprojekt zu verbessern, da sie sowohl für das Projektmanagement als auch
für die Funktionsfähigkeit der Kooperation der Beteiligten essentiell sind. Dies
erfordert2:
1. die Realisierung der Zusammenarbeit von Personen an unterschiedlichen
Orten
2 Information der Forschergruppe „VerteilteAssistierendeBauplanung“ an der Universität Karlsruhe
Die IuK-Problematik im Bauwesen 6
2. den Austausch und die gemeinsame Verwendung einer Vielzahl von
verschieden stark strukturierten Daten in der jeweils aktuellen und
verbindlichen Version
3. die Unterstützung bei der Festlegung von Anforderungen und der Bewertung
von Planungsalternativen bezüglich Eignung und lebenszyklusrelevantem
Verhalten.
2.2 Erweiterer Planungshorizont
Das Augenmerk von Bauherren und Planern war bisher auf Planung und Bau
eines Gebäudes gerichtet, Maßstab waren die Investitionskosten. Durch Facility
Management3 verschiebt sich die Priorität auf die Nutzungsphase, Betriebs-,
Unterhalts- und Wartungskosten gewinnen an Bedeutung. Der Planungshorizont
muß sich daher auf den gesamten Nutzungszeitraum einschließlich abzusehender
Nutzungsänderungen, Umbauten, Sanierungen usw. erweitern.
Wichtigste Grundlage für ein effizientes Faciliy Management ist ein – schon
während der Planungsphase beginnend – in eine optimale Datenstruktur
eingegliederter Objekt-Datenbestand.
Bei bestehenden Gebäuden ist eine Datenerfassung meist sehr mühsam und
aufwendig (Fotogrammetrie, Digitalisieren von Grundrissen auf Transparent,
Bestandsaufnahme technischer Anlagen usw.). Bei Neubauten liegt das gesamte
Potential an Informationen und Daten bei den Planungsbeteiligten und
Ausführungsfirmen. Wenn es gelingt, dieses Potential für Gebäudenutzer
verfügbar zu machen, dann ist eine wesentliche Grundvoraussetzung für eine
Realisierung von FM erfüllt.
CAFM4-Systeme unterstützen dabei die Erfassung, Übernahme und
verschiedenste Verarbeitung der in Datenbanken gesammelten Objektdaten.
3 „Facility Management ist die Betrachtung, Analyse und Optimierung aller kostenrelevanten
Vorgänge rund um ein Gebäude oder bauliches Objekt.“(GEFMA Definition Richtlinie 100, Bonn1996) entnommen aus: [Nä98], S.1
4 CAFM = Computer Aided Facility Management
Die IuK-Problematik im Bauwesen 7
Um einem Informationsverlust nach Fertigstellung und Übergabe eines Gebäudes
entgegenzuwirken, ist die Bildung eines gemeinsamen Datenpools für Planung,
Ausführung und Nutzung ein hilfreiches Unterstützungsmittel
LEBENSPHASEN
VerwertenNutzung /Betreiben
Bau /ErstellungPlanungEntwerfen /
Konzeption
Anpassung
ZEITSTRAHL
EDV-Werkzeuge
CAFM
DatenpoolDatenpool
VR CAD Projekt-planung ...GLT
Abbildung 1: Einheitliche Datenbasen während der Lebensphasen5
2.3 Zersplitterung der Zuständigkeiten
Einerseits der Trend zur Übernahme einer vollständigen Projektbetreuung (von
der Finanzierung über Planung und Ausführung bis hin zum privaten
Betreiberkonzept) und andererseits eine sich immer weiter zersplitternde
Aufgabenteilung kennzeichnen die momentane Lage der Bauwirtschaft.
5 [Nä97], S.65
Die IuK-Problematik im Bauwesen 8
Unter dem Stichwort „Outsourcing“ werden Teilplanungen ausgelagert.
Weitreichende Dezentralisierung mit gleichzeitig höherer Delegation von
Aufgaben, Verantwortlichkeiten und Kompetenzen sind sichtbare Zeichen dieser
Entwicklung.
Hierzu ein Beispiel, wie sich durch interdisziplinäre Planung und
Aufgabenzersplitterung Planungsabläufe verändern. Dadurch wird der enorme
Kommunikationsbedarf in der Planungsphase deutlich:
Ein Architekt konzipiert eine Doppelfassade (Glasfassade) als gestalterisches
Element. Der Bauphysiker prüft die Konsequenzen auf Wärme- und Kälteschutz,
empfiehlt eine Hinterlüftbarkeit im Sommer, Sonnenschutz und Tageslichtlenkung
(ggf. durch eine Simulation untermauert). Der RLT-Planer schlägt eine zeitweise
Nutzung der Doppelfassade als Zuluftfassade vor. Außerdem Nachtkühlung im
Sommer mit Nutzung von Speichermassen. Der Architekt verzichtet deshalb auf
abgehängte Decken und wählt eine offene Deckenrasterkonstruktion.
Ergebnis: Wärmebedarf im Winter verringert wegen zusätzlicher Außenhaut,
Kältebedarf im Sommer verringert wegen Hinterlüftung und Nachtkühlung.
Strombedarf verringert wegen Tageslichtlenkung und ggf. Jalousie- und
Kunstlichtsteuerung usw6...
Die Systemvorschläge eines technischen Planers müssen somit aus einer
ganzheitlichen Perspektive heraus getroffen werden, die Aspekte verschiedenster
Fachbereiche berücksichtigen muß.
Es sind Absprachen über Daten, Nachrichten, Arbeitsabläufe oder ganze
Anwendungssysteme im Sinne einer zwischenbetrieblichen, umfassenden
Integration notwendig. Schnittstellenprobleme, die Notwendigkeit von Nacharbeit
und Fehlerquellen beim Datenaustausch können so vermieden werden.
6 Artikel erschienen in: Beratende Ingenieure, Ausgabe 6/96
Die IuK-Problematik im Bauwesen 9
2.4 Vermehrte Auslandsprojekte
Abbildung 2: Deutsche Bauwirtschaft: Auftragseingang aus dem Ausland
Abbildung 3: Deutsche Bauwirtschaft: Bauinvestitionen in der EU 19977
7 Abbildungen 2 und 3: http://www.bauindustrie.de/hdb0004.htm am 30.04.99
Die IuK-Problematik im Bauwesen 10
Die Abbildungen 2 und 3 verdeutlichen den enormen Anteil und Zuwachs der
Wirtschaftsleistungen der deutschen Bauwirtschaft im Ausland.
Gekoppelt an deutsche Firmenzentralen und Planungsbüros werden
Großbauvorhaben über große Entfernungen zeit- und ortsunabhängig geplant,
koordiniert und betreut. Über Internet-basierte IuK-Systeme kann weltweit ohne
Zeitverluste und ohne störende Einflüsse der Zeitverschiebung im Projetktteam
gearbeitet werden. So kann „in Zukunft die zeitlich meist verspätete
Dokumentation in Projekten durch eine ziel-orientierte und Transparenz
schaffende Kommunikation“ abgelöst werden8.
2.5 Erhöhter Wettbewerbsdruck
„Weltweiter Konkurrenzdruck erfordert schnellere Problemlösungen, welche nur
durch Flexibilität und problemrelevante Koopertation erreicht werden können.“9
Die Öffnung der europäischen Grenzen , der Rückgang des Baubooms in den
neuen Bundesländern, sowie der generelle (vielfach diskutierte) Trend zur
Globalisierung sind nur die offensichtlichsten Gründe für einen erhöhten
Wettbewerbsdruck in der deutschen Bauwirtschaft.
Die Zusammenführung aller Informationsflüsse zwischen den am Projekt
Beteiligten bietet die Möglichkeit, den gesamten Projektablauf durch Verbesserung
der Kommunikation, Koordination und – daraus resultierend – der Kooperation
wesentlich effizienter zu gestalten.
8 Vgl.: IuK-System PKM: http://www.dreso.com/Themen_des_Jahres/pkm.htm am 23.04.999 [TSMB95], S.3
Die IuK-Problematik im Bauwesen 11
Kommunikation
Koordination
Kooperation
Abbildung 4: Kommunikation – Koordination - Kooperation
Folgende Gründe sprechen für die Einrichtung einer projektübergreifenden IuK-
Plattform zur Effizienzsteigerung der entscheidenden – sich gegenseitig
beeinflussenden – Wettbewerbsfaktoren Zeit – Kosten – Qualität.
Zeit
Qualitä
t
Kosten
Abbildung 5: Die sich gegenseitig beeinflussenden Wettbewerbsfaktoren
Die IuK-Problematik im Bauwesen 12
2.5.1 Beschleunigung des Informationsflusses
„Eine Projektleitung darf keinerlei Informationsverzögerung akzeptieren.“10
Das Verlangen nach immer kürzeren Bauzeiten (trotz zunehmender Komplexität)
erfordert Frühwarnsysteme, die es ermöglichen, frühzeitig Abweichungen vom
Soll-Verlauf und Störgrößen im Bauablauf zu erkennen. Arbeitsabläufe können so
rechtzeitig überdacht werden und Korrekturmaßnahmen eingeleitet werden, bevor
ein Projektabschnitt zeitkritisch geworden ist. Außerdem können
• Alternative Einsatzpläne bzw. Baustellenabläufe schneller ermittelt und
bewertet werden.
• Auswirkungen von Veränderungen können frühzeitig beachtet werden.
• Auf schneller verfügbaren Informationen können fundiertere Entscheidungen
getroffen werden.
• Über ein Groupwaresystem können Planlieferungen, Besprechungen und
sonstige kooperative Prozesse und Entscheidungen koordiniert werden.
2.5.2 Verbesserte Informationsbereitstellung
Aktuelle, immer zugriffsbereite Informationen ermöglichen ein optimales
Controlling und somit die effiziente Disponierung von Personal, Material, Geräten
und Fremdleistungen.
• Zutreffende (tagesaktuelle) Vorgaben machen eine schnelle Bestimmung der
kosten- und zeitrelevanten Größen und eine zeitnahe Kostenkontrolle möglich
• Sie liefern frühe Vorgaben für den Kosten- und Zahlungsverlauf der Baustelle.
• Durch frühzeitig prüfbar verfügbare Abrechnungsunterlagen ist eine bessere
Finanzierung durch schnellere Rechnungsstellung (Abschlags- und
Schlußrechnungen) erreichbar.11
10 [Wi97] S.1511 [WiSe95] S.178
Die IuK-Problematik im Bauwesen 13
2.6 Information als Produktionsfaktor
Werkstoffe, Betriebsmittel und Arbeitsleistungen bilden die klassischen
Produktionsfaktoren. Doch zunehmend wird auch die „Information“ als
unternehmerische „Ressource“ angesehen.
„Informationen sind wie Investitionen zu sehen: Sie erfordern Einmalaufwand,
verursachen Betriebskosten und bewirken Effekte, die zu quantifizieren sind...“12
Die gegenwärtige Dezentralisierung der Wirtschaft geht mit einem dramatisch
wachsenden Stellenwert der Information einher. Die Informationstechnik entwickelt
sich zu einer strategischen Waffe im Wettbewerb. Vernetzt-kooperatives Arbeiten13
wird die Art, wie wir arbeiten, grundlegend ändern.
Der Wandel innerhalb der Unternehmen (und im Umgang mit dem Unternehmen-
Umfeld) geht mit einigen Veränderungen einher:14
• die kooperative Arbeit gewinnt an Bedeutung
• Information wird zum wesentlichen Wettbewerbsfaktor
• Abflachung der Hierarchien
• Stärkung der Eigenverantwortung
• Teamarbeit
• Optimierung der Zusammenarbeit mit externen Partnern, z.B. „strategische
Allianzen“
• Zunehmende Orientierung an den verschiedenen Zielgruppen des öffentlichen
Interesses (z.B. ökologische Verbände)
12 [MaKl89] S.1313 So ist z.B. beim 11.Forum Bauinformatik ein Schwerpunkt :Vernetzt-kooperatives ArbeitenVgl.: [http://www.iib.bauing.tu-darmstadt.de/forum99] : 11.Forum Bauinformatik , 22.– 24.
September 99, TU Darmstadt ]
14 [KoKu95], S.23ff
Die IuK-Problematik im Bauwesen 14
Allen diesen Standpunkten ist eines gemeinsam: Sie verlangen Kooperation,
Kommunikation und Information. Diese Merkmale sind sowohl in der internen
Organisation als auch im Umgang mit externen Unternehmen von unverzichtbarer
Bedeutung.
Anforderungsanalyse 15
3 Anforderungsanalyse
Eine Verbesserung der projektübergreifenden Kommunikation sowie eines
reibungslosen Informationsflusses, möglichst unter Einbeziehung aller
Projektbeteiligten stellt eine Reihe von Anforderungen an eine zu entwickelnde
IuK-Plattform. Dabei sind Aspekte aus Sicht des Projektablaufs, der einzelnen
teilnehmenden Organisationseinheiten sowie der Benutzer zu berücksichtigen.
Da die einzelnen Anforderungen teilweise konkurrierend (sich gegenseitig
ausschließend) oder komplementär (gegenseitig fördernd) sind, können sie nicht
isoliert voneinander betrachtet werden.
3.1 Ziele der projektübergreifenden IuK-Unterstützung
„Die Zielfestlegung umfaßt die kritische Überprüfung der Systembeschreibung und
darauf aufbauend das Setzen globaler Informationsziele für das neue
computergestützte Informationssystem.“15
1. Verbesserung der projektübergreifenden Kommunikation, durch
• Ergänzung der bisherigen Kommunikation
• Beschleunigung von Kommunikationsprozessen (innerhalb und zwischen
den einzelnen Organisationseinheiten)
• Einbeziehung aller Projektbeteiligten auf allen Funktionsebenen in den
Informationsaustausch
• Allgemeine, zeit- und ortsunabhängige „Erreichbarkeit“ von
Informationsempfängern
• Ermöglichung von „strukturierter“ Kommunikation16
15 [HBW96], S.16016 siehe Kapitel 4.2.7: Lotus Notes: Grundlegende Funktionen
Anforderungsanalyse 16
• Hilfestellung bei der alltäglichen kooperativen Arbeit und Koordination von
Tätigkeiten
• Gemeinsame Ideenfindung und -sammlung; kooperative Nutzung bzw.
Verarbeitung von Information17, projektübergreifender Wissensaustausch
2. Verbesserung des Informationsflusses, durch
• aufgabenbezogene Informationsbedarfsdeckung, als elementare
Zielsetzung eines Informationssystems18
• Beschleunigung des Informationsaustausches
• zeit- und standortunabhängige kooperative Nutzung von Informationen
• gezielte Informationsverteilung
• Verkürzung von Antwortzeiten durch Vermeidung von Liegezeiten und
schnelle Datenübertragung
• Unterstützung bei der Koordination von Routineabläufen
• automatische Einbeziehung von definierten „Standard-
Kommunikationskanälen“ (z.B. über E-Mail- und Dokumenten-
Verteilerlisten)
• Vermeidung von Erfassungsfehlern und einfache Weiter- und
Nachbearbeitungsmöglichkeit von visualisierten Informationen (z.B. CAD-
Objekten) durch Vermeidung von Medienbrüchen
• automatisiertes Berichtswesen (Mahnlisten, Planstatuslisten,
Vorschaulisten, Objektlisten, Dokumentation des Planablaufes)
17 [KoKu95], S.49
18 [HBW96], S.14
Anforderungsanalyse 17
3. Verbesserung der Informationsqualität, durch
• bedarfsgerechte Informationsbereitstellung, d.h. die Informationen müssen
zeitgerecht, umfassend und zum gewünschten Zeitpunkt zugriffsbereit
sein.19
• Erhöhung der Transparenz und Aktualität (Teilprozesse, die ein Vorgang
durchläuft, sind an zentraler Stelle dokumentiert und der Status ist jederzeit
einsehbar und auf dem aktuellsten Stand)
• durchgehend klare, ersichtliche Strukturierung der Informationseinheiten
• Sortiermöglichkeit nach Dringlichkeit
• Verknüpfung mit relevanten Anschluß-Informationen
• Steigerung der Glaubwürdigkeit durch gemeinsame Informationsquelle
• Überwachung der Archivierung
• Förderung der Standardisierung durch einheitliche, konsistente und
reglementierte Datenhaltung
4. Indirekte Zielsetzungen:
• Verbesserung des allgemeinen Projektablaufs20
• Ganzheitliche Betrachtungsweise von Prozessen, da durch das Wegfallen
von zeitlichen und räumlichen Grenzen Vorgänge, die bisher mehr oder
weniger isoliert voneinander bearbeitet wurden, zu Prozessen
zusammengefaßt werden können, ohne auf Standorte oder
Abteilungsgrenzen achten zu müssen
• konsistente Sammlung beweiskräftiger Unterlagen
• effizienterer Personaleinsatz durch Reduzierung des Aufwandes im
„indirekten Leistungsbereich" (Posteingang, Verteilung, manuelle
Eintragungen, mehrfache Unterschriften, Akten anlegen, Ablage etc.)
19 [HBW96], S.1420 Vgl. Kapitel 2.5: Wettbewerbsdruck
Anforderungsanalyse 18
• optimale Voraussetzung für digitale Archivierung, da alle relevanten Daten
in chronologisch aufbauender und elektronischer Form von Beginn in eine
feste Struktur eingebunden werden
• Unterstützung der Entscheidungsfindung durch eine exaktere
Informationsbasis
• Optimierung von Arbeitsabläufen durch Standardisierung des Arbeitsflusses
(„Workflow“);
• Abbau des Formularbestandes
• Förderung der Teamarbeit durch partnerschaftliche Ausrichtung aller
Beteiligten
• Projektübergreifende Erschließung lokaler (allgemeiner sowie spezieller)
Wissensbestände
3.2 Anforderungskatalog
3.2.1 Systemanforderungen
• Aufbau einer projektspezifischen dokumentbezogenen Datenbank als
Datenpool für alle am Projekt beteiligten Kooperationspartner
• Organisatorische Integration, d.h. das Informationsystem muß mit der
Organisationsstruktur der Projektumgebung abgestimmt sein.21
• Vollständige Integration aller projektrelevanten Dokumente in ein einheitliches,
konsistentes Dokumentenmanagementsystem mit einer auf die Bau-
Informationsflüsse abgestimmten reglementierten Datenablage
• Offenes und flexibles System, das die Möglichkeit bietet, Datenbestände aus
anderen Systemen zu übernehmen
21 [HBW96], S.14
Anforderungsanalyse 19
• Einbindung des Projekt-Datenpools in die Informationskreisläufe der
Einzelorganisationen/-unternehmen; Koexistenz- und Integrationsfähigkeit in
bestehende DV-Landschaft
• Unkomplizierte Anbindung weiterer Projektbeteiligter
• Sukzessiver Aufbau durch modulare Strukturen, um sich an Veränderungen
anpassen zu können.22
• Durchgehende Dokumentation der Aktivitäten im Datenpool
• Abgleichsmechanismen für die Änderungsfortschreibung23
• Die Wartung des Systems sollte darüberhinaus - soweit möglich - vereinfacht
werden.
• Sichere Abschottung des Systems nach außen24
3.2.2 Projektsteuerung
• Unterstützung des Projektmanagements durch eine strukturierte, QM-gerechte
und rechnergestützte Projektdokumentation
• evtl. Einbezug von Vorgangssteuerungssystemen auf der Basis des Workflow-
Gedankens
• Einrichtung eines elektronischen Berichtswesens
• Bearbeitungsschritte sollten einheitlich durch das System definiert werden
können (Workflow-Modellierung)
• Unterstützung der Bauleitung auf der Baustelle durch einfache Anbindung
mobiler Arbeitsstationen
22 [Nä98], S.9123 Abgleichsmechanismen sorgen im Sinne einer „Vater-Sohn“-Beziehung für die Änderung aller
Kopien (Söhne) bei einer Änderung des Originals (Vater) [Kr94], S.2824 Vgl. Kapitel 4.2.6: Lotus Notes: Sicherheitsaspekte
Anforderungsanalyse 20
3.2.3 Benutzerschnittstelle
• Um Einarbeitung, Bedienung und Akzeptanz zu erleichtern und zu fördern,
sollte die verwendete Software neuesten Ergonomieerkenntnissen
entsprechen (z.B. einfache Bedieneroberfläche)25
• Leichtes Auffinden von Informationen durch überschaubare Strukturierung des
Informationsraumes, umfangreiche, leicht zu bedienende Suchmechanismen
und Hilfsmitteln zur Informationsfilterung
• schnelle und variable Datenbereitstellung26
• Einrichtung eines Benutzerservices (Hotline)27
25 [Ri98], S.1226 [Nä97], S.9027 [Ri98], S.13
Bauspezifische Problemfelder 21
4 Elemente einer projektübergreifenden IuK-
Plattform
4.1 Internettechnologien als Grundlage für einen offenen
Informationsaustausch
Aus einem ehemals militärischen Projekt28 hat sich in einem Zeitraum von fast drei
Jahrzehnten das Internet entwickelt, wie wir es heute kennen. Seine Infrastruktur,
basierend auf dem Standardprotokoll TCP/IP, ist Grundlage für weltweite
Kommunikation und Datenaustausch.
4.1.1 Offene Standards
Der ursprüngliche Zweck des Internets war die Verknüpfung unterschiedlicher
Computertypen und Dateiformate zu einem schnellen, flexiblen und stabilen
Netzwerk. Dies wurde durch Datenaustauschprotokolle erreicht, die extrem
unterschiedlichen Computern mit unterschiedlichen Betriebssystemen eine
„gemeinsame Sprache“ gaben, mit der sich diese verständigen konnten.29 Vor
allem dieser Umstand ebnete dem Internet den Weg zu seinem dramatischen
Erfolg.
Das Internet hat über seinen Publikumserfolg hinaus weitere wichtige Einflüsse
auf die Entwicklungen in der Informationstechnik geliefert. Waren bislang alle
Hersteller bemüht, eigene, sogenannte proprietäre Standards zu entwickeln und
28 In den 60er Jahren wurde vom US-Verteidigungsministerium ein verbindungsloses Datennetz
aufgebaut, das gegen Ausfall auch bei nationalen Katastrophen immun sein sollte. Dasentsprechende ARPA-Netz verband unter anderem auch Universitäten und diente alsTesteinrichtung für Forschung auf dem Gebiet der Rechnernetze. Dieses Netz wuchs mit der Zeitzu einem weltweiten Rechner-Netz, welches heute als „Internet“ bekannt ist.
29 [Gr97], S.55
Bauspezifische Problemfelder 22
durchzusetzen, sahen sie sich nun einem unabhängigen und frei zugänglichen
Werkzeug gegenüber30 (sog. „Offene Standards“).
4.1.2 Protokolle
Der oben erwähnte TCP/IP-Protokollstapel ist ein fundamentaler Bestandteil der
Funktion des Internets. Er besteht aus einer Gruppe von Protokollen (quasi einem
Stapel, siehe Abbildung 6), die die Basis der gesamten Internet-Kommunikation
bilden. TCP/IP31 und FTP32 sind die bekanntesten Protokolle, der Stack (Stapel)
umfaßt aber noch andere wichtige Protokolle:
• Internet Protocol (IP) ist ein verbindungsloses Protokoll, das Nachrichten in
Datenpakete aufbricht und diesen numerische Adressen zuordnet. Es liefert
Nachrichten zwischen Systemen aus, garantiert aber weder Zustellung noch
Erhalt.
• Transmission Control Protocol (TCP) ist ein verbindungsorientiertes Protokoll,
das die Datenpakete in sichere Umschläge einbindet und die Zustellung
zusichert.
• User Datagram Protocol (UDP) ist die Basis für entfernte Dateisysteme
(Remote File Systems) und Management-Protokolle.
• Remote Call Procedures (RCP) ermöglichen einer Anwendung, Routinen auf
entfernten Computern aufzurufen und auszuführen.
• Network File System (NFS) ermöglicht den Zugriff auf entfernte Dateien und
Festplatten vom Computer eines Benutzers.
• Simple Network Management Protocol (SNMP) verwaltet Netzwerkgeräte und
Diagnoseprogramme.
• File Transfer Protocol (FTP) ermöglicht bidirektionale Übertragung von Binär-
und ASCII33-Dateien zwischen lokalen und entfernten Computern.
30 [FPU97], S.2531 TCP/IP regelt die Adressierung und den Versand von Nachrichten über Netzwerke.32 FTP ermöglicht das Kopieren größerer Dateien aus Archiven.33 ASCII = American Standard Code for Information Interchange
Bauspezifische Problemfelder 23
IP - Internet Protocol
TransmissionControlProtocol
UDP
TelnetFTP
NFS
Abbildung 6: Der TCP/IP-Protokollstapel34
Zusätzlich zu diesen Internet-Protokollen sind zwei weitere Standards wichtig:
• Uniform Ressource Locator (URL) – ein normiertes Adressierungssystem
• HyperText Markup Language (HTML) – eine auf HTTP (HyperText Transfer
Protocol) basierende Sprache zur Anzeige von Text und multimedialen
Informationen (Grafiken, Audio, Video).
Sie ermöglichen die Übertragung und Anzeige von Informationen auf andere Art
als in Form von reinem Text und haben die Benutzerfreundlichkeit der Internet-
Technologie wesentlich erhöht.35
Zusammen bilden diese offenen Standards und Protokolle die Grundlage für
Internet-Technologien. Jedes Produkt, das für die Nutzung dieser Protokolle
konzipiert ist, kann mit anderen Produkten Daten austauschen, die nach
denselben Standards entwickelt wurden.
4.1.3 Intranet
Ein Werkzeug, das in einem weltweiten und vollkommen anarchistisch
organisierten Rechnerverbund funktionsfähig ist, sollte auch im Rahmen eines
organisationssinternen Netzwerkes Anwendung finden können. Ein solches
34 [Gr97], S.48
Bauspezifische Problemfelder 24
abgegrenztes, nach außen abgeschirmtes Netzwerk nennt man heute „Intranet“.
Es nutzt – im Gegensatz zu traditionellen Netzwerken – Internet-Standards und -
Protokolle (sog. offene Standards) zur Förderung effizienter Kommunikation.36
Abhängig von seinem Design kann ein Intranet eine leistungsfähige „Insel“ sein,
oder es kann mit Verbindungen zu anderen Netzwerken und zum „Internet“
ausgerüstet werden.
Ein Intranet ermöglicht die volle Integration über das gesamte Netzwerk einer
Organisation durch den Einsatz folgender Kompenenten:
• auf Internet-Technologien basierende Browser
• auf Internet-Technologien basierende Kommunikationsprotokolle
• auf Internet-Technologien basierende Server-Software
• auf Internet-Technologien basierende Entwicklungstools
Für die IuK-Unterstützung bietet es fünf Kernfunktionen:37
• E-Mail: Kommunikation von Person-zu-Person oder Person-zu-Gruppe.
• Gemeinsame Nutzung von Dateien: Gemeinsame Nutzung von Wissen,
Informationen und Ideen.
• Verzeichnisse: Wer darf auf welche Informationen zugreifen?
• Suchfunktionen: Kurzfristiges Suchen und Finden von relevanten
Informationen
• Netzwerkverwaltung: Wartung und Intranet-Modifikationen
Diese Funktionen sind, bedingt durch die Nutzung von auf Internet-Technologien
basierenden offenen Standards, über die verschiedensten Hardware- und
Software-Plattformen verfügbar.
Der gleichzeitige Zugriff verschiedener Nutzer auf gemeinsame Informationen und
Dokumente war von Anfang an das Ziel des WWW-Projektes. Jedes Intranet
35 [Gr97], S.47+4836 ebenda, S.2
Bauspezifische Problemfelder 25
besitzt mit der Unterstützung des Hypertext Transfer Protocols (HTTP) alle
Funktionalitäten zur Bereitstellung und zum verteilten Zugriff auf gemeinsame
Informationen und ist somit ein gemeinsamer Informationsraum.38
4.1.4 Groupware
Über die reine Informationsbereitstellung hinaus hin zu einer „expliziten
Unterstützung der Zusammenarbeit von mehreren Personen“39 ist Groupware
dazu konzipiert, zu berücksichtigen, daß mehr als ein Anwender mit einem
Problem beschäftigt ist.
Ziel der zusätzlichen Funktionalitäten ist in der Regel eine bessere Unterstützung
von Koordination und Zusammenarbeit innerhalb von Arbeitsgruppen und nicht
mehr lediglich der Informationsaustausch. Desweiteren hat Groupware zum Ziel,
bestehende Informationskanäle zu intensivieren bzw. neue Verbindungen zu
schaffen.40
Damit ist Groupware ein Teilbereich der sog. CSCW41-Forschung, die sich
allgemein mit der Verbesserung der Gruppenarbeit durch Computerunterstützung
befaßt.
„Ziel aller Bemühungen im Gebiet CSCW ist es, unter Verwendung aller zur
Verfügung stehenden Mittel der IuK-Technologie, Gruppenprozesse zu
unterstützen und dabei die Effektivität und Effizienz der Gruppenarbeit zu
erhöhen.“42
37 [Gr97], S.538 http://www.cck.uni-kl.de/~stamm/publikation/imIntranetCSCW/ IntranetGroupware.6.html am
24.04.9939 [KoKu95], S.17: Definition40 [Schm96], S.2341 CSCW = Computer Supported Cooperative Work
Bauspezifische Problemfelder 26
Als notwendige Merkmale von Groupware können dabei drei Komponenten
gelten43:
1. ein expliziter Gruppenbezug
2. elektronische Kommunikationsmöglichkeiten
3. Informationsmanagement-Funktionen.
Die rasante Entwicklung der Web-Technologie in Internet und Intranet hat viele
traditionelle Groupware-Anbieter dazu bewogen, ihre Produkte "Web-enabled"
umzugestalten, so daß die Groupware-Funktionalität zusätzlich auch im Standard-
Webbrowser als Benutzerschnittstelle zur Verfügung steht. Durch diese
Entwicklung wird der Webbrowser mehr und mehr zur integrierten
Benutzeroberfläche für die computerunterstützte Teamarbeit.
Gleichzeitig werden die Groupware-Anwendungen durch die Nutzung von
Standard-Internetprotokollen offener und die Kommunikation zwischen Produkten
verschiedener Hersteller wird erleichtert. Besonders offensichtlich ist diese
Entwicklung beim Austausch elektronischer Nachrichten: Hier haben sich schon
fast alle Anbieter auf SMTP und POP3 oder IMAP4 geeinigt.
4.1.5 Verteilte Hypertextsysteme
In Hypertextsystemen bestehen Dokumente aus voneinander unabhängigen
Informationseinheiten, die über Verknüpfungen in einen Kontext gesetzt werden.
Es wird – anders als bei herkömmlichen Texten – keine lineare Ordnung
vorgegeben. Bestehende Systeme können ohne großen Aufwand um
Informationseinheiten erweitert werden, die damit einem breiten Nutzerkreis zur
Verfügung stehen. Dadurch findet ein asynchroner, impliziter Informationstransfer
statt. Zwei der bekanntesten Hypertextsysteme sind das auf dem Internet
basierende World Wide Web und Lotus Notes.
Die nichtlineare Eigenschaft von Hypertext ermöglicht verschiedene Sichten auf
einen Datenbestand. Der Nutzer eines Hypertextes kann einen individuellen Weg
42 [TSMB95], S.17
Bauspezifische Problemfelder 27
durch den Informationsraum wählen. Daher werden Hypertextstrukturen „häufig
als besonders geeignete Organisationsformen für gemeinsam bearbeitete
Dokumente beschrieben.”44
4.1.6 Elektronische Post-Systeme
Elektronische Post-Systeme (Electronic-Mail-/E-Mail-Systeme) ermöglichen einen
schnellen, asynchronen Informationsaustausch über räumliche und zeitliche
Distanzen. Der Versender elektronischer Post muß den bzw. die Empfänger
explizit angeben. Seit der Einführung der Multipurpose Internet Mail Extensions
(MIME), einem Standard zur Spezifikation von Dokumenttypen, können über das
Internet nicht mehr nur textuelle Nachrichten, sondern auch andere, beliebige
Informationstypen als Anhang (Attachment) übertragen werden.
Zunächst spricht die Verbreitung von E-Mail für sich. Informationsaustausch durch
elektronische Post kommt unserem üblichen Kommunikationsverhalten gleich. “E-
mail ist von Natur aus asynchron, informell und unstrukturiert, (das heißt
Ausnahmen sind leicht modellierbar.)”45. Der größere Aufwand des Versenders
relativiert sich durch dessen höheren Nutzen.
In Zukunft wird E-Mail verstärkt zur Automatisierung von Gruppentätigkeiten ver-
wendet werden. Durch eine bestimmte Struktur oder Typisierung der Nachricht
kann auf Empfängerseite eine entsprechende Aktion ausgeführt werden. Ansätze
sind hier bereits vorhanden. Zur Aufnahme in eine Verteilerliste muß eine E-Mail,
die an diese Liste gesendet wird, lediglich ein bestimmtes Wort in der Betreffzeile
sowie die aufzunehmende E-Mail-Adresse im Körper enthalten. Diese Entwicklung
fördert die Integration von E-Mail in andere Groupware-Systeme.
43 [SiLa94], S.2744 [Rü93], S. 6445 [BoSchl95], S.34
Bauspezifische Problemfelder 28
4.1.7 Bulletin Board-Systeme
Bulletin Board-Systeme (BBS) sind spezielle „Datenbanken, die Meldungen
verschiedener Autoren nach Themenschwerpunkten speichern und einer Vielzahl
von Lesern zur Verfügung stellen.”46 In diesen Systemen kann ein Benutzer zu
beliebigen Themen Aussagen zur Diskussion stellen. Antworten und Reaktionen
werden dieser Aussage zugeordnet. Es findet eine implizite, asynchrone 1:n-
Kommunikation statt, d.h. der Autor einer Meldung stellt diese grundsätzlich einer
anonymen Leserschaft zur Verfügung. Dies kann einerseits dazu verwendet
werden, um Informationen (z.B. eine Ankündigung) schnell zu verteilen oder um
verteilte asynchrone, offene Diskussionen zu führen. Eines der bekanntesten BBS
bilden die auf dem Internet basierenden Usenet News, und ist ein teilweise
öffentlich zugängliches Diskussionsforum. Andere BBS sind eher für die
Unterstützung der Gruppenarbeit oder anderer Kommunikationsbedürfnisse
innerhalb nicht öffentlicher Gruppen konzipiert. Auf solch einem Bulletin Board-
Konzept baut Lotus Notes auf.47
4.2 Lotus Notes/Domino als Integrationsplattform
Lotus bezeichnet ihr Produkt selbst als ein Informations- und Kommunikations-
system, welches Gruppen in der gemeinsamen Nutzung von Dokumenten
unterstützt.48
Es ist ein System zur Verwaltung und Bereitstellung sowohl wenig strukturierter
als auch strukturierter Informationen in elektronischer Form. Es ist beispielhaft für
die umfassende Integration der verschiedenen Teilgebiete der IuK-Unterstützung
und bietet konkrete Problemlösungsmöglichkeiten für die kooperative Arbeit.49
46 [TSMB], S.15547 ebenda, S.154ff48 ebenda, S.15649 [KoKu95], S.85ff
Bauspezifische Problemfelder 29
KommunikationProzesse undAbläufe
Information Diskussion
LOTUS NOTES
Abbildung 7: Das Lotus Notes – Konzept50
4.2.1 Interner Aufbau
Bei Lotus Notes handelt es sich um ein klassisches Client-Server-Konzept, d.h. es
besteht aus zwei Komponenten: dem Notes (jetzt „Domino“)51 – Server und der
Notes Workstation (Client). Der Notes-Server ist die zentrale Komponente, auf der
die Informationen gespeichert werden. Die Notes Workstation (Client) ist die SW,
die auf dem PC des Anwenders läuft.52
Der interne Aufbau von Notes basiert auf einem Datenbank-System. Ein wichtiges
Element ist die Zugriffskontroll-Liste, die den Zugriff definierter Benutzer und
Benutzergruppen zu einer Notes-Datenbank regelt. Daneben sind auch alle
Formulare mit ihren Ein- und Ausgabemasken sowie die verschiedenen Ansichten,
die für diese Datenbank definiert sind, in der Datenbank selbst gespeichert. „Es
gibt in diesem Sinn also keine Trennung von Daten und Programm mehr.“53
50 [KoKu95], S.8551 Der Begriff „Notes“ ist mittlerweile so bekannt, daß er fast zu einem Synonym für „Groupware“
geworden ist. Deshalb verwende ich im folgenden weiter den Namen „Notes“ auch für denDomino-Server.
52 [KoKu95, S.100ff]
53 ebenda, S.98
Bauspezifische Problemfelder 30
4.2.2 Dokumentenorientierung
Im Gegensatz zu klassischen Datenbankkonzepten weist Notes eine
„dokumentenorientierte Denkweise“ auf. In der klassischen Form sind Dokumente
papier-basiert und weisen eine Reihe spezifischer Eigenheiten auf. Notes versucht
nun, die papierbasierte Form des Dokuments weitestgehend durch eine
elektronische zu ersetzen. So gibt es beispielsweise eine Reihe von Funktionen
für die Erfassung typischer Dokumentenattribute, wie Autorennamen, Erstellungs-
und Veränderungsdatum oder auch der Veränderungshäufigkeit. Die Notes-
Möglichkeiten erstrecken sich bis hin zur Verschlüsselung und elektronischen
Signatur der Dokumente.54
Desweiteren kann Notes mit Hilfe verschiedener Felder wie
• Abschnittsdefinition
• Leserfeld
• Autorenfeld
• Statusfeld
• Ungelesen-Marke
• Wiedervorlage-Kennzeichen
dazu genutzt werden, den Zugriff von Anwendern auf Informationen zu
beschränken und zudem eine gezielte Weiterleitung von Dokumenten zu
erreichen.55
4.2.3 Replikationsfunktionalität
Das Notes-Datenbank-Konzept ist eng an das Konzept der Replikation gekoppelt.
Das bedeutet, daß Arbeitsstationen, die über WAN-Verbindungen mit dem Server
verbunden sind, Kopien der Server-Datenbanken mit denen des lokalen Clients
oder Servers abgleichen („replizieren“) können. Um lange Übertragungszeiten zu
vermeiden, ist es möglich, zunächst einmal die gesamte Datenbank zu übertragen
54 [FPU97], S.25155 [KoKu95], S.109
Bauspezifische Problemfelder 31
und später nur noch veränderte Informationen auszutauschen. Dies ist bis auf
Feldebene möglich.
Dokumente sind dadurch jeweils mehrfach auf den verschiedenen in die
Replikation eingeschlossenen Servern vorhanden.56
Die Aktualisierungszeiträume für die Replizierung hängen davon ab, wie oft der
Datenbestand sich erneuert. Dies ist in erster Linie abhängig von der Komplexität
des Projekts. Sicherheit über den aktuellsten Stand der Daten besteht erst bei der
nächsten turnusmäßigen Replizierung.
Für die Replizierung gibt es folgende Grund-Einstellmöglichkeiten:
• Sollen alle Dokumente oder nur Dokumente, die bestimmten definierten
Bedingungen entsprechen, repliziert werden?
• Dokumente welchen Alters sollen repliziert werden?
• In welchen Zeitabständen und an welchen Tagen soll die Replikation erfolgen?
4.2.4 E-Mail-Funktionalität
Die E-Mail-Funktionalität von Notes basiert – wie sein gesamtes Konzept – auf
einer Datenbank. Das „öffentliche Namen- und Adressbuch“ (NAB) ist im Bereich
Messaging die zentrale Ressource zum Verwalten der Benutzerdaten,
Netzwerkverbindungen und Domäneninformationen.57
Da der Funktionsumfang des elektronischen Postfachs nicht fest in Notes
verdrahtet ist, sondern eben in Form einer Notes-Datenbank realisiert wurde,
ergeben sich im Gegensatz zu herkömmlichen Mail-Systemen viele Vorteile. So
läßt sich die Mail-Datenbank um benutzer- bzw. unternehmensspezifische
Funktionen erweitern und an die entsprechenden Bedürfnisse anpassen.
Die Ungeordnetheit von „normaler“, unstandardisierter E-Mail-Kommunikation
bringt Notes mit Hilfe seiner anpassbaren Masken in eine „strukturierte Form“.
Somit kann auch über E-Mail eine „geordnete“ Korrespondenz erfolgen.
56 [KoKu95], S.10457 [FPU97], S.678
Bauspezifische Problemfelder 32
Weiterhin bietet Notes automatisierte Weiterleitungsmechanismen an.
Infomationsflüsse können dadurch beschleunigt werden.
4.2.5 Workflow-Funktionalität
„Workflow ist – grob betrachtet – nichts anderes, als die Kopplung des
Informationsaustausches mit einer auf Geschäftsprozessen einer (Organisation)
beruhenden Struktur“.58
Notes unterstützt (auf Grundlage der Messaging-Datenbank) zwei grundlegende
Workflow-Modelle:
4.2.5.1 Send oder Push-Modell:
Ein Dokument wird während der Bearbeitung per E-Mail ins elektronische
Postfach des Empfängers verschoben. Dieser bearbeitet das Dokument und leitet
es – ebenfalls in elektronischer Form – an das nachfolgende Glied in der Kette.
Das Send-Modell eignet sich für Anwendungen, die eine eher sporadische oder
aber eine dringliche Bearbeitung von Dokumenten erforderlich machen.
4.2.5.2 Share-Modell:
Hier bleibt ein Dokument während der gesamten Bearbeitungszeit in einer
zentralen Datenbank gespeichert. Der Anwender ist also gezwungen, sich die für
ihn wichtigen Dokumente „selbst zu holen“. Diese Vorgehensweise setzt natürlich
voraus, daß die Anwender die Datenbank regelmäßig nach für sie relevanten
Dokumenten durchsuchen, was bei routinemäßig durchgeführten Aufgaben der
Fall sein wird.
Die beiden Modelle schließen einander keineswegs aus. Vielmehr werden in der
Praxis Lösungen vorherrschen, in denen die Vorteile beider Modelle miteinander
kombiniert werden.59
58 [FPU97], S.69759 ebenda, S.698
Bauspezifische Problemfelder 33
Dadurch können drei grundsätzliche Workflow-Techniken zum Einsatz kommen:
• Weiterleitung von elektronischen Formularen
• Statusverfolgung von Dokumenten
• Benachrichtigung
4.2.6 Sicherheitsaspekte
Notes bietet standardmäßig sieben Stufen der Zugriffsberechtigung, welche sich
vom „Manager“ (vollständiger Zugriff inklusive Änderung der ZKL60) bis zu „Kein
Zugriff“ (Datenbank kann nicht geöffnet werden.) erstreckt. Diese läßt sich im
Rahmen jeder Stufe anhand von weiteren acht Einstellungen benutzerspezifisch
modifizieren. Insgesamt ergeben sich daraus 56 (!) mögliche Differenzierungen
der Zugriffsberechtigung.
Sogenannte „Funktionen“ ermöglichen es darüberhinaus, in Form von „Rollen“
jedem Benutzer bis auf Feldebene definierte Zugriffsrechte zuzuweisen61
Abgesehen vom Sicherheitsaspekt bietet diese Eigenschaft die Möglichkeit,
Anwendungen auf jeden Benutzer maßgerecht zuzuschneiden.
Für eine Projektplattform des Bauwesens, wo eine Vielzahl konkurrierender
Partner auf denselben Datenbestand mit unterschielichsten Dokumenten zugreifen
müssen, bietet diese Rollen-Konzept die nötigen Reglementierungsmöglichkeiten.
60 ZKL = Zugriffskontrolliste61 [FPU97], S.260ff
Bauspezifische Problemfelder 34
Feld
Abschnitt
Dokument
Maske
Ansicht
Datenbank
Server
Abbildung 8: Ebenen der Zugriffsbeschränkung in Notes62
In Notes eingebaute Sicherheitsmechanismen sind:
• Authentifizierung (Zugangsvoraussetzung)
• Autorisierung (Ressourcenzugriffsrechte)
• Vertraulichkeit (Verschlüsselung)
• Datenintegrität (Änderung der Daten während des Sendens)
• Identität (Absender-Identifizierung beim Informationsaustausch)
• Ereignisprotokollierung
4.2.7 Grundlegende Funktionen von Notes
• Informationsspeicherung und –austausch
• eine offene Entwicklungsumgebung als Basis für die Entwicklung eigener
Anwendungen
• Förderung von strukturierter Kommunikation (E-Mail und Diskussionsforen) mit
vordefinierten „Masken“
62 [FPU97], S.264
Bauspezifische Problemfelder 35
• Strukturierung von Informationen durch frei definierbare Formular-Ansichten (in
Notes: „Masken“) als Schnittstellen zu einer Notes-Datenbank
• Aktionen können gezielt und automatisch durchgeführt werden, Abläufe
können automatisiert werden (Definition von Aufgaben in Standard-Datenbank
„Aktivitäten“)
• Ein Überblick über den Status von Aktivitäten ist jederzeit möglich.
• Gezielter Zugriff auch auf unstrukturierte Informationen z.B. durch Volltext-
Recherche in allen Datenbanken (auch Mail- und Diskussionsdatenbank)
• Erlaubt die Integration von Fremdanbieter-„Modulen“ für spezielle Aufgaben
(z.B. verschiedenste Bau-Software, Conferencing Module, etc.)
4.2.8 Plattformunabhängigkeit
Lotus Notes kann über unterschiedlichste Netzwerke korrekt arbeiten. Abbildung 9
verdeutlicht die Flexibilität bezüglich der verwendbaren Netzwerk-Protokolle.
Notes kann gleichermaßen in Netzwerken unter Novell NetWare, Windows NT,
Windows for Workgroups, dem IBM LAN Server und vielen anderen Umgebungen
eingesetzt werden. Es muß sich also nicht zwingend um ein File-Server-
basierendes Netzwerk handeln. Es kann somit auch nur mit einem dedizierten
Notes-Anwendungsserver gearbeitet werden, was allerdings einen deutlichen
Nachteil hat: Es wird zwar ein teurer Datei-Server eingespart, schafft aber damit
auch einen künstlichen Engpaß. Probleme bezüglich der Stabilität und der Server-
Wartung sowie vor allem eine deutliche Verlangsamung der Server-Aktivität sind
die Folge.63
63 [KoKu95], S.100ff
Bauspezifische Problemfelder 36
Notes
NetBIOS
AndereProtokolleSPC
IPXNetBEUITCP / IP
NDIS oder ODI (SPX)
Adapter - Treiber
Hardware
Abbildung 9: Notes – Netzwerkzugriff64
4.2.9 Anpassungsmöglichkeiten
„Lotus Notes ist vielleicht das Produkt, das zur Zeit am häufigsten in Unternehmen
installiert und nicht genutzt wird – weil keiner so richtig weiß, was er damit machen
soll“65 (und kann).
Notes ist kein Produkt mit festem anwendungsspezifischen Funktionsumfang,
sondern eine leistungsfähige Entwicklungsumgebung, die eine ganze Reihe an
Basisfunktionalitäten von Groupware schon bereitstellt. Auf diese Plattform
können maßgeschneiderte Anwendungen aufgesetzt werden. Um Notes wirklich
optimal einsetzen zu können, muß es an die speziellen Gegebenheiten der
Organisation, die es unterstützen soll, angepaßt werden. Das „offene System“
Notes bietet zwar viele Möglichkeiten der Unterstützung, doch werden diese nicht
automatisch durch das Produkt mitgeliefert, sondern verlangen zusätzlich
organisatorische und gestalterische Arbeit.
64 [KoKu95], S.10265 ebanda, S.125
Bauspezifische Problemfelder 37
Neben bereits vorhandenen Standard-Funktionen für Kommunikation,
Aufgabenmanagement, Telefonnotizen, Besprechungen, Diskussionen und
allgemein der Sammlung und Bereitstellung von Informationen, die direkt über
Notes realisierbar sind, gibt es die Möglichkeit, weitere Anwendungen zu
entwickeln.
Folgende Schnittstellen Notes bietet Notes dazu an66:
• Datenbank- und Maskenerstellung in Notes mit Makro
• Notes-API
• Notes VIP
• Notes/FX
Dazu müssen folgende Randbedingungen geschaffen werden67:68
• Analyse der Kommunikationsprozesse
• Analyse des Informationsbedarfs
• Analyse von Arbeitsabläufen
Mit steigenden Ansprüchen entwickelt sich die Notes-Nutzung durch optimale
Anpassung von einer Mail-Plattform über Kommunikations- und Informations-
datenbanken hin zu einer gezielten Prozeßunterstützung.
4.2.10 Masken
Die Notes-Masken sind das wichtigste Element von Notes. Über sie kann eine
Erzeugung und Verwaltung der Projektdatenbank erfolgen. Sie sind der
Grundstein der Dateneingabe und Datenverarbeitung.
Eine Fülle von vordefinierten Masken wird bereits mit Notes mitgeliefert, womit
sich unterschiedlichste Anwendungen ohne aufwendige Anpassung von Notes
durchführen lassen.
66 ebenda, S.11067 ebenda, S.12468 Vgl. Kapitel 5.1: Informationsflußgerechte Datenstrukturierung
Bauspezifische Problemfelder 38
Mit Masken, eine Art elektronisches Formular, können Dokumente erstellt,
bearbeitet und angezeigt werden. Dabei kann jede Maske Felder
unterschiedlichen Typs, OLE-Objekte, JAVA Applets oder auch Programmcode
enthalten. Ein Dokument ist hierbei in keiner Weise an die Maske gebunden,
sondern kann unter Umständen mit verschiedenen Masken angezeigt werden.
Weiterhin können Dokumente bestimmte Inhalte enthalten, die in der Maske nicht
angezeigt werden und umgekehrt.69
4.2.11 Beurteilung
Lotus Notes kann bei Anpassung an bauspezifische Eigenschaften als
Integrationsplattform für verschiedene Systemarchitekturen dienen. So wäre es
beispielsweise möglich, über eine Notes-Schnittstelle die Ist-Kosten eines Projekts
aus einer proprietären Datenbank zu holen und für den Soll-Ist-Vergleich in einer
AVA-Anwendung zur Verfügung zu stellen. Dabei werden Daten aus relationalen
und objektorientierten Datenbanken zusammengeführt. Gleichzeitig wird durch die
Verwendung von Notes auch sichergestellt, daß eine Baustelle, die lediglich eine
Mail-Verbindung zur zuständigen Niederlassung hat, Zugriff auf alle notwendigen
Daten erhalten kann.
Durch den Einsatz von Informationsdatenbanken, in denen interessante
technische Projektdetails, Kompetenzen, Referenzprojekte und Veröffentlichungen
gesammelt und verfügbar gemacht werden, kann der Erfolgsfaktor Wissen
entscheidend gestärkt werden.
Ein wesentlicher Aspekt bei solchen Wissensdatenbanken ist dabei, nicht nur
festzustellen, daß das Know-How vorhanden ist, sondern vor allem, wer das
Know-How hat. Die beteiligten Personen stehen daher im Vordergrund.
Über in Notes integrierbare Zusatzmodule ist es möglich Spezial-Applikationen
projektübergreifend anzuwenden.
69 [FPU97], S.425
Bauspezifische Problemfelder 39
5 Bauspezifische Problemfelder
5.1 Informationsflußgerechte Datenstrukturierung
Daten entstehen aus oder werden benötigt für Tätigkeiten, für die sie Eingangs-
und Ausgangsinformation darstellen.70 Werden Daten in einer Art Datenpool
gesammelt und allen Projektbeteiligten zugänglich gemacht, besteht die Gefahr,
daß die Übersichtlichkeit über den Datenbestand und damit die Grundlage für
einen effizienten Informationsfluß verloren geht.
Um die Projektbeteiligten nicht mit einer Masse von für sie nicht relevanten Daten
zu konfrontieren, ist es notwendig, den sich anhäufenden Datenbestand geeignet
zu strukturieren.
Desweiteren ist eine optimale Strukturierung entscheidend für eine detaillierte und
konsistente Projektdokumentation beispielsweise als Basis für
Nachtragsforderungen oder das Facility Management.
Es muß also zunächst untersucht werden, welche Informationen wann, in
welchem Umfang und in welcher Form wem zur Verfügung stehen müssen
(notwendiger Informationsfluß). Nur so kann vermieden werden, daß allen
Beteiligten immer mehr und immer unübersichtlichere Informationen zur
Verfügung stehen, die es dem Einzelnen erschweren, die für ihn Wichtigen ohne
großen Aufwand zu erkennen.
Durch die Beachtung dieser Informationsflüsse können standartisierte
Informationskanäle automatisch als eine Grundlage für eine Übernahme in ein
Datenkonzept dienen. Damit werden die „potentiellen Kommunikationsrelationen“
[Kr94_S.17ff] der am System beteiligten Prozesse definiert.
Eine Projektion der Informationsflüsse zwischen den Baubeteiligten und ihrer
Wechselwirkungen auf die Datenstruktur des Informationsraums würde die
Effizienz des Informationsflusses erheblich steigern
70 [BDTW89], S.38]
Bauspezifische Problemfelder 40
Die Gesamtheit aller relevanten Informationen kann nach verschiedenen
Gesichtspunkten eingeordnet und verschiedenen Teilaspekten des Projektablaufs
zugeordnet werden.
Eine Einteilung kann erfolgen nach:
• dem Zeitpunkt der Informationserzeugung und –bedarfs (Wann?)
• Tätigkeitsschwerpunkten (Wer tut Was?)
• Informationelle Beziehungen der Projektbeteiligten (Wer hat Kontakt mitWem?)
• Informationsart und -bezugsort (Was wird bewegt von Wo nach Wohin?)
• Projektunabhängige Informationen
• Gesamtbetrachtung
5.1.1 Zeitpunkt
Aus der Sicht des Bauherrn werden bis zur Inbetriebnahme des Bauwerkes vier
Projektphasen durchlaufen, nämlich die Definitionsphase, die Konzeptionsphase,
die Planungsphase und die Realisierungsphase.71 Abbildung 10 zeigt die
Zusammenhänge dieser Phasen mit den neun Phasen der HOAI. In allen Phasen
besteht ein hohes Bedürfnis an Kommunikation und Informationsaustausch.
71 [So94], S.21
Bauspezifische Problemfelder 41
Vorbereiten derVergabe
Vorplanung
Entwurf
Genehmigungs-planung
Ausführungs-planung
Grundlagen-ermittlung
Mitwirken bei derVergabe
Objektüber-wachung
Objektbetreuungund Dokumentation
Planungsphase
1
2
3
4
5
6
7
8
9Inbetriebnahme-phase
Nutzungs- undBetriebsphase
Umbau- bzw.Abbruchphase
Übernehmen
Planung
Realisierungs-phase
Ideenphase
Bauen
Programming
Konzeption
Definitionsphase
Gliederung vonLeistungen nach derHonorarabrechnungfür Architekten undIngenieure (HOAI)
Zyklus einesProjektes aus derSicht des Bauherrn /Nutzers
Abbildung 10: Projektzyklus72
72 [So94], S.20
Bauspezifische Problemfelder 42
5.1.2 Tätigkeitsschwerpunkte
Die Beteiligten lassen sich im wesentlichen in vier Gruppen zusammenfassen:
• Auftraggeber = Bauherr in den verschiedensten Formen
• Planer und Berater [So94], S.20
• bauausführende Firmen in den unterschiedlichsten Konstellationen
• Genehmigungsbehörden und Träger öffentlicher Belange73
BAUHERR
PLANERBAUUNTER-
NEHMEN
Bürgerinitiativen, Normenkontrollverfahren, Gutachten
Aufs
icht
srät
e, k
omm
unal
e Pa
rlam
ente
, Rec
hnun
gspr
üfun
g Baurecht, Stadtplanung, Denkmalpflege, Architektur
Wasserw
irtschaft, Um
weltschutz,Ladschaftsplege
Abbildung 11: Projektbeteiligte74
Folgende Tätigkeitsschwerpunkte bestimmen dabei die Arbeit der
Projektplanung:
• Organisation und Management
• Entwerfen und Konzipieren
• Umsetzen und Konstruieren
• Baubetreuung
• Objektverwaltung und -dokumentation
73 ebenda, S.674 [So94], S.6
Bauspezifische Problemfelder 43
5.1.3 Informationelle Beziehungen der Projektbeteiligten
Der Ablauf des Baugenehmigungsverfahrens mit den wesentlichen
informationellen Beziehungen zwischen Bauherrn, Planer (Entwurfsverfasser),
Unternehmer und Bauaufsichtsbehörde ist in Abbildung 12 in Form eines
Aktivitätenmodells dargestellt. An der Planung sind in der Regel mehrere
Leistungsbereiche (Spezialplaner) beteiligt, deren Arbeit fachübergreifend zu
koordinieren ist. Die vertikalen Informationsflüsse in Verantwortung des Bauherrn,
des bzw. der Planer und der Bauaufsichtsbehörden sind dabei berücksichtigt.
Ebenso sind die Beziehungen zu Fachbehörden und Sachverständigen nicht
enthalten.75
Das IuK-System als Träger dieser paralell ablaufenden Prozesse hat die Aufgabe,
die Prozeßkommunikation zu koordinieren und zu synchronisieren.
75 [Kr94], S.17ff
Bauspezifische Problemfelder 44
Bauantrag
Bauvoranfrage
Auftragserstellung
Grundlagen-ermittlung
Vorplanung
Ausführungs-planung
Vorbereitung derVergabe
Baugenehmigung
Genehmigungs-planung
Entwurfsplanung
Bauvorbescheid
Angebot
Mitwirkung beider Vergabe
Baubeginnanzeige
Objektüber-wachung
Rohbauarbeiten
Ausbauarbeiten
Rohbauabnahme
Nutzung
Antrag aufRohbauabnahme
Antrag auf Schlußabnahme
Schlußabnahme
Objektbetreuung
Bauherr Planer Unternehmer Behörden
Abbildung 12: Aktivitätenmodell76
76 [Kr94], S.18
Bauspezifische Problemfelder 45
5.1.4 Informationsart und -bezugsort
Die Planungsergebnisse werden zu einem großen Teil in Form von
Zeichnungen, Berichten und Ausschreibungsunterlagen dokumentiert. Eine
weitgehende Verknüpfung und Durchgängigkeit der verschiedenen
Dokumentationsformen ist eine wichtige Anforderung an ein zu entwickelndes
Datenkonzept.
5.1.4.1 Zeichnungen der Objektplanung
Die Ergebnisse der Objektplanung werden zu einem wesentlichen Teil in Form
von Bauzeichnungen dokumentiert. Das Erstellen, Fortschreiben, Aktualisieren
und Verwalten der Bauzeichnungen erfordert:
• Vorentwurfszeichnungen
• Entwurfszeichnungen
• Bauvorlagezeichnungen
• Ausführungszeichnungen
• Werkzeichnungen
• Detailzeichnungen
• Sonderzeichnungen
• Abrechnungszeichnungen
• Baubestandszeichnungen
• Bauaufnahmezeichnungen
• Benutzungspläne
5.1.4.2 Zeichnungen der Tragwerksplanung
Neben dem Statischen Bericht, der den Nachweis der Stand- und
Gebrauchssicherheit eines Bauwerkes ausweist, werden die Ergebnisse der
Tragwerksplanung in Form von Zeichnungen dokumentiert.
Die Bearbeitung des Statischen Berichtes und der Zeichnungen der
Tragwerksplanung stützt sich weitgehend auf die Zeichnungen der Objektplanung.
Bauspezifische Problemfelder 46
Die Gewährleistung dieser Schnittstelle zwischen Objektplanung und
Tragwerksplanung ist eine wesentliche Voraussetzung für eine durchgängige
Computerunterstützung der Bauplanung.
• Positionspläne
• Schalpläne und Fundamentpläne
• Bewehrungszeichnungen und Verlegepläne
• Fertigteilzeichnungen
• Verlegezeichnungen
Abbildung 13 macht die Informationsstruktur der beteiligten Planer von der
Entwurfsplanung bis zur Ausführungsplanung deutlich. Die Punkte 1-4 beinhalten
die Entwurfsplanung während die Punkte 5-23 die Ausführungsplanung Rohbau
verdeutlichen.
Bauspezifische Problemfelder 47
Prüfstatiker Statiker Architekt Fachingenieur Projektleitung
Arch./Entwurf 01
Belegungsplanung
Fach-Ing. 02
Beratung HaustechnikRohbaurelevante An-gabenArch./Entwurf 03
ReinzeichnungEntwurf
Projektleitung 04
Freigabe Entwurf
Tragwerks-Plan 05
Pos.-PläneStatische Berechnung
Arch./Ausf.-Plan 06
Ausführungsplan 1(Konzept)
Fach-Ing. 07
Entwurf Haustechnik(Reinzeichnung)
Tragwerks-Plan 08
Schalplan (Konzept)Statische Berechnung
Fach-Ing. 09
Schlitz- undDurchbruchsangaben
Architekt 10
Koordination durchArchitekten
Arch./Ausf.-Plan 12
Ausführungsplan 2Rohbau
Projektleitung 13
FreigabeAusführungsplan 2 zurDurchführung Rohbau
Prüfstatiker 11
Prüfung undBerechnung
Tragwerks-Plan 14
FertigstellungSchalplan
Fach-Ing. 15
Leerohrplanung
Tragwerks-Plan 16
ErstellungBewehrungspläne
Architekt 17
Freigabe Schalplan
Fach-Ing. 18
Entwässerungsplanung
Prüfstatiker 19
PrüfungBewehrungspläne
Arch./Ausf.-Plan 20
Ausführungsplan 3Technik und Ausbau
Projektleitung 21
Freigabe
Fach-Ing. 22
AusführungsplanungHaustechnik
Firma 23
BaudurchführungRohbau
Fundamente
Abbildung 13: Technische Koordination der Ausführungsplanung77
77 [RöVo94], S.138
Bauspezifische Problemfelder 48
Diese Elemente können zusammengefaßt werden in eine Objektgliederung, die
folgende Punkte umfaßt:
• Zeichnungsorganisation
• Leistungsverzeichnisse / Konstruktionsgliederung
• Kostenplanung
• Terminplanung / Ablaufplanung
• Einsatzmittelplanung
Abbildung 14 soll veranschaulichen, wie die einzelnen Bereiche miteinander
verknüpft sind.
KONSTRUKTIONS-GLIEDERUNG
ZEICHNUNGS-ORGANISATION
OBJEKT-GLIEDERUNG
MASSEN-BERECHNUNGEN
AUSSCHREIBUNGEN
AUSFÜHRUNGS-KOSTEN
AUFMASS /RECHNUNGEN
DOKUMENTATIONAUSWERTUNG
ABLAUFPLANUNG TERMINPLANUNG+ EINSATZMITTEL
KOSTEN-PLANUNG
Abbildung 14: Die Objektgliederung als Zentralproblem der Datenorganisation78
78 [RöVo94], S.38
Bauspezifische Problemfelder 49
5.1.5 Projektunabhängige Informationen
Im Planungsprozeß werden projektunabhängige und projektabhängige
Informationen verwendet bzw. erzeugt. Bei einer durchgängig computergestützten
Planung ist anzustreben, daß die projektunabhängigen Informationen als
Wissensbasis und die projektabhängigen Informationen in Form von
Produktmodellen möglichst weitgehend und durchgängig vom IuK-System
verwaltet werden.
Zur Wissensbasis sind zu zählen:
• Planungsunterlagen in Form baurechtlicher Vorschriften, Richtlinien und
Normen
• Marktinformationen über Baustoffe, Bauelemente, Bauteile, technologische
Verfahren usw.
• Erfahrungswissen in Form von persönlichen oder firmeneigenen Erfahrungen
oder Erkenntnissen aus Fachaufsätzen und anderen Veröffentlichungen
5.1.6 Gesamtbetrachtung
Das Produktmodell ist ein komplexes Datenobjekt, welches als logische Einheit
alle objektrelevanten Daten umfaßt. Es wird mit Beginn des Planungsauftrages
eröffnet und sollte über den gesamten Lebenszyklus des baulichen Objektes
existieren und dabei ständig aktualisiert werden. Es ist zugleich Grundlage für
einen durchgängigen Informationsfluß und für die fachübergreifende
Zusammenarbeit im Planungsprozeß.
Im Verlauf des Planungsprozesses repräsentiert das Produktmodell den jeweils
aktuellen Entwicklungsstand des zu planenden Objektes. Dies schließt auch die
Verwaltung der Planungsprotokolle, Planungsversionen und Planungsvarianten
mit ein.79
79 [Kr94], S.27
Bauspezifische Problemfelder 50
Nur durch eine gesamtheitliche Betrachtung der Informationsflüsse und Beachtung
ihrer verschiedenen Teilaspekte und Wechselwirkungen kann nachfolgend eine
optimale Datenstruktur entwickelt werden.
Diese Datenstruktur bildet die Grundlage für Konventionen, die
• einer standartisierten Dokumentenablage,
• einem optimierten Zugriff sowie
• einer effektiven späteren Nutzung des Datenbestandes
zugute kommen, falls ihre Einhaltung durch alle Projektbeteiligten gewährleistet
werden kann.
Die logische Positionierung der Einzelinformationen in die innere Ordnung der
Datenorganisation kann über Schlüsselnummersysteme erfolgen.
5.1.6.1 Planmanagement
Die Planverwaltung kann z.B. über zweidimensionale Barcodes (Typ PDF 417)
erfolgen, mit deren Hilfe die wesentlichen Informationen eines Plankopfes in
verschlüsselter Form zusätzlich auf dem Plan aufgebracht werden können. Bei
einem internationalen Bauprojekt (Bau des Flughafens Athen) wird der 2D-
Barcode schon erfolgreich eingesetzt. In Deutschland sind zur Zeit die ersten
Pilotprojekte in Vorbereitung.
Abbildung 15: Zweidimensionaler Barcode80
80 http://www.winplan.de/barcode.htm am 19.04.99
Bauspezifische Problemfelder 51
5.2 Schnittstellenproblematik
Bisher wird der genormte Datenaustausch zwischen unterschiedlichen EDV-
Systemen in der Regel über Dateien mit systemneutralen Austauschformaten
realisiert. Vor der Übertragung ist dabei das implizite Format des jeweiligen
Anwendungsprogramms in das normierte explizite Dateiformat zu übersetzen,
anschließend wird die Datei übertragen und in das Zielsystem eingelesen. Durch
das Festlegen der einheitlichen Formatierung und Interpretation der übertragenen
Informationen gewährleistet man, daß das empfangende System die Daten
ordnungsgemäß interpretieren und in sein eigenes implizites Format übersetzen
kann. Die Datenhaltung der beteiligten Unternehmen kann somit unabhängig
voneinander erfolgen - lediglich die ausgetauschten Daten müssen standardisiert
sein. Dieser Aspekt ist angesichts der häufigen Partnerwechsel gerade für die
Bauwirtschaft sehr interessant.
Abbildung 16: Schnittstellenproblem81
81 http://www.siline.com/350_fm/350_fm-edv.html am 28.02.99
Bauspezifische Problemfelder 52
Anwendungssysteme erstellen und verarbeiten Daten in systemspezifischen
internen Datenformaten, die speziell auf ihre Funktionalität zugeschnitten sind
(abhängig von der verwendeten Rechner-Architektur sowie der jeweiligen
Software-Release). Die Daten liegen dabei in einer binären Form vor, so daß der
Rechner sie ohne weitere Umwandlungen direkt verarbeiten kann. Die
Anwendungssysteme verfügen in der Regel neben dem internen Format auch
über ein sogenanntes externes Format, in dem die Daten als Klartext (meist in
ASCII-Form) dargestellt sind. Vor dem Datenaustausch wird dann das interne in
das Klartextformat übertragen. Die einzelnen Datenwerte stehen dabei in der
Austauschdatei.82
Abbildung 17 zeigt schematisch den Ablauf eines derartigen automatisierten
Datentransfers am Beispiel einer DXF-Datenkonvertierung.
DXFAustauschdatei
DXFAustauschdatei
InternesFromat
InternesFromat
Konvertierungs-programm- intern -
Konvertierungs-programm- intern -
InternesFormat
InternesFormat DXF
Austauschdatei
DXFAustauschdatei
Konvertierungs-programm- intern -
Konvertierungs-programm- intern -
CAD - System A
CAD - System B
Abbildung 17: DXF-Datenkonvertierung
82 [Ha93], S. 48ff
Bauspezifische Problemfelder 53
Die folgenden Kapitel beschreiben Beispiele für derartige Schnittstellen-Formate
zum Austausch von Daten zwischen unterschiedlichen Systemen und stellen
einige ausgewählte Standardisierungsinitativen vor.
5.2.1 Arten von Industriestandards:
5.2.1.1 De Facto-Standards
De Facto-Standards sind weitläufig eingesetzte, auf den tatsächlichen
Gegebenheiten basierende Industriestandards, die nicht unbedingt offiziell
anerkannt sind, aber trotzdem allgemein verwendet werden.83 (z.B. eine, durch
einen hohen Marktanteil weitverbreitete, „Standard“-Software). Sie stellen
eigentlich eine proprietäre Technologie dar, die von einem Unternehmen
entwickelt und gehalten sowie von anderen Unternehmen kopiert bzw. gegen
Gebühr imitiert wird.
5.2.1.2 De Jure-Standards
De Jure-Standards sind formale Standards, die von offiziellen, akademischen
Stellen und Behörden für die Aufstellung von Standards wie z.B. der ISO84
festgelegt werden.85 Im Gegensatz zu einem De Facto-Standard ist die von einer
Normungs-gemeinschaft offiziell festgelegte Norm nicht an das Leistungsspektrum
eines Systemanbieters angepaßt. Dadurch verringert sich das Risiko, daß bei
einem neuen Release des systemneutralen Austauschformates die
Übersetzungsvorgänge nicht mehr funktionieren. Dagegen sind die Schnittstellen
für den Defacto-Standard eines Herstellers bei jedem Versionswechsel an das
jeweils neueste Release anzupassen, was einem zuverlässigen Datenaustausch
natürlich nicht zuträglich ist.
83 [Gr97], S.5784 ISO = International Standards Organisation85 [Gr97], S.57
Bauspezifische Problemfelder 54
5.2.2 DXF
DXF86 hat sich beim CAD-Datenaustausch im Bauwesen zum Quasi-Standard
entwickelt. Diese von Autodesk (Hersteller von AutoCAD, dem "De Facto-
Standard" bei CAD-Software) entwickelte SW-Schnittstelle soll der Garant sein für
den problemlosen Austausch von Zeichnungsdaten. Trotzdem gibt es bei jedem
Transfer aufs neue Probleme, die oftmals zum Verzicht auf den Datenaustausch
führen87. Die Datenübertragung bricht oft mit einer Fehlermeldung ab oder das
Aussehen der Daten im Zielprogramm (Maßstab, Strichstärken, Farben,
Schraffuren, Layer, etc.) weicht stark vom Quellprogramm ab.
Trotz der weiten Verbreitung stellt die DXF-Schnittstelle eines der meistgenannten
Probleme beim Austausch von Zeichnungsdaten. Für einen effektiven DXF-
Datenaustausch sollte deshalb auf folgende Punkte geachtet werden88:
5.2.2.1 Kommunikation
Zwischen Architekt, Tragwerksplaner und Haustechniker genau absprechen, was
ausgetauscht werden soll. Oftmals kann man auf Schraffuren, Planränder,
Schriftfelder, manchmal auf Texte und Bemaßungen verzichten und dadurch die
Dateigröße und die Fehlerwahrscheinlichkeit reduzieren. Kommunizieren sollten
übrigens die, die sich mit CAD auskennen, und das sind nicht unbedingt immer die
Projektleiter!
5.2.2.2 Information
Den Partner über die Randbedingungen informieren, nämlich über verwendetes
CAD-System, Betriebssystem, Layerbelegung, Einheit, Maß Stiftzuweisung,
Verwendung von Blöcken, Linientypen, Textstilen. Am besten das Formblatt89 des
86 DXF = Drawing Interchange Format = Dateiformat zur Speicherung von Vektorgrafiken, Vgl.:
Programm-Hilfe zu Autocad Release 14.087 Vgl: Dipl.-Ing. Helmut Mersch: http://www.darmstadt-online.de/mersch/dxf.htm am 28.02.9988 ebenda89 siehe Anhang 7.1: Formblatt DXF-Datenaustausch:
Bauspezifische Problemfelder 55
Deutschen Beton-Vereins verwenden. Anwender in der Benutzung der DXFIN-
und DXFOUT-Schnittstellen schulen. In einer Firma einheitliche Zeichnungen
liefern.
5.2.2.3 Probeweiser Austausch
Den Datenaustausch schon im Vorfeld proben, solange das Projekt noch nicht
zeitkritisch ist. Dazu Pläne eines anderen Projektes oder spezielle Test-Pläne mit
allen CAD-Objekten austauschen. Beim Empfang auf die Qualität der Zeichnung
hinsichtlich Layer, Blöcke, Bemaßungen, Texte (Umlaute, Sonderzeichen!),
Linientypen und Strichstärken sowie die verwendete Zeichnungseinheit (für die
Richtigkeit eigener Bemaßungen) achten.
5.2.2.4 Probleme analysieren
Bei Abbruch eines DXF-Einlesevorgangs nicht gleich aufgeben. Maßstab für die
Richtigkeit einer DXF-Datei ist, wenn sie in AutoCAD eingelesen werden kann.
Prototypzeichnung in AutoCAD ausschalten. Evtl. Fehlermeldungen beachten und
Ursache analysieren. DXF-Datei, falls vorhanden, in DXF-Viewer oder anderes
CAD-System einlesen. Dienstleister einschalten.
5.2.2.5 Nicht nur auf die Technik verlassen
Eine DXF-Datei ersetzt (noch) keinen Papierplot. Diesen braucht man (evtl.
verkleinert) unbedingt noch zur Kontrolle der Richtigkeit des
Austauschergebnisses. Überprüfen, ob die CAD-Zeichnung maßgenau ist oder ob
Maße manuell per Textkorrektur verändert worden sind.
Als aktive Hilfe bei der Planung des Datenaustauschs im Vorfeld eine Projektes hat der Deutsche
Beton-Verein e.V. in seinem Arbeitskreis „Datenverarbeitung im Konstruktiven Ingenieurbau“ ein
Formblatt erarbeitet, das wesentliche Fragen zur projektbezogenen Planung des DXF-
Datenaustauschs enthält. Der Fragebogen - ausgefüllt von jedem Projektbeteiligten möglichst vor
dem ersten Datentransfer - dient als Diskussionsgrundlage, zur Festlegung von projektspezifischen
Standards und kann sogar als Anlage zum Architekten- oder Ingenieurvertrag verwendet werden.
Deutscher Beton-Verein e.V.: „DXF-Datenaustausch: Projektbezogene Vereinbarungen“.Wiesbaden 1996
Bauspezifische Problemfelder 56
5.2.3 CAE-Bauwerksmodell
Das CAE-Bauwerksmodell ist ein digitales Datenmodell, in dem die Summe aller
während der Planung, der Errichtung, des Nutzung und des Rückbaus eines
Bauwerks erforderlichen Informationen und Daten enthalten sind90. Konkret auf die
Erstellung von Planungsunterlagen bezogen bedeutet es, daß man auf die
relevanten Objekte (Wände, Stützen, Decken, Treppen) mit assoziierten Objekten
(Aussparungen, Konsolen) und Attributen (Materialien, Oberflächen) in einer
Projektdatenbank zugreifen und ihre zweidimensionale Ableitung im Plan
generieren kann91. Es werden somit nicht mehr Anordnungen von Linien als
Zeichnungsinhalt übertragen, sondern konkrete Objekte. Man könnte sagen, daß
System „weiß, daß eine Wand eine Wand ist“.
5.2.4 STEP
Der offizielle Name dieser von der internationalen Normungsorganisation ISO
entwickelten Normenreihe ISO 10303 lautet: „Industrial automation systems and
Integration - Product data representation and exchange“. Es hat sich jedoch die
Bezeichnung STEP als Abkürzung für „STandard for the Exchange of Product
model data“ eingebürgert.
Ein wesentliches Ziel von STEP ist es, die Vielfalt der im Konstruktionsbereich
genutzten Produktdaten-/Engineering-Standards zu reduzieren. Durch die
Definition eines den gesamten Lebenszyklus umfassenden Produktmodells soll
STEP neue Perspektiven für die integrierte Planung bieten.
STEP hat gegenüber dem DXF-Format einige sehr überzeugende Vorteile. So
verfügt AutoCAD beispielsweise über die marktgängigen Techniken der
assoziativen Bemaßung und der Definition von Maßketten, läßt jedoch im DXF-
Format - im Gegensatz zu STEP - nicht den Austausch dieser
Strukturierungsoptionen zu.
90 Beucke, K: „Schlußbericht zum Forschungsvorhaben DBV 188 ‘CAE Bauwerksmodelle’“.
Deutscher Beton Verein e.V., Wiesbaden 199691 Vgl: Dipl.-Ing. Helmut Mersch: http://www.darmstadt-online.de/mersch/dxf.htm
Bauspezifische Problemfelder 57
Weitere Defizite des DXF-Formates sind die Auffassung von Schraffuren als
Vielzahl von Linien (dadurch wird nicht nur die Austauschdatei stark aufgebläht,
auch die Assoziation zur schraffierenden Fläche geht verloren), die Übertragung
von Symbolen als Blöcke (somit lassen sich Gruppen nicht mehr von Symbolen
unterscheiden, so daß die Möglichkeit, auf gemeinsame Symbolbibliotheken
zurückzugreifen, versperrt ist) oder die nicht festgelegte Interpretation von
Sachdaten, die mit geometrischen oder grafischen Daten verknüpft werden.92
5.2.5 GAEB
Der Gemeinsame Ausschuß Elektronik im Bauwesen (GAEB)93 hat es sich zur
Aufgabe gemacht, die Rationalisierung im Bauwesen mittels Datenverarbeitung zu
fördern, und zwar durch Klassifizierung und Strukturierung der zwischen den
Informationspartnern im Verlauf der Planung und Baudurchführung zu
erstellenden und auszutauschenden Daten.
Das Ziel ist, „die gemeinsame Sprache aller am Bau Beteiligten“ zu
standardisieren. Dies erfolgt durch Aufstellung von Regeln für die automatisierte
Vergabe und Abrechnung von Bauleistungen (AVA). Hierzu gehören unter
anderem:
• standardisierte Textspeicher
• Regelungen für den Aufbau von Leistungsverzeichnissen
• Regelungen für den Datenaustausch
• Regelungen für Bauabrechnungen
Im GAEB sind die öffentlichen und privaten Auftraggeber, die Architekten, die
Ingenieure, die Bauwirtschaft und die Bausoftwarehäuser durch ihre jeweiligen
Spitzenorganisationen vertreten und stellen die Regelungen für alle am Bau
Beteiligten gemeinsam und einvernehmlich auf.
Zusammen mit dem Deutschen Verdingungsausschuß für Bauleistungen (DVA)
und dem Deutschen Institut für Normung (DIN) werden im Standardleistungsbuch
92 [Ha93], S.42ff93 GAEB - Info-Material
Bauspezifische Problemfelder 58
(STLB) Beschreibungstexte, gegliedert nach Leistungsbereichs-Nummern, in
Übereinkunft mit den einschlägigen Rechtsvorschriften standardisiert.
5.2.5.1 STLB-Bau – Dynamische Baudaten
Die elektronische Umsetzung des Standardleistungsbuches erfolgt in dem
Softwaremodul „STLB Bau – Dynamische Baudaten“ (aufgestellt von GAEB,
herausgegeben vom DIN). Es ermöglicht die Eingabe, Auswertung und Übergabe
von Bauleistungstexten entsprechend den Aufteilungen des STLB an andere
Anwendungsprogramme (z.B. AVA, Kostenplanung, etc.) über eine DLL-
Schnittstelle.
Abbildung 18: GAEB: AVA-Schnittstelle
Dadurch können wechselseitig zu bearbeitende Daten an Partner
maschinenlesbar weitergegeben werden. Durch Schlüsselnummern wird die
Eindeutigkeit, Unveränderbarkeit, Automaten-Interpretierbarkeit und beliebige
Auswertbarkeit durch andere Fachanwendungen gewährleistet.
Bauspezifische Problemfelder 59
5.2.5.2 GAEB 2000
Die Ergebnisse aus der praktischen Anwendung der vom GAEB bisher
herausgegebenen "Regelungen für den Aufbau des Leistungsverzeichnisses"
(Ausgabe August 1991) und "Regelungen für den Datenaustausch Leistungs-
verzeichnis" (mit Erläuterungen als 2., geänderte Auflage, Ausgabe Juni 1990),
sowie Beiträge und Anregungen der Anwender wurden in einer neuen Ausgabe
mit dem Titel „GAEB DA 2000“ zusammengefaßt.
Diese Regelungen sollen als Vorgabe bei der Schaffung neuer Programmsysteme
und bei der Anpassung bereits vorhandener Programmsysteme im Zuge einer
Fortschreibung dienen.
Im Datenaustausch GAEB DA 2000 ist nicht nur der Austausch von Daten des
Leistungsverzeichnisses zwischen Auftraggeber und Bieter/Auftragnehmer
geregelt, sondern auch der Austausch von:
• Katalogen,
• Bestellungen,
• Rechnungen,
• Vorgängen der Terminplanung,
• Kostenelementen zur Kostenschätzung und
• Raum- und Bauteilinformationen.
Darüber hinaus ist der Austausch solcher Informationen mit Herstellern und
Handel möglich.
Wollen Tauschpartner zusätzliche Informationen in der vorgegebenen Syntax
austauschen, so können sie innerhalb einer eigenen Austauschphase neue
Objekte und Elemente vereinbaren, die mit dem dafür reservierten Zeichen ( _ )
beginnen müssen. Alle anderen Namen sind für die Fortschreibung im GAEB-
Datenaustausch 2000 reserviert.
Jede Austauschphase wird in einer eigenen Datei übertragen. Sollen zum Beispiel
ein Kostengruppenkatalog, ein Lokalitätenkatalog und zwei Bieteranfragen
(Leistungsverzeichnisse) zum Bieter übertragen werden, dann müssen diese
Informationen in zwei Katalogdateien und zwei LV-Dateien abgelegt werden.
Bauspezifische Problemfelder 60
Die in einer Austauschphase enthaltenen Objekte werden durch die zu einem
bestimmten Zeitpunkt notwendigen fachlichen Anforderungen bestimmt. Der
zeitlich unabhängige Informationsaustausch kann weitergehende Inhalte, z.B. für
die Dokumentation, enthalten.
In Abbildung 19 sind die Datenaustauschphasen entsprechend der
Gruppenunterteilung in den Kapiteln des GAEB DA 2000 dargestellt.
Abbildung 19:GAEB: Austauschphasen
Bauspezifische Problemfelder 61
5.2.6 REB
Die Regelungen für die Elektronische Bauabrechnung (REB)94 sind ein Standard
für die Übergabe von Aufmaß- und Abrechnungsdaten und gliedern sich in zwei
Teile:
• REB-Allg.: Allgemeine Bedingungen für die Anwendung der REB-VB
• REB-VB: Verfahrensbeschreibungen für die Mengenberechnung (Massen-
ermittlung) zur Abrechnung von Bauleistungen
Sie geben für die typischen Abrechnungsaufgaben (insbesondere für
Mengenberechnungen) einheitliche und eindeutige Regelungen und geometrische
Lösungen, deren Beachtung sicherstellen soll, daß die für den jeweiligen
Abrechnungsvorgang mit denselben Ausgangsdaten von verschiedenen Stellen
unabhängig voneinander durchgeführte Berechnungen dasselbe Ergebnis (im
Rahmen einer fetsgelegten Toleranz) erbringen.
5.2.7 ISYBAU
Das Projekt „Integriertes Datenverarbeitungssystem Bauwesen“ befaßt sich
intensiv mit der Einführung und Durchdringung der Datenverarbeitung in den
staatlichen Bauverwaltungen. Es ist ein Gemeinschaftsvorhaben der
Bundesbauverwaltung sowie der Finanz- und Staatshochbauverwaltungen der
Länder. Mit dem Ziel der Integration durch Kommunikation soll ein durchgängiger
Datenfluß über alle Phasen des Bauens und Planens geschaffen und die
Datenverarbeitung zwischen den DV-Systemen der Partner ermöglicht werden.
Für die einzelnen Anwendungsgebiete im Bauwesen werden DV-Systeme
ausgewählt und integriert. Die Integration umfaßt sowohl den internen
Nachrichtenaustausch zwischen den Anwendungssystemen als auch den
externen Nachrichtenaustausch zwischen den Kommunikationspartnern in allen
Bauphasen.95
94 REB - Infomaterial95 [ Mü95], S.2
Bauspezifische Problemfelder 62
5.2.8 UN/ EDIFACT
(United Nations/ Electronic Data Interchange For Administration, Commerce and
Transport) ist eine weltweit gültige Norm (ISO 9735, national zuständig ist die DIN)
und internationales, branchenübergreifendes Austauschformat für den Austausch
von Produktdaten. Dabei ist ein EDI-Standard (z.B. VDA) in der Regel
inkompatibel zu Standards, die in anderen Branchen eingesetzt werden.
Im Bauwesen ist dieser Standard für AVA, CAD, Kosten- und Termindaten,
Beschaffungs- und Rechnungswesen und für administrative Daten vorgesehen.
Die Regeln des GAEB-Datenaustausches sind bereits in vollem Umfang
eingearbeitet.96
5.2.9 ICIS
Ziel der International Construction Information Society (ICIS) ist es, auf
internationaler Ebene Bestrebungen und Entwicklungen im Bereich von
Bauspezifikationen, Ausschreibungsverfahren und Kosteninformationen, die zu
einer Harmonisierung und Standardisierung führen, zu unterstützen.97
96 [Kr94], S.26097 ICIS-Informationsblatt
Schluß 63
6 Schluß
6.1 Erkenntnisse
Gewiß ist IuK-Technologie kein Allheilmittel. Ihr Einsatz wird keine schlechten
Planungsleistungen ausbessern. Doch gute Planungsleistungen können nicht
ohne eine intensive Zusammenarbeit und Kommunikation zwischen allen
Projektbeteiligten erreicht werden. Somit ist das eigentliche Thema nicht Internet /
Intranet, sondern Kommunikation.
Zusammenfassend können folgende zentrale Forderungen gestellt werden:
1. Es müssen die richtigen Personen/Funktionen zur richtigen Zeit und am
richtigen Ort über die relevanten Informationen in der benötigten Form
verfügen können, unabhängig von der Tageszeit und von geographischen
Standorten.
2. Die Zusammenarbeit zwischen den Projektbeteiligten, ihr Bedarf zu
kommunizieren, gemeinsam zu koordinieren und Wissen auszutauschen,
bedarf effizienter Unterstützungswerkzeuge.
Hierzu sind ein verlustarmer Datenaustausch, die Möglichkeit zur synchronen wie
asynchronen Kommunikation der Personen und Hilfsmittel zur
Entscheidungsfindung bei räumlicher und zeitlicher Verteilung der Bearbeitung
erforderlich.
Dazu bedarf es einer Technik, die explizit auf verteilte, kooperative Arbeit
zugeschnitten ist und die auch über verschiedenste Rechnerkonstellationen
hinweg funktionierende vernetzte Arbeit ermöglicht. Die Internettechnologie mit
ihren offenen, herstellerunabhängigen Standards bietet diese Möglichkeit.
Auf ihrer Grundlage und über eine effektive IuK-Plattform, wie z.B. Lotus Notes
können diese Forderungen erfüllt werden. Ein effektives Unterstützungswerkzeug
stellen sie jedoch nicht durch die bloße Einführung dar. Erst durch eine optimale
Schluß 64
Anpassung an die speziellen Gegebenheiten und Anforderungen, eine intensive
Einführung und Akzeptanz bei den Benutzern zeigt es seine Wirkung.
6.2 Ausblick auf zukünftige Entwicklungen
Die Entwicklungszyklen in der Technik werden immer kürzer, einen dauerhaften
Zustand gibt es nicht. Techniken wie CAFM, 3D-Modeling und Internet verändern
die Arbeitsweise der Planer und erschließen neue Wege zu einer immer
detaillierteren und ganzheitlicheren Gebäudeplanung. Die digitalen Werkzeuge
und das damit erzeugte Produkt unterliegen einer ständigen Entwicklung, einem
Prozess.
Anhang 65
7 Anhang
7.1 Formblatt: DXF - Datenaustausch
Anhang 66
DXF–Datenaustausch
Projektbezogene Vereinbarungen
1. Projektinformationen
Projekt:
Sender der Daten Empfänger der DatenFirma
ProjektleiterTel. Tel.eMail eMail
Ansprechpartner Tel. Tel.CAD/EDV eMail eMail
2. Sendendes CAD–System
Name: Version:
Unterstützte AutoCAD–Version der DXF–Schnittstelle:
ACAD 12 ACAD 13 ACAD 14
3. Verwendetes Betriebssystem
MS–DOS Windows Windows–NT UNIX
Version:
4. Eigenschaften der ZeichnungenEinheit der Zeichnungen:
m cm mm inch
Hauptmaßstab der Pläne:
1:500 1:250 1:200 1:100 1:50 1:25
Werden Nebenmaßstäbe verwendet ? Ja Nein
Lage des gemeinsamen Koordinatenursprungs
5. Stiftbelegung beim Plotten
Zuordnung Stiftnummer ↔ Farbe ↔ Strichstärke beim PlottenStift-Nr. Farbe Strichstärke
Falls diese Tabelle nicht ausreicht, bitte Liste mit vollständiger Stiftbelegung beifügen.
Anhang 67
6. Verwendung externer Blöcke
Werden externe Blöcke verwendet: JaNein
Wenn ja, Erläuterungen zu Punkt 5 beachten.
7. Verwendung von Layern
Bitte Zuordnungsliste verwendete Layer ↔ Bedeutung der Layer beifügen
8. Verwendung von SchriftartenIm Rahmen des Datenaustauschs sollen nach Möglichkeit nur ISO-Schriftarten verwendetwerden. Wenn möglich, bitte Liste mit Namen der Textfonts und Schriftprobe beifügen.
9. Verwendung von LinientypenSofern möglich, bitte Liste mit Namen der Linientypen und maßstäblichen Ausdruck derTypen beifügen.
10. Medium für den Datenaustausch
ISDN ID Trans ISDN Euro File Modem
Disk 3.5” 1.44 MB ZIP-Medium CD-Rom ISO9660
DAT–Band Video 8–Band eMail
Sonstige:
11. Sicherungsverfahren
COPY BACKUP Wintip
tar cpio wbak/rbak
komprimiert mit: ____________________________________ selbstentpackend
Sonstige:
12. KontrollplotZu jedem DXF–Datenaustausch gehört ein maßstäblicher, max. 50% verkleinerterKontrollplot. Bitte beifügen.
Aufgestellt am: Unterschrift
Anhang 68
DXF–DatenaustauschErläuterungen
Zweck der Vereinbarungen ist es, für konkrete Projekte einen effizientenDatenaustausch zu ermöglichen.
zu 1. ProjektinformationenDas Formblatt wird für jedes Projekt auf der Grundlage des aktuellen Kenntnisstandes vomProjektleiter bzw. vom CAD–Beauftragten ausgefüllt. Grundsätzlich füllt der Sender dasFormblatt aus. Ist ein Datenaustausch in zwei Richtungen vorgesehen, füllen beide Partnerein Formblatt aus. Informationen, die nicht bekannt sind, sind beim Softwarehersteller oder-vertreiber zu erfragen.
zu 2. Sendendes CAD–SystemDie Angabe der unterstützten AutoCAD–Version, die der DXF–Schnittstelle zugrunde liegt,ist wegen des unterschiedlichen Leistungsumfangs beim DXF–Datenaustausch notwendig.
zu 3. Verwendetes BetriebssystemJe nach Betriebssystem können Formatierung der ASCII–DXF–Dateien (Zeilenende-kennungen), die Formatierung der Datenträger und die Programme für Datenträgerzugriffund (De–)Komprimierung der Dateien variieren. Daher ist die Angabe von Betriebssystemund Version erforderlich.
zu 4. Eigenschaften der ZeichnungenBei den Zeichnungseigenschaften ist zwischen Einheit und Maßstab zu unterscheiden.Einheit ist die im CAD–System verwendete Zeichnungseinheit, im Normalfall Meter,Zentimeter oder Millimeter. Die Zeichnungsinhalte in einer DXF–Datei müssenmaßstabsunabhängig vorliegen und dürfen deshalb nicht aus der Zeichnung im Plotformatgeneriert werden.Die Angabe des Maßstabs dient der internen Zuordung zwischen maßstabsabhängigenInformationen (z.B. Konstruktionselemente wie Linie, Polygon) und maßstabsunabhängigen(z.B. Elementeigenschaften wie Texthöhe, Schraffurabstand).Bei der Verwendung von Nebenmaßstäben muß das Verfahren geklärt werden. ÜblicheVerfahren sind:- Zeichnungselemente werden innerhalb einer Zeichnung mit einem Faktor belegt- Blöcke innerhalb einer Zeichnung werden skaliert- maßstabsunabhängige Zeichnungselemente werden mit Hilfe des”Papierbereichsmodus” von AutoCAD/DXF zu einem Plan mitverschiedenen Maßstabsbereichen montiert.Die Verwendung eines einheitlichen Koordinatenursprungs ist sowohl im Hochbau alsauch in der Verkehrswegeplanung empfehlenswert. Im Hochbau sollte man sich auf einenprojektspezifischen Koordinatenursprung einigen, im Verkehrswegebau wird man die Datensinnvollerweise in Gauß–Krüger–Koordinaten austauschen.
zu 5. Stiftbelegung beim PlottenJe nach System erfolgt die Festlegung der Strichstärke beim Plotten über Stiftnummer oderFarbe. Die Spalten 1 und 3 oder 2 und 3 der Tabelle sind entsprechend auszufüllen.
zu 6. Verwendung externer BlöckeDie Verwendung externer Blöcke beim Datenaustausch sowie deren Weitergabe bedarfeiner gründlichen Vorbereitung und Absprache der tauschenden Parteien.Ist eine solche Vorbereitung nicht möglich bzw. bringt die Verwendung externer Blöcke keineVorteile, sollte auf deren Austausch verzichtet werden. Externe Blöcke sind dann vor demDatentransfer zu lösen bzw. an die Zeichnungsdatei zu binden.
Anhang 69
zu 7. Verwendung von LayernLayer (Folien, Ebenen) dienen der Strukturierung einer Zeichnung. Eine sinnvolleLayerdefinition und eine konsequente Verwendung sind gerade beim Datenaustauschunerläßlich. Deshalb sollte diesem Formblatt eine - nach Möglichkeit für das ganze Projektgültige - Layerliste beigefügt werden.
zu 8. Verwendung von SchriftartenBei Verwendung von ISO–Schriften sind die geringsten Abweichungen innerhalb derverschiedenen CAD–Systeme zu erwarten. Wird davon abgewichen, kann es sinnvoll sein,Textfonts im SHP– oder SHX–Format zu übergeben (falls das empfangende System solcheDateien verarbeiten kann). Eine Liste mit Schriftproben erleichtert die Zuordnung der Namendes Textfonts vom sendenden zum empfangenden System.
zu 9. Verwendung von LinientypenFalls ein anderes System als AutoCAD verwendet oder von den AutoCAD-Standard-Linientypen abgewichen wird, muß eine Liste mit einem maßstäblichen Ausdruck derLinientypen beigefügt werden, um die richtige Wiedergabe der Linientypen in der Zeichnungüberprüfen zu können.
zu 10.Medium für den DatenaustauschZur Bestimmung des optimalen Mediums ist eine Absprache mit dem Empfänger der Datenerforderlich. Das vereinbarte Medium ist anzugeben.
zu 11.SicherungsverfahrenFür Archivierung und Komprimierung stehen in der Regel verschiedene Hilfsmittel zur Verfü-gung. Eine Absprache mit dem Empfänger der Daten ist erforderlich. Das vereinbarte Siche-rungsverfahren ist anzukreuzen.
zu 12.KontrollplotEin Kontrollplot der DXF–Datei ist für jeden Plan unbedingt erforderlich, da beim DXF–Datenaustausch Probleme beim Übersetzen, Senden und Empfangen auftreten können.
Anhang 70
7.2 Abbildungsverzeichnis
Abbildung 1: Einheitliche Datenbasen während der Lebensphasen....................... 7
Abbildung 2: Deutsche Bauwirtschaft: Auftragseingang aus dem Ausland ............ 9
Abbildung 3: Deutsche Bauwirtschaft: Bauinvestitionen in der EU 1997 ................ 9
Abbildung 4: Kommunikation – Koordination - Kooperation.................................. 11
Abbildung 5: Die sich gegenseitig beeinflussenden Wettbewerbsfaktoren........... 11
Abbildung 6: Der TCP/IP-Protokollstapel.............................................................. 23
Abbildung 7: Das Lotus Notes – Konzept ............................................................. 29
Abbildung 8: Ebenen der Zugriffsbeschränkung in Notes..................................... 34
Abbildung 9: Notes – Netzwerkzugriff................................................................... 36
Abbildung 10: Projektzyklus.................................................................................. 41
Abbildung 11: Projektbeteiligte ............................................................................. 42
Abbildung 12: Aktivitätenmodell............................................................................ 44
Abbildung 13: Technische Koordination der Ausführungsplanung ....................... 47
Abbildung 14: Die Objektgliederung als Zentralproblem der Datenorganisation... 48
Abbildung 15: Zweidimensionaler Barcode........................................................... 50
Abbildung 16: Schnittstellenproblem .................................................................... 51
Abbildung 17: DXF-Datenkonvertierung ............................................................... 52
Abbildung 18: GAEB: AVA-Schnittstelle ............................................................... 58
Abbildung 19:GAEB: Austauschphasen ............................................................... 60
Anhang 71
7.3 Literaturverzeichnis
[BDTW89] U. Bleimann, D. Dippel, G. Turetschek, K. W. Wente; Betriebsinformatik:
Informationsverarbeitungssysteme in Unternehmen und Verwaltungen;
Hanser-Verlag; München, Wien; 1989
[Be94] A. T. Berking; Ablaufplanung mit Unterstützung durch Expertensysteme;
Dissertation; TU München; 1994
[BoSchl95] U. M. Borghoff, J. H. Schlichter; Rechnergestützte Gruppenarbeit: Eine
Einführung in Verteilte Anwendungen; Springer; Berlin, Heidelberg etc.;
1995
[Bu97] C. Burger; Groupware: Kooperatiosunterstützung für verteilte
Anwendungen; dpunkt-Verlag; Heidelberg; 1997
[DiLa94] M. Dier, S. Lautenbacher; Groupware: Technologien für die lernende
Organisation; Rahmen, Konzepte, Fallstudien; Computerwoche-Verlag;
München; 1994
[Dö97] M. Döge; Intranet: Einsatzmöglichkeiten, Planung, Fallstudien; O’Reilly-
Verlag; Köln; 1997
[FPU97] K. Fochler, P. Perc, J. Ungermann; Lotus Domino 4.5: Internet- und
Intranetlösungen mit dem Lotus Domino-Server; Addison-Wesley-Verlag;
Bonn; 1997
[Gr94] B. Grupp; Standard-Software richtig auswählen und einführen: Mit System
zur kostengünstigen und umfassenden DV-Lösung; TAW-Verlag;
Wuppertal; 1994
Anhang 72
[Gr97] T. Greer; Intranets verstehen: Ein Leitfaden für Entscheidungsträger;
Microsoft Press; Unterschleißheim; 1997
[GuSchu95] S. Guengerich, G. Schussel; Rightsizing: Informationssysteme optimal
anpassen; SAMS-Verlag; Haar bei München; 1995
[Ha93] W. Haas; CAD-Datenaustausch-Knigge: STEP-2DBS für Architekten und
Bauingenieure; Berlin u.a.; 1993
[HBW96] F. Hoffmann, H-C. Brauweiler, R. Wagner; Computergestützte
Informationssysteme: Einführung in die Bürokommunikation und
Datentechnik für Wirtschaftswissenschaftler; Oldenbourg-Verlag;
München, Wien; 1996
[Hei99] L. J. Heinrich; Informationsmanagement: Planung, Überwachung und
Steuerung der Informationsinfrastruktur; Oldenbourg-Verlag; München,
Wien; 1999
[KoKu95] O. G. Koch, M. Kuppinger; Lotus Notes: Grundlagen und Fallbeispiele,
Workgroup Computing in Unternehmen und Markt; Markt&Technik-Verlag;
Haar bei München; 1995
[Kr94] H. Kretschmar u. a.; Computergestützte Bauplanung; Verlag für
Bauwesen; Berlin; 1994
[Kü93] H. Küting; Informatikplanung, Informatikmanagement; Strategien und
Methoden zur Innovation im Unternehmen; VDI Verlag; Düsseldorf; 1993
[MaKl89] L.Martiny, M. Klotz; Strategisches Informationsmanagement: Bedeutung
und organisatorische Umsetzung; Oldenbourg-Verlag; München, Wien,
Oldenbourg; 1989
Anhang 73
[Mü95] T. Müller-Berg; EDI-Knigge: Elektronischer Datenaustausch am Beispiel
der AVA von Bauleistungen; Springer-Verlag; Berlin, Heidelberg, 1998
[Nä98] J. Nävy; Facility Management: Grundlagen, Computerunterstützung,
Einführunsstrategie, Praxisbeispiel; Springer-Verlag; Berlin, Heidelberg;
1998
[Ra97] H-D. Radke; Das Einsteigerseminar: Lotus Notes Release 3&4; bhv-
Verlag; Kaarst; 1997
[Re94] O. Reichert; Computergestützte Netzplantechnik: Ein Leitfaden für
Praktiker in Unternehmen; Vieweg & Sohn Verlagsgesellschaft;
Braunschweig, Wiesbaden; 1998
[Ri98] W. Riggert; Betriebliche Informationskonzepte: Von Hypertext zu
Groupware; Vieweg-Verlag; Braunschweig, Wiesbaden; 1998
[Rö87] W. Rösel; Baumanagement: Grundlagen, Technik, Praxis; Springer-
Verlag; Berlin, Heidelberg; 1987
[RöVo94] W. Rösch, Volkmann; Bau Projekt Management: Terminplanung mit
System für Architekten und Ingenieure; Müller-Verlag; Köln; 1994
[Rü93] T. Rüdebusch; CSCW: Generische Unterstützung von Teamarbeit in
verteilten DV-Systemen; Deutscher Universitäts-Verlag GmbH;
Wiesbaden;1993
[Schi96] A. Schill; Rechnergestützte Gruppenarbeit in verteilten Systemen; Prentice
Hall Verlag; München u.a.;1996
[Schm96] G.Schmidt; Informationsmanagement: Modelle, Methoden, Techniken;
Springer-Verlag; Berlin, Heidelberg; 1996
Anhang 74
[SchrGe93] J. W. Schregenberger, M. Gehri; Baustellen-Computer: Anforderungsprofil;
Forschungsprojekt 087/92 Schlussbericht; Institut für Bauplanung und
Baubetrieb, ETH Zürich; 1993
[Schw88] H. Schwarz; Daten- und Informationsverarbeitung in Planung und
Steuerung von Bauprojekten; Ernst-Verlag; Berlin; 1988
[So94] H. Sommer; Projektmanagement im Hochbau: Eine praxisnahe Einführung
in die Grundlagen; Springer-Verlag; Berlin, Heidelberg etc.; 1994
[Stu90] Holger H. Stutzke, Heiko H. Stutzke; Computereinführung in Klein- und
Mittelbetrieben: Ein Leitfaden für den Aufbau einer effektiven
Bürokommunikation; Hüthig-Verlag; 1990
[TSMB95] S. Teufel, C. Sauter, T. Mühlherr, K. Bauknecht; Computerunterstützung
für die Gruppenarbeit; Addison-Wesley-Verlag; Bonn; 1995
[Wi97] E. Wischnewski; Aktives Projektmanagement für das Bauwesen: Eine
Anleitung zur effektiven Unterstützung, Durchführung und Steuerung von
Bauprojekten; Vieweg-Verlag; Braunschweig, Wiesbaden; 1997
[WiSe95] V. Wirth, G. Seyfferth; Baustellen-Controlling: EDV-gestützte Planung,
Kontrolle und Informationsversorgung von Baustellen unter
Berücksichtigung des Unternehmens-Controlling; Expert-Verlag;
Renningen-Malmsheim; 1995
Anhang 75
Erklärung
Ich versichere an Eides Statt,
1. daß ich die Arbeit selbständig und ohne fremde Hilfe angefertigt habe,
2. daß ich alle Abschnitte, die wörtlich oder annähernd wörtlich aus einer
Veröffentlichung entnommen sind, als solche kenntlich gemacht habe,
3. daß die Arbeit noch nicht veröffentlicht und auch noch keiner anderen
Prüfungsbehörde vorgelegt worden ist.
Ich erkläre mich hiermit einverstanden, daß das Institut für Bauingenieurwesen IV
Tunnelbau und Baubetriebslehre die von mir hiermit vorgelegte Diplomarbeit zur
weiteren Bearbeitung bzw. Veröffentlichung verwenden kann.
München, den 21. Mai 1999
Top Related