2) PoV | Kriterien | PoC

Filterung der Umsetzungsvarianten

Das folgende Vorgehen gliedert sich in drei Bereiche, die sich vor allem auf die Einführung technischer Lösungen für das Wissensmanagement beziehen. Die Grundidee besteht darin, die zur Verfügung stehenden Programme und technischen Umsetzungsmöglichkeiten immer feiner zu filtern, um am Ende die richtige Software für den jeweiligen Einsatzzweck zu finden. Am Anfang der Auswahl steht die generelle Überlegung, welchen Mehrwert eine Softwarelösung für das Unternehmen bietet. In Ergäzung zum vorherigen Kapitel von Problemstellung, Bedarf, Ziele, stellt sich in typischen Projektmeetings die Frage: „Was wollen wir eigentlich?„.
So einfach die Frage scheint, so komplex kann ihre Beantwortung sein. Ist ein Ausgangspunkt gefunden, sollte ein Kriterienkatalog erstellt werden. Dieser ermöglicht eine Bewertung der unterschiedlichen Anforderungen (funktional, wie auch nicht-funktional), wodurch eine Vergleichbarkeit der verfügbaren Software erreicht wird. Im dritten Teil wird für bis zu drei der präferierten Kandidaten mit der höchsten Bewertung ein „Proof of Concept“ durchgeführt, d.h. eine technische und organisatorische Umsetzung, um die gewünschte Software im Detail testen zu können.

Prove of Value

Bevor die Umsetzung eines Wissensmanagementprojektes in Angriff genommen wird, sollte zunächst ein „Prove of Value“ (PoV) durchgeführt werden. Ziel des PoV ist es, den Nutzen für das Unternehmen zu identifizieren. Das heißt, die Frage zu beantworten, welchen Mehrwert die Methoden oder die Software eines Wissensmanagementsystems für das Unternehmen anhand konkreter Anwendungsfälle erwarten lassen.
Möglicherweise ergeben sich bereits an dieser Stelle verschiedene Fragen zum Nutzen, die möglichst früh beantwortet werden sollten, anstatt sie erst in späteren Prozessschritten zu betrachten. Dies können z.B. folgende Fragen sein:

  • Welchen Zeit- und Geldvorteil erlangen wir durch die Einführung eines WM-Systems?
  • Kann ein solches Projekt mit den Fähigkeiten unserer Mitarbeiter im vorgegebenen Zeitraum umgesetzt werden?
  • Ist es auf diesem Wege möglich die bisher mangelhafte Dokumentation zu vervollständigen oder zu verbessern?
  • Erlangen wir durch die verbesserte Erfassung und den Austausch von Wissen einen Wettbewerbsvorteil in einem bestimmten Bereich?
  • usw.

Kriterienkatalog und Bewertung

Proof of Value und Proof of Concept (PoC) werden gerne als ein gemeinsames Konstrukt behandelt. Betrachtet man den Prozess jedoch als eine immer feinere Filterung, um schließlich zum gewünschten System für den angestrebten Anwendungsfall zu gelangen, so sollten die zu analysierenden Softwarelösungen zunächst objektiv bewertet werden. In der Praxis ist dies nur bedingt möglich, da die Anforderungen zwar klar definiert sein können, die Interpretation des Erfüllungsgrades aber je nach Personenkreis sehr unterschiedlich ausfallen kann, da z.B. ein Teilnehmer bereits Erfahrung mit einem der Softwarekandidaten hat – oder ein anderer Teilnehmer die Funktionen für seinen Bereich als besonders vorteilhaft ansieht.
Um diese Verzerrung in der Bewertung abzumildern, sollten immer mehrere Personen aus unterschiedlichen Bereichen einbezogen werden, die auch unabhängig voneinander eine Bewertung zu den Kriterien abgeben. Die Erfahrung zeigt, dass es sinnvoll ist, hierfür separate Meetings/Termine zu vereinbaren. Nur so beeinflussen sich die Teilnehmer nicht gegenseitig und können ohne Zeitdruck Rückfragen stellen.
Dabei sollten nicht nur die Bewertungen getrennt voneinander erfolgen, sondern auch die Erstellung der Anforderungen. In der Praxis erweist sich dies jedoch als sehr schwierig, da die Anwender selten eine Vorstellung davon haben, was sie benötigen oder was die Software können muss. Dementsprechend entstehen die Anforderungen meist aus einer Mischung von Interviews, ersten Eindrücken der Fachverantwortlichen sowie des Managements, die im Nachhinein abgeglichen werden. Zusätzlich kann eine Unterteilung der Anforderungspunkte in folgende Bereiche pro Abteilung/Anwendungsgruppe hilfreich sein, um die gesammelten Informationen sinnvoll zu gruppieren:

  • Must-Haves= Dieses Kriterium ist zwingend zu erfüllen. Ist dies nicht der Fall, erfüllt die Software nicht den gewünschten Zweck.
  • Nice-To-Have = Es wäre hilfreich, wenn solche Funktionen vorhanden wären, sie sind jedoch nicht zwingend erforderlich.
  • Not Needed = Anforderungen mit dieser Markierung sind im jeweiligen Bereich nicht erforderlich. Achtung: Hier müssen die Aussagen der verschiedenen Abteilungen abgeglichen werden. Was für den einen irrelevant ist, kann für den anderen ganz wesentlich sein.

Was lässt sich daraus ableiten? Die Summe aller „Must-Have-Kriterien“ müssen von der Software erfüllt werden (Mindestanforderung), andernfalls ist eine Einführung nicht sinnvoll bzw. sollten Details hierzu nochmals diskutiert werden. Die „Nice-To-Haves“ erhöhen den Nutzen insgesamt und führen zu einer besseren Bewertung der Softwarelösung (s.u.). Der letzte Punkt erfüllt zwei Zwecke: Zum einen zeigt er den Bedarf für die jeweilige Anforderung (wenn alle Abteilungen keinen Bedarf sehen, kann kann die Anforderung gestrichen werden), zum anderen ist es so möglich zu priorisieren, welche Punkte zuerst umgesetzt werden, was gerade im Einführungsprojekt sehr wichtig ist. Eine Kriterienliste ist im entsprechenden Menüpunkt zu finden und kann als Anregung genutzt werden. Die konkreten Punkte sind natürlich auf den entsprechenden Anwendungsfall anzupassen.

Ist der Katalog erstellt, werden die jeweiligen Anforderungen anhand von Informationen aus Internetquellen, Herstellerinformationen, Produktpräsentationen, Videos, Forenbeiträgen, Telefonaten mit dem Hersteller, etc. bewertet. Dies kann durch ein Punktesystem oder durch ein Ampelsystem erfolgen. Dabei gilt: Je mehr grüne Ampelfelder eine Software erhält, desto positiver ist sie zu bewerten, wobei die „Must Haves“ die höchste Priorität haben müssen! Dieses Vorgehen kann zusätzlich durch eine Kommentarspalte ergänzt werden.
Im Ergebnis sind mindestens zwei, jedoch maximal fünf verschiedene Programme in den Teil des „Prove of Concept“ zu überführen. Alle anderen werden an diesem Punkt aus der Bewertung genommen, da sie entweder die Mindestanforderungen nicht erfüllen oder eine zu geringe Gesamtpunktzahl aufweisen.

Prove of Concept

Beim PoC geht es darum, die technische und/oder organisatorische Machbarkeit zu prüfen, die Anforderungen anhand einer konkreten Umsetzung zu bewerten und die kritischen Erfolgsfaktoren zu beleuchten. Wie der Name bereits verrät, geht es nicht um den Aufbau eines vollumfänglichen Systems oder der Abbildung vollständiger Unternehmensprozesse. Vielmehr wird in einem sehr kleinen Projekt überprüft, ob eine Umsetzbarkeit auf Basis der genannten Kriterien überhaupt möglich ist und welche Hürden sich hierbei zeigen.

  • Ist die Serversoftware der IT bspw. nicht kompatibel mit der zu installierenden Software?
  • Erfüllt diese überhaupt die Erwartungen an Bedienbarkeit und Performance?
  • Lassen sich die erwarteten Funktionen wiederfinden und das Programm intuitiv bedienen?
  • Welcher Schulungsaufwand ist tatsächlich nötig?
  • Wie muss ein Berechtigungskonzept aussehen?
  • usw.

Bereits mit einer sehr minimalistischen Struktur können viele Probleme frühzeitig erkannt werden. Darüber hinaus ergeben sich sehr gute Möglichkeiten, den Entscheidungsträgern Programme oder Abläufe im betrieblichen Umfeld zu zeigen, um sie zu überzeugen bzw. notwendige Änderungen abzustimmen. Dabei lohnt es sich, die Ergebnisse nicht nur schriftlich festzuhalten, sondern den Stakeholdern auch mit einer Demo oder einem Bildschirmvideo die Vor- und Nachteile der einzelnen Varianten aufzuzeigen.