Zuerst einmal müssen wir die Frage beantworten, was denn eine Informationsarchitektur überhaupt ist. Die Rolle eines Informationsarchitekten ist zwar nicht wirklich neu, in einem SharePoint-Umfeld allerdings anders zu definieren.
Einen Architekten für Informationen kennt man seit sehr langer Zeit. Bibliothekare haben sich seit an Beginn mit der Problematik auseinandersetzen müssen, wie sie ihre Informationen zugänglich machen.
Vermutlich ist die Informationsarchitektur eines der am wenigsten beachteten und am meist unterschätztesten Themen im SharePoint-Umfeld. Moderne Architekten haben sich vor allem im Web-Umfeld mit den Strukturen von Daten und Informationen befasst. Hierbei geht es aber nicht nur darum, Informationen zu strukturieren, sondern auch darum, wie man diese zugänglich macht, wie eine gute Navigation aussieht, was man aus dem Gesichtspunkt der User Experience beachten muss, etc.
Diese Themen fließen in einem SharePoint Umfeld mit den Anforderungen aus dem klassischen Enterprise Content Management zusammen. Sehr häufig spielen Dokumente eine zentrale Rolle. Aber auch hier muss berücksichtigt werden, wie man diese Dokumente am besten zugänglich macht. Wie holt man die „Klicker“ und die „Sucher“ ab? Wie sieht eine gute Navigation aus? Welche Regeln gibt es für die Navigation (Z.B: Nie mehr als drei Klicks zum Ziel)? Welche Metadaten werden verwendet?
Was ist nun die Informationsarchitektur?
Letztendlich ist es die Struktur, die einer SharePoint Seite, oder einer ganzen SharePoint Umgebung innewohnt. Diese Struktur bestimmt die Zugänglichkeit der Informationen. In großen SharePoint Umgebungen kann es mehrere Levels von Strukturen geben. Aufbauend auf der Struktur wird die Navigation, das User Interface, die Metadaten usw. aufgesetzt. Wir sehen also, dass es ein sehr weitläufiges Feld ist.
Unserer Erfahrung nach wird an dieser Stelle bereits ein entscheidender Faktor zur Akzeptanz einer Umgebung erfolgreich oder nicht erfolgreich umgesetzt. Wenn es keine Struktur gibt, die für den Benutzer eingängig ist, dann wird das System nicht angenommen. Eine fehlende benutzerfreundliche Navigation, das Fehlen guter Oberflächen und eine unzureichende Metadatenstruktur tun ihr übriges.
Wie fangen wir an?
Wenn man anfängt, eine gute Struktur aufzubauen, sollte man sich an ein paar Grundregeln halten. Wir kennen alle den Aufbau der Informationen nach Abteilungs-Organisation.
Dieses Modell hat sehr viele Schwächen. Die größte ist die Instabilität. Organisationsstrukturen ändern sich, frei nach dem Motto: „Nach der Reorganisation ist vor der Reorganisation“.
Häufig wird auch angefangen, ein ganzes Unternehmen abzubilden.
Zu große Strukturen sind schwer zu handhaben und schnell nicht mehr im Griff zu halten. Ebenfalls kommt man im SharePoint Umfeld regelmäßig mit den Limitationen der Site Collection Größen oder der Benutzerverwaltung an seine Grenzen.
Ein auch oft verwendetes Modell ist, sehr viele „Projekträume“, Teamnets, etc. zuzulassen. Dadurch bekommt man eine sehr große Fragmentierung seiner Umgebung. Oft verlieren die Anwender den Überblick und es wird kein „zu Hause“ für den Benutzer geschaffen.
Sie sehen, wir befinden uns im Thema Informationsarchitektur auf oberstem Level. Hier geht es noch nicht um die Informationen an sich, es geht um die große Struktur.
Eine Trennung in Intranet und Kollaboration ist auf jeden Fall sehr empfehlenswert. Wir haben im Intranet redaktionell gepflegte Informationen und Dokumente, im Kollaborationsbereich wird mehr Wert auf Zusammenarbeit, oder sogar Social Collaboration, gelegt. Im Intranet ist eine gute Verschlagwortung essenziell, im Kollaborations-Umfeld hat man nicht die Geduld der Anwender, um viele Metadaten auszufüllen. Oft muss auch mit Widerstand gegen das Auflösen von Ordnerstrukturen gerechnet werden (das kennen sicherlich viele von Ihnen).
Wir haben also eine grundlegende Unterscheidung nach Intranet und Kollaboration. Das Intranet als Publishing Plattform ist relativ leicht zu beschreiben, sind die Grundzüge einem Web-Publishing doch sehr ähnlich, allerdings innerhalb eines Unternehmens mehr dokumentenlastig. Auch hierzu werden wir demnächst einen eigenen Blogartikel veröffentlichen.
Viel weniger beachtet sind die Strukturen im Kollaborationsumfeld. Um einem Mitarbeiter sein Leben leichter zu machen, muss er sich in einer Umgebung bewegen können, die er kennt, die klar strukturiert ist und die für ihn nachvollziehbar ist. Wenn er es als „seinen Arbeitsplatz“ wahrnimmt, dann ist auch die nötige Akzeptanz da.
Dies erreichen wir nicht, indem wir viele einzelne Sites zur Verfügung stellen. Aber auch nicht, indem wir einen riesigen Bereich schaffen. Wichtig an dieser Stelle ist, das richtige Maß zu finden, oder das richtige Level. Ist es eine ganze Abteilung, die einen klaren Themenansatz hat, ist es ein ganzes Thema wie Marketing oder Produktentwicklung. Das muss von Fall zu Fall unterscheiden werden.
ENTSCHEIDEND ist, dass nicht an dem Verständnis oder dem Bedarf der Benutzer vorbei eine Umgebung entwickelt wird.
Dem Benutzer muss ganz klar sein, wie er an seine Informationen kommt, wo er diese findet, wo er sie abzulegen hat und wo er seine Arbeiten im Team, an seinen Themen oder alleine erledigen kann. Die richtige Struktur an dieser Stelle zu finden, ist kein leichter Prozess. Es braucht ein Maß an Erfahrung, man muss die nötigen Werkzeuge und Skills besitzen, um bei den Leuten an die richtigen Informationen zu kommen und dann braucht man auch noch das Wissen um SharePoint und seine Limitationen. Dies alles zusammengebracht ergibt dann eine hoffentlich richtige Struktur.
Lassen Sie uns ein wenig konkreter werden
Wir haben ein großes Unternehmen und wollen eine Struktur für eine Marketing-Abteilung aufbauen.
Zuerst erarbeiten wir in Workshops und Interviews das richtige Verständnis für die Arbeitsprozesse, die Ablagen der Informationen, welche Systeme involviert sind und bekommen ein Gefühl für die Menschen in der Abteilung.
Es wird viele Meetings geben. Die Kolleginnen und Kollegen arbeiten an Projekten, um beispielsweise neue Broschüren und Kampagnen zu erstellen oder auf Messen zu gehen. Andere Kollegen beschäftigen sich mit dem Thema Internetauftritt oder Brand Management. Ebenfalls gibt Informationen, die an alle Marketing Mitarbeiter gehen sollen. Zu guter Letzt haben wir noch spezifische Guidelines, Templates und Datenblätter, die zur Verfügung gestellt werden sollen. Ach ja, und natürlich wird sich viel mit den Landesvertretungen und externen Agenturen ausgetauscht. Was tun?
Zuerst schaffen wir einen gemeinsamen Bereich für die Kolleginnen aus dem Marketing. Ein „zu Hause“. Die Benutzer in der Abteilung werden einen sehr großen Teil ihrer Arbeit in diesem Bereich erledigen können. Wir schaffen also nicht für alles einzelne Seiten oder Bereiche, sondern geben dem Anwender das Gefühl, das es eine Umgebung ist. Er kann sich zu allen seinen nötigen Orten schnell über die Navigation hinbewegen.
Wenn man nun die nötigen Container schafft, ist man schon fast am Ziel. Einem Nutzer muss klar sein, wenn ich an einem Meeting teilnehmen möchte, finde ich es genau hier und nirgendwo anders. Wenn ich an meinem Projekt arbeite, gehe ich genau dort hin. Ich finde in meiner Umgebung immer meine zuletzt bearbeitenden Dokumente. Usw. Wenn das erreicht wird, ist die Akzeptanz der Umgebung hoch.
An dieser Stelle kann man sagen, oh wie altmodisch. Wir haben doch die MySite und es kommt ja Oslo, es gibt die Suche und so weiter. Alles gut und richtig. Wir schreiben hier aufgrund unserer Erfahrung. Eine MySite ist ein eigener Punkt und hat seine eigene Bedeutung. Wir haben gelernt, dass ein solches Modell das ist, was eine sehr hohe Akzeptanz erfährt. Sind wir schon so weit uns von Strukturen zu verabschieden und alle Infos zu aggregieren und uns im freien Raum zu vernetzen? Natürlich, aber bei Weitem nicht alle. Es ist sehr viel Change, also Veränderung im Spiel und diesem muss man Rechnung tragen. Die Suche wiederum ist ein weiterer eigener Punkt. Dieser wird später noch mit einbezogen.
Aber zunächst geht es nun um die Mikro-Info-Architektur. Also welche Informationen, Dokumente, Prozesse oder Workflows, etc. finden in den Bereichen statt. Dies beschreiben wir im nächsten Artikel.
Natürlich hier wieder der Hinweis, dass wir in unserer Demoumgebung eine solche Architektur zeigen und wir ihnen diese gerne näher bringen. Sprechen Sie uns an!
