Eine erfolgreiche Beschaffung startet mit dem passenden Partner

In diesem Blog erhältst du einen Einblick in einen Beschaffungsprozess im öffentlich-rechtlichen Rahmen mit Elementen von agile.agreement. Dafür haben wir uns mit Kay Zoller unterhalten. Er ist in seiner Rolle als Leiter Informatik Personalamt bei der Kantonalen Verwaltung Thurgau in dieser Beschaffung als Projektleiter involviert. Im Rahmen der Beschaffung wird eine neue Lösung für das Personal und Lohnwesen entwickelt und eingeführt.

 

Blogpost in Kürze:

  • Auf diese Art und Weise sahen die Leute das Produkt wachsen, konnten ihre Einwände äussern und hatten so schlussendlich ein höheres Verständnis und eine höhere Akzeptanz für die Lösung.

  • Der Riskshare erweist sich als intelligentes Werkzeug für die Risikoadressierung, welches viele Diskussionen überflüssig macht.

  • Den Wert, mit den Anbieter vor der Offertenstellung sprechen zu können und ein Gefühl für die Zusammenarbeit zu erhalten, erkennt man erst nachdem man es selbst erlebt hat.

 

Zur besagten Beschaffung: In einer WTO mit einem zweistufigen Verfahren (selektives Vergabeverfahren) wurden zuerst in einem Präqualifikationsverfahren die Anbieter auf ihre Eignung beurteilt. Dabei lag der Fokus in der ersten Phase nicht auf den Inhalten, sondern auf den Fähigkeit – der Art und Weise, wie diese Unternehmen in der Lösungsentwicklung arbeiten. In der zweiten Phase, dem Qualifikationsverfahren bauten die Anbieter verschiedene POC’s (Proof of Concept), welche dann beurteilt wurden.

 

 

Lieber Kay. Was ist dein erster Gedanke, wenn du an die Beschaffung mit agile.agreement denkst?

Da habe ich gleich verschiedene: Wir konnten als Verwaltung im Rahmen dieses Projektes unser Wissen und unsere Erfahrungen im Bereich «agiles Arbeiten» erweitern. Basierend darauf fand ich den Ansatz, Assessments mit den verschiedenen Anbietern abzuhalten, extrem spannend. Den Fokus zuerst darauf zu legen, wie der Anbieter gedenkt, ein solches Problem mit uns zusammen zu lösen war sehr aufschlussreich. Wir konnten extreme Unterschiede in der Herangehensweise und im Einbezug von uns als Auftraggeber feststellen. Als dritten Punkt möchte ich den agilen Vertrag erwähnen. Wir haben bereits bei Projektstart den Projektrahmenvertrag vorgelegt. Die Annahme dieses Vertrags war ein «Muss-Kriterium» um bei dieser WTO überhaupt teilnehmen zu können. Bestandteile dieses Projektrahmenvertrags waren z.B der Zusammenarbeits-Codex, der Prozess im Umgang mit Ungewissheit (Komplexität), die Formen der Risikoadressierung, Eskalationsprozess und die Form der Abnahmen bei einer iterativ wachsenden Lösung.

 

 

 

«Wir konnten extreme Unterschiede in der Herangehensweise und im Einbezug von uns als Auftraggeber feststellen.»

 

 

 

Wie erwähnt, habt ihr mit Sprints gearbeitet. Welche Folgen und Vorteile hatte dies für das Projekt?

Den Ansatz, mit Sprints zu arbeiten hatte zur Folge, dass wir uns regelmässig strukturiert über den Fortschritt des Projekts unterhielten. Am Ende jedes Sprints gab es eine Präsentation, bei der auch die Linie eingeladen war. Durch einen definierten Prozess konnten sie Einwände, Bedenken oder Ideen äussern. Dies hatte den grossen Vorteil, dass die Leute das Produkt wachsen sahen, in den Prozess einbezogen fühlten und bis zum Ende eine höhere Akzeptanz und ein besseres Verständnis für die Lösung entwickelten. Es macht einen erheblichen Unterschied aus, ob ich eine fertige Lösung hingestellt erhalte, die ich zuerst verstehen muss, und feststelle, dass manche Dinge für mich wenig Sinn ergeben, oder ob ich weiss, wie diese Lösung grob entwickelt wurde und warum manche Aspekte so umgesetzt wurden und nicht anders. Dazu konnten viele ja sogar noch ihre Bedenken oder Wünsche anbringen, die zumindest gehört und eventuell teilweise oder ganz umgesetzt wurden.

 

 

Was ist ein Learning aus diesem Projekt für dich?

Ein Bestandteil des Rahmenvertrags war der Riskshare (eine Form der Risikoadressierung). Dabei drückt der Anbieter seine Sicherheit aus, dass er die vor jedem Sprint definierten Features auch zum definierten Preis liefern kann. Falls sich die Entwicklung der Features als aufwändiger herausstellen, wird so bestimmt, wieviel der Mehrkosten der Anbieter übernehmen wird. Implizit ergibt sich für mich als Auftraggeber so die prozentualen Mehrkosten (Risiko), mit dem ich rechnen muss. Gibt der Anbieter bspw. einen Riskshare von 80% an, heisst dies für mich als Auftraggeber, dass der angegebene Preis eine Unsicherheit von 20% beinhaltet und in Realität der potenzielle Preis folglich um 20% höher liegt.

 

Aufgrund von meinen jetzigen Erfahrungen ist dieser Riskshare ein sehr intelligentes Feature, um Risiko bereits früh regeln zu können. Allerdings müsste hier noch mehr darauf eingegangen werden, was dies für einen Anbieter wirklich bedeutet. Es handelt sich nicht um Änderungen oder neue Features, die entwickelt werden sollen, sondern rein um Features, die zusammen abgemacht wurden und nun aus irgendwelchen Gründen mehr Zeit/Ressourcen beanspruchen.

 

 

«Die Leute fühlten sich in den Prozess einbezogen und hatten bis zum Ende ein besseres Verständnis für die Lösung.»

 

 

 

Herzlichen Dank für deine Einblicke Kay. Hast du noch ein paar abschliessende Worte für unsere Leser?

Gerne. Ich würde eine solche Beschaffung eines komplexen Problems immer wieder mit diesem Projektrahmenvertrag und den Assessments angehen. Besonders wenn man einmal mit solchen Assessments Erfahrungen machen durfte, realisiert man, was für ein Vorteil es ist, wenn man schon früh herausfinden kann, mit welchen Leuten oder Arbeitsweise man ein gutes Gefühl hat und sich eine angenehme Zusammenarbeit vorstellen kann. Es gibt oft verschiedene Firmen, die ein Problem lösen können. Eine gute Zusammenarbeit macht dann aber den Unterschied, dass die wirklich passende Lösung entwickelt werden kann.

 

 

Wenn du mehr solche Einblicke lesen möchtest, dann folge uns auf LinkedIn oder abonniere unseren Newsletter um auf dem aktuellsten Stand zu bleiben.

 

 

 

Quelle Bild: https://www.spitex-parta.ch/standort/leistungen-und-tarife-im-kanton-thurgau/

Kommentar schreiben

Kommentare: 0