Blockchain, Mythos und Wahrheit

Teil 3. Einsatzmöglichkeiten

Aber was sind denn nun die eigentlichen Anwendungen, bei denen diese Technologie wirklich Sinn macht?

Da wir über „verteilte Hauptbücher“ sprechen, bieten sich selbstverständlich Projekte aus dem Finanzsektor an. Das sind Anwendungsfälle, wie:

  • das Absichern von Daten und Dokumenten für Hypotheken
  • Smart Contracts
  • Finanzierungen, speziell im internationalen Handel, wenn es um „Geld-vor-der-Ware“-Prozesse geht
  • Internationale Zahlungen und Geldtransfers
  • Versicherungsverfahren incl. der Übermittlung von Dokumenten/Bildern
  • Abstimmungen im AG-Bereich ohne Anwesenheit der Aktionäre
  • Auditierungsprozesse

Aber natürlich auch Anforderungen aus den Bereichen

  • Digital Asset Management
  • Supply chain tracking
  • Identitätsmanagement
  • Abstimmungsverfahren
  • gesicherte Gerätekommunikation (IoT)
  • u.v.m.

Warum sehen wir dann aber so wenige, wirkliche Projekte außerhalb des großen Internets und der Währungsthematik?

Sicherlich weil Blockchain-/DLT-Projekte vor allem Transparenz und redundante, verteilte Datenhaltung fordern und sich nach wie vor viele Unternehmen schwer damit tun, steht doch Transparenz für viele Unternehmen im direkten Widerspruch zu Vertraulichkeit.

Natürlich möchte ich meine Patentdaten absichern, aber nicht indem ich sie Dritten zur Aufbewahrung gebe. Gleiches gilt für die Unveränderlichkeit von Objekten. Dies widerspricht in vielen Unternehmen dem gelebten Alltag, der auf einer Aneinanderreihung von Reaktionen, aus Ausnahmen von der Regel besteht. Dabei werden allzu oft auch Informationen mit angepasst und Dokumente verändert, und das nicht immer transparent.

Übrigens gibt es mit den etablierten Lösungen aus dem Lager der Dokumentenmanagement Software hier seit Jahren welche, die die teilweise diametralen Anforderungen der Unternehmen unter einen Hut bringen.

Was sind dann die kritischen Erfolgsfaktoren, wenn ich ein Blockchainprojekt für mein Unternehmen planen möchte?

Wie immer gilt es erst einmal das Ziel festzulegen:

  1. Welches Problem möchte ich lösen, oder
  2. Welche Möglichkeit möchte ich ergreifen?

Wenn ich das weiß, muss ich mir folgende Fragen beantworten:

  1. Brauchen unterschiedliche Menschen und Organisationen
    1. Zugriff auf die gleichen Informationen und
    2. einen gemeinsamen Speicher für weitere Informationen
  2. Brauchen die Teilnehmer an diesem Informationsaustausch die Gewissheit, dass die Daten valide und nicht manipuliert sind?
  3. Haben sie vielleicht schon heute einen proprietären Prozess hierfür in Benutzung (z.B. firmenspezifisches Transmittal Management) oder haben sie tatsächlich heute keine Absicherung?
  4. Gibt es gute Gründe die Lösung dezentral repliziert zu betreiben?

Wenn Sie all diese Fragen mit JA beantworten, dann könnte eine DLT- oder Blockchain-Lösung das richtige sein, aber es gibt noch weitere, wichtige Punkte zu berücksichtigen.

Damit Sie in der Projektumsetzung nicht stranden, sollten Sie nun die Grundsätze Ihre Lösung festlegen. Dazu gehören neben dem identifizierten Anwendungsfall auch Dinge wie die rechtlichen Rahmenbedingungen, die Teilnahmeregeln, also ob Ihre Lösung privat oder öffentlich sein soll, sowie die Verantwortlichkeit für die Einhaltung der Regeln.

In einem geschlossenen System kann das Ihr Unternehmen oder ein neutraler Dritter sein (z.B. Ihr QM Manager oder WP). In einem öffentlichen System erfolgt die Kontrolle durch alle Teilnehmer, die gegenseitig auf die Einhaltung der Regeln achten.

Weiterhin definieren Ihre grundsätzlichen Entscheidungen den möglichen technologischen Rahmen. Wenn Sie hier Kompromisse machen müssen, prüfen Sie deren Auswirkungen unbedingt im Vorfeld der Anwendung.

Der wesentliche Punkt ist aber, schaffen Sie es mit Ihrem Anwendungsfall und der gewählten Technologie wirklich ein Netzwerk von sich gegenseitig vertrauenden Knoten zu erstellen?

Hier kommt ein letzter wesentlicher Aspekt ins Spiel, übereilen Sie es nicht. Eine Blockchain-Lösung erfordert Vertrauen, und Vertrauen baut sich nicht in wenigen Tagen auf. Selbst vorhandene Lösungen passen i.d.R. nicht zu den Anforderungen der Unternehmen. Hier ist daher eine grundlegende konzeptionelle Arbeit gefordert, wenn das Projekt in Realität entstehen soll.

Denken Sie immer an Amaras Gesetz:

We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. (Roy Amara, 1925-2007)

Happy Chaining!

 

Autor: Dr. Oliver Holst