Pflichtenheft Digital Asset Management

Transkript

1 Pflichtenheft Digital Asset anagement Klassifizierung * Status ** Projektname Projektabkürzung Projektleiter Auftraggeber Autor Prüfende Genehmigende Kurzbeschreibung Nicht klassifiziert Abgeschlossen Projekt Output Services Peter Valentin SIS@BFS icha Roon Armin Grossenbacher Walter Grolimund BFS Ausschreibung für ein Digital Asset anagement System * Nicht klassifiziert, Intern, Vertraulich ** In Arbeit, In Prüfung, Abgeschlossen Änderungskontrolle, Prüfung, Genehmigung Version Datum Beschreibung, Bemerkung Name oder Rolle Feedback W. Grolimund. Roon, BA Architektur Feedback A. Grossenbacher, A. Nadeau und Ch. Blum. Roon, BA Architektur Initialversion. Roon, BA Architektur Reviewfeedback eingepflegt. Roon, BA Architektur «Die Projektführungsmethode HERES ist ein offener Standard der schweizerischen Bundesverwaltung. HERES wird vom Informatikstrategieorgan Bund (ISB) herausgegeben. Inhaberin der Urheberrechte an HERES und der arkenrechte am HERES-Logo ist die Schweizerische Eidgenossenschaft, vertreten d h d ISB

2 Definitionen, Akronyme und Abkürzungen Begriff / Abkürzung DA w2p Redsys DTP EIF IPTC DIA PD KD DWH POS SIS CS InfoObject Bedeutung Digital Asset anagement Web2Print Redaktionssystem Desktop Publishing Exchange Image Format International Press Telecommunication Council Diffusion und Amtliche Publikationen Produktdatenbank Konsolidierte Daten Datawarehouse Projekt Output-Services Statistical Information System Content anagement System Ein Informationsobjekt ist ein Baustein für eine Publikation. Es kann sich dabei um ein Bild oder eine Exceltabelle oder jedes andere elektronische Dokument handeln. 2/18

3 Inhaltsverzeichnis 1 Allgemeines Zweck des Dokuments Ausgangslage Projekt Output Services Tabellarische Daten aus dem DWH Artikel Qualitätsprüfung Anstoss und Gegenstand für die Beschaffung Projektbeschreibung und Rahmenbedingungen Schnittstellen Workflow Beschaffungsumfang Lizenz und Service Assurance Detailkonzepte Umsetzung Schulung Anpassungen Ist-Zustand Publikationen und Artikel Workflow Eingesetzte Systeme und odule Fazit Ist-Zustand engengerüst Ziele Hauptziel Quantifizierbare Ziele Nicht quantifizierbare Ziele Anforderungen Systemanforderungen Einsatzumgebung odule und Applikationen «uss»-kriterien Systemanforderungen Anbieterbezogene Anforderungen Erfahrung Projektvorgehen Zu erbringende Dienstleistungen Aufbau des Angebots Angebotsgliederung Administratives Vergütung für die Erstellung des Angebots Verfahren für die Bewertung der Angebote und beim Abschluss der Evaluation Allgemeine Geschäftsbedingungen Sprache des Angebots Vertraulichkeit, Rückgabe des Pflichtenhefts Rückfragen zum Pflichtenheft Angebotsabgabe Gültigkeit des Angebots Anhang /18

4 1 Allgemeines 1.1 Zweck des Dokuments Dieses Pflichtenheft beschreibt die Ziele, welche mit der angestrebten Lösung zu erreichen sind sowie die Anforderungen und Wünsche an das zukünftige System. Es dient als Grundlage für die Ausschreibung und es regelt das Vorgehen und die Form für die Angebotseinreichung eines DA-Systems beim Bundesamt für Statistik. 2 Ausgangslage 2.1 Projekt Output Services Das Bundesamt für Statistik verfolgt das Ziel eines integrierten Statistical Information System, welches im Programm SIS@BFS realisiert werden soll. Ein zentrales Anliegen dieses Vorhabens ist eine vereinheitlichte Infrastruktur. Zur Realisierung der entsprechenden Prozesse und Systeme wurden fünf Infrastrukturprojekte entlang der Wertschöpfungskette des BFS initialisiert. Die ersten beiden Projekte befassen sich vorwiegend mit dem Input ins BFS. Im Projekt DS geht es um die Kanäle ins System, um das anagement von Datenlieferanten und Erhebungen. Das Projekt SDAP befasst sich anschliessend mit der Aufbereitung der Daten. Die beiden folgenden Projekte, orientieren sich am Output. Im Projekt DWH wird ein Datawarehouse aufgebaut und es werden die Daten für die Produktion des Outputs vorbereitet. Das Projekt Output Services (POS) beschäftigt sich schliesslich mit der Erstellung und Verbreitung von Publikationen. Im fünften Projekt des Programmes SIS@BFS wird zusätzlich ein anagementsystem für etadaten realisiert. Das Projekt Output Services befasst sich mit den Prozessen der Publikation und Diffusion und realisiert entsprechende Systeme als Teil des integrierten statistischen Gesamtsystems. In diesem Zusammenhang, müssen alle Daten und Objekte verwaltet werden, die zur Publikation bestimmt sind. Die einzelnen Objekte sollen nicht nur gespeichert sondern auch auffindbar gemacht werden. Es soll auch möglich sein, die Herkunft von Daten in Publikationen im BFS Artikel genannt und die Verwendung von einzelnen Objekten in diesen Artikeln nachvollziehbar zu machen Tabellarische Daten aus dem DWH Bei den Daten, handelt es sich um strukturierte Daten, in einer Oracle Datenbank. Die Daten und ihre etadaten werden von dem Projekt DWH geliefert und in der sogenannten Produktdatenbank abgelegt. Aus dieser Datenbank, wird die jeweils letzte Version der Daten in einem Data-art abgelegt. Auf diesen Data-arts werden Abfragen durchgeführt, die in tabellarischer Form (Excel Tabellen) abgelegt werden Artikel Die Daten in den verschiedenen Data-arts unterstützen und belegen die Inhalte der Publikationen, die von den Autoren verfasst werden. Ein Artikel beinhaltet also Texte sowie Tabellen, Grafiken und Karten (zusammen InfoObjekte genannt) die aus dem Data-art generiert werden Qualitätsprüfung Jeder Artikel der das Amt verlässt, muss zwingen einer Qualitätskontrolle unterzogen werden. Die Kontrolle ist Aufgabe der Organisationseinheit (DIA), in deren Auftrag das System POS realisierst wird. 4/18

5 2.2 Anstoss und Gegenstand für die Beschaffung Anstoss für die Beschaffung ist das Bedürfnis den Arbeits- und Datenfluss besser verwalten zu können und die Erkenntnis, dass kein bestehendes System in Programm die geforderten Funktionalitäten anbietet, um InfoObjekte effizient zu verwalten und auffindbar zu machen. Aus diesem Grund sucht das BFS ein Digitales Asset anagement System als Standard Software mit entsprechenden Lizenzen, Wartung und Support, sowie die notwendigen Dienstleistungen zur Implementierung dieses Systems in die neu entstehende Systemlandschaft und die Schulung der betroffenen itarbeiterinnen und itarbeiter. Zusätzlich erwartet das BFS ein Angebot für Dienstleistungen zur Anpassung des Systems an die speziellen Bedürfnisse des BFS im Bereich der Workflows und Schnittstellen. 2.3 Projektbeschreibung und Rahmenbedingungen Das DA soll in eine Landschaft von Werkzeugen integriert werden, um als zentrales Repository für InfoObjekte und Artikel zu dienen. Folgende Abbildung zeigt die oben angesprochene Systemlandschaft: Das DA (mit gelbem Hintergrund) hat eine zentrale Rolle und es wird von den meisten Systemen genutzt. Die Schnittstellen sind mannigfaltig und setzen ein flexibles und offenes System voraus. 5/18

6 2.3.1 Schnittstellen Das DA soll anpassbare Schnittstellen zur Verfügung stellen, damit beliebige Systeme angebunden werden können. Beim Lesen und Schreiben aus dem und in das DA, ist von vorrangiger Wichtigkeit, dass die etadaten der InfoObjekte mitgegeben werden können Workflow Die Qualitätsprüfung ist ein Ablauf mit mehreren Schritten und sollt als solcher abgebildet werden. Es muss v.a. sichergestellt werden, dass der Inhalt des DA kontrolliert ist, damit die Informationen richtig und wiederauffindbar sind. 2.4 Beschaffungsumfang Die Ausschreibung für die Integration eines DA Systems in die SIS Systemlandschaft besteht aus verschiedenen Lieferobjekten: Lizenzen, Service Assurance (Softwareupdates), Wartung und Support für 4 Jahre Erstellung der Detailkonzepte für die Implementierung Umsetzung der Detailkonzepte Durchführung der Schulungen Anpassungen im Umfang von 20 Arbeitstagen In den folgenden Absätzen werden die Lieferobjekte weiter ausgeführt Lizenz und Service Assurance Das BFS erwartet eine Standard Software. Es soll eine Umgebung mit drei Servern aufgebaut werden, für Entwicklung, Test und Produktion wobei die Beschaffung der Infrastrukturen (HW und DB) nicht Teil dieser Ausschreibung sind. Auf dem Produktionsserver werden im ersten Jahr 50 Benutzer arbeiten. Die Benutzerzahl soll sich progressiv auf 200 erhöhen. Im Lieferpaket wird erwartet, dass die Software auf dem neuesten Stand gehalten werden kann und Bug-Fixes und Patches geliefert und installiert werden. Zusätzlich soll ein 2nd Level Support für Administratoren und Entwickler abrufbar sein. Im Angebot erwarten wir, dass die Kosten für Lizenz, Service Assurance, Wartung und Support für vier Jahre ausgewiesen werden Detailkonzepte Das Ziel der Detailkonzepte besteht in der Abbildung der Anforderungen des BFS an das Asset- anagement und die Detailkonzepte sollen Lösungen und einen gangbaren Weg für deren Umsetzung aufzeigen. Das Dokument besteht aus zwei Teilen: Systemspezifikation und Einsatzkonzept Umsetzung Nach Abnahme der Detailkonzepte kann die Umsetzung erfolgen. Die Umsetzung beinhaltet die Bereitstellung und Abnahme von 3 Lieferobjekten: Installation der Software, mit allen Konfigurationen und Erweiterungen Betriebshandbuch oder Handbücher Schulungsunterlagen für die Endbenutzer, Administratoren und Entwickler Schulung Die Durchführung der Schulungen soll primär der Ausbildung von Administratoren und Entwickler dienen. Es wird davon ausgegangen, dass das System intuitiv genug ist, damit die Endbenutzer mit einer Selbstschulung oder Fernschulung zurechtkommen. 6/18

7 2.4.5 Anpassungen Für mögliche Entwicklungen im Sinne von Anpassungen der SW an die heutigen und künftigen Anforderungen des BFS erwarten wir ein Angebot von 20 Arbeitstagen. Damit sollen v.a. Workflows und Schnittstellen realisierst werden. Der Abruf dieser Leistung geschieht nach Bedarf. 3 Ist-Zustand 3.1 Publikationen und Artikel Im BFS werden Artikel von den Fachsektionen verfasst und durch die Sektion DIA veröffentlicht. Bei den Autoren kann es sich sowohl um interne als auch um externe itarbeiter handeln. Damit die Qualität der Publikationen, seien diese elektronisch oder auf Papier, gewährleistet werden kann, wurde die Funktion bei der Sektion DIA zentralisiert. 3.2 Workflow Für die Herstellung der Artikel sind unterschiedliche interne und externe Teilnehmer mit unterschiedlichen Rollen und Aufgaben im Einsatz: Die Prozesse werden jedoch durch keine Software unterstützt und bleiben rein organisatorisches Konstrukt. 3.3 Eingesetzte Systeme und odule Ein CS für die elektronisch verteilten Artikel ist im Einsatz und soll auch in der Zukunft als eigenständiges System bestehen bleiben. Um den Workflow der Artikelverfassung abzubilden und zu steuern, ist ein Redaktionssystem von censhare in der Einführungsphase. Dieses Redaktionssystem muss eng mit dem DA verknüpft werden, da das erstere die meisten Verknüpfungen zwischen den InfoObjekten des letzteren herstellen soll. 3.4 Fazit Ist-Zustand Keine automatisierte Überwachung und Integration der Prozesse Fehlende Integration der Systeme CS und RedSys. Keine zentrale Ablagestelle für die Artikel und deren InfoObjekte. 3.5 engengerüst Es werden ungefähr InfoObjekte im Jahr erstellt, die auch veröffentlicht werden. Es ist davon auszugehen, dass nochmals so viele InfoObjekte als Zwischenstufen für die Publikation erstellt werden müssen. Das Daten-Volumen der InfoObjekte beträgt jährlich 100 GB. 4 Ziele it der Beschaffung eines zentralen DA und weiteren Crossmedia-odulen soll einerseits die definierte Einsatzstrategie vollzogen werden und andererseits eine entsprechende Wirtschaftlichkeit erzielt werden. Prioritäten: 1 = hoch, 2 = mittel, 3 = tief (weniger dringend, nice-to-have). 7/18

8 4.1 Hauptziel Historiographische Aufbewahrung der Publikationsdaten und Zur Verfügungsstellung der Dateien an BFS Interne Benutzer. Für jede Datei muss es möglich sein, mehrere Versionen zu speichern und etadaten zu verwalten. 4.2 Quantifizierbare Ziele Ziel Wahrung der Information der Datenkette. Herkunft der Daten Dokumentation der Benutzung der Produzierten Information Geordneter Ablauf der Informationslieferung Priorität Kriterien, essgrössen 2 Die InfoObjekt-Inhalte sollen zu ihrer Quelle (Data-art, Autor) zurückverfolgt werden können. 1 Für jedes InfoObjekt ist es möglich zu wissen in welchem Artikel es benutzt wird und jeder Artikel kann ausweisen welche InfoObjekte er benutzt. 1 Keine Lieferung per . Integration mit dem Publikationsablauf 2 Die Integration kann automatisiert werden Speicherung und Verwaltung von Dateien in mehreren Versionen mit Publikationsdaten. Verwaltung der etadaten für die gespeicherten Dateien nach Asset-Typ 1 Jede Version der Dateien ist wieder auffindbar und aufrufbar in der gewünschten, mediengetrennten Publikationsform (elektronisch oder Print oder CD, usw.) 1 Jeder Asset-Typ (Exceltabelle, Grafik, etc.) kann unterschiedliche etadatenfelder zugeteilt bekommen, nach denen gesucht werden kann. 4.3 Nicht quantifizierbare Ziele Ziel Schaffung einer zentralen Stelle um Informationen zu suchen und abzulegen Priorität Kriterien, essgrössen 1 Die Informationen betreffend integrierten Statistiken sind im DA auffindbar Beschleunigung des Publikationsablauf 2 Tatsächliche Zeit und Aufwand-essungen Verbesserung der Qualität der etadaten für die gelieferten Artikel und InfoObjekte. 1 Wie oft müssen die etadaten von den DIA itarbeiter, nach der Lieferung, angepasst werden. 5 Anforderungen Grundsätzlich wird unterschieden zwischen uss- und Kann-Kriterien. Die uss-kriterien müssen zwingend erfüllt sein und die geforderten Angaben in der Offerte gemacht werden. Die Kann-Kriterien sind nicht zwingend für den Erfolg des Projektes können aber die endgültige Lösung dennoch stark beeinflussen. Angaben zu den Kann-Kriterien sollten durch die Anbieterin wenn möglich gemacht werden. Es wird davon ausgegangen, dass die Anforderungen ohne Entwicklungsaufwand umgesetzt werden können. Es ist klar, dass gewisse Anpassungen notwendig sein werden. 8/18

9 Legende: A Absolutes uss-kriterium uss-kriterium K Kann-Kriterium Die Anforderungen sind in den verschiedenen Anforderungskatalogen zusammengefasst. Die Erfüllung der einzelnen Anforderungen muss durch die Offertsteller zwingend beantwortet werden. Die Antworten werden eine bedeutende Rolle spielen bei der Bewertung der eingereichten Offerte. 5.1 Systemanforderungen Die Systemanforderungen beziehen sich auf die Funktionsumgebung der angebotenen Lösung. Das heisst: Die Anforderungen betreffend den Betriebssystem und Rechner. Diese sind als A Kriterien zu verstehen Einsatzumgebung Die Lösung wird voraussichtlich beim Bundesamt für Informatik und Telekommunikation (BIT) betrieben. Das BIT setzt für Lösungen wie diese, virtuelle Server auf. Die virtuellen Server sind entweder Windows mit.net oder Linux mit Java EE basiert. Die beiden Plattformen sind in der Folge beschrieben..net Plattform:.NET Framework 3.0 / 3.5 Beschreibung.NET Integrationsumgebung für kundenspezifische Fachanwendungen auf einer standardisierten icrosoft- Plattform Technologie Authentisierung, Autorisierung Access und Identity anagement Lösung BIT mit LDAP-Verzeichnis. Active Directory nur im BV Netz verfügbar Präsentations- und Applikationsschicht icrosoft.net 2.0 / 3.5, icrosoft IIS Betriebssystem icrosoft Windows Server 2003, virtuelle Instanzen auf VWare ESX-Server Datenbank SQL Server 2005 icrosoft Weitere mögliche Datenbanken (in begründeten Oracle 11g (Unix) Fällen) Storage Hitachi High-End und idrange über SAN Datensicherung Veritas NetBackup Überwachung Patrol Sicherheit Normale Sicherheits-Infrastruktur des BIT (Virenschutz, Patch-anagement, PKI-Einsatz möglich, usw.) Verfügbarkeit Standard-Betrieb im BIT mit 98% Verfügbarkeit Höhere Verfügbarkeit ist mit geeigneten assnahmen im Windows und VWare ESX-Umfeld erreichbar Netz-Domaine BV-Netz Verfügbar SSZ Wird 2009 aufgebaut ETZ (DZ) verfügbar 9/18

10 Java Plattform: Java Runtime 1.4 / 1.5 Beschreibung Java Integrationsumgebung für kundenspezifische Fachanwendungen im Unix/Linux-Umfeld mit Oracle- Datenbank Technologie Authentisierung, Autorisierung Access und Identity anagement Lösung BIT mit LDAP-Verzeichnis. Clustering HW-Loadbalancer F5 BigIP Präsentation und Integrationsschicht Oracle Weblogic Server Integrationsschicht Oracle Service Bus 2.5 Betriebssystem SUSE Linux SLES 9/10, virtuelle Instanzen auf VWare ESX-Server Datenbank Oracle 10.2 (Unix) Weitere mögliche Datenbank (in begründeten IB DB2 9.x (z/os) Fällen) SQL Server 2005 icrosoft Storage Hitachi High-End und idrange über SAN Datensicherung Veritas NetBackup Verfügbarkeit Überwachung Sicherheit DIE Oracle Weblogic un den verschiedenen Netzzonen werden all auf einer virtualisierten Plattform (SUS Linux auf VWare ESX) betrieben. Die Anpassung an Ressourcenbedarf und Verfügbarkeit kann dynamisch erfolgen. Durch den Einsatz von HW-Loadbalancern wird gewährleistet, dass pro Dienst immer mehrere Server zuständig sind. Für höchste Ansprüche an die Verfügbarkeit können mit dem Weblogic Cluster zusätzlich die Sitzungsdaten von Webapplikationen in Echtzeit repliziert werden, damit bei einem Hardwareausfall mit der Webapplikation nahtlos weiter gearbeitet werden kann. Patrol Die eingesetzte Technologie ermöglicht es, alle Teilstrecken bezüglich Integrität und Vertraulichkeit zu schützen (Einsatz von Kryptographie und SAL- Token) Die technisch mögliche Verfügbarkeit liegt bei 99.8% Netz-Domaine BV-Netz Entwicklung, Test, Referenz, Abnahme, Schulung, Produktion. SSZ Wird 2009 aufgebaut ETZ (DZ) verfügbar odule und Applikationen Das Asset anagement System beinhaltet folgende Teile: Applikationsserver für die Funktionalitäten: o Speichern o Lesen / Editieren o Suchen o Workflowmanagement o Indexieren / Freitextsuche 10/18

11 Datenbankserver für die Speicherung der Assets o Oracle 11g oder Filesystem basiert Client der das GUI zum DA anbietet o Assets Navigieren, Suchen, Editieren, Lesen o etadaten verwalten und ergänzen o Workflow: Bearbeitung der Aufgaben Eine Administrationsschnittstelle o Benutzer und Rollen Verwaltung o Zugriffsrechte bewirtschaften o Workflow-Verwaltung und Entwicklung 5.2 «uss»-kriterien Nr Anforderung Beschreibung Typ Kriterien oder essgrössen zur Bewertung der Zielerreichung 1. edia Asset anagement 2. etadaten- Verwaltung 3. User-Rollen und Rechteverwaltung 4. assenmutation in etadaten Strukturiertes und standardisiertes edia Asset anagement. Auf den Assets müssen diverse etadatenfelder sowie Schlagwortbäume gepflegt werden können. Suchfunktionen über alle etadaten (bei geänderten Dateinamen Suche via Dateiinhalten). ehrsprachig (deutsch, französisch, italienisch und englisch). Single-Sign-On über Active Directory Die assenmutation von etadaten in mehreren Digital-Assets muss möglich sein. A A A A Volltext-Indizierung sowie umfassende Strukturierungs-, Navigations- und Suchmöglichkeiten. Anlegen beliebiger Asset-Typen (einzelne Infoobjekttypen bis fertige Layouts und Ausgaben) Folgende etadaten/schlagwortbäume müssen einrichtbar sein: Objekt-etadaten (z.b. Auflösung, Datum usw.) Freie etadaten (z.b. Autor, Data-art, Embargordatum, usw.) Schlagwortbäume (z.b. die Zuteilung von Kategorie, Inhaltsbeschreibung usw.) automatische Übernahme von EXIF bzw. IPTC-Daten Einlesen von etadaten in einer etadatendatei. Die etadatendatei wird mit der Asset Datei geliefert und dient ausschliesslich der etadaten. Selbständiges Verwalten von: Neuen Usern User-Gruppen- Zugriffs/Rechte Logins z.b. Veränderung von Verwendungszweck. Einzelimport und Serienimport (Batch) inkl. Über- 11/18

12 5. Einbindung von externen Dienstleistern 6. Lauffähigkeit auf BIT Umgebung Das System muss in der Lage sein, externe Dienstleister (mit entsprechenden User-Rollen- Zugriffs/Rechten) für die Bearbei- tung und Verwaltung von Digital- Assets remote einzubinden. Datenaustausch per E-ail, FTP oder WebDAV / -services. Das System kann auf eines der in oder beschriebe- nen installiert werden A nahme der Datenablagestruktur. Die assenmutation kann sowohl via GUI als auch Script ausgeführt werden. Es muss möglich sein, dass externe itarbeiter (Autoren) mit entsprechenden User-Rollen- Zugriffs/Rechten via Remote- Zugang Digital-Assets aufnehmen, beziehen, bearbeiten oder verwalten können. A Es ist möglich das System pro- duktiv auf den beschriebenen Umgebungen zu installieren und mit einer 98% Verfügbarkeit zu betreiben. 5.3 Systemanforderungen Nr Anforderung Beschreibung Typ Kriterien oder essgrössen zur Bewertung der Zielerreichung 1. Bildrechteverwaltung Verwaltung von Lizenzen und Nutzungsrechten. Verknüpfung von Bildern mit Einsatzgebieten (Publikationsform). 2. Sicherheit der Daten Verschlüsselung der hinterlegten Assets 3. Nutzungsrechte K K Festhalten der Dauer Nutzungsrechte. Berücksichtigung unterschiedlicher Berechtigungsansprü- che durch P s. Damit die Daten nur von den berechtigten Nutzern gelesen werden können, ist eine Verschlüsslung der hinterlegten Assets möglich. Die Nutzungsrechte müssen auf ögliche User-Gruppen: verschiedene User-Gruppen Sichtrecht individuell anpassbar sein. Sicht- und Leserecht Die Rechte können an die eta- daten gebunden werden (z.b. Sicht-, Lese-, Download-Recht eine Benutzergruppe für validierte Dateien und eine für nicht validierte) Sicht-, Lese-, Download-, Up- Up- load-recht Sicht-, Lese-, Download-, load-, Schreib-Recht Administrationsrecht Key-User-Rechte usw. 12/18

13 Nr Anforderung Beschreibung Typ Kriterien oder essgrössen zur Bewertung der Zielerreichung 4. Verwaltung jeglicher Art von Dateiformaten Unterstützung aller gängigen Dateiformate für die zu verwaltenden edia Assets (inkl. Bildvoransichten). Alle geläufigen: Bildformate Videoformate Audioformate Formate S-Office (.xls,.doc,.ppt) PDF-Formate (Low-Res/High- Res) InDesign-Formate (Layouts/Templates) Grafikprogramme 5. Relationale und dynamische Verbindung Die Verbindung von edia Assets (z.b. Bilder, Tabellen, Texte usw.) zu den jeweiligen Publikationen müssen relational und dynamisch (jederzeit aktuell) mitgeführt werden. Damit jederzeit ersichtlich ist, welche edia Assets in welcher Publikation verwendet wurde muss die Systemlösung diese Verbindung relational und dynamisch (jederzeit aktuell) mitführen. 6. Versionen- und Historie-Verwaltung Jede Veränderung eines Digital- Assets muss versioniert werden und den Bezug zum Original- Asset relational beibehalten. Veränderungen (z.b. Tabellenbearbeitung) von Digital-Assets auf edien- und Vorlagenebene werden im System laufend mitgeführt und können jederzeit rückverfolgt werden. Es ist möglich zu definieren, wann eine neue Version erstellt wird und wann das Asset überschrieben werden kann. Es soll z.b. möglich sein ein Artikel beliebig oft hoch zu laden und erst beim Begin des Validierungsworkflow eine Version anzulegen. 7. Workflow- anagement Jedem Digital-Asset können Workflows hinterlegt werden. Als Teilnehmer im Workflow, können Benutzer, Gruppen oder Systeme gewählt werden. Verschiedene Prozesse lassen sich via Workflow-Schritte ansteuern: z.b. wird bei der Aufnahme von neuen Bilddaten automatisch anhand des User-Logins erkannt, in welchen Bereich dieses Digital- Asset abgelegt wird, oder wie der Ablauf (z.b. Kontrolle durch DIA, Verifizierung durch Vorgesetzten, usw.) der edia- Asset-Aufnahme zu erfolgen hat. 13/18

14 Nr Anforderung Beschreibung Typ Kriterien oder essgrössen zur Bewertung der Zielerreichung 8. Administration Die Administration der Systemlösung muss durch den Kunden selbständig erfolgen können. 9. User-Frontend Das User-Frontend kann an das Corporate Design des BFS angepasst werden. K Anlegen und Verwaltung von: Digital-Asset-Typen etadaten-feldern Schlagwortbäumen Workflows User-Rollen-Zugriffs/Gruppen- /Rechte Das User-Frontend kann dem Corporate Design des Kunden in Farbe und Navigationsstruktur angepasst werden. Je nach User- Gruppe müssen unterschiedliche Frontend-Varianten (unterschiedliche Rechte und Navigationsaufbau) definiert werden können. 10. User-Frontend: Sprachen User-Frontend in mehreren Sprachen verfügbar. Deutsch, Französisch, Italienisch, Englisch 11. Up-/Download Es muss möglich sein, Digital- Assets je nach User-Rollen- Zugriffs/Rechten Digital-Assets in verschiedenen Formaten Upund Down- zu loaden 12. Notizfunktion Auf jedem Digital-Asset können Notizen als Post-it mitgeführt und verwaltet werden. K Es muss möglich sein, dass verschiedene User (z,b. Key-User), Digital-Assets mit standardisierten Workflows in das System via LAN, Intranet, Internet usw. uploaden können. Es muss möglich sein, dass verschiedene User (z.b. itarbeiter, Dienstleister, Partnerfirmen, Presse usw.) mit verschiedenen User- Rollen-Zugriffs/Rechten sowie bestimmte Bezugs-Workflows (z.b. Freigabe durch eine autorisierte Person oder Downloadlink per ail an einen bestimmten User usw.) Digital-Asset in verschiedenen Formaten, via Internet-Browser downloaden können. Jedem Digital-Asset können beliebige Notizen (z.b. für Korrekturanweisungen) angefügt werden. Diese werden dynamisch mit dem Autor in Relation gebracht. 14/18

15 Nr Anforderung Beschreibung Typ Kriterien oder essgrössen zur Bewertung der Zielerreichung 13. Auswertung Es muss möglich sein, dass sämtliche Veränderungen eines Digital-Assets auf statistischer Basis nachvollziehbar sind. 14. Versionskompatibilität Die einzelnen Versionen der Systemkomponenten müssen untereinander kompatibel sein und zusammenarbeiten können. Bei Releasewechsel soll man nicht alle Komponenten gleichzeitig updaten müssen. 15. Systemverfügbarkeit Es soll während den Betriebszeiten eine angemessene Verfügbarkeit des Systems gewährleistet sein. 16. offene Architektur Die Einbindung von Fremdsystemen muss möglich sein. K ögliche Auswertungen: Bezug von Digital-Assets (enge/wer)? Verwendungszweck des Digital-Assets? Verwendung von Digital-Asset in welcher Publikation engen von Up- und Downloads In der Systemauslegung muss diese Anforderung ersichtlich und nachvollziehbar aufgezeigt werden können. Die Verfügbarkeit der Gesamtapplikation beträgt 99 %. Es muss aufgezeigt werden können, dass die Software keine proprietäre Lösung darstellt und fremde Systeme eingebunden werden können. indestens alle gängigen Web2Print und Redaktionssysteme, aber auch z.b. andere CS 17. Stand der Technologie Der Beweis der arktreife der eingesetzten Technologie muss in Form von Referenz- Installationen bei vergleichbaren Kunden erbracht worden sein. In der Offerte sind die Referenzinstallationen beizulegen. 18. Reaktionszeiten/ Antwortzeiten Akzeptable Reaktions- und Antwortzeiten Die Reaktions- bzw. Antwortzeiten des Systems an allen Arbeitsplätzen dürfen für alle Transaktionen im Tagesgeschäft in 98 % aller Fälle zwei Sekunden nicht übersteigen. 19. Browser/Betriebssystem Die Systemlösung soll gängige Browser und Betriebssysteme unterstützen ögliche Browser: S-Explorer ab 8.x Firefox ozilla ab 3.x Safari ab 4.x ögliche Betriebssysteme: S XP, Vista, 2007 ac OSX 10.x 15/18

16 Nr Anforderung Beschreibung Typ Kriterien oder essgrössen zur Bewertung der Zielerreichung 20. Archivierung Archivierungsmöglichkeiten. Aufzeigen eines Archivierungskonzepts 5.4 Anbieterbezogene Anforderungen Erfahrung Die Anbieterin bestätigt, dass sie mit Einsatz von Asset anagement Systemen Erfahrung hat und mindestens eine Referenzinstallation in vergleichbarer Grösse nachweisen kann. Für die Referenz muss eine unabhängige (von der Anbieterin) Kontaktperson angegeben werden Projektvorgehen Die Anbieterin soll ein flexibles und gut dokumentiertes Projektvorgehen nachweisen. Agile Vorgehen werden bevorzugt. Die oben genannte Referenzinstallation, muss nach demselben Vorgehen entwickelt worden sein. Die Kontaktperson soll in der Lage sein über das Vorgehen Informationen zu geben, sie muss im Projekt mitgearbeitet haben Zu erbringende Dienstleistungen Es wird von der Anbieterin erwartet, dass sie die Inbetriebnahme und den laufenden Betrieb des Systems sicherstellt. Unter Inbetriebnahme und Betrieb werden folgende Punkte verstanden: Installation vor Ort beim BIT Entwicklung des Initialworkflow und Schnittstellen zu den existierenden Systemen Endbenutzer-Unterstützung (Support) Entwicklungs-Unterstützung (Support) Benutzer, Administratoren und Entwicklerschulungen Die Anbieterin bestätigt, dass sie Deutsch und Französisch sprachiges Personal einsetzen kann. Insbesondere für die Teile Schulung und Support. 6 Aufbau des Angebots 6.1 Angebotsgliederung Beschreibt die Gliederung des Angebots, welche dem Anbieter vorgegeben wird. Folgende Gliederung wird vorgeschlagen: 1. Kurzvorstellung des Anbieters 2. anagement-übersicht 3. Lösungskonzept des Anbieters Nachweis zur Erfüllung der usskriterien Lösungskonzept Anbieterbezogene Angaben Kommentierung der Systemanforderungen Referenzangaben mit entsprechenden Ansprechpartnern öglichkeiten für Besichtigungen, Vorführungen 4. Preise und Konditionen (vgl. auch Kapitel 2.4) 16/18

17 Lizenzen für 200 Benutzerinnen und Benutzer, Service Assurance, Wartung und Support für 4 Jahre (Support mit Angabe von Reaktionsfristen) Erstellung Detailkonzepte für die Implementierung (Aufwandschätzung vom Anbieter) Umsetzung der Detailkonzepte (Aufwandschätzung vom Anbieter) Durchführung der Schulungen (Aufwandschätzung vom Anbieter) Anpassungen im Umfang von 20 Arbeitstagen 5. Ergänzungen des Anbieters Weitere Punkte zur Umsetzung 6. Beilagen 7 Administratives 7.1 Vergütung für die Erstellung des Angebots Für die Erstellung des Angebots stehen dem Anbieter keine Vergütungen zu. 7.2 Verfahren für die Bewertung der Angebote und beim Abschluss der Evaluation Evaluationskriterien sind vorwiegend die inhaltliche Vollständigkeit und Verständlichkeit der Offerte und das Preis-/Leistungsverhältnis. Der Entscheid des BFS wird den Anbietern bis zum schriftlich mitgeteilt. 7.3 Allgemeine Geschäftsbedingungen Es gelten die Allgemeinen Geschäftsbedingungen des Bundes für Informatikdienstleistungen (Ausgabe Juni 1998), 7.4 Sprache des Angebots Das Angebot kann in deutscher oder französischer Sprache eingereicht werden. 7.5 Vertraulichkeit, Rückgabe des Pflichtenhefts Alle Informationen und Kenntnisse, die der Anbieter im Zusammenhang mit der Tätigkeit beim Auftraggeber erhält, sind vertraulich zu behandeln. Die Ausschreibungsunterlagen dürfen, auch nicht auszugsweise, nicht zu andern Zwecken als der Angebotserstellung verwendet werden. Die Anbieter behandeln Tatsachen vertraulich, die weder offenkundig noch allgemein zugänglich sind. Im Zweifel sind die Tatsachen als vertraulich zu behandeln. Diese Geheimhaltungspflicht besteht auch nach einer Absage auf das Angebot. Der Empfänger des Angebots verpflichtet sich, über dieses Angebot gegenüber DrittenStillschweigen zu bewahren. 7.6 Rückfragen zum Pflichtenheft Rückfragen zum Pflichtenheft sind bis zum zu stellen. Fragen, die nach dem genannten Termin eintreffen, können nicht mehr beantwortet werden. Die schriftlichen Antworten werden allen bekannten Anbietern in anonymisierter Form zugestellt. 7.7 Angebotsabgabe Das Angebot ist bis zum an folgende Adresse zu senden. 17/18

18 Bundesamt für Statistik BFS Armin Grossenbacher Espace de l'europe Neuchâtel OFS/NE 7.8 Gültigkeit des Angebots Die Gültigkeit des Angebots muss mindestens 60 Tage nach dem gesetzten Termin für die Einreichung des Angebots betragen. 8 Anhang Allgemeine Geschäftsbedingungen des Bundes für Informatikdienstleistungen (Ausgabe Juni 1998); Regeln zum Gebrauch der Informatik- und Kommunikationsmittel des Eidgenössischen Departements des Innern vom ärz 2007; Weisung über die Nutzung der Informatik- und Kommunikationsmittel des Eidgenössischen Departements des Innern vom ärz /18