Wie ein Elektronikdistributor einen Pilot für die Beendigung manueller ERP-Produktsuchen plant

Kann Software den ERP-Produktdatensatz ausfüllen, auf den ein Angebot wartet? Im Wesentlichen ja: Sie kann die Daten des Herstellers finden, sie den Feldern des ERP zuordnen und markieren, was ein Mensch noch prüfen muss. Genau diese Frage stellte uns ein Distributor für Industrieelektronik. Sein Vertriebsteam kann eine RFQ-Position nicht kalkulieren, solange das Produkt nicht im ERP existiert, und für jeden neuen Artikel öffnet jemand die Website des Herstellers und kopiert die Daten Feld für Feld. Automa.Net schlug vor, diese Daten automatisch zu erfassen, wobei die Quelle jedes Werts angezeigt wird, sie den eigenen ERP-Feldern des Distributors zuzuordnen und sie importfertig oder per API bereitzustellen, beginnend mit den Feldern, die ein Angebot blockieren. Das Projekt befindet sich derzeit in der Phase der Abstimmung des Umfangs des Piloten, daher beschreibt dieser Artikel das Problem und den Plan, nicht die Ergebnisse. Es ist der zweite Fall in unserer Serie über Pilotprojekte, nach der Automatisierung von Angeboten aus Rohbestandslisten: Automa.Net ist nicht nur Standardsoftware, wir entwickeln auch rund um den Prozess eines einzelnen Kunden, und wir beginnen mit einem Pilotprojekt.

Der Fall in Kürze:

• Problem: jede RFQ-Position, die noch nicht im ERP vorhanden ist, wartet auf eine manuelle Produktsuche auf der Website des Herstellers.
• Kosten: Angebote werden blockiert, bis ein Produktdatensatz existiert, der Aufwand wächst mit jeder RFQ-Position, es gibt keinen Nachweis darüber, woher die Werte stammen, und Code- oder Markenfehler werden erst spät entdeckt.
• Vorgeschlagene Lösung: automatisierte Anreicherung von Produktdaten aus Herstellerquellen zuerst, zugeordnet zu den ERP-Feldern des Distributors, mit einer Quelle und einem Prüfstatus für jeden Wert.
• Erster Schritt: ein Pilotprojekt, dessen Umfang derzeit definiert wird: Felder, Regeln, Hersteller, Beispiel-RFQs und wie der Erfolg gemessen wird.
• Aktueller Stand: noch keine Ergebnisse, absichtlich.

Was ist Produktdatenanreicherung für ein ERP?

Produktdatenanreicherung für ein ERP bedeutet, einen Produktdatensatz automatisch aus externen Quellen zu füllen, statt ihn von Hand einzugeben: Beschreibungen, Kategorie, Abmessungen, Gewicht, Zoll- und Exportcodes, EAN, Herkunftsland und Lebenszyklusdaten. Für einen Distributor von Industriekomponenten ist die wichtigste Quelle der Hersteller, weil nur die Daten des Herstellers zuverlässig genug für Zoll, Versand und Kundenfragen sind. Gute Anreicherung leistet über das bloße Kopieren von Werten hinaus drei Dinge: Sie wandelt sie in die eigenen Einheiten und Felddefinitionen des ERP um, sie dokumentiert, woher jeder Wert stammt, und sie kennzeichnet Werte, die widersprüchlich oder fehlend sind, damit ein Mensch entscheiden kann.

Das Problem: Kein Produktdatensatz, kein Angebot

Der Distributor verfügt über einen großen Bestand an Industrieelektronik. Dennoch fragen viele RFQs nach Teilen, die er noch nie verkauft hat. In seinem ERP kann ein Preis erst angegeben werden, wenn der Produktdatensatz existiert. Daher durchläuft jede neue RFQ-Position dieselbe manuelle Kette:

1. Die RFQ trifft ein mit einer Liste von Teilenummern.
2. Das Produkt ist nicht im ERP vorhanden.
3. Jemand sucht auf der Website des Herstellers nach dem exakten Teil und der Variante.
4. Die Daten werden Feld für Feld kopiert in das ERP.
5. Der Produktdatensatz wird angelegt, und erst dann kann die Position kalkuliert werden.

Dies erfolgt manuell, ein Produkt nach dem anderen. Bevor ein Produkt angelegt und bepreist werden kann, muss ein Satz obligatorischer Felder vollständig sein: Identifikation und Beschreibungen, Kategorie und Hersteller, der Zollwarencode, Abmessungen, Nettogewicht und Exportkontrollklassifizierung. Weitere Felder wie alternative Codes, EAN, Ursprungsland und Lebenszyklusdaten vervollständigen den Datensatz und können später ergänzt werden. Ein verwandter Leitfaden zu der Überwindung von Datensilos in Fertigungslieferketten erklärt, warum manuell zwischen Systemen kopierte Daten dazu neigen, sich zu verändern.

Was das Problem kostet: Zeit und Fehler

Wir haben die Nachschlagezeit des Distributors noch nicht gemessen; die Einigung darauf, wie sie gemessen wird, ist Teil des Pilotumfangs. Die Kosten sind jedoch schon daran leicht zu erkennen, wie die Arbeit erledigt wird:

• Das Angebot ist blockiert. Ein Kunde, der auf einen Preis wartet, wartet zuerst auf einen Produktdatensatz. Je mehr neue Artikel in einer RFQ sind, desto länger wartet das gesamte Angebot.
• Der Aufwand wächst mit jeder Position. Jeder neue Artikel bedeutet eine weitere Suche, eine weitere zu identifizierende Variante und eine weitere Kopierrunde. Eine lange RFQ vervielfacht das.
• Keine Aufzeichnung darüber, woher ein Wert stammt. Sobald ein Gewicht oder ein Ursprungsland im ERP steht, kann niemand mehr sagen, ob es vom Hersteller, von einem Reseller-Eintrag oder aus einer Schätzung stammt.
• Fehler werden spät entdeckt. RFQ-Positionen enthalten Codes, die zu mehreren Produkten passen, Tipp- oder OCR-Fehler in Teilenummern und Teile, die unter der falschen Marke aufgeführt sind. Werden sie manuell gefunden, tauchen sie erst auf, nachdem der Produktdatensatz bereits existiert oder nachdem das Angebot bereits versendet wurde.
• Einheiten stimmen nicht überein. Hersteller veröffentlichen oft Verpackungsgewicht und -abmessungen, während die Regeln des Distributors produktbezogene Werte in seinen eigenen Einheiten verlangen. Jede Nachschlageaktion bedeutet außerdem eine Umrechnung.

Wie wir es lösen wollen: Herstellerdaten, auf das ERP gemappt

Der Vorschlag ersetzt Einzelabfragen durch einen Batch pro RFQ-Liste: Die gesamte Liste wird eingespielt, und jedes Produkt kommt mit seinen Werten zurück, die auf die ERP-Felder des Distributors gemappt sind.

Herstellerdaten kommen zuerst. Werte werden aus drei Arten von Quellen in fester Reihenfolge übernommen:

1. Die Website des Herstellers. Daten, die direkt vom Hersteller extrahiert und auf die Felder des Distributors gemappt werden. Die Extraktion läuft bereits für 21 Hersteller, darunter Siemens, Allen-Bradley, Schneider Electric, ABB, Omron, Lenze, Phoenix Contact und Pilz, und weitere können auf Basis des RFQ-Volumens hinzugefügt werden.
2. Die Automa.Net-Datenbank, mit Produktdaten zu Teilen von mehr als 9.000 Herstellern, wird nur für Felder oder Produkte verwendet, die die Herstellerquelle nicht abdeckt.
3. Drittanbieterquellen, werden nur für die verbleibenden Lücken verwendet, und nur für diejenigen, die der Distributor akzeptiert, in der von ihm akzeptierten Reihenfolge.

Jeder Wert zeigt seine Quelle und seinen Status. Für jedes Feld zeigt das Ergebnis, woher der Wert stammt und ob er verwendet werden kann: bestätigt, prüfungsbedürftig, Konflikt zwischen Quellen oder fehlt. Wenn Quellen voneinander abweichen, hat der Wert des Herstellers Vorrang und der Konflikt bleibt sichtbar. Einheiten folgen den eigenen Regeln des Distributors, mit einem Hinweis, wenn der Hersteller nur verpackte Werte veröffentlicht.

Werte werden nach den Definitionen des Distributors erfasst, nicht nach dem Format des Herstellers. Alternative Bestellcodes werden nebeneinander gespeichert, sodass mit jedem der Codes das Produkt gefunden wird, und Lebenszyklusdaten werden mit verknüpftem Nachfolger und Vorgänger geliefert, wenn der Hersteller sie veröffentlicht. Unser Leitfaden zu der Nachverfolgung obsoleter Industriebauteile erklärt, warum diese Felder für einen Distributor wichtig sind.

Jedes Produkt wird danach sortiert, was vor der Angebotserstellung noch fehlt:

• Angebotsbereit: alle Felder für Produkterstellung, Angebotserstellung und Versand sind aus akzeptierten Quellen vollständig.
• Prüfungsbedürftig: eine unklare Zuordnung, ein korrigierter Code oder widersprüchliche Werte. Eine Person bestätigt dies, bevor der Datensatz erstellt wird.
• Fehlende Daten: Pflichtfelder, die in keiner vereinbarten Quelle gefunden wurden. Diese gehen zurück in die manuelle Bearbeitung.

Die Ausgabe wird für den Import in das ERP vorbereitet oder über eine API bereitgestellt, je nachdem, ob das Team einzelne Produkte nachschlagen oder ganze RFQ-Listen senden möchte. Dies sind dieselben Produktdaten, die hinter dem Automa.Net Produktdaten-Anreicherungsservicestehen, hier auf die Felddefinitionen eines Unternehmens abgebildet.

Der Pilot als erster Schritt

Der Rollout beginnt mit den Feldern, die die Angebotserstellung blockieren:

• Phase 1, Angebotserstellung freischalten: die Website des Herstellers als einzige Quelle, die Felder für Produkterstellung, Angebotserstellung und Versand sowie die Zuordnung zu den ERP-Feldern und Kategorien des Distributors.
• Phase 2, den Datensatz vervollständigen: die Automa.Net-Datenbank und vereinbarte Drittquellen, die verbleibenden Anreicherungsfelder und zusätzliche Prüfungen, wenn die Herstellerdaten nicht mehr ausreichen.

Bevor irgendetwas davon umgesetzt wird, braucht der Pilot fünf Entscheidungen, und genau diese stimmen wir jetzt mit dem Distributor ab:

1. Die Feldzuordnung: Produktkategorien, Einheiten und Lebenszyklusdefinitionen.
2. Regeln für unvollständige Herstellerdatenzum Beispiel wenn nur verpacktes Gewicht oder verpackte Abmessungen veröffentlicht werden.
3. Hersteller, Beispiel-RFQs und Datenmit einer bewussten Mischung aus sauberen Codes, alternativen Codes und problematischen Einträgen, damit der Pilot die schwierigen Fälle testet und nicht nur die einfachen.
4. Drittquellen für die verbleibenden Lücken: welche der Distributor akzeptiert und in welcher Reihenfolge.
5. Wie der Pilot gemessen wirdzum Beispiel eingesparte Suchzeit pro RFQ-Zeile.

Die aktuelle Phase

Das Projekt befindet sich in der Scoping-Phase. Wir haben dem Distributor gezeigt, wie die Daten erfasst, bezogen und sortiert würden, und wir stimmen die Feldzuordnung, die Regeln und die Pilotstichprobe ab. Wir werden keine Zahlen veröffentlichen, bis der Pilot mit den realen RFQs des Distributors gelaufen ist und so gemessen wurde, wie beide Seiten es vereinbart haben. Über die Ergebnisse berichten wir in einem Follow-up.

Sprechen Sie mit uns über einen Pilot mit Ihren eigenen Daten

Ein Pilot wie dieser ist sinnvoll, wenn Produktdatensätze der Engpass zwischen einer RFQ und einem Angebot sind:

• Mit jeder RFQ kommen neue Artikel hinzu, und jeder einzelne benötigt einen Produktdatensatz, bevor er bepreist werden kann.
• Ihr ERP hat eigene Felddefinitionen, Einheiten und Kategorien, die Herstellerdaten nicht eins zu eins abbilden.
• Sie müssen wissen, woher jeder Wert stammt, für den Zoll, die Exportkontrolle oder Kundenfragen.
• Ihr RFQ-Prozess hat bereits eine feste Struktur. Unser Leitfaden zu wie man den RFQ-Prozess für Teile optimiert beschreibt die Schritte, an denen Daten normalerweise hängen bleiben.

Der erste Schritt ist ein Gespräch, kein Vertrag. Senden Sie uns eine Stichprobe echter RFQ-Positionen und Ihre ERP-Feldliste, und wir zeigen Ihnen, welche Felder aus Herstellerquellen befüllt werden können, welche geprüft werden müssen und welche fehlen, bevor überhaupt etwas gebaut wird. Kontaktieren Sie das Automa.Net-Team , um über einen Pilot zu sprechen.

Häufig gestellte Fragen

Kann Software Produktsuchen für elektronische RFQs automatisieren?

Im Wesentlichen ja. Software kann jede RFQ-Position dem Produkt des Herstellers zuordnen, die vom ERP benötigten Daten extrahieren und sie den richtigen Feldern zuweisen. Positionen mit unklaren Codes, Tippfehlern oder widersprüchlichen Quellen müssen dennoch von einer Person bestätigt werden, daher sortiert ein gutes Setup Produkte in bereit zur Angebotserstellung, prüfungsbedürftig und fehlende Daten, statt zu raten.

Welche Produktdaten benötigt ein ERP vor einem Angebot?

Typischerweise einen Code, Beschreibungen, Kategorie, Hersteller und Zolltarifnummer, um den Artikel anzulegen, sowie Abmessungen, Nettogewicht und Exportkontrollklassifizierung, um ihn zu bepreisen und zu versenden. EAN, Ursprungsland, Lebenszyklusphase, Nachfolger und Vorgänger vervollständigen den Datensatz und können später ergänzt werden.

Woher stammen angereicherte Produktdaten?

Zuerst von der Website des Herstellers. Die Automa.Net-Datenbank füllt Felder oder Produkte, die der Hersteller nicht abdeckt, und vereinbarte Drittquellen ergänzen nur das, was dann noch fehlt. Jeder Wert trägt seine Quelle, und wenn Quellen widersprechen, hat der Wert des Herstellers Vorrang, während der Konflikt sichtbar bleibt.

Was passiert, wenn der Hersteller unvollständige Daten veröffentlicht?

Der Pilot legt dafür im Voraus eine Regel fest. Ein häufiger Fall ist ein Hersteller, der nur Verpackungsgewicht und -abmessungen veröffentlicht, während das ERP produktbezogene Werte benötigt: Der Wert wird markiert, statt so eingetragen zu werden, als wäre er korrekt. Pflichtfelder, für die keine vereinbarte Quelle vorhanden ist, gehen zurück in die manuelle Bearbeitung.

Können angereicherte Daten ohne doppelte Dateneingabe ins ERP übernommen werden?

Ja. Die Daten werden auf die eigenen Felder des ERP abgebildet und als Importdatei oder über eine API bereitgestellt, sodass niemand sie erneut eingeben muss. Ob das Team ganze RFQ-Listen in einem Batch sendet oder einzelne Produkte über die API nachschlägt, gehört zu den Entscheidungen, die während des Piloten getroffen werden.

Was sind ECCN und die statistische Nummer in einem Produktdatensatz?

ECCN, die Export Control Classification Number, gibt an, ob ein Produkt unter Exportkontrollen fällt und welche; sie wird benötigt, bevor bestimmte Produkte ins Ausland versendet werden können. Die statistische Nummer ist der Zollwarencode, aufgebaut auf dem internationalen HS-Code und durch die EU, das Vereinigte Königreich oder die USA zu ihren eigenen nationalen Codes erweitert. Beide sind Felder, von denen ein Angebot oder eine Sendung abhängen kann, und Hersteller veröffentlichen sie nicht immer, weshalb jeder Wert seine Quelle trägt.

Wie misst man einen Data-Enrichment-Pilot?

Beide Seiten legen die Kennzahl vor Beginn des Piloten fest, zum Beispiel die pro RFQ-Zeile eingesparte Suchzeit, den Anteil der Produkte, die bereit zur Angebotserstellung zurückkommen, und den Anteil, der überprüft werden muss. Die Stichprobe sollte saubere Codes, alternative Codes und problematische Einträge mischen, damit das Ergebnis reale RFQs widerspiegelt.