Kompatibel ist nicht dasselbe wie zertifiziert

Drei verschiedene Fragen

Kompatibilität fragt, ob ein Gerät in einer definierten Umgebung funktioniert. Plattformzertifizierung fragt, ob ein Anbieterprogramm bestanden wurde. Regulatorische Konformität fragt, ob Marktzugangsanforderungen erfüllt sind. Keines dieser Labels ersetzt das andere.

Für die Beschaffung ist die nützlichste Frage enger: Welche exakte Konfiguration wurde von wem, an welchem Datum und gegen welche Softwareversion getestet?

Wie Kompatibilitätsnachweise aussehen

Kompatibilitätsnachweis ist eine Konfigurationsaufzeichnung, kein Logo. Sie sollte Produktrevision, Betriebssystem und Build, Meeting-Anwendung und Version, Verbindungsmethode und getestete Firmware benennen.

Wenn sich ein Teil des Stacks ändert, ist der Nachweis technisch veraltet. Eine letztes Jahr unter einem älteren Betriebssystem getestete Konfiguration sagt Ihnen weiterhin etwas, sollte aber vor der Skalierung erneut validiert werden.

• Exakte Produkt- und Hardware-Revision
• Betriebssystem und Build
• Meeting-Anwendung und Version
• Verbindungsmethode und Kabel
• Firmware-Version und Testdatum

Was Zertifizierung tatsächlich erfordert

Zertifizierung wird von einem Anbieter- oder Standardprogramm vergeben und üblicherweise in einer formellen Listung, einem Zertifikat oder Schreiben dokumentiert. Inhaber, abgedeckte Produkte und Gültigkeitsdauer sind Teil des Nachweises.

Formulierungen wie certified-ready, Zertifizierung ausstehend oder certified-compatible sind Statusangaben, keine Zertifizierung. Wenn Ihre Produktrevision nicht in der Liste steht, deckt das Zertifikat sie nicht ab.

Regulatorische Konformität ist marktspezifisch

Konformität hängt vom Zielmarkt ab: Funkfunktionen, Stromversorgung, EMV, Verpackung und Kennzeichnung. Ein in einem Markt konformes Gerät kann es in einem anderen nicht sein.

Fordern Sie das Zertifikat oder die Erklärung an, das den gesetzlichen Hersteller, das exakte Modell, die abgedeckten Märkte und die Gültigkeitsdauer nennt. Marktspezifische Nachweise lassen sich nicht von einer Partnerregion verallgemeinern.

Fordern Sie die Nachweiskette an

Fordern Sie von jedem Anbieter dieselben Nachweise, um Antworten vergleichen zu können. Bewahren Sie die Antworten zusammen mit der Kaufakte auf — die Nachweiskette brauchen Sie bei Installation und Audits.

• Getestete Betriebssysteme und Anwendungsversionen
• Verbindungsmethode und Hardware-Revision
• Zertifizierungsliste oder Berichtsreferenz und deren Inhaber
• Abgedeckte Länder und Konfigurationen
• Test- und Überprüfungsdaten

Pflegen Sie ein lebendes Nachweisregister

Beschaffungsteams sollten pro Modell ein kurzes Register führen: Anspruch, Nachweisreferenz, Prüfdatum und nächstes Prüfdatum. Wenn Firmware, Hardware, Betriebssystem oder Anwendungsversionen wechseln, werden die betroffenen Zeilen neu getestet.

• Anspruch und Nachweisreferenz
• Prüfdatum und Verantwortlicher
• Geplante nächste Prüfung
• Neutest-Auslöser und Ergebnisse

Häufige Fallstricke

Die meisten Probleme entstehen, wenn ein Marketinglabel als Nachweis behandelt wird: ein Plattformlogo als Kompatibilitätsbeweis, eine Statusformulierung als Zertifizierung, eine abgelaufene Listung auf einer Produktseite oder eine alte Konfiguration als aktuelle.

In den meisten Fällen ist das keine Absicht, sondern das Ergebnis ungeprüfter Inhalte. Ein kurzes, datiertes Nachweisregister beseitigt die Mehrdeutigkeit.

• Ein Logo als Beweis eines Konfigurationstests
• Statusformulierungen als Zertifizierung
• Abgelaufene oder ersetzte Listungen
• Nachweise einer Region auf eine andere angewandt

Dokumentieren Sie ausstehende Status ehrlich

Eine öffentliche Roadmap darf sagen, dass eine Bewertung oder Prüfung läuft. Sie sollte keine Formulierungen verwenden, die einer Zertifizierung ähneln, bevor die Organisation den Status erteilt hat.