Leitfaden: das richtige System für Inhalte, Produktdaten und Portale

Die meisten Systemauswahlen beginnen mit einem Namen. Jemand hat von einem System gehört, eine Demo gesehen oder liest in einer Fachzeitschrift davon. Von dort aus wird geprüft, ob das System passt, und weil moderne Systeme fast alles können, lautet die Antwort meistens ja.

Belastbarer wird die Entscheidung, wenn sie von der anderen Seite aufgezogen wird: zuerst der eigene Bedarf, dann die Anforderungen, dann erst die Systeme. Der Unterschied klingt formal, macht in der Praxis aber den Unterschied zwischen einer Plattform, die nach zwei Jahren noch trägt, und einer, um die herum gearbeitet wird.

Dieser Leitfaden beschreibt sechs Schritte. Für ein mittleres Vorhaben lassen sie sich in vier bis acht Wochen durchlaufen, und zwar parallel zum Tagesgeschäft.

• Bedarf klären: was soll in zwei Jahren anders sein
• Anforderungen erheben und gewichten
• Die Frage nach Standard oder Eigenbau beantworten
• Den Kreis der Systeme eingrenzen
• Realistisch prüfen statt Demos ansehen
• Entscheiden und die Begründung festhalten

Vor jeder Anforderungsliste steht eine einfachere Frage: was soll in zwei Jahren anders sein als heute. Die Antwort darauf ist selten technisch. Sie lautet etwa, dass eine Produktänderung nicht mehr an fünf Stellen gepflegt wird, dass die Redaktion ohne Agentur eine Landingpage bauen kann, oder dass ein Mitgliederbereich entsteht, den es bisher nicht gibt.

Aus solchen Sätzen ergibt sich später fast von selbst, welche Anforderungen wirklich zählen. Ohne sie wird eine Anforderungsliste zu einer Sammlung von allem, was denkbar wäre, und verliert damit ihre Aussagekraft.

Hilfreich ist, diese Frage mit mehreren Bereichen getrennt zu besprechen. Marketing, Vertrieb, Produktmanagement und IT beschreiben denselben Sachverhalt oft unterschiedlich, und genau in diesen Unterschieden steckt die eigentliche Information.

Ein brauchbares Ergebnis dieses Schritts passt auf eine Seite und enthält drei bis fünf Sätze, denen alle Beteiligten zustimmen.

Anforderungen werden am besten entlang tatsächlicher Abläufe erhoben, nicht entlang von Funktionslisten. Statt zu fragen, ob ein Arbeitsablauf mit Freigabe unterstützt wird, ist es aufschlussreicher, sich zeigen zu lassen, wie eine Pressemitteilung heute vom Entwurf bis zur Veröffentlichung kommt und wer dabei in welcher Reihenfolge beteiligt ist.

Jede erhobene Anforderung bekommt anschließend eine Gewichtung. Bewährt haben sich drei Stufen: notwendig, deutlich wertvoll, angenehm. Entscheidend ist die Disziplin, die erste Stufe klein zu halten. Wenn dreißig Punkte notwendig sind, ist keiner davon notwendig.

• Wer legt Inhalte oder Daten an, wer prüft, wer gibt frei
• Welche Systeme liefern Daten zu und welche beziehen sie
• Welche Sprachen, Mandanten und Zielgruppen sind zu bedienen
• Welche Ausgabekanäle gibt es heute und welche sind absehbar
• Welche rechtlichen Vorgaben gelten, etwa zur Barrierefreiheit
• Welche Auswertungen werden regelmäßig gebraucht
• Wie viele Personen arbeiten täglich im System

Diese Frage wird oft übersprungen, obwohl sie den Zuschnitt des gesamten Vorhabens bestimmt. Drei Wege stehen offen, und keiner davon ist grundsätzlich der bessere.

Ein fertiges Standardsystem ist schnell verfügbar und günstig im Einstieg. Es passt gut, solange die eigenen Abläufe denen ähneln, für die es gebaut wurde. Ein offener Baukasten wie ein Content- oder Produktdatensystem liefert die wiederkehrenden Bestandteile mit und lässt das Datenmodell offen. Eine Eigenentwicklung passt exakt und bindet dauerhaft Aufwand, der sich nur bei einem echten Alleinstellungsmerkmal rechnet.

Eine brauchbare Faustregel: was im eigenen Haus tatsächlich besonders ist, verdient eine eigene Lösung. Alles andere ist in einem Standard besser aufgehoben, weil es dort gepflegt wird, ohne dass jemand daran denken muss.

Erst an dieser Stelle kommen Namen ins Spiel. Drei bis vier Kandidaten genügen; mehr können Sie nicht ernsthaft prüfen. Neben dem Funktionsumfang verdienen dabei vier Eigenschaften Aufmerksamkeit, die in Prospekten selten auftauchen.

• Verfügbarkeit von Fachleuten: wie viele Dienstleister und interne Kräfte Sie für dieses System finden
• Entwicklungsstand und Gemeinschaft: wie regelmäßig erscheinen Aktualisierungen und wie lange werden Versionen gepflegt
• Ausstiegsmöglichkeit: wie kommen Inhalte und Daten wieder heraus, wenn die Entscheidung einmal revidiert wird
• Kostenbild über fünf Jahre: Lizenzen, Betrieb, Aktualisierungen und Weiterentwicklung zusammengerechnet, nicht nur die Einführung

Der letzte Punkt verschiebt Vergleiche regelmäßig. Ein System ohne Lizenzgebühren kann im Betrieb teurer sein, ein Lizenzsystem im Gesamtbild günstiger. Beides kommt vor.

Eine vorgeführte Demo zeigt, was ein System gut kann. Aussagekräftig wird die Prüfung erst, wenn zwei bis drei eigene Abläufe mit eigenen Daten nachgebaut werden, und zwar von den Personen, die später damit arbeiten.

Dafür genügt ein knapper Zeitrahmen, etwa ein Tag je System. Entscheidend ist, dass die Aufgaben vorher schriftlich festgelegt sind und für alle Kandidaten identisch bleiben. Erst dadurch wird der Vergleich belastbar.

• Eine echte Seite oder einen echten Datensatz anlegen und veröffentlichen
• Eine Änderung durch den vollständigen Freigabeweg schicken
• Einen Auszug echter Bestandsdaten importieren
• Eine Anbindung an ein bestehendes System skizzieren oder prototypisch bauen
• Die Bedienung auf einem durchschnittlichen Arbeitsgerät beurteilen, nicht auf dem schnellsten

Am Ende steht eine Entscheidung, die sich im Haus erklären lassen muss, auch in zwei Jahren und auch gegenüber Personen, die am Verfahren nicht beteiligt waren. Dafür genügt ein kurzes Dokument, das festhält, welche Anforderungen den Ausschlag gegeben haben, welche Kandidaten geprüft wurden und was für die unterlegenen sprach.

Dieses Dokument ist mehr als eine Formalie. Es beantwortet später die Frage, warum etwas so entschieden wurde, und es verhindert, dass dieselbe Diskussion nach einem Personalwechsel von vorn beginnt.

Ebenso wichtig ist, gleich mitzuentscheiden, wer das System nach der Einführung betreut und in welchem Rhythmus es aktualisiert wird. Diese Frage später zu stellen, ist der häufigste Grund dafür, dass eine gute Auswahl im Betrieb nicht hält.

Die folgenden Punkte tauchen in Auswahlverfahren regelmäßig zu spät auf. Sie früh zu klären kostet wenig und erspart später viel.

• Die Migration der Bestandsdaten wird als Nebensache behandelt und ist oft der größte Einzelposten
• Die Schulung der Redaktion wird eingeplant, die Sprechstunde in den ersten Wochen danach aber nicht
• Die Betreuung nach dem Start wird erst nach dem Start geklärt
• Barrierefreiheit wird als Prüfpunkt am Ende gesehen statt als Anforderung an Redaktion und Vorlagen
• Schnittstellen werden fachlich beschrieben, aber nicht auf die tatsächliche Datenqualität geprüft
• Der Ausstieg aus dem System wird nicht betrachtet, obwohl genau er die Verhandlungsposition bestimmt