Konstrukteur und Progammiere in selber Funktion.....die Eier legnde Wollmilchsau

Kann Programmierer und Konstrukteur in einer Person auch zukünftig realisiert werden?

  • Ja, konstruieren und programmieren ist durch eine Person sehr gut zu leisten.

    Stimmen: 20 62,5%
  • Nein, Programmierer und Konstrukteur in einer Person funktioniert zukünftig nicht.

    Stimmen: 12 37,5%

  • Umfrageteilnehmer
    32
  • Umfrage geschlossen .

chriss-chross

Level-1
Beiträge
40
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Konstrukteur und Progammiere in selber Funktion.....die Eier legende Wollmilchsau

Liebe Forenmitglieder,

gern würde ich einmal eure Meinung zur Funktion

des Programmierer und Konstrukteur in einer Person kennen.

Ich selbst bin reiner Hardware-Konstrukteur im Sonderanlagen-Schaltschrankbau.


Der Zeit suchen wir dringend Nachwuchs / Unterstützung.

Die Geschäftsleitung (BWL-Geführt) wünscht sich gern einen "Konstrukteurprogramierer".

Unsere Abteilung entgegnet diese Vorstellung.

Wir sind geschlossen der Meinung das nach heutiger und auch zukünftiger Entwicklung die Funktion Programmierer sowie Konstrukteur getrennte Personen sein sollten.

Es ist von unserer Seite her nicht mehr vorzustellen, dass ein Programmier und Konstrukteur, wie sie es vor einigen Jahren gab, noch Ihren Job so ableisten ableisten können wie es einmal war.

Die Gründe hierfür sind u.a. die rasante stätige Weiterentwickelung der Programme die Produkte und Tool/Werkzeuge. Welche von Programmierer und/oder Konstrukteur unabhängig angewendet werden müssen.

Allein die ständige Veränderungen der bei uns absolut notwendigen Programme wie das TIA-Portal und Eplan P8 bieten nach unserem dafürhalten keiner EINZELPERSON wirklich die Möglichkeit up-to-date zu bleiben.

Wie ist heure Meinung...oder besser......welche Argumente Sprechen für einen Programiererkonstrukteur und welche Argumente für einen Konstrukteur / Programmierer in getrennter Person?
 
Zuletzt bearbeitet:
Ich bin Programmierer und Konstrukteur in Personalunion.
Klappt gut.
Ich sehe darin sogar Vorteile: Es entfällt eine Schnittstelle, auf der Missverständnisse entstehen können und es muss nichts zwischen Konstrukteur und Programmierer geklärt werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin auch Programmierer und Konstrukteur, gefällt mir so sehr gut. Ich bin Ansprechpartner sowohl für die Elektriker in der Fertigung als auch für den Prüfstand / Inbetriebnehmer / Kunden und weiß jederzeit was gerade an der Anlage passiert und wo es klemmt.
 
Das kann nur funktionieren, wenn die Projektlaufzeit lang genug ist, um beide Arbeitsschritte nacheinander (von einer Person) abzuarbeiten.

Bei kleinen Anlagen macht das sicher sinn.

Bei komplexen Anlagen wird das sicher schwierig. Und zur Komplexität der Anlagen kommt auch noch die steigende Komplexität der Tools. Und dann kommen immer mehr Dokumentationsthemen. Bei uns dokumentiert der Elektrokonstrukeur die Sicherheit und der Softi schreibt die Betriebsanleitung. Die Risikobeurteilung schriebt wieder ein anderer (der alle Risikobeurteilungen schreibt).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich seh das genauso wie Aventinus: Es ergibt nur bei kleinen Sondermaschinen einen Sinn. In einer Maschinenbaubude funzt das so mehrheitlich nicht. In einem Produktionsbetrieb, wo die Sondermaschinen klein und schnucklig sind (Schnittstellenlösungen zwischen Maschinengruppen oder kleine Handlingeinheiten) ist die Personalunion durchaus sinnvoll.

Daher ist die generelle Frage oben eigentlich zu global und sollte differenzierter betrachtet werden.
 
Ich seh das genauso wie Aventinus: Es ergibt nur bei kleinen Sondermaschinen einen Sinn. In einer Maschinenbaubude funzt das so mehrheitlich nicht. In einem Produktionsbetrieb, wo die Sondermaschinen klein und schnucklig sind (Schnittstellenlösungen zwischen Maschinengruppen oder kleine Handlingeinheiten) ist die Personalunion durchaus sinnvoll.

Daher ist die generelle Frage oben eigentlich zu global und sollte differenzierter betrachtet werden.

Das ist genau der Punkt. Größe, Anzahl und Anlagentyp und Projektzeit sind die Faktoren ob dies alles durch eine Person gemacht werden kann.
Ich habe mal bei einem Kühlmittelfilteranlagenhersteller gearbeitet und habe dies alles als 1 Mann Abteilung gemacht. Und es wahren auch größere Anlagen dabei. Aber halt nur 1 oder 2 große pro Jahr.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"Konstrukteurprogramierer" = eierlegende Wollmilchsau mit Petersilie im Fell

Ist schon nachvollziehbar, dieser Gedanke der GF/Personalabteilung. Aber ein gutes Gegenargument ist immer: Ein Projekt kommt mit dem Ausfall dieser einen Person u.U. komplett zum Stillstand.

Maschinenbau ist eigentlich immer Teamarbeit. Gerade hab ich von einer Partnerfirma erfahren, wo die Firmenexistenz dezeit durch die Krankheit des einen, treibenden MA komplett auf dem Spiel steht.
 
Aber ein gutes Gegenargument ist immer: Ein Projekt kommt mit dem Ausfall dieser einen Person u.U. komplett zum Stillstand.

Also ein Argument wäre das nur wenn du statt einem Programmierkonstrukteur zwei Programmierkonstrukteure einsetzt. Denn wenn du Konstruktion und Programmierung trennst hilft dir der Konstrukteur nix wenn der Programmierer krank ist.

Es stehe sich ja immer 2 Themen gegenüber:

Programmierung/Konstruktion getrennt = besserer Durchsatz - schlechtere Auslastung
Programmierkonstrukteur = schlechterer Durchsatz - bessere Auslastung

Ich kann das aus BWL Sicht gut verstehen. Es kommt halt auf die Projektgröße und eigentlich auch auf die Abteilungsgrößen an. Wenn ich nur 2 Leute habe dann hat es schon Charme wenn beide beides können. Wenn ich 50 Leute habe brauche ich das weniger.
 
"Konstrukteurprogramierer" = eierlegende Wollmilchsau mit Petersilie im Fell

Ist schon nachvollziehbar, dieser Gedanke der GF/Personalabteilung. Aber ein gutes Gegenargument ist immer: Ein Projekt kommt mit dem Ausfall dieser einen Person u.U. komplett zum Stillstand.

Maschinenbau ist eigentlich immer Teamarbeit. Gerade hab ich von einer Partnerfirma erfahren, wo die Firmenexistenz dezeit durch die Krankheit des einen, treibenden MA komplett auf dem Spiel steht.

Da muss ich immer an den bus factor denken ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ein Argument wäre das nur wenn du statt einem Programmierkonstrukteur zwei Programmierkonstrukteure einsetzt. Denn wenn du Konstruktion und Programmierung trennst hilft dir der Konstrukteur nix wenn der Programmierer krank ist.
...

Das Unterschreibe ich alles sofort. Im Ergebnis sagt der BWLer: Aber zwei Leute können wir nicht einstellen.
Ziel ist es doch immer, sowenig Leute wie irgend möglich. Im Ergebnis haben wir dann in bestimmten Bereichen den niedrigen bus-factor (danke manseluk) mit seinen Folgen. In der Praxis ist natürlich der eine Schuld, und nicht die Firmenstrategie. Ist ja wohl klar.

Übrigens liest sich das auch ganz gut in diversen Stellenbeschreibungen. Mein Chef erntet von mir ein ignorantes Schulterzucken, wenn er auf die Bündelung von Know How in einer bestimmten Person abhebt. Ausbilden will er nicht und fertig Ausgebildete/Erfahrene, die für'n Appel und 'n Ei arbeiten, findet er nicht. Shit happens.
 
Ich schließe mich eigentlich den Worten von Aventinus an.
In meinen Augen ist dies ebenfalls ggf. abhängig der Größe der Projekte / des Unternehmens. Ebenfalls sollte die Durchlaufzeit als auch die nötigen Ressourcen der Projekte Betrachtung finden.

Natürlich besteht wohl auch ein Unterschied ob man dies auf ein Unternehmen oder z.B. Ing. Büro / Freiberufler betrachtet! Je geringer die Betriebsgröße desto eher diese EierlegendeWollmichSau …

Ich denke auch, bei kleineren Projekten ist dies schon möglich, Hard- und Software durch eine Person zu erstellen und kann auch Vorteile bringen. Mit steigender Größe der Projekte bzw. Projektlaufzeiten oder Komplexität der Anwendungen dreht sich dies aber in meinen Augen. Oft überlappen sich solche Projekte und dann solle mit der HW Erstellung begonnen werden, aber man ist noch an anderen Projekten gebunden. Ebenfalls sind z.B. Unterstützung des Service und Hotline zeitlich nicht zu verachten. Da macht es Sinn die Bereich HW / SW zu spezialisieren und die Ressourcen effektiver einzusetzen … Auch sollte man die zukünftige Entwicklung der Technik in unserem Bereich beachte, da ist ggf. ein spezialisieren weiterhin nötig!
Die ist in meinen Augen teils analog wie mit dem neuen Beruf „Mechatroniker“, in manchen Bereich Sinnvoll aber nicht überall …
Wobei ich aber dem Grundgedanken Konform gehe, beide Seiten sollten die Grundlage der anderen Seite verstehen.
 
Dieses Konstruktierenden-Programmierer hängt doch auch stark von der Ausrichtung
und Organisation der Firma ab. Bei einen Serienmaschinenbauer wird unter Umständen
nicht so stark konstruiert wie bei einem Sondermaschinenbauer, da ist es dann möglich
das die Konstruktionsarbeit mitgemacht werden kann.

Wenn jemand sein CAE System gut organisiert hat, besteht die Möglichkeit das die Schaltpläne
Automatisch aus der Auftragsbeschreibung erstellt werden können. Das gleiche gilt auch bei
SPS Programmen. Das habe ich mal bei einen Maschinenbauer gesehen > 2000 MA, da funktionierte
das.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich finde die Diskussion seltsam.
Bisher dachte ich, team ist die Grundlage für eine gute und erfolgreiche Arbeit.
Wenn man alles allein macht, dann schwimmt man in seiner Suppe und denkt die Welt gehört mir.
Wenn es Reibungsverluste gibt, sollte man zusammen ein Bier trinken, dann klappt es auch mit der Kommunikation.
Wenn ich einen Plan bekomme und meine Vorschläge nicht darin wiederfinde, dann bin / war ich oft sauer.
Doch da Änderungen nur zusammen stattfinden können, lernt man andere Ansichten kennen und dazu.

Mal von dieser Seite anschauen.


bike
 
Zurück
Oben