Der ERP-Irrtum

ERP-Systeme wie Microsoft Dynamics 365 F&O sind Meister der Struktur. Sie beherrschen die Kunst, große Mengen transaktionaler Daten sicher und effizient zu verarbeiten. Sie planen Fertigungsaufträge, berechnen Bedarfe, verwalten Lagerorte, buchen Wareneingänge, erstellen Rechnungen und konsolidieren Kennzahlen in Echtzeit. Sie sind unerlässlich für jedes Unternehmen, das wachsen, skalieren und kontrolliert wirtschaften will.
In genau dieser Rolle ist ERP unersetzlich.

Dynamics 365 F&O glänzt, wenn es darum geht:

Doch genau dort liegt auch seine Grenze:

In der Produktentwicklung ist nichts klar, nichts stabil und schon gar nichts abgeschlossen. Entscheidungen werden getroffen – und wieder verworfen. Konstruktionen entstehen – und werden geändert. Varianten entstehen aus Kundenwünschen, Normänderungen, technologischem Fortschritt.

Und genau hier beginnt das Problem:

Was dabei entsteht, ist eine Illusion von Kontrolle – auf Basis eines Systems, das die Realität des Engineerings nicht versteht.

Und je länger man versucht, beides in einem System zu vereinen, desto größer wird der Schaden: Daten werden verbogen, Zusammenhänge gehen verloren, Entscheidungen werden auf unsicherer Basis getroffen. Das Ergebnis ist nicht Effizienz – es ist ein strukturiertes Missverständnis.

Was es braucht, ist Klarheit.
ERP soll tun, was ERP am besten kann.
Engineering braucht ein eigenes System – eines, das seine Sprache spricht.

Die Absicht ist nachvollziehbar. Das ERP ist eingeführt, die Prozesse laufen stabil, die IT ist zufrieden – und jetzt soll auch das Engineering „einbezogen“ werden. Es klingt effizient. Es klingt systematisch. Es klingt nach: „Lasst uns alles an einem Ort verwalten.“

Denn die Realität in vielen Unternehmen, die Engineering in Dynamics 365 F&O oder einem vergleichbaren ERP-System abbilden wollen, sieht anders aus. Sie ist geprägt von:

Und wenn man ehrlich ist, weiß es jeder: Eigentlich funktioniert das nur, weil Menschen die Lücken füllen. Sie exportieren manuell. Sie pflegen doppelt. Sie schreiben sich Notizen, bauen Excel-Logiken, basteln Workflows in SharePoint oder Teams – und hoffen, dass nichts vergessen wird.

Doch was passiert, wenn diese Menschen krank sind? Oder das Unternehmen verlassen? Oder einfach keine Lust mehr haben, permanent gegen die Systemgrenzen anzurennen? Dann bricht das Kartenhaus zusammen.

Plötzlich tauchen Fehler in der Produktion auf – weil eine Variante nicht richtig übergeben wurde.
Plötzlich fehlen Informationen im Einkauf – weil die Änderung nicht im System dokumentiert war.
Plötzlich stellt man fest, dass niemand mehr weiß, warum ein bestimmter technischer Kompromiss eingegangen wurde.

Und spätestens jetzt stellt sich die Frage: Was hat das mit Effizienz zu tun?
Die Antwort: Nichts. Es ist keine Effizienz – es ist Improvisation auf hohem Niveau. Getragen von gutem Willen, aber auf Dauer weder skalierbar noch belastbar.

Denn das Problem liegt nicht bei den Menschen.
Es liegt im System. Und in der Entscheidung, einem System Aufgaben zu übertragen, für die es nie gebaut wurde.

Wer Engineering in ein transaktionales System presst, bekommt am Ende kein integriertes Unternehmen, sondern eine gut getarnte Schattenwelt. Mit versteckten Kosten. Versteckten Risiken. Und wachsender Unsicherheit.

Engineering ist heute mehr als nur Konstruktion. Es ist der Ort, an dem Innovation entsteht – wo Ideen Gestalt annehmen, wo Anforderungen in technische Lösungen übersetzt werden, wo Produkte leben, lange bevor sie produziert werden.

Und genau deshalb braucht Engineering ein eigenes Rückgrat.
Nicht nur ein Ablagesystem. Kein Modul. Kein Workaround. Sondern ein System, das von Grund auf dafür gebaut wurde, Engineering in seiner ganzen Komplexität zu unterstützen.

Denn moderne Produktentwicklung ist:

Ein ERP-System kann das nicht leisten – und es soll es auch nicht.
Denn es wäre überfordert mit der Vielfalt, Flexibilität und Unschärfe, die Produktentwicklung mit sich bringt.
Engineering braucht Systeme, die mit Unschärfe umgehen können – ohne in Chaos zu verfallen.

Was heißt das konkret?
Ein echtes Engineering-System muss:

Und: Es muss mit dem ERP sprechen, ohne von ihm abhängig zu sein.
Denn erst dann entsteht ein echter digitaler Produktkern – ein „Digital Backbone“, der den gesamten Lifecycle trägt: von der Idee bis zur Serienreife, von der Anforderung bis zur Ausmusterung.

Auf dem Papier scheint alles klar: Dynamics 365 F&O ist modern, cloudbasiert, modular erweiterbar. Microsoft investiert massiv, Partnernetzwerke sind stark, die Integrationsmöglichkeiten sind vielfältig. Warum also nicht auch das Engineering über kurz oder lang „mit reinnehmen“?

Und genau hier beginnt die Dynamik, die viele Unternehmen in die falsche Richtung lenkt – nicht aus Inkompetenz, sondern aus einem Mix aus Pragmatismus, internen Zwängen und externen Versprechen.

Was passiert konkret?

1. ERP-Berater versprechen Lösungen, die nicht funktionieren
   Viele ERP-Implementierer kennen sich in Logistik und Finanzen hervorragend aus – aber nicht in der Welt des Engineerings. Dennoch wird versprochen: „Ja klar, das kriegen wir auch hin – Stücklisten, Varianten, Änderungen, kein Problem.“ Technisch stimmt das sogar. Irgendwie lässt sich vieles „abbilden“. Aber es bleibt bei einer reinen Verwaltung – ohne die Logik, die Engineering ausmacht. Was am Ende entsteht, ist nicht Integration – sondern ein Korsett.

2. Die IT will Komplexität reduzieren – und übersieht dabei Funktionstiefe
   IT Abteilungen denken oft in Systemkonsolidierung, Lizenzverträgen, Infrastruktur. Für sie ist weniger oft mehr – und ein weiteres System bedeutet Aufwand, Support, Integration. Was dabei übersehen wird: Die Spezialprozesse des Engineerings lassen sich nicht einfach in Standardstrukturen pressen. Wer alles in einem System abbilden will, verliert die Qualität in den Bereichen, die eigentlich hochspezialisiert geführt werden müssten.

3. Engineering macht sich zu selten bemerkbar
   Die Realität: Viele Engineering-Teams akzeptieren Einschränkungen – aus Gewohnheit, aus Zeitdruck, oder weil sie es nicht besser kennen. Sie arbeiten sich „irgendwie durch“, führen Schattenlisten in Excel, lösen Probleme pragmatisch – und verstärken damit das Bild, dass alles „schon irgendwie geht“. Das Schweigen der Fachabteilung wird als Zustimmung interpretiert – dabei ist es oft ein stiller Rückzug.

4. Das Management sieht nur Lizenzkosten – nicht die echten Kosten
   PLM klingt nach zusätzlicher Software, nach weiteren Lizenzen, nach Aufwand. ERP ist schon da, bezahlt, eingeführt. Also wird gespart – und die Kosten der Ineffizienz, der Redundanzen, der Fehler, der Verzögerungen bleiben unsichtbar. Bis es knallt. Ein Rückruf. Ein nicht produzierbares Produkt. Ein verlorener Großkunde. Und plötzlich stellt sich die Frage: „Warum haben wir das nicht früher gesehen?“

Genau hier setzt Bluestar PLM an: Nicht als Kritik am ERP. Sondern als Korrektur an einer gefährlichen Fehlannahme. ERP ist unverzichtbar – aber eben nicht universell. Engineering braucht ein System, das seine Sprache spricht – und Dynamics 365 versteht.

Was wäre, wenn es ein System gäbe, das Engineering wirklich versteht – und gleichzeitig nahtlos mit Dynamics 365 F&O verbunden ist? Ein System, das tief in den Entwicklungsprozessen verankert ist, aber so integriert, dass es sich nicht wie ein Fremdkörper anfühlt, sondern wie eine natürliche Erweiterung des ERP?

Genau das ist Bluestar PLM.

Bluestar wurde von Ingenieuren für Ingenieure entwickelt – mit dem klaren Ziel, die Disziplinen der Produktentwicklung in ihrer ganzen Tiefe zu unterstützen. Und zwar dort, wo sie entstehen: im Engineering – nicht im ERP. Bluestar PLM ist kein Tool, kein Modul, kein „Add-on“.

Es ist das Engineering-Rückgrat für Dynamics 365-Kunden, die ihre Produktdaten wirklich im Griff haben wollen.
Es bringt Struktur dorthin, wo andere Systeme Lücken lassen.
Es bringt Sicherheit in Entscheidungen, die sonst auf Annahmen basieren.
Und es bringt Geschwindigkeit – nicht durch Hektik, sondern durch Klarheit.

In Zeiten knapper Ressourcen, globaler Lieferketten und ständig wachsender Produktkomplexität suchen Unternehmen nach Effizienz. Nach Standardisierung. Nach einer klaren, durchgängigen IT-Landschaft. Das ist richtig – und wichtig.

Doch Standardisierung darf nicht in Vereinfachung auf Kosten des Engineering umschlagen. Denn wer Produktentwicklung in ein System zwingt, das für Planung und Abwicklung gebaut wurde, begeht einen Denkfehler mit weitreichenden Folgen.

Es ist nicht gemacht für Versionen, für Varianten, für multidisziplinäre Iterationen. Es verwaltet, was entschieden wurde – aber es unterstützt nicht den Weg zur Entscheidung. Genau deshalb braucht Engineering ein eigenes, starkes Rückgrat:

Letzter Gedanke:
Man kann Engineering in Dynamics 365 F&O abbilden.

Man kann Änderungen manuell nachpflegen.
Man kann Stücklisten in Excel vorbereiten.
Man kann Freigaben per E-Mail organisieren.
Aber man sollte es nicht.

Denn Produkte entstehen nicht in Tabellen – sie entstehen im Kopf. Und sie brauchen ein System, das diesen Prozess ernst nimmt. Nicht als Modul. Sondern als Mission.