Carbon-Beton ist ein spannender Werkstoff. Wenn Beton keinen Stahl als Armierung mehr braucht, dann wird es viel leichter. Ganz neue Bauwerke sind dann möglich. Und weniger Energie wird auch benötigt, denn die Herstellung von Carbon-Fasern ist deutlich effizienter als das Schmelzen, Gießen und Walzen von Stahl. Doch was hat das alles mit samarbeid, Webhooks und der Digitalisierung von Arbeitsabläufen zu tun?
Im Projekt FIBERCONNECT ging es darum, eine große Datenbank aufzubauen, die alle Unternehmen rund um den gesamten Lebenszyklus von Faserverbundwerkstoffen erfasst. Dieser Radar soll helfen, die richtigen Leute für den Aufbau einer Kreislaufwirtschaft für Carbon-Beton zusammenzubringen. Hier geht es zur Akteursdatenbank des C³ – Carbon Concrete Composite e.V.
Diese Datenbank muss aufgebaut und regelmäßig erweitert werden. Dabei muss das Team jeden Datensatz manuell freigeben und gegebenfalls redaktionell bearbeiten – denn die Qualität der Daten in der Akteursdatenbank ist entscheidend. Und genau für diese Redaktionsprozesse kommt samarbeid zum Einsatz. Und für eine optimale Integration in den Gesamtablauf kommen die Samarbeid API und Webhooks zum Einsatz. Die API wird schon aktiv und operativ genutzt. Die Webhooks sind derzeit noch ein experimentelles Feature, welches nur bei ausgewählten Nutzern testweise zum Einsatz kommt.
Aber was sind eigentlich Webhooks?
Laut Wikipedia ermöglichen Webhooks es, einer Server-Software mitzuteilen, dass ein bestimmtes Ereignis eingetreten ist und eine Reaktion auf das Ereignis auszulösen. Und was bedeutet das für samarbeid? Vereinfacht gesagt: mit einem Webhook kann samarbeid die API einer anderen Anwendung nutzen, beispielsweise wenn eine Aufgabe abgeschlossen wird.
Wie sieht das jetzt konkret bei dem Aufbau der Akteursdatenbank für die Kreislaufwirtschaft der Faserverbundwerkstoffe aus? Dort gibt es ein eigenständiges Stück Software – den Fiber-Connect Hub, der für die Identifikation neuer, bisher unbekannter Akteure zuständig ist. Der Hub crawlt und analysiert kontinuierlich unterschiedliche externe Datenquellen. Hat er dabei einen neuen, potentiellen Akteur identifiziert, werden Machine Learning und GenAI eingesetzt, um die Akteure zu klassifzieren und Textbausteine zu generieren. Die dabei genutzten Verfahren wurden von der Gruppe Data Science for Innovation des Fraunhofer ISI im Rahmen des Projekts entwickelt.
Natürlich können diese Daten nicht direkt veröffentlicht werden. Es benötigt eine Experten-Entscheidung, ob es sich tatsächlich um relevante Akteure handelt. Und natürlich müssen auch die automatisch generierten Daten geprüft und redaktionell optimiert werden. Dafür gibt es in samarbeid einen Redaktionsprozess.
Die samarbeid API und der Webhook
Für jeden neu identifizierten Akteur startet der Hub in samarbeid einen Redaktionsprozess. Dabei nutzt er die samarbeid API und übergibt die erstellen Daten direkt in den Prozess. Der automatisch zugewiesene Verantwortliche erhält eine Benachrichtigung (per Mail und direkt in samarbeid), dass neue redaktionelle Arbeit wartet. Und sollte die Aufgabe nicht bis zur automatisch festgelegten Deadline erledigt sein, erinnert samarbeid regelmäßig.
Das komfortable an dieser Lösung ist, dass der Redaktionsprozess jetzt alle Features von samarbeid sofort nutzen kann. Das Zuweisen von Verantwortlichen und Teilnehmern, das Setzen von Fälligkeiten, die Kommunikation in den Aufgaben, die Benachrichtigungen per Mail und noch vieles mehr. Und wenn das Team samarbeid auch für die sonstigen Aufgaben und Arbeitsabläufe im Team nutzt, dann sind die Redaktionsaufgaben direkt im allgemeinen Arbeitskontext. Komfortabler geht es nicht.
Wenn die Daten redaktionell freigegeben sind, müssen diese in die Akteursdatenbank eingetragen werden. Dafür bietet die die Akteursdatenbank eine eigen API an. Mit dem experimentellen Webhook kann samarbeid diese API selbständig ansprechen. Sobald der Nutzer die Aufgabe zur redaktionellen Prüfung abschließt, wird dieser Webhook ausgelöst und die Daten an die Akteursdatenbank per API übergeben. In samarbeid erhält der Nutzer eine Benachrichtigung darüber, damit alles transparent sichtbar ist.
Mit diesem Vorgehen gelingt es, einen kontinuierlich fortlaufenden Scan-Prozess mit redaktionellen Prozessen zu verknüpfen, so dass die Akteursdatenbank auch langfristig aktuell gehalten werden kann.
Ein erstes Fazit
Natürlich hat dieses Vorgehen auch Limitationen. Durch die lose Kopplung von drei Systemen – dem Hub, samarbeid und der Akteursdatenbank – steht immer die Frage im Raum, wo die Masterdaten der Gesamtlösung gespeichert sind. Auch müssen die bestehenden Daten in der Akteursdatenbank regelmäßig auf Korrektheit geprüft werden, was andere Redaktionsprozesse erfordert.
Trotz dieser Herausforderungen steht jetzt ein robustes System, dass durch die Redaktionsprozesse in samarbeid sicherstellt, dass Daten mit einer hohen Qualität in die Akteursdatenbank einfließen. So kann das Team diese Aufgaben leicht dort bearbeiten, wo es alle anderen Aufgaben und Prozesse auch managt. Diese niedrigschwellige Integration der Redaktionsaufgaben in die zentrale Arbeitsumgebung des Teams ist eigentliche Stärke dieses Ansatzes. Und samarbeid kann so seinen kleinen Beitrag leisten, dass die Kreislaufwirtschaft rund um den Carbon-Beton vielleicht etwas früher Realität wird.