Treffend gesagt auf CommonCraft:
Blogs and message boards both suffer from the same problem- they are great for presenting emerging information, but poor at organizing it for future reference. The „good stuff“? that people often need and companies often want to capture quickly gets buried among all the comments and messages… With this post, I“m outlining a potential way organizations can use blogs and message boards as a way to generate useful information and a wiki as a way to filter, archive and organize it for future reference.
Bilder sagen mehr als Worte, wie sich das der Autor grundsätzlich vorstellt bzw ausgemalt hat.
Diese Grafik ist selbstredend:
Neue Stellenangebote
|
Growth Marketing Manager:in – Social Media GOhiring GmbH in Homeoffice |
|
|
Senior Social Media Manager:in im Corporate Strategy Office (w/d/m) Haufe Group SE in Freiburg im Breisgau |
|
|
Senior Communication Manager – Social Media (f/m/d) E.ON Energy Markets GmbH in Essen |
Und so könnte der Übernahmeprozess auf Knopfdruck aus einem Blogartikel in ein Wiki aussehen:
Allerdings wird dort eine Copy&Paste Lösung genannt. Das finde ich für den User nicht zumutbar. Hier gehört mE auf den ersten Gedanken hin beim Klick auf „WikiThis“ eine kleine Box hin, in der man folgende Optionen setzen kann:
– Verlinkter Begriff/Phrase
– Kategorisierung (Lösungsansatz = Support für die Problemkategorie XYZ)
– Workflow Schritt (zur Freigabe, zur Revidierung, Freigeben)
– optional Übernahme aller oder ausgewählter Usercomments
– Tagging inkl. einer Tagübersichtsseite im Wiki
– interne Kennzeichnung im Blogartikel, daß dieser im Wiki hinterlegt wurde
– Crossreferencing = Weitere, passende Artikel im Wiki aussuchen können (über Suchfilter) und im Wikibeitrag crosslinken, dazu natürlich nicht nur das Crosslinking vom neu generierten Wikiartikel A zu N Artikeln, sondern N Artikel zu A automatisch crosslinken. Ergebnis: Mit der Zeit findet man vermehrt Wikiartikel die auf weitere Lösungsansatze (wenn es im Supportbeispiel bleibt) innerhalb des Wikis verweisen. Klassische Knowledge Base Ansatz.
das ist ein spannender ansatz. copy & paste ist allerdings wirklich (noch) zu wenig. könnte wie ein kleines bookmarklet aussehen oder dass der text automatisch schon drin steht. wobei man da auch wieder gefahr läuft, dass aus jedem artikel 3-4 kommentare 1:1 ins wiki kopiert werden. insgesamt finde ich das eine sehr schöne, neue schnittstelle.
Ich grübel auch schon lange, wie man ein Wiki integrieren könnte, denn der Background macht Sinn im Zusammenhang mit Blogs. Ich frage mich nur beim Ansatz oben, ob daraus tatsächlich eine Knowledge Base entstehen würde und nicht einfach nur die Diskussion weitergeführt bzw. gespiegelt werden würde. Oder anders: Müsste man nicht einen „Filter“ haben, der sich beinahe Fulltime um das Wiki kümmert, damit es eine tatsächliche Bereicherung ist?
Bei Interesse bitte gerne per Mail gemeinsam weiterdenken, sehr spannend.
Das hängt ganz von der Konstellation ab, in der Du Dich bewegst.
Nehmen wir folgendes organisatorisches Konstrukt:
– 80 Supporter mit je 20er Teams, also 4 Spezialbereiche, die hauptsächlich tel. qualitativen Support für Fachkräfte betreiben (Branche egal)
– 4 Teamleiter und 4 Stellvertreter
– 1 Knowledge Team aus den besten Experten des jeweiligen Teams
– 4 Blogs passend zu den Spezialbereichen
Wenn man das Wiki nun als etwas versteht, in dem ein Externer nichts zu suchen hat, nur die 80 Mitarbeiter, kann es und wird es nicht zu „Diskussionen“ führen. Ein erfasstes Problem = Blogartikel+Kommentare wird analysiert, beschrieben und eine Lösung formuliert. Die Analyse erfolgt bereits nicht mehr im Blog, sondern bedarf idR einer workflowgesteurten Lösung. Wikis kennen sowas nicht, ist aber kein Problem. Warum Workflow? Da uU weder ein Team noch die anderen drei etwas „lösen“ können, muß diese Info an weitere Experten inhouse gelangen. Wikiflow quasi.
Die Schritte sind also Blog => Artikel => Kommentar => Problem erkannt => Analyse im Team, teamübergreifend bzw. weitere externe Experten => fertige Ablage in Wiki (zwischendurch sind die einzelnen Versionen = Workflowsteps). Wer gibt nun frei? Die Teamleiter segnen einen fertigen Artikel im Wiki ab. Ergänzungen an den Artikeln kann nur ein weiterer Experte vornehmen, der die Änderungen absegnen lassen muß. Auch wiederum nicht ein Externer als Blogleser etwa. Die können immer nur im Blog etwas beisteuern.
Ohweehhh … ich habe wohl hoffentlich nicht zu sehr gedanklich Wichtiges verschluckt, da ich dummerweise schon wegen alten Projekten diesbezgl. eingegleist bin. Wikis haben lediglich den Charme, daß sie einfach sind und eine gemeinsame Pflege ermöglichen. Doch gerade eine besonders striktes Quality Management ist gedanklich schwer davon zu überzeugen, Kontrolle hinsichtlich justierter Workflowsteps mit entsprechenden Rechten für Editoren, Leser, …. zu Gunsten eines Wikis aufzugeben. Das Dumme ist aber an diesen strikten Systemen: Je mehr Infos reingeballert werden, umso mehr rächt sich das Korsett aus Kontrolle, Freigabe, Gegenkontrolle,.. es wird einfach zu unhandlich diese Verwaltung eines Infoberges. Da mitunter natürlich viele Infos eine nur geringe Halbwertszeit haben (der Aufwand des Einstellenprozess inkl. Kontrollinstanzen ist größer als der Wert der Info). Ich tendiere eher dazu Wikis gegenüber anderen superduperhighflyer System zu bevorzugen.
In jeglicher anderer Konstellation ist natürlich ein Mitmischen der originären Infoproduzenten durchaus denkbar. Ausgelutschtes Beispiel ist ja die Wikipedia vs. Old World = Enzyklopädie XYZ
Will sagen? Wenn Wikis in einer solchen „komisch regulierten“ Umgebung – die wirklich nicht easy ist, weil so starr – wie man sie bei Großkonzernen vorfindet möglicherweise funktionieren würden, warum sollen dann nicht da draussen funktionieren, wo man auf Knopfdruck schwupp einen Artikel ins Wiki übernimmt und zB nur registrierten Lesern Schreibrechte vergibt? Die Leser sind quasi Deine Experten.