3 Prinzipien erfolgreicher Gießerei ERP-Projekte

Das erste Prinzip klingt banal, wird aber systematisch ignoriert: Erfolgreiche Projekte starten mit der Frage „Welches Problem lösen wir?" — nicht mit „Welches System brauchen wir?"

Wie es typischerweise läuft

In vielen Digitalisierungsprojekten beginnt die Diskussion mit: „Wir evaluieren ERP-Systeme", „Wir holen drei Angebote ein", oder es werden Checklisten ausgefüllt. Seitenweise Anforderungskataloge nach denen ein ERP ausgewählt werden kann — aber kein Wort darüber: Welches konkrete Problem wollen Sie eigentlich lösen?

Das ist nachvollziehbar — Technologie ist greifbar, vergleichbar, entscheidbar. Probleme hingegen sind oft diffus und ihre Analyse erfordert unbequeme Gespräche über interne Abläufe.

Wie erfolgreiche Projekte starten

Erfolgreiche Projekte nehmen sich Zeit für eine präzise Problembeschreibung — nicht Tage oder Wochen, sondern häufig Monate. Nicht: „Wir brauchen bessere Übersicht" oder „Unser System ist veraltet". Das sind Symptome, keine Problembeschreibungen.

Der Unterschied: Die erste Variante bleibt vage. Die zweite beschreibt eine konkrete Ursache-Wirkungs-Kette mit messbaren negativen Auswirkungen.

Ein praktisches Beispiel aus der Branche

Eine mittelständische Gießerei startete mit der Aussage „Wir brauchen Echtzeit-Maschinenüberwachung". Die Evaluierung von Dashboard-Systemen war bereits angelaufen. Die kritische Nachfrage: „Welches konkrete Problem löst Echtzeit-Überwachung?"

Nach mehreren Gesprächen kristallisierte sich heraus: Das eigentliche Problem waren ständige Rückfragen zwischen den Schichten. Die Lösung war kein Dashboard für 20.000 Euro — sondern ein standardisiertes 5-Minuten-Übergabe-Meeting mit Checkliste.

Die psychologische Barriere

Warum wird dieses Prinzip so oft ignoriert? Weil es unbequem ist. Es ist psychologisch einfacher zu sagen „Unser System ist veraltet, wir brauchen ein neues" als „Unsere internen Abläufe funktionieren nicht optimal." Das erste ist eine externe Ursache (die Software), das zweite eine interne (die Organisation).

Das Prinzip in der Praxis: Bevor auch nur ein Anbieter kontaktiert wird — investieren Sie Wochen oder Monate in die zentrale Frage: „Was ist unser konkretes Problem? Nicht das Symptom — die eigentliche Ursache?"

Das zweite Prinzip erfordert einen Perspektivwechsel: Erfolgreiche Projekte betrachten die Gießerei als vernetztes System — als Organismus — nicht als Aneinanderreihung isolierter Prozessschritte.

Der Standard-Ansatz: Prozess-Denken

Der konventionelle Digitalisierungsansatz basiert auf Prozess-Analyse: Welche Schritte gibt es? In welcher Reihenfolge? Das funktioniert hervorragend in standardisierten Fertigungsumgebungen — etwa bei Automobilzulieferern. Dort sind Prozesse tatsächlich weitgehend linear, standardisiert und isolierbar.

Warum Gießereien fundamental anders funktionieren

Ein Schmelzprogramm ist nicht einfach ein isolierter Prozessschritt „Schmelzen". Es beeinflusst in komplexen Wechselwirkungen: wann welche Modelle gewechselt werden können, zu welchem Zeitpunkt Kerne produziert werden müssen, in welcher Sequenz Aufträge bearbeitet werden können, welches Personal benötigt wird und wie sich Energiekosten verteilen. Es ist ein Kreislauf mit Ursache-Wirkungs-Ketten die sich über Stunden oder Tage erstrecken können.

Ein praktischer Test: Können die direkt beteiligten Mitarbeiter ohne langes Nachdenken erklären, wie sich eine Änderung in Prozess A auf die Ergebnisse in Prozess C auswirkt — inklusive der zeitlichen Verzögerung? Wenn nicht, ist das Verständnis des Organismus noch nicht ausreichend entwickelt.

Das ERP-Paradox: Warum beide Standard-Wege scheitern

Aus dem konzeptionellen Mismatch zwischen linearer ERP-Logik und zyklischem Organismus ergibt sich ein Paradox mit zwei scheinbar alternativlosen Wegen:

Der intelligente Mittelweg: Minimale strategische Anpassungen statt extensiver Programmierung. Lieber drei präzise gezielte Anpassungen die kritische Lücken schließen, als 30 Anpassungen die jeden Spezialfall abdecken wollen. Wartbarkeit über alles — und akzeptieren, dass kein System perfekt passt.

Das dritte Prinzip widerspricht der üblichen Projektmanagement-Lehre: Erfolgreiche Projekte arbeiten mit 3–5 Personen — nicht mit 10–15.

Je mehr Stakeholder involviert sind, desto mehr Energie fließt in Abstimmung statt in Problemlösung. Lösungen tendieren zu Kompromissen die der Systemkomplexität nicht gerecht werden. Ein kleines Team, das den Organismus wirklich versteht, trifft systematisch bessere Entscheidungen als ein großes Team das nach Standard-Projektmethoden operiert.

Die drei entscheidenden Rollen

Die Entscheidung: Berater oder Experte?

Ein konkreter Test — stellen Sie die Frage: „Wie gehen Sie mit Chef-Aufträgen in Gießereien um?"

Die unterschätzte Rolle der Key User

Das 3–5 Personen Kern-Team ist für strategische Entscheidungen optimal. Für die praktische Umsetzung kommen Key User hinzu — mit klar definierter Funktion:

• Fachexpertise einbringen aus allen Bereichen (Schmelzen, Formen, Kernmacherei, Putzerei, QS)
• Organismus-Verständnis in die Breite tragen — sie sind Multiplikatoren in ihren Bereichen
• Integrative Tests ermöglichen — das Kern-Team kann nicht alle Prozess-Kombinationen testen
• Go-Live Support — erste Anlaufstelle nach der Implementierung

Bei kleineren Optimierungen: 5–7 Key User. Bei einem kompletten ERP-Wechsel: 15–20 Key User. Aber sie bleiben operational fokussiert und berichten an das strategische Kern-Team. Die Entscheidungsstrukturen bleiben schlank.

Bonus-Prinzip: Die richtige Steuerungsgröße finden

Die Wahl der Steuerungsgröße bestimmt was optimiert wird. In Gießereien manifestiert sich das klassisch als „Tonnen pro Stunde" — eine rein physikalische Größe die Ausschuss, Energiekosten und Deckungsbeitrag ignoriert.

Die wirtschaftlich sinnvollere Alternative stammt aus Eliyahu Goldratts Theory of Constraints: Deckungsbeitrag pro Engpass-Maschinenstunde.

Das Dashboard zeigt weiterhin „Ziel erreicht" — aber die entscheidende wirtschaftliche Frage wird nicht gestellt. Nicht nach der Kennzahl steuern die das System vorschlägt, sondern nach der Kennzahl die wirtschaftlich relevant ist: Wertschöpfung am systemlimitierenden Engpass.

Warum werden diese Prinzipien so selten befolgt?

• Prinzip 1 wird ignoriert weil Probleme zu analysieren unbequem ist. Es ist psychologisch einfacher, ein neues System zu beschaffen.
• Prinzip 2 wird ignoriert weil Organismus-Denken nicht zu Standard-Methoden passt. Es erfordert eigene Analyse statt Best Practices.
• Prinzip 3 wird ignoriert weil es Vertrauen erfordert — dass 3–5 richtige Personen bessere Entscheidungen treffen als 15.

Psychologische Forschung (Dunning & Kruger, 1999) zeigt: Je weniger fundiertes Verständnis über IT-Systemarchitekturen vorhanden ist, desto mehr wird die tatsächliche Komplexität unterschätzt. Die Vorsichtigen, Nachdenklichen mit Praxiserfahrung werden oft überhört. Nicht die lautesten Stimmen sollten die Richtung bestimmen, sondern die mit dem fundiertesten Wissen.

Was das konkret bedeutet

• Problem präzise definieren Nicht „Wir brauchen ein neues ERP" sondern „Welches konkrete Problem lösen wir?" Wochen oder Monate investieren bis die Antwort präzise ist.
• Systemische Zusammenhänge verstehen Wie beeinflusst A den B? Was sind die Rückkopplungen? Wo sind die echten Engpässe? Erst wenn das Gesamtsystem verstanden ist, über Software nachdenken.
• Das richtige Team bilden Maximum 5 Personen. Mit Gießerei-Systemverständnis, Entscheidungsbefugnis, technischer Kompetenz.
• Die richtige Steuerungsgröße definieren Nicht „Was zeigt das ERP?" sondern „Was ist wirtschaftlich relevant?" Für Gießereien: Deckungsbeitrag pro Engpass-Stunde.

Erst nach diesen vier Schritten: Software-Auswahl, Berater-Einbindung, Implementierung.

Die erfolgreichsten Digitalisierungsprojekte sind nicht die mit dem größten Budget, nicht die mit der modernsten Technologie. Es sind die Projekte in denen die Menschen mit dem tiefsten Systemverständnis — oft langjährig Erfahrene — tatsächlich gehört und ernst genommen werden.

P.S.: Diese Prinzipien sind nicht theoretisch. Sie basieren auf der Beobachtung was erfolgreiche Projekte anders machen als gescheiterte. Der Unterschied liegt nicht in größeren Budgets oder besserer Software — sondern in der Herangehensweise.