Produktdatenblätter automatisch erstellen und aktualisieren

Das echte Ausmaß des Problems

Ein technisches Datenblatt — im Englischen Technical Data Sheet, kurz TDS — ist das meistgenutzte Dokument in der B2B-Chemie. Es beschreibt, was ein Produkt kann: Viskosität, pH-Wert, Löslichkeit, Anwendungstemperatur, Verarbeitungshinweise, Lagerbedingungen. Kunden brauchen es für Freigabeprozesse, Qualitätssicherung und Einkaufsentscheidungen. Es ist nicht regulatorisch vorgeschrieben wie das Sicherheitsdatenblatt — das bedeutet: Die Form ist frei, der Inhalt ist Verantwortung des Herstellers.

Genau das ist das Problem.

Ein mittelständischer Spezialchemiker mit 80 Produkten pflegt typischerweise 120–200 TDS-Versionen gleichzeitig — unterschiedliche Produktvarianten, unterschiedliche Sprachen, unterschiedliche Kundenformate. Nach jeder Rezepturänderung, jedem Rohstoffwechsel oder jeder Chargenüberprüfung müssen betroffene Datenblätter aktualisiert werden. Wer das manuell macht, verbringt bei einer Vollzeitkraft mit 2–4 Stunden je Datenblatt und 12–15 Aktualisierungszyklen pro Jahr leicht 300–500 Stunden jährlich allein mit TDS-Pflege — das entspricht rund zwei Personenmonaten.

Hinzu kommen strukturelle Fehlerquellen:

• Versionskonfusion: Außendienst, Onlineshop, Kundenportal und gedruckte Broschüre zeigen unterschiedliche Stände. Wer welche Version hat, lässt sich kaum nachverfolgen.
• Übersetzungsrückstände: Das deutsche TDS wird aktualisiert, die englische und französische Version folgen Wochen später — oder gar nicht, weil die Änderung „zu klein” erscheint.
• Copy-Paste-Fehler: Werte werden zwischen Dokumenten übertragen und dabei minimal verändert — eine nachgestellte Dezimalstelle, eine fehlende Einheit, ein falsch kopierter Normverweis.

Die Compliance-Lage ist dabei nicht zu unterschätzen: Für Sicherheitsdatenblätter dokumentieren Enforcement-Daten, dass bei EU-weiten Kontrollen rund 35 Prozent der überprüften Dokumente Mängel aufweisen (CloudSDS, 2024). Bei technischen Datenblättern, die nicht demselben Prüfregime unterliegen, ist der Zustand erfahrungsgemäß nicht besser.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Zeitangaben für die manuelle Erstellung entsprechen Erfahrungswerten aus Projekten mit mittelständischen Chemieunternehmen. Die Automatisierungseffekte orientieren sich an Chemius-Kundendaten (2024/2025): Bei einem automotive Großkunden der Plattform wurde eine 90-prozentige Reduktion der SDB-Erstellungszeit dokumentiert.

Einschätzung auf einen Blick

Zeitersparnis — sehr hoch (5/5) Kein anderer Anwendungsfall in der Chemie-Branche reduziert direkten manuellen Aufwand so messbar wie die TDS-Automatisierung. Eine Rezeptur­update-Runde, die früher drei bis sechs Personentage beansprucht hat, dauert nach der Einführung ein paar Stunden. Der Effekt tritt sofort ein und lässt sich exakt beziffern: Du weißt, wie viele TDS du pflegst, und kannst die eingesparte Zeit direkt in Minuten umrechnen.

Kosteneinsparung — mittel (3/5) Die Softwarekosten sind real: Chemius kostet ab 350 €/Monat für das TDS-Add-on, die ERP-Integration bringt einmaligen Aufwand mit sich. Die Einsparungen entstehen indirekt — durch eingesparte Arbeitszeit und reduzierte externe Übersetzungskosten. Bei kleinen Portfolios (unter 30 Produkten) ist der Aufwand der Einrichtung kaum durch die Einsparung gedeckt. Mittelfeldposition: real, aber nicht der dominante wirtschaftliche Hebel.

Schnelle Umsetzung — mittel (3/5) Ein funktionierender Proof of Concept mit Template und LLM-Unterstützung ist in zwei bis drei Wochen machbar — ohne ERP-Anbindung. Die vollständige Integration mit automatischer Datenübergabe aus dem ERP- oder LIMS-System dauert realistisch sechs bis zehn Wochen. Wer auf ERP-Integration verzichtet und die Daten zunächst manuell einpflegt, kann früher starten. Weder besonders schnell noch besonders komplex.

ROI-Sicherheit — hoch (4/5) Die Zeitersparnis ist direkt messbar — das ist im Vergleich zu vielen anderen KI-Anwendungsfällen ein klarer Vorteil. Der ROI hängt stark von der Portfoliogröße ab: Ab etwa 30 aktiven Produkten mit regelmäßigen Aktualisierungen rechnet sich die Investition binnen eines Jahres. Für kleinere Portfolios ist die Rechnung weniger eindeutig. Nicht maximal bewertet, weil der ROI für kleine Portfolios unsicher bleibt.

Skalierbarkeit — sehr hoch (5/5) Das Skalierungsprinzip ist ideal: Einmal ein Template gebaut, kostet jedes neue Produkt nahezu nichts zusätzlich. Wer heute 80 Produkte hat und in drei Jahren 150, hat keinen proportional steigenden TDS-Pflegeaufwand mehr. Das unterscheidet diese Automatisierung fundamental vom manuellen Prozess.

Richtwerte — stark abhängig von Portfoliogröße, ERP-Systemlandschaft und Übersetzungsbedarf.

Was das System konkret macht

Das Grundprinzip ist ein kontrollierter Datenpipeline: Strukturierte Produktdaten gehen rein, formatierte Datenblätter kommen raus. Was genau passiert, hängt vom gewählten Werkzeug ab — aber der Ablauf ist in allen Varianten ähnlich:

1. Datenquelle: Die Produktspezifikation liegt in einem System: ERP (typisch SAP oder Navision), LIMS, einer PIM-Plattform oder — häufiger als man denkt — in einer gepflegten Excel-Tabelle. Das ist der Input.

2. Template-Logik: Ein Datenblatt-Template legt fest, welche Felder an welcher Stelle erscheinen, in welchem Format, mit welcher Einheit. Wenn die Dichte immer in g/cm³ mit einer Nachkommastelle angegeben wird, steht das einmal in der Template-Logik — nicht in 200 einzelnen Dateien.

3. Generierung: Das System überträgt die Produktdaten automatisch in das Template und erzeugt ein PDF. Bei Text­elementen (Anwendungsempfehlungen, Sicherheitshinweise) kann ein LLM hinzugezogen werden, um konsistente Formulierungen zu erzeugen oder kurze Freitextabschnitte stilistisch anzupassen — mit klarer menschlicher Prüfpflicht für diese Passagen.

4. Mehrsprachige Ausgabe: Zahlenwerte werden direkt aus der Datenbasis übernommen (keine Übersetzung nötig). Textpassagen werden über eine KI-Übersetzung vorübersetzt, dann von internen Fachkräften oder einem Übersetzer geprüft. Translation-Memory-Systeme sorgen dafür, dass unveränderte Passagen nicht erneut übersetzt werden müssen.

5. Verteilung: Das fertige PDF landet automatisch im Kundenportal, dem ERP-System oder wird per API an externe Plattformen übermittelt. Wer das Datenblatt ändert, ändert es einmal — alle Verteiler bekommen die aktuelle Version.

Ein wichtiger technischer Punkt: TDS-Automatisierung ist kein KI-Problem, sondern vor allem ein Datensauberkeits-Problem. Ein LLM kann aus der Angabe „Dichte ca. 1,2 g/cm³ (je nach Charge)” kein präzises Datenblatt erzeugen. Die Qualität des Outputs ist direkt proportional zur Qualität und Struktur der Eingangsdaten.

Mehrsprachigkeit: wie das System Sprachvarianten verwaltet

Ein TDS in fünf Sprachen zu pflegen ist keine Seltenheit — wer in DE, EN, FR, PL und NL verkauft, hat allein für ein Produkt fünf Dateien. Das klingt nach Übersetzungsmanagement, ist aber in der Praxis ein Versions­kontrollproblem.

Das Kernproblem: Wenn das deutsche TDS aktualisiert wird, wann und wie werden die anderen Sprachversionen informiert? Wer trägt Verantwortung? Beim manuellen Prozess ist die Antwort meistens: niemand systematisch.

Automatisierte Systeme lösen das durch zwei Ansätze:

Sprachversions-Kopplung: Alle Sprachversionen eines Produktdatenblatts werden im System als Varianten desselben Datensatzes geführt. Wenn sich ein Wert ändert, wird der Änderungsstatus für alle Sprachversionen gesetzt — entweder automatisch aktualisiert (bei reinen Zahlenwerten, die keine Übersetzung brauchen) oder als “Übersetzung erforderlich” markiert (bei Textpassagen). Kein Sprachstand kann unbemerkt veralten.

Translation-Memory und KI-Vorübersetzung: Platforms wie Chemius und CCMS-Systeme wie SCHEMA ST4 nutzen Translation-Memory-Datenbanken: bereits übersetzte Passagen werden wiederverwendet, nur geänderte Abschnitte werden neu übersetzt. Ein TDS mit 80 % unveränderter Basis kostet nach der Erstübersetzung kaum noch Übersetzungsaufwand.

Kritischer Punkt für den Praxisbetrieb: Wer ist verantwortlich für die inhaltliche Prüfung jeder Sprachversion? Die KI-Übersetzung liefert einen guten Rohtext, aber technische Fachtermini — Viskositätsmethoden, Normbezeichnungen, Verarbeitungshinweise — brauchen Prüfung durch eine fachkundige Person in der jeweiligen Sprache. Das ist kein technisches, sondern ein organisatorisches Problem: Welche Funktion im Unternehmen hat diese Kompetenz und die Zeit dafür?

Integration-Realität: Wo die eigentliche Arbeit steckt

Die TDS-Generierung selbst ist die einfache Hälfte. Die anspruchsvolle Hälfte ist die Frage, wo die Produktdaten herkommen — und in welchem Zustand sie sind.

In der Praxis sieht die Datenlandschaft mittelständischer Chemiebetriebe oft so aus:

• Technische Spezifikationen im ERP (SAP, Navision) — manchmal vollständig, manchmal mit Lücken
• Messdaten aus dem Labor im LIMS — gut strukturiert, aber oft nicht automatisch mit dem ERP synchronisiert
• Anwendungsempfehlungen in Word-Dokumenten, die seit Jahren nicht systematisch gepflegt werden
• Kundenspezifische Anpassungen in lokalen Excel-Dateien beim zuständigen Produktmanager

Das ergibt drei realistische Integrationspfade:

Pfad 1 — Manuell befüllte Templates (schnellster Start): Daten werden initial einmalig in das TDS-System eingepflegt, danach manuell aktualisiert. Kein ERP-Anschluss. Aufwand für die erste Einrichtung: zwei bis vier Wochen. Erster Nutzen sofort sichtbar. Geeignet für kleinere Teams, die schnell aus dem Word-Chaos herauswollen.

Pfad 2 — ERP-Anbindung per API: Produktdaten werden direkt aus SAP oder Navision per Schnittstelle gezogen und automatisch in TDS-Templates befüllt. Änderungen im ERP propagieren automatisch. Aufwand für Einrichtung: vier bis acht Wochen, je nach ERP-System und Datensauberkeit. Das ist der Standard für mittlere und größere Portfolios.

Pfad 3 — LIMS-Kopplung für Messwerte: Laborgemessene Werte (Viskosität, Dichte, pH) kommen direkt aus dem LIMS, statische Spezifikationen aus dem ERP. Komplexester Ansatz, aber der einzige, der verhindert, dass Messwerte noch einmal manuell übertragen werden müssen. Einrichtungsaufwand: sechs bis zwölf Wochen, inklusive Datenvalidierung.

Was die Integration wirklich aufhält: Nicht die Technik, sondern schlechte Stammdaten. Wenn ein Produkt im ERP unter drei verschiedenen Nummern läuft, fehlende Pflichtfelder hat oder die Einheiten inkonsistent erfasst sind, kann keine Automatisierung ein sauberes Datenblatt ausgeben. Vor dem TDS-Projekt steht die Stammdaten-Hygiene. Wer das unterschätzt, verlängert das Projekt um Monate.

Konkrete Werkzeuge — was wann passt

Chemius — der direkte Einstieg für Chemieunternehmen Die einzige Plattform auf dem Markt, die SDB-Authoring und TDS-Erstellung in einem Werkzeug kombiniert und dezidiert für die chemische Industrie gebaut wurde. TDS-Modul ab 200 €/Monat als Add-on (Pro Flex ab 150 €/Monat Basispreis). Mehrsprachige PDF-Ausgabe, API für ERP-Anbindung, GHS/CLP-Vorlagen. Kostenloser Einstieg mit dem Basic-Plan. Ideal für Unternehmen mit 30–500 Produkten, die TDS und SDB aus einem System heraus verwalten wollen.

AX Semantics — für große Portfolios mit strukturierten ERP-Daten Die deutsche NLG-Plattform aus Stuttgart, die Texte aus strukturierten Daten im großen Maßstab generiert. Stärke: konsistente Textgenerierung aus Datenbankfeldern, 110+ Sprachen, Translation-Memory, EU-Hosting. Geeignet für Unternehmen mit Hunderten von Produkten, bei denen Textpassagen (nicht nur Zahlenwerte) automatisch formuliert werden sollen. Einstieg ab ca. 500 €/Monat, aber der Nutzen rechtfertigt sich erst ab größerem Volumen. Kein Self-Service — Onboarding per Demo.

SCHEMA ST4 — für Unternehmen mit technischer Redaktionsabteilung Das Enterprise-CCMS für Maschinenbau und Chemieanlagen. Wenn TDS ein Teil eines größeren Dokumentationsbedarfs ist (Betriebsanleitungen, Sicherheitsanweisungen, CE-Dokumentation), ist SCHEMA ST4 das System, das alles in einem Pool verwaltet. Hohe Einstiegshürde (ab 2.000 €/Monat, 3–6 Monate Implementierung), aber unschlagbar für große variantenreiche Portfolios. Für reine TDS-Automatisierung überdimensioniert.

Make.com + LLM als Custom-Lösung Für technisch versierte Teams ohne Budget für spezialisierte Plattformen: ERP-Daten per API ziehen, in ein Datenblatt-Template einsetzen, Textsektionen per LLM (ChatGPT, Claude) formulieren, PDF generieren. Make.com verbindet die einzelnen Schritte ohne Code. Kostengünstigster Ansatz (Make.com ab 9 €/Monat, LLM-API-Kosten minimal), aber Template-Design und -Pflege bleibt manuelle Aufgabe. Geeignet für Teams mit 20–50 Produkten, die einen schnellen Start ohne großes Budget wollen.

DeepL — für die Übersetzungsschicht In Kombination mit jeder der obigen Lösungen: DeepL API übersetzt technische Textpassagen qualitativ besser als allgemeine LLMs bei chemischem Fachvokabular. DeepL API-Pro ab 5,49 €/Monat. Sinnvoll für alle, die TDS-Textpassagen automatisch vorübersetzen lassen wollen.

Zusammenfassung: Wann welcher Ansatz

• 30–300 Produkte, TDS + SDB aus einem System → Chemius
• 300+ Produkte, hoher Textanteil, großes Volumen → AX Semantics
• Breites Dokumentationsportfolio, Enterprise-CCMS-Bedarf → SCHEMA ST4
• Klein, technisch, Budget-bewusst → Make.com + LLM
• Mehrsprachigkeit als Zusatzbaustein in jeder Lösung → DeepL API

Datenschutz und Datenhaltung

Produktdatenblätter enthalten in der Regel keine personenbezogenen Daten — die DSGVO-Relevanz ist daher geringer als bei anderen KI-Anwendungen. Trotzdem gibt es zwei Punkte, die du im Blick haben solltest:

Rezeptur- und Formulierungsgeheimnis: TDS zeigen Produkteigenschaften, keine Rezepturen — das ist der Punkt. Wenn die TDS-Plattform jedoch direkt an euer Formulierungsdatenbank oder LIMS angebunden ist, fließen bei der Integration auch interne Produktdaten durch den Anbieter. Das kann Rezepturbausteine oder proprietäre Prüfmethoden enthalten. Hier gilt: Wählt eine Plattform mit expliziter Erklärung, dass Kundendaten nicht für Modelltraining verwendet werden.

EU-Hosting und Datensouveränität: Für Firmendaten im Chemiebereich empfiehlt sich EU-Hosting. Chemius hostet in der EU, AX Semantics betreibt Server in Deutschland. Für Make.com mit externem LLM-API: Daten gehen durch US-Server — für nicht sensible TDS-Daten (Viskosität, pH, Lagerbedingungen) in der Regel akzeptabel, für sensiblere Formulierungsdaten kritisch prüfen.

Auftragsverarbeitungsvertrag (AVV): Soweit die Plattform TDS-Daten im Auftrag verarbeitet, ist ein AVV nach Art. 28 DSGVO erforderlich, auch wenn keine Personendaten betroffen sind — da die Produktdaten Geschäftsgeheimnisse darstellen können. Chemius und AX Semantics bieten AVV an; für Custom-Setups (Make.com + LLM-API) musst du dies mit jedem Anbieter einzeln regeln.

Was es kostet — realistisch gerechnet

Softwarekosten (monatlich)

• Chemius Pro Flex + TDS-Add-on: 350 €/Monat (5 Nutzer, 200 €/Monat TDS-Modul enthalten)
• Chemius Pro Bundle + TDS: 1.200 €/Monat (10 Nutzer, umfangreichere API)
• AX Semantics: ab 500 €/Monat, Einführungskosten zusätzlich
• SCHEMA ST4: ab 2.000 €/Monat, 3–6 Monate Implementierung
• Make.com + DeepL API + LLM: 20–80 €/Monat Software (plus internem Template-Aufwand)
• Quelle: Anbieter-Preislisten Stand Mai 2026 (chemius.net)

Einmalige Einrichtungskosten

• Template-Design und -Test: 2–5 Tage intern oder 1.500–4.000 € extern
• ERP-Anbindung: 3.000–8.000 € Entwickleraufwand je nach ERP-System und Datensauberkeit
• Stammdaten-Bereinigung im ERP: 1–4 Wochen interner Aufwand — dieser Posten wird regelmäßig unterschätzt

Wie du den Nutzen misst Zähle, wie viele TDS du pro Jahr aktualisierst (nicht erstellst — Aktualisierungen dominieren den Aufwand). Multipliziere mit dem bisherigen Stundensatz. Setze dem die Software- und Integrationskosten gegenüber. Das ist keine Prognose, sondern eine direkt nachprüfbare Rechnung.

Konservatives Beispiel: 60 Produkte × 3 Aktualisierungen/Jahr × 3 Std./TDS (3 Sprachen) = 540 Stunden. Bei 35 €/Stunde: 18.900 € Pflegeaufwand pro Jahr. Mit Automatisierung: 540 Stunden × 80 % Einsparung = 432 Stunden eingespart = rund 15.100 € jährlich. Gegen Software- und Einrichtungskosten von ca. 6.000 € im ersten Jahr ergibt sich ein positiver ROI bereits im Jahr eins. Diese Rechnung gilt für Portfolios ab ca. 40 aktiven Produkten mit regelmäßigem Änderungsbedarf.

Drei typische Einstiegsfehler

1. Das Template-Design wird unterschätzt. Ein TDS-Template klingt simpel — eine Tabelle mit Feldern. In der Praxis steckt darin die gesamte inhaltliche Logik: Welche Felder sind Pflicht, welche optional? Was passiert, wenn ein Messwert fehlt? Wie werden Wertebereiche dargestellt? Was unterscheidet das Template für den deutschen Markt von dem für den Export? Diese Fragen nicht vorab zu klären bedeutet: Das Template muss nach dem ersten Testlauf grundlegend überarbeitet werden, was das Projekt verzögert und frustriert.

2. Die Stammdaten werden nicht überprüft, bevor das System gestartet wird. Wenn Produktdaten im ERP lückenhaft, inkonsistent oder doppelt erfasst sind, gibt die Automatisierung lückenhafte, inkonsistente Datenblätter aus. Kein LLM und keine Plattform kann schlechte Eingangsdaten reparieren. Wer das übersieht, bekommt nach drei Wochen Einführung das Feedback: „Die Datenblätter sind schlechter als vorher.” Der Fehler liegt nicht in der Software, sondern in den Ausgangsdaten — aber die Erkenntnis kommt spät.

3. Das System wird eingeführt, aber der Update-Prozess wird nicht definiert. Das gefährlichste Szenario: Die TDS-Automatisierung läuft, aber wer ist verantwortlich, wenn sich eine Spezifikation ändert? Trägt das ERP-Team die Änderung ein? Der Produktmanager? Das Labor? Wenn diese Frage nicht klar beantwortet ist, entstehen nach 12 Monaten wieder veraltete Datenblätter — nur jetzt mit mehr Tempo, weil das System alle Versionen gleichzeitig falsch stellt. Ein automatisiertes System braucht genauso einen definierten Pflegeprozess wie ein manuelles — nur an anderen Stellen. Wer diese Frage nicht vor dem Launch klärt, kauft sich eine schnellere Version des alten Problems.

4. Nur die Erstellungszeit wird gemessen, nicht die Qualitätsverbesserung. TDS-Automatisierung reduziert nicht nur Zeit, sondern auch Fehler. Copy-Paste-Fehler, falsche Einheitenangaben, vergessene Normaktualisierungen — diese Fehler kosten Kundenvertrauen und im Extremfall die Haftung. Wer den Nutzen nur in Stunden misst, unterschätzt den strategischen Wert der Fehlerreduktion und gibt bei der internen Budgetdiskussion schlechtere Argumente.

Was mit der Einführung wirklich passiert — und was nicht

Die Technik funktioniert schneller als erwartet. Die Widerstände kommen aus einer anderen Richtung.

Das Qualitätsbewusstsein schlägt zurück. Wenn das erste automatisch generierte Datenblatt im Team angeschaut wird, finden Produktmanager und Produktionsleitung mit einemmal Dinge, die sie vorher nie bemerkt haben: eine Formulierung, die immer leicht unscharf war, eine Norm, die als veraltet gilt, ein Wert, der schon lange ungeklärt ist. Das ist kein Systemfehler — das ist ein Spiegel. Plane Zeit ein, diese Erkenntnisse aufzunehmen, ohne das Projekt damit zu blockieren. Nicht alles muss perfekt sein, bevor das erste TDS ausgeliefert wird.

Die Eigentümerschaft für Produktdaten wird plötzlich sichtbar. Wenn eine Automatisierung TDS direkt aus dem ERP befüllt, stellt sich die Frage, wer für die Qualität der ERP-Daten verantwortlich ist — eine Frage, die vorher nie gestellt wurde. Das führt zu produktiven Diskussionen, aber auch zu Abwehrhaltungen: „Das ist Aufgabe der IT.” „Dafür sind wir nicht zuständig.” Lösung: Diese Diskussion bewusst führen, bevor das System live geht, nicht danach.

Außendienst und Kundenportale sind der schwierigste Teil. Die Automatisierung intern läuft schnell. Das Problem: Kunden, die seit Jahren das TDS von einer bestimmten URL oder aus einer E-Mail kennen, müssen informiert werden, wenn sich das Format oder der Übermittlungsweg ändert. Das unterschätzen viele beim ersten Rollout.

Was konkret hilft:

• Vor dem Launch drei bis fünf Pilotprodukte wählen und TDS damit durchgehen — Lücken und Sonderfälle zuerst kennenlernen
• Außendienst frühzeitig einbinden: Sie wissen, welche TDS-Formate Kunden verlangen
• Einen internen Redakteur benennen, der für Template-Anpassungen zuständig ist — nicht die IT
• Kommunizieren, wann ein Update ein TDS auslöst und wann nicht (nicht jede Charge-Variation braucht ein neues TDS)

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Wir haben Word-Templates, das reicht doch.” Word-Templates lösen das Formatierungsproblem, nicht das Versionsproblem. Wenn du zwölf Produkte in drei Sprachen hast und eine Viskosität ändert sich, musst du zwölf Word-Dateien öffnen, suchen, ersetzen, speichern, exportieren. Das Template ändert nichts am Grundproblem: Die Daten stecken in den Dokumenten, nicht in einem System. Eine Automatisierung dreht das um: Die Daten sind einmal gepflegt, das Dokument wird daraus generiert.

„Das ist zu teuer für unser kleines Sortiment.” Für Unternehmen mit unter 30 Produkten stimmt das oft. Für ein Portfolio von 60 oder mehr Produkten mit regelmäßigen Änderungen liegt der Breakeven realistisch unter zwei Jahren — schon ohne ERP-Anbindung. Die günstigste Variante (Make.com + LLM) kostet unter 50 €/Monat an Software; der Hauptaufwand liegt einmalig im Template-Design. Wer diese Rechnung macht, kommt selten auf „zu teuer.”

„Die Kunden wollen das TDS als Word-Datei, nicht als PDF.” Das kommt vor — aber seltener, als man denkt. In der Praxis wollen Kunden aktuelle, verlässliche Informationen. PDF aus einer Automatisierung ist per Definition aktuell; ein Word-File vom Außendienst ist es meistens nicht. Bei Kunden, die tatsächlich Word-Dateien für eigene Weiterverarbeitung brauchen, kann das Ausgabeformat angepasst werden — das ändert nichts am Kernprozess.

„Was, wenn das System etwas Falsches ausgibt?” Das kann es — wenn die Eingangsdaten falsch sind oder das Template einen Fehler hat. Deshalb gibt es in jeder ernsthaften Implementierung einen Review-Schritt: TDS werden nicht direkt vom System veröffentlicht, sondern zuerst freigegeben. Dieser Freigabeschritt ist viel schneller als die bisherige Erstellung (5 Minuten statt 3 Stunden), aber er bleibt. Ein Qualitätsmangel des Systems ist fast immer auf Datenmängel zurückzuführen, nicht auf technische Fehler.

Woran du merkst, dass das zu dir passt

Das spricht dafür:

• Dein Team aktualisiert regelmäßig TDS-Versionen — mindestens zehn bis zwanzig Mal pro Jahr über das gesamte Portfolio
• Ihr habt mehr als 30 aktive Produkte, für die TDS gepflegt werden müssen
• Ihr beliefert Kunden in mehr als einer Sprache und pflegt Übersetzungen manuell
• TDS-Aktualisierungen verzögern sich, weil „gerade keine Zeit ist” — und dieser Stau führt zu Kundenbeschwerden
• Ihr habt Produktdaten zumindest teilweise strukturiert im ERP oder LIMS — nicht nur in Köpfen und E-Mails

Drei harte Ausschlusskriterien:

1. Unter 30 aktiven Produkten oder weniger als acht TDS-Updates pro Jahr. Der Einrichtungsaufwand lohnt sich nicht. Eine gepflegte Word-Vorlage mit klarem Ablageort und Versionierung ist die sinnvollere Lösung. Richtungswechsel erst bei Wachstum.

2. Produktspezifikationen liegen nicht strukturiert vor. Wenn Viskositätswerte, Dichtewerte und Anwendungsempfehlungen primär in Köpfen, Labor-Notizbüchern oder E-Mail-Anhängen stecken — nicht im ERP oder LIMS — dann ist das erste Projekt nicht TDS-Automatisierung, sondern Stammdaten-Strukturierung. Die Automatisierung kommt danach.

3. Kein festes Responsible für Produktdaten-Pflege im ERP. Eine TDS-Automatisierung ist nur so aktuell wie die Daten, aus denen sie schöpft. Wenn keine namentliche Person verantwortlich ist, dass ERP-Daten korrekt und vollständig sind, produziert das System schneller mehr falsche Datenblätter als das manuelle System. Eine Automatisierung braucht Verantwortung, nicht Verantwortungslosigkeit.

Das kannst du heute noch tun

Nimm ein Produkt aus deinem Portfolio, für das ihr häufig TDS aktualisiert. Öffne ein neues Dokument in Claude oder ChatGPT und gib folgendes ein: alle technischen Werte dieses Produkts als strukturierte Liste, dann die Anweisung, daraus den Textblock für ein deutsches TDS zu formulieren.

Das dauert fünfzehn Minuten. Was du dabei lernst: ob eure Produktdaten strukturiert genug sind, dass ein System damit arbeiten kann — und was noch fehlt.

Für den nächsten Schritt — ein erstes Template und die Generierung eines echten TDS — hier ein Prompt, den du direkt verwenden kannst:

Quellen & Methodik

• 90 % Zeitreduktion bei SDB-Erstellung: Chemius-Kundendaten, veröffentlicht 2024/2025 — dokumentiert für einen großen Automotive-Chemie-Kunden. Quelle: chemius.net
• 35 % SDB-Compliance-Fehlerquote bei EU-Kontrollen: CloudSDS, 2024. Quelle: cloudsds.com
• Chemius-Preise (TDS-Add-on 200 €/Monat, Pro Flex 150 €/Monat): Veröffentlichte Preisliste, Stand Mai 2026. Quelle: chemius.net/our-pricing/
• Übersetzungskosten 0,12–0,20 €/Wort: Marktübliche Preise für technische Übersetzungen Chemie/Life Sciences, basierend auf Angeboten spezialiserter Übersetzungsagenturen (Stand 2025).
• Erstellungszeiten 2–4 Stunden pro TDS: Erfahrungswerte aus Projekten mit mittelständischen Chemieunternehmen (3–5 Implementierungen, Portfolio 40–200 Produkte, 2023–2025). Keine repräsentative Studie, aber konsistente Praxisbeobachtung.
• AX Semantics (ab 500 €/Monat), SCHEMA ST4 (ab 2.000 €/Monat): Veröffentlichte Tarifinformationen und eigene Erfahrungswerte, Stand April 2026.