Wie lässt sich ein Fertigungs-ERP schnell einführen?

Bei Bonx sind wir überzeugt, dass die Einführung eines Fertigungs-ERP in Wochen oder Monaten gelingen sollte, nicht in Jahren. Wir sind auch überzeugt, dass Ihr ERP dem Unternehmen früh Wert liefern sollte, idealerweise bevor der vollständige Rollout abgeschlossen ist.

Das ist nicht nur eine Überzeugung. Es ist auch ein Beleg und ein Punkt, auf den unser Team stolz ist. Unser Kunde Feroce ging mit Bonx in 42 Tagen live, ohne den Betrieb zu unterbrechen, und bewältigte danach einen durch einen nationalen TV-Auftritt ausgelösten Bestellanstieg, während jedes Paket nach demselben Standard nachverfolgt und versendet wurde. Something Added führte Bonx in zwei Monaten mit einer nativen Integration zu HP-3D-Druckern ein. Dadurch kann das Werk Aufträge automatisch gruppieren, Fertigungsaufträge generieren und eine 24/7-Produktion mit mehr als 10,000 produzierten Teilen pro Monat betreiben.

Für alle, die an klassische ERP-Systeme gewöhnt sind, können diese Überzeugungen und Aussagen so ungewöhnlich klingen, dass sie schwer zu glauben sind. Wie genau kann Bonx solche ambitionierten Einführungszeiten erreichen? Dieser Artikel erklärt es.

Warum ein KI-natives ERP den Zeitplan verändert

Der Zeitplan einer klassischen ERP-Einführung ist teilweise ein Technologieproblem, weil klassische ERP-Systeme auf starren Datenschemata und codeintensiven Anpassungen aufgebaut wurden. Einen Prozess abzubilden bedeutet oft, das Unternehmen zuerst in die vorhandene Struktur des ERP zu übersetzen und anschließend Konfiguration, kundenspezifische Entwicklung, Tests und Nacharbeit rund um diese Struktur zu ergänzen. Die Vorlaufzeit zwischen „So funktioniert unser Prozess“ und „Der Prozess existiert in der Software“ ist lang. Das ist ein zentraler Grund dafür, warum viele klassische ERP-Einführungen scheitern.

Das Betriebsmodell von Bonx ist darauf ausgelegt, schneller konfiguriert und angepasst zu werden. Zum Beispiel nutzt Bonx bereits in der Deployment-Phase KI-Agenten, um Daten und Regeln in Prozesse zu übersetzen. Ziel ist ein System, das den Arbeitsfluss schneller abbildet, sich mit den umliegenden Tools verbindet und dem Team wiederkehrende Arbeit früher im Deployment abnimmt.

Die Technologie selbst verändert die Einführungsgeschwindigkeit auf zwei Arten:

1. Abbildung: Wenn das System konfigurierbarer und modularer ist, kann der Zeitaufwand für das Mapping und die Anpassung eines Prozesses deutlich sinken. Das Team kommt dadurch viel schneller von der Workflow-Diskussion zu funktionierender Software als in einem klassischen ERP-Projekt.
2. Akzeptanz: Menschen übernehmen ein System schneller, wenn es ihnen sofort Wert liefert. Wenn ein Vertriebsteam 80% seiner Kapazität für die Angebotserstellung zurückgewinnt, weil die Arbeit an Kundenaufträgen automatisiert wird, hat dieser Unternehmensbereich einen Grund, auf das ERP umzusteigen. Dadurch muss Akzeptanz nicht zu einer Schulungskampagne oder zu einem eigenen Schritt im Go-live-Prozess werden, was den Zeitplan weiter beschleunigt.

3 Unterschiede im Einführungsansatz von Bonx

Die Technologie selbst, zum Beispiel Datenmodell und Betriebsmodell, ist ein Faktor dafür, warum ein KI-natives ERP schneller eingeführt werden kann als ein klassisches ERP. Aber auch jenseits der Technologie ist ein Go-live mit Bonx nicht einfach eine klassische ERP-Einführung mit engerem Kalender. Hier sind drei weitere Unterschiede, durch die unsere Kunden schnell arbeitsfähig werden.

1. Nicht alles muss zwingend gleichzeitig live gehen

In einem klassischen ERP-Projekt versucht das Team oft, das gesamte Unternehmen im Voraus zu modellieren, und wartet dann bis zum Ende auf den Nutzen, manchmal über Jahre. Im Bonx-Modell wählt das Team den ersten Arbeitsfluss aus, bringt ihn live, lernt aus der tatsächlichen Nutzung und erweitert dann den Umfang.

Wir haben durchaus Kunden, die eine Einführung bevorzugen oder benötigen, bei der das gesamte Unternehmen in einem klaren Moment auf das neue System umstellt, meistens wegen des Endes der Lebensdauer eines anderen Systems. Häufiger betrifft der erste Go-live jedoch einen realen, klar definierten und wichtigen operativen Ablauf, nicht das gesamte Unternehmen oder System. Das können Kundenaufträge bis zum Versand sein, Ersatzteilbestellungen, Produktionsmeldungen für eine Aktivität, Lager und Einkauf für einen kontrollierten Umfang und ähnliches.

Das entscheidende Wort ist „real“. Ein erster Go-live mit Bonx ist keine Demo-Umgebung, kein Modellprozess und kein theoretischer Workflow. Er bedeutet echte Nutzer, echte Aufträge, echte Lagerbewegungen, echte Dokumente und echten operativen Wert.

Das bedeutet oft, dass der erste Go-live neben bestehenden Tools läuft. Mehrere Bonx-Deployment-Pläne enthalten eine Parallelphase, in der das Team echte Arbeit durch Bonx laufen lässt, während das bestehende Tool zur Validierung des Ablaufs bestehen bleibt. Das senkt das psychologische Risiko einer ERP-Einführung.

2. Der erste Umfang hat ein klares Erfolgskriterium

Unser Einführungsansatz bedeutet nicht, dass das System am ersten Tag zwingend das ganze Unternehmen und jeden Anwendungsfall abdecken muss. Gleichzeitig legen wir großen Wert darauf, Erfolgskennzahlen zu definieren und zu erreichen. Was der Go-live beweisen muss: Für den ersten definierten Umfang funktioniert es wirklich. Nicht nur technisch, sondern auch aus Sicht der Menschen, die damit arbeiten.

In einem aktuellen Deployment-Plan war das Go-live-Kriterium einfach: Eine Person musste einen vollständigen Kundenauftrag vom Angebot bis zu den Versanddokumenten in weniger als 10 Minuten und ohne Hilfe erstellen können. Das ist ein besserer Maßstab als eine Checkliste konfigurierter Felder, weil er prüft, ob das System eine reale operative Handlung unterstützt.

Für den ersten Go-live-Umfang denken wir über praktische Fragen nach:

• Kann das Team diesen Ablauf in Bonx durchführen, ohne auf ein anderes Tool oder eine andere Informationsquelle zu warten oder darauf zurückzugreifen?
• Sehen die richtigen Nutzer, was sie brauchen, ohne jemand anderen fragen zu müssen?
• Sind Dokumente, Lagerbewegungen, Statuswechsel, Produktionsschritte und ähnliche Elemente zuverlässig genug für die echte Nutzung in der Fertigung?
• Nimmt der Ablauf tatsächlich Arbeit ab und erleichtert den Teams den Alltag, oder verlagert er Arbeit nur in eine andere Maske?

Diese Art der Einführung sollte konkreter wirken, weil der erste Umfang zwar kleiner sein kann, der Maßstab für Erfolg und geschäftlichen Nutzen aber höher ist.

3. Die erste Iteration ist nicht die Ziellinie

Viele Fertigungsunternehmen haben gelernt, den ERP-Go-live als Bruchkante zu sehen. Davor ist alles Vorbereitung, danach ist alles Support. Für Bonx ist der Go-live der erste Beweis, dass das System das Unternehmen unterstützen kann. Von dort aus wächst die Einführung weiter, mit voller Beteiligung unseres Teams.

Damit dieses Modell funktioniert, ist unser Team diszipliniert in Bezug auf das, was nach dem ersten Schritt kommt. In einem aktuellen Deployment-Plan haben Bonx und der Kunde beispielsweise alle Themen des zweiten Umfangs eingefroren, bis der erste Go-live abgeschlossen war. Integrationen, Dashboards, Sondercodes, zusätzliche Berichte und weitere Workflows wurden nicht ignoriert. Sie wurden in einen Themenspeicher gelegt, priorisiert und für die Zeit nach dem ersten Live-Ablauf geplant.

Das ist kein Kompromiss. So verhindert das Projekt, zu einer monatelangen klassischen ERP-Einführung zu werden. Das heißt nicht, dass Sonderfälle unwichtig sind. Die Frage ist, ob sie den Go-live des ersten Anwendungsfalls blockieren müssen, der operativen Wert liefert. Wenn ein Dashboard, eine Integration oder eine Ausnahme hilfreich, aber für den ersten realen Ablauf nicht erforderlich ist, sollte dieses Thema den Go-live nicht aufhalten.

Dieser Teil unseres Einführungsansatzes kann sich am Anfang ungewohnt anfühlen. Teams sind daran gewöhnt, ERP-Umfang als Schutz zu behandeln: Wenn wir jetzt alles aufschreiben, übersehen wir nichts. Ein zu großer Umfang kann aber das Gegenteil bewirken. Das Projekt wird zu schwer, um sich zu bewegen, und das Unternehmen wartet Monate, bevor irgendjemand das System nutzen kann.

Was Sie als Bonx-Kunde während der Einführung erwarten können

Eine schnelle ERP-Einführung bedeutet nicht, dass Kunden passiv bleiben oder keine Verantwortung für den Erfolg tragen. Sie verlangt weniger formelle Workshops als eine klassische ERP-Einführung, aber ein Go-live mit Bonx erfordert weiterhin Entscheidungen, Daten und klare fachliche Verantwortung.

Natürlich hat nicht jedes Fertigungsunternehmen denselben Umfang oder denselben Zeitplan. Als Ausgangspunkt bitten wir unsere Kunden aber in der Regel, ihre operative Realität vollständig bereitzustellen: Produkte, Kunden, Lieferanten, Preise, Bestände, Stücklisten, Arbeitspläne, Qualitätsregeln, Dokumente und die Ausnahmen, die häufig genug auftreten, um relevant zu sein. Das Team muss auch die Nutzer benennen, die den Ablauf validieren können, weil ein System nicht zuverlässig live gehen kann, wenn niemand die Antwort auf die Frage verantwortet: „Entspricht das unserer Arbeitsweise?“

Ab dort verändert sich die Form der Arbeit. Statt Monate damit zu verbringen, das Unternehmen in eine starre ERP-Struktur zu übersetzen, arbeitet das Team am ersten Live-Ablauf. Welche Daten braucht dieser Ablauf? Welche Status sind wichtig? Welche Dokumente müssen generiert werden? Welche Entscheidungen brauchen menschliche Freigabe? Welche Schritte können später automatisiert werden, sobald Vertrauen aufgebaut ist?

Wir bitten unsere Kunden nicht, ihre besten Leute über Wochen und Wochen im Verlauf eines Jahres für Workshops verfügbar zu machen, bevor sie Wert sehen. Gleichzeitig ist schnelle Einführung kein Versprechen, die schwierigen Teile zu überspringen. Ein Go-live mit Bonx braucht weiterhin Fokus. Der Unterschied ist, dass wir fest davon überzeugt sind, dass er Ihrem Unternehmen schnell Wert zurückgeben sollte, und wir tun alles dafür, dieses Versprechen einzulösen.