Mal angenommen, Sie wollen ein Haus bauen: Kämen Sie dann auf die Idee, einen Rahmenvertrag mit einer Maurerbrigade abzuschließen und den Baufortschritt nach Tagen abzurechnen?! Sicher nicht!
Genau das ist es jedoch, was in großen IT-Projekten des Bundes und der Länder immer mehr zum Standard wird. Der Abschluss von Dienstverträgen mit Auftragnehmern, aus denen dann Leistungen abgerufen und nach Zeitaufwand abgerechnet werden. Auf diese Weise stockt insbesondere das Bundeskriminalamt seit Jahren seinen Personalbestand pro Jahr dauerhaft um eine zweistellige Anzahl von Mitarbeitern auf.
_________________________________________________________________________________________
Probleme tauchen regelmäßig auf, wenn es um die Entwicklung einer Individualsoftware geht oder eines IT-Systems nach den individuellen Vorstellungen des Auftraggebers. Dafür ist der EVB-Vertragstyp ‚EVB-IT System‘ vorgesehen. Er entspricht einem Werkvertrag mit den dafür typischen Merkmalen:
- Der Auftragnehmer erstellt eine Software bzw. ein IT-System nach den individuellen Leistungsmerkmalen, die mit dem Auftraggeber vereinbart wurden,
- er haftet für die Fertigstellung zum vereinbarten Zeitpunkt,
- und gewährleistet die vereinbarten Eigenschaften und die Freiheit von Fehlern.
- Dafür zahlt der Auftraggeber die vereinbarte Vergütung, ggf. in Teilbeträgen und nach dem Erreichen vereinbarter Teilleistungen/Meilensteine.
Auch wenn dies einfach und nachvollziehbar klingt, ist doch in der polizeilichen IT-Praxis heute kaum noch ein IT-Beschaffungsvorgang festzustellen, bei dem ein EVB-IT-Systemvertrag verwendet wurde.
Problem 1: Es gibt kein Pflichtenheft
Die größte Schwierigkeit besteht nämlich darin, die geforderten Leistungsmerkmale vertragsfest zu formulieren. Wenn allerdings noch nicht einmal festgelegt ist, was eigentlich entwickelt werden soll, kann auch kein Fertigstellungstermin vereinbart werden. Und so hat es sich eingebürgert, dass bei polizeilichen Informationssysteme munter drauf los „entwickelt“ wird, ohne umfassende Leistungsbeschreibung, ohne verbindliche Fertigstellungstermine, ohne die Möglichkeit der Kontrolle des „Erfolgs“, ohne Haftung für Auftragnehmer oder verantwortliche Entscheider, jedoch garantiert auf Kosten des Steuerzahlers.
Es erfordert erhebliche Anstrengung und monatelange, manchmal jahrelange Vorarbeit, um ein komplexes IT-System fachlich umfassend und kompetent und unter Berücksichtigung aller technischen Rahmenbedingungen zu konzipieren. Wer diese Arbeit erbringt, muss sich sozusagen im Kopf das fertige IT-System vorstellen und es dann auch mit allen seinen Eigenschaften und Rahmenbedingungen in rechtssicheren Formulierungen beschreiben. Das Ergebnis dieser Arbeit wird als Pflichtenheft bezeichnet und ist wie folgt definiert:
„Das Pflichtenheft ist ein Dokument, in dem alle Anforderungen an ein Software-System systematisch niedergelegt sind. Es dient als Ausgangs- und Referenzpunkt für die Entwicklung bzw. Beschaffung einer Software. Pflichtenhefte sollen als Bestandteil eines juristischen Vertrages zwischen Auftraggeber und –nehmer dienen können.“ [1]
Die Erstellung eines fachlich und technisch qualifizierten Pflichtenhefts ist die mit Abstand anspruchsvollste Aufgabe des gesamten Projekts: Man braucht dazu Mitwirkende, die die fachlichen Anforderungen (hier: aus der Polizeiarbeit) einbringen können, dabei jedoch genug Abstand haben, um das große Ganze im Auge zu haben und sich nicht verzetteln in den Details von Datenfeldern, Listenausgabeformaten, Inhalten von Katalogen oder der schicken Funktion, die sie schon immer bei ihrer eigenen Arbeit haben wollten. Man braucht ferner Mitwirkende, die über viel Berufserfahrung auf technischem Gebiet verfügen und einen sehr gründlichen Überblick darüber haben, was heute Stand der Technik ist und was aller Voraussicht nach in zehn bzw. fünfzehn Jahren Stand der Technik sein wird. Denn das ist der Zeithorizont, in dem das zu entwickelnde IT-System einsatzfähig gehalten werden muss.
Übrigens: Weil Lastenheft und Pflichtenheft so wichtig sind, sind die Begriff sogar in einer DIN-Norm definiert. Die Norm 69901 befasst sich mit Projektmanagement und definiert im Teil -05 die dafür relevanten Begriffe. Da heißt es dann …Lastenheft ist die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines (Projekt-)Auftrags“ und
Pflichtenheft ist die „Realisierungsvorgabe auf der Basis des vom Auftraggeber vorgegebenen Lastenheftes“.
Warum es in polizeilichen IT-Projekten (fast) nie Pflichtenhefte gibt, die diesem Anspruch gerecht werden …
Pflichtenhefte, die den genannten Anforderungen genügen und daher die Bezeichnung „Pflichtenheft“ auch verdienen, gibt es in Informationstechnik der deutschen Polizeibehörden nur sehr, sehr selten! Das fällt allerdings nicht weiter auf, da in den Polizeibehörden – und insbesondere in den gemeinsamen Projekten von Bund und Ländern eine Fülle von Papier produziert und mit klangvollen Titeln versehen wird. Da finden sich „Projektstudien“ und „grobe fachliche Lastenhefte“, „Anforderungsaufnahmen“ bzw. „Anforderungsfestlegungen“ u.ä. Nur ein Pflichtenheft, das der obigen Definition auch nur annähernd gerecht werden würde, das findet man so gut wie nie. Und da die Entscheider – und zwar weder in der Polizeiführung und erst recht nicht die Innenminister, die letztlich solche Projekte absegnen sollen – nicht sonderlich beschlagen sind in IT-Fachfragen, fällt auch niemandem auf, dass man zwar „Ja“ sagt zur nächsten millionenschweren Geldausgabe. Dass es dafür aber weder eine konkrete Leistungsvorgabe gibt, noch einen belastbaren Zeitplan. Man sagt also „Ja“ zum weiteren Drauf-los-Wursteln. Warum das so ist, hat mehrere Gründe:
Fehlende methodische Kenntnisse
Mitarbeiter von Polizeibehörden, die in ein IT-Projektteam berufen werden, haben weder während ihrer Ausbildung an der Polizeifach/-hochschule gelernt, wie man Leistungsbeschreibungen für IT-Projekte erstellt. Danach werden sie ins kalte Wasser geworfen, sollen „mal machen“ und können sich allenfalls bei erfahrenen Kollegen abschauen, wie man das so macht. Allerdings wird niemand Spitzenleistungen erwarten, wenn Autodidakten Autodidakten anlernen. Dadurch wird allenfalls das allgemeine Niveau solcher Dokumente abgesenkt, weil jede weitere unzulängliche Leistungsbeschreibung dazu beiträgt, das übliche Maß weiter zu verschlechtern.
Fehlende bzw. nur sporadisch für das Projekt verfügbare technische Kompetenz
Wer, als Techniker, über so viel oben schon genannte Berufserfahrung und „Überblick“ auf technischem Gebiet verfügt, arbeitet wohl kaum als Angestellter des öffentlichen Dienstes bzw. Beamter, sondern erzielt den Geldwert für seine Kompetenz in der Privatwirtschaft. Damit soll nicht gesagt sein, dass es nicht auch in Polizeibehörden – bzw. den ihnen zugeordneten technischen Dienstleistungsbetrieben (Zentraldienst für … ) technische Fachleute mit entsprechender Expertise gibt. Das Problem ist nur, dass diese – wenigen – Fachleute – von vielen IT-Projekten und für viele IT-Systeme in Anspruch genommen werden und daher für dauerhafte Zuarbeiten bei der Erstellung eines Pflichtenhefts nicht zur Verfügung stehen.
Bloß keine Verantwortung übernehmen – die Krux im Beamtenstaat
Neben dem Nicht-Können gibt es jedoch noch das Motiv des „Nicht-Wollens“. Man will nämlich keine Verantwortung übernehmen. Verantwortung wäre sozusagen zementiert, wenn ein Projektteam (oder sein Leiter) eine Spezifikation erarbeitet und vorlegt, die dann auch wesentlicher Bestandteil der vertraglich vereinbarten Eigenschaften zwischen Auftraggeber und Auftragnehmer werden würde.
Der „Feind“, um dies einmal martialisch auszudrücken, wäre in diesem Fall an vielen Fronten zu verorten: Einerseits der spätere Auftragnehmer, der den Auftrag zur Realisierung dieses IT-Systems/-Projekts erhält: Denn er könnte jede Unvollständigkeit, jeden Fehler oder Mangel in der Leistungsbeschreibung ausnutzen und finanzielle Nachforderungen geltend machen für nachträglich geforderte, zusätzliche Leistungen oder Änderungen. Spätestens in der Pilot- bzw. Testphase würden auch andere Fachanwender, die nicht beteiligt waren an der Erstellung des Lastenhefts (!) Bekanntschaft machen mit dem neuen System. Zwei bis drei Jahre sind seitdem ins Land gegangen. Die Ansichten bzw. Anforderungen der Organisation haben sich weiterentwickelt und ebenso die der Fachanwender. Das alles liefert Gründe, um das neue IT-System in seiner frühen Testphase im besten Fall nur kritisch zu beäugen bzw. geflissentlich zu ignorieren bzw. vehement zu kritisieren.
Diese Spätfolgen bei der Erstellung von Lasten- und Pflichtenheft ist kein Angehöriger des öffentlichen Dienstes bereit auf die eigene Kappe zu nehmen, wenn er auch nur über ein klein wenig Berufspraxis verfügt.
Aus all den genannten Gründen ist es ein Dilemma mit der Erstellung von Pflichtenheften. Denn sie werden gebraucht, um Werkverträge rechtssicher abschließen zu können. Beim Auftraggeber ist man aber weder fähig, noch willens, ein Pflichtenheft zu erstellen und dies auch als Vertragsbestandteil zu verantworten.
Lastenhefte als verbrämte Pflichtenhefte?!
In nahezu jedem IT-Projekt deutscher Polizeibehörden gibt es dagegen ein „Lastenheft“ [2], also eine mehr oder minder vollständige Beschreibung der fachlichen und technischen Anforderungen: Solche Papiere entstehen z.B. als Ergebnis einer umfassenden Befragung aller Diensteinheiten, die später mit dem neuen System zu tun haben werden. Und so schreibt dann jeder recht munter drauf los, was ihm bzw. ihr schon immer mal aufgefallen war und ein neues System haben sollte. Nichts gegen eine solche grobe erste Bestandsaufnahme von Anforderungen der Fachlichkeit. Bis auf dieser Basis allerdings ein Pflichtenheft entsteht, muss jedoch erheblich investiert werden in Systematisierung, Priorisierung, fachliche und technische Beratung und Konzeption und genau das geschieht in vielen IT-Projekten erst gar nicht.
Vielmehr erhält man als potenzieller Auftragnehmer nicht selten ein Papier mit klangvollem Titel, das jedoch nichts anderes darstellt als einen Wunschkatalog des Auftraggebers. Ein solches mal mehr, mal weniger systematisches Konvolut von Anforderungen, ist jedoch ungeeignet, um auf dieser Basis ein Angebot oder eine Kalkulation zu erstellen. Denn die angebliche Leistungsbeschreibung ist ungenau und unvollständig, Fachbegriffe sind falsch verwendet, andere „individuelle“ Begriffe nicht definiert und technische Rahmenbedingungen fehlen häufig völlig ganz. Solche unprofessionell erstellten, angeblichen ‚Spezifikationen‘ verursachen viel Arbeit und Aufwand für den Interessenten an einem IT-System/-Projekt, der versuchen müsste, auf der Grundlage des vorliegenden Flickwerks ein rechtssicheres Angebot und eine für Auftragnehmer und Auftraggeber „haltbare“ Kalkulation zu erstellen. Zudem befindet er sich in einem psychologischen Dilemma: Fragte er bei der ausschreibenden Organisation all das ab, was auch seiner fachlichen bzw. technischen Sicht zu fragen wäre, steht er leicht als „Pfennigfuchser“ da. Fragt er das nicht, macht es für einen vernünftigen Techniker und Kaufmann überhaupt keinen Sinn, ein Angebot zu erstellen. Jüngstes Beispiel für die Pein, die mit einer unzureichenden Leistungsbeschreibung einhergehen kann, lieferte vor wenigen Wochen ein kleines Bundesland. Innerhalb weniger Tage musste die ausschreibende Stelle aufgrund von Fragen der potenziellen Anbieter wieder und wieder ihre Leistungsbeschreibung nachbessern: Beim 14. Nachtrag zur Ergänzung der Leistungsbeschreibung habe ich dann aufgehört, die Sache weiter zu verfolgen. Vor allem aber stellt sich für den potenziellen Anbieter die Wirtschaftlichkeitsfrage: Was sollte ihn veranlassen, Mannmonate im Voraus in ein Projekt zu investieren, um dafür eine Feinspezifikation zu erstellen – in der Hoffnung, für die Entwicklung dafür später auch den Auftrag zu erhalten?!
Wenige, positive Ansätze für einen Ausweg aus dem Pflichtenheft-Dilemma
Es gibt Ansätze in Vergabeverfahren der letzten Monate, die einen Ausweg aus diesem Dilemma versuchen: Wenn, wie z.B. vor kurzem durch das Land Sachsen geschehen, Beratung gesucht wird zur „Erstellung eines Projektplanes zur Auftragserfüllung, Prüfung des bestehenden Grobkonzeptes und Entwicklung eines Feinkonzeptes“.
Keine verbindlichen Fertigstellungstermine
Natürlich kann der Auftraggeber (s)einen Wunschtermin für die Fertigstellung bzw. Einführung vorgeben.
Und das wäre auch ein weiterer wesentlicher Vertragsbestandteil in einem Werkvertrag = EVB-IT-Systemvertrag. Das Problem ist nur: Wenn nicht genau genug definiert ist, was eigentlich erstellt bzw. geliefert werden soll, wenn kein Projektplan vorliegt, kein Meilensteinplan, keine Darstellung des ‚kritischen Pfades‘, der man entnehmen könnte, wo es Abhängigkeiten von den Vorleistungen anderer Projektteilnehmer gibt usw. Wenn all das also nicht vorliegt: Wie will man dann einen Fertigstellungstermin im Vertrag definieren – und wer sollte sich darauf einlassen bei der Unterzeichnung des Vertrages?!
Sollen andere Anbieter als die Wunschkandidaten an der Abgabe eines Angebots gehindert werden?
Die große Mehrzahl potenzieller IT-Entwicklungsprojekte in den deutschen Polizeibehörden wird aktuell nicht auf werkvertraglicher Basis vergeben, der EVB-IT-Systemvertrag kommt bei diesen Systemen /-Projekten faktisch nicht vor. Beschafft werden vielmehr „Dienstleistungen“, meist in Form eines mehrjährigen Rahmenvertrages. Häufig erhält ein „Haus- und Hof-„Anbieter den Zuschlag, also ein Unternehmen, das bereits seit Jahren für diesen Auftraggeber bzw. für den Kooperationsverbund arbeitet, dem der Auftraggeber angehört. Insofern ist nicht allzu weit hergeholt, wenn man vermutet, dass die Nicht-Vorlage von Pflichtenheften auch ein taktisches Mittel ist: Mit dem effektiv verhindert wird, dass ein bisher nicht mit der Sache befasster Auftragnehmer überhaupt eine Chance erhält, ein Angebot abzugeben.
EVB-IT Dienstverträge oder auch „Body Shopping“ – untaugliches Werkzeug zur Erstellung von Individualsoftware und IT-Systemen
Als Ausweg aus dem dargestellten Dilemma mit nicht vorhandener bzw. unzureichender Leistungsbeschreibung und nicht vorhersehbarem Fertigstellungstermin wird in letzter Zeit verstärkt auf den EVB-IT Dienstvertrag zurückgegriffen, in ausführlicher Bezeichnung „EVB-IT-Vertrag über die Beschaffung von IT-Dienstleistungen“. In den ‚Nutzerhinweisen EVB-IT‘ heißt es zum Zweck dieses Vertragstyps: Er sei „anzuwenden, wenn der Schwerpunkt der vom Auftragnehmer geschuldeten Leistung in der Erbringung von Diensten liegt, wie etwa bei Schulungs-, Beratungs- oder sonstigen Unterstützungsleistungen“.
Das bedeutet praktisch: Der Auftragnehmer stellt Personalleistungen (einer oder mehrerer Qualifikations- und Vergütungsstufen) für einen vereinbarten Zeitraum zur Verfügung. Dafür zahlt der Auftraggeber. Für dieses Geschäftsmodell hat sich in der Informationstechnik der Begriff „Body Shopping“ eingebürgert.
Der Auftragnehmer haftet weder für irgendeinen Erfolg, der in diesem Vertragskonstrukt ja auch nirgends definiert ist. Und insbesondere haftet der Auftragnehmer nicht dafür, eine bestimmte Leistung zu einem bestimmten Zeitpunkt auch fertigzustellen. Ganz im Gegenteil verleitet dieses Vertragskonstrukt ja geradezu dazu, möglichst viel abrechenbaren Aufwand zu produzieren, denn bezahlt wird jede abrechenbare Stunde!
Eine solche Vertragskonstellation mag sinnvoll sein, wenn – wie im Fall der Vergabeprojekts in Sachsen – durch die Beratungsleistungen des Dienstvertrages (gemeinsam mit dem Auftraggeber) ein Pflichtenheft erarbeitet wird, die dann – in einem weiteren Beschaffungsprojekt – zur Grundlage für einen Werkvertrag = EVB-IT Systemvertrag gemacht wird.
Es wird dieses Vertragskonstrukt jedoch auch angewendet für Beschaffungsmaßnahmen, bei denen es ganz eindeutig um die „Erstellung“ eines bestimmten Werkes = IT-Systems geht. Verklausuliert wird das dann in der öffentlichen Bekanntmachung eines „Dienstleistungsauftrages“ als „Aufbau und Installation eines … Systems“. Aufbau im Rahmen einer Dienstleistung ist vorstellbar, ebenso die Installation. Offen bleibt allerdings, welche Eigenschaften dieses IT-Systems eigentlich hat und wer für den Erfolg des funktionsfähigen Werkes, d.h. IT-Systems geradezustehen hat.
Mehrjährige Rahmenverträge über Dienstleistungen
Um die Sache möglichst einfach zu machen – denn wer will schon alle paar Monate neu ausschreiben und verhandeln! – werden solche Dienstleistungsaufträge üblicher Weise als Rahmenverträge vergeben. Beispiele dafür lieferte immer wieder das Bundeskriminalamt mit seinen Rahmenverträgen für die Firmen CSC Deutschland Solutions GmbH oder Mummert & Partner [4], die hessische Zentrale für Datenverarbeitung mit Aufträgen an die Firma Trivadis oder ganz aktuell die Dataport AöR mit einem ‚Dienstleistungs‘-Rahmenvertrag über 75 Mannjahre, ebenfalls an Trivadis [5].
_________________________________________________________________________________________
Dieser Artikel ist Teil der Serie Beschaffung & Vergabe |
IT- und Vertragsrecht
Hier finden Sie eine Liste sämtlicher Artikel dieser Serie.
Verwandte Artikel
IT-Verbundprojekte der Polizeibehörden von Bund und Ländern
https://police-it.net/dossiers/projektmanagement-it-verbundprojekte-der-polizeibehoerden-alle-artikel
Quellen zu diesem Artikel
[1] Definition des Begriffs „Pflichtenheft“, 12.06.2014,Thomas Myrach in Enzyklopädie der Wirtschaftsinformatik [2] Definition des Begriffs „Lastenheft“, 12.06.2014,
Thomas Myrach in Enzyklopädie der Wirtschaftsinformatik [3] siehe auch: Balzert, Helmut: Lehrbuch der Software-Technik:
Basiskonzepte und Requirements Engineering. 3. Auflage. Heidelberg: Spektrum 2009, S. 485 ff. [4] Beschaffungsvorhaben für polizeiliche IT 2013, 29.07.2013, Police-IT
https://police-it.net/beschaffung-vergabe/beschaffungsvorhaben-fuer-polizeiliche-it-2013-3366 [5] IPCC und Konsorten (4): Dataport beschafft für das Inpol Polas Competence Center,
07.03.2014, Police-IT
https://police-it.net/akteure/dataport-beschafft-fuer-das-inpol-polas-competence-center-8583