Der Scanner-Tausch: 25 % weniger Stückkosten

Auf einen Blick

Ausgangslage

Das Produkt funktionierte. Die Zutrittsterminals („Pods“) standen in Fitnessstudios, scannten QR-Codes und öffneten Türen.

Darunter war die Struktur in drei Punkten improvisiert, die das Team von innen nicht sehen konnte:

• Der QR-Code-Scanner, nach der Rechenplatine das teuerste Einzelbauteil der Stückliste, wurde über einen einmaligen Direktkauf bei einem europäischen Einzelhändler zu 33,61 € pro Stück beschafft. In der Stückliste stand dazu „immer begrenzte Verfügbarkeit“. Kein zweiter Lieferant. Keine Beziehung zum Hersteller. Der Preis war ein Einzelhandelspreis.
• Die Integration eines anderen, günstigeren Scanners stand bereits auf der Roadmap, und der Kostenvoranschlag des bestehenden Software-Dienstleisters lag vor. Die Zahl war hoch genug, um die Entscheidung zu blockieren, und niemand hatte die Annahmen dahinter hinterfragt.
• Der bestehende Scanner-Treiber, eine einzelne Python-Datei mit 1.266 Zeilen, war eng auf ein bestimmtes Herstellerprotokoll zugeschnitten. Von außen sah es so aus, als würde ein Scanner-Tausch bedeuten, alles neu zu schreiben.

Drei Gespräche, drei Gesprächspartner und niemand mit dem Auftrag, zu prüfen, ob die Annahmen zusammenpassen.

Der Hardware-Pfad

Das Audit begann mit der Stückliste und der Frage: Was würde es kosten, wenn der aktuelle Lieferant diesen Scanner nächsten Monat nicht mehr liefern könnte?

Der Weg zur Antwort:

• Quelle identifiziert. Die Einzel-SKU war eine umgelabelte NFC- und 2D-Scan-Engine eines OEMs aus Guangzhou. Der Weg von der Fabrik zur Wand im Fitnessstudio lautete: Fabrik → europäischer Importeur → europäisches Einzelhandelsangebot → Stückliste. Zwei Zwischenhändler, voller Einzelhandelsaufschlag, kein Mengenrabatt, keine verbindliche Lieferzeit.
• Shortlist erstellt. Fünfzehn Kandidatenlieferanten geprüft, verteilt auf zwei Scanner-Familien: die des bisherigen Scanners und eine vergleichbare Alternative. Preise, Mindestbestellmengen, monatliche Kapazität, Lieferzeiten, OEM- oder Händler-Status und Qualität der technischen Dokumentation auf Chinesisch: alles aus erster Hand geprüft.
• Direktkontakt zum OEM hergestellt. Gespräche mit dem eigentlichen Hersteller, auf Mandarin und ohne Vermittler. Ab 100 Stück lag der Preis direkt beim OEM bei rund 25 € gegenüber 33,61 € im Einzelhandel.

Nettoeffekt: rund 25 % niedrigere Beschaffungskosten, deutlich bessere Lieferverfügbarkeit und eine direkte OEM-Beziehung, ausgelegt auf Skalierung über 100 Pods hinaus ohne Nachverhandlung.

Der Software-Pfad

Der ursprüngliche Kostenvoranschlag beruhte auf einer einzigen unausgesprochenen Annahme: Die Integration des neuen Scanners bedeute, den bestehenden Treiber zu portieren. Gleiches Protokoll, neue Bytes.

Der Abgleich des bestehenden Treibers (1.266 Zeilen) mit dem 105-seitigen Herstellerhandbuch des neuen Scanners ergab ein anderes Bild.

Der neue Scanner spricht das alte Protokoll überhaupt nicht. Er wird nicht über Registerbefehle auf der seriellen Leitung konfiguriert, sondern indem man eine gedruckte Seite mit Setup-Barcodes scannt: Schnittstelle, Baudrate, Präfix/Suffix, NFC ein/aus, alles. Es gibt keinen Befehlssatz vom Host zum Scanner. Es gibt nichts zu portieren.

Für die Codebasis heißt das:

Rund 80 % des bestehenden Treibers konnten gelöscht werden, statt sie zu portieren. Die verbleibende Arbeit ist überschaubar: ein serieller Frame-Parser, eine Code-ID-Lookup-Tabelle und ein einseitiges gedrucktes Setup-Verfahren für die Installation.

Realistische Kosten für den vollständigen Tausch, einschließlich Bereinigung der Softwarearchitektur und Rollout: 6.000 bis 12.000 € bei einem Offshore-Dienstleister, 10.000 bis 16.000 € bei einem europäischen Freelancer. Die Differenz zum ursprünglichen Kostenvoranschlag ist keine Preisfrage, sondern eine strukturelle. Scanner-Integrationen erfordern fast immer das Portieren eines Herstellerprotokolls; diese hier nicht. Diese Tatsache stand aber in einem einzigen Absatz des Herstellerhandbuchs. Um zu erkennen, dass die Arbeit zu 80 % aus Löschen und nicht aus Portieren bestand, mussten Handbuch und Treiber in derselben Woche gelesen werden. Dafür wird ein externer Dienstleister, der nach einer schriftlichen Spezifikation arbeitet, normalerweise nicht bezahlt.

Warum es nicht früher erkannt wurde

Das ist der Teil des Falls, der sich verallgemeinern lässt.

Die Entscheidung über die Hardware-Beschaffung und die Vergabe der Software gehörten zu verschiedenen Gesprächen mit verschiedenen Gesprächspartnern. Keine Seite hatte einen Anreiz, die Annahmen der anderen zu hinterfragen. Der Lieferant sah eine Bestellung. Der Dienstleister sah eine Spezifikation.

Die eine Tatsache, an der der ursprüngliche Kostenvoranschlag scheiterte, stand in einem Absatz auf Seite 14 des Herstellerhandbuchs, in dichtem technischem Englisch neben einem Diagramm: Dieser Scanner wird per Barcode konfiguriert, nicht per Protokoll. Es war schlicht niemandes Aufgabe, das zu lesen.

Fast jedes Hardware-Unternehmen kennt eine Variante dieses Problems. Die strukturellen Kosten entstehen dort, wo zwei Ebenen aufeinandertreffen und niemand für die Schnittstelle verantwortlich ist.

Was das Audit aufgedeckt hat

Was die Arbeit möglich machte

• Fließendes Mandarin. Produktseite, Datenblätter und Preislisten des OEMs wurden im chinesischen Original gelesen, ohne Übersetzungsverluste und ohne Händler dazwischen. Die Beziehung wurde in der Sprache des OEMs aufgebaut.
• Technische Analyse. Codebasis und Herstellerhandbuch nebeneinander lesen und erkennen, was tatsächlich an den Hersteller gekoppelt und was wiederverwendbar war. Nicht theoretisch, sondern Zeile für Zeile.
• Blick über Abteilungsgrenzen. Beschaffung und Software arbeiten in den meisten Unternehmen getrennt. Sie gehören an einen Tisch. Die 20.000 € Einsparung ergaben sich erst dadurch, dass jemand beide Seiten zusammen betrachtete.

Ergebnis

• Hardware-Stückkosten um rund 25 % gesunken, Lieferverfügbarkeit bei steigenden Stückzahlen gesichert.
• Rund 20.000 € in einem einzigen Software-Workstream eingespart. Das Unternehmen hat jetzt einen klar definierten Umfang, auf dessen Grundlage es verhandeln kann.
• Eine saubere Abstraktionsschicht in der Codebasis, sodass der nächste Scanner-Tausch (oder NFC-Leser oder jedes seriell angeschlossene Peripheriegerät) deutlich einfacher ist.

Der Nutzen für den Auftraggeber lag deutlich über dem Audit-Honorar.

Wie solche Fälle typischerweise aussehen

Auch in Ihrem Produkt gibt es wahrscheinlich eine Variante davon. Sie findet sich typischerweise an einer von drei Stellen:

1. Eine Komponente, die einzeln oder über einen Zwischenhändler bezogen wird, weil das beim ersten Prototyp so gemacht und nie neu bewertet wurde.

2. Ein Arbeitsumfang, der auf einer falschen Annahme beruht, weil niemand den Überblick über beide Ebenen hat, um das zu erkennen.

3. Eine fehlende Abstraktionsschicht, durch die herstellerspezifischer Code in die Geschäftslogik eingedrungen ist. Ein Lieferantenwechsel fühlt sich dann an wie eine Neuentwicklung des Produkts.

Ein BOM-Audit reicht in der Regel aus, um diese Punkte sichtbar zu machen. Das Ergebnis ist eine Liste aller konkreten Abhängigkeiten, samt den Kosten, jede einzelne aufzulösen.