von Daniel Koch, Susanne Maaß, Andree Rebers und Yvonne Schwarte

Die Gebäude und Anlagen der Universität werden täglich von uns genutzt. Wer sorgt eigentlich dafür, dass sie immer funktionsfähig sind? Im Rahmen eines Lehrprojektes in der Informatik konnten die Studierenden hinter die Kulissen schauen. Das Projekt „FACIL: Informationstechnik für die Gebäudebetriebstechnik“ lief über zwei Jahre und war Bestandteil des Bachelor- und Master-Studiums Informatik. Die Teilnahme an solchen Projekten ist für alle Studierenden obligatorisch und soll sie auf die spätere Berufspraxis vorbereiten [Robben 2014]. Im Projekt FACIL untersuchten wir mit 15 Studierenden die Arbeitsprozesse der Gebäudebetriebstechnik (GBT) und entwickelten zwei Software-Prototypen zur Unterstützung der HandwerkerInnen und Funktionsmeister. Hier wollen wir über das Projekt berichten und insbesondere darüber, wie im Projekt unter Leitung von Prof. Susanne Maaß und Dipl. Soz. Carola Schirmer das Konzept des forschenden Lernens realisiert wurde.

Das Projekt FACIL

Die Bremer Uni-Gebäudebetriebstechnik ist gebäudebezogen in Gruppen aufgeteilt und gehört organisatorisch zum Dezernat 04 (Technischer Betrieb/Bauangelegenheiten). Die beiden FACIL-Betreuerinnen hatten in Abstimmung mit dem Dez. 04 den Kontakt zu einer Gruppe hergestellt, die bereit war, mit uns zusammenzuarbeiten. Der Bereich GBT war für die Lehrenden zunächst genauso unbekannt wie für uns als Studierende. Das Projektziel war grob vorgegeben: Es sollten IT-Konzepte für die GBT entwickelt werden. Die Software sollte primär die HandwerkerInnen und ihre Funktionsmeister bei der täglichen Arbeit unterstützen. Doch was macht die Gebäudebetriebstechnik eigentlich? Gebäudeinstandhaltung (Wartung und Reparatur) ist ein typischer Bereich sog. „unsichtbarer Arbeit“ [Kumbruck 2001], über die sich die meisten Menschen keine Gedanken machen, solange alles gut funktioniert. Erst wenn selbstverständliche Gebäudefunktionen ausfallen, wird die GBT sichtbar: ein Raum ist nicht zugänglich, eine Jalousie lässt sich nicht bewegen, die Mensakühlung fällt aus, eine Lüftung im Labor streikt – jetzt muss repariert werden! Regelmäßige Kontrolle und Wartung soll sicherstellen, dass solche Fehler gar nicht erst auftreten. Wenn Arbeit allerdings unsichtbar bleibt, wenn sie „übersehen“ wird, läuft sie Gefahr, nicht wertgeschätzt zu werden. Das kann dazu führen, dass sie bei Überlegungen zu IT-Unterstützung übersehen wird. Die Beschäftigten haben dann wenige Chancen, ihre Interessen und Bedarfe zur Geltung zu bringen.

Im Projekt haben wir mit Methoden der Partizipativen Softwareentwicklung gearbeitet [Simonsen & Robertson 2013], um detaillierten Einblick in die Arbeit der GBT zu bekommen und die Beschäftigten an der Entwicklung von Lösungen zu beteiligen. Dabei konzentrierten wir uns auf einen Teilbereich der GBT-Arbeit: die Bearbeitung von  Reparaturaufträgen, die von Uni-MitarbeiterInnen an die GBT geschickt werden. Jeder  Auftrag wird vom Funktionsmeister an eine HandwerkerIn zugewiesen, die ihn dann – ggf. in Kooperation mit KollegInnen aus den Uni-eigenen Werkstätten und dem Uni-Zentrallager – bearbeitet und dokumentiert. Während im ersten Jahr des Projektes eine PC-Software realisiert wurde, konzipierten wir im zweiten Jahr eine mobile Anwendung für  Smartphones, um den GBT-MitarbeiterInnen, die den ganzen Tag auf dem Uni-Gelände unterwegs sind, jeweils vor Ort die relevanten Daten zugänglich zu machen. Unsere Zwischenergebnisse in Form von interaktiven Software-Prototypen konnte „unsere“ GBT-Gruppe in mehreren Workshops und zum Teil auch bei ihrer Arbeit ausprobieren und kommentieren. Auf Basis dieser Evaluationen wurde die Software überarbeitet und angepasst. Für das Abschlusstreffen mit der GBT-Gruppe und allen AkteurInnen aus den Dezernaten 04 und 05, mit denen wir im Laufe des Projekts zu tun hatten, wurde eine Broschüre erstellt, die die Anforderungen der GBT an eine Software zur Unterstützung ihrer Arbeit zusammenfasst und anhand unserer Prototypen illustriert.

Forschendes Lernen in FACIL

Als praktisches Softwareentwicklungsprojekt bot das FACIL-Projekt reichlich Gelegenheiten zum forschenden Lernen. Dieses zeichnet sich nach Ludwig Huber dadurch aus, dass „die Lernenden den Prozess eines Forschungsvorhabens, das auf die Gewinnung von auch für Dritte interessanten Erkenntnissen gerichtet ist, in seinen wesentlichen Phasen – von der Entwicklung der Fragen und Hypothesen über die Wahl und Ausführung der Methoden bis zur Prüfung und Darstellung der Ergebnisse in selbstständiger Arbeit oder in aktiver Mitarbeit in einem übergreifenden Projekt – (mit)gestalten, erfahren und reflektieren“. [Huber 2009, S. 11] All diese Aspekte konnten wir in FACIL erfahren. Gleich zu Beginn des Projektes vermittelte uns das Dezernat 04 Kontakt zu einer Softwarefirma, die große CAFM-Systeme (Computer- Aided Facility Management) anbietet und bereit war, uns diese während einer längeren Sitzung über Skype vorzuführen und zur Erkundung zugänglich zu machen. Hier wurde exemplarisch
deutlich, dass IT meist primär zur Unterstützung der Verwaltung und Organisation von Arbeit dient, also auf die Managementbedarfe ausgerichtet ist. Im Projekt wurde dagegen beschlossen, die Beschäftigten selbst bei ihrer handwerklichen und dennoch weitgehend unsichtbar bleibenden Arbeit zu unterstützen. Dass wir in ihrem Interesse Erkenntnisse gewinnen und Lösungen entwickeln wollten, stand für uns schnell fest.

Nun war es nötig, die Anwendungsdomäne, in der wir uns bewegten, zu verstehen. Im  Kurs „Partizipative Softwareentwicklung“ im Semester vor dem Projektbeginn hatten die ProjektteilnehmerInnen Methoden kennengelernt, um in Kooperation mit späteren NutzerInnen deren Anforderungen zu erheben, Lösungskonzepte zu entwickeln und zu überprüfen. Für unser Projekt wählten wir Methoden aus und modifizierten sie für unsere Zwecke. Zunächst wurden die einzelnen GBT-MitarbeiterInnen im Rahmen von Beobachtungsinterviews über mehrere Stunden von Studierenden bei ihrer täglichen Arbeit begleitet und befragt; ihre Arbeitsmittel wurden mittels Artefaktanalysen untersucht. So bekamen wir Einblick in ihr Arbeitsumfeld, ihre Arbeitsaufgaben und -prozesse. Alle TeilnehmerInnen führten Erhebungen durch und trugen in strukturierten Auswertungssitzungen ihre Erfahrungen und verbleibenden Fragen zusammen. Sie fassten ihre Ergebnisse in formale Arbeitsmodelle und legten informelle  Materialsammlungen an. Durch die Präsentation und Diskussion im Plenum wurde ein gemeinsames und allgemeineres Verständnis erreicht.

Auf dieser Basis wurden erste Ideen entwickelt, an welchen Stellen Software die Arbeit der GBT unterstützen könnte. Um unser Verständnis abzusichern und zu erkunden, ob unsere Überlegungen in die richtige Richtung gingen, organisierten wir ein Treffen mit der GBT-Gruppe. Dort präsentierten wir die Arbeitsabläufe und unsere Ideen zum Einsatz von IT mit Hilfe von Storyboards. Diese handgezeichneten Folgen von Bildern, die Arbeitssituationen und Ereignisse darstellten, dienten uns als gemeinsamer Bezugspunkt für unsere Diskussionen. Die GBT-MitarbeiterInnen erkannten ihre Arbeit darin wieder, sie ließen sich auf unsere Ideen ein und entwickelten sie mit uns weiter. Aufgrund ihrer  Rückfragen, Einwände und Anregungen waren wir schon viel sicherer, die Arbeit der Gebäudebetriebstechnik einigermaßen verstanden zu haben. Und wir sahen uns in der Wahl unserer Methoden bestätigt.

Nachdem wir unsere Ideen in Form von zunächst Papierprototypen und später digitalen Prototypen weiter ausgearbeitet hatten, trafen wir die Beschäftigten erneut und ließen sie unsere Lösungen anhand von vorbereiteten Aufgabenszenarien ausprobieren und  kommentieren. Uns wurde deutlich, wie hilfreich und produktiv eine partizipative Vorgehensweise sein kann und wie gut die Kommunikation zwischen EntwicklerInnen und AnwenderInnen vorbereitet und moderiert werden muss.

Während unserer Projektarbeit gingen die Diskussionen um die Beschaffung eines CAFM-Systems im Dezernat 04 weiter. Im Vordergrund stand dabei, wie mit seiner Hilfe ein genauerer Überblick über den Arbeitsanfall und die Auslastung der GBT-Gruppen und der Werkstätten gewonnen werden könnte. Durch unsere Kontakte auf der Management- wie auf der operativen Ebene erhielten wir Einblick in die verschiedenen Positionen, Argumente und organisatorisch- technischen Randbedingungen. Wie wird eine Beschaffung vorbereitet? Wer ist an solchen Prozessen beteiligt? Wie laufen die Aushandlungen zwischen Personalrat und Management? Im Projekt beschäftigten wir uns daher auch mit Fragen der Mitbestimmung und des Datenschutzes. Zur Formulierung der Leistungsbeschreibung für die Ausschreibung konnten wir durch unsere Untersuchungen sogar etwas beitragen.

Eine Überraschung vor Beginn des zweiten Projektjahres war die Entscheidung der Uni, Smartphones für alle MitarbeiterInnen der GBT anzuschaffen. Was uns während des ersten Projektjahres zwar sehr wünschenswert, aber leider undenkbar erschien, sollte nun plötzlich geschehen! Wir erfuhren von den Auswahlkriterien für den Netzbetreiber sowie von den Kriterien zur Auswahl eines robusten Smartphones. Für uns bedeutete das, dass wir nun unseren Entwicklungsschwerpunkt auf die mobile Unterstützung der  HandwerkerInnen vor Ort legen konnten und sogar für ein konkretes Gerät und Betriebssystem entwickeln konnten. Für einige Zeit durften wir eines der beschafften Smartphones ausleihen und unsere Software darauf installieren, um sie mit  GBT-MitarbeiterInnen zu evaluieren. Verfahren zur Evaluation mobil genutzter Software werden in der Wissenschaft erst ansatzweise diskutiert. Wir studierten die Literatur und entschieden uns für ein eigenes Vorgehen, das wir im Nachhinein auch kritisch auswerteten.

Um zu Beginn die Ziele für unser gemeinsames Forschungs- und Entwicklungsvorhaben abzustecken und es dann arbeitsteilig und kooperativ durchzuführen, waren  wissenschaftliche Bereiche zu sichten, Entscheidungen zu fällen, Arbeitspakete zu  schnüren und Absprachen zu treffen, Kontakte zu pflegen und angemessene Kommunikationsformen zu entwickeln. Die Koordination aller Aktivitäten geschah durch die Projektkoordinationsgruppe (PKG). Jedes Projektmitglied musste für sechs bis acht Wochen mit ein bis zwei anderen in der PKG arbeiten und unter Beratung durch die Veranstalterinnen das Projekt steuern. Bei Schwierigkeiten griffen die Betreuerinnen ein, halfen bei der Reflexion, indem sie die Probleme in einen größeren Rahmen einordneten, und halfen weiter oder unterstützten die TeilnehmerInnen dabei, Lösungen zu finden. So versuchten sich alle TeilnehmerInnen am Projektmanagement und konnten in der Gruppe Strategien dafür entwickeln und erproben.

Projektspuren

Die MitarbeiterInnen der GBT, mit denen wir zusammengearbeitet hatten, waren sich am Ende einig – für sie wäre es schön, die von uns erstellte Software nutzen zu können, sei es am PC oder auf dem Smartphone. Leider mussten wir einsehen, dass eine studentische Software nicht den Anforderungen der Universität entspricht, da wir keine Wartung und Gewährleistung über einen längeren Zeitraum hinweg bieten und für wünschenswerte Erweiterungen nicht mehr zur Verfügung stehen können. Diese Einsicht war – nach all dem Aufwand für Analyse, Konzeption, nutzerorientierter Gestaltung und Realisierung – bitter, aber auch ein weiterer wichtiger Lernschritt. So haben wir der GBT zwar keine Software geliefert, aber wir konnten den Austausch zwischen den verschiedenen Ebenen des Dezernats 04 und den MitarbeiterInnen und Funktionsmeistern der GBT über die Notwendigkeit des Einsatzes einer mobilen Software anstoßen. Durch unsere auf die Bedarfe der HandwerkerInnen ausgerichteten Softwareprototypen ist es uns gelungen, deren Perspektive zu dokumentieren und die Einsetzbarkeit solcher Software zu demonstrieren. Die Erkenntnisse aus unseren Untersuchungen wurden von uns in einem „Anforderungskatalog für eine Informationstechnologie für die GBT“ festgehalten und all unseren externen ProjektpartnerInnen überlassen. Die Idee war, dass dieser, wenn der Zeitpunkt der Auswahl einer CAFM-Software und ihrer späteren Anpassung an die Bedarfe der Universität gekommen ist, als Unterstützung hinzugezogen werden kann.

Eine weitere Spur wird das Projekt FACIL hoffentlich hinterlassen: Zukünftig werden die MitarbeiterInnen der Universität im Falle eines Gebäudemangels nicht mehr nach dem entsprechenden Auftragsformular (pdf) suchen, dieses ausfüllen und als Anhang einer  eMail an die richtige GBT-Gruppe schicken müssen.

Stattdessen können sie im Beschäftigtenportal ihre Angaben und Wünsche online in ein Webformular eintragen, das sie beim vollständigen und korrekten Ausfüllen unterstützt. Sie erhalten bei einer erfolgreichen Übertragung ihres Auftrags eine Bestätigungsmail. Die entsprechende Programmierung wurde im Rahmen von FACIL durchgeführt und soll voraussichtlich beim nächsten Systemupdate integriert werden. Und auch bei diesem letzten kleinen Projektschritt wurde klar, wie viele kleine und größere organisatorische Entscheidungen bei jeder technischen Maßnahme zu bedenken sind: Lassen sich die Zuständigkeiten der GBT-Gruppen, die den Aufträgen automatisch zugeordnet werden, später noch verändern? Was passiert, wenn die Uni ein weiteres Gebäude baut, das im System noch nicht vorgesehen ist? Bekommen die Funktionsmeister weiterhin ein Formular, das sie um Angaben ergänzen und einer MitarbeiterIn ausgedruckt in die Hand drücken können, wenn diese den Auftrag bearbeiten soll? Können die Werkstätten in gewohnter Weise damit weiterarbeiten? Wie schon während des gesamten Projekts wurde uns wieder deutlich, dass wir als InformatikerInnen nicht allein Technik, sondern sozio-technische Systeme gestalten.

Wir möchten uns herzlich bei allen MitarbeiterInnen der Dezernate 04 und 05, mit denen  wir zu tun hatten, und ganz besonders bei „unserer“ GBT-Gruppe für die tolle  Unterstützung und das uns entgegengebrachte Vertrauen bedanken!

Über die AutorInnen:

Daniel Koch ist Student im Masterstudiengang Informatik an der Universität Bremen.

Susanne Maaß ist Professorin für Informatik am Fachbereich 3 der Universität Bremen.

Andree Rebers ist Student im Masterstudiengang Informatik an der Universität Bremen.

Yvonne Schwarte ist Studentin im Masterstudiengang Informatik an der Universität Bremen.

Literatur:

Huber, Ludwig (2009). Warum Forschendes Lernen nötig und möglich ist, in L. Huber, J.  Hellmer & F. Schneider (Hrsg.): Forschendes Lernen im Studium. Aktuelle Konzepte und Erfahrungen, Bielefeld: UniversitätsVerlagWebler, 9–35.

Kumbruck, Christel (2001). Unsichtbare Arbeit. Umgang mit unsichtbarer Arbeit bei Reorganisationsprozessen aus Sicht eines soziokulturellen Ansatzes, in: Journal für Psychologie (Jg. 9), 24–38.

Robben, Bernard (2014). Projektstudium in Bremen. (K)Eine Entwicklungsgeschichte, in L. Huber, M. Schröder & H. Schelhowe (Hrsg.): Forschendes Lernen als Profilmerkmal einer Universität. Beispiele aus der Universität Bremen, Bielefeld: UniversitätsVerlagWebler, 37–55.

Simonsen, Jesper & Robertson, Toni (Hrsg.) (2013): Routledge International Handbook of Participatory Design. New York/London: Routledge.

 

 

Bildnachweis:

• AutorInnenfotos: Regina Schumacher
• Abb. 1/2: Projekt „facil – Informationstechnologie für die Gebäudebetriebstechnik“