Informationsarchitektur: Teil I Überblick


Einführung

Bevor wir mit diesem Post beginnen, möchte ich kurz darauf eingehen, warum wir in einem SharePoint Blog überhaupt über die Informationsarchitektur sprechen. Auch hier muss man nach dem Motto gehen “Wer nicht weiss was er will bekommt das was er nicht braucht”. Die Informationsarchitektur hilft also zu definieren, was wir mit SharePoint überhaupt wollen. Es gibt bestimmte Parallelen zur SharePoint Governance, diese beiden Themen sind sehr eng miteinander verknüpft.

Im ersten Beitrag gehen wir auf die theoretischen Aspekte einer Informationsarchitektur ein, welche integrativen Bestandteil eines Intranet bildet. Die Informationsarchitektur wie wir sie in diesem Projekt anwenden werden wird im späteren Verlauf dieses Dokumentes beschrieben.

Damit klar ist, was wir unter Informationsarchitektur verstehen und damit alle Beteiligten dasselbe Bild haben, starten wir den Abschnitt mit einer Definition.

Definition

Informationsarchitektur bezeichnet die Konzeption und Definition der Struktur eines Informationssystems, meist eines Computersystems, sowie der für den Nutzer des Systems möglichen Interaktionen und schließlich der An- und Zuordnung sowie die Benennung der in dem System enthaltenen Informationseinheiten und Funktionen.

(Quelle: Wikipedia)

Kurzdefinition aus „Informationsarchitektur für das World Wide Web“ Second Edition:

  • Eine Kombination des Bezeichnens und der Navigationsstruktur innerhalb eines Informationssystems.
  • Das strukturelle Design eines Informationsraumes, um Aufgaben(-Vollendung) und intuitiven Content-Zugang zu erleichtern.
  • Die Kunst und Wissenschaft der Strukturierung und Klassifizierung von Websites und Intranets, um den Nutzern zu helfen, Informationen zu finden und zu ordnen.

(Quelle: Institut für Informationsarchitektur)

Es geht also bei der Informationsarchitektur darum, ein Informationssystem (Intranet, Extranet, Internet, Kollaborationssystem etc.) so zu gestalten, dass der darin liegende Inhalt für den Nutzer möglichst schnell und intuitiv zugänglich ist. Die Frage, welche sich bei einer Informationsarchitektur also stellt, ist: Wie findet jede individuelle Benutzergruppe die von ihr benötigte Information in möglichst kurzer Zeit. Dabei spielt der Aspekt der Multiperspektivität eine wesentliche Rolle.

Das Resultat ist ein Dokument, welches die Seiten und Unterseiten sowie deren Inhalt aufzeigt. Weiter wird darin geregelt, wer wo welche Zugriffe hat und wo mit wem welche Interaktion stattfindet sowie wer für welche Inhalte verantwortlich ist.

Planen einer Informationsarchitektur

Beim Planen einer Informationsarchitektur steht der End User im Zentrum der Informationsbetrachtung. Meines Erachtens muss aber im selben Moment die Informatik im Zentrum der – ich will es mal die Betreibbarkeitsbetrachtung nennen – stehen. Das beste Informationssystem mit allen Freiheiten für den End User nützt nämlich nichts, wenn es nicht mehr mit angemessenem Aufwand betrieben werden kann. Um die Informationsarchitektur zu umzusetzen, braucht es diverse Zwischenschritte um zu einem befriedigenden Ergebnis zu kommen.

Bestandteile einer Informationsarchitektur

Wir werden in dieser Serie über die folgenden Bereiche sprechen:

  • Usability und Userfriendlyness
  • Service Design und Betreibbarkeit
  • Sitemap und Inhaltsstruktur
  • Rechte- und Rollenkonzept
  • Webdesign und Layout
  • Taxonomie und Tagging

Freuen Sie sich auf eine spannende weitere Serie
so long, Samuel

Aus dem Alltag: 503 Service Unavailable in der Central Administration


Problem:

Nachdem ich bei einem Kunden erfolgreich SQL Server 2008 R2 und SharePoint Server 2010 installiert hatte, erhielt ich beim erstmaligen Öffnen der Central Administration (Zentraladministration) den folgenden Fehler:

Service Unavailable

——————————————————————————-

HTTP Error 503. The service is unavailable.

 

Die Kontrolle im Windows Log ergab folgende drei Einträge:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5021
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
The identity of application pool SharePoint Central Administration v4 is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request.  If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5057
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
Application pool SharePoint Central Administration v4 has been disabled. Windows Process Activation Service (WAS) did not create a worker process to serve the application pool because the application pool identity is invalid.

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5059
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
Application pool SharePoint Central Administration v4 has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.

Grund:

Wie aus den Log Einträgen ersichtlich wird, fehlt dem Application Pool Account die folgende Berechtigung “Logon as a batch job”, welche in den Security Policies definiert werden können. In unserem Fall war diese Einstellung von einer überliegenden Policy auf unser System publiziert worden. Diese Berechtigung wird benötigt, damit der Windows Process Activation Service dem entsprechenden Application Pool einen Worker Process zuordnen kann.

Lösung:

  1. Kontrollieren Sie, ob die “Logon as a batch job” Policy von einer höheren Instanz gesteuert wird.
    1. Klicken Sie auf Start –> ausführen
    2. Geben Sie “secpol.msc” ein und drücken Sie Enter
    3. Navigieren Sie zu Local Policies –> User Rights Assignment –> Log on as a batch job
      image
  2. Ist die “Logon as a batch job” Policy nicht übersteuert, kontrollieren Sie ob IIS_IUSRS berechtigt sind. Wenn nicht, vergeben Sie diese.
  3. Ist die Policy übersteuert (sie können lokal keine Änderungen vornehmen), so bearbeiten Sie die entsprechend übergeordnete Policy:
    1. Erstellen Sie eine Active Directory Gruppe, welcher Sie alle Application Pool User von SharePoint zuordnen (inkl. dem Service User für die Service Applications (SharePoint 2010) oder dem Shared Services Provider (SharePoint 2007) und dem Farm User für die Central Administration)
    2. Fügen Sie die Active Directory Gruppe der die Policy “Logon as a batch job” hinzu

So long, Samuel Zürcher

SharePoint Governance Teil V: Rechte


Kommen wir nun zum Bereich Rechte. Natürlich ist es auf jeder Plattform essentiell, sich über Rechte oder Berechtigungen zu unterhalten. Hier kommen wir an einen Punkt, der sehr kontrovers und z.T. auch heiss diskutiert wird. Wir wollen versuchen, den Weg der Best Practices zu verfolgen. Um eine saubere Rechtestruktur zu vermitteln, muss ich etwas ausholen und teile diesen Blogpost in verschiedene Teile ein.

Einführung

In der Rechtevergabe bei SharePoint möchte ich es sehr einfach halten. Wir unterscheiden SharePoint Gruppen, Active Directory Gruppen, User und Berechtigungsstufen.

Berechtigungselement Beschreibung
SharePoint Gruppe SharePoint Gruppen werden in SharePoint selbst angelegt. Sie dienen dazu, Inhalte von SharePoint mit Berechtigungen zu versehen. Sie enthalten User oder Active Directory Gruppen, nie aber weitere SharePoint Gruppen. SharePoint Gruppen werden von der IT oder von Super Usern gemanaged und auf Site Collections, Sites, Bibliotheken, Listen oder einzelne Items vergeben.
Active Direcotry Gruppe Diese Gruppen werden von der IT gemanaged. Sie enthalten User und sind z.T. auch im Outlook als Verteilergruppen sichtbar. Sie können in SharePoint Gruppen vergeben oder direkt wie solche verwendet werden.
User User werden von der IT im Active Directory angelegt. Sie regeln den Zugang zu Systemen und setzten sich aus einem Login und einem Passwort zusammen. Zusätzlich können weitere Informationen zum User hinterlegt werden.
Berechtigungsset Sie regeln die eigentliche Berechtigung auf einer Seite bzw. einem Item(Dokumente etc.) Stichwort dazu: CRUD (Create, Read, Update, Delete). Berechtigungssets werden an AD Gruppen, SP Gruppen oder User angehängt.

Es gibt folgende Arten, Berechtigungen zu steuern:

  1. Vergeben von Rechten direkt an User (DON’T DO THIS)
  2. Vergeben von Rechten direkt an AD Gruppen (DON’T DO THIS)
  3. Erstellen von SharePoint Gruppen und einfügen von AD Gruppen
  4. Erstellen von SharePoint Gruppen und einfügen von Usern
  5. Erstellen von SharePoint Gruppen und eine Kombination von 3 + 4 (Für die meisten Szenarien empfohlene Variante)

Es gibt Szenarien, wo es durchaus Sinn macht, alles in AD Gruppen zu steuern und diese in SharePoint Gruppen zu verteilen (Nr. 3) doch meistens macht es sinn, diesen Aufwand von der IT wegzunehmen und an Power User zu übergeben. Warum? Die IT weiss meist so wie so nicht, ob diese Rechte Sinn machen oder nicht. Sie befolgen einen Auftrag, der meist per Formular zu ihnen gekommen ist. Warum nicht die Abteilungen ihre Rechte mit einem definierten Prozess selbstständig regeln lassen? AD Gruppen werden so wie so gepflegt, also alles was so wie so gepflegt wird mit AD Gruppen lösen. Was aus dem Schema fällt löst man dann besser mit einzelnen Usern, welche man den SharePoint Gruppen zusätzlich zu den bereits bestehenden AD Gruppen hinzufügt.

Also nochmal zur Repetition: User kommen automatisch in AD Gruppen. Diese wiederum verteilt man in SharePoint Gruppen, wo das nicht reicht, ergänzt man die SharePoint Gruppen mit einzelnen Usern.

SharePoint Gruppen

Versuchen Sie die meisten Szenarien mit den SharePont Standardgruppen zu lösen. Wenn eine Webseite erstellt wird, so stehen folgende SharePoint Gruppen zur Verfügung.

  1. Besitzer von…
  2. Besucher von…
  3. Mitglieder von…

image

Sobald Publishing (Veröffentlichungs-Infrastruktur) auf Site Collection Ebene aktiviert wird, kommen folgende SharePoint Gruppen dazu:

  1. Anzeigende Benutzer
  2. Designer
  3. Formatressourcenleser
  4. Genehmigende Personen
  5. Hierarchie-Manager
  6. Personen mit eingeschränkten Leserechten

image

Diese Gruppen werden nun auf der Ebene Site Collection, Site, Bibliothek, Liste oder Item vergeben. Natürlich kann man auch beim sogenannten Brechen von Berechtigungen einzelne User oder AD Gruppen vergeben, doch dies ist absolut nicht empfehlenswert, da sonst der Überblick verloren geht.

Rightsmanagement

Eine Site Collection vererbt an seine Inhalte (Unterwebseiten, Bibliotheken, Listen, Items), Eine Webseite vererbt an seine Inhalte (Unterwebseiten, Bibliotheken, Listen, Items), eine Bibliothek bzw. Liste vererbt an seine Inhalte (ggf. Ordner, Items). An jeder Stelle kann die Vererbung gebrochen und eine SharePoint Gruppe, eine AD Gruppe oder ein User eingesetzt werden. Wir auf der Ebene Webseite gebrochen, so vererbt diese Webseite die neu eingesetzten Berechtigungen wiederum auf die Unterwebseiten, Bibliotheken, Listen und Items. Wird auf der Ebene Bibliothek gebrochen, so erben danach ggf. Ordner und Items. Wird auf der Ebene Item gebrochen so betrifft es nur noch dieses Item.

Berechtigungsstufen

Grundsätzlich gibt es sechs Berechtigungsstufen. Natürlich kann man sich ganz individuelle Berechtigungsstufen konfigurieren, doch SharePoint liefert in der Grundstruktur sechs Stufen:

  1. Teilnehmen (Neu: Mitwirken)
  2. Lesen
  3. Vollzugriff
  4. Design
  5. Beschränkter Zugriff
  6. Nur lesen

Designen wird wird oft nur aufgrund von Szenarien gebraucht, bei welchen mit Genehmigungen (Einstellung in einer Bibliothek oder Liste) gearbeitet wird. Es empfiehlt sich jedoch, für Genehmigungen entweder die Publishing Gruppe “Genehmigen” zu benutzen, diese wird allerdings nur sichtbar, wenn Publishing auf der Site Collection aktiviert ist. Wenn Publishing nicht eingesetzt wird oder lediglich die SharePoint Foundation eingesetzt wird würde ich das Teilnehmen Berechtigungsset kopieren, neu benennen und zusätzlich Genehmigungsrechte zu vergeben.

image

Wird das Publishing aktiviert (Veröffentlichungs-Infrastruktur), stehen zusätzlich folgende Berechtigungsstufen zur Verfügung:

  1. Genehmigen
  2. Hierarchie verwalten
  3. Eingeschränkter Lesezugriff

image

Ich rate Ihnen an, sich an diese Standard Gruppen zu halten, denn mit ihnen lassen sich 90% aller Szenarien abbilden. Sie begeben sich auf dünnes Eis, wenn Sie anfangen, eigene Berechtigungsstufen zu erstellen.

Ausnahmen:

  • Sie benötigen ein Berechtigungsset, welches das Löschen von Content ausschliesst, nicht aber das Erstellen oder das Ändern von Content.
  • Sie arbeiten mit SharePoint Fundation und haben an ein- oder mehreren Stellen die Inhaltsgenehmigung aktiviert

Jede SharePoint Gruppe (und wenn man einzelne User oder AD Gruppen direkt berechtigen würde diese auch) erhält nun eine solche Berechtigungsstufe. Die Berechtigungsstufe definiert, welche Rechte die Gruppe am eingesetzten Ort hat. Auch hier gibt es natürlich auch Spielvarianten, wie Gruppe A hat auf der Bibliothek B grundsätzlich “Mitwirken” als Berechtigungsstufe, doch auf dem Ordner X in der Bibliothek B hat die selbe Gruppe A nur “Lesen”. Auch hier ist absolute Vorsicht geboten, man kann also ggf. nicht davon ausgehen, dass eine Gruppe einfach überall diese Rechte hat, wie es den Anschein haben mag.

Roundup

Wie wir nun sehen, ist das Ganze schon an und für sich komplex. Wenn Sie nun anfangen, die Berechtigungen wild zu vergeben (Person X und Y haben Rechte auf Ordner A und B, Person Y und Z haben Rechte auf Ordner C und D etc.), dann werden Sie sich schon bald im puren Chaos wiederfinden. Wie stellt man also sicher, dass die Berechtigungen einigermassen im Griff zu halten sind?

Hier kommen wir nun zurück auf die Rollen. Es ist meines Erachtens zwingend, dass man die definierten Rollen auch gleich dazu verwendet, die Berechtigungen festzulegen. Welche Rolle hat welche Gruppenzugehörigkeit? Damit ist auch gleich klar, was die Rolle für Berechtigungen hat.

Szenario:
Sie haben ein Projekt, in welchem verschiedene Personen involviert sind. Sie möchten gerne die Berechtigungen dazu festlegen, wie gehen sie am besten vor.

Methode A:
Sie vergeben die Berechtigungen der Personen direkt auf die Ordner und Inhalte anhand Ihren Bedürfnissen.

Vorteile Nachteile
  • Direkte und individuelle Vergabe von Rechten möglich
  • Keine Übersicht über die vergebenen Rechte
  • Schwieriges Szenario bei neuen Projektmitgliedern (Wo muss die Person überall berechtigt sein?
  • Viel Zeitaufwand beim managen der Zugriffe
  • Um einigermassen den Überblick zu erhalten muss ein Excel mit den vergebenen Rechten geführt werden.

 

Methode B:
Sie vergeben die Berechtigungen der Personen mittels verschiedenen SharePoint Gruppen

Vorteile Nachteile
  • Gute Übersicht durch vorhandene Gruppen
  • Individuelle Vergabe von Rechten möglich
  • Schwieriges Szenario bei neuen Projektmitgliedern (In welche SharePoint Gruppen muss die Person verteilt werden?)
  • Nach wie vor viel Zeitaufwand beim managen der Zugriffe
  • Es muss ein Excel geführt werden, welche Gruppe wo Zugriff hat, und wer in welcher Gruppe ist.

 

Methode C:
Sie definieren klare Rollen (Projektleiter, Projektassistenz, Projektmitarbeiter, Berater, Besucher), erstellen pro Rolle eine SharePoint Gruppe mit entsprechender Berechtigungsstufe und verteilen die User nach ihren Rollen in eine der Gruppen. Die SharePoint Gruppen werden dann auf den Inhalt verteilt. (Projektleitungsordner etc.)

Vorteile Nachteile
  • Gute Übersicht durch vorhandene Gruppen
  • Schnelle Vergabe von Rechten möglich
  • Klare Verwaltung der Zugriffe
  • Bei Wechsel im Projekt müssen Sie die neue Person nur gemäss ihrer Rolle in eine der Gruppen berechtigen
  • Es braucht lediglich ein Grundkonzept welche Rolle was darf, dies ist danach generisch auf alle weiteren Projekte anwendbar
  • Gewisse Einschränkungen durch die Bindung an ein Rollenmodell und daraus entstehender Mehraufwand bei der Planung

 

Wie Sie sehen, ist Methode C die beste Wahl. Wenn ich betrachte, wie viel Aufwand betrieben werden muss um die Berechtigungen einigermassen im Griff zu halten, ist Methode C die zumindest erfolgversprechendste der drei Methoden. Ansonsten müssen Leintuchmässige Excel Listen geführt werden, um zu wissen, wer wo berechtigt ist.

Fazit

Ich möchte folgende Kernaussagen festhalten:

  • Verwenden Sie die Rollen, um die Berechtigungen zu bestimmen.
  • Nehmen Sie den initialen Aufwand in Kauf, dass für jedes Szenario Rollen gebildet werden müssen, sie werden es dafür später leichter haben.
  • Lassen Sie sich nicht von der Angst der unflexibilität in eine wilde Rechtevergabe treiben
  • Anwender möchten immer gerne alles in einem kleinen Garten geschützt haben (Ich und X haben Zugriff auf Ordner A etc.), doch dies ist nicht verwaltbar.
  • Verwenden Sie möglichst viel die Standardgruppen von SharePoint
  • Verwenden Sie möglichst ausschliesslich die Standard Berechtigungsstufen von SharePoint

Das Berechtigungsmanagement ist eines der heikelsten und auch der kontroversesten Themen im SharePoint. Lassen Sie sich nicht verwirren, es braucht eine Zeit bis man ein klares Konzept davon erfassen kann.

Lo long, Samuel

SharePoint Governance: Teil IV Prozesse


Heute geht es zum nächsten Teil unseres SharePoint Governance Rades, zu den Prozessen. Sie bilden einen wichtigen Teil im Governancemodell für SharePoint. Wann entsteht zum Beispiel eine neue Projektsite und wie?

Die Prozessorganisation von SharePoint muss sich natürlich an der Prozessorganisation Ihres Unternehmens orientieren. Wenn Ihr Unternehmen nicht prozessorientiert arbeitet, dann definieren Sie zumindest Regeln, wie und wann bestimmte Aktivitäten ausgeführt werden (müssen). Folgende Dinge sind sehr wichtig zu planen und ggf. als Prozesse aufzunehmen:

Welche Schritte sind notwendig…

  • bevor eine neue Webseite oder Webseitensammlung erstellt wird
  • um eine neue Webseite oder Webseitensammlung zu erstellen
  • nachdem eine neue Webseite oder Webseitensammlung erstellt wurde
  • um Inhalte zu archivieren
  • um eine Webseite oder Webseitensammlung zu löschen

In der Folge werde ich nun zu jedem Punkt etwas zu möglichen Inhalten erwähnen. Wie gesagt, müssen sich Prozesse in Ihre Prozesslandschaft bzw. in Ihr Unternehmen integrieren, aus diesem Grund kann ich hier nur Hinweise und meine Gedanken  weitergeben.

Welche Schritte sind notwendig bevor eine neue Webseite oder Webseitensammlung erstellt wird

In diesen Bereich gehören Aktivitäten die den Anwender befähigen herauszufinden, ob für sein Begehren überhaupt eine SharePoint Seite erstellt werden kann. Ihre Informationsarchitektur (dazu mehr in einem weiteren Blog) muss klare Strukturen beinhalten, welche beschreiben, welche Informationen wo und wie in platziert werden oder eben nicht. Findet der Anwender heraus, dass für sein Begehren keine SharePoint Plattform erstellt werden kann, muss er z.B. auch wissen, wo er sich in welcher Form hinwendet, um sein Begehren anzumelden. Es kann ja durchaus sein, dass durch veränderte Businessbedürfnisse ggf. die Informationsarchitektur angepasst werden muss.

Weiter enthält dieser Bereich Anweisungen zu Schritten oder Informationen, welche Dinge der Anwender bereitstellen bzw. abklären muss, um eine SharePoint Webseite erstellen zu können, sofern sein Begehren in der Informationsarchitektur vorgesehen ist. Dieser Teil ist wiederum sehr an Richtlinien und Strategien Ihres Unternehmens anzulehnen. Hier können Dinge wie Platzbedarf, Verwendungsdauer, Klassifikation (z.B. Confidential etc.) oder Rollenverteilung aufgelistet werden, wobei diese Liste längst nicht abschliessend ist.

Welche Schritte sind notwendig um eine neue Webseite oder Webseitensammlung zu erstellen

Wenn der Anwender vom vorherigen Schritt weiss, welche Art Webseite oder Webseitensammlung er erstellen kann und welche Informationen er dazu angeben muss, kann der eigentliche Erstellungsprozess starten. Auch hier können verschiedene Szenarien abgebildet werden. Diese gehen von einem Wordformular das ausgefüllt an die IT gesendet wird, welche dann entsprechend der Informationen die richtige Seite mit dem richtigen Template erstellt über halbautomatisierte Prozesse mit elektronischen Formularen bis hin zu eigenentwickelten Lösungen oder Drittanbieter Software sie z.B. MatchPoint welche ein vollintegriertes automatisches Provisionning von Webseiten oder Webseitensammlungen zulassen.

Nach diesem Schritt ist die entsprechende Webseite oder Webseitensammlung erstellt und kann genutzt werden. Es können hier auch Informationsflüsse abgebildet werden, wer z.B. in welchem Fall informiert wird oder wer ggf. welchen Erstellungsprozess bewilligen muss. Auch solche Szenarien können hier vertreten sein. Zusammegefasst einfach welche Schritte, Informationen, Aktionen und Genehmigungen sind von welcher Stelle notwendig, bis einen spezifischer Arbeitsraum in SharePoint erstellt ist.

Welche Schritte sind notwendig nachdem eine neue Webseite oder Webseitensammlung erstellt wurde

Hier kommen Aspekte wie z.B. Pflege von Inhalt und Berechtigungen zur Sprache. Wie geht man z.B. vor, wenn Teilnehmer hinzugefügt, bzw. entfernt werden müssen? Wie beantrage ich einen Zugang für eine externe Person? Auch muss darüber nachgedacht werden, wie mit Inhalten umzugehen ist. Wenn es sich z.B. um vertrauliche Daten handelt, wie müssen diese hochgeladen werden, wie müssen diese gelöscht werden etc.

Dieser Bereich kann in verschiedenen Szenarien sehr gering gehalten werden. Es kommt darauf an, wie genau Sie den Inhalt steuern wollen, welcher auf der Plattform gespeichert wird. Zumindest die Berechtigungsregelung sollte aber abgedeckt werden.

Welche Schritte sind notwendig um Inhalte zu archivieren

Im besten Fall wird ein Grossteil der Arbeitsräume  zu einem Bestimmten Zeitpunkt wieder gelöscht. Im Normalfall hat die Arbeit in einem solchen Arbeitsraum Ergebnisse geliefert, welche weiterverwendet werden. Man kann diese auch als Lieferobjekte bezeichnen. Diese sind zu archivieren, oder in einen anderen Arbeitsraum (z.B. DMS Bereich) zu verschieben. In diesem Abschnitt beschreiben Sie, wie dazu vorgegangen werden muss. Alle Daten, welche zur Unterstützung der Erstellung der Lieferobjekte gedient haben können gelöscht werden, und das ist meist der grösste Teil.

Welche Schritte sind notwendig um eine Webseite oder Webseitensammlung zu löschen

Zum Abschluss werden noch die Schritte beschrieben, welche dann zur Löschung des Arbeitsraumes führen. Hier muss der Anwender ggf. angeben, dass er alle relevanten Daten archiviert hat. Danach folgt eine Abfolge von Tätigkeiten und Zuständigkeiten um die Webseite oder die Webseitensammlung zu löschen. Natürlich kann auch hier ein Drittanbietersystem eingesetzt werden, welches alle Inhalte aus SharePoint herauszieht und auf billigem Speicherplatz ablegt. So gehen keine Informationen verloren und doch wird die SharePoint Infrastruktur entschlackt.

 

Soviel grob zum Bereich Prozesse in der SharePoint Governance. Wie mehrmals erwähnt muss dieser Bereich individuell auf die Ablauf- und Aufbauorganisation Ihres Unternehmens angepasst werden, es macht viel Sinn, hier einen SharePoint Profis beratend beizuziehen.

So long, Samuel Zürcher

Aus dem Alltag: Timer Job Probleme


Wenn Sie mit Timer Jobs auf SharePoint arbeiten, so kann es vorkommen, dass ein Timer Job, welcher deinstalliert wurde, trotzdem noch weiter läuft. Der SharePoint Timer Service hat den Code im Cache, und sollte nach der Deinstallation neu gestartet werden.

Nach dem Neustart des SharePoint Timer Services ist alles wieder so wie es sein sollte.

  1. Klicken Sie auf Start –> Ausführen und geben Sie services.msc ein.
  2. Suchen Sie nach Windows SharePoint Services Timer
  3. Klicken Sie auf “Restart”

image

SharePoint Governance: Teil III Rollen


Nun kommen wir zum nächsten Punkt, die Rollen. Es gibt zwei Ansätze, wie man Rollen verstehen kann.

  1. Aus IT Sicht, wo eine Rolle immer direkt mit einem definiterten Berechtigungsschema hinterlegt ist
  2. Aus Business Sicht, in welcher an verschiedenen Stellen im Unternehmen gleiche Rollen anders wahrgenommen und ausgefüllt werden

Ich nehme ein paar Beispiele:

  • In der IT ist die Rolle des Systemadministrators gegeben, er ist der, welcher auf den Servern Zugriff hat und darauf arbeitet. Die Rolle des Supporters ist die, welche Telefone entgegennimmt und die daraus entstehenden Issues an den Systemadministrator weitergibt, wenn er diese nicht selbst lösen kann. Meist nimmt der Systemadministrator nur selten die Rolle des Supporters ein und umgekehrt, es sei denn, man hat eine kleine IT Infrastruktur und jeder muss jede Rolle wahrnehmen.
  • In der Business Sicht ist die Rolle etwas Anderes. Es ist ein Aufgabenbereich, welcher in einer bestimmten Konstellation zusammengestellt ist bzw. wird. So kann z.B. sehr gut ein Abteilungsleiter der Abteilung B gleichzeitig ein Mitarbeiter in Bereich A sein. In einer anderen Abteilung ist der selbe Mitarbeiter nur Besucher und in einer dritten Abteilung vielleicht noch Stellvertreter. Dieses Szenario liesse sich beliebig ausweiten, wenn man  z.B. noch die Projektebene hinzunimmt, welche doch (möchte ich behaupten) in jedem Unternehmen vorkommt. In jedem Projekt gibt es wieder eigene Rollen, in denen Mitarbeitende wie in einer Matrixorganisation diverse Rollen einnehmen können. Ist ein Mitarbeiter in Projekt A ein Projektleiter, so kann es durchaus sein, dass er in Projekt B Mitarbeiter ist und in Projekt C gar keinen Zugriff hat.

Wir sehen also, die Business Sicht auf ein sogenanntes Rollenkonzept viel weiter reicht als lediglich ein Berechtigungsset zu definieren. Natürlich haben wir bei genauerem Hinschauen auch in den IT Rollen Überschneidungen und auch in der Business Sicht liessen sich starre Modelle realisieren. Doch wichtig ist hier, Rollen bestimmen nicht nur ein Set an Rechten und Zugriffen. Dies ist nur ein Teil davon, sondern sie bestimmen auch ggf. Aufgaben,  Kompetenzen und Verantwortlichkeiten.

Um ein Rollenkonzept zu definieren, brauchen Sie zuerst einen Überblick über das Business. Wir sind ja auf einer SharePoint Seite, also sprechen wir natürlich nur über Rollen, welche dann auch mit SharePoint in Verbindung stehen. Von der Business Sicht muss also zuerst angeschaut werden, welche Informationsarchitektur besteht. Sprich: Wo werden wir welche Inhalte auf welche Weise verwalten. Auch hier wieder ein Beispiel: Viele Firmen arbeiten mit Projekten. Ein Projekt ist eine perfekte Endität für eine SharePoint Seite oder eine SharePoint Webseitensammlung. Welche Rollen habe ich in meinem Unternehmen, welche mit diesem Projekt zu tun haben werden? Hier eine nicht abschliessende Liste einer Grundausstattung. Natürlich können wir auch die Rollen eines Projektes zu tode aufblasen, jede nur erdenkliche Rolle hinzufügen.

  • Projektleiter
  • Projektassistenz
  • Projektmitarbeiter
  • Externe Beteiligte
  • Projektcontrolling
  • Besucher

Gestützt auf die Rollen werden dann die Aufgaben und die Berechtigungen verteilt. In SharePoint sind vor Allem die Rechte relevant, da die AKV betriebsorganisatorisch geregelt werden müssen. Man kann also hingehen, und z.B. einen PL Ordner machen, auf welchen nur die Rolle PL und Projektassistenz so wie Controlling Zugriff haben.

Analog diesem Beispiel kann nun jede Umgebung (Intranet, DMS, Extranet, Projektportal etc.) mit Rollen versehen und Berechtigungsmässig strukturiert werden. So lassen sich im SharePoint Wildwuchs und Berechtigungschaos (welches auch auf den Fileservern herrscht) vermeiden. Wichtig ist, Business first. Also zuerst das Business in logische Einheiten einteilen, die Rollen und Aufgaben klären und dann die Struktur des SharePoint designen.

So long, Samuel

SharePoint Governance Teil II: Richtlinien


Wie bereits in der Übersicht gezeigt, kommen als nächstes die Richtlinien. Es ist eigentlich egal, in welcher Reihenfolge man die einzelnen Punkte anbarbeitet, wichtig ist nur, dass alle Aspekte vertreten sind. Doch macht es sicherlich Sinn, sich in einem frühen Stadium des Projektes Gedanken über Richtlinien zu machen. Die Frage, welche man sich bei den Richtlinien stellen sollte ist: „Wer soll/darf was ausführen/angehen“ Im Gegensatz zu den Rechten wird hier gefragt, wer nach den Richtlinien etwas angehen/ausführen soll/darf. Es kann nämlich durchaus sein, dass jemand rein von den Berechtigungen her (technisch) etwas tun könnte, was ihm von den Richtlinien her verboten ist (organisatorisch). Meiner Ansicht nach macht es nämlich überhaupt keinen Sinn, alles technisch verbieten und einschränken zu wollen, damit der Anwender wirklich nur noch das tun kann, was er wirklich ausdrücklich darf.

Wo ist denn hier bitte die Eigenverantwortung des Mitarbeiters? Jeder ist für sein Tun verantwortlich. Man kann doch wirklich noch davon ausgehen, dass jeder, der einen Job hat, diesen zur Zufriedenheit des Arbeitgebers ausfüllen möchte. In der Regel arbeiten erwachsene Menschen im Unternehmen mit, welchen man durchaus einen gesunden Menschenverstand zutrauen darf. Jede technische Einschränkung bedarf wieder eines gewissen Management Overheads, der wiederum Kosten verursacht und wertvolle Ressourcen bindet. Und ja, mir ist bewusst, dass es bei einem solchen Ansatz auch schwarze Schafe gibt, die eine solche Situation ausnutzen. Doch diese muss auch man viel eher organisatorisch schären, als mit viel Aufwand und technischem Einsatz die weissen Schafe zu bestrafen. Sehen wir der Tatsache ins Auge: Ist jemand darauf aus, schlechtes zu tun, wird er auch Mittel und Wege finden, auch trotz technischen Hürden. Wer einen Hund schlagen will, findet immer einen Stock.

Ich nehme mal den Good-Guy Bad-Guy Ansatz zum veranschaulichen:

Bad-Guy Ansatz:
Gehen Sie davon aus, dass Ihre Mitarbeitenden nicht in der Lage sind, eigenverantwortlich zu handeln, werden Sie ihnen technische Hürden in den Weg legen und sicherstellen, dass jeder nur seinen Teil der Arbeit im vorgegebenen Prozess verrichten kann. Dadurch wird die Offenheit untereinander gehindert, die Mitarbeitenden werden nicht in eine eigenverantwortliche Position gebracht und können so nur Dienst nach Vorschrift leisten. Dadurch wird Innovation und aktives Mitdenken gehemmt und die Mitarbeitenden werden nicht die grossen Würfe an den Tag legen und einfach nur wie Lemminge den Vorgaben folgen. Was Ihnen wiederum bestätigt, dass Ihre Mitarbeitenden nicht eigenverantwortlich handeln können.

Good-Guy Ansatz:
Gehen Sie davon aus, dass Ihre Mitarbeitenden in der Lage sind, eigenverantwortlich zu handeln, werden Sie alles tun, um eine möglichst offene Landschaft zu bauen, in welcher nur die wirklich notwendigen Einschränkungen gelten und nur die notwendigen Regulierungen aufbebaut werden. Dadurch fördern Sie die Zusammenarbeit und den gegenseitigen Austausch. Sie bestätigen damit Ihr Vertrauen in die Mitarbeitenden und vermitteln ihnen ein Gefühl von Selbstständigkeit und wahrgenommener Eigenverantwortung. Dies wiederum fördert den Innovationsgeist und lässt aktives Mitdenken zu. Mitarbeitende werden auch einmal etwas neues ausprobieren, wobei oft sehr gute Ideen aus so etwas erwachsen können. Jeder bringt seinen Teil ein, was Ihnen bestätigt, dass ein offener Ansatz die beste Lösung ist.

Haben Sie also z.B. ein Corporate Design, dann weisen Sie Ihre Mitarbeitenden per Richtlinie an, dir richtigen Designs zu verwenden. Haben Sie einen bestimmten technischen Aufbau im SharePoint, so erstellen Sie eine Richtlinie, wie Seiten richtig erstellt werden müssen. Oder haben Sie ein bestimmtes Standardlayout, so erstellen Sie eine Richtlinie über die Verwendung von Standardseiten. Lassen Sie so viel Innovation wie möglich zu, ohne Ihre Struktur unwartbar zu machen. Setzen Sie Leitplanken und lassen Sie genügend Spielraum um eine gewisse Bandbreite von Individualität zu ermöglichen. Doch denken Sie daran: Es soll nicht die Devise sein, macht was ihr wollt, sondern eher Hier ist ein Minima und ein Maxima, bewegt euch darin. Ihr könnt zwar viel, aber dürft nicht alles. Schaffen Sie Standards und Guidelines. Brinen Sie den Mitarbeitenden bei, sich in bestimmten Bahnen zu bewegen. Die denkbaren Szenarien sind dabei schier unerschöpflich. Passen Sie das gesamte Paket Ihrer Branche, den gesetzlichen Bestimmungen und Regulatorien an.

So frei wie möglich, so geführt wie nötig. Beim nächsten Mal werden wir das Thema Rollen angehen.

So long, Samuel Zürcher