Dieser Text richtet sich an Vorstände und all jene, die den Kauf eines Systems verantworten: an Sekretär (Gemeinde-/Kreissekretär) und Skarbnik (Kämmerer/Treasurer) im Amt, an den Geschäftsführer einer kommunalen Gesellschaft (spółka komunalna), an den CFO, an den Unternehmensinhaber. Auch an den IT-Leiter, der ein Vergabeverfahren oder eine Angebotsanfrage vorbereitet und wissen möchte, worauf der Vorstand achten sollte, bevor er die Unterlagen freigibt.
Warum dieses Problem entsteht
Die meisten Probleme mit Anbietern haben ihre Ursache beim Auftraggeber – und zwar lange vor der Unterschrift. Nicht aus bösem Willen: Die Vorbereitung einer Ausschreibung ist Arbeit, für die in der Organisation selten Zeit und Kompetenz vorhanden sind, und die Anbieter erleichtern sie nur zu gern. Sie liefern fertige Leistungsbeschreibungen, Präsentationen und Kalkulationen. Im Ergebnis kauft der Auftraggeber das, was der Anbieter zu verkaufen versteht, nicht das, was er tatsächlich braucht. Problematisch ist zudem, dass Kaufentscheidungen sehr oft in den Fachabteilungen verbleiben, während die IT lediglich die Rolle des Sicherheitswächters übernimmt. Das Fehlen von Standards und einer langfristigen IT-Strategie führt dazu, dass die Organisation Anschaffungen tätigt, die nicht immer in den Rahmen passen, der eigentlich dem Risikomanagement dienen soll.
Dieselben Fehler sehe ich in Ämtern wie in Unternehmen. Unterschiedlich ist das Vergabeverfahren, nicht der Mechanismus.
Zwölf Fehler
- Anforderungen, die auf Basis des Angebots oder der Präsentation eines einzigen Anbieters verfasst wurden. Das schränkt den Wettbewerb ein und zementiert die Abhängigkeit, noch bevor Sie überhaupt einen Auftragnehmer wählen. Ausführlicher beschrieben habe ich das im Beitrag über Vendor Lock-in in der Leistungsbeschreibung (SWZ).
- Fehlender fachlicher Eigentümer. Das Projekt hat formal einen Projektleiter, aber niemand mit Vorstandsmandat entscheidet, wie die Prozesse ablaufen sollen.
- Keine Abnahmekriterien und Testszenarien vor Vertragsunterzeichnung. Die Abnahme wird zum Streit über Auslegung, statt zur Überprüfung, ob das Projektergebnis die Erfolgskriterien der Implementierung erfüllt.
- Unkenntnis des bereits Vorhandenen. Sie kaufen ein neues System, ohne zu wissen, welche bestehenden Verträge, Lizenzen und Funktionen sich damit überschneiden.
- Vergessene Schnittstellen. Mit welchen Systemen soll das neue System Daten austauschen, in welche Richtungen, welche Systeme sind führend, welche Daten in welchen Formaten – und weiß der Anbieter davon, garantiert er, die nötigen Mechanismen zu liefern, und übernimmt er die Verantwortung für die Kontinuität ihres Betriebs?
- Datenmigration in einem einzigen Satz beschrieben. Ohne Festlegung, welche Daten, aus welchem Zeitraum, wer sie bereinigt und wer das Ergebnis prüft.
- Anforderungen als Funktionsliste statt als Prozessbeschreibung. Jeder Anbieter wird die Frage nach einer Funktion mit „Ja“ beantworten. Auf die Frage, wie er Ihren konkreten Anwendungsfall abdeckt, fallen die Antworten unterschiedlich aus.
- Vergleich des Einstiegspreises statt der Gesamtkosten. Die Lizenz ist nur der Anfang. Betrieb, Änderungen und Schnittstellen bezahlt man jahrelang. Diesen Mechanismus beschreibe ich im Beitrag über die Gesamtbetriebskosten (TCO) und den Frosch im Kochtopf.
- Keine Regeln für Änderungen des Leistungsumfangs. Es ist nicht geklärt, wer eine Änderung meldet, wer sie bewertet und wer sie genehmigt.
- Vertrag ohne Ausstiegsbedingungen. Es fehlen Regelungen zu Datenexport, Dokumentation und Übergabe der Wartung an einen anderen Anbieter. Es fehlen Instrumente zur Risikominderung.
- Wartungsvertrag unverändert aus der Vorlage des Anbieters übernommen. Servicelevel, Reaktionszeiten und Kosten für Änderungen legt dann nur eine Seite fest.
- Entscheidung bis zum letzten Moment vor der Frist aufgeschoben. Wenn eine gesetzliche Frist oder das Ende des Supports für das Altsystem naht, bleibt kein Raum mehr für Angebotsvergleiche oder Verhandlungen.
Die Fehler eins bis drei sind die Ursprungsfehler. Beheben Sie sie, werden die meisten übrigen bereits in der Vorbereitungsphase sichtbar und nicht erst bei der Umsetzung.
Für den Rat, den Aufsichtsrat oder die Zentrale ist entscheidend, ob die Entscheidung für einen Anbieter dokumentiert und begründet ist. Die zwölf oben genannten Punkte sind zugleich eine Liste von Fragen, die sich lohnt zu stellen, bevor der Vorstand die Vergabeunterlagen freigibt.
Beispiel aus der Praxis
Einer unserer Kunden erhielt vom Anbieter seines ERP-Systems die Zusage, man werde problemlos Daten zu Geschäftspartnern mit dem gerade eingeführten System für die elektronische Dokumenten- und Aktenverwaltung (EZD/e-Doręczenia – E-Delivery) austauschen können. Ein solches System speichert in der Regel die Daten aller Geschäftspartner, nicht nur derjenigen, bei denen es bereits zu wirtschaftlichen Vorgängen gekommen ist, also die zu Kunden oder Lieferanten werden. Der Lebenszyklus der Daten eines neuen Geschäftspartners beginnt meist deutlich früher, als es zu solchen wirtschaftlichen Vorgängen kommt.
Im Laufe der Implementierung stellte sich heraus, dass die Kosten für die Anpassung der API-Schnittstelle für den bidirektionalen Datenaustausch zu Geschäftspartnern auf Seiten des ERP-Anbieters 80 % des gesamten Projektwerts der Implementierung des Kostenbeleg-Workflows ausmachten – inklusive Integration mit KSeF, OCR, VIES, dem statistischen Amt (GUS) und schließlich dem Export der Daten ins Finanz- und Rechnungswesensystem. Diese eine Schnittstelle, die zu Beginn nicht genau mit dem Anbieter abgestimmt worden war, hat die Projektkosten praktisch verdoppelt.
Wann ein unabhängiger Berater nötig ist
Wenn Sie ein erfahrenes Team haben, das bereits mehrere ähnliche Vergabeverfahren vorbereitet hat, dient diese Liste als Kontrolle. Ein unabhängiger Blick lohnt sich, wenn die Ausschreibung im Maßstab der Organisation groß ist, wenn die Anforderungen im Kontakt mit nur einem Anbieter entstanden sind, wenn die Entscheidung vor einer Prüfung, dem Rat oder der Zentrale verteidigt werden muss, oder wenn niemand auf Seiten des Auftraggebers diese Systeme von innen kennt.
Ich kann die Unterlagen vor Veröffentlichung des Verfahrens oder vor Versand der Anfrage prüfen, Anforderungen und Testszenarien erarbeiten oder bereits eingereichte Angebote bewerten. Bei Ämtern sieht der Ausgangspunkt etwas anders aus; ich beschreibe ihn auf der Seite für Einheiten der kommunalen Selbstverwaltung (JST).