Die Micro-Info-Architektur

Home/Dokumentenmanagement, Intranet, Kollaboration/Die Micro-Info-Architektur

Die Micro-Info-Architektur

Nachdem wir im Artikel SharePoint und Informationsarchitektur – worauf kommt es an die Strukturierung eines Arbeitsbereichs, von Themen und natürlich auch von Informationen auf hohem Level (in der Großstruktur/ auf Makroebene) besprochen haben, wenden wir uns nun dem Micro-Management der Informationsarchitektur zu.

In den Workshops mit den Usern, aus den Abteilungen/ Teams haben wir ihre Aufgaben und Tätigkeiten kennen gelernt und erfahren welche Informationen sie in diesem Prozess benötigen. Daran anknüpfend werden nun diese Anforderungen in den weiteren (Mikro-) Strukturen abgebildet. Bitte unterschätzen Sie diese Aufgabe nicht. Bei der Analyse der vorhanden Informationen, Prozesse, Aufgaben und Workflows entscheidet sich der weitere Erfolg der Umgebung.

Mit der Gliederung der Informationen in große Container haben wir schon einiges geschafft. Dem Nutzer ist klar, wo er beispielsweise seine Meetings findet. Auch sind die relevanten Themen, an denen er arbeitet oder die Projekte, in die er involviert ist, eindeutig zugeordnet.

Informationen verorten

Zunächst muss der Charakter der Information bestimmt werden. Was bedeutete das konkret?

Im Prinzip ist es die Unterscheidung, ob ein Dokument eine Publishing Information oder eine kollaborative Information ist. Viele unserer Kunden tun sich zu Beginn damit schwer, diese Unterscheidung nachzuvollziehen. Fakt ist, wir haben auch im Kollaborationsumfeld Publishing Informationen. Ein Template, eine Guideline oder eine Anweisung sind Dokumente, die zentral einer Gruppe zur Verfügung gestellt werden müssen. Wenden wir uns einem einzelnem Template zu, um den Entscheidungsprozess weiter zu verdeutlichen: Ein Template wird verwendet und ausgefüllt. Zu diesem Zeitpunkt wird daraus eine Information, die ich bearbeite und die damit Teil meines Arbeitsbereichs oder auch Kollaborationsbereichs wird. Warum legen wir diese Informationen nicht ins Intranet? Weil es organisationsspezifische oder thematische Dokumente sind, die nicht einer Zielgruppe eines Intranets entsprechen.

Wenn wir diese Unterscheidung getroffen haben, können wir die Publishing Dokumente schon einmal „verräumen“. Der richtige Ort hierfür kann ein Knowledge oder Informationsbereich sein.

Publishing

Wie greifen wir nun auf diese Informationen zu? Hier kommen die Metadaten ins Spiel. Mit den richtigen Taxonomien können wir die Informationen bedarfsgerecht präsentieren und strukturieren. Ein Tipp an dieser Stelle: Denken Sie bei Metadaten nicht nur an Dokumente, auch Links, News, etc. können in gleicher Weise verschlagwortet werden, so dass daraus eine Art Portal entstehen.

Zum Erfassen der Metadaten hier nur ganz kurz. Lassen Sie sich nicht auf „große Metadaten-Runden“ ein. Zu Beginn saßen wir immer wieder in fortlaufenden Meetings und haben „Trilliarden“ von Metadaten erfasst. Lösen Sie sich von diesem Gedanken und gehen Sie an das Thema von der anderen Seite heran. Fragen Sie sich nicht, welche Metadaten brauche ich denn, sondern beantworten Sie sich die Frage, wie ich meine Informationen wiederfinden möchte. Dann ergibt sich daraus die richtige Verschlagwortung. Hier noch ein Tipp: Vermeiden Sie es zu viele Einträge in einem Metadatum zu verwenden. Der Anwender wird das Metadatum Nummer 26 auswählen, obwohl das an der Position 76 viel besser geeignet wäre. Gleiches gilt für die Anzahl unterschiedlicher Metadatenspalten. Sie haben in einem kollaborativen Umfeld 30 – 45 Sekunden, die Ihnen ein Nutzer zur Verschlagwortung einräumt.

Oft ist es auch nicht nötig, zu viele Spalten in einer Bibliothek zur Verfügung zu stellen. Sites und die Bibliothek an sich stellen auch schon „Metadaten“ dar. An dieser Stelle möchte ich den Begriff der richtigen Menge und der richtigen „Trennschärfe“ der Metadaten einführen. Denn ähnliche Metadaten-Werte helfen auch keinem weiter.

Was haben wir bis jetzt erreicht? Wir haben die Publishing Inhalte erfasst und sie in unserem Informationsportal abgelegt und verschlagwortet. Jetzt brauchen wir noch die richtigen Ansichten und fertig ist dieser Bereich. Hört sich jetzt einfach an, aber ein bisschen Erfahrung hilft hier schon weiter.

 

 

 

Kollaboration

Für das Organisieren der Arbeitsdokumente und Informationen nutzen wir die identifizierten Bereiche und Container. Auch hier werden wir auf Bibliothekslevel, Ordner-Level oder mit Taxonomien weitere Strukturen einziehen. Eine Bibliothek ist nichts anderes als ein weiteres Strukturelement. Sammeln Sie alle Verträge in einer Bibliothek, benennen Sie diese unbedingt auch entsprechend. Eine Vertragsbibliothek kann dann automatisch einen Content Type oder entsprechende Metadaten bekommen, die die Dokumente als Vertrag identifizieren und an anderer Stelle Verwendung finden kann. Wir sehen, die Bibliothek hat damit auch wieder eine Struktur ergeben. Ähnliches gilt für Ordner. Wobei Sie es weitestgehend vermeiden sollten mit Ordnern zu arbeiten. Ein Argument dafür ist eine nötige Berechtigung. Ansonsten sind Metadaten das überlegenere System.

Oft habe ich schon gehört, dass Kunden ganz tolle verschachtelte Site-Strukturen gebaut haben und damit sehr glücklich sind. Genauso oft habe ich schon gehört, dass die Struktur nicht mehr wartbar ist, es findet keiner mehr etwas, es wurden umstrukturiert und es passt nichts mehr, usw. Vertrauen Sie mir hier einfach und lassen Sie es. Flache Strukturen sind wesentlich effektiver.

Sie können jetzt ihre Arbeitsbereiche noch mit Kollaborationselementen anreichern und die nötigen Templates zur Verfügung stellen und wieder sind wir fertig. Und wieder hört es sich einfach an. Und wieder ist es nicht ganz so leicht.

Selbstverständlich ist das eine sehr vereinfachte Darstellung des Prozesses zur Erstellung einer Informationsarchitektur. Natürlich gehören auch Elemente dazu, die die Zusammenarbeit verbessern, Austausch ermöglichen und das Arbeiten weiter vereinfachen. Auch Social -Collaboration kann hier ein Thema sein. Das sind Dinge, die im Detail mit den Kunden erarbeitet werden, sich aber auch schon aus den vorangegangenen Analysen ableiten lassen.

Entscheidend ist aber auf jeden Fall, dass Sie alle Informationen klar verortet haben und in stabile Strukturen überführt wurden. Wie oft haben uns Kunden gesagt, dass diese Neustrukturierung der größte Vorteil eines SharePoint Projekts war und den meisten Mehrwert geliefert hat.

By | 2017-02-06T16:05:49+00:00 Juli 17th, 2014|Dokumentenmanagement, Intranet, Kollaboration|0 Comments

About the Author:

Business Unit Manager, Experte für: Intranet, Kollaboration, Social, Change Management

Kommentar verfassen

%d Bloggern gefällt das: