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.

Alexander Siedschlag, Rosemarie Stangl, Katastrophenmanagement: Eine wissenschaftliche Einführung, Hamburg 2020, ISBN-13: 9783347179301 (Amazon)

Statt noch ein Buch über Risikomanagement oder Projektmanagement zu lesen, ist es manchmal wesentlich anregender in ein benachbartes Regal zu greifen, statt erneut in der eigenen Blase zu bleiben und sich gegenseitig selbst zu bestätigen. Das „Katastrophenmanagement“ entstammt der Sicherheitsforschung und versteht sich als eine wissenschaftliche Einführung, steht also in einem Nachbarregal und nicht im PM-Sumpf.

Ja, es ist ein akademisches Buch und die Ländervergleiche und politischen Betrachtungen haben mich jetzt weniger interessiert, aber das ist ja vollkommen ok, weil nicht mein Anspruch. Die grundlegenden Schulen und Analysemethoden, Katastrophenkommunikation und das Resilienzkonzept hingegen schon.

Wir kennen klassische Risikobetrachtungen die mathematisch das Produkt aus Eintrittswahrscheinlichkeit (Likelihood) und den verbunden Auswirkungen (Impact) bilden. Das Disaster Risk Model zeigt, dass man sich auch mit anderen Ansätzen mit der Risikothematik befassen kann:

Jetzt ist so ein Venn-Diagramm, dass die Schnittmenge aus Gefährdung, Exponiertheit und Verletzlichkeit betrachtet nicht so einfach modellierbar wie ein mathematisches Produkt, zeigt aber, dass es sich darüber nachzudenken lohnt, ob es nicht noch andere Faktoren gibt, die wir in die Risikobetrachtung einbeziehen sollten und warum – zum Teufel – müssen diese Faktoren multiplikativ verknüpft sein? Weil es einfach ist?

Ich muss gestehen, dass es noch ein weiteres Motiv für die Lektüre gab: Neugier, denn Alex Siedschlag kenne ich schon aus Schulzeiten. wir haben gemeinsam Abitur gemacht, waren gemeinsam bei der Bundeswehr und haben uns lose im Auge behalten. Insofern war eine solche Einführung auch der willkommene Anlass in sein Metier zu schnuppern. Alex ist heute Professor für Homeland Security an der Penn State University. Zugegebenermaßen musste ich schmunzeln, als ich bei der Beschreibung des Szenariotrichters dann eine Abbildung gefunden habe, die ich vor langer Zeit mal für einen Wikipedia-Artikel gebaut habe (siehe Foto oben) – selbstverständlich ordentlich zitiert, auch wenn die Wikipedia in wissenschaftlichen Kreisen ja eher verpönt ist, aber meine Grafik hat es immerhin in das „Katastrophenmanagement“ geschafft. Die inhaltlichen Belegstellen sind selbstverständlich wissenschaftlicher Natur, aber die Darstellung wurde übernommen.

Für mich wertvolle Inputs waren u.a. die Unterscheidung von Krise und Katastrophe, das Sieben-Phasen-Modell nach Chapmann oder die Impact-Zonen nach Tiryakian. Psychologische Aspekte und systemische Betrachtungen bis hin zum Resilienzkonzept hatten naturgemäß eine hohe Überschneidung zu meinem persönlichen Hintergrund (habe doch Organisationspsychologie (im Nebenfach) durchaus studiert).

Das Buch hält was es verspricht und – ja – es hat auch schon kritische Bezüge zu COVID-19:

„In diesem Zusammenhang wird wiederum deutlich, dass COVID-19 im Bereich des planerisch durchaus vorstellbaren und Antizipiertem lag. Aus sozialwissenschaftlicher Sicht besteht die katastrophale Qualität dieser Pandemie eben auch darin, dass über Jahrzehnte hinweg verfolgte Risikomanagementstrategien entweder nicht (mehr) Praxis bereit waren, nicht kohärent angewandt wurden oder nicht wie vorgesehen griffen (…).“

Diese inhaltliche Aktualität ist bemerkenswert. An anderer Stelle habe ich sie allerdings vermisst: Die Rolle von Blogs und Web 2.0 in der Gefahrenkommunikation ist überholt. An ihre Stelle ist längst Social Media getreten, schneller als die zitierte Fachliteratur nachziehen konnte. Alles in allem aber nur eine Kleinigkeit, die den Gesamteindruck nicht schmälert.

Zahlen haben fast schon eine „magische“ Wirkung auf uns. Wir schenken ihnen Vertrauen und sie liefern uns exakte Aussagen.

Schön wäre es, denn im Detail liegen ein paar Tücken: Messen bzw. zeigen die Zahlen tatsächlich das, was sie vermeintlich vorgeben zu zeigen? Und mit welcher Zuverlässigkeit und Genauigkeit tun sie es?

Die Krux mathematischer Modelle und Berechnungen liegt darin, dass sie uns Ergebnisse mit Nachkommastellen liefern. Das aber ist lediglich eine Scheingenauigkeit, denn das Ergebnis kann nicht besser sein als das zugrundeliegende Modell. Wie sehr uns das überfordert, zeigt der aktuelle Umgang mit den Covid Statistiken. Von uns Laien werden Zahlen vogelwild interpretiert ohne das wir wirklich wissen, was sie aussagen, ohne das wir statistische Effekte aus Erfassung und Verarbeitung, wie z.B. durch die Änderung der Teststrategie oder das Meldeverhalten, berücksichtigen.

Wir sind in guter Gesellschaft. Seit langem bemängelt  Gerd Gigerenzer (Amazon), dass die meisten Mediziner, medizinische Wahrscheinlichkeitsaussagen nicht interpretieren können. Wie soll das dann bei Covid anders sein?

Oder im Risikomanagement?

Die bekannteste Quantifizierung eines Risikos ergibt sich aus der versicherungmathematischen Formel als Produkt von Eintritswahrscheinlichkeit und potentiellem Schaden, dem sogenannten Erwartungwert.

Aber welche Aussagekraft hat der Erwartungswert?

Nun statistisch gesehen, ist das der durchschnittlich zu erwartende Schaden. Aber nutzt uns das was? Das ist in etwas wie die durchschnittliche Fiebertemperatur aller Krankenhauspatienten. Nehmen wir einmal an, ein Unternehmen würde aufgrund eines solchen Modells finanzielle Rückstellungen in Höhe des Erwartungswerts treffen. Bei Risiken die digital eintreten, d.h. sie treten entweder ein oder sie treten nicht ein, stecken wir in dem Dilemma, dass wir im einen Fall zu niedrige und im anderen Fall zu hohe Rückstellungen getroffen haben. Worst case ist beides existenzbedrohend, z.B. im Falles des Eintretens eines „schwarzen Schwans“ (Amazon Affilitate Link), also eines äußerst unwahrscheinlichen Ereignisses – z.B. einer Covid-Pandemie….

Weil heute Thanksgiving ist: Kennt Ihr den Truthahn Irrtum?

Unter dem Truthahn Irrtum versteht man nach Nassim Taleb die irrige Annahme des Truthahns, nachdem ihn der Der Farmer 364 Tage gefüttert hat, er wäre sein Freund. Das war am Tag vor Thanksgiving.

Die Geschichte zeigt, dass uns Erkenntnisgewinn nicht immer weiter hilft. Zumindest hat es dem Truthahn nichts genutzt.

Compliance, die Einhaltung rechtlicher und eigener verbindlicher Vorgaben und Richtlinien, scheint doch so einfach, tja wären doch unsere Regelungen widerspruchsfrei und aufeinander abgestimmt.

Und dann leben wir auch noch in einer globalisierten Welt, wo wir dann auch noch die Compliance in den verschiedenen betroffenen Rechtsräumen brauchen – ich meine jetzt nicht unterschiedliche Fachgebiete, sondern geografisch einzelne Länder mit ihren eigenen Rechtssystemen. Welcher Rechtsraum ist für unseren konkreten Geschäftsvorfall relevant? Bzw. welche Rechtsräume sind relevant? Die direkt betroffenen? Also wenn wir einen deutsch-ägyptischen Geschäftsfall anschauen: deutsches Recht und ägyptisches Recht? Was ist mit der Transitstrecke? Oh Mist, US-Recht beansprucht für sich weltweite Gültigkeit, verpflichtet „US-Persons“ und das sind nicht nur US-Staatsbürger, sondern beispielsweise auch Greencard-Inhaber oder Geschäftsreisende, die sich in USA aufhalten, und nimmt sie in die Pflicht. Wenn auch noch US-Technologie davon betroffen ist, weil die verwendeten Schrauben auf einer US-Drehbank gefertigt wurden, dann mal viel Spaß. Und wir haben noch nicht geschaut, ob nicht auch das nordkoreanisches Recht Anforderungen an unseren konkreten Vorgang richtet. Dessen Relevanz haben wir womöglich gedanklich ausgeblendet. Ein Abwägungsprozess – nicht Compliance.

Einen weiteren Abwägungsprozess liefert uns die Verhältnismässigkeit der Mittel. Denken wir an Informationssicherheit und fehlerfreie Programmierung. Mit absolutem Anspruch vollkommen unsinnige Zielsetzungen, weil wer 100%-ige IT-Sicherheit verspricht oder fehlerfreie Programme von der Materie keine Ahnung hat oder ein Blender ist. Ob wir wollen oder nicht kommen wir um Abwägung und einen Risiko-basierten Ansatz nicht herum. Wir müssen ein sinnvolles Sicherheitsniveau definieren und verfolgen. Und auch hier wieder bewusst abwägen.

Die Abwägung unterhöhlt elementare Grundprinzipien beispielsweise im Datenschutz, wo sich selbst staatliche Hüter der Domäne, die sonst alle Betroffenen mit aller Härte in Ihre Schranken verweisen, z.B. gegenüber Lobbyisten der Versicherungswirtschaft in die Knie gehen, selbst wenn es um die Auswertung besonderer personenbezogenen Daten geht.

Compliance ist zweifellos ein weites Feld. Ein schwammiges noch dazu.

Wenn wir mit Compliance-Anforderungen konfrontiert sind, ist die Definition geeigneter Prozesse unsere einzige Chance Transparenz in die Abläufe und Abwägungen  zu bringen und Verantwortung wahr zu nehmen.

Ein echtes Dilemma.

Das Compliance-Dilemma.

Beitrag #701 auf schlossBlog

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?

Für die zweite Ausgabe des ProjektSMag hat Tim Dettmer u.a. mich gefragt, was ich tun würde wenn ein Risiko mit hoher Tragweite eintritt. Hier meine Antwort:

• (1) Orientieren – Meine „Lieblingswerkzeuge sind hierbei der MindManager und visuelle Hilfsmittel wie der openPM-Canvas (den ich auch selber mitentwickelt habe).
• (2) Kommunizieren & Transparenz – Kommunikation ist der Erfolgsfaktor in Projekten schlechthin. Ohne Kommunikation gibt es keine Transparenz. Die Kommunikation muss dabei konstruktiv, also lösungsorientiert sein. Schuldzuweisungen, Fingerpointing, etc. sind gerade in Krisenzeiten zwar beliebt, aber kontraproduktiv
• (3) Verbindliches Handeln – Ich brauche nicht die x-te Revision eines Projektplans, oft reicht schon eine einfache Aufgabenliste mit klaren Verantwortlichkeiten, die dann aber auch verbindlich umgesetzt und verfolgt wird.

Im aktuellen RiskNet-Newsletter ist ein Interview mit dem Neurowisenschaftler Prof. Dr. Bernd Weber und dem Beraterkollegen Axel Esser erschienen mit der Aufforderung sich im Risikomanagement nicht auf Intuition zu verlassen.

Hierzu entscheidend Bernd Weber:

Einerseits gibt es aus der Gehirnforschung die Aussage, analytisch-logische Verfahren sind hilfreich bei einfachen Entscheidungen und bei komplexen Entscheidungen ist Intuition besser. Das trifft so wohl auch für die alltäglichen Entscheidungen zu, die wir treffen müssen. Das ist allerdings anders, wenn es um unternehmerische oder finanzielle Entscheidungen unter Risiko geht. Da sollten wir uns lieber nicht auf Heuristiken oder Intuition verlassen. Intuition basiert auf der Fähigkeit der Mustererkennung im Gehirn, das heißt einer automatischen Abwägung von „gelernten Wahrscheinlichkeiten“. Das bedingt ein Umfeld, das hinreichend regelmäßig ist, um vorhersagbar zu sein und viele Gelegenheiten, diese Regelmäßigkeit durch langjährige Erfahrung zu bestätigen.

Diese Einstufung von Intuition erscheint mit plausibel und realistisch, aber was die komplexen unternehmerischen und finanziellen Entscheidungen angeht fehlt dieser Realismus gegenüber den dort nach Meinung von Weber und Esser anzuwendenden Methoden. Es ist wichtig die Grenzen der angewandten Methodik zu kennen. Was die Intuition angeht bin ich ganz bei den beiden, vermisse aber die relativierende Einschätzung anderer Methoden.

Wir leiden an einer Methodengläubigkeit ohne deren Grenzen zu thematisieren. Unsere Modelle sind logischerweise vereinfachend und unvollständig. Von der Intuition wissen wir, dass sie nicht perfekt ist, aber an Methoden klammern wir uns fest.

Wenn wir nicht hinreichend „gelernte Wahrscheinlichkeiten“ haben, können wir dann überhaupt die Zuverlässigkeit jedweder Methode beurteilen?

Nun, wir tun es wohl trotzdem. Ohne Kritikbewusstsein, Ein selbstkritisches intuitives Vorgehen  ist mir da lieber, wohlwissend dass die permanete Hinterfragung der Intuition keine leichte Hürde ist.

Compliance war schon das eine oder andere mal Thema auf schlossBlog, insbesondere Compliance-Themen vor dem Hintergrund von IT-Offshoring und Outsourcing:

• #285 Compliance bei Cloud Computing, Outsourcing & Offshoring
  
• #320 Schizophrenie Datenschutz
• #338 Compliance – Status Quo
• #390 Juristische Fallstricke in Cloud, IT-Outsourcing und –Offshoring
• #400 Compliance in Cloud, IT-Outsourcing und –Offshoring
• #423 Compliance Management Architecture
• #454 Die Cloud, Compliance und Rechtssicherheit
• #505 Compliance vs. Risikomanagement
• #506 Compliance vs. Risikomanagement II

Der nächste Beitrag im Best of… diesmal zum Risikomanagement:

• #07 Was bitte heißt hier Risikomanagement?
  
• #08 Der Risikomanagementprozes
• #09 „Spielregeln“ im Risikomanagement
• #43 Intelligentes Risikomanagement
• #126 Zusammenfassung Risikomanagement (Englisch)
• #175 Checklisten im Risikomanagement
• #224 Risikomanagement á la PMI
• #353 Erfolgsfaktoren im Risikomanagement
• #356 Nachschlag Risikomanagement
• #456 Modernes Risikomanagement
• #457 Risikomanagement in Japan (Fukushima)
• #498 Risikomanagement und Wahrnehmung
• #505 Compliance vs. Risikomanagement
• #506 Compliance vs. Risikomanagement