.png)
Es beginnt meistens ganz harmlos.
Ein Kunde meldet sich beim Vertrieb:
„Wir brauchen da eine Lösung. Könnt ihr so etwas bauen?“
Die Entwicklung schaut sich das an und sagt:
„Ja, grundsätzlich schon.“
Also beginnt das Projekt.
Der Konstrukteur erstellt erste Zeichnungen, der Einkauf fragt ein paar Komponenten an und die Stückliste wächst Stück für Stück. Die Frage nach den Kosten wird irgendwo nebenbei beantwortet – meist mit einer schnellen Kalkulation.
Materialpreise plus ein bisschen Overhead.
Dazu ein grober Ansatz für Entwicklungskosten. Und irgendwie passt es am Ende auch.Das Produkt wird gebaut, geliefert – und alle sind zufrieden.
Zumindest fürs Erste.
Das eigentliche Problem beginnt oft erst später. Der Kunde bestellt erneut. Oder ein anderer Kunde möchte das gleiche Produkt. Vielleicht sogar leicht angepasst. Oder, oh Wunder, man möchte wissen, was man denn wirklich an dem Projekt verdient hat.
Jetzt stellt sich plötzlich eine scheinbar einfache Frage: Was kostet der Artikel eigentlich wirklich? Und plötzlich wird es kompliziert. Denn die ursprüngliche Kalkulation war ja nur eine Projektkalkulation. Sie war nie dafür gedacht, als dauerhafte Kostenstruktur zu dienen.
Spätestens wenn Produkte regelmäßig bestellt werden, wandern sie ins ERP-System. Bei meinem Kunden werden Artikel schon mit den ersten Prototypen angelegt. Das heißt, während der Entwicklung eines Produkts entsteht häufig eine sogenannte Growing BOM – eine wachsende Stückliste.
Neue Komponenten kommen hinzu, andere werden geändert. Manche werden durch Alternativen ersetzt. Der Einkauf fragt dabei häufig jede Position einzeln an, ein Motor hier, ein Bauteil dort, ein Gehäuse eines anderen Lieferanten. Jede dieser Komponenten hat irgendwann einen Preis.
Wenn aber ein konkreter Workflow fehlt, wer denn eigentlich dafür zuständig ist die Stammdaten regelmäßig und kontinuierlich zu pflegen, bleiben Preise nur projektbezogen stehen, weil niemand eindeutig verantwortlich ist. Die Informationen existieren zwar, nur eben verteilt.
Der Artikelstamm wird hierdurch nicht besser und es entsteht das, vielen Unternehmen bekannte Phänomen des „Shit in-Shit out“. Anders gesagt, wenn ich falsche oder unvollständige Daten in ein System eingebe, kommt natürlich kein korrektes Ergebnis raus.
Solange Produkte nur bestellt und verbaut werden, fällt das eventuell nicht auf, aber spätestens im Controlling wird es sichtbar.
Denn wenn Preise im System fehlen, entstehen weitere Probleme:
Die Lösung liegt in einer strukturierten Kostenlogik. Statt projektbezogener Einzelkalkulationen werden Standardkosten für Artikel definiert.
Das bedeutet, für jedes Produkt werden systematisch hinterlegt:
Sind diese Daten sauber gepflegt, lässt sich der Produktpreis „auf Knopfdruck“ berechnen.
Meinen Kunden rate ich hierbei ein Stammdatenteam und strukturierte Prozesse rund um die zentralen Daten des Unternehmens zu etablieren, welches der Dreh- und Angelpunkt zwischen den Abteilungen ist. Es vereint den Einkauf, die Technik, Produktion, Qualität und ist dafür zuständig, dass der Artikelstamm und die Stücklisten immer sauber gepflegt sind.
Das klingt erstmal nach rein administrativer Arbeit, ist aber in Wahrheit eine strategische Grundlage für Kostenkontrolle.
Und schon heißt es dann nicht mehr „Shit In- shit out“ sondern Produkte können sauber kalkuliert, Angebote sicher erstellt und Einkaufsentscheidungen fundiert getroffen werden.
Wie sieht das bei Euch im Unternehmen aus? Habt ihr klare Prozesse und Verantwortlichkeiten definiert, oder gleicht Eurer Artikelstamm auch eher einer Müllhalde als einer Datenquelle?
Panzer Consulting GmbH
Schleißheimer Str. 274
80809 München
.png)
.svg){kind=small}