1 Richtlinien-Management-Software
1.1 Anforderungen an die Funktionalität
1.1.1 Den Anwendungsbereich (Scope) festlegen
1.1.2 Konventionen definieren
Anweisung, Prozessbeschreibung, Checkliste, …
Wie sollen die verschiedenen Typen von Richtlinien grundsätzlich strukturiert sein? Metainformationen, Einleitung, Definition von Begriffen, Anweisungen … Für diese Strukturen sollten sich im System Vorlagen (Templates) hinterlegen lassen, das reduziert die Aufwände bei der Erstellung. Solche Vorlagen sollten auch die Berechtigungen vorgeben, die für das Dokument in seiner jeweiligen Ausprägung gelten sollen.
Eine Nummer hilft bei der eindeutigen Identifizierung einer Richtlinie, ohne dass man immer den vollständigen Titel nennen muss, der u.U. lang sein kann.
Man kann in eine Nummer auch eine leichte Semantik bringen. Grundsätzlich würde ich aber nicht zu viel Bedeutung reinpacken, insbesondere nicht in Unternehmen der freien Wirtschaft. Denn zum Erfolg am Markt gehört die permanente Anpassung des Angebots und der Unternehmensstrukturen an die Erfordernisse des Marktes und der Kunden. Und damit sind wiederholte organisatorische Veränderungen heute eher der Normalfall. Wurde dann zu viel Bedeutung in die Nummerierung gepackt, kann diese bald von den tatsächlichen Gegebenheiten im Unternehmen abweichen.
Mit Änderungen im Unternehmen werden auch Richtlinien angepasst werden müssen. Damit entstehen verschiedene Versionen eines Dokuments, die sich eindeutig identifizieren lassen sollten. Das kann zum Beispiel erfolgen durch …
- das Datum der Veröffentlichung z.B. 07.10.2019
- eine fortlaufende Versionsnummer z.B. 1, 2, 3, …
- semantische Versionierung mit Unterscheidung von wesentlichen Änderungen (vor dem Punkt hochzählen) und unwesentlichen Änderungen (nach dem Punkt), z.B. 3.2
Auch hier raten wir zur einfachsten Variante. Insbesondere sollte man im Normalfall *nicht* semantisch versionieren, da die Unterscheidung zwischen wesentlichen und unwesentlichen Änderungen in der Praxis oft schwierig ist, wenn es nicht gerade um die Korrektur von Rechtschreibfehlern geht.
In Unternehmen sind oft schon Vertraulichkeitsstufen definiert und die Anwendung sollte diese Stufen abbilden können. Beispiele: Firmenintern, Vertraulich, Streng vertraulich.
Anwender brauchen bei einer neuen Version Hinweise darauf, was sich gegenüber der vorherigen Version geändert hat. Andernfalls besteht die Gefahr, dass sie wichtige Punkte übersehen, wenn sie die das Dokument grundsätzlich schon kennen und deshalb neue Versionen nur noch überfliegen. Das kann beispielsweise wie die Änderungsverfolgung in MS Word geschehen, wobei das in anderen Systemen technisch schwierig zu realisieren ist und bei komplexen Änderungen auch schnell unübersichtlich werden kann. Eine Alternative ist die Kennzeichnung der geänderten Passagen am Rand mit einem Balken. Oft reicht aber auch schon ein textueller Hinweis auf die geänderten Stellen.
Neben der Kennzeichnung einer Richtlinie an sich kann es sinnvoll sein, auch die einzelnen Anweisungen innerhalb der Richtlinie identifizierbar zu machen. Beispielsweise durch eine laufende Nummer. Wobei das Verfahren dann so aufgebaut sein sollte, dass man später einzelne Anweisungen einfügen oder löschen kann, ohne dass sich die Nummerierung aller anderen Anweisungen verschiebt.
Die Ausdrucksmöglichkeiten unserer Sprache sind extrem vielfältig, damit besteht aber auch das Risiko von Mehrdeutigkeiten und Fehlinterpretationen. Dem kann man begegnen, indem man die Sprache an wichtigen Stellen formalisiert. Ein Beispiel dafür ist die Nutzung der Begriffe Muss/Soll/Kann, um unterschiedliche Grade der Verbindlichkeit bzw. des Ermessens auszudrücken, siehe https://de.wikipedia.org/wiki/Muss-,_Soll-_und_Kann-Vorschrift
Ebenfalls um Einheitlichkeit und Eindeutigkeit in der Sprache zu erzielen sollte es im jeweiligen Kontext ein Verzeichnis von wichtigen Begriffen und ihrer Nutzung geben. Damit zum Beispiel eine Planungsanwendung nicht einmal als „Budgetplanung“ bezeichnet wird, während sie das nächste Mal nur als „Planning“ angesprochen wird und dann wieder als „Budget Planning“. Je nach Anwendungsfall können in einem solchen Terminologie-Verzeichnis definiert werden: Standorte, Organisationseinheiten, Rollen, IT-Anwendungen, Geschäftsprozesse usw.
1.1.3 Richtlinien erstellen und veröffentlichen
In welchem technischen System sollen Richtlinien erstellt werden? Hier gibt es unterschiedliche Möglichkeiten:
Die Inhalte werden direkt im Richtlinienmanagement-System erstellt
Genau dafür wird doch ein Richtlinienmanagement-System beschafft, oder? Kommt darauf an, nämlich auf die Anforderungen, die man an Formatierung, das Einbindung von Bildern usw. stellt – und ob das System diese Möglichkeiten bietet. Denn die in solche Systeme integrierten Editoren haben meistens einen bedeutend geringeren Funktionsumfang als beispielsweise MS Word. Das trifft besonders auf web-basierte Anwendungen zu. Trotzdem können sie für Erstellung und Pflege einfacher Inhalte genutzt werden, wie es häufig für stark textorientierte Inhalte ausreicht.
Inhalte in einer Textverarbeitung erstellen und im System als Anhang führen
Aber wozu brauche ich dann noch die Richtlinien-Verwaltung? Die wird genutzt, um eine strukturierte Ablage zu bekommen, um die Abläufe wie Wiedervorlage zu führen und um Richtlinien in andere Teilsysteme einzubinden wie z.B. in das Interne Kontrollsystem oder in ein Information Security Management System.
Einbindung per Link
Liegen Richtlinien bereits in einem anderen System wie einem Enterprise Content Management System oder MS Sharepoint vor, so sollten sie sich über einen Link referenzieren lassen.
Sofern Richtlinien bereits in einem anderen System geführt werden und komplett in das neue System überführt werden sollen, sollten die Möglichkeiten eines Imports geprüft werden. Wenn es sich um eine einmalige Übernahme handelt, reicht auch eine projektorientierte Lösung. Eine einfache Möglichkeit zur Übernahme ist Copy&Paste der Inhalte. Abhängig von den beteiligten Systemen kann es dabei jedoch zum Verlust von Formatierungen und anderen Elementen kommen, wodurch Nacharbeit notwendig werden kann.
Neben der Suche ist die Zuordnung zu Kategorien eine wichtige Methode, um Dokumente auffindbar zu machen. Die Kategoriestruktur sollte eine Tiefe und Granularität haben, die häufige Anwendungsfälle abbildet und zur Anzahl der Dokumente bzw. Richtlinien passt. 1000 Dokumente in einer Unterkategorie sind vermutlich zu viel, während mehrere Unterkategorien mit nur jeweils einem Dokument genauso wenig hilfreich sind und das Auffinden eher behindern.
Kategoriestrukturen leiten sich häufig aus dem Thema oder dem zugrunde liegenden Standard ab. Oft kann auch die Möglichkeit zur Mehrfachkategorisierung nützlich sein.
Es gibt zahlreiche Inhalte, die nicht für jedermann im Unternehmen einsehbar sein sollten. Das sind beispielsweise alle Richtlinien, die sich mit Risiken und Bedrohungen befassen, die für den Geschäftsbetrieb oder sogar für den Fortbestand des Unternehmens von Bedeutung sein können. Wettbewerber oder Kriminelle könnten daraus wichtige Informationen gewinnen und Schwachpunkte identifizieren, die ihnen helfen könnten, wirksamer gegen das Unternehmen vorzugehen. Daher sollten die Dokumente sinnvoll berechtigt werden können. Im Idealfall ist eine Berechtigungsstruktur bereits in Vorlagen definiert, die zur Erstellung von neuen Richtlinien genutzt werden können, so dass man sich als Ersteller nicht jedes Mal neu Gedanken darüber machen muss.
Eine wichtige Funktion eines Richtlinien-Managementsystems ist die Sicherstellung der Gültigkeit der Dokumente bzw. deren rechtzeitige Wiedervorlage zur Überprüfung. Das System sollte also die Möglichkeit bieten, solche Informationen für jedes Dokument zu definieren und zu überwachen. Bei Erreichen des Datums erhält der Bearbeiter einen entsprechenden Hinweis, z.B. in Form einer Mail.
In international tätigen Unternehmen müssen Richtlinien häufig in mehrere Sprachen übersetzt und an landesspezifische Gegebenheiten angepasst (lokalisiert) werden. Eine Software für Richtlinienmanagement kann diese Tätigkeiten unterstützen durch …
- Sprach- bzw. länderspezifische Vorlagen
- Übersetzungsworkflows
- mehrsprachiges Terminologieverzeichnis
- Anbindung von Werkzeugen zur maschinellen Übersetzung, z.B. DeepL, Google Translate oder Microsoft Translator
Eine Richtlinie kann für ein Unternehmen eine große praktische und auch rechtliche Bedeutung haben. Daher müssen Vollständigkeit und Korrektheit sichergestellt sein. Das wird in der Regel dadurch erreicht, dass eine Richtlinie nach Erstellung oder Änderung von einer weiteren Person bzw. Rolle überprüft werden muss, um sie dann von einer dazu befugten Rolle freizugeben bzw. gültig zu machen.
Abhängig vom Typ der Richtlinie, von Organisationseinheit, Thema, Sprache, Land, Vertraulichkeitsgrad, usw. kann eine Überprüfung und Freigabe durch höchst unterschiedliche Personen bzw. Rollen notwendig werden. Das System sollte das unterstützen, in dem sich flexibel Review- und Freigabe-Workflows definieren lassen, die den Prozess über die verschiedenen Rollen steuern und dokumentieren.
1.1.4 Richtlinien bereitstellen und nutzen
Nach der Freigabe soll eine Richtlinie für die Anwender an einer definierten Stelle abrufbar sein. Das kann ein Portal innerhalb des zu schaffenden Richtlinien-Management-Systems sein. Der Einstieg kann aber auch über ein bereits vorhandenes Portal erfolgen, sofern eine Integration technisch möglich und sinnvoll ist.
Die bei der Erstellung der Dokumente hinterlegte Kategoriezuordnung sollte auch für die Nutzer verfügbar sein. Damit wird das Durchstöbern eines Themengebiets möglich, um sich beispielsweise einen Überblick über die vorhandenen Richtlinien zu verschaffen.
Für das zielgerichtetes Auffinden von Dokumenten zu einem bestimmten Stichwort sollte das System eine Suchfunktion bieten. Die die Inhalte der Richtlinien werden dabei im Volltext erfasst und indiziert. Nach Eingabe eines oder mehrerer Suchbegriffe werden alle Dokumente aufgelistet, die diese Begriffe enthalten. Die Suche sollte eine Gewichtung beinhalten, um Inhalte mit höherer Relevanz weiter vorne aufzulisten.
Um eine gute Informationsversorgung sicherzustellen, sollten Nutzer die Möglichkeit haben, Themengebiete oder Kategorien zu abonnieren. Werden dann neue Inhalte eingestellt oder bestehende Inhalte verändert, so werden sie per Mail benachrichtigt.
In manchen Prozessen oder Management-Systemen kann es notwendig sein, dass Nutzer eine Richtlinie auf jeden Fall Kenntnis nehmen und diese Kenntnisnahme bestätigen, so dass jederzeit belegbar ist, dass die Inhalte dem Nutzer bekannt sein müssen. Sofern dies gefordert ist, sollte das vom System unterstützt werden. Der Herausgeber der Richtlinie muss dann den Nutzerkreis festlegen, der zur Kenntnisnahme verpflichtet ist. Diese Nutzer bekommen dann die Aufforderung, das Lesen zu bestätigen. Kommt ein Nutzer innerhalb einer definierten Zeit dem nicht nach, so wird er daran erinnert oder dieser Umstand wird an seinen Vorgesetzten eskaliert. Umgekehrt hat der Herausgeber der Richtlinie eine Übersicht, welche Nutzer das Lesen wann bestätigt haben bzw. welche Bestätigungen noch ausstehen.
Für eine größtmögliche Akzeptanz bei den Nutzern sollten Richtlinien aktuell und sehr nahe an den tatsächlichen Gegebenheiten im Unternehmen sein. Das können die Nutzer am besten selbst einschätzen und deshalb sollte es im System eine Möglichkeit geben, Richtlinien zu kommentieren bzw. Feedback an den Herausgeber zu schicken. Der Herausgeber kann bei einer Überarbeitung diese Rückmeldungen lesen und ggf. berücksichtigen.
1.1.5 Richtlinien ändern und außer Kraft setzen
Da Richtlinien weitgehende Auswirkungen im und für das Unternehmen haben können, sollten Änderungen immer auf eine kontrollierte und nachvollziehbare Weise erfolgen. Dazu gehören:
- Kennzeichnung der Version in den Metainformationen
- Markierung von Änderungen im Dokument
- Erneute Freigabe vor der Veröffentlichung
- Archivierung der Vorversion
- Vergleich zweier Versionen
Aufgrund der hohen Bedeutung ist es auch nach der Außerkraftsetzung einer Richtlinie häufig notwendig, zu dokumentieren, dass es diese Richtlinie gab, nachvollziehbar zu machen von wann bis wann sie Gültigkeit hatte usw. Daher sollten nicht mehr benötigte Richtlinien nicht einfach gelöscht sondern im System archiviert werden, so dass bei Bedarf wieder auf sie zugegriffen werden kann.
1.2 Besonderheiten in der Organisation
Ist die Trennung über ein Kennzeichen in der Datenbank ausreichend oder müssen sie in getrennten Datenbanken gehalten werden? (z.B. nach regulatorischen Vorgaben oder aus Sicherheitsgründen)
Zum Beispiel bei übergreifenden Vorhaben oder bei gemeinsam betriebenen Systemen.
1.3 Mengengerüste
1.3.1 Anzahl der Benutzer
Einige Lizenz- und Nutzungsmodelle basieren auf "named user", d.h. die Höhe der zu entrichtenden Lizenz bzw. Nutzungsgebühr berechnet sich u.a. aus der Anzahl der Benutzer, die grundsätzlich zur Nutzung freigegeben sind.
Das können beispielsweise sein: Power User, die das System durchgängig nutzen und täglich viele Arbeitsschritte durchführen. Im Unterschied zu Gelegenheitsnutzern, die nur manchmal mit dem System arbeiten müssen und dann nur wenige Arbeitsschritte absolvieren müssen.
Diese Zahlen sind für die Abschätzung der maximal gleichzeitig mit dem System arbeitenden Nutzer hilfreich. Beispiel: 5 Power User, die täglich und fortdauernd mit dem System arbeiten; 30 Gelegenheitsnutzer, die sich ca. einmal pro Woche für ca. 20 Minuten anmelden. Das System bzw. die Lizenz muss dann nicht auf 35 gleichzeitige Nutzer ausgelegt werden, sondern es kann auf einem geringeren Wert basieren, da wahrscheinlich niemals alle 30 Gelegenheitsnutzer gleichzeitig auf das System wollen.
Einige Lizenz- und Nutzungsmodelle basieren auf "concurrent user", d.h. die Höhe der zu entrichtenden Lizenz bzw. Nutzungsgebühr berechnet sich u.a. aus der Anzahl der Benutzer, die gleichzeitig mit dem System arbeiten können.
Außerdem muss die Infrastruktur entsprechend ausgelegt werden: Je mehr Nutzer gleichzeitig auf dem System sind, desto leistungsfähiger müssen Server, Datenbank usw. ausgelegt werden, um gute Antwortzeiten zu gewährleisten.
Hierbei ist zu beachten, dass es unterschiedliche Situationen geben kann. Neben dem Normalbetrieb ist ggf. mit Spitzen zu rechnen, z.B. vor anstehenden Audits.
In die Abschätzung sollten ggf. unterschiedliche Nutzungsintensitäten einbezogen werden. Im Beispiel oben könnte gerechnet werden: 5 Power User + 3 Gelegenheitsnutzer = 8 Nutzer, die gleichzeitig mit dem System arbeiten können.
1.3.2 Daten
z.B. Anzahl der Organisationseinheiten
z.B. Anzahl der Assets
1.4 Schnittstellen
1.4.1 Fachliche Schnittstellen
z.B. bestehende Dokumenten-Management-Systeme
1.4.2 Technische Schnittstellen
z.B. SSO über Kerberos, Authentifizierung gegen LDAP
Die Systeme verschicken Mails, um Nutzer über anstehende Aufgaben und Termine zu benachrichtigen
2 Allgemeine Anforderungen
2.1 Gesetzliche und regulatorische Rahmenbedingungen
Beispiele:
- BaFin BAIT / KAIT / VAIT
- IT-Sicherheitsgesetz
- Datenschutzgrundverordnung mit besonderen Kategorien von Daten
- Sozialgesetzbücher
2.2 Anforderungen des IT-Betriebs
2.2.1 On-premises / Installation im eigenen Rechenzentrum:
2.2.2 Cloud / Software-as-a-Service (SaaS)
z.B. Zertifizierung nach ISO 27001
2.3 Datensicherheit und Informationsschutz
2.4 Datenschutz
2.5 Ausfallsicherheit und Wiederherstellung
2.6 Barrierefreiheit
3 Weitere Überlegungen
Fragen:
- Kann eine bestehende Instanz mitgenutzt werden?
- Erfahrungsaustausch?