CAFM-System der Humboldt-Universität zu Berlin

Transcrição

CAFM-System der
Humboldt-Universität
zu Berlin
Abschlussbericht
Hochschul-Informations-System GmbH
Mai 2002
CAFM-System der
Humboldt-Universität
zu Berlin
Abschlussbericht
Ralf-Dieter Person
Hochschul-Informations-System GmbH
Goseriede 9, 30159 Hannover
Mai 2002
HIS-Hochschul-Informations-System
Abteilung III
Ralf-Dieter Person
Telefon:
(0511) 1220-248
Fax:
(0511) 1220-250
E-mail:
[email protected]
HIS Hochschul-Informations-System GmbH
Goseriede 9, 30159 Hannover – www.his.de
Mai 2002
Inhaltsverzeichnis
5
Inhaltsverzeichnis
1 Projektbeschreibung.................................................................................................................... 7
1.1 Ausgangssituation ................................................................................................................. 7
1.2 Aufgabenstellung und Zielsetzung........................................................................................ 7
1.3 Vorgehensweise.................................................................................................................... 8
1.3.1 Befragungen............................................................................................................... 8
1.3.2 Projektgruppe............................................................................................................. 9
1.3.3 Sonstige Informationen............................................................................................ 10
2 Das CAFM-System der Humboldt-Universität......................................................................... 11
2.1 Merkmale des CAFM-Systems ........................................................................................... 11
2.2 Konzeption........................................................................................................................... 11
2.3 Bedienung............................................................................................................................ 13
2.4 Anwendungsprogrammierung............................................................................................. 14
2.5 Datenbank............................................................................................................................ 15
2.6 Grafische Informationen und CAD-Daten ........................................................................... 16
2.7 Sonstige Informationen........................................................................................................ 16
3 Ergebnisse der Untersuchung .................................................................................................. 17
3.1 Nutzung und Akzeptanz des Systems................................................................................ 17
3.2 Organisation des CAFM-Systemeinsatzes ......................................................................... 18
3.2.1 Zuständigkeiten (allgemein) .................................................................................... 18
3.2.2 Systembetreuung..................................................................................................... 19
3.2.3 Zusammenarbeit und Informationsaustausch......................................................... 23
3.2.4 Schulungen, Information über das System ............................................................. 23
3.3 Datenverwaltung.................................................................................................................. 24
3.3.1 Datenerfassung und Datenpflege............................................................................ 24
3.3.2 Datenzugriff.............................................................................................................. 25
3.3.3 Datenaustausch....................................................................................................... 26
3.3.3.1 Datenaustausch innerhalb der Universität ................................................ 26
3.3.3.2 Datenaustausch mit externen Einrichtungen ............................................ 26
3.4 Abbildung von Einzelaufgaben im System ......................................................................... 27
3.4.1 Haushaltsdaten ........................................................................................................ 27
3.4.2 Verträge.................................................................................................................... 29
3.4.3 Ausschreibung, Vergabe, Abrechnung (AVA) ......................................................... 30
3.4.4 Energie- und Medienverbrauchsdaten .................................................................... 31
3.4.5 Anlagenstammdaten/Störungsannahme/Instandhaltung........................................ 32
3.4.6 Zutrittskontrolle/Schlüsselverwaltung ...................................................................... 33
3.4.7 Dokumentenmanagement ....................................................................................... 34
3.4.8 Umzüge.................................................................................................................... 35
3.4.9 Bau- und Liegenschaftsdaten.................................................................................. 37
3.4.10 Lehrraumverwaltung und -vergabe.......................................................................... 41
3.4.11 Gebäudereinigung ................................................................................................... 43
3.4.12 Arbeitssicherheit, Arbeitsschutz und Brandschutz ................................................. 44
3.4.13 Adress- und Telefondaten ....................................................................................... 45
3.4.14 IuK, Leitungen und Kabel ........................................................................................ 46
3.4.15 Arbeitsabläufe .......................................................................................................... 47
3.4.16 Sonstige Aufgaben................................................................................................... 47
3.5 Systembedienung................................................................................................................ 47
3.5.1 Bedienoberfläche..................................................................................................... 47
3.5.2 Auswertungen .......................................................................................................... 48
3.6 Kooperation mit den Berliner Hochschulen ........................................................................ 49
3.6.1 FU Berlin .................................................................................................................. 49
3.6.2 TU Berlin .................................................................................................................. 50
3.7 Vergleich mit CAFM-Systemen anderer Hochschulen ....................................................... 52
6
Inhaltsverzeichnis
4 Umsetzung der Empfehlungen ................................................................................................. 55
4.1 Inhaltliche Vorschläge ......................................................................................................... 55
4.1.1 Organisation der CAFM-Systembetreuung und -weiterentwicklung....................... 55
4.1.2 Perspektiven zur Fortentwicklung des CAFM-Systems ......................................... 57
4.1.3 Zusammenarbeit mit anderen Berliner Hochschulen.............................................. 60
4.2 Zeitplanung für eine Umsetzung der Empfehlungen .......................................................... 60
4.3 Fazit ..................................................................................................................................... 61
Literatur ............................................................................................................................................ 63
Glossar.............................................................................................................................................. 65
Anhang.............................................................................................................................................. 71
Befragung der Mitarbeiterinnen und Mitarbeiter der Humboldt Universität ................................. 71
Musterentwurf Raumbuch............................................................................................................. 77
Zeitplan ........................................................................................................................................ 79
Vergleichsdaten ausgewählter Hochschulen (außerhalb Berlins) zum CAFM-Einsatz .............. 80
Projektbeschreibung
7
1 Projektbeschreibung
1.1 Ausgangssituation
Nach einer EU-weiten Ausschreibung wurde im Jahre 1995 an der Humboldt-Universität (HU) ein
CAFM-System1 eingeführt. Den Zuschlag erhielt seinerzeit die Firma IIEF mit Sitz in BerlinAdlershof. Das daraufhin eingeführte System war allerdings nach kurzer Zeit bereits an die Grenze
seiner Leistungsfähigkeit gekommen. Bedingt durch weitere Erfordernisse, die eine Erneuerung
von Teilen der Datenbanksoftware und eine Anpassung an die Weiterentwicklung der WindowsBetriebssysteme erforderlich machten, entschloss sich die HU, Programmierung und Weiterentwicklung des Systems in Eigenregie vorzunehmen. Neben der Erweiterung und Modernisierung
des Systems sollte mit einer Web-basierten Bedienoberfläche eine vereinfachte Bedienbarkeit sowie dezentrale Pflege der Daten ermöglicht werden.
Die Entwicklung des DV-Systems wurde seinerzeit als HBFG-Maßnahme genehmigt. Von den im
Rahmenplan veranschlagten 1,8 Mio. DM wurde bisher etwa die Hälfte für das Projekt aufgewendet. Die Personalkosten der beteiligten Mitarbeiterinnen und Mitarbeiter sind darin nicht berücksichtigt. Das CAFM-System wird fachlich von zwei Personen betreut (davon eine Person für die
Programmierung).
1.2 Aufgabenstellung und Zielsetzung
In einem gemeinsamen Gespräch HU/HIS am 28. Juni 2001 in Berlin, an dem seitens der HU der
Leiter der Technischen Abteilung sowie die mit der Systembetreuung befassten Mitarbeiter teilnahmen, wurde der Wunsch der HU, die Nutzung des CAFM-Systems evaluieren und Strategien
der Weiterentwicklung erarbeiten zu wollen, erörtert. Seitens der HU wurden folgende Untersuchungsziele und Randbedingungen hervorgehoben:
§
§
§
§
In einigen Arbeitsbereichen der Technischen Abteilung (insbesondere Hochbau und Technik)
gibt es erhebliche Akzeptanzprobleme.
Die Verwaltungsleiter der Fakultäten sollen zukünftig die Informationen aus dem CAFMSystem nutzen sowie die Daten z. T. selbst pflegen (z. B. Datenabgleich der Flächen).
Die technische sowie inhaltliche Weiterentwicklung des CAFM-Systems werden zur Zeit jeweils von nur einer Person vorgenommen. Es soll geprüft werden, ob eine externe Unterstützung sinnvoll ist.
Die Einführung eines Hörsaalmanagements (Lehrveranstaltungsplanung) ist vorgesehen.
Für die Bearbeitung des Themas wurden drei Abschnitte vorgesehen:
§
Ist-Analyse des vorhandenen CAFM-Systems unter Berücksichtigung der hochschulinternen
Aufgaben und Prozesse.
§
Bewertung des Systems.
§
Zusammenstellung von Empfehlungen (Soll-Konzept).
1
Der Begriff CAFM (Computer Aided Facility Management System) wird im Folgenden allgemein für Informationssysteme, die Bereiche des Gebäudemanagements abdecken, verwendet – also auch für das System der Technischen Abteilung der Humboldt-Universität.
8
Projektbeschreibung
1.3 Vorgehensweise
Das Projekt wurde im Rahmen einer Informationsveranstaltung am 25. September 2001 in der HU
vorgestellt.
1.3.1
Befragungen
Im Rahmen des Projektes wurde ein großer Teil der mit dem CAFM-System befassten Mitarbeiterinnen und Mitarbeiter sowie Personen, die typische oder besondere Aufgaben im Bereich des
Gebäudemanagements wahrnehmen, befragt, um deren Bedürfnisse und Wünsche im Hinblick auf
den Einsatz eines CAFM-Systems zu ermitteln. Ziel war es dabei auch, Anregungen und Vorschläge zu sammeln, aufzubereiten und hieraus Hinweise für die weitere Vorgehensweise zu gewinnen.
Im Anschluss an die Veranstaltung wurden erste Gespräche mit den Mitarbeiterinnen und Mitarbeitern, die sich mit Fragen des Gebäudemanagements befassen, durchgeführt. Weitere Gespräche fanden danach jeweils ganztägig in Form von Einzelgesprächen von ca. 45 Minuten Dauer am
1., 16., 23., 25., 29. und 30. Oktober 2001 statt. In den Gesprächen wurden Fragen zum SoftwareEinsatz allgemein sowie speziell zur Verwendung des CAFM-Systems der HU gestellt. Den Befragten sollte dabei die Möglichkeit gegeben werden, Kritik zu äußern sowie Vorschläge für Verbesserungen mitzuteilen.
Der Kreis der befragten Personen setzte sich zusammen aus den Verwaltungsleitern der Fakultäten, den Leitern und Mitarbeitern der beiden Hochbaureferate sowie aus weiteren Mitarbeiterinnen
und Mitarbeitern der Technischen Abteilung. Insgesamt wurden 44 Gesprächstermine wahrgenommen, hinzu kamen noch Besprechungen mit dem Leiter der Technischen Abteilung.
Im Einzelnen wurden folgende Personen aus den Abteilungen/Referaten/Fakultäten befragt:
Referat/Bereich
I (Studienabteilung)
Name
Herr Baeckmann
Herr Möhlmann
II (Forschungsabteilung)
Frau Dr. Lehmann
III (Personalabteilung)
Frau Hecht
Frau Hielscher
IV (Haushaltsabteilung)
Frau Klug
V (Technische Abteilung)
Herr Schwalgin
V A (Allg. Dienste)
Herr Gadow
V B (Planung)
Herr Meißner
Herr Hoefs
Frau Roll
Herr van Suntum
V C (Hochbau I, GeisteswissenHerr Köhler
schaften)
Herr Himmel
V D (Hochbau II, Naturwissenschaften) Frau Richter-Sepke
Frau Rünger
Herr Wintrich
V E (Technische Gebäudeausrüstung) Herr Rompf
Herr Fiedler
Herr Gutte
Herr Schulze
V F (Grundstücks-/
Herr Greulich
Gebäudeverwaltung)
Frau Heber
Frau Lübke
Herr Mammel
Herr Nelde
Frau Peitsch
V 2 (Bautechnische Verwaltung)
Frau Dr. Krüger
V 3 (Abrechnung und Controlling)
Frau Hößelbarth
V 4 (Arbeitsschutz)
Frau Dr. Bader
Tätigkeit
Abteilungsleiter
Referatsleiter
Abteilungsleiterin
Referatsleiterin
Abteilungsleiterin
Abteilungsleiterin
Abteilungsleiter
Referatsleiter
Referatsleiter
Mitarbeiter
Gruppenleiterin
Gruppenleiter
Referatsleiter
Bauleiter (Gruppenleiter)
Referatsleiterin
Bauleiterin
Bauleiter (Gruppenleiter)
Referatsleiter
Gruppenleiter
Fachbauleiter
Fachbauleiter
Gruppenleiter
Gruppenleiterin
Referatsleiterin
Programmentwickler CAFM
Mitarbeiter
Gruppenleiterin
Gruppenleiterin
Gruppenleiterin
Referatsleiterin
9
Projektbeschreibung
Großbritannien-Zentrum
Juristische Fakultät
Landwirtschaftl.-gärtnerische Fakultät
Mathemat.-Naurwissensch. Fakultät I
Mathemat.-Naurwissensch. Fakultät II
Philosophische Fakultät I
Institut für Geschichtswissenschaften
Philosophische Fakultät II
Philosophische Fakultät III
Philosophische Fakultät IV
Rechenzentrum
Museum für Naturkunde
Theologische Fakultät
Universitätsbibliothek
Wirtschaftswissenschaftliche Fakultät
Zentraleinrichtung Sprachzentrum
Strategische Entwicklung und Planung
(LESSY-Projekt)
Frau Zöllner
Dr. Aßmann
Dr. Gröning
Herr Dietzsch
Frau Dr. Katzung
Herr Hartmann
Herr Dr. Kohring
Frau Dr. van Mörbeck
Frau Schmidt
Herr Dr. Kudella
Frau Jung
Dr. Kroß
Frau Natusch
Herr Hackmann
Herr Plappert
Herr Kolb
Frau von Garrel
Frau Wöß
Frau Kattein-Hebestedt
Herr Bauerfeld
Herr Reinsch
Dr. Stuchtey
Verwaltungsleiterin
Verwaltungsleiter
Verwaltungsleiter
Verwaltungsleiter
Verwaltungsleiterin
Verwaltungsleiter
Wiss. Mitarbeiter
Verwaltungsleiterin
Verwaltungsleiterin
Verwaltungsleiter
Verwaltungsleiterin
Sachgebietsleiter
Sachbegietsleiterin
Verwaltungsleiter
Sachgebietsleiter
Verwaltungsleiter
Verwaltungsleiterin
Verwaltungsleiterin
Verwaltungsleiterin
Gruppenleiter
Verwaltungsleiter
Projektleiter
Frau Dr. Bader, Herr Reinsch und Frau Rünger wurden per E-Mail befragt. Mit Herrn Mammel, der
die Erweiterungen sowie die Web-Unterstützung des CAFM-Systems in den letzten Jahren allein
programmiert hat (teilweise unterstützt durch eine studentische Hilfskraft), wurde ein zusätzlicher
Gesprächstermin (am 13. November) vereinbart. Darin ging es vorwiegend um DV-technische
Fragen zum CAFM-System.
Bei der Bearbeitung des Themas wurden verschiedene Möglichkeiten der Informationsbeschaffung
berücksichtigt.
1.3.2
Projektgruppe
Erfahrungen, die HIS in vergangenen Projekten gemacht hat, haben gezeigt, dass ein entscheidendes Kriterium für das erfolgreiche Einführen eines CAFM-Systems die Akzeptanz durch die
betroffenen Mitarbeiterinnen und Mitarbeiter ist. Aus diesem Grund wurde mit der Zusammenstellung einer Projektgruppe bzw. mit der Bildung von Arbeitsgruppen zu speziellen Themenbereichen
die Möglichkeit geschaffen, eine direkte Beteiligung der verschiedenen Gruppen zu erreichen.
Die hochschulinterne Projektgruppe umfasste folgenden Personenkreis:
Herr Dr. Aßmann (Juristische Fakultät)
Herr Fiedler (Referat Technische Gebäudeausrüstung)
Herr Dr. Gröning (Landwirtschaftlich-Gärtnerische Fakultät)
Frau Günther/Frau Natusch (Rechenzentrum)
Frau Hecht (Personalabteilung)
Frau Klug (Haushaltsabteilung)
Herr Köhler (Hochbauabteilung I)
Herr Dr. Kohring (Institut für Geschichtswissenschaften)
Frau Dr. Krüger (Bautechn. Verwaltung)
Frau Lübke (Referat Grundstücks- und Gebäudeverwaltung)
Herr Mammel (Referat Grundstücks- und Gebäudeverwaltung; Systemverantwortlicher)
Herr Person (HIS Hochschul-Informations-System)
Frau Rünger/Herr Wintrich (Hochbauabteilung II – Bauleitung)
Herr Scholz (Hochbauabteilung I – Bauleitung)
Herr Schwalgin/Frau Richter-Sepke (Leiter der Technischen Abteilung/Stellvertretende Leiterin)
Herr van Suntum (Planung)
Je nach themenbezogenem Bedarf wurden Arbeitsgruppen gebildet, die ggf. fachbezogen um
weitere Mitarbeiterinnen und Mitarbeiter der HU ergänzt wurden. Hinzugezogen wurden dabei
10
Projektbeschreibung
Frau Hößelbarth (Referat Abrechnung und Controlling), Herr Schulze (Referat Technische Gebäudeausrüstung), Herr Szdzuy (Referat Grundstücks- und Gebäudedienste – Brandschutz), Herr
Wenzel (Referat Grundstücks- und Gebäudedienste – Gebäudereinigung).
Die Leitung der Projektgruppe wurde von Herrn Person übernommen. Frau Dr. Krüger wird diese
Aufgabe (in Abstimmung mit Herrn Schwalgin) nach Abschluss des HIS-Projektes übernehmen.
Projektgruppensitzungen fanden jeweils am 10. Januar 2002, 24. Januar 2002, 14. Februar 2002
und 14. März 2002 statt. Weitere Sitzungen sind vorgesehen. Im Rahmen der Projektgruppensitzungen wurden die Anforderungen an das CAFM-System unter Berücksichtigung von Ergebnissen
der HIS-Befragung sowie von der HU selbst erhobenen Informationen präzisiert bzw. zum Teil neu
formuliert und eine Zeitplanung für die weitere Vorgehensweise aufgestellt (s. Anhang). Ziel sollte
sein, dem genannten Personenkreis über die HIS-Beteiligung an dem Projekt hinaus eine Perspektive für die weitere Vorgehensweise aufzuzeigen und damit Hilfestellung für die Weiterentwicklung des CAFM-Systems sowie den sachgerechten Systemeinsatz zu geben.
1.3.3
Sonstige Informationen
Im Rahmen des Projektes wurden außerdem Informationen über den CAFM-Einsatz einer Reihe
weiterer Hochschulen zusammengestellt. Ergänzend hierzu wurden die Leiter der Technischen
Abteilungen anderer Berliner Universitäten (Freie Universität Berlin und Technische Universität
Berlin) befragt, um herauszufinden, inwieweit hier vergleichbare Aufgabenstellungen und Zielsetzungen vorhanden sind und sich daraus eine gemeinsame Strategie beim Systemeinsatz ableiten
lässt.
Der Einsatz des CAFM-Systems der HU auch an anderen Berliner Hochschulen wurde bereits
frühzeitig in Betracht gezogen. Insbesondere die Berliner Universitäten und die Charité wurden
hier als potenzielle Partner genannt. Die bisherigen Kontakte auf der Abteilungsleitungsebene waren jedoch eher zurückhaltend. HIS hat daher speziell in dieser Frage Kontakt mit zwei Universitäten (FU und TU Berlin) aufgenommen (siehe unter 3.6). Infolge der starken SAP-Orientierung der
Kliniken, wurden diese, auch im Hinblick auf den zeitlichen Rahmen des Projektes, von der Betrachtung ausgenommen.
Das CAFM-System der Humboldt-Universität
11
2 Das CAFM-System der Humboldt-Universität
2.1 Merkmale des CAFM-Systems
Anfang 1997 übernahm die HU die Weiterentwicklung des Systems, nachdem umfangreiche Änderungen u. a. wegen eines Betriebssystemswechsels von Windows 3.11 nach Windows 95 erforderlich wurden [1].
An der HU wird vorwiegend mit Anwendungen unter Windows 95 gearbeitet. Auf der Server-Seite
sind UNIX- (Sun-Solaris) und LINUX-Systeme im Einsatz. Das lokale Datennetz der HU basiert
überwiegend auf dem System Banyan VINES. Eine Intranet-Umgebung ist – abgesehen von den
Haushalts- und Personalabteilungen – nicht realisiert.
Die technischen Merkmale des CAFM-Systems wurden in Gesprächen mit dem für die Programmierung und DV-technische Pflege des Systems verantwortlichen Mitarbeiter an der HU erfragt.
Sie sind im Folgenden zusammengefasst wiedergegeben und, soweit dies sinnvoll erschien, kommentiert (Stand März 2002).
2.2 Konzeption
Von der Universitätsseite her gibt es derzeit keine allgemeinen konzeptionellen Vorgaben im Sinne
von Standards, die sich direkt auf das CAFM-System beziehen. Bei der Programmierung werden
allgemein übliche Programmierstandards bzw. die Konventionen der Firma Sun2 berücksichtigt.
Bei der Erstellung der Anwendungen werden eigene Vorgaben (des Programmierers) zugrunde
gelegt. Der Wunsch nach Vorgaben im Sinne eines durchgängigen Konzeptes wurde auch von
dieser Seite geäußert.
Ein Problem stellt offenbar die fehlende Zusammenführung der Nutzeranforderungen dar. Da die
Nutzerwünsche bisher vorwiegend „auf Zuruf“ erledigt wurden, sind zum Teil sehr viele Anwendungen entstanden (Beispiel: Auswertefunktionen), die sich teilweise kaum voneinander unterscheiden. Hinzu kommt, dass eine Reihe von Funktionen bisher kaum genutzt wurden. Aus diesem Grund sind bereits einige dieser Funktionen aus dem CAFM-System entfernt worden. Eine
bessere Abstimmung der Nutzer untereinander wird hier als wünschenswert angesehen.
Das CAFM-System soll zunächst anhand der Bedienoberfläche, der Anwendungsprogrammierung
und der verwendeten Datenbanksysteme beschrieben werden.
Von der Softwarestruktur her ist das System historisch gewachsen. Derzeit finden sich dort Programmteile aus unterschiedlichen Entwicklungsphasen wieder. Teilweise sind noch Anwendungen,
die seinerzeit unter Windows 3.1 programmiert wurden integriert. Ein modularer Aufbau oder eine
Skalierbarkeit des Systems kann unter diesen Voraussetzungen nicht festgestellt werden.
Konzeptionelle Festlegungen für das Gesamtsystem sowohl im Hinblick auf die Zuständigkeiten
als auch im Hinblick auf die technische Umsetzung sind bislang nicht getroffen worden. Begründet
wurde dies u. a. mit den sehr unterschiedlichen Anforderungen der verschiedenen Nutzergruppen.
In Abb. 1 ist schematisch das Modell des CAFM-Systems in der Form, wie es derzeit genutzt werden kann, dargestellt. Erkennbar sind dort die verschiedenen Bedienoberflächen (FM-Works, Webbasiert sowie die des Systems InfoCable). Auf der Applikationsebene sind ebenfalls unterschiedliche Methoden der Programmierung eingesetzt worden. Zwei Datenbank-Systeme werden als
Basis für die Ablage der Daten genutzt.
2
Die Firma Sun besitzt die Lizenzrechte für die Programmiersprache Java.
12
Dargestellt ist in der Abbildung auch das Kabelmanagement-System „InfoCable“, das noch vom
Rechenzentrum der Universität genutzt wird. Für den künftigen Ausbau des CAFM-Systems wird
es allerdings keine Rolle mehr spielen, da das Rechenzentrum die vertragliche Bindung an die
Firma IIEF, die das System entwickelt hat, Ende 2001 gelöst hat. Begründet wurde die Vertragskündigung mit dem hohen Pflegeaufwand für die Daten, der seitens des Rechenzentrums nicht zu
leisten ist. Aus dem selben Grund wurden bisher lediglich wenige Daten in das System eingepflegt
und damit dessen Möglichkeiten nur zu einem geringen Teil ausgenutzt, so dass ein weiterer Einsatz nicht gerechtfertigt erschien.
WebOberfläche
FM-Works
IIEF-Bedienoberfläche
Java
HTML, XML
CGI, PHP
InfoCable
(IIEF)
mySQL
ORACLE
Titelverwaltung
Bau- und
Liegenschaftsdaten
Abb. 1: Modell des CAFM-Systems der Universität
13
2.3 Bedienung
Derzeit besteht die Möglichkeit mit einem marktüblichen Web-Browser auf das CAFM-System zuzugreifen. Dabei wird die in Abb. 2 dargestellte Oberfläche auf der Startseite www.ta.hu-berlin.de
sichtbar.
Abb. 2: Startseite des CAFM-Systems der Humboldt-Universität
Eine andere Möglichkeit, die jedoch noch nicht an allen Arbeitsplätzen realisiert wurde, besteht
darin, das JAVA-basierte System FM-Works zu starten. FM-Works ist eine Client-/Server-Anwendung, die auf der Client-Seite ohne spezielle Software für die Arbeit mit dem CAFM-System auskommt. Lediglich einmal, d. h. vor dem erstmaligen Aufruf des Systems ist eine Software zu installieren (JAVA-Web-Start). Mit Hilfe des JNLP kann die automatische Installation auf dem Zielsystem
erfolgen. Danach ist jeder Client in der Lage, auf die Serverdaten zuzugreifen. Spezielle Anwendungen werden bei Bedarf hinzugeladen. Wird die Software auf dem Server geändert, erfolgt ein
automatisches Herunterladen der aktuell benötigten Komponenten auf der Client-Seite, ohne dass
sich der Nutzer darum zu kümmern braucht. Ein Web-Browser ist für den Zugriff auf das System
nicht erforderlich. Auch eine spezielle Intranet-Lösung ist nicht erforderlich. Eine Zertifizierung der
Anwendung ist vorgesehen, um die mit dem Zugriff von außen verbundenen Sicherheitsrisiken zu
verringern. Abb. 3 zeigt ein Beispiel für die Bedienoberfläche unter FM-Works.
14
Abb. 3: Bedienoberfläche unter FM-Works. Dargestellt ist die Funktion „Raumbuch“
2.4 Anwendungsprogrammierung
Die aktuellen Anwendungen wurden bereits in Java programmiert. Durch diese Technik wird ein
modularer Systemaufbau erreicht. In sich gekapselte Anwendungen (sog. Java-Beans) ermöglichen zudem die Programmierung von Funktionen unabhängig vom Gesamtsystem. Die bisher
verfügbaren Funktionen erlauben derzeit nicht den Ersatz der vorhandenen (auf dem IIEF-System
basierenden, älteren) Anwendungen. Vorgesehen ist die Ergänzung des Systems durch XMLElemente. XML ermöglicht die Programmierung von Funktionen, die von nahezu allen Betriebssystemen und Datenbanken genutzt werden können. Mit dem Einsatz von XML wurde erst ab etwa
Mitte 2001 begonnen.
Java ermöglicht Verschlüsselungen (SSL) zu integrieren. Diese Funktion wird zum Teil bereits genutzt.
Mit JDBC steht eine einheitliche Datenbank-Schnittstelle zur Verfügung. Die JDBC-Schnittstelle
lässt sich mit der ODBC-Schnittstelle für Microsoft-Systeme vergleichen. Sie muss jedoch nicht
gesondert auf jedem Rechner installiert werden. Die JDBC-Schnittstelle wird als sehr stabil eingeschätzt.
Bei der Programmierung der Module werden zur Zeit keine hochschulspezifischen Standards
zugrunde gelegt. Es werden selbstdefinierte Standards des Programmierers unter Berücksichtigung der Konventionen der Fa. Sun sowie allgemeiner Konventionen wie sie in Programmierkreisen üblich sind berücksichtigt. Auf der Serverseite werden UNIX-basierte Betriebssysteme (Sun
Solaris und LINUX) eingesetzt. Es könnten aber auch andere UNIX-Systeme Verwendung finden.
15
Das System ermöglicht die Realisierung von verteilten Anwendungen. Damit ist es möglich, rechenintensive Vorgänge auf mehrere Systeme zu verteilen. Im Vordergrund steht weiterhin die
Verwendung „kostengünstiger und bewährter Systeme“ (LINUX, Apache, MySQL, PHP). Dabei
wird die Integration von gängigen Standarddateiformaten (z. B. PDF für Dokumente, DXF für CAD)
angestrebt.
Die Software-Distribution auf der Client-Seite erfolgt via Internet mit JNLP (es fallen keine Wartungsarbeiten bei den Client-Systemen an, da alle benötigten Komponenten automatisch auf dem
Zielsystem installiert bzw. aktualisiert werden – s. a. 2.3).
2.5 Datenbank
Derzeit erfolgt ein Parallelbetrieb einer ORACLE und einer MySQL-Datenbank (wie in Abb. 1 dargestellt). ORACLE wird derzeit in der Version 8.0.4 verwendet. Die Version 8.1.6 ist vorhanden.
Der Wechsel zu einer neuen Version ist nach Auskunft des betreffenden Mitarbeiters nicht ohne
Probleme durchführbar. Der ORACLE-Einsatz ist vorwiegend durch den Einsatz des IIEF-Systems
begründet. Die IIEF-Lösung hat offenbar in großem Maße den Einsatz von Triggern und speziellen
Prozeduren vorgesehen. Bei einem Versionswechsel ist aus diesem Grund eine Neukompilierung
der Anwendung erforderlich. Erfahrungen haben gezeigt, dass es dabei auch zu Inkompatibilitäten
kommen kann, die das CAFM-System in seiner Funktion beeinträchtigen oder ganz lahmlegen
können.
Das derzeit vorhandene CAFM-System wird von der Softwarestruktur her als zu komplex bezeichnet, insbesondere gilt dies für die Datenbank, die die Bau- und Liegenschaftsdaten enthält. Nach
Angaben des für das System Verantwortlichen enthält die ORACLE-Datenbank knapp 2.000 verknüpfte Tabellen und ist unter Verwendung verschiedener Programmiersprachen programmiert
worden. Die Dokumentation ist schlecht, so dass sich außer ihm niemand mit dem CAFM-System
auskennt.
Der Einsatz von ORACLE wird seitens des zuständigen Mitarbeiters der TA grundsätzlich als sehr
aufwändige Lösung gesehen, die zudem mit hohen Kosten verbunden ist. Kritik gibt es dort auch
an technischen Merkmalen (genannt wurden „geringe Flexibilität“, „... unterstützt lediglich ein Freitext-Feld je Tabelle“). Die Geschwindigkeit der Datenbankzugriffe wird als zu gering empfunden
(wobei darauf hingewiesen wurde, dass ORACLE im Vergleich zu anderen kommerziellen Datenbanken bereits zu den schnelleren Systemen gehört).
Favorisiert wird in der Technischen Abteilung das Datenbanksystem MySQL. Seit 1997 wird diese
Datenbank eingesetzt, derzeit in der Version 3.21.32 (mittlerweile wird die Version 4 angeboten).
MySQL beinhaltet ein offenes Datenbankkonzept, das für verschiedene BetriebssystemPlattformen verfügbar ist. Es ist in der Regel kostenlos verfügbar. Das System zeichnet sich durch
hohe Verarbeitungsgeschwindigkeit aus. Während ältere MySQL-Versionen einige Funktionen
kommerzieller Datenbank-Systeme nicht enthielten, werden mittlerweile z. B. auch Transaktionen
bei Mehrfachzugriff unterstützt. Hinzu kommt jetzt auch hier die Möglichkeit spezielle Programme
auf der Datenbankebene (sog. Trigger) zu starten.
Der Einsatz von MySQL umfasst derzeit die Erfassung der Haushaltsdaten (der Technischen Abteilung) sowie das Dokumentenmanagement. Bei der Übertragung von sensiblen Daten wird eine
128-Bit-Verschlüsselung (SSL) verwendet3. Eine Gruppen- und Benutzerverwaltung ist integriert.
Die Gebäude- und Raumdaten sind in der ORACLE-Datenbank enthalten. Alle Datenbankoperationen erfolgen nach dem SQL 92-Standard.
3
ORACLE bietet die SSL-Verschlüsselung ebenfalls an, sie gehört jedoch nicht zum Standardlieferumfang und muss
daher gesondert erworben werden. Die Technische Abteilung besitzt keine entsprechende Lizenz.
16
Das CAFM-System ist in der Lage, Daten aus jeder Datenbank, die ODBC unterstützt, zu übertragen (Text oder CSV-Format). Allerdings kann in Abhängigkeit von Aufbau und Struktur der Datenfelder eine Nachbearbeitung erforderlich werden. Als Nachteil des Datenaustausches über die
ODBC-Schnittstelle wurde angemerkt, dass hierbei keine Protokollierung erfolgen kann.
Zugriffsrechte lassen sich bereits in dem vorhandenen System flexibel konfigurieren. Dabei können auch Zugriffsbeschränkungen in der Form „Lesen bestimmter Datenfelder nur für einen bestimmten Berechtigtenkreis“ festgelegt werden.
Die Zugriffsrechte lassen sich auch für Dokumente individuell festlegen.
2.6 Grafische Informationen und CAD-Daten
CAD-Daten werden in der derzeitigen Lösung mit Hilfe eines (kostenlosen) Viewers angezeigt. Die
im System vorhandenen Etagengrundrisse sind allerdings nicht maßstabsgerecht bzw. bemaßt.
Auf die Aufnahme von Wänden, Türen, Fenstern etc. wurde verzichtet. Die Darstellungen werden
auf der Basis der Grundrisse (gescannte Zeichnungen oder „abgespeckte“ CAD-Pläne) beim Aufruf mit Hilfe der Informationen aus der Datenbank dynamisch generiert. Die Datenbank ist hier also
das führende System.
Derzeit werden verschiedene Dateiformate für die digitalisierten bzw. in Dateiform vorhandenen
Originalzeichnungen (CAD-Pläne) und die im CAFM-System hinterlegten Grundrisse verwendet.
Technisch wäre eine Zusammenführung – nach Auskunft des CAFM-Entwicklers – realisierbar. Die
Integration von CAD-Plänen in das CAFM-System könnte dabei über eine XML-Applikation realisiert werden. Beispielsweise besitzt das CAD-Programm AUTOCAD eine XML-Schnittstelle, die
besser geeignet ist, als der Import von z. B. DXF-Daten in ein CAD-System.
Bilder in Form von Pixelgrafiken (Fotos, eingescannte Pläne) können bereits vom jetzigen System
problemlos verarbeitet werden, indem sie z. B. bestimmten Gebäuden oder Räumen zugeordnet
werden. Teilweise ist dies auch realisiert.
Am Standort Adlershof wurden bereits ca. 70 % der Gebäudegrundrisse erfasst (MicrostationFormat4).
2.7 Sonstige Informationen
Die Historisierung der Daten erfolgt derzeit in Stufen (rotierender Backup-Zyklus). Eine chronologische Datenhistorisierung ist jedoch nicht vorhanden (Ausnahmen können in Absprache mit den
zuständigen Bearbeitern gemacht werden, z. B. bei den Finanzdaten). Als Nachteil einer durchgängigen Historisierung wurde die dabei anfallende Datenmenge angeführt. In einigen Bereichen,
z. B. im Rechnungswesen ist eine Historisierung der Daten über 10 Jahre gesetzlich vorgeschrieben.
Die Währungsumstellung von DM in EURO wurde zu einem festen Termin (vorgesehen war der
7. Dezember 2001) durchgeführt. Die gleichzeitige Verwendung beider Währungseinheiten ist nicht
vorgesehen.
Die Möglichkeit Termine anstoßen zu können ist noch nicht realisiert. Eine Realisierung in Form
eines Workflow-Managements wäre technisch machbar, Probleme werden jedoch im organisatorischen Bereich gesehen.
Auch die automatische Generierung von Arbeitsaufträgen wird als realisierbar angesehen.
4
CAD-Progamm der Fa. Bentley.
Ergebnisse der Untersuchung
17
3 Ergebnisse der Untersuchung
Basis der HIS-Recherchen zum CAFM-System bildet eine Befragung von Mitarbeiterinnen und
Mitarbeitern (Einzelheiten zum befragten Personenkreis siehe unter 1.3), aus der sich eine umfangreiche Sammlung von Aussagen ergab. Neben kritischen Anmerkungen sind dabei auch eine
Reihe von Verbesserungsvorschlägen gemacht worden (eine Zusammenstellung der Aussagen ist
im Anhang zu finden).
Die Ergebnisse sind zu folgenden Themenkomplexen gebündelt worden:
§
§
§
§
§
Nutzung und Akzeptanz des Systems,
Organisation des CAFM-Systemeinsatzes,
Datenverwaltung,
Abbildung von Einzelaufgaben,
Systembedienung.
Bei der Darstellung des jeweiligen Themas wird zunächst eine Beschreibung des Ist-Zustandes
(aus der Sicht von HIS) vorgenommen. Anschließend folgt jeweils die Zusammenfassung von
Aussagen, Kritik und Vorschlägen, die im Rahmen der Befragung durch HIS angebracht worden
sind. Danach sind jeweils eine Bewertung der Situation (aus der Sicht von HIS) sowie Vorschläge
zur Verbesserung, wobei letztere bereits Ergebnisse der Projektgruppensitzungen enthalten, ausgeführt. Als Abschluss dieses Kapitels wird auf charakteristische Merkmale des CAFM-Einsatzes
an ausgewählten Hochschulen in Deutschland im Vergleich zur HU eingegangen.
3.1 Nutzung und Akzeptanz des Systems
Ist-Zustand:
Die Nutzung des CAFM-Systems erfolgt hauptsächlich durch die Technische Abteilung. Der
Schwerpunkt der Nutzung liegt in den Referaten, die sich mit den Bau-, Liegenschafts- und Rechnungs- bzw. Haushaltsdaten befassen. Eine weit weniger intensive Nutzung ist im Bereich des
Hochbaureferats sowie im Referat Technische Gebäudeausrüstung zu beobachten.
Von den Verwaltungsleitern der Fakultäten und universitären Einrichtungen wird das System vereinzelt zu Informationszwecken genutzt.
Anforderungen und Kritik (Befragung):
Die Befragung ergab, dass das CAFM-System (außerhalb der Technischen Abteilung) z. T. nicht
bekannt war. In einigen Fällen sind die betreffenden Personen erst durch Hinweise von außen
(z. B. durch externe Ingenieurbüros) auf das CAFM-System gestoßen. Hieraus resultiert der
Wunsch nach verbesserter Information über das System sowie nach einer Einführung (im Sinne
einer Schulung).
Oft geäußert wurde auch der Wunsch nach einem weiteren Ausbau des CAFM-Systems. Vereinzelt wurde die Anforderung erwähnt, das System auch für die Erfassung ganz spezieller, z. B. fakultätsspezifischer Merkmale (z. B. zur Erfassung bestimmter technischer Geräte) nutzen zu können, die dann nur in dem betreffenden Bereich verfügbar sein sollen.
HIS-Bewertung:
Der in einigen Bereichen geringe Bekanntheitsgrad des CAFM-Systems erscheint insbesondere im
Hinblick auf den bereits mehrere Jahre andauernden Einsatz des Systems nicht nachvollziehbar.
Schwerwiegender erscheint allerdings die unterschiedliche Intensität, mit der die Nutzung innerhalb der Referate der Technischen Abteilung erfolgt. Dies lässt vermuten, dass das CAFM-System
18
in der bisher eingesetzten Form nicht immer als nützliches Instrument zur Bewältigung der täglichen Aufgaben gesehen wird. Umso mehr gilt dies für die Zuständigkeitsbereiche außerhalb der
Technischen Abteilung. Hier wird das System von dem überwiegenden Teil der befragten Personen lediglich sporadisch genutzt.
HIS-Vorschlag
Der häufig geäußerte Wunsch nach einem weiteren Ausbau des CAFM-Systems zeigt, dass ein
Bedarf nach einem Informationssystem vorhanden ist. Ausgehend von diesem Bedarf sollten zunächst schwerpunktmäßig diejenigen Teile des Systems über- bzw. bearbeitet werden, an deren
Funktionsfähigkeit ein großes Interesse besteht. Dabei ist es wichtig, die Anforderungen genau zu
formulieren, realistische Aussagen zur Datenerfassung und Pflege zu machen und klare Verantwortlichkeiten festzulegen. Eine Entkopplung der Zuständigkeiten für die Festlegung der Anforderungen (Arbeitsgruppen) und der praktischen Realisierung (Programmierung) ist dabei unabdingbar, wobei der Informationsaustausch erhalten bleiben soll. Letzteres könnte z. B. durch die Realisierung von Pilotanwendungen geschehen, die es ermöglichen, die Umsetzung der Anforderungen
praktisch zu überprüfen.
Des Weiteren ist eine regelmäßige Information über den Stand der Entwicklung des CAFMSystems anzustreben. Hier ist nicht davon auszugehen, dass sich der potenzielle Nutzer die Informationen holt, sondern er sollte gezielt angesprochen werden (durch Aushang und per E-Mail
sowie durch Workshops und ggf. Informationsveranstaltungen).
3.2 Organisation des CAFM-Systemeinsatzes
Organisatorische Fragen der Technischen Abteilung werden an dieser Stelle nur insoweit betrachtet, wie sie unmittelbar mit dem Einsatz des CAFM-Systems zusammenhängen.
3.2.1
Zuständigkeiten (allgemein)
Ist-Zustand:
Nahezu alle Aufgabenbereiche aus dem infrastrukturellen, technischen und kaufmännischen Gebäudemanagement sind der Technischen Abteilung zugeordnet. Bei einigen Aufgaben gibt es Berührungspunkte mit anderen Abteilungen (Studienabteilung, Forschungsabteilung, Rechenzentrum, Haushaltsabteilung, Personalabteilung) sowie mit den Verwaltungsleitungen der Fakultäten
und Zentraleinrichtungen.
Die Technische Abteilung der HU ist in folgende Referate (Stellen) gegliedert (mit Standortangabe):
§
§
§
§
§
§
§
§
§
§
Leitung/Sekretariat (Ziegelstraße 10/11)
Bautechnische Verwaltung (Ziegelstraße 10/11)
Abrechnung und Controlling (Ziegelstraße 13c)
Allgemeine Dienste (Ziegelstraße 10 u. a. )
Planung (Ziegelstraße 10)
Hochbau I – Geisteswissenschaften (Ziegelstraße 13b u. a.)
Hochbau II – Naturwissenschaften (Ziegelstraße 10 u. a.)
Technische Gebäudeausrüstung (Ziegelstraße 10 u. a.)
Grundstücks- und Gebäudeverwaltung (Ziegelstraße 10)
Arbeitsschutz/Beauftragte – Arbeitsschutz-, Abfall- und Energiebeauftragte (Jägerstr. 10/11)
Ungeklärt scheint häufig die Zuständigkeit (Verantwortlichkeit) für die Weitergabe von Informationen zu baulichen Änderungen zu sein. Teilweise werden die Bauleiter der Hochbaureferate, teilweise auch die Verwaltungsleiter der Fakultäten und zentralen Einrichtungen in der Verantwortung
19
gesehen. Auf unterschiedliche Zuständigkeiten wurde auch bei der Verwaltung von Räumen für
Veranstaltungen hingewiesen (s. 3.4.10).
Beklagt wurden in einigen Fällen arbeitsorganisatorische Defizite sowie eine fehlende Kundenorientierung seitens der Mitarbeiterinnen und Mitarbeiter der Technischen Abteilung.
Als Problem insbesondere bei der Einführung von DV-Systemen stellt sich offenbar auch die Altersstruktur in einigen Referaten der Universität dar.
Die detaillierte Beschreibung von Arbeitsabläufen, die dann im CAFM-System umgesetzt werden
sollen, wird insbesondere von den für die Systembetreuung zuständigen Mitarbeiterinnen und Mi tarbeitern gewünscht.
HIS-Bewertung:
Die Betrachtung allgemeiner organisatorischer Fragen ist nicht Bestandteil dieser Untersuchung.
Im Hinblick auf den effizienten Einsatz eines CAFM-Systems sollten jedoch insbesondere die Fragen nach der Verantwortlichkeit, der Arbeitsorganisation, der Kommunikation der Mitarbeiterinnen
und Mitarbeiter sowie der Kundenorientierung parallel betrachtet werden.
HIS-Vorschlag:
Empfohlen wird eine detaillierte Untersuchung der Arbeitsabläufe in der Technischen Abteilung,
um hier optimale Voraussetzungen für einen CAFM-Einsatz zu schaffen (s. 3.4.15). Zwar ist ein
CAFM-System in der Lage, bestimmte Defizite im Bereich der Informationsweitergabe bzw. Kommunikation auszugleichen, als Mittel zur Optimierung der Organisation einer Abteilung ist es jedoch ungeeignet.
Eine Lösung ist auch für die als problematisch empfundene Altersstruktur bei den Bauleitern in den
Hochbauabteilungen anzustreben, da sie auch mit Akzeptanzproblemen in der DV-Technik gekoppelt ist. Kurzfristig ließen sich speziell auf diesen Personenkreis abgestimmte Schulungen anbieten. Davon unabhängig kann sich hier mittelfristig die Umsetzung organisatorischer Veränderungen anbieten. Übergangsweise ist auch eine Verlagerung von DV-Aufgaben (z. B. im Bereich der
Datenerfassung und Dokumantation) an zusätzliche Kräfte, die z. B. dem Personalüberhang der
HU entnommen werden können, denkbar.
3.2.2
Systembetreuung
Ist-Zustand:
Die technische Betreuung des CAFM-Systems erfolgt im Referat Grundstücks- und Gebäudeverwaltung durch eine Person. Dafür stehen nach deren Angaben ca. 45 % an Zeit für Arbeiten am
System zur Verfügung. Unterstützt wird der Mitarbeiter zeitweilig durch eine studentische Hilfskraft.
Der Rest der Arbeitszeit gilt Verwaltungsaufgaben, der Dokumentation und Präsentation sowie der
Betreuung und Administration der UNIX-Systeme in der Technischen Abteilung.
Es gibt weder eine Vertretungsregelung für den Urlaubs- und Krankheitsfall, noch könnte eine
Weiterbetreuung des CAFM-Systems bei Ausfall des betreffenden Mitarbeiters gewährleistet werden. Hinzu kommt, dass dieser neben der Systemprogrammierung auch inhaltliche Fragen bearbeitet hat. Beispielsweise wurde seinerseits Ende 2001 eine interne Veranstaltung an der HU
durchgeführt, in deren Rahmen auch die Ergebnisse einer von ihm durchgeführten Befragung unter ausgewählten Mitarbeitern der Technischen Abteilung zur Weiterentwicklung des CAFMSystems vorgestellt wurde.
Die technische Betreuung beinhaltet die Entwicklung von Anwendungen auf der Basis von Java
(Oberflächen), CGI, HTML, PHP sowie anderer Programmiersprachen. Die Entwicklung von Anwendungen erfolgt dabei in der Regel auf Anforderung durch den Nutzer.
20
Da große Teile des CAFM-Systems noch auf älteren Anwendungen, die seinerzeit Bestandteil des
CAFM-Systems der Firma IIEF waren und nur zu geringen Teilen dokumentiert sind, basieren, ist
das System in der derzeit verwendeten Form nicht ohne weiteres durch eine andere Person, bzw.
Externe weiterentwickelbar.
Für organisatorische Fragen, die das CAFM-System betreffen, ist eine weitere Person zuständig.
Da diese u. a. auch mit Ausschreibungen, die im Zuständigkeitsbereich der Technischen Abteilung
liegen, befasst ist, ist der für die Betreuung des CAFM-Systems verfügbare Zeitrahmen begrenzt.
Gewünscht wird von den zuständigen Mitarbeitern mehr Zeit und Unterstützung sowohl für die organisatorische als auch für die technische Betreuung des CAFM-Systems.
HIS-Bewertung:
Der derzeitige Zustand der Systembetreuung kann sowohl aus der Sicht der Hochschule als auch
aus der Sicht des für die Systementwicklung verantwortlichen Mitarbeiters als nicht weiter tragbar
bezeichnet werden. Der Ausfall eines Mitarbeiters könnte dazu führen, dass das gesamte CAFMSystem der HU zumindest für einen längeren Zeitraum nicht mehr nutzbar ist. Sollen mit dem
System wirklich wichtige Daten gepflegt und genutzt werden, ist hier eine andere Lösung anzustreben. Umgekehrt ist es für den verantwortlichen Mitarbeiter eine hohe Belastung, sich quasi „um
alles kümmern“ zu müssen. Die fehlende Möglichkeit sich auf einzelne Projekte konzentrieren zu
können und dabei ständig mit eher diffusen Anforderungen konfrontiert zu werden, kann hier zu
Frustrationen führen.
HIS-Vorschlag:
Festlegung von inhaltlichen Anforderungen an das CAFM-System und Systemprogrammierung
sollten entkoppelt werden. Anforderungen sollten ausschließlich von der Projektgruppe bzw. den
von dieser festgelegten Arbeitsgruppen formuliert werden. Die Umsetzung der Vorgaben sollte
dann anschließend in der Projektgruppe abgenommen bzw. im Rahmen einer Pilotanwendung
getestet werden. Technische Probleme bei der Umsetzung lassen sich in dieser Form rechtzeitig
erkennen und der Aufwand für die Realisierung lässt sich so m inimieren.
Für die eigentliche Systemprogrammierung besteht zum einen die Möglichkeit, eine zusätzliche
Arbeitskraft einzustellen oder alternativ die Zusammenarbeit mit einer externen Firma zu wählen.
Denkbar wäre auch eine Kooperation mit einer oder mehreren anderen Hochschulen, die das
CAFM-System ebenfalls einsetzen möchten.
In der folgenden Tabelle (Tab. 1) sind Kostenschätzungen für verschiedene Möglichkeiten getroffen worden. Berücksichtigt wurde dabei zum Vergleich auch der Einsatz eines kommerziellen
CAFM-Systems (die Informationen sind auf der Basis einer Preisliste der Fa. Agiplan-Technosoft,
Stand: Dezember 2000, zusammengestellt). Die Kosten sind jeweils für einen Zeitraum von fünf
Jahren zusammengefasst, um den Einfluss laufender Kosten gegenüber einmaliger Anschaffungskosten deutlicher herauszustellen. In diesem vereinfachten Beispiel sind Preis- und Gehaltssteigerungen nicht berücksichtigt worden.
21
5
Personalkosten
[EUR]
Variante a)
Zusätzliche Kraft
Mitarbeiter/in BAT IVa (O)
alternativ:
Mitarbeiter/in BAT IIa (O)
Variante b)
Externe Softwarefirma
60 Tage p. a.,
Tagessatz: 600 EUR
alternativ:
90 Tage p. a.,
Tagessatz: 600 EUR
Variante c)
Entwicklungskooperation mit
Hochschule
Student. Hilfskraft
Variante d)
Neubeschaffung eines
kommerziellen Systems
Hardware, Betriebssystem
(UNIX)
Software (Beispiel: 16-UserLizenz), Basissystem Einzelmodule, u. a. Flächen- u. Raumdaten, Auswertung, Instandhaltung,
Schlüsselverwaltung, Workflow,
Verträge, Dokumente, Datenbanklizenz
Beratungsleistung/Installation:
30 Tage, Tagessatz: 900 EUR
Schulung (1.000 EUR p. a. je
Mitarbeiter im ersten Jahr, danach jew. 2 Mitarbeiter p. a.)
Summe Neubeschaffung
Gesamtkosten inkl.
Gemeinkostenan6
teil etc. [EUR]
Kosten über 5 Jahre
(ohne Bereinigung)
[EUR]
42.690
53.363
266.814
51.212
64.014
320.072
36.000
entfällt
180.000
54.000
entfällt
270.000
7.500
9.375
46.875
Beschaffungskosten
[EUR]
Kosten p. a. für
Pflege
[EUR]
Kosten über 5 Jahre
[EUR]
50.000
2.000
60.000
105.000
12.000
165.000
27.000
27.000
16.000
2.000
26.000
198.000
16.000
278.000
Tab. 1: Kostenvergleich Weiterentwicklung DV-System
a) Einstellung einer zusätzlichen Kraft:
Diese Möglichkeit erscheint kostenmäßig – insbesondere wenn der hier betrachtete Zeitraum von
fünf Jahren zugrunde gelegt wird – als die ungünstigste Lösung (selbst unter der Voraussetzung,
dass der BAT-O mit einer mit IVa vergüteten Stelle Anwendung findet. Sogar eine Neubeschaffung
eines CAFM-Systems wäre in diesem Fall nur wenig teurer (allerdings setzen die Berechnungen
für die Neubeschaffung voraus, dass hierfür kein zusätzliches Personal für die Betreuung benötigt
wird). Nachteilig wirken sich insbesondere die laufenden Kosten aus, die unabhängig vom tatsächlichen Bedarf zu erbringen sind. Von Vorteil sind dagegen die flexiblen Möglichkeiten, die sich für
den Ausbau des CAFM-Systems ergeben. So kann weiterhin ohne Schwierigkeiten der bisherige
Ansatz verfolgt werden, standardisierte und frei verfügbare Softwarekomponenten einzusetzen.
5
6
Zugrunde gelegt wurden die für Sachsen gültigen Werte, die für das Jahr 2001 vorlagen. Enthalten sind Versorgungszuschlag (Sozialversicherung, Zusatzversicherung jeweils mit Arbeitgeberanteil) sowie Personalnebenkosten (z. B.
Beihilfe).
Der Zusatzkostenanteil bestehend aus Personalgemeinkos ten (Allgemeine Verwaltung, Leitung etc.) sowie Sachkosten
(Raumkosten, Geschäftsbedarf, Einrichtung etc.) wurden in Anlehnung an [3] mit 25 % angesetzt.
22
b) Beauftragung einer externen Software-Firma:
Die Weiterverfolgung des bisherigen Konzeptes wäre auch möglich, wenn eine externe Firma mit
der Anfertigung einzelner Programmteile bzw. Module beauftragt wird. Die Beauftragung erfolgt
also gemäß den konzeptionellen Überlegungen, die in der Projektgruppe angestellt werden unter
der Koordination des für das CAFM-System verantwortlichen Mitarbeiters. Die Beauftragung kann
im Rahmen eines Ausschreibungsverfahrens erfolgen. Dabei wäre zunächst die Ausschreibung
eines abgeschlossenen Moduls (z. B. Schlüsselverwaltung) sinnvoll, um damit Erfahrungen zu
sammeln. Für die Vergabe von Programmierleistungen sind eindeutige Schnittstellen zu definieren.
Die Dokumentation der eigenen und der Fremdleistungen müssen gewährleistet sein. Der programmierte Code sollte in das Eigentum der HU übergehen, um eine zu starke Abhängigkeit von
einem Anbieter zu vermeiden. Ein gewisser Aufwand für Abstimmung, Kontrolle bzw. Test und
Abnahme der Fremdleistungen (15 % des Fremdleistungsumfangs können hier zumindest bei den
ersten Aufträgen angesetzt werden) ist erforderlich. Der in der Tabelle zugrunde gelegte Tagessatz von 600 € entspricht dem, was beispielsweise im Internet für die Erstellung und Bearbeitung
von Web-Anwendungen angeboten wird. In der Tabelle sind zwei Varianten angegeben, die einen
Vergleich unterschiedlicher Auftragsumfänge ermöglichen. Der Eigenaufwand für die Betreuung
der Fremdleistungen wird hier nicht gesondert ausgewiesen, da davon ausgegangen wird, dass
dieser vom zuständigen Mitarbeiter im Zuge der Entlastung von anderen Tätigkeiten beigesteuert
werden kann. Ein Nachteil der Lösung besteht in der Schwierigkeit die Zusammenarbeit mit einer
Software-Firma zunächst zu beginnen (Auswahl einer geeigneten Firma, Definition der Schnittstellen, Dokumentation des CAFM-Systems). Der Aufwand zu Beginn der Zusammenarbeit ist ggf.
sehr hoch und lässt sich hier nicht hinreichend genau abschätzen.
c) Entwicklungskooperation mit anderen Hochschulen (s. a. 3.6):
Diese Lösung erscheint in der Tabelle als diejenige mit den geringsten Kosten. Vorausgesetzt wird
hier allenfalls der zusätzliche (dauerhafte) Aufwand für eine studentische Hilfskraft, die für hochschulspezifische Anpassungen des CAFM-Systems vorzusehen ist. Es wird ferner davon ausgegangen, dass an den betreffenden Hochschulen (hier kommen vor allem die Berliner Universitäten
in Frage) jeweils zumindest eine Person für die Entwicklung und Betreuung des CAFM-Systems
bereits zur Verfügung steht. Von Vorteil wäre dabei auch, wenn aus dem Bereich Forschung und
Lehre im Rahmen von Studien- und Diplomarbeiten Weiterentwicklungen des CAFM-Systems
durchgeführt werden könnten. Vorteilhaft ist diese Lösung insbesondere wegen der geringen Kosten und der Möglichkeit, hier ggf. auf das Wissen anderer Hochschulen zurückgreifen zu können.
Nachteilig ist der in der Regel langwierige Abstimmungsprozess, wenn die Belange mehrerer
Hochschulen berücksichtigt werden müssen.
d) Neubeschaffung eines CAFM-Systems:
Zu Vergleichszwecken ist in der Tabelle auch die Möglichkeit der Neubeschaffung eines CAFMSystems mit aufgeführt worden. Diese Lösung lässt jedoch nach dem derzeitigen Stand keine
Vorteile für die HU erkennen. Sie könnte allenfalls dann Kostenvorteile bringen, wenn eine Weiterentwicklung des derzeit eingesetzten CAFM-Systems mangels Personal ausscheiden würde. Ein
CAFM-Anbieter wäre in der Lage ein Komplettangebot bis hin zur vollständigen Ersterfassung von
Daten zu machen. Allerdings wären in solch einem Fall die Kosten wesentlich höher anzusetzen
als in der Tabelle angegeben.
Fazit:
HIS-seitig werden die Vorschläge b) und c) für geeignet gehalten. Die Möglichkeit der Kooperation
mit einer anderen Hochschule hätte neben dem Kostenvorteil für die HU auch einen geringeren
Kostenaufwand für die Partnerhochschule(n) zur Folge, was angesichts der derzeit angespannten
Haushaltslage in Berlin nicht unwichtig sein dürfte. Die Beauftragung eines externen SoftwareUnternehmens kommt dagegen dann in Frage, wenn eine Kooperation bei der SoftwareEntwicklung mit einer anderen Hochschule nicht möglich sein sollte. Diese Lösung bietet die
größte Flexibilität, da die notwendige Arbeitsleistung nach Bedarf eingekauft werden kann.
3.2.3
23
Zusammenarbeit und Informationsaustausch
Ist-Zustand:
Der Austausch von Informationen erfolgt mittlerweile vorwiegend per E-Mail. Die Zusammenarbeit
zwischen verschiedenen Abteilungen bzw. mit den Verwaltungsleitern der Fakultäten bzw. zentralen Einrichtungen erfolgte bisher überwiegend nur im Rahmen der jeweils zu bearbeitenden Aufgaben. Gemeinsame Abstimmungen z. B. in DV-technischen Fragen finden nicht statt.
Gewünscht wurde eine verbesserte Zusammenarbeit zwischen Studienabteilung und Technischer
Abteilung, um eine bessere Abstimmung der verfügbaren Raumkapazitäten mit der Zulassungszahl von Studierenden zu erreichen.
Bemängelt wurde, dass Informationen zum Teil nicht weitergegeben werden bzw. geschlossene
Informationskreisläufe fehlen.
HIS-Bewertung:
Die nahezu durchgängige Nutzung elektronischer Kommunikation (E-Mail) ist positiv zu werten.
Handlungsbedarf besteht bei der Abstimmung zwischen den Abteilungen bzw. Verwaltungsleitungen, auch im Hinblick auf einen effizienten Systemeinsatz.
HIS-Vorschlag:
Mit der neu geschaffenen Projektgruppe CAFM besteht nunmehr die Möglichkeit, die Bearbeitung
von Aufgaben und die Weiterentwicklung des CAFM-Systems frühzeitig abzustimmen. Bei Fortführung der Projektgruppe ist darauf zu achten, dass die verschiedenen Interessengruppen jeweils
vertreten sind bzw. die Möglichkeit erhalten, ihre Standpunkte jeweils zu vertreten. Die alleinige
Information über vorgesehene Entwicklungen reicht nicht aus.
3.2.4
Schulungen, Information über das System
Ist-Zustand:
In der Vergangenheit hat es vereinzelt Vorstellungen bzw. Vorführungen des CAFM-Systems
(auch außerhalb der Technischen Abteilung) gegeben. Seit Dezember 2001 wurde in kleineren
Gruppen eine Einweisung in das System „FM-Works“ für Interessenten (vorwiegend in der Technischen Abteilung) durchgeführt.
Häufig wurde von den Befragten beklagt, dass die Information über das CAFM-System in der Vergangenheit nicht ausreichend gewesen sei. Das CAFM-System wurde in einigen Fällen erst durch
Hinweise von außen (z. B. durch eine an der HU tätige externe Firma) bekannt. Es gab sogar einige Personen, die erst durch die Auftaktveranstaltung zum HIS-Projekt von der Existenz des Systems erfahren haben.
HIS-Bewertung:
In der Vergangenheit ist die Information über das CAFM-System außerhalb der Technischen Abteilung nicht ausreichend gewesen. Mittlerweile dürfte dieses Problem so nicht mehr bestehen.
Gleichwohl ist noch ein Bedarf an Information bzw. Schulung insbesondere in den Bereichen außerhalb der Technischen Abteilung festzustellen.
HIS-Vorschlag:
Informations- und Schulungsveranstaltungen sollten regelmäßig angeboten werden. Dabei könnten auch Hinweise zur effizienten Nutzung des CAFM-Systems (wo bzw. wie finde ich welche In formation am schnellsten?) vermittelt werden. Aktuelle Informationen über Neuerungen können so
einem breiteren Kreis zugänglich gemacht werden. Schulungen sollten auch speziell zum System
FM-Works angeboten werden. Die Häufigkeit, mit der solche Veranstaltungen stattfinden sollten,
24
hängt nicht zuletzt von der Weiterentwicklung des CAFM-Systems ab. Empfohlen wird aber etwa
halbjährig über den aktuellen Stand zu informieren.
3.3 Datenverwaltung
3.3.1
Datenerfassung und Datenpflege
Ist-Zustand:
Die Datenerfassung und Datenpflege wird zum Teil dezentral vorgenommen. Beispielsweise erfolgt die Eingabe der Flächendaten einmal im Jahr durch die Fakultäten (bzw. Institute) bzw. weitere Einrichtungen der Universität. Das Verfahren geht hier nicht über die direkte Dateneingabe in
das CAFM-System, sondern über den Weg eines Datenexports (in eine Excel-Datei), die z. B. den
Verwaltungsleitern zur Verfügung gestellt wird, dort bearbeitet und anschließend an den zuständigen Mitarbeiter im Referat Grundstücks- und Gebäudeverwaltung übermittelt wird, der die Daten
wieder in das System einpflegt.
Die Dateneingabe erfolgt derzeit zentral. Bau- und Liegenschaftsdaten werden von einem Mitarbeiter in das CAFM-System eingegeben. Die Verantwortung für die Richtigkeit der Informationen
liegt jeweils bei den zuständigen Personen (z. B. Verwaltungsleiter für Raum- und Gebäudedaten).
Buchungsdaten sowie Daten über angemietete und vermietete Objekte werden von den jeweils
zuständigen Mitarbeiterinnen und Mitarbeitern direkt in das System eingepflegt.
Für einige Bereiche gibt es keine gültigen Festlegungen hinsichtlich der Eingabe und Pflege von
Daten.
Die Qualität der Daten sowie die Organisation und Durchführung von Datenerfassung und Datenpflege wurden häufig bemängelt. Sofern exakte Angaben zu Raumdaten gewünscht werden, ist die
Besichtigung der Verhältnisse vor Ort üblich. Außerdem wurde die Zeit, bis zu der eine Korrektur
von als fehlerhaft gemeldeten Daten erfolgte, als zu lang empfunden. Auch der Ausfall einzelner
Mitarbeiterinnen und Mitarbeiter für einen längeren Zeitraum (durch Krankheit oder Urlaub) wird als
problematisch gesehen, da in einigen Fällen keine Vertretungsregelung festgelegt wurde.
HIS-Bewertung:
Der Hinweis auf die Qualität der Daten bzw. die nicht immer eindeutigen Regelungen hinsichtlich
der Datenerfassung und Datenpflege sind ernstzunehmende Kritikpunkte. In den Bereichen, in
denen ohnehin eine geringe Motivation zur Nutzung des CAFM-Systems vorhanden ist, führt dies
zu einem geringen Interesse an der Bereitstellung aktueller Daten, was wiederum – durch die damit verbundene Verschlechterung der Qualität der Datenbasis – zu einem weiteren Absinken des
Interesses am System führt.
Das gelegentlich genannte Argument, in den meisten Fällen sei eine Begehung vor Ort erforderlich, kann aus der Sicht von HIS nicht akzeptiert werden. Sollte dies zutreffen, so wäre der Nutzen
des CAFM-Systems insgesamt in Frage gestellt. Um das CAFM-System sinnvoll nutzen zu können, muss sich der Datenbestand in einem Zustand befinden, der Begehungen vor Ort nur noch in
besonderen Fällen notwendig macht.
Die derzeitige Vorgehensweise bei der Aktualisierung der Raum- und Gebäudedaten erscheint
umständlich. Die Korrektur bzw. Ergänzung der Raumbuchdaten lediglich einmal im Jahr (im
Rahmen der jährlichen Meldungen für die Hochschulstatistik) ist nicht ausreichend, wenn ein aktueller Datenbestand genutzt werden soll.
HIS-Vorschlag:
Datenerfassung und Datenpflege sollten von der Zuständigkeit her eindeutig geregelt sein.
25
Entsprechend dem an der HU verfolgten Konzept der Dezentralisierung, könnte die Dateneingabe
selbst durch die jeweils verantwortlichen Personen (dezentral) vorgenommen werden. Beispielsweise kommen hier die Verwaltungsleiter für die in ihrem Zuständigkeitsbereich liegenden Bauund Liegenschaftsdaten (Nutzungsänderungen, Raumausstattungsmerkmale), die Bauleiter
(Hochbau) für die hochbaulichen Merkmale (Flächen, bauliche Änderungen, Grundrisse), die zuständigen Personen für Gebäudereinigung (Reinigungsflächen, Glasflächen etc.) in Frage. Sollte
die Dateneingabe in einigen Bereichen nicht vorgenommen werden können (z. B. aus Kapazitätsgründen), sollte die Möglichkeit bestehen, die Daten zentral, durch die verantwortliche Stelle in der
Technischen Abteilung eingeben zu lassen. Ggf. muss hierfür gesondert Personalkapazität zur
Verfügung gestellt werden 7.
Im Zuständigkeitsbereich der Technischen Abteilung sollte mindestens eine Person (plus Vertretung) für die formal korrekte Datenaufnahme in das CAFM-System verantwortlich sein. Sofern dies
technisch realisierbar ist, käme eine Vorab-Überprüfung von geänderten Datensätzen in Frage,
bevor die endgültige Übernahme in die Datenbank bestätigt wird. Alternativ wäre auch die stichprobenartige Überprüfung der Daten möglich. Wichtig ist, dass sämtliche Inkonsistenzen sowie
fehlerhafte Daten von den Nutzern unmittelbar nachdem sie beobachtet wurden an diese Stelle
gemeldet werden.
Zu überprüfen ist auch, ob zunächst eine Vollerhebung der Daten durchgeführt werden soll, um
den Datenbestand zu aktualisieren. Zu beachten ist dabei allerdings der hohe Aufwand. Empfehlenswert ist daher eine bereichsweise Vorgehensweise (z. B. Beginn mit den Gebäuden, die unlängst saniert worden sind).
3.3.2
Datenzugriff
Ist-Zustand:
Technisch bietet das CAFM-System flexible Möglichkeiten, den Zugriff auf Daten auf bestimmte
Benutzer bzw. Benutzerkreise zu beschränken.
Bislang wurden keine Festlegungen hinsichtlich der Beschränkung der Zugriffsrechte getroffen.
Sofern nicht explizit (z. B. durch die zuständigen Mitarbeiterinnen und Mitarbeiter) Einschränkungen im Zugriff gewünscht wurden, wurden diese entweder von dem Systemverantwortlichen nach
eigenen Maßstäben festgelegt oder ohne Beschränkungen der Leserechte freigegeben.
Da das CAFM-System auch über das Internet zugänglich ist und ein großer Teil der Informationen
auch ohne beantragtes Passwort abgerufen werden kann, wurde häufiger der Wunsch geäußert,
den Zugriff von außen (d. h. außerhalb der HU) restriktiver zu handhaben. Vereinzelt wurde auch
gefordert, den Zugriff beispielsweise auf Flächendaten auf den jeweiligen Bereich (Fakultät) zu
beschränken und lediglich der Technischen Abteilung noch den Zugriff zu ermöglichen, um Begehrlichkeiten anderer Fakultäten nicht zu wecken. Letztere Forderung wurde vorwiegend von den
gut ausgestatteten Fakultäten erhoben.
HIS-Bewertung:
Die Festlegung von Zugriffsrechten ist nach Auskunft des zuständigen Mitarbeiters in sehr weitreichender Form möglich. Bisher sind jedoch nur relativ wenige Festlegungen getroffen worden. Dies
gilt auch für die Zusammenstellung von Berechtigungsgruppen.
HIS-Vorschlag:
Für jeden Themenschwerpunkt bzw. Aufgabenbereich sollten Festlegungen hinsichtlich der
Zugriffsmöglichkeiten auf die Daten getroffen werden. Dies kann unmittelbar bei der Formulierung
der Anforderungen geschehen. Denkbar wäre eine Abstufung von „allgemein zugänglich (lesen)“
7
Dies kann beispielsweise aus dem Personalüberhang der HU kurzfristig bewerkstelligt werden.
26
über „nur für HU-Angehörige zugänglich (lesen)“, „nur für bestimmte Gruppe, Personenkreis zugänglich (lesen)“ bis hin zu detailliert ausgeführten Schreibrechten. Ein Beispiel für die Einschränkung von Leserechten wäre z. B. die Schlüsselverwaltung (zur Vermeidung von missbräuchlichen
Verwendungen von Schlüsseln, sollen Informationen über die Zuordnung von Schlüsseln nicht
allgemein einsehbar sein).
3.3.3
Datenaustausch
Das vorhandene CAFM-System ermöglicht technisch den Export von Systemdaten in verschiedene Formate (u. a. HTML, CSV/Excel, ASCII, PDF, RTF, DXF).
Es wurde darauf geachtet, dass die vom CAFM-System verwendeten Schlüssel kompatibel zu den
Anforderungen von Statistischem Landes- und Bundesamt, Raumnutzungsarten nach DIN 277
sowie HIS-BAU bzw. ARGEBAU (Raumnutzungsarten) sind.
3.3.3.1 Datenaustausch innerhalb der Universität
Ist-Zustand:
Der Datenaustausch zwischen dem CAFM-System und anderen Systemen erfolgt entweder über
den Austausch von Excel-Dateien (z. B. bei der Aktualisierung der Bau- und Liegenschaftsdaten,
s. unter 3.4.9) oder in Papierform (Datenaustausch mit der Haushaltsabteilung, s. unter 3.4.1).
Außerdem werden Zählerstände (Energiezähler) und Umzugslisten in Papierform oder als Textbzw. Excel-Datei ausgetauscht. Reparaturmeldungen können direkt in ein Formular des CAFMSystems eingegeben werden. Durchgängig werden Kommunikationsmöglichkeiten per E-Mail genutzt (auch zum Austausch von Dokumenten bzw. Dateien). Die Datenpflege des ZIS wird jeweils
dezentral von den zuständigen Personen (z. B. Verwaltungsleiter) vorgenommen bzw. veranlasst
(s. 3.4.13).
Schnittstellen des CAFM-Systems zu den Programmen der Haushaltsabteilung oder zum ZIS wurden in der Befragung häufig genannt. Weitere Möglichkeiten, z. B. eine Verbindung zu HISCOB
wären für die Befragten denkbar.
HIS-Bewertung:
Bisher gab es von den Nutzern nur geringe Anforderungen zum Datenaustausch in der Universität.
Die Möglichkeit Informationen per E-Mail auszutauschen hat hier zunächst ausreichende Möglichkeiten geschaffen. Allerdings ist davon auszugehen, dass im Zuge des verstärkten Einsatzes des
CAFM-Systems in den Aufgabenbereichen auch die Anforderungen an den Austausch von Daten
steigen werden.
HIS-Vorschlag:
Lösungen für die verschiedenen Aufgabenbereiche sind bereits unter 3.4 beschrieben. Ein Großteil
des erforderlichen Datenaustausches ist bei einer Integration der betreffenden Aufgaben in das
CAFM-System nicht mehr gesondert zu betrachten. Ergänzend soll hier auf die Möglichkeit der
Schaffung sicherer Verbindungen in Form von entsprechenden Übertragungsstrukturen (VPN)
sowie mit Hilfe von Verschlüsselungsverfahren (z. B. SSL) hingewiesen werden. Diese Verfahren
bieten sich insbesondere bei sensiblen Anwendungen (z. B. Übertragung von Haushaltsdaten) an.
3.3.3.2 Datenaustausch mit externen Einrichtungen
Ist-Zustand:
Liegenschaftsdaten werden mit dem Senat für Wissenschaft und Forschung ausgetauscht, Rahmenplanstatistikdaten mit dem Statistischen Landesamt Berlin. Die Daten werden jeweils einmal
im Jahr zur Verfügung gestellt. Die Generierung ist unproblematisch.
27
Dokumentationsdaten (CAD- und Raumbuchdaten) werden mit Fremdfirmen der verschiedenen
Gewerke ausgetauscht (Bau, Planung, Sicherheitstechnik, Brandschutz, Technische Anlagen etc.).
Die Integration dieser Daten in das CAFM-System ist bisher gar nicht bzw. nur ansatzweise realisiert.
Anforderungen ergeben sich hier vorwiegend aus dem Austausch von CAD-Daten mit externen
Planern.
HIS-Bewertung:
Der Austausch alphanumerischer Daten verläuft offenbar ohne Probleme. Für den Austausch von
CAD-Daten ist insbesondere im Hinblick auf die anstehenden Neubau- und Sanierungsmaßnahmen eine geeignete Lösung zu finden.
Vorschlag:
Für den Austausch von CAD-Daten mit externen Planungsbüros etc. sind Vorgaben für die HU zu
formulieren, die folgende Informationen enthalten müssen:
§
§
§
§
Austauschformat (z. B. DWG oder DXF),
Layerstruktur (einheitliche Festlegung von Layernamen und zugehöriger Darstellung – z. B.
Grundriss, Bemaßung etc.),
ggf. die farbliche Zuordnung,
zusätzlich zu übergebenden Daten (z. B. Raumnummern, Flächen etc.) sowie das dazu erforderliche Format (Dateiformat, Feldnamen, Feldattribute).
3.4 Abbildung von Einzelaufgaben im System
Die Reihenfolge der Darstellung der Einzelaufgaben entspricht der Vorgehensweise bei der Festlegung der Arbeitsgruppen wie sie auch im Zeitplan im Anhang wiederzufinden ist.
3.4.1
Haushaltsdaten
Ist-Zustand:
Die Erfassung der notwendigen Daten erfolgt in der Haushaltsabteilung unter Verwendung von
HIS-DV-Systemen (zur Zeit HISMBS). Fakultäten und die Technische Abteilung haben keinen direkten Zugriff auf die Daten der Haushaltsabteilung. Dezentral werden z. T. eigene Systeme zur
Erfassung von Haushaltsdaten genutzt, um den aktuellen Umfang der jeweiligen Haushaltstitel
kontrollieren zu können. Zum Einsatz kommen dabei HISMBS (PC-Version), eigene Systeme (auf
der Basis von MS-Excel, MS-Access) sowie das Titelprogramm als Teil des CAFM-Systems der
Technischen Abteilung.
Beispielhaft soll hier die Bearbeitung von Rechnungsdaten im zuständigen Referat der Technischen Abteilung dargestellt werden:
§
§
§
§
§
Zunächst erfolgt die Eingabe der Rechnungsdaten in ein Word-Dokument (Formular),
das anschließend (auf gelbem Papier) ausgedruckt
und danach per Hauspost an die Haushaltsabteilung geschickt wird,
wo die Daten anschließend in HISMBS eingegeben werden.
Zusätzlich werden die Daten in das CAFM-System eingegeben, um jeweils tagesaktuelle Informationen über die verausgabten bzw. die noch verfügbaren Mittel abrufen zu können.
Bei der Verbuchung einer Einnahme wird analog vorgegangen – es existiert hierfür ebenfalls eine
Vorlage für eine Auszahlungsanordnung, die zur Unterscheidung auf rosa Papier ausgedruckt
wird.
28
Ein direkter Zugriff auf HISMBS scheidet bisher aus Sicherheitsgründen aus, da aufgrund einer
fehlenden durchgängigen Intranet-Struktur an der HU der Zugriff über das Internet erfolgen müsste. Von der Haushaltsabteilung werden in regelmäßigen Abständen (ca. einmal monatlich) Kontrolllisten ausgedruckt, aus denen sämtliche Buchungspositionen ersichtlich sind. Diese Listen
werden dann an die jeweiligen Bereiche (Abteilungen, Fakultäten, sonstige Einrichtungen) verschickt. In der Technischen Abteilung werden diese Listen anschließend mit den Einträgen im
CAFM-System verglichen und die in der dortigen Titelverwaltung vergebenen Buchungsnummern
von Hand in die Kontrollliste eingetragen (die Buchungsnummern des MBS-Systems der Haushaltsabteilung und des CAFM-Systems sind nicht identisch).
Im Rahmen des Projekts DZUG gibt es Aktivitäten an der HU, die darauf abzielen, einen sicheren
Zugriff auf das MBS-System auch über das Internet zu ermöglichen. Mit Ergebnissen ist hier ab
Anfang 2003 zu rechnen. Beteiligt sind u. a. das Rechenzentrum und die Haushaltsabteilung.
Nach den vorliegenden Informationen soll an der HU das System HISFSV eingeführt werden. Der
Probebetrieb wurde (u. a. in der Juristischen Fakultät) bereits begonnen. HIS-seitig wird davon
ausgegangen, dass ein Vollbetrieb des Moduls „MBS“ von HISFSV frühestens Mitte 2003 an der
HU erreicht werden kann. HISMBS bietet in seiner jetzigen Form eine Import-Schnittstelle, deren
Spezifikation bei HIS abgefragt werden kann. Eine Export-Schnittstelle ist nicht realisiert. Sie
könnte jedoch im Rahmen der FSV-Realisierung entwickelt werden. Möglich wäre auch ein direkter
Zugriff auf die Datenbank des HIS-Systems.
Das CAFM-System wäre nach Auskunft des Entwicklers auch in der Lage, eigene Funktionen der
Bewirtschaftung (Mittelbewirtschaftung, Kosten-/Leistungsrechnung) zur Verfügung zu stellen.
Derzeit werden die Rechnungsdaten erfasst, um diese jeweils aktuell verfügbar zu haben.
Gewünscht wird eine Verbindung bzw. die Möglichkeit des Datenaustausches zwischen CAFMSystem und Haushaltsabteilung. Insbesondere wird der derzeitige Austausch von Daten als umständlich bezeichnet. Bei der Datenhaltung im CAFM-System ist außerdem eine Trennung bestimmter Positionen (z. B. Gebäudeversicherungen und Steuern) nicht möglich. Diese Trennung
wird jedoch benötigt. Weiterhin wurde die Realisierung einer Kostenkontrolle sowie eine Fortschreibung der Kosten nach Kostenarten angeregt.
HIS-Bewertung:
Die derzeitige Doppelerfassung nahezu identischer Daten ist unbefriedigend, da sie erhebliche
Arbeitszeit der Mitarbeiterinnen und Mitarbeiter bindet. Die Bemühungen des Rechenzentrums
eine befriedigende Lösung für den Zugriff auf die Haushaltsdaten zu schaffen, könnte hier Abhilfe
schaffen.
HIS-Vorschlag:
Da sowohl die Einführung von HIS-FSV als auch die Möglichkeit direkt auf die Daten der Haushaltsabteilung zuzugreifen nicht vor 2003 realisierbar sein dürften, sollte zunächst eine Zwischenlösung gefunden werden:
§
§
Übermittlung der Buchungsdaten an die Haushaltsabteilung in einer für das derzeit verwendete System HISMBS lesbaren Form entweder direkt auf einem Datenträger (Diskette) oder
verschlüsselt per E-Mail.
Übergabe der HISMBS-Buchungsnummer, sobald die Eingabe in HISMBS erfolgt ist. Um eine
möglichst einfache Übergabe zu gewährleisten, könnte eine eindeutige Kennzeichnung eines
jeden Datensatzes mit Hilfe eines Datums und einer fortlaufenden Nummer erfolgen (oder es
wird die bereits jetzt im CAFM-System erzeugte Nummer gewählt). Die Rückgabe der MBSBuchungsnummer kann dann einfach per Text-Datei (per E-Mail) in Form einer Tabelle mit
den Nummernzuordnungen erfolgen. Eine gesicherte Übertragung dieser Daten ist nicht erforderlich.
§
29
Die MBS-Buchungsnummer wird im CAFM-System zum jeweils zugehörigen Datensatz erfasst. Dies könnte auch automatisiert geschehen, wenn die Text-Datei mit der Zuordnung der
Buchungsnummern ausgelesen wird.
Sofern ein direkter Zugriff auf HISFSV realisiert werden kann, stellt sich jedoch die Frage, ob dann
die vorhandenen dezentral eingesetzten Systeme noch weiter gepflegt werden sollten. Für das
CAFM-System würde dies bedeuten, dass dann die Nutzung des vorhandenen Moduls Titelverwaltung in der jetzigen Form in Frage zu stellen ist. Grundsätzlich ist jedoch damit zu rechnen,
dass weiterhin Kostendaten im CAFM-System erfasst werden, da die Ansätze und Zielsetzungen
der Systeme zur Mittelbewirtschaftung und des CAFM-Systems andere sind. Während bei HISFSV
die korrekte Verbuchung und Abwicklung von Zahlungen im Vordergrund steht, ist die Aufgabe des
CAFM-Systems stärker in der Zuordnung von Kosten flächen- bzw. gebäudebezogen verortet.
Eine doppelte Erfassung von Buchungs- und Kostendaten kann durch die Realisierung geeigneter
Schnittstellen zwischen den Systemen vermieden werden.
3.4.2
Verträge
Ist-Zustand:
Im CAFM-System sind ausgewählte Mietverträge und Übersichten zu HOAI-Verträgen abrufbar
(als Dokument hinterlegt). Informationen aus einigen Verträgen mit Fremdfirmen sind außerdem
auch in der Datenbank abgelegt. Die Verträge bzw. Vertragsdaten können mit einer entsprechenden Berechtigung eingesehen werden. Abb. 4 zeigt eine Übersicht von Musterformularen, die im
System abrufbar sind.
Abb. 4:
Abruf von Vertragsformularen (Vorlagen)
30
Es wurde der Wunsch nach Mustermietverträgen sowie nach einer Möglichkeit zur Verwaltung von
Vertragsdaten geäußert. Die Vertragsdaten sollten für alle einsehbar sein. Allerdings stößt die
Möglichkeit zur Einsicht in die Vertragsdaten an Grenzen, da es Vertragswerke mit besonderen
Vereinbarungen gibt (z. B. bestimmte Mietverträge), die nicht allgemein zugänglich sein dürfen.
HIS-Bewertung:
Die Anforderung Mustermietverträge in das CAFM-System einzustellen ist ohne größeren Aufwand
zu realisieren (zum Teil ist diese Möglichkeit bereits vorhanden). Die Verwaltung von Vertragsdaten in der Datenbank ist dagegen aufwändiger. Diese Anforderung ist jedoch zeitlich von geringer
Priorität.
HIS-Vorschlag:
Da es sich hier um Aufgaben handelt, die zur Zeit mit geringer Priorität betrachtet werden können,
kann die Bearbeitung auf einen späteren Zeitpunkt (ab Ende 2002) verschoben werden. Das Einstellen von Dokumenten als Vorlagen ließe sich bei Bedarf kurzfristig ermöglichen (vgl. Dokumentenmanagement).
3.4.3
Ausschreibung, Vergabe, Abrechnung (AVA)
Ist-Zustand:
Im Zuständigkeitsbereich des Hochbaureferats wird das Programm WinAVA der Firma Sidoun
(www.sidoun.de) in einer nicht netzwerkfähigen Einzelplatz-Version eingesetzt. Die Beschaffung
einer neueren Software (entweder ein Update der vorhandenen Software oder ein anderes Programm) ist vorgesehen.
Eine Einbindung aller für den AVA-Aufgabenbereich benötigten Daten in das CAFM-System wird
seitens der Hochbauleiter nicht für nötig erachtet. Hier bestehen zum Teil sehr spezielle Anforderungen, die ausschließlich die Bauleitungen betreffen. Als sinnvoll wird die Möglichkeit erachtet,
Verknüpfungen zu Dateien, die mit dem Programm WinAVA erstellt worden sind (zum Beispiel
Leistungsverzeichnisse) einzelnen Gebäuden oder Räumen zuordnen zu können (vgl. Dokumentenmanagement). Zu den genannten spezifischen Anforderungen zählen eine Baudatenbank für
Kalkulation und Ausschreibung sowie die Verfügbarkeit von Baudaten im System. Die Übernahme
von Daten (Leistungsverzeichnisse) aus dem AVA-System in das Dokumentenmanagement soll
mit einer GAEB-Schnittstelle realisiert werden.
HIS-Bewertung:
Der hohe Grad an Eigenverantwortlichkeit, mit dem die HU Baumaßnahmen in Eigenverantwortung ohne Beteiligung der Bauverwaltung durchführen kann, erfordert eine fachliche bauliche
Betreuung, wie Sie dort durch die Bauleiter gegeben ist. Der gesamte Komplex von Ausschreibung, Vergabe und Abrechnung zählt üblicherweise nicht zu den Aufgaben, die seitens eines
CAFM-Systems abgedeckt werden. Gleichwohl ist die Verwendung von Daten aus dem CAFMSystem (z. B. Flächen und Raummaße) erforderlich.
HIS-Vorschlag:
Eine spezielle Kopplung zwischen den Systemen erscheint unter den derzeitigen Bedingungen
wenig sinnvoll, da der Aufwand in keinem Verhältnis zum Nutzen steht. Die innerhalb der CAFMProjektgruppe befürwortete Lösung, eine Verknüpfung von WinAVA-Dateien mit dem CAFMSystem auf der Gebäude bzw. Raumebene zu ermöglichen (ggf. über die GAEB-Schnittstelle)
kann als ausreichend angesehen werden. Allerdings ist zu beachten, dass allein der Zugriff auf
Daten bisheriger Ausschreibungsverfahren nicht ausreicht. Insbesondere wenn diese älteren Datums sind kann durch mittlerweile durchgeführte weitere bauliche Änderungen deren Brauchbarkeit
eingeschränkt sein. Es wäre daher sinnvoll, ggf. ein zusätzliches Feld vorzusehen, dass auf solche
Veränderungen verweist (Datum und Art der Maßnahme). Sofern die AusschreibungsinformatioCAFM-System der Humboldt-Universität zu Berlin
31
nen älter sind als die letzte Baumaßnahme ist eine Überprüfung der Verhältnisse vor Ort erforderlich.
3.4.4
Energie- und Medienverbrauchsdaten
Ist-Zustand:
In der Vergangenheit hat es bereits Aktivitäten zur Erfassung von Daten zum Energieverbrauch
gegeben. Aus Abb. 5 ist ersichtlich, dass u. a. Dokumente mit Kosten- und Verbrauchsdaten bis
1999 abrufbar sind. Auch eine Maske zur Erfassung der Einspeisepunkte wurde entwickelt. Die
Daten wurden später jedoch nicht weiter gepflegt. Der Austausch von Daten mit dem GLT-System
der HU ist bereits angedacht worden. Für die kostenbezogene Auswertung der Zählerdaten ist das
Referat Grundstücks- und Gebäudeverwaltung zuständig. Ein großer Teil der Stromzähler wird
direkt von den zuständigen EVU abgelesen. Hochschuleigene Zähler für Strom und Wärme spielen
derzeit noch eine untergeordnete Rolle.
Abb. 5: Inhalte des CAFM-Systems zu Energie- und Medienverbrauchsdaten
Vom Referat Betriebstechnik wird die Ausschreibung eines Energie-Benchmarkings für die HU
vorbereitet. Darin enthalten ist die Bewertung des vorhandenen Gebäude- und Anlagenbestands
unter energetischen Gesichtspunkten sowie die Erarbeitung von Vorschlägen zum effizienteren
Energieeinsatz.
32
Energie- und Medienverbrauchsdaten sollten grundsätzlich im CAFM-System zur Verfügung gestellt werden. Viele Zähler für Strom, Wärme, Wasser und Gas werden derzeit noch „von Hand
abgelesen“. Der Aufwand für die Erfassung dieser Daten ist in einigen Gebäuden hoch.
HIS-Bewertung:
Ein CAFM-System bietet weitreichende Möglichkeiten, Aufgaben im Bereich Energiemanagement
sowie bei der Erfassung von Energie- und Medienverbräuchen zu übernehmen. Während die zahlenmäßige Erfassung von Verbrauchsdaten vornehmlich durch ein geeignetes Gebäudeautomations-System erfolgt, kann das CAFM-System die weitere Auswertung und kostenmäßige Zuordnung der Daten zu Nutzern und Gebäuden übernehmen. In der HU sind diese Möglichkeiten bisher
nur ansatzweise realisiert.
Abgesehen von den in Abb. 5 dargestellten Punkten, hat es im Referat Betriebstechnik hierzu keine weiteren Aktivitäten gegeben.
HIS-Vorschlag:
Die Erfassung und Auswertung der Zählerdaten sowie die kostenmäßige Erfassung der Energieund Medienverbräuche erscheint wichtig. Im Rahmen der Beauftragung des Energiebenchmarkings darf erwartet werden, dass zumindest die Erfassung der Energiedaten thematisiert wird. Es
wird vorgeschlagen diesen Punkt weiter zu verfolgen. Das Referat Betriebstechnik sollte hier verstärkt tätig werden, um eine Verbesserung der derzeitigen Situation zu erreichen. Eine Möglichkeit
des Datenaustausches (Zählerdaten) zwischen den Gebäudeautomationssystemen und dem
CAFM-System der HU sollte hierzu realisiert werden. Die Realisierung kann aufgrund der derzeitigen Situation (geringe Anzahl eigener Zähler, Ablesung eines großen Teils der Stromzähler durch
das zuständige EVU) zu einem späteren Zeitpunkt erfolgen.
3.4.5
Anlagenstammdaten/Störungsannahme/Instandhaltung
Ist-Zustand:
Bisher wurde keine DV-gestützte Erfassung von Anlagenstammdaten durchgeführt. Seitens des
Referats Betriebstechnik gab es bisher keine entsprechenden Anforderungen. Daten sind jedoch –
allerdings nicht vollständig – auf Karteikarten gesammelt bzw. liegen in Form von Excel-Dateien
vor. Sie werden vom Umfang her derzeit als ausreichend angesehen. Aufgaben im Instandhaltungs- und Störungsmanagement wurden begonnen, indem z. B. Wartungszyklen im CAFMSystem hinterlegt worden sind, die Informationen wurden dann aber nicht mehr genutzt. Instandhaltungsinformationen zu ausgewählten Anlagen sind als PDF-Dokumente abgelegt (vgl. Abb. 6).
Die Dokumente sind unter einem gesonderten Menüpunkt „Wartungs- und Instandhaltungszyklen
abrufbar“. Eine Verknüpfung mit Gebäuden (oder Anlagen) besteht nicht. Die bestehende Möglichkeit Störungsmeldungen in ein Web-Formular einzutragen und an die zuständige Stelle weiterzuleiten wird sehr positiv bewertet.
Die Möglichkeit Prüftermine zu verwalten ist im CAFM-System vorgesehen, die Daten wurden zunächst auch erfasst, später jedoch nicht mehr weitergepflegt.
Kritisch wird die Arbeit der zentralen Störungsannahme bzw. Störmeldestelle bewertet (war zum
Teil noch nicht bekannt). Gewünscht wird hier eine Rückmeldung über den Stand der Bearbeitung
(insbesondere wenn Handwerker beauftragt worden sind) von Störmeldungen bzw. Reparaturen.
Seitens der Betriebstechnik wird die Wichtigkeit der Unterstützung durch das CAFM-System eher
niedrig angesetzt („hochbauliche Daten sind wichtiger als die Daten der Betriebstechnik“). Allerdings wurde auch ein hoher Sanierungsbedarf bei der technischen Ausstattung angeführt und der
Wunsch die Anlagenstammdaten zu vervollständigen. Der Wunsch nach einem einfachen Instandhaltungssystem wurde ebenfalls geäußert.
33
Abb. 6: Auszug aus einem Wartungsplan der Humboldt-Universität (PDF-Dokument)
HIS-Bewertung:
Vom Referat Betriebstechnik kamen nur wenige Wünsche im Hinblick auf eine Unterstützung
durch das CAFM-System oder andere DV-Programme. Es entstand der Eindruck, dass hier eher
Nachteile durch den DV-Einsatz gesehen werden, da damit zunächst ein höherer Aufwand (Einarbeitung, Datenerfassung) verbunden ist. Die ansatzweise Vorhaltung von Wartungsplänen im
CAFM-System zeigt jedoch, dass auch in der Betriebstechnik ein Bedarf vorhanden ist.
HIS-Vorschlag:
Lösungen zur Unterstützung der Aufgabenbereiche Anlagenstammdaten, Instandhaltung und Störungsannahme durch das CAFM-System sollten entwickelt bzw. weiter verfolgt werden. Vorab ist
allerdings im Referat Betriebstechnik zu klären, für welche Bereiche ein Bedarf besteht. Vorstellbar
wäre die DV-gestützte Erstellung einer Anlagenkartei sowie die Unterstützung bei der Planung von
Instandhaltungsmaßnahmen (z. B. durch die Realisierung einer Kalender- und Workflow-Funktion
für geplante, wiederkehrende und zustandsabhängige Instandhaltungsmaßnahmen sowie für Prüfungen).
3.4.6
Zutrittskontrolle/Schlüsselverwaltung
Ist-Zustand:
An der HU gibt es eine Vielzahl unterschiedlicher Schlüsselsysteme. Die Schlüsselverwaltung ist
nicht einheitlich geregelt. In den Gebäuden werden Informationen zu Schlüsseln jeweils von den
zuständigen Personen (in der Regel Pförtner bzw. Hausmeister) meist auf Karteikarten archiviert.
Im Zuständigkeitsbereich des Rechenzentrums wird seit etwa 10 Jahren eine spezielle Software
für die Schlüsselverwaltung und Zutrittskontrolle eingesetzt. Das Zutrittskontrollsystem basiert auf
Chipkarten. Bedingt durch den Umzug von Teilen des Rechenzentrums an den Standort Adlershof
34
wird hier vermutlich ein neues System zum Einsatz kommen. An der HU gibt es eine spezielle Arbeitsgruppe, die sich mit der Weiterentwicklung der Zutrittskontrolle befasst.
Die Integration einer Schlüsselverwaltung in das CAFM-System wurde mehrfach als Wunsch geäußert. In Betracht gezogen wurden aber auch andere Möglichkeiten (z. B. Einführung von Einzellösungen). Gewünscht wurde auch die Möglichkeit, Zugriff auf aktuelle Informationen zu
Schlüsseldiensten und Wachschutz zu erhalten.
HIS-Bewertung:
Der Bereich ist nur für einen kleineren Teil der Beschäftigten an der HU von Interesse. Dort ist allerdings der Wunsch nach einer geeigneten DV-Lösung groß (Beispiele: Zutrittskontrolle und
Schlüsselverwaltung im Rechenzentrum sowie im Museum für Naturkunde). In vielen Gebäuden
erfolgt die Verwaltung der Schlüssel dezentral durch die Pförtner bzw. Hausmeister. Inwieweit hier
Übersichten über vorhandene, ausgegebene oder verlorene Schlüssel bestehen, wurde nicht im
Detail untersucht. Es ist jedoch davon auszugehen, dass hier Defizite bestehen.
HIS-Vorschlag:
Die Erfassung der Daten von Schließanlagen sollte zukünftig im CAFM-System erfolgen, da es
bisher keine geeigneten anderweitigen Übersichten gibt. Bereits beim Verlust eines Schlüssels
kann es zu einem erhöhtem Arbeitsaufwand kommen, wenn z. B. Mehrfachschließungen betroffen
sind und keine Daten über Schließungen und ausgegebene Schlüssel verfügbar sind.
Die zu erfassenden Daten sollten im Detail in der zuständigen CAFM-Arbeitsgruppe festgelegt
werden. In Frage kommen die Namen der Schlüsselinhaber, Aus- und Rückgabedaten von
Schlüsseln, Schlüsselanzahl, verlorengegangene Schlüssel und Schließdaten (Schlüsselnummern,
Schließhierarchie, Typenbezeichnung etc.). Die Datenerfassung kann auch ohne Probleme auf
Zutrittskontrollsysteme auf Chipkartenbasis o. ä. angewendet werden. Die weitergehende Integration eines Zutrittskontrollsystems in das CAFM-System sollte dagegen zurückgestellt und mit der
Arbeitsgruppe zu Zutrittskontrollsystemen abgestimmt werden, da der Bedarf hier als eher gering
einzustufen ist.
Bei der Realisierung einer Schlüsselverwaltung ist zu beachten, dass die darin erfassten Informationen aus Sicherheitsgründen nicht allgemein zugänglich sein dürfen.
3.4.7
Dokumentenmanagement
Ist-Zustand:
Funktionen eines Dokumentenmanagements werden z. T. im CAFM-System genutzt, z. B. in Form
von Zuordnung und Verwaltung von Notrufplänen o. ä. zu bestimmten Objekten (Räume, Gebäude
etc.). Eine direkte Verknüpfung von Dokumenten, z. B. mit Gebäuden oder Räumen, besteht nicht.
Teilweise sind die Dokumente in den zugehörigen Kategorien (z. B. Technisches Gebäudemanagement) abgelegt, teilweise sind sie nach Klassen sortiert (z. B. Verträge, Service-Unterlagen etc.)
verfügbar (s. a. Abb. 7).
In der Projektgruppe wurde für einige Anwendungen, zu denen Informationen als Datei verfügbar
sind (Textdokumente, CAD-Pläne – s. hierzu 3.4.9, Ausschreibungsunterlagen etc.), vorgeschlagen, diese in ein Dokumentenmanagement zu integrieren. Das betrifft vor allem solche Anwendungen, bei denen eine Erfassung der Daten in einer Datenbank aufgrund des erheblichen Aufwands nicht bzw. erst zu einem späteren Zeitpunkt vorgesehen ist (s. a. 3.4.2 und 3.4.3).
35
Abb. 7: Beispiel für die Dokumentenverwaltung im CAFM-System
HIS-Bewertung:
Der schnelle Zugriff auf aktuelle Dokumente ist eine wichtige Grundlage für effizientes Arbeiten.
Beispielsweise kann es bei der Auswahl von Gebäuden oder Räumen sinnvoll sein, auf Verträge
(Mietverträge, Gebäudereinigung), Ausschreibungsunterlagen, Pläne, Fotos etc. zuzugreifen. Die
im Rahmen des vorhandenen CAFM-Systems zur Verfügung gestellten Dokumente stellen bereits
eine Hilfe dar, allerdings ist die Ablage der Dokumente nicht einheitlich geregelt.
HIS-Vorschlag:
Das Dokumentenmanagement sollte weiter ausgebaut werden. Damit ergibt sich die Möglichkeit,
Informationen in DV-lesbarer Form aufzubereiten und so abzulegen, dass ein schnelles Auffinden
ermöglicht wird. Der bereits bestehende Zugriff auf Formulare und Vertragsmuster kann erweitert
werden. Geeignete Verknüpfungen in Form von Querverweisen (Links), z. B. von einem Raum auf
die zugehörigen Verträge, Ausschreibungsunterlagen etc. ermöglichen eine schnelle Bearbeitung
insbesondere von häufig auftretenden Fragestellungen.
In das Dokumentenmanagement sollte auch die Verwaltung von CAD-Plänen mit aufgenommen
werden, da häufig der Wunsch nach genauen (bemaßten) Grundrissen geäußert wurde (nur Lesezugriff erforderlich).
3.4.8
Umzüge
Ist-Zustand:
Nutzerwechsel und Flächennutzungsänderungen treten an der HU derzeit häufig auf. Im Rahmen
der Erweiterung des Ausbaus des Standorts Adlershof ist in den nächsten Jahren verstärkt mit
36
weiteren Umzügen zu rechnen. Die Verantwortlichkeit für die Durchführung größerer Umzüge liegt
bei einem Mitarbeiter der Technischen Abteilung. Instituts- bzw. gebäudeinterne Umzüge werden
häufig in Eigenregie der Mitarbeiterinnen und Mitarbeiter durchgeführt. Die Unterstützung von Umzügen ist im CAFM-System bisher nicht realisiert. Lediglich ein Hinweis auf die zuständige Person
ist vorhanden. Die Raumausstattung mit beweglichen Sachen (Mobiliar) wurde bisher nicht zentral
erfasst. Die Erfassung fällt in den Zuständigkeitsbereich der Fakultäten. Mitteilungen an die bei
einem Umzug betroffenen Stellen (Telefonzentrale, Gebäudereinigung etc.) erfolgen entweder
durch den Umziehenden selbst oder zu einem geringen Teil durch die für den Umzug verantwortliche Stelle (bei gebäudeübergreifenden Umzügen).
Die Unterstützung bei der Umzugsplanung könnte darin bestehen, für einen ausgewählten Raum
eine Liste aller bei einem Umzug durchzuführenden Arbeiten und Maßnahmen zu erhalten. Wünschenswert wäre außerdem Unterstützung bei den im Rahmen eines Umzugs erforderlichen Maßnahmen (z. B. Benachrichtigungen).
HIS-Bewertung:
Die Anforderungen an der HU in Bezug auf ein Umzugsmanagement sind bislang eher gering. Die
im CAFM-System derzeit vorhandenen Informationen sind allerdings nicht ausreichend, um im
Vorfeld einer Umzugsmaßnahme feststellen zu können, ob ein Raum für die vorgesehene Anzahl
von Mitarbeitern geeignet ist und ob das vorhandene Mobiliar in den neuen Räumlichkeiten untergebracht werden kann. Auch fehlen Daten zur Raumausstattung. Nachteilig ist, dass es keine Unterstützung z. B. in Form eines automatischen Benachrichtigungssystems gibt, das nach einer
Umzugsmaßnahme Informationen an zuständige bzw. betroffene Stellen in der Verwaltung weitergibt.
HIS-Vorschlag:
In dem Diagramm in Abb. 8 wird beispielhaft aufgezeigt, wie die Bereitstellung von Informationen,
die bei einer Umzugsmaßnahme erforderlich ist, organisiert werden könnte.
In der Projektgruppe wurde festgelegt, dass ein Meldeformular für Umzüge entworfen wird, in das
die benötigten Informationen für die beteiligten Stellen eingetragen werden. Das Formular wird bei
einem Umzug per E-Mail (ggf. automatisch mit Unterstützung des CAFM-Systems) an die zuständigen Stellen verschickt.
Abb. 8: Beispiel für Arbeitsablauf „Umzug“
3.4.9
37
Bau- und Liegenschaftsdaten
Ist-Zustand:
Derzeit sind etwa 18.000 Räume im CAFM-System erfasst. Der Umfang der raum- und gebäudebezogenen Daten ist in Abb. 9 und Abb. 11 auszugsweise dargestellt. Für einen Teil der Gebäude
sind auch CAD-Grundrisse (Geschossansichten) verfügbar (Abb. 10). Die Ansichten basieren auf
vereinfachten Darstellungen der Grundrisse (nicht exakt maßstäblich, keine Darstellung von Wänden), die beim Laden dynamisch mit den jeweils ausgewählten Informationen aufgebaut werden
(z. B. Flächenangaben und nutzerbezogene Markierung der Flächen). Über die Auswahl des Menüpunktes „Archiv“ (s. Abb. 9) besteht bei einigen Gebäuden auch die Möglichkeit direkt auf digitalisierte CAD-Pläne zuzugreifen. Die Pläne sind in verschiedenen Formaten abgelegt (Autocad –
DWG, Microstation – DGN, CAD-Austauschformat – DXF). Zum Teil sind auch nur gescannte Pläne vorhanden. Zugriff besteht bei einigen Gebäuden auch auf Text-Dokumente (z. B. Vertragsunterlagen, Notizen) und Fotos.
In einer Arbeitsgruppe der HU wurde bereits vor Beginn des HIS-Projektes ein Musterblatt für die
Erfassung von Raum- und Gebäudedaten erstellt (s. Anhang: Musterentwurf Raumbuch). Eine
Datenerfassung gemäß den im Musterraumbuch enthaltenen Vorgaben ist bisher jedoch noch
nicht durchgeführt worden. Im Musterentwurf sind auch Hinweise auf das jeweils für die Datenpflege verantwortliche Referat enthalten.
Abb. 9:
Raumbuch (Übersicht) der Humboldt-Universität (Beispiel Hauptgebäude)
Die im CAFM-System gesammelten Daten über Flächen und Nutzung werden einmal im Jahr aktualisiert (im Rahmen der erforderlichen Meldung der Hochschulflächendaten an das Landesamt
für Statistik). Die Fakultäten und sonstigen betroffenen Verwaltungsbereiche erhalten hierzu jeweils eine Excel-Datei (in der Regel per E-Mail) zugesandt, in der sich die aktuellen Flächendaten
befinden. Diese Datei wird dann jeweils von den zuständigen Verwaltungsleitern aktualisiert (bzw.
38
zur Aktualisierung in die Fachbereiche weitergegeben), und anschließend wieder an die zuständige Stelle in der Technischen Abteilung zurückgeschickt. Anschließend erfolgt dann die Eingabe
der Daten in das CAFM-System im Referat Grundstücks- und Gebäudeverwaltung.
Kleinere Baumaßnahmen (Versetzen einer Tür o. ä) werden zur Zeit nicht erfasst.
Die Frage der Verantwortlichkeit für die Flächen- und Nutzungs- (Belegungs-)daten (Aktualisierung) ist noch nicht zufriedenstellend gelöst (vorgeschlagen wurden die Bauleiter und die Verwaltungsleiter). Dies betrifft z. B. die Weitergabe von baulichen Änderungen (zumindest wertsteigernde Um- und Ausbauten). Es wurde vorgeschlagen, alle Maßnahmen, die einen Bauantrag erfordern zu dokumentieren.
Die Datenpflege konnte bislang nicht durchgängig sichergestellt werden, was sich in fehlenden
oder zum Teil falschen Informationen äußert. Teilweise werden Grundstücks- und Gebäudedaten
auch in eigenen Dateien (z. B. MS-Excel) gepflegt und das CAFM-System nicht genutzt.
Der Flächendatenabgleich über Excel-Dateien (einmal im Jahr) wird als ungünstig empfunden und
stattdessen eine direkte Eingabe sowie eine häufigere Aktualisierung der Daten gewünscht. Allerdings gibt es auch Stimmen aus den Fakultäten, die eine weitergehende dezentrale Bearbeitung
(z. B. durch direkten Zugriff auf das CAFM-System) ablehnen, da sie den dafür erforderlichen Zeitaufwand als zu hoch ansehen.
Abb. 10: Grafische Darstellung der Räume (Beispiel: Erdgeschoss Hauptgebäude)
39
Eine häufige Forderung ist die nach dem Zugriff auf exakte maßstäbliche Grundrisse. Diese sind
selbst bei den neueren Gebäuden (am Standort Adlershof) nur zum Teil und nicht immer in der
gewünschten Form vorhanden. Die zur Zeit verfügbaren schematischen Grundrissdarstellungen im
CAFM-System (Beispiel s. Abb. 10) werden vielfach als nicht ausreichend empfunden, da wichtige
Informationen (Wände, Fenster etc.) nicht dargestellt werden. Die zum Teil nur als Rastergrafiken
vorhandenen Pläne (gescannte Pläne) werden als zu ungenau eingestuft. Sie eignen sich lediglich
als Übersicht.
Ein Problem liegt in den zum Teil fehlenden Zuständigkeiten für die Aktualisierung der CADZeichnungen. Hierzu wurde bereits vorgeschlagen, eine gesonderte Kraft im Referat Planung vorzuhalten. Weitere Vorschläge zielten darauf ab, die Änderungen an den Plänen direkt durch die
Bearbeiter (z. B. Bauleiter) durchführen zu lassen. Hinzu kommen noch eine Reihe von speziellen
Anforderungen, wie z. B. die Kennzeichnung von Rettungswegen in den Etagengrundrissen.
Seitens des zuständigen Bearbeiters wurde auf den erhöhten Aufwand für die Pflege der CADDaten hingewiesen, die zum einen die Pflege der Originalzeichnung und die Pflege der Pixelgrafiken, die in der CAFM-Datenbank hinterlegt sind, umfasst. Eine stärkere Verknüpfung zwischen
Grundrissen und Raumdaten wurde in diesem Zusammenhang ebenfalls vorgeschlagen.
Abb. 11: Spezielle Angaben zu Bau- und Liegenschaftsdaten im CAFM-System
Bezüglich der zu erfassenden Daten gab es folgende Anregungen:
§
Einheitliche Gestaltung der Raumnummernschlüssel,
40
§
§
§
§
Namentliche Zuordnung von Räumen (wer sitzt wo?),
Angaben zur technischen Raumausstattung (z. B. zur Vernetzung, Verkabelung, Steckdosen,
DV-Anschlüsse),
Grunddaten (z. B. Stellfläche, Verkehrslast, Raummaße, Flächen für die Gebäudereinigung,
Maximalbelegung),
Allgemeine Ausstattungsdaten (z. B. Zustand, Bodenbelag).
Unterstützend könnten die Daten auch bei der Zuordnung von Flächen zu Betreuungsbereichen
genutzt werden. Beispielsweise käme eine ausgewogene Zuordnung von Hausmeisterbereichen
sowie Betreuungsbereichen für die Bauleiter dafür in Betracht. Auch eine bessere Bewertung des
Flächenbedarfs, der sich bei Neuberufungen von Professoren ergibt, wäre denkbar.
HIS-Bewertung:
Absprachen bezüglich des Umfangs der zu erfassenden Daten sind zwar getroffen worden (Musterentwurf Raumbuch), allerdings gibt es keine Festlegungen, wie diese Daten erfasst werden
können. Es ist außerdem nicht verbindlich festgelegt, welche Personen für die Pflege welcher Daten verantwortlich sind.
Die im Musterentwurf festgelegten Informationen enthalten zu einem großen Teil FreitextInformationen. Dies kann sich bei der Datenerfassung ungünstig auswirken, sofern keine Eindeutigkeit bei den verwendeten Begriffen festgelegt wurde. Beispielsweise wäre im Freitextfeld „Angaben zu Eigentum oder Miete“ der Eintrag „Universität“, „Univ.“, „HU“ zur Bezeichnung der Universität möglich.
Die Eignung der im Musterentwurf festgelegten Felder ist hier nicht im Detail untersucht worden,
da die Anforderungen in einer Arbeitsgruppe der HU seinerzeit selbst festgelegt wurden. Allerdings
sollten diese im praktischen Einsatz (Beispieldaten) noch überprüft werden. Beispielsweise erscheint die Anzahl der Felder mit Angaben zur Gebäudereinigung sehr knapp bemessen.
Im Hinblick auf die Integration von CAD-Daten werden vor allem zwei Anforderungen deutlich:
§
§
Zugriff auf digitalisierte Pläne (hohe Genauigkeit) sowie
eine erweiterte Grundrissdarstellung bei den mit den Gebäudedaten verknüpften Geschossplänen.
Auch hier fehlt es an der Festlegung von Verantwortlichkeiten. Insbesondere die Pflege der Bestandspläne ist nicht durchgängig geregelt. Grundsätzlich gibt es zwar eine Stelle, die für die Archivierung von Bestandsplänen verantwortlich ist, wobei jedoch nicht sichergestellt ist, dass hier
jeweils aktuelle Pläne zur Verfügung stehen. Vielmehr werden aktualisierte Pläne von einzelnen
Bauleitern für den eigenen Bedarf gesammelt und auf Anfrage auch anderen Kolleginnen und
Kollegen zur Verfügung gestellt. Problematisch wird diese Verfahrensweise insbesondere dann,
wenn ein Bauleiter für längere Zeit ausfällt bzw. (was in den nächsten Jahren mehrfach zu erwarten ist) in den Ruhestand geht.
HIS-Vorschlag:
Die Bau- und Liegenschaftsdaten sind das zentrale Element eines jeden CAFM-Systems. Daher ist
es besonders wichtig, hier eine verlässliche Datenbasis zu schaffen. Dieser Punkt sollte mit
höchster Priorität bearbeitet werden. Empfohlen werden folgende Schritte:
§
§
Festlegung der Daten, die erfasst werden müssen (auf der Grundlage des erarbeiteten
Raumbuch-Musterentwurfs (s. Anhang) ausgehend vom derzeitigen Umfang bereits erfasster
Daten; ggf. weitere Reduzierung des Umfangs). Die Projektgruppe sollte die getroffene Festlegung mit den für die Datenpflege verantwortlichen Referaten bzw. Gruppen noch einmal abstimmen.
Festlegung von Verantwortlichkeiten für Datenerfassung und Pflege: jeder Wunsch nach Aufnahme bestimmter Daten muss zunächst eine Klärung der Verantwortlichkeit für die Daten
§
§
§
§
41
nach sich ziehen. Falls niemand die Zuständigkeit dafür übernehmen will bzw. kann, ist von
einer Erfassung der betreffenden Daten abzusehen, selbst wenn diese sporadisch bzw. in einem begrenzten Zeitraum möglich wäre. Die Definition entsprechender Datenfelder im CAFMSystem kann – sofern dies gewünscht ist – trotzdem erfolgen, sie bleiben jedoch für den Nutzer unsichtbar.
Schaffung einer verantwortlichen Stelle für die Pflege der CAD-Pläne. Diese kann sowohl bei
den Bauleitern als auch im Planarchiv angesiedelt sein. Sämtliche Änderungen sind hier zu
erfassen.
Für den Ausbau des CAD-gestützten Planarchivs ist eine strategische und zeitliche Planung
durchzuführen.
Es ist zu überprüfen, ob nicht eine direkte Verknüpfung zwischen den CAD-Plänen und dem
CAFM-System – wie bei kommerziellen Systemen üblich – sinnvoll ist. Neben dem Vorteil keine doppelte Pflege von Plänen durchführen zu müssen, ergibt sich hierdurch auch die Möglichkeit, maßstäbliche Grundrisse mit allen erforderlichen Informationen (Wände, Türen,
Fenster etc.) zu nutzen. Voraussetzung für eine geeignete Darstellung ist die Festlegung einer
einheitlichen Layerstruktur, mit der es möglich ist, nicht benötigte Zeichnungsinformationen
auszublenden.
Verständigung über erforderliche Auswertungen bzw. Möglichkeiten, diese den individuellen
Wünschen der Mitarbeiterinnen und Mitarbeiter anzupassen.
Eine besondere Betrachtung ist bei der Frage nach den Zuständigkeiten für die numerischen Daten (Flächen, Nutzungen) erforderlich. Die bisherige Lösung, diese Daten nur einmal im Jahr zu
aktualisieren entspricht nicht dem Anspruch, der üblicherweise an ein Informationssystem gestellt
wird. Der Qualität (Aktualität und Genauigkeit) der Daten sollte eine wesentlich höhere Priorität
eingeräumt werden, als der Quantität. Vorgeschlagen wird, eine ständige Aktualisierung der Daten
vorzusehen. Die Dateneingabe könnte dabei auch dezentral durch die jeweiligen Verwaltungsleiter
vorgenommen werden. Es wäre allerdings zum derzeitigen Zeitpunkt noch nicht möglich, dies generell festzuschreiben, da zum Teil mit einer ablehnenden Haltung der Betroffenen zu rechnen ist.
Um hier unnötige Reibungsverluste zu vermeiden, wird eine zweigleisige Vorgehensweise empfohlen:
§
§
Für diejenigen Nutzer, die den direkten Zugriff wünschen wird eine entsprechende Möglichkeit
geschaffen. Ein Sicherheitsmechanismus könnte dafür sorgen, dass die Daten erst nach Freigabe durch den (vorab zu bestimmenden) verantwortlichen Mitarbeiter in der Technischen
Abteilung in die Datenbank übernommen werden.
Für diejenigen, die sich eine Bearbeitung der Daten im CAFM-System noch nicht vorstellen
können (z. T. ist die PC-Nutzung in einigen Bereichen noch nicht sehr stark ausgeprägt), sollte
die Möglichkeit, die Hinweise per E-Mail (ggf. auch in einem zur Datenübernahme geeigneten
Excel-Formular) erhalten bleiben. Allerdings ist personell dafür Sorge zu tragen, dass die Dateneingabe jeweils zeitnah erfolgen kann.
3.4.10 Lehrraumverwaltung und -vergabe
Ist-Zustand:
Derzeit wird die Vergabe von Lehrräumen mit Hilfe einer (vom Rechenzentrum) entwickelten Software (Pascal-Programm aus den 80er Jahren) durchgeführt. Das Programm ermöglicht zwar eine
kriterien- und prioritätsabhängige Raumvergabe, ist dabei aber von der Handhabung her sehr umständlich. So lassen sich beispielsweise Fehleingaben nicht nachträglich editieren und machen in
diesem Fall eine komplette Neueingabe der Daten erforderlich.
Seit 2001 wird an einem zusätzlichen Modul als Teil des CAFM-Systems gearbeitet, um das bisherige System abzulösen (s. Abb. 12). Hierzu werden derzeit in der Philosophischen Fakultät I
(Fachbereich Geschichte) und in der Juristischen Fakultät Testeinsätze durchgeführt. Ziel ist es
dabei nicht nur eine Verbesserung der Systemfunktionalität, sondern auch eine stärkere Dezentralisierung bei der Raumvergabe zu erreichen. Die Fakultäten sollen bestimmte Raumkontingente,
42
deren Umfang aus vorgegebenen Parametern nach einem festgelegten Schlüssel – u. a. aus dem
für die zugehörigen Fachbereiche vorgesehenen Lehrdeputat – ermittelt wird, jeweils pro Semester
zugeteilt bekommen. Die Erstellung der Belegungspläne wird dann intern innerhalb der jeweiligen
Abb. 12: Beispiel für Übersicht Hörsaalvergabe (im Entwurfsstadium)
Fachbereiche geregelt.
Die Ausdehnung auf allgemeine Reservierungsmöglichkeiten von Räumen für Veranstaltungen
(einmalige, periodische oder Blockveranstaltungen) wird technisch als machbar angesehen. Es
bestehen jedoch organisatorische Probleme, da es bereits einen Veranstaltungskalender an der
HU gibt, der jedoch nicht schlüsselbasiert aufgebaut ist (als Sybase-Datenbank organisiert).
Die Position der Hochschulleitung zur Problematik der Lehrraumverwaltung konnte im Laufe des
Projekts nicht abschließend geklärt werden: So ist neben der Weiterentwicklung des o. g. Moduls
auch die Beschaffung einer speziell für diesen Zweck vorgesehenen Software externer Anbieter im
Gespräch.
Verlässliche Übersichten über die (für Veranstaltungen nutzbare) Raumstruktur der Universität
stehen derzeit nur in geringem Umfang zur Verfügung. Unterschiedliche Zuständigkeiten bei der
Raumverwaltung (Studienabteilung, Fakultäten, Pressestelle) erschweren die Reservierung von
Räumen für Veranstaltungen. Die Vergabe von Lehrräumen erfolgt derzeit in einem langwierigen
Verfahren, was dazu führt, dass ein hoher Anteil der im Vorlesungsverzeichnis ausgewiesenen
Lehrveranstaltungen in Bezug auf die Veranstaltungsorte nicht auf dem aktuellen Stand ist. Gewünscht wird daher eine Unterstützung bei der Lehrraumvergabe. Ebenfalls genannt wurden:
§
Suchen nach freien Veranstaltungsräumen,
§
§
43
Ermittlung der aktuell festgelegten Belegung von Räumen,
Einbeziehung von Kapazitätsberechnungen zur Ermittlung der benötigten Raumkapazität (in
Abhängigkeit von Raumgröße und erforderlichen Semesterwochenstunden).
Die Aktualität des Vorlesungsverzeichnisses der HU sollte gewährleistet sein.
HIS-Bewertung:
Die Lehrraumvergabe stellt insbesondere für die Fachbereiche bislang ein Problem dar. Die derzeitig angewandte Methode der Raumvergabe ist unzulänglich. Die geringe Flexibilität des vorhandenen Systems führt dazu, dass die Institute bei der Abfrage ihrer Wünsche möglichst hohe Forderungen aufstellen, um ihre Chancen bei der Raumzuteilung zu erhöhen. Das kann dazu führen,
dass zu viele Räume angefordert bzw. die angeforderten Räume nicht optimal genutzt werden.
Problematisch erscheint auch die z. T. sehr negativ bewertete Aktualität der Vorlesungsverzeichnisse in Bezug auf die Angaben zu Veranstaltungsorten. Eine verbesserte Lösung erscheint hier
dringend geboten.
HIS-Vorschlag:
Die weitere Vorgehensweise ergibt sich in Abhängigkeit von der Entscheidung der Hochschulleitung. Sollte ein externes Programm beschafft werden, reduziert sich die Betrachtung dieses
Punktes auf die Frage der Entwicklung von Schnittstellen. Beispielsweise könnten Daten zur
Raumausstattung, Flächen- und Kapazitätsangeben vom CAFM-System zur Verfügung gestellt
werden. Was die Systembeschaffung angeht, so sind hier eine Reihe von Anbietern auf dem
Markt, die zum Teil preiswerte, speziell auf den Hochschulbereich zugeschnittene Systeme entwickelt haben. Verwiesen sei an dieser Stelle auf eine neue HIS-Lösung [4] 8.
Sollen die Funktionen in das CAFM-System integriert werden, ist die Vorhaltung von personeller
Kapazität für diesen Bereich unerlässlich. Die Weiterentwicklung sollte dann in einer speziellen
Arbeitsgruppe unter Beteiligung der Studienabteilung abgestimmt werden.
3.4.11 Gebäudereinigung
Ist-Zustand:
Im Musterentwurf Raumbuch der HU (Anhang: Musterentwurf Raumbuch) sind Daten zur Gebäudereinigung enthalten (Reinigungsfläche, Fensterfläche, Bodenbelag als Freitext). Eine weitere
Differenzierung ist bislang nicht vorgesehen (s. Abb. 13).
Von dem zuständigen Sachbearbeiter wurde angegeben, dass er bereits im Rahmen der CAFMArbeitsgruppe der HU Vorschläge gemacht hat, aus denen hervorgeht, welche Daten für die Bearbeitung von Aufgaben der Gebäudereinigung benötigt werden. Die entsprechenden Funktionen
und Abfragen (beispielsweise für die Unterstützung von Ausschreibungen) sind derzeit noch nicht
vorhanden. So besteht noch keine Möglichkeit Flächen nach bestimmten Nutzungsarten (z. B. alle
Büroflächen) abzufragen. Im Februar 2002 ist die Vergabe eines größeren Objektes in Adlershof
vorgesehen (Physikgebäude), dass sich nach Ansicht des befragten Sachbearbeiters für eine exemplarische Datenerfassung eignen würde.
HIS-Bewertung:
Die Gebäudereinigung stellt infolge ihres hohen Anteils an den Betriebskosten von Gebäuden einen wichtigen Bereich zur Kostenoptimierung dar. Voraussetzung dafür ist die Verfügbarkeit von
geeigneten Informationen, wie z. B. Angaben zu Reinigungsflächen, Bodenbelegen, Nutzungsintensität etc. An der HU sind Daten zur Gebäudereinigung bislang noch nicht im CAFM-System
erfasst. Auch bleibt der Umfang der festgelegten Datenfelder eher gering. Einige Felder sind als
8
Das System soll auf der CeBit in Hannover im März 2002 erstmals einer breiteren Öffentlichkeit präsentiert werden.
44
Abb. 13: Daten für die Gebäudereinigung (FM-Works)
Freitext festgelegt (z. B. „Bodenbelege“). Das birgt die Gefahr, dass hier unterschiedliche Bezeichnungen für gleiche Daten verwendet werden (z. B. Teppich, Teppichboden), was die Auswertung
erschwert. Weiterhin fehlt die Möglichkeit zur Erfassung von Reinigungszyklen.
HIS-Vorschlag:
Die Abbildung des Aufgabenbereichs Gebäudereinigung kann im Rahmen der Umsetzung des
Moduls Bau- und Liegenschaftsdaten erfolgen, da seitens der HU offenbar keine speziellen Anforderungen bestehen. Ein gesondertes Modul ist nach dem derzeitigen Stand also nicht erforderlich.
Allerdings sollten die Anforderungen an die Daten, die (u. a. auch für die Unterstützung im Rahmen von Ausschreibungen) benötigt werden, noch im Detail geklärt werden (was wird bisher erfasst bzw. benötigt). Neben den Reinigungsflächen (Fußboden u. Fenster) wäre die Übernahme
weiterer Daten zu überlegen (z. B. Reinigungszyklen bzw. Kategorie). Die Erfassung der Bodenbeläge sollte mit Hilfe von Auswahlfeldern erfolgen.
Die anstehende Ausschreibung eines Physikgebäudes am Standort Adlershof könnte genutzt werden, um exemplarisch alle für die Gebäudereinigung relevanten Daten zu erfassen und geeignete
Auswertungen zu erstellen.
3.4.12 Arbeitssicherheit, Arbeitsschutz und Brandschutz
Ist-Zustand:
Für die Bereiche Arbeitssicherheit und Brandschutz sind an der HU zur Zeit eigene Homepages
(außerhalb des CAFM-Systems) verfügbar. Das Referat Arbeitsschutz bietet beispielsweise eine
45
Seite an, auf der Informationen über Adressen und Ansprechpartner abrufbar sind. Verfügbar sind
Übersichten zu organisatorischen Zuständigkeiten, Terminen, gesetzlichen Grundlagen sowie
Hinweise zum Verhalten bei Unfällen.
Im Brandschutz (Sachgebiet) werden Übersichten zu Feuerlöschanlagen (als PDF-Dokument),
eine Musterbrandschutzordnung sowie Formulare (z. B. Bestellung zum Brandschutzbeauftragten)
angeboten. Eine Übersicht über die Brandschutzbeauftragten ist nicht vorhanden.
Alarmierungspläne für den Notfall (dokumentenbasiert mit tabellarischen Daten) können generiert
werden. Bei der Erstellung von Flucht- und Rettungsplänen für die Gebäude sowie von Einsatzplänen für die Feuerwehr wird in der Regel auf vorhandene CAD- oder Papierpläne zurückgegriffen.
Im Musterentwurf Raumbuch sind Felder für Sicherheitstechnik, Gefahrmeldetechnik und Feuerlöscher vorgesehen. Bislang sind diese Daten jedoch im CAFM-System nicht erfasst.
Im Rahmen der Befragung wurde bemängelt, dass die Informationen zum Arbeitsschutz und zum
Brandschutz nicht auf dem aktuellen Stand sind. Außerdem wäre ein weitergehender Zugriff auf
Informationen sinnvoll. Gewünscht werden außerdem brandschutzrelevante Angaben, wie z. B.
Standorte der Feuerlöscher, Evakuierungswege, Brandmelder und Rauchmelder in den Lageplänen (Grundriss- und Etagenpläne).
HIS-Bewertung:
Die auf den Webseiten der HU eingestellten Informationen zu Arbeits- und Brandschutz dienen
vorwiegend der Information. Auswertungen lassen sich damit nicht durchführen.
HIS-Vorschlag:
Die Anforderungen für diese Bereiche sind von den zuständigen Referaten festzulegen, um dort
eine Nutzung des CAFM-Systems zu ermöglichen. Im einfachsten Fall könnte es sich anbieten, die
Standorte von Feuerlöschern und Brandmeldeeinrichtungen zusammen mit den Raumbuchdaten
zu erfassen. Flucht- und Rettungswege könnten in den Geschossplänen ausgewiesen werden.
Fest installierte Löscheinrichtungen, wie z. B. Sprinkleranlagen könnten im Rahmen der Erfassung
der Anlagenstammdaten mit aufgenommen werden. Brandmeldesysteme und Löscheinrichtungen
unterliegen außerdem der regelmäßigen Überwachung (Prüfpflicht). Eine Unterstützung der Terminplanung und Durchführung der Prüfaufgaben könnte als eigenständige Anwendung oder auch
im Rahmen eines Instandhaltungsmanagements realisiert werden.
Vorgehalten werden sollte eine Übersicht über die Beauftragten und sonstige zuständige Personen, die Funktionen in diesen Bereichen wahrnehmen. Für den Brandschutz fehlen diese bislang
völlig. Eine Integration in ein Personenregister (wie z. B. ZIS) mit gezielter Suchmöglichkeit nach
diesen Kriterien wäre ebenfalls hilfreich.
3.4.13 Adress- und Telefondaten
Ist-Zustand:
Ein Personenregister ist unter der Bezeichnung „Zentrales Informationssystem“ (ZIS) über die Internet-Seiten der HU verfügbar. Die Betreuung erfolgt durch das Rechenzentrum. Eine Kopplung
zum CAFM-System besteht aufgrund technischer Probleme bei der Verknüpfung der Datenbanken
(Eindeutigkeit der Daten ist im ZIS nicht gewährleistet, keine Schlüssel verfügbar) nicht. Die Pflege
der Daten erfolgt dezentral durch die jeweils verantwortlichen Personen (z. B. Verwaltungsleiter).
Sie können die Daten direkt in eine Access-Eingabemaske eingeben.
Anforderungen bestehen hinsichtlich vereinfachter Möglichkeiten zur Aktualisierung der Daten.
46
Bewertung:
Die derzeitige Lösung (ZIS) ist für sich betrachtet sehr nützlich und wird insgesamt sehr gut angenommen. Die Suche nach Adressen, Telefonnummern, E-Mail-Adressen etc. gestaltet sich sehr
einfach. Eine Verknüpfung mit Wegeplänen ist ebenfalls vorhanden. Nachteilig ist allerdings die
Realisierung dieses Systems als Stand-alone-Lösung. Da innerhalb des CAFM-Systems ebenfalls
Daten erfasst und verarbeitet werden, die sich auf Personen, Adressen, Funktionen etc. beziehen,
besteht hier die Gefahr das Daten doppelt gepflegt werden müssen.
Vorschlag:
Auf der Verwaltungsleitungsebene ist zunächst abzustimmen, inwieweit eine Beibehaltung des ZIS
in der bisherigen Form befürwortet wird. Falls ja, müsste das System dahingehend überarbeitet
werden, dass ein Zugriff von außen auf das System möglich wird. Das ZIS wäre dann das führende System für diese Daten. Die Adress- und Gebäudeinformationen sollten aber dem CAFMSystem entnommen werden. Alternativ bietet sich eine neue Realisierung des Systems als Teil des
CAFM-Systems an. Die Hinzuziehung des Rechenzentrums zu diesem Punkt ist unbedingt erforderlich.
3.4.14 IuK, Leitungen und Kabel
Ist-Zustand:
Im Bereich Informations- und Kommunikationsmanagement wurde seitens des Rechenzentrums
das System InfoCable der Firma IIEF bis Ende 2001 eingesetzt. Eine weitere Nutzung ist jedoch
nicht mehr vorgesehen. Daten zur Ausstattung des Backbone-Netzes sowie einiger Gebäude wurden eingepflegt. Die Pflege der Daten wurde jedoch Ende 2001 eingestellt, da der Aufwand für die
Nutzung des Systems als zu hoch angesehen wird. Bestimmte Daten (z. B. passive Ports) sollen
aber weiterhin erfasst werden (ggf. in eigenen Tabellen).
Im Referat „Betriebstechnische Dienste“ sind Informationen zur Daten-, Telefon- und Nachrichtentechnik in Excel-Dateien erfasst (z. T. mit Übersichts- und Klemmenplänen). Die Dateien sind über
das CAFM-System abrufbar.
Rohrleitungen und Stromkabel sind bislang nicht explizit erfasst. Es sind lediglich Pläne (vorwiegend in Papierform) vorhanden.
Für den IuK-Bereich werden Informationen zu LAN-Verkabelung, Netzsegmenten und Anschlüssen gewünscht. Ansonsten gibt es den Wunsch nach Informationen zur Stromverkabelung in den
Räumen.
HIS-Bewertung:
Bisher hat es keine gemeinsamen Aktivitäten von Rechenzentrum und Technischer Abteilung im
Hinblick auf die Erfassung der IuK-Daten gegeben. Die Erfassung von Daten und Plänen zur Daten-, Telefon- und Nachrichtentechnik (allerdings schwer zu finden, da unter dem Stichwort „Archiv“ abgelegt) stellt beispielhaft eine mögliche sinnvolle Anwendung des CAFM-Systems dar.
HIS-Vorschlag:
Eine bessere Abstimmung zwischen Technischer Abteilung und Rechenzentrum erscheint erforderlich. Sinnvoll wäre eine Integration der Daten in das CAFM-System, die seitens des Rechenzentrums benötigt werden. Die Verantwortung für die Datenpflege bliebe dann beim Rechenzentrum.
Der Umfang der Erfassung von Daten (Kabel und Leitungen) aus dem Zuständigkeitsbereich des
Referats „Betriebstechnische Dienste“ ist noch einmal mit den Betroffenen zu klären. Dieser Punkt
kann jedoch zunächst zurückgestellt werden, da hierzu keine Anforderungen geäußert wurden.
Allerdings zeigen die begonnenen Aktivitäten im Bereich der Daten-, Telefon- und NachrichtenCAFM-System der Humboldt-Universität zu Berlin
47
technik, dass hier geeignete Anwendungen zu finden sind; ggf. ist hier die Erfassung der Daten mit
Hilfe des CAFM-Systems (in der Datenbank ggf. mit hinterlegten Grafiken) in Betracht zu ziehen.
Auf Wunsch der Projektgruppe wird dieser Bereich dem unter Abschnitt 3.4.5 beschriebenen Aufgabenkomplex zugeordnet.
3.4.15 Arbeitsabläufe
Die Auseinandersetzung mit den hochschulinternen Arbeitsabläufen ist bisher nur zu einem geringen Teil erfolgt. In der Projektgruppe wurden hier weitere Notwendigkeiten erkannt. Beispielhaft
sind einige Prozesse (z. B. Umzug, s. 3.4.8) von HIS dargestellt worden. Zum Teil sind hier noch
detaillierte Untersuchungen seitens der HU erforderlich. Insbesondere sind viele Abläufe nicht oder
nur unvollständig beschrieben bzw. hinterlegt. Die Arbeitsabläufe sollen durch das CAFM-System
unterstützt werden. Angedacht sind hier zunächst einfache Lösungen, z. B. das automatische
Versenden von E-Mails an ereignisabhängige Verteiler (ggf. mit Rückmeldung). Exemplarisch wurde in der Projektgruppe eine Realisierung für den Aufgabenbereich „Umzüge“ vorgeschlagen.
3.4.16 Sonstige Aufgaben
Möglichkeiten zur Unterstützung von Materialwirtschaft/Beschaffung/Lagerhaltung waren bisher nicht gefordert. Zuständig ist hier die zentrale Beschaffungsstelle der HU.
Gleiches gilt für die Inventarisierung. Sie wird nicht zentral durchgeführt. Die Verantwortung liegt
in den Fakultäten bzw. Fachbereichen.
Der Bereich Abfallentsorgung ist bisher ebenfalls nicht berücksichtigt worden (abgesehen von
der Titelverwaltung).
Die Anforderungen aus den o. g. Bereichen ließen sich im Rahmen des Projektes nicht mehr klären.
3.5 Systembedienung
3.5.1
Bedienoberfläche
Ist-Zustand:
Die Systembedienung erfolgt derzeit vorwiegend mittels Web-Browser. Alternativ ist die Bedienung
über die FM-Works-Oberfläche möglich (s. unter 2.3).
Anregungen betrafen die Funktionsaufrufe (Begrifflichkeiten sind z. T. unglücklich gewählt – s. u.)
und die Gliederung der Bedienoberfläche. Bei den Suchfunktionen wurde vorgeschlagen, dem
Nutzer die Möglichkeit zur Vorgabe von Suchkriterien zu ermöglichen. Außerdem wurde eine Reduzierung der Ansicht auf die benötigten Daten (Ausblenden von Funktionen gruppenweise, z. B.
für Bauleiter) gewünscht.
HIS-Bewertung:
Die Bedienung mittels Zugriff über Web-Browser auf das Portal der Technischen Abteilung stellt
sich unkompliziert dar. Besondere Möglichkeiten zur Konfigurierung durch den Nutzer stehen nicht
zur Verfügung (abgesehen von kleineren Layout-Festlegungen). Die vorhandenen Informationen
sind in der Regel gut zu finden, erfordern jedoch bei nur gelegentlicher Nutzung einige Versuche,
da die Begriffe nicht immer schlüssig gewählt sind (z. B. verbergen sich recht unterschiedliche Informationen unter dem Oberbegriff „Archiv“, der unter „Flächenmanagement“ – „Standorte“ aufgeCAFM-System der Humboldt-Universität zu Berlin
48
rufen werden kann). Bei längeren Ladezeiten (z. B. für die Grundrissdarstellungen) kann das „Probieren“ lästig werden. Die gezielte Suche nach Informationen ist noch relativ eingeschränkt. In der
Suchmaske führt beispielsweise eine Eingabe „Hauptgebäude“ oder „Unter den Linden“ zum Erfolg, nicht jedoch eine Kombination „Hauptgebäude Unter den Linden“. Möchte der Nutzer erfahren, welche Gebäude zur „Technischen Abteilung“ gehören, so erhält er zwar eine Liste sämtlicher
Haushaltsbuchungen, nicht jedoch einen Hinweis auf die Gebäude der Technischen Abteilung.
Die Gliederung der Seiten nach technischem, infrastrukturellem und kaufmännischem Gebäudemanagement entspricht zwar der Norm, jedoch nicht der Organisationsstruktur der Technischen
Abteilung. Zweckmäßiger erscheint dagegen die Darstellung in der FM-Works-Oberfläche.
HIS-Vorschlag:
Der grundlegende Aufbau der Bedienoberfläche (insbesondere FM-Works) ist für den vorgesehenen Einsatz gut geeignet. Die Begrifflichkeiten sollten in einigen Fällen noch einmal in der Projektgruppe überdacht werden. Die Möglichkeiten zur Suche nach Informationen könnten noch verbessert werden (vgl. Bewertung). Grafische Darstellungen sollten abschaltbar sein, um ggf. schneller
an bestimmte Daten zu kommen (Anzeige aller wichtigen Daten für einen Raum, ohne dass vorher
der Grundriss geladen werden muss – funktioniert derzeit nur auf Umwegen, z. B. über Suche von
Gebäudenummer und Anklicken des gewünschten Raumes). Hilfreich wäre hier die Möglichkeit,
über Auswahllisten direkt Räume anwählen zu können.
Die Gliederung der Oberfläche sollte in gewissen Grenzen vom Nutzer vorgegeben werden können. so dass häufig genutzte Funktionen bzw. Darstellungen schnell abrufbar sind (Beispiel:
Raumliste für die Gebäude x, y u. z).
3.5.2
Auswertungen
Ist-Zustand:
Derzeit sind eine Reihe fester Auswertungen als fest vorgegebene Berichte (Standardlisten) vorhanden. Eine Übergabe der Daten an andere Programme (z. B. MS-Excel) ist in jedem Fall möglich. Die Auswertungen lassen sich prinzipiell als Text-, HTML- oder PDF-Datei generieren. Eine
Volltext-Suche im gesamten Datenbestand ist möglich.
Die ursprünglich (zahlenmäßig) vielen Auswertungsmöglichkeiten wurden bereits verringert, da
zum einen die Übersichtlichkeit gelitten hat, zum anderen die Auswertungen z. T. sehr ähnlich waren bzw. sich zusammenfassen ließen.
Der Einsatz eines Report-Generators ist geplant. Es wird aber davon ausgegangen, dass die Ausgabe der Daten in einem für MS-Excel geeigneten Format in den meisten Fällen die bessere Lösung darstellt.
Von den Befragten wurden u. a. folgende Auswertungswünsche vorgeschlagen:
§
Nutzungsarten nach DIN 277.
§
Flächenbilanzen (z. B. nach Organisationseinheiten, Gebäuden, Kriterien der KLR o. ä.) [bereits möglich, wurde bisher aber nicht nachgefragt].
§
Erfassung von Objekten (im Raum oder Gebäude), an denen vorgeschriebene Prüfungen (z.
B. nach VBG 4) durchzuführen sind [bereits eingerichtet, jedoch wurden die Daten nicht weiter
gepflegt].
§
Sicherheitsrelevante Merkmale (z. B. in den Bereichen Gentechnik, Gefahrstoffe, Strahlenschutz etc.) [bereits möglich, jedoch werden die Daten bisher nur zum Teil genutzt].
§
Festlegung von Faktoren, z. B. für die Flächenbewertung (z. B. anteilige Bewertung bestimmter Flächen für Mieten) [bereits realisiert].
§
Verwaltung personenbezogener Daten (z. B. zugeordneter PC, Telefonnummer etc.) [bereits
möglich, wurde bisher aber noch nicht genutzt].
49
Gewünscht wurde auch die Möglichkeit, spezielle Auswertungen selbst erstellen zu können, z. B.
Auswertung von Gebäude- und Raumdaten nach OKZ, Fläche je Lehrstuhl, Baumaßnahmen,
Räume, die nicht von der Fakultät verwaltet werden.
Die recht ausführliche (grafische) Darstellung der Gebäudeflächen nach Nutzungsarten ist dagegen nur für wenige Nutzer der HU von Interesse.
HIS-Bewertung:
Die Listen konnten zum Teil nicht aufgerufen werden, da (abgesehen von denen, deren Zugriff
gesperrt war) Fehlermeldungen bei der Ausgabe auftraten oder die Ergebnisse nur über Umwege
angezeigt wurden. Nachteilig ist allerdings die nicht vorhandene Konfigurierbarkeit der Listen durch
den Nutzer. Auch der Export (z. B. als Excel-Datei) lässt sich derzeit nicht direkt durch den Nutzer
bewerkstelligen.
HIS-Vorschlag:
Für Auswertungen sollten grundsätzlich zwei Möglichkeiten zur Verfügung stehen:
§
§
Generierung einfacher Abfragen (ohne besondere Layout-Gestaltungsmöglichkeiten) mit der
Möglichkeit Ausgaben im Text bzw. CSV- (bzw. Excel-) Format zu ermöglichen.
Generierung von Reports, die eine aufwendigere Darstellung der Ergebnisse ermöglichen.
Beide Lösungen sollten durch den Nutzer voreingestellt werden können (zumindest die Auswahl
der anzuzeigenden Felder). Da nicht jeder Nutzer sich intensiv mit dem CAFM-System beschäftigen möchte, kann es durchaus sinnvoll sein, häufig benötigte Reports standardisiert im System
vorzuhalten.
3.6 Kooperation mit den Berliner Hochschulen
HIS-seitig fanden Gespräche mit den jeweiligen Technischen Leitern unter Beteiligung weiterer
fachbezogener Mitarbeiter am 14.02.2002 an der FU Berlin und am 20.02.2002 an der TU Berlin
statt.
Ziel war es dabei, Informationen über die Aktivitäten der Berliner Hochschulen im Gebäudemanagement zu bekommen, um daraus Hinweise auf mögliche Felder der Zusammenarbeit ableiten zu
können. Dabei wurde deutlich, dass es zwar gemeinsame inhaltliche Interessen und Aufgaben
gibt, die Ansätze zur Bearbeitung jedoch voneinander abweichen. Eine Übertragung der CAFMLösung der HU käme derzeit nicht in Frage. Trotzdem ist es aus Sicht von HIS sinnvoll den bereits
auf der Abteilungsleiterebene begonnenen Erfahrungsaustausch weiter zu betreiben. Insbesondere inhaltliche Fragen lassen sich so besser bearbeiten, wenn die Hochschulen die bisherigen gesammelten Erfahrungen miteinander austauschen. Sehr positiv wurde auch der Vorschlag aufgenommen, die jeweils an den Hochschulen verwendeten DV-Lösungen einander vorzustellen. Es ist
nicht auszuschließen, dass sich im Rahmen des Informationsaustausches Möglichkeiten für eine
weitergehende Zusammenarbeit ergeben.
3.6.1
FU Berlin
Die FU Berlin verfügt über ca. 13.500 Räume, die sich auf ca. 200 Gebäude verteilen (nicht berücksichtigt ist die Humanmedizin des Universitätsklinikums Benjamin Franklin). Berichtet wurde
von sehr frühen Erfahrungen im Bereich des DV-gestützten Gebäudemanagements. Das hierzu
(zuletzt nur regional begrenzt) verwendete eigenentwickelte System wurde mittlerweile abgeschaltet. Aktuell wird eine Lösung auf MS-Access-Basis verwendet. Die Anwendung enthält im
Wesentlichen Raumdaten, ergänzt um Informationen zur Gebäudereinigung und Abfallentsorgung
(Containerstandorte). Alle Räume der FU (außer im medizinischen Bereich) sind erfasst. Ein Abfragesystem bietet umfangreiche Datenzusammenstellungen für die Raumplanung an. Die LDSCAFM-System der Humboldt-Universität zu Berlin
50
Meldung (Hochschulstatistik) ist ebenfalls enthalten. Die erfassten Daten weisen nur einen geringen Detaillierungsgrad auf. Die Raumdatei soll mit Hilfe von studentischen Hilfskräften zunächst
auf den aktuellen Stand gebracht werden. Das System wird durch eine externe Firma nach den
Vorgaben der FU programmiert. Die Lösung wird unter den derzeitigen Randbedingungen als ausreichend angesehen. Bei veränderten Randbedingungen, wie sie sich z. B. im Rahmen der Einführung von Budgetierungsstrukturen ergeben würden, wären grundlegende Änderungen am System
erforderlich. Demnächst ist die Einführung eines CAD-Systems vorgesehen. Im Bereich der Betriebstechnik wird ein – mittlerweile nicht mehr vom Hersteller unterstütztes – Instandhaltungsplanungssystem eingesetzt (System Activity der Fa. Insta). Der Einsatz beschränkt sich hauptsächlich
auf die Ausgabe von Arbeitskarten.
Im Bereich des kaufmännischen Gebäudemanagements wird im Zuständigkeitsbereich der Technischen Abteilung ein älteres Buchungssystem der Fa. Siemens-Nixdorf eingesetzt.
Seit Beginn des Jahres 2002 besitzt die FU ein eigenes Abrechnungssystem im Personalwesen, das auf SAP/R3 basiert. Eine Ausweitung der SAP-Anwendungen ist vorgesehen.
Seitens der Technischen Abteilung wird davon ausgegangen, dass mittelfristig auch im Bereich des Gebäudemanagements eine entsprechende Orientierung erfolgen wird. Da die Fa.
SAP selbst derzeit nicht als Anbieter von CAFM-Lösungen9 auftritt, könnte dies auch mit
Partnerfirmen wie speedikon oder Aperture geschehen. Insofern wird die Möglichkeit eine
Lösung auf der Basis des CAFM-Systems der HU zu realisieren als wenig wahrscheinlich
angesehen.
3.6.2
TU Berlin
Die TU Berlin befindet sich in einer Umstrukturierungsphase, die auch dazu führte, dass in den
letzten Jahren eine Reihe neuer DV-Systeme eingeführt wurden. Die Fakultäten sind bereits in
Teilen budgetiert; im Jahr 2003 soll die vollständige Budgetierung eingeführt werden. Damit verbunden ist auch die Möglichkeit, ein Raumhandelsmodell einzuführen.
An der TU wird ein selbst entwickeltes CAFM-System eingesetzt. Ursprünglich war der Kauf eines
kommerziellen Systems vorgesehen (es hat hierzu auch eine Untersuchung einer Unternehmensberatung gegeben), die speziellen Anforderungen der Hochschule, die bei diesen Systemen jedoch einen hohen Aufwand für Anpassungen erforderlich gemacht hätten, führten jedoch dazu,
dass eine Eigenentwicklung durchgeführt wurde.
Ziel für den Einsatz eines CAFM-Systems war es zum einen, die Kundenorientierung zu verbessern und zum anderen Entscheidungen zur Fremdvergabe sachgerechter treffen zu können.
Unter der Leitung von Professor Pape wurde ein integrales CAFM-System als Client/ServerLösung entwickelt, aufgebaut und in Gang gesetzt. Das Projekt ist als Forschungsprojekt am
Fachbereich Wirtschaftsinformatik im Lehrstuhl für Angewandte Elektronische Datenverarbeitung
(AEDV) angesiedelt. Die Projektentwicklung wurde über den Abschluss von Zielvereinbarungen
geregelt. An dem Projekt sind u. a. drei wissenschaftliche Mitarbeiter beteiligt. In das Projekt ist
auch eine externe Firma, mit enger Verbindung zur Hochschule, mit eingebunden.
Die Systementwicklung ist in mehreren Schritten vorgesehen. Für die Realisierung der Einzelmodule bzw. Funktionen ist ein fester Zeitplan vorgesehen. Eine spätere Vermarktung des Programms wird nicht ausgeschlossen. Einer Kooperation mit anderen Hochschulen gegenüber zeigt
man sich offen. Angebote zur Kooperation soll es auch schon von namhaften CAFM-Anbietern
geben. Da sich das CAFM-System noch in der Entwicklungsphase befindet, ist die TU noch zurückhaltend mit der Weitergabe von detaillierten Informationen.
9
In Hessen werden die dortigen Universitäten gemäß einer Vereinbarung des Landes mit SAP-Software ausgestattet.
Bestandteil der Vertragsvereinbarungen ist dort auch eine CAFM-Software, die von einer SAP-Partnerfirma für diesen
Zweck neu entwickelt werden soll.
51
Eine durchgängige FM-Softwarelösung wurde für die TU nicht für realisierbar gehalten, so dass ein
modulares Konzept gewählt wurde, in das auch vorhandene bzw. fremde Software integriert werden kann.
Die Realisierung ist in vier Phasen vorgesehen, für die jeweils ein Zeitraum von einem halben Jahr
angesetzt wurde. Dabei wird als Ziel zum einen die praktische Nutzung des CAFM-Systems angestrebt, zum anderen die Begleitung des Projektes durch Lehrveranstaltungen.
Die Programmierung der Module wird zum Teil an externe Unternehmen vergeben. Das CAFMSystem verteilt sich auf vier Ebenen:
§
§
§
§
Datenbank als unterste Ebene,
Basisdienste (z. B. CAD-Verknüpfung, Dokumentenverwaltung),
Applikationsserver (Anwendungen wie Flächen- u. Umzugsmanagement),
Client-Software.
Abgesehen von der Datenebene, die durch die Verwendung von ORACLE als Datenbankmanagementsystem festgelegt ist, sollen die anderen Ebenen weitgehend in einer heterogenen Welt
(unterschiedliche Betriebssysteme) funktionieren. Wobei die Clients in der Regel unter Windows
NT laufen. In einem weiteren Schritt ist die Realisierung von Web-Browser basierten Lösungen
vorgesehen. Verteilte Anwendungen sollen zudem eine gute Performanz garantieren. Die Verknüpfung unterschiedlicher Anwendungen erfolgt unter Einbeziehung des CORBA10-Ansatzes.
Bei der Realisierung wurde auf die Möglichkeit zur späteren Anpassung sowie der nachträglichen
Einbindung von Modulen Wert gelegt. Neben den Modulen für spezielle Aufgabenbereiche (z. B.
Bau- und Liegenschaftsdaten, Gebäudereinigung etc.) gibt es solche mit übergreifenden Funktionen (CAD, Dokumentenverwaltung, Systemadministration, Vorgangsmanagement – hier als generelle Unterstützung, d. h. weitreichender als Workflow-Management verstanden).
Die CAD-Daten werden einheitlich im DXF-Format verarbeitet. An der TU wird Autocad 2000 verwendet. Als Grundlage für die Darstellung im CAFM-System dienen die CAD-Zeichnungen (es gibt
immer nur eine gültige Version einer Zeichnung; die Zeichnungen werden in der Dokumentenverwaltung des CAFM-Systems geführt). Datenbank und CAD-Pläne sind direkt miteinander verknüpft
(Räume können direkt in der Zeichnung angewählt werden). So sind beispielsweise Umzüge per
Drag and Drop möglich, wobei das System bestimmte Bedingungen (sind Ausstattung und bauliche Voraussetzungen des künftigen Raumes ausreichend) überprüfen kann. An der TU wird die
Auffassung vertreten, dass ein CAFM-System ohne verknüpfte CAD-Pläne nicht sinnvoll einsetzbar ist.
Realisiert ist das Modul Raum- und Flächenmanagement. Die Grunddaten sämtlicher Räume sind
erfasst (zum großen Teil aus einem vorher genutzten Altsystem übernommen). Etwa 60 % der
Räume an der TU sind derzeit auch als CAD-Daten integriert. Die vollständige Erfassung der Gebäudedaten ist bereits in einem Zeitplan festgelegt worden. Zum Einsatz kommen wird dabei eine
spezielle Softwarelösung, die den Vorgang zusätzlich beschleunigen soll. Bis zum Ende des
Sommersemesters 2002 soll der Vorgang abgeschlossen sein. Alle Daten sollen jeweils tagesaktuell gepflegt werden.
Parallel zur Einführung des jetzigen Systems werden sämtliche Gebäudepläne digitalisiert bzw. die
Gebäude komplett neu ausgemessen, wenn vorhandene Pläne für eine Digitalisierung nicht mehr
geeignet sind.
10
Common Object Request Broker Architecture; CORBA erlaubt unterschiedlichen Applikationen miteinander zu kommunizieren (verteilte Anwendungen, unterschiedliche Betriebssysteme).
52
Zur Informationsausgabe steht im System ein Report-Builder zur Verfügung, der es ermöglicht auf
der Basis einer XML-programmierten Struktur unter Verwendung eines SQL-Query-Builders Abfragen und Reports ohne Spezialkenntnisse selbst zu definieren und in unterschiedlichen Formaten
(z. B. Excel, PDF, HTML) auszugeben.
In der Bearbeitung befinden sich zur Zeit die Module Kabel- und Leitungsmanagement (DVVerkabelung, Stromleitung, Heizungsrohre, Wasser- und Abwasserleitungen etc.) sowie Auftragsabwicklung.
Die Mitarbeiter der Abteilung sind in den CAFM-Einführungsprozess offenbar sehr gut eingebunden, so dass von dieser Seite eine positive Resonanz erreicht wurde.
Innerhalb der Lehrveranstaltungen wurden Projektgruppen (aus Studenten) gebildet, die sich vor
Ort mit den Mitarbeitern der Abteilung zu Gesprächsrunden getroffen haben. Auf diese Weise sind
auch die Ideen dieser Mitarbeiter in die Systementwicklung mit eingeflossen. In den nächsten
Schritten wurden dann die Grob- und Feinklassifikation sowie das Pflicht- und Lastenheft erarbeitet. Die Realisierung der Module erfolgte jeweils im Anschluss an eine Lehrveranstaltungseinheit.
Im Bereich der Lehrplanerstellung und Lehrraumverwaltung wurde bereits ein spezielles System
beschafft, das aber nicht den Anforderungen der TU gerecht geworden ist. Derzeit wird überlegt,
ob ein System beschafft wird, oder ob eine Eigenentwicklung vorgenommen wird.
Eine Übernahme des CAFM-Systems der HU Berlin kann aufgrund der bestehenden Eige nentwicklung ausgeschlossen werden. Generell ist die TU jedoch offen für Kooperationen
mit anderen Hochschulen. Als Voraussetzung dafür wurde jedoch eine ernsthafte Auseinandersetzung mit der Materie sowie eine weitgehende Übereinstimmung mit den Zielsetzungen der TU gefordert. Die Möglichkeit, das CAFM-System in der von der TU entwickelten
Form zu übernehmen, wäre ebenfalls denkbar. Eine Vorführung für interessierte Kreise ließe sich kurzfristig arrangieren.
3.7 Vergleich mit CAFM-Systemen anderer Hochschulen
Im Anhang sind Beispiele aus verschiedenen Hochschulen zum Einsatz der dortigen CAFMSysteme mit den wichtigsten Informationen zusammengestellt, auf die im Folgenden Bezug genommen wird. Die Beispiele stammen vorwiegend aus Nordrhein-Westfalen, da dort aufgrund eines bestehenden Rahmenvertrages, der seitens des Wissenschaftsministeriums mit der Firma
Agiplan Technosoft abgeschlossen wurde, ein nahezu flächendeckender Einsatz des CAFMSystems BuiSy Client Server entstanden ist. Die Daten der BuiSy-Anwender sind (soweit verfügbar) einem Zwischenbericht [2] der IuK-Koordinierungsstelle Nordrhein-Westfalen (Stand Oktober
2001) entnommen. Die Berliner Universitäten (FU und TU) werden im Abschnitt 3.6 insbesondere
unter dem Aspekt möglicher gemeinsamer Vorgehensweisen betrachtet.
Von der Größe her ist die HU-Berlin mit ihren 322 Gebäuden und ca. 18.000 Räumen in erster
Linie mit den Universitäten Aachen, Bielefeld und Münster aus der Auswahl im Anhang zu vergleichen. Vom Umfang der realisierten Funktionen her ist die RWTH Aachen am weitesten fortgeschritten. Dort ist auch eine Web-basierte Nutzung des CAFM-Systems möglich.
Aktuell beteiligt war HIS an der Auswahl und Einführung des CAFM-Systems an den Hochschulen
in Münster. Das dort eingesetzte CAFM-System Kopernikus ermöglicht infolge seines zugrunde
liegenden Konzepts, dass Anwendungen und Datenbank vollständig voneinander entkoppelt, eine
hohe Flexibilität und Offenheit für den Nutzer. Hinzu kommt, dass den Hochschulen alle zur Ergänzung vorhandener sowie Entwicklung weiterer Module notwendigen Informationen und technischen Hilfsmittel zur Verfügung stehen. Nach einer Einführungsphase, in der die einzelnen Module
gemeinsam mit der Anbieterfirma entwickelt wurden, ist vorgesehen, dass die Universität Münster
weitere Funktionen eigenständig realisiert (wobei die Möglichkeit gegeben ist, Beratungsleistungen
53
vom Anbieter hinzuzukaufen). Daraus resultiert ein hohes Maß an Investitionssicherheit. Die Festlegung der erforderlichen Funktionen für die Module erfolgte gemeinsam mit den später für die
Datenerfassung und Pflege verantwortlichen Mitarbeiterinnen und Mitarbeitern. Die Einbeziehung
aller Betroffenen, die bereits während der Systemauswahlphase begonnen wurde, führte zu einer
sehr guten Akzeptanz des CAFM-Systems.
Vom Umfang der realisierten Funktionen her, liegt die HU gleichauf mit dem Durchschnitt der
meisten hier betrachteten Hochschulen. Allerdings beschränken sich die meisten Hochschulen in
der Regel zunächst auf die Realisierung von Funktionen im Bereich der Raum- und Gebäudeverwaltung (ggf. noch ergänzt um die Gebäudereinigung), in den meisten Fällen mit entsprechender
Verknüpfung zu CAD-Daten (Grundrisse). Als Besonderheit für die HU sind zum einen der Anteil
realisierter bzw. genutzter kaufmännischer Funktionen zu nennen, zum anderen der vollständige
Bedienzugriff über Web-Browser bzw. über sog. Thin Clients. Der von nahezu jedem PC aus mögliche Zugriff auf das CAFM-System ermöglicht einen hohen Verbreitungsgrad. Die konsequente
Verfolgung des Client/Server-Ansatzes reduziert hier den Installationsaufwand deutlich. Ein Vergleich der Nutzer an der HU mit der Anzahl der erworbenen Lizenzen bei den hier aufgeführten
Hochschulen zeigt, dass dort in der Regel nur wenige Personen mit der Bedienung der dort eingesetzten CAFM-Systeme befasst sind (ggf. sind in den Angaben noch 1 bis 2 Lizenzen für die Administration abzuziehen).
Der Ansatz der HU Berlin, der sich durch den Einsatz moderner, standardisierter und offener Datenbankstandards sowie mit dem vorgesehenen Einsatz von Java-basierten Thin Clients auszeichnet, dürfte von der „Modernität“ her im Hochschulbereich unübertroffen sein.
Hervorzuheben ist auch die Erfahrung mit dem Einsatz von CAFM-Systemen, da die HU zu den
Hochschulen gehört, die bereits sehr früh mit der Einführung eines CAFM-Systems begonnen haben. Allerdings konnten die Erfahrungen nur wenig genutzt werden, da bisher konzeptionelle Überlegungen einen zu geringen Raum einnahmen und die Akzeptanz des CAFM-Systems zu wenig berücksichtigt wurde. Damit steht die HU zwar nicht allein – eine Reihe von Hochschulen, die
ein CAFM-System einsetzen, sind in der Nutzung auf einzelne wenige Bereiche beschränkt und in
den bisher erreichten Ergebnissen eher unspektakulär – jedoch wird dies nicht dem Anspruch der
Hochschule gerecht.
54
Umsetzung der Empfehlungen
55
4 Umsetzung der Empfehlungen
4.1 Inhaltliche Vorschläge
4.1.1
Organisation der CAFM-Systembetreuung und -weiterentwicklung
Die Akzeptanz bzw. der Einsatz des CAFM-Systems ist je nach betrachtetem Einsatzbereich bzw.
Referat/Abteilung unterschiedlich. In einigen Bereichen (z. B. im Bereich der Haushaltsdatenerfassung der Technischen Abteilung) findet eine intensive Nutzung statt, andere Bereiche (z. B. die
Hochbaureferate) nutzen das CAFM-System kaum. Ein häufiger Kritikpunkt ist die schlechte Qualität der erfassten Daten. Begründet ist diese Kritik u. a. durch fehlende Festlegungen bzw. deren
Durchsetzung, wenn es um die Zuständigkeit für die Pflege der Daten geht.
Die wichtigste Empfehlung, die sich aus dieser Untersuchung ableiten lässt, ist die, organisatorisch eine eindeutige Trennung zwischen DV-seitiger Entwicklung und Betreuung des
CAFM-Systems und inhaltlicher Konzeption durchzuführen.
Grund für diese Empfehlung sind im Wesentlichen drei Aspekte, die im Rahmen der Untersuchung
beobachtet wurden:
§
§
§
Die Arbeitsbelastung des für die Systementwicklung und Betreuung zuständigen Mitarbeiters
ist zu hoch. Obwohl eine Reihe von programmbezogenen Veränderungen erforderlich bzw.
gewünscht sind (Einführung der Oberfläche FM-Works, Vereinheitlichung der Datenbank, Beseitigung der „Altlasten“ aus dem ursprünglichen CAFM-System), ist es nur schwer oder gar
nicht möglich, diese Aufgaben anzugehen, da zeitgleich auch inhaltliche Aufgaben mit bearbeitet werden (z. B. Durchführung einer Umfrage zu den Nutzerwünschen, Absprache der Realisierung von Funktionen jeweils mit den betroffenen Mitarbeiterinnen und Mitarbeitern).
Die Formulierung der Anforderungen geschieht in der Regel wenig strukturiert, direkt zwischen Programmierer und Nutzer. Der auf den ersten Blick unkomplizierte Weg führt zwar
kurzfristig zu schnellen Lösungen, da jedoch eine strukturierte Planung im Rahmen einer
ganzheitlichen Betrachtung des Gesamtsystems unterbleibt, ist der Nutzen dieser Vorgehensweise begrenzt.
Da sehr viele Anforderungen derzeit vom Programmierer allein entschieden werden (z. B. weil
der Nutzer sich nicht selbst äußert), werden Lösungen nicht optimal angepasst an die tatsächlichen Bedürfnissen der Nutzer konzipiert.
Organisatorisch ist die erforderliche Trennung umzusetzen, indem die Verantwortung für
die Weiterentwicklung des CAFM-Systems an das Rechenzentrum abgegeben wird. Der
verantwortliche Mitarbeiter würde organisatorisch dem Rechenzentrum zugeordnet werden.
Die Vorschläge zu einer Kooperation mit anderen Hochschulen oder zur Vergabe von Leistungen an Dritte (s. 3.2.2) bleiben hiervon unberührt.
Vorteil dieser Lösung ist die damit verbundene Eindeutigkeit in der Trennung zwischen Programmierarbeit und inhaltlicher Arbeit. Hinzu kommt, dass eine dauerhafte Unterstützung bei der Weiterentwicklung des CAFM-Systems ohnehin nur aus dem Rechenzentrum möglich ist (abgesehen
von der eher unrealistischen Möglichkeit eine zusätzliche Kraft in der Technischen Abteilung einzustellen). Zudem wäre damit längerfristig betrachtet die Abhängigkeit der Systementwicklung von
nur einer Person aufgehoben bzw. die Schaffung einer Vertretungsregelung möglich. Nachteil dieser Lösung sind die derzeit noch sehr unterschiedlichen System- und Datenbankplattformen, die
für das CAFM-System bzw. die Systeme, die im Rechenzentrum betreut werden, verwendet werden. Danach bestehen zur Zeit keine Berührungspunkte in Bezug auf die genutzten Softwareumgebungen (dort werden vorwiegend Sybase-Datenbanksysteme eingesetzt). Allerdings wird dies
auch als eine Art Generationenproblem gesehen. Bei den studentischen Hilfskräften und jüngeren
Mitarbeitern sind die in der Technischen Abteilung verfolgten Ansätze offenbar weiter verbreitet.
56
Die Realisierung von Systemerweiterungen ist zunächst in Form von Pilotprojekten (Testerfassung
der Daten von geeigneten Einzelgebäuden) jeweils zu prüfen.
Im Folgenden sind die Zuständigkeiten für die im CAFM-System enthaltenen Informationen (z. B.
Raum- und Gebäudedaten) sowie für den weiteren Systemausbau zusammengestellt. Einige der
darin vorgeschlagenen Maßnahmen wurden bereits begonnen:
<
Projektgruppe: Ziel der HIS-Empfehlungen ist es, eine klare Trennung zwischen der Softwareentwicklung bzw. DV-seitigen Betreuung auf der einen Seite und den inhaltlichen Festlegungen des CAFM-Systems auf der anderen Seite zu erreichen. Die Arbeit der Projektgruppe
ist von entscheidender Bedeutung für das Erreichen der gesetzten Ziele. Sie ist für die inhaltliche Organisation und Prioritätensetzung verantwortlich. Die Formulierung und Koordinierung
von Vorgaben zur inhaltlichen Ausgestaltung des CAFM-Systems – wie z. B. die Festlegung
der Anforderungen und Funktionen der Module, die weiterentwickelt bzw. realisiert werden
sollen – fallen künftig ausschließlich in die Zuständigkeit der Projektgruppe. Die Projektgruppe
übernimmt außerdem die Abstimmung und Abnahme der Detailspezifikationen. Sie legt fest,
welche Daten für wen sichtbar bzw. öffentlich sein sollen. Sie ist auch das Gremium, dass die
DV-technische Umsetzung der Vorgaben überprüft und z. B. im Rahmen von Pilotanwendungen abnimmt. Die Projektgruppe stellt bei Bedarf Arbeitsgruppen (unter Heranziehung von
Fachkräften) für die Bearbeitung der jeweiligen Themenschwerpunkte zusammen. Die Mitglieder der Projektgruppe stimmen sich mit ihren jeweiligen Arbeitsbereichen ab, so dass eine
möglichst breite Einbeziehung der betroffenen Sachgebiete bzw. Bereiche erreicht wird. Die
Abstimmung mit der Stelle, die für die Programmierung verantwortlich ist, erfolgt nach Bedarf.
<
Arbeitsgruppen: Zu bestimmten Themen werden Arbeitsgruppen durch die Projektgruppe
gebildet, die die Anforderungen an bestimmte Module formulieren. Die Arbeitsgruppen können
unabhängig von der Projektgruppe tagen. Die Ergebnisse werden in die Projektgruppe durch
direkten Bericht von Mitgliedern der Arbeitsgruppe oder in schriftlicher Form eingebracht.
<
Systembetreuung: Die Systembetreuung wird von der hierfür verantwortlichen Person durchgeführt. Die Abstimmung mit der Projektgruppe erfolgt nach Bedarf in den Sitzungen.
Die Zuständigkeiten für die Datenpflege sind festzulegen:
<
Verwaltungsleiter: Die Verwaltungsleiter sind für die Richtigkeit der Bestandsdaten (der Umfang ist noch festzulegen: Nutzer, Nutzungsart, Raumnummer, Raumbezeichnung etc.) verantwortlich. Änderungen sind entweder der zuständigen Stelle unmittelbar mitzuteilen oder –
sofern die Berechtigung vorhanden ist – selbst einzugeben. Nachteil letzterer Version: Es ist
nicht gewährleistet, dass dies neben der alltäglich anfallenden Arbeit auch immer geschieht.
Daher kann auch die Möglichkeit vorgesehen werden, dass die Verwaltungsleiter die Änderungen (zeitnah) an die Technische Abteilung liefern, wo sie dann eingegeben werden.
<
Bauleiter: Bei den Bauleitern laufen die Informationen zusammen, die die hochbaulichen In formationen beinhalten. Sie sollten daher die gebäudebezogenen Daten zur Verfügung stellen
und pflegen (Flächen, Grundrisse, hochbauliche CAD-Pläne). Letzteres erfordert eine gesonderte Betrachtungsweise. Ein Problem stellt der Informationsverlust dar, der sich durch die Ruhestandsproblematik ergibt. Besonders im Zuständigkeitsbereich der Bauleiter (Hochbaureferate) ist mit dem altersbedingten Ausscheiden einiger Mitarbeiter im Laufe der nächsten Jahre
zu rechnen. Viele Informationen sind nicht dokumentiert, allenfalls in Papierform entsprechend
der Systematik des jeweiligen Mitarbeiters abgelegt. In diesem Bereich besteht Handlungsbedarf.
Von den Aufgaben her, erfordern die CAD-Pläne eine besondere Betrachtung. Hier kann sich eine
Verknüpfung der CAD-Pläne mit der Datenbank als sinnvoll erweisen (zumal dies bereits von einigen Mitarbeitern gefordert wird). Allerdings ist nach dem derzeitigen Stand davon auszugehen,
dass die Datenbank Priorität bei der Umsetzung hat. Zu berücksichtigen ist dabei auch, dass nur
57
für einen kleineren Teil der Gebäude der HU CAD-Pläne in geeigneter Form vorliegen. Im Anschluss an die Aufbereitung und Aktualisierung des CAFM-Systems kann ein einfaches Verfahren
ausgewählt werden, das es ermöglicht, aus den vorhandenen Grundrissen Übersichtspläne (maßstabsgenau) für das CAFM-System zu generieren (s. a. 3.4.7 u. 3.4.9). Der Zugriff auf die vollständigen Pläne ließe sich im Rahmen des Dokumentenmanagements realisieren (z. B. über Viewer).
Die Untersuchung hat auch deutlich gezeigt, dass im Bereich der organisatorischen Abläufe
Defizite bestehen, die sich nicht allein durch den Einsatz eines CAFM-Systems beheben
lassen. Insbesondere der Informationsfluss ließe sich verbessern. Abstimmungsdefizite
zwischen den verschiedenen Zuständigkeitsbereichen sollten eliminiert werden. In einem
ersten Schritt bietet sich zunächst die systematische Zusammenstellung und Dokumentation von Arbeitsabläufen an (s. a. unter 3.4.15), um hier anschließend Optimierungen durchzuführen.
4.1.2
Perspektiven zur Fortentwicklung des CAFM-Systems
Die HU setzt bereits seit mehreren Jahren ein sehr heterogenes CAFM-System ein. Das System
besteht aus mehreren unterschiedlichen Komponenten, die im Laufe der Jahre organisch gewachsen sind. Eine einheitliche Struktur konnte bisher jedoch nicht aufgebaut werden. Das CAFMSystem ist weder modular aufgebaut noch kann es als skalierbar bezeichnet werden. Die Bedienung des Systems ist derzeit vorwiegend mittels Web-Browser über das Internet möglich. Dies
stellt allerdings eine interessante Besonderheit im Vergleich zu kommerziellen Systemen dar.
Für die technische Seite des CAFM-Systems wurden HIS-seitig weitreichende Vorstellungen und
Festlegungen vorgefunden. Die Bewertung stellte sich indes alsschwierig dar, da es sich – im Vergleich zu kommerziellen Systemen – um sehr neue und aufgrund der Orientierung an offenen
Standards in diesem Bereich eher seltene Ansätze handelt. Trotzdem kann eine weitere Fortführung des bisher verfolgten Weges empfohlen werden, da die bisherigen Ansätze einem Vergleich
mit vielen anderen Hochschulen durchaus standhalten können.
Die technische Konzeption des CAFM-Systems bietet genügend Potenzial für einen sinnvollen
zukünftigen Einsatz an der HU. Die zur Zeit bei der Programmierung berücksichtigten Vorgaben:
§
§
§
§
§
§
§
§
Einsatz von (austauschbaren) Standardkomponenten,
modularer Aufbau,
Verwendung von möglichst herstellerunabhängigen Komponenten,
Aufbau einer homogenen (möglichst wenig Fremdprodukte) Umgebung,
Verwendung plattformübergreifender Sprachen und Standards (z. B. XML, Java, SSLVerschlüsselung),
vereinfachte Software Distribution (keine spezielle Client-Software erforderlich),
leicht zu wartende, benutzerfreundliche Anwendungen,
verteilte Anwendungen,
entsprechen einem Anspruch, dem sich auch kommerzielle Anbieter solcher Systeme stellen müssen.
Der Verantwortliche für die Systembetreuung zeigte Möglichkeiten zur weiteren Vorgehensweise
bei der Weiterentwicklung der Software auf. Aus den derzeit verfügbaren Software-Umgebungen
wurde die J2EE-Umgebung ausgewählt (betrachtet wurden auch die Firmen Microsoft: „.NET“,
IBM: „Websphere“ und BEA: „Weblogic“). Argumente für die Auswahl waren u. a.:
§
§
§
der offene Standard (trotz Entwicklung aus dem Hause Sun),
die kostenfreie Verfügbarkeit,
Skalierbarkeit.
58
HIS-seitig kann im Rahmen dieser Untersuchung nicht beurteilt werden, ob die verschiedenen
Software- und Datenbank-Umgebungen für die Realisierung des CAFM-Systems besser oder
schlechter geeignet sind. Zu Empfehlen ist allerdings, dass der eingeschlagene Weg konsequent
weiterverfolgt wird und zu bestimmten Zeitpunkten einer Überprüfung unterzogen wird.
Die Vorgehensweise wurde in Abstimmung mit der Projektgruppe wie folgt festgelegt:
Phase 1: Paralleler Aufbau eines zweiten Systems (neue Datenbank: MySQL), das zunächst
parallel zum bisherigen System betrieben wird. Altes Layout plus Daten werden in ein
neues Layout transferiert. Der Datenabgleich (Aktualisierung) zwischen beiden Systemen erfolgt halbautomatisch (gesteuert über ein Skript).
Phase 2: Installation und Anpassung des JBoss-Applikationsservers (auf dem die J2EEAnwendungen laufen). Der Server ist bereits im Probebetrieb. Der bisher genutzte
Web-Server bleibt bestehen.
Phase 3: Übernahme aller (tatsächlich genutzten) Anwendungen auf das neue System und Abschaltung des alten Systems. Informationen und Anwendungen, die sich noch auf dem
alten System befinden, jedoch in letzter Zeit nicht weiter gepflegt bzw. genutzt wurden,
sind ggf. zu einem späteren Zeitpunkt – nach Festlegung in der Projektgruppe – zu realisieren.
Inhaltlich gestaltet sich die Umsetzung wie folgt:
§
§
Umbau des vorhandenen CAFM-Systems. Die Vorgaben sind vom zuständigen Mitarbeiter in
Abstimmung mit der Abteilungsleitung festgelegt worden. Sie beinhalten die Ablösung der bestehenden ORACLE- durch eine MySQL-Datenbank. Als Entwicklungsumgebung dient J2EE
der Fa. Sun. J2EE definiert einen offenen Standard, um Unternehmenslösungen zu realisieren, indem z. B. Programmschnittstellen zur Verfügung gestellt werden, die eine Einbindung
beliebiger Anwendungen, die diesen Standard unterstützen, ermöglicht. Es sollen damit außerdem sehr kurze Einarbeitungszeiten in die damit realisierten Projekte erreicht werden, so
dass es ohne weiteres möglich ist, auch externe Programmierer in ein solches Projekt zu integrieren. Es wurde zudem die Möglichkeit hervorgehoben, dass mehrere Personen unabhängig voneinander gleichzeitig in einem Projekt tätig sein können, da die Schnittstellen so
definiert sind, dass eine eindeutige Abgrenzung der Aufgaben möglich ist.
Sämtliche Anwendungen im CAFM-System sollen in einer Zwischenebene (angesiedelt zwischen Client = Nutzerprogramm und Server = Datenbanksoftware) als sog. Middleware realisiert werden (dieser Ansatz entspricht auch dem einiger kommerzieller Anbieter, z. B. Kopernikus). Auf diese Weise wird eine Abhängigkeit von bestimmten Datenbanksystemen vermieden sowie die Verwendung einfacher Client-Software (vergleichbar: Web-Browser) ermöglicht.
Der bisher an der HU realisierte Ansatz (FM-Works) geht derzeit noch nicht so weit. Die Systemfunktionen sind hier noch innerhalb der Client-Software realisiert. Die Einbindung der vorhandenen FM-Works-Struktur in das neue CAFM-System soll sich nach Angaben des Programmierers unproblematisch gestalten, da sie kompatibel zu der geplanten Entwicklung ist.
Als Bedienoberflächen werden sowohl eine Web-basierte Darstellung (ähnlich der jetzigen,
jedoch mit grundlegend überarbeitetem Layout) als auch eine mit FM-Works vergleichbare Oberfläche (Thin Client) realisiert. Die Web-basierte Oberfläche ist dabei vorwiegend für gelegentliche Nutzer bzw. als reines Informationsmedium gedacht.
Im Anschluss an Phase 1 ist eine erste Überprüfung der Ergebnisse durch die Projektgruppe vorgesehen. Dabei ist auch festzustellen, ob die Umstellung des Systems in der vorgesehenen Form
leistbar ist. Für den Fall, dass sich hier Probleme ergeben, ist zu prüfen, ob
§
§
eine weitere zeitliche Ausdehnung des Projektes erforderlich ist: Dies erscheint dann angebracht, wenn Verzögerungen aufgrund unvorhergesehener Ereignisse (Krankheit, Bearbeitung
von Aufgaben außerhalb des Projektes, z. B. in Notfällen etc.) entstanden sind;
zusätzliche externe Leistungen eingekauft werden müssen bzw. befristet zusätzliches Personal hinzugezogen wird: Diese Möglichkeit sollte in Betracht gezogen werden, wenn die BearCAFM-System der Humboldt-Universität zu Berlin
§
§
59
beitung der Aufgaben mehr Zeit in Anspruch nimmt als erwartet und die Tätigkeiten innerhalb
einer vertretbaren Einweisungszeit für eine Bearbeitung durch externe Kräfte geeignet sind.
Zur Auswahl stehen hier unterschiedliche Möglichkeiten, die vom Einsatz studentischer Hilfskräfte über das „Ausleihen“ geeigneter Kräfte innerhalb der Universität (z. B. Rechenzentrum)
bis hin zum befristeten Einkauf externen Know Hows reichen können;
eine grundsätzliche Änderung der Vorgehensweise erforderlich ist: Stellt sich heraus, dass der
Aufwand für die Umsetzung so hoch ist, dass der Nutzen in Frage steht, so ist zu überlegen,
ob die Zielsetzungen anzupassen sind. Der Umfang der zu realisierenden Funktionen könnte
in einem ersten Schritt reduziert werden. Auch könnte der Rückgriff auf kommerziell verfügbare Lösungen für bestimmte Funktionen (Auswertungstools, Datenbanktools) oder Aufgaben
(im Bereich der Lehrraumverwaltung) in Frage kommen;
das Projekt in dieser Form nicht mehr weiter verfolgt wird: Für den Fall, dass der Aufwand sich
als derart hoch herausstellt, dass der Zeitpunkt der Umsetzung nicht mehr abzuschätzen ist,
die Ergebnisse unbefriedigend sind oder besondere Ereignisse die Umsetzung gefährden, ist
die Einführung eines kommerziellen CAFM-Systems anzubieten. In einem solchen Fall sind
die in der Projektgruppe zu leistenden Vorarbeiten genauso zu erbringen, dass ein zügiger
Systemumstieg erreicht werden kann. Die Ausschreibung sollte die Übernahme der im derzeitigen CAFM-System genutzten Daten beinhalten. Denkbar wäre auch eine Kooperation mit einer anderen Hochschule (z. B. TU Berlin, vgl. 3.6.2).
Nach Abschluss der Umsetzungsphase ist der Projektstand wiederum durch die Projektgruppe zu
überprüfen.
Die Vergabe von Programmieraufgaben an Externe ist infolge der dafür erforderlichen Aufstellung
eines Pflichtenheftes im Rahmen der Umstellungsphase zu aufwändig. Hinzu kommt, dass sehr
viele kleinteilige Aufgaben, die ein gute Detailkenntnis des vorhandenen CAFM-Systems voraussetzen, zu erledigen sind.
Denkbar wäre allerdings die (ggf. auch zeitweilige) Unterstützung durch einen Programmierer. Die
Möglichkeit hierzu auf den Personalüberhang der HU zuzugreifen, wird als problematisch angesehen, da Kräfte mit entsprechender Qualifikation fehlen bzw. nicht kurzfristig zur Verfügung stehen
(Personalüberhang ist nicht gleichbedeutend mit freier Verfügbarkeit der Personen, ggf. ist die
Stelle lediglich mit einem KW-Vermerk versehen). Als mögliche Lösung wurde das sog. XPProgramming (extreme programming) vorgeschlagen, eine erst jüngst entstandene Programmiertechnik, die entsprechend dem Motto „Probieren geht über studieren“ Lösungen stückweise in
laufender Abstimmung mit dem Nutzer erarbeitet (eine Projektierung im herkömmlichen Sinne gibt
es nicht mehr). Inwieweit hierdurch Unterstützung erreicht werden kann, lässt sich jedoch nur
schwer beurteilen. Denkbar wäre allerdings in der Umstellungsphase auch solche Methoden zunächst probeweise mit einzubeziehen, um deren Tauglichkeit zu überprüfen. Die entsprechenden
Schritte sind mit der Projektgruppe abzustimmen, die insbesondere die Verhältnismäßigkeit (Aufwand zu Nutzen) abschätzen kann.
Nach der Umsetzung soll sich das CAFM-System in einem Zustand befinden, der es auch für externe Programmierer möglich macht, in die Weiterentwicklung einzusteigen. Außerdem erhöht sich
durch den Middleware-Ansatz die Sicherheit gegen unbefugte Zugriffe erheblich. Ein Zugriff von
außen auf die Datenbank, wie er bei dem jetzigen System noch denkbar wäre, ist dann nicht mehr
möglich.
Die Problematik, die mit der Umsetzung einer derart komplexen Aufgabe verbunden ist, soll hier
nicht verschwiegen werden. Die ganze Umsetzung hängt hier an einer Person. Insofern ist eine
funktionsfähige begleitende Kontrollinstanz (in Form der Projektgruppe) unabdingbar. Sie hat die
Möglichkeit ggf. rechtzeitig einzugreifen, wenn sich herausstellt, dass die anvisierten Ziele nicht
erreicht werden bzw. unvorhergesehene Probleme auftauchen.
Allerdings entstehen auch beim Einsatz kommerzieller CAFM-Systeme Abhängigkeiten, die sich
selbst bei namhaften Herstellern im Falle einer Änderung der Firmenstrategie negativ auswirken
60
können. Genannt sei an dieser Stelle das Beispiel SpanFM. Der Vertrieb des Programms, das in
der deutschsprachigen Version u. a. der Fa. Siemens Landis & Staefa angeboten wurde und auch
in einigen Hochschulen zum Einsatz kam, wurde Ende 2000 eingestellt. Eine weitere Unterstützung gab es nicht mehr. Den betroffenen Hochschulen bleibt letztendlich nur der Umstieg auf ein
neues CAFM-System. Da kommerzielle CAFM-Systeme häufig proprietäre Komponenten beinhalten, ist bei der Migration des Datenbestandes in ein neues System mit einem hohen Aufwand zu
rechnen.
4.1.3
Zusammenarbeit mit anderen Berliner Hochschulen
Angesichts der derzeitigen Finanzsituation des Landes Berlin stellt sich die Frage, ob nicht eine
stärkere Zusammenarbeit der Berliner Universitäten beim DV-Einsatz im FM-Bereich stärker vorangetrieben werden sollte. Der hier aufgezeigte momentane Stand an der FU und TU Berlin (vgl.
Abschnitt 3.6) zeigt zwar deutlich, dass die gemeinsame Festlegung auf ein CAFM-System für die
Hochschulen – wie z. B. von einigen Hochschulen in Niedersachsen praktiziert11 – derzeit nicht in
Frage kommt; dies schließt jedoch eine Zusammenarbeit mit dem Ziel einer Vereinheitlichung der
Systemmerkmale nicht aus. Vorgeschlagen wird daher die Einrichtung einer festen Gesprächsrunde auf der Leitungsebene (Technische Abteilungen), an der auch weitere interessierte Hochschulen (in Frage kommen die Medizinische Fakultät/Charité sowie die Fachhochschulen) teilnehmen
können sollten. Zusätzlich könnte in einem nächsten Schritt ein fachlicher Austausch auf Projektgruppenebene initiiert werden.
4.2 Zeitplanung für eine Umsetzung der Empfehlungen
Mit der Festlegung zeitlicher Vorgaben in Verbindung mit der Möglichkeit, die weitere Umsetzung
zu festgelegten Zeitpunkten zu überprüfen, wird die Gefahr bei der Umsetzung zu scheitern, deutlich verringert.
Im Anhang (Zeitplan) ist der zeitliche Ablauf der Arbeiten dargestellt. Es sind dabei jeweils zwei
Aufgabenbereiche zu unterscheiden:
1. die inhaltliche Vorbereitung/Formulierung der Anforderungen,
2. die Umsetzung der Vorgaben.
Eine gesonderte Betrachtung ist dem Systemumbau gewidmet (s. 4.1.2). Dieser hat Vorrang vor
der Realisierung weiterer Aufgaben. Die inhaltliche Vorbereitung bzw. Formulierung der Anforderungen kann dagegen parallel betrieben werden.
Die Umsetzungsphase für den Systemumbau wurde auf ein halbes Jahr (April bis Ende September
2002) festgelegt. Für die ersten drei Monate (Phase 1) ist eine grobe Liste der zu bearbeitenden
Aufgaben durch den verantwortlichen Programmierer aufzustellen. Im Anschluss an Phase 1 (Ende Juni 2002) soll die erste Überprüfung der Ergebnisse durch die Projektgruppe erfolgen. Nach
Abschluss der Umsetzung (Phase 2 und 3), die für Anfang Oktober vorgesehen ist, erfolgt die
nächste Überprüfung durch die Projektgruppe.
Ab Oktober 2002 kann dann die Entwicklung weiterer Funktionen bzw. Module gemäß Vorgabe
durch die Projektgruppe vorgesehen werden. Die Umsetzung beinhaltet diejenigen Module und
Funktionen, die in der Projekt- bzw. in den Arbeitsgruppen entsprechend vorbereitet worden sind
(Definition der Anforderungen ist erfolgt, Verantwortlichkeiten für die Datenaufnahme und die Datenpflege sind geregelt).
11
Federführend bei dem in Niedersachsen durchgeführten Verfahren zur Ausschreibung eines CAFM-Systems waren die
Universitäten Oldenburg und Osnabrück.
61
Der im Anhang vorgegebene Zeitplan ist nicht als strenges Ablaufschema zu sehen. Viele Faktoren (z. B. der tatsächliche Aufwand für die Umsetzung des jetzigen CAFM-Systems auf die neue
Systemumgebung) lassen sich derzeit noch nicht hinreichend genau abschätzen. Wichtig ist daher, dass der Zeitplan in den Projektgruppensitzungen laufend aktualisiert wird. Aufgabenbereiche,
die sich nicht an der Bearbeitung beteiligen, sollten nach entsprechender Aufforderung aus dem
Plan herausgenommen werden. Es wird empfohlen, ggf. den Vorgang bzw. die Gründe schriftlich
festzuhalten, damit auf künftige Nachfragen der Hochschulleitung reagiert werden kann.
4.3 Fazit
Die Kernaussagen der Empfehlungen, die aus der Untersuchung resultieren, sind im Folgenden
noch einmal zusammengefasst.
Organisatorisch:
§
DV-seitige Entwicklung und Betreuung des CAFM-Systems sowie inhaltliche Konzeption sind
eindeutig zu trennen.
§
Die Verantwortung für die Weiterentwicklung des CAFM-Systems kann an das Rechenzentrum abgegeben werden.
§
Aufgrund der bestehenden Defizite im Bereich der organisatorischen Abläufe, die sich nicht
durch den Einsatz eines CAFM-Systems beheben lassen, sind geeignete Maßnahmen zur
Dokumentation und Optimierung empfehlenswert.
Technisch:
§
Wegen der bereits geleisteten Vorarbeiten sowie der professionellen Ansätze des eigenentwickelten Teils des CAFM-Systems der HU, ist eine Weiterentwicklung auch im Hinblick auf die
Akzeptanz durch die bisherigen Nutzer des Systems zu empfehlen.
§
Allerdings ist das Risiko, dass hier mit einer „Eigenentwicklung“ verbunden ist, wegen der
Personenabhängigkeit nicht unerheblich. Dies gilt unabhängig von der organisatorischen Zuordnung der Programmieraufgaben.
§
Der Umbau des vorhandenen Systems in eine Richtung, die maßgeblich auf offenen Standards basiert und in geeigneter Form dokumentiert ist, soll dazu dienen, Investitionssicherheit
zu schaffen.
Umsetzung:
§
Eine Überprüfung der Umsetzung ist in zwei Schritten vorzusehen, so dass ggf. ein rechtzeitiges Eingreifen möglich ist durch
§
§
§
Überprüfung der terminlichen Vorgaben,
Zukauf externer Leistungen,
Änderung der Vorgehensweise (bis hin zum Kauf eines kommerziellen Systems).
Noch im Jahre 2002 sollte dann evaluiert werden, ob der von der HU beschrittene eigene Weg
weiterhin Aussicht auf Erfolg bietet.
Außerdem sollte eine Zusammenarbeit mit anderen Berliner Hochschulen beim DV-Einsatz im FMBereich angestrebt werden.
62
Literatur
63
Literatur
[1]
Krüger, Gabriela; Mammel, Martin und Schwalgin, Ewald-Joachim: Das Liegenschafts- und
Gebäudemanagement der Technischen Abteilung der Humboldt-Universität zu Berlin (HU). –
In: HIS Kurzinformation Bau und Technik, Nr. B2/2001, S. 19–30. HIS HochschulInformations-System GmbH, März 2001.
[2]
Mengel, Roger u. Neuheuser, Martin: Einsatz des Gebäudemanagementsystems BuiSy in
den Hochschulverwaltungen des Landes Nordrhein-Westfalen – Zwischenbericht für die
Gutachter des DFG; Stand: Oktober 2001.
[3]
Arbeitskreis Maschinen- und Elektrotechnik staatlicher und kommunaler Verwaltungen (AMEV): Hinweise zur Ermittlung des Personalbedarfs für das Betreiben der technischen Anlagen in öffentlichen Gebäuden (Personalbedarf 2000). – Berlin 2000.
[4]
HIS Hochschul-Informations-System: Programmmodul Lehre, Studium, Forschung (HISLSF).
– In: HIS DV-News Nr. 1, S. 8. Februar 2001.
64
Literatur
65
Glossar
Glossar
Applet
In der Regel ein Programm, dass in der Programmiersprache Java entwickelt wurde
und in Verbindung mit einem Java-fähigen Internet-Browser eingesetzt werden
kann.
ASCII
American Standard Code for Information Interchange: Häufig verwendeter Code zur
Datenübertragung, mit dem sich 128 Zeichen (in der erweiterten Form 256 Zeichen)
direkt kodieren lassen. Der ASCII-Standard wurde in den 60er Jahren zur Zeit der
Datenübertragung mittels Telex entwickelt. Für jedes Zeichen gibt es einen Zahlencode, der es ermöglicht, zwischen verschiedenen Systemen Texte auszutauschen.
Backbone
Primärer Verkabelungsbereich (oberste Verkabelungsebene in einem lokalen Netzwerk).
CAFM
Computer Aided Facility Management: DV-unterstütztes Facility Management.
CSV
Comma Separated Variables: CSV-Dateien sind ASCII-Dateien, die häufig benötigt
werden, um den Inhalt einer Datenbank (z.B. dBASE, ACCESS, SQL-Datenbank)
zu extrahieren und in eine andere Datenbank wieder einzulesen. Die Datensätze
werden dabei in der Regel durch Zeilen getrennt, die Felder (Zellen) z. B. durch
Komma, Semikolon etc.
DXF
Drawing Exchange Format: Datenformat für vektorisierte Grafikinformationen (z. B.
aus CAD-Programmen), das von den meisten CAD- und FM-Programmen unterstützt wird.
EVU
Energieversorgungsunternehmen
ftp
file transfer protocol: Protokoll bzw. darauf basierender Internet-Dienst zur Übertragung von Dateien zwischen verschiedenen Computern bzw. Servern über das Netz.
GAEB
Gemeinsamer Ausschuss für Elektronik im Bauwesen: Hinter dem GAEB steht ein
normierendes Gremium für den gesamten Baubereich.
GAEBSchnittstelle: genormte Schnittstelle, die dem elektronischen Datenaustausch von Leistungsverzeichnissen ermöglicht.
GLT
Gebäudeleittechnik: Bestandteil einer Gebäudeautomation, mit der Aufgabe des
Überwachens und Führens von Betriebstechnischen Anlagen.
HISFSV-GX HIS-Software zur Finanz- und Sachmittelverwaltung mit den Untermodulen: Beschaffung (BES), Mittelbewirtschaftung (MBS), Inventarisierung (IVS) und Materialwirtschaft (MAT). HISFSV kann als PC-Version für den Einzelplatzbetrieb (bzw. beschränkten Netzbetrieb) oder als Client-Server-Version eingesetzt werden.
HISMBS
HIS-Software zur Mittelbewirtschaftung (Haushaltsüberwachung, Buchungen, Kostenarten- und Kostenstellenrechnung) als UNIX- und PC-Version verfügbar.
HTML
Hypertext Markup Language: Standardisierte Seitenbeschreibungssprache für
WWW-Seiten im Internet bzw. Intranet (genormt in ISO 8879).
66
Glossar
http
hypertext transfer protocol: Kommunikationsprotokoll zwischen Web-Server und
Web-Browser zur Übertragung von HTML-Daten.
HU
Humboldt Universität
IuK
Informations- und Kommunikationstechnik
J2EE
Java 2 Enterprise Edition: Offener Standard zur Realisierung von Unternehmenslösungen, der die Einbindung beliebiger Anwendungen, die den Standard unterstützen, ermöglicht.
Java
Java ist eine von der Firma SUN entwickelte Programmiersprache, die für Anwendungen im Internet häufig Verwendung findet. Zur Ausführung von JavaProgrammen wird eine „Java Virtual Machine“ benötigt. Diese ist in den verbreiteten
Browsern eingebaut, so dass sich Java-Programme auf nahezu jedem Computer,
unabhängig von dessen Hardware oder Betriebssystem ausführen lassen.
JDBC
Java Data Base Connectivity: JDBC ist eine von der Fa. Sun entwickelte Datenbankschnittstelle. Damit ist es möglich auf vergleichsweise einfache und effektive
Art aus Applets heraus auf externe Datenbanken zuzugreifen.
JNLP
Java Network Launching Protocol: erlaubt es dem Nutzer Java-Programme oder Applets direkt aus dem Internet (ohne Verwendung von Browsern) auszuführen.
LAN
Lokal Area Network: Lokales Datennetz
Middleware Software, die verschiedene Applikationen verbindet, z. B. Web Server und Datenbanken.
MySQL
MySQL ist ein relationales Datenbank Managementsystem (SQL-Datenbank), welches von der Firma T.c.X. DataKonsult (www.tcx.se) in Schweden entwickelt wurde
(s. a. www.mysql.com).
ODBC
Open Data Base Connectivity: Offene Datenbankverbindung, die den Zugriff auf
Datenbanken erlaubt, ohne dabei zu berücksichtigen, aus welchem Programm oder
von welchem Betriebssystem aus der Zugriff erfolgt. ODBC beruht auf einer Spezifikation, die von der SQL-ACCESS-Group (SAG) unter Federführung von Microsoft
ins Leben gerufen wurde. ODBC-Treiber ermöglichen beispielsweise den Zugriff
unter MS-Windows auf Oracle-Datenbanken.
ORACLE
Relationales Datenbanksystem (Oracle Deutschland GmbH bzw. Oracle Corporation), das die Abfragesprache SQL PLUS nutzt und über eine Programmierschnittstelle mit der Möglichkeit zum Aufbau verteilter Datenbanken verfügt (s. a.
www.oracle.de).
PDF
Portable Document Format: verbreitetes Dateiformat (De facto-Standard) der Fa.
Adobe zum Austausch von Dokumenten. Diese können mit dem kostenlos erhältlichen Acrobat Reader gelesen werden.
Port
Schnittstelle, Verbindungsmöglichkeit des PCs mit Peripheriegeräten; bei TCP/IPAnwendungen werden die Kommunikationspartner neben der IP-Adresse über die
Port-Nummer identifiziert. Letztere legt den Dienst auf dem angesprochenen Rechner fest (z. B. ftp-Anwendungen sind unter Port 21, http-Anwendungen unter Port 80
erreichbar).
67
Glossar
RTF
Rich Text Format: spezielles Dateiformat, das für den Datenaustausch formatierter
Texte zwischen verschiedenen Textverarbeitungsprogrammen entwickelt wurde.
SQL
Structured Query Language: Abfragesprache für Datenbanken, die in den 70er Jahren des 20. Jahrhunderts von der Firma IBM entwickelt wurde (ursprünglich für die
relationale Datenbank DB2). Mit ANSI-92 SQL wurde ein Standard geschaffen, der
es erlaubt Datenbanken, die SQL unterstützen, zu bearbeiten.
SSL
Secure Socket Layer: Von den Firmen Netscape und RSA Data Security entwickelte
Technik mittels der ein Web-Client den Server authentifizieren kann und der Datenverkehr zwischen beiden verschlüsselt wird.
TCP/IP
Transmission Control Protocol/Internet Protocol: weit verbreitetes Protokoll zur Verbindung heterogener Systeme (z. B. über das Internet).
Thin Client
preisgünstiges System (z. B. Endgerät) in einer Server-basierten NetzwerkUmgebung. Thin Clients benötigen weder leistungsstarke Prozessoren noch große
Speicherkapazitäten, da die Applikationen auf einem zentralen Server liegen. Thin
Clients sind für den Einsatz in Application Server Umgebungen konzipiert.
Trigger
datenbankspezifische Programme, mit denen spezielle Funktionalitäten realisiert
werden können. Dem Vorteil, damit bestimmte Lösungen elegant ausführen zu können, steht der Nachteil entgegen, beim Umstieg auf neuere Versionen oder gar auf
ein anderes Datenbank-System (jede Datenbank hat ihre eigene „Programmiersprache“), diese Programme ggf. neu schreiben zu müssen.
VPN
Virtual Private Network: dient der sicheren Übertragung von Daten über nichtsichere Verbindungen. Hierzu wird ein virtuelles Netzwerk z. B. mit Hilfe eines geeigneten Protokolls aufgebaut und physisch dazu das „normale“ Netzwerk (z. B. Internet) genutzt.
XML
eXtensible Markup Language: seit 1998 als Standard des W3C verabschiedete
Sprache für Web-Anwendungen, die unter Beteiligung von Adobe, Hewlett Packard,
Microsoft, Netscape und Sun entwickelt wurde. Sie ist geeignet, um strukturierte
Daten (Tabellen, Verzeichnisse, Parameterlisten, technische Zeichnungen etc.) in
einer Textdatei darzustellen. XML ist lizenzfrei und plattformunabhängig verfügbar.
68
Glossar
69
Anhang
Anhang
70
Anhang
Anhang
71
Anhang
Befragung der Mitarbeiterinnen und Mitarbeiter der Humboldt Universität
Die folgenden Informationen sind aus den Protokollen der Befragung (September, Oktober und
November 2001) zusammengestellt.
72
Anhang
Ausgefüllt von:
Nr.
Kategorie
1 Wünsche;
Kritik
2
3
4
5
Wünsche
Wünsche
Wünsche
Kritik
6 Sonstiges
7 Kritik
8 Kritik;
Sonstiges
9 Kritik
Datum:
Woher
(Anwender- Bezeichnung
gruppe)
TA; VL
Direkte Verbindung zur Haushaltsabteilung (Tagesaktualität);
Keine Rückkopplung vom FM-System zur Haushaltsabteilung
vorhanden
VL
Zugriff auf HIS-MBS (lesend)
TA
Austausch von Daten mit Haushaltsabteilung umständlich
VL
Direktes Übermitteln von Bestellungen an die Haushaltsabteilung
TA
Grundstücks- und Gebäudedaten werden teilweise losgelöst vom
FM-System von den Nutzern gepflegt
TA
mangelnde Akzeptanz des Systems, dadurch Insellösungen
TA
System genügt nicht den Anforderungen (dürftig illustrierte
Datenbank, Daten im System nicht ausreichend, Eignung allenfalls
zur groben Information)
TA
Fehlende Kontrollkapazitäten; Kontrolle der Leistungen
TA; VL
10 Verbess.
TA
11 Verbess.
12 Verbess.
VL
TA
13 Kritik
14 Kritik
15 Verbess.
VL
TA
TA; VL
16 Verbess.
TA
17 Kritik
TA
18 Sonstiges
TA
19 Verbess.
TA
20
21
22
23
VL
TA
TA
VL
Verbess.
Kritik
Kritik
Verbess.
24 Kritik
25 Kritik
26 Kritik
TA
TA
TA
27 Kritik
SO
28 Kritik
TA
29 Verbess.
VL
30 Verbess.
31 Verbess.
32 Verbess.
TA
SO
VL
33 Verbess.
TA
34 Verbess.
TA
35 Wünsche
36 Wünsche;
Verbess.
37 Kritik
38 Wünsche
39 Wünsche
40 Kritik
VL
TA; VL
TA
TA
TA
TA
Daten nicht korrekt (geringes Vertrauen, Verlässlichkeit der Daten);
Datenerfassung und Pflege sind schlecht (Korrektur von
gemeldeten fehlerhaften Daten dauert zu lange; z. T. keine
Vertretungsregelungen); Verbesserung der Datenpflege; schnellere
Durchführung von (gemeldeten) Änderungen
Aktualisierung von Daten (z. B. Flächen) terminlich festlegen
(periodische Änderungen reichen aus, alte Daten müssen
gesichert werden)
Rückmeldung bei durchgeführten Korrekturen
Warnmeldungsanzeige bei Änderungen (bezieht sich auf die bisher
praktizierte Lösung mit zusätzlichen Excel-Dateien)
nicht alle Gebäude sind erfasst
Verantwortlichkeiten für die Daten fehlen
Verantwortlichkeit der Bauleiter für Flächen- und Belegungsdaten
und deren Aktualisierung
regelmäßige Meldung der Daten von baulichen Änderungen
(Bauleiter und Verwaltungsleiter)
unzureichende Weiterleitung von baulichen Veränderungen durch
die Bauleiter
Alterstruktur; Ruhestandsproblematik: "Wissen geht verloren";
Überalterung der Kollegen (Bauleitung); Informationsverlust bei
Ausscheiden
Wertsteigernde Um- und Ausbauten müssen (von den Bauleitern)
mitgeteilt werden
Bessere Betreuung der Objekte durch Bauleiter
Systemwartung ist nicht ausreichend gewährleistet
Betreuung nur durch eine Person problematisch
Unterstützung bei Vermietung an Externe (Mustermietverträge,
Verwaltung der Vertragsdaten)
Exakte Angaben zu Reinigungsflächen fehlen
Raumbuchblätter sind bereits erarbeitet, aber nicht eingesetzt
Wissenschaftliches Potenzial der Universität wird nicht
ausgeschöpft
Informationen nicht immer aktuell (z. B. Arbeitsschutz,
Brandschutz)
Informationaustausch bei kleineren Änderungen am Gebäude
funktioniert in der Regel nicht (Nutzerumbauten sind zusätzliche
Fehlerquelle), Vor-Ort-Begehung erforderlich
Bessere Information über das System (war z. T. erst spät bzw.
durch Zufall bekannt geworden)
weiterer Ausbau des CAFM-Systems; mehr Nutzer gewinnen
System sollte an mehreren Hochschulen eingesetzt werden
Informationsnutzung für Sicherheits- und Brandschutzbeauftragte
ermöglichen
Wegfall der bislang noch notwendigen Excel-Dateien (z. B. zum
Datenabgleich mit den Fakultäten)
Spezielle FM-Gruppe (ca. 10 Personen) beim Verwaltungsleiter
angesiedelt
Anschluss an das Verwaltungsnetz der zentralen Verwaltung
Maßstäbliche (aktuelle) Grundrisse zur Verfügung stellen; exakte
(maßstäbliche) Erfassung des Gebäudebestandes (CAD)
Grundrisse stehen nur schematisch zur Verfügung
CAD-Pläne zur Verfügung stellen; Zugriff auf CAD-Pläne im Netz
Papierpläne digitalisieren
selten stimmen Zeichnungen und tatsächliche Gegebenheiten
überein (Pläne nicht immer stimmig)
Bereich
Bewertung
Anmerkung
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
73
Anhang
40 Kritik
TA
41 Verbess.
TA
42 Verbess.
43 Kritik
VL
TA
44 Kritik
45 Sonstiges
TA; VL
TA
46 Kritik
TA
47 Verbess.
48 Kritik
49 Verbess.
TA
TA
TA
50 Wünsche
TA
51 Wünsche
52 Wünsche
TA; VL
TA; VL
Weiterer Ausbau/Verbesserung des CAFM-Systems der HU
Organis.
Kapazitäten zur Datenerfassung und -pflege zur Verfügung stellen Organis.
53 Verbess.
VL
dezentrale Pflege der Raumbestandsstatistik; Korrekturmöglichkeit Organis.
der Raum- und Gebäudedaten dezentral (bei den Fakultäten)
54 Verbess.;
Sonstiges
VL
55 Verbess.
56 Sonstiges
57 Wünsche
SO
SO
VL
Ablehnung von stärkerer Dezentralisierung der
Organis.
Verwaltungsaufgaben; keine weitere Dezentralisierung der
Datenpflege (Arbeitsaufwand)
Kaum verläßliche Übersichten über Raumstruktur der Universität
Organis.
Unterschiedliche Zuständigkeiten in der Einzelraumverwaltung
Organis.
Einrichtung einer zentralen Störungsannahme bzw. Störmeldestelle Organis.
58 Verbess.
59 Verbess.
TA
SO
60
61
62
63
64
VL
VL
VL
VL
VL
Sonstiges
Wünsche
Wünsche
Wünsche
Verbess.
65 Verbess.
66 Verbess.
TA
VL
67 Kritik
68 Verbess.
TA
SO
69 Verbess.
VL
70 Sonstiges
SO; VL
71 Sonstiges
72 Sonstiges
TA
VL
73 Sonstiges
74 Sonstiges
TA
TA
75 Sonstiges
76 Sonstiges
TA
TA
77 Sonstiges
78
79
80
81
82
selten stimmen Zeichnungen und tatsächliche Gegebenheiten
überein (Pläne nicht immer stimmig)
Aktualisierung der CAD-Zeichnungen entweder im Referat Planung
oder durch zu benennende gesonderte Kraft
Kennzeichnung der Rettungswege in Etagengrundrissen
im Extremfall erfolgt zur Zeit eine doppelte Pflege der Zeichnungen
(eingescannte Pixelgrafiken und CAD-Pläne)
ungenaue Pläne durch Einscannen
Fehlende Daten vom Standort Adlershof (z. B. noch keine
Vektorgrafiken)
Grundrissänderungen (durch Baumaßnahmen) können nicht durch
die Bauleiter eingegeben werden
Eingabe von kleineren Planungen bzw. Änderungen (CAD-Pläne)
Schwierige Handhabung von CAD-Dateien (DXF)
Dokumentation aller Maßnahmen, die einen Bauantrag erfordern in
den Bestandsplänen
Fortschreibung der Kosten nach Kostenarten und Verknüpfung zur
Honorarermittlung (anrechenbare Kosten) für die Kostenkontrolle
über vorhandene Störungshotline informieren
Rückmeldung nach erfolgter Störungsmeldung
(Bearbeitungsstatus)
Zuständigkeiten für Mängelberichte nicht geklärt
Unterstützung der strategischen Planung im Drittmittelbereich
Unterstützung der Vollkostenrechnung im Drittmittelbereich
Kapazitätsberechnungen unterstützen
Schaffung eines einheitlichen Raumnummernschlüssels;
Sortierung von Raumnummern mit Buchstaben ungünstig
namentliche Zuordnung von Räumen
eingeschränkter Datenzugriff (Zugriff nur für Bereich bzw. Fakultät)
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Datenpräsentation im Internet problematisch (unbefugter Zugriff) Organis.
es sollte genau festgelegt werden, welche Informationen für
Organis.
Außenstehende zugänglich sind
Abkürzungen erläutern (auch für Nichtfachleute, z. B. FF, VF etc.) Organis.
Organis.
TA
Aktualität des Vorlesungsverzeichnisses der Uni garantieren (ggf.
Möglichkeit zur Bearbeitung)
generell fehlendes Interesse an PC´s
Zusammenarbeit zwischen Studien-, Bau- und Technischer
Abteilung verbessern
Nicht-Weitergabe von Informationen schafft Probleme
Einsatz des CAFM-Systems könnte bei Zuordnung von Flächen zu
den Hausmeistern sowie ausgewogener Flächenzuordnung zu den
Bauleitern hilfreich sein
keine geschlossenen Informationskreisläufe (organisatorisch)
mehr Zeit für organisatorische Betreuung des Facility
Managements erforderlich
Hochbauliche Daten sind wichtiger als Daten der Betriebstechnik
Sonstiges
Sonstiges
Sonstiges
Sonstiges
Sonstiges
TA
VL
SO
SO
SO
Arbeitsorganisatorische Defizite
Fehlende Kundenorientierung
Vermietung von Räumen an Dritte
Neuberufungen könnten flächenmäßig reduziert werden
Ausweitung der privatwirtschaftlichen Aktivitäten (Einnahmequelle)
Organis.
Organis.
Organis.
Organis.
Organis.
83 Sonstiges
84 Wünsche;
Verbess.
85 Verbess.
TA
TA
hoher Sanierungsbedarf bei der technischen Ausstattung
Grundrisse/CAD-Pläne mit Raumdaten verknüpfen
Organis.
Anwendung
VL
Qualitätsverbesserung der Grundrisse (Ausdrucke als Aushang
nutzbar)
Anwendung
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
Organis.
74
Anhang
86 Wünsche
TA
87 Verbess.
SO; TA; VL
88 Wünsche
VL
89 Wünsche
VL
90
91
92
93
94
95
96
Wünsche
Wünsche
Kritik
Wünsche
Wünsche
Wünsche
Wünsche;
Sonstges
97 Kritik
TA
TA
TA
VL
VL
TA
SO; TA; VL
98 Verbess.
VL
99 Verbess.
TA
TA
100
101
102
103
104
Wünsche
Wünsche
Wünsche
Wünsche
Wünsche
TA
VL
SO
TA
TA
105
106
107
108
109
110
Wünsche
Wünsche
Wünsche
Wünsche
Kritik
Verbess.
VL
SO; VL
VL
TA
SO
VL
111 Wünsche
112 Wünsche
113 Verbess.
VL
VL
SO
114 Kritik
115 Kritik
116 Verbess.
TA
TA
SO
117 Verbess.
TA; SO
118 Verbess.
TA
119 Verbess.
TA
120 Kritik
121 Verbess.
122 Verbess.
TA
TA
TA
123 Verbess.
124 Verbess.
VL
SO
Raumdatenkatalog mit Angaben zu technischer und sonstiger
Ausstattung; Informationen über Raumausstattung (z. B.
Bodenbelege) sind nicht vorhanden
Daten, die erfasst werden sollten: Erfassung der
Raumausstattungen, z. B. Vernetzung möglich, vorhandene
Stellfläche für Aktenschränke (ggf. auch Foto); Grunddaten
(konstruktiv) wie Verkehrslast, Türlaibungstiefen,
Heizkörpernischen, Raummaße; Gebäudereinigungsdaten;
Qualitätskriterien, z. B. Zustand der Räume, Verkabelung,
Informationen über Steckdosen, DV-Anschlüsse; Anzahl der
möglichen Mitarbeiter in einem Raum, Maximalbelegung von
Seminarräumen; Außenanlagen (z. B. Standsicherheit Bäume)
Informationen zu LAN-Verkabelung, Netzsegmenten und anschlüssen
Informationen über (Strom-)Verkabelung in den Räumen
bereitstellen
Unterstützung beim Vertragsmanagement
Baudatenbank für Kalkulation und Ausschreibungsvorbereitung
Baukosten im System nicht verfügbar
Energie- und Medienverbrauchsdaten zur Verfügung stellen
Anlagenstammdaten vervollständigen
Telefondaten aktualisieren
Umzüge unterstützen; Unterstützung bei der Umzugsplanung
(Umzüge u.a. nach Adlershof sind zu erwarten, z. B. RZ)
längere Historisierung von Daten (z. T. bis zu 10 Jahren gesetzlich
vorgeschrieben) erforderlich.
Interne Nutzung der Datenbank (Erfassung spezieller Merkmale,
die nur in einem Bereich sichtbar sind) Datenbank sollte möglich
sein
Steuern und Gebäudeversicherungen müssen (im Titelprogramm)
getrennt ausgewiesen sein
Maßnahmenkatalog (To-do-Liste) generieren
Zutrittskontrolle/Schlüsselverwaltung
Dokumentenmanagement
Instandhaltungssystem
Revisionsunterlagen-Erstellung (Fachgewerke/Gebäude)
unterstützen
Stundenplangenerierung
Lehrraumvergabe (Unterstützung)
Suche nach freien Lehrveranstaltungsräumen
Belegung von Räumen abfragen
Suchfunktionen fehlen bzw. sind z. T. ungeeignet
Auswertungen von Gebäude- und Raumdaten z. B. nach OKZ,
Fläche je Lehrstuhl, Baumaßnahmen, nach Räumen, die nicht zur
Fakultät gehören
Prüfungsverwaltung
Zugriff auf HIS-SVA (lesend)
Informationen zu Schlüsseldienst, Umzugsdienst, Wachschutz etc.
wären hilfreich
Begrifflichkeiten (Funktionsaufrufe) z. T. ungünstig
Gliederung der Bedienoberfläche ungünstig
Suchfunktionen und Auswertungen sollten durch den Nutzer
vorgegeben werden
Eine Einschränkung der Bedienersicht auf die benötigten Daten
sollte möglich sein (z. B. gruppenweise für Bauleiter etc.); Zur
besseren Übersichtlichkeit und schnelleren Auffindbarkeit sollten
betimmte Funktionen und Bereiche ausgeblendet werden können.
Anwendung
Konfigurierbarkeit von Teilen der Bedienoberfläche durch den
Benutzer
Daten müssen in einem leistungsstarken DB-System bearbeitbar
sein
Historisch gewachsene Strukturen (Software) problematisch
Trennung des CAFM-Systems von der Datenbank der Fa. IIEF
Software: Ersetzen von ORACLE durch ein anderes
Datenbanksystem (MySQL), homogene (möglichst wenig
Fremdprodukte), leicht zu wartende, benutzerfreundliche
Anwendung; Programmiersprache JAVA, Datenbankanbindung an
JDBC-Thin-Clients, XML plattformübergreifend, sichere
Datenübermittlung mit SSL-Verschlüsselung, Software-Distribution
via Internet mit JNLP, verteilte Anwendungen, Verwendung
kostengünstiger und bewährter 'LAMP'-Systeme, Integration von
gängigen Standard-Dateiformaten
schnellerer Zugriff auf die Daten
Login (bei Neueinrichtung) vereinfachen (z. B. über Erkennung
über IP-Nummer)
Software
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Anwendung
Software
Software
Software
Software
Software
Software
Software
Software
Software
Software
75
Anhang
125
126
127
128
129
130
Kritik
Wünsche
Wünsche
Wünsche
Kritik
Verbess.
SO
VL
VL
SO
TA
TA
System zu unhandlich
Einfache Terminkalendersoftware
Einfache Urlaubsplanungsspftware
Besseres Mail-Programm
Teilweise fehlen geeignete PCs (Drucker)
Hardware: Teilweise veraltete PC-Systeme, dadurch lange
Ladezeiten; bessere Druckmöglichkeiten z. B. für CAD-Pläne
Software
Software
Software
Software
Hardware
Hardware
Erläuterungen:
Anwendergruppe, die Vorschlag,
Kritik etc. geäußert hat:
VL ... Verwaltungsleiter
TA ... Technische Abteilung
SO ... Sonstige
Vorschlag für die Bewertung (Wichtigkeit für Realisierung):
H ... Priorität hoch (wichtig)
M ... Priorität mittel (hilfreich)
N ... Priorität niedrig (ggf. später realisieren)
J ... bereits vorhanden/erfüllt
X ... nicht erforderlich/sollte hier nicht betrachtet werden
Fassung vom 01.02.2002
76
Anhang
Anhang
Musterentwurf Raumbuch
77
78
Anhang
Anhang
Zeitplan
79
80
Anhang
Vergleichsdaten ausgewählter Hochschulen (außerhalb Berlins) zum CAFMEinsatz
RWTH Aachen
Daten zur RWTH Aachen: 289 Gebäude, 14.090 Räume
Einführungsbeginn: 1999
Eingesetztes CAFM-System: BuiSy 2.9.5 unter Oracle 8.0.5 (16 Client-Lizenzen); Autocad 14 u.
2000, Archivierungssystem SER ITA
Eingesetzte Module/Funktionen:
§
§
§
§
§
§
§
§
§
§
Raumbuch wird im Echtbetrieb genutzt (mehr als 1.000 Hochbaupläne sind im CAFMSystem),
Liegenschaftsbereiche mit allen Flurstücken sind erfasst (Grundbucheinträge),
laufende Baumaßmahmen (neu eingebunden),
Übersicht Brandmeldeanlagen (neu eingebunden),
Abfallwirtschaft (Containerstandorte, Abfallbehälter),
Reinigungsmanagement ab 2002,
mittelfristig geplant: Daten aus dem Strahlenschutz übernehmen; Technik- und Anlagenpläne
übernehmen (ca. 20.000 Stück),
BuiSy-Daten können via Internet abgerufen werden (z. B. Hörsaal-, Gebäude- und Nutzerdaten);
Schnittstelle zu HISCOB-GX,
LDS-Meldung ist realisiert.
Neben der Entwicklergruppe nutzen 8 Fachabteilungen das CAFM-System.
U Bielefeld
Daten zur U Bielefeld: 12 Gebäude, 10.700 Räume
Einführungsbeginn: 2. Quartal 2000
Eingesetztes CAFM-System: BuiSy 2.9.5 unter Oracle 7.3 (12 Client-Lizenzen); Grafiken sind als
Übersichtspläne mit sensitiven Flächen eingebunden.
§
§
§
§
Raumbuch wird im Echtbetrieb genutzt,
Gebäudereinigungsdaten sind erfasst,
Mittelfristig geplant ist die Einführung des Moduls zur Schlüssel- bzw. Schließsystemverwaltung.
FH Bochum
Daten zur FH Bochum: 8 Gebäude, 870 Räume
Einführungsbeginn: Ende 1999
Anhang
81
Eingesetztes CAFM-System: BuiSy 2.9.7 unter Oracle 8.0.6 (8 Client-Lizenzen); Autocad LT
§
§
§
§
Raumbuch wird im Echtbetrieb genutzt; sämtliche (39) Geschosspläne sind mit der BuiSyDatenbank verbunden,
Modul Gebäudereinigung wird eingesetzt,
LDS-Meldung ist realisiert,
Verbindung zum KLR-System (Mach 1) über SQL-Select.
Geplant (ab 2002) ist der Einsatz von Modulen zur zentralen Hörsaalverwaltung und zur DVgestützten Schlüsselverwaltung.
An der FH Bochum ist ein internes Mietmodell realisiert, das vom CAFM-System unterstützt wird
(Ziel: bessere Kostentransparenz sowie bedarfsgerechte Flächennutzung).
U Bonn
Einführungsbeginn: Anfang 1999
Eingesetztes CAFM-System: BuiSy 2.9.5 unter Oracle 8.0.5; Autocad 2000, FM 2000
Genutzte Funktionen/Module:
§
Raumbuch wird im Echtbetrieb genutzt, Daten jedoch noch nicht vollständig erfasst.
Geplant ist der Einsatz des CAFM-Systems zur Unterstützung von Wartung und Instandhaltung.
FH Dortmund
Daten zur FH Dortmund: 25 Gebäude, 2.338 Räume
Einführungsbeginn Mitte 1999
Eingesetztes CAFM-System: BuiSy 2.9.5 unter Oracle 8.0.5 (8 Client-Lizenzen); Autocad
§
§
§
Raumbuch wird im Echtbetrieb genutzt (komplette Erstdatenerhebung und -erfassung). CADGrafiken wurden neu erstellt und sind anzeigbar (keine sensitiven Flächen);
Gebäudereinigungsmodul ist im Echtbetrieb;
Daten für Feuerlöscheinrichtungen sind erfasst (auch Wartungstermine).
Geplant ist die Erfassung von Aufzügen, Krananlagen und Brandmeldeeinrichtungen. Weiterhin
sollen die Telefondaten in das CAFM-System eingepflegt sowie eine Schnittstelle zu HISCOB-GX
erstellt werden.
Heinrich-Heine-Universität Düsseldorf
Daten zur U Düsseldorf: 91 Gebäude, 8.457 Räume
Einführungsbeginn 1998
82
Anhang
Eingesetztes CAFM-System: BuiSy 2.9.5 unter Oracle 8.0.5 (6 Client-Lizenzen); Autocad R 13
§
§
Raumbuch wird im Echtbetrieb genutzt.
Gebäudereinigungsdaten sind erfasst (Reinigungsmodul seit Februar 1999 im Echtbetrieb).
§
Auftragsabwicklung über BuiSy (Instandhaltung), Instandhaltungsbriefkasten, WorkflowManagement
§
Geplant ist die Unterstützung von präventiver Instandhaltung- und Wartung durch das CAFMSystem sowie die Einführung der Oberfläche FM 2000 und die Integration sensitiver Flächen in die
grafische Darstellung.
Gerhard Mercator Universität Duisburg
Daten zur U Duisburg: 40 Gebäude, 5.000 Räume
Eingesetztes CAFM-System: BuiSy 2.9.5 unter Oracle 8.0.5 (16 Client-Lizenzen); Autocad R 13
§
§
§
§
§
Raumbuch wird im Echtbetrieb genutzt. Sämtliche Räume sind mit ihren Merkmalen erfasst.
Ca. 50 % der verfügbaren Grafiken sind im CAFM-System, davon ca. 25 % mit der Datenbank
verbunden.
Personendaten werden erfasst (täglicher Abgleich mit HIS-SVA).
Pflege sämtlicher Telefonnummern in BuiSy (Aktualisierung in unregelmäßigen Abständen).
LDS-Meldung ist über BuiSy realisiert.
Geplant ist die Unterstützung von Instandhaltung- und Wartung durch das CAFM-System sowie
die Integration von Arbeitssicherheit (Fluchtwege, Feuerlöscher) und die Erfassung der Netzwerktopologie.
FH Köln
Daten zur FH Köln: 19 Gebäude, 3.661 Räume
Eingesetztes CAFM-System: BuiSy 2.9.7 unter Oracle 8.0.5 (8 Client-Lizenzen)
§
§
Raumbuch wird im Echtbetrieb genutzt (Daten sind vollständig erfasst),
Geplant ist die Inbetriebnahme weiterer Module.
Anhang
83
Universität, Fachhochschule und Kunstakademie Münster
Daten zu den Hochschulen in Münster: 198 Gebäude (= Universität; FH: 20, KA: 1), ca. 14.900
Räume (Universität)
Einführungsbeginn: 2001, Ausgangssituation (2000): Kein FM-System vorhanden, Echtbetrieb
wurde im Jahr 2002 begonnen.
Eingesetztes CAFM-System: Kopernikus 10.0 unter Oracle 8i (Systempartnerschaft)
Anforderungen:
§
§
§
§
Erfassung der Bau- und Liegenschaftsdaten (grafische Darstellung von untergeordneter Bedeutung),
Materialwirtschaft und Lagerverwaltung (umfangreiche Anforderungen),
Instandhaltung, Erfassung der Daten der technischen Anlagen (Instandhaltungsplanungssystem war bereits beschafft),
Raumvergabe (Lehre) und Stundenplanerstellung: wurde wegen zu großer Komplexität nicht
realisiert.
§
§
§
§
Modul Bau- und Liegenschaftsdaten (Echtbetrieb in 2002 begonnen)
Modul Materialwirtschaft und Arbeitsauftragsverfahren (Echtbetrieb soll bis Mitte 2002 begonnen werden)
Instandhaltung (wurde begonnen)
Schnittstellen (z. B. zu HISCOB waren geplant, wurden jedoch noch nicht realisiert).
Die Erarbeitung der Anforderungen erfolgte in Arbeitsgruppen unter Beteiligung von HIS (z. T. mit
Vertretern aus allen Hochschulen, die Kunstakademie war aus Kapazitätsgründen nur begrenzt
beteiligt).
(Stand Januar 2002)
FH Niederrhein
Daten zur FH Niederrhein: 23 Gebäude, 2.300 Räume
Eingesetztes CAFM-System: BuiSy 2.9.7 unter Oracle 8.0 (4 Client-Lizenzen); Autocad LT 2000
§
§
Raumbuch wird im Echtbetrieb genutzt. CAD-Grafiken sind teilweise in das CAFM-System
integriert.
Gebäudereinigungsdaten sind erfasst.
Geplant ist der Einsatz der Module Umzugsplanung sowie Instandhaltung- und Wartung. Außerdem ist die Integration des CAFM-Systems in ein Raumhandelsmodell vorgesehen.
U Siegen
Daten zur U Siegen: 9 Gebäude, 4.731 Räume
84
Anhang
Eingesetztes CAFM-System: BuiSy 2.9.5e unter Oracle 7.3.3.0; 13 Client-Lizenzen; Autocad 2000
Genutzte Funktionen/Systeme:
§
§
§
§
Raumbuch wird im Echtbetrieb genutzt. Sämtliche Räume sind mit ihren Merkmalen erfasst.
Ca. 40 % der verfügbaren Grafiken sind in das CAFM-System eingebunden.
Gebäudereinigungsmodul,
Geplant ist die Erfassung der Telefondaten (BuiSy als Datenzulieferer für ein neues Telefonabrechnungssystem), die Integration der Schlüsselverwaltung sowie die Unterstützung von Instandhaltungs- und Störungsmanagement durch das CAFM-System.
Bauhaus-Universität Weimar
(Stand: Januar 2002)
Daten zur Bauhaus Universität: 67 Gebäude, 3.200 Räume
Einführungsbeginn: 1997
Eingesetztes CAFM-System: Fame Version 4.0 – ab April 2002: Version 5.0 (5 Client-Lizenzen);
Autocad 13.
§
§
Raumbuch wird im Echtbetrieb genutzt. CAD-Grafiken sind in das CAFM-System integriert.
Gebäudereinigungsdaten sowie Daten zur Unterstützung der Lehrraumvergabe sind erfasst.
Die Schlüsselverwaltung erfolgt vollständig mit dem CAFM-System.
Geplant ist die Erfassung von Daten zur Verkabelung (Elektro und LAN, Rohrleitungen etc.) sowie
zur Inventarisierung. Außerdem ist der Zugriff über Web-Browser vorgesehen. Künftig soll die Dateneingabe bei Baumaßnahmen durch beauftragte Ingenieurbüros erfolgen.

CAFM-System der Humboldt-Universität zu Berlin

Transcrição

Documentos relacionados

CAFM Trendstudie 2013 Executive Summary

Humboldt-Universität zu Berlin ZE Hochschulsport Invalidenstraße

„WeltWissen“ im Martin-Gropius-Bau - Hu

Newsletter 1/2016 (pdf 2,2 MB)

der kompletten Ausgabe - Hu

durchblick - Fotowettbewerb der Studentenwerke

Seminarkonzeption

DR. FISCHER / Jürgen Bahnhofstr. 27 99084 Erfurt

als PDF - Jugendrat Remscheid

curriculum vitae