Wissens-Hub an ERP und MES anbinden: Was technisch wirklich nötig ist

Warum ein isolierter Wissens-Hub die Suche verdoppelt statt verkürzt

Ein Anlagenbauer aus dem Münsterland führte vor einigen Jahren ein Dokumentenmanagementsystem ein, das komplett losgelöst vom bestehenden ERP lief. Das Ergebnis war ernüchternd: Mitarbeiter mussten fortan in zwei statt einem System suchen, weil Auftragsdaten im ERP und technische Dokumente im neuen System getrennt blieben. Die eigentlich gewünschte Zeitersparnis kehrte sich teilweise ins Gegenteil um.

Diese Erfahrung ist ein wichtiger Hinweis für jede Einführung eines Wissens-Hubs: Ohne Anbindung an die vorhandenen Kernsysteme entsteht im schlimmsten Fall nicht weniger, sondern mehr Aufwand, weil ein zusätzlicher Ort existiert, an dem gesucht werden muss.

ERP-Anbindung: Kontext statt Doppelpflege

Die Anbindung an das ERP-System liefert dem Wissens-Hub vor allem Kontext: Zu welchem Auftrag, welcher Stückliste, welchem Kunden gehört ein Dokument oder eine Störungsmeldung. Technisch reicht dafür in den meisten Fällen eine schlanke, lesende Schnittstelle, die Stammdaten wie Materialnummern und Auftragsnummern bereitstellt, ohne dass Daten doppelt gepflegt werden müssen.

Wichtig ist dabei ein klares Prinzip: Das ERP bleibt die führende Quelle für Auftrags- und Stammdaten, der Wissens-Hub verknüpft und ergänzt diese Daten um Dokumente, Erfahrungswissen und Suchbarkeit, ersetzt sie aber nicht.

MES-Anbindung: Echtzeitdaten als Auslöser, nicht als Ersatz

Die Anbindung an das MES ist technisch anspruchsvoller, weil hier Echtzeitdaten aus der Fertigung entstehen, etwa Stillstandsmeldungen oder Sollwertabweichungen. Der Wissens-Hub muss diese Ereignisse nicht in Echtzeit verarbeiten, um nützlich zu sein, es reicht meist, wenn er sie als Auslöser nutzt: Tritt eine bestimmte Störung auf, wird automatisch die passende, bereits dokumentierte Lösung vorgeschlagen, statt dass ein Mitarbeiter manuell danach suchen muss.

Diese Art der Anbindung setzt voraus, dass Störungscodes im MES sauber gepflegt sind. Ist das nicht der Fall, lohnt es sich, zunächst mit einer einfacheren, manuellen Verknüpfung zu starten und die automatische Auslösung erst in einer zweiten Ausbaustufe zu ergänzen.

Was für einen Pilot technisch wirklich reicht

Für einen Piloten ist eine vollständige, bidirektionale Anbindung an alle Systeme selten notwendig und oft sogar hinderlich, weil sie den Start um Monate verzögert. Eine schlanke, lesende Anbindung an die wichtigsten Stammdaten aus ERP und MES reicht in der Regel aus, um den entscheidenden Effekt zu zeigen: Antworten, die automatisch mit dem richtigen Auftrags- und Anlagenkontext versehen sind.

• Lesende Schnittstelle zu Stammdaten aus dem ERP, keine Doppelpflege von Daten
• Verknüpfung von Störungscodes aus dem MES mit bereits dokumentierten Lösungen
• Klare Festlegung, welches System für welche Daten führend bleibt
• Schrittweiser Ausbau von manueller zu automatischer Verknüpfung
• Regelmäßige Prüfung, ob Schnittstellendaten noch mit der Realität übereinstimmen

Warum Schnittstellen am Ende über die Skalierung entscheiden

Was im Pilot noch mit wenigen manuellen Verknüpfungen funktioniert, muss beim Rollout auf weitere Werke oder Linien tragfähig automatisiert sein. Deshalb lohnt es sich, die Schnittstellenarchitektur von Anfang an so zu planen, dass sie sich wiederholen lässt, wie auch im Beitrag zur branchenunabhängigen Übertragbarkeit beschrieben.

Ob sich der Aufwand für eine saubere Anbindung gelohnt hat, zeigt sich am Ende an denselben Kennzahlen wie beim gesamten Piloten, etwa der Zeit bis zur richtigen Antwort, wie im Beitrag zu Kennzahlen für den Pilotenerfolg beschrieben.