Vor allem fand ich interessant, dass das Microblogging mit einer “Facebook-like”-Social-Networking-Plattform verknüpft wurde.

Doch ich frage mich, ob es wirklich um Microblogging im Sinne von “Ich sag auch wie ich mich gerade fühle” geht oder mehr um das Mitteilen von Neuigkeiten / Aufmerksammachen auf Neuigkeiten – also eher Awareness-Feeds in Blog-Form. Letzteres ist meiner Meinung nach sehr sinnvoll in Unternehmen – Mitteilungen über neue Projekte, Schulungen, die man besucht hat, Kundenkontakte, die man gehabt hat/haben wird.

Der Begriff “Microblogging ala Twitter” für den Unternehmenseinsatz ist meiner Meinung nach negativ belegt. Ausserdem erfinden wir damit einen neuen Begriff für die Awareness-Feeds, die es auf Social-Networking-Plattformen eh schon gibt.

Wir werden übrigens bis Jahresende eine “solche Plattform” (SNS mit Awareness-Feeds) für unsere Universität bereitstellen. Sowohl für die Kommunikation nach innen (zu Kollegen) als auch nach aussen (was für tolle Forschung wir machen ;-)). Da ist glaube ich großes Potential.

“Anticipative Awareness in a Groupware System”, Wolfgang Prinz, Elke Hinrichs, Irina Kireyev

Wolfgang Prinz vom Fraunhofer Institut Angewandte Informationstechnik beginnt mit einem Bericht über verschiedene Awareness Features (am Beispiel von BSCW) – mit diesen Features kann man sehen, was konkret passiert ist. Es ist heute aber nicht möglich zu spezifizieren, was passieren sollte – und einen Hinweis zu erhalten, wenn das nicht passiert (z.B. Studenten, die ein Papier nicht gelesen haben; Projektpartner, die ein Dokument nicht hochgeladen haben …): “Awareness about things that did no happen”

Dies wurde in Form von “Expectations” in BSCW eingebaut – Zu Expectations können Participants (Individuen, Gruppen, Rollen), Activities und Artifacts zugeordnet werden.

Interessant: Es ist möglich eigene Expectations für andere Sichtbar zu machen; ein anderes Feature: E-Mail an alle, die eine Expectation erfüllt bzw. nicht erfüllt haben.

“The Wiki as an Integrative Tool in Project Work”, Birgit Rognebakke Krogstie

In diesem Beitrag wurde über die Nutzung von Wikis in Software-Engineering-Projekten berichtet.

Ein paar interessante Erkenntnisse aus der Beobachtung:

• Wikis wurden hauptsächlich für “Integration” genutzt
  • Integration zwischen sozialen und zielorientierten Aktivitäten
  • Integration zwischen Information im Team und ausserhalb des Teams
  • Integration zwischen verschiedenen Artefakten
• Wikis dienten verschiedenen Zielen
  • “knowledge repository”
  • “stage”
  • “coordination mechanism”
  • “shared workspace”
• Wikis wurde nicht für soziale Interaktion genutzt – also eigentlich keine “Social Software” – aber das lag wohl auch daran, dass die Teams nicht verteilt waren – Für soziale Interaktion wurden genutzt IM, F2F, …

“Proliferation in Enterprise Wikis”, Hans-Jörg Happel

Herr Happel vom FZI in Karlsruhe berichtete über Erkenntnisse aus der Untersuchung der Nutzung von Wikis in Unternehmen. Seine Forschungsfrage war: “What problems occur when enterprise wikis grow and how are they adressed?”.

Zuerst verglich er Enterprise Wikis mit Wikipedia:

• Wikipedia: klare Struktur (Lexikon), klare Namens- und Linkkonventionen, grosse Benutzerbasis
• Enterprise Wikis: keine so klare Struktur, teilweise hierarchische (Unter-)Strukturen, Frage: “where to put what?”, kleine Benutzerbasis

Wegen dieser Unterschiede finden sich in Unternehmenswikis auch andere Probleme als in Wikipedia. So scheint das Hauptproblem “profileration” (wegen des Wachstums) zu sein. Also eine schwindende Qualität der Struktur, ein schwieriger werden des Findens von Inhalten oder von Seiten auf denen Inhalte aufgenommen werden sollten.

Lösung dazu scheint “gardening” zu sein – Zusätzlich werden als Lösung auch vorbeugende Massnahmen angegeben:

• “employee training”
• “quality standards, rules”
• “tagging, categorization”
• “use of templates”

Aber darüber wollte ich eigentlich gar nicht schreiben – sondern darüber, dass die ACM eine neue Funktionalität in ihre DL eingebaut hat: Author Profile Pages. Das sind Seiten, auf denen Informationen zu den Autoren und deren komplette Veröffentlichungsliste aufgeführt werden. Natürlich nur die bei der ACM erfassten Veröffentlichungen. Das sind natürlich die Veröffentlichungen auf ACM Tagungen und in ACM Zeitschriften – aber auch alle Veröffentlichungen, die in ersteren zitiert werden.

Hier die URL zu einer meiner Author Profile Pages – “einer meiner” bedeutet, dass das System noch nicht perfekt ist – so wurden meine Veröffentlichungen gleich auf mehrere Identitäten (alle mit dem Namen Michael Koch) aufgeteilt. Aber das wird sicher noch – ist ja nur ein erster Prototyp.

Noch interessanter als die Liste der Veröffentlichungen sind die “Bibliometrics” zu den ACM-Veröffentlichungen. Da heisst es dann z.B.

Bibliometrics: Downloads (6 Weeks): 5, Downloads (12 Months): 37, Citation Count: 3

Das Papier ist also in den letzten sechs Wochen fünf mal runtergeladen worden (nicht schlecht für ein Papier von 1999) und wird von drei anderen Papieren in der Datenbank zitiert.

Ich bin gespannt wie ACM das ganze weiterentwickelt. Mit dieser Basis hätten sie auf jeden Fall eine gute Möglichkeit ein Forschungs-Social-Network aufzubauen. Hoffentlich verstärkt sich dadurch aber nicht der am Anfang des Beitrags erwähnte Druck nur noch auf/in ACM-Publikationen zu veröffentlichen – weil man sonst nicht sichtbar ist.

So – Und was hat das nun mit diskontinuierlicher Innovation zu tun?

Zuerst vielleicht einmal ein paar Worte dazu, was diskontinuierliche Innovation überhaupt ist … Hierunter versteht man größere Innovationssprünge, die über die iterative (kontinuierliche) Weiterentwicklung/Verbesserung von schon vorhandenen Konzepten/Ideen hinausgehen. Problem dabei ist, dass klassische Innovationsprozesse auf kontinuierliche Verbesserung ausgerichtet sind – u.a. dadurch, dass Ideen von den Fachexperten bewertet werden, die mehr auf Verbesserungen der etablierten Prozesse, das was sie kennen/beobachten, schauen als auf etwas ganz Neues/Unerwartetes. Diese Fachexperten sehen also meist den Gorilla nicht – und damit wären wir wieder bei Part 1, dem Video.

Mit meiner Kollegin Kathrin Möslein habe ich mir in einem Beitrag zur Wirtschaftsinformatik 2007 (siehe unten) Gedanken gemacht, was man da tun kann – wie man die Chance, dass eine Idee “ungeplanterweise” bei dem landet, der was damit anfangen kann, erhöhen kann – und natürlich wie man erreichen kann, dass Ideengeber überhaupt Ideen einreichen.

Unser Lösungsvorschlag besteht aus der Nutzung von grossen Wandbildschirmen an halböffentlichen Plätzen im Unternehmen zur “Visualisierung des Ideenpotentials im Unternehmen”. Also die Bereitstellung zusätzlicher “Fenster” in die oft schon existierenden Ideenmanagementsysteme. Dadurch kann einerseits ein Gewahrsein über Ideen (bei nicht fest bestimmten Empfängern) erreicht werden, andererseits unterstützt die Lösung auch die Wertschätzung für die Ideengeber (indem sie sichtbar sind/werden). Weitere Details dazu im Paper:

Michael Koch, Kathrin Möslein: Diskontinuierliche Innovation fördern – Die Rolle von Idea Mirrors zur Unterstützung von Innovation und Kooperation im Unternehmen. Proc. Tagung Wirtschaftsinformatik (1): S. 787-804, Universitätsverlag Karlsruhe, Karlsruhe, 2007.
PDF (789KB)

Die Idee wurde übrigens weitergeführt und inzwischen auch in Prototypen umgesetzt. Demnächst startet auch eine Evaluierung der “Idea Mirrors” in Unternehmen.

Btw: Der Werbeclip von Part 1 greift eine Studie der University of Illinois auf – siehe z.B. http://de.wikipedia.org/wiki/Unaufmerksamkeitsblindheit oder http://viscog.beckman.uiuc.edu/djs_lab/demos.html für weitere Information dazu.

Und was das Ganze mit “diskontinuierlicher Innovation” zu tun hat dann in einem weiteren Post – ich will ja niemanden vom Test ablenken ;-)

Mein erster Eindruck nach dem Lesen: zuerst einmal etwas enttäuscht … Das Buch liefert zwar viele interessante Einblicke in (Software-)Projektarbeit und damit auch gute Anregungen, wo man hinschauen oder eingreifen sollte/könnte – aber es fehlt die zusammenhängende, geschichtenartige “Schreibe”, die ich bisher bei Tom DeMarco gewohnt war – und geliebt habe.

Denn das Buch ist kein zusammenhängender Text, sondern eine Sammlung von 86 Mustern, die bei (Software-)Projektarbeit beobachtet werden können. Jedes Muster ist auf einer bis vier Seiten kurz beschrieben. Dabei ist die Qualität (und Lesbarkeit) der Beschreibungen stark unterschiedlich. Weiterhin sind positive, negative und neutrale Muster wild gemischt.

Hier noch die “Muster”, die mir beim Lesen des Buches als besonders lesenswert bzw. erwähnenswert aufgefallen sind – mit ein paar Kommentaren von mir dazu.

7) Manana: “Wir alle verfügen über Zeitfenster, innerhalb derer wir erkennen, dass wir in Gang kommen und dranbleiben müssen, um eine Tätigkeit abzuschließen. Stichtage jenseits dieser Zeitfenster erzeugen kein Gefühl von Dringlichkeit und folglich auch nur eine geringe Motivation, sofort zu handeln.” (S. 19) – “Ausserhalb dieses Wahrnehmungsfensters befindet sich Manana. Manana bedeutet, dass wir zwar grundsätzlich einsehen, dass wir diese Arbeit erledigen müssen, aber nicht begreifen, dass wir umgehend damit beginnen müssen, um rechtzeitig fertig zu sein.” (S. 20).

Die Lösung ist (wie bei vielen der Muster/Probleme) einfach: Zwischenziele definieren, die innerhalb des Zeitfensters liegen. Trotz dieser einfachen Lösungsmöglichkeit wird aber nicht immer (rechtzeitig) erkannt, dass überhaupt ein Problem existiert.

26) Der Versuchsballon: “Bei einem Versuchsballon handelt es sich (…) um einen Lösungsvorschlag, von dem Sie allerdings wissen, dass er unvollkommen und/oder fehlerhaft ist, und den Sie bewusst einsetzen, um von Kollegen oder Kunden Kritik zu bekommen.” (S. 68).

Schöner habe ich die Idee der iterativen Entwicklung, des häufigen Generierens und Diskutierens von Prototypen noch nicht dargestellt gesehen. Dazu passt auch das auf S. 69 abgedruckte Zitat von Albert Schweitzer sehr gut: “Beispiele sind nicht das Hauptmittel um andere zu überzeugen. Sie sind das einzig mögliche Mittel.”.

75) Die Kühlschranktür: “Teammitglieder hängen ihre Arbeitsergebnisse routinemäßig für alle sichtbar aus.” (S. 185).

Hier wird besprochen, was mit Awareness / einem Gewahrsein über die Arbeit der anderen / den Stand der Arbeiten bzw. des Projektes erreicht werden kann. Das passt auch sehr gut zu den in vielen anderen Mustern angesprochenen Problem mit der zu starken (blinden) Konzentration auf in Vorgehensmodellen vorgeschriebenen Dokumenten zur Fortschrittsdokumentation (z.B. Muster 79 Papierfabrik).

Anstelle einer “Kühlschranktür” kann man natürlich auch Medien wie Blogs benutzen – sollte sich aber immer der Vorteile der Kühlschranktür bewusst sein bzw. versuchen sie nachzubilden!

Gut hierzu passt auch das Muster 81 Lagezentrum. Hier wird ein Projektraum empfohlen, der erstens Informationsaustausch und Informationsbewahrung sicherstellt – und dem Projekt einen sichtbaren Wert gibt.

76) Morgen scheint die Sonne wieder …: “Der Projektmanager ist davon überzeugt, dass der durchschnittliche künftige Fortschritt den durchschnittlichen zurückliegenden Fortschritt übertrifft.” (S. 187).

77) Einer geht noch: “Die Beteiligten sichern Unterstützung für ein Projekt zu, blähen es dann aber immer weiter auf, bis das Projekt unter der Eigenlast zusammenbricht.” (S. 190).

83) Aus gehabtem Schaden nichts gelernt …: “Ein Team erkennt seine Fehler, aber wiederholt sie trotzdem.” (S. 203).

In diesem Muster wird ausführlich auf den Aspekt der Lessons-learned eingegangen und auch einige konkrete Tipps zu deren erfolgreichen Durchführung/Implementierung gegeben (S. 205). Erstmal sollten Nachbesprechungen überhaupt abgehalten werden. Dann sollte vermieden werden, dass die Besprechungen nur zum “Dampfablassen” genutzt werden – z.B. nur Beschreibungen von Problemen gesammelt werden, aber keine Handlungsanweisungen zur zukünftigen Begebung.

Die Argumentation von WorkLight ist, dass es zwar interessant für Unternehmen ist, Blogs und Wikis als neue Mittel der (internen) Unternehmenskommunikation einzuführen, dass aber ein noch größerer Bedarf besteht, die Daten in Unternehmensdatenbanken (insbesondere in CRM- und ERP-Systemen) besser zugänglich zu machen. Und auch hier böten Web 2.0 Technologien einen guten Ansatz.

Soweit ich es verstanden habe bietet WorkLight vor allem zwei Möglichkeiten um existierende Unternehmensanwendungen Web 2.0-tauglich zu machen:

• RSS: Es werden sichere, personenbezogene, einfach konfigurierbare und per-se einfach nutz- und kombinierbare RSS-Feeds aus Unternehmensanwendungen angeboten. So können Vertriebsmitarbeiter RSS-Feeds aus dem CRM-System des Unternehmens abonnieren und über beliebige Mashup-Möglichkeiten anreichern, filtern, nutzen …
• Bookmarks: Benutzer können beliebige Datensätze in den Unternehmensanwendungen “bookmarken”. Also z.B. eine bestimmte Rechnung im ERP System. Solche Bookmarks können einfach per E-Mail verschickt werden oder in Social Bookmarking Systemen gespeichert / geteilt werden. Über die Bookmarks kann dann ohne weiteren Navigationsaufwand auf die eigentlichen “Business-Objekte” zugegriffen werden.

Vermutlich bietet WorkLight noch ein bisschen mehr – Aber ich finde die Umsetzung dieser beiden Konzepte schon sehr spannend. Damit wird die “Datenzentriertheit” und die Möglichkeit der einfach konfigurierbaren und integrierbaren Signaling/Awareness-Möglichkeit über RSS auch für klassische Business-Anwendungen verfügbar. Im Endeffekt braucht eine sinnvolle Einführung von “klassischen” Social Software Anwendungen (Wikis, Blogs, Social Bookmarking Werkzeuge, Social Networking Services, …) diese Integration. Denn nur so kann in diesen Kommunikationsmedien über Business-Objekte kommuniziert / auf solche Objekte verwiesen werden.

• “Koordinator” sendet E-Mail an alle mit ein paar Terminvorschlägen
• “Alle” antworten per E-Mail – entweder nur an den Koordinator – oder schlimmer per “Reply All” an alle – mit mehr oder weniger strukturierten Kommentaren, wann es geht und wann nicht
• Der Koordinator wühlt sich durch die Antworten und stellt hoffentlich eine Überschneidung fest (die er dann allen mitteilt) – ansonsten nochmal von vorne

Ich möchte jetzt nicht die seit zwanzig Jahren im Groupware/CSCW-Bereich propagierten Gruppenkalender als Lösung vorschlagen – denn die funktionieren in wenig strukturierten/anarchischen Bereichen (wie Universitäten) oder bei organisationsübergreifenden Teams noch nicht so richtig. Aber es gibt eine andere gute Lösung für die Vermeidung von E-Mail-Kaskaden:

• z.B. Nutzung eines Wikis, in das die Terminvorschläge eingetragen werden und alle Ihre Verfügbarkeit dazu vermerken

Unter www.doodle.ch gibt es inzwischen sogar einen Web-Dienst, der das ganze narrensicher mit einer schönen UI umsetzt: Einfach Terminvorschläge eintragen und den Link an alle potentiellen Teilnehmer schicken, die dann auf der Website ihr Feedback dazu geben können. Das Aufsummieren der Antworten übernimmt dann wieder der Dienst – schön sichtbar für alle.

Wobei man beim Einsatz des Tools mal wieder beobachten kann, dass ein Tool alleine keine Lösung ist (“a fool with a tool is still a fool …”). So muss man erstens mal abstimmen, ob auch der Initiator seine Verfügbarkeit einträgt – oder ist mit den vorgegeben Terminvorschlägen automatisch verbunden, dass der Initiator an all diesen Zeit hat? Und dann habe ich auch schon beobachtet, dass sich nach dem Einrichten der Abstimmung plötzlich keiner mehr für den Prozess mehr zuständig fühlt – und so am Schluss das Resultat auf ewig (bis zum Verstreichen aller Terminangebote) bei doodle verschüttet bleibt. Die Lösung ist also wie immer nicht nur ein technisches System, sondern ein soziotechnisches – mit Organisation/Absprachen um die Technik rum …

Was jetzt noch fehlt?

Erstens mal eine Klassifizierung von Kontakten – Ich bin eh schon so restriktiv, dass ich nur Leute als Kontakte akzeptiere, mit denen ich zumindest schon mal mehr als ein paar Worte persönlich gesprochen habe. Aber trotzdem gibt es in meinen Kontakten noch unterschiedliche Klassen. Wäre schön, wenn man das abbilden kann.

Und zweitens eine API, mit deren Hilfe ich die Daten auch in eigenen Portalen und Mashups verwenden kann. Xing mit den neuen Awareness-Daten wäre eine sehr interessante Quelle für meine Awareness-Mashups.

UPDATE: Das neue Awareness-Feature wird in der Blogosphäre ja ziemlich gemischt aufgenommen (bin ich mal wieder zu positiv/unkritisch?) – Interessant zu lesen ist der Beitrag von Cem Basman und die Kommentare dazu – u.a. auch ein Kommentar von Lars Hinrichs von Xing.