--- title: "Bieten, wenn nicht alle Anforderungen erfüllt sind?" description: "Klassifizieren Sie jede Capability Gap nach Konsequenz, Cure Path, Deadline und Authority statt eine hohe Match Percentage als Bid-Grund zu nehmen." canonical: "https://zephior.com/de/insights/decide-whether-a-partial-capability-fit-is-biddable" last-updated: 2026-09-02 --- # Bieten, wenn nicht alle Anforderungen erfüllt sind? > Klassifizieren Sie jede Capability Gap nach Konsequenz, Cure Path, Deadline und Authority statt eine hohe Match Percentage als Bid-Grund zu nehmen. Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Veröffentlicht 2026-09-02; aktualisiert 2026-09-02. 8 Min. Lesezeit. ## Definition Partial-fit Biddability Assessment bestimmt, ob ein Supplier ein zulässiges, wahrheitsgemäßes und lieferbares Angebot einreichen kann, wenn Current Capability nicht vollständig passt. Sie klassifiziert jede Gap nach formaler Konsequenz, prüft erlaubte Alternatives und Qualifications, testet Machbarkeit und Authority eines Cure und klärt, wann Compliance bestehen muss. Sie berechnet nicht die gesamte strategische Attraktivität und nimmt nicht an, dass ein Prozentwert Mandatory Failure ausgleicht. ## Problem Teams sagen, sie erfüllen 85 oder 90 Prozent eines RFP, als wären Requirements austauschbare Einheiten. Eine fehlende Signature, License, Certification, Data Residency oder Core Service kann Evaluation verhindern, während zwanzig kleine Schwächen nur Punkte kosten. Product verspricht Feature ohne Delivery, Commercial versteckt Exception in Assumptions und Writer beschreibt Manual Workaround als native Capability. Die Percentage ignoriert Konsequenz, Timing, Dependency und ob Departure erlaubt ist. ## Perspektive Entscheiden Sie auf Gap Level vor Opportunity Level. Bewahren Sie das Controlling Requirement und klassifizieren Sie Participation, Technical Pass-Fail, Scored, Contractual, Delivery, Evidence oder Presentation. Nennen Sie Current Shortfall exakt. Testen Sie Compliant Interpretation, permitted Alternative, Evidence Recovery, Partner, Delivery Cure, formal Deviation oder Stop. Jeder Cure braucht Owner, Proof, Latest Date, Cost, Dependency und Authority. Er ist nur curable, wenn das Angebot zum erforderlichen Zeitpunkt erlaubt, wahr und machbar bleibt. ## Fit Percentage durch Consequence Map ersetzen Bilden Sie das Gap Set aus Controlling Tender Baseline mit Annexes, Forms, Contract Schedules, Clarifications und Portal Fields. Je Gap erfassen Sie Requirement, Verb, Mandatory Language, Evaluation Treatment und Required Time. Schreiben Sie Current State falsifizierbar. „Partial Fit“ genügt nicht. „Der Current Service exportiert täglich; Requirement 7.4 verlangt Event in sechzig Sekunden“ definiert den Unterschied. Klassifizieren Sie Consequence vor Solution. Participation und Technical Pass-Fail können Evaluation stoppen. Scored Requirements beeinflussen Position, erlauben aber eventuell niedrigeren Score. Contract Gaps können negotiable, prohibited oder nur im Deviation Process erlaubt sein. Delivery Gap besteht trotz formaler Compliance. Evidence Gap bedeutet vorhandene Capability ohne Proof. Presentation Gap betrifft Format statt Substanz. Maßgeblich bleibt die exakte Rule. Die EU Procurement Directive trennt Selection Conditions, Technical Specifications, Award Criteria und Contract Performance Conditions. Der Tender entscheidet, doch diese Trennung zeigt die Gefahr eines Match Scores. Ein Supplier kann Eligibility erfüllen und bei einem Feature schwächer sein oder exzellente Solution mit fehlender Participation Condition anbieten. Zeigen Sie Hard Gaps einzeln und nie nur „97 Prozent compliant“. **Gap Classes** | Klasse | Frage | Treatment | | --- | --- | --- | | Participation oder Pass-Fail | Wird evaluiert? | Pass oder explizit erlaubter Weg | | Scored Capability | Welche Points gefährdet? | Score und Differentiation | | Contract | Kann Obligation akzeptiert werden? | Exception und Authority | | Delivery | Kann Promise erfüllt werden? | Design und Acceptance | | Evidence | Kann Capability belegt werden? | Current Proof | ## Missing Capability, Missing Proof und Interpretation trennen Lassen Sie Product, Delivery oder Policy Owner den Current State in repräsentativen Bedingungen demonstrieren. Sales Statement oder Roadmap Slide ist keine Evidenz. Erfassen Sie Edition, Configuration, Geography, Environment, Scale, Dependencies und Failure Modes. Capability nur durch Custom Work oder Third Party ist nicht Standard Function. Testing Feature ist nicht automatisch approved für Proposed Service. Existiert Capability, aber Proof fehlt, definieren Sie admissible Record: Demonstration, Test Output, Certificate, Customer Acceptance, Policy, Operating Report oder Signed Declaration. Prüfen Sie Recency und Scope. Redesignen Sie nicht Product wegen Documentation Gap. Erfinden Sie umgekehrt keinen Screenshot für substantive Shortfall. Evidence Recovery bestätigt einen bestehenden Fakt; sie erzeugt ihn nicht. Manche Gaps folgen Interpretation. Real time, standard, local, automated, supported oder equivalent können undefiniert sein. Mappen Sie plausible Reads und Consequence. Suchen Sie Definitions und Related Clauses und fragen Sie neutral im permitted Channel. Wählen Sie nicht privat die leichteste Bedeutung. Bis Resolution bleibt die Gap Conditional mit Stop Date vor großem Investment. - Current State im Proposed Configuration demonstrieren. - Conditions und Dependencies erfassen. - Evidence Recovery nur für bestehende Capability. - Ambiguity sichtbar halten. - Clarification Condition befristen. ## Remedies testen, ohne Noncompliance zu verstecken Nutzen Sie Reihenfolge. Prüfen Sie erst bessere Interpretation der Controlled Documents, dann Clarification, dann Compliant Alternative mit gleichem Outcome, Partner Capacity unter Participation Rules, Delivery Cure bis Required Date und zuletzt formal Qualification nur bei Erlaubnis und Commercial Acceptance. Workaround wird gegen Requirement geprüft. Manual Review kann Accuracy liefern und dennoch Automation oder Response Time verfehlen. Partner kann Capability besitzen, aber Signed Commitment, Role, Security oder Priced Scope fehlen. Custom Development kann technisch möglich sein, aber Daten, Architecture, Testing und Buyer Acceptance verlangen. Erfassen Sie Operating und Contract Effect und nicht nur Functional Endpoint. Verstecken Sie Deviation nicht in Assumptions oder Footnotes. Fragt die Form compliant oder noncompliant, antworten Sie nach Definition wahr. Sind Alternatives erlaubt, trennen Sie Base und Alternative. Brauchen Exceptions ein Schedule, gleichen Sie Narrative, Price und Contract Response ab. Ein kaum sichtbares Caveat reduziert Commitment nicht; es erhöht Misrepresentation und Delivery Risk. **Treatment Test** | Treatment | Evidence | Failure | | --- | --- | --- | | Clarified Interpretation | Published Answer | Private Reading | | Compliant Alternative | Outcome und Permission | Prescribed Method geändert | | Partner | Role und Binding Evidence | Logo ohne Commitment | | Delivery Cure | Plan, Resource, Test und Date | Roadmap Aspiration | | Qualification | Permitted Schedule und Authority | Hidden Caveat | ## Closure Proof verlangen, bevor der Tender biddable ist Erfassen Sie je curable Gap den Closure State: Owner, funded Resources, Dependencies, Acceptance, Evidence Artifact, Cost, Risk, Internal Decision und Buyer Date. Trennen Sie Bid Time, Award, Signature, Mobilization und Service Start. Ein Cure nach Relevant Date ist Failure. Integrieren Sie ihn in Solution, Implementation, Price, Risk und Contract, damit er kein uncosted Promise bleibt. Nutzen Sie Authority, die Consequence trägt. Product kann Development Plan, aber nicht Customer Commitment freigeben. Delivery akzeptiert Feasibility. Security oder Compliance Owner akzeptieren Controls. Finance akzeptiert Cost. Commercial oder Legal Delegates behandeln Exceptions. Opportunity Owner kann diese Freigaben nicht aggregieren. Ändern Dates oder Scope, öffnen Sie Decision. Proceed gilt, wenn Hard Conditions bestehen oder permitted, approved und evidenced Treatment haben. Conditional Proceed nennt Closure Evidence und kurze Expiry und begrenzt Investment. Hold verhindert Commitment bis zum Fakt. Stop erfasst failed Condition und verhindert spätere Umbenennung durch Sunk Cost. Danach bewertet breiteres Bid-or-No-Bid Probability, Economics, Capacity und Strategy. - Closure Evidence statt Activities definieren. - Cure Date an Required State ausrichten. - Treatment preisen und vertraglich abbilden. - Richtige Authority nutzen. - Bei Hard Gap ohne Route stoppen. ## Nützliche Ergebnisse - Jede Gap ist mit Requirement und Consequence verbunden. - Hard Failures werden nicht durch Percentage verdünnt. - Evidence Gap bleibt von fehlender Capability getrennt. - Alternative, Qualification und Partner werden nur erlaubt genutzt. - Jeder Cure hat Authority, Proof, Cost und Date. - Pursue oder Stop hängt nicht an Hidden Promise. ## Ablauf 1. **Gap Set bilden.** Requirement Baseline mit evidenced Current Capability vergleichen. 2. **Konsequenz klassifizieren.** Participation und Pass-Fail von Scoring, Contract, Delivery und Evidence trennen. 3. **Treatments testen.** Interpretation, Clarification, Alternative, Partner, Evidence, Cure und Qualification prüfen. 4. **Cure belegen.** Plan, Acceptance, Cost, Dependencies, Authority und rechtzeitigen State verlangen. 5. **Biddability entscheiden.** Nur mit Passed Hard Gaps oder permitted, approved, evidenced Treatment fortfahren. ## Wichtige Entscheidungen - Ist die Gap real oder ändert Clarification die Interpretation? - Führt sie zu Exclusion, Score Loss, Contract Exception oder Delivery Risk? - Wann muss Capability bestehen? - Sind Alternatives, Evidence, Partner oder Qualification erlaubt? - Erfüllt ein Workaround das Outcome? - Wer autorisiert Cost und Commitment? - Welcher Proof schließt die Gap? - Welche Gap erzwingt Stop? ## Risiken - Mandatory Condition wird mit Scored Requirements gemittelt. - Missing Documentation und Missing Capability werden verwechselt. - Manual Process erfüllt Automation nicht. - Partner fehlt erlaubte Reliance oder Commitment. - Future Capability ist nicht approved. - Qualification wird in Narrative versteckt. - Cure kommt nach Required Date. - Gap Closure erzeugt Widerspruch in Price oder Contract. ## Kennzahlen - Gaps nach Consequence - Hard Gaps mit permitted Treatment - Evidence Gaps geschlossen - Cure Plans approved - Partner Gaps mit Binding Evidence - Conditional Decisions rechtzeitig geschlossen - Late Changes aus Hidden Gaps ## Häufige Fragen ### Reichen 90 Prozent Fit? Nein. Ein unmet Pass-Fail kann viele Matches überwiegen. Prüfen Sie jede Gap nach Consequence und Treatment. ### Kann Manual Workaround compliant sein? Nur wenn er Requirement in Outcome und Method erfüllt, erlaubt, machbar und offengelegt ist. Eine Automation Condition wird nicht durch Umbenennung erfüllt. ### Dürfen wir ein fehlendes Feature versprechen? Nur wenn Future State erlaubt ist, rechtzeitig existiert, Dependencies und Acceptance kontrolliert sind und autorisierte Owner das Commitment freigeben. ### Stoppt eine Scored Gap den Bid? Nicht automatisch. Schätzen Sie Score Loss, Differentiation, Delivery und Treatment Cost für die breitere Qualification. ## Primärquellen - [Richtlinie 2014/24/EU](https://eur-lex.europa.eu/eli/dir/2014/24/oj/deu), EUR-Lex - [The Sourcing Playbook](https://www.gov.uk/government/publications/the-sourcing-and-consultancy-playbooks/the-sourcing-playbook-html), UK Cabinet Office - [World Bank Project Procurement Framework](https://www.worldbank.org/ext/en/what-we-do/project-procurement/framework), World Bank ## Weiterführende Artikel - [Braucht diese Ausschreibung einen Partner?](https://zephior.com/de/insights/decide-when-a-bid-needs-a-partner) - [Ausschreibung ohne Auftraggeberkontakt qualifizieren](https://zephior.com/de/insights/qualify-a-tender-without-buyer-access) - [Bieten trotz Lücke bei einer Sicherheitskontrolle?](https://zephior.com/de/insights/qualify-a-bid-with-security-control-gaps) - [Fehlendes Zertifikat: Ist die Ausschreibung noch bietbar?](https://zephior.com/de/insights/decide-whether-to-bid-with-missing-certification)