Collaboration beginnt im Kopf – nicht bei der Technik


Schon vor einiger Zeit habe ich mal in einer schlaflosen Nacht eine Präsentation über die Voraussetzungen von Kollaboration erstellt. Es geht dabei darum, dass Kollaboration nicht mit Technik beginnt, sondern in den Köpfen der Menschen. In der Art und Weise wie wir miteinander umgehen.

Wie sollen die Mitarbeiter zusammenarbeiten, einander helfen, sich gegenseitig unterstützen, wenn wir doch in einem System der Selbstbezogenheit, der Gewinnmaximierung und ROI Wahnsinn leben? Wenn es fast nur noch darum geht, was für mich drin ist? Wir es gewohnt sind, dass man uns alles zuträgt? Sit back and kick the TV on…

In dieser Präsentation habe ich mir über diese Themen Gedanken gemacht. Was müssen wir in unserer Zusammenarbeitskultur tun, damit wir auch mit den uns zur Verfügung stehenden Systemen zusammenarbeiten? Natürlich gebe ich die Präsentation auch mal gerne in euren Teammeetings oder auf Tagungen.

So 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

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

Aufbau eines Schulungsszenarios: Überblick


Wie bereits in einem früheren Post erwähnt, ist Schulung eine sehr wichtige und Zentrale Sache. Schulung ist einer der wichtigsten, und doch am meisten vernachlässigten Erfolgsfaktoren bei SharePoint Projekten. In diesem Post will ich darauf eingehen, warum ein gutes Schulungskonzept mission critical ist und warum es Sinn macht, ein paar Gedanken daran zu verschwenden.

Was sind die Ziele einer SharePoint Einführung:

Die Grundsätzlichen Vorteile einer SharePoint Einführung werde ich hier nicht wiederholen, sie wurden bereits in 100 Büchern mehrfach lang und breit ausgeführt. Viel mehr möcht eich auf die grundsätzlichen Benefits eingehen, welche erreicht werden können, wenn SharePoint eingesetzt wird. Zumindest die, welche man sich als IT Abteilung erhofft.

  1. Die User sollen für die Zusammenarbeit ein Tool einsetzen können, welches den heutigen Ansprüchen eines modernen Information Management genügt
  2. Informationen sollen per Web zugänglich sein, ohne zusätzliche Client Software installieren zu müssen
  3. Dokumente sollen automatisch versioniert werden, ohne dies per Versionsnummer im Dateinamen machen zu müssen
  4. Mittels Check-Out / Check-In sollen Dokumente zur Bearbeitung reserviert werden können
  5. Es sollen Links per e-Mail versendet werden, anstelle die Dokumente immer als Anhang intern zu versenden
  6. In geschützten Arbeitsbereichen sollen bestimmte Gruppen von Mitarbeitern ihre Daten austauschen können
  7. Über eine starke und performante Suche soll der Endanwender „Google like“ suchen können
  8. Die Verteilung von Information soll zentralisiert und vereinfacht werden
  9. Jeder soll möglichst zeitnah über die für ihn wichtigen Informationen verfügen
  10. Es sollen möglichst viele Informationen zentral an einem Ort verfügbar sein, ohne mehrere Systeme starten zu müssen

Dies sind jetzt einmal 10 Punkte, die ich hier aufführe, welche sicher in irgend einer Art und Weise im Wunschdenken von Projektleitern oder IT Abteilungen vorkommen. Es gibt natürlich viele andere Punkte welche wichtig und wünschenswert sind, doch die oben aufgeführten bilden sicherlich einen repräsentativen Teil möglicher Bedürfnisse.

Die Gretchenfrage

Nun, diese Punkte sind sicher gut und es ist auch löblich, diese umsetzen zu wollen, doch wie in aller Welt soll der Enduser das alles verstehen, wenn er noch nie vorher eine SharePoint Plattform gesehen hat? Sie können ihm noch so viel vorschwärmen, wie viel Nutzen es ihm bringen wird. Wenn Herr und Frau Enduser sich nichts konkretes darunter vorstellen können, dann haben Sie verloren.

Eine Erkenntnis, welche ich in meinen vielen Schulungen erfahren musste ist die Folgende: Trotz Facebook und Youtube, trotz Xing und Google sind Endanwender NICHT in der Lage, SharePoint ohne jegliche Anleitung zu bedienen.

Ich arbeite z.T. mit Studierenden, welche sich bestimmt nächte lang in Facebook und Co. tummeln und doch verstehen sie SharePoint nicht „einfach so“. Auch sie brauchen Anleitung. Ich kann Ihnen garantieren, wenn Sie versuchen, SharePoint ohne Schulung einzuführen, werden Sie auf Ablehnung stossen. SharePoint ist zwar simpel zu verstehen, es ist aber nicht so intuitiv, dass man es ohne Schulung versteht. Es braucht ein Mindestmass an Ausbildung, will man ein SharePoint Projekt erfolgreich zum Abschluss bringen. Oder hat jemand von Ihnen MS Word gleich begriffen, als er es zum ersten Mal gesehen hat? Und doch ist die Bediengung eigentlich so einfach.

Schulung ist das A und O einer SharePoint Einführung

Wer also ein erfolgreiches SharePoint Projekt umsetzen will, muss in der Einführungphase Schulungen planen. Achtung, planen Sie die Schulungen nicht zu früh, da sonst die Anwender das Gelernte nicht schnell genug umsetzen können und es wieder vergessen. Auch zu spät ist nich so gut, denn sonst sind die Anwender bereits entmutigt, wenn sie das erste Mal auf SharePoint arbeiten. Auch der richtige Zeitpunkt ist sehr entscheidend. Planen Sie Schulungen vor der Einführung, während und kurz nach der Einführung. Lassen Sie die User entscheiden, wann sie sich einschreiben, so hängen Sie die Langsamen nicht ab und bremsen die Schnellen nicht aus.

Ein weiterer Punkt ist der Inhalt der Schulungen. Generell wird bei SharePoint Schulungen oft zu weit gegangen. Das Gedankengut ist weit verbreitet, dass wer SharePoint macht, auch gleich eigene Listen und Seiten anlegt, Recht verwaltet etc. Das ist eine komplett falsche Vorstellung. Ja, SharePoint ist eigentlich einfach, aber nicht DAU (Dümmster Anzunehmender User) sicher. Weiter sind z.T. Endanwender nicht in der Lage, sich den minimalen Teil an IT-Denken anzueignen, den es benötigt, um SharePoint verwalten zu können. Es ist auch nicht zielführend, zu meinen, jeder mache Alles sein ein sinnvolles Konzept. Folgende drei Ebenen machen in der Ausbreitung und Verwaltung von SharePoint sinn:

  • Endanwender
  • Super User
  • SharePoint Administrator

Für jede dieser Rollen braucht es eine massgeschneiderte Schulung, wobei man sagen kann, dass für die Masse von Mitarbeitern die Stufe Endanwender reicht. Verteilen Sie in jede Abteilung einen Super User und setzen Sie zwei oder mehr SharePoint Admins ein (je nach Grösse der Firma). Für wen welche Schulungsinhalte sinnvoll sind, darüber schreibe ich in einer Fortsetzung meines Blogs. Auch werde ich Ihnen Unterlagen zur Verfügung stellen und Ihnen Literatur empfehlen.

Das beste Projekt macht wenig Sinn, wenn die Anwender den Nutzen nicht sehen, oder das Tool nicht anwenden können.
So long, Samuel Zürcher

SharePoint Governance: Teil I Überblick


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.

Über Quick Wins und Schulungen bei der Einführung von SharePoint


Wenn Sie in Ihrem Unternehmen SharePoint einführen wollen ist es wichtig, mehrere Dinge zu beachten:

  1. SharePoint ist nicht direkt selbsterklärend, wie jede andere Applikation wie Word oder ähnliches braucht es Know How und Zeit um sich als User darin zurecht zu finden
  2. Man kann nicht davon ausgehen, nur weil XING, Youtube, Facebook und Co. so populär sind, dass sich alle mit einer Webplattform auskennen
  3. Auch wenn die Installation straight forward ist, steckt viel unter der Haube von SharePoint. Wenn IT Professionals sich mit dem Produkt nicht auskennen, ist die Gefahr gross, den Ansatz des Konzeptes falsch zu machen. Einmal einen falschen Weg eingeschlagen, kann die Korrektur viel Geld und Zeit kosten
  4. Ohne vorgängiges Konzept und klares Ziel kann SharePoint nicht erfolgreich sein
  5. Wenn SharePoint den Usern einfach zur Verfügung gestellt wird, sind diese meist überfrodert. Es ist besser dem Enduser mit kleinen Schritten die Vorteile näher zu bringen. Beginnen Sie mit einem Testteam von early adopters und breiten Sie das Deployment danach aus
  6. Versuchen Sie Quick Wins zu erreichen. Die Verwaltung von Sitzungen mit dem Sitzungstemplate ist eine gute Möglichkeit, das Management von den Vorteilen zu überzeugen
  7. Etwas dürfen Sie niemals vergessen, SCHULUNG diese wird oft vernachlässigt, was verheerende Folgen hat. Die User sind verunsichert, begreifen das Konzept nicht und dies wiederum führt zu Ablehnung
  8. Holen Sie sich professionelle Hilfe, wenn Sie keine SharePoint Crack zur Hand haben, bauen Sie intern Know How auf und wagen Sie sich erst dann an SharePoint heran. SharePoint mag zwar aussehen wie ein Käfer, hat aber einen hochkomplexen und z.T. auch heiklen Ferrari Motor unter der Haube
  9. Ohne Support vom Management ist eine Einführung von SharePoint sehr schwierig, wenn nicht unmöglich. SharePoint ist eine Plattform, welche für den Globalen Einsatz gedacht ist, muss also auch global unterstützt, gefördert und akzeptiert werden. Holen Sie sich den Nicker vom Management, bevor Sie mit dem Projekt beginnen
  10. Es gibt viele Wege nach Rom, auch in SharePoint. Doch meist gibt es eben auch Autobahnen und Feldwege. Nicht jeder Weg ist in jedem Fall geeignet, nicht jeder Weg ist gleich schnell und nicht jeder Weg bringt sicher ans Ziel. Um SharePoint zu beherrschen, muss man SharePoint kennen

Wenn sie diese Punkte beachten, dann ist Ihr Projekt sicher auf dem Weg.