Akteure | BMI und untergeordnete Behörden || IT-Systeme Inpol-Neu, Inpol-Fall und PIAV

Ein eigener Fall: Inpol-Fall

1. Oktober 2013 | Von | Kategorie: BMI UND SICHERHEITSBEHÖRDEN, CRIME, INPOL POLAS

Wenn es einen Meistertitel gibt in der Disziplin ‚Das Rad neu erfinden‘, so gebührt er der deutschen Polizei und ihrer IT-Planung und -Konzeption. Das Rad, das derzeit neu erfunden wird, heißt PIAV – Polizeilicher Informations- und Analyseverbund. Es soll wieder mal ein Verbundsystem werden, welches von Länder- und Bundespolizeibehörden gemeinsam genutzt wird. Es soll wieder mal das seit Jahrzehnten nicht gelöste Problem der Einmalerfassung und Einmalabfrage lösen. Und es soll – Überraschung! – Zusammenhänge erkennen, „insbesondere Tat-/Tat- und Tat-Täter-Zusammenhänge“, um Straftaten von länderübergreifender Bedeutung analysieren und auswerten zu können [1].

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 [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 „Vater von Inpol“] nachlesen, dass über den bis dahin verwendeten 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 ab- 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 IPCC

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-Land 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.

Die Verwertung von ComVor

Unter den Brautgeschenken des weißen Ritters Lemke aus Hamburg fand sich auch das Vorgangsbearbeitungssystem ComVor. Für ComVor 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, in der sich anfangs die Länder Hamburg und Hessen zusammenschlossen und Baden-Württemberg kurz darauf beitrat. Im Jahr 2007 wurde Brandenburg dann der vierte im Bunde der ComVor-Kooperationäre.

Crime wird Inpol-Fall beim BKA

Bessere Aussichten gab es für 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 Kriminalpolizeiehö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.

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 BW, HW und HH

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 Verbundddateien, … 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 Anwort 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 Daten- und das Informationsmodell in Inpol-Fall

Inpol-Fall ist, wie auch Crime, ein Informationssystem mit generischem Datenmodell und zentraler Linktabelle für sämtliche Beziehungen zwischen Objekten. Für jeden der oben genannten Deliktsbereiche, bzw. generell für jede Inpol-Fall-Anwendung, wird jeweils eine eigene Datenbank eingerichtet, was aus rechlichen Gründen auch so vorgeschrieben ist. Jede dieser Datenbank kann ein eigenes Informationsmodell verwenden, also eine eigene Definition der Objekttypen (z.B. Person, Adresse, Fahrzeug, usw.), der ihnen zugehörigen Merkmalstypen (z.B. Familienname, Vorname, Geburtsdatum usw.) und der Kataloge für Merkmalsbegriffe (z.B. männlich | weiblich, ledig | verheiratet | geschieden | …).

Der größte Fehler, den das BKA bei der Einrichtung und dem Betrieb von Inpol-Fall begangen hat, hat mit den Informationsmodellen zu tun. Denn man hat nicht erkannt, dass der Informationsaustausch zwischen den Systemen erschwert bzw. verunmöglicht wird, wenn das Sender- und das Empfänger-Informationssystem unterschiedliche Informationsmodelle verwenden. Und nach wie vor hagelte es auch nach der Inbetriebnahme von Inpol-Fall entsprechende Anforderungen aus den diversen Bund-Länder-Arbeitskreisen und -Projektgruppen bzw. Bedarfsträgern im BKA: Und immer gab es 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. Diesen Anforderungen wurde stattgegeben, die Folgen davon nicht rechtzeitig aufgezeigt: Sie bestanden – schon wenige Jahre nach der Einführung – im großen Chaos bei Inpol-Fall. Die Rede war von „mehr als 150 verschiedenen Informationsmodellen“ in den Inpol-Fall-Datenbanken. Ein wesentlicher Vorteil von Inpol-Fall, nämlich das in allen Datenbanken einheitliche, generische Datenmodell, war damit ins Gegenteil verkehrt worden.

Erst jetzt 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“.

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 im Jahr 2003.

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 ein eigenes System namens Easy entwickelt. Und dann gab es, wie oben bereits gesagt, noch Crime als Fallbearbeitungssystem in BW, HE und HH.

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. Eine Begründung dafür gab es nicht. Einige Monate später wurde auch für das BKA ein System der Firma Rola beschafft und auf den Namen b-case getauft. Hier, wie auch in anderen diesbezüglichen Beschaffungsfällen, wurden die Aufträge „freihändig“ vergeben. De 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 unserer Firma 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, 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“ 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

Mitte/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 Landesystemen 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 …

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 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 Anti-Terror-Datei 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 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.“

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 ein standardisiertes gemeinsames Informationsmodell Polizei 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äßt, 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äßt 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 PIAV auch in dieser Hinsicht seinem Vorgänger – Inpol-Neu – in nichts nachsteht.

__________________________________________________________________________________________________________________________________________________________

Dieser Beitrag ist Teil der Serie …

Neues vom PIAV

Sämtliche bisher erschienenen Beiträge dieser Serie

Teil 1 vom 23.09.2013: BMI bestätigt: Bisherige Verbundprojekte gescheitert!
Teil 2 vom 26.09.2013: Vergabeverfahren in Theorie und Praxis
Teil 3 vom 01.10.2013: Ein eigener Fall: Inpol-Fall

Quellen zu diesem Artikel

[1] Polizeiliche Datensysteme zur Erfassung und Analyse Politisch motivierter Kriminalität – rechts, Antwort der Bundesregierung auf die Kleine Anfrage der Fraktion Bündnis90/Die Grünen, 16.09.2013, DBT-Drs. 17/14753
[2] Grundsätze für Zusammenarbeit von Bund und Ländern bei der polizelichen Datenverarbeitug 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
[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, 14/7734
[5] Polizei-Informationssystem: Nach nur zwei Jahren entpuppte sich Inpol-Neu als 60-Mio-Euro-Flop, VDI-Nachrichten
[6] Informationstechnik für die Fachlichkeit – Teil 6: Wie kommt das Informationsmodell ins Datenmodell? 27.08.2013
[7] Computergestützte Kriminaltechnik bei Polizeibehörden, 06.02.2012, Antwort der Bundesregierung auf die Kleine Anfrage der Linksfraktion, DBT-Drs 17/8544 (neu)
[8] Lobbyismus bei Beschaffungsprojekten des Bundesministeriums des Innern, 04.04.2011, Antwort der Bundesregierung auf die Kleine Anfrage der Linksfraktion, DBT-Drs 17/5343
[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

Schlagworte: , , , , , , , , , , , ,

Schreibe einen Kommentar