Umgang mit Wissensproblemen in der ... - w.e.b.Square
Umgang mit Wissensproblemen in der ... - w.e.b.Square Umgang mit Wissensproblemen in der ... - w.e.b.Square
wichtige Grundlage für Änderungseingriffe. Sind diese nicht vorhanden, entsteht eine große Unsicherheit und die Weiterentwicklung der Anwendung wird verzögert oder gar blockiert. Um das Risiko bei Änderungseingriffen möglichst sicher ausschließen zu können, ist eine lange Analysephase zur Durchführung eines Eingriffs erforderlich, was wiederum den Zeitdruck erhöht und die Zeit für die Dokumentation der Erkenntnisse raubt. Weitere Folgen dieser Problematik sind die sinkende Motivation sowie die Unabschätzbarkeit des Arbeitsaufwandes, was die Zusammenarbeit mit den Fachbereichen behindert, da eine Aufwandschätzung kaum möglich ist. Problemursache II: Wie bei der kurzen Beschreibung der Aufgabenverteilung deutlich wurde, ist Wissen und Erfahrung unterschiedlich unter den Teammitgliedern verteilt, was prinzipiell nicht schlecht ist, sondern im Gegenteil bei gutem Wissensaustausch auch Vorteile mit sich bringen kann, beispielsweise durch Synergieeffekte. Jedoch wird es bei schwachem Wissenstransfer u.a. dann zu einem Nachteil, wenn es um die Vertretung eines abwesenden Teammitgliedes geht. So sagt Bettina Gaus: „Also wir hängen da in der Luft, wenn mal jemand mit Spezialwissen krank wird“ (Aufnahme Bettina Gaus, 22:28 min., s. elektronischer Anhang). Die Vertretung eines Teammitgliedes wird zusätzlich dadurch erschwert, dass es keine Dokumentation über die alltäglichen Aufgaben der Mitarbeiter gibt bzw. den anderen nicht bekannt ist. Problemursache III: Mangelnde Entlastung durch den Support. Wie bereits bei Ursache 1 angedeutet, nutzt der Support die Dokumentation in Assyst nur teilweise, sodass immer wieder Problemfälle, die bereits behandelt wurden, bei dem Team landen. Nach der Einschätzung von Bettina Gaus und Dimitri Marx liegt dies einerseits daran, dass es üblich ist Probleme weiter zu schieben, statt sich selbst die Mühe zum Nachforschen zu machen. Andererseits ist es auch auf das fehlende Wissen des Supports über WBMS zurückzuführen sowie auf die schlechte Handhabbarkeit von Assyst. Dies erhöht v.a. die zeitliche Belastung des Teams und führt somit zu Frust und Stress. Problemursache IV: Die Unterbesetzung des Teams trägt indirekt zur Verstärkung der Problematiken bei, da dadurch wieder der Zeitdruck erhöht wird. Allerdings wird auf diese Ursache im Folgenden nicht weiter eingegangen, weil es nicht durch eine Wissensmanagement-Maßnahme zu lösen wäre. Gemein ist v.a den Ursachen 1, 3 und 4, dass sie den Zeitdruck verstärken und somit sowohl die Zeit zur Weiterentwicklung und Verbesserung des Systems als auch die Zeit zur Dokumentation rauben. So entsteht der beschriebene Teufelskreis. Um nun die gesamte Problemsituation zu strukturieren und mit einer Wissensmanagement- Brille zu analysieren, werden die vier Wissensprozesskategorien des Münchener Modells angewendet. Es wird untersucht, welche Problematik in welche Kategorie einzuordnen ist. Anhand Abbildung 5 wird deutlich, wie die Probleme in den einzelnen Prozesskategorien die in den anderen Kategorien beeinflussen. Somit wird die enge Verkettung der vier Wissensprozesse durch den Praxisbezug offensichtlich. 28
Abbildung 5: Ist-Zustand in den Prozesskategorien Wie in Abbildung 5 deutlich wird, liegen die hauptsächlichen Probleme im Bereich der Wissensrepräsentation, die negative Auswirkungen auf die Wissenskommunikation, die Wissensnutzung und indirekt auch auf die Wissensgenerierung haben. Durch die Schwächen in der Wissensrepräsentation wird das Wissen schwer zugänglich und damit auch schwer transferierbar und nutzbar. Folglich entsteht keine Wissenstransparenz, was das Risiko für Wissensverluste erhöht. Der psychologische Aspekt der Angst vor Machtverlust durch das Preisgeben von Wissen kommt im vorliegenden Fall nicht zum Tragen, da dem Team die Notwendigkeit zur Dokumentation von Wissen bewusst ist und die Bereitschaft dazu besteht. Dies liegt daran, dass die Dokumentation nur positive Auswirkungen für das Team haben kann. Zum einen entstünde dadurch eine große Entlastung, da einerseits der Support selbstständiger arbeiten könnte und andererseits der Know-how-Transfer im Team erleichtert werden würde. Zum anderen würde die Dokumentation die Weiterentwicklung der Software erleichtern. Durch die mangelnde Nutzung des dokumentierten Wissens, wird das Potenzial dieses informationsnahen Wissens nicht genutzt, indem es in Handlungen umgewandelt wird. Somit kommt es zu aufwendigen Doppelarbeiten, der Know-how-Transfer wird erschwert und Vertretungen sind problematisch. Eine weitere Folge der mangelnden Wissensnutzung, ist die dadurch eingeschränkte Wissensgenerierung. Da der Support Wissenslücken bezüglich des WBMS-Systems hat, wäre die Dokumentation in Assyst für ihn eine hilfreiche Ressource, um daraus Wissen zu schöpfen. Auch die Teammitglieder könnten die Dokumentation nutzen, um Wissen über die Tätigkeitsfelder der Kollegen zu generieren. Der psychologische Aspekt, der sich sowohl bei der Wissensnutzung als auch bei der Wissensgenerierung und der Wissensrepräsentation als Hindernis auswirkt, ist die mangelnde Akzeptanz der verwendeten Tools, die einhergeht mit deren inkonsequenten Nutzung. Dies lässt auf eine geringe Motivation und Bereitschaft der Mitarbeiter, das träge Wissen zu aktivieren, schließen (vgl. Kap. 2.3.2). Trotzdem ist davon auszugehen, dass das Problem technischer Natur ist und, dass die ausschlaggeben- 29
- Seite 1 und 2: Umgang mit Wissensproblemen in der
- Seite 3 und 4: 7. Literaturverzeichnis............
- Seite 5 und 6: ternehmen wird hier deutlich und is
- Seite 7 und 8: Der zweite Abschnitt befasst sich m
- Seite 9 und 10: Aufgrund der Interdisziplinarität
- Seite 11 und 12: Generell wird in der Studie von 91%
- Seite 13 und 14: system nicht für Wissensmanagement
- Seite 15 und 16: gement-Maßnahme wichtig, dass hier
- Seite 17 und 18: „neue Technologien schnell und br
- Seite 19 und 20: � Der hohe Grad an Arbeitsteilung
- Seite 21 und 22: zu Grunde lag, entspricht den Forsc
- Seite 23 und 24: über das Nichtwissen sowie gewisse
- Seite 25: setzung erfolgt dann in den beschri
- Seite 30 und 31: den Punkte für ein passendes Instr
- Seite 32 und 33: lung der Erkenntnisse im Tool sollt
- Seite 34 und 35: Wiki: Der erste Bestandteil des Ma
- Seite 36 und 37: (Eppler, 2000 und Tergan, 2004). Ei
- Seite 38 und 39: den. Die Rahmenbedingungen, die in
- Seite 40 und 41: Teil III. — Lösungskonzept auf h
- Seite 42 und 43: zu Beginn der Maßnahme Regeln für
- Seite 44 und 45: Zusammenfassend stellt Abbildung 8
- Seite 46 und 47: Ähnliche Fragen stellen sich bei m
- Seite 48 und 49: Aktivitäten in den Arbeitsalltag.
- Seite 50 und 51: Hackman, J. R., Oldham, G.R. (1980)
- Seite 52 und 53: Smolnik, S., Riempp, G. (2006). Nut
- Seite 55: II. Beispiel für einen Mikroartike
Abbildung 5: Ist-Zustand <strong>in</strong> den Prozesskategorien<br />
Wie <strong>in</strong> Abbildung 5 deutlich wird, liegen die hauptsächlichen Probleme im Bereich <strong>der</strong><br />
Wissensrepräsentation, die negative Auswirkungen auf die Wissenskommunikation, die<br />
Wissensnutzung und <strong>in</strong>direkt auch auf die Wissensgenerierung haben. Durch die Schwächen<br />
<strong>in</strong> <strong>der</strong> Wissensrepräsentation wird das Wissen schwer zugänglich und da<strong>mit</strong> auch<br />
schwer transferierbar und nutzbar. Folglich entsteht ke<strong>in</strong>e Wissenstransparenz, was das Risiko<br />
für Wissensverluste erhöht. Der psychologische Aspekt <strong>der</strong> Angst vor Machtverlust<br />
durch das Preisgeben von Wissen kommt im vorliegenden Fall nicht zum Tragen, da dem<br />
Team die Notwendigkeit zur Dokumentation von Wissen bewusst ist und die Bereitschaft<br />
dazu besteht. Dies liegt daran, dass die Dokumentation nur positive Auswirkungen für das<br />
Team haben kann. Zum e<strong>in</strong>en entstünde dadurch e<strong>in</strong>e große Entlastung, da e<strong>in</strong>erseits <strong>der</strong><br />
Support selbstständiger arbeiten könnte und an<strong>der</strong>erseits <strong>der</strong> Know-how-Transfer im<br />
Team erleichtert werden würde. Zum an<strong>der</strong>en würde die Dokumentation die Weiterentwicklung<br />
<strong>der</strong> Software erleichtern. Durch die mangelnde Nutzung des dokumentierten<br />
Wissens, wird das Potenzial dieses <strong>in</strong>formationsnahen Wissens nicht genutzt, <strong>in</strong>dem es <strong>in</strong><br />
Handlungen umgewandelt wird. So<strong>mit</strong> kommt es zu aufwendigen Doppelarbeiten, <strong>der</strong><br />
Know-how-Transfer wird erschwert und Vertretungen s<strong>in</strong>d problematisch. E<strong>in</strong>e weitere<br />
Folge <strong>der</strong> mangelnden Wissensnutzung, ist die dadurch e<strong>in</strong>geschränkte Wissensgenerierung.<br />
Da <strong>der</strong> Support Wissenslücken bezüglich des WBMS-Systems hat, wäre die Dokumentation<br />
<strong>in</strong> Assyst für ihn e<strong>in</strong>e hilfreiche Ressource, um daraus Wissen zu schöpfen.<br />
Auch die Team<strong>mit</strong>glie<strong>der</strong> könnten die Dokumentation nutzen, um Wissen über die Tätigkeitsfel<strong>der</strong><br />
<strong>der</strong> Kollegen zu generieren. Der psychologische Aspekt, <strong>der</strong> sich sowohl bei <strong>der</strong><br />
Wissensnutzung als auch bei <strong>der</strong> Wissensgenerierung und <strong>der</strong> Wissensrepräsentation als<br />
H<strong>in</strong><strong>der</strong>nis auswirkt, ist die mangelnde Akzeptanz <strong>der</strong> verwendeten Tools, die e<strong>in</strong>hergeht<br />
<strong>mit</strong> <strong>der</strong>en <strong>in</strong>konsequenten Nutzung. Dies lässt auf e<strong>in</strong>e ger<strong>in</strong>ge Motivation und Bereitschaft<br />
<strong>der</strong> Mitarbeiter, das träge Wissen zu aktivieren, schließen (vgl. Kap. 2.3.2). Trotzdem ist<br />
davon auszugehen, dass das Problem technischer Natur ist und, dass die ausschlaggeben-<br />
29
Change language