Agilität in der öffentlichen Beschaffung

Agilität scheint vielerorts das Zauberwort zur Lösung unterschiedlichster Herausforderungen zu sein. Unter agiler Beschaffung wird primär das seit gut drei Jahren etablierte Dialogverfahren verstanden. Dieser Ansatz ist für das Beschaffungsverfahren eine Entwicklung in die richtige Richtung. Denn das Einreichen einer Offerte auf der Basis eines Pflichtenhefts und einer einmaligen Fragerunde lässt oftmals zu viel Interpretationsspielraum offen. Was veranlasst uns zu erwarten, dass ein Lieferant aufgrund eines durch den Auftraggeber erstellten Pflichtenhefts genau das gleiche Bild vor Augen hat wie er? Das Erarbeiten eines Pflichtenhefts kann mehrere Monate dauern und der Auftraggeber durchläuft dabei einen wichtigen Entwicklungsprozess. Es ist illusorisch, dass Lieferanten innerhalb der Angebotsfrist den gleichen Wissensstand erreichen.

Ein Lösungsansatz dazu liefert eine Empfehlung der swissICT Fachgruppe lean, Agile & Scrum. Reto Maduz, Mitglied Leitungskreis der Fachgruppe, weist darauf hin, dass sich der Auftraggeber primär auf die Beschreibung des “WAS” und nicht des “WIE” fokussieren sollte. Seitens Auftraggeber ist also ein Lastenheft mit der Beschreibung des “WAS” und nicht ein Pflichtenheft, welches bereits das “WIE” beschreibt, zu erstellen.

Sprints und Optionen

Neben dem Dialogverfahren, welches in der Regel nach einem selektiven Verfahren zum Kennenlernen der Partner und deren Lösungsideen dient, zeigt Reto Fetz, Stv. Leiter Logistik des BBL, die Möglichkeiten von Sprints und Optionen auf. Diese noch jungen Konstrukte sollen helfen, der Realisierungsphase die nötige Agilität zu verleihen, um der Komplexität von IT-Projekten begegnen zu können. Der Zuschlag für Realisierungsleistungen kann damit in einen Grundauftrag und Optionen aufgeteilt werden. Dies wird bereits so praktiziert wie z.B. die aktuell laufende WTO Ausschreibung der Landestopografie für das Geoportal zeigt. Im Grundauftrag ist hier die Erstellung des Detailkonzepts gefordert. Alle weiteren Realisierungsleistungen sind optional.

Durch Unterteilung der Realisierung in Sprints – wie von der “Scrum” Methode her bekannt – in Kombination mit mehreren Technologiepartnern wird auch die Möglichkeit geschaffen von Sprint zu Sprint den Partner zu wechseln. Diese Möglichkeit dürfte wohl nur im äussersten Notfall zum Einsatz gelangen. Denn ist es wirklich realistisch, das eine Stockwerk oder Zimmer mit dem einen, ein weiteres mit einem anderen Architekten zu realisieren? In der Praxis ergeben sich aus meiner Erfahrung häufig Probleme, da die im Fundament gelegten Design-Entscheidungen von einem nachfolgenden Lieferanten nicht verstanden oder unterstützt werden. Was allenfalls in der Bauindustrie – wo Baupläne, statische Berechnungen etc. vor der Realisierung vorliegen – funktionieren mag, erachte ich aufgrund der noch nicht so weit industrialisierten Software-Entwicklungsbranche als illusorisch.

Die Erfolgsfaktoren aus unserer Sicht

Was sind nun eigentlich unabhängig der aus juristischer Sicht einzuhaltenden Verfahren wirklich die Erfolgsfaktoren? Aus meiner Erfahrung sind es Werte und Prinzipien wie:

• Vertrauen
• Partnerschaft
• Intensiver Austausch/Kommunikation
• Committment
• Durchsetzungsvermögen und Willenskraft
• Einfachheit

Ohne gegenseitiges Vertrauen und Commitment sowie einem intensiven Austausch zwischen Kunde und Entwicklungspartner scheinen mir wirklich gute, wirtschaftliche Lösungen nicht realisierbar. Zu häufig gibt der bestellende Fachbereich das Commitment in Bezug auf die Bedarfsformulierung oder das Priorisieren an Spezialisten ab, welche Bundesordner mit Papier füllen. Was es braucht, ist der direkte Kontakt zwischen einem fachlich orientierten Team auf Kundenseite und einem Team mit dem technischen Know-how auf der Seite des Lieferanten.

Als KMU würden wir es begrüssen, wenn auch bei Vorhaben mit Volumen unter 5 Millionen nach einer ersten Selektion der Fokus auf das intellektuelle Kapital des Lieferanten – den Lösungsideen für die durch den Kunden beschrieben Anforderungen – gerichtet wäre. Wie beim Dialogverfahren sollten dabei bereits im Rahmen des Angebots geforderte Lösungskonzepte entschädigt werden.

Wir sind gespannt, über welche Erfahrungen aus den laufenden und kommenden Ausschreibungen mit Dialogverfahren sowie den neuen Konstrukten Sprint und Optionen an der nächsten Beschaffungskonferenz berichtet werden kann.

Rahmenverträge

In einer zweiten Fachsession beleuchten vier Referate das Thema Rahmenverträge oder zeigen neuartige Formen der Beschaffung (Crowd Funding). Christian Laux stellt das schwedische Modell für Open Source Rahmenverträge vor. Der schwedische Staat schreibt seit einiger Zeit Rahmenverträge für konkrete Open Sourcen Produkte aus. Dadurch werden Aspekte wie Garantie und Gewährleistung einheitlich gelöst. Dieser Ansatz wird derzeit auch für die Schweiz geprüft. In der anschliessenden Diskussion der Referenten mit dem Publikum wird der Nutzen eines solchen Modells in Frage gestellt. Wir möchten hier widersprechen: Aus unserer Sicht dürften solche Verträge dazu führen, lokale Open Source Dienstleister und Open Source Angebote allgemein sichtbarer innerhalb der Verwaltung zu machen. Schlussendlich dürfte ein solcher Schritt ein wichtiger Mosaikstein in der Open Source Strategie der Schweizer Bundesverwaltung sein.

Weiter führen das Bundesamt für Bauten und Logistik und das Bundesamt für Informatik aus, wie Rahmenverträge in der Schweiz rechtlich geregelt sind und wie aktuell im Zusammenhang mit Rahmenverträgen beschafft wird sowie welche Erfahrungen damit gemacht werden.

• Bruno Gygi, Leiter Kompetenzzentrums Beschaffungswesen Bund beim BBL: Einsatz von Rahmenverträgen in der Schweiz

• Jürg Sager, Leiter Beschaffung Dienstleistungen im Bundesamt für Informatik und Telekommunikation BIT: Rahmenverträge für Personalverleih und IT-Dienstleistungen im BIT

Die Einblicke sind sehr interessant und wertvoll für uns. So setzt das BIT für Themen, bei welchen die Projektanforderungen noch nicht klar umrissen sind, aber ein Bedarf bekannt ist, auf Rahmenverträge mit Lieferanten für ein bestimmtes Thema oder eine Technologie. Beispielsweise die neu laufende Ausschreibung Partner für Business Analyse/Requirements Engineering und Lösungsarchitektur für das Bundesamt für Informatik und Telekommunikation (BIT) von 2014 – 2017. Damit werden Firmen gesucht, welche in diesem Thema über grosse Erfahrung verfügen und entsprechendes Personal anhand einer vorausschauenden Planung dem BIT für Projekte zur Verfügung stellen kann (solche Aufträge können als Werk, Auftrag oder im Personalverleih erfolgen).

Als letzter Vortrag in dieser Reihe stellt Cédric Moullet das Verfahren für die Finanzierung der Entwicklung von OpenLayers 3 vor: Statt einer herkömmlichen Vergabe an eine Firma nutzte swisstopo dazu die Open Source Community und führte ein Crowd Funding der gesuchten Mittel durch. Swisstopo bot an, CHF 100’000.- in die Neuentwicklung zu investieren, wenn insgesamt CHF 350’000.- bis zu einem gewissen Zeitpunkt von anderen Nutzern und aus der Community zusammenkommen. Und – es funktionierte tatsächlich. In einem Monat war die Finanzierung durch über 100 Beitragende sichergestellt. Sogar die US Regierung steuerte einen Anteil bei.

Aus unserer Sicht eine absolut zukunftsträchtige Möglichkeit der Beschaffung. Innerhalb der /ch/open wird aktuell ein Projekt initiiert, welche die Entwicklung solcher Open Source Gemeinschaftslösungen fördern soll.