Nachdem bereits einige super Vorträge eingegangen sind, möchte ich einen Aufruf an alle SharePoint Begeisterten absetzten. Social Computing ist eines der stärkst wachsenden Segmente in der Internetwelt. Mit ca. 6 Personen ist man im Schnitt mit dem Rest der Welt verbunden. Einer Freundesempfehlung folgt man mehr als einer allgemeinen Werbung. Dies möchten wir uns mit den Collaboration Days zu Nutze machen, doch dafür braucht es die COMMUNITY, als DICH. Wenn Du diesen Eintrag hier liest, gehörst Du bereits dazu, denn aus irgendeinem Grund bist Du ja hier gelandet, nicht?

Jeder einzelne kann diese Schweizer SharePoint Konferenz 2010 erfolgreich machen. Ob als Sprecher/in, als Teilnehmer/in, als Unterstützer/in, als Aussteller/in, als Sponsor/in oder einfach als als die Person, welche den Event an seine/ihre Freunde weitergibt. Du kannst auch Freundschaftswerbung machen, wenn Du selber nicht teilnehmen kannst oder willst. Es reicht, wenn Du jemanden kennst, der die Konferenz ev. interessieren könnte und Du ihm/ihr vom Event erzählst.

Wie kannst Du dich beteiligen?

• Als Sprecher/in: Reich Deinen Call for Paper ein (auch Englisch)  http://www.collaborationdays.ch/Call_for_Papers.html
• Als Teilnehmer/in: Melde Dich an http://www.collaborationdays.ch/Anmeldung.html
• Als Unterstützung: Sende eine Mail mit Deinem Unterstützungsvorschlag an Stefan.Heinz@SharePointCommunity.ch oder an Stefan.Heinz@Collaborati0ndays.ch
• Als Aussteller: Melde Dich als Aussteller an http://www.collaborationdays.ch/Aussteller.html
• Als Sponsor: Melde Dich als Sponsor an http://www.collaborationdays.ch/sponsoren.html
• Mache die SharePoint Konferenz der Schweiz Deinen Freunden bekannt, in Twitter, Facebook, XING, LinkedIn etc…
• Nutze beim Twittern unbedingt den HASHTAG #CollabDays um auf der Seite http://www.collaborationdays.ch zu erscheinen
• Wenn Du keinen Account bei einem der Sozialen Plattformen hast, maile ganz einfach den Link zur Homepage an Freunde und Bekannte
• Verlinke diesen Blog Eintrag in Deinem Blog, damit noch mehr Menschen ihn lesen und die Information verteilen.

Lasst uns die Welt erreichen, SPREAD THE WORD

So long, Samuel

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

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

Wie bereits erwähnt, ist SharePoint Governance eines ihrer wichtigsten Anliegen beim oder besser vor dem Start eines SharePoint Projektes. Ohne ein anständiges Konzept über die Überwachung und Steuerung der Sites und Berechtigungen werden Sie bald in sehr viel Arbeit versinken. Ein Motto, das mich in meiner Projektarbeit stark geprägt hat und immer wieder auf den Tisch kommt ist:

Wer nicht weiss was er will, bekommt das was er nicht braucht

Es geht also auch darum, sich Gedanken zu machen, was man genau mit SharePoint machen will. Nur wenn der Auftrag klar ist, welchen man mit SharePoint erfüllen will, kann auch über ein mögliches Governance Modell nachgedacht werden. In diesem Überblick gebe ich Ihnen einen möglichen Ansatz, wie so ein Modell aussehen könnte.

Das Governance Rad

Dieses “Rad”, wie wir es ja beim SharePoint gewohnt sind, soll die Aspekte des Governance beleuchten. In meiner Postserie über Governance werde ich nach und nach alle diese Aspekte einzeln beleuchten und mit nützlichen Tipps füllen. Nachfolgend ein kurzer Abriss über die Begrifflichkeiten.

• Richtlinien – Wer soll/darf was ausführen/angehen
• Rollen – wer macht was
• Prozesse – Wie wird etwas ausgeführt/erstellt
• Rechte – Wer hat wo zugriff
• Lifecycles – Wie entsteht Information und wohin geht sie
• Verantwortung – Wer ist wofür zuständig

Alle diese Themen müssen mit SharePoint interagieren, will man ein funktionierendes, nachhaltig entwickelbares System mit SharePoint bauen. Die Frage welche sich zusammenfassend noch stellt ist, wie wird das Governance Modell überwacht? Auch das gehört nämlich zum Thema Governance. Es nützt nichts, nur Definitionen und Regeln zu haben, wenn diese weder gelebt noch durchgesetzt werden.
Wussten Sie z.B. dass Italien eines der schärfsten Umweltgesetze hat? (Ich erinnere nebenbei an den Müllskandal) Jede Regel, jede Abmachung, jede SLA, ja jegliche Vereinbarung irgendwelcher Art ist nur so gut wie ihre Akzeptanz, Umsetzung und Kontrollmöglichkeit so wie die Konsequenz bei Nichteinhaltung. Wer nicht gewillt ist, eine Regel durchzusetzen, kann sich die Zeit sparen sie zu formulieren. Auch hier wieder: Wichtig ist, dass die Management Etage hinter dem Modell steht und gewillt ist, es auch um- bzw. auch durchzusetzen.

In den nächsten Posts rund um Governance mehr zu den einzelnen Themengebieten.

Ich möchte ein paar Worte über SharePoint Governance verlieren.
Governance ist ein bereits sehr verbreiteter Begriff und klingt z.T. auch schon etwas abgedroschen. Doch für SharePoint ist Governance ein Match entscheidendes Element. In diesem Post werde ich kurz eine Einführung in Governance geben und warum es so wichtig ist für SharePoint.

Governance:
(von frz. “gouverner” verwalten, leiten, erziehen aus lat. “gubernare”; gleichbed. griech. “kybernan”: das Steuerruder führen; vgl. Kybernetik)bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet. Der Begriff governance wird häufig unscharf verwendet.
(Quelle: Wikipedia)

Governance für SharePoint wird im Begriffssinn dazu verwendet, um die Steuerung und Leitung von Aktivitäten in SharePoint zu beschreiben.

Warum ist Governance Match entscheidend?
In der Realität zeigt sich oft, dass SharePoint eigentlich “zu einfach” ist. Zu Beginn ist es zwar nicht selbsterklärend wie SharePoint funktioniert, doch wenn man die Grundbegriffe einmal gelernt hat, ist die Erstellung von neuen Seiten oder neuem Content ein Kinderspiel. Mit wenigen Klicks hat man eine neue SharePoint Seite erstellt (mit 4 um genau zu sein). Meist beginnt der Aufbau sehr strukturiert (sofern die User richtig geschult sind!!). Ein gängiges Modell, ist eine Abbildung des Organigramms in SharePoint Seiten. Doch SharePoint ist so praktisch, wir könnten doch dies und jenes damit verwalten. Ja, und dort haben wir noch eine Arbeitsgruppe und dort noch eine Interessensgemeinschaft etc. bis die gesamte Installation nicht mehr überblickbar ist. (vgl. Bild unten)

Wenn es bei Ihnen einmal nicht so aussehen soll, ist es wichtig, die Grundbegriffe von SharePoint zu verstehen und im Fokus der Unternehmung ein an die Aufbau- und Ablauforganisation angelehntes SharePoint Governance Modell zu erarbeiten, zu schulen, einzuführen und zu leben. Ansonsten ist es vorprogrammiert, dass Ihre SharePoint Struktur schon bald nicht mehr managebar ist. Dies wiederum führt dazu, dass Content schlecht gefunden und so die Usability von SharePoint stark reduziert wird. Die Akzeptanz der SharePoint Installation ist dadurch bereits gefährdet.

FAZIT:
Wenn Sie nicht zumindest eine minimale SharePoint Governance einführen, laufen Sie gefahr, dass Ihre SharePoint Einführung floppen wird. Wenn Sie sich einen Projekterfolg bei der Einführung von SharePoint sichern wollen, denken Sie an zwei Dinge: Governance und Schulung. Dies wird Ihnen helfen, früh Problemen aus dem Weg zu gehen, die den Projekterfolg beeinträchtigen können. Wie man eine SharePoint Governance aufbaut, welche Aspekte bei dabei wichtig sind und worauf man bei der Schulung achten sollte, dazu später in diesem Blog.