20100910e Opitz Consulting Neue Wissenskultur Kollektive Intelligenz
|
|
|
»manage
it«
als
|
Neue Wissenskultur Kollektive Intelligenz im Unternehmen nutzen Wie Wikis im Rahmen von Business-Intelligence-Projekten nutzbringend eingesetzt werden können.
Denn es sind viele, und jeder hat einen Teil an Tugend und Einsicht« [Aristoteles, Politik-III]. Auch wenn Aristoteles mit seiner These kaum die interaktiven Prozesse zur Sammlung und Erstellung von Wissen über das Internet vor Augen gehabt haben dürfte, so trifft dieses Zitat doch den Kern der heutigen Diskussionen. In den letzten Jahren ist »Web 2.0« zu einem Oberbegriff für all das geworden, was auf irgendeine Weise mit menschlicher Interaktion über das Internet zu tun hat. Neben den populären Angeboten, die primär auf kommunikative Aspekte abzielen – wie etwa soziale Netzwerke oder Messaging Dienste – hat sich eine neue Wissenskultur etabliert, die erst moderne Kommunikationsmittel in dieser Form ermöglicht haben. Die freie Internet-Enzyklopädie Wikipedia, die im Zuge des Web-2.0-Hypes groß geworden ist, gilt als Paradebeispiel für die Chancen und Risiken einer kollektiven Informationssammlung. Wikipedia folgt unserem aristotelischen Leitgedanken sehr stringent, denn jeder Nutzer darf Inhalte zu diesem Wiki beitragen, sei es in Form neuer Artikel, durch die Änderung vorhandener Artikel oder über die Kommentierung bestehender Inhalte.
Anfang 2009 wurde der Fall des jetzigen Verteidigungsministers
Karl-Theodor zu Guttenberg bekannt, dem durch einen bewusst falsch
gesetzten. Eintrag ein zusätzlicher Vorname zuteil wurde. Der
zusätzliche Vorname „Wilhelm“ wurde am folgenden Tag in vielen
Zeitungen veröffentlicht, welche sich bei der Recherche vermutlich
zu blind auf Wikipedia verlassen hatten.
Quelle:
http://www.bildblog.de/5704/wie-ich-freiherr-von-guttenberg-zu-wilhelm-machte/ Auf diese Weise entsteht demokratisches Wissen. Da dieses Wissen der fortlaufenden Modifikation durch mehrere Millionen Internetnutzer unterliegt, stellt es sogar eine relativ verlässliche Quelle für weit verbreitetes Wissen oder weit verbreitete Auffassungen dar. Soweit die Theorie. In der Praxis erfolgt eine Überprüfung der Eintragungen durch ein großes Netz an ehrenamtlichen Helfern. Diese verhindern, dass Vandalismus stattfindet, anstößige oder sogar rechtswidrige Inhalte erscheinen. Trotz dieser umfangreichen Bemühungen wird die Online-Enzyklopädie offiziell als unzuverlässige Wissensquelle angesehen, was allerdings auch Autoren namhafter Printmedien nicht davon abhält, Wiki- oder Blog-Inhalte ungeprüft zu übernehmen (siehe Kasten). Das kollektiv erstellte Wissen, wie etwa in Wikipedia oder in Blogs, sollte jedoch nicht so unreflektiert wie in diesem Beispiel übernommen werden. Im Gegenteil erfordert dieses besonders kritische Konsumenten, vielleicht noch kritischere als die »Mainstream-Medien«. Die Wissensflut in Unternehmen bändigen Warum sollten sich Unternehmen auf derart unzuverlässigen Informationen verlassen und zudem den organisatorischen Aufwand für die Moderation und die Kontrolle der Inhalte auf sich nehmen? Ein Hauptmotiv für ein solches Wagnis, kann in der rasant wachsenden Informationsflut gesehen werden, die auch vor den Unternehmen nicht Halt macht. Um das umfangreiche und schnell wachsende Unternehmenswissen effektiv zu nutzen, sollte es zunächst den betreffenden Mitarbeitern zugänglich gemacht werden und dann so effizient wie möglich aktuell gehalten werden. Um die Herausforderungen für die Umsetzung eines Unternehmens-Wikis greifbarer zu machen, möchte ich diese nachfolgend anhand typischer Fragestellungen in Business-Intelligence-Projekten (kurz: BI-Projekten) herausarbeiten. Was spricht für ein Wiki in Business-Intelligence-Projekten? Zu den besonderen Herausforderungen in BI-Projekten zählen in der Regel:
BI-Projekte zeichnen sich in vielen Fällen durch organisationsübergreifende Teams aus. Dies macht sie zu einem idealen Anwendungsszenario für Wikis. Die Mitarbeiter der verschiedenen Abteilungen können so ort- und zeitunabhängig an bestimmten Fragestellungen arbeiten, etwa an einer Kennzahlendefinition. Aus zahlreichen BI-Projekten lässt sich die Erfahrung ableiten, dass der Analyseprozess den herausforderndsten, richtungsweisendsten und somit für das Endprodukt wichtigsten Teil für den Aufbau einer BI-Umgebung darstellt. Für alle weiteren Schritte – die Entwicklung der Datenflüsse, den Aufbau der IT-Infrastruktur, die Präsentation der Daten – gibt es eine Unmenge an Anbietern, Lösungswegen oder Projekten mit ähnlichen Anforderungen, an denen man sich orientieren kann. Aber gerade die Projektphase, in der herausgefunden werden soll, wie das Unternehmen tickt und wie die Prozesse in der Praxis ablaufen, damit das Unternehmen erfolgreich ist, birgt enorme Herausforderungen und ist jedes Mal einzigartig. Welche Kennzahlen sind zu überwachen und zu steuern? In welchen Hierarchien und Ebenen liegen die Daten vor? Diese Fragen können und müssen ausschließlich im Dialog geklärt werden. In der Analysephase muss sich der Analyst in den Spagat zwischen der informationstechnischen Abbildung und der fachlichen Wirklichkeit begeben: Welche Quellsysteme mit relevanten Informationen gibt es? Wie sind diese untereinander vernetzt? Welche Fachabteilungen verwenden Daten für welche Zwecke aus diesen Systemen, und was sind die eigentlichen Ziele ihres Outputs? Abbildung 1 zeigt die Realität in einer Vielzahl von Unternehmen. Häufig liegen gleiche oder ähnlich bezeichnete beziehungsweise unklar und weich formulierte Kennzahlen vor und werden unterschiedlich, nach buchhalterischer, vertrieblicher oder sonstiger Sichtweise, ermittelt und weitergegeben.
Abbildung 1: So wird i.d.R. den Entscheidern reportet. Die vorangestellten Fragen werden klassischerweise mittels Interviews oder in Workshops beantwortet. Diese Tätigkeiten sind zeitaufwendig und daher teuer. Zusätzlich werden umfangreiche Dokumente erzeugt, die in der Praxis nach ihrer Erstellung nur noch selten gelesen werden. Erst nach der Beantwortung der vorangegangenen Fragen, kann gemeinsam – unter Berücksichtigung der jeweiligen Unternehmensstrategie und IT-Infrastruktur – ermittelt werden, wie eine sinnvolle Zielarchitektur, ein Modell der Daten, die Datenflüsse und eine Präsentation der möglichen Informationen aussehen kann. Der »klassische« Ansatz sieht vor, mit der Analyse erst kurz vor dem Start eines BI-Projektes in großen Arbeitsgruppen zu beginnen und einen Kennzahlenkatalog sowie eine fachliche Systemsicht aufzubauen. Häufig enden diese Diskussionen an Abteilungsgrenzen und bringen politisch geprägte Auseinandersetzungen zwischen den beteiligten Bereichen mit sich. Erfahrungsgemäß zieht das die Analysephase in die Länge und verringert so die Akzeptanz einer möglichen BI-Lösung. Wer in seinem Unternehmen noch nicht so weit ist, aber weiß, dass er »irgendwann« ein BI-Projekt starten wird, sollte aus diesem Grund lieber heute als morgen mit der »Analysephase« beginnen! Problemstellung Jedes Unternehmen zeichnet sich durch unterschiedliche, teilweise undokumentierte Prozesse aus. In einer typischen Organisation gibt es zwischen den Organisationseinheiten eine Fülle von Prozessschnittstellen. Im Rahmen des Reportings werden von den Fachabteilungen Daten aus verschiedenen Quellsystemen extrahiert. Dies kann durch IT-gesteuerte CSV-Exporte oder durch das Partizipieren an bestimmten Informations-E-Mails und -listen aus anderen Abteilungen erfolgen. Häufig gelangt der Mitarbeiter auch durch sein persönliches Netzwerk an die entsprechenden Informationen, etwa wird Herr Müller, Datenbankadministrator aus der IT, oder Frau Meier aus der Buchhaltung, die mit dem Neukundengeschäft betraut ist, angesprochen, ob er oder sie weiß, wo die betreffenden Daten zu finden sind, oder wo welche Berechnungsgrundlage vorliegt. Dies führt langfristig zu sogenannten »Datenschattenhaushalten« und Unmengen von Abhängigkeiten. Komplexe Prozesse sind in der Folge nur noch schwer zu durchschauen und zu verändern. Doch genau aus diesem Gefüge werden wichtige Entscheidungen getroffen! Aber welche »wirklichen« Prozesspunkte verstecken sich hinter den reporteten Kennzahlen? Können diese Kennzahlen tatsächlich nach den aufgezeigten Informationsebenen detailliert werden oder gibt es nicht eingerechnete Ausnahmen? Sind alle Abhängigkeiten zwischen den Datenerhebungen beachtet worden? Und zu allerletzt: Verstehen wir unter den Kennzahlen das Richtige beziehungsweise interpretieren wir diese sachgemäß? Der sinnvollste Weg, um die genannten Probleme und »Stille Post«-Effekte zu vermeiden, ist die Herstellung von Transparenz und einer gemeinsame Informationsbasis. Mitarbeiterbeteiligung Eine Kommunikationsplattform wie Wikipedia entsteht nicht unter Druck, sondern auf freiwilliger Basis. Ganz so einfach wird man es sich in einem Unternehmen nicht machen können. Sinnvolle Rahmenbedingungen lassen sich grob wie folgt formulieren: Im ersten Schritt sollten die betreffenden Mitarbeiter aus den Fachabteilungen ermittelt werden. Wer ist bisher für den Reportingoutput der einzelnen Abteilungen (Controlling, Finanzen, Buchhaltung, Produktentwicklung etc.) verantwortlich? Darüber hinaus ist es wünschenswert mehrere Mitarbeiter aus der IT zur Klärung technischer Abhängigkeiten sowie für den Aufbau eines nötigen fachlichen Verständnisses zu beteiligen. Welcher der IT-Mitarbeiter tauscht sich mit den Fachabteilungen aus und hat die Fähigkeit die eigene »IT-Brille« abzusetzen und sich auch eine fachliche Sichtweise zu erarbeiten? Um ein kooperatives und motiviertes Umfeld zu schaffen, gehört es dazu, den Mitarbeitern Vertrauen zu schenken und Verantwortung zu übertragen. Dies kann durch Freiräume positiv unterstützt werden. Wichtig ist, dass die neuen Aufgaben nicht zusätzlich zum Tagesgeschäft – quasi als Strafarbeit – erteilt werden. Außerdem hilft eine ergebnisoffene Diskussionskultur und das Aufzeigen neuer Entwicklungsmöglichkeiten. Dokumentationsansatz Im ersten Schritt gilt es, die Anforderungen des Unternehmensreportings auf die berichtenden Fachabteilungen zu verteilen. Welche Abteilung hat welchen Berichtsoutput? Jede Fachabteilung kann dies mit einfachen Mitteln tun und erzeugt dadurch Transparenz. Die Dokumentation aller Berichtslayouts oder Beispielberichte, kann kurz und prägnant erfolgen: Was wird gezeigt und warum? Wer sind die Empfänger? Wie oft wird der Bericht erstellt? In diesem ersten Schritt geht es nicht darum, die komplette Tiefe des Berichtes zu erklären, sondern den Bericht für alle anderen verständlich aufzubereiten. Andere Fachabteilungen können beurteilen, ob dieses Ziel erreicht wurde und ob alle Begriffe in sich konsistent sind. So werden beispielweise häufig die gleichen Begriffe synonym verwandt, was an dieser Stelle, vereinheitlicht werden sollte. Im zweiten Schritt soll erreicht werden, dass Kennzahlen und Informationsebenen sowie die darin enthaltenen Hierarchien transparenter werden. Jede Kennzahl wird einmal benannt und ihr Inhalt erklärt: Was versteht man zum Beispiel unter »Anzahl Kunden«? Verbergen sich dahinter Käufer und Lieferanten oder werden diese getrennt betrachtet? Lehnt sich die Regionsebene an Länderstrukturen an oder werden eigene synthetische Regionshierarchien für den Vertrieb benötigt? Die abgestimmten Begrifflichkeiten können nun mit den im ersten Schritt beschriebenen Berichten durch Hyperlinks verbunden werden. Außerdem sollten aufeinander aufbauende Begriffe miteinander verlinkt und so redundante Erklärungen vermieden werden. In einem weiteren, dritten Schritt versucht man gemeinsam, eine Übersicht zu erstellen, die die gesammelten Informationen an zentraler Stelle zusammenfasst, etwa mithilfe einer Kennzahlmatrix. In der ersten Spalte werden alle Kennzahlen aufgelistet, in der ersten Zeile alle Informationsebenen.
Abbildung : Kennzahlmatrix
Die drei beschriebenen Schritte haben nicht den Anspruch, schon im ersten Anlauf vollständig zu sein. Es empfiehlt sich von vornherein, mehrere Iterationen zu planen, die Mitarbeiter zu motivieren, Änderungen und neue Erkenntnisse so schnell wie möglich einzupflegen und zu kommunizieren. Spätestens mit der Erstellung der Kennzahlmatrix wird einen wichtiger Schritt für das eigentliche BI-Projekt vollzogen: Ein erfahrener BI-Modellierer kann mit diesen Informationen die meisten Fragen für sein dimensionales Modell beantworten und es erstellen. Doch selbst wenn das BI-Projekt nun immer noch nicht beginnen soll: Ihre bisherige Reporting-Vorgehensweise und -Infrastruktur ist nun transparent dokumentiert und die ersten Verbesserungsmöglichkeiten sind erkennbar geworden. Wie Wikis wirken Wie kann ich als verantwortlicher Mitarbeiter ein Wiki so einsetzen, dass es mir bei der Verwirklichung der aufgezeigten Projektherausforderungen hilft? Moderne Enterprise-Wikis verfügen über eine Reihe von Funktionalitäten, die ein effizientes Projektmanagement ermöglichen. Angefangen bei einem differenzierten Rechtemanagement, über eine Benachrichtigungsfunktion, wenn Inhalte erstellt oder geändert werden, bis hin zur Definition von Freigabeprozessen für sensible Inhalte. Auch wenn wir es beim Unternehmens-Wiki mit geringeren Nutzerzahlen zu tun haben, so bleiben doch einige Probleme öffentlicher Wikis bestehen: die Anzahl der Autoren ist erheblich geringer als die der passiven Nutzer. Es stellt also eine Herausforderung dar, die Nutzer zum aktiven Erstellen und Ändern von Inhalten zu motivieren. Für ein Unternehmens-Wiki bedeutet das, dass die Wichtigkeit der Wiki-Nutzung und die Content-Generierung im Unternehmen kommuniziert werden muss. Eine weitere Möglichkeit, die Nutzung des Wiki zu fördern, ist die Einbindung in die Unternehmensabläufe beispielsweise als zentrales Projekt-Kommunikationsmittel. Wie üblich, wenn Mitarbeiter verschiedener Fachrichtungen aufeinander treffen, sind Kommunikations-Barrieren zu überbrücken. Hierfür sind häufig weiterführende Erklärungen der Inhalte notwendig. Die Kennzahl »Anzahl Kunden« hat etwa mathematische, betriebswirtschaftliche, softwaretechnische Beschreibungs-Dimensionen. Diese lassen sich durch die Verweise in der Wiki-Syntax einfacher kommunizieren, als dies durch klassische Textverarbeitungsmethoden möglich wäre. Im folgenden Abschnitt beschreibe ich einige hilfreiche Funktionen, die sich typischerweise in Enterprise-Wikis finden. Die verwendeten Bezeichnungen beziehen sich auf das Wiki »Confluence« von Atlassian. Brainstorming Ein Wiki eignet sich besonders dazu, Ideen zu erfassen und mit einer Gruppe von räumlich verteilten Mitarbeitern weiterzuentwickeln. Werden jetzt erste Konzeptideen erstellt, haben die Mitarbeiter die Möglichkeit, Ergänzungen vorzunehmen, Fehler zu berichtigen und Inhalte zu kommentieren. Da für jede Seite eine Historie besteht, können die Änderungen jederzeit nachvollzogen, Benutzern zugeordnet und im Bedarfsfall auch wieder rückgängig gemacht werden. Bereiche In den meisten Enterprise Wikis lassen sich unabhängige Bereiche erstellen, die sich wie ein separates Wiki verhalten. Diese auch als Wiki-Farming bezeichnete Funktion erlaubt es, die Inhalte stärker voneinander abzugrenzen und etwa nur einem Projektteam zugänglich zu machen. Templates Für wiederkehrende Dokumentationen, etwa für die Beschreibungen von Kennzahlen, die bestimmte Angaben umfassen müssen, können Vorlagen erzeugt werden. Solche Templates können von einzelnen Wiki-Seiten bis hin zu ganzen Wiki-Bereichen etwa für komplette BI-Konzepte erstellt werden. Projektmanagement-Werkzeuge Aus Projektmanagement-Sicht scheint es sinnvoll, über neu hinzugefügte oder geänderte Inhalte informiert zu werden. Dies ist durch die sogenannte »Überwachen«-Funktion möglich. Häufig lassen sich auch einfache Aufgabenlisten erzeugen, die der Zuteilung von Aufgaben dienen. Hierfür sind allerdings teilweise Erweiterungen in Form von Plugins notwendig. Konzeption und Dokumentation Die grobe Ideensammlung eines Brainstormings kann dann in die eigentliche Konzeptionsphase, in der die Anforderungen detailliert erfasst werden, miteinfließen und verlinkt werden. Einige Enterprise-Wikis, so auch das betrachtete Confluence-Wiki, bieten die Möglichkeit, Word-Dokumente zu importieren und aus ihnen automatisch eine Wiki- Struktur mit Haupt- und Unterseiten zu erzeugen. Confluence erkennt beim Import die Überschrift-Formatierung von Microsoft Word und nutzt diese für die automatische Erstellung von Unterseiten. Aus erstellten Inhalten lassen sich andersherum auch wieder Word- oder PDF-Dateien erstellen, Dies kann etwa von Vorteil sein, wenn an einen Beteiligten, der keinen Zugriff auf das Wiki hat, eine klassische Dokumentation übergeben werden soll.
Resümee. Keine Wunderwaffe, aber praktisches Werkzeug! Abschließen bleibt zu sagen, dass Wikis keine Wunderwaffen für die unternehmensinterne Kommunikation sind, sondern die Projektbeteiligten sogar teilweise vor neue Schwierigkeiten stellen. Die Funktionen eines Wikis müssen bekannt sein und richtig eingesetzt werden, damit es einem Unternehmen wirklich nutzen kann. Um die vollen Potenziale einer Wiki-Lösung zu entfalten, sollte neben dem technischen Know-how auch eine entsprechende Wissens- und Informationskultur etabliert werden. In diesem Zusammenhang ist es wichtig, die Informationen unternehmensintern kritisch zu hinterfragen und gleichzeitig wertzuschätzen. Eine große Chance und einen Gewinn für das ganze Unternehmen über die IT-Plattformen hinaus bringt die Förderung einer neuen Informationskultur mit sich. Hierzu gehört, dass bestehende Hierarchien für die neue Informationskultur durchbrochen werden: Auch die Beiträge eines Vorgesetzten sind zu diskutieren und nötigenfalls zu korrigieren. Rico Großmann und Sacha Baulan ____________________________________ Rico Großmann und Sacha Baulan, OPITZ CONSULTING Berlin GmbH
|
