Wer Angebote von IT-Dienstleistern vergleichen will, steht 2026 vor einem Paradox: Es gibt mehr Anbieter, mehr Spezialisierungen (Cloud, Security, Data, GenAI) – und gleichzeitig weniger Zeit, Fehlentscheidungen zu korrigieren. Ein scheinbar günstiges Angebot kann sich über Change Requests, unklare Abnahmen oder fehlende Betriebsverantwortung schnell verteuern. Umgekehrt kann ein „teures“ Angebot das Risiko so stark senken, dass es über den Lebenszyklus wirtschaftlicher ist.
Dieser Leitfaden zeigt Ihnen eine belastbare Vorgehensweise, um Angebote nicht nur preislich, sondern entlang von Leistungsumfang, Risikoprofil, Preislogik, SLA, Team-Qualität und Governance zu bewerten. Sie erhalten Vorlagen-Logik, Bewertungsmatrizen und konkrete Fragen für Bietertermine – damit Sie am Ende einen Anbieter auswählen, der fachlich, vertraglich und operativ zu Ihrem Vorhaben passt.
Key Takeaways
- Vergleichen Sie Angebote zuerst auf Scope und Annahmen – Preise sind erst sinnvoll, wenn Leistungsgrenzen identisch sind.
- Nutzen Sie eine gewichtete Bewertungsmatrix (fachlich, kommerziell, Risiko, Betrieb) und dokumentieren Sie jede Abweichung als Entscheidungsvorlage.
- Prüfen Sie das Preismodell (Festpreis, T&M, Managed Service, Outcome) samt Anreizstruktur; Gartner ordnet Vor- und Nachteile systematisch ein: Optimum Pricing Model for IT Services Deals.
- Bewerten Sie nicht nur den Anbieter, sondern auch das geplante Team, die Delivery-Methodik, Übergaben und die Messbarkeit über SLA/KPIs.
- Schließen Sie die Auswahl mit einem „Proof of Delivery“ (Workshop, Spike, Pilot) ab, bevor Sie in große Commitments gehen.
Wie gehen Sie beim Angebotsvergleich von IT-Dienstleistern systematisch vor?
Ein erfolgreicher Angebotsvergleich folgt einer festen Reihenfolge: erst Scope klären, dann Qualität und Risiken bewerten, erst danach Preise und Vertragsmodelle gegenüberstellen. Arbeiten Sie mit einer einheitlichen Struktur (Annahmen, Deliverables, Abnahme, Betrieb, Change) und einer gewichteten Matrix. So vermeiden Sie Äpfel-mit-Birnen-Vergleiche und machen Entscheidungen auditierbar.
In der Praxis bewährt sich ein 6-Schritte-Prozess: (1) Anforderungen und Bewertungskriterien vorab fixieren, (2) Angebote normalisieren, (3) fachliche Passung bewerten, (4) kommerzielle Bewertung inkl. Preislogik, (5) Risiko- und Lieferfähigkeit prüfen, (6) Verhandlung und Finalauswahl. Wichtig: Jede Abweichung vom Soll (z. B. andere Tools, andere Rollenverteilung, weniger Tests) wird als Abweichung dokumentiert und bewertet – nicht „wegdiskutiert“.
- Bewertungsschema definieren (Kriterien, Gewichtung, Mindestanforderungen, Knock-out-Kriterien).
- Angebote in ein einheitliches Template überführen (Scope, Annahmen, Zeitplan, Team, Preis, SLA, Risiken).
- Fachliche Bewertung: Architektur, Security, QA, Delivery-Plan, Abnahmefähigkeit.
- Kommerzielle Bewertung: Preismodell, Kostentreiber, Zahlungsplan, Change-Mechanik.
- Lieferfähigkeit: Team-Verfügbarkeit, Referenzen, Onboarding, Betriebsmodell, Compliance.
- Verhandlung: Klarstellungen, Best-and-Final-Offer, Pilot/Workshop, Vertragsfinalisierung.
Welche Kriterien gehören in eine Bewertungsmatrix für IT-Dienstleister-Angebote?
Eine gute Bewertungsmatrix kombiniert harte Muss-Kriterien (Compliance, Security, Mindest-SLA) mit gewichteten Qualitäts- und Wirtschaftlichkeitskriterien. Typisch sind vier Säulen: Fachlichkeit/Technik, Delivery & Team, Betrieb & Governance sowie Kommerzielles (Preis, Zahlungsplan, Vertragsrisiken). Entscheidend ist, dass jedes Kriterium messbar beschrieben ist – inklusive Bewertungsstufen.
Vermeiden Sie Kriterien wie „macht einen guten Eindruck“. Formulieren Sie stattdessen beobachtbare Nachweise: „liefert Threat-Model und Security-Testplan“, „stellt Product Owner/Delivery Lead namentlich vor“, „beschreibt Abnahme je Deliverable“, „legt Runbook-Struktur für Betrieb vor“. Wenn Sie im Bereich Software-Entwicklung einkaufen, sollten Architektur- und QA-Kriterien besonders hoch gewichtet sein, weil sie spätere Betriebs- und Änderungskosten stark beeinflussen.
Beispiel: Bewertungsmatrix (kompakt) als Startpunkt
Die folgende Struktur ist ein praxistauglicher Startpunkt, den Sie je nach Projekt (App, Plattform, Integration, KI) anpassen. Legen Sie pro Kriterium eine Skala (z. B. 0–5) mit klaren Definitionen fest. Ergänzen Sie Mindestanforderungen als Knock-out, damit „billig aber riskant“ nicht durchrutscht.
- Fachlichkeit/Technik: Architekturvorschlag, Security-by-Design, Teststrategie, Daten- & Integrationskonzept.
- Delivery: Vorgehensmodell (agil/hybrid), Meilensteine, Abnahme- und Demo-Rhythmus, Risikomanagement.
- Team: Rollenbesetzung, Seniorität, Verfügbarkeit, Fluktuationsrisiko, Sprache/Zeitzone.
- Betrieb: Monitoring, Incident/Problem/Change, Übergabe, Dokumentation, SLA/OLA.
- Kommerzielles: Preismodell, Kostentransparenz, Zahlungsplan, Change-Mechanik, IP-Rechte.
Wie stellen Sie sicher, dass alle Angebote denselben Leistungsumfang (Scope) abdecken?
Scope-Vergleich gelingt nur, wenn Sie Angebote „normalisieren“: gleiche Deliverables, gleiche Abnahmekriterien, gleiche Annahmen. Fordern Sie eine explizite Liste von Inclusions/Exclusions, Annahmen und Abhängigkeiten. Erst wenn diese Punkte harmonisiert sind, ist ein Preisvergleich aussagekräftig – sonst vergleichen Sie unterschiedliche Projekte.
Erstellen Sie ein „Scope-Delta“-Dokument: pro Anbieter eine Zeile je Deliverable, daneben Abweichungen, Risiken und geschätzte Folgekosten. Typische Scope-Fallen sind: fehlende Testumgebungen, nicht eingepreiste Security-Scans, unklare Datenmigration, fehlende Schulungen oder keine Verantwortung für Betrieb. Besonders bei KI- und Datenprojekten lohnt der Blick auf Integrationsgrenzen; thematisch passend ist auch die Kategorie KI-Integration, wenn Sie Anbieter für produktive Einbettung von Modellen bewerten.
Scope-Check: Fragen, die Sie jedem Anbieter stellen sollten
- Welche Deliverables liefern Sie konkret (Artefakte, Code, Doku, Trainings, Übergaben) – und wie sehen die Abnahmekriterien aus?
- Welche Annahmen treffen Sie zu Datenqualität, Systemzugängen, Fachbereichsverfügbarkeit und Entscheidungswegen?
- Welche Leistungen sind explizit ausgeschlossen (z. B. Penetrationstest, Migration, Lizenzkosten, Betrieb)?
- Wie gehen Sie mit Änderungen um (Change Requests, Backlog-Grooming, Budget- und Terminwirkung)?
- Welche Abhängigkeiten sehen Sie (Drittanbieter, interne Teams, Compliance-Freigaben) und wie mitigieren Sie diese?
Welche Preismodelle sind sinnvoll – und wie bewerten Sie Angebote fair?
Bewerten Sie Preismodelle nach Risikoallokation, Transparenz und Anreizwirkung – nicht nur nach Tagessatz oder Gesamtpreis. Festpreis kann Planungssicherheit geben, erzeugt aber oft Scope-Diskussionen; T&M ist flexibel, braucht jedoch starke Steuerung. Gartner bietet einen Leitfaden zu gängigen Preislogiken und ihren Vor- und Nachteilen: Optimum Pricing Model for IT Services Deals.
Praktisch heißt das: Sie vergleichen nicht „Preis A vs. Preis B“, sondern „Preis pro Risiko“. Ein Anbieter, der Tests, Security, Betriebseinführung und klare Abnahmen einpreist, wirkt teurer – reduziert aber Nacharbeit und Produktionsrisiken. Prüfen Sie außerdem, ob Lizenzen, Cloud-Kosten, Subunternehmer und Reisekosten separat laufen und wie diese kontrolliert werden.
Preismodell-Checkliste (inkl. versteckter Kostentreiber)
- Preisbasis: Tagessatz, Sprint-Rate, Paketpreis, Transaktionspreis, Nutzerpreis, Outcome-basierte Komponente.
- Kostenpositionen: Rollenmix, QA/Testing, DevOps, Projektmanagement, Architektur, Security, Dokumentation.
- Nicht enthaltene Kosten: Cloud/Hosting, Lizenzen, Datenbeschaffung, Monitoring-Tools, Pen-Tests, Schulungen.
- Zahlungsplan: Meilensteinzahlungen vs. monatlich; Kopplung an Abnahmen statt nur „Zeitablauf“.
- Anreizstruktur: Wird Qualität belohnt (z. B. SLA-Boni) oder nur Geschwindigkeit? Wie werden Nacharbeiten behandelt?
Wenn Sie intern argumentieren müssen, hilft ein kurzer Business-Case: Listen Sie pro Angebot die wichtigsten Kostentreiber und die größten Risiken samt potenzieller Folgekosten qualitativ (oder mit Ihren internen Erfahrungswerten) auf. Für Marktsignale zu Rollen und Regionen können Sie ergänzend auf IT salary data by city and role schauen, um Tagessätze/Teamkosten plausibilisieren zu können – ohne daraus automatisch ein „richtiges“ Angebot abzuleiten.
Wie prüfen Sie Qualität, Delivery-Fähigkeit und Team-Seniorität?
Qualität und Delivery-Fähigkeit erkennen Sie an konkreten Nachweisen: Rollenbesetzung, Arbeitsproben, Referenzarchitekturen, QA-Plan, Demo- und Abnahmerhythmus sowie an der Fähigkeit, Risiken offen zu benennen. Verlangen Sie namentliche Schlüsselrollen und prüfen Sie, ob das angebotene Team real verfügbar ist – nicht nur „typisch besetzbar“.
Ein häufiger Fehler ist, nur das Sales-Team zu bewerten. Bestehen Sie auf einem Termin mit dem vorgesehenen Delivery Lead und (bei relevanter Kritikalität) dem Security-Verantwortlichen. Lassen Sie sich erklären, wie sie mit technischen Schulden, Regressionen und Release-Management umgehen. Bei Webprojekten kann der Blick in den Ratgeber Responsive Design in modernen Webprojekten: Umfassender Ratgeber helfen, die richtigen Qualitätsfragen zu stellen (z. B. Performance, Accessibility, Geräteabdeckung).
Lieferfähigkeit: konkrete Prüfpunkte statt Bauchgefühl
- Teamplan: Wer startet wann? Welche Puffer gibt es für Onboarding und Knowledge Transfer?
- Rollenmix: Anteil Senior/Staff vs. Junior; wer entscheidet Architektur und Qualität?
- Methodik: Definition of Done, Code Reviews, Testpyramide, CI/CD, Release-Gates.
- Transparenz: Wöchentliche Statusberichte mit Risiken/Entscheidungsbedarf; nachvollziehbare Metriken.
- Eskalation: Klare Wege bei Blockern, Budget-/Scope-Konflikten und Qualitätsproblemen.
Wie bewerten Sie SLA, Betrieb und Support realistisch?
SLA-Bewertung gelingt, wenn Sie Serviceziele an Geschäftsauswirkungen koppeln: Verfügbarkeit, Reaktions- und Wiederherstellungszeiten, Supportfenster, Monitoring und Verantwortlichkeiten. Prüfen Sie, ob der Anbieter den Betrieb wirklich leisten kann (Tools, On-Call, Runbooks) oder nur „mitliefert“. Ohne klares Betriebsmodell werden SLAs schnell zu Papier.
Achten Sie auf die Schnittstelle zwischen Entwicklung und Betrieb: Wer betreibt, wer patcht, wer verantwortet Security Updates? Bei Managed Services sollten Incident-, Problem- und Change-Prozesse beschrieben sein, inklusive Übergabe nach Projektende. In KI-nahen Vorhaben ist zudem Skalierbarkeit zentral: McKinsey empfiehlt für die öffentliche Verwaltung, dass Dienstleister flexibel einsetzbare und kurzfristig skalierbare Infrastrukturelemente anbieten sollten (McKinsey: Generative KI in der öffentlichen Verwaltung).
SLA-„Reality Check“: typische Lücken in Angeboten
- SLA ohne Messpunkt: Es fehlt, wie Verfügbarkeit gemessen wird (End-to-End vs. Komponente).
- Kein klarer RACI: Unklar, wer im Incident-Fall entscheidet und kommuniziert.
- Supportfenster passt nicht zum Geschäft (z. B. nur 9–17 Uhr, obwohl Kundensystem 24/7 läuft).
- Keine Regelung für Security-Patches, CVE-Handling und Abhängigkeiten (Libraries, Container, Images).
- Unklare Übergabe: Keine Runbooks, keine Betriebsdokumentation, keine Schulung interner Teams.
Wie erkennen Sie Risiken, Annahmen und versteckte Abhängigkeiten in Angeboten?
Risikobewertung heißt: Annahmen sichtbar machen, Eintrittswahrscheinlichkeit und Auswirkung einschätzen und Gegenmaßnahmen bewerten. Gute Anbieter benennen Risiken proaktiv und planen Puffer, Tests und Entscheidungswege ein. Schlechte Angebote wirken „glatt“, weil sie Risiken ausblenden – und verschieben die Kosten später in Change Requests oder Verzögerungen.
Erstellen Sie ein Risikoregister pro Angebot: Datenmigration, Schnittstellen, Compliance, Abhängigkeit von Schlüsselpersonen, Lieferketten (Subunternehmer), Tooling, Verfügbarkeit interner Stakeholder. Bewerten Sie auch „Governance-Risiken“: Wie wird entschieden, priorisiert, freigegeben? Für viele Organisationen ist ein ausgewogener Mix aus In- und Outsourcing sinnvoll, um externe Erkenntnisse zu nutzen und interne Denkweisen zu hinterfragen – McKinsey diskutiert diesen Ansatz im Kontext Digitalisierung im Banking (McKinsey: In-/Outsourcing-Mix).
Risikofragen für den Bietertermin
- Welche drei Risiken sehen Sie als größte Bedrohung für Termin, Budget und Qualität – und wie adressieren Sie diese konkret?
- Welche Entscheidungen benötigen Sie von uns bis wann (z. B. Datenzugänge, Fachfreigaben, Tool-Freigaben)?
- Welche Teile würden Sie als „Spike“ oder Pilot validieren, bevor wir in die Umsetzung gehen?
- Wie stellen Sie sicher, dass Wissen nicht bei Einzelpersonen hängt (Dokumentation, Pairing, Reviews)?
- Welche Abhängigkeiten zu Dritten (Cloud, Lizenzen, Subunternehmer) bestehen und wie sichern Sie Lieferfähigkeit ab?
Welche Rolle spielen Referenzen, Zertifizierungen und Anbieter-Transparenz?
Referenzen und Zertifizierungen sind nützlich, aber nur aussagekräftig, wenn sie zu Ihrem Kontext passen: Branche, Regulatorik, Systemlandschaft, Skalierung und Betriebsanforderungen. Verlangen Sie konkrete Projektbeispiele mit ähnlichen Integrationen, Datenvolumen oder Verfügbarkeitszielen. Transparenz über Subunternehmer, Standorte und Verantwortlichkeiten ist dabei wichtiger als „Logo-Slides“.
Prüfen Sie Referenzen mit Leitfragen: Was war der Ausgangszustand? Welche Risiken traten wirklich ein? Wie wurde gemessen, ob Erfolg erreicht ist? Wenn Sie eine breitere Longlist aufbauen möchten, kann ein Verified IT company catalog helfen, Anbieter zunächst strukturiert zu filtern – die eigentliche Eignung entscheidet sich aber im Angebot, im Team und in der Lieferlogik.
Mini-Case (illustrativ): Zwei Anbieter, gleiche Referenzen – unterschiedliche Realität
Illustratives Beispiel: Zwei Dienstleister bewerben sich auf ein Kundenportal. Beide zeigen ähnliche Referenzen, beide bieten „agile Entwicklung“. Anbieter A liefert im Angebot ein detailliertes Test- und Abnahmekonzept, benennt Teammitglieder und plant eine Betriebsübergabe. Anbieter B bleibt allgemein, kalkuliert günstiger, schließt aber Performance-Tests und Monitoring aus – das Risiko wandert in die Betriebsphase.
Wie bewerten Sie KI- und GenAI-Angebote (ohne sich blenden zu lassen)?
KI-Angebote sollten Sie entlang von Nutzenhypothesen, Daten- und Integrationsfähigkeit, Sicherheits- und Compliance-Konzept sowie Betriebs- und Skalierungsplan bewerten. Achten Sie auf klare Grenzen: Welche Modelle, welche Daten, welche Qualitätsmetriken, welche menschlichen Kontrollen? Ein gutes Angebot macht Risiken wie Halluzinationen, Datenschutz und Kosten pro Anfrage explizit.
Gerade im öffentlichen Kontext wird Skalierbarkeit und flexible Infrastruktur betont: McKinsey empfiehlt für GenAI in der Verwaltung kurzfristig skalierbare Infrastrukturelemente durch IT-Dienstleister (Quelle). Zudem lohnt ein Blick auf Personalisierung: McKinsey betont in einem Gesundheitskontext die Bedeutung von personalisierten Angeboten, angepasst an Bedarf und individuelle Bedürfnisse (Quelle) – übertragen auf KI-Projekte heißt das: Nutzen entsteht oft erst durch zielgruppengerechte Ausgestaltung, nicht durch „ein Modell für alle“.
KI-Angebotsprüfung: Muss-Inhalte, die häufig fehlen
- Use-Case-Definition: messbare Zielmetriken (Qualität, Zeitersparnis, Fehlerquote) und Abnahmelogik.
- Datenkonzept: Datenquellen, Datenqualität, Zugriffsrechte, Aufbewahrung, Löschung, Auditierbarkeit.
- Sicherheitskonzept: Prompt- und Daten-Schutz, Rollen/Permissions, Logging, Red-Teaming-Ansatz.
- Betrieb: Kostensteuerung (z. B. Limits), Monitoring von Qualität/Drift, Incident-Prozesse.
- Integrationsplan: Schnittstellen, MLOps/LLMOps, Rollout- und Change-Management.
Wie verhandeln Sie Angebote, ohne Qualität kaputtzusparen?
Erfolgreiche Verhandlungen trennen Preis von Scope und Qualität: Sie reduzieren nicht blind den Preis, sondern optimieren Leistungszuschnitt, Risikoallokation und Zahlungslogik. Verhandeln Sie über klare Abnahmen, Change-Mechanik, Rollenmix und Transparenz. Ziel ist ein Vertrag, der gutes Verhalten belohnt und Überraschungen früh sichtbar macht.
Nutzen Sie „Trade-offs“ statt Rabatte: z. B. geringere Kosten durch standardisierte Komponenten, reduzierte Varianten, klare Priorisierung oder einen Pilot vor dem Vollausbau. Für Preis- und Feature-Optimierung entlang des Lebenszyklus bietet Statista+ einen Überblick zur Produkt- und Preisforschung (Produkt- und Preisforschung entlang des Produktlebenszyklus) – als Orientierung, wie Organisationen Preislogik und Nutzenargumentation strukturieren, ohne zwangsläufig Zahlen zu übernehmen.
Verhandlungspunkte mit hoher Hebelwirkung
- Abnahme & Definition of Done: Präzisieren statt verwässern; Abnahmen an messbare Kriterien koppeln.
- Change-Mechanik: klare Kategorien (Bug/Change), Aufwandsschätzung, Entscheidungsfristen, Budget-Gates.
- Rollenmix: Seniorität in kritischen Phasen erhöhen (Architektur, Security, Go-live), später optimieren.
- Zahlungsplan: Meilensteine mit Abnahme; Retention-Anteil bis stabiler Betrieb.
- Transparenz: regelmäßige Kosten-/Fortschrittsreports, Zugriff auf Backlog, Doku und Repos.
Praktische Beispiele: 5 typische Vergleichssituationen (illustrativ)
Die folgenden Beispiele sind illustrativ, aber typisch für reale Auswahlprozesse. Sie zeigen, wie sich Angebotsunterschiede erst bei genauer Betrachtung von Scope, Betrieb, Risiken und Teamqualität offenbaren. Nutzen Sie sie als Muster, um Ihre eigenen Angebote gezielt zu „zerlegen“.
Beispiel 1: Festpreis vs. T&M bei unklaren Anforderungen
Illustrativ: Anbieter A bietet Festpreis, setzt aber viele Annahmen (fertige User Stories, keine Datenprobleme) und schließt Änderungen teuer aus. Anbieter B bietet T&M mit Cap und klarer Sprint-Planung, inklusive Discovery-Phase. In dieser Situation ist B oft besser steuerbar, wenn Sie Governance und Priorisierung beherrschen.
Beispiel 2: Günstiger Tagessatz, teurer Rollenmix
Illustrativ: Ein Angebot wirkt günstig, weil der Tagessatz niedrig ist. Beim Rollenmix zeigt sich jedoch: hoher Junior-Anteil, wenig Architektur- und QA-Kapazität, kaum DevOps. Das Risiko sind längere Laufzeiten, mehr Rework und spätere Stabilitätsprobleme – die Gesamtkosten steigen trotz „günstigem“ Einstieg.
Beispiel 3: Web-Relaunch ohne Performance- und Accessibility-Plan
Illustrativ: Zwei Webagenturen bieten denselben Relaunch an. Eine kalkuliert Performance-Budget, Accessibility-Checks und Geräte-/Browser-Matrix; die andere nicht. Wenn Ihre Plattform Umsatz oder Lead-Generierung treibt, sind diese Qualitätsmerkmale keine „Extras“, sondern betriebswirtschaftliche Anforderungen – und sollten in Scope und Abnahme verankert werden.
Beispiel 4: KI-Pilot ohne Plan für produktiven Betrieb
Illustrativ: Ein Anbieter liefert schnell einen Chatbot-Pilot, aber ohne Logging, Kostenkontrolle, Rollen-/Rechtekonzept und Integrationsstrategie. Ein anderer plant von Beginn an LLMOps, Monitoring und Skalierung. Der zweite wirkt langsamer, reduziert aber das Risiko, dass der Pilot nie produktionsreif wird.
Beispiel 5: Outsourcing ohne interne Produktverantwortung
Illustrativ: Ein Unternehmen will „alles auslagern“ und erwartet, dass der Dienstleister Anforderungen und Priorisierung übernimmt. Das Angebot wird zwangsläufig unpräzise oder teuer, weil Entscheidungen fehlen. Besser: klare interne Produktverantwortung und ein ausgewogener In-/Outsourcing-Mix, wie McKinsey ihn als Nutzenhebel beschreibt (Quelle).
Welche Dokumente sollten Sie im Angebot zwingend anfordern?
Fordern Sie Dokumente an, die den Übergang von „PowerPoint“ zu lieferbarer Realität abbilden: Scope-Definition, Projektplan, Team, Qualitätssicherung, Security, Betrieb und Vertragsanlage. Je konkreter die Artefakte, desto besser lässt sich vergleichen. Ein Anbieter, der diese Inhalte nicht liefern kann, wird sie später auch schwer umsetzen.
Für komplexe Vorhaben lohnt ein standardisiertes Angebots-Template (RFP/RFQ), damit Sie Antworten direkt nebeneinander legen können. Wenn Sie zusätzlich wissen möchten, welche typischen Auswahlfehler in der Praxis passieren, hilft der Artikel Top 10 Fehler bei der Auswahl von IT-Agenturen vermeiden als Gegencheck während der Shortlist-Phase.
Mindest-Set an Angebotsanhängen (praxisbewährt)
- Leistungsbeschreibung mit Inclusions/Exclusions, Annahmen, Abhängigkeiten.
- Projekt- und Releaseplan mit Meilensteinen, Abnahmen, Demo-Rhythmus.
- Teamübersicht (namentlich für Schlüsselrollen), Rollenbeschreibung, Verfügbarkeit.
- QA- und Testkonzept (Automatisierung, Teststufen, Abdeckung, Testdaten).
- Security-Konzept (Threat Modeling, Reviews, Scans, Pen-Test-Plan, Patch-Prozess).
- Betriebskonzept inkl. SLA, Monitoring, Incident-Prozess, Runbooks, Übergabeplan.
Umsetzungs-Checkliste: Nächste Schritte für Ihren Angebotsvergleich
Nutzen Sie diese Checkliste als Arbeitsplan für die nächsten 10–15 Werktage – von der Vorbereitung bis zur finalen Entscheidung. Ziel ist ein nachvollziehbarer, vergleichbarer und verhandelbarer Angebotsstand. Wenn Sie konsequent normalisieren, bewerten und nachweisen lassen, sinkt das Projektrisiko messbar – ohne dass Sie „überbürokratisieren“.
- Bewertungskriterien finalisieren: Gewichtungen festlegen, Knock-out-Kriterien definieren, Bewertungsstufen beschreiben.
- Angebots-Template versenden: gleiche Struktur für alle (Scope, Annahmen, Team, QA, Betrieb, Preis, Vertragsannahmen).
- Angebote normalisieren: Scope-Delta je Anbieter erstellen; offene Punkte als Fragenliste sammeln.
- Fachreview organisieren: Architektur, Security, Betrieb, Fachbereich – jede Disziplin bewertet definierte Kriterien.
- Bietertermine durchführen: Team vorstellen lassen; Risiken, Annahmen, Abnahmen und Change-Mechanik durchsprechen.
- Kommerzielle Auswertung: Preismodell, Zahlungsplan, Kostentreiber, Ausschlüsse, Subunternehmer- und Nebenkostenlogik prüfen.
- Proof of Delivery planen: Workshop/Spike/Pilot (2–4 Wochen) mit klaren Abnahmekriterien statt „Gefühlstest“.
- Best-and-Final-Offer einholen: Änderungen dokumentieren; Matrix aktualisieren; Entscheidungsvorlage erstellen.
- Vertrag & Governance fixieren: RACI, Kommunikationsrhythmus, Reporting, Eskalation, SLA, Übergaben, IP-Rechte.
- Kickoff vorbereiten: Onboarding, Zugänge, Tooling, Definition of Done, erste Meilensteine, Risiko-Register aktivieren.
