In diesem Blogbeitrag werde ich ein paar kleine (aber feine) Konfigurationstipps rund um in-STEP BLUE geben. Ein zweiter Teil ist für die nähere Zukunft auch schon auf dem Weg. Dieses Mal soll es bei meinem Beitrag also nicht um komplexe Problemstellungen gehen, sondern um vergleichsweise einfach zu konfigurierende, aber nicht weniger hilfreiche Aufgabenstellungen.
1.1 Wissensmanagement – mal meins, mal unsers
Wissen zu sammeln war und ist sehr wichtig und führt zu den unterschiedlichsten individuellen Lösungen. Einig sind wir uns mit Sicherheit, dass der klassische Schmierzettel, die Papierkladde oder Ähnliches ausgedient haben. Und doch werden sich jetzt einige ertappt fühlen. Papier ist eben immer noch schnell greifbar und kreative Ideen, die vom Gehirn über die Hand auf das Papier fließen sind immer noch sehr effektiv (siehe Literatur zur „Hand-Hirn-Kopplung“ oder frage ChatGPT).
Aber aus den Ideen, Visionen, Plänen, etc. entsteht echtes, oft firmeninternes Wissen, das es gilt, digital festzuhalten und im besten Fall auch teilbar zu machen. Und hier kommt für mich in-STEP BLUE ins Spiel. Ausgangspunkt könnte ein individuelles Projekt sein zum Managen eigener, persönlicher Themen, es könnte aber auch ein Team-Projekt sein oder ein Wissensmanagement eines (Kunden-) Projektes. Auch wenn in-STEP BLUE kein klassisches WIKI-System ist, so kann man doch Wissen erfassen, klassifizieren und verknüpfen. In bekannter Weise kann ein Wissensformular gebaut werden, dass Text inkl. Bilder, Referenzen, WEB-Links, Metadaten, Schlagworte, etc. verwalten kann.
Das könnte z.B. so aussehen:
Das Konfigurieren ist dabei kein Hexenwerk und wurde von mir schon in einem früheren Blog (Wissensmanagement mit in-STEP BLUE) beschrieben, auch wenn das oben gezeigte Beispiel aus einem anderen Projekt stammt.
In diesem kleinen Tipp soll es darum gehen, das Wissen entweder nur im kleinen Kreis oder für alle verfügbar bereitzustellen. In meinem Beispiel gibt es ein Sonderprojekt mit ein paar Spezialisten, vielleicht ein strategisches Entwicklungsprojekt mit einer Geheimhaltungsstufe. Diese Spezialisten sammeln Projektwissen in einem oben gezeigten Wissensmanagement innerhalb des Projektprozesses. Das gesammelte Wissen ist aber von anderen in-STEP BLUE Usern nicht einsehbar. Aber was ist, wenn einzelne Einträge über das Projekt hinaus wertvolles Wissen für die gesamte Organisation enthalten? Das Erste, was einem einfällt, ist alle Mitarbeitende der Organisation ohne Rechte im Projekt aufzunehmen und dann gezielt Rechte zuzuweisen, wenn ein Eintrag veröffentlicht werden soll. Veröffentlicht? Da war doch was: Auf dem Rechteregister gibt es die Boolesche Option „Öffentlich lesbares Produkt“.
Ist hier die Option gesetzt und gibt es eine Sicht, die z.B. alle „öffentlich lesbaren Produkte“ anzeigt, steht das Wissen allen Mitarbeitenden zur Verfügung, selbst wenn sie nicht Mitglied in diesem Projekt sind. Doch ist es für viele Anwender zu umständlich, in die Eigenschaften zu wechseln und die Option zu setzen. Zum Glück gibt es seit kurzem in in-STEP BLUE einen neuen Zustandsübergang: „Lesbarkeit setzen“. Sollte dieser Übergang noch nicht zur Verfügung stehen, muss dieser noch über die Komponenten registriert werden (gehört zur StdExtension.dll).
Es gibt nun verschiedene, elegante Lösungsansätze. Der einfachste Weg ist es, zwei Übergänge zu definieren: „Eintrag veröffentlichen“ setzt auf „True“ (=gesetzt) und „Eintrag privat setzen“ setzt auf „False“ (=aufgehoben). Um den jeweiligen Zustand transparent zu zeigen, könnte auch der Zustand von „Aktuell“ auf „Veröffentlicht“ wechseln und umgekehrt.
Noch eleganter ist es, wenn im Formular und/oder der Sicht eine zu definierende Boolesche Option „Eintrag veröffentlichen“ zur Verfügung steht und die Standardübergänge „Eigenschaften geändert“ und „Produkt zurückgeben“ die Eigenschaft abfragen und dann, je nach gesetzter Eigenschaft, die Lesbarkeit setzen. Mit dieser Lösung muss der Anwender nur einen Klick machen.
Dazu definiert man zuerst eine Boolesche Eigenschaft, z.B. „Wissen veröffentlichen“ und ein Ereignis im dazugehörigen Zustandsautomaten. Alle Ereignisse, die nicht direkt sichtbar sein sollen, sondern durch eine weitere Aktion angesprochen werden, werden bei mir mit „(Automatisch)“ ergänzt:
Dieser versteckte Übergang wird jetzt durch die Übergänge „Eigenschaften geändert“ und „Produkt zurückgeben“ benachrichtigt (an das auslösende Produkt):
Danach müssen zwei Übergänge definiert werden, einmal für den Zustand „Wahr“ und einmal „Falsch“ der Booleschen Eigenschaft.
Ist die Boolesche Option „Wahr“, wird als Aktion die Lesbarkeit gesetzt und umgekehrt.
Mit diesem Trick kann jetzt mit einem Mausklick im Formular oder in der angepassten Sicht die öffentliche Sichtbarkeit aktiviert oder deaktiviert werden.
1.2 Produktabhängigkeitshierarchie als Standardsicht
Ein klassischer Anwendungsfall bei uns: Ein projektrelevantes Dokument, das in einem zentralen Projekt liegt (z.B. „Validierung“), wird in ein Kundenprojekt referenziert (z.B. ein Validierungsantrag). Über die Funktion „Bearbeiter benachrichtigen“ sendet ein Projektverantwortlicher einen Arbeitsauftrag an einen Mitarbeitenden. Wenn dieser über den Link in das Projekt springt, landet er entweder im Projekt, in dem das Dokument liegt („Validierung“) oder zwar im richtigen Kundenprojekt in der richtigen Sicht, aber am obersten Knoten.
Dialog „Produkt öffnen“
Variante 1: In in-STEP BLUE mit Standardansicht anzeigen: Dokument wird im Projekt angezeigt, in dem es tatsächlich liegt (Beispiel hier: „Validierung“)
Variante 2: In in-STEP BLUE mit vorgegebener Sicht anzeigen: Das Kundenprojekt wird geöffnet, die Produktabhängigkeitshierarchie wird geöffnet, aber es wird nur der oberste Knoten selektiert und nicht zum referenzierten Dokument gesprungen.
Beide Varianten führen zu einem Akzeptanzproblem. Entweder wird das Dokument gefunden aber nicht in der gewünschten Projektumgebung des Kundenauftrages, oder man springt in das Kundenprojekt, findet aber die Datei nicht. Zum Glück kann man seit kurzem mit wenigen Konfigurationsschritten hier Abhilfe schaffen.
Nachdem in die Sicht „Vorlagen“ gewechselt wurde, wählt man im ersten Schritt einen geeigneten Ort aus, an dem der Unterordner „_INDEX“ angelegt wird:
In Schritt zwei wird in diesem Unterordner eine leere txt-Datei mit der neuen Kategorie „VIEW INDEX FILE” erstellt:
Im dritten Schritt muss die Indexdatei mit der gewünschten Sicht verknüpft werden. Im Kontextmenü der Datei findet man dazu den Befehl „Konfigurieren“.
In dem Dialog, den man über die drei Punkte rechts im Konfigurationsfenster öffnet, werden mögliche Sichten vom Typ „Produktabhängigkeitshierarchie“ angezeigt. Die gewünschte Sicht auswählen und bestätigen. Nach diesem Schritt hat man einiges erreicht. Mit jeder Aktualisierung der Sicht über F5 (bzw. das Aktualisierungs-Icon) oder durch die Funktion „Bearbeiter benachrichtigen“ wird eine neue Index-Datei geschrieben. Dabei werden historische Versionen der Indexdatei nicht behalten, um Speicherplatz zu sparen.
Der Index wird mit allen Produkten, die in der konfigurierten Sicht zu sehen sind, geschrieben. Das bedeutet, dass alle definierten oder alle beliebigen Produktreferenzen, die vorhanden sind, gespeichert werden.
Mit dem Schritt vier wird der Taskmanager konfiguriert. Dadurch wird die Indexdatei automatisch und regelmäßig aktualisiert. Dazu muss die Task-Verwaltung aufgerufen werden:
Dort ist der Task „Index für eine Sicht aktualisieren“ aufzurufen.
Die zuvor konfigurierte Indexdatei ist über den Dialog auszuwählen und es kann eine passende Bezeichnung vergeben werden.
Nun ist noch festzulegen, in welchem Intervall, z.B. stündlich, in-STEP BLUE die Indexdatei neu schreiben soll.
Als letzten Schritt kann diese Sicht über das Sichtenmenü zur Standardsicht für Produkte gemacht werden.
Fazit
Was nehmen wir mit? in-STEP BLUE zeigt einmal mehr, dass es nicht immer die große Architekturänderung braucht, um spürbaren Mehrwert zu schaffen. Oft sind es die kleinen aber feinen Tipps, die im Alltag den Unterschied machen. Ein Klick genügt, um Wissen projektübergreifend verfügbar zu machen, sicher gesteuert und sauber nachvollziehbar. Die Produktabhängigkeitshierarchie als Standardsicht sorgt zusätzlich dafür, dass Nutzer genau dort landen, wo sie arbeiten sollen: im richtigen Projekt, am richtigen Produkt.
Falls hilfreich, kann nun auch für bestimmte Produkte der GoTo-Befehl auf diese Sicht gelenkt werden. Sie kennen den GoTo-Befehl noch nicht? Dann freuen Sie sich schon auf meinen nächsten Blogbeitrag „Kleine, aber feine Tipps – Teil 2“.