Was bringt Social Software finanziell im Projektmanagement?

KalkulationsbeispielAuf was Mittelständler doch für Fragen kommen! Anstatt einfach nur dankbar zu sein, dass ihnen jemand (=ich) den Einsatz von Social Software (Blogs und Wikis im internen Einsatz) vermittelt, will man erst einmal wissen, was das „bringt“. Also dann hier mal ein Rechenexempel:

Ein Maschinenbauer macht im Jahr 60 Mio Euro Umsatz mit individuell konfigurierten Maschinen. Deren durchschittlicher Verkaufspreis betrage 2 Mio Euro, so dass davon 30 Stück (jährlich) produziert werden. Bei der Koordination der einzelnen Aufträge wirken regelmäßig folgende Stellen mit: Die Geschäftsleitung, ein Vertriebsingenieur, ein Verantwortlicher aus der Produktion, ein Konstruktionsingenieur, ein Qualitätsmanager und der Controller.

Diese sechs Personen treffen sich in Meetings, telefonieren, schicken sich E-Mails oder „besuchen“ sich gegenseitig am Arbeitsplatz. In der Folge ist der Informationsfluss im einzelnen Vertriebsprojekt ausgesprochen asynchron. Nicht alle Beteiligten sind immer ausreichend informiert. Dieser Kommunikationsstil leidet aber auch darunter, dass nicht alle Mitglieder im Projekt immer gleichermaßen gut zu erreichen sind. Inbesondere das Mitglied der Geschäftsleitung hat viele andere Termine und der Vertriebsingenieur ist oft außer Haus.

Hier könnte ein Projektblog Abhilfe schaffen: Für jeden Auftrag wird ein eigenes Blog als schriftliches Kommunikationsmedium eingerichtet. Alle Vereinbarungen, Protokolle und relevanten Nachrichten werden in Artikeln schriftlich festgehalten.

Aber was bringt das in Zahlen? Ich schätze eine Zeitersparnis von 10% pro Projekt. Das ist sicherlich sehr ambitioniert kalkuliert. Zumal es sich explizit auf das gesamte Projekt bezieht. Aber nur das macht in meinen Augen Sinn: Ein Projektblog ist kein Selbstzweck, sondern dient explizit der Beschleunigung des gesamten Projektes, auch wenn über das Blog zunächst nur die Abstimmungsebene der beteiligten Verantwortlichen tangiert wird.

Die weitere Rechnung ist einfach: Wird die angepeilte Ersparnis auf das Gesamtvolumen von 30 Stück hochgerechnet, lassen sich (stur linear gerechnet) bei 10 % Zeitersparnis 3 Aufträge mehr abwickeln. Es ergibt sich also ein signifikanter Kapazitätseffekt für das Unternehmen. Weiter linear gerechnet kann dadurch auch der Umsatz um 10 % steigen.

Die Marge dürfte sogar um mehr als 10 % zunehmen, da für die zusätzlich produzierten Maschinen im Grunde ja nur die Material- und Energiekosten zu Buche schlagen. Das Unternehmen verbessert also auch noch seine Rentabilität.

Mancher Praktiker mag angesichts dieser Kalkulation ins Grübeln kommen. Aber an den Hochschulen wurde uns Betriebswirten das Kalkulieren so (ähnlich) beigebracht. Noch habe ich selbst zu wenig praktische Erfahrungen mit Blogs im Projektmanagement, um das Modell zu falsifizieren bzw. zu verbessern. Was denken Sie?

18 Kommentare Schreibe einen Kommentar

  1. Ich glaube, dass v.a. Wikis für die Abwicklung komplexer Projekte eine sehr effziente Sache sein können. In unserem kleinen Verlag Kultquartett wollen wir dies bald mal testen. Zur Zeit machen wir schon gute Erfahrungen mit der Online-Software Mindmeister. Man kann hier Mindmaps zu Themen oder Projekten anlegen und diese für beliebig viele Personen zur Ansicht oder Bearbeitung freischaten. Eine Projektstruktur, Ziele oder die Ergebnisse von Meetings kann man damit schon sehr gut abbilden.

  2. Ich habe im Rahmen eines allerdings sehr kleinen Projektes ein Blog verwendet und dabei gelernt, dass das Tool alleine keine Vorteile bringt.

    In meinen Augen muss die Unternehmenskultur passen. Streng hierarchisch geführte Unternehmen werden, so denke ich, von Blogs und Wikis nicht profitieren, denn nur ein offener Umgang der beteiligten Personen bringt ihre Vorteile zum Tragen.

  3. Ich hatte vor zwei Tagen ein Gespräch mit einem typischen, größeren fränkischen Mittelständler. Es ist sicher auch eine Frage der Kultur, aber die meist Eigentümer-getriebenen Unternehmen sind für Verbesserungen und Optimierungen in den Prozessen immer aufgeschlossen. Es geht ja um ihr „Baby“, das sie hegen und pflegen wollen. Sie geben viel Geld aus für Kaizen, Kanban, JIT und SixSigma Einführungen und sind stolz auf jede Innovation, für die sie einen Preis bekommen. Von Wikis und Blogs haben sie meist noch nie wirklich gehört, aber sie wissen, dass das Knowhow ihrer Mitarbeiter ihr eigentliches Kapital ist und Kaizen und Kanban-Knowhow geht verloren, wenn der Mitarbeiter ausscheidet.
    Also erst mal zwei Schritte zurück. Und dann, ganz im Sinne von Kaizen, gehört zu einem erfolgreichen Projektablauf auch eine gute Dokumentation. Das muss zunächst in die Zielvorgaben und in die Köpfe rein. Ob man dann ein Wiki oder Projektblog einführt oder das ganze mit Kärtchen macht, die in der Fabrik hängen :-), ist eine Frage des Geschmacks oder der Beratung.

  4. Pingback: Oliver Gassner

  5. Matthias, darf ich das als Votum für einen Spezialabend „Projektmanagement“ am nächsten WikiWednesday Stuttgart verstehen?

    Ich finde deine Überlegungen interessant und schlüssig, und du stellst auch die Art und Weise in der zur Zeit gearbeitet wird richtig dar. Allerdings – und da kennst Du mich ja auch mittlerweile – bin ich stets kritisch gegenüber einzelnen und unverbunden eingesetzten Werkzeugen.

    Projektblogs sehe ich so auch mehr als ein Element eines „Social Software Werkzeugkastens für das Projektmanagement“ – gerade weil sie an Wert gewinnen wenn sie im Verbund mit anderen Instrumenten eingesetzt werden.

    Bspw. sind Wikis in meinen Augen ein um Größenordnungen wichtigerer Bestandteil dieses Werkzeugkastens – gerade weil sie ihre Stärken im Bereich der gemeinschaftlichen (Projektteam-)Bearbeitung von Inhalten haben. Dazu kommt eine ausgeprägte Anpassungsfähigkeit und leichte Vernetzung dieser Inhalte – wodurch Wikis sich besser für Projektdokumentation und -koordination eignen (@Thorsten, ja).

    Dass Projektwikis um Blogs, gemeinsame Bookmarks, Tagging etc etc ergänzt werden können (und manchmal auch sollten) steht aber außer Frage – und da denke ich liegt auch der Wert von Beratung, nämlich Unternehmen bei der Auswahl der Werkzeuge und deren Anpassung zu helfen.

  6. Zum Trackback von Oliver Gassner: Sein Artikel dazu ist sehr lesenswert, zeigt er doch die hohe Kunst , die mit dem Web 2.0 möglich ist. Mein Artikel war aber eher darauf gemünzt, dass ein Betrieb mal an einer Stelle ansetzt und Erfahrungen sammelt.

    Zu Dr. Martina Göhring: Herzlichen Dank! Ich sehe auch, dass viele Betriebe im Grunde schon pragmatisch handeln wollen, sie aber aufgrund der vielen Management-Moden und -Methoden der letzten Jahre auch vorsichtig und zurückhaltend geworden sind. Wo es dauernd etwas Neues gibt, geht man nicht mit wehenden Fahnen auf das Web 2.0 zu.

    Zu Christian Henner-Fehr: Es kommt sicher ganz auf die individuelle Situation im Betrieb an. Und Kulturbetriebe sind nochmal eine ganz spezielle Sache – kein leichtes Brot für einen Berater….

    Zu Thorsten: In sehr überschaubaren Betrieben (bzw. Verlagen) eignen sich Wikis sicher besser als Blogs.

  7. Pingback: frogpond » Einsatzmöglichkeiten von Projektwikis (und eierlegende One-Trick Ponys)

  8. Nun ja, ich denke die Enscheidung ‚Wiki oder Blog‘ muss man gar nicht treffen.Man hat Dokumente (wiki) und gs (Gespräche). das wäre, als würde eine Firma sagen: „Also entweder nur Fax (doc) oder nur Telefon (voice).“

    Klar kann man Dokumente vorlesen (bloggen) oder via Fax Diskussionen führen (wie damals in der Schule).

    Software ist aber inzwischen so multifunktional, dass ich mit Wikiblogs längst Doks und ihre Versionen pflegen und News verteilen/diskutieren kann.

    Matthias und ich haben heute telefoniert und dabei hab ich auch gesagt, dass aus meiner Sicht RSS ein ganze wesentliche Komponente der Sache ist. (Nicht umsonst hat sich Socialtext Newsgator als Partner gezogen.)

    Um es mit einem Exbundeskanzler zu sagen: „entscheidend ist was hinten rauskommt.“ Und das wäre im Idealfall optimal distribuiertes (also individuelles wie rollenbedinges berücksichtigend) und intelligent gefiltertertes (also: „suche überall nach xyz“ und sag gleich Bescheid) RSS.

    Sonst haben wir nachher wieder das selbe Kommunkationsproble wie vorher.

    Fazit: Weblogs und Wikis sind kein ‚oder‘ und RSS ist essentiell.

  9. @Martin (Nr. 5): Ich hänge etwas hinterher mit der Moderation, sorry…

    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.

  10. Ein Projektblog, in dem alle wichtigen Informationen zum Projekt abgelegt oder referenziert sind, ist sicher ein tolle Sache.

    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.

  11. @Matthias, über die Frage Wiki oder Blog muss ich gar nicht streiten weil sie sich nicht wirklich stellt. Beides geht gut zusammen, und kann sich ergänzen. Insofern sind die Alternativen, die im Wettstreit stehen doch die konventionelle Art des Projektmanagements (viele Emails, Gruppenlaufwerk, endlose Meetings etc.) und die Alternative „Social Software – dort eingesetzt wo es Sinn macht“.

    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 …

  12. @Wolff: Die Maschinen sind schon weitgehend die gleichen, aber die Umstände doch von Fall zu Fall verschieden: Da wird etwa eine Maschine in den Nachbarort verkauft (ein Handel unter Schwaben), während die nächste nach Korea geht. Oder wieder eine andere Maschine wird an einen namhaften Großkonzern geliefert, dem eine sehr kurze Lieferzeit versprochen wird. Oder es wird nach Skandinavien geliefert, wo die Auflage zu erfüllen ist, dass die Maschine auch nahe dem Gefrierpunkt noch einwandfrei läuft….

    @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.

  13. Ich findes es recht mutig eine Prozentzahl anzugeben. Darüber lässt sich natürlich streiten, wobei ich mir schon vorstellen könnte, dass wir bei einem Projekt mit großen „Kommunikationsoverhead“ in diese Region kommen.

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

  14. @Matthias

    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 …

  15. Pingback: frogpond » Selbstorganisation in Unternehmen und Erfolgsfaktoren der Beratung

  16. Pingback: bwl zwei null » Perspektiven 2008: Let the good times roll…

  17. Pingback: Social Software - was bringt das? : edu.tainment

  18. Pingback: bwl zwei null » Vier Gründe für das Web 2.0 im Mittelstand