Seit vielen Jahren arbeite ich im öffentlichen Sektor oder für halbstaatliche Unternehmen und immer wieder habe ich mit Ausschreibungen und Ausschreibungspflicht zu tun … egal ob es darum geht, einen erfahrenen externen Mitarbeiter (weiter) zu beschäftigen oder Hard- und Software zu beschaffen.

Management Summary

Der Text droht lang zu werden, deswegen hier eine kurze Zusammenfassung

Das Konzept Aussschreibungen ist kaputt.

Die Grundideen einer Ausschreibung (sei es WTO oder einfach so) sind gut, ja sogar hervorragend. Leider sind die Beschaffenden häufig mit den gesetzlichen und organisationseigenen Richtlinien überfordert und wissen dementsprechend nicht, was sie (sich an-) tun.

  • Der Beschaffungsprozess ist dokumentiert. Zu jedem Zeitpunkt kann man dem Management gegenüber zeigen, wo man steht, was tatsächlich beschafft werden soll.

  • Die Bietenden wissen genau, was sie liefern müssen (*Räusper*) und können dementsprechend ein präzise zugeschnittenes Angebot erstellen.
  • Alle Anbietenden müssen einen vergleichbaren Funktionsumfang offerieren und damit werden die Angebote einfach vergleichbar.
  • Wegen der Vergleichbarkeit der Angebote kann man sich zum Schluss für den "billigsten" Anbieter entscheiden.

  • Da man – je nach Auftragsvolumen – mehrere Anbieter anschreiben muss oder sogar frei für alle ausschreibt, sinkt das Risiko von Vetternwirtschaft.

Das klingt doch alles sehr gut. Was kann also ein klar denkender Mensch dagegen haben? Naja, nichts. Häufig funktioniert der ganze Prozess aber nicht oder nur unzureichend, weil die Mitarbeiter zuwenig Kenntnisse des Vorgehens und der Vorschriften haben oder die Entscheider sich soweit absichern wollen, dass es nicht mehr zielführend ist.

Ein Kollege (selbst bei der IBM) hat mal folgendes gesagt, was übrigens auch für die anderen "Grossen" im Beratungsgeschäft gilt:

Die Tagessätze der IBM sind so hoch, weil wir natürlich sehr gute Mitarbeiter liefern. Es kommt aber noch die Versicherungsprämie dazu. Wenn man mit uns ein Projekt in den Sand setzt, kann der Manager sagen: "Ich hab die IBM ins Haus geholt. Wenn es mit denen nicht funktioniert, hätte es ja wohl mit keinem funktioniert."

Und genau dieses Prinzip gilt auch für Ausschreibungen. Man versteckt sich hinter einem "Wir haben das ausgeschrieben und haben uns für den besten Anbieter entschieden".

Ab hier müssen Sie nur noch weiterlesen, wenn Sie meine Vorbehalte detailliert verstehen oder meine Ideen für Verbesserungen kennenlernen wollen.

Praktische Probleme

Wo scheitert die gute Idee "Ausschreibung"?

In den letzten 20 Jahren habe ich viele Ausschreibungen sowohl im privaten als auch im öffentlichen Sektor mitgemacht. Meistens habe ich die Ausschreibungen von Kundenseite begleitet, einige Male aber auch auf Lieferantenseite. Dabei sind mir neben den offensichtlichen Vorteilen auch viele Probleme aufgefallen.

Fachleute

Häufig haben wir ein Problem bei den Mitarbeitern und Entscheidern. Ausschreibungen sind Aufgabe der IT-Abteilung oder sogar eines Einkaufs.

Die IT-Abteilung tendiert dazu, statt der Anforderungen eine Lösung zu beschreiben. Damit werden potentielle Lieferanten schon stark eingeschränkt und gute Lösungsansätze können erst gar nicht angeboten werden (schliesslich darf man ja nur das anbieten, was in der Ausschreibung beschrieben ist).

Einem Einkauf (sorry an alle, denen ich Unrecht tue) fehlt im Regelfall sowohl fachliches als auch technisches Wissen, um die Unterlagen zu erstellen und zu bewerten.

Die offensichtliche Idee, den Fachbereichen die Führung zu übergeben scheitert meist daran, dass diejenigen, die ein neues System brauchen und die Bedürfnisse kennen, so stark ins Tagesgeschäft eingebunden sind, dass ihnen die Zeit fehlt.

Wo sind die Fallen?

Aber wenn alles so gut definiert ist, wo sind denn dann die Probleme? Gibt es überhaupt welche?

Leider ja. Viele der Probleme haben nur am Rand mit Ausschreibungen zu tun. Sie treten in jedem Projekt stärker oder schwächer auf. Bei Ausschreibungen tun sie einfach mehr weh.

Wir haben ja keine Zeit

Da stellt man fest, dass in fünf Jahren aus irgendwelchen Gründen (Änderung der Rechtsgrundlagen, keine Unterstützung mehr für die bestehende Lösung, …) ein neues System benötigt wird oder ein bestehendes abgelöst werden muss. Zack, kaum ein Jahr später weiss man, dass man eine Ausschreibung machen muss. Man hat ja noch vier Jahre. Das Budget für die Ausschreibung ist gesprochen und das für die Umsetzung eingeplant.

Ein weiteres halbes Jahr später ist die Organisation für diese Ausschreibung klar (also man hat zumindest mal den Verantwortlichen benannt). Jetzt muss man sich aber schon etwas sputen, da es ja nur noch dreieinhalb Jahre bis zur Einführung sind.

Das nächste halbe Jahr braucht man, um festzustellen, dass von den wirklich betroffenen keiner Zeit hat und man ziemlich genau am Anfang steht. Puh, noch drei Jahre und ein Haufen Arbeit für die Ausschreibung steht noch an. Jetzt lenkt das Management die Ausschreibung in den Taskforce-Modus (da bin ich ja extrem gerne, kann ich doch meine Tarnkleider und das adrette Barrett tragen).

Die betroffenen nehmen sich die Zeit und man kommt zum ersten Mal vorwärts. Nach weiteren sechs Monaten hat man eine Version 0.9 der Spezifikation für die Ausschreibung. Die ist zwar nicht perfekt, aber es war ja auch wenig Zeit. Zweieinhalb jahre bleiben noch für die Ausschreibung, Sichtung der Angebote, die Vertragsunterzeichnung und vor allem: Die Umsetzung! Der Projektleiter schwitzt immer öfter an unangenehmen Stellen.

Jetzt geht es in die Vernehmlassung. Zum Glück sind ja viele beteiligte dabei. Also braucht man drei Monate, um über die Versionen 0.9.1 – 0.9.23 zu einer offensichtlich finalen Version kommt.

Diese "finale" Version müssen jetzt noch ein paar Leute abzeichnen. Da sie eine Leseschwäche haben, braucht jeder sein eigenes Meeting, in dem man ihm oder ihr erklärt, um was es denn geht. Hui, zwei Monate später ist es soweit: Version 1.0 der Ausschreibungsunterlagen. Da sind zwar immer noch Lücken und Fehler drin, aber immerhin haben alle zugestimmt. Man öffnet eine Flasche Champagner und fällt erschossen ins Bett. Noch zwei Jahre und ein Monat.

Also wird das Zeug veröffentlicht, was nur einen knappen Monat dauert. Interessierte Lieferanten haben drei Monate Zeit dafür, die Unterlagen zu verstehen und ein Angebot einzugeben.

Wir haben jetzt einen Monat, um die Angebote auszuwerten und das sieht ja auch ganz gut aus. Einige erscheinen seriöser, andere weniger. Aber wir haben was.

Jetzt kommt der schöne Moment, in dem man sich kurz entspannen kann, um dann festzustellen, dass alle Angebote höher sind als man urspünglich dachte. Es fehlt Budget. Entweder verbrint man die folgenden zwei Monate damit, zu erklären, warum der ursprüngliche Budgetantrag nicht den Angeboten entspricht, oder man verändert die Ausschreibung so, dass es billiger wird (Wir brauchen das ja eh nicht alles.).

Da eine erneute Ausschreibung wieder mindestens sechs Monate dauert und wir ja sowieso zuwenig Zeit haben, entscheidet man sich für mehr Geld. Noch eineinhalb Jahre.

Auswahl, Zuschlag, Einsprachefrist für nicht berücksichtigte Lieferanten. Und Zack, weitere drei Monate später kann man den Vertrag unterzeichnen. Der Lieferant hat jetzt 15 Monate Zeit. Naja, zwölf Monate, wir wollen ja wenigstens noch drei Monate Testen, bevor wir das neue System auf unsere Mitarbeiter loslassen.

Jetzt wird es spannend, da einige der Lücken und Fehler in der Spezifikation leider ab dem ersten Tag der Nutzung klar und umgesetzt sein müssen. Der (billigste) Lieferant verlangt dafür zu Recht Änderungsanträge / -verträge, da das ja nicht im offerierten Umfang enthalten ist. Das Management verlangt eine Erklärung, warum dieses ausgeschriebene Gewerk jetzt doch noch teurer wird als die schon zur Vertragsunterzeichnung viel höheren Kosten. Der Projektleiter verlangt nach Ferien und seiner Ruhe.

Einige Funktionalitäten können erst nach der Einführung geliefert werden (da sich ja so viel verändert hat).

Auch wenn das Ganze überzeichnet ist, wird sich jeder Manager, jeder Ausschreibungsverantwortliche, einfach jeder Beteilgte hier leider wiedererkennen.

Ganz einfach: Neu für Alt

Meist fängt es mit dem Hauptproblem der Informatik an. Viele Projekte (und damit auch Beschaffungen) starten damit, dass jemand entscheidet, dass ein altes System abgelöst werden soll. Und da man keine Zeit hat, muss das neue System genauso funktionieren wie das alte.

Als Projektleiter stehe ich da immer vor der Frage: "Warum zur Hölle soll jemand einen sechs- bis siebenstelligen Betrag dafür ausgeben, dass sich nichts ändert (ausser dass mehr Fehler im System sind, da es ja neu ist)?"

Das ist aber nur der Anfang des Problems: Da wir ja das alte System haben, braucht es keine Fachleute. Die Spezifikation ist ja klar. Die Mitarbeiter, die das alte System entwickelt haben, müssen dieses noch warten. Also setzen wir jemand neues dran, der aus der bestehenden Implementierung die Anforderungen ableitet. Leider geht dabei rund 20% der Funktionalität verloren.

You can't always get what you want.

Bei Ausschreibungen muss man sich bewusst sein, dass man sehr früh – beim Erstellen der Ausschreibungsunterlagen – festlegt, was man am Ende bekommen wird. Je genauer die Spezifikation der Anforderungen ist, umso stärker ist man gebunden, je ungenauer, umso unzuverlässiger sind die Angebote.

Man bekommt das, was man beschrieben hat, zu dem Angebotspreis. Änderungen kosten Geld. Dinge, die Interpretierbar sind, kosten Geld. Dinge, die fehlen, kosten Geld. Das vermittelt dann vielleicht auch einen Eindruck, warum die meisten IT-Projekte teurer als erwartet werden.

Vertrauen ist gut …

Ein Beispiel nicht aus einer Ausschreibung: Wegen einer persönlichen Beziehung bin ich mal durch den ersten Auswahlprozess bei einer Stelle durchgekommen, obwohl mein Profil rein von den Kriterien nicht passte.

BEim gespräch haben wir dann festgestellt, dass ich bei einem Musskriterium "Mindestens fünf Jahre Erfahrung mit x" angegeben habe, dass ich nur drei Jahre Erfahrung damit habe. Das war auch ok, da es diese Produkt erst seit drei Jahren gab. Bei einem anderen Produkt hatte ich keine Erfahrung, obwohl fünf Jahre gefordert waren. Dieses Produkt gab es nich (Kopierfehler bei der Ausschreibung). Ich hatte dann beim eigentlich geforderten Produkt die Erfahrung.

Das Problem ist, dass die Personalvermittler hier häufig die Profile von Kandidaten "fälschen". Der ist gut, da ist das mit der Erfahrung ja nur eine Frage der Zeit. In dem Fall oben gab es 15 Bewerber, die die Qualifikationen hatten, obwohl das unmöglich ist.

Ich möchte hier nicht Lenin zitieren, da ich mit der Grundaussage nicht wirklich einverstanden bin. Vertrauen ist gut, muss aber auch begründet sein. Bei (öffentlichen) Ausschreibungen hat man häufig mit Lieferanten zu tun, die man nicht kennt. Hier ist ein bisschen Kontrolle meist hilfreich.

Leider vertraut man den Lieferanten teils blind ("Die haben das so schriftlich eingereicht. Das muss also stimmen.") und benachteiligt damit die ehrlichen und meist besseren. Natürlich hat man dann auch selbst Probleme damit. Wenn der Lieferant vorgibt, über alle notwendigen Fähigkeiten im bestehenden Mitarbeiterpool zu verfügen, das aber nicht stimmt, kommt es zu Verzögerungen oder technischen Problemen.

Billig ist nicht immer preiswert

Wenn die Ausschreibungsunterlagen eher schwach sind (oft), wird eine Entscheidung letztendlich über den Preis getroffen. Das birgt enorme Risiken:

  • Der billigste Anbieter hat vermutlich bei allen unklaren Anforderungen die billigste Variante berechnet. Die anderen haben mehr oder weniger Risikokosten einkalkuliert.

  • Grade bei grossen Ausschreibungen hat der billigste Anbieter häufig mit einer Entwicklungsabteilung im Ausland (Nearshoring, Outsourcing, Offshoring … setzen Sie einen Euphemismus Ihrer Wahl ein) kalkuliert. Zu kulturellen Unterschieden (ein einfaches Beispiel: Icons) kommen dann auch noch sprachliche Probleme, da die Spezifikation im Regelfall ein bis zwei Übersetzungsschritte durchläuft. Dasselbe gilt übrigens auch für Rückfragen. Bei einer perfekten Spezifikation muss das kein Problem sein. Allerdings wurde eine perfekte Spezifikation bisher noch nicht in freier Wildbahn gesehen.

  • Wenn der billigste Anbieter so knapp kalkuliert hat, dass das Projekt trotz perfekter Spezifikation (siehe oben) nicht umgesetzt werden kann, steht man vor einer schwierigen Entscheidung: Rechtsstreit und möglicherweise Abbruch des Projektes oder Geld nachschiessen. Wenn man an Deadlines gebunden ist oder sonst auf das Ergebnis angewiesen, wird man immer Geld nachschiessen.

Vertrauen und verstehen

Beispiel aus der Praxis: Ich habe mich mal zwei Monate mit einem Rechtsdienst gestritten, weil ich an einen Lieferanten einen Auftrag freihändig (ohne Ausschreibung) vergeben wollte: Ein Lieferant, der über eine Ausschreibung einen zehnjährigen Vertrag mit uns hatte, sollte nach sechs Jahren auf seiner Seite eine Schnittstelle (seiner eigenen Produktionsanlage) ändern, da wir eine neue Schnittstelle definiert haben.

Mein Argument: Die Produktionsanlage und Software gehört dem Lieferanten. Er ist der Einzige, der diese ändern kann. Es gibt keine Rechtsgrundlage für ihn, einem dritten Zugriff darauf zu gewähren. Die Preise sind realistisch.

Argument des Rechtsdienstes: Das sind über 50 kCHF. Dafür muss immer ein kleines Ausschreibungsverfahren durchlaufen werden.

Hier geht es mehr um die internen Strukturen. Die beteiligten müssen einander respektieren, vertrauen und verstehen. Leider läuft es häufig darauf hinaus, dass die Arbeit der internen Beteiligten beim Ausschreibenden wesentlich stärker hinterfragt wird als die eines Lieferanten.

Woran das liegt? Ich habe keine Ahnung. Vielleicht daran, dass alle Beteiligten bis zum Abschluss der Vorbereitungen einer Ausschreibung Input liefern, für den sie verantwortlich gemacht werden. Danach …

Ein Rechtsdienst oder Einkauf muss sich darauf verlassen (können), dass die Eingaben der Beschaffenden korrekt und korrekt begrünndet sind. Andersrum müssen sich die Beschaffenden darauf verlassen können, dass allfällige Einwände begründet sind. Meine Erfahrung (als Beschaffender) ist, dass Aufgrund fehlenden Wissens auf Seiten "Recht" Beschaffungen abgelehnt werden, weil sie nicht dem Standardvorgehen entsprechen. Auf Seiten "Beschaffung" wird dafür dann schnell auf das Standardvorgehen umgestellt, das aber so manipuliert wird, dass das ursprüngliche Ziel erreicht wird (Voraussetzungen für den Lieferanten sinngemäss und leicht überzeichnet: "Der Geschäftsführer muss 47 Jahre alt sein und einen blonden Schnauzbart haben."). Und damit stehen wir alle gemeinsam bei einem Audit vor grossen Erklärungsnöten. Das hilft niemandem und kostet sehr viel Geld (und Nerven, oh so viele Nerven – siehe mein Beispiel).

Wenn alle Beteiligten verstehen, was die Aufgaben der anderen sind und dass diese auch einen guten Job machen wollen, läuft so eine Ausschreibung viel effizienter und schlussendlich auch effektiver.

Lösungsansätze

Wen braucht's?

Wer muss denn wirklich seinen Senf dazu geben? Reicht es nicht, wenn die IT schreibt, was gebraucht wird und der Einkauf auf Basis der von der IT definierten Entscheidungskriterien aussucht, welcher Lieferant liefern darf?

Kurz: Nein.

Etwas länger: Aus der Erfahrung kann ich sagen, dass das nur dann reicht, wenn man in der IT jemanden hat, der Fachwissen, technisches Wissen, Prozesswissen (Einkaufsprozesse) und Zeit hat. Spätestens am Letzten scheitert es im Regelfall. Aber es gibt diese Leute.

Um eine Ausschreibung sauber und erfolgreich durchführen zu können, braucht es die Beteiligung der folgenden Personen / Rollen. Die Mitarbeiter müssen früh eingeplant und hinzugezogen werden. Jeder einzelne braucht für sein Fachgebiet Entscheidungskompetenz. Eine (interne) abstimmung ist natürlich bei jedem nötig. Braucht man aber für jede Entscheidung zwölf Unterschriften, wird man nie fertig.

  • Einen Verantwortlichen Manager (Owner), der das Budget und das Ergebnis nicht nur verantwortet sondern dessen Ziel auch genau die Einführung des neuen Systems ist.

  • Eine Projektleiterin, die schon mehrere Beschaffungen durchgeführt hat und sich mit Anforderungsmanagement und Stakeholdermanagement auskennt.

  • Fachleute, die Ihre Anforderungen kennen. Das kann zwar durchaus ein Teamleiter sein, aber nur dann, wenn er im Team arbeitet.

Zu Requirements Engineers muss ich was sagen: Ich habe mit vielen hervorragenden zusammen gearbeitet … und mit vielen anderen.

Wichtig ist, dass sie die Bedürfnisse der Fachleute erheben (und aufschreiben!) und Vorschläge, Ideen einbringen, unterschiedliche Meinungen zwischen verschiedenen Beteiligten ausdiskutieren.

Wichtig ist weiterhin, dass sie nicht die Bedürfnisse der Fachleute ignorieren, weil sie der Meinung sind, das eh besser zu wissen.

  • Requirements Engineers: Leute, die sich damit auskennen, wie man Anforderungen eindeutig und vollständig erfasst. Grade bei grösseren Projekten kann das ein Projektleiter nicht nebenher machen.

  • IT-Spezialisten, die die technischen Restriktionen des Unternehmens kennen (eingesetzte Datenbanken, Programmiersprachen, Authentisierungsverfahren, …).

  • Einkäufer / Rechtsdienst, die die Unternehmensspezifischen Einkaufsrichtlinien kennen (zum Beispiel: muss der Lieferant seinen Sitz in der Schweiz, eine gewisse Mindestgrösse haben, …)

Abläufe

Wir verlieren meist sehr viel Zeit und damit auch Geld, weil ein Einführungsdatum in ferner Zukunft liegt und man ja viel Zeit hat. "Die Umsetzung braucht doch höchstens zwei Jahre, also kein Grund für Aktionismus."

Sobald man weiss, dass es ein neues System braucht und dieses Ausgeschrieben werden muss, sollte man loslegen. Wenn man zu früh fertig ist (Spoiler: Das ist man nie.), kann man Zeit mit Schulungen der Betroffenen Mitarbeiter, einem Pilotbetrieb, Finetuning verschwenden. das alles fällt meist weg oder wird massiv gekürzt, wenn es dann eng wird.

  • Wenn klar ist, das eine Beschaffung / Ausschreibung gemacht werden muss, muss umgehend ein verantwortlicher Manager definiert werden. Neben der Budgetverantwortung muss dieser auch die Verantwortung für den Erfolg tragen. Die Managementebene muss dabei hoch genug sein, um den Zugriff auf alle benötigten Mitarbeiter (insbesondere Fachverantwortliche) sicherstellen zu können.

  • Einkäufer und Rechtsdienst müssen hinzugezogen werden (insbesondere wenn bei der Beschaffung bereits externe Mitarbeiter benötigt werden).

  • Der Projektleiter für die Ausschreibung und die Umsetzung muss gefunden (intern oder extern) und beauftragt werden.

  • Der Projektleiter muss einen groben, realistischen und verbindlichen Zeitplan aufstellen. Dieser muss vom Management so akzeptiert werden.

    Hier wird oft der Fehler gemacht, rückwärts zu rechnen: "Wir müssen am 31.12.2022 fertig sein, also muss die Ausschreibung am 01.07.2019 rausgehen, wir haben viel Zeit."

    Es sollte eher ein "Für das Aufsetzen der Organisation für die Ausschreibung brauchen wir drei Monate, für die Spezifikation sechs, für die Abstimmung und Genehmigung weitere drei. In einem Jahr geht die Ausschreibung raus."

  • Requirements Engineers müssen – sofern notwendig – gesucht und beauftragt werden. Dabei ist fachspezifisches Wissen von Vorteil, aber nicht zwingend.

  • Die Fachvertreter müssen ausgesucht und eingeplant werden. Es müssen erfahrene Mitarbeiter sein, die das Tagesgeschäft kennen, und sie müssen dem Projekt zum geplanten Anteil zur Verfügung stehen (!). Hier besteht immer das Risiko, dass Fachabteilungen lieber einen neuen Mitarbeiter abstellen, da dieser im Tagesgeschäft nicht so fehlt.

  • IT-Vertreter müssen ausgesucht und eingeplant werden. Neben einem IT-Architekten, der generelle Vorgaben macht, ist grade bei der Ablösung eines bestehenden Systems auch ein Engineer aus diesem Umfeld sehr hilfreich.

Vermeidungsstrategien vermeiden

Es gibt – neben den offiziellen Ausnahmeregelungen – einige Situationen, die gegen ein "sauberes" Ausschreibungsverfahren sprechen:

  • Anpassung eines Systems, das bereits von einem externen Partner entwickelt und gewartet wird (ist meist schon in den offiziellen Regelungen abgedeckt).

    Der Partner hat Detailwissen zum System, das Spezifikationslücken eher erlaubt. Aufgrund einer (hoffentlich) etablierten Kommunikation sind Rückfragen und Klärungen leicht zu machen. Ein Wechsel auf einen neuen Partner bedeutet immer auch Zusatzaufwand im eigenen Haus (neben der Ausschreibung).

  • Entwicklung eines neuen Systems, das in sehr ähnlicher Form bereits im Haus ist und von einem bestimmten Partner geliefert wurde. Vorteile sind analog der Systemanpassung.

  • Lieferant, der Aufgrund früherer Aufträge bereits Wissen in der Domäne hat. Einarbeitungszeit und Risiko von Missverständnissen ist geringer.

All diese Situationen sind legitime Gründe für eine "freie" Vergabe ohne Ausschreibungsverfahren, da man damit (interne) Kosten oder Risiken reduziert. Natürlich stellen solche Ausnahmen auch ein Risiko für Vetternwirtschaft dar, da ein Einkäufer oder Auditor den Wahrheitsgehalt beziehungsweise das Ausmass im Regelfall nicht prüfen kann.

Wer jetzt aber glaubt, das man durch ein Verbot dieser Ausnahmen eine sauberere Vergabe hinbekommt, ist doch etwas blauäugig: Die Mitarbeiter sind nicht dumm – weder die, die einen legitimen Grund für so eine Ausnahme haben, noch die, die ihrem Schwager ein nettes Geschäft zukommen lassen wollen.

Eine Ausschreibung kann sehr gezielt auf die Kompetenzen und Produkte eines Lieferanten zugeschnitten werden. Bei einem Feierabendbier kann leicht die Offerthöhe anderer Lieferanten "rausrutschen". Man kann eine erste Ausschreibung machen, die unter der vorhandenen Grenze für Zwangsausschreibungen liegt und dann weitere Ausschreibungen als "Folgeauftrag" planen.

Wenn wir Ausnahmen zulassen und diese dokumentieren, wissen wir wenigstens, wo mit welcher Begründung Ausnahmen gemacht wurden. Werden die Mitarbeiter in die Vermeidung der Ausschreibungspflicht getrieben, kann man das nur noch sehr schwer nachvollziehen.

Wenn ich jetzt dem Patenonkel meines Kindes einen Auftrag für ein neues Corporate Design und einen neuen Webauftritt über eine Viertelmillion frei zukommen lasse, müssen der Einkauf, Legal und meine Vorgesetzten schon extrem pennen, damit diese Ausnahme durchgewunken wird. Jedem sollte in so einem Fall klar sein, dass es wohl keine spezifische Erfahrung für solch einen Auftrag geben kann, die die freie Vergabe rechtfertigt.

Verantwortung statt Prozesse

Das Vieraugenprrinzip kenne ich seit meinen ersten Programmieraufgaben. Auch im Management kennt man Prozesse, die sicherstellen sollen, dass mehrere Personen draufschauen und es genehmigen.

Bei meinem aktuellen Auftraggeber habe ich das Glück, dass tatsächlich zwei Leute über mir sind, die meine Beschaffungen freigeben müssen und die es auch tatsächlich interessiert, was ich da schon wieder bestelle. Dabei liegt so ziemlich alles, was ich bestelle unter 100 kCHF, das meiste sogar unter 20 kCHF.

Je höher der Betrag wird, umso geringer wird die Verantwortung, weil da ja noch jemand über mir ist, der das freigeben muss … und der versteht ja eh nicht, um was es geht (das ist weniger meine eigene Erfahrung, da ich ja immer ein externer Mitarbeiter war, dem man sehr genau auf die Finger schauen muss – und das ist für mich auch gut so).

Aber jetzt bestellt jemand eine neue Software, die unbedingt vom Schwager geliefert werden muss und begründet das kurz in zwei Sätzen. Der direkte Vorgesetzte denkt sich "Das wird schon passen. Der Mitarbeiter hat sich ja drei Monate damit beschäftigt." Der nächste in der Hierarchie kriegt ständig so Zeug und denkt sich "Sein Vorgesetzter hat das ja freigegeben. Das wird also alles korrekt sein." und so geht es weiter: Eigentlich gibt es im ganzen Ablauf niemanden, der wirklich das Gefühl hat, verantwortlich zu sein.

Und genau das muss sich ändern. Neben mir als Bestellendem muss es weitere Augen geben, die nicht nur schauen, ob ich alle Pflichtfelder im Antrag ausgefüllt habe, sondern auch, ob der Antrag als solcher "sauber" ist und mir Fragen dazu stellen. Ich persönlich bin um jeden Anruf dankbar, bei dem mich jemand fragt: "Wofür brauchen wir das eigentlich?" oder "Warum haben wir das nicht ausgeschrieben?" oder "Gibt's da nicht eine günstigere Alternative?"