Das Karriereportal für Wissenschaft & Forschung von In Kooperation mit DIE ZEIT Forschung und Lehre
Der F&E Manager

Mosaiksteinchen mit Mehrwert

Interview mit Helmuth Schneider

Mit der Umstrukturierung in Business Units hat Pierburg das Kapazitätsmanagement eingeführt. Das Central Engineering bekam den Auftrag, Kapazitätsangebote und Bedarfe abzubilden und ein Abrechnungssystem für den Ressourceneinsatz zu schaffen. Für den Erfolg des Projektes waren nicht nur im Vorfeld Überzeugungsarbeit und umfangreiche Unterstützung zu leisten.

Mosaiksteinchen mit Mehrwert© jock+scott - photocase.comKapazitätsmanagement ist als Teil des Gesamtbildes zu betrachten und gibt Aufschluss über den Ressourceneinsatz
DER F&E MANAGER: Herr Schneider, wie kamen Sie zu Pierburg?

Helmuth Schneider: Ich bin von der Ausbildung her Kaufmann und habe 1997 bei Pierburg im Vertrieb begonnen. Dass ich als Kaufmann seitdem auch viele Jahre in der Entwicklung oder zumindest in einem entwicklungsnahen Bereich gearbeitet habe, war bei Pierburg zunächst nicht selbstverständlich, für mich selbst aber eine tolle Erfahrung. Ingenieure haben eine ganz eigene Denkweise. Sie sind an einer schnellen und technisch brillanten Lösung interessiert, während ein ganzheitlicher Managementansatz für sie zunächst einmal nicht im Vordergrund steht. Ich fühle mich da sehr wohl und empfand es als eine spannende Aufgabe, die Kollegen zum Beispiel auch mit in das Boot Ressourcenmanagement hineinzunehmen.

Wie sah Ihr Umfeld aus, als Pierburg sich dafür entschied, ein Kapazitätsmanagement einzuführen?

Wir sind 2004 mit dem Kapazitätsmanagement gestartet, damals als Teil des übergreifenden Ansatzes, den Produktentstehungsprozess zu überarbeiten. 2005 waren wir damit fast fertig - so dachten wir - man findet immer noch Stellen im PEP, die der Verbesserung bedürfen. 2004/2005 hatten wir aber auch eine weitere Besonderheit abzubilden, wir führten die Business-Unit-Struktur bei Pierburg ein. Die alten Entwicklungsbereiche bekamen über ihre bisherige Verantwortung hinaus auch die Produktverantwortung in kommerzieller Hinsicht. Dafür schaffte man ein Central Engineering, das als Ressourcenpool ausgestattet war mit Versuchsingenieuren, Konstrukteuren etc. Das Central Engineering hatte dazu die Anforderung, ein Abrechnungssystem bereitzustellen, mit dem auch der Ressourceneinsatz in einem fremden Bereich geplant werden konnte. All das waren bereits gute Gründe dafür, dass wir ein Kapazitätsmanagementsystem benötigten. 2005 habe ich diese Aufgabe übernommen. Zu dem Zeitpunkt hatte ich bereits eine unterstützende Funktion in einem der Entwicklungsbereiche, eine Art Assistenz des Entwicklungsleiters. Somit war es naheliegend, dass ich das als Kaufmann für alle zukünftigen Business Units zusammen übernehme. Das ganze Projekt war damals eine sehr spannende Angelegenheit, die wir zusammen mit einem Beratungshaus durchgeführt haben.

Was hat Pierburg dazu bewogen, sich mit dem Thema Kapazitätsmanagement und -planung zu beschäftigen?

Letztendlich war es genau diese Anforderung, zwei Bereiche - der eine kapazitätsnachfragend, der andere Kapazitäten anbietend - abzubilden. Gleichzeitig wollten wir feststellen, ob es gerechtfertigt ist, wenn Abteilungen nach zusätzlichen Ressourcen rufen. Das selbstverständliche Herangehen im Projektmanagement - welche Projekte haben wir im Unternehmen, was braucht ein Projekt - das war bei Pierburg 2004/2005 einfach nicht über alle Entwicklungsbereiche präsent. Die damaligen Ressourcenverantwortlichen haben ihre Projekte direkt gesteuert. Sie konnten beim Durchgang durch ihre Büros sehen, ob die Kollegen Schweiß auf der Stirn hatten (lacht).

Da haben Sie in der F&E sicher auch organisatorische Veränderungen vorgenommen. Wie sind Sie bei der Einführung vorgegangen?

Die organisatorischen Veränderungen gab es: Die schon beschriebene Aufteilung der Entwicklungsverantwortung und der Ressourcen zwischen Business Units und Central Engineering sowie die Schaffung einer zentralen Stelle für das Ressourcenmanagement, von der die Planung und Abrechnung zwischen den Bereichen unterstützt wird. Es gab aber auch einen Schritt zurück. Inzwischen sind nur die Bereiche, die eine klassische Dienstleisterfunktion haben, nach wie vor im Central Engineering angesiedelt: vor allem Simulation, Prüffeld und Elektronikentwicklung, die übergreifend von verschiedenen Business Units als Ressourcen genutzt werden. Auch da blieb jedoch die Anforderung, planen und mit denjenigen regelmäßig und nachvollziehbar abrechnen zu können, die vom jeweiligen Projektbudget-Tellerchen gegessen hatten.

Mosaiksteinchen mit Mehrwert © Der F&E Manager Diplom-Kaufmann Helmuth Schneider
Wie unterstützt das Kapazitätsmanagement-System das Management bei der Entscheidung für neue Entwicklungsprojekte?

Hier müssen wir den Begriff "Management" differenziert betrachten: Das Top-Management und die BU-Leiter müssen eine eher langfristige Tendenz-Aussage bekommen, um zu entscheiden, in welchen Bereich sie investieren. Wo werden Stellen aufgebaut oder verschoben? Welche Funktionen brauche ich? Design Engineer, Testing Engineer, Simulation Engineer usw. Und bei Business Units oder Produktfamilien: Wo sind die Bedarfe von den einzelnen Projekten geplant, wie stellt sich das BU-übergreifend dar? Das ist eher eine mittel- bis langfristige Sicht, die durch entsprechende Zahlen aus den Projekten gesichert werden muss. Diese Themen unterstützen wir durch Auswertungen aus den vorhandenen Kapazitätsplanungen. Wir sind damit auch der Ansprechpartner für die Geschäftsführung, wenn es z.B. darum geht, bei Bedarf die Zahlen in unserem POC, dem Pierburg Operations Commitee, zu präsentieren. Die BU-Leiter bekommen die gleichen Zahlen für ihre jeweiligen Bereiche, sie erhalten Sonderauswertungen oder was auch immer sie zum Beispiel für ihre jährliche Wirtschaftsplanung benötigen. Eine andere Managementebene ist das Projektmanagement, auch das sind unsere Kunden. Sie haben aber nicht einen BU-übergreifenden Anspruch, sondern brauchen eine Aussage darüber, was sie ihr Projekt, ihr konkretes Vorhaben kosten wird; unter anderem also, wie viele Leute sie voraussichtlich brauchen. Dafür erhalten Sie eine entsprechende Kostenplanung mitgeliefert.

Welche Zielgrößen - Innovation, Qualität, Kosten oder Termine - standen bei der Einführung im Vordergrund?

Damals stand die Kostensicht im Vordergrund, also die Anzahl der Köpfe. Dabei ist es letztendlich auch geblieben. Denn wenn wir über Kapazität sprechen oder über Ressourcen, dann sprechen wir zwar immer über Menschen, aber aus Managementsicht eben auch über die Kosten, die sie verursachen. Wir verplanen allerdings nicht zentral einzelne Mitarbeiter fest auf Projekt X, Y oder Z. Dafür sind wir trotz eines Pools von mehreren hundert Entwicklungsmitarbeitern, aber eben auch einer entsprechenden Anzahl an Projekten, zu kleinteilig aufgestellt. Ich kenne die mitarbeiterbezogene Planung nur von wirklich großen Unternehmen mit vielen Mitarbeitern mit vergleichbaren Fähigkeiten je Business Unit oder mit wenigen, dafür aber relativ großen Projekten. Das ist bei Pierburg nicht üblich. Wenn Sie aktuell nur einen Konstrukteur haben, der zum Beispiel das CATIA-V5-System beherrscht, dazu die Sprache des Kunden X perfekt spricht und auch noch das entsprechende Know-how für ein Produkt Y hat, dann wird er in allen entsprechenden Projekten die Spezialaufgaben übernehmen. Da lohnt es sich nicht mehr, kleinteilig jede Spezialaufgabe auf die einzelne Person herunterzuplanen. Die Projekte werden stattdessen flexibel in einer verantwortlichen Gruppe bearbeitet und dort unter den drei, vier oder fünf Leuten, die dem Ressourcenverantwortlichen zur Verfügung stehen, direkt vor Ort entsprechend den Fähigkeiten jedes Einzelnen gesteuert und geshiftet.

Wenn nach wie vor die Kosten im Vordergrund stehen, hat dann Ihr Kapazitätsmanagement nichts mit Innovationen und Terminen zu tun?

Die Termine sind natürlich Teil einer Kapazitätsplanung, klar. Aber die Innovation selbst kann man nicht über Ressourcen allein planen, das geschieht vor allem technologie- und strategieorientiert. Das Kapazitätsmanagement ist dann das Mittel, um Transparenz herzustellen, um zu zeigen, wo die Ressourcen gebraucht werden, damit Projekte abgearbeitet werden können und wo ggf. Ressourcen nicht mehr optimal genutzt werden.

Wie haben Sie im Vorfeld die Notwendigkeit für dieses System kommuniziert und die Einführung unterstützt?

Das ging im Gesamtprojekt 2004/2005 etwas unter. Es gab damals eine ganze Reihe von Neuerungen und das Ressourcenmanagement war eine unter vielen. Die Einführung unseres PEPs war ja ein ganzheitliches Projekt. Somit gab es keine separate Kommunikation dazu und andere Dinge standen im Vordergrund. Aus meiner Sicht als Teilprojektleiter, der für das Kapazitätsmanagement verantwortlich war, ist es aber ziemlich geräuschlos eingeführt worden. Das mag auch damit zu tun haben, dass die damaligen Entwicklungsverantwortlichen klar gesagt haben "Das ist jetzt so".

Wie wurde das Kapatool angenommen, ging man konstruktiv damit um?

In einer ersten Phase war nur der Kreis der Abteilungsleiter damit befasst, bei 12 bis 15 Kollegen noch relativ überschaubar. Sie, die zuvor mit eigenen Excel-Listen und anderen Tools planten, mussten von etwas Neuem überzeugt werden: einem Tool, das übergreifend funktioniert, einen Mehrwert bietet und das auch von einem Top-Management wahrgenommen werden kann. Außerdem bietet es den Abteilungsleitern eine Eintrittskarte in die Diskussionen um mehr Ressourcen. Daher war das relativ einfach. Es gab damals in allen Entwicklungsbereichen Koordinatoren, die das begleitet und die Leute an die Hand genommen haben. Diese Unterstützung ist auch heute noch sehr wichtig. Unsere Ingenieure planen ja nicht um des Planens willen oder um das Management glücklich zu machen. Man muss kommunizieren, dass das jetzt zum Aufgabengebiet dazugehört, aber nach meiner Erfahrung darüber hinaus auch im Prozess selbst laufend unterstützen. Wir haben heute als Pierburg GmbH im Wesentlichen einen Entwicklungsschwerpunkt. Das ist Deutschland mit dem Hauptsitz in Neuss, wo auch zwei unterstützende Mitarbeiter von mir vor Ort sind, sowie Berlin. Darüber hinaus haben wir insbesondere Standorte in den USA und inzwischen auch in Indien, wo Entwickler vor Ort beschäftigt sind. In Neuss können wir unsere Kunden im Tagesgeschäft persönlich bedienen, was sehr gut funktioniert. Mit den anderen läuft alles ebenfalls unproblematisch, aber eben über das Telefon, Webex-Konferenzen etc.

Was bedeutete die Einführung für die Schnittstellen und für die Prozesse?

Wir mussten damals die mittel- und langfristige Kapazitätsplanung neu gestalten - das war bei den Abteilungsleitern noch relativ einfach. Weitaus intensiver aber mussten wir für die Einführung der Kurzfristplanung werben. Hier bestand die klare Forderung, dass die Abrechnung, also die Ist-Stundenbuchung des Ingenieurs, in das Projektcontrolling integriert sein muss. Die Abbildung der Plan- und Ist-Welt in einem System bedeutete für uns in jedem Fall die Nutzung von SAP. Nun ist SAP eine Software von Profis für Profis. Für den Konstrukteur oder den Versuchsingenieur, der selbstverständlich seine Software am CAD-Rechner oder Prüfstand beherrscht, ist SAP meistens etwas Ungewohntes. Er möchte außerdem wissen, weshalb er aufschreiben soll, woran er gearbeitet hat, wenn man doch den Versuchsbericht sieht. Das gab Diskussionen ...

Und wie lautete die Antwort darauf?

Wir haben sehr viel Werbung dafür gemacht, denn jeder von uns sieht etwas Neues nicht ohne Weiteres ein, wenn dadurch für die eigene Tätigkeit kein Nutzen entsteht, sondern dieser erst anderen Orts generiert wird. Wir mussten klarmachen, warum es nun einmal auch zum Beruf eines Ingenieurs gehört, dass er seine Leistungen wie jeder Handwerker oder externe Dienstleister nachvollziehbar verrechnet. Letztendlich hat es dann funktioniert, zumal wir auch den Support dafür bieten konnten. Die Kollegen konnten sich in ein festgefügtes, von uns vordefiniertes System hineinfinden und wir haben viele Arbeiten für sie übernommen: Sie konnten weiterhin zum Beispiel in Excel arbeiten, wo sie sich wohler fühlten, und wir sorgten für die Schnittstelle zu SAP. Zwei Mitarbeiter von mir betreuen das auch heute noch und fügen zum Beispiel die Planung in SAP ein. Das hat sich bis heute bewährt. Der Konstrukteur kann uns beispielsweise fragen, welche Nummer für sein Projekt die richtige ist, und muss nicht in SAP suchen, sondern bekommt etwas Filterbares in Excel. Und auch der Project Manager, der sich nicht mit SAP befassen will, weil er mit der CAD-Welt oder den Versuchsberichten genug zu tun hat, kommt zu uns und erhält Support für seine Planung. Diese Zeit nehmen wir uns gerne auch deshalb, weil der Aufwand, allen die Bedienung von SAP beizubringen, um ein vielfaches höher ist, da die meisten Kollegen es zu selten anwenden - wir dagegen sind SAP gewohnt. Hier in Neuss können wir eine persönliche Betreuung bieten und die Berliner oder die Amerikaner können uns jederzeit anrufen - das funktioniert prima. Oder wir erhalten eine Mail, "mein Projekt ist jetzt in Phase X, ich brauche neue Arbeitspakete für die nächsten Monate, macht mal bitte ...!". Wir haben viel gelernt von unseren Projektverantwortlichen, können also ein "Mach mal bitte" recht schnell umsetzen.

Was waren die Rahmenbedingungen und Anforderungen, die Sie an eine Software für ein Kapazitätsmanagement gestellt haben und wer hat Sie bei der Anforderungserstellung unterstützt?

Was das SAP und die Kurzfristplanung betrifft: Das war Inhouse-Know-how. Ich kam 2003 aus einem Projekt, in welchem wir SAP R3 eingeführt haben und war der Verantwortliche für die Entwicklungsfunktionen. Und wenn man ein Modul PS, also Project System hat, ist es relativ leicht, daraus die notwendigen Dinge abzuleiten. Wir benötigten dafür kaum Programmierungen. Die anderen Rahmenbedingungen ergaben sich aus der bis dahin üblichen Durchführung und dem Controlling der Abrechnung, der Ist-Buchungen und der Kurzfrist-Planung. Damit war SAP gesetzt. Für die Mittel- und Langfrist-Sicht half es uns, von einem Beratungshaus ein Tool zu bekommen, wie das aussehen könnte. Das ist jetzt eine Excel-Lösung, VBA-programmiert. Es hätte aber auch jede andere Art von Software sein können, denn Pierburg stand damals komplett am Anfang. Wichtig war uns die Anbindung an SAP, außerdem mussten wir dezentral planen, die Daten aber zentral zusammenfassen und auswerten können. Durch die Business-Unit-Struktur brauchen wir jemanden, der übergreifend und auch neutral für eine Geschäftsführung Daten zusammen tragen konnte. Für uns ist es außerdem von Vorteil, viele Planungen zu machen. Da fragt man beim Projektverantwortlichen schon einmal nach: "bei ähnlichen Projekten habt ihr dafür Elektroniker gebraucht, braucht ihr die jetzt nicht mehr?" Mit unserer Erfahrung können wir für den einen oder anderen manchmal schon hilfreich sein. Auch das ist ein Vorteil bei einer zentralen Steuerung, wir bieten neutralen Support auch in dieser Hinsicht.

Wie lange hat der Einführungsprozess gedauert und wie viele Mitarbeiter waren damit beschäftigt?

Bei dem Mittel-Langfrist-Thema waren die genannten 12 bis 15 Abteilungsleiter betroffen, also die Ebene unterhalb der Business-Unit-Ebene. Damit waren wir in drei Monaten durch. Es gibt aber auch heute noch Kollegen, die aus einer anderen Funktion in die Program-Management-Rolle wachsen müssen und die wir jetzt bei dieser Art der Planung unterstützen.

Welche Organisationseinheiten und Fachdisziplinen werden über das Kapazitätsmanagement gesteuert?

Bei Pierburg sind das alle Funktionen, die in der Business Unit angesiedelt sind, außer Sekretariat und BU-Leiter. Somit also alle stundenschreibenden Mitarbeiter, vom Testingenieur über den Designer, den Konstrukteur, bis hin zu Program Management-Funktionen und den Projektleitern. Sie alle müssen sich selbst verplanen und im IST abrechnen. Die Business Units sind außerdem daran interessiert, einen Blick über ihre eigenen, internen Kosten hinaus zu bekommen: z.B. auf Simulation, Elektronik, Laborprüfstände - das sind ja alles Kostenfaktoren für die Projekte, die im Bedarfsfall mit geplant werden sollen.

Auf welcher Ebene wird geplant? Wie ist der Prozess angelegt und wer löst ihn aus bzw. steuert ihn?

In der Regel ist eine Planung für die einzelnen Produktentwicklungsprojekte vorhanden. Sie werden dann auf der Ebene der Produktfamilien und der Business Unit verdichtet. Zu Anfang eines Projektes machen meine Mitarbeiter gemeinsam mit den Projektverantwortlichen eine Planung, die dann auch Teil der "Deliverables" im Produktentstehungsprozess ist. Das dauert eine halbe Stunde, dann haben wir einen aktuellen Datenstand. Dieser ist zwar für das einzelne Projekt nicht dauerhaft gültig, aber in der Summe über alle Projekte dennoch nicht so schnell obsolet. Um alles aktuell zu halten, werden von uns dann revolvierend möglichst oft Planungsgespräche mit den Verantwortlichen geführt. Projekte werden hoffnungsvoll begonnen, der Kunde entscheidet sich dann doch für den Wettbewerber - so etwas fischen wir entsprechend raus. Außerdem können wir Änderungen im Projekt, die völlig überraschend von der Seite hereinschneien, auch schnell abbilden. Wir sprechen dabei nicht immer denselben Kollegen an, das machen wir als Neutrale schon aus eigenem Antrieb heraus nicht, um möglicherweise auftretende systematische Fehler auszuschließen. Daher fragen wir mal beim Projektleiter der Entwicklung, mal beim Program Manager nach und versuchen so, mehrere Sichtweisen hineinzubringen, um eine möglichst belastbare Planung zu bekommen.

Wie genau wird das mit dem Projektmanagement umgesetzt?

Wir arbeiten auf Projektebene, das ist unser Rahmen. Die Ressourcen planen wir dann pauschal monatsweise, nicht auf Tage, Stunden oder einzelne Arbeitsschritte - denn da würden wir bei laufend 300 bis 400 Projekten untergehen. Außerdem planen wir anonym, wie gesagt also nicht auf den einzelnen Mitarbeiter, sondern für die beschriebenen Funktionen.

Inwieweit hat die Einführung einer Kapazitätsmanagementsoftware ihre Erwartungen erfüllt?

Da Pierburg in der Vergangenheit immer gewachsen ist und wir ständig mehr und neuartige Projekte hatten, kann man nicht direkt ableiten, ob wir durch das Kapazitätsmanagement in einem bestimmten Bereich X Euro gespart haben. Das macht aus meiner Sicht auch keinen Sinn, denn es ist immer mehr Arbeit da, als man eigentlich Ressourcen hat. Allerdings: Wir sind profitabel gewachsen, also kann es so schlimm nicht gewesen sein. Mit einer Kapazitätsplanung kann ich aber sehen, wo meine Ressourcen letztendlich eingesetzt werden. Habe ich profitable Produktgruppen, in denen ich die Masse meiner Ressourcen einsetze? Es bedeutet eine große Überwindung für einen Abteilungsleiter zu sagen, ich habe hier Kapazitäten, die könnt ihr anderswo einsetzen - das tut im Normalfall keiner. Es bedarf deshalb einer Versachlichung und Transparenz, wenn beispielsweise immer mehr Ressourcen verplant werden, die Umsatzentwicklung in der Produktfamilie aber nach unten geht - und genau das ist ein Teil der Möglichkeiten mittels des Kapazitätsplanungstools. Ich kann erkennen, dass sich bestimmte Entwicklungen abzeichnen. Als wir zum Beispiel eine bestimmte Produktgruppe abbildeten, deren Lebenszyklus-Höhepunkt überschritten war, stellten wir fest, dass wir zusätzliche Ressourcen zur Verfügung hätten stellen müssen, weil der Markt die nächste Generation erwartete. Dieser Abgleich zwischen der Bedarfsplanung und dem, was zur Verfügung steht - dafür ist eine Kapazitätsplanung sehr wohl geeignet! Aber kein Tool ist unersetzlich, das gilt auch für SAP. Die Frage ist nur, wann brauche ich es, wie oft und welchen Stellenwert messe ich einem Tool bei. Die Kapaplanung ist immer nur ein Mosaiksteinchen im Gesamtbild, und das ist auch gut so.


Über den Interviewten
Diplom-Kaufmann Helmuth Schneider, startete nach dem Studium an der Universität Köln seine berufliche Karriere 1997 bei Pierburg in Neuss. Als Abteilungsleiter im Serienvertrieb wechselte er 2002 für zwei Jahre in ein internes SAP-Migrationsprojekt, in dem er als Projektleiter die erfolgreiche Anpassung der damaligen Prozesse und IT-Lösungen der Produktentwicklung bei Pierburg an das SAP R/3 verantwortete. Nach einer weiteren Station in der Entwicklung im Produktbereich Pumpen übernahm er 2005 schließlich innerhalb eines zentralen Bereichs die Verantwortung für die Bereitstellung einer Reihe von Services und Funktionen für die Entwicklungsbereiche. Dazu gehören neben dem Ressourcenmanagement in der Entwicklung inzwischen auch eine übergreifende Verantwortung für den Product Development Process (PDP) bei Pierburg und das Product Lifecycle Management (PLM).

Aus Der F&E Manager» :: 04/2012

Ausgewählte Artikel
Ausgewählte Stellenangebote