Mit dem Polizeilichen Informations- und Analyseverbund (PIAV) setzen Bund und Länder völlig neu auf bei der Entwicklung und Einführung eines Verbundsystems für den polizeilichen Informationsaustausch. Die grobe Kostenschätzung allein für eine erste Ausbaustufe beläuft sich auf 62 Millionen Euro. Wichtige Arbeitsbereiche der Polizei, in denen Informationsaustausch über Ländergrenzen hinweg besonders notwendig wäre, wie zum Beispiel Staatsschutz, Bekämpfung des Terrorismus, organisierte Kriminalität, Einbruchskriminalität oder Wirtschaftskriminalität, sind dabei noch gar nicht berücksichtigt.
Eine mögliche Alternative zum Polizeilichen Informations- und Analyseverbund (PIAV), nämlich die Verbesserung des bei Bund und Ländern schon eingeführten Systems INPOL-Fall, ist gar nicht erst ernsthaft in Betracht gezogen worden. Dabei gab es dafür den ausdrücklichen Auftrag der Innenministerkonferenz.
Wir werfen einen Blick auf die Hintergründe und die möglichen Folgen …
Man fragt sich, wie oft diese Absichtserklärungen noch als bahnbrechend und neu verkauft werden und auf welche Vergesslichkeit bzw. Desinteresse beim Leser die Urheber solcher Slogans eigentlich setzen. Denn all dies wird bereits seit mehr als zwanzig Jahren versprochen: Schon im „Konzept für die Fortentwicklung des polizeilichen Informationssystem INPOL“ von 1990 (sic!) [2] gehörte es zu den INPOL-Grundsätzen, dass „jedes Datum nur einmal eingegeben werden und automatisch für verschiedene INPOL-Anwendungen verfügbar gemacht werden“ soll. 1998 konnte man in der Festschrift des BKA zum 75. Geburtstag von Horst Herold [, dem geistigen Vater von INPOL] nachlesen, dass über den Kriminalpolizeilichen Meldedienst (KPMD) „so gut wie keine Tat-/Tat- oder Tat-/Täter-Zusammenführungen erfolgen“ und dieser Meldedienst daher „einzustampfen“ sei. INPOL-Neu sei das System der Zukunft, das den KPMD und die Sondermeldedienste ablösen werde.
Das Scheitern von INPOL-Neu
Doch daraus wurde nichts: Die Einführung des Systems INPOL-Neu, an der das Bundeskriminalamt und die Länder seit 1992 gearbeitet hatten, und das seit 1998 in eine ‚Realisierungsphase‘ eingetreten war, wuchs sich vielmehr zum totalen Flop aus: Testläufe im April 2001 zeigten, dass das System nicht lauffähig war und es zu kompletten Systemabstürzen kam [3]. Zum Zeitpunkt der Terroranschläge vom 11. September 2001 verfügten die deutschen Polizeibehörden nicht über ein Verbundsystem, das die Suche und Auswertung nach Zusammenhängen mit den Tätern bzw. den Anschlägen hätte herstellen können [4]. Daran sollte sich, wie die Untersuchungen zu den fehlgeschlagenen NSU-Ermittlungen zeigten, auch noch jahrelang nichts ändern [siehe auch unseren Beitrag ‚Was hat Informationstechnik mit den NSU-Ermittlungen zu tun?!‘].
Statt der angekündigten ‚Revolution‘ des polizeilichen Informationssystems gab es eine allmähliche ‚Evolution‘: Ursächlich dafür waren „Fehleinschätzungen hinsichtlich Zeitbedarf und Machbarkeit“, wie es der neue IT-Direktor des BKA, ein gewisser Harald Lemke, formulierte [5]: Die ‚Evolution‘ bestand darin, dass man sich bei INPOL-Neu nur noch auf die unabdingbaren Kernfunktionen beschränkte, wie Personen- und Sachfahndung, Kriminalaktennachweis (KAN) oder Datenbanken mit erkennungsdienstlichen Daten (ED). Der KPMD, die Sondermeldedienste, die SSD = Straftaten-/Straftäterdatei und, damit zusammenhängend, der ambitionierte Anspruch vom Erkennen von Tat-/Tat bzw. Tat-/Täter-Zusammenhängen fiel dagegen unter den Tisch. Und dort liegt er – bis heute.
Bedingt durch das Scheitern bei der Entwicklung von INPOL-Neu nahm man beim Bundeskriminalamt auch Abstand davon, ein solches System zum Erkennen von Zusammenhängen selbst entwickeln zu wollen. Denn Harald Lemke, der kurz zuvor aus Hamburg abgewanderte und für das BKA angeworbene neue IT-Direktor, konnte mit Alternativen aufwarten und Hoffnung verbreiten: Lemke war von 1998 bis 2002 IuK-Leiter der Polizei in Hamburg und hatte dort schon einmal die Kastanien aus dem Feuer geholt, nachdem die Entwicklung und Einführung eines polizeilichen Vorgangsbearbeitungssystems namens COMVOR(I) gründlich aus dem Ruder gelaufen war. Der dortige Behördenleiter, Ernst Uhrlau, berief in dieser Situation Lemke als den Krisenmanager. Der hatte es in Hamburg mit tatkräftiger Unterstützung externer Firmen, darunter u.a. Microsoft und Oracle, nicht nur geschafft, ein lauffähiges Vorgangsbearbeitungssystem COMVOR zur Einführung zu bringen. Er ließ auch noch zwei weitere Systeme entwickeln, nämlich POLAS – ein Informationssystem für Fahndungs- und klassische polizeiliche Auskunftszwecke, sowie CRIME, die „Criminal Research Investigation Management Software“.
INPOL-(Neu-Neu-)Bund
Im Bund-Länder-Projekt INPOL-Neu brannte es im Sommer 2001 lichterloh und der damalige Bundesinnenminister Schily drängte auf umgehende Einführung eines funktionsfähigen Systems. Lemke, der neue IT-Direktor des Bundeskriminalamts, trumpfte sogleich mit seinem ersten Brautgeschenk auf: Das gescheiterte (ursprüngliche) INPOL-Neu wurde sang- und klanglos eingestampft und durch POLAS ersetzt. Dieses Datenbanksystem wurde zum zentralen Kern des polizeilichen Informationsverbunds INPOL-Neu(-Neu). Heute heißt dieses System beim BKA INPOL-Z(entral).
INPOL-Neu(-Neu)-Land und die Geburtsstunde des Inpol Polas Competence Centers
Es wäre unfair, für das Scheitern des Projekts INPOL-Neu allein das BKA verantwortlich zu machen. Mitbeteiligt waren die Länder, die sich in der INPOL-Neu-Entwicklungsphase zusammengeschlossen hatten zu AGIL, der Arbeitsgemeinschaft INPOL-Land. Damals wie heute steht bei den Ländern das jeweilige Landesinteresse im Vordergrund. Und damals wie heute ist es Gepflogenheit, das Maximum aus einer vor allem „fachlichen“ Sicht zu fordern, ohne systemischen oder technischen Rahmenbedingungen angemessenen Raum zu geben. Eine erschreckende Kakophonie solcher Anforderungen der Länder war nicht unmaßgeblich für das Scheitern des ursprünglichen INPOL-Neu.
Auch sie waren geschockt vom Ausmaß der Pleite mit INPOL-Neu und stimmten daher, ohne den sonst üblichen öffentlichen Diskurs über die Schuldfrage, dem neuen Weg zu INPOL-Neu-Neu zu: Es wurde das IPCC errichtet, das Inpol Polas Competence Center, das ist eine Entwicklungskooperation der Länder ohne eigene Rechtsform, die die Aufgabe übernahm, das INPOL-(Neu-Neu)-System weiter zu entwickeln und zu pflegen. Das BKA gab seinen diesbezüglichen gesetzlichen Auftrag insofern ab an das IPCC.
INPOL-Neu-Neu geht in Betrieb
Knapp zwei Jahre nach dem Scheitern des ursprünglichen INPOL-Neu gab es im Sommer 2003 dann den Neustart für INPOL-Neu-Neu. Von Seiten des BMI, des BKA oder der Länder bemühte sich keiner um die Klarstellung, dass das INPOL-Neu von 2003 eine völlig andere Entwicklung war als das in den Sand gesetzte [3] INPOL-Neu von 2001. Der dafür verantwortliche Projektleiter erklärte, dass der weitere Ausbau nunmehr „stufenweise“ vorangehen solle. Vom Erklimmen der weiteren Stufen war dann allerdings öffentlich nichts mehr zu hören. Erst jetzt, zehn Jahre später und nachdem – angeblich – der PIAV deshalb „so schnell“ eingeführt werden muss, weil Neonazis über Jahre unentdeckt durch das Land ziehen und zehn Morde begehen konnten, ist man wieder aufgeschreckt und beginnt ‚zeitnah‘ mit dem „stufenweisen“ Ausbau von PIAV. Er soll beginnen mit dem „rechtsaffinen“ Deliktsbereich der Waffen- und Sprengstoffdelikte.
Zweitverwertungen …
Die Verwertung des Vorgangsbearbeitungssystems COMVOR
Unter den Brautgeschenken des weißen Ritters Harald Lemke aus Hamburg fand sich auch das Vorgangsbearbeitungssystem COMVOR. Und für dessen Zukunft sah es nicht gut aus, denn das BKA hat keinen Auftrag, die Länder mit Vorgangsbearbeitungssystemen zu versorgen. Kurzerhand kümmerte sich das IPCC also auch um COMVOR und etablierte eine weitere Entwicklungs- und Pflegekooperation für dieses Produkt. Darin schlossen sich anfangs die Länder Hamburg und Hessen zusammen und Baden-Württemberg trat der Kooperation kurz darauf bei. Im Jahr 2007 wurde Brandenburg dann der vierte im Bunde der COMVOR-Kooperationspartner.
Das Fallbearbeitungssystem CRIME wird INPOL-Fall beim BKA
Bessere Aussichten gab es für das Fallbearbeitungssystem CRIME, was seine weitere Verwendung auf Bund- und Länderebene anlangte. Denn INPOL-Neu sollte nach der ursprünglichen INPOL-Konzeption auch ‚PIOS-Arbeitsdateien für besondere Kriminalitätsbereiche, sowie Falldateien für Straftaten von länderübergreifender Bedeutung‚ bereitstellen. Da POLAS für diese Aufgabe technisch nicht ausgelegt war, entschloss man sich, für diese Zwecke das System CRIME aus Hamburg einzusetzen: Kernkomponente von CRIME ist ein hochflexibles Informationssystem, das das relationale Datenbanksystem Oracle nutzt. Es verwendet ein (immer gleiches) physisches Datenmodell (, das vielfach auch als ‚generisches Datenmodell‘ bezeichnet wird).
Als CRIME – in Form von INPOL-Fall, auf den Markt gebracht wurde, gab es ein solches System allerdings bereits: Es hieß POLYGON, war als polizeiliches Informations-, Analyse und Auswertungssystem bereits 1996 im Markt eingeführt worden und beim Bundesministerium des Innern bestens bekannt: Denn das BMI hatte für drei große Projekte, nämlich die landesweite Ausstattung der Kriminalpolizeibehörden in Ungarn, in der Slowakei und in der Ukraine Ausschreibungen durchgeführt [das gab es damals noch …], aus denen POLYGON als Sieger hervorgegangen war. In POLYGON war das ‚generische Datenmodell‘ erstmals realisiert worden. Und dafür erhielt POLYGON im Jahr 2001 die entsprechenden Patente in Deutschland und anderen Ländern [a].
Eine der ersten Amtshandlungen beim BKA bestand darin, CRIME umzutaufen. Beim BKA hieß das System nunmehr INPOL-Fall. Das bot sich an, denn seit Jahr(zehnt)en war auf der Bund-Länder-Ebene schon viel kommuniziert, konzipiert und diskutiert worden über „Fall“-Dateien, insbesondere die „Straftaten-/Straftäter-Datei“. INPOL-„Fall“ war also allein aus Marketing-Gesichtspunkten der richtige Name. Im Übrigen war – man schrieb immerhin das Jahr 2003 – ein erster praktischer Lösungsansatz überfällig für die seit mehr als einem Jahrzehnt versprochene Lösung für das Erkennen von Zusammenhängen. CRIME, bzw. INPOL-Fall, wie es nun beim BKA hieß, war für diese Aufgabe ziemlich gut aufgestellt, weil im Kern das generische Datenmodell und darin eine zentrale (Link-)Tabelle für sämtliche Beziehungen zwischen Objekten verwendet wird: Für die Auswertung von Zusammenhängen muss also „nur“ auf diese eine Tabelle zugegriffen werden und nicht – wie bei Verwendung von Datenbanken mit konventionellem Datenmodell – auf zig, bzw. hunderte verschiedener Tabellen [6].
CRIME wird Fallbearbeitungssystem in Baden-Württemberg, Hamburg und Hessen
Auch die Länder der COMVOR-Entwicklungskooperation hatten Interesse an der weiteren Nutzung von CRIME. Doch konnten sich BKA und diese Ländern nicht auf eine gemeinsame Entwicklung und Pflege von CRIME/INPOL-Fall verständigen. „Besondere Anforderungen an Verbunddateien, … u.a. Besitzerprinzip, dediziertes Benutzerrechtekonzept, hohe Verfügbarkeit und Performanz bei großen Datenmengen“ „ seien dafür der Grund gewesen, erklärte das Bundesministerium des Innern Jahre später in der Antwort auf eine Anfrage im Bundestag [7, dort Antwort zu Frage 18a]. Aus CRIME wurde daher einerseits INPOL-Fall beim BKA und es blieb bei CRIME in den drei COMVOR-Ländern. Techniker nennen so etwas ein ‚Forking‘, also eine Verzweigung einer Produktentwicklung aus ursprünglich einer gemeinsamen Wurzel. Soweit dies von außen zu erkennen war, änderte dies nicht allzu viel am Team der Personen, die für die CRIME-/INPOL-Fall-Entwicklung maßgeblich waren. Dabei handelte es sich um eine überschaubare Anzahl von Leuten, die teilweise früher mal für Oracle gearbeitet hatten, inzwischen jedoch als Freiberufler bzw. bei anderen Firmen tätig waren und die entsprechenden Entwicklungsaufträge für CRIME bzw. INPOL-Fall bearbeiteten.
INPOL-Fall beim BKA
Das BKA brauchte nach dem INPOL-Neu Desaster eine ganze Weile, um sich neu zu orientieren. Eine Zeitlang wurde INPOL-Fall als „Fallbearbeitungssystem“ für die Länder angepriesen. Ferner wurden auf der Basis von INPOL-Fall Datenbanken eingerichtet (aus historischen Gründen als „Dateien“ bezeichnet), mit denen wichtige Teile des kriminalpolizeilichen Meldedienstes und der Sondermeldediensten realisiert wurden. Dabei handelt es sich um zentral, also beim BKA, geführte Datenbestände mit Informationen aus bestimmten Deliktsbereichen von überregionaler Bedeutung, wie z.B. Innere Sicherheit, politisch motivierte Kriminalität (PMK), Falschgeldkriminalität, Kinderpornographie usw. Die Länder sind gesetzlich verpflichtet, dafür relevante Vorgänge (innerhalb festgelegter Zeit) an das BKA zu melden, wo die entsprechenden Informationen in die jeweilige Datenbank eingespeist werden und dort für alle Verbundteilnehmer, d.h. die Polizeibehörden des Bundes und der Länder zur Abfrage und Auswertung zur Verfügung stehen. In solche, so genannten Verbunddateien können Bund und Länder Informationen einspeisen und daraus abfragen.
INPOL-Fall wurde jedoch auch verwendet für sonstige Aufgaben des BKA: Bei den so genannten Amtsdateien handelt es sich um Datenbanken, die nur vom BKA befüllt und abgefragt werden, auch die Zentraldateien werden nur vom BKA aufgebaut, können jedoch auch von den Ländern abgefragt werden. Es entstand so innerhalb weniger Jahre ein Konglomerat von weit mehr als hundert Datenbanken für ganz unterschiedliche Zwecke. [9]
Das generische Datenmodell in CRIME und INPOL-Fall
INPOL-Fall und CRIME sind Informationssysteme, in deren Kern eine relationale (Oracle-) Datenbank sitzt. Beide Systeme nutzen als Tabellenstruktur das so genannte generische Datenmodell. Seine Besonderheit ist, dass die Datenbankstruktur fix ist, d.h. nicht jeweils angepasst werden muss auf die Informationen, die in der Datenbank gespeichert sind. Letzteres wird als ‚konventionelles Datenmodell‘ bezeichnet.
Eine kurze Beschreibung des generischen Datenmodells
Das generische Datenmodell
Das generische Datenmodell ist relativ einfach und sehr robust: Es besteht im Wesentlichen
- aus einer Tabelle, in der sämtliche Objekte gespeichert werden und zwar mit einem „Namen“ und einer Typangabe. Sie gibt an, ob es sich bei dem konkreten Objekt um ein Fahrzeug, eine Adresse, ein Person oder Firma usw. handelt.
- In einer zweiten Tabelle werden sämtliche Beziehungen zwischen Objekten gespeichert. Sie enthält eine systeminterne Identifikation für das erste und das zweite Objekt in dieser Beziehung, sowie einen Bezeichner für die Beziehung. Auf diese Weise entstehen kurze „Sätze“, wie z.B. ‚Jogi Löw‘ (Person) ‚ist Trainer der‘ ‚BRD Fußballnationalmannschaft‘ (Gruppierung).
- In einer dritten Tabelle werden die Merkmale von Objekten gespeichert. Solche Merkmale repräsentieren beschreibende oder identifizierende Angaben, wie z.B. die Haarfarbe, das Fahrzeugmodell, ein Geburtsdatum, einen Straßennamen u.v.m. Ein Merkmal besteht immer aus zwei Teilen, nämlich einer Merkmalsbedeutung und dem konkreten Wert, der dieser Bedeutung zugeordnet ist, wie z.B. Familienname:Kiefer, Ortsname:München, Geburtsdatum:06.07.1978 usw.
- Eine vierte Tabelle „linkt“, d.h. verbindet Objekte, mit den auf sie zutreffenden Merkmalen.
- Und dann kann es noch eine fünfte Tabelle geben, um Dokumente zu speichern, wie z.B. Text- oder Grafikdateien, Bilder, Multimediaformate u.ä.
- und eine sechste Datei, die solche Dokumente mit Objekten „linkt“.
Diese generische Struktur kann für viele verschiedene Anwendungsbereiche verwendet werden, ohne dass die Tabellenstruktur geändert werden müsste. Das ist einer der Vorteile des generischen Datenmodells, weil es Entwicklungszeit und -kosten spart, die bei konventionell modellierten Datenbanken aufgewendet werden müssen.
Das Informationsmodell im generischen Datenmodell
Wie oben erwähnt, gibt es im generischen Datenmodell „Typen“ für Objekte und Merkmale. Objekttypen geben an, zu welcher Gruppe gleichartiger Objekte ein bestimmtes Objekt gehört. Denn man möchte Personen mit Personen und Adressen mit Adressen vergleichen. Und die Merkmalstypen geben an, in welcher Bedeutung ein Merkmalswert verstanden werden soll. Ist „06.07.1978“ ein Geburtsdatum oder Datum eines Ereignisses?! Ist „Ullrich“ ein Vorname oder ein Nachname.
Ein solcher Vorrat an Objekttypen und Merkmalstypen ist natürlich notwendig für ein bestimmtes Anwendungsgebiet. Als Oberbegriff für solche Definitionen hat sich „Informationsmodell“ eingebürgert. Und das Informationsmodell wird im generischen Datenmodell in eigenen Vorratstabellen für die Objekttypen und die Merkmalstypen hinterlegt. Damit liegt auf der Hand, dass man in einem generischen Datenmodell beliebige Informationsmodelle verwenden kann, ohne dass sich dadurch an der Tabellenstruktur auch nur ein Jota ändert.
Der größte Fehler des BKA bei der Adaption des generischen Datenmodells
INPOL-Fall sollte, wie oben erwähnt, als zentrales Informationssystem für verschiedene Meldedienste und Deliktsbereiche auf- und ausgebaut werden. Man ging also munter daran, für jeden Fachbereich eine eigene INPOL-Fall-Datenbank (mit dem gleichen generischen Datenmodell) aufzubauen. Diese Trennung in voneinander abgegrenzte Daten“töpfe“ ist rechtlich so vorgeschrieben, da die Informationen, die für einen bestimmten polizeilichen Zweck erhoben wurden und gespeichert werden, nicht mit solchen gemischt werden dürfen, die für einen anderen Zweck erhoben und gespeichert werden. Jede dieser Datenbanken kann ein eigenes Informationsmodell verwenden. Und diese „Freiheit“ wurde von den fachlich verantwortlichen für die verschiedenen Datenbanken auch mit großer Begeisterung genutzt. Denn die hatten immer gute Begründungen dafür, warum z.B. für die Erfassung von PMK-Delikten spezifische Merkmale benötigt werden, dass fachspezifische Begriffskataloge für die Erfassung von Falschgelddelikten unumgänglich sind, oder warum ein dritter Deliktsbereich seine eigenen Objekttypen für unverzichtbar hält. Von Polizeibeamten, die nur ihre fachlichen Anforderungen sehen, kann man nicht verlangen, dass sie die negativen Folgen abschätzen können.
Wohl aber von den Mitarbeitern in der IT-Abteilung des BKA und ihren teuer bezahlten Beratern. Die grummelten zwar heftig, unternahmen jedoch nichts, um diesen Wildwuchs an Informationsmodellen zu kanalisieren. Mit der Folge, dass der Informationsaustausch zwischen den verschiedenen INPOL-Fall-Datenbanken erschwert bzw. verunmöglicht wurde, weil Sender- und Empfänger-Datenbank unterschiedliche Informationsmodelle verwenden. Wenige Jahre nach der Einführung von INPOL-Fall herrschte das große Chaos. Der neue IT-Direktor des BKA beschwerte sich in einem Gespräch mit mir darüber, dass „wir jetzt mehr als 150 verschiedene Datenbanken“ haben. Seine Schlussfolgerung war allerdings falsch. Nicht das generische Datenmodell war dafür verantwortlich, sondern nicht vorhandene Führung und Anleitung der IT-Fachleute im BKA im Umgang mit Informationsmodellen.
Damit war der wesentliche Vorteil des generischen Modells – und damit von INPOL-Fall, nämlich das in allen Datenbanken einheitliche, generische Datenmodell, ins Gegenteil verkehrt worden.
Erst Jahre später hat man diesen Riesenfehler erkannt und stellt mit dem IMP, dem Informationsmodell Polizei, (endlich) ein einheitliches, fachlich für die Bedürfnisse der Polizei ausgerichtetes Informationsmodell zur Verfügung. Das allerdings kommt viel zu spät, sind doch inzwischen seit Jahren die Fallbearbeitungssysteme in den meisten Ländern und beim BKA selbst mit ihren jeweils eigenen Informationsmodellen in Betrieb. Sie müssen auf jeden Fall auf einen einheitlichen Standard angepasst werden, egal, ob der nun GED heißt, oder „PIAV“ heißt oder „INPOL-Fall“.
Von INPOL-Fall zur Idee eines PIAV
Die Idee vom ‚oberflächenlosen‘ System
Mit der Einrichtung von INPOL-Fall beim BKA gab es nun zwar ein zentrales Datenbanksystem. Ungeklärt war allerdings, wie die Länder als eigentliche „Lieferanten“ der entsprechenden Informationen die Daten dorthin bringen bzw. aus den INPOL-Fall-Datenbanken abrufen sollten. In der ursprünglichen INPOL-Konzeption war die Rede gewesen von einem „oberflächenlosen“ System. Dahinter steckte die Vorstellung, dass der zentrale Datenbankrechner beim BKA und die Datenbankrechner der Länder in einem Rechner-Rechner-Verbund zusammengeschaltet würden (, wie es beim INPOL-Fahndungs- und Auskunftssystem ja auch realisiert worden war). Die Bedien-Oberfläche für den Nutzer sollte dann die des jeweiligen Landessystems sein, mit der Folge, dass der Bediener mit der für ihn gewohnten Oberfläche „seines“ Landessystems ohne Medienbruch auch Informationen für das zentrale System erfassen, bearbeiten bzw. abfragen könnte. Soweit die ursprüngliche Vorstellung. Sie war meilenweit entfernt von der tatsächlichen Situation dieser Tage.
Einführung von Fallbearbeitungssystemen beim BKA und in den Ländern
Denn die Länder hatten sich inzwischen weitgehend verabschiedet vom Konzept einer gemeinsamen Entwicklung von Bund und Ländern. Vorgangsbearbeitungssysteme waren inzwischen in den meisten Ländern entwickelt bzw. beschafft worden. Sie werden verwendet, um die Masse polizeilicher Vorgänge, wie z.B. die Führung des Tagebuchs, der Aufnahme und Bearbeitung von Strafanzeigen u.ä. dv-gestützt zu erfassen, zu bearbeiten und zu verwalten.
Viele Länder interessierten sich anschließend für Fallbearbeitungssysteme. Hinter diesem Begriff wird ein IT-Werkzeug verstanden, mit dem komplexe Ermittlungsverfahren in der Kriminalpolizei und die dabei anfallenden Informationen erfasst, bearbeitet und ausgewertet werden. In Brandenburg wird seit Jahren POLYGON für diese Zwecke genutzt. Das LKA in Bayern hatte gemeinsam mit bzw. auf Basis des Fallbearbeitungssystems der Firma Rola Security Solutions GmbH ein eigenes System namens EASY entwickelt. Und dann gab es, wie oben bereits gesagt, noch CRIME als Fallbearbeitungssystem in Hamburg, Hessen und Baden-Württemberg.
Auch im BKA rührte sich die Fraktion der kriminalpolizeilich tätigen Mitarbeiter und forderte ein eigenes Fallbearbeitungssystem. INPOL-Fall, bis vor kurzem noch vom BKA als „Fallbearbeitungssystem“ angepriesen, kam für die kriminalpolizeiliche Arbeit beim BKA selbst nicht in die engere Wahl. POLYGON wurde ebenfalls im BKA vorgestellt. Auf Anfragen nach dem weiteren Fortgang erhielten wir die Mitteilung, dass POLYGON von der IT-Leitung nicht erwünscht sei. Seinerzeit war Harald Lemke der IT-Direktor des BKA. Er wurde kurz darauf zum Beauftragten für eGovernment der hessischen Landesregierung und entwickelte dort das Konzept des Inpol Polas Competence Centers. Unter dessen Dach wurde dann auch CRIME weiter vermarktet.
Die Fachlichkeit im BKA entschied sich für ein System der Firma Rola Security Solutions, das im BKA den Namen B-CASE erhielt. Hier, wie auch in anderen Beschaffungsfällen zugunsten von Rola, wurden die Aufträge freihändig vergeben. Die Bundesregierung gab später an, dass im Rahmen dieser Beschaffung eine Marktsichtung durchgeführt worden sei [8], auch unter Einbeziehung von POLYGON. Sie muss stattgefunden haben, ohne dass dies bei Polygon bemerkt wurde.
Die INPOL-Fall ‚Bedienoberfläche‘
Dies alles zog sich über einige Jahre hin ohne dass ein ganz wesentliches Problem dadurch gelöst worden wäre: Wie kommen die Informationen aus den Ländersystemen in das zentrale INPOL-Fall-System beim BKA? Denn anfangs gab es noch nicht einmal eine Schnittstelle, über die ein Landessystem Informationen beim INPOL-Fall-System des BKA hätte anliefern können.
Das BKA stellt den Ländern für die Erfassung von meldepflichtigen Informationen bzw. für deren Abfrage vielmehr die„INPOL-Fall-Webapplikation“ zur Verfügung. Wenn ein Land also Informationen an eine INPOL-Fall-Datei zu übermitteln hatte, [wofür es gesetzliche Verpflichtungen gab und gibt!] mussten die entsprechenden Informationen entweder (Verbunddatei / im Land) noch einmal eingetippt werden oder aber die Informationen wurden aus klassisch-polizeilichen Wegen (z.B. über PC-gestützte Fernschreibverbindungen) vom jeweiligen Land an das BKA übermittelt und mussten dort in INPOL-Fall „eingepflegt“, d.h. noch einmal eingetippt werden (Zentraldatei). In beiden Fällen war man also von der versprochenen Einmalerfassung weit entfernt. Die Länder empfanden die Mehrfacherfassung – erst im eigenen Landessystem und dann noch einmal bei INPOL-Fall – zunehmend als Zumutung. Dies umso mehr, als Meldesysteme – schon lange vor INPOL-Fall – vor allem als lästige Pflicht angesehen wurden und immer noch werden, weil sie dem Sachbearbeiter vor Ort, der die Arbeit hat, wenig bis gar keinen Nutzen bringen.
INPOL-Fall erhält Schnittstellen
Ende 2005 kam dann neue Bewegung in die Sache INPOL-Fall. Einerseits verlangten die Länder die Möglichkeit einer Schnittstelle, um Informationen aus ihren Landessystemen ohne erneutes Abtippen direkt in die INPOL-Fall-Dateien = Meldesysteme übertragen zu können. Und andererseits stellte man überrascht fest, dass im Jahr 2006 die Fußball-Weltmeisterschaft in Deutschland stattfinden würde. Terroristische Anschläge oder ‚Großschadenslagen‘ können bei solchen Großereignissen nicht ausgeschlossen werden. Darauf musste Polizei sich vorbereiten. Das BKA wurde also aktiv und ließ eine Schnittstelle entwickeln für die Datenanlieferung an INPOL-Fall. Sie erhielt den Namen BLDS = Bund-Länder-Datei-Schnittstelle, was später verkürzt wurde zu BLS.
Diese BLS war und ist bis heute eigentlich eine feine Sache. Wir kamen mit ihr ab Ende 2005 in Berührung, weil wir den Auftrag hatten, die Datenanlieferung aus dem POLYGON-Landessystem über diese BLDS-Schnittstelle bei INPOL-Fall zu realisieren. Das bedeutet praktisch, dass Informationen, die in POLYGON bereits erfasst sind, von einem qualifizierten Sachbearbeiter selektiert und ggf. überarbeitet werden, dann zur Übertragung bereitgestellt werden und die POLYGON-/BLS-Schnittstelle die so selektierten Informationen aufbereitet, in eine XML-Datei „verpackt“ und zur Übertragung an das BKA bereitstellt. Auf diese Weise war realisiert, was schon viele Jahre zuvor als „oberflächenloses“ System gefordert war: Der Bediener konnte aus seinem Landessystem heraus ohne Medienbruch auch Informationen an das zentrale System beim BKA liefern.
Zwischen der Auftragserteilung im Frühjahr 2006 und dem Beginn der WM2006 lagen nur wenige Monate. Umso erfreulicher war es für uns, wie leicht es war, diese BLDS-Schnittstelle zwischen POLYGON und INPOL-Fall zu realisieren. Grund dafür war, dass das Datenmodell in INPOL-Fall, das ja auch das Datenmodell „hinter“ der BLS-Schnittstelle ist, offensichtlich sehr ähnlich ist zum generischen Datenmodell von POLYGON. Diese Erkenntnis fanden wir ebenso positiv, wie verblüffend. Ich führte daher Gespräche mit dem (neuen) IT-Direktor des BKA und brachte sowohl die Ähnlichkeit, als auch das seit Jahren vorliegende Patent zur Sprache – nicht etwa konfrontativ, sondern mit dem Vorschlag einer Kooperation. Nach mehrwöchiger „hausinterner“ Prüfung der nach dem Gespräch übersandten Patentschrift ließ er uns wissen, dass man zu der Erkenntnis gekommen, sei, dass POLYGON und INPOL-Fall „sehr ähnlich, aber nicht gleich“ seien. Was, außer den nachvollziehbaren Interessen des BKA, zu dieser Erkenntnis geführt hat, haben wir nicht erfahren. Die Bundesregierung wiederum steht auf dem Standpunkt [7, dort Antwort zu Frage 18b], dass etwaige Patentansprüche „erfolgreich zu erstreiten“ seien. Die weitere Möglichkeit, nämlich zu kooperieren und zu übernehmen, was POLYGON offensichtlich besser löst als INPOL-Fall, passt offensichtlich nicht in diese Denkweise.
INPOL-Fall wird schlecht geredet und geschrieben…
In politischen Erklärungen drückte die Bundesregierung immer dann ihre Zufriedenheit mit INPOL-Fall aus, wenn Erfolgsnachrichten gefragt waren:
“ Mit INPOL-Fall steht eine bewährte Softwareplattform für die ATD [Antiterrordatei] zur Verfügung, die von den Polizeien von Bund und Ländern bereits seit Jahren genutzt wird.“
hieß es im Dezember 2006 z.B. zur Begründung dafür, warum INPOL-Fall auch zur technischen Grundlage für die Antiterrordatei gemacht wird [16/3851].
Bei einem Gespräch mit dem IT-Direktor des BKA im April 2009, an dem auch der damalige Projektleiter für INPOL-Fall teilnahm, war dann zu hören, wie man abseits der politischen Erklärungen über INPOL-Fall denkt: Das System habe eklatante Performanceprobleme und im Übrigen habe man im BKA jetzt mehr als 150 verschiedene Informationsmodelle – das waren die beiden wesentlichen Argumente, die bei mir hängenblieben. Unser Vorschlag, dass man INPOL-Fall doch sicher verbessern könne – denn das „sehr ähnliche“ POLYGON hat keinerlei derartige Probleme, wurden beschieden mit der Aussage, dass das BKA „keine müde Mark mehr für INPOL-Fall investieren werde“. Angesichts des drängenden Problems mit der Mehrfacherfassung fand ich diese Aussage bemerkenswert. Wir haben daraufhin ein schriftliches Angebot unterbreitet, zu einem Preis von weniger als 8.000 Euro eine Kurzanalyse zu den beklagten Schwierigkeiten von INPOL-Fall zu erarbeiten. Die Antwort darauf war, dass man „bei Bedarf“ auf unser Angebot zurückkomme und im Übrigen „externe Dienstleistungen, so sie denn erforderlich sein sollten, unter Beachtung der Wertgrenzen durch das Beschaffungsamt des BMI zugekauft würden.“ Zumindest das war eine Nachricht, die positive Veränderungen in der Zukunft erwarten ließ …
Im Februar 2012 gab es dann wieder einmal eine Äußerung der Bundesregierung zu INPOL-Fall: In ihrer Antwort auf die umfangreiche Anfrage mit dem fachlich nicht ganz passenden Titel „Computergestützte Kriminaltechnik bei Polizeibehörden“ [7, Seite 24 oben], teilt die Regierung mit, dass „in den letzten vier Jahren noch ca. 6,6 Mio Euro für externe Dienstleistungen zur Weiterentwicklung“ ausgegeben wurden. Die Weiterentwicklung von INPOL-Fall, heißt es im Gegensatz dazu an anderer Stelle, sei „durch das BKA selbst vorgenommen“ worden.
Und auch aus den Ländern war Negatives über INPOL-Fall zu hören. Beklagt wurden auch hier ganz pauschal Performanceprobleme. Ob es sich dabei jedoch um Probleme des INPOL-Fall-Zentralsystems handelt oder um Schwächen des INPOL-Fall-Erfassungs- und Abfragesoftware oder um überlastete Datenleitungen, spielte keine Rolle. Denn aus Sicht vieler Länder ist jedes Zentralsystem, das aufgrund gesetzlicher Verpflichtung bedient werden muss, viel Last und Aufwand und wenig Nutzen. Viel verlockender erscheint da der Gedanke, dass Informationsaustausch zwischen Bund und Ländern – und vor allem auch zwischen den Ländern – doch ein Leichtes sein müsse, wenn nur alle das gleiche System verwenden. Dass die Götter Hindernisse aufgetürmt haben zwischen diese These und die Wirklichkeit, ergibt sich aus der Tatsache, dass auch Länder, die Systeme des gleichen Herstellers verwenden, anscheinend nicht so ohne weiteres in der Lage sind, Informationen untereinander auszutauschen. Es könnten diese Hindernisse etwas mit unterschiedlichen Daten- und Informationsmodellen zu tun haben …
Und zumindest in einem Punkt – nämlich dem einheitlichen Datenmodell – hätte INPOL-Fall objektiv belegbare Vorteile. Gefragt nach den Einsatzmöglichkeiten von INPOL-Fall für den PIAV, weiß die Bundesregierung zu berichten [7, Antwort zu Frage 18d]:
„INPOL-Fall wurde im Rahmen der Bund-Länder-Expertengruppe PIAV betrachtet. Für ein neues, zukunftsweisendes PIAV-Zentralsystem kommt INPOL-Fall nach Einschätzung der Expertengruppe aufgrund bestehender funktionaler und technischer Einschränkungen nicht in Betracht.“
Diese Einschätzung war – wieder einmal, wenn es um IT-Systeme in der deutschen Polizei geht – dem gewünschten Ergebnis geschuldet, das da lautete: bloß wegzukommen von INPOL-Fall. Wie die oben erzählte Geschichte belegt, gibt es dafür, neben den behaupteten Einschränkungen ja auch noch ganz andere Motive. Und überhaupt nicht geprüft wurde die naheliegende Idee, das inzwischen entwickelte einheitliche Informationsmodell der Polizei, nämlich IMP, als zukunftsweisendes gemeinsames Informationsmodell auf der Basis von INPOL-Fall zu verwenden.
PIAV – die Geschichte wiederholt sich …
Mit dem PIAV wird also nach zehn Jahren völlig neu aufgesetzt – auf der grünen Wiese. Eine echte Verbesserung ist, dass es inzwischen dieses standardisierte gemeinsame Informationsmodell Polizei (IMP) gibt. Zu hören ist allerdings, dass auch darin schon wieder etliche fachspezifische „Cluster“ bzw. „Dateien“ gebildet werden sollen, was die Befürchtung aufkommen lässt, dass bei PIAV der Fehler mit nicht einheitlichen Informationsmodellen wiederholt wird.
Die Vorteile eines einheitlichen Datenmodells, wie es in INPOL-Fall gegeben ist, scheinen noch nicht erkannt worden zu sein. Es müsste sich sonst nämlich in der Auftragsbekanntmachung für PIAV-Zentral eine entsprechende Anforderung finden.
Sonstige „funktionale oder technische Verbesserungen“ des PIAV gegenüber INPOL-Fall sind nicht erkennbar: Man tauscht also das System INPOL-Fall mit seinem einheitlichen Datenmodell und aus dem Ruder gelaufenen, unterschiedlichen Informationsmodellen aus gegen ein neues System PIAV mit nicht einheitlichem Datenmodell und (zumindest anfänglich) einheitlichen Informationsmodell – ein wirklich bahnbrechender Fortschritt! Wesentlich einfacher, wäre es, INPOL-Fall mit dem einheitlichen Informationsmodell Polizei auszustatten und bestehende funktionale Schwächen zu beseitigen. Doch dafür besteht offensichtlich keinerlei Bereitschaft.
Auch hinsichtlich der Kosten kommen schlimme Befürchtungen auf: Allein für die „Entwicklung und Anpassung“ von PIAV-Zentral sind – nach einer ersten „groben Aufwandsabschätzung“ 22 Millionen Euro aufzuwenden. Insgesamt beläuft sich diese Schätzung auf 62 Millionen Euro. [1]
Was solche Kostenschätzungen taugen, lässt sich in einer Auskunft der Bundesregierung aus dem Jahr 2001 ablesen. Es ging um Schwierigkeiten bei der Einführung von INPOL-Neu [4, dort Antwort zu Frage 6]. Gefragt wurde nach anfänglich geschätzten Gesamtkosten von 17,4 Mio DM, die für INPOL-Neu in einer ebensolchen Grobschätzung angegeben waren und die sich – nach Auskunft der Regierung – dann auswuchsen auf rund 116 Mio DM (ohne interne Personalkosten) beim Bund und den Ländern.
Zur Begründung sagt die Bundesregierung:
„Ungeachtet dessen sind in dem Projekt – wie bei anderen IT-Großprojekten aus dem öffentlichen und privaten Sektor – im Laufe der Jahre Kalkulationssteigerungen notwendig geworden. Sie erklären sich im Wesentlichen aus der sukzessiven Erhöhung der funktionellen Anforderungen während der Projektlaufzeit sowie aus einer Steigerung der technischen Komplexität des Systems im Vergleich zu den ursprünglichen Annahmen.“
.
Vieles spricht dafür, dass der Polizeiliche Informations- und Analyseverbund auch in dieser Hinsicht seinem Vorgänger – INPOL-Neu – in nichts nachstehen wird.
Hinweis in eigener Sache
Die Autorin gehört zu den Entwicklern von POLYGON, ist Inhaberin der Patente in D, A, CH und USA, für das generische Datenmodell, das in POLYGON integriert ist und war im hier relevanten Zeitraum Projektleiterin für polizeiliche Informationssysteme bei der Firma Polygon und insofern in die Entwicklung involviert. Daher auch die zeitweilige „ich“- bzw. „wir“-Form.
Quellen zu diesem Beitrag
[1] Polizeiliche Datensysteme zur Erfassung und Analyse Politisch motivierter Kriminalität – rechts, Antwort der Bundesregierung auf die Kleine Anfrage der FraktionBündnis90/Die Grünen, 16.09.2013, DBT-Drs. 17/14753
http://dipbt.bundestag.de/dip21/btd/17/147/1714753.pdf [2] Grundsätze für Zusammenarbeit von Bund und Ländern bei der polizeilichen Datenverarbeitung im Rahmen des Informationssystems der Polizei INPOL, BMI – P I 5 – 006 123-010-9/9, zitiert nach Dieter Küster: Informationstechnologie – Entwicklung und Auswirkungen auf die Polizei in H.L. Zachert (Hrsg.) 40 Jahre Bundeskriminalamt. [3] Neues Fahndungssystem wird zum Millionengrab, 29. 05.2001, SpiegelOnline
http://www.spiegel.de/panorama/bundeskriminalamt-neues-fahndungssystem-wird-zum-millionengrab-a-136815.html [4] Schwierigkeiten bei der Einführung des Fahndungscomputernetzes INPOL-Neu,
05.12.2001, Antwort der Bundesregierung auf die Kleine Anfrage der CDU/CSU-Fraktion,
DBT-Drs 14/7734
http://dipbt.bundestag.de/doc/btd/14/077/1407734.pdf [5] Polizei-Informationssystem: Nach nur zwei Jahren entpuppte sich INPOL-Neu
als 60-Mio-Euro-Flop, VDI-Nachrichten [6] Informationstechnik für die Fachlichkeit (6): – Wie kommt das Informationsmodell ins Datenmodell? 27.08.2013, Polygon-Blog
http://blog.polygon.de/2013/08/27/it_fd_fachlichkeit_teil-6_infmodell_in_datenmodell/4054 [7] Computergestützte Kriminaltechnik bei Polizeibehörden, 06.02.2012,
Antwort der Bundesregierung auf die Kleine Anfrage der Linksfraktion, DBT-Drs 17/8544 (neu)
http://dipbt.bundestag.de/dip21/btd/17/085/1708544.pdf [8] Lobbyismus bei Beschaffungsprojekten des Bundesministeriums des Innern, 04.04.2011,
Antwort der Bundesregierung auf die Kleine Anfrage der Linksfraktion, DBT-Drs 17/5343
http://dipbt.bundestag.de/dip21/btd/17/053/1705343.pdf [9] Beim Bundeskriminalamt geführte Gewalttäter- und andere Dateien, 28.02.2010,
Antwort der Bundesregierung auf eine Kleine Anfrage der Linksfraktion, DBT-Drs 17/2803
http://dipbt.bundestag.de/dip21/btd/17/028/1702803.pdf
Copyright und Nutzungsrechte
(C) 2013ff CIVES Redaktionsbüro GmbH
Sämtliche Urheber- und Nutzungsrechte an diesem Artikel liegen bei der CIVES Redaktionsbüro GmbH bzw. bei dem bzw. den namentlich benannten Autor(en). Links von anderen Seiten auf diesen Artikel, sowie die Übernahme des Titels und eines kurzen Textanreißers auf andere Seiten sind zulässig, unter der Voraussetzung der korrekten Angabe der Quelle und des/der Namen des bzw. der Autoren. Eine vollständige Übernahme dieses Artikels auf andere Seiten bzw. in andere Publikationen, sowie jegliche Bearbeitung und Veröffentlichung des so bearbeiteten Textes ohne unsere vorherige schriftliche Zustimmung ist dagegen ausdrücklich untersagt.