Ein System das nicht lebt ist tot!

Ein System das nicht lebt ist tot!

Zu dieser wenig überraschenden Einsicht gelangt man, wenn man sich lange genug durch die Forenwelt in Netz geklickt hat. Es gibt hervorragende Beispiele von Foren, bei denen die Betreiber einfach alles richtig machen. Und es gibt Foren, bei denen das nicht so ist. Ich meine damit übrigens durchaus gar nicht mal die Inhalte, manche Foren und/oder Groups (auch bei Xing) sind derart speziell, dass sich dort nicht gerade minütlich Threads sammeln, dennoch können sie hoch effektiv und inhaltlich geradezu einzigartig und somit von hohem Wert sein.

Ich meine die Moderation! Zwar ist man als Benutzer eines Forums oder einer Gruppe nicht direkt mit einem Gegenüber befasst, aber dennoch merkt man doch recht schnell, ob ein Forum moderiert wird. Wenn nicht, „fühlt“ es sich tot an. Und dann stirbt ein derartiges System auch recht schnell.

Mir sind Beispiele bekannt, bei denen das dennoch versucht wurde. Beispielsweise wurde eine Online-Bildagentur ins Netz gestellt und dann davon ausgegangen, dass das „schon von selbst läuft“. Es lief nicht. Kein einziges Bild wurde verkauft! Oder ein Forum, das mit einem einprägsamen Namen einfach ins Netz gestellt wurde und in dem sich im Laufe von wenigen Wochen wenig Sinnhaftes ansammelte. Das Forum starb noch vor seinem ersten Geburtstag, es wurde einfach nicht mehr genutzt.

Es bedarf eines lebenden Menschen aus Fleisch und Blut der zuständig ist, der „dafür steht“, der ansprechbar ist, der re-agiert.

Genauso wie im weltweiten Netz, verhält es sich auch in internen Netzen, Stichwort „Wissensmanagement“. Auch hier ist mir ein Beispiel bekannt, bei dem ein großes Unternehmen in einer hoch-kompetenten Arbeitsgruppe die Voraussetzungen für ein Wissensmanagement-System erarbeitet hat. Nachdem die Arbeitsgruppe ihre vorbereitende Projektarbeit beendet hatte, gab es plötzlich niemanden mehr, der für die Umsetzung einstand. Das System wurde nicht realisiert. In einem anderen Beispiel ging es umgekehrt zu. Ein komplexes System für ein Wissensmanagement wurde realisiert und die Mitarbeiter wurden nicht „mitgenommen“; weder an der Planung beteidigt noch eingewiesen, noch nicht mal richtig informiert. Geschweige denn, dass zu Beginn bereits verwertbarer content eingepflegt wurde. Die Anwender navigierten einige Zeit im luftleeren Raum, das komplexe und teure System starb den Erstickungs-Tod.

Mehr zum Thema „Wissens-Management“ gibt es HIER

Zum Scheitern verurteilt?

Zum Scheitern verurteilt?

Hier einige Punkte, die nach meiner Erfahrung ein Projekt (zumeist unnötig) zum Scheitern bringen können:

  • Zu allererst: Der Rohrkrepierer (der „Klassiker“ sozusagen): In einer Gruppe / Abteilung / Firma entsteht eine Idee, die ein neues Produkt, Projekt mitunter aus einem „brainstorm“ heraus gebiert (nicht selten in der berühmten Kaffee-Pause). In den meisten Fällen bleibt es bei der Idee, eine  Weiterverfolgung scheitert (vermeintlich) an Zeit, Geld und an dem Vertrauen, dass die Idee etwas „wert sei“ und ein hinreichendes Interesse – und hinreichende Unterstützung – besteht, Innovation zu fördern.
  • Schlechte / unzureichende Finanz- und Ressourcenplanung: Manche Projekte starten mit einem nicht hinreichend durchgeplanten Ziel (personeller Einsatz, Bereitstellung von geldlichen Mitteln), das betrifft zum einen das zeitliche als auch das personelle und inhaltliche Ziel. In  manchen Fällen ist das auch nicht im Vorfeld auf den Punkt genau zu definieren, wenn allerdings unterwegs die Luft ausgeht, kann das (mitunter auch kurz vor Erreichen des Ziels) zum Abbruch führen.
  • Der Unfall: Ein Projekt wird aufgrund eines unvorhersehbaren Ereignisses abgebrochen, z.B. Softwaresteuerung für ein bestimmtes Produkt, das aus unterschiedlichen Gründen aus der „Palette“ entfernt wird/werden muss
  • Der Feind des Projektes: In manchen Fällen wird seitens einer Abteilung ohne hinreichende Rücksprache mit einer „durchführenden Instanz“ ein Ziel definiert, dass von Seiten der Hauptverantwortlichen (oder einer „übergeordneten Instanz“) nicht nur „nicht-unterstützt“ sondern aktiv bekämpft wird.

Beispiel:

-Erstellung einer Anwendung mit einer Software, die von der IT-Abteilung nicht gewünscht wird.
-Erstellung einer Software, die Personaldaten mit einbezieht ohne hinreichende Rücksprache mit dem Betriebsrat oder dem verantwortlichen Datenschutzbeauftragten

  • Akzeptanzprobleme: Durchführung eines Projektes z.B. im Software-Bereich, das für den Anwender nicht akzeptiert wird weil u.a. die inhaltliche und abstimmende Rücksprache mit den betreffenden Personen fehlt(e) und das  Personal nach Fertigstellung ein Produkt „vor die Füße geworfen“ bekommt, dass nicht in jedem Fall den organisatorischen Ablauf widerspiegelt.
  • Persönliche Animositäten im Projekt beteiligter Personen (die „Männerfeindschaft“ – wahlweise auch die Frauenfeindschaft). Der oder die Beauftragende wird von einem Kollegen/Kollegin (oder Vorgesetzten) im Projekt derart behindert, bis das Projekt als gescheitert gilt. Beispielsweise  werden immer neue Anforderungen an das Projekt gestellt, die immer wieder erneute Kosten entstehen lassen oder gar technisch nicht umsetzbar sind mit der Folge, dass das Projekt als nicht-mehr-zielführend oder unfinanzierbar gilt. Mitunter wird dann sogar auf ein „altes“ System zurückgeschaltet – und das vielleicht nur, um dem Kollegen eines „auszuwischen“ und dem die entstandenen Kosten vorzuhalten bzw. sein Budget zu verpulvern.

Schon der erste genannte Punkt lässt sich häufiger als gedacht vermeiden. So sind mir Beispiele bekannt, bei denen Mitarbeiter aus eigenem Antrieb eine kleine Software, beispielsweise eine kleine Datenbank oder einen (zunächst) kleinen Makro erstellen, mit der sich eine häufig wiederkehrende Aufgabe deutlich schneller und zuverlässiger erledigen lässt. Nach nur wenigen Wochen stellt sich der eigentliche „Wert“ dieser dann weiter verfeinerten Anwendung heraus die ich später (mit Unterstützung der Fachabteilung) professionell weiterentwickeln und in die Umgebung des Unternehmens fest installiert konnte.

Also: Nur Mut!