Informationstechnik für die Fachlichkeit (5)

Was hat Informationstechnik mit den NSU-Ermittlungen zu tun?!

5. August 2013 | Von | Kategorie: DATENBANKEN

Die wichtigste Aufgabe von polizeilichen Informationssystemen, insbesondere den Fallbearbeitungs-, Analyse- und Auswertungssysteme besteht darin, Zusammenhänge erkennbar und auswertbar zu machen. Das wird auch für den PIAV hervorgehoben, den neuen Polizeilichen Informations- und Analyseverbund: Er soll insbesondere die Aufklärung von Tat-/Täter- bzw. Tat-/Tat-Zusammenhängen ermöglichen.
Warum aber wurden bei den NSU-Ermittlungen offensichtliche Gemeinsamkeiten und Zusammenhänge nicht (rechtzeitig) erkannt, um die Täter dingfest zu machen, bevor weitere Menschen ihr Leben lassen mussten? Hat etwa das Informationsmodell bzw. das Datenmodell, also die eingesetzte polizeiliche Informationstechnik, Auswirkungen für die Auswertbarkeit von Gemeinsamkeiten und Zusammenhängen. Dieser Frage werden wir im aktuellen Beitrag näher nachgehen.

Gemeinsamkeiten und Zusammenhänge bei den NSU-Morden

Die Untersuchungsausschüsse zu den NSU-Ermittlungen stehen vor dem Abschluss ihrer Arbeiten. Sie haben erhebliche Versäumnisse bei den polizeilichen Ermittlungen zutage gefördert. Erstaunlicher Weise hat sich jedoch niemand näher mit der Frage beschäftigt, ob und welchen Einfluss die Informationstechnik auf den Verlauf und die Ergebnisse dieser Ermittlungen hatte. Denn es gab ja Gemeinsamkeiten zwischen den Morden des NSU, die bei mehreren Taten vorkamen: Im Bericht der Bund-/Länder-Kommission Rechtsterrorismus findet man (dort ab S. 146) z.B.

  • Opfer: Neun von zehn Opfern waren Männer von türkischer bzw. griechischer Abstammung
  • Tatort: Ladenlokal, wo diese Männer arbeiteten / das ihnen gehörte
  • Tatwaffe: Pistole Marke Ceska
  • Begehungsweise: Zwei oder mehr Schüsse in Kopf bzw. Oberkörper
  • Personen, die in Tatortnähe beobachtet wurden: Ein bzw. zwei Männer, in manchen Fällen mit Fahrrädern unterwegs, mal mit Baseballmützen auf dem Kopf, mal mit Radlerhose bekleidet.

Das sind, zugegeben, recht vage Angaben, die jedoch zusammengenommen ein deutliches Muster ergeben: Ob und wie gut man dieses Muster im jeweiligen polizeilichen Informationssystem abbilden kann, darüber entscheidet – erstens – das Informationsmodell und – zweitens – das physische Datenmodell. Dies wird im Folgenden näher untersucht, wobei es nicht darum geht, Stärken bzw. Schwächen von bestimmten, damals eingesetzten polizeilichen Informationssystemen beleuchten. Was auch nicht mehr sonderlich aktuell wäre, denn alle Systeme haben sich seither weiterentwickelt. Es geht vielmehr darum, grundlegende, konzeptionelle Aspekte zu verdeutlichen, nämlich die, wie ein Informationssystem ausgelegt sein muss, um die Auswertbarkeit von Zusammenhängen zu unterstützen – bzw. was deren effektive Auswertung verhindert.

Problem Nr. 1: Uneinheitliche und nicht immer „passende“ Objekttypen

Zusammenhänge lassen sich dann gut erfassen und auswerten, wenn die relevanten Informationen als Informationsobjekte dargestellt werden. Welche Objekttypen verfügbar sind, also vom Erfasser genutzt werden können, darüber entscheidet das Informationsmodell im eingesetzten Informationssystem. Leider war die Auswahl der Objekttypen zur Zeit der NSU-Ermittlungen ziemlich uneinheitlich und gibt es bis heute keinen bundesweit einheitlichen, in allen Fallbearbeitungssystemen gleichermaßen verwendeten Satz von Objekttypen. Dass mit dem IMP[II], dem Informationsmodell Polizei, ein wesentlicher Schritt unternommen wird, dieses Manko zu beseitigen, ist unstrittig und zu begrüßen. Allerdings ist das IMP bis heute eben noch nicht in allen polizeilichen Informationssystemen der Bundes- bzw. Länderpolizeibehörden der gemeinsame, verbindliche Standard.

Die notwendigen Objekttypen im „NSU-Fall“

Doch schauen wir uns zunächst an, was sich im „NSU-Fall“ – im Hinblick auf die später festgestellten Gemeinsamkeiten – als Informationsobjekt anbietet und welche Objekttypen im entsprechenden Informationsmodell vorhanden sein müssten. Es sind dies

  • die Opfer (Objekttyp: Person)
  • die Ladenlokale als Tatorte (Objekttyp: Gewerbe-/Geschäftsbetrieb (für das Geschäft / Ladenlokal), auch möglich als „Örtlichkeit“)
  • die Begehungsweise (Modus Operandi) der Tat (Objekttyp: Straftat bzw. Begehungsweise / Modus Operandi)
  • die Tatwaffe (Objekttyp: Waffe bzw. Schusswaffe)
  • die von Zeugen beobachteten (ein, meist zwei) Männer am Tatort (Objekttyp: Person)
  • Fahrräder, die von diesen Männern benutzt wurden (Objekttyp: Fahrrad / Zweirad, hilfweise: Fahrzeug, sehr hilfsweise: Sache)
  • Bekleidungsgegenstände, wie die Baseballmützen oder die Radlerhose (Objekttyp: Kleidungsstück, sehr hilfsweise: Sache)

Optimale, objektorientierte Darstellung

Eine optimale „objektorientierte“ und für die Auswertung von Zusammenhängen optimierte Erfassung sieht z.B. so aus:

NSU_OO1_939_484
Abbildung 1: Beispiel für eine umfassende, objektorientierte Erfassung

Die in der Aufzählung oben verwendeten Objekttypen dürften für Polizisten und Nicht-Polizisten gleichermaßen plausibel und nachvollziehbar sein. Allerdings standen nicht alle oben genannten, notwendigen Objekttypen in den damals verwendeten Informationssystemen zur Verfügung. Daran hat sich auch bis heute nicht viel geändert:

Objekttypen für Geschäfte / Ladenlokale bzw. ‚Örtlichkeiten‘

Ein Objekttyp „Geschäfts- und Gewerbebetrieb“ existiert bis heute nicht in den meisten polizeilichen Informationssystemen bzw. gemeinsam abgestimmten Informationsmodellen für die Polizei. Vielmehr werden sämtliche nicht-natürliche Personen zusammengefasst zu einem Über-Objekttyp, dessen Merkmalstypen [Sie erinnern sich, dass zu jedem Objekttyp ein Satz von festgelegten Merkmalstypen gehört …] es schwierig machen, damit einfach mal einen türkischen Obst- und Gemüseladen zu erfassen. Was überreichlich vorhanden ist, sind Merkmalstypen zur Erfassung von Registernummer, Gewerbeanmeldung und Gründungsdaten – doch spielen die für die hier in Frage stehende Ermittlung und Erkennung des Musters der Gemeinsamkeiten ersichtlich keine Rolle.

In Frage käme auch der Objekttyp ‚Örtlichkeit‘, der in vielen polizeilichen Informationssystemen vorhanden ist. Allerdings wird auch der nicht einheitlich verwendet. Modernere Informatinsmodelle tendieren dazu, eine Örtlichkei dann als eigenständiges Objekt darzustellen, wenn ausgedrückt werden soll, um welche Art von Örtlichkeit es sich handelt und ob diese Feststellung von kriminalistischer Relevanz wäre, was beides hier der Fall ist. Örtlichkeit findet sich jedoch in anderen, bundesweit verwendeten Informationsmodellen auch nur als Merkmalstyp nicht als eigenständiger Objekttyp, das dafür aber gleich bei mehreren Objekttypen. Diese Merkmalstypen sind i.d.R. auch noch mit einem Katalot hinterlegt, in dem sich als die Begriffe mit dem höchsten Näherungswert ‚Verkaufsraum‘ oder ‚Marktstand‘ oder ‚Kiosk‘ finden. Dass es sich im vorliegenden Beispiel um ein südländisches Obst- und Gemüsegeschäft kann man damit also nicht zum Ausdruck bringen.

Was also ist das Ergebnis? In manchen Informationssystemen werden die Ladenlokale als Objekte vom allgemeinen Typ ’nicht-natürliche Person‘ erfasst, in anderen dagegen als solche vom Objekttyp ‚Örtlichkeit“, in wieder anderen dagegen gar nicht als eigenständige Objekttyp, sondern verschwinden als Merkmal vom Typ „Örtlichkeit“ im Objekttyp „Ereignis“. Der Erfasser in Nürnberg, Kassel oder Dortmund hat keine Chance: Er muss das Objekt erfassen, wie es ihm „sein“ Informationssystem anbietet. Dass nicht abgestimmte Informationsmodelle zwangsläufig dazu führen, dass an sich zusammengehörige Informationen nicht mehr als solche zu erkennen sind, als „verschwinden“ im Heuhaufen der Informationen, ist die zwangsläufige Folge.

Objektypen für Sachen

Besonders problematisch wird es erfahrungsgemäß bei der Abbildung von Sachen / Gegenständen in einem Informationssystem. Doch gerade die Sachen sind am Anfang einer Ermittlung, wo konkrete Personen häufig noch nicht bekannt sind, besonders relevant als Kandidaten zum Erkennen von Zusammenhängen. Denn Sachen sind ja das, was Zeugen wahrgenommen haben können. Sehen wir uns dies mit Bezug zum NSU-„Fall“ an:
Die Fahrräder: Für Fahrrad / Zweirad gab es in polizeilichen Informationssystemen zur Zeit der NSU-Ermittlungen meist keinen eigenen Objekttyp, sie wurden dann z.B. als ‚allgemeines Fahrzeu'“ oder als'“Sache‘ erfasst. Selbst für Schusswaffen gab bzw. gibt es in den Informationsmodellen polizeilicher Informationssysteme mitunter keinen eigenen Objekttyp. Sie sind dann ebenfalls als ‚Sache / allgemeiner Gegenstand‘ zu erfassen. Ähnlich verhält es sich mit den Kleidungsstücken. Auch dafür gibt es keinen eigenen Objekttyp, sondern sie sind (in den meisten polizeilichen Informationssystemen) zu erfassen als ‚Sache / allgemeiner Gegenstand‘. Wer schon einmal versucht hat, die fallrelevante Radlerhose, das Fahrrad, die Baseballmütze oder eine Rockerkutte mit all ihren spezifischen und sehr bedeutungsreichen Patches in das Korsett des „üblichen“ Objekttyps ‚Sache / allgemeiner Gegenstand‘ zu zwängen, weiß, wie viel an sich im Einzelfall vorhandene Information da verloren geht.

Nicht, dass es für diesen Objekttyp keine Merkmalstypen / Datenfelder gäbe: Aber was fängt der Erfasser an, wenn er ‚Art des Gegenstands‘ aus einem Katalog auswählen muss, in dem seine Radlerhose, Baseballmütze oder Rockerkutte gar nicht vorkommt?! Was tut er, wenn er zwar umfassende Möglichkeiten hat, Länge, Höhe, Breite und Gewicht der ‚Sache‘ einzutragen oder die ‚Individualnummer‘?! Er seufzt im Geiste, läßt alle diese Felder leer und schreibt alles, was ihm sonst noch wichtig erscheint, was aber beim besten Willen nicht unterzubringen ist, in die ach so beliebten Volltextfelder. Der Sachbearbeiter hat damit seine Pflicht und Schuldigkeit getan! Gleichzeitig ist damit vorhandene und für die Ermittlung / Aufklärung sehr relevante Information auf dem großen Volltext-Heuhaufen gelandet ist und jeglicher automatisierter Auswertung von Zusammenhängen vermutlich für immer entzogen. Denn wer hat schon die Zeit und die Mittel, irgenwann später systematisch den Heuhaufen zu durchsuchen und woher sollten sich, wenn man nach ‚Nadeln‘ sucht, Zusammenhänge zwischen den Nadeln im Heuhaufen automatisch ergeben?!

Die Erfassung des gleichen Sachverhalts wie in Abbildung 1, oben, könnte dann folgendermaßen aussehen:

NSU_Volltext2
Abbildung 2: Mögliche Erfassung des gleichen Sachverhalts, nicht objektorientiert optimiert

Problem Nr. 2: Unsicherheiten im Umgang mit nicht genau identifizierbaren Informationsobjekten

Polizisten sind darauf ausgebildet, bei der Erfassung von Informationen möglichst genaue, identifizierende Angaben zu machen. Zu einer Person gehören – nach dem Weltbild eines Polizisten deren Personalie, also Familienname, Vorname und möglichst das Geburtsdatum, zu einem Fahrzeug das Kennzeichen, und am besten noch Hersteller und Modell, zu einer Ortsangabe die möglichst präzise Adresse. Viele polizeiliche Informationssysteme verstärken diesen Trend, indem sie in den entsprechenden Datenfeldern (also z.B. im Feld „Familienname“ einer Person) eine Eingabe erzwingen (Pflichtfeld).

Und hier schlägt dann häufig ein Denkfehler zu bei den Sachbearbeitern: Sie sagen sich: Wenn ich den Namen nicht kenne, kann ich ihn auch nicht eingeben, also kann ich die Person nicht erfassen. Gerade in der Fallbearbeitung ist es jedoch gang und gäbe, dass – besonders zu Beginn einer Ermittlung – Namen und andere identifizierende Merkmale noch nicht oder noch nicht vollständig bekannt sind. Demzufolge beobachtet man in der Praxis häufig, dass Personen (und andere relevante Objekte) nicht erfasst werden, weil die konkreten Namens- oder Identifizierungsbestandteile, die möglicherweise das Informationssystem auch noch als Pflichtfeld erzwingt, dem Sachbearbeiter nicht bekannt sind. Und da er auch nicht über Regeln verfügt, wie er Personen (oder andere Objekte) eingeben soll, deren Namensangaben er nicht kennt – läßt er sie dann schon eher mal ganz weg. Und so kommt es dann in einem „NSU-Fall“, dass südländische Ladenlokale, Fahrradfahrer, Fahrräder, Baseballmützen und Radlerhosen unerfasst bleiben, weil man ihren Wert als Informationobjekte (und mögliche ‚Missing Links‘) nur deswegen nicht würdigt, weil man nicht weiß, wie man ein solches Objekt ohne konkreten Namen im System eingeben soll.

Das Problem wäre meiner Ansicht nach zu beheben mit klaren und bundesweit einheitlichen Erfassungsregeln darüber, wie Informationsobjekte mit unbekannten bzw. unvollständigen identifizierenden Merkmalen zu erfassen sind – und mit mehr bzw. besserer Aus- und Fortbildung für Polizeibeamten in diesem Punkt.

Problem Nr. 3: Ein Datenmodell ohne zentrale Linktabelle verhindert die Erfassung aller vorhandenen Beziehungen und Zusammenhänge

Die Abbildung 1 oben zeigt eine Informationserfassung, die die im Sachverhalt vorkommenden Informationsobjekte in optimaler Weise (d.h. ohne Informationsverluste!) darstellt. Um dies leisten zu können, muss das zugrunde liegende polizeiliche Informationssystem im Umgang mit Beziehungen zwischen Objekten die folgenden Anforderungen erfüllen:

  • Jedes Objekt kann einmal oder mehrfach mit jedem anderen Objekt verbunden / in Beziehung gesetzt werden
  • Jedes Objekt von jedem Objekttyp kann mit jedem Objekt von gleichen oder jedem anderen Objekttyp (einmal oder mehrfach) in Beziehung gesetzt werden
  • Jede Beziehung zwischen zwei Objekten hat eine Richtung (von Objekt A nach Objekt B)
  • Für jede Beziehung zwischen zwei Objekten kann (im Bezug auf die Richtung der Beziehung) eine eindeutige Aussage vergeben werden (z.B. „A ist Vater von B“ | „B ist Sohn von A“)
  • Für jede Beziehung kann bei Bedarf angegeben werden, von wann bis wann sie gültig war
  • Für jede Beziehung kann bei Bedarf angegeben werden, wann sie festgestellt wurde
  • Für jede Beziehung kann bei Bedarf eine qualitative Bewertung angegeben werden

Ob ein polizeiliches Informationssystem diese fachlich notwendigen (!!!) Anforderungen erfüllt, hängt auschließlich davon ab, wie das darin verwendete Datenmodell mit Beziehungen umgeht. In Kürze läßt sich sagen, dass ein System sowohl vertretbare Antwortzeiten liefern als auch diese Anforderungen nur erfüllen kann, wenn eine zentrale Linktabelle verwendet wird. Dies ist erfüllt bei den so genannten „generischen“ polizeilichen Informationssystemen (, also Polygon, aber auch (soweit hier bekannt) bei Crime und Inpol-Fall).

Im Zweifelsfall sollten Sie also für ‚Ihr‘ polizeiliches Informationssystem hinterfragen,

  • ob dennoch sämtliche Beziehungen zwischen sämtlichen Objekten von allen möglichen Objekttypen
  • in einer zentralen Linktabelle = Tabelle für Beziehungen gespeichert werden,
  • ob für jede Beziehung eine Richtung (von A nach B) dargestellt ist,
  • ob eine entsprechend gerichtete Aussage („A ist Vater von B“ | „B ist Sohn von A“),
  • ob für jede Beziehung eine Zeitperiode angegeben werden kann „von wann“ „bis wann“ diese Beziehung Gültigkeit hatte und
  • ob für jede Beziehung eine qualitative Bewertung eingegeben werden kann.

Sollte dies nicht der Fall sein, hat das in Frage stehende polizeiliche Informationssystem technisch bedingte Einschränkungen im Umgang mit Beziehungen, die es schwierig, wenn nicht unmöglich machen, mit Beziehungen so umzugehen, wie oben beschrieben, d.h. wie die polizeiliche Fachlichkeit dies braucht bzw. die Anforderungen zu erfüllen, die auch der PIAV, der gerade entstehende polizeiliche Informations- und Analyseverbund, als zwingend vorgibt: Das Erkennen und Aufklären von Tat/Täter- bzw. Tat-/Tat-Zusammenhängen.

___________________________________________________________________________________________________

Dieser Beitrag ist Teil der Serie …

Informationstechnik für die Fachlichkeit

Sämtliche bisher erschienenen Beiträge der gleichen Serie

Teil 1: Daten- und Informationsmodelle
Teil 2: Entwicklung des Informationsmodell – Objekttypen
Teil 3: Entwicklung des Informationsmodells – Merkmalsbedeutungen / „Datenfelder“
Teil 4: Entwicklung des Informationsmodells – Merkmalsbegriffe und Kataloge
Teil 5: Was hat Informationstechnik mit den NSU-Ermittlungen zu tun?!
Teil 6: Wie kommt das Informationsmodell ins Datenmodell?
 

Schlagworte: , , , , , , ,

Schreibe einen Kommentar