Compliance- und Security-Schritte bei der Anfrage: die unbequemen Fragen zuerst stellen
Die zwei Schritte im Request Wizard, die Certifications, Datenbehandlung und Handling-Auflagen festnageln, bevor die Bid-Runde öffnet.
Eine Pickup Request, die nie sagt, was die Entsorgung belegen muss, kommt mit Geboten zurück, die für einen anderen Job kalkuliert sind. Alle merken das nach dem Award, in einem Meeting, mit einem Procurement Officer, der nicht mehr charmiert ist. Zwei Schritte im Request Wizard existieren, damit diese Antworten vor dem Bieten feststehen: einer für das, was der Kunde belegt haben will, einer dafür, wie die Ware auf dem Weg nach draußen behandelt werden muss.
Der Compliance-Schritt
Der Kunde gibt an, ob die Geräte datentragend sind, und wählt dann die Datenbehandlung: logische Datenlöschung, physische Vernichtung oder beides. Die geforderten Certifications kommen aus einer kurzen festen Liste — R2v3, e-Stewards, NAID AAA, ISO 14001, ISO 27001 und WEEELABEX — und jede einzelne verkleinert den Kreis der ITADs, die die Request erreichen kann. Daneben stehen die Nachweiswünsche: Vernichtung vor Ort, Vernichtung unter Zeugen, Videonachweis, ein Report pro Asset, ein ESG Report. Der Schritt schließt mit der Disposition Preference: Wiederverwendung bevorzugt, nur Recycling oder beides akzeptabel.
Sechs Certifications sind kein Mangel an Ehrgeiz. Es ist exakt die Menge, die die Certification Tags spiegelt, die ein ITAD auf seiner Sourcing Coverage pflegt — und genau das lässt das Matching-Gate überhaupt funktionieren. Ein Picker mit neunzig Einträgen erzeugt längere Formulare und dieselben sechs Antworten.
Der Security-Schritt
Anderes Thema, eigener Schritt. Zuerst Brand Protection: Asset Tags entfernen, Branding abziehen, diese Maschinen nicht in dieser Region weiterverkaufen — die Fragen, die eine Company stellt, wenn ihr Logo auf einem Second-Hand-Laptop ein größeres Risiko ist als der Laptop. Dann Transportsicherheit: GPS-getrackte Fahrzeuge, versiegelte Container, eine Zwei-Mann-Crew, überprüfte Fahrer. Dann Zugang vor Ort: Abholung außerhalb der Geschäftszeiten, Abholung am Wochenende und ein benannter Security-Kontakt für den Standort, denn die Laderampe um 06:00 gehört jemandem.
Beachten Sie, was hier nicht steht. Die Wahl der Datenvernichtung liegt im Compliance-Schritt, denn sie ist ein Versprechen über die Daten, nicht über den Transporter.
Zwei Listen, kein Mapping
Die Auswahl übersetzt sich nicht je in einen sauberen Code. Die Request trägt zwei Arrays: geforderte Certifications und geforderte Services. Certifications sind Gates — ein ITAD, dessen Coverage nicht jeden geforderten Tag trägt, sieht die Request gar nicht erst. Services sind das, was die Request vom gewinnenden Bieter tatsächlich verlangt, und sie erscheinen auf der Bieterseite in denselben Worten, die der Kunde gewählt hat. Eine Request, zwei Listen, keine Übersetzungsschicht, um die niemand gebeten hat.
Wenn niemand bietet
Eine veröffentlichte Request, die bei null Geboten steht, ohne Award und ohne nachgelagerte Übergabe, kann gelockert werden: eine geforderte Certification streichen oder einen geforderten Service. Die Plattform schlägt vor, welche Auflage im Weg steht, der Kunde wendet eine nach der anderen an, und die Request wird neu veröffentlicht, sodass sie wieder weit oben in der Sourcing Inbox auftaucht — ohne Coverage-Zahlen offenzulegen und ohne irgendetwas darüber, wer nicht geboten hat.
Eine Auflage nach der anderen ist der Punkt. Das hält die Request ehrlich in Bezug auf das, was sie weiterhin verlangt, statt sie still zu einer anderen Request werden zu lassen. Und manchmal lautet die ehrliche Schlussfolgerung, dass WEEELABEX ambitioniert gedacht war.