Hallöchen,
ich würde als Lieferant ein altes Projekt nur dann auf die neue Version hochziehen, wenn der Kunde dies vorschreibt und er selbst das EPLAN-Projekt mit der Enddoku verlangt. In diesem Fall würde ich allerdings das aktuelle P8-Projekt vom Kunden geben lassen und nicht auf dem Stand meines Projekts aufbauen - wer weiss, was der Kunde in der Zwischenzeit verändert hat. Braucht der Kunde kein P8-Projekt, würde ich es einfach weiterbearbeiten, selbst dann, wenn inzwischen die EPLAN Version höher ist. Ändern würde ich im bestehenden Teil nur solchen Sachen, die unbedingt notwendig sind. Zum Beispiel würde ich die Funktionsdefinitionen der Klemmen der 1.9-er Version NICHT gegen die der 2-er Version austauschen. Eine Neukonstruktion von alten Projekten kommt für mich - wenn überhaupt - nur in Verbindung mit Übernahme aus EPLAN 5 infrage.
Ich glaube aber, die Frage muss auch differenzierter beantwortet werden. Es gibt zunächst eine gesetzlich vorgeschriebene Aufbewahrungsfrist für die Konstruktionsunterlagen. Ob das im Originalformat oder nur als PDF oder gar nur auf Papier erfolgen soll, ist teilweise umstritten. Anderseits dienen alte Projekte oft als Kopiervorlage für neuen. In bestimmten Geschäftfeldern wird eine strikte Revisionsverwaltung verlangt, die teilweise sogar den Zugriff auf den vorherigen Stand für notwendig macht. In anderen Bereichen wird durch Validierungsprozesse auf eine saubere Versionierung sehr großer Wert gelegt.
Der springende Punkt ist jedoch, was mit den abgeschlossenen Projekten im eigenen Unternehmen passiert bzw. wie oft müssen diese nochmal angefasst werden. Und genau hier können sich unterschiedliche Argumente und Nöte ergeben, je nach dem, ob man Lieferant oder Betrieber einer Anlage/Maschine ist. Für den Anlagen-/Maschinenbetreiber hat die Aktualität und Richtigkeit der Pläne die absolute Priorität. Für ihn spielt die Version des Konstruktionstools - zumindest im Elektrobereich - meistens eine unerhebliche Rolle.
Für den Lieferanten kann es durchaus sinnvoll sein, Projekte immer auf die aktuelle Version hochzuziehen - sogar die bereits abgeschlossenen Projekte. Besonders dann, wenn diese sehr oft als Grundlage für neue Projekte herhalten.
Vorteil: die Pflege mehrerer Versionen entfällt, die besonders auf lägere Sicht einen nicht unerheblichen Aufwand bedeuten kann - wenn nämlich auch das alte Betriebssystem oder gar die Hardware, auf der das BS noch läuft, vorgehalten werden muss.
Nachteil: Die auf neuere Version übernommene Projekte müssen ggf. angefasst werden. Hier müsste allerdings der Aufand der Anpassung und der tatsächliche Nutzen durch die Änderung gegeneinander abgewogen werden.
Selbst für Lieferanten lohnt es sich aber nicht immer, die abgeschlossenen Projekte zu aktualisieren. Es gibt ja auch technischer Fortschritt, Kundenvorschriften können sich grundlegend ändern, Versionen werden aus der Freigabeliste gestrischen, usw. Wenn die techischen Rahmen sich relativ schnell ändern, macht die weitere Aktualisierung der alten Projekte irgendwann keinen Sinn mehr. In solchen Fällen kommt es sowieso zur Neukonstruktion, die aber nicht mehr aus der alten hervorgeht, sonder komplett neu entwickelt wird. Optimalerweise kann dies mit einer Versionswechsel verbunden werden.
Was aber kein Konstrukteur freiwillig tun sollte, ist, Plattformupdate im laufenden Projekt durchzuführen. Das kann in ungünstigen Situationen zu einem großen Projektrisiko werden. Das Projekt daher noch im bisherigen System zu Ende führen und erst nach Projektabschluss darüber entscheiden, ob das Projekt in die neue Version hochgezogen wird. Wann und wie sich das lohnt, dafür gibt es leider kein Patentrezept.
Noch eine Gedanke zum Schluss: eine neue Version vom P8 enthält bestimmte Features, die für die Anwender unterschiedlich wichtig sind. Die Auswirkungen eines Updates hängen aber nicht nur davon ab, welche Funktionen genutzt werden, sonder auch von der Arbeitsweise! Schon bei kleineren Teams würde sogar eine vorherige Evaluierung der neuen Version durch ein Teammitglied viel Sinn machen. Er müsste die gewohnte Arbeitsweise und die bereits etablierten Automatisierungslösungen (Nummerierungen, Auswertungen, Beschriftungen, Prüflauf, evtl. Skripte) mit der neuen Version ausprobieren. Damit lassen sich eventuelle Schwierigketen frühzeitig erkennen, noch bevor die Version im Unternehmen ausgerollt wird und das Problem zum erheblichen Projektrisiko werden kann.
Gruß
Ferenc
------------------
Until you spread your wings,
you'll have no idea how far you can walk.
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP
Foren auf CAD.de (alle Foren)
| 
