pantrag_fisi Projektantrag: Umzug DHCP-Scopes (Brauche Feedback)

[Leon99z]

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

[allesweg]

Threadtitel gelesen --> das wird ein Arbeitsauftrag.

Rest überflogen --> bestätigt.

[Leon99z]

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

[charmanta]

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

[ickevondepinguin]

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.

[Leon99z]

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

[ickevondepinguin]

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]

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.

 

[charmanta]

das sollte nun durchkommen ... auch wenn da immer noch der MS Begriff steht

[Leon99z]

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!

[ickevondepinguin]

Ich sehe das wie @charmanta - so ist es durchaus genehmigungsfähig.  

[Leon99z]

Danke euch für die Kritik  
Denke das hilft Einigen beim Verständnis.

Bearbeitet 11. Januar von Leon99z