Anforderungsanalyse – Mängel melden aus BürgerInnensicht

Nachdem wir im letzten Blogartikel einen kurzen Überblick über vielen unterschiedlichen Facetten unseres Mängel- und Anliegenmelder-Projektes gegeben haben, wollen wir diesmal den Fokus ganz auf den mängelmeldenden Menschen legen. Was sind die Anforderungen, Wünsche und Zukunftsideen der BürgerInnen die in ihrem Alltag in einer digitalen smarten Stadt einen Mängel- und Anliegenmelder nutzen sollen? Wie können wir sie neugierig auf unser Projekt machen? Was ist ihre Motivation? Wie (be)hält man sie langfristig?

Betrachten wir zunächst den zeitlichen Aspekt von Mängeln und Anliegen und welche Anforderungen sich hieraus ergeben. Wir können hier grob vier Kategorien unterscheiden:

1. Notfälle
Es wäre natürlich ein schöner Zukunftstraum für unser Projekt, wenn wir hiermit auch eine ernsthaft zuverlässige Infrastruktur schaffen, welche auch für zeitkritische Notfälle geeignet ist. Doch auf Grund der technischen und rechtlichen Komplexität hierfür und dem engen Zeitrahmen dieses Projektes liegt dies derzeit in weiter Ferne. Darüber hinaus ist es ohnehin fraglich, ob Menschen wirklich ein Mängelmelder für (persönliche) Notfälle akzeptieren würden. Wir gehen eher davon aus, dass Menschen es im Notfall bevorzugen mit einer zuständigen Person direkt zu telefonieren. Dies hat nicht nur psychologische Vorteile, sondern vermeidet auch unnötige Verzögerungen im Notfall, da alle (Rück-)Fragen sehr viel schneller und einfacher gestellt und beantwortet werden können.

2. Akute Mängel
Die kaputte Straßenlaterne, der wilde Müllhaufen, der Lärm des OpenAirs… für all diese aktuellen Mängel gibt es seit Jahren viele gute Lösungen anderer Mängelmelder wie beispielsweise FixMyStreet, Mark-A-SpotWer-denkt-Was, STADTRADELN, etc.pp. Viele dieser sind Webseiten oder Apps, bei denen man auf einer digitalen Karte Mängel eintragen, verschlagworten und nach dem einfachen internationalen Standard Open311 GeoReport v2 API zwischen verschiedenen Mängelmeldesystemen austauschen kann.
Viele dieser Systeme sind jedoch noch eher elektronische Formulare als echte digitale Lösungen und scheinen nur selten die Bedürfnisse digitaler Bürger der „Generation Smartphone“ in den Mittelpunkt zu stellen. Auf Anforderungen die wir hier als notwendig erachten, wird im Laufes dieses Blogartikels näher eingegangen werden.

3. Mittelfristige Anliegen
Bereits ein Anliegen wie „StadtLärm“ ist eine nicht ganz so einfache Angelegenheit. Einerseits kann „Lärm“ ein sehr akuter Mangel mit Tendenz zu einem Notfall sein, andererseits erfordern viele Lärmschutzmassnahmen längerfristige Planungen und auch eine längere Umsetzungszeit ist hierbei sehr wahrscheinlich. Dazu ist ein „Lärmmängel“ selten alleine. Oft gehören zu einem konkreten Anliegen eine Vielzahl akuter Mängelmeldungen, welche über einen längeren Zeitraum von verschiedenen BürgerInnen – auch aus vielleicht ganz unterschiedlichen Gründen – gemeldet wurden. Eine wichtiger Faktor für die Benutzerfreundlichkeit ist hierbei, wie einzelne akute Mängel am besten vollautomatisch den jeweiligen Anliegen bzw. Problemfeldern zugeordnet werden können (Textanalyse, Bildanalyse, AI, KI, MachineLearning), damit der Meldende nicht den Überblick über all die Mängel in ihrer digitalen Stadt verliert. Dies muss allerdings nicht notwendiger Weise direkt beim Erstellen des Mängels geschehen. Gerade Trendanalysen und Kategorisierungsverfahren (z.B. Clustering) brauchen ohnehin immer einen gewissen Vorlauf um erste Ergebnisse zu liefern (Beispiele solcher Analysen: Philly Open311 2017 data).
Neben solchen automatischen Verfahren, kann man natürlich auch den Spieß rumdrehen und die BürgerInnen gezielt einladen Mängel bzw. Daten zu konkreten Fragestellungen, z.B. StadtLärm zu sammeln oder ihre Meinungen zu den geplanten Bau- und Stadtentwicklungsvorhaben des Stadt abzugeben. Auf solche gemeinsamen Aktionen, bei uns „Challenges“ genannt, werden wir in einem späteren Blogartikel noch genauer eingehen.

4. Langfristige Planung und Bürgerbeteiligung
Einige Anliegen können nicht im Tagesgeschäft einer digitalen smarten Stadtverwaltung erledigt werden, da hierfür Stadtratsbeschlüsse notwendig sind. Somit sind diese praktisch immer auf mehrere Monate bis Jahre angelegt und können auch Bürgerbeteiligungsverfahren umfassen. Gerade formale Bürgerbeteiligungsverfahren sind stark strukturell vorgegeben, so dass wir uns hier nur auf eine Bereitstellung einer guten Daten- und Diskussionsbasis über digitale Schnittstellen beschränken. Auch hier können Analysemethoden helfen Mängel die für ein Anliegen gemeldet wurden besser aufzuarbeiten und darzustellen und so die oftmals verschiedenen Blickwinkel, aber auch unerwarteten Gemeinsamkeiten verschiedener gesellschaftlicher Gruppen sichtbarer zu machen.

Unterm Strich sehen wir unser Projekt also vor allem im Bereich der „mittel- und langfristigen Anliegen“. Wir bekommen Mängelmeldungen nicht nur direkt von BürgerInnen, sondern auch von anderen Mängelmeldern, allem voran vom zukünftigen Mängelmelder der Stadtverwaltung Jena und ihrer Eigenbetriebe und Tochterunternehmen. Diese Mängel versuchen wir zusammenzuführen,  hieraus abstraktere Anliegen zu ermitteln und all diese Informationen für BürgerInnen sinnvoll aufzubereiten.

Laternenmängelmelder des ksj bzw. störung24.de

Ein interessantes Beispiel eines bereits existierenden Mängelmelders in Jena sind die neuen LED-Straßenlaternen des Kommunalservice Jena (ksj) . Hier bietet der Laternendienstleister von sich aus einen Mängelmelder an. Anders als bei vielen bisherigen Mängelmeldern wird dem Bürger das Melden eines Mangels an einer Straßenlaterne dadurch vereinfacht, dass alle Straßenlaternen bereits auf der Karte vorhanden und auswählbar sind. Somit entfällt das häufig sehr aufwendige Verorten eines Mangels durch den Bürger und das Raten beim Kommunalservice welche Laterne nun genau gemeint gewesen sein könnte. Durch zusätzliche Metadaten zu den Laternen lassen sich auch einzelne Besonderheiten eines Laternenmodells sehr viel einfacher abfragen. Dies alles dient natürlich vor allem um Fehler in den Mängelmeldungen zu vermeiden, die Datenqualität zu steigern und den gesamten Meldeprozess noch effizienter zu gestalten.

Entwickelt man diese Idee weiter, so liegt es nahe Mängel- und Anliegenmelder und OpenData-Portale einer digitalen smarten Stadt als Gesamtsystem zu sehen. Häufig stehen OpenData-Pioniere unter einem hohen Rechtfertigungsdruck „wer sich bitte schön für Datensatz XYZ interessieren“ sollte. Eine OpenData-Referenzanwendung wäre also durchaus wünschenswert. Hier für wäre es wünschenswert, wenn kommunale OpenData-Portale zu jedem physikalischen Objekt in der Stadt einen digitalen Zwilling (Digital Twin) beinhalten würden, welcher auch Informationen über mögliche Mängel und wer für dieses Objekt verantwortlich ist beinhaltet. Gerade die Klärung von Zuständigkeiten ist unserer Meinung nach ein zu häufig unterschätztes Problem für die Akzeptanz von Mängelmeldern. Nicht immer ist die Stadtverwaltung der beste Ansprechpartner für einen Mängel. Liegt ein Mängel in Jena beispielsweise auf dem Gelände der Universität, der Uniklinik, von privaten Wohnungsgenossenschaften oder des Landes Thüringen, so wäre es nicht nur wünschenswert, sondern auch deutlich effizienter dies direkt an ein Mängelmeldesystem der jeweiligen Organisation weiterzuleiten. Andernfalls sieht man in der Praxis häufig BürgerInnen die auf Grund unklarer Zuständigkeiten einen Mängel gern an möglichst viele Stellen in der Stadt melden, denn schließlich wollen sie wirklich sicher gehen, dass dieser auch rasch bearbeitet werden wird. Dies führt unweigerlich zu einem deutlichen Mehraufwand auf allen Seiten.

Ein beliebter Versuch solche Doppel- und Mehrfachmeldungen zu vermeiden ist die Stadtverwaltung als „zentralen Hub“ zum Austausch aller Mängelmeldungen zu bestimmen. Doch die Erfahrung zeigt, dass solch komplexe zentralistische Systeme nur sehr selten mit der technischen und organisatorischen Entwicklung ihres Umfeldes Schritt halten können und relativ schnell ein neues Nadelöhr darstellen. Meist bleiben zentrale Systeme auch nicht lange alleine. Spätestens wenn es drei oder vier konkurrierende „zentrale Systeme“ gibt, wäre es in der Regel besser gewesen das System von Anfang an nach dem Vorbild dezentraler kooperativer Internet-Systeme zu entwickeln. Als aktuelles Negativbeispiel hierfür kann die Elektromobilität dienen, in der das Roaming an fremden Ladestationen auch nach Jahren für den Endkunden noch immer ein Glücksspiel ist.

Bei Gesprächen zu der Frage von Zuständigkeiten mit einer Jenaer Wohnungsbaugesellschaft wurde auch schnell klar, dass diese sehr interessiert an solch einem offenen Mängelmeldersystem wären, da sie ebenfalls eine große Anzahl an Mängeln pro Jahr verwalten und jede Form von Rückschlüssen und Analysen auf Grund unterschiedlicher Datensilos sehr schwierig sind. Allerdings gibt es hierbei eine recht große Klasse von sehr gruppenspezifischen und auch rein privaten Mängeln. Ein defekter Wasserhahn ist sicherlich für einen Mieter ein wichtiger Mängel, aber für seine Nachbarn hoffentlich eher irrelevant. Genauso ist eine defekte Heizung sicherlich für alle Mieter eines Hauses ein sehr wichtiger Mängel, doch für das Nachbarhaus ist dies in der Regel schon wieder irrelevant… außer vielleicht es ist die fünfte defekte Heizung in der gleichen Strasse und die Einzelmängel eskaliert zu einem größeren gemeinsamen Problem. Aus Nutzersicht sollte es also eine Möglichkeit geben sowohl gruppenspezifische als auch öffentliche Mängel zu melden ohne mehrere Apps installieren oder Webseiten aufrufen zu müssen. Gleichzeitig sollte es Filtermöglichkeiten geben, damit Nutzer nur für sie relevante Mängel, beispielsweise aus ihrer Nachbarschaft, ihrer Gruppe oder nur entlang ihres täglichen Arbeitsweges erfahren. An diesen Punkten treten Datenschutzaspekte deutlich zu Tage, denn niemand soll seinen täglichen Arbeitsweg auf zentralen Servern hinterlegen müssen, nur um ein paar Benachrichtigungen über aktuelle Mängel entlang des Weges zu bekommen, wenn dies auch mit digital signierten Offenen Daten möglich ist. Gleichzeitig sollte niemand zwingend seine eindeutige Identität preisgeben müssen nur um einen öffentlichen Mängel zu melden – auch nicht gegenüber der eigenen Stadtverwaltung.

Ähnliche Datenschutzaspekte begegnen uns auch an Schulen. Schulen sind allgemein ein sehr interessantes geschlossenes Ökosystem mit sehr hohen Datenschutzanforderungen bei jeglicher digitalen Kommunikation zwischen SchülerInnen, LehrerInnen und Eltern und gleichzeitig ein Ort an dem Informatik- und Programmierkenntnisse aktiv gefördert werden. Deshalb ist es auch eines unserer erklärten Ziele das Thema Mängel- und Anliegen in Kontext von Schule zusammen mit Schülern zu diskutieren und weiterzuentwickeln. Das ein großes Kommunikationsbedürfnis zwischen SchülerInnen, LehrerInnen und Eltern besteht, zeigen nicht zu letzt die vielen Diskussionen rund um den Datenschutz an Schulen. Meist wird dieses Bedürfnis derzeit mit unterschiedlichsten Messengerdiensten realisiert, welche allerdings nur selten den aktuellen Datenschutzanforderungen gerecht werden können. Welche Formen der Gruppenkommunikation sinnvoll durch ein System analog zu einem Mängel- und Anliegenmelder umgesetzt werden könnten ist hierbei zu erörtern (z.B. Digitales Schwarzes Brett).

devoxx4kids beim Jenathon3

Leider hat sich hier bislang allerdings gezeigt, dass der organisatorische Aufwand ein solches doch recht kurzes agiles Projekt mit den erstaunlich starren Strukturen in der MINT-Bildung an Schulen zusammenzubringen enorm hoch ist. Schulen bevorzugen eher fertige und erprobte Konzepte und weniger „Learning-by-Doing“. Andererseits hat unser Jenathon (Jenaer OpenData-Hackathon) im April gezeigt, dass sich einzelne Schüler in kleinen Gruppen oder mit einem Elternteil durchaus für solche Fragestellungen begeistern können, sofern man es ihnen auf eine spielerische Art und Weise präsentiert. Und warum sollte eine Gruppe Hamster oder Roboter bei ihrem programmierten Wegen durch Labyrinthe nicht auch mal einen Mängelmelder nutzen um ein gemeinsames Ziel in einem Spiel zu erreichen 🙂

Titelbild: (c) by MapBox and OpenStreetMap