Ziel der Tool-Auswahl ist es, die Richtlinienmanagement-Software zu finden, die auf die eigene Organisation und Situation am besten passt. Wichtige Voraussetzung dafür ist, dass Sie als Verantwortlicher für die Auswahl die Rahmenbedingungen und Anforderungen der eigenen Organisation erhoben und verstanden haben. Mit der folgenden Liste können Sie die Anforderungen bei den Ansprechpartnern in Ihrer Organisation strukturiert abfragen.

Anhand von typischen Anwendungsfällen leiten wir die Anforderungen an eine Software für das Management von Richtlinien her und erläutern sie. Jedoch werden nicht alle diese Anforderungen für Ihre Organisation gleichermaßen relevant sein. Wir zeigen daher die grundsätzlichen Möglichkeiten auf und Sie entscheiden, was davon für Sie wichtig ist. Bitte beachten Sie: Technisch sind viele Dinge möglich. Aber mit den technischen Möglichkeiten wächst auch die Komplexität und damit steigen in der Regel auch die Aufwände zur Einrichtung, zur Integration und zum Betrieb eines solchen Systems. Die Herausforderung für Sie besteht darin, dass Sie Ihre aktuellen Anforderungen abdecken, auch ein bisschen visionär in Zukunft schauen – und trotzdem auf dem Boden bleiben und ein pragmatisches System definieren. Sie möchten vor allem ein Richtlinienmanagement einführen, nicht Betreiber eines großen und komplexen IT-Systems werden.

Die Ergebnisse fließen in wichtige Vorüberlegungen ein und sind Grundlage für die Kriterienkataloge, mit denen später die Anbieter verglichen werden.

1 Richtlinien-Management-Software

1.1 Anforderungen an die Funktionalität

1.1.1 Den Anwendungsbereich (Scope) festlegen

Am Anfang sollten Sie überlegen, in welchem Kontext das Richtlinienmanagement stehen soll. Es gibt Bereiche, in denen ein solches System perfekt alleine existieren kann. Beispielsweise ein geschlossenes Themenfeld mit einem hohen Aufkommen an Regelungen, die man damit steuern möchte. Oft sind Richtlinien aber Bestandteil eines Management-Systems oder können es zukünftig werden. Beispiele sind das Interne Kontrollsystem (IKS) oder das Information Security Management System (ISMS). Deshalb sollten Sie prüfen, ob der Aufbau einer Software für Richtlinienmanagement nicht eher in einem solchen größeren Kontext erfolgen sollte, bei dem im System auch ein IKS, ISMS usw. abgebildet werden kann.

1.1.2 Konventionen definieren

Welche Typen soll es geben?

Anweisung, Prozessbeschreibung, Checkliste, …

Aufbau und Vorlagen

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.

Soll es eine Nummerierung geben?

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.

Versionsbezeichnung

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.

Einstufung der Vertraulichkeit

In Unternehmen sind oft schon Vertraulichkeitsstufen definiert und die Anwendung sollte diese Stufen abbilden können. Beispiele: Firmenintern, Vertraulich, Streng vertraulich.

Kennzeichnung von Änderungen

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.

Identifikation von einzelnen Anweisungen

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.

Konventionen zur Sprache

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

Konventionen zur Terminologie

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

Zu den im vorherigen Kapitel genannten Punkten kommen noch hinzu:

Medium

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.

Import bestehender Dokumente

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.

Kategorisierung

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.

Berechtigungen

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.

Gültigkeit bzw. Wiedervorlage

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.

Richtlinien übersetzen bzw. lokalisieren

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

Richtlinien freigeben

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

Technische Bereitstellung

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.

Navigation

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.

Suche

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.

Benachrichtigung über neue oder geänderte Inhalte

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.

Lesebestätigung

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.

Kommentieren bzw. Feedback geben

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

Richtlinien ändern

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

Richtlinien außer Kraft setzen

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

Welche Besonderheiten gibt es in Ihrer Organisation, die in einem Richtlinien-Management-Tool vermutlich berücksichtigt werden müssen bzw. schwierig werden könnten.

Gibt es spezielle Organisationsstrukturen, die abgebildet werden müssen?

Gibt es Unterorganisationen, deren Daten getrennt geführt werden müssen?

Gibt es spezielle Prozesse und Abläufe?

Wie stark getrennt müssen die Dokumente dieser Unterorganisationen sein?

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)

Gibt es Fälle, in denen Unterorganisationen mit eigentlich getrennten Dokumentenbeständen ihre Dokumente doch gegenseitig sehen können sollen?

Zum Beispiel bei übergreifenden Vorhaben oder bei gemeinsam betriebenen Systemen.

Sind Gesellschaften aus Ländern mit grundsätzlichen anderen Rechtssystemen einzubeziehen, deren Dokumente strikt abzutrennen sind? (z.B. China)

1.3 Mengengerüste

1.3.1 Anzahl der Benutzer

Die Zahl der Benutzer ist häufig relevant für die Berechnung der Lizenz der Tools und für die Dimensionierung der Infrastruktur.

Wieviele Nutzer sollen grundsätzlich mit dem System arbeiten können? (named user)

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.

Lassen sich die Benutzer nach Nutzungsintensität gruppieren?

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.

Wieviele Nutzer sollen gleichzeitig mit dem System arbeiten können? (concurrent user)

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.

Wie werden sich diese Zahlen in den kommenden Jahren voraussichtlich verändern?

Könnten sich diese Zahlen durch anstehende organisatorische Umstrukturierungen verändern?

1.3.2 Daten

Die Datenmengen helfen bei der Abschätzung der notwendigen Speicherkapazitäten.

Mit welchen Datenmengen ist bei den Stammdaten zu rechnen?
z.B. Anzahl der Organisationseinheiten

Mit welchen Datenmengen ist bei den Dokumenten zu rechnen?
z.B. Anzahl der Assets

Wieviele Dokumente kommen regelmäßig hinzu? (z.B. monatlich oder jährlich)

Mit welchen Mengen ist zukünftig durch organisatorische Veränderungen zu rechnen? (z.B. durch Übernahme von anderen Unternehmen)

1.4 Schnittstellen

1.4.1 Fachliche Schnittstellen

Aus welchen anderen Systemen soll die Anwendung fachliche Daten beziehen?

z.B. bestehende Dokumenten-Management-Systeme

An welche anderen Systeme soll die Anwendung fachliche Daten übergeben?

1.4.2 Technische Schnittstellen

Soll es eine Anbindung an ein Benutzerverwaltung (LDAP, Active Directory) geben?

Soll es eine technische Anbindung für die Benutzer-Anmeldung geben?

z.B. SSO über Kerberos, Authentifizierung gegen LDAP

Soll ein Monitoring-System angeschlossen werden, um den Systemzustand zu überwachen?

Welche Mail-Systeme sollen angebunden werden?

Die Systeme verschicken Mails, um Nutzer über anstehende Aufgaben und Termine zu benachrichtigen

2 Allgemeine Anforderungen

2.1 Gesetzliche und regulatorische Rahmenbedingungen

Welchen speziellen gesetzlichen Vorschriften unterliegt das Unternehmen bzw. die Organisation, die bei der Einführung eines Systems für Richtlinienmanagement bzw. einer Software allgemein relevant sind? Welche Anforderungen ergeben sich daraus?

Beispiele:
- BaFin BAIT / KAIT / VAIT
- IT-Sicherheitsgesetz
- Datenschutzgrundverordnung mit besonderen Kategorien von Daten
- Sozialgesetzbücher

Ist die Software mitbestimmungspflichtig?

2.2 Anforderungen des IT-Betriebs

Was wird bevorzugt: On-premises-Installation oder Cloud?

2.2.1 On-premises / Installation im eigenen Rechenzentrum:

Welche IT-Plattformen stehen im eigenen Rechenzentrum bzw. auf den Clients zur Verfügung und müssen von der Software unterstützt werden? (Datenbanken, Server, Browser usw.)

Was sind weitere Lieferpflichten für einen internen Betrieb? (z.B. Betriebshandbuch)

2.2.2 Cloud / Software-as-a-Service (SaaS)

Welche Anforderungen muss ein Cloud-Anbieter erfüllen?
z.B. Zertifizierung nach ISO 27001

2.3 Datensicherheit und Informationsschutz

Welche Anforderungen an die Datensicherheit sind zu erfüllen, damit kritische Informationen nicht an Externe wie Wettbewerber, Akteure anderer Staaten, Kriminelle usw. abfließen können?

Dürfen die Dokumentenbestände (z.B. vertrauliche Dokumente) bei einem externen Anbieter liegen?

Gibt es Ausschluss-Kriterien, z.B. keine Anbieter aus den USA bzw. die dem Patriot-Act unterliegen?

2.4 Datenschutz

Welche Anforderungen an den Schutz personenbezogener Daten sind zu erfüllen?

Dürfen personenbezogene Daten des Unternehmens bzw. der Organisation im Cloud-System eines externen Anbieters gespeichert werden?

2.5 Ausfallsicherheit und Wiederherstellung

Wie soll die Verfügbarkeit des Systems sein?

Welche Verfügbarkeit des Tools sollte das eigene Rechenzentrum bzw. der SaaS-Anbieter gewährleisten?

Recovery Time Objective (RTO): Wie lange darf das System im Fall eines Notfalls ausfallen?

Recovery Point Objective (RPO): Wieviel Datenverlust kann in einem Notfall in Kauf genommen werden?

2.6 Barrierefreiheit

Barrierefreiheit ermöglicht Menschen mit Behinderungen die Nutzung des Systems.

Welche Anforderungen bestehen innerhalb Ihrer Organisation an Software im Hinblick auf Barrierefreiheit?

3 Weitere Überlegungen

Gibt es andere Bereiche im Unternehmen bzw. in der Organisation, die eine solche Software bereits im Einsatz haben könnten?

Fragen:
- Kann eine bestehende Instanz mitgenutzt werden?
- Erfahrungsaustausch?

Für welche Bereiche wäre die Nutzung einer solchen Software ebenfalls interessant?

Mit welchen Veränderungen in der Organisation ist zukünftig zu rechnen? Zum Beispiel Zukäufe/M&A, Zusammenlegung mit anderen Organisationen, Abspaltungen.

Lesen Sie weiter ...

Anforderungskatalog für die Auswahl eines Richtlinienmanagement-Tools

Marktübersicht: Standardsoftware für Richtlinienmanagement

Auswahl einer Software für Richtlinien-Management - Startseite