Es tut mir leid, mit deiner Argumentation habe ich mehrere Schwierigkeiten, insbesondere an den Nahtstellen von “Bedienbarkeit und Einfachheit” und dem Verhältnis zu Unternehmensanforderungen und -nutzen. Das sehe ich etwas anders, ich plädiere ja auch nicht aus “Berateregoismus” für eine ergebnisoffene Anforderungsanalyse und Auswahl aus dem “Werkzeugkasten Enterprise Social Software”, sondern gerade weil so nachhaltig erfolgreiche Lösungen entstehen können.

Dass der Startpunkt noch für längere Zeit und in den allermeisten Fällen “Pilotprojekt” heißen wird ist klar und vernünftig – ich empfehle meinen potenziellen und tatsächlichen Beratungskunden auch nichts anderes. In einem Pilotprojekt können die Chancen und Risiken sehr schön und in einem kleinen und überschaubaren Rahmen erprobt werden.

Dazu kommt dass in diesen “Experimenten” neue und angrenzende Einsatzpotenziale und -arenen entdeckt und evaluiert werden können. Was wiederum den Berater freut, der dann die Skalierung und Übertragung vorbereiten und begleiten kann …

Übrigens vielen Dank für die Verlinkung meines Beitrages: http://www.jahooda.org/?p=251

@Martin: Klar kann man noch viel mehr machen. Mein Ansatz war es aber, mit einer bewusst einfachen Lösung überhaupt erst einmal Social Software zum Einsatz zu bringen.

Mein “pädagogisches” Ideal wäre es, die Betriebe setzen Social Software zunächst eher experimentell ein und erkunden so deren Potenziale. Läuft alles gut, entdecken die Menschen im Betrieb im Lauf der Zeit von allein, was noch so alles möglich wäre und entwickeln die Systeme weiter bzw. bauen neue auf. Die Lösungen kommen so Schritt für Schritt immer mehr von innen und nicht nur vom einem externen Berater.

Der einzelne Betrieb soll ja auf Dauer nicht vom Berater abhängig sein, sondern sich die Kompetenz selbst erwerben. Das ist mir insbesondere bei den mittelständischen Betrieben wichtig, die nur wenige Hundert Mitarbeiter haben.

Und ich muss dabei bleiben, der “Social Software Werkzeugkastens für das Projektmanagement” hat mehr zu bieten als Blogs. Das siehst Du sicher auch so denn die Möglichkeiten, die RSS in Verbindung mit Tagging bietet hat Oliver ja bereits sehr schön umrissen, ebenfalls die Möglichkeiten von Social Bookmarking im Projektkontext.

Warum sich also auf die eine Lösung Projektblog versteifen? Warum nicht ein Wiki in Verbindung mit Projektblogs, Tagging-Strukturen, angepassten RSS-Feeds zur Informationsverteilung, “Shared Bookmarks” und mehr?

Vielleicht kann ich dich ja von den Potenzialen von Wikis (mit integriertem Tagging, angepassten Feeds und ja – ein Blog, ein News-Bereich ist auch dabei) ja am praktischen Beispiel überzeugen: Ich habe vor kurzem und mit einem Partner zusammen eine solche Projektinfrastruktur konzipiert und implementiert. Alle deine auf Projektblogs gemünzten Vorteile sind vorhanden, und zudem noch ein paar Sachen, die mit einem Blog allein nicht so leicht zu machen sind:
- ein Portal in dem verschiedene Projekte (mit ihren Unterportalen) integriert werden – zusammen mit eingebundenen RSS-Feeds für Neuigkeiten aus dem Projekt etc.
- RSS-Feeds für einzelne Seiten, Seitengruppen etc etc etc
- Glossar, Yellow Pages – jeder Projekt-MA kann seine Seite selbst anpassen
- persönliche Wiki Seiten in denen Platz für Vorarbeiten und Ideensammlungen zur Verfügung steht
- und vieles mehr …

Die obige Kalkulation scheint mir aber nicht ganz schlüssig zu sein. Wenn immer wieder die gleichen Maschinen verkauft werden, lassen sich die Prozessschritte mit Sicherheit standardisieren. Und dann bleibt für das Blog nicht mehr so viel übrig.

Klar steht das von mir so vorgeschlagene Vetriebsblog isoliert im Raum. Es ist gedacht für ein Unternehmen, das erste Erfahrungen mit Social Software sammeln will, dabei aber schon von Beginn an auf einen hohen (finanziell messbaren) Nutzen abzielt.

Würde das Instrument greifen, könnte man die Infrastruktur dann erweitern. Das Thema “Blog versus Wiki” können wir gerne beim nächsten WikiWednesday thematisieren. Gerne trete ich dabei für die Blogs ein, während Du für Wikis sprechen kannst.

Ich bin davon überzeugt, dass im Vertrieb einzelne Projektblogs sehr sinnvoll sein können:
1. Ein Vertriebsprojekt ist zeitlich begrenzt, es hat einen klaren Beginn (Auftragserteilung durch den Kunden) und ein klares Ende (Auslieferung und Inbetriebnahme der Maschine).
2. Das Projekt ist wesentlich von der Zeit geprägt (Zeitschiene), damit ist für einen fortlaufenden Dialog zur Sache ein Blog besser als ein Wiki geeignet (es sei denn, man nimmt eine Mischform wie Oliver Gassner vorschlägt).
3. Man hat hinterher eine vollständige und in sich geschlossene Dokumentation des Projektes, in der jederzeit recherchiert werden kann.