Kabelmanagement am DESY .

1. Kabelmanagement am DESY.

2. Agenda • Projektziel • Projekthistorie • Projektablauf • Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung) • Systemeinführung • Produktivbetrieb • Ausblick und Randbedingungen • Erfahrungen

3. Projektziel • “Das KDS soll als Werkzeug der elektronischen Datenverarbeitung zur Unterstützung von Kabelinstallationen, Wartungsarbeiten, Reparaturen und deren Dokumentation dienen.“ D.h. es soll • Informationen über Kabel, Kabeltrassen, Verbindungen, verbundene Geräte, Auslastungen halten, • z.B. Engpässe oder Störungen verfolgen, • bei der Planung neuer Trassen und Schaltungen (Patchaufträge, Wegesuche etc.) unterstützen, • . . .

4. Betrieb Produktion Planung Entwurf Lebenszyklus eines Beschleunigerprojektes und Einsatz eines Kabelmanagement-Systems Planung Störungen Schaltaufträge Patchungen Berichte Neuverkabelung in Gebäuden Dokumentation I t

5. Projekthistorie • Juli 2006: Neuaufnahme des Projekts • bis Nov. 2006: Erstellung des Lastenhefts • Parallel: Marktstudie (Long-IT) • Ergebnis: • *Es gibt mehrere Anbieter, die die DESY-Muss-Anforderungen erfüllen können, d.h. die Systemauswahl muss(te) über eine Ausschreibung erfolgen. • *Es ist Anpassungsaufwand am System zu erwarten, um DESY-Anforderungen umzusetzen, daher ist die Auswahl eines geeigneten Systemanbieters mitentscheidend für den Erfolg des Projekts. • *System und Anbieter werden getestet im Benchmark.

6. Projekthistorie • Juli 2006: Neuaufnahme des Projekts • bis Nov. 2006: Erstellung des Lastenhefts • Parallel: Marktstudie (Long-IT) • Nov. 2006: Ausschreibung (Bekanntmachung des Vorhabens; EU-Verf.; Verhandlungsverfahren m. vorheriger Bekanntmachung) • Mrz. 2007: Systemtests mit 3 Firmen -> Funktionstest Empfehlung: Weiter geht´s!

7. Projekthistorie • Juli 2006: Neuaufnahme des Projekts • bis Nov. 2006: Erstellung des Lastenhefts • Parallel: Marktstudie (Long-IT) • Nov. 2006: Ausschreibung (Bekanntmachung des Vorhabens; EU-Verf.; Verhandlungsverfahren m. vorheriger Bekanntmachung) • Mrz. 2007: Systemtests mit 3 Firmen -> Funktionstest • Nov./Dez. 2007: Pilotphase (Pilot-Feinspezifikation I und Pilotinstallation) -> Handhabungstest • Feb.2008: Freischaltung der OOTB-KDS-Version für DESY und parallel Schulungen • Juli 2008: Fertigstellung der Feinspezifikation und Aufwandsschätzung • Bis Dez.2008: Erstellung eines Systementwurfs (FNT) und Umsetzung • Nov. 2008 - Januar 2009: Überprüfung der Umsetzung von DESY-Anforderungen am Testsystem (iteratives Vorgehen) • Feb. 2009: Freigabe eines an DESY-Anforderungen angepasstes KDS

8. Agenda • Projektziel • Projekthistorie • Projektablauf • Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung) • Systemeinführung • Produktivbetrieb • Ausblick und Randbedingungen • Erfahrungen

9. Von den Aufgaben... Zunächst wird ein (Schalt-) Auftrag geschrieben... ...dann zugewiesen...

10. ...über deren Abfolge... Der (Schalt-)Auftrag wird angelegt... ...auf Vollständigkeit geprüft... ...angenommen, umgesetzt... ...und zum Schluss abgenommen.

11. ... bis zur beschriebenen Systemoberfläche Welche Randbedingungen gibt es? Wie genau stellen wir uns den Vorgang „Auftrag anlegen“ vor?

12. Erstellung von Lastenheften durch „Verbalisierung“ des Modells mit Forderungen an z.B. Arbeitsabläufe Datenbankinhalte Masken und Berichte Funktionsumfang der Systemkomponenten Systemkonfiguration und -administration oder durch betriebliche Randbedingungen Arbeitsgrundlage für alle Projektmitarbeiter Spezifikationen

13. Tabellarische Auflistung aller Anforderungen aus dem Pflichtenheft Erfüllungsgrad durch gelieferte Systemsoftware ist vom Lieferanten vorab schriftlich zu fixieren Standardumfang, im nächsten Release enthalten, zu realisieren binnen x Tagen, nicht realisierbar, ... Der Leistungszusicherungskatalog wird Vertragsbestandteil ! Leistungszusicherungskataloge

14. Systemauswahl - Methode • Benchmark (bzw. Benchmarking (= Maßstäbe setzen)) als formalisiertes Konzept,nach der komplexe Leistungen von vergleichbaren Programmen gemessen und nach bestimmten Kriterien verglichen und bewertet werden…und zwar VOR Software-Kauf • Ausgeführt durch repräsentatives Anwenderteam • Voraussetzung für Projektplanung und -aufwandsschätzung • Ergebnis: Technische Fähigkeiten und Grenzen des KDS ermitteln, Konfigurationsaufwand und Erfüllungsgrad des Lastenhefts abschätzen, Projektrisiken ermitteln • Ablauf: Im Vorwege erhielt der Anbieter ein BM-Vorbereitungsexemplar (mit Themen) und Testdaten. Am BM-Tag wurden Aufgaben live am KDS vorgeführt. Basis war das BM-Durchführungsexemplar und mitgebrachte Daten. Das BM-Team bewertete vor Ort die vorgeführten Aufgaben.

15. Szenario „Point-to-Point-Connection“ Gebäude Building #16 #16 Gebäude #50 Building #50 R16 R16 R16 - - - 1 1 1 R R R 50 50 50 - - - 1 1 1 L1 L1 L1 L2 L2 L2 L L L 2 2 2 L L L 1 1 1 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a Cable 1 Cable 1 + + + SPS1 SPS1 SPS1 DW - 1 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b monitor monitor monitor sensor IN IN IN Spezialisierte Funktionalität Bldg. Geb. #16 #16 transormer transformer switchboard transormer transormer switchboard 10 kV 10 kV source source HV HV - - cable cable 10 kV MK MK MK - - - 2806D 2806D 2806D source consumer consumer consumer Systemauswahl ... und Benchmarkszenarien • point-to-point-connection Verbindung von Geb. 16 nach Geb. 50 • finde mögliche Verbindungen • generiere alle Patches • erstelle mehraderige Verb. • identifiziere angeschlossene Endgeräte • Spezialfälle • erkenne HV-Verbindungen durch Transformatoren usw. • verwalte Telefone und Tel.-Nr. • ...

16. ...einige Eindrücke von den Benchmarks • Benchmarktest mit Kandidatensystemen • Evaluierungsteam aus 10 künftigen Anwendern • Idee: Test-Szenarien auf allen Kandidatensystemen ausführen • zuvor Kriterien definieren, Zeitlimits setzen, Szenarien beobachten und Leistung bewerten • Ergebnisse nach Themen, Anwendern etc. aggregieren

17. Lizenz- u. Dienstleistungsverträge • Dienstleistungsvertrag beschreibt geplanten Projektumfang • erstes Projektergebnis: abgestimmte Feinspezifikation gemeinsam mit Systemanbieter erstellt • Lizenzvertrag basiert auf Feinspezifikation und tritt erst mit deren Abschluss und Umsetzung in Kraft • Hauptteil des Budgets wird erst nach Lizenzlieferung freigegeben • Vertragsmodell, das den Anbieter früh einbezieht (suspensiv verkettete Verträge) Dienstleistungs-vertrag (20% des ges. Volumens f. Pilot) Feinspezifikation m.Leistungszusicherungs- Katalog (LZK) Dienstleistungs- vertrag Wartungs- und Lizenzvertrag

18. Vorgehen bei der Systemeinführung Phase 1 (Pilotinstallation) Dokumentation der Verkabelung von DESY-Gebäuden (insbes. PETRA) • Meilensteine: • Lauffähiges KDS in der DESY-Softwareumgebung (OOTB) • Geschulte Anwender (begrenzter Anwenderkreis) • Dokumentierte Verkabelung (begrenzter Datenumfang) • Bewertete Pilotphase Phase 2 (Feinspezifikation) Erstellung einer Feinspezifikation (Pflichtenheft) gemeinsam mit dem Systemanbieter • Meilensteine: • Ausgearbeitetes und abgestimmtes Pflichtenheft • Definierter Umfang des Betriebs- und Wartungskonzepts • Definierter Umfang der Systemanpassungen gem. Spezifikation Phase 3 (Umsetzung) Bereitstellung eines DESY-spezifischen KDS • Meilensteine: • Betriebsbereites DESY-weit verfügbares KDS gem. Pflichtenheft • Geschulte Anwender

19. Durchführung der Pilotphase (Phase 1) • Pilotteam: Mitarbeiter der Fachgruppen MDI, MKK, IT, IT-TK, IPP • Vorbereitung: 3 Tage Schulung in der Handhabung des KDS von FNT (Command) • Durchführung: 10 Tage intensives Arbeiten am KDS unter fachlicher Betreuung sowie detaillierte Einweisung in weitere Themen durch Fa. FNT. • Abschluss: Bewertung zur Handhabung und Komfortabilität des KDS durch jeden Pilotteam-Mitarbeiter • Fachliche Kompetenz der FNT-Mitarbeiter • Zugriffsrechte, Benutzereinrichtung • Import von Stamm- und Bewegungsdaten • Berichte, Protokolle, Abfragen, Suche • Gruppenübergreifende Fremdverkabelung • Systemdokumentation • System-Handhabung • System-Vollständigkeit (FNT-Standard) • Visio

20. Ergebnis der Pilotphase (Phase 1) • Ziel: • Test des KDS bzgl. Handhabung, Nutzbarkeit (Usability) und Anpassungsfähigkeit im Rahmen von fachgruppenspezifischen Arbeitsabläufen, d.h. • schnelle und einfache Einarbeitung, • Gute Zusammenarbeit mit der Fa. FNT • effiziente, eingängige Anwendungsmöglichkeiten. • Test einer KDS-Installation in der DESY-Systemumgebung • Ergebnis: • Ein zufriedenstellendes Arbeiten am DESY mit dem KDS wird erwartet • Mehrwert für DESY durch das KDS • Endlich eine gruppenübergreifende Dokumentation von Kabeln und Verbindungen, z.B. Pilotherme • Das System erfüllt schon jetzt viele wesentliche DESY-Anforderungen • Einige DESY-spezifische Anforderungen (existieren) müssen dringend noch umgesetzt werden (insbesondere grafische Anbindung). • FNT erscheint als ein sehr kompetenter Partner, der in der Lage ist, diese Anforderungen zu erfüllen. Eine Durchschnittsnote von 2,34 für ein System „out of the box“ (bzw. commercial of the shelf COTS)

21. Abnahmeverfahren DESY-DEV DESY-TST • DESY-Anforderungen wurden in der Feinspezifikation (FSII) beschrieben und dienen DESY als Testszenarien, um die Umsetzung zu prüfen. • Die Projektleitung prüfte in einem Vorabtest, ob die Version zum Test für die Anwender geeignet ist. Ggf. werden gravierende Fehler umgehend von FNT behoben. • Die Anwender testeten die Version. Eine Fehlerliste wurde erstellt. • Die Abschlussprüfung erfolgt durch DESY. Ein Abnahme-Protokoll wird erstellt. vorab testen (DESY) gravierende Mängel [ nok ] beheben (FNT) [ ok ] Anwender testen (DESY) Fehlerliste erstellen Bugs fixen (FNT) [ ok ] Abschlussprüfung durch- führen und freigeben (DESY) Abnahmeprotokoll erstellen [ ok ] Freigegeben für Betrieb (DESY-PRD)

22. Fehlerliste • Die Fehlerliste klassifiziert die Fehler hinsichtlich der weiteren Bearbeitung. • Fehlerschwere/Severity: • Kat. 1: Systemfunktion nicht nutzbar, nur durch Systemänderung behandelbar • Kat. 2: Systemfunktion nicht nutzbar, durch Anleitung (Workaround) behebbar • Kat. 3: Systemverhalten fehlerhaft/fehlerträchtig • Kat. 4: Systemverhalten ergonomisch ungünstig • Kat. 5: nicht direkt mit Geschäftsprozess verbunden • Fehlerbehebung: • QS : Der Fehler fällt unter Qualitätssicherung und wird umgehend behoben • ignore : Der Fehler wird zur Zeit nicht weiter behandelt. • Zusatz : Der Fehler soll behoben werden, die Kosten trägt der Auftraggeber.

23. Abnahmeprotokoll • Wenn alle UseCases (oder Funktionen) mit „ok“ bewertet wurden, gilt die Programmversion als abgenommen. • Eine definierte Anzahl von kleineren Fehlern kann nachträglich beseitigt werde und schließt die Abnahme nicht aus.

24. Agenda • Projektziel • Projekthistorie • Projektablauf • Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung) • Systemeinführung • Produktivbetrieb • Ausblick und Randbedingungen • Erfahrungen

25. Zahlen... • DESY-Gruppen im KDS und Anwender im Juni 09 • MDI • MKK • IT • IT-TK • IPP • MPS • HASYLAB • MHF-E • MHF-P • MKS • MIN • HASYLAB-SHT • ZEUTHEN • EMBL Immer mehr Anwendern aus unterschiedlichen Gruppen arbeiten mit command. -> command wird für zunehmend interdisziplinäreAufgaben eingesetzt, teilweise über die Grenzen des Systems hinaus. • Read-Zugriff: 50 • Davon Voll-Zugriff: 39 • Davon KDS-Gruppenadmins: 19

26. Weitere Aufgaben • Schnittstellen-Umsetzung • Bestandsdaten-Erfassung (in Arbeit) • Update-Schulungen (geplant) • (Später auch Inhouse-Schulungen) • Anwendertreffen • Etc.

27. Umsetzung eines Anwendungsfalls im Geoinformations- und Facility Management System (GIS/FMS) Such-Maske Karte Stückliste/TGA-Bericht Raumnutzungs-Bericht Raumnutzungs-Anzeige

28. Weitere Aufgaben • Schnittstellen-Umsetzung • Bestandsdaten-Erfassung (in Arbeit) • Update-Schulungen (geplant) • (Später auch Inhouse-Schulungen) • Anwendertreffen • Etc.

29. Risiken und Abhängigkeiten • Verfügbarkeit der Projektmitarbeiter • Bestandsdatenerfassung als Folge-/Parallelaufgabe zur Einführung des Systems ist Voraussetzung für die gruppenübergreifende Arbeit. • Separates Projekt unter Leitung von MDI • Erweiterung von command durch Schnittstellen zu bereits eingesetzten Systemen für den Einsatz bei interdisziplinären Aufgaben. • Akzeptanz und Einhaltung der definierten Arbeitsabläufe Prozessorientierte Aktivitäten, (hierarchisches) Transaktionsmodell Kollaboratives Aktivitäten, „marketplace working“, Ad hoc- Prozesse, Netzwerkmodell

30. Erfahrungen • Betrachtung aller geplanten Nutzungen und deren Zusammenspiel im Vorfeld • hilft bei Definition des Projektumfangs • bezieht zukünftige Anwender früh mit ein und fördert die System-Akzeptanz • Rechtzeitige und intensive Einbeziehung der zukünftigen Anwender wichtig für Teambildung und Ausbildung • Sicherheit und Systemstabilität durch den Einsatz mehrerer Systemumgebungen für Entwicklung, Test und Produktiv-Programmversionen • Benchmarking als Systemauswahl-Methode • gibt gute Einschätzung des Systemverhaltens im späteren Einsatz bereits vor Einführung eines Systems • lässt Stärken und Schwachstellen des Systems frühzeitig erkennen • hilft bei Abschätzung der zu erwartenden Anpassungs- und Entwicklungsaufwände • Benchmark mit Testszenarien essenziell für Projektplanung, aber auch schwer durchsetzbar wegen (scheinbarer) Aufwände • Vertragsmodell (suspensiv verkettete Verträge) • bezieht Systemanbieter früh mit ein und schützt vor Spezifikation „am System vorbei“ • LZK schützt Kunden vor Packaging-Willkür des Herstellers

31. GIS/FMS andere KDS User + Systeminterfaces Kernel Repository Erfahrungen • Betrachtung aller Anwendungsfälle zur Systemintegration in eine vorhandene Softwarelandschaft • Integration: • Der Anwender sieht nur das User-Interface und ist nicht daran interessiert, unterschiedliche Software zu nutzen. • Die Integration muß sowohl auf Logik- und Datenebene (Datenimport und –austausch) als auch insbesondere auf der Oberfläche umgesetzt werden. • Eine “schnelle” Lösung betrachtet meist nur eine dieser Ebenen und erfüllt damit häufig nur Anwendungsfälle geringer Komplexität. Eine umfangreiche Nutzung und gute Akzeptanz der Software wäre damit nicht gesichert. • Objektbezogene Umsetzung ggü. prozessbezogener Abnahme • Abhängig von Erfahrung des Fertigers sind zusätzliche Testszenarien notwendig, die Verwendung der gefertigten (Teil-) Komponenten beschreiben (die ggf. nicht den def. Anwendungsfällen entsprechen) • Fertiger lernen beim Kunden 

32. Vielen Dank für Ihre Aufmerksamkeit! Andrea Robben Deutsches Elektronen-Synchrotron (DESY)Informationsmanagement, Prozesse, Projekte (IPP)Notkestraße 85 22607 Hamburg Tel. 040/8998 4946 andrea.robben@desy.de