In meinen Kundenprojekten nimmt die KI immer mehr Raum ein – auch im SAP Umfeld. Dabei zeigt sich, dass alle Parteien (inkl. SAP selber) noch am Lernen sind – insbesondere was sicherheitsrelevante und regulatorische Aspekte angeht (die Technik eilt da eher voraus).

Ein Kollege hat in einer Übersicht die Use Cases in Pattern/Muster geclustert und unterscheidet:

• Knowledge-Based Use Cases – Dem Anwender wird gezielt mittels KI Wissen angeboten und aufbereitet, z.B. aus der SAP Hilfe, Prozessdokumentationen, etc.
• Navigational Use Cases – Dem Anwender wird geholfen Funktionalitäten und Menüpunkte zu finden ohne dass die AI aktiv in die Geschäftsprozesse eingreift. Das geht schon stark in die Richtung KI als User Interface.
• Analytical Use Cases – KI gestützt werden Informationen aufbereitet und ausgegeben. Auch wenn die KI nicht direkt in die Geschäftsprozesse eingreift, kann dies außerhalb des Systems in Entscheidungen zum Tragen kommen. Eine Bewertung kann daher nur fallweise erfolgen.
• Transactional Use Cases – Die KI führt aktiv Transaktionen durch. Theoretisch könnte die KI damit auch gravierende Entscheidungen treffen. Dass ein Bot Menschen entlässt oder einstellt, halte ich allerdings eher für eine theoretische Variante. Viel mehr kommt hier das Thema Automatisierung zum Tragen: Wie ein Mensch kann die KI Käufe/Verkäufe/Zahlungen/etc. veranlassen, dummerweise halt nicht nur eine einzelne, sondern unzählige, bis der Vorgang überhaupt erst transparent wird und ggf. jemand eingreifen könnte. Eigentlich ist das Automatisierungsrisiko auch keine KI-Thematik, sondern ein Effizienz-Thema und die KI ist uns in Sachen Effizienz bei der Massenverarbeitung hoffnungslos überlegen.

Die ersten beiden Use Cases sind hingegen vergleichsweise trivial: Ihre Inhalte sind weitgehend öffentlich oder maximal für einen internen Gebrauch bestimmt und es gibt keine direkten Konsequenzen, die zu verfolgen wären.

Auf der Lösungsseite sind mir im SAP Umfeld bislang 3 technologische Ansätze untergekommen:

• SAP Joule – die SAP eigene KI, wobei man etwas aufpassen muss, weil SAP den Namen Joule marketingtechnisch etwas inflationär benutzt und schnell alles, was mit KI zu tun hat, auch mal als Joule betitelt
• Specific Capabilities – Während Joule weitgehend produktübergreifend konzipiert ist, entwickelt SAP auch spezifische KI-Lösungen für Ihre Produkte, z.B. für SAP Signavio oder andere. Dabei wird mitunter, wie auch bei Joule, die Business AI Foundation genutzt, sprich auch für spezifischere Anwendungsfälle kommen die gleichen LLMs zum Einsatz, die dann auch spezifische Modelle und Lösungen unterstützen.
• Individual AI Solutions – Mit SAP BTP hat die SAP entwicklungsseitig Tür und Tor geöffnet und findige Entwickler können im eigenen Programmcode natürlich auch beliebige KI Lösungen ansprechen. Der Tragweite kann durchaus immens sein und der SW-Entwicklung kommt plötzlich auch die Verantwortung für Auswahl, Konfiguration und Nutzung der KI-Modells zu. In diese Kategorie würden auch KI-Lösungen von 3rd-Party Anbietern fallen, auch wenn mir solche bislang noch nicht untergekommen sind, was aber sicher nur eine Frage der Zeit ist.

Unabhängig von der KI-Thematik gilt es zu berücksichtigen, dass Daten mitunter über Schnittstellen bis hin zu 3rd Parties, wie z.B. einem LLM-Anbieter gegeben werden. Wie weit dies in Abhängigkeit von der Kritikalität der Daten sinnvoll oder sogar zulässig ist, ist zu berücksichtigen.

Wie verteilen sich nun die Use Cases auf die Lösungsszenarien? Hier meine Interpretation (es mag Ausnahmen geben, aber die Tendenz scheint naheliegend):

SAP Joule dürfte die Knowledge-Based und Navigational Use Cases weitestgehend abdecken. Bei Analytical Use Cases bin ich mir noch nicht sicher , wie weit hier SAP Joule zum Einsatz kommen wird, auch wenn generisch die Ansätze vorhanden sein werden. Im analytischen und auch im transaktionalen Bereich werden aber produktspezifische Capabilities wie sie auch bei der SAP auf der Roadmap stehen eine gewichtige Rolle spielen. Individuelle Lösungen können als „Schweizer Taschenmesser“ oder für noch spezifischere Anwendungsfälle fungieren. Die Hemdsärmligkeit, wie wir sie auch aus der Entwicklung von KI-Tools in anderen Bereichen kennen steht hier im Widerspruch zu den gestiegenen Anforderungen und der Verantwortung bei Entwicklung und Einsatz.

Das bringt uns noch zu einem weiteren Aspekt: den Compliance-Anforderungen, z.B. aus dem EU AI Act (eine Zusammenfassung gibt es übrigens auch im schlossBlog) und unternehmenseigenen Anforderungen, z.B. aus dem Risikomanagement.

Jetzt stehen das Enterprise Risk Management und der EU AI Act zwar nicht im Widerspruch, aber die EU-Bürokraten haben bei ihrer Arbeit leider übersehen, dass der Risiko-Begriff längst auch anderweitig besetzt war und ist. Ihr Fokus auf Menschenrechte und hoheitliche Themen ist Ausdruck des Elfenbeinturms in dem sie sich bewegen. Nicht dass die Anforderungen per se falsch wären, aber es gibt eben auch noch andere Anforderungen und ich persönlich halte es nicht für zielführend für jede Technologie eigene Regelwerke zu erlassen, anstatt allgemeine Regelwerke auf ihre Tauglichkeit hin für neue Technologien zu prüfen, das hat schon zur EU-Leuchtmittelverordnung und zu EU-Staubsaugerverodnung geführt.

Auch wenn Unternehmensrisiken durchaus die Themen des AI Act aufgreifen sollten, ist der Schwerpunkt der Betrachtung doch ein anderer. Ich sehe hier vor allem zwei Themenfelder:

(1) KI-gestützte Entscheidungen (und nicht nur Personalentscheidungen wie im AI Act, sondern grundsätzlich auch die strategische Entscheidungsfindung, die im worst case existenzbedrohend für ein Unternehmen werden kann.)

(2) Das Automatisierungsdilemma. Die KI kann, wie wir Menschen, Fehler machen, nur kann sie diese auch exponentiell machen. Ich habe ja auch an anderer Stelle schon darauf hingewiesen, dass wir vielleicht eine eigene Fehlerkultur für die KI entwickeln müssen.

Spannend wird es, wenn wir nun die Enden dieses Beitrags zusammenführen:

Die meisten SAP Joule Anwendungsfälle (weil Knowledge-based und Navigational) sind aus Risikosicht (sowohl des AI Acts als auch des Enterprise Risk Managements) trivial. Die Tücke liegt aber im Detail und analytische und transaktionale Anwendungsfälle benötigen dann doch eine genauere Betrachtung. In einer Diskussion mit Vertretern der SAP habe ich den Kollegen die Frage gestellt, ob SAP Joule maximal low-risk Use Cases im Sinne des AI Acts abdeckt und high-risk Use Cases out of scope sind. Soweit wollte allerdings niemand gehen, auch wenn sich alle Fälle die wir aktuell diskutieren in diesem Bereich bewegen. Die Fragen, wie die Anforderungen für high-risk Use Cases (im Sinnes des AI Acts) seitens SAP abgedeckt werden, wurden aber eher mit einem Commitment als mit konkreten Aussagen beantwortet.

Bei den Specific Capabilities liegt eine fallweise Betrachtung auf der Hand. Zur Herausforderung könnten aber insbesondere Individual AI solutions werden. Anforderungen, wie Logging Capabilities, technische Dokumentation und Robustheit, wie sie der AI Act für high-risk Use Cases fordert machen auch aus Unternehmenssicht darüber hinaus Sinn, wenn man an das Thema Automatisierung denkt. Die Verantwortung der Entwickler steigt hier, mitunter ohne dass sie sich dessen bewusst sind.

Mein persönliches Verständnis von KI verändert sich derzeit. Der Begriff „Intelligenz“ erscheint mir zunehmend irreführend. Tatsächlich beginne ich, KI weniger als Form von Intelligenz, sondern vielmehr als  User Interface zu sehen – als eine Art, mit Systemen, Daten und Prozessen auf natürliche und adaptive Weise zu interagieren.

Seit Jahrzehnten ist das vorherrschende Paradigma in der Mensch-Computer-Interaktion die grafische Benutzeroberfläche (GUI) – Fenster, Symbole, Menüs und Zeiger. Doch mit der zunehmenden Leistungsfähigkeit von KI-Systemen treten wir in eine Ära ein, in der die KI selbst zur primären Schnittstelle wird.

Von Befehlen zu Gesprächen
Traditionelle Schnittstellen erfordern, dass der Benutzer die Sprache des Systems lernt: wohin er klicken muss, welche Befehle er eintippen muss, welche Abläufe er befolgen muss. KI kehrt dieses Prinzip um: Das System lernt unsere Sprache. Anstatt sich durch verschachtelte Menüs zu klicken, können wir unsere Absicht in natürlicher Sprache, über Bilder oder Gesten ausdrücken – und die KI interpretiert und setzt um.

Adaptiv und personalisiert
Eine KI-zentrierte Schnittstelle ist von Natur aus adaptiv. Sie kann sich Vorlieben merken, sich an den Kontext anpassen und sogar Bedürfnisse vorhersagen. Während GUIs statisch sind, kann KI völlig unterschiedliche Erlebnisse für verschiedene Nutzer bieten – ganz ohne manuelle Konfiguration.

Herausforderungen und Vertrauen
Der Wandel bringt Risiken mit sich. KI-gesteuerte Schnittstellen müssen transparent sein, um einen „Black Box“-Effekt zu vermeiden. Falsch interpretierte Nutzerabsichten können weitreichende Folgen haben. Gestaltung für Vertrauen, Nachvollziehbarkeit und klares Feedback wird entscheidend sein.

Die Zukunft ist hybrid
Anstatt GUIs vollständig zu ersetzen, wird KI zunehmend neben – oder unter – traditionellen Bedienelementen agieren. Man kann es sich als Doppelschicht vorstellen: Die GUI für Präzision, die KI für Geschwindigkeit und Flexibilität. Mit der Zeit könnte die KI-Ebene die Führung übernehmen, aber menschliche Aufsicht bleibt unerlässlich.

Mein persönlicher Weg zu dieser Schlussfolgerung wurde vor allem durch laufende Diskussionen über SAP Joule beeinflusst – SAPs Ansatz, KI in ihre Unternehmenslösungen zu integrieren. Joule nutzt KI als User Interface: Ein erster Aufruf an Sprachmodelle (LLMs) identifiziert die Capability hinter einer Benutzeranfrage. Daraufhin läuft ein konventioneller Verarbeitungsprozess innerhalb der bestehenden Landschaft (ohne KI). Das Ergebnis wird dann zurück durch die LLMs geleitet, die die Antwort in benutzerfreundliche Formate und Designs bringen.

Früher nutzten wir Websuchen, bei denen das Prinzip darin bestand, dass Algorithmen uns halfen, Webseiten zu finden, die mögliche Antworten auf unsere Fragen enthielten. Mit KI ist das anders: Wir suchen nicht – wir finden. Wir suchen nicht nach Webseiten, sondern wir finden Antworten. Das Dilemma dabei ist, dass die Quellen – und damit unsere Möglichkeit, die Zuverlässigkeit der Antworten zu beurteilen – in den Hintergrund treten. Das kann ein echtes Problem sein, ist uns in den meisten Fällen aber schlicht egal, denn wir sind froh, direkte Antworten zu bekommen, anstatt auch noch Quellen lesen und beurteilen zu müssen.

Natürlich ist der blinde Einsatz von KI bedenklich. KI kann halluzinieren, Fehler machen (weil sie in erster Linie auf Wahrscheinlichkeiten und nicht auf Logik beruht) und ist stark abhängig vom Trainingsmaterial. Es gibt ethische und rechtliche Bedenken, etwa zum Urheberrecht, und wir dürfen nicht vergessen, dass die meisten KI-Lösungen auch Webservices sind: Wir kommunizieren mit Drittanbietern und teilen unsere Informationen. Dabei stellt sich z. B. die Frage, ob die Modelle aus unseren Informationen lernen und ob andere davon profitieren können. Außerdem entstehen bei der Kommunikation zusätzliche Angriffsvektoren und Abhängigkeiten – besonders dann, wenn wir uns zunehmend auf KI verlassen und verlernen, Dinge selbst zu tun.

Zurück zu SAP und der Idee von KI als Benutzerschnittstelle: Der SAP GUI, wie wir ihn heute kennen, kann seine Wurzeln in Mainframe-Architekturen mit Transaktionscodes nicht verleugnen. Verschiedene Modernisierungsversuche sind nie vollständig ans Ziel gekommen, weil Power-User mit den „alten“ Transaktionscodes vertraut waren und damit schneller ans Ziel kamen. Ich bin gespannt, ob KI hier zum wirklich disruptiven Game Changer wird. Wir werden sehen.

Um ehrlich zu sein, ist es mir selbst ein Rätsel warum, aber das Testmanagement in IT-Projekten ist jetzt über Jahre dauerhaft der meistgefragteste Content auf schlossBlog.

Die Artikel für das Projektmagazin sind bereits aus dem Jahr 2009. Die Zusammenfassung gibt es auch als Präsentation:

Oder im Original beim Projektmagazin (Abodienst):
Teil 1: Ablauf und Organisation
Teil 2: Das Excel-Toolset

Heute frisch angereist zur PVM nach Hagen. Die PVM ist eine Fachtagung zweier Fachgruppen der Gesellschaft für Informatik (Vorgehensmodelle und Projektmanagement) in Kooperation mit der Fachgruppe IT-Projektmanagement der GPM e.V. und PMI Germany Chapter e.V..

Dieses Jahr geht es um nachhaltige IT-Projekte.

Morgen darf ich in einem Kompaktbriefing das Thema Ethik & Compliance in Projekten vorstellen. (Die Folien gibt es hier.)

Ethik und Compliance? Da war doch mal was… Ja, richtig dazu gibt es auch ein LinkedIn Learning Training von uns.

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.

Der ursprüngliche Post stammt aus dem Jahr 2017.

Noch beschäftigen sich alle mit Digitalisierung. Der Hype ist in vollem Gang, da stellt t3n in Heft 54 die Frage: Was kommt danach?
Klingt spannend – finde ich.

Wer heute sich auf die Digitalisierung konzentriert, verpasst der nicht schon den nächsten Trend und wird erst recht abgehängt?
Aber was heißt schon Digitalisierung?

Ist Digitalisierung überhaupt die richtige Fragestellung?
Müssen wir nicht unsere Modelle permanent in fragestellen um erfolgreich bleiben zu können?
Und das Thema Digitalisierung streift dabei nur den technologischen Aspekt.

Die schöpferische Zerstörung des guten, alten Schumpeter ist dabei doch wichtiger, oder?

Achja, zu meiner t3n-Weihnachtslektüre: Ich habe sie wieder weggelegt. Eine Mogelpackung, weil sie die Digitalisierung letztlich nur aufwärmt. Erste Spuren von dem, was danach kommt, konnte ich leider nicht entdecken.

Digitalisierung, Cloud und agile Vorgehensweisen sind Anzeichen einer sich verändernden IT in Unternehmen. Die einen versuchen sich an einem Paradigmenwechsel, die anderen wollen sich gar selbst abschaffen. Wenn das „Business“ IT-Leistungen von der Stange in der Cloud zusammenstellt und einkauft, braucht es dann überhaupt noch klassische IT in Unternehmen?

So etwas wie einen Application Manager braucht es dann künftig nicht mehr, entgegnete mir jüngst ein Kunde.

Aber das greift zu kurz.

Auch wenn klassische IT-Abteilungen Auflösungserscheinungen haben, wenn das Pendel gerade wieder von der zentralen IT zu dezentralen Lösungen im Business ausschlägt, sich Rollen und Aufgabenverteilungen ändern: Verantwortlichkeiten lösen sich nicht in Luft auf und müssen auch in der neuen Welt wahrgenommen werden. Außerdem müssen Kompetenz und Know-how erhalten bleiben.

Auch in der neuen Welt wird es jemanden geben, der die IT-Lösungen (aus der Cloud) konfiguriert und zusammenstellt – einen Architekten. Der ist künftig vielleicht wieder im Business und nicht mehr in der IT angesiedelt. Es wird zweifellos Veränderungen geben.  Er ist dann eher ein Service-Manager mit einem weniger technischen Profil, der Konfiguration und Einkauf vornimmt, aber letztlich behält er immer noch eine Gesamtverantwortung. Die lässt sich nicht delegieren. Der beste Cloudanbieter kann nicht wissen, wie wir sein Produkt einsetzen und wofür, mit welchen anderen Produkten, anderer Hersteller wir es kombinieren, wem wir Zugriffsrechte geben und welche Anforderungen wir haben.

Wenn wir IT-Abteilungen abschaffen, müssen wir dem Rechnung tragen, dass wir die neuen Rollen auch entsprechend befähigen. Auch ein Service-Manager im Business muss Sicherheitsanforderungen und Compliance sicherstellen. Die Cloudanbieter sind dabei seine Partner, aber verantwortlich bleibt er letztlich selbst. Die Welt wird nicht weniger komplex.

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.
 

Mein geschätzter Kollege Till sagt immer:“Jedes Problem beginnt mit einer Excel-Liste, dann wird eine Datenbank daraus und schließlich eine Applikation.“

Die Zwischenstadien „Schmierzettel“ und Sharepoint-Liste überspringt er gleich.

Vielleicht aus gutem Grund. Aktuell strapaziere ich Sharepoint, mit einem Access-Frontend, dass mehrere Sharepointlisten zusammenführt.

Und man glaubt gar nicht, wie schnell man an die Grenzen von Sharepoint stößt. Auch wenn eine SQL-Datenbank darunter liegt, so sind doch insbesondere dem Web-Frontend einige Einschränkungen geschuldet: So sollten es beispielsweise nicht mehr als 5000 Datensätze in einer Tabelle sein, mehrwertige Felder sind ganz BÖSE und Bulk-Jobs, also Massenbearbeitung, z.B. durch eine Aktualisierungsabfrage aus Access sollte nicht mehr als 100 Datensätze umfassen.

Auf diese und eine Reihe weiterer Einschränkungen verweist selbst Micsrosoft im Technet.

Warum wir trotzdem Sharepoint nutzen? Als Provisorium und zur Vorbereitung der späteren Applikation. Till hat doch Recht…

Bei dem ganzen Hype, der dem Thema Informationssicherheit in den letzten Jahren widerfahren ist, darf man eines nicht vergessen: Informationssicherheit ist kein Selbstzweck, sie dient lediglich zur Sicherstellung des eigentlichen Geschäftszweckes/des eigentlichen Auftrags. Demnach gilt: Business first!

Beim Thema Informationssicherheit darf es nicht um die Befriedigung aus Normen abgeleiteter Anforderungen gehen, sondern es ist stets eine Abwägung aus Business Sicht. Dies gilt insbesondere, da es eine 100%-Sicherheit nicht gibt, insofern ist Informationssicherheit immer auch ein Risikomanagement-Prozess.

Bei einem großen Rollout-Projekt zur Implementierung eines IT-Security-Prozesses im IT Service-Management, mussten wir lernen, dass wir die Kollegen immer wieder überfordert haben. Zum Einen ging die eben erwähnte Business-Perspektive in den Köpfen immer wieder verloren, zum Anderen verloren die Kollegen bei der Vielzahl der Security Requirements schnell den Überblick und haben den Wald vor lauter Bäumen nicht mehr gesehen. Da wurden dann technische Betriebs-Details  formal mit dem Provider geklärt, anstatt sich grundsätzlich mit der Frage auseinander zu setzen, was (im konkreten Fall) eine Cloud-Lösung überhaupt ist und ob man die eigenen Daten wirklich in fremde Hände geben möchte. Natürlich braucht es auch dedizierte Anforderungen, aber ohne ein entsprechendes Mindset wurde die Bearbeitung schnell zum sinnentleerten Papiertiger.

Vor diesem Hintergrund habe ich eine Reihe von Guiding Questions formuliert, um die Kollegen wieder „abzuholen“. Natürlich gilt als oberster Grundsatz die Orientierung am Geschäftszweck (1), dann ist ein generelles Lösungsverständnis erforderlich (2) um überhaupt die klassischen Dimensionen der Informationssicherheit bearbeiten zu können (3-5). Zur Visualisierung habe ich mich des IT Security Canvas bedient:

(1) Business first!

(2) Lösung & Architektur
Um ein allgemeines Verständnis unserer Lösung zu entwickeln:

• Wie sieht das generelle Design/die Architektur der Lösung aus?
• Gibt es Schnittstellen zu anderen Systemen?
• Wo sind diese Systeme räumlich angesiedelt?
• Wo werden Daten gespeichert, verarbeitet oder transportiert?
• Welche Parteien sind involviert (Benutzer, Administratoren, Dienstleister,…)?
• Gibt es ein IT-Service-Management?

(3) Vertraulichkeit / Confidentiality
Wenn Vertraulichkeit von besonderer Relevanz für unsere Lösung ist:

• Welche Personengruppen und Systeme sind beteiligt bzw. haben Zugriff?
• Deckt die Zugriffskontrolle all diese ab?
• Werden Verschlüsselungstechniken eingesetzt? Bei der Speicherung? Bei der Übertragung?

(4) Integrität / Integrity
Wenn Integrität von besonderer Relevanz für unsere Lösung ist:

• Wie kann ein Integrationsverlust bemerkt werden?
• Gibt es Optionen zur Wiederherstellung?
• Werden unterstützende Features wie Plausibilisierungen, Verschlüsselung, Backups, etc. genutzt?

(5) Verfügbarkeit / Availability
Wenn die Verfügbarkeit von besonderer Relevanz für unsere Lösung ist:

• Ist unsere Lösung in einem IT Disaster Recovery und/oder in einem Business Continuity Management zu berücksichtigen?
• Decken Disaster Recovery und Business Continuity Pläne alle beteiligten Systeme und Parteien ab?