Interview: Simon Zaugg

Weshalb ist das Thema «agile Beschaffung» wichtig?

Reto Maduz: Insgesamt unterteile ich den Beschaffungsprozess gern in drei Phasen: vor, während und nach der Beschaffung. Im klassischen Vorgehen wird vor der Beschaffung alles bis ins Detail beschrieben. Diese Anforderungen werden über die Mauer zu den Entwicklern zur Umsetzung gegeben. Man hat nun aber mit der Zeit gemerkt, dass dies so je länger je mehr nicht mehr funktioniert.

«Agile Beschaffung» adressiert dieses Problem. Wir wollen von Anfang an eng miteinander kommunizieren. Und trotzdem wollen wir die Grundsätze der Beschaffung einhalten: Transparenz, Wirtschaftlichkeit, Gleichbehandlung und Wettbewerb. Das ist eine Herausforderung.

Gemäss der Trends & Benchmarks Studie von SwissQ (Link: https://report.swissq.it), arbeitet man heute bereits in 94 Prozent der Projekte hybrid, sprich in einem Mix aus Wasserfall und agilen Vorgehensweisen. Vor 10 Jahren an der 1. IT-Beschaffungskonferenz war dieser Trend bereits ersichtlich, war aber noch nicht so ausgeprägt. Wir haben uns gesagt, dass etwas passieren muss. Viele haben uns entgegnet: «Da könnt ihr nichts verändern!» Heute sehen wir, dass sich doch einiges verändert hat. Das Thema ist auf dem Tisch. Und das ist gut so.

Stephan Sutter: Wenn das Team, das die Lösung designt, nicht dasselbe Team ist, welches diese nachher umsetzt, dann braucht es dazwischen immer einen Know-How-Transfer. Bei diesen Grenzen – vor, während, nach der Beschaffung – gibt es somit automatisch Brüche.

In der Beschaffung will man gewährleisten, dass alle gleich behandelt werden. Das steht dem Anspruch gegenüber, dass du sehr viel wissen musst, um eine gute Lösung anbieten zu können.

Mirko Kleiner, ein Kollege aus der Lean, Agile & Scrum Fachgruppe, hat einen Ansatz entwickelt, um die Beschaffung in einem Tag zu schaffen. Das ist eine extreme Vision. Aber sie bringt auf den Punkt, dass wir schneller werden müssen. Heute sagt man in der Bundesverwaltung, dass eine Beschaffung etwa ein halbes Jahr dauert. Bei einem dringenden Problem wie der Covid Tracing App ist das aber viel zu lange. Deshalb ist Agilität in der Beschaffung wichtig.

Da kommt es dann mehr auf die Leute an, die hinter diesem Projekt stehen und es umsetzen. Und nicht unbedingt auf den exakten Plan, der auf dem Papier skizziert wurde.

Reto Maduz: Ja, richtig. Die grösste Herausforderung in der Beschaffung sind jedoch die Gleichbehandlung und die Transparenz. Wenn ich mit dem einen Lieferanten spreche, dann muss alles, was ich mit ihm diskutiert habe, allen anderen auch zur Verfügung gestellt werden. Das ist der sogenannte Dialog.

Nachdem das Projekt ausgeschrieben und die Informationen auf «Simap» publiziert sind, damit sie alle Lieferanten lesen können, geht man in die Interaktion, um mit einer Auswahl von Lieferanten zu sprechen. Bei einer Beschaffung gibt es eine anonyme Fragerunde. Lieferanten stellen Fragen, und der Auftraggeber, die Bedarfsstelle, antwortet. Diese Antwort geht immer an alle. Es gibt jedoch keine Möglichkeit, nachzufragen. Ab und zu kommt es zwar vor, dass zwei Fragerunden gemacht werden. Schon besser, wird aber selten angewendet.

Eine weitere grosse Herausforderung ist die Definition des «was» und «wie» zu einem frühen Zeitpunkt. Schauen wir uns zum Beispiel das «DaziT» Projekt der Eidgenössischen Zollverwaltung an: Das ist ein riesiges Vorhaben mit ganz vielen spannenden Themen. Es geht um die Verfolgung und das Überwachungsmonitoring von Grenzübertritten des ganzen Warenverkehrs. Da weiss man am Anfang halt wirklich noch nicht, wie die Endlösung – in etwa fünf bis zehn Jahren – aussehen wird. Wie soll man das jetzt im Detail beschreiben und spezifizieren? Die agile Softwareentwicklung ist da sicher ein vielversprechender Ansatz.

Stephan Sutter: Ein gutes Beispiel ist das Projekt Justitia 4.0. Da wurde – noch vor der eigentlichen Ausschreibung – ein Industrietag organisiert. Dieser Anlass war offen für alle, die potenziell mitmachen wollen. Das ist auch eine Art, wie man einen Prozess agiler machen kann.

Ein anderes Beispiel: Die SBB veröffentlicht zu Rail 4.0 regelmässig den aktuellen Stand der Dokumentation auf Simap. So haben alle den gleichen Stand.

Wenn es nämlich um Steuergelder geht, dann darf es nicht passieren, dass Korruption oder Bevorzugung stattfindet.

Bei Agilität geht es darum, schnell reagieren zu können. Ist das nicht auch ein Widerspruch zu Grossbeschaffungen?

Reto Maduz: Ja, definitiv. Beschaffung heisst ja eigentlich letztlich auch, dass ich früh in der Produktentwicklung einen Schwarz-Weiss-Entscheid machen müsste. Damit ist früh ganz viel vordefiniert.

Je nach Beschaffungsarchitektur kann mehr Flexibilität in den Beschaffungsprozess «eingebaut» werden. Ich habe zum Beispiel die Möglichkeit, mit der Firma XY erst einmal einen Grundauftrag zu machen. Gleichzeitig halte ich mit zwei bis drei zusätzlichen Anbietern weitere Optionen in der Hinterhand. So hätte ich theoretisch die Möglichkeit, dass ich mich nach dem Grundauftrag noch für einen anderen Partner entscheiden könnte. Wichtig ist hier aber so oder so, dass das Gesamtvorhaben in Grundauftrag und Optionen aufgeteilt wird. Kleinere Stücke sind einfacher zu bewältigen.

Die zweite Option: Ich wähle am Anfang nicht nur einen Anbieter aus, sondern vielleicht deren drei für ein «Proof of Concept» (POC). In einem einen ersten Durchlauf von ein bis zwei Monaten arbeite ich mit allen drei Partnern parallel zusammen. Und dann schaue ich, mit welchem es am besten funktioniert und wer meine Herausforderung am besten versteht.

Das ist jedoch nicht agile Beschaffung an sich, sondern Beschaffungsarchitektur. Grundsätzlich gab es schon immer mehrere Beschaffungselemente. Es gab einen Dialog, oder die Möglichkeit, dass man ein POC machen kann. Oder die Aufteilung in Grundauftrag und Optionen. Im Kontext der agilen Beschaffung und Entwicklung wird genau dies einfach noch viel wichtiger.

Eine weitere Option ist natürlich, gar kein Werk, sondern eine Partnerschaft auszuschreiben. Ich suche eine Firma, die gute IT-Spezialist:innen hat. Das kann ich mit Referenzen oder Zertifizierungen überprüfen. Ich suche drei bis fünf Firmen. Sobald ich mit der Produkt-Entwicklung starte, frage ich genau diese Firmen an. So muss ich nicht mehr die ganze Welt anfragen. Dazu gibt es den sogenannten Rahmenvertrag, der in der IT-Beschaffung momentan sehr populär ist, gerade bei Grossbeschaffungen.

Gibt es eigentlich weniger rechtliche Probleme, wenn die IT-Beschaffung agil gemacht wird?

Stephan Sutter: Nein, ich glaube nicht.

Reto Maduz: Nein, ein Allerweltsheilmittel ist es nicht. Die Herausforderungen sind letztlich genau dieselben. Wir merken aber, dass bei einer agilen Vorgehensweise die Probleme zum Teil viel früher ersichtlich werden.

Das Spannende dabei ist, dass herkömmliche Verträge relativ einfach sind. Ein Beispiel: Bitte liefere mir die 472 Anforderungen, die wir im Lastenheft beschrieben haben, zu dem Preis, den du gesagt hast und zu dem Termin, den ich dir mitteile. Ein vollständiger Scope zu dem Zeitpunkt, den ich genannt habe und zu dem Preis, den du mir offeriert hast. Termin – Kosten – Qualität im Scope, alles fix.

Ein agiler Vertrag ist demgegenüber viel umfangreicher, weil wir darin im Voraus gemeinsam beschreiben, wie wir vorgehen werden. Die Kommunikation, die Rollenverteilung, Pflichten und Rechte werden vorgängig definiert. Je nachdem auch, wie man eskaliert. Wenn man sich diese Überlegungen vorgängig macht, dann werden gewisse Probleme schon im Vornhinein abgefedert. Das ist sicher das Positive.

Die Schwierigkeit ist, dass genau das noch nicht so häufig praktiziert wird. Man verweist dann lieber auf die bestehenden Rahmenverträge oder Vertragskonstrukte, die man schon hat. Und die Arbeiten im Voraus, wie man zusammenarbeiten will, macht man nicht.

Matthias Stürmer, der Treiber dieser Konferenz, ist auch ein starker Förderer von Open Source. Seit es diese Konferenz gibt – wie hat sich das Zusammenspiel Open Source und Agilität im Beschaffungsthema entwickelt?

Stephan Sutter: Wenn du für Produkte nicht auf eine einzelne Firma angewiesen sein willst, dann ist es empfehlenswert, Produkte zu wählen, welche eine Open-Source-Community haben. Diese beiden Elemente Agilität und Open Source waren bei der IT-Beschaffungskonferenz von Anfang an dabei. Eine sehr gute Synergie, wie ich finde. Es geht zudem darum, einen partnerschaftlichen Ansatz zu wählen.

Zudem hat die Bundesverwaltung immerhin seit 10 Jahren eine Strategie für Open Source. Sie setzt einiges an Open Source ein.

Reto Maduz: Ich sehe Open Source als eines der zentralen Themen an der IT-Beschaffungskonferenz. Es ist immer ein Track dabei. Eine Verbindung zur agilen IT-Beschaffung – auf Methodik-Ebene – sehe ich aber eher weniger.

Dann sind es eher zwei Teile, die separat zu betrachten sind.

Reto Maduz: Genau. Das Einzige, wo man vielleicht eine Verbindung sehen kann, ist das Mindset. Open-Source-Projekte werden sehr häufig agil umgesetzt. Das hat aber nichts mit der agilen Beschaffung an sich zu tun, sondern es ist das Mindset, dass man es miteinander macht und der Source Code allen gehört. Das sind Prinzipien, die man in einer agilen Softwareentwicklung leben will.

Zum Schluss habt ihr einen Wunsch frei – im Zusammenhang mit dem besprochenen Thema.

Reto Maduz: Es wäre schön, wenn wir Ende Jahr vom Bundesamt für Logistik und Bauten (BBL) eine Guideline hätten, wie wir agile Projekte ausschreiben. Und sie würden das entsprechend mit einem grossen Commitment vorantreiben. Das wäre grossartig.

Eine klare Botschaft.

Stephan Sutter: Ich wünsche mir, dass Agilität einen Beitrag für die Digitalisierung der Schweiz leisten kann. Wir alle sollten zudem den eigentlichen Problemen in IT-Projekten mehr auf den Grund gehen, anstatt kollektiv die IT-Branche zu bashen, wenn ein Projekt schief läuft.

Hoffen wir, dass die entsprechenden Stellen dieses Interview lesen. Danke euch vielmals für das spannende Gespräch!