Als ich vor ein paar Jahren Accounto (accounto.ch) startete, ging ich davon aus, dass es für Dokumentdatenextraktion einfach eine API geben würde, an welche ich irgendwelche Dokumente senden könnte. Die Schnittstelle würde mir dann Informationen zurückgeben, was für Dokumente das sind und zusätzlich auch die wichtigsten Informationen, die auf den Dokumenten stehen. Und das so strukturiert, dass eine Maschine damit arbeiten kann.
„Dokumentenextraktion ist doch gelöst?!“
Ich hatte damals von Dokumentenmanagement keinerlei Ahnung. Umso mehr war ich erstaunt, dass es eine solche API offensichtlich nicht gab. In der Folge sprach ich mit den einschlägigen Anbietern und erhielt Angebote und Projektvorschläge, die zum einen unseren Budgets, zum anderen aber auch unserer Vorstellung von „Dokumentenextraktion ist gelöst“ überhaupt nicht entsprachen. Zu teuer, zu mühsam, zu wenig flexibel.
Diskrepanz zwischen der Nachfrage und Industrie-Experten
Sprach ich über meine Vision der Dokumentenextraktions-API mit Business-Leadern, fanden das alle eine glänzende Idee. Sprach ich hingegen mit Experten aus der Dokumenten-Branche, wurde mir recht rasch erklärt, ich sei ein Phantast und eine solche API nie und unter keinen Umständen möglich. Das hat mich getriggert, das Problem mit unserem Team genauer anzusehen.
Was ist das technologische Problem, das gelöst werden muss?
Kern des Problems ist, möglichst viele Dokumententypen „out-of-the-box“ anbieten zu können. Also, funktional ohne irgendwelches Zutun. Bisherige Dokumentenextraktionssysteme setzen in der Regel pro Dokumententyp ein einziges Set von Methoden und Modellen ein, um die Daten des Dokuments auszulesen. Der Aufwand pro Dokumententyp ist je nach Umfang und Tools des Teams bei rund 2-4 Wochen für ein 4 Personen-Team. Je nachdem, wie man die Kosten rechnet, liegen sie im Bereich von 15-40k EUR. Die Kosten multiplizieren sich in der Regel mit weiteren Dimensionen wie neuen geografischen Regionen und verschiedenen Businesskontexten.
Mit konventionellen Konzepten wird es nie eine universelle Dokumentenverarbeitungs-API geben
Meine Rechnung war einfach; will ich eine API erarbeiten, welche in der Hälfte aller Länder der Welt eingesetzt werden kann und soll diese API jeweils nur die 50 wichtigsten Dokumententypen „out-of-the-box“ abbilden, resultiert daraus ein Bedarf von 4‘800 Dokumententypen und Kosten, notabene nur für die Dokumententyperarbeitung, von rund 170M US-Dollar. Vielleicht kann ich diese Kosten noch ein wenig reduzieren, sagen wir um 20%, aber am Ende bleibt es ein Case, der sich in keinem Businessmodell rechnet.
Ein weiteres Problem ist die Beschaffung der Trainingsdokumente. Zwar kann ich ohne Weiteres grosse Dokumentenmengen recht günstig beschaffen, diese sind aber immer super eindimensional. Es bringt für das Anlernen von Auslesefähigkeiten nicht viel, wenn ich von jeweils sehr ähnlichen Dokumenten tausende Exemplare habe. Man benötigt innerhalb eines Dokumententyps eine möglichst breite Repräsentation der möglichen auszulesenden Dokumente und Strukturen. Solche Dokumentensets, so meine Erfahrung, sind de fakto (zu recht!) nicht käuflich zu erwerben.
Der Pfad zu universeller, intelligenter Dokumentenextraktion
Um das Problem also zu lösen, müssen gänzlich andere Konzepte und Methoden umgesetzt werden. Die Lösung für die enormen Kosten der Erarbeitung von tausenden Dokumententypen ist das Parashift-proprietäre „Document Swarm Learning“. Konzeptionell ist das Ganze eigentlich ziemlich simpel: Anstatt dass wir ein Modell pro Dokumententyp erstellen, anlernen und optimieren, binden wir sämtliches Learning auf die darunterliegende Ebene, die Datenpunkt-Extraktoren.
Dies aus dem simplen Grund, dass sich viele Dokumententypen diese Datenpunkt-Extraktoren rein logisch teilen. Ein Datum beispielsweise kommt in vielen verschiedenen Dokumententypen vor. Anstatt es im Rahmen eines jeden Dokumententypen immer wieder einzeln mitzutragen, entkoppeln wir es vom Dokumententyp und lassen ein Set von Modellen nur zu diesem Datenpunkt-Extraktor lernen.
Der Dokumententyp selbst ist dann jeweils nur eine Kollektion von gemeinsam trainierten und verwendeten Datenpunkt-Extraktoren. Das hat viele, massive Vorteile:
- Reduziert es die Kosten der Dokumententyp-Erstellung auf einen Bruchteil der herkömmlichen Methoden
- Ermöglicht es Kunden auf unserer Plattform neue Dokumenten-Anwendungsfälle mit signifikant weniger Aufwand (Zeit & Kosten) zu erstellen (anstatt etwas „Anlernen“ werden bestehende Datenpunkt-Extraktoren zusammengeklickt)
- Wir produzieren damit im Dokumentenbereich ein massives und einzigartiges Datennetzwerk
„Lernen und Verbessern im Schwarm“
Um die Trainingsaufwände so weit wie möglich zu reduzieren, aggregieren wir das Learning aus sämtlichen Kunden-Mandanten und sämtlichen Dokumententypen vollkommen EU-DSGVO konform und nutzen diese Lernmenge, um alle Fähigkeiten auf der Plattform zu verbessern. Daher kommt auch der Name; da der ganze Schwarm an Usern und Machine Learning-Komponenten zusammenarbeitet, profitieren auch alle auf der Plattform wiederum entsprechend.
Automatisieren was automatisiert werden kann
Der dritte wichtige Punkt ist, dass dieses Swarm Learning möglichst vollautomatisch und permanent erfolgen sollte. Separate Trainingsintervalle, die dann auch noch den User beschäftigen, Data Scientists, die irgendwelche Modelle manuell updaten… Das alles ist teuer und aufwändig. Und verhindert eine schnelle Entwicklung der Fähigkeiten.
Businessmodell, welches ein Datennetzwerk ermöglicht
Um das Problem der Lerndokumente zu lösen, gibt es nur ein Weg: Die Plattform muss sich durch tausende Anwendungsfälle durchlernen. Das braucht zum einen Zeit und zum anderen benötigt es viele Kunden aus möglichst verschiedenen Branchen. Bieten wir dem Kunden eine Plattform, mit der er möglichst einfach und ohne grosse Hürden Anwendungsfälle umsetzen kann, ist die Chance hoch, dass er das oft und rasch tut.
Aus einer theoretischen Perspektive ist das alles recht trivial. In der Realität sieht die Welt, wie so oft, komplett anders aus. Jeder dieser drei Komponenten ist per se recht schwierig zu lösen. Hinzu kommt, dass wir, um ein rasch skalierendes Modell zu ermöglichen, Plattformkapazitäten bereithalten müssen. Es ist etwas völlig anderes, ein System für 30k Transaktionen pro Tag zu bauen als ein System für 300k Transaktionen pro Tag. Und, nur weil etwas als Prototyp funktioniert, bedeutet das leider oft nicht zwangsläufig, dass es sich auch in der Produktion ausbezahlt.
Eine langfristige Vision und ein Plan in 4 Schritten
1. Schritt: Basis-Technologie erarbeiten
In einem ersten Schritt haben wir die Konzeption und die Basistechnologie erarbeitet, um „Document Swarm Learning“ automatisiert zu betreiben. Wir haben unzählige Innovationen erschaffen, nicht ganz alle haben wir auch im heutigen Produkt. Auch sind, quasi nebenbei, weitere Komponenten entstanden, die mit unserer Mission nicht so viel zu tun haben. Zu erwähnen wäre da ein System, welches in Grossunternehmen mit hunderten von Bankkonten Buchungen mithilfe von Machine Learning Geschäftsfällen zuordnet und Buchungssätze generiert. Oder eine Komponente, welche aus maschinell generierten Dokumenten qualitativ schlechte Dokumente macht (ich weiss, das klingt absurd, ist aber in der Tat sehr hilfreich).
2. Schritt: Plattform und Ökosystem erarbeiten, Umsatzquellen ermöglichen
Im zweiten Schritt haben wir Swarm Learning, die Automatisierung und das Businessmodell zu Parashift wie wir es aktuell kennen, zusammengestellt. Das Angebot konzentriert sich auf:
- KMU
- Grosskunden
- Integratoren und Softwarehersteller
Als Multiplikatoren in Vertrieb und Integration setzen wir auf Partnerunternehmen. Damit sind wir in der Lage, die eigentlichen Subscriptions in einem für diese Art von Produkt sehr hohen Tempo zu skalieren.
Innert kurzer Zeit, meist in Beta-Stadium, konnten wir viele Kunden gewinnen und nennenswerte, wiederkehrende Umsätze generieren. Der ganz grosse Wurf ist das für Kunden zwar noch nicht, aber in den meisten Ausschreibungen und Evaluationen gewinnen wir mit diesem ersten Produktstand vergleichsweise einfach. Gleichermassen gegen alteingesessene Systemanbieter wie auch gegen viele vertikal orientierten Start-Ups, die derzeit entstehen.
Wir können mit diesem Ökosystem aus Produkt, Technologie, Partnern und Kunden schnell die notwendigen Dokumenten-Cases durchlernen und immer mehr Standard-Dokumententypen „out-of-the-box“ anbieten. Im Moment haben wir rund 350 davon erarbeitet, wovon wir nun laufend welche auf der Plattform veröffentlichen. In naher Zukunft werden wir damit das erste und einzige System am Markt sein, dass mehr als 500 Standard-Dokumententypen ohne Konfiguration über eine einzige API konsumierbar vorhält.
Der wichtigste Punkt dieser Phase ist die Kommerzialisierung. Unsere Daten zeigen, dass wir zwar weiterhin signifikant in F&E und Plattformentwicklung investieren müssen, gleichzeitig können wir mit dem Geschäftsmodell aber auch erhebliches Business generieren. Das müssen wir auch, damit wir komfortabel „bankable“ bleiben. Alleine diese Phase hat das Potential, Parashift zu einer global erfolgreichen Firma zu machen. Darauf konzentrieren wir uns im Moment, über Probleme, welche in der Zukunft und Weiterentwicklung liegen werden, versuchen wir uns auch möglichst nicht jetzt zu befassen.
Was also jetzt kommt, sind die nächsten strategischen Schritte, welche aber im aktuellen Going der Firma erstmal keine operative/kommerzielle Relevanz haben.
3. Schritt: Ein KMU-Offering lancieren
Der nächste logische Schritt ist das Lancieren eines KMU-Offerings. Dadurch erhalten wir nochmals einen riesigen Schub an weiteren Lern-Cases, die uns vorwärts pushen. Wie das Geschäftsmodell für dieses Produkt genau aussehen wird, liegt noch grösstenteils im Dunkeln. Thilo Rossa, unser Chief Product Officer, und ich haben dazu verschiedene Ideen. Klar ist jedoch, es muss geschehen, um von 1‘500 Standard-Dokumententypen in Richtung 25‘000 und darüber hinaus zu kommen.
4. Schritt: Die universelle Dokumentenverarbeitungs-API skalieren
Sind die 25‘000 Standard-Dokumententypen erreicht, gibt es für die meisten Dokumenten-Automatisierungs-Cases praktisch keine ernsthaften Alternativen zur Nutzung der Parashift API mehr. Das hat auch damit zu tun, dass es möglich sein wird, das Pricing für die Nutzung der API nur knapp über den eigentlichen Transaktionskosten zu halten. Ich gehe davon aus, dass wir die (totalen) Kosten pro Transaktion (Dokument) um mehr als 90% senken werden können. Damit wird, was mich ganz am Anfang der Reise getriggert hat, die Reise erst anzutreten, tatsächlich Wirklichkeit.
Von der Produkt- zur Infrastruktur-Company
Parashift verwandelt sich auf dieser Reise laufend. Die ersten zwei Jahre waren geprägt von der Entwicklung des Konzepts, der Technologie und der Strategie. Es ist nicht so, dass wir von Anfang an den ganzen Masterplan bereits vorliegen gehabt hätten. Im Gegenteil: Oft mussten wir Rückschläge hinnehmen und teuer Lehrgeld bezahlen. Schritt für Schritt haben wir die Lösung für die Herausforderung erarbeitet. Über kurz oder lang werden wir damit eine Infrastruktur-Company. So etwas wie eine Mischung aus Stripe und DeepL. Einfach für die Dokumenten-Industrie.
