Als ich vor ein paar Jahren Accounto (accounto.ch) startete, ging ich davon aus, dass es f\u00fcr Dokumentdatenextraktion einfach eine API geben w\u00fcrde, an welche ich irgendwelche Dokumente senden k\u00f6nnte. Die Schnittstelle w\u00fcrde mir dann Informationen zur\u00fcckgeben, was f\u00fcr Dokumente das sind und zus\u00e4tzlich auch die wichtigsten Informationen, die auf den Dokumenten stehen. Und das so strukturiert, dass eine Maschine damit arbeiten kann.<\/p>\n\n\n\n
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\u00e4gigen Anbietern und erhielt Angebote und Projektvorschl\u00e4ge, die zum einen unseren Budgets, zum anderen aber auch unserer Vorstellung von \u201eDokumentenextraktion ist gel\u00f6st\u201c \u00fcberhaupt nicht entsprachen. Zu teuer, zu m\u00fchsam, zu wenig flexibel.<\/p>\n\n\n\n
Sprach ich \u00fcber meine Vision der Dokumentenextraktions-API mit Business-Leadern, fanden das alle eine gl\u00e4nzende Idee. Sprach ich hingegen mit Experten aus der Dokumenten-Branche, wurde mir recht rasch erkl\u00e4rt, ich sei ein Phantast und eine solche API nie und unter keinen Umst\u00e4nden m\u00f6glich. Das hat mich getriggert, das Problem mit unserem Team genauer anzusehen.<\/p>\n\n\n\n
Kern des Problems ist, m\u00f6glichst viele Dokumententypen \u201eout-of-the-box\u201c anbieten zu k\u00f6nnen. 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\u00fcr 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.<\/p>\n\n\n\n
Meine Rechnung war einfach; will ich eine API erarbeiten, welche in der H\u00e4lfte aller L\u00e4nder der Welt eingesetzt werden kann und soll diese API jeweils nur die 50 wichtigsten Dokumententypen \u201eout-of-the-box\u201c abbilden, resultiert daraus ein Bedarf von 4\u2018800 Dokumententypen und Kosten, notabene nur f\u00fcr 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.<\/p>\n\n\n\n
Ein weiteres Problem ist die Beschaffung der Trainingsdokumente. Zwar kann ich ohne Weiteres grosse Dokumentenmengen recht g\u00fcnstig beschaffen, diese sind aber immer super eindimensional. Es bringt f\u00fcr das Anlernen von Auslesef\u00e4higkeiten nicht viel, wenn ich von jeweils sehr \u00e4hnlichen Dokumenten tausende Exemplare habe. Man ben\u00f6tigt innerhalb eines Dokumententyps eine m\u00f6glichst breite Repr\u00e4sentation der m\u00f6glichen auszulesenden Dokumente und Strukturen. Solche Dokumentensets, so meine Erfahrung, sind de fakto (zu recht!) nicht k\u00e4uflich zu erwerben.<\/p>\n\n\n\n
Um das Problem also zu l\u00f6sen, m\u00fcssen g\u00e4nzlich andere Konzepte und Methoden umgesetzt werden. Die L\u00f6sung f\u00fcr die enormen Kosten der Erarbeitung von tausenden Dokumententypen ist das Parashift-propriet\u00e4re \u201eDocument Swarm Learning\u201c. Konzeptionell ist das Ganze eigentlich ziemlich simpel: Anstatt dass wir ein Modell pro Dokumententyp erstellen, anlernen und optimieren, binden wir s\u00e4mtliches Learning auf die darunterliegende Ebene, die Datenpunkt-Extraktoren.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Der Dokumententyp selbst ist dann jeweils nur eine Kollektion von gemeinsam trainierten und verwendeten Datenpunkt-Extraktoren. Das hat viele, massive Vorteile:<\/p>\n\n\n\n
Um die Trainingsaufw\u00e4nde so weit wie m\u00f6glich zu reduzieren, aggregieren wir das Learning aus s\u00e4mtlichen Kunden-Mandanten und s\u00e4mtlichen Dokumententypen vollkommen EU-DSGVO konform und nutzen diese Lernmenge, um alle F\u00e4higkeiten 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.<\/p>\n\n\n\n
Der dritte wichtige Punkt ist, dass dieses Swarm Learning m\u00f6glichst vollautomatisch und permanent erfolgen sollte. Separate Trainingsintervalle, die dann auch noch den User besch\u00e4ftigen, Data Scientists, die irgendwelche Modelle manuell updaten\u2026 Das alles ist teuer und aufw\u00e4ndig. Und verhindert eine schnelle Entwicklung der F\u00e4higkeiten.<\/p>\n\n\n\n
Um das Problem der Lerndokumente zu l\u00f6sen, gibt es nur ein Weg: Die Plattform muss sich durch tausende Anwendungsf\u00e4lle durchlernen. Das braucht zum einen Zeit und zum anderen ben\u00f6tigt es viele Kunden aus m\u00f6glichst verschiedenen Branchen. Bieten wir dem Kunden eine Plattform, mit der er m\u00f6glichst einfach und ohne grosse H\u00fcrden Anwendungsf\u00e4lle umsetzen kann, ist die Chance hoch, dass er das oft und rasch tut.<\/p>\n\n\n\n
Aus einer theoretischen Perspektive ist das alles recht trivial. In der Realit\u00e4t sieht die Welt, wie so oft, komplett anders aus. Jeder dieser drei Komponenten ist per se recht schwierig zu l\u00f6sen. Hinzu kommt, dass wir, um ein rasch skalierendes Modell zu erm\u00f6glichen, Plattformkapazit\u00e4ten bereithalten m\u00fcssen. Es ist etwas v\u00f6llig anderes, ein System f\u00fcr 30k Transaktionen pro Tag zu bauen als ein System f\u00fcr 300k Transaktionen pro Tag. Und, nur weil etwas als Prototyp funktioniert, bedeutet das leider oft nicht zwangsl\u00e4ufig, dass es sich auch in der Produktion ausbezahlt.<\/p>\n\n\n\n
1. Schritt: Basis-Technologie erarbeiten<\/strong><\/p>\n\n\n\n In einem ersten Schritt haben wir die Konzeption und die Basistechnologie erarbeitet, um \u201eDocument Swarm Learning\u201c automatisiert zu betreiben. Wir haben unz\u00e4hlige 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\u00e4hnen w\u00e4re da ein System, welches in Grossunternehmen mit hunderten von Bankkonten Buchungen mithilfe von Machine Learning Gesch\u00e4ftsf\u00e4llen zuordnet und Buchungss\u00e4tze 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).<\/p>\n\n\n\n 2. Schritt: Plattform und \u00d6kosystem erarbeiten, Umsatzquellen erm\u00f6glichen<\/strong><\/p>\n\n\n\n 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:<\/p>\n\n\n\n Als Multiplikatoren in Vertrieb und Integration setzen wir auf Partnerunternehmen. Damit sind wir in der Lage, die eigentlichen Subscriptions in einem f\u00fcr diese Art von Produkt sehr hohen Tempo zu skalieren.<\/p>\n\n\n\n Innert kurzer Zeit, meist in Beta-Stadium, konnten wir viele Kunden gewinnen und nennenswerte, wiederkehrende Ums\u00e4tze generieren. Der ganz grosse Wurf ist das f\u00fcr 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.<\/p>\n\n\n\n Wir k\u00f6nnen mit diesem \u00d6kosystem aus Produkt, Technologie, Partnern und Kunden schnell die notwendigen Dokumenten-Cases durchlernen und immer mehr Standard-Dokumententypen \u201eout-of-the-box\u201c anbieten. Im Moment haben wir rund 350 davon erarbeitet, wovon wir nun laufend welche auf der Plattform ver\u00f6ffentlichen. In naher Zukunft werden wir damit das erste und einzige System am Markt sein, dass mehr als 500 Standard-Dokumententypen ohne Konfiguration \u00fcber eine einzige API konsumierbar vorh\u00e4lt.<\/p>\n\n\n\n Der wichtigste Punkt dieser Phase ist die Kommerzialisierung. Unsere Daten zeigen, dass wir zwar weiterhin signifikant in F&E und Plattformentwicklung investieren m\u00fcssen, gleichzeitig k\u00f6nnen wir mit dem Gesch\u00e4ftsmodell aber auch erhebliches Business generieren. Das m\u00fcssen wir auch, damit wir komfortabel \u201ebankable\u201c bleiben. Alleine diese Phase hat das Potential, Parashift zu einer global erfolgreichen Firma zu machen. Darauf konzentrieren wir uns im Moment, \u00fcber Probleme, welche in der Zukunft und Weiterentwicklung liegen werden, versuchen wir uns auch m\u00f6glichst nicht jetzt zu befassen.<\/p>\n\n\n\n Was also jetzt kommt, sind die n\u00e4chsten strategischen Schritte, welche aber im aktuellen Going der Firma erstmal keine operative\/kommerzielle Relevanz haben.<\/p>\n\n\n\n 3. Schritt:<\/strong> Ein KMU-Offering lancieren<\/strong><\/p>\n\n\n\n Der n\u00e4chste logische Schritt ist das Lancieren eines KMU-Offerings. Dadurch erhalten wir nochmals einen riesigen Schub an weiteren Lern-Cases, die uns vorw\u00e4rts pushen. Wie das Gesch\u00e4ftsmodell f\u00fcr dieses Produkt genau aussehen wird, liegt noch gr\u00f6sstenteils im Dunkeln. Thilo Rossa, unser Chief Product Officer, und ich haben dazu verschiedene Ideen. Klar ist jedoch, es muss geschehen, um von 1\u2018500 Standard-Dokumententypen in Richtung 25\u2018000 und dar\u00fcber hinaus zu kommen.<\/p>\n\n\n\n 4. Schritt:<\/strong> Die universelle Dokumentenverarbeitungs-API skalieren<\/strong><\/p>\n\n\n\n Sind die 25\u2018000 Standard-Dokumententypen erreicht, gibt es f\u00fcr die meisten Dokumenten-Automatisierungs-Cases praktisch keine ernsthaften Alternativen zur Nutzung der Parashift API mehr. Das hat auch damit zu tun, dass es m\u00f6glich sein wird, das Pricing f\u00fcr die Nutzung der API nur knapp \u00fcber den eigentlichen Transaktionskosten zu halten. Ich gehe davon aus, dass wir die (totalen) Kosten pro Transaktion (Dokument) um mehr als 90% senken werden k\u00f6nnen. Damit wird, was mich ganz am Anfang der Reise getriggert hat, die Reise erst anzutreten, tats\u00e4chlich Wirklichkeit.<\/p>\n\n\n\n\n
Von der Produkt- zur Infrastruktur-Company<\/strong><\/h2>\n\n\n\n