„Wissen heißt wissen, wo es geschrieben steht“ ist ein Zitat von Albert Einstein, zumindest wenn man dem „World Wide Web“ Glauben schenken darf. Dieser schier unendliche Topf hält viel nützliches aber auch scheinbar unbegrenzt viel unnützes Wissen parat. Die Kunst ist nun, das benötigte Wissen auch zu finden und für den eigenen Anwendungsfall aufzubereiten. Was aber, wenn der eigene Anwendungsfall so spezifisch ist, dass maximal Puzzleteile im Internet zu finden sind? Oder wenn zu befürchten ist, dass Wissen vom Autor im Internet wieder entfernt wird?
In diesen Fällen macht es Sinn, sich ein eigenes Wissensmanagement aufzubauen. Da ist es für mich naheliegend, so ein Wissensmanagement in in-STEP BLUE zu konfigurieren. Dafür habe ich mir folgende Anforderungen definiert:
- Neben dem eigentlichen Wissenseintrag müssen Felder für Internetreferenzen, Schlagwörter und interne Dokumente vorhanden sein.
- Über den Zustand kann ich die Gültigkeit des Wissenseintrag anzeigen: „In Bearbeitung“, „aktuell“ oder „überholt“.
- Es muss ein Rechtemanagement geben, mit dem einzelne Wissenseinträge anderen Mitarbeitern lesend oder auch schreibend zur Verfügung gestellt werden können
- Es muss ein Kommentarfeld geben, das auch beschreibbar ist, wenn der Wissenseintrag „aktuell“ und schreibgeschützt ist.
- Ein Eintrag muss kategorisierbar sein, z.B. „in-STEP BLUE, Oracle, Windows Server, Client, Excel,….“, wobei mehrere Begriffe auswählbar sein müssen.
Aller Anfang ist (nicht) schwer
Es wäre an dieser Stelle etwas übertrieben über das Ei-Huhn Problem zu philosophieren, aber klar ist, vor dem digitalen Wissensmanagement benötige ich mein neuronales. Im Grunde ist der Aufbau in in-STEP BLUE nicht schwierig, nur ein paar kleine Kniffe sind notwendig, um alle Anforderungen oben zu erfüllen.
Als ersten Schritt definiere ich mir einen neuen Produkttypen und einen Ablageordner, definiere die notwendigen Eigenschaften in einer passenden Kategorie, baue das Formular und konfiguriere einen Zustandsautomaten. Zum Abschluss baue ich dann noch eine passende Sicht und dann kann es auch schon losgehen mit dem Sammeln von Wissen.
Wo soll mein Wissen hin?
Es kann sinnvoll sein, für das Wissensmanagement ein eigenes in-STEP BLUE Projekt zu erstellen, z. B. wenn geplant ist, es für mehr als ein paar Personen oder Themenbereiche zu benutzen. In meinem Fall geht es „nur“ um Wissen rund um meine eigene Arbeit. Es ist also interessant für mich und meine fachliche Vertretung. Deshalb genügt es, das Wissensmanagement in ein existierendes Projekt (in-STEP Management) zu integrieren. Für ein eigenes Projekt wäre der erste Schritt, ein leeres Projekt anzulegen, nicht benötigte Elemente zu löschen und dann loszulegen (wie das geht, wird in diesem Beitrag beschrieben).
Um einen neuen Produkttyp für ein Formular definieren zu können, wird zuerst eine neue Kategorie benötigt, in der ich die gewünschten Eigenschaften definieren kann. Selbst wenn ich alle Eigenschaften später direkt in der Kategorie PRODUCTREVISION definieren möchte, brauche ich eine eigene Kategorie unter „IN-STEP DOCUMENT“. In diesem Fall nenne ich sie „WISSENSMANAGEMENT“
Nun definiere ich meine Eigenschaften. Dabei sind – wie immer beim Arbeiten mit in-STEP BLUE – der Fantasie keine Grenzen gesetzt. Die Definition ist nur abhängig von den eigenen Anforderungen. Das Schöne ist, dass mit wachsenden Anforderungen das Wissensmanagement angepasst werden kann.
Zumindest benötige ich aber ein Feld für den eigentlichen Text (alphanumerisch, formatierbar), ein Feld für Schlagworte (alphanumerisch, Kardinalität 1..*), ein Feld für die Kategorie (Aufzählung, Kardinalität 1..*, Teil meiner Anforderung und gefüllt mit passenden Einträgen), ein Feld für Internetlinks (URL, Kardinalität 1..*), ein Feld für Kommentare, auch wenn der Eintrag schon freigegeben ist (alphanumerisch, Kardinalität 1..*) und Eigenschaften für die Rechtevergabe (Mitarbeiter, Kardinalität 1..*). Letzteres habe ich direkt unter PRODUCTREVISION angelegt, da ich diese Eigenschaften auch an anderer Stelle benötige.
Jetzt kann ich meinen Produkttypen anlegen:
Den Zustandsautomat habe ich vorher schon als leeren Dummy angelegt. Er wird etwas später noch mit Leben gefüllt.
Es muss auch gut aussehen
Es wird Zeit, das Wissensformular zu bauen. Ich persönlich mag diese kreative Phase am meisten. Auch hier gilt es, das Formular so zu bauen, wie es für den eigenen Anwendungsfall am geeignetsten erscheint. Anpassungen und Erweiterungen sind auch später jederzeit möglich und wirken sich dann auch auf alle schon geschriebenen Wissenseinträge aus.
So könnte ein Formular im Designer aussehen:
Schauen wir uns ein paar Details an:
Das Feld „Beschreibung“ wird nur im Zustand „in Bearbeitung“ aktiviert, in jedem anderen Zustand kann das Feld nicht bearbeitet werden (das entspricht einer weiter oben genannten Anforderung), in jedem Fall ist es ein Pflichtfeld:
Das Feld „Support-Eskalationslevel“ (ComboBox) soll nur dann aktiviert werden, wenn das Formular in Bearbeitung ist und wenn die Boolesche Option „Support“ wahr ist. Dann wird es aber auch gleich zu einem Pflichtfeld:
Ebenfalls können „Thema“ und „Kategorie“ auch nur im Zustand „in Bearbeitung“ verändert werden.
Die unteren Felder auf den Registern sind von dieser Einschränkung ausgenommen. Die Felder sind in jedem Zustand aktiv. Hier gelten nur noch mögliche Einschränkungen des Zustandsautomaten (auch das ist eine Anforderung).
Zuletzt fehlt noch das Rechtemanagement. Dafür habe ich diese zwei Felder definiert:
Was wäre noch sinnvoll? Schreiben Sie es gerne unten in den Kommentar. Ich freue mich über tolle Ideen!
Auch Wissen benötigt einen Zustand
Für meine Bedürfnisse kann Wissen „in Bearbeitung“ sein, es kann „aktuell“ sein und es kann „überholt“ sein. Das sieht dann so aus:
Es ist erkennbar, dass auch im Zustand „aktuell“ das Produkt prinzipiell bearbeitbar ist. Das bedeutet, dass das Formular die Bearbeitbarkeit im jeweiligen Zustand steuert, was weiter oben gezeigt wird. Aufpassen muss man aber nun beim Erstellen der Sichten (das zeige ich weiter unten). Das Editieren der Felder in den Sichten muss unterbunden sein, denn dort greifen nur die Regeln des Zustandsautomaten, nicht aber der Formularfelddefinitionen.
Für die Übergänge habe ich drei neue Ereignisse definiert:
Für Wissensmanagement-Projekte mit vielen Zugriffen und Autoren ist es außerdem ratsam, Artikel vor dem „aktuell“ setzen noch zum Review vorzulegen. Für diesen Fall werden ein weiterer Zustand (Review) und ein Übergang (zum Review vorlegen) benötigt. Zusätzlich wird eine Mitarbeiter-Eigenschaft „Reviewer“ benötigt. Die Rechtevergabe würde ich in diesem Fall über die Beteiligungsarten regulieren, d. h. einem eingeteilten Reviewer wird die Beteiligungsart „Review“ gegeben und nur damit kann im Zustand „Review“ editiert werden.
Der wichtigste Übergang ist „Produkt zurückgeben“, denn als Aktion werden hier die Rechte vergeben oder entzogen:
Die anderen Zustandsübergangsaktionen sind einfach gehalten. Mit der jeweiligen Bedingung, die richtige Rolle zu haben (hier ist individuell z. B. ein Wissensmanager als Rolle o. Ä. zu definieren), werden nur Rechte verwaltet und Beteiligungsarten gesetzt.
Auch hier gilt: Es gibt viele Freiheiten im Rahmen der eigenen Anforderungen.
Ein gelebter Wissenseintrag könnte so aussehen:
Die Sichten des Wissens
Eine Sicht zu definieren ist Ihnen mit Sicherheit geläufig, zeigen möchte ich ein Beispiel dennoch. Wichtig ist, dass – obwohl es ein Komfortverlust ist – nicht in Sichten editiert werden kann, denn die Rechtesteuerung wird in diesem Beispiel maßgeblich durch das Formular gesteuert.
Auch eine Produktabhängigkeitssicht kann hilfreich sein, wenn über eine definierte Eigenschaft Wissenseinträge verknüpft werden:
Und zu guter Letzt
Wenn der Wunsch besteht, dass Wissen auch mal in Papierform vorliegen muss, dann hinterlegt man eine Word-Vorlage und definiert diese wie gewohnt:
Und das Ergebnis könnte dann so aussehen:
Fazit
Ein Wissensmanagement ist in in-STEP BLUE schnell gebaut. In meinem gezeigten Beispiel ist der Mehrwert nur für mich als Systemadministrator und meine Vertretung gegeben. In einem größeren Umfeld entsteht ganz schnell ein Mehrwert, wenn ich die Wissenseinträge z. B. auch mit Projektdokumenten verknüpfen kann. So kann ich z. B. Kundenanforderungen, Normen, Lessons Learned etc. mit Wissenseinträgen referenzieren und zusammenführen.
Haben Sie weitere gute Ideen und Erfahrungen passend zu diesem Thema? Senden Sie uns gern eine Mail.