Fahrplan für die Einführung von Wissensmanagement in KMUs

Generell ist die erfolgreiche Anwendung von Wissensmanagement in KMUs ist in zwei Phasen zu untergliedern. So muss im Rahmen eines Projekt das Thema eingeführt werden (Phase 1 Einführung von Wissensmanagement) und dann anschließend in in das tägliche Geschäft möglichst aller Mitarbeiter (operative Prozesse) eingebunden werden . Hierbei spricht man auch von der Operationalisierung des Wissensmanagements.

Die zwei Phasen des Wissensmanagements

Zur optimalen Einführung von Wissensmanagement in KMUs sollte in einem ersten Schritt ein (evtl auch im ersten Schritt vorläufiges) WiMa-Team gebildet werden, das die Einführung des Wissensmanagements fachlich begleiten kann. Wichtig ist hierbei, dass die Mitglieder des WiMa Teams folgende Bereiche abdecken:

• Ablaufverantwortliche der großen betroffenen Geschäftsbereiche (Process-Owner)
• Expertise im Bereich Prozessmanagement
• IT Expertise

Eines der Teammitglieder sollte entweder direkt aus dem Topmanagement stammen oder zumindest über sehr engen Kontakt dazu verfügen und Budget-Verantwortung haben (strategischer WiMa Leiter), ein weiteres, anderes Mitglied sollte mit der operativen Koordination betraut sein (operationeller WiMa Leiter) und hierfür auch ein definiertes Arbeitszeitkontingent zur Verfügung gestellt bekommen. Mitglieder des WiMa Teams können dem operationellen WiMa Leiter später für verschiedene Abschnitte und Aufgaben unterstützend zur Seite stehen (Workshopmoderatoren, IT-Spezialisten etc.). Mit dem WiMa-Team sollten dann in einem eintägigen Workshop die grundlegenden Rahmenbedingungen, die langfristigen Ziele des Wissensmanagements, einen Pilotbereich bzw. ein Schwerpunktthema zur Einführung und ein erster grober und visionärer Zeitplan entworfen und die Ergebnisse in einer WiMa-Roadmap dokumentiert werden.Wichtig ist hierbei die klare Unterteilung der Vorgehensweise in ein WiMa-Pilotprojekt und (evtl. mehrere) erweiterte WiMa-Projekte. Jedes Projekt sollte aber in sich schlüssig sein und präzise Benefits bieten, die eine Umsetzung erforderlich machen.

Anschließend muss die WiMa-Roadmap mit dem Topmanagement, idealerweise dem Unternehmer selbst abgestimmt werden.

Offizieller Startschuss für die Einführung sollte eine kurze (30 Minuten bis maximal 1 Stunde) WiMa Unternehmenspräsentation sein (auch als Telefonkonferenz möglich), an dem nach Möglichkeit alle Mitarbeiter des Unternehmens diese Roadmap und das WiMa-Team und dabei explizit den strategischen und den operationellen WiMa Leiter vorgestellt bekommen. Bei diesem Termin muss das Topmanagement seinen klaren Rückhalt für das Vorhaben und die agierenden Personen zum Ausdruck bringen.

Ab dieser Präsentation sollten der operationelle und der strategische WiMa Leiter einen gemeinsamen wöchentlichen Abstimmungstermin festlegen, damit der strategische WiMa Leiter und damit das Topmanagement jederzeit über den aktuellen Stand der Entwicklungen auf dem laufenden gehalten werden kann und Fehlentwicklungen, Spannungen und andere Probleme frühzeitig adressiert werden können.

Folgend muss vom WiMa-Team im Rahmen eines halbtägigen Pilot-Workshops zum WiMa Projektstart ein grobes Pilot-Konzept zur Einführung und Operationalisierung des Wissensmanagement in dem Pilotbereich bzw. dem Schwerpunktthema mit einem klar definierten, relativ kurzfristigen Ziel und einem konkreten Zeitplan spezifiziert werden. Es empfiehlt sich, den thematischen Bereich des Piloten als einen zusammenhängenden Pilot-Geschäftsprozess zu begreifen (z.B. der Umgang mit Wissen übder kundenspezifische Installationen, oder Verwaltung der Produktkataloge und zugehöriger Informationen der Zulieferer). Die aktuell bestehende Dokumentation sollte dabei für das Projekt als Nacharbeit des Pilot-Workshops zusammengetragen werden. Der operationelle WiMa Leiter ist mit der Ausarbeitung eines Umsetzungskonzeptes für diesen Piloten verantwortlich.

Der operationelle WiMa Leiter sollte hierfür eine 1-3 wöchige Pilot-Analysephase (je nach Komplexität) durchführen, im Rahmen derer er das zu verwaltende Wissen spezifiziert (Fachwissen, Methodenkenntnisse, Kundenwissen, Marktwissen Produktwissen etc.), die vom Wissemsnmanagement betroffenen Organisationseinheiten ermittelt (wer/wann wird Wissen aufgezeichnet, wer/wann wird Wissen abgerufen, etc.) und beteiligte und hilfreiche neue IT-Tools identifiziert.

Das Umsetzungskonzept für den Piloten muss der operationelle WiMa Leiter dem WiMa Team zur Abstimmung und zum Beschluss präsentieren. Der operationelle WiMa Leiter ist folgend auch für die Umsetzung dieses Konzeptes verantwortlich und muss vom strategischen WiMa Leiter dafür mit den nötigen Ressourcen (Zeit, Budget etc.) ausgestattet werden.

Eine der wichtigsten Aufgaben des operationellen WiMa Leiters ist es in den jeweiligen Umsetzungsphasen, das Wissensmanagement den beteiligten und umsetzenden Kollegen als hilfreich und entlastend und für den Einzelnen absolut förderlich darzustellen. Hierbei kann der Unterschied zum strategischen WiMa Leiter, der die Umsetzung „beauftragt“ hat durchaus dargestellt werden. Themen die in diesem Zusammenhang von Person zu Person unterschiedlich motivierend wirken können sind:

• Weiterbildung im Umgang mit den vorgesehenen Tools zum WiMa
• Kompetenzaufbau in angrenzenden Wissensbereichen
• Management des eigenen Wissens – auch privat anwendbar
• Gewinnen von Seniorität und Souveränität gegenüber den Kollegen (z.B. als Autor von Artikeln)
• Profilierung durch Verbesserungsanregungen, Weitergabe von „Guter Praxis“ an Kollegen („Also ich würde das ja so machen…“)

Die konkrete Umsetztung des Piloten erfolgt wiederum in zwei Schritten. Im ersten Schritt werden mit den beteiligten Organisationseinheiten WiMA-Prozessworkshops abgehalten, bei denen Teilprozesse des Pilot-Geschäftsprozesses mit WiMa-relevanten Elemente spezifiziert werden. Es geht dabei darum klar zu identifizieren, welches Wissen in welchen Aktivitäten verwendet wird, wo und wann dieses Wissen entsteht, wie dieses Wissen im Unternehmen vorliegt (im Kopf eines Mitarbeiters, in Schriftform, in einer Applikation), wie und welche Informationen ausgetauscht werden und um welches Wissen (Fachwissen, Kundenwissen etc.) es sich dabei handelt. Anschließend werden Wissensmanagement-Methoden in den Teilprozess integriert und der Pilot-Geschäftsprozess dadurch optimiert. Die Ergebnisse der WiMa-Prozessworkshops müssen in formellen Protokollen festgehalten werden. Insbesondere den Optimierungsvorschlägen und den zugrundeliegenden Problemen muss hierbei erhöhte Aufmerksamkeit geschenkt werden. Nachdem alle Workshops durchgeführt sind, werden im zweiten Schritt vom operationellen WiMa Leiter die Ergebnisse aller WiMa-Prozessworkshops zusammengefasst und die beschloßenen Maßnahmen sowie die zu ändernden Prozessabläufe in einer Präsentation zusammengefasst. Das WiMa Team erhält diese WiMa Decision-Präsentation zur Beschlussfassung.

Folgend werden die beschloßenen Masnahmen im Rahmen eines WiMa-Change Management-Projektes unter der Verantwortlichkeit des operationellen WiMa Leiters umgesetzt. Nach Abschluss der Implementierung ist der operationelle WiMa Leiter für die Erstellung passender WiMa-Anweisungen verantwortlich, deren Einhaltung die Umsetzung des Wissensmanagements im Rahmen des Tagesgeschäftes sicherstellt. WiMa Anweisungen können beispielsweise Leitfäden, Prozessbeschreibungen, Schritt-für-Schritt Anweisungen, Checklisten, etc. sein.

Im Rahmen eines Debriefings für das Pilotprojekt werden die WiMa Anweisungen dem WiMa Team vom operationellen WiMa Leiter vorgestellt und dem strategischen WiMa Leiter übergeben. Das Debriefing dient des weiteren dazu, eine „Manöverkritik“ durchzuführen und – ganz im Sinne des Wissensmanagements – die „Lessions Learned“ festzuhalten und Optimierungsvorschläge bei der WiMa Projektdurchführung selbst zu definieren.

Nach dem Debriefing wird vom operationellen WiMa Leiter ein Vorschlag für den Scope des / der folgenden erweiterte(n) WiMa Projekt(e) erstellt. Dieser Vorschlag wird vom WiMa Team überarbeitet und beschloßen. Die einzelnen erweiterten WiMa Projekte werden analog zum Pilotprojekt durchgeführt. Sofern mehrere erweiterte WiMa parallel durchgeführt werden sollen, sollte für jedes erweiterte WiMa Projekt ein eigener WiMa-Projektleiter definiert werden, der die Funktion des operationellen WiMa Leiters für das Projekt einnimmt und dem operationellen WiMa Leiter fachlich untergeordnet ist. Es hat sich als schwer durchführbar erwiesen, mehrere WiMa Projekte gleichzeitig und unabhängig operationell zu leiten.

Parallel zur SetUp der erweiterten WiMa Projekte erfolgt jetzt die Operationalisierung des Wissensmanagements für das Pilotprojekt. Die Verantwortung für die Verteilung und die Durchsetzung der Einhaltung der jeweiligen WiMa-Anweisungen trägt der strategische WiMa Leiter. Er ist bei der Operationalisierung im Lead. Die Vorgehensweise für diese Umsetzung ist sehr unternehmensspezifisch und erfordert in vielen Fällen auch politische Unterstützung des Topmanagements.

Es hat sich jedoch als sehr hilfreich erwiesen, wenn der strategische WiMa Leiter hierbei mit Stichproben auf unterster Ebene arbeitet. Er sollte sich also mit einzelnen in den WiMa-Anweisungen spezifizierten Details befassen und diese auf Systemebene prüfen. Bei der Prüfung im System kann der strategische Leiter natürlich auch durch den operationelle WiMa Leiter oder andere Helfer unterstützt werden. Im Falle von Fehlern, sollte aber der strategische WiMa Leiter den direkten Kontakt mit den umsetzenden Mitarbeitern suchen, den Fehler schnell und in Zusammenarbeit beheben und den Mitarbeiter auf die Wichtigkeit der Integration der jeweiligen WiMa Tasks aufmerksam machen. Auch hier sollten sich die oben beschriebenen Motivationsanreize als hilfreich erweisen.

Gründe für die Einführung von Wissensmanagement in KMUs

Im Rahmen der Verschiebung von einer industriellen Gesellschaft hin zur post-industriellen Informationsgesellschaft entwickeln sich vielfach die Unternehmensabläufe (sprich Geschäftsprozesse) analog von industriellen Produktionsprozessen hin zu individuellen Dienstleistungen. Daraus resultiert eine wesentlich höhere Komplexität der Geschäftsprozesse, da Individualisierung der Dienstleistungen immer wieder neu angepasste Leistungen erfordert. Zentrales Werkzeug ist hier natürlich einerseits das Prozessmanagement, andererseits das Wissensmanagement.

Insbesondere in kleinen und mittelständischen Betrieben (KMU) stellt die Einführung von Wissensmanagement-Methoden regelmßig eine hohe Hürde da. In vielen Fällen wird dann ein Tool (z.B. ein Wiki) als Lösung betrachtet. Die Integration diese Tools in die operationelle Arbeit sprich ins Tagesgeschäft des einzelnen Mitarbeiters wird dabei jedoch fast immer vernachlässigt. Die folgende Artikel-Serie soll eine Hilfestellung bei der Operationalisierung von Wissensmanagement in KMUs geben.

Generell ist Wissensmanagement in Unternehmen natürlich nichts neues. Beispielsweise wurde wichtiges Unternehmenswissen (z.B. Kundendaten, Buchhaltung, Baupläne, Rezepte, Berichte etc.) schon immer aufgeschrieben, um es im Bedarfsfall zu begutachten. Mehrere grundsätzlich neue Faktoren führen jedoch zu einem neune Verständnisse und Einsatzbereich des Wissensmanagement:

• Im Gegensatz zu früher herscht heute eine signifikant höhere Mitarbeiter-Fluktuation in Unternehmen. War es früher durchaus üblich in dem Unternehmen, in dem man zu arbeiten begonnen hat, auch in Rente zu gehen, ist die heute wohl eher die krasse Ausnahme. Dementsprechend muss das Wissen über die jeweiligen Prozesse wesentlich schneller aufgebaut / weitergegeben werden;
• Die hohe Individualisierung der Geschäftsprozesse führt zu komplexeren Abläufen, die dementsprechend teilweise selten ausgeführt werden;
• Die Einführung von modernen IT System ermöglicht neue Vorgehensweisen (insbesondere hochperformante Datenbanken, ubiquitous Computing, Web2.0 Ansätze etc.);
• Schnelllebigere Wertschöpfungsprozesse führen zu häufigeren Anpassungen der Vorgehensweise;
• Qualitätsmanagement Standards verpflichten Unternehmen in vielen Fällen zur (teilweise Kontraproduktiven) Einhaltung einer (teilweise unübersichtlichen) Vielfalt von Richtlinien;
• Die stärkere örtliche Verteilung der Mitarbeiter (Heimarbeit, mehr Business Trips, Projekteinsätze beim Kunden, etc.) im Gegensatz zur klassischen Büro-/ Teamarbeit bei der alle Teammitglieder an einem Ort sind und sich (mehr oder weniger) permanent austauschen können;

All diese Faktoren machen Wissensmanagement, das weit über klassisches Dokumentenmanagement, die Buchhaltung und eine Kundendatenbank hinaus geht, auch in KMUs immer wichtiger. Eine Fahrplan zur Einführung von Wissensmanagement in KMUs finden sie hier.

Prozessmanagement – Geschichtliche Entwicklung

Die erste größere Strategie die sich nach der industriellen Revolution im Bezug auf die Zusammenarbeit in Betrieben durchsetzte war von dem Gedanken der Spezialisierung getragen. Ihre konsequenteste und bekannteste Umsetzung erfuhr die Spezialisierung in den Automobil-Werken von Henry Ford. Einzelne eng begrenzte Aufgaben wurden Spezialisten übertragen, die für deren Lösung optimierte Werkzeuge entwickelten und die Rahmen ihres operativen Geschäfts auch nur mit dieser einen Aufgabe betraut waren. Im Rahmen des Scientific Managements wurden die Arbeitsabläufe und die einzelnen Aktivitäten dabei hochgradig detailliert vorgegeben und der eine beste Weg (One Best Way), das Ziel zu erreichen definiert. In die Definition dieses Best-Ways wird dabei erheblicher Aufwand investiert und die Resultate werden mit viel Empirie unterlegt (Messungen mit der Stoppuhr, wie eine Schraube am schnellsten platziert werden kann). Damit einher gingen tiefe Hierarchien und oft stupide Einzelarbeit, woraus wiederum oft ein Mangel an Verständniss für die Zusammenhänge im Unternehmen resultierte. Mit der steigenden Komplexität der Produktionsprozesse nahmen auch die Probleme dieser als Taylorismus bekannten Managementschule zu. Insbesondere das Wachstum des Dienstleistungssektors, in dem die produzierten Produkte – sprich die Dienstleistungen – wesentlich häufiger individualisiert werden müssen als auch der zunehmende Einsatz von Maschinen und später Robotern für die standardisierbaren Arbeitsschritte in der Industrie führten zu immer größeren Unzulänglichkeiten dieses Ansatzes.

Dies führte dazu, dass sich in den 70ern und 80er Jahren des letzten Jahrhunderts die Organisationen und dementsprechend auch die wissenschaftlichen Management Schulen immer mehr mit dem aus Japan kommendem Toyota Production System (TPS) und seinen Maximen beschäftigten. Im Rahmen dieses aus Managementansatz, der auch als Lean Management oder Kai Zen bekannt ist, bilden Gruppen von Mitarbeiter (Teams) die zentralen ausführenden Einheiten. Diese Gruppen erledigen weitestgehend autonom die Ihnen übertragenen Aufgabenfelder. Einerseits führt die Teamarbeit dazu, dass einzelne Personen leichter vertreten bzw. ersetzt werden können (z.B. im Krankheitsfall oder beim Ausscheiden). Auf der anderen Seite nimmt aufgrund des erweiterten Aufgabenspektrums des Teams und der Weiterbildung der Mitarbeiter durch Trainings auch gleichzeitig der Verständnishorizont für die jeweiligen Unternehmensabläufe und innerbetrieblichen Zusammenhänge stark zu. Dieser Faktor ist bei komplexen Geschäftstätigkeiten essentiell und ermöglicht es dem Team in seinem Arbeitsgebiet möglichst permanent kleine Verbesserungen (Kontinuierliches Verbesserungs-Programm (KVP) / Continous Improvement Program, CIP) durchzuführen, die stets die Optimierung des eigenen Arbeitsplatzes und der Arbeitsabläufe zum Ziel haben. Im Japanischen ist „Muda“ hier der zentrale Begriff. Er steht für die – sinnlose – Verschwendung von Ressourcen. Zur Vermeidung der Verschwendung dürfen dementsprechend auch möglichst wenige fehlerhafte Produkte erzeugt werden, sprich Fehler vermieden werden. Hieraus entstand insbesondere Six Sigma und ähnliche Ansätze. Die Qualität der Produkte und Dienstleistungen rückte hier immer stärker in den Mittelpunkt und die Messung dieser Qualität und von Produkt-Vorstufen erfolgt mittels sogenannter Key-Performance-Indikators (KPI). Deren regelmäßige Messung und deren permanentes Monitoring und Controlling durch das Management (z.B. durch Balanced Scorecards (BSC) oder Management Cockpits) bilden die Grundlage jedes modernen Qualitätsmanagement Systems (QM / TQM). Der bekannteste internationale Standard in diesem Bereich ist ISO 9000 / ISO 9001. Basierend darauf haben sich viele weitere branchenspezifischen QM-Standards und Best-Practices entwickelt (z.B. ITIL / Cobit für die IT, CMMI für die Automobilbranche etc.).

Parallel zu diesen Standards ging auch eine Entwicklung einher, die die zu erledigenden Aufgaben innerhalb von Unternehmen wieder stärker als eine sich wiederholende und damit standardisierbare Abfolge von Tätigkeiten begreift. Auch wenn es viele Kombinationen für die jeweiligen Abläufe gibt und die Abläufe teils in vielen Varianten vorliegen um die individualisierten Produkte bereitstellen zu können, ermöglicht eine Standardisierung der Abläufe eine Sicherung der vorgegebenen Qualitätskriterien. Diese definierten Arbeitsabläufe werden als Prozesse bzw. Geschäftsprozesse bezeichnet. Der dazugehörige Management Ansatz ist das Geschäftsprozessmanagement (GPM, bzw. engl. Business Process Management, BPM). Hierbei werden möglichst alle Vorgänge innerhalb des Unternehmens als Prozesse verstanden. Für eine operative Umsetzung von BPM ist die Definition eines Process Owner Konzepts, mittels dessen die Verantwortlichkeiten für die Prozesse und die damit verbundenen Befugnisse definiert werden. Der Process Owner trägt hierbei die Verantwortung für die Korrektheit und die Effizienz des jeweiligen Geschäftsablaufs sowie die Verteilung der mit dem Prozess verbundenen Aufgaben. Er ist die Person, die für Ablaufgestaltung und die Einhaltung aller Vorgaben sowie für die Erreichung der Ziele des Prozesses verantwortlich ist.

Bezüglich der Organisationsgestaltung stellt das Rollenverständnis des Prozessmanagements eine weitere Veränderung zum klassischen Team-Modell dar. Im Rahmen des Prozessmanagements werden die einzelnen Aktivitäten innerhalb von Prozessen von Rollen ausgeführt bzw. verantwortet. Diese Rollen werden von Mitarbeitern einer Organisationseinheit bzw. eines Teams eingenommen und werden ihnen anhand von spezifischen Anforderungsprofilen zugeordnet.

Auf der obersten Abstraktionsebene, dem Level 0, werden Geschäftsprozesse grundsätzlich in drei verschiedene Prozessarten unterschieden.

1. Die Kernprozesse (Core Processes) oder Geschäftsprozesse im engeren Sinn, die die wertschöpfenden Abläufe im Unternehmen darstellen. Dazu gehören alle Prozesse der Bereiche Product Livecycle Management (PLM), Customer Relationship Management (CRM) und des Supply Chain Managements (SCM).
2. Die Support Prozesse, die eine reibungslose Durchführung der Kernprozesse ermöglichen. Hierzu zählen unter vielen anderen alle IT-Management Prozesse, Human Ressources Prozesse, Real Estate Management, Financial Services, Compliance, Audit u.v.m.
3. Die Management Prozesse, die sich mit der Steuerung und strategischen Ausrichtung des Unternehmens befassen.

Zur detaillierteren Betrachtung der Prozesse (Level 1) werden sogenannte Wertschöpfungsketten-Diagramme (WKD bzw. engl. Value Added Chain Diagramms, VACDs) verwendet. Diese WKDs kann man für die übersichtliche Zergliederung von Prozessen verwenden. Ab einem gewissen Level (dem Level n, typischer Weise dem Level 3-5) wechselt man in der Darstellung zu (erweiterten) Ereignisgesteuerten Prozessketten (EPK bzw. engl. (extended) Eventdriven Process Chains, (e)EPC). Zusätzlich zu dieser meist organisatorisch getriebenen Gliederung der Prozesse kann es noch andere Blickwinkel (engl. Views) geben. Hierbei ist insbesondere der End-To-End (E2E) View zu erwähnen. Mittels des E2E Views werden die Unternehmensabläufe aus sicht eines einzelnen Geschäftsvorfalls wie z.B. von einer Kundenanfrage bis zur Auslieferung des Produktes betrachtet. Alle Views, insbesondere auch der E2E View, sollten dabei ausschließlich auch in Form von WKDs (evtl. mehrere Level) modelliert werden aber letztendlich immer auf die bestehenden (e)EPKs des Level n verweisen.

Alle Prozesse, die gänzlich innerhalb einer Organisationseinheit ablaufen werden in den meisten Fällen regelmäßig reviewed und optimiert und sind dementsprechend effizient. Im Bereich der Optimierung von Organisationseiheiten-übergreifenden Prozessen ist meist keine zentrale Verantwortlichkeit definiert. Auf Grund dieser fehlenden Verantwortung wird eine Optimierung organisationsübergreifender Prozesse meist nicht durchgeführt. In vielen Fällen entstehen dadurch hochgradig komplexe End-To-End und damit Ineffizienzen im Bereich der Schnittstellen zwischen den Verantwortlichkeiten zweier Teams. Zur Lösung dieser Ineffizienzen werden derzeit zwei verschiedene Ansätze verfolgt:

1. Konsequente Durchsetzung des Process Owner Konzepts über alle Prozesse, Views und Level hinweg. Insbesondere auch für den End-To-End Process View. Problematisch kann hier die eindeutige Zuordnung der Verantwortlichkeiten werden, wenn die einzelnen Views nicht stringent nach Verantwortlichkeiten getrennt verwaltet werden.
2. Die Verantwortlichkeit für eine Schnittstellenübergreifende Prozessverwaltung wird einer Zentralstelle übertragen. Diese Zentralstelle muss zwingend den Rückhalt des Top-Managements genießen, da sie selbst in den schnittstellenübergreifenden Geschäftsprozessen der zweiten Führungsebene Optimierungen vornehmen müssen.

Welcher dieser beiden Ansätze sich schließlich durchsetzen wird bleibt abzuwarten.

Dieser Artikel erschien erstmalig als Artikel von tomqb