1 Einleitung
Blockchains werden immer noch hauptsächlich als Technik hinter der digitalen Währung Bitcoin wahrgenommen (Nakamoto 2008). Es wird aber vielfach versucht, diese Technik auf andere Geschäftsvorgänge zu übertragen (Lehner 2016). Ein wichtiger Aspekt ist die Durchführung von Transaktionen ohne einer dritten Partei, wie einer Bank oder einem Zahlungsdienstleister, vertrauen zu müssen (Antonopoulos 2014). Blockchains bieten Pseudoanonymität: Teilnehmer können zwar eine beliebige Anzahl von anfangs anonymen Adressen generieren und damit Werteinheiten empfangen. Sobald sie jedoch Transaktionen bei zentralen Serviceanbietern mit persönlicher Anmeldung durchführen, können sie mitsamt ihrer gesamten Transaktionshistorie zugeordnet werden (Schützeneder 2016). Es bleiben noch viele Forschungsfragen und Herausforderungen im Kontext von Blockchain, Bitcoin sowie anderer Kryptowährungen offen (Bonneau et al. 2015, Schüssler et al. 2017).
Wir werden zeigen, wie Blockchains zur Projektkoordination verwendet werden können. Dabei ist die Anonymität eingeschränkt, obwohl die Teilnehmer sich untereinander nicht notwendigerweise kennen müssen, wie das bei virtueller Teamarbeit zunehmend der Fall ist. Wir haben zunächst eine passende Blockchain ausgewählt und dann in diversen Lehrveranstaltungen an der Johannes Kepler Universität Linz (JKU) verschiedene Organisationsmodelle getestet. Mit dieser Arbeit intendieren wir zwei Arten von Beiträgen. Erstens wollen wir eine Grundlage schaffen, um aus der Vielzahl an Möglichkeiten auszuwählen, die bereits jetzt für die Schaffung von Tokens bzw. Kryptowährungen für organisationale Anwendungen zur Verfügung stehen. Dazu werden einige dieser Plattformen kurz charakterisiert und es wird ein Kriterienschema vorgeschlagen. Zweitens wollen wir eine dieser Plattformen konkret an einer organisationalen Anwendung testen. Insbesondere sollen erste Erkenntnisse gesammelt werden, über die Möglichkeit mittels Blockchain generierte Tokens Projekte zu steuern und opportunistisches Verhalten (Fernandez et al. 2017) einzudämmen.
Anzeige
2 Custom Tokens
Custom Tokens sind Werte (assets) auf Basis einer Blockchain. Sie können für verschiedene Anwendungsfälle generiert und eingesetzt werden. Es können damit z. B. Währungen wie Dollar oder Bitcoin repräsentiert werden. Sie finden auch für Initial Coin Offerings (ICOs – Methode einer erstmaligen Kapitalaufnahme) und für öffentliche als auch für private Zwecke Anwendung (Ivanov 2016).
Es ist Benutzern selbst überlassen, wie sie Tokens nach der Erstellung auf einer Blockchain verwenden oder in Umlauf bringen. Auch ob der Token zukünftig einen echten Tauschwert erhalten oder für interne Zwecke vorbehalten sein soll, wird durch den jeweiligen Anwendungsfall entschieden. Im Folgenden beschreiben wir einige der wichtigsten Plattformen für die Erstellung von Custom Tokens und Kriterien für deren Einsatz.
2.1 Ethereum
Ethereum wurde im Juli 2015 in Betrieb gekommen und erweitert Grundfunktionalitäten einer Kryptowährung wie Bitcoin um sogenannte Smart Contracts (Hertig 2018). Smart Contracts sind digitale, selbstdurchführende Verträge zwischen sich nicht vertrauenden Parteien, welche durch beliebige Ausführung von Programmcode auf der Blockchain ermöglicht werden (Wüst und Gervais 2017). Smart Contracts bieten eine umfangreiche Einsatzpalette, beispielsweise im Kontext des „Internet der Dinge“ (Christidis und Devetsikiotis 2016).
Der von Ethereum etalblierte ERC20 Token Standard beschreibt die Schnittstelle (interface), welche von einem Ethereum-Token implementiert werden muss (Buterin 2016). Die Entwicklung erfolgt durch einen Smart Contract in der Programmiersprache Solidity, welcher diese vorgeschriebenen Funktionen und Ereignisse (events) implementiert. Mehr als 90 % aller gelisteten Tokens auf coinmarketcap.com basieren auf Ethereum (Stand: Mai 2018). Mehr als drei Viertel aller ICOs fanden auf der Ethereum-Blockchain statt (Fenu et al. 2018).
Anzeige
Das Problem der Skalierbarkeit existiert wie bei Bitcoin auch bei Ethereum. Es sind derzeit ca. 15 Transaktionen pro Sekunde möglich. Die Transaktionsgebühren können je nach aktueller Auslastung auch über einem Dollar betragen.
2.2 Waves
Waves ist ähnlich zu Ethereum eine offene Blockchain-Plattform, welche seit Juni 2016 verfügbar ist und durch einen ICO („Initial Coin Offering“, 16 Mio. US-Dollar) finanziert wurde (Waves Platform 2018). Anders als bei Ethereum wird Leasing Proof-of-Stake (LPoS) als Konsensalgorithmus verwendet. LPoS erweitert PoS um die Möglichkeit, Waves an Betreiber von Nodes zu leihen und dabei ebenfalls von den Transaktionsgebühren zu profitieren, ohne dabei selbst einen Node zu betreiben oder über technische Kenntnisse zu verfügen. Der geliehene Anteil bleibt vollständig in Kontrolle des Inhabers und das Leasing kann jederzeit abgebrochen werden (Ivanov 2016).
Im Vergleich zu offenen Blockchains wie Bitcoin bieten Plattformen nicht nur die Abwicklung von Transaktionen einer nativen Währung als einzigen Transaktionstyp, sondern ein komplettes Ökosystem von der Erstellung und Transaktion von Custom Tokens, einer dezentralen Handelsplattform, bis zum Umtausch von herkömmlichen Währungen wie Dollar oder Euro auf Kryptowährungen über Gateways an. Smart Contracts sind in Entwicklung und befinden sich in der Testphase. Es gibt noch weitere Typen von Transaktionen, z. B. die Erstellung von Aliases. Ein Alias erlaubt es, eine eigene und eindeutige Zeichenkette für eine Hash-Adresse zu vergeben. Alle Transaktionstypen in Waves haben eine festgesetzte Transaktionsgebühr.
Der bisherige Verzicht auf Smart Contracts hat Vor- und Nachteile. Einerseits fallen Programmierkenntnisse, Programmieraufwand und teure Audits (keine Überprüfung von komplexem Programmcode) weg. Die Tokens können in kurzer Zeit und gegen eine Gebühr von 1 Waves erstellt werden. Ein weiterer Vorteil ist, dass Tokens sofort auf einer dezentralen Handelsplattform verfügbar sind. Ein Nachteil ist die geringere Anpassungsmöglichkeit der Tokens im Vergleich zu programmierbaren Ethereum Smart Contracts. Einstellbar sind der Name, die Beschreibung, die Anzahl der Tokens, die Anzahl der verwendeten Dezimalstellen und die Möglichkeit zur späteren Erhöhung der maximalen Anzahl an Tokens. Die Generierung wird durch eine Transaktion auf der Blockchain abgewickelt, wodurch der Absender der Transaktion die erzeugten Tokens auf seine Wallet (digitale Geldbörse) erhält und der Token eine eindeutige ID auf der Blockchain erhält.
2.3 NEO
Die Blockchain-Plattform NEO bietet eine weitere Möglichkeit zur Erstellung von Custom Tokens und wird nach Ethereum und Waves derzeit am häufigsten verwendet (Fenu et al. 2018). Die Plattform wurde 2014 in China gegründet. Die Vorteile ist die hohe Skalierbarkeit (Abwicklung von 10.000 Transaktionen pro Sekunde) durch eine Proof-of-Stake Variante und die Verwendung der Programmiersprachen C#, C++ und Javascript für Smart Contracts. Die Einstiegshürde für Programmierer ist dadurch geringer. Ein Nachteil ist, dass es auf Grund seiner Wurzeln im nicht-englischsprachigen Bereich noch nicht viele Informationen über dieses Projekt gibt. Die hohe Marktkapitalisierung (5 Mrd. US-Dollar, elftwertvollste Kryptowährung) zeigt aber, dass aus Investorensicht dieses Projekt als zukunftsträchtig gehandelt wird (coinmarketcap.com, Mai 2018).
2.4 Eigene Blockchain
Die Entwicklung einer eigenen Blockchain und der Betrieb auf eigenen Servern sind möglich, aber dadurch können Robustheit und Ausfallsicherheit nicht in vollem Ausmaß gewährleistet werden. Öffentliche Blockchains sind ständig Angriffen ausgesetzt und somit umfangreich und jahrelang getestet. Robustheit und Ausfallsicherheit ergeben sich auch maßgeblich aus der Dezentralität, welche bei einer eigenentwickelten Blockchain nur in geringerem Umfang gegeben ist. Alle Vorteile, die sich aus den grundlegenden Eigenschaften einer Blockchain ergeben, können durch die Verwendung einer öffentlichen dezentralen Blockchain ebenso genutzt werden.
Dazu zählen z. B. die Irreversibilität und die Transparenz von Transaktionen. Für die Entwicklung einer Blockchain-Lösung wie Ethereum oder Waves ist zudem hoher Aufwand und viel Knowhow nötig.
2.5 Auswahl der Blockchain
Die Entwicklung einer eigenen Blockchain war für unsere Zwecke nicht notwendig, da wir nur Funktionen benötigen, die sich auch auf öffentlichen Blockchains abbilden lassen. Somit war zu entscheiden, welche öffentliche Blockchain für unseren Anwendungsfall sinnvoll eingesetzt werden kann. Wichtige Kriterien dafür waren die Benutzerfreundlichkeit der Software, die Verfügbarkeit von mobilen Applikationen, die Kosten der Transaktionen sowie die Geschwindigkeit ihrer Durchführung. Stark schwankende Transaktionskosten sind für Mikrotransaktionen ungünstig. Dabei sind selbst 10 Cent schon zu viel.
Bitcoin kam nicht in Frage, da keine eigenen Tokens erstellt werden können und die Transaktionsgebühren sehr hoch sind. Waves bietet eine übersichtliche und benutzerfreundliche grafische Benutzerschnittstelle für die Abwicklung von Transaktionen. Außerdem sind mobile Applikationen für Android und iOS verfügbar. Die Transaktionskosten bei Bitcoin und Ethereum schwanken stark. Bei Waves liegen die Transaktionsgebühren konstant bei 0,001 Waves, wobei der Wert von 1 Waves im März 2018 etwa bei 4 Dollar lag. Sowohl bei Ethereum als auch bei Waves liegt die sog. Block Time unter einer Minute. Bei Bitcoin wird im Durchschnitt alle 10 min ein neuer Block generiert.
Tab. 1 zeigt eine Zusammenfassung der Entscheidungskriterien, die bei der Auswahl der Blockchain eine Rolle spielten. Auf Grund der einfachen Token-Erstellung ohne signifikante Nachteile für unseren Anwendungsfall fiel die Entscheidung daher auf Waves.
Tab. 1
Entscheidungskriterien bei der Blockchain-Auswahl
Blockchain-Lösung/Kriterium | Bitcoin | Ethereum | Waves | NEO | Eigene Blockchain |
|---|---|---|---|---|---|
Custom Tokens | − | + | + | + |
a
|
Flexibilität | − | + | o | o | + |
Benutzerfreundlichkeit | o | o | + | o |
a
|
Transaktionsdauer | − | + | + | + |
a
|
Transaktionsgebühren | − | o | + | + |
a
|
Robustheit | + | + | + | o | − |
Ausfallsicherheit | + | + | + | o | − |
Support/Community | + | + | + | − | − |
Entwicklungsaufwand | − | o | + | o | − |
2.6 Kepler Tokens
Wir haben zuerst eine Million Kepler-Tokens auf der Waves-Blockchain erstellt. Da die Anzahl beliebig erhöht werden kann, werden die generierten Kepler-Tokens vorerst auch keinen Wert auf einem globalen Markt bekommen. Interessant ist, ob die Tokens innerhalb der Projektteilnehmer einen Tauschwert erhalten, da sie für die Projektmitarbeiter nur durch Arbeit bzw. Leistung zu bekommen sind. Teilnehmer könnten untereinander mit Tokens handeln und diese gegen andere Währungen wie Bitcoin, EUR oder USD tauschen. Da die Waves-Blockchain eine dezentrale Börse anbietet, kann somit ein Markt für Kepler Tokens entstehen. Schlussendlich erhalten die Tokens dann denjenigen Wert, welcher für eine bestimmte Beurteilung (z. B. Noten 1–5 im Schulnotensystem) als gerecht empfunden wird. Die Möglichkeit zur Erhöhung der Menge an Tokens kann vom Ersteller selbst später entfernt werden, falls das und allfällige Wertsteigerungen gewünscht sind. Die ID des Kepler-Tokens1 kann jederzeit auf der Waves-Blockchain überprüft werden. Die Generierung wurde als Waves-Transaktion mit dem Typ 3 („Asset Issue“) in Block 671364 durchgeführt. Es wurden 8 Nachkommastellen festgelegt. Die geringen Transaktionsgebühren und Gebühren für die Erstellung des Tokens wurden auf einer Börse für Kryptowährungen gekauft. Die Generierung erfolgte durch einen „Admin“-Account.
3 Tokens zur Steuerung von Projekten
Professionelles Projektmanagement wird durch einen ausgefeilten Standard an Werkzeugen zur Planung und Steuerung auf Projektebene unterstützt (zusammengefasst etwa in PMBoK 2013), welches auch ein hohes Maß an Transparenz über die Leistung einzelner Projektteams garantiert. Für das Management und die Koordination innerhalb dieser Teams allerdings sind diese Werkzeuge in der Regel zu bürokratisch und schwerfällig. Vielmehr wird in der Regel auf eine Clan-Kultur (Ouchi 1980) vertraut, welche eine Gleichverteilung von Beiträgen und Leistungen innerhalb eines Teams sicherstellen soll. Aus einer ökonomischen Perspektive jedoch ist opportunistisches Verhalten in Organisationen (Williamson 1981), zwischen Auftraggebern und Agenten (Jensen und Meckling 1976) und zwischen Kollaborateuren in Innovationsprojekten (Fernandez et al. 2017) zu erwarten. Opportunismus beeinflusst den Erfolg der Projektarbeit bei zunehmender Agilität, bei hoher Dynamik und Unsicherheit, etwa bei Entwicklungsprojekten negativ (Um und Kim 2018). Zunehmend virtuelle Zusammenarbeit, ohne direkte Clan-Kontrolle erleichtert dies zusätzlich. Wegen hoher Bürokratiekosten ist „Performance-Monitoring“ als klassische Gegenmaßnahme zu opportunistischem Verhalten in Kleingruppen und Teams nur beschränkt sinnvoll.
3.1 Steuerungsmodelle mit Blockchain und Custom Tokens
Die Blockchain-Technologie bietet zur „Governance“ und Steuerung der Projektarbeiten Alternativen zu den klassischen Methoden aus mehreren Perspektiven. Erstens gestatten Blockchains vollständige Transparenz der einzelnen Beiträge der Teammitglieder und einmal getätigte Einträge können nicht verändert werden. Projektleiter oder Auftraggeber wissen im Normalfall nicht, welche Person wieviel Aufwand in das Projekt oder in spezifische Aufgaben investiert hat. Da die Blockchain öffentlich einsehbar ist und analysiert werden kann, werden diese Vorgänge und Transaktionen für Stakeholder sichtbar und können nicht revidiert werden. Zweitens können mit dafür geschürften Kryptowährungen oder Tokens Beiträge schnell und individuell belohnt werden. Für die konkrete Ausgestaltung von letzterem gibt es verschiedene Möglichkeiten, welche an den Projektkontext angepasst werden müssen (ein Beispiel wird in Abschn. 3.2 im Detail beschrieben):
-
(a) Hierarchisch: Für jedes Arbeitspaket (oder für jeden „Sprint“) wird eine bestimmte Anzahl von Tokens ausgeschrieben. Die Teamleiterin verteilt diese Tokens während und am Ende unter den Teammitgliedern, je nach Qualität ihrer Beiträge.
-
(b) Symmetrisch: Jedes Teammitglied bekommt am Beginn eine bestimmte Anzahl von Tokens zugewiesen, mit der Verpflichtung, diese vollständig zu verteilen. Jedes Teammitglied entscheidet, wem es seine Tokens gibt.
Würde jedem Beitrag eines Teammitglieds eindeutig eine abgrenzbare Menge an Beiträgen der Teamleiter (oder der anderen Teammitglieder) gegenübergestellt werden können, könnten beide Möglichkeiten als mehrstufige Spiele betrachtet werden, im einfachsten Fall als zweistufiges Stackelberg-Spiel (Fudenberg und Tirole 1991, S. 67 ff), in welchem die Teammitglieder auf Stufe 1 ihr Ausmaß an Beiträgen wählen und auf Stufe 2 die Teamleiterin (Modell (a)) oder die anderen Teammitglieder (Modell (b)) ihre Tokenverteilung wählen. In realistischen Projekten ist wegen der Mehrdeutigkeit der Beiträge allerdings keine Auszahlungsmatrix aufstellbar.
Statt spieltheoretischer Überlegungen werden die Teammitglieder motivationale und Gerechtigkeitskonzepte anwenden. Letzteres legt etwa rein reziproke (gibst Du mir, gebe ich Dir) Transaktionen im Modell (b) nahe, die negativ sanktioniert werden könnten. Dennoch wird eine Tendenz zur Gleichverteilung entstehen, besonders wenn sich die Teammitglieder wenig mit den Beiträgen der anderen beschäftigen. In jedem Fall sind erhöhte Transparenz und die Verknüpfung mit extrinsischen Anreizen für die Motivation der Teammitglieder nicht unumstritten (Deci 1972) und benötigen in diesem Zusammenhang mehr Forschung.
Motivation wird in jedem Fall nur durch einen extrinsischen „Wert“ der Tokens hergestellt. Dafür gibt es mehrere Möglichkeiten: (a) Es wird eine „Börse“ eingerichtet, an der die Tokens später in Euros oder andere Gratifikationen (Noten an Universitäten, wie im vorliegenden Anwendungsfall, siehe 3.2) umgewandelt werden. (b) Die Tokens dienen zur Darstellung des eigenen Status in der Firma und können allenfalls als Grundlage für Beförderungen oder Gehaltserhöhungen herangezogen werden. Der wesentliche Vorteil gegenüber traditionellen Formen der Gratifikation ergibt sich aus der Transparenz und Unveränderbarkeit der Blockchain. Die Spieler kennen zwar ihre Auszahlungsmatrix nicht vor ihren Zügen, aber jedem ihrer Beiträge steht nachträglich eine eindeutige Auszahlung von Tokens gegenüber, welche von allen Beteiligten eingesehen werden kann. Damit kann opportunistisches Verhalten zwar nicht ausgeschlossen werden, aber es wird transparent und daher unwahrscheinlicher, weil es jenseits der Auszahlungsmatrix später negativ sanktioniert wird.
Durch die Verwendung einer Blockchain entsteht ein weiterer Mehrwert hinsichtlich der Wartungskosten. Im Gegensatz zu einem Client-Server-Modell kann eine Uptime des Systems von 100 % erreicht werden und Kosten für den Betrieb einer Datenbank und für Sicherheitsmanagement werden zu einem hohen Grad an das P2P-System ausgelagert. Bestimmte Prozesse innerhalb eines Projektes, die Vertrauen an andere Projektteilnehmer erfordern, können nur durch Dezentralisierung erreicht werden (siehe Abschn. 3.2, Uber-Modell). Eine mögliche Manipulierung der Prozesse durch eine zentrale Instanz ist im Gegensatz zu einem Client-Server-Modell hierbei nicht möglich.
3.2 Gruppenprojekte
Eine einfache Form der Projektkoordination stellen die im Folgenden beschriebenen Gruppenprojekte dar, mit denen der Einsatz einer Blockchain für die Abbildung von Mikro-Leistungen in Lehrveranstaltungen an der JKU zu zeigen war. Ziel ist die Generierung erster Erkenntnisse über konkrete Anwendungen der Blockchain im Organisationskontext, insbesondere in Hinblick auf Anreizwirkung, Akzeptanz und auf Vertrauensbildung, über den Umgang technisch wenig versierter Nutzer mit Blockchain-Anwendungen und über die Akzeptanz verschiedener damit möglicher Steuerungsmöglichkeiten für Projekte.
Es wurden drei Modelle bezüglich der Verteilung und der Organisation der Tokens mit insgesamt 74 Teilnehmern getestet. Bei der Verteilung der Tokens haben wir uns für das hierarchische Modell (a) entschieden (siehe oben). Dabei haben wir die benötigte Anzahl an Tokens abhängig von der Anzahl an Teilnehmern und dem getesteten Organisationsmodell an die Accounts der Projektleiter transferiert.
Im ersten Modell („Uber-Modell“) erhielten anonyme 4er oder 5er-Gruppen (12 Gruppen) ein Thema für eine Seminararbeit und einen für sie eingerichteten Chatroom. Die Gruppenmitglieder erhielten einen Nicknamen, mit dem sie online kommunizierten und anonym Zwischenstände ihrer Arbeitspakete austauschten. Am Anfang des Seminars wurde ein Kredit von 100 K (Kepler) an alle Gruppenmitglieder gesendet. Am Ende mussten Kepler an den Lehrveranstaltungsleiter zurückgezahlt und somit die Note „gekauft“ werden. Basierend auf einem Notenschlüssel hatte jede Note einen „Preis“ zwischen 100 K und 125 K. Nach Abgabe der Seminararbeit wurden je nach Beurteilung noch einmal 0 bis 100 K vom LVA-Leiter an den Gruppenleiter gesendet. In der ersten Online-Diskussion bestimmt die Gruppe über Zuordnung von Kepler eine Aufgabenstruktur und eine Zuordnung von Gruppenmitgliedern zu den einzelnen Teilen. Das Projekt konnte z. B. in 25 Aufgabenpakete eingeteilt werden, für die jeweils 4 K veranschlagt werden. Die Art der Verteilung der Tokens im Team erfolgte ohne Vorgabe und nach Absprache im Gruppenchat. Der Projektleiter verhandelt, wie viele Kepler für die Pakete gezahlt werden. Um die Verhandlungsmacht nicht zu groß werden zu lassen, werden die Gruppenmitglieder also eine Anzahlung fordern, wozu der Anfangskredit eingesetzt werden kann. Die Gruppenmitglieder sollen so lange wie möglich anonym bleiben, da ansonsten die Wahrscheinlichkeit für die übliche Gleichverteilung, wie es Mitarbeiter sonst von Gruppenarbeiten kennen, hoch ist. Die anonyme Online-Umgebung sollte auch das Experimentieren mit anderen Formen der Zusammenarbeit erleichtern.
Im zweiten Modell erhielt die Projektgruppe (5 Teilnehmer), ebenfalls über einen zuvor gewählten Projektleiter die Kepler im Laufe eines Softwareentwicklungsprojekts abhängig vom wöchentlichen Fortschritt und vom Endergebnis. Der Fortschritt wurde bei drei Meilensteinterminen bewertet. Ein solcher Entwicklungszyklus ist auch bei Softwareentwicklungsprojekten in der Praxis gängig. Die LVA-Leitung übernahm in diesem Fall zugleich die Rolle des Auftraggebers und die Rolle eines Consultants. Es wurden insgesamt maximal 100 K an den Gruppenleiter verteilt. Für jeden Fortschrittstermin wurden maximal 15 K verteilt. Die restlichen maximal 55 K wurden je nach Erreichung der Anforderungen am Ende verteilt. Die Aufteilung erfolgte in verschiedenen Kategorien (Interne Qualität 15 K, Externe Qualität 15 K, Funktionale Anforderungen 15 K, Dokumentation 15 K), wobei diese vorher dem Projektteam bekannt waren. Die Beurteilung muss natürlich seitens der LVA-Leitung auf die gängige Art und Weise erfolgen, die Verteilung im Team erfolgte jedoch ohne Vorgabe. Somit wird eine faire persönliche Beurteilung ermöglicht. Sowohl im ersten als auch im zweiten Modell wurden Waves-Wallets für alle Teilnehmer angelegt, um im Notfall Backups zu besitzen. Diese Vorgehensweise widerspricht allerdings teilweise der Idee der Blockchain-Technologie, da Vertrauen in die Administratoren vorausgesetzt wird.
Diese Einschränkung wurde im dritten Modell (2 Gruppen zu je 5 Teilnehmer) aufgehoben, wo im Unterschied zum zweiten Modell die Teilnehmer ihre Wallets selbst erstellten. Somit lag die Verantwortung für die sichere Aufbewahrung und Backups vollständig in den Händen der Teilnehmer. Dies sollte zu einem höheren Verantwortungs- und Sicherheitsbewusstsein führen, da die Kepler-Tokens im Ernstfall nicht mehr durch ein Backup seitens eines Administrators wiederhergestellt werden können. Dieser Umstand wurde im Vorhinein ausführlich an die Teilnehmer kommuniziert.
In allen beschriebenen drei Modellen konnten die Teammitglieder mit den erhaltenen Tokens am Ende eine mehr oder weniger gute Note nach einem vorher definierten Schlüssel „kaufen“.
4 Erkenntnisse
Die Beobachtungen während der Projektarbeit und die Protokolle der Teamkommunikation ergeben erste Erkenntnisse zu organisationalen Anwendungen der Blockchain-Technologie. Erstens, soweit die Teammitglieder aus der Generation der „Digital Natives“ stammen, ist die Akzeptanz der für den Umgang mit Blockchain und Kryptowährungen notwendigen Werkzeuge groß und stellt kein wesentliches Problem dar. Zweitens, die Wirkungen der damit möglichen Transparenz und die Anreizwirkung sind zumindest in relativ kleinen Projekten wie sie hier getestet wurden, gering. Allerdings ermutigt der erste Versuch zu Anwendungstests in größeren Projekten, in denen mögliche Effekte stärker durchschlagen sollten.
In Bezug auf unseren ersten intendierten Beitrag zeigen die Ergebnisse, dass organisationsinterne Anwendungsfälle durchaus auf einer öffentlichen Blockchain abgewickelt werden können. Datenschutzgründe könnten zwar für eine interne Speicherung sprechen, allerdings würde dadurch ein zentrales Blockchain-Merkmal wegfallen, denn die Teilnehmer müssten dann der Organisation ihr Vertrauen schenken. Alternativ könnte somit auch eine Datenbank eingesetzt werden. In Bezug auf das zweite Forschungsinteresse zeigen die Ergebnisse ein überraschend großes Vertrauen in die Technologie und damit verbundene Verteilung der Tokens. Die Teilnehmer in den einzelnen Gruppen verlangten keinerlei Sicherheiten in Form von Vorauszahlungen für ihre Arbeitspakete. Dieses Ergebnis kann aber am besonderen Setting des Projektes im Rahmen einer Lehrveranstaltung liegen, wo aufgrund des Vertrauens in den Lehrveranstaltungsleiter die Gefahr opportunistischen Verhaltens als eher gering einzustufen ist.
Das Verteilungssystem mit Custom Tokens wurde von den Teilnehmern als fair empfunden, da unterschiedliche Tätigkeiten und Fortschritte individuell bewertet werden konnten. Das Verhalten und die Leistung der einzelnen Gruppenmitglieder konnte im Gegensatz zur normalen Projektabwicklung durch die Verwendung einer öffentlichen Blockchain für Auftraggeber transparenter gemacht werden. Unabhängig vom Einsatz einer Blockchain und Custom Tokens bleibt die Bewertung von Tätigkeiten bzw. Aufwand ein generelles Problem des Projektmanagements. Die Ergebnisse aller drei untersuchten Modelle legen jedenfalls einen ersten vorsichtigen Schluss nahe: die Transparenz und Nachfolgziehbarkeit der Zuordnung von Beiträgen und Tokenauszahlungen genügte, um opportunistisches Verhalten im Sinne von einseitiger Aufwands- oder Auszahlungsminimierung einzuschränken.
Allerdings könnte das Risiko opportunistischen Verhaltens mit dem Wissensstand über die Technologie steigen und dies könnte von den Teilnehmern auch vermehrt wahrgenommen werden. Jedenfalls hat sich der Wissensstand der Teilnehmer über Bitcoin, Blockchain und Waves über die Projektverläufe hinweg signifikant verbessert (Auswertung von Fragebögen).
5 Schlussfolgerung und Ausblick
Custom Tokens auf Basis der Blockchain-Technologie eignen sich grundsätzlich zur Projektkoordination, wie die hier vorgestellten Fallstudien nahe legen. Vorhandene Blockchain-Plattformen erlauben es, Custom Tokens einfach zu erstellen und zu verwenden. Der Einsatz der Tokens kann je nach gewählter Organisation unterschiedlich ausfallen. Wir haben mehrere Modelle getestet und erste Erfahrungen gesammelt. Interessant ist die Frage des Vertrauens, das sowohl der Token-Ausgabestelle als auch dem Projektleiter von den Teilnehmern entgegengebracht werden muss. Unser Ziel war es, die Beurteilung von Leistungen in einer Gruppe nicht gleich zu verteilen, sondern die Gruppe selbst darüber entscheiden lassen, wie ein Bonus untereinander je nach erbrachter Leistung verteilt werden soll. Dieser Ansatz lässt sich verallgemeinern und kann in Projektteams eingesetzt werden, um beispielsweise für besondere, in der Gruppe anerkannte Leistungen Tokens zu vergeben und diese dann später zu honorieren, z. B. durch Bezahlen einer Prämie. Auch Optimierungen wie z. B. die automatische Rückzahlung der Tokens durch Smart Contracts am Ende der Projektlaufzeit können bei weiteren Experimenten erprobt werden.
Das besondere Setting des hier beschriebenen Projektes limitiert sicherlich dessen Aussagekraft, zeigt aber Richtungen für weitere Forschungen auf. Diese sind insbesondere in größeren, realen Projekten wünschenswert, in denen opportunistisches Verhalten wahrscheinlicher ist (Fernandez et al. 2017) und in denen daher mögliche positive, allerdings auch negative Effekte einer Projektsteuerung mittels Tokens identifiziert werden könnten.
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
Weitere Details zur Lizenz entnehmen Sie bitte der Lizenzinformation auf https://creativecommons.org/licenses/by/4.0/deed.de.