Leon99z Geschrieben 10. Januar Geschrieben 10. Januar (bearbeitet) Hallo zusammen, ich habe folgenden Projektantrag durch mehrere Ausbildungsverantwortliche absegnen lassen, hätte aber trotzdem gerne eure Meinung dazu. (Habe ihn so gut es geht anonymisiert) Freue mich auf Feedback! 1.* Projektbezeichnung (Auftrag/Teilauftrag) Umzug von Access Point DHCP-Scopes von einem Core-Switch auf einen lokalen Server mithilfe von IP-Helper Adressen samt Einrichtung einer Failover Konfiguration für einen Logistikstandort als Pilotprojekt für weitere Standorte 1.1.* Ausgangssituation Beschreibung der derzeitigen Ausgangssituation (IST-Zustand) Derzeit befinden sich in der Zentrale, den ANZAHL Logistikstandorten, den Zwischenlagern und den Kundensupportcentern jeweils Core-Switches mit den für den Standort bestimmten DHCP-Scopes, welche fest auf den Core-Switches angelegt sind. Im Lifecycle-Prozess für Core-Switches ist vorgesehen, dass die DHCP-Scopes immer nach Einbau neu auf den Switch konfiguriert werden müssen. Das Projekt fokussiert sich auf den Logistikstandort STANDORT. Der Standort verfügt noch über keinen lokalen DHCP-Server, welcher Scopes der Access Points hat. Für die dort laufenden Server wird ein Failover Konzept durch einen georedundanten externen Server in einem angemieteten Rechenzentrum betrieben. 1.2.* Zielsetzung Was soll nach Abschluss des Projektes erreicht/umgesetzt sein? (SOLL-Zustand) Die DHCP-Scopes für die Access Points sollen im Logistikstandort auf einen in der Nutzwertanalyse, sowie der wirtschaftlichen Analyse, ausgewählten lokalen DHCP-Server umziehen. Dieser muss mit einer Failover-Verbindung zu dem georedundanten externen Server gegen einen Ausfall abgesichert werden. Dies gewährleistet eine ausfallsichere Adressvergabe im Netzwerk des Logistikstandortes und reduziert den Wartungsaufwand durch beispielsweise einen Switch Tausch durch den Lifecycle-Prozess. 1.3. Konsequenzen bei Nichtverwirklichung Was wären die Konsequenzen, wenn das Projekt nicht wie geplant umgesetzt werden könnte? (ggf. Einfluss auf nachfolgende oder sich auf dieses Projekt beziehende Projekte?) Häufiges Neuanlegen der DHCP-Scopes durch den Lifecycle-Prozess Höhere Fehleranfälligkeit, da bei Ausfall des Switches auch die DHCP-Scopes verloren gehen Daraus resultierender Wartungsaufwand durch Pflege der Scopes auf allen in Deutschland verteilten Switches 2.* Projektumfeld/Rahmenbedingungen organisatorisch + technisch Das Projekt wird bei der UNTERNEHMEN am STANDORT im Auftrag des Projektbetreuers durchgeführt. Das UNTERNEHMEN ist der IT-Dienstleister des UNTERNEHMEN, einem (ausführliche Erklärung darüber, was das Unternehmen macht). Das UNTERNEHMEN ist hauptsächlich für die Sicherstellung des reibungslosen IT-Betriebs der Zentrale, der ANZAHL in Deutschland verteilten Logistikstandorte, der Zwischenlager, sowie Kundensupportcenter zuständig. Zudem werden an weiteren fünf Standorten in LAND und LAND Serversysteme zur Kommissionierung betrieben. Ebenfalls ist UNTERNEHMEN für die kontinuierliche Weiterentwicklung der IT zuständig, um dem Unternehmen mit neuster Technologie einen Wettbewerbsvorteil zu sichern. 3.* Projektplanung/Projektphasen/geplante Arbeitsschritte inklusive Zeitplanung ggf. inklusive Angabe der Meilensteine Analyse und Planung - insgesamt 10 Stunden - Ist Zustand -> 1 Stunde - Soll Konzept -> 2 Stunden - Lösungsansätze gegenüberstellen (DHCP zentralisieren) - > 2 Stunde - Wirtschaftliche Analyse und Nutzwertanalyse -> 3 Stunden - Zeitplan erstellen -> 2 Stunden Vorbereitung und Umsetzung - insgesamt 14 Stunden - Vorbereiten der ausgewählten Serverlösung -> 3 Stunden - Vorbereiten der Device-Verbindungen -> 2 Stunden - Übersicht über umzuziehende Scopes -> 1 Stunde - Umziehen der Scopes -> 7 Stunden - Einrichten der Failover-Verbindung -> 1 Stunde Testen und Projektabschluss – insgesamt 6 Stunden - Inbetriebnahme -> 1 Stunde - Testen der DHCP-Adressvergabe und des Failovers -> 3 Stunden - Go Live mit Vorortbetreuung -> 2 Stunden Dokumentation -> 8 Stunden Pufferzeit -> 3 Stunden Insgesamt: 40 Stunden 4.* Dokumentation/technische Unterlagen Welche technischen Unterlagen planen Sie ihrer Dokumentation später beizufügen? Die Dokumentation wird in Form eines Prozessorientierten Projektberichtes erstellt. Ein weiterer Bestandteil der Dokumentation ist ein mit Visio erstelltes Schaubild zu den relevanten Netzwerkstrukturen. Zudem werden Konfigurationsdokumentationen der relevanten Netzwerkstrukturen beigefügt. Prägnante Konfigurationseinstellungen werden jedoch aus Datenschutzgründen durch fiktive und farblich markierte Eingaben ersetzt. Bearbeitet 10. Januar von mapr Zitieren
allesweg Geschrieben 10. Januar Geschrieben 10. Januar Threadtitel gelesen --> das wird ein Arbeitsauftrag. Rest überflogen --> bestätigt. Zitieren
Leon99z Geschrieben 10. Januar Autor Geschrieben 10. Januar (bearbeitet) Danke! Das stimmt - da muss ich mich klarer von distanzieren. Hier wären die korrigierten Stellen: 1.* Projektbezeichnung (Auftrag/Teilauftrag) Auswahl einer Lösung für den Umzug von Access Point DHCP-Scopes auf einen dedizierten Server mit Failover Konfiguration als Pilotprojekt 1.2.* Zielsetzung Was soll nach Abschluss des Projektes erreicht/umgesetzt sein? (SOLL-Zustand) Die DHCP-Scopes für die Access Points sollen im Logistikstandort auf eine in der Nutzwertanalyse, sowie der wirtschaftlichen Analyse, ausgewählte Serverlösung umziehen. Jene Serverlösung muss mit einer Failover-Verbindung zu dem georedundanten externen Server gegen einen Ausfall abgesichert werden. Dies gewährleistet eine ausfallsichere Adressvergabe im Netzwerk des Logistikstandortes und reduziert den Wartungsaufwand. Bearbeitet 10. Januar von mapr Zitieren
charmanta Geschrieben 10. Januar Geschrieben 10. Januar Hm. Alleine der Begriff "Scope" ist meines Wissens nach nur von einem einzelnen Hersteller gebräuchlich. Um die Anforderung zu lösen braucht es weder Krähenblut noch Igelspei .... sprich eigentlich haut mich die Komplexität nicht vom Hocker. Ich persönlich bleibe dabei, Ablehnung. Aber ein PA besteht aus mehr Leuten, zb @Voller01 @skylakeoder @ickevondepinguin Mal sehen ob sie mich überstimmen Zitieren
ickevondepinguin Geschrieben 11. Januar Geschrieben 11. Januar vor 20 Stunden schrieb Leon99z: Projektbezeichnung (Auftrag/Teilauftrag) Auswahl einer Lösung für den Umzug von Access Point DHCP-Scopes auf einen dedizierten Server mit Failover Konfiguration als Pilotprojekt Du bennenst es in der in fett hinterlegten Zeile selbst: Auftrag/Teilauftrag. Es bleibt bei einem Arbeitsauftrag. Ich weiß zwar nicht welchen Hersteller @charmanta da bedenkt, aber ganz gewiss löst du hier kein Problem mit einem ganzheitlichen Lösungsansatz. Du willst nur weg von der Hardwareeigenen Lösung zu einer Serverlösung. Und das ist ein Arbeitsauftrag, kein Projekt. Wie kommt ihr darauf, dass ihr eine, auf einen Server laufende DHCP-Lösung benötigt? Genau das gilt es im Projekt herauszuarbeiten und dann Ansätze zu Vergleichen. Wäre bei mir auch eine Ablehnung. Zitieren
Leon99z Geschrieben 11. Januar Autor Geschrieben 11. Januar (bearbeitet) vor 28 Minuten schrieb ickevondepinguin: Du bennenst es in der in fett hinterlegten Zeile selbst: Auftrag/Teilauftrag. Es bleibt bei einem Arbeitsauftrag. Ich weiß zwar nicht welchen Hersteller @charmanta da bedenkt, aber ganz gewiss löst du hier kein Problem mit einem ganzheitlichen Lösungsansatz. Du willst nur weg von der Hardwareeigenen Lösung zu einer Serverlösung. Und das ist ein Arbeitsauftrag, kein Projekt. Wie kommt ihr darauf, dass ihr eine, auf einen Server laufende DHCP-Lösung benötigt? Genau das gilt es im Projekt herauszuarbeiten und dann Ansätze zu Vergleichen. Wäre bei mir auch eine Ablehnung. Die Formulierung "Auftrag/Teilauftrag" stammt tatsächlich vom offiziellen IHK Formular 😅 Das von @charmanta angesprochene Problem bezüglich der Benutzung des Begriffes "Scopes" habe ich behoben und es überall als "Bereiche" aufgeführt. Ich verstehe die Kritik - dann wäre es korrekt so zu formulieren, oder? "Auswahl einer Lösung für eine redundante, performante und konsistente Bereitstellung von DHCP-Bereichen" Oder noch neutraler/offener: "Neukonzeptionierung und Aufbau einer redundanten, performanten und konsistenten Bereitstellung von DHCP-Bereichen" Der Fokus soll auf dem Vergleichen in wirtschaftlicher sowie technischer Hinsicht liegen und es soll eine begründete Auswahl getroffen werden, verstehe ich. Aber wenn der Wille nach einer neuen Lösung (da die alte durch häufiges "Sterben" schlecht ist) nur der Arbeitsauftrag ist, wie würde man dann ein Projekt definieren? Da steige ich gerade nicht ganz hinter Bearbeitet 11. Januar von Leon99z Zitieren
ickevondepinguin Geschrieben 11. Januar Geschrieben 11. Januar (bearbeitet) vor 30 Minuten schrieb Leon99z: Der Fokus soll auf dem Vergleichen in wirtschaftlicher sowie technischer Hinsicht liegen und es soll eine begründete Auswahl getroffen werden, verstehe ich. Aber wenn der Wille nach einer neuen Lösung (da die alte durch häufiges "Sterben" schlecht ist) nur der Arbeitsauftrag ist, wie würde man dann ein Projekt definieren? Da steige ich gerade nicht ganz hinter Du sprichst es aus. Das ist das Problem! Die aktuelle Lösung ist instabil. Ihr sucht eine stabile Lösung, die folgende Kriterien (Liste) erfüllt. Und dann geht es in ein SOLL-Konzept das eure Kriterien aufgreift und ein Vgl. mehrerer Lösungen wird angestrebt. Man kann ja (gute!) Firewalls, die DHCP machen, auch redundant auslegen z.B. und das ganze entsprechend aufziehen, oder eben eure Serverlösung. Aber so wird ein Schuh draus. Formulier den Projektantrag einmal entsprechend neu, und stell ihn gerne noch einmal ein. Das SOLL-Konzept ist nat. für die Doku später - nicht im Antrag. Hier geht es bis zu den zu erfüllenden Kriterien. Sprich: Was wird bisher benutzt, was ist das Problem (instabil weil...), wir suchen eine bessere Lösung die folgende Kriterien erfüllt. Grobe Zeitplanung dran, und fertig ist der Antrag Bearbeitet 11. Januar von ickevondepinguin Leon99z reagierte darauf 1 Zitieren
Leon99z Geschrieben 11. Januar Autor Geschrieben 11. Januar vor 14 Minuten schrieb ickevondepinguin: Du sprichst es aus. Das ist das Problem! Die aktuelle Lösung ist instabil. Ihr sucht eine stabile Lösung, die folgende Kriterien (Liste) erfüllt. Und dann geht es in ein SOLL-Konzept das eure Kriterien aufgreift und ein Vgl. mehrerer Lösungen wird angestrebt. Man kann ja (gute!) Firewalls, die DHCP machen, auch redundant auslegen z.B. und das ganze entsprechend aufziehen, oder eben eure Serverlösung. Aber so wird ein Schuh draus. Formulier den Projektantrag einmal entsprechend neu, und stell ihn gerne noch einmal ein. Das SOLL-Konzept ist nat. für die Doku später - nicht im Antrag. Hier geht es bis zu den zu erfüllenden Kriterien. Sprich: Was wird bisher benutzt, was ist das Problem (instabil weil...), wir suchen eine bessere Lösung die folgende Kriterien erfüllt. Grobe Zeitplanung dran, und fertig ist der Antrag Danke! Das hilft mir enorm. Jetzt mit Fokus auf "Wir haben ein Problem und wollen es beheben, das sind die Kriterien und hier ist der Zeitplan" Hier die geupdatete Version: 1.* Projektbezeichnung Neukonzeptionierung und Aufbau einer redundanten, performanten und konsistenten Bereitstellung von DHCP-Bereichen 1.1.* Ausgangssituation Derzeit befinden sich in der Zentrale, den zwölf Logistikstandorten, den Zwischenlagern und den Kundensupportcentern jeweils Core-Switches mit den für den Standort bestimmten DHCP-Bereichen, welche fest auf den Core-Switches angelegt sind. Im Lifecycle-Prozess für Core-Switches ist vorgesehen, dass die DHCP-Bereiche immer nach Einbau neu auf den Switch konfiguriert werden müssen. Zusätzlich gibt es für die DHCP-Bereiche keinerlei Redundanz. Diese instabile Lösung führt zu einem hohen Wartungsaufwand und durch die fehlende Redundanz ebenfalls zu einem hohen Betriebsrisiko, da der Standort von einer fehlerfreien Adressvergabe abhängig ist. 1.2.* Zielsetzung Die auszuwählende Serverlösung soll redundant, performant und konsistent verfügbar sein. Um eine stabile Adressvergabe zu gewährleisten, sollen die DHCP-Bereiche im Logistikstandort auf eine in der Nutzwertanalyse, sowie der wirtschaftlichen Analyse, ausgewählte Bereitstellungslösung umzogen werden, da die derzeitige Lösung zu instabil und riskant ist. Somit soll eine ausfallsichere Adressvergabe im Netzwerk des Logistikstandortes gewährleistet und ein stark reduzierter Wartungsaufwand garantiert werden. Das Projekt soll sich auf den Logistikstandort STANDORT beziehen. 1.3. Konsequenzen bei Nichtverwirklichung Häufiges Neuanlegen der DHCP-Bereiche durch den Lifecycle-Prozess Bestehendes Betriebsrisiko wird nicht verringert Höhere Fehleranfälligkeit, da bei Ausfall des Switches auch die DHCP-Bereiche verloren gehen Daraus resultierender Wartungsaufwand durch Pflege der Scopes auf allen in Deutschland verteilten Switches 2.* Projektumfeld/Rahmenbedingungen Das Projekt wird bei der UNTERNEHMEN am STANDORT im Auftrag des Projektbetreuers durchgeführt. Das UNTERNEHMEN ist der IT-Dienstleister des UNTERNEHMEN, einem (ausführliche Erklärung darüber, was das Unternehmen macht). Das UNTERNEHMEN ist hauptsächlich für die Sicherstellung des reibungslosen IT-Betriebs der Zentrale, der ANZAHL in Deutschland verteilten Logistikstandorte, der Zwischenlager, sowie Kundensupportcenter zuständig. Zudem werden an weiteren fünf Standorten in LAND und LAND Serversysteme zur Kommissionierung betrieben. Ebenfalls ist UNTERNEHMEN für die kontinuierliche Weiterentwicklung der IT zuständig, um dem Unternehmen mit neuster Technologie einen Wettbewerbsvorteil zu sichern. 3.* Projektplanung/Projektphasen/geplante Arbeitsschritte inklusive Zeitplanung Analyse und Planung - insgesamt 10 Stunden - Ist Zustand -> 1 Stunde - Soll Konzept -> 2 Stunden - Lösungsansätze gegenüberstellen - > 2 Stunde - Wirtschaftliche Analyse und Nutzwertanalyse -> 3 Stunden - Zeitplan erstellen -> 2 Stunden Vorbereitung und Umsetzung - insgesamt 17 Stunden - Vorbereiten der ausgewählten Serverlösung -> 4 Stunden - Vorbereiten der Device-Verbindungen -> 2 Stunden - Übersicht über umzuziehende Scopes -> 1 Stunde - Umziehen der Scopes -> 7 Stunden - Einrichten der Failover-Verbindung -> 3 Stunde Testen und Projektabschluss – insgesamt 6 Stunden - Inbetriebnahme -> 1 Stunde - Testen der DHCP-Adressvergabe und des Failovers -> 3 Stunden - Go Live mit Vorortbetreuung -> 2 Stunden Dokumentation -> 7 Stunden Insgesamt: 40 Stunden 4.* Dokumentation/technische Unterlagen Die Dokumentation wird in Form eines Prozessorientierten Projektberichtes erstellt. Ein weiterer Bestandteil der Dokumentation ist ein mit Visio erstelltes Schaubild zu den relevanten Netzwerkstrukturen. Zudem werden Konfigurationsdokumentationen der relevanten Netzwerkstrukturen beigefügt. Prägnante Konfigurationseinstellungen werden jedoch aus Datenschutzgründen durch fiktive und farblich markierte Eingaben ersetzt. Zitieren
charmanta Geschrieben 11. Januar Geschrieben 11. Januar das sollte nun durchkommen ... auch wenn da immer noch der MS Begriff steht ickevondepinguin und Leon99z reagierten darauf 2 Zitieren
Leon99z Geschrieben 11. Januar Autor Geschrieben 11. Januar vor 6 Minuten schrieb charmanta: das sollte nun durchkommen ... auch wenn da immer noch der MS Begriff steht Stimmt! Verdammt Vielen lieben Dank für die Kritik! Zitieren
ickevondepinguin Geschrieben 11. Januar Geschrieben 11. Januar Ich sehe das wie @charmanta - so ist es durchaus genehmigungsfähig. Zitieren
Leon99z Geschrieben 11. Januar Autor Geschrieben 11. Januar (bearbeitet) Danke euch für die Kritik Denke das hilft Einigen beim Verständnis. Bearbeitet 11. Januar von Leon99z Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.