Einbindung der Institute - Partizipationskonzept Kick-off Meeting Der Piloten für Publication Management Service 26. Januar 2006 Berlin, MPI Molekulare Genetik Ulla Tschida, Gerhard Beier Nutzbar unter den Bedingungen einer Creative Commons Lizenz Namensnennung-NichtKommerziell-Weitergabe unter gleichen Bedingungen 2.0 Deutschland

Warum Partizipation? „… (ist mir) zwischen dem eDoc-Team und uns Bibliotheksleuten ein befremdlicher Wandel zwischen dem anfänglichen eDoc – „Was können wir für Sie tun?“- zum aktuellen, überspitzt formuliert, aber meinen Eindruck wiedergebend, „Friss oder stirb“ (aufgefallen). Die Bibliotheksbedürfnisse waren doch ganz klar ausgedrückt in diesem Punkt (…) Hr. Brüggemann an eDoc Forum, 27.10.2004 Frühe Einbindung der Nutzer statt später Frust Transparente Entscheidungen statt unklarer Vorgehensweise Besser explizite Entscheidung gegen Funktionalitäten/Ideen statt gar keiner Information Miteinander verbessern statt sich alleine ärgern Dokumentierte Bedarfe statt verloren gegangener Ideen Kritik und Feedback rechtzeitig kanalisieren statt vor vollendete Tatsachen stellen

Einbindung der Institute in der Ausgestaltung des Projektes eSciDoc – Partizipation Bei Bedarf und für bestimmte Services: Expertise aus der MPG bzw. externen Partnern (zu Service oder Projekt allg.) Direktoren Partner eSciDoc Projekt-Management Direktoren Pilot-Institute eLib eLab Scholarly Workbench Publication Management Pilotgruppe Publication Management Partner: Entwicklung von klar definierten Software- Arbeitspaketen Piloten: Kontinuierliches Feedback zu Funktionalitäten der Software und Sicherstellung der technischen und organisationellen Einbettung des Service am Institut Pilotgruppe Scholarly Workbench Partner Pilotgruppe eLab Pilotgruppe eLib

Akteure – Partizipationskonzept eSciDoc Piloten (pro Service) Prüfen das Serviceangebot auf pragmatische Umsetzung im Institutsalltag Validieren und detaillieren Konzepte, Funktionalitäten, Workflows Prüfen Ideen zur Umsetzung des Service am Institut Testen den Prototyp Partner (pro Service, eventuell auf Projektebene) Übernehmen Arbeitspakete in der Software-Entwicklung Entwickeln im Rahmen von eSciDoc Open-Source Lösungen für institutsrelevante Bedarfe Weitere MPG Wissensträger – externe Akteure (pro Service oder auf Projektebene) Werden bei Bedarf eingeladen (Vorschläge durch Piloten oder eSciDoc-Team) Feedback zu Service oder Architekturkomponenten Komplementäres Feedback aus Wissenschaftsorganisationen Grundlage für mögliche Kooperationen

Akteure Pilotgruppe eines Service Pilotgruppe – verschiedenes Know-how, verschiedener Input Bibliothek IT Wissenschaftler, Forschungskoordinator Kontaktperson Ansprechpartner, Sprecher und Teilnehmer der Pilotgruppe Organisiert Meetings am Institut Holt Feedback von Institutsmitarbeitern ein, insbesondere vom Direktor Kümmert sich Rückkoppelung der Ergebnisse an das Institut, insbesondere an den Direktor Direktor Agiert als Mentor eines Service Wählt Teilnehmer für Pilotgruppe aus und stellt Personal frei Bleibt über Entwicklung des Service auf dem Laufenden (Minutes, Reports) Informiert Kollegen Schnittstelle zum sInfo Programm-Management (Konfliktstrategie)

Was erwartet eSciDoc von der Pilotierung des Service Publication Management? Serviceumfang und -konzept (inhaltlich, organisationell) sind validiert Grundlegende Konzepte sind sinnvoll und dem Institutsbedarf gerecht Beschriebene Funktionalitäten sind valide und umfassend Funktionalitäten und Konfigurationsmöglichkeiten mit hoher Priorität identifiziert Feedback beim Test von Prototypen Feedback beim Test der Konzepte zur Einführung und Unterstützung des Service

Was bedeutet das an Arbeit für die Piloten? Validierung der allgemeinen Servicebeschreibung Validierung von Nutzungsszenarien und entsprechenden Anforderungen Priorisierung der Anforderungen an die Funktionalitäten Beratung bei spezifischen Konzepten (z.B. Verwendung von Klassifikationen, Schnittstellen zu lokalen Systemen, etc.) Vorschlag für Einbindung von MPG- oder externen Wissensträgern (z. B. IT Experten, Bibliothekare Helmholtz) Testen von Prototypen Eingabe/Ablage von digitalem Material auf Prototyp Validierung der Konzepte für die Service-Einführung in der MPG

Was macht das eSciDoc Team? Vorbereitung der Materialien und Treffen mit den Piloten Vorbereitung der kritischen Fragen, die gelöst werden müssen Institutsbesuche bzw. regionale / themenspezifische Treffen Moderation der Treffen Dokumentation der Ergebnisse, Vorschläge und offene Fragen Vorbereitung der Berichte an die Direktoren (Abstimmung mit Pilotgruppe) Feedback-Kanal an eSciDoc Management und Entwicklung Rückkoppeln der Entwicklungsentscheidungen an Piloten

Was passiert mit den Ergebnissen? Ergebnisse der Treffen auf http://www.escidoc-project.de/ (geschützter Bereich für Piloten) Berichte an die Pilot-Direktoren über Kontaktpersonen, parallel über sInfo Berichte an eSciDoc Projektleitung bzw. Entwicklung Berichte ggf. an Lenkungsausschuss oder andere Gremien Geplant: Dokumentation von Feedback im „Issue-tracking tool“ (automatisiert den Prozess der Dokumentation und Nachvollziehbarkeit von Problemen/Anforderungen bzw. deren Lösung) Geplant: Change Request Prozess (Prozess-gestützte Strukturierung und Nachverfolgung von nachträglichen Änderungen bzw. Lösungsvorschlägen nach dem ersten Einfrieren der Anforderungen) Im Falle des Konflikts: Anforderungen der Piloten werden nicht umgesetzt wie gewollt, nicht so schnell umgesetzt, wie gewollt => Direktoren berichten an sInfo Programm bzw. sInfo Lenkungsausschuss

Zusammenspiel Entwicklung des Service – Input Piloten Service-Entwicklung Feedback von den Piloten Validierung des Service Ist der Service auf die Bedürfnisse meines Instituts abgestimmt? Report an Direktoren Report an eSciDoc Entwicklung Welche Detailanforderungen ergeben sich bei den wichtigsten Funktionalitäten? Report an Direktoren Report an eSciDoc Testreihen Report an eSciDoc Report an Direktoren Wie kann ich den Prototyp verbessern? Service-Einführung Report an eSciDoc und sInfo Wie wird der Service bestmöglich in den Institutsalltag integriert? Report an Direktoren Kann ich mit den Erfahrungen als Pilot andere Institute unterstützen? Betrieb

Zusammenspiel im Detail - Wie arbeiten wir zusammen? Diskussion im Kick-off Meeting Service-Beschreibung und grundlegende Konzepte Liste von Funktionalitäten (siehe Servicebeschreibung) – Identifikation von Basisfunktionalitäten Februar 2006 – einzelne Arbeitstreffen mit Piloten, zusätzlich themenspezifische AGs Themenspezifische Impulsfragen Validierung der ZIM-Ideen zum Thema anhand Nutzungsszenarien Detaillierung von entsprechenden Funktionalitäten Reihung von Funktionalitäten März 2006 – alle Piloten Abnahme Servicebeschreibung, inkl. Konzepte und Features Abnahme Nutzungsszenarien (USCs) und detaillierter Anforderungen Abnahme priorisierter, erweiterter Feature/Funktionalitätenliste Themenspezifische Impulsfragen – was fäält dazu ein? Keine Bedarfsanaylse – konkrete antworten zu konkreten Fragen

Vorgeschlagene Themen für Pilotentreffen/AGs Dateneingabe Qualitätssicherung Versionierung Persistent Identifier (Zitierfähigkeit) Prüfung Copyright-Lage (AG) Supplementary Material Darstellung, Ausgabe von Daten (Re-use) Import Researcher Workspace Zugriffsrechte Administration User Management Suche Integration NPS 5 (AG) Researcher Workspace, Re-use für Presse, Webmaster (AG)

Fallbeispiel Impulsfragen zu bestimmten Thema Thema „Dateneingabe“ Komplexität Eingabemasken? Quellen für Import? Normdatensätze, Klassifikationen? Affiliation-Collections? Eingabe/Auszeichnung Supplementary Material Mark-up, LaTeX, Unicode? Genre-Typen/Dokumentarten, Formate (Suppl. Material)? Persönliche Voreinstellungen / Affiliation Voreinstellungen? Konfigurationsmöglichkeiten?

Fallbeispiel Nutzungsszenario - exemplarisch Beispiel Nutzungsszenario „MPG Yearbook“ usc_pubman_yearbook

Fallbeispiel Nutzungsszenarien - Übersicht Siehe Materialien overview_usc_in_pubmanprocess

Pubman Workflow – 3 stages and appropriate usage scenarios Entering Data Quality and Rights Assurance Data usage Submission Quality Assurance Search Ingestion Rights Checking Export Reporting Catalogues MPG Yearbook Researcher WSP Baskets Three stages of workflow in PubMan: 1. Data entry (submission, ingestion) 2. Quality assurance 3. Usage of data for reports, views, websites, personal lists etc.

Description of additional processes & concepts Administration of PubMan Customization (MPI, Depts. etc.) Collection Admin User/Rights Mgt Affiliation Admin Workflow Supporting functionalities Citation Style Mgt Transformation Help System Messaging System Underlying concepts / functionalities Collection Concept Authority files Affiliation Concept Classifications Versioning Duplicate Check Persistent Identifier Statistics Research Usage

Grober Zeitplan – erste Meetings Validierung des Service- u. Funktionalitätsumfang 26.01.2006 Kick-off Meeting - Zielsetzung Validierung Servicebeschreibung Verständnis bei Piloten für grundlegende Konzepte Vorstellung Feature-, Funktionalitätenliste, → Bildung von Arbeitsgruppen Februar 2006 - Zielsetzung detaillierte Diskussion der Nutzungsszenarien, Konzepte u. Funktionaliäten mit entsprechenden Arbeitsgruppen. Feedback von Direktoren zur Servicebeschreibung einholen Anfang März 2006 - Zielsetzung Abnahme Servicebeschreibung, inkl. Konzepte und Features Abnahme Nutzungsszenarien (USCs) und detaillierter Anforderungen Abnahme priorisierter, erweiterter Feature/Funktionalitätenliste Entwicklung Testreihen …

Festlegung Arbeitsgruppen, Termine, Kommunikation Themenschwerpunkte pro Pilot Welche der Themenschwerpunkte sind kritisch an meinem Institut? Wozu kann ich bzw. meine Kollegen sinnvoll beitragen? Haben wir dazu gute / schlechte Erfahrungen gemacht? In welcher institutsübergreifenden Arbeitsgruppe kann ich mich sinnvoll einbringen? Terminoptionen im Februar Institutsbesuch (Anwesenheit Kontaktperson, restliche Pilotgruppe) Übergreifende Arbeitsgruppe (An-/Abreise, 1 Tag Workshop) Kommunikation Mailverteiler Kontakte oder alle Teilnehmer der Pilotgruppen? Webseite: http://www.escidoc-project.de/de/intern/index.html Geschützter Zugang über ID: escidoc-pilot; PW: p!lotescidoc Termine, Tagesordnung, Protokolle, Materialien, Übersicht Piloten geplant: online-Glossar Märztermin konsolidieren (spätestens 10. März) Konkrete beschreibung februar