Prüfen, ob Referenzen die Tender-Regeln erfüllen

Regel

Einen Referenzsatz in getrennte Pass-Fail-Tests zerlegen

Kopieren Sie die vollständige Condition aus dem Controlling Document, einschließlich Definitions, Footnotes, Form Instructions, Entity Rules und Clarifications. Zerlegen Sie sie in atomare Predicates. „Drei vergleichbare, in den letzten fünf Jahren abgeschlossene Verträge von je mindestens einer Million Euro einschließlich Multi-site Migration“ enthält Count, Similarity, Completion, Period, Value, Activity und Evidence Tests. Keiner kompensiert einen anderen.

Klassifizieren Sie jedes Predicate als explicit, interpreted oder unresolved. Explicit ist definiert. Interpreted nutzt einen begründeten Read für einen Begriff wie „similar“. Unresolved bedeutet, dass plausible Reads Eligibility verändern. Erfassen Sie Frage, Quelle und Konsequenz für Clarification. Fragen Sie nicht informell nach Freigabe Ihres Lieblingsprojekts, sondern nach der Regel, die alle Bieter konsistent anwenden können.

Trennen Sie Mandatory und Scored Experience. Ein Projekt kann das Minimum erfüllen und dennoch schwach gegen Quality Criteria sein. Ein anderes ist sehr überzeugend, liegt aber außerhalb der Look-back Period. Bilden Sie zuerst das Eligibility Set. Wählen Sie danach jene zulässigen Beispiele, die Understanding, Complexity, Outcomes und Risk Control am besten belegen.

Projekt

Die tatsächlich erbrachte Arbeit vor Similarity definieren

Erstellen Sie einen Reference Fact Record aus Contracts, Statements of Work, Purchase Orders, Invoices, Acceptance Records und Delivery Data. Nennen Sie Customer Legal Entity, Supplier Entity, Contract und Lot IDs, Base und Options, Status, Geography, Users oder Sites, Supplier Role, Subcontractors und Service Boundary. Liegen mehrere Work Orders unter einem Framework, prüfen Sie, ob sie als ein Contract gelten dürfen.

Gleichen Sie Value genau ab. Erfassen Sie Total Contract Value, Award an die Bidding Entity, Amount Performed und Value der relevanten Services. Nennen Sie Currency, Tax, Price Basis und Conversion Date. Ein Framework Maximum ist nicht automatisch Spend. Ein JV Contract gehört nicht automatisch jedem Member. Ein Multi-service Contract kann Threshold überschreiten, obwohl Similar Work darunter liegt. Nutzen Sie die Tender Metric und nicht die größte plausible Zahl.

Mappen Sie Similarity auf der verlangten Ebene: Outcome, Technical Activity, Regulation, Scale, Contract Model, Geography oder Customer Type. Erfassen Sie Direct Match, Comparable Match und Gap mit Evidence. Machen Sie aus allgemeinem Deployment keine Data Migration, wenn diese Arbeit nicht tatsächlich geleistet wurde. Verwerfen Sie aber keine Referenz nur wegen anderer Terminologie, wenn die zugrunde liegende Arbeit das definierte Predicate klar erfüllt.

• Controlled Records statt Marketing Summary.
• Framework, Contract, Work Order und Relevant Value trennen.
• Supplier Role erfassen.
• Units, Currency, Tax und Period normalisieren.
• Similarity gegen Buyer Activity testen.

Attribution

Prüfen, wem die Experience gehört und wann sie zählt

Beginnen Sie mit Bidding Legal Entity und Consortium. Prüfen Sie, ob jeder Member, ein Member, Group collectively, Lead, named Subcontractor oder eine Reliance Entity die Bedingung erfüllen darf. Die EU Public Procurement Directive behandelt technische Leistungsfähigkeit und unter Bedingungen die Nutzung von Kapazitäten anderer Entities. Die konkrete Vergabe bestimmt Struktur und Proof. Gemeinsame Marke überträgt keinen Parent Contract an eine Subsidiary.

Bei Acquisition, Merger, Reorganization und Predecessor belegen Sie Legal Succession, Assets, People und übertragene Capacity und beschaffen die verlangte Interpretation. Beanspruchen Sie nicht die gesamte Seller History, weil Mitarbeiter wechselten. Für JV Reference nennen Sie Member Role, Share und Activities. Kann Named Expert Experience separat zählen, bleiben Personal und Corporate Experience getrennt und Availability wird belegt.

Erstellen Sie Date Line mit Award, Signature, Service Start, Relevant Activity, Acceptance, Completion, Current Status und Extension. Wenden Sie den genauen Trigger an. Ein vor sechs Jahren signierter und vor zwei Jahren abgeschlossener Contract kann unter Completion Test passen und unter Award Test scheitern. Ein Live Contract kann bei „performed during“ passen, aber bei Completion Requirement scheitern.

Proof

Vorgeschriebenen Nachweis sichern, bevor die Referenz trägt

Listen Sie admissible Proof: Prescribed Form, Completion oder Performance Certificate, Contract Extract, Purchase Order, Invoice Record, Customer Declaration, Contact Details, Translation, Signature oder Portal Field. World Bank und EBRD Standard Resources zeigen, warum strukturierte Experience Records wichtig sind: Dates, Role, Value und Completion werden vergleichbar. Folgen Sie der aktuellen Vergabe statt allgemeines Case-study Document anzunehmen.

Kontaktieren Sie den Customer über autorisierten Account Owner. Erklären Sie Procurement, disclosed Facts, Verification Route, Consent und Deadline. Die Kontaktperson bestätigt nur, was sie wissen und nennen darf. Ein Executive, der nach Delivery eintrat, kann Historical Scope vielleicht nicht zertifizieren. Schützen Sie Confidentiality und Data Protection. Nutzen Sie erlaubte Redaction oder Alternative Evidence statt vertraulichen Vertrag unerlaubt zu senden.

Gleichen Sie jedes Form Field mit Records und Predicate Result ab: Dates, Currency, Tax, Names, Entity Numbers, Values, Role, Completion Wording und Contact. Ein unabhängiger Reviewer reproduziert Pass aus Rule und Evidence. Conditional Interpretation bleibt in Qualification sichtbar. Wenn kein Projekt bis Deadline alle Mandatory Tests erfüllt, ist dies Eligibility Failure oder verlangt eine erlaubte strukturelle Lösung, nicht bessere Prosa.

• Prescribed Form und Evidence Hierarchy folgen.
• Customer Consent sichern.
• Confidential Records erlaubnisgerecht behandeln.
• Jedes Feld mit Source abgleichen.
• Ehrlich failen, wenn kein Projekt passt.